[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa686aa40905280634m153ff338j5791a22dba3ad790@mail.gmail.com>
Date: Thu, 28 May 2009 07:34:02 -0600
From: Grant Likely <grant.likely@...retlab.ca>
To: Wolfram Sang <w.sang@...gutronix.de>
Cc: Robert Schwebel <r.schwebel@...gutronix.de>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
devicetree-discuss <devicetree-discuss@...abs.org>,
Russell King - ARM Linux <linux@....linux.org.uk>,
linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.arm.linux.org.uk,
Jon Smirl <jonsmirl@...il.com>,
Scott Wood <scottwood@...escale.com>,
Janboe Ye <yuan-bo.ye@...orola.com>,
Timur Tabi <timur@...escale.com>
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform
On Thu, May 28, 2009 at 12:34 AM, Wolfram Sang <w.sang@...gutronix.de> wrote:
>
>> 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....
... which is the whole point of "compatible". Every possible variant
doesn't get listed in the device driver; device nodes in the tree
claim compatibility with older, already known parts.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists