ARM: davinci: step towards removing at24_platform_data
Subsystems (8)
v4 cover ARM: davinci: step towards removing at24_platform_data
From: Bartosz Golaszewski <[email protected]>
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(-)
Signature · 1 line
2.17.1
PATCH v4 1/18 nvmem: add support for cell lookups
From: Bartosz Golaszewski <[email protected]>
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.
--- drivers/nvmem/core.c | 77 +++++++++++++++++++++++++++++++++- include/linux/nvmem-consumer.h | 6 +++ include/linux/nvmem-provider.h | 10 +++++ 3 files changed, 92 insertions(+), 1 deletion(-)
drivers/nvmem/core.c +76 -1
@@ -62,6 +62,9 @@ static DEFINE_IDA(nvmem_ida);static LIST_HEAD (nvmem_cells);static DEFINE_MUTEX (nvmem_cells_mutex); +static LIST_HEAD (nvmem_cell_lookups); +static DEFINE_MUTEX (nvmem_lookup_mutex); +#ifdef CONFIG_DEBUG_LOCK_ALLOC static struct lock_class_key eeprom_lock_key;#endif
@@ -247,6 +250,41 @@ static const struct attribute_group *nvmem_ro_root_dev_groups[] = { NULL, }; +/** +* nvmem_add_lookup_table() - register a number of nvmem cell lookup entries +* +* @lookup: array of nvmem cell lookup entries +* @nentries: number of lookup entries in the array +*/ +void nvmem_add_lookup_table (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_add_lookup_table); + +/** +* nvmem_del_lookup_table() - unregister a set of previously added nvmem cell +* lookup entries +* +* @lookup: array of nvmem cell lookup entries +* @nentries: number of lookup entries in the array +*/ +void nvmem_del_lookup_table (struct nvmem_cell_lookup *lookup,size_t nentries) +{ +int i; + +mutex_lock (&nvmem_lookup_mutex); +for (i =0 ; i < nentries; i++) +list_del (&lookup[i].list); +mutex_unlock (&nvmem_lookup_mutex); +} +EXPORT_SYMBOL_GPL (nvmem_del_lookup_table); +static void nvmem_release (struct device *dev) {struct nvmem_device *nvmem =to_nvmem_device (dev);
@@ -916,6 +954,39 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,EXPORT_SYMBOL_GPL (of_nvmem_cell_get);#endif +static struct nvmem_cell *nvmem_cell_from_lookup (const char *cell_id) +{ +struct nvmem_cell *cell =ERR_PTR (-ENOENT ); +struct nvmem_cell_lookup *lookup; +struct nvmem_device *nvmem; +int rc; + +mutex_lock (&nvmem_lookup_mutex); + +list_for_each_entry (lookup, &nvmem_cell_lookups, list) { +if (strcmp (cell_id, lookup->info.name) ==0 ) { + nvmem =nvmem_find (lookup->nvmem_name); +if (!nvmem) { + cell =ERR_PTR (-EPROBE_DEFER ); + goto out; + } + + rc =nvmem_add_cells (nvmem, &lookup->info,1 ); +if (rc) { + cell =ERR_PTR (rc); + goto out; + } + + cell =nvmem_cell_get_from_list (cell_id); +break ; + } + } + +out: +mutex_unlock (&nvmem_lookup_mutex); +return cell; +} +/** * nvmem_cell_get() - Get nvmem cell of device form a given cell name *
@@ -936,7 +1007,11 @@ struct nvmem_cell *nvmem_cell_get(struct device *dev, const char *cell_id)return cell; } -return nvmem_cell_get_from_list (cell_id); + cell =nvmem_cell_get_from_list (cell_id); +if (!IS_ERR (cell) ||PTR_ERR (cell) == -EPROBE_DEFER ) +return cell; + +return nvmem_cell_from_lookup (cell_id); }EXPORT_SYMBOL_GPL (nvmem_cell_get);
include/linux/nvmem-consumer.h +6 -0
@@ -29,6 +29,12 @@ struct nvmem_cell_info {unsigned int nbits; }; +struct nvmem_cell_lookup { +struct nvmem_cell_info info; +struct list_head list; +const char *nvmem_name; +}; +#if IS_ENABLED (CONFIG_NVMEM )/* Cell based interface */
include/linux/nvmem-provider.h +10 -0
@@ -17,6 +17,7 @@struct nvmem_device ;struct nvmem_cell_info ; +struct nvmem_cell_lookup ;typedef int (*nvmem_reg_read_t )(void *priv,unsigned int offset,void *val,size_t bytes); typedef int (*nvmem_reg_write_t)(void *priv, unsigned int offset,
@@ -72,6 +73,9 @@ struct nvmem_config {struct nvmem_device *nvmem_register (const struct nvmem_config *cfg);int nvmem_unregister (struct nvmem_device *nvmem); +void nvmem_add_lookup_table (struct nvmem_cell_lookup *lookup,size_t nentries); +void nvmem_del_lookup_table (struct nvmem_cell_lookup *lookup,size_t nentries); +struct nvmem_device *devm_nvmem_register (struct device *dev,const struct nvmem_config *cfg);
@@ -92,6 +96,12 @@ static inline int nvmem_unregister(struct nvmem_device *nvmem)return -ENOSYS ; } +static inline void +nvmem_add_lookup_table (struct nvmem_cell_lookup *lookup,size_t nentries) {} + +static inline void +nvmem_del_lookup_table (struct nvmem_cell_lookup *lookup,size_t nentries) {} +static inline struct nvmem_device *devm_nvmem_register (struct device *dev,const struct nvmem_config *c) {
Signature · 1 line
2.17.1
Re: [PATCH v4 01/18] nvmem: add support for cell lookups
Quoted 7 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
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.
Quoted 6 lines
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 <[email protected]>
Re: [PATCH v4 01/18] nvmem: add support for cell lookups
In reply to Bartosz GolaszewskiQuoted 7 lines · Bartosz Golaszewski
From: Bartosz Golaszewski<[email protected]>
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.
Quoted 6 lines
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<[email protected]>
PATCH v4 2/18 Documentation: nvmem: document lookup entries
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
Describe the usage of nvmem cell lookup tables.
--- Documentation/nvmem/nvmem.txt | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
Documentation/nvmem/nvmem.txt +28 -0
@@ -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 +++++++++++++++
Signature · 1 line
2.17.1
Re: [PATCH v4 02/18] Documentation: nvmem: document lookup entries
Quoted 15 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
Describe the usage of nvmem cell lookup tables.
Signed-off-by Bartosz Golaszewski <[email protected]>--- Documentation/nvmem/nvmem.txt | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)Documentation/nvmem/nvmem.txt +0
-0@@ -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
Documentation/nvmem/nvmem.txt static int qfprom_probe(struct platform_device *pdev) · line 68
Quoted 10 lines
Documentation/nvmem/nvmem.txt +8
-0struct 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
Re: [PATCH v4 02/18] Documentation: nvmem: document lookup entries
In reply to Bartosz GolaszewskiQuoted 5 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
Describe the usage of nvmem cell lookup tables.
Signed-off-by Bartosz Golaszewski <[email protected]>
Quoted 44 lines
--- Documentation/nvmem/nvmem.txt | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)Documentation/nvmem/nvmem.txt +28
-0@@ -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 +++++++++++++++
PATCH v4 3/18 ARM: davinci: dm365-evm: use nvmem lookup for mac address
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
We now support nvmem lookups for machine code. Add a lookup for mac-address.
--- arch/arm/mach-davinci/board-dm365-evm.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
arch/arm/mach-davinci/board-dm365-evm.c +12 -0
@@ -28,6 +28,7 @@#include <linux/spi/spi.h> #include <linux/spi/eeprom.h> #include <linux/v4l2-dv-timings.h> +#include <linux/nvmem-provider.h> #include <asm/mach-types.h> #include <asm/mach/arch.h>
@@ -169,6 +170,15 @@ static struct platform_device davinci_nand_device = { }, }; +static struct nvmem_cell_lookup dm365evm_mac_address_cell = { + .info = { + .name ="mac-address" , + .offset =0x7f00 , + .bytes =ETH_ALEN , + }, + .nvmem_name ="1-00500" , +}; +static struct at24_platform_data eeprom_info = { .byte_len = (256 *1024 ) /8 , .page_size =64 ,
@@ -769,6 +779,8 @@ static __init void dm365_evm_init(void)dm365_init_spi0 (BIT (0 ), dm365_evm_spi_info,ARRAY_SIZE (dm365_evm_spi_info)); + +nvmem_add_lookup_table (&dm365evm_mac_address_cell,1 ); }MACHINE_START (DAVINCI_DM365_EVM ,"DaVinci DM365 EVM" )
Signature · 1 line
2.17.1
PATCH v4 4/18 ARM: davinci: dm644-evm: use nvmem lookup for mac address
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
We now support nvmem lookups for machine code. Add a lookup for mac-address.
--- arch/arm/mach-davinci/board-dm644x-evm.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
arch/arm/mach-davinci/board-dm644x-evm.c +12 -0
@@ -28,6 +28,7 @@#include <linux/v4l2-dv-timings.h> #include <linux/export.h> #include <linux/leds.h> +#include <linux/nvmem-provider.h> #include <media/i2c/tvp514x.h>
@@ -476,6 +477,15 @@ static struct pcf857x_platform_data pcf_data_u35 = {* - ... newer boards may have more */ +static struct nvmem_cell_lookup dm6446evm_mac_address_cell = { + .info = { + .name ="mac-address" , + .offset =0x7f00 , + .bytes =ETH_ALEN , + }, + .nvmem_name ="1-00500" , +}; +static struct at24_platform_data eeprom_info = { .byte_len = (256 *1024 ) /8 , .page_size =64 ,
@@ -828,6 +838,8 @@ static __init void davinci_evm_init(void)phy_register_fixup_for_uid (LXT971_PHY_ID ,LXT971_PHY_MASK , davinci_phy_fixup); } + +nvmem_add_lookup_table (&dm6446evm_mac_address_cell,1 ); }MACHINE_START (DAVINCI_EVM ,"DaVinci DM644x EVM" )
Signature · 1 line
2.17.1
PATCH v4 5/18 ARM: davinci: dm646x-evm: use nvmem lookup for mac address
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
We now support nvmem lookups for machine code. Add a lookup for mac-address.
--- arch/arm/mach-davinci/board-dm646x-evm.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
arch/arm/mach-davinci/board-dm646x-evm.c +12 -0
@@ -37,6 +37,7 @@#include <linux/platform_data/i2c-davinci.h> #include <linux/platform_data/mtd-davinci.h> #include <linux/platform_data/mtd-davinci-aemif.h> +#include <linux/nvmem-provider.h> #include <asm/mach-types.h> #include <asm/mach/arch.h>
@@ -310,6 +311,15 @@ static struct pcf857x_platform_data pcf_data = {* - ... newer boards may have more */ +static struct nvmem_cell_lookup dm646x_evm_mac_address_cell = { + .info = { + .name ="mac-address" , + .offset =0x7f00 , + .bytes =ETH_ALEN , + }, + .nvmem_name ="1-00500" , +}; +static struct at24_platform_data eeprom_info = { .byte_len = (256 *1024 ) /8 , .page_size =64 ,
@@ -802,6 +812,8 @@ static __init void evm_init(void)davinci_init_ide (); soc_info->emac_pdata->phy_id =DM646X_EVM_PHY_ID ; + +nvmem_add_lookup_table (&dm646x_evm_mac_address_cell,1 ); }MACHINE_START (DAVINCI_DM6467_EVM ,"DaVinci DM646x EVM" )
Signature · 1 line
2.17.1
PATCH v4 6/18 ARM: davinci: da830-evm: use nvmem lookup for mac address
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
We now support nvmem lookups for machine code. Add a lookup for mac-address.
--- arch/arm/mach-davinci/board-da830-evm.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
arch/arm/mach-davinci/board-da830-evm.c +12 -0
@@ -29,6 +29,7 @@#include <linux/platform_data/spi-davinci.h> #include <linux/platform_data/usb-davinci.h> #include <linux/regulator/machine.h> +#include <linux/nvmem-provider.h> #include <asm/mach-types.h> #include <asm/mach/arch.h>
@@ -409,6 +410,15 @@ 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_lookup da830_evm_mac_address_cell = { + .info = { + .name ="mac-address" , + .offset =0x7f00 , + .bytes =ETH_ALEN , + }, + .nvmem_name ="1-00500" , +}; +static struct at24_platform_data da830_evm_i2c_eeprom_info = { .byte_len =SZ_256K /8 , .page_size =64 ,
@@ -618,6 +628,8 @@ static __init void da830_evm_init(void)pr_warn ("%s: spi 0 registration failed: %d\n" , __func__, ret);regulator_has_full_constraints (); + +nvmem_add_lookup_table (&da830_evm_mac_address_cell,1 ); }#ifdef CONFIG_SERIAL_8250_CONSOLE
Signature · 1 line
2.17.1
PATCH v4 7/18 ARM: davinci: mityomapl138: add nvmem cells lookup entries
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
We now support nvmem lookups for machine code. Add a lookup for mac-address.
--- arch/arm/mach-davinci/board-mityomapl138.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
arch/arm/mach-davinci/board-mityomapl138.c +22 -0
@@ -21,6 +21,7 @@#include <linux/etherdevice.h> #include <linux/spi/spi.h> #include <linux/spi/flash.h> +#include <linux/nvmem-provider.h> #include <asm/io.h> #include <asm/mach-types.h>
@@ -160,6 +161,25 @@ static void read_factory_config(struct nvmem_device *nvmem, void *context)mityomapl138_cpufreq_init (partnum); } +static struct nvmem_cell_lookup mityomapl138_nvmem_cells[] = { + { + .info = { + .name ="factory-config" , + .offset =0x0 , + .bytes =sizeof (struct factory_config ), + }, + .nvmem_name ="1-00500" , + }, + { + .info = { + .name ="mac-address" , + .offset =0x64 , + .bytes =ETH_ALEN , + }, + .nvmem_name ="1-00500" , + } +}; +static struct at24_platform_data mityomapl138_fd_chip = { .byte_len =256 , .page_size =8 ,
@@ -534,6 +554,8 @@ static void __init mityomapl138_init(void)if (ret)pr_warn ("spi 1 registration failed: %d\n" , ret); +nvmem_add_lookup_table (mityomapl138_nvmem_cells, +ARRAY_SIZE (mityomapl138_nvmem_cells));mityomapl138_config_emac (); ret =da8xx_register_rtc ();
Signature · 1 line
2.17.1
PATCH v4 8/18 net: davinci_emac: potentially get the MAC address from MTD
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
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.
--- drivers/net/ethernet/ti/davinci_emac.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)
drivers/net/ethernet/ti/davinci_emac.c +18 -2
@@ -67,7 +67,7 @@#include <linux/of_irq.h> #include <linux/of_net.h> #include <linux/mfd/syscon.h> - +#include <linux/mtd/mtd.h> #include <asm/irq.h> #include <asm/page.h>
@@ -1783,7 +1783,10 @@ static int davinci_emac_probe(struct platform_device *pdev)struct cpdma_params dma_params;struct clk *emac_clk;unsigned long emac_bus_frequency; - +#ifdef CONFIG_MTD +size_t mac_addr_len; +struct mtd_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) goto err_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;
Signature · 1 line
2.17.1
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
Quoted 38 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
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 <[email protected]>--- drivers/net/ethernet/ti/davinci_emac.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)drivers/net/ethernet/ti/davinci_emac.c +5
-2@@ -67,7 +67,7 @@#include <linux/of_irq.h> #include <linux/of_net.h> #include <linux/mfd/syscon.h> - +#include <linux/mtd/mtd.h> #include <asm/irq.h> #include <asm/page.h> @@ -1783,7 +1783,10 @@ static int davinci_emac_probe(struct platform_device *pdev)struct cpdma_params dma_params;struct clk *emac_clk;unsigned long emac_bus_frequency; - +#ifdef CONFIG_MTD +size_t mac_addr_len; +struct mtd_info *mtd; +#endif /* CONFIG_MTD */ /* obtain emac clock from kernel */ emac_clk =devm_clk_get (&pdev->dev,NULL );
drivers/net/ethernet/ti/davinci_emac.c static int davinci_emac_probe(struct platform_device *pdev) · line 1821
Quoted 4 lines
drivers/net/ethernet/ti/davinci_emac.c +1
-0@@ -1815,6 +1818,19 @@ static int davinci_emac_probe(struct platform_device *pdev) goto err_free_netdev; } +#ifdef CONFIG_MTD
What about the case when MTD is compiled as a module?
drivers/net/ethernet/ti/davinci_emac.c static int davinci_emac_probe(struct platform_device *pdev) · line 1822
Quoted 1 line
drivers/net/ethernet/ti/davinci_emac.c +1
-0+ mtd =get_mtd_device_nm ("MAC-Address" );
What about the case when PTR_ERR(mtd) == -EPROBE_DEFER?
Quoted 15 lines
drivers/net/ethernet/ti/davinci_emac.c +11
-0+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;
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
Quoted 43 lines · David Lechner
Quoted 36 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
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 <[email protected]>---
?drivers/net/ethernet/ti/davinci_emac.c| 20 ++++++++++++++++++-- ? 1 file changed, 18 insertions(+), 2 deletions(-)drivers/net/ethernet/ti/davinci_emac.c +0
-0@@ -67,7 +67,7 @@? #include <
linux/of_irq.h>
? #include <linux/of_net.h>
? #include <linux/mfd/syscon.h>drivers/net/ethernet/ti/davinci_emac.c +1
-1- +#include <linux/mtd/mtd.h> ? #include <
asm/irq.h>
? #include <asm/page.h>drivers/net/ethernet/ti/davinci_emac.c +4
-1@@ -1783,7 +1783,10 @@ static int davinci_emac_probe(struct platform_device *pdev) ????? struct cpdma_params dma_params; ????? struct clk *emac_clk; ????? unsigned long emac_bus_frequency; - +#ifdef CONFIG_MTD +??? size_t mac_addr_len; +??? struct mtd_info *mtd; +#endif /* CONFIG_MTD */ ????? /* obtain emac clock from kernel */
?????emac_clk=devm_clk_get(&pdev->dev, NULL);drivers/net/ethernet/ti/davinci_emac.c static int davinci_emac_probe(struct platform_device *pdev) · line 1820
Quoted 3 lines
drivers/net/ethernet/ti/davinci_emac.c +1
-0@@ -1815,6 +1818,19 @@ static int davinci_emac_probe(struct platform_device *pdev) ????????? goto err_free_netdev; ????? } +#ifdef CONFIG_MTD What about the case when MTD is compiled as a module?
Quoted 3 lines
drivers/net/ethernet/ti/davinci_emac.c static int davinci_emac_probe(struct platform_device *pdev) · line 1821
Quoted 1 line
drivers/net/ethernet/ti/davinci_emac.c +1
-0+??? 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 17 lines
Quoted 16 lines
drivers/net/ethernet/ti/davinci_emac.c +11
-0+??? 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;
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
2018-06-29 22:35 GMT+02:00 David Lechner <[email protected]>:
Quoted 56 lines · David Lechner
Quoted 49 lines · Bartosz Golaszewski
Quoted 39 lines
From: Bartosz Golaszewski <[email protected]>
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 <[email protected]>--- drivers/net/ethernet/ti/davinci_emac.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)drivers/net/ethernet/ti/davinci_emac.c +5
-2@@ -67,7 +67,7 @@#include <linux/of_irq.h> #include <linux/of_net.h> #include <linux/mfd/syscon.h> - +#include <linux/mtd/mtd.h> #include <asm/irq.h> #include <asm/page.h> @@ -1783,7 +1783,10 @@ static int davinci_emac_probe(struct platform_device *pdev)struct cpdma_params dma_params;struct clk *emac_clk;unsigned long emac_bus_frequency; - +#ifdef CONFIG_MTD +size_t mac_addr_len; +struct mtd_info *mtd; +#endif /* CONFIG_MTD */ /* obtain emac clock from kernel */ emac_clk =devm_clk_get (&pdev->dev,NULL );drivers/net/ethernet/ti/davinci_emac.c static int davinci_emac_probe(struct · line 1821
Quoted 4 lines
drivers/net/ethernet/ti/davinci_emac.c +1
-0@@ -1815,6 +1818,19 @@ static int davinci_emac_probe(struct platform_device *pdev) goto err_free_netdev; } +#ifdef CONFIG_MTD What about the case when MTD is compiled as a module?
Quoted 4 lines
drivers/net/ethernet/ti/davinci_emac.c static int davinci_emac_probe(struct platform_device *pdev) · line 1822
Quoted 1 line
drivers/net/ethernet/ti/davinci_emac.c +1
-0+ mtd =get_mtd_device_nm ("MAC-Address" );What about the case when
PTR_ERR(mtd)== -EPROBE_DEFER?
Quoted 9 lines
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
-ENODEVeven 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=yCONFIG_MTD_M25P80=yCONFIG_SPI_DAVINCI=y
Best regards,
Bartosz Golaszewski
Quoted 19 lines
Quoted 18 lines
Quoted 17 lines
drivers/net/ethernet/ti/davinci_emac.c +11
-0+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;
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
In reply to Bartosz GolaszewskiQuoted 6 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
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
Quoted 52 lines
Signed-off-by Bartosz Golaszewski <[email protected]>--- drivers/net/ethernet/ti/davinci_emac.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)drivers/net/ethernet/ti/davinci_emac.c +18
-2@@ -67,7 +67,7 @@#include <linux/of_irq.h> #include <linux/of_net.h> #include <linux/mfd/syscon.h> - +#include <linux/mtd/mtd.h> #include <asm/irq.h> #include <asm/page.h> @@ -1783,7 +1783,10 @@ static int davinci_emac_probe(struct platform_device *pdev)struct cpdma_params dma_params;struct clk *emac_clk;unsigned long emac_bus_frequency; - +#ifdef CONFIG_MTD +size_t mac_addr_len; +struct mtd_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) goto err_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;
Signature · 1 line
Florian
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
Quoted 10 lines · Florian Fainelli
Quoted 6 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
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.
Quoted 5 lines
This should be made something generic to all drivers, not just something the
davinci_emacdriver does, something like this actually:
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.
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
In reply to Florian FainelliQuoted 10 lines · Florian Fainelli
Quoted 6 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
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.
Quoted 4 lines
This should be made something generic to all drivers, not just something the
davinci_emacdriver does, something like this actually:
...and that's would also make it work when MAC address is stored in 24c08 EEPROM, which is quite common.
Quoted 58 lines
Quoted 51 lines
Signed-off-by Bartosz Golaszewski <[email protected]>--- drivers/net/ethernet/ti/davinci_emac.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)drivers/net/ethernet/ti/davinci_emac.c +18
-2@@ -67,7 +67,7 @@#include <linux/of_irq.h> #include <linux/of_net.h> #include <linux/mfd/syscon.h> - +#include <linux/mtd/mtd.h> #include <asm/irq.h> #include <asm/page.h> @@ -1783,7 +1783,10 @@ static int davinci_emac_probe(struct platform_device *pdev)struct cpdma_params dma_params;struct clk *emac_clk;unsigned long emac_bus_frequency; - +#ifdef CONFIG_MTD +size_t mac_addr_len; +struct mtd_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) goto err_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;Signature · 5 lines
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
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
2018-07-04 9:09 GMT+02:00 Ladislav Michl <[email protected]>:
Quoted 11 lines · Florian Fainelli
Quoted 10 lines · Bartosz Golaszewski
Quoted 6 lines
From: Bartosz Golaszewski <[email protected]>
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.
Quoted 8 lines
Quoted 4 lines
This should be made something generic to all drivers, not just something the
davinci_emacdriver does, something like this actually:...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
Quoted 58 lines
Quoted 58 lines
Quoted 41 lines
Signed-off-by Bartosz Golaszewski <[email protected]>--- drivers/net/ethernet/ti/davinci_emac.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)drivers/net/ethernet/ti/davinci_emac.c +11
-2@@ -67,7 +67,7 @@#include <linux/of_irq.h> #include <linux/of_net.h> #include <linux/mfd/syscon.h> - +#include <linux/mtd/mtd.h> #include <asm/irq.h> #include <asm/page.h> @@ -1783,7 +1783,10 @@ static int davinci_emac_probe(struct platform_device *pdev)struct cpdma_params dma_params;struct clk *emac_clk;unsigned long emac_bus_frequency; - +#ifdef CONFIG_MTD +size_t mac_addr_len; +struct mtd_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) goto err_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 )drivers/net/ethernet/ti/davinci_emac.c static int davinci_emac_probe(struct platform_device *pdev) · line 1836
Quoted 10 lines
drivers/net/ethernet/ti/davinci_emac.c +7
-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
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
Quoted 28 lines · Bartosz Golaszewski
2018-07-04 9:09 GMT+02:00 Ladislav Michl <[email protected]>:
Quoted 11 lines · Florian Fainelli
Quoted 10 lines · Bartosz Golaszewski
Quoted 6 lines
From: Bartosz Golaszewski <[email protected]>
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.
Quoted 8 lines
Quoted 4 lines
This should be made something generic to all drivers, not just something the
davinci_emacdriver does, something like this actually:...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_emacin 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 at24setup()callback more generic.
Quoted 6 lines
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
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
2018-07-04 11:04 GMT+02:00 Sekhar Nori <[email protected]>:
Quoted 41 lines · Bartosz Golaszewski
Quoted 28 lines
2018-07-04 9:09 GMT+02:00 Ladislav Michl <[email protected]>:
Quoted 11 lines · Florian Fainelli
Quoted 10 lines · Bartosz Golaszewski
Quoted 6 lines
From: Bartosz Golaszewski <[email protected]>
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.
Quoted 8 lines
Quoted 4 lines
This should be made something generic to all drivers, not just something the
davinci_emacdriver does, something like this actually:...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_emacin 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 at24setup()callback more generic.Quoted 6 lines
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).
Quoted 8 lines
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
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
Quoted 13 lines · Bartosz Golaszewski
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. Thedavinci_emacpatches 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.
Quoted 8 lines
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
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
Quoted 18 lines · Sekhar Nori
Quoted 16 lines · Bartosz Golaszewski
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. Thedavinci_emacpatches 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.
Quoted 8 lines
Quoted 5 lines
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
Quoted 4 lines
Thanks,
Sekhar
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
Quoted 28 lines · Srinivas Kandagatla
Quoted 25 lines · Sekhar Nori
Quoted 22 lines · Bartosz Golaszewski
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. Thedavinci_emacpatches 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.
Quoted 8 lines
Quoted 2 lines
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
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
Quoted 36 lines · Sekhar Nori
Quoted 35 lines · Srinivas Kandagatla
Quoted 19 lines · Sekhar Nori
Quoted 17 lines · Bartosz Golaszewski
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. Thedavinci_emacpatches 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.
Quoted 8 lines
Quoted 5 lines
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?
Quoted 6 lines
Quoted 1 line
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 :)
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
Quoted 37 lines · Greg Kroah-Hartman
Quoted 36 lines · Sekhar Nori
Quoted 35 lines · Srinivas Kandagatla
Quoted 19 lines · Sekhar Nori
Quoted 17 lines · Bartosz Golaszewski
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. Thedavinci_emacpatches 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.
Quoted 8 lines
Quoted 5 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
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
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
In reply to Srinivas KandagatlaQuoted 28 lines · Srinivas Kandagatla
Quoted 25 lines · Sekhar Nori
Quoted 22 lines · Bartosz Golaszewski
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. Thedavinci_emacpatches 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.
Quoted 5 lines
Quoted 2 lines
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
Quoted 8 lines
Let me know.
--srini
Quoted 4 lines
Thanks,
Sekhar
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
Quoted 9 lines · Sekhar Nori
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
PATCH v4 9/18 ARM: davinci: da850-evm: remove dead MTD code
In reply to Bartosz GolaszewskiFrom: 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 address.
--- arch/arm/mach-davinci/board-da850-evm.c | 28 ------------------------- 1 file changed, 28 deletions(-)
arch/arm/mach-davinci/board-da850-evm.c +0 -28
@@ -124,32 +124,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" ,
@@ -1455,8 +1429,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.17.1
Re: [PATCH v4 09/18] ARM: davinci: da850-evm: remove dead MTD code
Quoted 4 lines · 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 address.
I think you mean "it's now being done in the emac _driver_"
Re: [PATCH v4 09/18] ARM: davinci: da850-evm: remove dead MTD code
2018-06-29 19:09 GMT+02:00 David Lechner <[email protected]>:
Quoted 9 lines · Bartosz Golaszewski
Quoted 5 lines
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 address.
I think you mean "it's now being done in the emac _driver_"
Haha yes I do. :)
Thanks,
Bart
PATCH v4 10/18 net: davinci_emac: use nvmem to retrieve the mac address
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
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.
--- drivers/net/ethernet/ti/davinci_emac.c | 35 +++++++++++++++++++------- 1 file changed, 26 insertions(+), 9 deletions(-)
drivers/net/ethernet/ti/davinci_emac.c +26 -9
@@ -68,6 +68,8 @@#include <linux/of_net.h> #include <linux/mfd/syscon.h> #include <linux/mtd/mtd.h> +#include <linux/nvmem-consumer.h> +#include <linux/nvmem-consumer.h> #include <asm/irq.h> #include <asm/page.h>
@@ -1696,7 +1698,6 @@ davinci_emac_of_get_pdata(struct platform_device *pdev, struct emac_priv *priv)const struct of_device_id *match;const struct emac_platform_data *auxdata;struct emac_platform_data *pdata =NULL ; -const u8 *mac_addr;if (!IS_ENABLED (CONFIG_OF ) || !pdev->dev.of_node)return dev_get_platdata (&pdev->dev);
@@ -1708,12 +1709,6 @@ davinci_emac_of_get_pdata(struct platform_device *pdev, struct emac_priv *priv) np = pdev->dev.of_node; pdata->version =EMAC_VERSION_2 ; -if (!is_valid_ether_addr (pdata->mac_addr)) { - mac_addr =of_get_mac_address (np); -if (mac_addr) -ether_addr_copy (pdata->mac_addr, mac_addr); - } -of_property_read_u32 (np,"ti,davinci-ctrl-reg-offset" , &pdata->ctrl_reg_offset);
@@ -1783,10 +1778,12 @@ static int davinci_emac_probe(struct platform_device *pdev)struct cpdma_params dma_params;struct clk *emac_clk;unsigned long emac_bus_frequency; -#ifdef CONFIG_MTD +const void *mac_addr;size_t mac_addr_len; +#ifdef CONFIG_MTD struct mtd_info *mtd;#endif /* CONFIG_MTD */ +struct nvmem_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 ; + }else 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;
Signature · 1 line
2.17.1
PATCH v4 11/18 ARM: davinci: mityomapl138: don't read the MAC address from machine code
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
This is now done by the emac driver using a registered nvmem cell.
--- arch/arm/mach-davinci/board-mityomapl138.c | 8 -------- 1 file changed, 8 deletions(-)
arch/arm/mach-davinci/board-mityomapl138.c +0 -8
@@ -120,7 +120,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" );
@@ -146,13 +145,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.17.1
PATCH v4 12/18 ARM: davinci: dm365-evm: use device properties for at24 eeprom
In reply to Bartosz GolaszewskiFrom: 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.
--- 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
@@ -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>
@@ -179,18 +179,15 @@ static struct nvmem_cell_lookup dm365evm_mac_address_cell = { .nvmem_name = "1-00500", }; -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.17.1
PATCH v4 13/18 ARM: davinci: da830-evm: use device properties for at24 eeprom
In reply to Bartosz GolaszewskiFrom: 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.
--- 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
@@ -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>
@@ -419,12 +419,9 @@ static struct nvmem_cell_lookup da830_evm_mac_address_cell = { .nvmem_name = "1-00500", }; -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,
@@ -458,7 +455,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.17.1
PATCH v4 14/18 ARM: davinci: dm644x-evm: use device properties for at24 eeprom
In reply to Bartosz GolaszewskiFrom: 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.
--- arch/arm/mach-davinci/board-dm644x-evm.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-)
arch/arm/mach-davinci/board-dm644x-evm.c +4 -8
@@ -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>
@@ -486,12 +486,8 @@ static struct nvmem_cell_lookup dm6446evm_mac_address_cell = { .nvmem_name = "1-00500", }; -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 ), };/*
@@ -601,7 +597,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.17.1
PATCH v4 15/18 ARM: davinci: dm646x-evm: use device properties for at24 eeprom
In reply to Bartosz GolaszewskiFrom: 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.
--- 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
@@ -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 <media/i2c/tvp514x.h>
@@ -320,12 +320,9 @@ static struct nvmem_cell_lookup dm646x_evm_mac_address_cell = { .nvmem_name = "1-00500", }; -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
@@ -396,7 +393,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.17.1
PATCH v4 16/18 ARM: davinci: sffsdr: fix the at24 eeprom device name
In reply to Bartosz GolaszewskiFrom: 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.
--- arch/arm/mach-davinci/board-sffsdr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/mach-davinci/board-sffsdr.c +1 -1
@@ -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.17.1
PATCH v4 17/18 ARM: davinci: sffsdr: use device properties for at24 eeprom
In reply to Bartosz GolaszewskiFrom: 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.
--- arch/arm/mach-davinci/board-sffsdr.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-)
arch/arm/mach-davinci/board-sffsdr.c +5 -6
@@ -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.17.1
PATCH v4 18/18 ARM: davinci: remove dead code related to MAC address reading
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
There are no more users of davinci_get_mac_addr(). Remove it. Also remove the mac_addr field from the emac platform data struct.
--- arch/arm/mach-davinci/common.c | 15 --------------- include/linux/davinci_emac.h | 2 -- 2 files changed, 17 deletions(-)
arch/arm/mach-davinci/common.c +0 -15
@@ -28,21 +28,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 -2
@@ -19,7 +19,6 @@ struct mdio_platform_data { };struct emac_platform_data { -char mac_addr[ETH_ALEN ];u32 ctrl_reg_offset;u32 ctrl_mod_reg_offset;u32 ctrl_ram_offset;
@@ -46,5 +45,4 @@ enum { EMAC_VERSION_2, /* DM646x */ }; -void davinci_get_mac_addr (struct nvmem_device *nvmem,void *context);#endif
Signature · 1 line
2.17.1