Re: [RFC] [PATCH] Device Tree on ARM platform

[Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1714 bytes --]


> It is inherent in the value "atmel,24c08".  Because the exact device
> model is specified, the kernel can know what the page size and flags
> are for that device.

I am afraid this is not the case. I remember that we once had two revisions of
the same eeprom, and the vendor decided to increase the page size without
changing the naming of the eeprom. (Can't point to any documentation yet, would
have to dig this up.) Those eeproms can be really weird.

Also, there are _a lot_ of eeprom manufacturers out there, so the match table
will be enormous....

> OTOH, if it is appropriate for the device, then the binding can be defined to
> include things like page size and flags encoded explicitly in additional
> properties.

..., so I think a property like "page-size" could really be argumented for.
Actually, I am quite optimistic that there could be agreement on it. Maybe we
could also reuse the "read-only" property which is used for partitions. Still,
this discussion has to be done, and that is additional work for mainlining.

Also, this would be _another_ wrapper to collect data from the device tree and
pass it into platform_data. I think it is difficult to maintain. If somebody
extends at24 and forgets about the of-wrapper, it may easily get broken. Plus,
at least for me, coding always very similar stuff, feels like bloating the
kernel. I did it a few times now, and that made me really wonder if we can't
have a more generic solution to that problem. Sadly, I could neither come up
with anything useful :(

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 194 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org
https://ozlabs.org/mailman/listinfo/devicetree-discuss