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

[Matt Sealey]

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 at 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 <matt at genesi-usa.com>
Genesi, Manager, Developer Relations