Re: [PATCH] of: i2c: improve last resort compatible entry selection

2008-07-30 Thread Jon Smirl
On 7/30/08, Grant Likely <[EMAIL PROTECTED]> wrote: > On Mon, Jul 28, 2008 at 09:47:21AM +0200, Segher Boessenkool wrote: > >>> A reasonable "compatible" value would be something like > >>> "serial-eeprom-24c32". > >>> You can go a little bit more generic than that, if you write up in > >>>

Re: [PATCH] of: i2c: improve last resort compatible entry selection

2008-07-30 Thread Grant Likely
On Mon, Jul 28, 2008 at 09:47:21AM +0200, Segher Boessenkool wrote: >>> A reasonable "compatible" value would be something like >>> "serial-eeprom-24c32". >>> You can go a little bit more generic than that, if you write up in >>> your binding how the driver should figure out the device size and

Re: [PATCH] of: i2c: improve last resort compatible entry selection

2008-07-28 Thread Segher Boessenkool
A reasonable "compatible" value would be something like "serial-eeprom-24c32". You can go a little bit more generic than that, if you write up in your binding how the driver should figure out the device size and the protocol used. Matching on "serial-eeprom-24c32" requires me to convince the

Re: [PATCH] of: i2c: improve last resort compatible entry selection

2008-07-27 Thread M. Warner Losh
In message: <[EMAIL PROTECTED]> "Jon Smirl" <[EMAIL PROTECTED]> writes: : On 7/27/08, Segher Boessenkool <[EMAIL PROTECTED]> wrote: : > > : > > > : > > > > compatible = "atmel,24c32wp", "24c32", "eeprom"; : > > > > : > > > : > > : > : > : > > : > > > I know this is just an example; but

Re: [PATCH] of: i2c: improve last resort compatible entry selection

2008-07-27 Thread Jon Smirl
On 7/27/08, Segher Boessenkool <[EMAIL PROTECTED]> wrote: > > > > > > > > > compatible = "atmel,24c32wp", "24c32", "eeprom"; > > > > > > > > > > > > > > > > I know this is just an example; but to keep thinks clear, the second > > > and third values in this compatible property are completely bogus

Re: [PATCH] of: i2c: improve last resort compatible entry selection

2008-07-27 Thread Segher Boessenkool
compatible = "atmel,24c32wp", "24c32", "eeprom"; I know this is just an example; but to keep thinks clear, the second and third values in this compatible property are completely bogus (for device trees). The manufacturer prefix needs to be present and 'eeprom' is far to vague. Isn't 24c

Re: [PATCH] of: i2c: improve last resort compatible entry selection

2008-07-27 Thread Jon Smirl
On 7/27/08, Grant Likely <[EMAIL PROTECTED]> wrote: > On Sun, Jul 27, 2008 at 1:05 AM, Jon Smirl <[EMAIL PROTECTED]> wrote: > > On 7/26/08, Grant Likely <[EMAIL PROTECTED]> wrote: > >> On Mon, Jul 14, 2008 at 09:54:37PM +0400, Anton Vorontsov wrote: > >> > Currently of_i2c will select first com

Re: [PATCH] of: i2c: improve last resort compatible entry selection

2008-07-26 Thread Grant Likely
On Sun, Jul 27, 2008 at 1:05 AM, Jon Smirl <[EMAIL PROTECTED]> wrote: > On 7/26/08, Grant Likely <[EMAIL PROTECTED]> wrote: >> On Mon, Jul 14, 2008 at 09:54:37PM +0400, Anton Vorontsov wrote: >> > Currently of_i2c will select first compatible property as a last resort >> > option. This isn't best

Re: [PATCH] of: i2c: improve last resort compatible entry selection

2008-07-26 Thread Jon Smirl
On 7/26/08, Grant Likely <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 09:54:37PM +0400, Anton Vorontsov wrote: > > Currently of_i2c will select first compatible property as a last resort > > option. This isn't best choice though, because generic compatible entries > > are listed last, no

Re: [PATCH] of: i2c: improve last resort compatible entry selection

2008-07-26 Thread Grant Likely
On Mon, Jul 14, 2008 at 09:54:37PM +0400, Anton Vorontsov wrote: > Currently of_i2c will select first compatible property as a last resort > option. This isn't best choice though, because generic compatible entries > are listed last, not first. For example, two compatible entries given for > the MC

Re: [PATCH] of: i2c: improve last resort compatible entry selection

2008-07-15 Thread Jean Delvare
On Tue, 15 Jul 2008 16:52:01 +0200, Jochen Friedrich wrote: > Hi Jean, > > > Eeeek. The patch you mention here is only the conversion of ONE driver. > > It is absolutely not relevant as to what the general rule is. > > Sorry, i must have misunderstood you then. > > http://git.kernel.org/?p=linux

Re: [PATCH] of: i2c: improve last resort compatible entry selection

2008-07-15 Thread Jochen Friedrich
Hi Jean, > Eeeek. The patch you mention here is only the conversion of ONE driver. > It is absolutely not relevant as to what the general rule is. Sorry, i must have misunderstood you then. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=af294867a52bf718df835a688e

Re: [PATCH] of: i2c: improve last resort compatible entry selection

2008-07-15 Thread Jean Delvare
On Tue, 15 Jul 2008 09:40:08 -0400, Jon Smirl wrote: > On 7/15/08, Jochen Friedrich <[EMAIL PROTECTED]> wrote: > > Hi Anton, > > > > > > > Since no sane driver will ever match specific devices, what we want is > > > to select most generic option (last). Then driver may call > > > of_device_is_co

Re: [PATCH] of: i2c: improve last resort compatible entry selection

2008-07-15 Thread Jon Smirl
On 7/15/08, Jochen Friedrich <[EMAIL PROTECTED]> wrote: > Hi Anton, > > > > Since no sane driver will ever match specific devices, what we want is > > to select most generic option (last). Then driver may call > > of_device_is_compatible() if it is really interested in details. > > > My original

Re: [PATCH] of: i2c: improve last resort compatible entry selection

2008-07-15 Thread Jochen Friedrich
Hi Anton, > Since no sane driver will ever match specific devices, what we want is > to select most generic option (last). Then driver may call > of_device_is_compatible() if it is really interested in details. My original intention was to have alias entries for specific devices in the i2c device

[PATCH] of: i2c: improve last resort compatible entry selection

2008-07-14 Thread Anton Vorontsov
Currently of_i2c will select first compatible property as a last resort option. This isn't best choice though, because generic compatible entries are listed last, not first. For example, two compatible entries given for the MCU node: "fsl,mc9s08qg8-mpc837xrdb", "fsl,mcu-mpc8349emitx"; Since no sa