<kettenis_>
just double checked them, but they match the j274 ADT
kettenis_ is now known as kettenis
<povik>
yeah, was looking at the .yml, thought likely the right numbers for m1 would be there
<povik>
now there's no confusion
<povik>
j_ey: you may be missing documentation for specifier cells, no?
<povik>
as in, when i refer to a gpio from another device, what do the cells mean
<kettenis>
standard binding
<kettenis>
see gpio.txt (I don't think that has been yamlified yet)
<povik>
that's what i am looking at
<povik>
> The exact meaning of each specifier cell is controller specific, and must be documented in the device tree binding for the device, but it is strongly recommended to use the two-cell approach.
<povik>
okay, should have read the sentence to end
<povik>
:)
<kettenis>
heh, it seems that most bindings actually don't follow that advice
<kettenis>
but it wouldn't be bad to explicitly state in the apple,pinctrl.yaml binding that the two cells are the pin number and the standard bitfield
<kettenis>
using GPIO_ACTIVE_HIGH instead of 0 in the device tree for the pcie reset-gpios field would probably be good as well
<j_ey>
yeah, best to remove all those magic numbers!
<kettenis>
0 is the least magic number of them all though ;)
<alyssa>
what about 3
<alyssa>
that song from when we were kids, said that 3 is a magic number
<kettenis>
another issue with the pinctrl binding is that it lists "clocks" as a property, which is no longer necessary with the pmgr stuff
<kettenis>
but addressing that is probably best left alone until we actually have a pmgr binding
<kettenis>
alyssa: not over here
<alyssa>
...apparently schoolhouse rock live had a run in toronto in '97. i do not know how to feel about that.
<j_ey>
kettenis: its not required at least
<kettenis>
true
<kettenis>
that shouldn't prevent the driver from going in through the appropriate tree
<kettenis>
the actual device tree stuff needs to be coordinated by marcan anyway