| Age | Commit message (Collapse) | Author |
|---|
|
This driver provides an access to EEPROM of IDT PCIe-switches. IDT PCIe-
switches expose a simple SMBus interface to perform IO-operations from/to
EEPROM, which is located at private (so called Master) SMBus. The driver
creates a simple binary sysfs-file to have an access to the EEPROM using
the SMBus-slave interface in the i2c-device susfs-directory:
/sys/bus/i2c/devices/<bus>-<devaddr>/eeprom
In case if read-only flag is specified at dts-node of the device, User-space
applications won't be able to write to the EEPROM sysfs-node.
Additionally IDT 89HPESx SMBus interface has an ability to read/write
values of device CSRs. This driver exposes debugfs-file to perform simple
IO-operations using that ability for just basic debug purpose. Particularly
the next file is created in the specific debugfs-directory:
/sys/kernel/debug/idt_csr/
Format of the debugfs-file value is:
$ cat /sys/kernel/debug/idt_csr/<bus>-<devaddr>/<devname>;
<CSR address>:<CSR value>
So reading the content of the file gives current CSR address and it value.
If User-space application wishes to change current CSR address, it can just
write a proper value to the sysfs-file:
$ echo "<CSR address>" >
/sys/kernel/debug/idt_csr/<bus>-<devaddr>/<devname>
If it wants to change the CSR value as well, the format of the write
operation is:
$ echo "<CSR address>:<CSR value>" > \
/sys/kernel/debug/idt_csr/<bus>-<devaddr>/<devname>;
CSR address and value can be any of hexadecimal, decimal or octal format.
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Now that we have the nvmem framework, we can consolidate the common
driver code. Move the driver to the framework, and hopefully, it will
fix the sysfs file creation race.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
[srinivas.kandagatla: Moved to regmap based EEPROM framework]
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Allwinner has electric fuses (efuse) on their line of chips. This driver
reads those fuses, seeds the kernel entropy and exports them as a sysfs
node.
These fuses are most likely to be programmed at the factory, encoding
things like Chip ID, some sort of serial number, etc. and appear to be
reasonably unique.
While in theory, these should be writeable by the user, it will probably
be inconvenient to do so. Allwinner recommends that a certain input pin,
labeled 'efuse_vddq', be connected to GND. To write these fuses however,
a 2.5 V programming voltage needs to be applied to this pin.
Even so, they can still be used to generate a board-unique mac from,
board unique RSA key and seed the kernel RNG.
On sun7i additional storage is available, this is initially used for an
UEFI BOOT key, Secure JTAG key, HDMI-HDCP key and vendor specific keys.
Currently supported are the following known chips:
Allwinner sun4i (A10)
Allwinner sun5i (A10s, A13)
Allwinner sun7i (A20)
Signed-off-by: Oliver Schinagl <oliver@schinagl.nl>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Both displays on digsy_mtc board obtain their configuration from microwire
EEPROMs which are connected to the SoC over GPIO lines. We need an easy
way to access the EEPROMs to write the needed display configuration or to
read out the currently programmed configuration. The generic
eeprom_93xx46 SPI driver added by previous patch allows EEPROM access over
sysfs. Using the simple driver added by this patch we provide used GPIO
interface and access control description on the board for generic
eeprom_93xx46 driver and spi_gpio driver.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Jonathan Cameron <jic23@cam.ac.uk>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Add EEPROM driver for 93xx46 chips. It can also be used with spi_gpio
driver to access 93xx46 EEPROMs connected over GPIO lines. This driver
supports read/write/erase access to the EEPROM chips over sysfs files.
[rdunlap@xenotime.net: fix printk format]
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Jonathan Cameron <jic23@cam.ac.uk>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This driver only reads the user EEPROM of that chip, so we can move it
to the eeprom-directory in order to further clean up (and later remove)
drivers/i2c/chips.
The Kconfig text was updated to match the current functionality,
dropping the meanwhile obsoleted parts.
Defconfigs have been adapted.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Ben Gardner <gardner.ben@gmail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
|
|
Now that all EEPROM drivers live in the same place, let's harmonize
their symbol names.
Also fix eeprom's dependencies, it definitely needs sysfs, and is no
longer experimental after many years in the kernel tree.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
|
|
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
|
|
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
|
|
Update Kconfig text to specify this driver as I2C.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
|
|
As drivers/i2c/chips is going to go away, move the driver to
drivers/misc/eeprom. Other eeprom drivers may be moved here later, too.
Update Kconfig text to specify this driver as I2C.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
|
