[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAXf6LXkgLiBLFmwH_GR9hkjFgOJ5z1nSTQd9Q4pJud732Lb9Q@mail.gmail.com>
Date: Sun, 20 Jan 2013 19:08:28 +0100
From: Thomas De Schampheleire <patrickdepinguin@...il.com>
To: linux-kernel@...r.kernel.org, David Brownell <david-b@...bell.net>,
Wolfram Sang <w.sang@...gutronix.de>,
Anatolij Gustschin <agust@...x.de>,
Frodo Looijaard <frodol@....nl>,
Philip Edelbrock <phil@...roedge.com>,
Greg Kroah-Hartman <greg@...ah.com>,
Ben Gardner <bgardner@...tec.com>
Cc: Ronny Meeus <Ronny.Meeus@...il.com>,
Thomas De Schampheleire <patrickdepinguin@...il.com>
Subject: [RFC] Creating an eeprom class
[plaintext and fixed address of David Brownell]
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.
Or should we rather hook the eeprom code into the mtd subsystem?
What is your opinion?
Thanks,
Thomas
--
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