Skip to contentSkip to conversation

at24: remove

PATCH Applied Bartosz Golaszewski 8 participants 41 messages Nov 13, 2018 – Dec 6, 2018

Subsystems (13)
Networking Network drivers Arm (32-bit) Arm sub-architectures +9 more subsystems
lore
Share & tools
lore

Bartosz Golaszewski

author
#0 lore raw

v2 cover at24: remove

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
Signature · 1 line
2.19.1
author
#1 lore raw

PATCH v2 1/25 nvmem: add new config option

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(-)
drivers/nvmem/core.c +2 -1
index 9b18ce90f907..ac7971e8154e 100644
@@ -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);
include/linux/nvmem-provider.h +2 -0
index 1e3283c2af77..e53545e9852b 100644
@@ -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;
Signature · 1 line
2.19.1
author
#2 lore raw

Re: [PATCH v2 01/25] nvmem: add new config option

wt., 13 lis 2018 o 15:01 Bartosz Golaszewski <[email protected]> napisał(a):

Quoted 57 lines

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(-)
drivers/nvmem/core.c +2 -1
index 9b18ce90f907..ac7971e8154e 100644
@@ -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);
include/linux/nvmem-provider.h +2 -1
index 1e3283c2af77..e53545e9852b 100644
@@ -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;
--
Quoted 2 lines

2.19.1

Hi Srinivas,

if there are no objections - can you Ack this patch for Greg to pick up into char-misc?

Bart

#3 lore raw

Re: [PATCH v2 01/25] nvmem: add new config option

Quoted 6 lines

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

Quoted 3 lines

Bart

author
#4 lore raw

Re: [PATCH v2 01/25] nvmem: add new config option

czw., 29 lis 2018 o 15:32 Srinivas Kandagatla
<[email protected]> napisał(a):

Quoted 14 lines
Quoted 7 lines

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

Quoted 3 lines

Bart

Boris, are you fine with Srinivas sending the MTD patch as well so that they stay together?

Bart

#5 lore raw

Re: [PATCH v2 01/25] nvmem: add new config option

Quoted 12 lines · 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):

Quoted 10 lines
Quoted 7 lines

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.

Quoted 7 lines
Quoted 4 lines

--srini

Quoted 3 lines

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.

author
#6 lore raw

PATCH v2 2/25 mtd: add support for reading MTD devices via the nvmem API

In reply to Bartosz Golaszewski

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(+)
drivers/mtd/Kconfig +1 -0
index c77f537323ec..efbe7a6f1d8f 100644
@@ -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
drivers/mtd/mtdcore.c +56 -0

86 lines not on this page · raw message

include/linux/mtd/mtd.h +2 -0
index cd0be91bdefa..545070c2ee64 100644
@@ -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,
Signature · 1 line
2.19.1
Acked-by on v2 2/25
#7 lore raw

Re: [PATCH v2 02/25] mtd: add support for reading MTD devices via the nvmem API

Quoted 7 lines · 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.

Quoted 8 lines
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.

Quoted 132 lines
---
 drivers/mtd/Kconfig     |  1 +
 drivers/mtd/mtdcore.c   | 56 +++++++++++++++++++++++++++++++++++++++++
 include/linux/mtd/mtd.h |  2 ++
 3 files changed, 59 insertions(+)
drivers/mtd/Kconfig +1 -0
index c77f537323ec..efbe7a6f1d8f 100644
@@ -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
drivers/mtd/mtdcore.c +56 -0
index 97ac219c082e..5f1053d995b0 100644
@@ -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);
include/linux/mtd/mtd.h +2 -0
index cd0be91bdefa..545070c2ee64 100644
@@ -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,
author
#8 lore raw

PATCH v2 3/25 ARM: davinci: dm365-evm: use cell nvmem lookup for mac address

In reply to Bartosz Golaszewski

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(+)
arch/arm/mach-davinci/board-dm365-evm.c +25 -0
index 8143756ff38b..8703fc18dd3b 100644
@@ -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);
Signature · 1 line
2.19.1
author
#9 lore raw

PATCH v2 4/25 ARM: davinci: dm644x-evm: use cell nvmem lookup for mac address

In reply to Bartosz Golaszewski

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(+)
arch/arm/mach-davinci/board-dm644x-evm.c +24 -0
index e4a8f9225d16..e1428115067f 100644
@@ -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
Signature · 1 line
2.19.1
author
#10 lore raw

PATCH v2 5/25 ARM: davinci: dm646x-evm: use cell nvmem lookup for mac address

In reply to Bartosz Golaszewski

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(+)
arch/arm/mach-davinci/board-dm646x-evm.c +24 -0
index 3e5ee09ee717..8d5be6dd2019 100644
@@ -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
Signature · 1 line
2.19.1
author
#11 lore raw

PATCH v2 6/25 ARM: davinci: da830-evm: use cell nvmem lookup for mac address

In reply to Bartosz Golaszewski

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(+)
arch/arm/mach-davinci/board-da830-evm.c +26 -0
index 7d8ab36ff83d..e52ec1619b70 100644
@@ -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));
Signature · 1 line
2.19.1
author
#12 lore raw

