[PATCH 2/2] powerpc: pcm030/032: add pagesize to dts

Grant Likely grant.likely at secretlab.ca
Tue Nov 16 08:58:51 EST 2010


On Mon, Nov 15, 2010 at 2:24 PM, Anton Vorontsov <cbouatmailru at gmail.com> wrote:
> On Mon, Nov 15, 2010 at 11:06:44AM -1000, Mitch Bradley wrote:
> [...]
>> >>                    eeprom at 52 {
>> >>                            compatible = "catalyst,24c32";
>> >>                            reg =<0x52>;
>> >>+                           pagesize =<32>;
>> >
>> >I think you'd better drop the pagesize property altogether, and
>> >instead make the compatible string more specific (if needed at
>> >all. are there any 'catalyst,24c32' chips with pagesize != 32?)
>>
>> Microchip makes a 24c32 part that looks pretty similar to the
>> catalyst part, but Microchip's has a 64-byte page size compared to
>> Catalyst's 32.
>
> Well, when using microchip part, the compatible string would be
> "microchip,24c32", correct? Then we have all the information
> already, no need for the pagesize.
>
>> It would probably be feasible to have a generic I2C EEPROM driver
>> that could handle many different parts, parameterized by total size,
>> block size, and page size.

The current at24.c driver is already parameterized; but part of the
parameter data is statically linked into the board support code.

>
> I guess it can do this already via I2C ID table. The problem
> is that I2C core is only using part ID (no vendor ID matching).

This could potentially be changed for at24 devices since the i2c
subsystem already matches by name.  It would mean adding the vendor
prefix to all instantiations of the device in the kernel, although it
would mess up the current heuristic used by of_modalias_node() (not a
show-stopper).

>
> So, the current driver may just implement quirks like this:
>
> if (of_device_is_compatible(np, "catalyst,24c32"))
>        pagesize = 32;
>
> Or, if it's some generic pattern, something like
>
> if (of_device_is_compatible_vendor(np, "catalyst"))
>        pagesize /= 2;

This would get ugly in a hurry.  It would be better to make it data
driven by searching for a better match in an of_device_id table so
that the workarounds don't grow over time and eventually achieve
sentience.

g.


More information about the devicetree-discuss mailing list