On Mon, Mar 23, 2009 at 19:49, David Brownell <david-b@xxxxxxxxxxx> wrote: > On Sunday 22 March 2009, Kay Sievers wrote: >> On Fri, Mar 20, 2009 at 19:46, David Brownell <david-b@xxxxxxxxxxx> wrote: >> > And there's MTD-specific metadata, like the OTP bits >> > provided on most modern chips and which MTD technology >> > is used by that device. >> >> If we can provide any other useful data to identify devices, it would >> be nice, if someone could make that work. Can such attributes somehow >> be added to sysfs? > > In some cases, maybe ... thing is that OTP (One Time Programmable) > bits vary widely in terms of structure, size, and even presence. > > OTP data in lot of the NAND chips I have here exceeds the sysfs 4KB > binary file limit; 20KB commonly, 128KB for OneNand. There is no such limit for binary sysfs files. We have many large file there, which map such sizes. >> MTD currently creates all devices as "virtual", it does not even use >> the proper parent devices in the kernel, which would at least allow a >> very simple identification, based on the underlying platform device >> properties. > > That would be an entirely separate problem though. ISTR > having a similar "WTF is this doing" reaction last time I > had to look at MTD core driver model stuff. Yeah, it definitely needs fixing. It's not only the driver core, also all mtd devices share a single block request queue for all devices, which is pretty weird. >> I keep an untested and unfinished patch around, I did the last time >> someone tried to solve the problem of reordered mtd devices with udev >> rules: >> http://git.kernel.org/?p=linux/kernel/git/kay/patches.git;a=blob;f=mtd-parent-dev.patch;hb=HEAD > > Looks plausible ... and I may have actually seen a system where > that "problem" matters. (Normally all flash drivers are linked > statically, and the system root uses one of them.) > > That obviously needs to be split into "core" (mtd block and char > dev support) and driver bits; the core bits could go in at any > time once they're ready. > > FWIW I did a quick test of this on a physmap flash ... didn't > work, /sys/devices/virtual/mtd still held everything that was > not in /sys/devices/virtual/block/mtdblock*. I think the issue > might be lack of mtdpart support. Would be great, if you possibly could find out how to get something like this working, so the mtd devices which are backed by real hardware would no longer show up as virtual, and people have at least a chance to identify them by the properties of the platform devices. >> If we can offer people the information which will be available with >> this rather simple change, people can probably switch over to that, >> and we can replace the current one. > > Best to get rid of the currently-broken udev bits first. Done. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
