lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090528063445.GA12004@pengutronix.de>
Date:	Thu, 28 May 2009 08:34:45 +0200
From:	Wolfram Sang <w.sang@...gutronix.de>
To:	Grant Likely <grant.likely@...retlab.ca>
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


> 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/  |

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