PATCH v2 7/25 ARM: davinci: mityomapl138: use cell nvmem lookup for mac address

In reply to Bartosz Golaszewski

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(+)
arch/arm/mach-davinci/board-mityomapl138.c +29 -0
index 2933e0c87cfa..8df16e81b69e 100644
@@ -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);
Signature · 1 line
2.19.1
author
#13 lore raw

PATCH v2 8/25 ARM: davinci: dm850-evm: use cell nvmem lookup for mac address

In reply to Bartosz Golaszewski

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(+)
arch/arm/mach-davinci/board-da850-evm.c +29 -0
index e1a949b47306..bac2162e2153 100644
@@ -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));
Signature · 1 line
2.19.1
author
#14 lore raw

PATCH v2 9/25 ARM: davinci: da850-evm: remove unnecessary include

In reply to Bartosz Golaszewski

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(-)
arch/arm/mach-davinci/board-da850-evm.c +0 -1
index bac2162e2153..6a29baf0a289 100644
@@ -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>
Signature · 1 line
2.19.1
author
#15 lore raw

PATCH v2 10/25 net: ethernet: provide nvmem_get_mac_address()

In reply to Bartosz Golaszewski

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(+)
include/linux/etherdevice.h +1 -0
index 572e11bb8696..2c0af7b00715 100644
@@ -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;
net/ethernet/eth.c +38 -0
index fd8faa0dfa61..df38593d1bb4 100644
@@ -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);
Signature · 1 line
2.19.1
author
#16 lore raw

Re: [PATCH v2 10/25] net: ethernet: provide nvmem_get_mac_address()

wt., 13 lis 2018 o 15:02 Bartosz Golaszewski <[email protected]> napisał(a):

Quoted 79 lines

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(+)
include/linux/etherdevice.h +1 -0
index 572e11bb8696..2c0af7b00715 100644
@@ -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;
net/ethernet/eth.c +38 -1
index fd8faa0dfa61..df38593d1bb4 100644
@@ -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);
--
Quoted 2 lines

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

maintainer
#17 lore raw

Re: [PATCH v2 10/25] net: ethernet: provide nvmem_get_mac_address()

From: Bartosz Golaszewski <[email protected]>
Date: Thu, 29 Nov 2018 17:45:51 +0100

Quoted 3 lines

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.

author
#18 lore raw

PATCH v2 11/25 net: cadence: switch to using nvmem_get_mac_address()

In reply to Bartosz Golaszewski

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(-)
drivers/net/ethernet/cadence/macb_main.c +1 -1
index 1d86b4d5645a..d9a208f7bb40 100644
@@ -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;
Signature · 1 line
2.19.1
Acked-by on v2 11/25
#19 lore raw

Re: [PATCH v2 11/25] net: cadence: switch to using nvmem_get_mac_address()

Quoted 7 lines · Bartosz Golaszewski

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]>
Quoted 18 lines
---
  drivers/net/ethernet/cadence/macb_main.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/cadence/macb_main.c +1 -1
index 1d86b4d5645a..d9a208f7bb40 100644
@@ -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;
Signature · 1 line
Nicolas Ferre
author
#20 lore raw

PATCH v2 12/25 of: net: kill of_get_nvmem_mac_address()

In reply to Bartosz Golaszewski

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(-)
drivers/of/of_net.c +0 -39
index 53189d4022a6..810ab0fbcccb 100644
@@ -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);
include/linux/of_net.h +0 -6
index 90d81ee9e6a0..9cd72aab76fe 100644
@@ -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;
Signature · 1 line
2.19.1
maintainer Reviewed-by on v2 12/25
#21 lore raw

Re: [PATCH v2 12/25] of: net: kill of_get_nvmem_mac_address()

Quoted 11 lines · Bartosz Golaszewski

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]>
author
#22 lore raw

PATCH v2 13/25 net: davinci_emac: use nvmem_get_mac_address()

In reply to Bartosz Golaszewski

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(-)
drivers/net/ethernet/ti/davinci_emac.c +9 -5
index 9153db120352..840820402cd0 100644
@@ -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;
Signature · 1 line
2.19.1
author
#23 lore raw

PATCH v2 14/25 ARM: davinci: da850-evm: remove dead MTD code

In reply to Bartosz Golaszewski

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(-)
arch/arm/mach-davinci/board-da850-evm.c +0 -28
index 6a29baf0a289..128dd7d8dff6 100644
@@ -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",
Signature · 1 line
2.19.1
author
#24 lore raw

PATCH v2 15/25 ARM: davinci: mityomapl138: don't read the MAC address from machine code

In reply to Bartosz Golaszewski

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(-)
arch/arm/mach-davinci/board-mityomapl138.c +0 -8
index 8df16e81b69e..3286dc2457a5 100644
@@ -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);
Signature · 1 line
2.19.1
author
#25 lore raw

PATCH v2 16/25 ARM: davinci: dm365-evm: use device properties for at24 eeprom

In reply to Bartosz Golaszewski

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(-)
arch/arm/mach-davinci/board-dm365-evm.c +5 -8
index 8703fc18dd3b..f016584285b0 100644
@@ -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),
Signature · 1 line
2.19.1
author
#26 lore raw

PATCH v2 17/25 ARM: davinci: da830-evm: use device properties for at24 eeprom

In reply to Bartosz Golaszewski

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(-)
arch/arm/mach-davinci/board-da830-evm.c +5 -8
index e52ec1619b70..ddd871d8b44c 100644
@@ -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),
Signature · 1 line
2.19.1
author
#27 lore raw

PATCH v2 18/25 ARM: davinci: dm644x-evm: use device properties for at24 eeprom

In reply to Bartosz Golaszewski

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(-)
arch/arm/mach-davinci/board-dm644x-evm.c +5 -8
index e1428115067f..efe4e170e87d 100644
@@ -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),
Signature · 1 line
2.19.1
author
#28 lore raw

PATCH v2 19/25 ARM: davinci: dm646x-evm: use device properties for at24 eeprom

In reply to Bartosz Golaszewski

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(-)
arch/arm/mach-davinci/board-dm646x-evm.c +5 -8
index 8d5be6dd2019..02b57face113 100644
@@ -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),
Signature · 1 line
2.19.1
author
#29 lore raw

PATCH v2 20/25 ARM: davinci: sffsdr: fix the at24 eeprom device name

In reply to Bartosz Golaszewski

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(-)
arch/arm/mach-davinci/board-sffsdr.c +1 -1
index 792bb84d5011..acd9778ffa07 100644
@@ -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:
Signature · 1 line
2.19.1
author
#30 lore raw

PATCH v2 21/25 ARM: davinci: sffsdr: use device properties for at24 eeprom

In reply to Bartosz Golaszewski

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(-)
arch/arm/mach-davinci/board-sffsdr.c +5 -6
index acd9778ffa07..ff14de1396c8 100644
@@ -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)
Signature · 1 line
2.19.1
author
#31 lore raw

PATCH v2 22/25 ARM: davinci: remove dead code related to MAC address reading

In reply to Bartosz Golaszewski

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(-)
arch/arm/mach-davinci/common.c +0 -15
index e1d0f0d841ff..0c638fe15dcb 100644
@@ -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;
include/linux/davinci_emac.h +0 -1
index 05b97144d342..28e6cf1356da 100644
@@ -46,5 +46,4 @@ enum {
 	EMAC_VERSION_2,	/* DM646x */
 };
 
-void davinci_get_mac_addr(struct nvmem_device *nvmem, void *context);
 #endif
Signature · 1 line
2.19.1
author
#32 lore raw

PATCH v2 23/25 ARM: davinci: mityomapl138: use nvmem notifiers

In reply to Bartosz Golaszewski

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(-)
arch/arm/mach-davinci/board-mityomapl138.c +15 -3
index 3286dc2457a5..ac1a1699d185 100644
@@ -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);
Signature · 1 line
2.19.1
author
#33 lore raw

PATCH v2 24/25 ARM: davinci: mityomapl138: use device properties for at24 eeprom

In reply to Bartosz Golaszewski

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(-)
arch/arm/mach-davinci/board-mityomapl138.c +6 -6
index ac1a1699d185..a381b26328d8 100644
@@ -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,
 	},
 };
Signature · 1 line
2.19.1
author
#34 lore raw

PATCH v2 25/25 eeprom: at24: remove at24_platform_data

In reply to Bartosz Golaszewski

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
MAINTAINERS +0 -1
index 0abecc528dac..b3ee25e95bd0 100644
@@ -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]>
drivers/misc/eeprom/at24.c +75 -87

254 lines not on this page · raw message

include/linux/platform_data/at24.h deleted +0 -60

60 lines not on this page · raw message

Signature · 1 line
2.19.1
author
#35 lore raw
In reply to Bartosz Golaszewski

wt., 13 lis 2018 o 15:01 Bartosz Golaszewski <[email protected]> napisa?(a):

Quoted 111 lines

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
Quoted 3 lines

--
2.19.1

Ugh the subject was supposed to be: at24: remove platform data...

#36 lore raw
In reply to Bartosz Golaszewski

Bartosz,

Thanks for keeping at this!

Quoted 4 lines

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20181113/af827045/attachment.sig>

#37 lore raw
In reply to Bartosz Golaszewski
Quoted 11 lines · 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?

Quoted 7 lines

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).

author
#38 lore raw

niedz., 18 lis 2018 o 17:03 Boris Brezillon
<[email protected]> napisa?(a):

Quoted 13 lines
Quoted 9 lines · 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

Quoted 5 lines
Quoted 2 lines

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

#39 lore raw
Quoted 15 lines · 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):

Quoted 13 lines
Quoted 9 lines · 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

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

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.

Quoted 4 lines

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.

Applied
#40 lore raw
In reply to Bartosz Golaszewski
Quoted 30 lines · Bartosz Golaszewski

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.

Quoted 8 lines

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

Applied patches 3-9 to davinci tree for v4.21

Quoted 13 lines

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).

Quoted 2 lines

[1] https://lkml.org/lkml/2018/9/21/293
[2] https://lkml.org/lkml/2018/8/8/528

Thanks,
Sekhar

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/