Ian Lepore wrote at Friday, August 14, 2015 11:46 AM: > On Fri, 2015-08-14 at 09:27 -0500, Rob Herring wrote: > > On Thu, Aug 13, 2015 at 2:04 PM, Ian Lepore <ian@xxxxxxxxxxx> wrote: > > > On Thu, 2015-08-13 at 14:13 -0400, Tom Rini wrote: > > >> On Thu, Aug 13, 2015 at 10:02:58AM -0600, Stephen Warren wrote: ... (Replying from my NVIDIA address, since one of the mail servers in the path to you bounced my last reply. Apologies for any formatting issues.) > > > A great case in point would be i2c eeproms. What a perfect > > > opportunity DT would be to describe everything about the eeprom > > > parts (total capacity, page read/write size, whether the page > > > address bits extend into the bus-slave address bits, etc). It seems > > > to me that anything claiming to be an independent description of the > > > hardware would have to include such things. Instead, all the > > > bindings define is the compatible string. That's crazy. Why? > > > Well, when I went and looked at the Linux eeprom drivers it became > > > clear why: that's all they need to know, because everything else is hard- > > > coded in tables in the driver source. > > > > Think of compatible as a PID/VID pair like USB or PCI. It is simply a > > unique identifier. You don't get any more information with PCI or > > non-class USB devices. DT was originally only solving the problem of > > finding the non-probeable h/w. It's grown to be a lot more with > > today's SOCs. > > > > The more we put into DT the more chance it can be wrong and then we > > have to work around not h/w quirks, but DT quirks. > > > > That said we can always add to the bindings. It would have to be > > worded something like "optional, but required for new dts's". You > > would have to have a new DTB if the OS is dependent on the new > > properties. > > > > > So if I want to write a FreeBSD i2c eeprom driver that uses DT data, > > > what are my choices? I have exactly one: make my driver > > > essentially a clone of the Linux driver, with all the same data hard-coded > > in source. > > > > Don't you already have these drivers w/o using DT? If you did, you > > would have this information already in the drivers. It wouldn't be a > > question of the binding being Linux specific, but rather can we move > > more of the data out of drivers and into DT. That is fundamentally a > > different issue than is a binding Linux specific. > > This last paragraph most eloquently illustrates the point I was trying to make: > From the point of view of someone who only knows about the existing linux > driver and how it is written, the current DT data is perfect. It's exactly what > that existing driver needs to know, and from that position you can argue that > it is thus the ONLY thing any driver written by anyone would need to know. > That assumes that everyone wants to just clone the linux drivers (or in our > case, because of licensing, rewrite the drivers in a completely linux- > compatible way that somehow isn't simply copying them in violation of the > GPL). I believe this is nothing to do with encoding Linuxisms into the DT. It's part of DT itself. DT practice is generally to encode the device model name/number into DT (perhaps with a few properties for extra details) rather than to encode a completely generic device type (e.g. "I2C EEPROM") along with all the possible information anyone could ever want to know about that device. As Rob and Geert mentioned before, "all the possible information" is something that's generally not possible to enumerate fully and/or correctly. If DT weren't an ABI, that might not be a problem; we'd just change the schema, fix the bug and move on. However since DT is an ABI, we can't just go back and fix mistakes. The fact the way DT represents devices aligns well with some aspects of the Linux driver model is nice, but in no way a Linuxism; I believe DT was like this well before Linux used DT. -- nvpbulic ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
