| Message ID | 1387239151-19226-1-git-send-email-bgamari.foss@gmail.com |
|---|---|
| State | Deferred |
| Headers | show |
On 12/16/2013 05:12 PM, Ben Gamari wrote: > diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > This is a list of trivial i2c devices that have simple device tree > bindings, consisting only of a compatible field, an address and > -possibly an interrupt line. > +possibly an interrupt line. The compatible field is used to lookup the > +modalias of the driver which will handle the device. The compatible > +string may begin with a manufacturer prefix (separated from the > +modalias by a comma) which will be stripped off during lookup. This part of the patch described Linux-specific behaviour, whereas DT bindings should be OS-agnostic. BTW, you didn't CC the DT binding maintainers. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Stephen Warren <swarren@wwwdotorg.org> writes: > On 12/16/2013 05:12 PM, Ben Gamari wrote: > >> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > >> This is a list of trivial i2c devices that have simple device tree >> bindings, consisting only of a compatible field, an address and >> -possibly an interrupt line. >> +possibly an interrupt line. The compatible field is used to lookup the >> +modalias of the driver which will handle the device. The compatible >> +string may begin with a manufacturer prefix (separated from the >> +modalias by a comma) which will be stripped off during lookup. > > This part of the patch described Linux-specific behaviour, whereas DT > bindings should be OS-agnostic. > I see your point but it would be nice to have language like this somewhere. One of the biggest challenges in diving in to writing a devicetree is figuring out details like this. > BTW, you didn't CC the DT binding maintainers. > Very true. Fixed. Cheers, - Ben
On Tue, Dec 17, 2013 at 11:47:19AM -0500, Ben Gamari wrote: > Stephen Warren <swarren@wwwdotorg.org> writes: > > > On 12/16/2013 05:12 PM, Ben Gamari wrote: > > > >> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > > > >> This is a list of trivial i2c devices that have simple device tree > >> bindings, consisting only of a compatible field, an address and > >> -possibly an interrupt line. > >> +possibly an interrupt line. The compatible field is used to lookup the > >> +modalias of the driver which will handle the device. The compatible > >> +string may begin with a manufacturer prefix (separated from the > >> +modalias by a comma) which will be stripped off during lookup. > > > > This part of the patch described Linux-specific behaviour, whereas DT > > bindings should be OS-agnostic. > > > I see your point but it would be nice to have language like this > somewhere. One of the biggest challenges in diving in to writing a > devicetree is figuring out details like this. What about putting this into a seperate paragraph prefixed with "Current Linux specific implementation:"?
Wolfram Sang <wsa@the-dreams.de> writes: > On Tue, Dec 17, 2013 at 11:47:19AM -0500, Ben Gamari wrote: >> Stephen Warren <swarren@wwwdotorg.org> writes: >> >> > On 12/16/2013 05:12 PM, Ben Gamari wrote: >> > >> >> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt >> > >> >> This is a list of trivial i2c devices that have simple device tree >> >> bindings, consisting only of a compatible field, an address and >> >> -possibly an interrupt line. >> >> +possibly an interrupt line. The compatible field is used to lookup the >> >> +modalias of the driver which will handle the device. The compatible >> >> +string may begin with a manufacturer prefix (separated from the >> >> +modalias by a comma) which will be stripped off during lookup. >> > >> > This part of the patch described Linux-specific behaviour, whereas DT >> > bindings should be OS-agnostic. >> > >> I see your point but it would be nice to have language like this >> somewhere. One of the biggest challenges in diving in to writing a >> devicetree is figuring out details like this. > > What about putting this into a seperate paragraph prefixed with "Current > Linux specific implementation:"? > This would address my concern quite nicely. Cheers, - Ben
On 01/13/2014 07:25 AM, Ben Gamari wrote: > Wolfram Sang <wsa@the-dreams.de> writes: > >> On Tue, Dec 17, 2013 at 11:47:19AM -0500, Ben Gamari wrote: >>> Stephen Warren <swarren@wwwdotorg.org> writes: >>> >>>> On 12/16/2013 05:12 PM, Ben Gamari wrote: >>>> >>>>> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt >>>> >>>>> This is a list of trivial i2c devices that have simple device tree >>>>> bindings, consisting only of a compatible field, an address and >>>>> -possibly an interrupt line. >>>>> +possibly an interrupt line. The compatible field is used to lookup the >>>>> +modalias of the driver which will handle the device. The compatible >>>>> +string may begin with a manufacturer prefix (separated from the >>>>> +modalias by a comma) which will be stripped off during lookup. >>>> >>>> This part of the patch described Linux-specific behaviour, whereas DT >>>> bindings should be OS-agnostic. >>>> >>> I see your point but it would be nice to have language like this >>> somewhere. One of the biggest challenges in diving in to writing a >>> devicetree is figuring out details like this. >> >> What about putting this into a seperate paragraph prefixed with "Current >> Linux specific implementation:"? >> > This would address my concern quite nicely. The text should go into Documentation/ not the DT binding. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Stephen Warren <swarren@wwwdotorg.org> writes: > On 01/13/2014 07:25 AM, Ben Gamari wrote: >> Wolfram Sang <wsa@the-dreams.de> writes: >>> What about putting this into a seperate paragraph prefixed with "Current >>> Linux specific implementation:"? >>> >> This would address my concern quite nicely. > > The text should go into Documentation/ not the DT binding. > The problem here is that as it stands DT is quite daunting to pick up. My needs are pretty minimal yet I had to spend many hours sifting through source, blogs, and Documentation/* to get something that more or less worked. The bindings are generally well-documented, but there is no "start here" document in the tree giving conventions and an overview of how Linux in particular uses DT. The closest thing I know of is Documentation/devicetree/usage-model.txt. Perhaps this is where the language Wolfram suggested should be placed. Cheers, - Ben
On Mon, Jan 13, 2014 at 12:26:47PM -0500, Ben Gamari wrote: > Stephen Warren <swarren@wwwdotorg.org> writes: > > > On 01/13/2014 07:25 AM, Ben Gamari wrote: > >> Wolfram Sang <wsa@the-dreams.de> writes: > >>> What about putting this into a seperate paragraph prefixed with "Current > >>> Linux specific implementation:"? > >>> > >> This would address my concern quite nicely. > > > > The text should go into Documentation/ not the DT binding. > > > The problem here is that as it stands DT is quite daunting to pick > up. My needs are pretty minimal yet I had to spend many hours sifting > through source, blogs, and Documentation/* to get something that more or > less worked. The bindings are generally well-documented, but there is no > "start here" document in the tree giving conventions and an overview of > how Linux in particular uses DT. > > The closest thing I know of is Documentation/devicetree/usage-model.txt. > Perhaps this is where the language Wolfram suggested should be placed. I appreciate your effort to improve documentation on how to get started. Sadly, I don't know where the best place would be and I am too busy to look it up. If you are interested, I'll happily apply the outcome, otherwise we sadly have to wait until someone else comes up.
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index b1cb341..0e68085 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -1,6 +1,9 @@ This is a list of trivial i2c devices that have simple device tree bindings, consisting only of a compatible field, an address and -possibly an interrupt line. +possibly an interrupt line. The compatible field is used to lookup the +modalias of the driver which will handle the device. The compatible +string may begin with a manufacturer prefix (separated from the +modalias by a comma) which will be stripped off during lookup. If a device needs more specific bindings, such as properties to describe some aspect of it, there needs to be a specific binding @@ -9,10 +12,10 @@ document for it just like any other devices. Compatible Vendor / Chip ========== ============= +ad,adt7411 I2C Digital 8-channel 10-bit ADC and temperature sensor ad,ad7414 SMBus/I2C Digital Temperature Sensor in 6-Pin SOT with SMBus Alert and Over Temperature Pin ad,adm9240 ADM9240: Complete System Hardware Monitor for uProcessor-Based Systems -adi,adt7461 +/-1C TDM Extended Temp Range I.C -adt7461 +/-1C TDM Extended Temp Range I.C +adi,adt7461 +/-1C SMBus digital thermometer at,24c08 i2c serial eeprom (24cxx) atmel,24c02 i2c serial eeprom (24cxx) atmel,at97sc3204t i2c trusted platform module (TPM)