Mitch Bradley wrote:
[EMAIL PROTECTED] {The name here should reflect the purpose of the pin, i.e. what it does (perhaps "NAME,magic"), not the fact that is is GPIO pin. By analogy, an ethernet controller's node name is "ethernet", not "pci-card". The fact that the node represents one or more gpio pins is implicit and obvious - all children of a gpio-controller node are gpio pin(s). All children of a scsi node are SCSI devices, ad nauseum.
Right. I had a similar discussion about this the other day with Anton (I think he forwarded it here but I wasn't subscribed at that point..). The current ideology for device trees is to get rid of device_type for new trees that aren't OF-based. I think it's relevant to give nodes fancy names (i.e. not "timer" or even "ethernet") since the name property is entirely descriptive in nature. I also think it's relevant that device_type still exists because since the name is totally irrelevant except from a user-friendliness point of view, marking a device as a generic type is quite important (device_type = serial, ethernet, rtc, keyboard) where compatible properties are usually wildly over-specific. This reminded me of a discussion I had a long time back that encoding the manufacturer and chip name into EVERY child node was bordering on the insane (and if the dt wasn't compressed in the first place, wasting space) - if you have /soc/usb and they have compatible="fsl,mpc5200b" and "fsl,mpc5200b-usb-ohci" respectively, isn't that encoding redundant information? Someone I think proposed assigning a couple of quirk properties to notify drivers that fsl,mpc5200b-usb-ohci did things differently because of the chip revision, and I was shot down when I asked if the driver could just check it's parent node instead. Apparently current ideology there is to have every node self-contained (however the current practise in the Linux kernel, for example with some PCI quirks, is to search for the parent PCI southbridge and check off some values or disable features there, which I don't think is that much different..) Anyway back to the actual discussion, yes, I should have given it a much fancier name than "gpio_pin" but at the time I wasn't thinking of any particular use and didn't want to confuse by giving it a fancy name like "sleep-controller-wakeup-pin".
It has been my experience that full explicit descriptions are usually a win in the long run. (Which is not to say that I've always done the right thing, but when I have it has often been worthwhile.)
In my view, having an overly descriptive and unwieldy device tree is only bad when you type "ls" on the forth prompt and it scrolls off the screen 8 times. At the driver level One thing I had a crazy dream about was a GUI-based device tree builder for platforms. Instead of editing them manually and passing them through the compiler, wouldn't it be fun to drag and drop system components (and build new ones) into something like a DirectX Filter Graph Builder (or the GStreamer one for that matter) or those GUI SQL database builders, so that you could build a tree and have it output all the craziness and connect phandles to range properties etc. That way dropping a bunch of pins on a GPIO bank, or i2c devices on an i2c bus (I have a board here with an i2c bus with 8 devices on it, I suppose you could have more than 100 if you got your addresses right) and having a device tree that goes on for 8 screens would not be so bad to maintain. And no, I did NOT just volunteer to write one, I'm happy coding my device tree updates in Forth :) -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations _______________________________________________ devicetree-discuss mailing list [email protected] https://ozlabs.org/mailman/listinfo/devicetree-discuss
