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
v2 -> v3:
- documented new nvmem cell lookup API
- renamed the nvmem cell lookup routines
- added a function for removing the lookup tables
- in order to completly remove the mac_addr from davinci's soc_info
added a patch that moves reading the MAC address from SPI to the emac
driver
- removed more dead code
v3 -> v4:
- only return -EPROBE_DEFER from nvmem_cell_from_lookup() if we have
a matching lookup entry but no corresponding nvmem device yet, return
-ENOENT if we can't match the lookup
- check for -EPROBE_DEFER in the emac driver
- put the mtd device after reading the MAC address
Bartosz Golaszewski (18):
nvmem: add support for cell lookups
Documentation: nvmem: document lookup entries
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: potentially get the MAC address from MTD
ARM: davinci: da850-evm: remove dead MTD code
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 related to MAC address reading
Documentation/nvmem/nvmem.txt | 28 ++++++++
arch/arm/mach-davinci/board-da830-evm.c | 25 ++++---
arch/arm/mach-davinci/board-da850-evm.c | 28 --------
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 | 53 ++++++++++++---
drivers/nvmem/core.c | 77 +++++++++++++++++++++-
include/linux/davinci_emac.h | 2 -
include/linux/nvmem-consumer.h | 6 ++
include/linux/nvmem-provider.h | 10 +++
14 files changed, 258 insertions(+), 103 deletions(-)
--
2.17.1
@@ -58,6 +58,34 @@ static int qfprom_probe(struct platform_device *pdev) It is mandatory that the NVMEM provider has a regmap associated with its struct device. Failure to do would return error code from nvmem_register().+Additionally it is possible to create nvmem cell lookup entries and register+them with the nvmem framework from machine code as shown in the example below:++static struct nvmem_cell_lookup foobar_lookup = {+ .info = {+ .name = "mac-address",+ .offset = 0xd000,+ .bytes = ERH_ALEN,+ },+ .nvmem_name = "foobar",+};++static void foobar_register(void)+{+ ...+ nvmem_add_lookup_table(&foobar_lookup, 1);+ ...+}++A lookup entry table can be later removed if needed:++static void foobar_fini(void)+{+ ...+ nvmem_del_lookup_table(&foobar_lookup, 1);+ ...+}+ NVMEM Consumers +++++++++++++++
@@ -58,6 +58,34 @@ static int qfprom_probe(struct platform_device *pdev) It is mandatory that the NVMEM provider has a regmap associated with its struct device. Failure to do would return error code from nvmem_register().+Additionally it is possible to create nvmem cell lookup entries and register+them with the nvmem framework from machine code as shown in the example below:++static struct nvmem_cell_lookup foobar_lookup = {+ .info = {+ .name = "mac-address",+ .offset = 0xd000,+ .bytes = ERH_ALEN,
ETH_ALEN. Will fix while applying.
Regards,
Sekhar
@@ -58,6 +58,34 @@ static int qfprom_probe(struct platform_device *pdev) It is mandatory that the NVMEM provider has a regmap associated with its struct device. Failure to do would return error code from nvmem_register().+Additionally it is possible to create nvmem cell lookup entries and register+them with the nvmem framework from machine code as shown in the example below:++static struct nvmem_cell_lookup foobar_lookup = {+ .info = {+ .name = "mac-address",+ .offset = 0xd000,+ .bytes = ERH_ALEN,+ },+ .nvmem_name = "foobar",+};++static void foobar_register(void)+{+ ...+ nvmem_add_lookup_table(&foobar_lookup, 1);+ ...+}++A lookup entry table can be later removed if needed:++static void foobar_fini(void)+{+ ...+ nvmem_del_lookup_table(&foobar_lookup, 1);+ ...+}+ NVMEM Consumers +++++++++++++++
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 | 35 +++++++++++++++++++-------
1 file changed, 26 insertions(+), 9 deletions(-)
@@ -1783,10 +1778,12 @@ static int davinci_emac_probe(struct platform_device *pdev)structcpdma_paramsdma_params;structclk*emac_clk;unsignedlongemac_bus_frequency;-#ifdef CONFIG_MTD+constvoid*mac_addr;size_tmac_addr_len;+#ifdef CONFIG_MTDstructmtd_info*mtd;#endif /* CONFIG_MTD */+structnvmem_cell*cell;/* obtain emac clock from kernel */emac_clk=devm_clk_get(&pdev->dev,NULL);
@@ -1831,8 +1828,28 @@ static int davinci_emac_probe(struct platform_device *pdev)}#endif /* CONFIG_MTD */+cell=nvmem_cell_get(&pdev->dev,"mac-address");+if(IS_ERR(cell)&&PTR_ERR(cell)==-EPROBE_DEFER){+return-EPROBE_DEFER;+}elseif(!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>
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>
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>
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 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>
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-dm644x-evm.c | 12 ++++--------
1 file changed, 4 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-dm646x-evm.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
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 no longer need to register the MTD notifier to read the MAC address
as it's now being done in the emac address.
Signed-off-by: Bartosz Golaszewski <redacted>
---
arch/arm/mach-davinci/board-da850-evm.c | 28 -------------------------
1 file changed, 28 deletions(-)
From: David Lechner <david@lechnology.com> Date: 2018-06-29 17:09:33
On 06/29/2018 04:40 AM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski <redacted>
We no longer need to register the MTD notifier to read the MAC address
as it's now being done in the emac address.
I think you mean "it's now being done in the emac _driver_"
2018-06-29 19:09 GMT+02:00 David Lechner [off-list ref]:
On 06/29/2018 04:40 AM, Bartosz Golaszewski wrote:
quoted
From: Bartosz Golaszewski <redacted>
We no longer need to register the MTD notifier to read the MAC address
as it's now being done in the emac address.
I think you mean "it's now being done in the emac _driver_"
From: Bartosz Golaszewski <redacted>
On da850-evm board we can read the MAC address from MTD. It's currently
done in the relevant board file, but we want to get rid of all the MAC
reading callbacks from the board file (SPI and NAND). Move the reading
of the MAC address from SPI to the emac driver's probe function.
Signed-off-by: Bartosz Golaszewski <redacted>
---
drivers/net/ethernet/ti/davinci_emac.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
@@ -1783,7 +1783,10 @@ static int davinci_emac_probe(struct platform_device *pdev)structcpdma_paramsdma_params;structclk*emac_clk;unsignedlongemac_bus_frequency;-+#ifdef CONFIG_MTD+size_tmac_addr_len;+structmtd_info*mtd;+#endif /* CONFIG_MTD *//* obtain emac clock from kernel */emac_clk=devm_clk_get(&pdev->dev,NULL);
@@ -1815,6 +1818,19 @@ static int davinci_emac_probe(struct platform_device *pdev)gotoerr_free_netdev;}+#ifdef CONFIG_MTD+mtd=get_mtd_device_nm("MAC-Address");+if(!IS_ERR(mtd)){+rc=mtd_read(mtd,0,ETH_ALEN,+&mac_addr_len,priv->mac_addr);+if(rc==0)+dev_info(&pdev->dev,+"Read MAC addr from SPI Flash: %pM\n",+priv->mac_addr);+put_mtd_device(mtd);+}+#endif /* CONFIG_MTD */+/* 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;
From: David Lechner <david@lechnology.com> Date: 2018-06-29 20:09:45
On 06/29/2018 04:40 AM, Bartosz Golaszewski wrote:
quoted hunk
From: Bartosz Golaszewski <redacted>
On da850-evm board we can read the MAC address from MTD. It's currently
done in the relevant board file, but we want to get rid of all the MAC
reading callbacks from the board file (SPI and NAND). Move the reading
of the MAC address from SPI to the emac driver's probe function.
Signed-off-by: Bartosz Golaszewski <redacted>
---
drivers/net/ethernet/ti/davinci_emac.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
From: David Lechner <david@lechnology.com> Date: 2018-06-29 20:35:39
On 06/29/2018 03:09 PM, David Lechner wrote:
On 06/29/2018 04:40 AM, Bartosz Golaszewski wrote:
quoted
From: Bartosz Golaszewski <redacted>
On da850-evm board we can read the MAC address from MTD. It's currently
done in the relevant board file, but we want to get rid of all the MAC
reading callbacks from the board file (SPI and NAND). Move the reading
of the MAC address from SPI to the emac driver's probe function.
Signed-off-by: Bartosz Golaszewski <redacted>
---
? drivers/net/ethernet/ti/davinci_emac.c | 20 ++++++++++++++++++--
? 1 file changed, 18 insertions(+), 2 deletions(-)
What about the case when MTD is compiled as a module?
quoted
+??? mtd = get_mtd_device_nm("MAC-Address");
What about the case when PTR_ERR(mtd) == -EPROBE_DEFER?
To answer my own question: because get_mtd_device_nm() doesn't
ever return -EPROBE_DEFER.
I'm trying to make this work on LCDK, but the emac driver probes
before any mtd device is registered, so, I just get -ENODEV even
though I've added a partition to the device tree labeled
"MAC-Address". You can see in the kernel messages that MTD is
not probed until later.
quoted
+??? if (!IS_ERR(mtd)) {
+??????? rc = mtd_read(mtd, 0, ETH_ALEN,
+????????????????? &mac_addr_len, priv->mac_addr);
+??????? if (rc == 0)
+??????????? dev_info(&pdev->dev,
+???????????????? "Read MAC addr from SPI Flash: %pM\n",
+???????????????? priv->mac_addr);
+??????? put_mtd_device(mtd);
+??? }
+#endif /* CONFIG_MTD */
+
????? /* 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;
2018-06-29 22:35 GMT+02:00 David Lechner [off-list ref]:
On 06/29/2018 03:09 PM, David Lechner wrote:
quoted
On 06/29/2018 04:40 AM, Bartosz Golaszewski wrote:
quoted
From: Bartosz Golaszewski <redacted>
On da850-evm board we can read the MAC address from MTD. It's currently
done in the relevant board file, but we want to get rid of all the MAC
reading callbacks from the board file (SPI and NAND). Move the reading
of the MAC address from SPI to the emac driver's probe function.
Signed-off-by: Bartosz Golaszewski <redacted>
---
drivers/net/ethernet/ti/davinci_emac.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
What about the case when MTD is compiled as a module?
quoted
+ mtd = get_mtd_device_nm("MAC-Address");
What about the case when PTR_ERR(mtd) == -EPROBE_DEFER?
To answer my own question: because get_mtd_device_nm() doesn't
ever return -EPROBE_DEFER.
I'm trying to make this work on LCDK, but the emac driver probes
before any mtd device is registered, so, I just get -ENODEV even
though I've added a partition to the device tree labeled
"MAC-Address". You can see in the kernel messages that MTD is
not probed until later.
I tested it on da850-evm - all MTD & SPI related modules need to be
built-in for it to work, so:
CONFIG_MTD=y
CONFIG_MTD_M25P80=y
CONFIG_SPI_DAVINCI=y
Best regards,
Bartosz Golaszewski
quoted
quoted
+ if (!IS_ERR(mtd)) {
+ rc = mtd_read(mtd, 0, ETH_ALEN,
+ &mac_addr_len, priv->mac_addr);
+ if (rc == 0)
+ dev_info(&pdev->dev,
+ "Read MAC addr from SPI Flash: %pM\n",
+ priv->mac_addr);
+ put_mtd_device(mtd);
+ }
+#endif /* CONFIG_MTD */
+
/* 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;
On 06/29/2018 02:40 AM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski <redacted>
On da850-evm board we can read the MAC address from MTD. It's currently
done in the relevant board file, but we want to get rid of all the MAC
reading callbacks from the board file (SPI and NAND). Move the reading
of the MAC address from SPI to the emac driver's probe function.
This should be made something generic to all drivers, not just something
the davinci_emac driver does, something like this actually:
https://lkml.org/lkml/2018/3/24/312
@@ -1783,7 +1783,10 @@ static int davinci_emac_probe(struct platform_device *pdev)structcpdma_paramsdma_params;structclk*emac_clk;unsignedlongemac_bus_frequency;-+#ifdef CONFIG_MTD+size_tmac_addr_len;+structmtd_info*mtd;+#endif /* CONFIG_MTD *//* obtain emac clock from kernel */emac_clk=devm_clk_get(&pdev->dev,NULL);
@@ -1815,6 +1818,19 @@ static int davinci_emac_probe(struct platform_device *pdev)gotoerr_free_netdev;}+#ifdef CONFIG_MTD+mtd=get_mtd_device_nm("MAC-Address");+if(!IS_ERR(mtd)){+rc=mtd_read(mtd,0,ETH_ALEN,+&mac_addr_len,priv->mac_addr);+if(rc==0)+dev_info(&pdev->dev,+"Read MAC addr from SPI Flash: %pM\n",+priv->mac_addr);+put_mtd_device(mtd);+}+#endif /* CONFIG_MTD */+/* 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;
From: David Lechner <david@lechnology.com> Date: 2018-07-03 16:47:28
On 07/03/2018 11:39 AM, Florian Fainelli wrote:
On 06/29/2018 02:40 AM, Bartosz Golaszewski wrote:
quoted
From: Bartosz Golaszewski <redacted>
On da850-evm board we can read the MAC address from MTD. It's currently
done in the relevant board file, but we want to get rid of all the MAC
reading callbacks from the board file (SPI and NAND). Move the reading
of the MAC address from SPI to the emac driver's probe function.
This should be made something generic to all drivers, not just something
the davinci_emac driver does, something like this actually:
https://lkml.org/lkml/2018/3/24/312
I was thinking about suggesting adding a nvmem provider for MTD devices
as well. It would fix the kernel config dependency problems I was running
into since nvmem lookups can do -EPROBE_DEFER.
From: Ladislav Michl <hidden> Date: 2018-07-04 07:11:10
On Tue, Jul 03, 2018 at 09:39:51AM -0700, Florian Fainelli wrote:
On 06/29/2018 02:40 AM, Bartosz Golaszewski wrote:
quoted
From: Bartosz Golaszewski <redacted>
On da850-evm board we can read the MAC address from MTD. It's currently
done in the relevant board file, but we want to get rid of all the MAC
reading callbacks from the board file (SPI and NAND). Move the reading
of the MAC address from SPI to the emac driver's probe function.
This should be made something generic to all drivers, not just something
the davinci_emac driver does, something like this actually:
https://lkml.org/lkml/2018/3/24/312
...and that's would also make it work when MAC address is stored
in 24c08 EEPROM, which is quite common.
@@ -1783,7 +1783,10 @@ static int davinci_emac_probe(struct platform_device *pdev)structcpdma_paramsdma_params;structclk*emac_clk;unsignedlongemac_bus_frequency;-+#ifdef CONFIG_MTD+size_tmac_addr_len;+structmtd_info*mtd;+#endif /* CONFIG_MTD *//* obtain emac clock from kernel */emac_clk=devm_clk_get(&pdev->dev,NULL);
@@ -1815,6 +1818,19 @@ static int davinci_emac_probe(struct platform_device *pdev)gotoerr_free_netdev;}+#ifdef CONFIG_MTD+mtd=get_mtd_device_nm("MAC-Address");+if(!IS_ERR(mtd)){+rc=mtd_read(mtd,0,ETH_ALEN,+&mac_addr_len,priv->mac_addr);+if(rc==0)+dev_info(&pdev->dev,+"Read MAC addr from SPI Flash: %pM\n",+priv->mac_addr);+put_mtd_device(mtd);+}+#endif /* CONFIG_MTD */+/* 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;
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
2018-07-04 9:09 GMT+02:00 Ladislav Michl [off-list ref]:
On Tue, Jul 03, 2018 at 09:39:51AM -0700, Florian Fainelli wrote:
quoted
On 06/29/2018 02:40 AM, Bartosz Golaszewski wrote:
quoted
From: Bartosz Golaszewski <redacted>
On da850-evm board we can read the MAC address from MTD. It's currently
done in the relevant board file, but we want to get rid of all the MAC
reading callbacks from the board file (SPI and NAND). Move the reading
of the MAC address from SPI to the emac driver's probe function.
This should be made something generic to all drivers, not just something
the davinci_emac driver does, something like this actually:
https://lkml.org/lkml/2018/3/24/312
...and that's would also make it work when MAC address is stored
in 24c08 EEPROM, which is quite common.
This is what the second patch for davinci_emac in this series does. I
agree that this should become more generic at some point - we should
probably have a routine somewhere in net that would try to get the MAC
address from all possible sources (nvmem, of etc.). This is somewhat
related to the work I want to do on nvmem to make the at24 setup()
callback more generic.
Unfortunately we don't have it yet and I will not have time to work on
it before v4.20 so if there are no serious objections, I'd like to get
this series merged for v4.19 and then we can refactor the MAC reading
later.
How does it sound?
Best regards,
Bartosz Golaszewski
@@ -1783,7 +1783,10 @@ static int davinci_emac_probe(struct platform_device *pdev)structcpdma_paramsdma_params;structclk*emac_clk;unsignedlongemac_bus_frequency;-+#ifdef CONFIG_MTD+size_tmac_addr_len;+structmtd_info*mtd;+#endif /* CONFIG_MTD *//* obtain emac clock from kernel */emac_clk=devm_clk_get(&pdev->dev,NULL);
@@ -1815,6 +1818,19 @@ static int davinci_emac_probe(struct platform_device *pdev)gotoerr_free_netdev;}+#ifdef CONFIG_MTD+mtd=get_mtd_device_nm("MAC-Address");+if(!IS_ERR(mtd)){+rc=mtd_read(mtd,0,ETH_ALEN,+&mac_addr_len,priv->mac_addr);+if(rc==0)+dev_info(&pdev->dev,+"Read MAC addr from SPI Flash: %pM\n",+priv->mac_addr);+put_mtd_device(mtd);+}+#endif /* CONFIG_MTD */+/* 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;
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Sekhar Nori <hidden> Date: 2018-07-04 09:06:02
On Wednesday 04 July 2018 01:59 PM, Bartosz Golaszewski wrote:
2018-07-04 9:09 GMT+02:00 Ladislav Michl [off-list ref]:
quoted
On Tue, Jul 03, 2018 at 09:39:51AM -0700, Florian Fainelli wrote:
quoted
On 06/29/2018 02:40 AM, Bartosz Golaszewski wrote:
quoted
From: Bartosz Golaszewski <redacted>
On da850-evm board we can read the MAC address from MTD. It's currently
done in the relevant board file, but we want to get rid of all the MAC
reading callbacks from the board file (SPI and NAND). Move the reading
of the MAC address from SPI to the emac driver's probe function.
This should be made something generic to all drivers, not just something
the davinci_emac driver does, something like this actually:
https://lkml.org/lkml/2018/3/24/312
...and that's would also make it work when MAC address is stored
in 24c08 EEPROM, which is quite common.
This is what the second patch for davinci_emac in this series does. I
agree that this should become more generic at some point - we should
probably have a routine somewhere in net that would try to get the MAC
address from all possible sources (nvmem, of etc.). This is somewhat
related to the work I want to do on nvmem to make the at24 setup()
callback more generic.
Unfortunately we don't have it yet and I will not have time to work on
it before v4.20 so if there are no serious objections, I'd like to get
this series merged for v4.19 and then we can refactor the MAC reading
later.
How does it sound?
I don't think the series introduces any regressions. We need to have MTD
and SPI flash built into the kernel even today to get mac address on
DA850 EVM. So from that perspective, I don't have objections (I need to
actually test still).
OTOH, it will be nice to do the conversion once and not piecemeal. That
way there is less churn and scope for regressions.
So from a mach-davinci perspective, I don't have a very strong position
either way.
Thanks,
Sekhar
2018-07-04 11:04 GMT+02:00 Sekhar Nori [off-list ref]:
On Wednesday 04 July 2018 01:59 PM, Bartosz Golaszewski wrote:
quoted
2018-07-04 9:09 GMT+02:00 Ladislav Michl [off-list ref]:
quoted
On Tue, Jul 03, 2018 at 09:39:51AM -0700, Florian Fainelli wrote:
quoted
On 06/29/2018 02:40 AM, Bartosz Golaszewski wrote:
quoted
From: Bartosz Golaszewski <redacted>
On da850-evm board we can read the MAC address from MTD. It's currently
done in the relevant board file, but we want to get rid of all the MAC
reading callbacks from the board file (SPI and NAND). Move the reading
of the MAC address from SPI to the emac driver's probe function.
This should be made something generic to all drivers, not just something
the davinci_emac driver does, something like this actually:
https://lkml.org/lkml/2018/3/24/312
...and that's would also make it work when MAC address is stored
in 24c08 EEPROM, which is quite common.
This is what the second patch for davinci_emac in this series does. I
agree that this should become more generic at some point - we should
probably have a routine somewhere in net that would try to get the MAC
address from all possible sources (nvmem, of etc.). This is somewhat
related to the work I want to do on nvmem to make the at24 setup()
callback more generic.
Unfortunately we don't have it yet and I will not have time to work on
it before v4.20 so if there are no serious objections, I'd like to get
this series merged for v4.19 and then we can refactor the MAC reading
later.
How does it sound?
I don't think the series introduces any regressions. We need to have MTD
and SPI flash built into the kernel even today to get mac address on
DA850 EVM. So from that perspective, I don't have objections (I need to
actually test still).
OTOH, it will be nice to do the conversion once and not piecemeal. That
way there is less churn and scope for regressions.
So from a mach-davinci perspective, I don't have a very strong position
either way.
Thanks,
Sekhar
We're getting close to rc5 so I'd like to make a case for this series again.
I understand that there's more to do than just the changes introduced
here, but we shouldn't try to fix several problems in many different
places at once. There's just too many moving pieces. I'd rather start
merging small improvements right away.
The idea behind this series is to remove (almost) all users of
at24_platform_data. The davinci_emac patches are there only because we
need to remove some MAC adress reading stuff from the board files.
Having this code there and calling it back from EEPROM/MTD drivers is
already wrong and we should work towards using nvmem for that anyway.
Currently for MTD the nvmem support series seems to be dead and it's
going to take some time before anything gets upstream.
So I'd like to again ask you to consider picking up the patches from
this series to your respective trees or at the very least: I'd like to
ask Srinivas to pick up the nvmem patches and Sekhar to take the
first, non-controversial batch of davinci platform changes so that
we'll have less code to carry for the next release.
Best regards,
Bartosz Golaszewski
From: Sekhar Nori <hidden> Date: 2018-07-16 08:52:47
On Friday 13 July 2018 11:30 PM, Bartosz Golaszewski wrote:
We're getting close to rc5 so I'd like to make a case for this series again.
I understand that there's more to do than just the changes introduced
here, but we shouldn't try to fix several problems in many different
places at once. There's just too many moving pieces. I'd rather start
merging small improvements right away.
The idea behind this series is to remove (almost) all users of
at24_platform_data. The davinci_emac patches are there only because we
need to remove some MAC adress reading stuff from the board files.
Having this code there and calling it back from EEPROM/MTD drivers is
already wrong and we should work towards using nvmem for that anyway.
Currently for MTD the nvmem support series seems to be dead and it's
going to take some time before anything gets upstream.
So I'd like to again ask you to consider picking up the patches from
this series to your respective trees or at the very least: I'd like to
ask Srinivas to pick up the nvmem patches and Sekhar to take the
first, non-controversial batch of davinci platform changes so that
we'll have less code to carry for the next release.
I think those are patches 3-7. I can take those if I get an immutable
commit over v4.18-rc1 from Srinivas with patches 1 & 2 applied.
Thanks,
Sekhar
On Friday 13 July 2018 11:30 PM, Bartosz Golaszewski wrote:
quoted
We're getting close to rc5 so I'd like to make a case for this series again.
I understand that there's more to do than just the changes introduced
here, but we shouldn't try to fix several problems in many different
places at once. There's just too many moving pieces. I'd rather start
merging small improvements right away.
The idea behind this series is to remove (almost) all users of
at24_platform_data. The davinci_emac patches are there only because we
need to remove some MAC adress reading stuff from the board files.
Having this code there and calling it back from EEPROM/MTD drivers is
already wrong and we should work towards using nvmem for that anyway.
Currently for MTD the nvmem support series seems to be dead and it's
going to take some time before anything gets upstream.
So I'd like to again ask you to consider picking up the patches from
this series to your respective trees or at the very least: I'd like to
ask Srinivas to pick up the nvmem patches and Sekhar to take the
first, non-controversial batch of davinci platform changes so that
we'll have less code to carry for the next release.
I think those are patches 3-7. I can take those if I get an immutable
commit over v4.18-rc1 from Srinivas with patches 1 & 2 applied.
nvmem patches go via Greg KH char-misc tree, if it makes things easy I
can provide Ack on nvmem patches, so that you can take these patches via
your tree?
Let me know.
--srini
From: Sekhar Nori <hidden> Date: 2018-07-16 12:00:49
On Monday 16 July 2018 02:26 PM, Srinivas Kandagatla wrote:
On 16/07/18 09:50, Sekhar Nori wrote:
quoted
On Friday 13 July 2018 11:30 PM, Bartosz Golaszewski wrote:
quoted
We're getting close to rc5 so I'd like to make a case for this series
again.
I understand that there's more to do than just the changes introduced
here, but we shouldn't try to fix several problems in many different
places at once. There's just too many moving pieces. I'd rather start
merging small improvements right away.
The idea behind this series is to remove (almost) all users of
at24_platform_data. The davinci_emac patches are there only because we
need to remove some MAC adress reading stuff from the board files.
Having this code there and calling it back from EEPROM/MTD drivers is
already wrong and we should work towards using nvmem for that anyway.
Currently for MTD the nvmem support series seems to be dead and it's
going to take some time before anything gets upstream.
So I'd like to again ask you to consider picking up the patches from
this series to your respective trees or at the very least: I'd like to
ask Srinivas to pick up the nvmem patches and Sekhar to take the
first, non-controversial batch of davinci platform changes so that
we'll have less code to carry for the next release.
I think those are patches 3-7. I can take those if I get an immutable
commit over v4.18-rc1 from Srinivas with patches 1 & 2 applied.
nvmem patches go via Greg KH char-misc tree, if it makes things easy I
can provide Ack on nvmem patches, so that you can take these patches via
your tree?
Let me know.
I can do that.
Greg, are you fine with this? It will be great to have your ack for
patches 1/8 and 2/18.
Thanks,
Sekhar
On Mon, Jul 16, 2018 at 05:27:00PM +0530, Sekhar Nori wrote:
On Monday 16 July 2018 02:26 PM, Srinivas Kandagatla wrote:
quoted
On 16/07/18 09:50, Sekhar Nori wrote:
quoted
On Friday 13 July 2018 11:30 PM, Bartosz Golaszewski wrote:
quoted
We're getting close to rc5 so I'd like to make a case for this series
again.
I understand that there's more to do than just the changes introduced
here, but we shouldn't try to fix several problems in many different
places at once. There's just too many moving pieces. I'd rather start
merging small improvements right away.
The idea behind this series is to remove (almost) all users of
at24_platform_data. The davinci_emac patches are there only because we
need to remove some MAC adress reading stuff from the board files.
Having this code there and calling it back from EEPROM/MTD drivers is
already wrong and we should work towards using nvmem for that anyway.
Currently for MTD the nvmem support series seems to be dead and it's
going to take some time before anything gets upstream.
So I'd like to again ask you to consider picking up the patches from
this series to your respective trees or at the very least: I'd like to
ask Srinivas to pick up the nvmem patches and Sekhar to take the
first, non-controversial batch of davinci platform changes so that
we'll have less code to carry for the next release.
I think those are patches 3-7. I can take those if I get an immutable
commit over v4.18-rc1 from Srinivas with patches 1 & 2 applied.
quoted
nvmem patches go via Greg KH char-misc tree, if it makes things easy I
can provide Ack on nvmem patches, so that you can take these patches via
your tree?
Let me know.
I can do that.
Greg, are you fine with this? It will be great to have your ack for
patches 1/8 and 2/18.
From: Sekhar Nori <hidden> Date: 2018-07-16 12:16:56
On Monday 16 July 2018 05:40 PM, Greg Kroah-Hartman wrote:
On Mon, Jul 16, 2018 at 05:27:00PM +0530, Sekhar Nori wrote:
quoted
On Monday 16 July 2018 02:26 PM, Srinivas Kandagatla wrote:
quoted
On 16/07/18 09:50, Sekhar Nori wrote:
quoted
On Friday 13 July 2018 11:30 PM, Bartosz Golaszewski wrote:
quoted
We're getting close to rc5 so I'd like to make a case for this series
again.
I understand that there's more to do than just the changes introduced
here, but we shouldn't try to fix several problems in many different
places at once. There's just too many moving pieces. I'd rather start
merging small improvements right away.
The idea behind this series is to remove (almost) all users of
at24_platform_data. The davinci_emac patches are there only because we
need to remove some MAC adress reading stuff from the board files.
Having this code there and calling it back from EEPROM/MTD drivers is
already wrong and we should work towards using nvmem for that anyway.
Currently for MTD the nvmem support series seems to be dead and it's
going to take some time before anything gets upstream.
So I'd like to again ask you to consider picking up the patches from
this series to your respective trees or at the very least: I'd like to
ask Srinivas to pick up the nvmem patches and Sekhar to take the
first, non-controversial batch of davinci platform changes so that
we'll have less code to carry for the next release.
I think those are patches 3-7. I can take those if I get an immutable
commit over v4.18-rc1 from Srinivas with patches 1 & 2 applied.
quoted
nvmem patches go via Greg KH char-misc tree, if it makes things easy I
can provide Ack on nvmem patches, so that you can take these patches via
your tree?
Let me know.
I can do that.
Greg, are you fine with this? It will be great to have your ack for
patches 1/8 and 2/18.
I'm not the nvmem maintainer :)
Got it. Will apply with Srinivas's ack.
Regards,
Sekhar
From: Sekhar Nori <hidden> Date: 2018-07-20 05:06:10
On Monday 16 July 2018 02:26 PM, Srinivas Kandagatla wrote:
On 16/07/18 09:50, Sekhar Nori wrote:
quoted
On Friday 13 July 2018 11:30 PM, Bartosz Golaszewski wrote:
quoted
We're getting close to rc5 so I'd like to make a case for this series
again.
I understand that there's more to do than just the changes introduced
here, but we shouldn't try to fix several problems in many different
places at once. There's just too many moving pieces. I'd rather start
merging small improvements right away.
The idea behind this series is to remove (almost) all users of
at24_platform_data. The davinci_emac patches are there only because we
need to remove some MAC adress reading stuff from the board files.
Having this code there and calling it back from EEPROM/MTD drivers is
already wrong and we should work towards using nvmem for that anyway.
Currently for MTD the nvmem support series seems to be dead and it's
going to take some time before anything gets upstream.
So I'd like to again ask you to consider picking up the patches from
this series to your respective trees or at the very least: I'd like to
ask Srinivas to pick up the nvmem patches and Sekhar to take the
first, non-controversial batch of davinci platform changes so that
we'll have less code to carry for the next release.
I think those are patches 3-7. I can take those if I get an immutable
commit over v4.18-rc1 from Srinivas with patches 1 & 2 applied.
nvmem patches go via Greg KH char-misc tree, if it makes things easy I
can provide Ack on nvmem patches, so that you can take these patches via
your tree?
There is a lot of follow-up traffic on how exactly to develop the needed
interfaces for reading mac address in mtd and/or network subsystem.
But, I don't think any of that negates the need for nvmem lookups that
work for non-device-tree and populating the lookups in mach-davinci
board code.
I am going to send patches 1-7 to ARM-SoC soon, so please do say if
there is any disagreement on this.
Thanks,
Sekhar
From: Sekhar Nori <hidden> Date: 2018-07-27 09:54:22
On Friday 20 July 2018 10:34 AM, Sekhar Nori wrote:
There is a lot of follow-up traffic on how exactly to develop the needed
interfaces for reading mac address in mtd and/or network subsystem.
But, I don't think any of that negates the need for nvmem lookups that
work for non-device-tree and populating the lookups in mach-davinci
board code.
I am going to send patches 1-7 to ARM-SoC soon, so please do say if
there is any disagreement on this.
I owed a response on this. After thinking over some and discussing with
Bartosz as well, I decided not to merge any patches from this series.
Its better to merge anything after the actual path we are talking is
fully clear.
Thanks,
Sekhar
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 functions that allow
machine code to register nvmem lookup which are later lazily used to
add corresponding nvmem cells and remove them if no longer needed.
Signed-off-by: Bartosz Golaszewski <redacted>
---
drivers/nvmem/core.c | 77 +++++++++++++++++++++++++++++++++-
include/linux/nvmem-consumer.h | 6 +++
include/linux/nvmem-provider.h | 10 +++++
3 files changed, 92 insertions(+), 1 deletion(-)
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 functions that allow
machine code to register nvmem lookup which are later lazily used to
add corresponding nvmem cells and remove them if no longer needed.
Signed-off-by: Bartosz Golaszewski<redacted>
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 functions that allow
machine code to register nvmem lookup which are later lazily used to
add corresponding nvmem cells and remove them if no longer needed.
Signed-off-by: Bartosz Golaszewski <redacted>