On Mon, Jan 21, 2013 at 08:25:59AM +0100, Thomas De Schampheleire wrote: > On Sun, Jan 20, 2013 at 11:39 PM, Greg KH <[email protected]> wrote: > > On Sun, Jan 20, 2013 at 07:08:28PM +0100, Thomas De Schampheleire wrote: > >> [plaintext and fixed address of David Brownell] > > > > David passed away a year or so ago, so that's really not going to help :( > > So sorry to hear that, I was not aware... > > > > >> Hi, > >> > >> Several of the eeprom drivers that live in drivers/misc/eeprom export > >> a binary sysfs file 'eeprom'. If a userspace program or script wants > >> to access this file, it needs to know the full path, for example: > >> > >> /sys/bus/spi/devices/spi32766.0/eeprom > >> > >> The problem with this approach is that it requires knowledge about the > >> hardware configuration: is the eeprom on the SPI bus, the I2C bus, or > >> maybe memory mapped? > >> > >> It would therefore be more interesting to have a bus-agnostic way to > >> access this eeprom file, for example: > >> /sys/class/eeprom/eeprom0/eeprom > >> > >> Maybe it'd be even better to use a more generic class name than > >> 'eeprom', since there are several types of eeprom-like devices that > >> you could export this way. > > > > Does all of the existing "eeprom" devices use the same userspace > > interface? If so, yes, having a "class" would make sense. > > All but one do. That one (eeprom_93cx6.c) exports its read/write > functions to other kernel code, and is used in several > wireless/ethernet drivers.
Then it shouldn't be used here, right? > >> Or should we rather hook the eeprom code into the mtd subsystem? > > > > Why mtd? > > Because an eeprom is a piece of memory. Maybe mtd is overkill in term > of the operations supported, but from a high-level perspective an > eeprom is a memory technology device, right? Everything is a memory device in the end :) Feel free to send patches, but I don't think this is really a big deal that deserves this type of change at the moment. Feel free to prove me wrong though. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
