From: Bartosz Golaszewski <[email protected]>
Now that nvmem has gained support for defining cells from board files and
looking them up from relevant drivers[1], it's time for a respin of the
previous series[2] that aims at removing struct at24_platform_data from
the tree.
Since I took over maintainership of the at24 driver I've been working
towards removing at24_platform_data in favor for device properties.
DaVinci is the only platform that's still using it - all other users
have already been converted.
One of the obstacles in case of DaVinci is removing the setup() callback
from the pdata struct, the only user of which are some davinci boards.
First we add support for nvmem to MTD in a way previously discussed with
Boris Brezillon and Srinivas Kandagatla.
Then, since most boards use the EEPROM to store the MAC address, we register
relevant cells for all users, implement a function that allows to read
the MAC address from nvmem (and also replaces the previous DT-specific
variant) and make davinci_emac aware of it.
Next we switch all davinci users to using at24 device properties instead
of platform data. While we're at it: we remove all other traces of the
setup callback and platform data from davinci.
Finally we remove the at24 platform data structure.
I kept the review tags in patches that haven't changed from the last
submission.
As far as merging of this series goes: I'd like to avoid dragging it over
four releases. The series is logically split into five groups:
patches 1-2: nvmem and mtd changes
patches 3-9: davinci arch-specific changes
patches 10-13: networking changes
patches 14-24: davinci specific again
patch 25: final at24 change
With that I believe we can do the following: Greg KH could pick up the
first two patches into his char-misc tree. Sekhar would take the second
group and the third would go through the networking tree since the first
three sets are not linked in any way. This would be merged for 4.21. Then
for the next release Sekhar would pick up 14-24, provide an immutable
branch for me and I'd merge the final patch for at24 and send it upstream
through Wolfram's i2c tree (maybe we could even delay the i2c PR in the
merge window to avoid the immutable branch altogether).
[1] https://lkml.org/lkml/2018/9/21/293
[2] https://lkml.org/lkml/2018/8/8/528
Alban Bedel (1):
mtd: add support for reading MTD devices via the nvmem API
Bartosz Golaszewski (24):
nvmem: add new config option
ARM: davinci: dm365-evm: use cell nvmem lookup for mac address
ARM: davinci: dm644x-evm: use cell nvmem lookup for mac address
ARM: davinci: dm646x-evm: use cell nvmem lookup for mac address
ARM: davinci: da830-evm: use cell nvmem lookup for mac address
ARM: davinci: mityomapl138: use cell nvmem lookup for mac address
ARM: davinci: dm850-evm: use cell nvmem lookup for mac address
ARM: davinci: da850-evm: remove unnecessary include
net: ethernet: provide nvmem_get_mac_address()
net: cadence: switch to using nvmem_get_mac_address()
of: net: kill of_get_nvmem_mac_address()
net: davinci_emac: use nvmem_get_mac_address()
ARM: davinci: da850-evm: remove dead MTD code
ARM: davinci: mityomapl138: don't read the MAC address from machine
code
ARM: davinci: dm365-evm: use device properties for at24 eeprom
ARM: davinci: da830-evm: use device properties for at24 eeprom
ARM: davinci: dm644x-evm: use device properties for at24 eeprom
ARM: davinci: dm646x-evm: use device properties for at24 eeprom
ARM: davinci: sffsdr: fix the at24 eeprom device name
ARM: davinci: sffsdr: use device properties for at24 eeprom
ARM: davinci: remove dead code related to MAC address reading
ARM: davinci: mityomapl138: use nvmem notifiers
ARM: davinci: mityomapl138: use device properties for at24 eeprom
eeprom: at24: remove at24_platform_data
MAINTAINERS | 1 -
arch/arm/mach-davinci/board-da830-evm.c | 39 ++++-
arch/arm/mach-davinci/board-da850-evm.c | 58 ++++----
arch/arm/mach-davinci/board-dm365-evm.c | 38 ++++-
arch/arm/mach-davinci/board-dm644x-evm.c | 37 ++++-
arch/arm/mach-davinci/board-dm646x-evm.c | 37 ++++-
arch/arm/mach-davinci/board-mityomapl138.c | 67 ++++++---
arch/arm/mach-davinci/board-sffsdr.c | 13 +-
arch/arm/mach-davinci/common.c | 15 --
drivers/misc/eeprom/at24.c | 162 ++++++++++-----------
drivers/mtd/Kconfig | 1 +
drivers/mtd/mtdcore.c | 56 +++++++
drivers/net/ethernet/cadence/macb_main.c | 2 +-
drivers/net/ethernet/ti/davinci_emac.c | 14 +-
drivers/nvmem/core.c | 3 +-
drivers/of/of_net.c | 39 -----
include/linux/davinci_emac.h | 1 -
include/linux/etherdevice.h | 1 +
include/linux/mtd/mtd.h | 2 +
include/linux/nvmem-provider.h | 2 +
include/linux/of_net.h | 6 -
include/linux/platform_data/at24.h | 60 --------
net/ethernet/eth.c | 38 +++++
23 files changed, 391 insertions(+), 301 deletions(-)
delete mode 100644 include/linux/platform_data/at24.h
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We want to add nvmem support for MTD. TI DaVinci is the first platform
that will be using it, but only in non-DT mode. In order not to
introduce any new interface to supporting of which we would have to
commit - add a new config option that tells nvmem not to use the DT
node of the parent device.
This way we won't be creating nvmem devices corresponding with MTD
partitions defined in device tree. By default MTD will set this new
field to true.
Once a set of bindings for MTD nvmem cells is agreed upon, we'll be
able to remove this option.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
drivers/nvmem/core.c | 3 ++-
include/linux/nvmem-provider.h | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 9b18ce90f907..ac7971e8154e 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -604,7 +604,8 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
nvmem->priv = config->priv;
nvmem->reg_read = config->reg_read;
nvmem->reg_write = config->reg_write;
- nvmem->dev.of_node = config->dev->of_node;
+ if (!config->no_of_node)
+ nvmem->dev.of_node = config->dev->of_node;
if (config->id == -1 && config->name) {
dev_set_name(&nvmem->dev, "%s", config->name);
diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
index 1e3283c2af77..e53545e9852b 100644
--- a/include/linux/nvmem-provider.h
+++ b/include/linux/nvmem-provider.h
@@ -30,6 +30,7 @@ typedef int (*nvmem_reg_write_t)(void *priv, unsigned int offset,
* @ncells: Number of elements in cells.
* @read_only: Device is read-only.
* @root_only: Device is accessibly to root only.
+ * @no_of_node: Device should not use the parent's of_node even if it's !NULL.
* @reg_read: Callback to read data.
* @reg_write: Callback to write data.
* @size: Device size.
@@ -53,6 +54,7 @@ struct nvmem_config {
int ncells;
bool read_only;
bool root_only;
+ bool no_of_node;
nvmem_reg_read_t reg_read;
nvmem_reg_write_t reg_write;
int size;
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We already have of_get_nvmem_mac_address() but some non-DT systems want
to read the MAC address from NVMEM too. Implement a generalized routine
that takes struct device as argument.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
include/linux/etherdevice.h | 1 +
net/ethernet/eth.c | 38 +++++++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+)
diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index 572e11bb8696..2c0af7b00715 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h
@@ -32,6 +32,7 @@
struct device;
int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr);
unsigned char *arch_get_platform_mac_address(void);
+int nvmem_get_mac_address(struct device *dev, void *addrbuf);
u32 eth_get_headlen(void *data, unsigned int max_len);
__be16 eth_type_trans(struct sk_buff *skb, struct net_device *dev);
extern const struct header_ops eth_header_ops;
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index fd8faa0dfa61..df38593d1bb4 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -47,6 +47,7 @@
#include <linux/inet.h>
#include <linux/ip.h>
#include <linux/netdevice.h>
+#include <linux/nvmem-consumer.h>
#include <linux/etherdevice.h>
#include <linux/skbuff.h>
#include <linux/errno.h>
@@ -548,3 +549,40 @@ int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr)
return 0;
}
EXPORT_SYMBOL(eth_platform_get_mac_address);
+
+/**
+ * Obtain the MAC address from an nvmem cell named 'mac-address' associated
+ * with given device.
+ *
+ * @dev: Device with which the mac-address cell is associated.
+ * @addrbuf: Buffer to which the MAC address will be copied on success.
+ *
+ * Returns 0 on success or a negative error number on failure.
+ */
+int nvmem_get_mac_address(struct device *dev, void *addrbuf)
+{
+ struct nvmem_cell *cell;
+ const void *mac;
+ size_t len;
+
+ cell = nvmem_cell_get(dev, "mac-address");
+ if (IS_ERR(cell))
+ return PTR_ERR(cell);
+
+ mac = nvmem_cell_read(cell, &len);
+ nvmem_cell_put(cell);
+
+ if (IS_ERR(mac))
+ return PTR_ERR(mac);
+
+ if (len != ETH_ALEN || !is_valid_ether_addr(mac)) {
+ kfree(mac);
+ return -EINVAL;
+ }
+
+ ether_addr_copy(addrbuf, mac);
+ kfree(mac);
+
+ return 0;
+}
+EXPORT_SYMBOL(nvmem_get_mac_address);
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
There are no more users of at24_platform_data. Remove the relevant
header and modify the driver code to not use it anymore.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
MAINTAINERS | 1 -
drivers/misc/eeprom/at24.c | 162 +++++++++++++----------------
include/linux/platform_data/at24.h | 60 -----------
3 files changed, 75 insertions(+), 148 deletions(-)
delete mode 100644 include/linux/platform_data/at24.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 0abecc528dac..b3ee25e95bd0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2456,7 +2456,6 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
S: Maintained
F: Documentation/devicetree/bindings/eeprom/at24.txt
F: drivers/misc/eeprom/at24.c
-F: include/linux/platform_data/at24.h
ATA OVER ETHERNET (AOE) DRIVER
M: "Ed L. Cashin" <[email protected]>
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 636ed7149793..f189a5307abd 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -22,10 +22,24 @@
#include <linux/i2c.h>
#include <linux/nvmem-provider.h>
#include <linux/regmap.h>
-#include <linux/platform_data/at24.h>
#include <linux/pm_runtime.h>
#include <linux/gpio/consumer.h>
+/* Address pointer is 16 bit. */
+#define AT24_FLAG_ADDR16 BIT(7)
+/* sysfs-entry will be read-only. */
+#define AT24_FLAG_READONLY BIT(6)
+/* sysfs-entry will be world-readable. */
+#define AT24_FLAG_IRUGO BIT(5)
+/* Take always 8 addresses (24c00). */
+#define AT24_FLAG_TAKE8ADDR BIT(4)
+/* Factory-programmed serial number. */
+#define AT24_FLAG_SERIAL BIT(3)
+/* Factory-programmed mac address. */
+#define AT24_FLAG_MAC BIT(2)
+/* Does not auto-rollover reads to the next slave address. */
+#define AT24_FLAG_NO_RDROL BIT(1)
+
/*
* I2C EEPROMs from most vendors are inexpensive and mostly interchangeable.
* Differences between different vendor product lines (like Atmel AT24C or
@@ -107,10 +121,6 @@ module_param_named(write_timeout, at24_write_timeout, uint, 0);
MODULE_PARM_DESC(at24_write_timeout, "Time (in ms) to try writes (default 25)");
struct at24_chip_data {
- /*
- * these fields mirror their equivalents in
- * struct at24_platform_data
- */
u32 byte_len;
u8 flags;
};
@@ -468,63 +478,11 @@ static int at24_write(void *priv, unsigned int off, void *val, size_t count)
return 0;
}
-static void at24_properties_to_pdata(struct device *dev,
- struct at24_platform_data *chip)
-{
- int err;
- u32 val;
-
- if (device_property_present(dev, "read-only"))
- chip->flags |= AT24_FLAG_READONLY;
- if (device_property_present(dev, "no-read-rollover"))
- chip->flags |= AT24_FLAG_NO_RDROL;
-
- err = device_property_read_u32(dev, "address-width", &val);
- if (!err) {
- switch (val) {
- case 8:
- if (chip->flags & AT24_FLAG_ADDR16)
- dev_warn(dev, "Override address width to be 8, while default is 16\n");
- chip->flags &= ~AT24_FLAG_ADDR16;
- break;
- case 16:
- chip->flags |= AT24_FLAG_ADDR16;
- break;
- default:
- dev_warn(dev, "Bad \"address-width\" property: %u\n",
- val);
- }
- }
-
- err = device_property_read_u32(dev, "size", &val);
- if (!err)
- chip->byte_len = val;
-
- err = device_property_read_u32(dev, "pagesize", &val);
- if (!err) {
- chip->page_size = val;
- } else {
- /*
- * This is slow, but we can't know all eeproms, so we better
- * play safe. Specifying custom eeprom-types via platform_data
- * is recommended anyhow.
- */
- chip->page_size = 1;
- }
-}
-
-static int at24_get_pdata(struct device *dev, struct at24_platform_data *pdata)
+static const struct at24_chip_data *at24_get_chip_data(struct device *dev)
{
struct device_node *of_node = dev->of_node;
const struct at24_chip_data *cdata;
const struct i2c_device_id *id;
- struct at24_platform_data *pd;
-
- pd = dev_get_platdata(dev);
- if (pd) {
- memcpy(pdata, pd, sizeof(*pdata));
- return 0;
- }
id = i2c_match_id(at24_ids, to_i2c_client(dev));
@@ -541,13 +499,9 @@ static int at24_get_pdata(struct device *dev, struct at24_platform_data *pdata)
cdata = acpi_device_get_match_data(dev);
if (!cdata)
- return -ENODEV;
+ return ERR_PTR(-ENODEV);
- pdata->byte_len = cdata->byte_len;
- pdata->flags = cdata->flags;
- at24_properties_to_pdata(dev, pdata);
-
- return 0;
+ return cdata;
}
static void at24_remove_dummy_clients(struct at24_data *at24)
@@ -616,7 +570,8 @@ static int at24_probe(struct i2c_client *client)
{
struct regmap_config regmap_config = { };
struct nvmem_config nvmem_config = { };
- struct at24_platform_data pdata = { };
+ u32 byte_len, page_size, flags, addrw;
+ const struct at24_chip_data *cdata;
struct device *dev = &client->dev;
bool i2c_fn_i2c, i2c_fn_block;
unsigned int i, num_addresses;
@@ -631,35 +586,72 @@ static int at24_probe(struct i2c_client *client)
i2c_fn_block = i2c_check_functionality(client->adapter,
I2C_FUNC_SMBUS_WRITE_I2C_BLOCK);
- err = at24_get_pdata(dev, &pdata);
+ cdata = at24_get_chip_data(dev);
+ if (IS_ERR(cdata))
+ return PTR_ERR(cdata);
+
+ err = device_property_read_u32(dev, "pagesize", &page_size);
if (err)
- return err;
+ /*
+ * This is slow, but we can't know all eeproms, so we better
+ * play safe. Specifying custom eeprom-types via platform_data
+ * is recommended anyhow.
+ */
+ page_size = 1;
+
+ flags = cdata->flags;
+ if (device_property_present(dev, "read-only"))
+ flags |= AT24_FLAG_READONLY;
+ if (device_property_present(dev, "no-read-rollover"))
+ flags |= AT24_FLAG_NO_RDROL;
+
+ err = device_property_read_u32(dev, "address-width", &addrw);
+ if (!err) {
+ switch (addrw) {
+ case 8:
+ if (flags & AT24_FLAG_ADDR16)
+ dev_warn(dev,
+ "Override address width to be 8, while default is 16\n");
+ flags &= ~AT24_FLAG_ADDR16;
+ break;
+ case 16:
+ flags |= AT24_FLAG_ADDR16;
+ break;
+ default:
+ dev_warn(dev, "Bad \"address-width\" property: %u\n",
+ addrw);
+ }
+ }
+
+ err = device_property_read_u32(dev, "size", &byte_len);
+ if (err)
+ byte_len = cdata->byte_len;
if (!i2c_fn_i2c && !i2c_fn_block)
- pdata.page_size = 1;
+ page_size = 1;
- if (!pdata.page_size) {
+ if (!page_size) {
dev_err(dev, "page_size must not be 0!\n");
return -EINVAL;
}
- if (!is_power_of_2(pdata.page_size))
+ if (!is_power_of_2(page_size))
dev_warn(dev, "page_size looks suspicious (no power of 2)!\n");
- if (pdata.flags & AT24_FLAG_TAKE8ADDR)
+ if (flags & AT24_FLAG_TAKE8ADDR)
num_addresses = 8;
else
- num_addresses = DIV_ROUND_UP(pdata.byte_len,
- (pdata.flags & AT24_FLAG_ADDR16) ? 65536 : 256);
+ num_addresses = DIV_ROUND_UP(byte_len,
+ (flags & AT24_FLAG_ADDR16) ? 65536 : 256);
- if ((pdata.flags & AT24_FLAG_SERIAL) && (pdata.flags & AT24_FLAG_MAC)) {
+ if ((flags & AT24_FLAG_SERIAL) && (flags & AT24_FLAG_MAC)) {
dev_err(dev,
"invalid device data - cannot have both AT24_FLAG_SERIAL & AT24_FLAG_MAC.");
return -EINVAL;
}
regmap_config.val_bits = 8;
- regmap_config.reg_bits = (pdata.flags & AT24_FLAG_ADDR16) ? 16 : 8;
+ regmap_config.reg_bits = (flags & AT24_FLAG_ADDR16) ? 16 : 8;
regmap_config.disable_locking = true;
regmap = devm_regmap_init_i2c(client, ®map_config);
@@ -672,11 +664,11 @@ static int at24_probe(struct i2c_client *client)
return -ENOMEM;
mutex_init(&at24->lock);
- at24->byte_len = pdata.byte_len;
- at24->page_size = pdata.page_size;
- at24->flags = pdata.flags;
+ at24->byte_len = byte_len;
+ at24->page_size = page_size;
+ at24->flags = flags;
at24->num_addresses = num_addresses;
- at24->offset_adj = at24_get_offset_adj(pdata.flags, pdata.byte_len);
+ at24->offset_adj = at24_get_offset_adj(flags, byte_len);
at24->client[0].client = client;
at24->client[0].regmap = regmap;
@@ -684,10 +676,10 @@ static int at24_probe(struct i2c_client *client)
if (IS_ERR(at24->wp_gpio))
return PTR_ERR(at24->wp_gpio);
- writable = !(pdata.flags & AT24_FLAG_READONLY);
+ writable = !(flags & AT24_FLAG_READONLY);
if (writable) {
at24->write_max = min_t(unsigned int,
- pdata.page_size, at24_io_limit);
+ page_size, at24_io_limit);
if (!i2c_fn_i2c && at24->write_max > I2C_SMBUS_BLOCK_MAX)
at24->write_max = I2C_SMBUS_BLOCK_MAX;
}
@@ -730,7 +722,7 @@ static int at24_probe(struct i2c_client *client)
nvmem_config.priv = at24;
nvmem_config.stride = 1;
nvmem_config.word_size = 1;
- nvmem_config.size = pdata.byte_len;
+ nvmem_config.size = byte_len;
at24->nvmem = devm_nvmem_register(dev, &nvmem_config);
if (IS_ERR(at24->nvmem)) {
@@ -739,13 +731,9 @@ static int at24_probe(struct i2c_client *client)
}
dev_info(dev, "%u byte %s EEPROM, %s, %u bytes/write\n",
- pdata.byte_len, client->name,
+ byte_len, client->name,
writable ? "writable" : "read-only", at24->write_max);
- /* export data to kernel code */
- if (pdata.setup)
- pdata.setup(at24->nvmem, pdata.context);
-
return 0;
err_clients:
diff --git a/include/linux/platform_data/at24.h b/include/linux/platform_data/at24.h
deleted file mode 100644
index 63507ff464ee..000000000000
--- a/include/linux/platform_data/at24.h
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * at24.h - platform_data for the at24 (generic eeprom) driver
- * (C) Copyright 2008 by Pengutronix
- * (C) Copyright 2012 by Wolfram Sang
- * same license as the driver
- */
-
-#ifndef _LINUX_AT24_H
-#define _LINUX_AT24_H
-
-#include <linux/types.h>
-#include <linux/nvmem-consumer.h>
-#include <linux/bitops.h>
-
-/**
- * struct at24_platform_data - data to set up at24 (generic eeprom) driver
- * @byte_len: size of eeprom in byte
- * @page_size: number of byte which can be written in one go
- * @flags: tunable options, check AT24_FLAG_* defines
- * @setup: an optional callback invoked after eeprom is probed; enables kernel
- code to access eeprom via nvmem, see example
- * @context: optional parameter passed to setup()
- *
- * If you set up a custom eeprom type, please double-check the parameters.
- * Especially page_size needs extra care, as you risk data loss if your value
- * is bigger than what the chip actually supports!
- *
- * An example in pseudo code for a setup() callback:
- *
- * void get_mac_addr(struct nvmem_device *nvmem, void *context)
- * {
- * u8 *mac_addr = ethernet_pdata->mac_addr;
- * off_t offset = context;
- *
- * // Read MAC addr from EEPROM
- * if (nvmem_device_read(nvmem, offset, ETH_ALEN, mac_addr) == ETH_ALEN)
- * pr_info("Read MAC addr from EEPROM: %pM\n", mac_addr);
- * }
- *
- * This function pointer and context can now be set up in at24_platform_data.
- */
-
-struct at24_platform_data {
- u32 byte_len; /* size (sum of all addr) */
- u16 page_size; /* for writes */
- u8 flags;
-#define AT24_FLAG_ADDR16 BIT(7) /* address pointer is 16 bit */
-#define AT24_FLAG_READONLY BIT(6) /* sysfs-entry will be read-only */
-#define AT24_FLAG_IRUGO BIT(5) /* sysfs-entry will be world-readable */
-#define AT24_FLAG_TAKE8ADDR BIT(4) /* take always 8 addresses (24c00) */
-#define AT24_FLAG_SERIAL BIT(3) /* factory-programmed serial number */
-#define AT24_FLAG_MAC BIT(2) /* factory-programmed mac address */
-#define AT24_FLAG_NO_RDROL BIT(1) /* does not auto-rollover reads to */
- /* the next slave address */
-
- void (*setup)(struct nvmem_device *nvmem, void *context);
- void *context;
-};
-
-#endif /* _LINUX_AT24_H */
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
Stop using the at24_platform_data setup callback in favor of nvmem
notifiers.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
arch/arm/mach-davinci/board-mityomapl138.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 3286dc2457a5..ac1a1699d185 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -15,6 +15,8 @@
#include <linux/console.h>
#include <linux/platform_device.h>
#include <linux/mtd/partitions.h>
+#include <linux/notifier.h>
+#include <linux/nvmem-consumer.h>
#include <linux/nvmem-provider.h>
#include <linux/regulator/machine.h>
#include <linux/i2c.h>
@@ -117,10 +119,15 @@ static void mityomapl138_cpufreq_init(const char *partnum)
static void mityomapl138_cpufreq_init(const char *partnum) { }
#endif
-static void read_factory_config(struct nvmem_device *nvmem, void *context)
+static int read_factory_config(struct notifier_block *nb,
+ unsigned long event, void *data)
{
int ret;
const char *partnum = NULL;
+ struct nvmem_device *nvmem = data;
+
+ if (strcmp(nvmem_dev_name(nvmem), "1-00500") != 0)
+ return NOTIFY_DONE;
if (!IS_BUILTIN(CONFIG_NVMEM)) {
pr_warn("Factory Config not available without CONFIG_NVMEM\n");
@@ -152,8 +159,14 @@ static void read_factory_config(struct nvmem_device *nvmem, void *context)
bad_config:
/* default maximum speed is valid for all platforms */
mityomapl138_cpufreq_init(partnum);
+
+ return NOTIFY_STOP;
}
+static struct notifier_block mityomapl138_nvmem_notifier = {
+ .notifier_call = read_factory_config,
+};
+
/*
* We don't define a cell for factory config as it will be accessed from the
* board file using the nvmem notifier chain.
@@ -183,8 +196,6 @@ static struct at24_platform_data mityomapl138_fd_chip = {
.byte_len = 256,
.page_size = 8,
.flags = AT24_FLAG_READONLY | AT24_FLAG_IRUGO,
- .setup = read_factory_config,
- .context = NULL,
};
static struct davinci_i2c_platform_data mityomap_i2c_0_pdata = {
@@ -561,6 +572,7 @@ static void __init mityomapl138_init(void)
davinci_serial_init(da8xx_serial_device);
+ nvmem_register_notifier(&mityomapl138_nvmem_notifier);
nvmem_add_cell_table(&mityomapl138_nvmem_cell_table);
nvmem_add_cell_lookups(&mityomapl138_nvmem_cell_lookup, 1);
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
The currently used 24lc64 i2c device name doesn't match against any
of the devices supported by the at24 driver. Change it to the closest
compatible chip.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
arch/arm/mach-davinci/board-sffsdr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c
index 792bb84d5011..acd9778ffa07 100644
--- a/arch/arm/mach-davinci/board-sffsdr.c
+++ b/arch/arm/mach-davinci/board-sffsdr.c
@@ -100,7 +100,7 @@ static struct at24_platform_data eeprom_info = {
static struct i2c_board_info __initdata i2c_info[] = {
{
- I2C_BOARD_INFO("24lc64", 0x50),
+ I2C_BOARD_INFO("24c64", 0x50),
.platform_data = &eeprom_info,
},
/* Other I2C devices:
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the at24_platform_data structure and replace it with an array
of property entries. Drop the byte_len/size property, as the model name
already implies the EEPROM's size.
Signed-off-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
---
arch/arm/mach-davinci/board-dm644x-evm.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index e1428115067f..efe4e170e87d 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -16,8 +16,8 @@
#include <linux/gpio/machine.h>
#include <linux/i2c.h>
#include <linux/platform_data/pcf857x.h>
-#include <linux/platform_data/at24.h>
#include <linux/platform_data/gpio-davinci.h>
+#include <linux/property.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
@@ -532,12 +532,9 @@ static struct nvmem_cell_lookup dm644evm_nvmem_cell_lookup = {
.con_id = "mac-address",
};
-static struct at24_platform_data eeprom_info = {
- .byte_len = (256*1024) / 8,
- .page_size = 64,
- .flags = AT24_FLAG_ADDR16,
- .setup = davinci_get_mac_addr,
- .context = (void *)0x7f00,
+static const struct property_entry eeprom_properties[] = {
+ PROPERTY_ENTRY_U32("pagesize", 64),
+ { }
};
/*
@@ -647,7 +644,7 @@ static struct i2c_board_info __initdata i2c_info[] = {
},
{
I2C_BOARD_INFO("24c256", 0x50),
- .platform_data = &eeprom_info,
+ .properties = eeprom_properties,
},
{
I2C_BOARD_INFO("tlv320aic33", 0x1b),
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the at24_platform_data structure and replace it with an array
of property entries. Drop the byte_len/size property, as the model name
already implies the EEPROM's size.
Signed-off-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
---
arch/arm/mach-davinci/board-dm646x-evm.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index 8d5be6dd2019..02b57face113 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -22,7 +22,7 @@
#include <linux/gpio.h>
#include <linux/platform_device.h>
#include <linux/i2c.h>
-#include <linux/platform_data/at24.h>
+#include <linux/property.h>
#include <linux/platform_data/pcf857x.h>
#include <linux/platform_data/ti-aemif.h>
@@ -364,12 +364,9 @@ static struct nvmem_cell_lookup dm646x_evm_nvmem_cell_lookup = {
.con_id = "mac-address",
};
-static struct at24_platform_data eeprom_info = {
- .byte_len = (256*1024) / 8,
- .page_size = 64,
- .flags = AT24_FLAG_ADDR16,
- .setup = davinci_get_mac_addr,
- .context = (void *)0x7f00,
+static const struct property_entry eeprom_properties[] = {
+ PROPERTY_ENTRY_U32("pagesize", 64),
+ { }
};
#endif
@@ -440,7 +437,7 @@ static void evm_init_cpld(void)
static struct i2c_board_info __initdata i2c_info[] = {
{
I2C_BOARD_INFO("24c256", 0x50),
- .platform_data = &eeprom_info,
+ .properties = eeprom_properties,
},
{
I2C_BOARD_INFO("pcf8574a", 0x38),
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the at24_platform_data structure and replace it with an array
of property entries. Drop the byte_len/size property, as the model name
already implies the EEPROM's size.
Signed-off-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
---
arch/arm/mach-davinci/board-da830-evm.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index e52ec1619b70..ddd871d8b44c 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -18,7 +18,7 @@
#include <linux/platform_device.h>
#include <linux/i2c.h>
#include <linux/platform_data/pcf857x.h>
-#include <linux/platform_data/at24.h>
+#include <linux/property.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
#include <linux/spi/spi.h>
@@ -457,12 +457,9 @@ static struct nvmem_cell_lookup da830_evm_nvmem_cell_lookup = {
.con_id = "mac-address",
};
-static struct at24_platform_data da830_evm_i2c_eeprom_info = {
- .byte_len = SZ_256K / 8,
- .page_size = 64,
- .flags = AT24_FLAG_ADDR16,
- .setup = davinci_get_mac_addr,
- .context = (void *)0x7f00,
+static const struct property_entry da830_evm_i2c_eeprom_properties[] = {
+ PROPERTY_ENTRY_U32("pagesize", 64),
+ { }
};
static int __init da830_evm_ui_expander_setup(struct i2c_client *client,
@@ -496,7 +493,7 @@ static struct pcf857x_platform_data __initdata da830_evm_ui_expander_info = {
static struct i2c_board_info __initdata da830_evm_i2c_devices[] = {
{
I2C_BOARD_INFO("24c256", 0x50),
- .platform_data = &da830_evm_i2c_eeprom_info,
+ .properties = da830_evm_i2c_eeprom_properties,
},
{
I2C_BOARD_INFO("tlv320aic3x", 0x18),
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
This is now done by the emac driver using a registered nvmem cell.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
arch/arm/mach-davinci/board-mityomapl138.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 8df16e81b69e..3286dc2457a5 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -121,7 +121,6 @@ static void read_factory_config(struct nvmem_device *nvmem, void *context)
{
int ret;
const char *partnum = NULL;
- struct davinci_soc_info *soc_info = &davinci_soc_info;
if (!IS_BUILTIN(CONFIG_NVMEM)) {
pr_warn("Factory Config not available without CONFIG_NVMEM\n");
@@ -147,13 +146,6 @@ static void read_factory_config(struct nvmem_device *nvmem, void *context)
goto bad_config;
}
- pr_info("Found MAC = %pM\n", factory_config.mac);
- if (is_valid_ether_addr(factory_config.mac))
- memcpy(soc_info->emac_pdata->mac_addr,
- factory_config.mac, ETH_ALEN);
- else
- pr_warn("Invalid MAC found in factory config block\n");
-
partnum = factory_config.partnum;
pr_info("Part Number = %s\n", partnum);
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We no longer need to register the MTD notifier to read the MAC address
as it's now being done in the emac driver.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
arch/arm/mach-davinci/board-da850-evm.c | 28 -------------------------
1 file changed, 28 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 6a29baf0a289..128dd7d8dff6 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -150,32 +150,6 @@ static struct spi_board_info da850evm_spi_info[] = {
},
};
-#ifdef CONFIG_MTD
-static void da850_evm_m25p80_notify_add(struct mtd_info *mtd)
-{
- char *mac_addr = davinci_soc_info.emac_pdata->mac_addr;
- size_t retlen;
-
- if (!strcmp(mtd->name, "MAC-Address")) {
- mtd_read(mtd, 0, ETH_ALEN, &retlen, mac_addr);
- if (retlen == ETH_ALEN)
- pr_info("Read MAC addr from SPI Flash: %pM\n",
- mac_addr);
- }
-}
-
-static struct mtd_notifier da850evm_spi_notifier = {
- .add = da850_evm_m25p80_notify_add,
-};
-
-static void da850_evm_setup_mac_addr(void)
-{
- register_mtd_user(&da850evm_spi_notifier);
-}
-#else
-static void da850_evm_setup_mac_addr(void) { }
-#endif
-
static struct mtd_partition da850_evm_norflash_partition[] = {
{
.name = "bootloaders + env",
@@ -1494,8 +1468,6 @@ static __init void da850_evm_init(void)
if (ret)
pr_warn("%s: SATA registration failed: %d\n", __func__, ret);
- da850_evm_setup_mac_addr();
-
ret = da8xx_register_rproc();
if (ret)
pr_warn("%s: dsp/rproc registration failed: %d\n",
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the at24_platform_data structure and replace it with an array
of property entries. Drop the byte_len/size property, as the model name
already implies the EEPROM's size.
Signed-off-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
---
arch/arm/mach-davinci/board-dm365-evm.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index 8703fc18dd3b..f016584285b0 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -18,7 +18,7 @@
#include <linux/i2c.h>
#include <linux/io.h>
#include <linux/clk.h>
-#include <linux/platform_data/at24.h>
+#include <linux/property.h>
#include <linux/leds.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
@@ -225,18 +225,15 @@ static struct nvmem_cell_lookup davinci_nvmem_cell_lookup = {
.con_id = "mac-address",
};
-static struct at24_platform_data eeprom_info = {
- .byte_len = (256*1024) / 8,
- .page_size = 64,
- .flags = AT24_FLAG_ADDR16,
- .setup = davinci_get_mac_addr,
- .context = (void *)0x7f00,
+static const struct property_entry eeprom_properties[] = {
+ PROPERTY_ENTRY_U32("pagesize", 64),
+ { }
};
static struct i2c_board_info i2c_info[] = {
{
I2C_BOARD_INFO("24c256", 0x50),
- .platform_data = &eeprom_info,
+ .properties = eeprom_properties,
},
{
I2C_BOARD_INFO("tlv320aic3x", 0x18),
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
There are no more users of davinci_get_mac_addr(). Remove it.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
arch/arm/mach-davinci/common.c | 15 ---------------
include/linux/davinci_emac.h | 1 -
2 files changed, 16 deletions(-)
diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
index e1d0f0d841ff..0c638fe15dcb 100644
--- a/arch/arm/mach-davinci/common.c
+++ b/arch/arm/mach-davinci/common.c
@@ -26,21 +26,6 @@ EXPORT_SYMBOL(davinci_soc_info);
void __iomem *davinci_intc_base;
int davinci_intc_type;
-void davinci_get_mac_addr(struct nvmem_device *nvmem, void *context)
-{
- char *mac_addr = davinci_soc_info.emac_pdata->mac_addr;
- off_t offset = (off_t)context;
-
- if (!IS_BUILTIN(CONFIG_NVMEM)) {
- pr_warn("Cannot read MAC addr from EEPROM without CONFIG_NVMEM\n");
- return;
- }
-
- /* Read MAC addr from EEPROM */
- if (nvmem_device_read(nvmem, offset, ETH_ALEN, mac_addr) == ETH_ALEN)
- pr_info("Read MAC addr from EEPROM: %pM\n", mac_addr);
-}
-
static int __init davinci_init_id(struct davinci_soc_info *soc_info)
{
int i;
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index 05b97144d342..28e6cf1356da 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -46,5 +46,4 @@ enum {
EMAC_VERSION_2, /* DM646x */
};
-void davinci_get_mac_addr(struct nvmem_device *nvmem, void *context);
#endif
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the at24_platform_data structure and replace it with an array
of property entries. Drop the byte_len/size property, as the model name
already implies the EEPROM's size.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
arch/arm/mach-davinci/board-mityomapl138.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index ac1a1699d185..a381b26328d8 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -14,13 +14,13 @@
#include <linux/init.h>
#include <linux/console.h>
#include <linux/platform_device.h>
+#include <linux/property.h>
#include <linux/mtd/partitions.h>
#include <linux/notifier.h>
#include <linux/nvmem-consumer.h>
#include <linux/nvmem-provider.h>
#include <linux/regulator/machine.h>
#include <linux/i2c.h>
-#include <linux/platform_data/at24.h>
#include <linux/etherdevice.h>
#include <linux/spi/spi.h>
#include <linux/spi/flash.h>
@@ -192,10 +192,10 @@ static struct nvmem_cell_lookup mityomapl138_nvmem_cell_lookup = {
.con_id = "mac-address",
};
-static struct at24_platform_data mityomapl138_fd_chip = {
- .byte_len = 256,
- .page_size = 8,
- .flags = AT24_FLAG_READONLY | AT24_FLAG_IRUGO,
+static const struct property_entry mityomapl138_fd_chip_properties[] = {
+ PROPERTY_ENTRY_U32("pagesize", 8),
+ PROPERTY_ENTRY_BOOL("read-only"),
+ { }
};
static struct davinci_i2c_platform_data mityomap_i2c_0_pdata = {
@@ -324,7 +324,7 @@ static struct i2c_board_info __initdata mityomap_tps65023_info[] = {
},
{
I2C_BOARD_INFO("24c02", 0x50),
- .platform_data = &mityomapl138_fd_chip,
+ .properties = mityomapl138_fd_chip_properties,
},
};
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the at24_platform_data structure and replace it with an array
of property entries. Drop the byte_len/size property, as the model name
already implies the EEPROM's size.
Signed-off-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
---
arch/arm/mach-davinci/board-sffsdr.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c
index acd9778ffa07..ff14de1396c8 100644
--- a/arch/arm/mach-davinci/board-sffsdr.c
+++ b/arch/arm/mach-davinci/board-sffsdr.c
@@ -26,7 +26,7 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/i2c.h>
-#include <linux/platform_data/at24.h>
+#include <linux/property.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
@@ -92,16 +92,15 @@ static struct platform_device davinci_sffsdr_nandflash_device = {
.resource = davinci_sffsdr_nandflash_resource,
};
-static struct at24_platform_data eeprom_info = {
- .byte_len = (64*1024) / 8,
- .page_size = 32,
- .flags = AT24_FLAG_ADDR16,
+static const struct property_entry eeprom_properties[] = {
+ PROPERTY_ENTRY_U32("pagesize", 32),
+ { }
};
static struct i2c_board_info __initdata i2c_info[] = {
{
I2C_BOARD_INFO("24c64", 0x50),
- .platform_data = &eeprom_info,
+ .properties = eeprom_properties,
},
/* Other I2C devices:
* MSP430, addr 0x23 (not used)
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We now support nvmem lookups and cell definitions for machine code.
Add relevant data structures for the mac-address stored in at24 EEPROM.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
arch/arm/mach-davinci/board-da850-evm.c | 29 +++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index e1a949b47306..bac2162e2153 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -28,6 +28,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
+#include <linux/nvmem-provider.h>
#include <linux/mtd/physmap.h>
#include <linux/platform_device.h>
#include <linux/platform_data/gpio-davinci.h>
@@ -100,6 +101,31 @@ static struct mtd_partition da850evm_spiflash_part[] = {
},
};
+static struct nvmem_cell_info da850evm_nvmem_cells[] = {
+ {
+ .name = "macaddr",
+ .offset = 0x0,
+ .bytes = ETH_ALEN,
+ }
+};
+
+static struct nvmem_cell_table da850evm_nvmem_cell_table = {
+ /*
+ * The nvmem name differs from the partition name because of the
+ * internal works of the nvmem framework.
+ */
+ .nvmem_name = "MAC-Address0",
+ .cells = da850evm_nvmem_cells,
+ .ncells = ARRAY_SIZE(da850evm_nvmem_cells),
+};
+
+static struct nvmem_cell_lookup da850evm_nvmem_cell_lookup = {
+ .nvmem_name = "MAC-Address0",
+ .cell_name = "macaddr",
+ .dev_id = "davinci_emac.1",
+ .con_id = "mac-address",
+};
+
static struct flash_platform_data da850evm_spiflash_data = {
.name = "m25p80",
.parts = da850evm_spiflash_part,
@@ -1395,6 +1421,9 @@ static __init void da850_evm_init(void)
davinci_serial_init(da8xx_serial_device);
+ nvmem_add_cell_table(&da850evm_nvmem_cell_table);
+ nvmem_add_cell_lookups(&da850evm_nvmem_cell_lookup, 1);
+
i2c_register_board_info(1, da850_evm_i2c_devices,
ARRAY_SIZE(da850_evm_i2c_devices));
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We now support nvmem lookups and cell definitions for machine code.
Add relevant data structures for the mac-address stored in at24 EEPROM.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
arch/arm/mach-davinci/board-dm646x-evm.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index 3e5ee09ee717..8d5be6dd2019 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -32,6 +32,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
+#include <linux/nvmem-provider.h>
#include <linux/clk.h>
#include <linux/export.h>
#include <linux/platform_data/gpio-davinci.h>
@@ -342,6 +343,27 @@ static struct pcf857x_platform_data pcf_data = {
* - ... newer boards may have more
*/
+static struct nvmem_cell_info dm646x_evm_nvmem_cells[] = {
+ {
+ .name = "macaddr",
+ .offset = 0x7f00,
+ .bytes = ETH_ALEN,
+ }
+};
+
+static struct nvmem_cell_table dm646x_evm_nvmem_cell_table = {
+ .nvmem_name = "1-00500",
+ .cells = dm646x_evm_nvmem_cells,
+ .ncells = ARRAY_SIZE(dm646x_evm_nvmem_cells),
+};
+
+static struct nvmem_cell_lookup dm646x_evm_nvmem_cell_lookup = {
+ .nvmem_name = "1-00500",
+ .cell_name = "macaddr",
+ .dev_id = "davinci_emac.1",
+ .con_id = "mac-address",
+};
+
static struct at24_platform_data eeprom_info = {
.byte_len = (256*1024) / 8,
.page_size = 64,
@@ -815,6 +837,8 @@ static __init void evm_init(void)
pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
#ifdef CONFIG_I2C
+ nvmem_add_cell_table(&dm646x_evm_nvmem_cell_table);
+ nvmem_add_cell_lookups(&dm646x_evm_nvmem_cell_lookup, 1);
evm_init_i2c();
#endif
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We now support nvmem lookups and cell definitions for machine code.
Add relevant data structures for the mac-address stored in at24 EEPROM.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
arch/arm/mach-davinci/board-da830-evm.c | 26 +++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 7d8ab36ff83d..e52ec1619b70 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -30,6 +30,7 @@
#include <linux/platform_data/usb-davinci.h>
#include <linux/platform_data/ti-aemif.h>
#include <linux/regulator/machine.h>
+#include <linux/nvmem-provider.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -435,6 +436,27 @@ static inline void da830_evm_init_lcdc(int mux_mode)
static inline void da830_evm_init_lcdc(int mux_mode) { }
#endif
+static struct nvmem_cell_info da830_evm_nvmem_cells[] = {
+ {
+ .name = "macaddr",
+ .offset = 0x7f00,
+ .bytes = ETH_ALEN,
+ }
+};
+
+static struct nvmem_cell_table da830_evm_nvmem_cell_table = {
+ .nvmem_name = "1-00500",
+ .cells = da830_evm_nvmem_cells,
+ .ncells = ARRAY_SIZE(da830_evm_nvmem_cells),
+};
+
+static struct nvmem_cell_lookup da830_evm_nvmem_cell_lookup = {
+ .nvmem_name = "1-00500",
+ .cell_name = "macaddr",
+ .dev_id = "davinci_emac.1",
+ .con_id = "mac-address",
+};
+
static struct at24_platform_data da830_evm_i2c_eeprom_info = {
.byte_len = SZ_256K / 8,
.page_size = 64,
@@ -620,6 +642,10 @@ static __init void da830_evm_init(void)
__func__, ret);
davinci_serial_init(da8xx_serial_device);
+
+ nvmem_add_cell_table(&da830_evm_nvmem_cell_table);
+ nvmem_add_cell_lookups(&da830_evm_nvmem_cell_lookup, 1);
+
i2c_register_board_info(1, da830_evm_i2c_devices,
ARRAY_SIZE(da830_evm_i2c_devices));
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We now support nvmem lookups and cell definitions for machine code.
Add relevant data structures for the mac-address stored in at24 EEPROM.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
arch/arm/mach-davinci/board-dm365-evm.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index 8143756ff38b..8703fc18dd3b 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -24,6 +24,7 @@
#include <linux/mtd/partitions.h>
#include <linux/slab.h>
#include <linux/mtd/rawnand.h>
+#include <linux/nvmem-provider.h>
#include <linux/input.h>
#include <linux/spi/spi.h>
#include <linux/spi/eeprom.h>
@@ -203,6 +204,27 @@ static struct platform_device davinci_aemif_device = {
.num_resources = ARRAY_SIZE(davinci_aemif_resources),
};
+static struct nvmem_cell_info davinci_nvmem_cells[] = {
+ {
+ .name = "macaddr",
+ .offset = 0x7f00,
+ .bytes = ETH_ALEN,
+ }
+};
+
+static struct nvmem_cell_table davinci_nvmem_cell_table = {
+ .nvmem_name = "1-00500",
+ .cells = davinci_nvmem_cells,
+ .ncells = ARRAY_SIZE(davinci_nvmem_cells),
+};
+
+static struct nvmem_cell_lookup davinci_nvmem_cell_lookup = {
+ .nvmem_name = "1-00500",
+ .cell_name = "macaddr",
+ .dev_id = "davinci_emac.1",
+ .con_id = "mac-address",
+};
+
static struct at24_platform_data eeprom_info = {
.byte_len = (256*1024) / 8,
.page_size = 64,
@@ -781,6 +803,9 @@ static __init void dm365_evm_init(void)
if (ret)
pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
+ nvmem_add_cell_table(&davinci_nvmem_cell_table);
+ nvmem_add_cell_lookups(&davinci_nvmem_cell_lookup, 1);
+
evm_init_i2c();
davinci_serial_init(dm365_serial_device);
--
2.19.1
From: Alban Bedel <[email protected]>
Allow drivers that use the nvmem API to read data stored on MTD devices.
For this the mtd devices are registered as read-only NVMEM providers.
We don't support device tree systems for now.
Signed-off-by: Alban Bedel <[email protected]>
[Bartosz:
- include linux/nvmem-provider.h
- set the name of the nvmem provider
- set no_of_node to true in nvmem_config
- don't check the return value of nvmem_unregister() - it cannot fail
- tweaked the commit message]
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
drivers/mtd/Kconfig | 1 +
drivers/mtd/mtdcore.c | 56 +++++++++++++++++++++++++++++++++++++++++
include/linux/mtd/mtd.h | 2 ++
3 files changed, 59 insertions(+)
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index c77f537323ec..efbe7a6f1d8f 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -1,5 +1,6 @@
menuconfig MTD
tristate "Memory Technology Device (MTD) support"
+ imply NVMEM
help
Memory Technology Devices are flash, RAM and similar chips, often
used for solid state file systems on embedded devices. This option
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 97ac219c082e..5f1053d995b0 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -41,6 +41,7 @@
#include <linux/reboot.h>
#include <linux/leds.h>
#include <linux/debugfs.h>
+#include <linux/nvmem-provider.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
@@ -488,6 +489,50 @@ int mtd_pairing_groups(struct mtd_info *mtd)
}
EXPORT_SYMBOL_GPL(mtd_pairing_groups);
+static int mtd_nvmem_reg_read(void *priv, unsigned int offset,
+ void *val, size_t bytes)
+{
+ struct mtd_info *mtd = priv;
+ size_t retlen;
+ int err;
+
+ err = mtd_read(mtd, offset, bytes, &retlen, val);
+ if (err && err != -EUCLEAN)
+ return err;
+
+ return retlen == bytes ? 0 : -EIO;
+}
+
+static int mtd_nvmem_add(struct mtd_info *mtd)
+{
+ struct nvmem_config config = {};
+
+ config.dev = &mtd->dev;
+ config.name = mtd->name;
+ config.owner = THIS_MODULE;
+ config.reg_read = mtd_nvmem_reg_read;
+ config.size = mtd->size;
+ config.word_size = 1;
+ config.stride = 1;
+ config.read_only = true;
+ config.root_only = true;
+ config.no_of_node = true;
+ config.priv = mtd;
+
+ mtd->nvmem = nvmem_register(&config);
+ if (IS_ERR(mtd->nvmem)) {
+ /* Just ignore if there is no NVMEM support in the kernel */
+ if (PTR_ERR(mtd->nvmem) == -ENOSYS) {
+ mtd->nvmem = NULL;
+ } else {
+ dev_err(&mtd->dev, "Failed to register NVMEM device\n");
+ return PTR_ERR(mtd->nvmem);
+ }
+ }
+
+ return 0;
+}
+
static struct dentry *dfs_dir_mtd;
/**
@@ -570,6 +615,11 @@ int add_mtd_device(struct mtd_info *mtd)
if (error)
goto fail_added;
+ /* Add the nvmem provider */
+ error = mtd_nvmem_add(mtd);
+ if (error)
+ goto fail_nvmem_add;
+
if (!IS_ERR_OR_NULL(dfs_dir_mtd)) {
mtd->dbg.dfs_dir = debugfs_create_dir(dev_name(&mtd->dev), dfs_dir_mtd);
if (IS_ERR_OR_NULL(mtd->dbg.dfs_dir)) {
@@ -595,6 +645,8 @@ int add_mtd_device(struct mtd_info *mtd)
__module_get(THIS_MODULE);
return 0;
+fail_nvmem_add:
+ device_unregister(&mtd->dev);
fail_added:
of_node_put(mtd_get_of_node(mtd));
idr_remove(&mtd_idr, i);
@@ -637,6 +689,10 @@ int del_mtd_device(struct mtd_info *mtd)
mtd->index, mtd->name, mtd->usecount);
ret = -EBUSY;
} else {
+ /* Try to remove the NVMEM provider */
+ if (mtd->nvmem)
+ nvmem_unregister(mtd->nvmem);
+
device_unregister(&mtd->dev);
idr_remove(&mtd_idr, mtd->index);
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index cd0be91bdefa..545070c2ee64 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -25,6 +25,7 @@
#include <linux/notifier.h>
#include <linux/device.h>
#include <linux/of.h>
+#include <linux/nvmem-provider.h>
#include <mtd/mtd-abi.h>
@@ -341,6 +342,7 @@ struct mtd_info {
struct device dev;
int usecount;
struct mtd_debug_info dbg;
+ struct nvmem_device *nvmem;
};
int mtd_ooblayout_ecc(struct mtd_info *mtd, int section,
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We've switched all users to nvmem_get_mac_address(). Remove the now
dead code.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
drivers/of/of_net.c | 39 ---------------------------------------
include/linux/of_net.h | 6 ------
2 files changed, 45 deletions(-)
diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
index 53189d4022a6..810ab0fbcccb 100644
--- a/drivers/of/of_net.c
+++ b/drivers/of/of_net.c
@@ -81,42 +81,3 @@ const void *of_get_mac_address(struct device_node *np)
return of_get_mac_addr(np, "address");
}
EXPORT_SYMBOL(of_get_mac_address);
-
-/**
- * Obtain the MAC address from an nvmem provider named 'mac-address' through
- * device tree.
- * On success, copies the new address into memory pointed to by addr and
- * returns 0. Returns a negative error code otherwise.
- * @np: Device tree node containing the nvmem-cells phandle
- * @addr: Pointer to receive the MAC address using ether_addr_copy()
- */
-int of_get_nvmem_mac_address(struct device_node *np, void *addr)
-{
- struct nvmem_cell *cell;
- const void *mac;
- size_t len;
- int ret;
-
- cell = of_nvmem_cell_get(np, "mac-address");
- if (IS_ERR(cell))
- return PTR_ERR(cell);
-
- mac = nvmem_cell_read(cell, &len);
-
- nvmem_cell_put(cell);
-
- if (IS_ERR(mac))
- return PTR_ERR(mac);
-
- if (len < ETH_ALEN || !is_valid_ether_addr(mac)) {
- ret = -EINVAL;
- } else {
- ether_addr_copy(addr, mac);
- ret = 0;
- }
-
- kfree(mac);
-
- return ret;
-}
-EXPORT_SYMBOL(of_get_nvmem_mac_address);
diff --git a/include/linux/of_net.h b/include/linux/of_net.h
index 90d81ee9e6a0..9cd72aab76fe 100644
--- a/include/linux/of_net.h
+++ b/include/linux/of_net.h
@@ -13,7 +13,6 @@
struct net_device;
extern int of_get_phy_mode(struct device_node *np);
extern const void *of_get_mac_address(struct device_node *np);
-extern int of_get_nvmem_mac_address(struct device_node *np, void *addr);
extern struct net_device *of_find_net_device_by_node(struct device_node *np);
#else
static inline int of_get_phy_mode(struct device_node *np)
@@ -26,11 +25,6 @@ static inline const void *of_get_mac_address(struct device_node *np)
return NULL;
}
-static inline int of_get_nvmem_mac_address(struct device_node *np, void *addr)
-{
- return -ENODEV;
-}
-
static inline struct net_device *of_find_net_device_by_node(struct device_node *np)
{
return NULL;
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We now have a generalized helper routine to read the MAC address from
nvmem which takes struct device as argument. The nvmem subsystem will
then try device tree first before all other potential providers.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
drivers/net/ethernet/cadence/macb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 1d86b4d5645a..d9a208f7bb40 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -4055,7 +4055,7 @@ static int macb_probe(struct platform_device *pdev)
if (mac) {
ether_addr_copy(bp->dev->dev_addr, mac);
} else {
- err = of_get_nvmem_mac_address(np, bp->dev->dev_addr);
+ err = nvmem_get_mac_address(&pdev->dev, bp->dev->dev_addr);
if (err) {
if (err == -EPROBE_DEFER)
goto err_out_free_netdev;
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
All DaVinci boards still supported in board files now define nvmem
cells containing the MAC address. We want to stop using the setup
callback from at24 so the MAC address for those users will no longer
be provided over platform data. If we didn't get a valid MAC in pdata,
try nvmem before resorting to a random MAC.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
drivers/net/ethernet/ti/davinci_emac.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 9153db120352..840820402cd0 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1912,11 +1912,15 @@ static int davinci_emac_probe(struct platform_device *pdev)
ether_addr_copy(ndev->dev_addr, priv->mac_addr);
if (!is_valid_ether_addr(priv->mac_addr)) {
- /* Use random MAC if none passed */
- eth_hw_addr_random(ndev);
- memcpy(priv->mac_addr, ndev->dev_addr, ndev->addr_len);
- dev_warn(&pdev->dev, "using random MAC addr: %pM\n",
- priv->mac_addr);
+ /* Try nvmem if MAC wasn't passed over pdata or DT. */
+ rc = nvmem_get_mac_address(&pdev->dev, priv->mac_addr);
+ if (rc) {
+ /* Use random MAC if still none obtained. */
+ eth_hw_addr_random(ndev);
+ memcpy(priv->mac_addr, ndev->dev_addr, ndev->addr_len);
+ dev_warn(&pdev->dev, "using random MAC addr: %pM\n",
+ priv->mac_addr);
+ }
}
ndev->netdev_ops = &emac_netdev_ops;
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
The include file for at24_platform_data is not needed in this file.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
arch/arm/mach-davinci/board-da850-evm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index bac2162e2153..6a29baf0a289 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -20,7 +20,6 @@
#include <linux/kernel.h>
#include <linux/leds.h>
#include <linux/i2c.h>
-#include <linux/platform_data/at24.h>
#include <linux/platform_data/pca953x.h>
#include <linux/input.h>
#include <linux/input/tps6507x-ts.h>
--
2.19.1
wt., 13 lis 2018 o 15:01 Bartosz Golaszewski <[email protected]> napisał(a):
>
> From: Bartosz Golaszewski <[email protected]>
>
> Now that nvmem has gained support for defining cells from board files and
> looking them up from relevant drivers[1], it's time for a respin of the
> previous series[2] that aims at removing struct at24_platform_data from
> the tree.
>
> Since I took over maintainership of the at24 driver I've been working
> towards removing at24_platform_data in favor for device properties.
>
> DaVinci is the only platform that's still using it - all other users
> have already been converted.
>
> One of the obstacles in case of DaVinci is removing the setup() callback
> from the pdata struct, the only user of which are some davinci boards.
>
> First we add support for nvmem to MTD in a way previously discussed with
> Boris Brezillon and Srinivas Kandagatla.
>
> Then, since most boards use the EEPROM to store the MAC address, we register
> relevant cells for all users, implement a function that allows to read
> the MAC address from nvmem (and also replaces the previous DT-specific
> variant) and make davinci_emac aware of it.
>
> Next we switch all davinci users to using at24 device properties instead
> of platform data. While we're at it: we remove all other traces of the
> setup callback and platform data from davinci.
>
> Finally we remove the at24 platform data structure.
>
> I kept the review tags in patches that haven't changed from the last
> submission.
>
> As far as merging of this series goes: I'd like to avoid dragging it over
> four releases. The series is logically split into five groups:
>
> patches 1-2: nvmem and mtd changes
> patches 3-9: davinci arch-specific changes
> patches 10-13: networking changes
> patches 14-24: davinci specific again
> patch 25: final at24 change
>
> With that I believe we can do the following: Greg KH could pick up the
> first two patches into his char-misc tree. Sekhar would take the second
> group and the third would go through the networking tree since the first
> three sets are not linked in any way. This would be merged for 4.21. Then
> for the next release Sekhar would pick up 14-24, provide an immutable
> branch for me and I'd merge the final patch for at24 and send it upstream
> through Wolfram's i2c tree (maybe we could even delay the i2c PR in the
> merge window to avoid the immutable branch altogether).
>
> [1] https://lkml.org/lkml/2018/9/21/293
> [2] https://lkml.org/lkml/2018/8/8/528
>
> Alban Bedel (1):
> mtd: add support for reading MTD devices via the nvmem API
>
> Bartosz Golaszewski (24):
> nvmem: add new config option
> ARM: davinci: dm365-evm: use cell nvmem lookup for mac address
> ARM: davinci: dm644x-evm: use cell nvmem lookup for mac address
> ARM: davinci: dm646x-evm: use cell nvmem lookup for mac address
> ARM: davinci: da830-evm: use cell nvmem lookup for mac address
> ARM: davinci: mityomapl138: use cell nvmem lookup for mac address
> ARM: davinci: dm850-evm: use cell nvmem lookup for mac address
> ARM: davinci: da850-evm: remove unnecessary include
> net: ethernet: provide nvmem_get_mac_address()
> net: cadence: switch to using nvmem_get_mac_address()
> of: net: kill of_get_nvmem_mac_address()
> net: davinci_emac: use nvmem_get_mac_address()
> ARM: davinci: da850-evm: remove dead MTD code
> ARM: davinci: mityomapl138: don't read the MAC address from machine
> code
> ARM: davinci: dm365-evm: use device properties for at24 eeprom
> ARM: davinci: da830-evm: use device properties for at24 eeprom
> ARM: davinci: dm644x-evm: use device properties for at24 eeprom
> ARM: davinci: dm646x-evm: use device properties for at24 eeprom
> ARM: davinci: sffsdr: fix the at24 eeprom device name
> ARM: davinci: sffsdr: use device properties for at24 eeprom
> ARM: davinci: remove dead code related to MAC address reading
> ARM: davinci: mityomapl138: use nvmem notifiers
> ARM: davinci: mityomapl138: use device properties for at24 eeprom
> eeprom: at24: remove at24_platform_data
>
> MAINTAINERS | 1 -
> arch/arm/mach-davinci/board-da830-evm.c | 39 ++++-
> arch/arm/mach-davinci/board-da850-evm.c | 58 ++++----
> arch/arm/mach-davinci/board-dm365-evm.c | 38 ++++-
> arch/arm/mach-davinci/board-dm644x-evm.c | 37 ++++-
> arch/arm/mach-davinci/board-dm646x-evm.c | 37 ++++-
> arch/arm/mach-davinci/board-mityomapl138.c | 67 ++++++---
> arch/arm/mach-davinci/board-sffsdr.c | 13 +-
> arch/arm/mach-davinci/common.c | 15 --
> drivers/misc/eeprom/at24.c | 162 ++++++++++-----------
> drivers/mtd/Kconfig | 1 +
> drivers/mtd/mtdcore.c | 56 +++++++
> drivers/net/ethernet/cadence/macb_main.c | 2 +-
> drivers/net/ethernet/ti/davinci_emac.c | 14 +-
> drivers/nvmem/core.c | 3 +-
> drivers/of/of_net.c | 39 -----
> include/linux/davinci_emac.h | 1 -
> include/linux/etherdevice.h | 1 +
> include/linux/mtd/mtd.h | 2 +
> include/linux/nvmem-provider.h | 2 +
> include/linux/of_net.h | 6 -
> include/linux/platform_data/at24.h | 60 --------
> net/ethernet/eth.c | 38 +++++
> 23 files changed, 391 insertions(+), 301 deletions(-)
> delete mode 100644 include/linux/platform_data/at24.h
>
> --
> 2.19.1
>
Ugh the subject was supposed to be: at24: remove platform data...
From: Bartosz Golaszewski <[email protected]>
We now support nvmem lookups and cell definitions for machine code.
Add relevant data structures for the mac-address stored in at24 EEPROM.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
arch/arm/mach-davinci/board-mityomapl138.c | 29 ++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 2933e0c87cfa..8df16e81b69e 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -15,6 +15,7 @@
#include <linux/console.h>
#include <linux/platform_device.h>
#include <linux/mtd/partitions.h>
+#include <linux/nvmem-provider.h>
#include <linux/regulator/machine.h>
#include <linux/i2c.h>
#include <linux/platform_data/at24.h>
@@ -161,6 +162,31 @@ static void read_factory_config(struct nvmem_device *nvmem, void *context)
mityomapl138_cpufreq_init(partnum);
}
+/*
+ * We don't define a cell for factory config as it will be accessed from the
+ * board file using the nvmem notifier chain.
+ */
+static struct nvmem_cell_info mityomapl138_nvmem_cells[] = {
+ {
+ .name = "macaddr",
+ .offset = 0x64,
+ .bytes = ETH_ALEN,
+ }
+};
+
+static struct nvmem_cell_table mityomapl138_nvmem_cell_table = {
+ .nvmem_name = "1-00500",
+ .cells = mityomapl138_nvmem_cells,
+ .ncells = ARRAY_SIZE(mityomapl138_nvmem_cells),
+};
+
+static struct nvmem_cell_lookup mityomapl138_nvmem_cell_lookup = {
+ .nvmem_name = "1-00500",
+ .cell_name = "macaddr",
+ .dev_id = "davinci_emac.1",
+ .con_id = "mac-address",
+};
+
static struct at24_platform_data mityomapl138_fd_chip = {
.byte_len = 256,
.page_size = 8,
@@ -543,6 +569,9 @@ static void __init mityomapl138_init(void)
davinci_serial_init(da8xx_serial_device);
+ nvmem_add_cell_table(&mityomapl138_nvmem_cell_table);
+ nvmem_add_cell_lookups(&mityomapl138_nvmem_cell_lookup, 1);
+
ret = da8xx_register_i2c(0, &mityomap_i2c_0_pdata);
if (ret)
pr_warn("i2c0 registration failed: %d\n", ret);
--
2.19.1
From: Bartosz Golaszewski <[email protected]>
We now support nvmem lookups and cell definitions for machine code.
Add relevant data structures for the mac-address stored in at24 EEPROM.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
arch/arm/mach-davinci/board-dm644x-evm.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index e4a8f9225d16..e1428115067f 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -22,6 +22,7 @@
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/physmap.h>
+#include <linux/nvmem-provider.h>
#include <linux/phy.h>
#include <linux/clk.h>
#include <linux/videodev2.h>
@@ -510,6 +511,27 @@ static struct pcf857x_platform_data pcf_data_u35 = {
* - ... newer boards may have more
*/
+static struct nvmem_cell_info dm644evm_nvmem_cells[] = {
+ {
+ .name = "macaddr",
+ .offset = 0x7f00,
+ .bytes = ETH_ALEN,
+ }
+};
+
+static struct nvmem_cell_table dm644evm_nvmem_cell_table = {
+ .nvmem_name = "1-00500",
+ .cells = dm644evm_nvmem_cells,
+ .ncells = ARRAY_SIZE(dm644evm_nvmem_cells),
+};
+
+static struct nvmem_cell_lookup dm644evm_nvmem_cell_lookup = {
+ .nvmem_name = "1-00500",
+ .cell_name = "macaddr",
+ .dev_id = "davinci_emac.1",
+ .con_id = "mac-address",
+};
+
static struct at24_platform_data eeprom_info = {
.byte_len = (256*1024) / 8,
.page_size = 64,
@@ -842,6 +864,8 @@ static __init void davinci_evm_init(void)
platform_add_devices(davinci_evm_devices,
ARRAY_SIZE(davinci_evm_devices));
#ifdef CONFIG_I2C
+ nvmem_add_cell_table(&dm644evm_nvmem_cell_table);
+ nvmem_add_cell_lookups(&dm644evm_nvmem_cell_lookup, 1);
evm_init_i2c();
davinci_setup_mmc(0, &dm6446evm_mmc_config);
#endif
--
2.19.1
Bartosz,
Thanks for keeping at this!
> for the next release Sekhar would pick up 14-24, provide an immutable
> branch for me and I'd merge the final patch for at24 and send it upstream
> through Wolfram's i2c tree (maybe we could even delay the i2c PR in the
> merge window to avoid the immutable branch altogether).
But we want linux-next coverage. So, I think an immutable branch makes
sense.
Wolfram
On Tue, 13 Nov 2018 15:01:20 +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <[email protected]>
>
> We've switched all users to nvmem_get_mac_address(). Remove the now
> dead code.
>
> Signed-off-by: Bartosz Golaszewski <[email protected]>
> ---
> drivers/of/of_net.c | 39 ---------------------------------------
> include/linux/of_net.h | 6 ------
> 2 files changed, 45 deletions(-)
>
Reviewed-by: Rob Herring <[email protected]>
On 13/11/2018 at 15:01, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <[email protected]>
>
> We now have a generalized helper routine to read the MAC address from
> nvmem which takes struct device as argument. The nvmem subsystem will
> then try device tree first before all other potential providers.
>
> Signed-off-by: Bartosz Golaszewski <[email protected]>
Acked-by: Nicolas Ferre <[email protected]>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index 1d86b4d5645a..d9a208f7bb40 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -4055,7 +4055,7 @@ static int macb_probe(struct platform_device *pdev)
> if (mac) {
> ether_addr_copy(bp->dev->dev_addr, mac);
> } else {
> - err = of_get_nvmem_mac_address(np, bp->dev->dev_addr);
> + err = nvmem_get_mac_address(&pdev->dev, bp->dev->dev_addr);
> if (err) {
> if (err == -EPROBE_DEFER)
> goto err_out_free_netdev;
>
--
Nicolas Ferre
On Tue, 13 Nov 2018 15:01:08 +0100
Bartosz Golaszewski <[email protected]> wrote:
> As far as merging of this series goes: I'd like to avoid dragging it over
> four releases. The series is logically split into five groups:
>
> patches 1-2: nvmem and mtd changes
> patches 3-9: davinci arch-specific changes
> patches 10-13: networking changes
> patches 14-24: davinci specific again
> patch 25: final at24 change
>
> With that I believe we can do the following: Greg KH could pick up the
> first two patches into his char-misc tree.
The char-misc tree? Why not the MTD or NVMEM tree?
> Sekhar would take the second
> group and the third would go through the networking tree since the first
> three sets are not linked in any way. This would be merged for 4.21. Then
> for the next release Sekhar would pick up 14-24, provide an immutable
> branch for me and I'd merge the final patch for at24 and send it upstream
> through Wolfram's i2c tree (maybe we could even delay the i2c PR in the
> merge window to avoid the immutable branch altogether).
On Tue, 13 Nov 2018 15:01:10 +0100
Bartosz Golaszewski <[email protected]> wrote:
> From: Alban Bedel <[email protected]>
>
> Allow drivers that use the nvmem API to read data stored on MTD devices.
> For this the mtd devices are registered as read-only NVMEM providers.
>
> We don't support device tree systems for now.
>
> Signed-off-by: Alban Bedel <[email protected]>
> [Bartosz:
> - include linux/nvmem-provider.h
> - set the name of the nvmem provider
> - set no_of_node to true in nvmem_config
> - don't check the return value of nvmem_unregister() - it cannot fail
> - tweaked the commit message]
> Signed-off-by: Bartosz Golaszewski <[email protected]>
Acked-by: Boris Brezillon <[email protected]>
To the person taking this patch (Greg?): I'll need an immutable tag,
just in case we end up with other changes in mtdcore.c for this release.
> ---
> drivers/mtd/Kconfig | 1 +
> drivers/mtd/mtdcore.c | 56 +++++++++++++++++++++++++++++++++++++++++
> include/linux/mtd/mtd.h | 2 ++
> 3 files changed, 59 insertions(+)
>
> diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
> index c77f537323ec..efbe7a6f1d8f 100644
> --- a/drivers/mtd/Kconfig
> +++ b/drivers/mtd/Kconfig
> @@ -1,5 +1,6 @@
> menuconfig MTD
> tristate "Memory Technology Device (MTD) support"
> + imply NVMEM
> help
> Memory Technology Devices are flash, RAM and similar chips, often
> used for solid state file systems on embedded devices. This option
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 97ac219c082e..5f1053d995b0 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -41,6 +41,7 @@
> #include <linux/reboot.h>
> #include <linux/leds.h>
> #include <linux/debugfs.h>
> +#include <linux/nvmem-provider.h>
>
> #include <linux/mtd/mtd.h>
> #include <linux/mtd/partitions.h>
> @@ -488,6 +489,50 @@ int mtd_pairing_groups(struct mtd_info *mtd)
> }
> EXPORT_SYMBOL_GPL(mtd_pairing_groups);
>
> +static int mtd_nvmem_reg_read(void *priv, unsigned int offset,
> + void *val, size_t bytes)
> +{
> + struct mtd_info *mtd = priv;
> + size_t retlen;
> + int err;
> +
> + err = mtd_read(mtd, offset, bytes, &retlen, val);
> + if (err && err != -EUCLEAN)
> + return err;
> +
> + return retlen == bytes ? 0 : -EIO;
> +}
> +
> +static int mtd_nvmem_add(struct mtd_info *mtd)
> +{
> + struct nvmem_config config = {};
> +
> + config.dev = &mtd->dev;
> + config.name = mtd->name;
> + config.owner = THIS_MODULE;
> + config.reg_read = mtd_nvmem_reg_read;
> + config.size = mtd->size;
> + config.word_size = 1;
> + config.stride = 1;
> + config.read_only = true;
> + config.root_only = true;
> + config.no_of_node = true;
> + config.priv = mtd;
> +
> + mtd->nvmem = nvmem_register(&config);
> + if (IS_ERR(mtd->nvmem)) {
> + /* Just ignore if there is no NVMEM support in the kernel */
> + if (PTR_ERR(mtd->nvmem) == -ENOSYS) {
> + mtd->nvmem = NULL;
> + } else {
> + dev_err(&mtd->dev, "Failed to register NVMEM device\n");
> + return PTR_ERR(mtd->nvmem);
> + }
> + }
> +
> + return 0;
> +}
> +
> static struct dentry *dfs_dir_mtd;
>
> /**
> @@ -570,6 +615,11 @@ int add_mtd_device(struct mtd_info *mtd)
> if (error)
> goto fail_added;
>
> + /* Add the nvmem provider */
> + error = mtd_nvmem_add(mtd);
> + if (error)
> + goto fail_nvmem_add;
> +
> if (!IS_ERR_OR_NULL(dfs_dir_mtd)) {
> mtd->dbg.dfs_dir = debugfs_create_dir(dev_name(&mtd->dev), dfs_dir_mtd);
> if (IS_ERR_OR_NULL(mtd->dbg.dfs_dir)) {
> @@ -595,6 +645,8 @@ int add_mtd_device(struct mtd_info *mtd)
> __module_get(THIS_MODULE);
> return 0;
>
> +fail_nvmem_add:
> + device_unregister(&mtd->dev);
> fail_added:
> of_node_put(mtd_get_of_node(mtd));
> idr_remove(&mtd_idr, i);
> @@ -637,6 +689,10 @@ int del_mtd_device(struct mtd_info *mtd)
> mtd->index, mtd->name, mtd->usecount);
> ret = -EBUSY;
> } else {
> + /* Try to remove the NVMEM provider */
> + if (mtd->nvmem)
> + nvmem_unregister(mtd->nvmem);
> +
> device_unregister(&mtd->dev);
>
> idr_remove(&mtd_idr, mtd->index);
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index cd0be91bdefa..545070c2ee64 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -25,6 +25,7 @@
> #include <linux/notifier.h>
> #include <linux/device.h>
> #include <linux/of.h>
> +#include <linux/nvmem-provider.h>
>
> #include <mtd/mtd-abi.h>
>
> @@ -341,6 +342,7 @@ struct mtd_info {
> struct device dev;
> int usecount;
> struct mtd_debug_info dbg;
> + struct nvmem_device *nvmem;
> };
>
> int mtd_ooblayout_ecc(struct mtd_info *mtd, int section,
niedz., 18 lis 2018 o 17:03 Boris Brezillon
<[email protected]> napisał(a):
>
> On Tue, 13 Nov 2018 15:01:08 +0100
> Bartosz Golaszewski <[email protected]> wrote:
>
> > As far as merging of this series goes: I'd like to avoid dragging it over
> > four releases. The series is logically split into five groups:
> >
> > patches 1-2: nvmem and mtd changes
> > patches 3-9: davinci arch-specific changes
> > patches 10-13: networking changes
> > patches 14-24: davinci specific again
> > patch 25: final at24 change
> >
> > With that I believe we can do the following: Greg KH could pick up the
> > first two patches into his char-misc tree.
>
> The char-misc tree? Why not the MTD or NVMEM tree?
>
There is no NVMEM tree - Srinivas sends his patches to Greg to be
applied to char-misc.
The second patch depends on the first one so in order to avoid more
merging problems I suggested that the MTD patch go through char-misc
as well. If you see a better solution, please let me know.
Bart
On Mon, 19 Nov 2018 09:58:46 +0100
Bartosz Golaszewski <[email protected]> wrote:
> niedz., 18 lis 2018 o 17:03 Boris Brezillon
> <[email protected]> napisał(a):
> >
> > On Tue, 13 Nov 2018 15:01:08 +0100
> > Bartosz Golaszewski <[email protected]> wrote:
> >
> > > As far as merging of this series goes: I'd like to avoid dragging it over
> > > four releases. The series is logically split into five groups:
> > >
> > > patches 1-2: nvmem and mtd changes
> > > patches 3-9: davinci arch-specific changes
> > > patches 10-13: networking changes
> > > patches 14-24: davinci specific again
> > > patch 25: final at24 change
> > >
> > > With that I believe we can do the following: Greg KH could pick up the
> > > first two patches into his char-misc tree.
> >
> > The char-misc tree? Why not the MTD or NVMEM tree?
> >
>
> There is no NVMEM tree - Srinivas sends his patches to Greg to be
> applied to char-misc.
Okay, I didn't know that.
>
> The second patch depends on the first one so in order to avoid more
> merging problems I suggested that the MTD patch go through char-misc
> as well. If you see a better solution, please let me know.
No that's fine, as long as I have an immutable tag/branch I can pull if
needed.
>
> Hi Srinivas,
>
> if there are no objections - can you Ack this patch for Greg to pick
> up into char-misc?
Patch is fine for me. I normally send all the nvmem patches just before rc5.
--srini
>
> Bart
>
czw., 29 lis 2018 o 15:32 Srinivas Kandagatla
<[email protected]> napisał(a):
>
>
> >
> > Hi Srinivas,
> >
> > if there are no objections - can you Ack this patch for Greg to pick
> > up into char-misc?
>
> Patch is fine for me. I normally send all the nvmem patches just before rc5.
>
> --srini
> >
> > Bart
> >
Boris, are you fine with Srinivas sending the MTD patch as well so
that they stay together?
Bart
wt., 13 lis 2018 o 15:01 Bartosz Golaszewski <[email protected]> napisał(a):
>
> From: Bartosz Golaszewski <[email protected]>
>
> We want to add nvmem support for MTD. TI DaVinci is the first platform
> that will be using it, but only in non-DT mode. In order not to
> introduce any new interface to supporting of which we would have to
> commit - add a new config option that tells nvmem not to use the DT
> node of the parent device.
>
> This way we won't be creating nvmem devices corresponding with MTD
> partitions defined in device tree. By default MTD will set this new
> field to true.
>
> Once a set of bindings for MTD nvmem cells is agreed upon, we'll be
> able to remove this option.
>
> Signed-off-by: Bartosz Golaszewski <[email protected]>
> ---
> drivers/nvmem/core.c | 3 ++-
> include/linux/nvmem-provider.h | 2 ++
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index 9b18ce90f907..ac7971e8154e 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -604,7 +604,8 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
> nvmem->priv = config->priv;
> nvmem->reg_read = config->reg_read;
> nvmem->reg_write = config->reg_write;
> - nvmem->dev.of_node = config->dev->of_node;
> + if (!config->no_of_node)
> + nvmem->dev.of_node = config->dev->of_node;
>
> if (config->id == -1 && config->name) {
> dev_set_name(&nvmem->dev, "%s", config->name);
> diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
> index 1e3283c2af77..e53545e9852b 100644
> --- a/include/linux/nvmem-provider.h
> +++ b/include/linux/nvmem-provider.h
> @@ -30,6 +30,7 @@ typedef int (*nvmem_reg_write_t)(void *priv, unsigned int offset,
> * @ncells: Number of elements in cells.
> * @read_only: Device is read-only.
> * @root_only: Device is accessibly to root only.
> + * @no_of_node: Device should not use the parent's of_node even if it's !NULL.
> * @reg_read: Callback to read data.
> * @reg_write: Callback to write data.
> * @size: Device size.
> @@ -53,6 +54,7 @@ struct nvmem_config {
> int ncells;
> bool read_only;
> bool root_only;
> + bool no_of_node;
> nvmem_reg_read_t reg_read;
> nvmem_reg_write_t reg_write;
> int size;
> --
> 2.19.1
>
Hi Srinivas,
if there are no objections - can you Ack this patch for Greg to pick
up into char-misc?
Bart
On Thu, 29 Nov 2018 15:35:58 +0100
Bartosz Golaszewski <[email protected]> wrote:
> czw., 29 lis 2018 o 15:32 Srinivas Kandagatla
> <[email protected]> napisał(a):
> >
> >
> > >
> > > Hi Srinivas,
> > >
> > > if there are no objections - can you Ack this patch for Greg to pick
> > > up into char-misc?
> >
> > Patch is fine for me. I normally send all the nvmem patches just before rc5.
> >
> > --srini
> > >
> > > Bart
> > >
>
> Boris, are you fine with Srinivas sending the MTD patch as well so
> that they stay together?
Yes, I'll just need an immutable branch/tag in case we have conflicting
changes in the MTD tree.
wt., 13 lis 2018 o 15:02 Bartosz Golaszewski <[email protected]> napisał(a):
>
> From: Bartosz Golaszewski <[email protected]>
>
> We already have of_get_nvmem_mac_address() but some non-DT systems want
> to read the MAC address from NVMEM too. Implement a generalized routine
> that takes struct device as argument.
>
> Signed-off-by: Bartosz Golaszewski <[email protected]>
> ---
> include/linux/etherdevice.h | 1 +
> net/ethernet/eth.c | 38 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 39 insertions(+)
>
> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> index 572e11bb8696..2c0af7b00715 100644
> --- a/include/linux/etherdevice.h
> +++ b/include/linux/etherdevice.h
> @@ -32,6 +32,7 @@
> struct device;
> int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr);
> unsigned char *arch_get_platform_mac_address(void);
> +int nvmem_get_mac_address(struct device *dev, void *addrbuf);
> u32 eth_get_headlen(void *data, unsigned int max_len);
> __be16 eth_type_trans(struct sk_buff *skb, struct net_device *dev);
> extern const struct header_ops eth_header_ops;
> diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
> index fd8faa0dfa61..df38593d1bb4 100644
> --- a/net/ethernet/eth.c
> +++ b/net/ethernet/eth.c
> @@ -47,6 +47,7 @@
> #include <linux/inet.h>
> #include <linux/ip.h>
> #include <linux/netdevice.h>
> +#include <linux/nvmem-consumer.h>
> #include <linux/etherdevice.h>
> #include <linux/skbuff.h>
> #include <linux/errno.h>
> @@ -548,3 +549,40 @@ int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr)
> return 0;
> }
> EXPORT_SYMBOL(eth_platform_get_mac_address);
> +
> +/**
> + * Obtain the MAC address from an nvmem cell named 'mac-address' associated
> + * with given device.
> + *
> + * @dev: Device with which the mac-address cell is associated.
> + * @addrbuf: Buffer to which the MAC address will be copied on success.
> + *
> + * Returns 0 on success or a negative error number on failure.
> + */
> +int nvmem_get_mac_address(struct device *dev, void *addrbuf)
> +{
> + struct nvmem_cell *cell;
> + const void *mac;
> + size_t len;
> +
> + cell = nvmem_cell_get(dev, "mac-address");
> + if (IS_ERR(cell))
> + return PTR_ERR(cell);
> +
> + mac = nvmem_cell_read(cell, &len);
> + nvmem_cell_put(cell);
> +
> + if (IS_ERR(mac))
> + return PTR_ERR(mac);
> +
> + if (len != ETH_ALEN || !is_valid_ether_addr(mac)) {
> + kfree(mac);
> + return -EINVAL;
> + }
> +
> + ether_addr_copy(addrbuf, mac);
> + kfree(mac);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(nvmem_get_mac_address);
> --
> 2.19.1
>
If there are no objections - can patches 10-13 go into the networking
tree already so that they spend some time in next before the merge
window?
Best regards,
Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
Date: Thu, 29 Nov 2018 17:45:51 +0100
> If there are no objections - can patches 10-13 go into the networking
> tree already so that they spend some time in next before the merge
> window?
Please submit them as a separate series, clearly targetted at the
net-next tree.