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
the protocol
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
your binding how the
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 at24
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 compatible
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 24c32 a
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 (for
device trees). The
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 to keep thinks clear, the second
:
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 MCU
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, not first.
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 choice
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 intention
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_compatible() if it
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.
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 sane
14 matches
Mail list logo
