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

Mitch Bradley wrote:

I don't use device_type much, if at all, anymore.  Generic name + 
compatible just works better than device_type + specific name.  When

 > I write code that has to find a node that is suitable for a given purpose,
 > I look for the existence of suitable methods and perhaps other properties.
 > I was just too hard to keep the list of device_type values properly
 > synchronized with all the possible things that you might want to infer
 > from that set of names.

The simple problem comes when you define a device_type for everything,
I do agree it's best not to add any *MORE* that aren't in the IEEE1275
or CHRP etc. bindings, but for those that still exist and are well
defined (serial port probably the best, but network devices too) I
think we should keep using them where possible and where relevant.

device_type is one of those things that seemed like a good idea at the 
time, but didn't work out as well as I had hoped.

I can imagine a scenario where you would want to perhaps have a serial
port, where you want to say a) that is is a serial port, b) that it is
for a specific purpose without creating some new standard or proprietary
property set and c) tell the world what kind of serial port it is.

How about name = "debug" or "modem" or something else, which gives you
a pretty name for what the port is for (and maybe matches the markings
on the outside of a case) but the device_type would always be "serial",
and compatible would give you "mpc5200b-psc-uart" or so. You can find
all the serial ports, you can find the serial port that is assigned to
the modem or debug (this may actually allow the driver to be informed
not to do anything crazy - if you've ever connected a modem to a port
that gets set up to output firmware debug data or whatever, you'll know
sometimes it's kind of difficult to bring the modem back out of it's
funk from being hammered with data for the duration of boot), and you
know which driver to attach to it.

I personally think while deprecate and shouldn't be used for new
definitions, the old ones work really well for devices it encompasses.
On the MPC8641D board I have here there are 4 network ports; in the
device tree they're all called ethernet, device_type "network",
compatible "gianfar" and have a model "TSEC" - in a real OF
implementation you shouldn't have to check for a "ping" method to
make sure it's ACTUALLY a network device :D

(I'd advocate all those ports being renamed to eTSEC{n} since that
matches the board documentation, for example, and while cell-index
tells you which port is is on the back of the board, this is not
user friendly (a simple "boot eTSEC0 tftpboot/kernel" is more
intuitive than cd /boot/ethernet@24000, .properties, backing out
if it wasn't the one you were looking for.. or assuming that the
lowest numbered "reg" is the first port on the back of the chassis
and finding out that is not how it's connected :)

I'm really big on descriptive device trees that I can just browse
and know what I am looking at without delving. There is already
too much needless cross-referencing in Linux as it is.

-- 
Matt Sealey [off-list ref]
Genesi, Manager, Developer Relations

On Sun, Oct 26, 2008 at 04:13:26PM -0500, Matt Sealey wrote:

Mitch Bradley wrote:

quoted

I don't use device_type much, if at all, anymore.  Generic name +  
compatible just works better than device_type + specific name.  When
I write code that has to find a node that is suitable for a given purpose,
I look for the existence of suitable methods and perhaps other properties.
I was just too hard to keep the list of device_type values properly
synchronized with all the possible things that you might want to infer
from that set of names.

The simple problem comes when you define a device_type for everything,
I do agree it's best not to add any *MORE* that aren't in the IEEE1275
or CHRP etc. bindings, but for those that still exist and are well
defined (serial port probably the best, but network devices too) I
think we should keep using them where possible and where relevant.

device_type in 1275 defines the runtime method interface.  It's *not*
for declaring the general class of the device, although it often
matches that in practice.  Drivers which attempt to use it this way
are buggy.

So, in the  case of a real OF implementation,  yes, you should include
device_type values as specified by 1275.  Assuming of course that your
implementation  really  does  implement  the OF  method  binding  that
matches the stated device_type.  However, flattened trees clearly
can't provide the method interface, and so shouldn't declare the
device_type.

In practice, we do suggest including device_type in certain, limited,
circumstances precisely because there are a whole bunch of buggy
drivers out there which match (at least partly) on device_type.  We
don't want to break these gratuitously, but neither do we want to
encourage any further spread of using device_type incorrectly for
driver matching.  Hence the current policy.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson