From: Bartosz Golaszewski <redacted>
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.
Most boards use the EEPROM to store the MAC address. This series adds
support for cell lookups to the nvmem framework, registers relevant
cells for all users, converts the davinci_emac driver to using them
and replaces at24_platform_data with device properties.
The only board that's still using this callback is now mityomapl138.
Unfortunately it stores more info in EEPROM than just the MAC address
and will require some more work. Unfortunately I don't have access
to this board so I can't test any actual solutions on a live hardware.
Tested on a dm365-evm board.
v1 -> v2:
- for backward compatiblity: fall back to using of_get_mac_address() if
we can't get an nvmem cell in patch 7
- add patch 15 which removes dead code
Bartosz Golaszewski (15):
nvmem: add support for cell lookups
ARM: davinci: dm365-evm: use nvmem lookup for mac address
ARM: davinci: dm644-evm: use nvmem lookup for mac address
ARM: davinci: dm646x-evm: use nvmem lookup for mac address
ARM: davinci: da830-evm: use nvmem lookup for mac address
ARM: davinci: mityomapl138: add nvmem cells lookup entries
net: davinci_emac: use nvmem to retrieve the mac address
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
arch/arm/mach-davinci/board-da830-evm.c | 25 +++++++---
arch/arm/mach-davinci/board-dm365-evm.c | 25 +++++++---
arch/arm/mach-davinci/board-dm644x-evm.c | 24 ++++++---
arch/arm/mach-davinci/board-dm646x-evm.c | 25 +++++++---
arch/arm/mach-davinci/board-mityomapl138.c | 30 +++++++++---
arch/arm/mach-davinci/board-sffsdr.c | 13 +++--
arch/arm/mach-davinci/common.c | 15 ------
drivers/net/ethernet/ti/davinci_emac.c | 33 +++++++++----
drivers/nvmem/core.c | 57 +++++++++++++++++++++-
include/linux/davinci_emac.h | 2 -
include/linux/nvmem-consumer.h | 6 +++
include/linux/nvmem-provider.h | 6 +++
12 files changed, 186 insertions(+), 75 deletions(-)
--
2.17.1
From: Bartosz Golaszewski <redacted>
All users which store the MAC address in EEPROM now register relevant
nvmem cells. Switch to retrieving the MAC address over the nvmem
framework. If we can't get the nvmem cell then fall back to using
the device tree.
Signed-off-by: Bartosz Golaszewski <redacted>
---
drivers/net/ethernet/ti/davinci_emac.c | 33 ++++++++++++++++++--------
1 file changed, 23 insertions(+), 10 deletions(-)
@@ -1783,7 +1776,9 @@ static int davinci_emac_probe(struct platform_device *pdev)structcpdma_paramsdma_params;structclk*emac_clk;unsignedlongemac_bus_frequency;-+structnvmem_cell*cell;+constvoid*mac_addr;+size_tmac_addr_len;/* obtain emac clock from kernel */emac_clk=devm_clk_get(&pdev->dev,NULL);
@@ -1815,8 +1810,26 @@ static int davinci_emac_probe(struct platform_device *pdev)gotoerr_free_netdev;}+cell=nvmem_cell_get(&pdev->dev,"mac-address");+if(!IS_ERR(cell)){+mac_addr=nvmem_cell_read(cell,&mac_addr_len);+if(!IS_ERR(mac_addr)){+if(is_valid_ether_addr(mac_addr)){+dev_info(&pdev->dev,+"Read MAC addr from EEPROM: %pM\n",+mac_addr);+ether_addr_copy(priv->mac_addr,mac_addr);+}+kfree(mac_addr);+}+nvmem_cell_put(cell);+}else{+mac_addr=of_get_mac_address(np);+if(mac_addr)+ether_addr_copy(priv->mac_addr,mac_addr);+}+/* MAC addr and PHY mask , RMII enable info from platform_data */-memcpy(priv->mac_addr,pdata->mac_addr,ETH_ALEN);priv->phy_id=pdata->phy_id;priv->rmii_en=pdata->rmii_en;priv->version=pdata->version;
From: Bartosz Golaszewski <redacted>
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 <redacted>
---
arch/arm/mach-davinci/board-dm646x-evm.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
From: Bartosz Golaszewski <redacted>
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 <redacted>
---
arch/arm/mach-davinci/board-sffsdr.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
From: Bartosz Golaszewski <redacted>
There are no more users of davinci_get_mac_addr(). Remove it. Also
remove the mac_addr field from the emac platform data struct.
Signed-off-by: Bartosz Golaszewski <redacted>
---
arch/arm/mach-davinci/common.c | 15 ---------------
include/linux/davinci_emac.h | 2 --
2 files changed, 17 deletions(-)
@@ -28,21 +28,6 @@ EXPORT_SYMBOL(davinci_soc_info);void__iomem*davinci_intc_base;intdavinci_intc_type;-voiddavinci_get_mac_addr(structnvmem_device*nvmem,void*context)-{-char*mac_addr=davinci_soc_info.emac_pdata->mac_addr;-off_toffset=(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);-}-staticint__initdavinci_init_id(structdavinci_soc_info*soc_info){inti;
From: Bartosz Golaszewski <redacted>
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 <redacted>
---
arch/arm/mach-davinci/board-sffsdr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Bartosz Golaszewski <redacted>
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 <redacted>
---
arch/arm/mach-davinci/board-dm644x-evm.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
From: Bartosz Golaszewski <redacted>
This is now done by the emac driver using a registered nvmem cell.
Signed-off-by: Bartosz Golaszewski <redacted>
---
arch/arm/mach-davinci/board-mityomapl138.c | 8 --------
1 file changed, 8 deletions(-)
@@ -120,7 +120,6 @@ static void read_factory_config(struct nvmem_device *nvmem, void *context){intret;constchar*partnum=NULL;-structdavinci_soc_info*soc_info=&davinci_soc_info;if(!IS_BUILTIN(CONFIG_NVMEM)){pr_warn("Factory Config not available without CONFIG_NVMEM\n");
@@ -146,13 +145,6 @@ static void read_factory_config(struct nvmem_device *nvmem, void *context)gotobad_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);
From: Bartosz Golaszewski <redacted>
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 <redacted>
---
arch/arm/mach-davinci/board-dm365-evm.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
From: Bartosz Golaszewski <redacted>
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 <redacted>
---
arch/arm/mach-davinci/board-da830-evm.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
From: Bartosz Golaszewski <redacted>
We can currently only register nvmem cells from device tree or by
manually calling nvmem_add_cells(). The latter options however forces
users to make sure that the nvmem provider with which the cells are
associated is registered before the call.
This patch proposes a new solution inspired by other frameworks that
offer resource lookups (GPIO, PWM etc.). It adds a function that allows
machine code to register nvmem lookup which are later lazily used to
add corresponding nvmem cells.
Signed-off-by: Bartosz Golaszewski <redacted>
---
drivers/nvmem/core.c | 57 +++++++++++++++++++++++++++++++++-
include/linux/nvmem-consumer.h | 6 ++++
include/linux/nvmem-provider.h | 6 ++++
3 files changed, 68 insertions(+), 1 deletion(-)
Thanks for the patch,
On 26/06/18 11:22, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski <redacted>
We can currently only register nvmem cells from device tree or by
manually calling nvmem_add_cells(). The latter options however forces
users to make sure that the nvmem provider with which the cells are
associated is registered before the call.
This patch proposes a new solution inspired by other frameworks that
offer resource lookups (GPIO, PWM etc.). It adds a function that allows
machine code to register nvmem lookup which are later lazily used to
add corresponding nvmem cells.
Overall the idea look fine to me.
This needs to be documented in ./Documentation/nvmem/nvmem.txt
Can we rename this to nvmem_add_lookup_table()?
register sound bit heavy here.
We should also have something like nvmem_remove_lookup_table() for
consistency, and it should ensure that it clears the cells entry too.
quoted hunk
+ * @lookup: array of nvmem cell lookup entries
+ * @nentries: number of lookup entries in the array
+ */
+void nvmem_register_lookup(struct nvmem_cell_lookup *lookup, size_t nentries)
+{
+ int i;
+ > + mutex_lock(&nvmem_lookup_mutex);
+ for (i = 0; i < nentries; i++)
+ list_add_tail(&lookup[i].list, &nvmem_cell_lookups);
+ mutex_unlock(&nvmem_lookup_mutex);
+}
+EXPORT_SYMBOL_GPL(nvmem_register_lookup);
+
static void nvmem_release(struct device *dev)
{
struct nvmem_device *nvmem = to_nvmem_device(dev);
Thanks for the patch,
On 26/06/18 11:22, Bartosz Golaszewski wrote:
quoted
From: Bartosz Golaszewski <redacted>
We can currently only register nvmem cells from device tree or by
manually calling nvmem_add_cells(). The latter options however forces
users to make sure that the nvmem provider with which the cells are
associated is registered before the call.
This patch proposes a new solution inspired by other frameworks that
offer resource lookups (GPIO, PWM etc.). It adds a function that allows
machine code to register nvmem lookup which are later lazily used to
add corresponding nvmem cells.
Overall the idea look fine to me.
This needs to be documented in ./Documentation/nvmem/nvmem.txt
*nvmem_ro_root_dev_groups[] = {
NULL,
};
+/**
+ * nvmem_register_lookup() - register a number of nvmem cell lookup
entries
+ *
Can we rename this to nvmem_add_lookup_table()?
register sound bit heavy here.
We should also have something like nvmem_remove_lookup_table() for
consistency, and it should ensure that it clears the cells entry too.
What do you mean by clearing the cells entry exactly?
Bart
quoted
+ * @lookup: array of nvmem cell lookup entries
+ * @nentries: number of lookup entries in the array
+ */
+void nvmem_register_lookup(struct nvmem_cell_lookup *lookup, size_t
nentries)
+{
+ int i;
+ > + mutex_lock(&nvmem_lookup_mutex);
+ for (i = 0; i < nentries; i++)
+ list_add_tail(&lookup[i].list, &nvmem_cell_lookups);
+ mutex_unlock(&nvmem_lookup_mutex);
+}
+EXPORT_SYMBOL_GPL(nvmem_register_lookup);
+
static void nvmem_release(struct device *dev)
{
struct nvmem_device *nvmem = to_nvmem_device(dev);
We should also have something like nvmem_remove_lookup_table() for
consistency, and it should ensure that it clears the cells entry too.
What do you mean by clearing the cells entry exactly?
I meant, Removing entry from the nvmem_cells list.
Initially I though we should remove the entry form nvmem_cells list,
but It would complicate this path if some consumer has reference to it.
So, just removing the lookup list should be good! Lets not worry about
removing from nvmem_cells list.
--srini