Re: GPIO - marking individual pins (not) available in device tree

[Matt Sealey <matt@genesi-usa.com>]

Scott Wood wrote:
>
>> They did always work. The real sore points here are device bindings and a
>> grand total of nothing changed between OF and now with that.
>>
>> The assertion in ePAPR that device_type is deprecated and ignored 
>> because ePAPR doesn't support FCode is naive at best.
> 
> It's deprecated *in the context of flat device trees*.  Anything not 
> using flat device trees is out-of-scope with respect to ePAPR.

Isn't the beauty of a device tree that every firmware no matter what
type can present it in whatever form it chooses, but still be describing
the same hardware in the same way?

Designing a tree for OF and one for U-Boot should be an absolutely
identical process, internal firmware methodologies notwithstanding
be it pure Forth in Firmworks, C API in Codegen, or output of dtc
for U-Boot, the exact same tree should be output, device_type and
all, within reason. I don't think "it's not real Open Firmware" is
a valid reason. Not as valid as "our firmware doesn't support this
hardware yet so we can't probe or initialize, only describe the bus",
for example (USB on Efika is filled out, USB on U-Boot for Lite5200B
is not).

I'm curious, is it the remit of the ePAPR TSC to publish and act as
a registration authority for device tree bindings for specific SoCs
or is that devolved to the SoC maker itself (be they a member of
Power.org or not) and, more prudent, two other questions; where are
Freescale and IBM publishing these if it is their responsibility,
are things like the mysterious i2c binding going to be published
under this TSC?

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations