From: Bartosz Golaszewski <redacted>
This is a follow-up to the previously rejected series[1] which partially
removed the at24_platform_data structure. After further development and
taking reviews into account, this series finally removes that struct
completely but not without touching many different parts of the code
base.
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, adds nvmem support to eth_platform_get_mac_address(),
converts davinci_emac driver to using it and replaces at24_platform_data
with device properties.
There's also one board (da850-evm) which uses MTD for reading the MAC
address. I used the patch from Alban Bedel's previous submission[2] to
add support for nvmem to the MTD framework. Since this user doesn't
need device tree, I dropped Alban's patches modifying the DT bindings.
We can add that later once an agreement is reached. For the time being
MTD devices are registered as nvmem devices and we're registering the
mac-address cell using the cell lookup mechanism.
This series adds a blocking notifier chain to the nvmem framework, so
that we can keep the EEPROM reading code in the mityomapl138 board file
with only slight modifications.
I also included some minor fixes to the modified code.
Tested on da850-evm & dm365-evm.
[1] https://lkml.org/lkml/2018/6/29/153
[2] https://lkml.org/lkml/2018/3/24/312
Alban Bedel (1):
mtd: Add support for reading MTD devices via the nvmem API
Bartosz Golaszewski (27):
nvmem: add support for cell lookups
Documentation: nvmem: document lookup entries
nvmem: add a notifier chain
nvmem: provide nvmem_device_name()
nvmem: remove the name field from struct nvmem_device
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
ARM: davinci: da850-evm: use nvmem lookup for mac address
ARM: davinci: da850-evm: remove unnecessary include
net: split eth_platform_get_mac_address() into subroutines
net: add support for nvmem to eth_platform_get_mac_address()
net: davinci_emac: use eth_platform_get_mac_address()
ARM: davinci: da850-evm: remove dead MTD code
ARM: davinci: mityomapl138: don't read the MAC address from machine
code
ARM: davinci: dm365-evm: use device properties for at24 eeprom
ARM: davinci: da830-evm: use device properties for at24 eeprom
ARM: davinci: dm644x-evm: use device properties for at24 eeprom
ARM: davinci: dm646x-evm: use device properties for at24 eeprom
ARM: davinci: sffsdr: fix the at24 eeprom device name
ARM: davinci: sffsdr: use device properties for at24 eeprom
ARM: davinci: remove dead code related to MAC address reading
ARM: davinci: mityomapl138: use nvmem notifiers
ARM: davinci: mityomapl138: use device properties for at24 eeprom
eeprom: at24: kill at24_platform_data
Documentation/nvmem/nvmem.txt | 28 +++++
MAINTAINERS | 1 -
arch/arm/mach-davinci/board-da830-evm.c | 25 ++--
arch/arm/mach-davinci/board-da850-evm.c | 45 +++-----
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 | 59 +++++++---
arch/arm/mach-davinci/board-sffsdr.c | 13 +--
arch/arm/mach-davinci/common.c | 15 ---
drivers/misc/eeprom/at24.c | 127 +++++++++------------
drivers/mtd/Kconfig | 1 +
drivers/mtd/mtdcore.c | 50 ++++++++
drivers/net/ethernet/ti/davinci_emac.c | 12 +-
drivers/nvmem/core.c | 106 ++++++++++++++++-
include/linux/davinci_emac.h | 2 -
include/linux/mtd/mtd.h | 2 +
include/linux/nvmem-consumer.h | 31 +++++
include/linux/nvmem-provider.h | 10 ++
include/linux/platform_data/at24.h | 60 ----------
net/ethernet/eth.c | 86 ++++++++++++--
21 files changed, 492 insertions(+), 255 deletions(-)
delete mode 100644 include/linux/platform_data/at24.h
--
2.18.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 +++++++++++++++
From: Bartosz Golaszewski <redacted>
Add a blocking notifier chain with two events (add and remove) so that
users can get notified about the addition of nvmem devices they're
waiting for.
We'll use this instead of the at24 setup callback in the mityomapl138
board file.
Signed-off-by: Bartosz Golaszewski <redacted>
---
drivers/nvmem/core.c | 20 ++++++++++++++++++++
include/linux/nvmem-consumer.h | 18 ++++++++++++++++++
2 files changed, 38 insertions(+)
From: Bartosz Golaszewski <redacted>
This field is never set and is only used in a single error message.
Remove the field and use nvmem_device_name() instead.
Signed-off-by: Bartosz Golaszewski <redacted>
---
drivers/nvmem/core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
From: Alban Bedel <albeu@free.fr>
Allow drivers that use the nvmem API to read data stored on MTD devices.
For this the mtd devices are registered as read-only NVMEM providers.
On OF systems only devices that have the 'nvmem-provider' property
are registered, on non-OF system all MTD devices are registered.
Signed-off-by: Alban Bedel <albeu@free.fr>
[Bartosz:
- use the managed variant of nvmem_register(),
- set the nvmem name]
Signed-off-by: Bartosz Golaszewski <redacted>
---
drivers/mtd/Kconfig | 1 +
drivers/mtd/mtdcore.c | 50 +++++++++++++++++++++++++++++++++++++++++
include/linux/mtd/mtd.h | 2 ++
3 files changed, 53 insertions(+)
@@ -488,6 +488,49 @@ int mtd_pairing_groups(struct mtd_info *mtd)}EXPORT_SYMBOL_GPL(mtd_pairing_groups);+staticintmtd_nvmem_reg_read(void*priv,unsignedintoffset,+void*val,size_tbytes)+{+structmtd_info*mtd=priv;+size_tretlen;+interr;++err=mtd_read(mtd,offset,bytes,&retlen,val);+if(err&&err!=-EUCLEAN)+returnerr;++returnretlen==bytes?0:-EIO;+}++staticintmtd_nvmem_add(structmtd_info*mtd)+{+structnvmem_configconfig={};++config.dev=&mtd->dev;+config.owner=THIS_MODULE;+config.name=mtd->name;+config.reg_read=mtd_nvmem_reg_read;+config.size=mtd->size;+config.word_size=1;+config.stride=1;+config.read_only=true;+config.root_only=true;+config.priv=mtd;++mtd->nvmem=devm_nvmem_register(&mtd->dev,&config);+if(IS_ERR(mtd->nvmem)){+/* Just ignore if there is no NVMEM support in the kernel */+if(PTR_ERR(mtd->nvmem)==-ENOSYS){+mtd->nvmem=NULL;+}else{+dev_err(&mtd->dev,"Failed to register NVMEM device\n");+returnPTR_ERR(mtd->nvmem);+}+}++return0;+}+staticstructdentry*dfs_dir_mtd;/**
@@ -570,6 +613,11 @@ int add_mtd_device(struct mtd_info *mtd)if(error)gotofail_added;+/* Add the nvmem provider */+error=mtd_nvmem_add(mtd);+if(error)+gotofail_nvmem_add;+if(!IS_ERR_OR_NULL(dfs_dir_mtd)){mtd->dbg.dfs_dir=debugfs_create_dir(dev_name(&mtd->dev),dfs_dir_mtd);if(IS_ERR_OR_NULL(mtd->dbg.dfs_dir)){
@@ -595,6 +643,8 @@ int add_mtd_device(struct mtd_info *mtd)__module_get(THIS_MODULE);return0;+fail_nvmem_add:+device_unregister(&mtd->dev);fail_added:of_node_put(mtd_get_of_node(mtd));idr_remove(&mtd_idr,i);
From: Bartosz Golaszewski <redacted>
The include file for at24_platform_data is not needed in this file.
Signed-off-by: Bartosz Golaszewski <redacted>
---
arch/arm/mach-davinci/board-da850-evm.c | 1 -
1 file changed, 1 deletion(-)
From: Bartosz Golaszewski <redacted>
We want do add more sources from which to read the MAC address. In
order to avoid bloating this function too much, start by splitting it
into subroutines, each of which takes care of reading the MAC from
one source.
Signed-off-by: Bartosz Golaszewski <redacted>
---
net/ethernet/eth.c | 48 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 37 insertions(+), 11 deletions(-)
From: Bartosz Golaszewski <redacted>
Many non-DT platforms read the MAC address from EEPROM. Usually it's
either done with callbacks defined in board files or from SoC-specific
ethernet drivers.
In order to generalize this, try to read the MAC from nvmem in
eth_platform_get_mac_address() using a standard lookup name:
"mac-address".
Signed-off-by: Bartosz Golaszewski <redacted>
---
net/ethernet/eth.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
From: Bartosz Golaszewski <redacted>
We now support nvmem in eth_platform_get_mac_address() and all boards
have the mac-address cells defined. Stop getting the MAC from pdata
and use the dedicated helper.
Signed-off-by: Bartosz Golaszewski <redacted>
---
drivers/net/ethernet/ti/davinci_emac.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
@@ -1819,8 +1812,11 @@ static int davinci_emac_probe(struct platform_device *pdev)gotoerr_free_netdev;}+rc=eth_platform_get_mac_address(&pdev->dev,priv->mac_addr);+if(rc==-EPROBE_DEFER)+return-EPROBE_DEFER;/* We'll get the MAC address later. */+/* MAC addr and PHY mask , RMII enable info from platform_data */-memcpy(priv->mac_addr,pdata->mac_addr,ETH_ALEN);priv->phy_id=pdata->phy_id;priv->rmii_en=pdata->rmii_en;priv->version=pdata->version;
From: Bartosz Golaszewski <redacted>
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the at24_platform_data structure and replace it with an array
of property entries. Drop the byte_len/size property, as the model name
already implies the EEPROM's size.
Signed-off-by: Bartosz Golaszewski <redacted>
---
arch/arm/mach-davinci/board-dm365-evm.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
From: Bartosz Golaszewski <redacted>
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the at24_platform_data structure and replace it with an array
of property entries. Drop the byte_len/size property, as the model name
already implies the EEPROM's size.
Signed-off-by: Bartosz Golaszewski <redacted>
---
arch/arm/mach-davinci/board-dm644x-evm.c | 12 ++++--------
1 file changed, 4 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(-)
@@ -116,10 +118,15 @@ static void mityomapl138_cpufreq_init(const char *partnum)staticvoidmityomapl138_cpufreq_init(constchar*partnum){}#endif-staticvoidread_factory_config(structnvmem_device*nvmem,void*context)+staticintread_factory_config(structnotifier_block*nb,+unsignedlongevent,void*data){intret;constchar*partnum=NULL;+structnvmem_device*nvmem=data;++if(strcmp(nvmem_device_name(nvmem),"1-00500")!=0)+returnNOTIFY_DONE;if(!IS_BUILTIN(CONFIG_NVMEM)){pr_warn("Factory Config not available without CONFIG_NVMEM\n");
@@ -151,8 +158,14 @@ static void read_factory_config(struct nvmem_device *nvmem, void *context)bad_config:/* default maximum speed is valid for all platforms */mityomapl138_cpufreq_init(partnum);++returnNOTIFY_STOP;}+staticstructnotifier_blockmityomapl138_nvmem_notifier={+.notifier_call=read_factory_config,+};+staticstructnvmem_cell_lookupmityomapl138_nvmem_cells[]={{.info={
From: Bartosz Golaszewski <redacted>
There are no more users of at24_platform_data. Remove the relevant
header and modify the driver code to not use it anymore.
Signed-off-by: Bartosz Golaszewski <redacted>
---
MAINTAINERS | 1 -
drivers/misc/eeprom/at24.c | 127 +++++++++++++----------------
include/linux/platform_data/at24.h | 60 --------------
3 files changed, 57 insertions(+), 131 deletions(-)
delete mode 100644 include/linux/platform_data/at24.h
@@ -22,10 +22,24 @@#include<linux/i2c.h>#include<linux/nvmem-provider.h>#include<linux/regmap.h>-#include<linux/platform_data/at24.h>#include<linux/pm_runtime.h>#include<linux/gpio/consumer.h>+/* Address pointer is 16 bit. */+#define AT24_FLAG_ADDR16 BIT(7)+/* sysfs-entry will be read-only. */+#define AT24_FLAG_READONLY BIT(6)+/* sysfs-entry will be world-readable. */+#define AT24_FLAG_IRUGO BIT(5)+/* Take always 8 addresses (24c00). */+#define AT24_FLAG_TAKE8ADDR BIT(4)+/* Factory-programmed serial number. */+#define AT24_FLAG_SERIAL BIT(3)+/* Factory-programmed mac address. */+#define AT24_FLAG_MAC BIT(2)+/* Does not auto-rollover reads to the next slave address. */+#define AT24_FLAG_NO_RDROL BIT(1)+/**I2CEEPROMsfrommostvendorsareinexpensiveandmostlyinterchangeable.*Differencesbetweendifferentvendorproductlines(likeAtmelAT24Cor
@@ -124,10 +138,6 @@ MODULE_PARM_DESC(at24_write_timeout, "Time (in ms) to try writes (default 25)");usleep_range(1000,1500),op_time=jiffies)structat24_chip_data{-/*-*thesefieldsmirrortheirequivalentsin-*structat24_platform_data-*/u32byte_len;u8flags;};
@@ -467,46 +477,11 @@ static int at24_write(void *priv, unsigned int off, void *val, size_t count)return0;}-staticvoidat24_properties_to_pdata(structdevice*dev,-structat24_platform_data*chip)-{-interr;-u32val;--if(device_property_present(dev,"read-only"))-chip->flags|=AT24_FLAG_READONLY;-if(device_property_present(dev,"no-read-rollover"))-chip->flags|=AT24_FLAG_NO_RDROL;--err=device_property_read_u32(dev,"size",&val);-if(!err)-chip->byte_len=val;--err=device_property_read_u32(dev,"pagesize",&val);-if(!err){-chip->page_size=val;-}else{-/*-*Thisisslow,butwecan'tknowalleeproms,sowebetter-*playsafe.Specifyingcustomeeprom-typesviaplatform_data-*isrecommendedanyhow.-*/-chip->page_size=1;-}-}--staticintat24_get_pdata(structdevice*dev,structat24_platform_data*pdata)+staticconststructat24_chip_data*at24_get_chip_data(structdevice*dev){structdevice_node*of_node=dev->of_node;conststructat24_chip_data*cdata;conststructi2c_device_id*id;-structat24_platform_data*pd;--pd=dev_get_platdata(dev);-if(pd){-memcpy(pdata,pd,sizeof(*pdata));-return0;-}id=i2c_match_id(at24_ids,to_i2c_client(dev));
@@ -598,8 +569,9 @@ static int at24_probe(struct i2c_client *client){structregmap_configregmap_config={};structnvmem_confignvmem_config={};-structat24_platform_datapdata={};+conststructat24_chip_data*cdata;structdevice*dev=&client->dev;+u32byte_len,page_size,flags;booli2c_fn_i2c,i2c_fn_block;unsignedinti,num_addresses;structat24_data*at24;
@@ -613,35 +585,54 @@ static int at24_probe(struct i2c_client *client)i2c_fn_block=i2c_check_functionality(client->adapter,I2C_FUNC_SMBUS_WRITE_I2C_BLOCK);-err=at24_get_pdata(dev,&pdata);+cdata=at24_get_chip_data(dev);+if(IS_ERR(cdata))+returnPTR_ERR(cdata);++err=device_property_read_u32(dev,"pagesize",&page_size);+if(err)+/*+*Thisisslow,butwecan'tknowalleeproms,sowebetter+*playsafe.Specifyingcustomeeprom-typesviaplatform_data+*isrecommendedanyhow.+*/+page_size=1;++flags=cdata->flags;+if(device_property_present(dev,"read-only"))+flags|=AT24_FLAG_READONLY;+if(device_property_present(dev,"no-read-rollover"))+flags|=AT24_FLAG_NO_RDROL;++err=device_property_read_u32(dev,"size",&byte_len);if(err)-returnerr;+byte_len=cdata->byte_len;if(!i2c_fn_i2c&&!i2c_fn_block)-pdata.page_size=1;+page_size=1;-if(!pdata.page_size){+if(!page_size){dev_err(dev,"page_size must not be 0!\n");return-EINVAL;}-if(!is_power_of_2(pdata.page_size))+if(!is_power_of_2(page_size))dev_warn(dev,"page_size looks suspicious (no power of 2)!\n");-if(pdata.flags&AT24_FLAG_TAKE8ADDR)+if(flags&AT24_FLAG_TAKE8ADDR)num_addresses=8;else-num_addresses=DIV_ROUND_UP(pdata.byte_len,-(pdata.flags&AT24_FLAG_ADDR16)?65536:256);+num_addresses=DIV_ROUND_UP(byte_len,+(flags&AT24_FLAG_ADDR16)?65536:256);-if((pdata.flags&AT24_FLAG_SERIAL)&&(pdata.flags&AT24_FLAG_MAC)){+if((flags&AT24_FLAG_SERIAL)&&(flags&AT24_FLAG_MAC)){dev_err(dev,"invalid device data - cannot have both AT24_FLAG_SERIAL & AT24_FLAG_MAC.");return-EINVAL;}regmap_config.val_bits=8;-regmap_config.reg_bits=(pdata.flags&AT24_FLAG_ADDR16)?16:8;+regmap_config.reg_bits=(flags&AT24_FLAG_ADDR16)?16:8;regmap_config.disable_locking=true;regmap=devm_regmap_init_i2c(client,®map_config);
@@ -654,11 +645,11 @@ static int at24_probe(struct i2c_client *client)return-ENOMEM;mutex_init(&at24->lock);-at24->byte_len=pdata.byte_len;-at24->page_size=pdata.page_size;-at24->flags=pdata.flags;+at24->byte_len=byte_len;+at24->page_size=page_size;+at24->flags=flags;at24->num_addresses=num_addresses;-at24->offset_adj=at24_get_offset_adj(pdata.flags,pdata.byte_len);+at24->offset_adj=at24_get_offset_adj(flags,byte_len);at24->client[0].client=client;at24->client[0].regmap=regmap;
@@ -666,10 +657,10 @@ static int at24_probe(struct i2c_client *client)if(IS_ERR(at24->wp_gpio))returnPTR_ERR(at24->wp_gpio);-writable=!(pdata.flags&AT24_FLAG_READONLY);+writable=!(flags&AT24_FLAG_READONLY);if(writable){at24->write_max=min_t(unsignedint,-pdata.page_size,at24_io_limit);+page_size,at24_io_limit);if(!i2c_fn_i2c&&at24->write_max>I2C_SMBUS_BLOCK_MAX)at24->write_max=I2C_SMBUS_BLOCK_MAX;}
@@ -712,7 +703,7 @@ static int at24_probe(struct i2c_client *client)nvmem_config.priv=at24;nvmem_config.stride=1;nvmem_config.word_size=1;-nvmem_config.size=pdata.byte_len;+nvmem_config.size=byte_len;at24->nvmem=devm_nvmem_register(dev,&nvmem_config);if(IS_ERR(at24->nvmem)){
@@ -721,13 +712,9 @@ static int at24_probe(struct i2c_client *client)}dev_info(dev,"%u byte %s EEPROM, %s, %u bytes/write\n",-pdata.byte_len,client->name,+byte_len,client->name,writable?"writable":"read-only",at24->write_max);-/* export data to kernel code */-if(pdata.setup)-pdata.setup(at24->nvmem,pdata.context);-return0;err_clients:
@@ -1,60 +0,0 @@-/*- * at24.h - platform_data for the at24 (generic eeprom) driver- * (C) Copyright 2008 by Pengutronix- * (C) Copyright 2012 by Wolfram Sang- * same license as the driver- */--#ifndef _LINUX_AT24_H-#define _LINUX_AT24_H--#include <linux/types.h>-#include <linux/nvmem-consumer.h>-#include <linux/bitops.h>--/**- * struct at24_platform_data - data to set up at24 (generic eeprom) driver- * @byte_len: size of eeprom in byte- * @page_size: number of byte which can be written in one go- * @flags: tunable options, check AT24_FLAG_* defines- * @setup: an optional callback invoked after eeprom is probed; enables kernel- code to access eeprom via nvmem, see example- * @context: optional parameter passed to setup()- *- * If you set up a custom eeprom type, please double-check the parameters.- * Especially page_size needs extra care, as you risk data loss if your value- * is bigger than what the chip actually supports!- *- * An example in pseudo code for a setup() callback:- *- * void get_mac_addr(struct nvmem_device *nvmem, void *context)- * {- * u8 *mac_addr = ethernet_pdata->mac_addr;- * off_t offset = context;- *- * // Read MAC addr from EEPROM- * if (nvmem_device_read(nvmem, offset, ETH_ALEN, mac_addr) == ETH_ALEN)- * pr_info("Read MAC addr from EEPROM: %pM\n", mac_addr);- * }- *- * This function pointer and context can now be set up in at24_platform_data.- */--struct at24_platform_data {- u32 byte_len; /* size (sum of all addr) */- u16 page_size; /* for writes */- u8 flags;-#define AT24_FLAG_ADDR16 BIT(7) /* address pointer is 16 bit */-#define AT24_FLAG_READONLY BIT(6) /* sysfs-entry will be read-only */-#define AT24_FLAG_IRUGO BIT(5) /* sysfs-entry will be world-readable */-#define AT24_FLAG_TAKE8ADDR BIT(4) /* take always 8 addresses (24c00) */-#define AT24_FLAG_SERIAL BIT(3) /* factory-programmed serial number */-#define AT24_FLAG_MAC BIT(2) /* factory-programmed mac address */-#define AT24_FLAG_NO_RDROL BIT(1) /* does not auto-rollover reads to */- /* the next slave address */-- void (*setup)(struct nvmem_device *nvmem, void *context);- void *context;-};--#endif /* _LINUX_AT24_H */
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-mityomapl138.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
From: Bartosz Golaszewski <redacted>
There are no more users of davinci_get_mac_addr(). Remove it. Also
remove the mac_addr field from the emac platform data struct.
Signed-off-by: Bartosz Golaszewski <redacted>
---
arch/arm/mach-davinci/common.c | 15 ---------------
include/linux/davinci_emac.h | 2 --
2 files changed, 17 deletions(-)
@@ -28,21 +28,6 @@ EXPORT_SYMBOL(davinci_soc_info);void__iomem*davinci_intc_base;intdavinci_intc_type;-voiddavinci_get_mac_addr(structnvmem_device*nvmem,void*context)-{-char*mac_addr=davinci_soc_info.emac_pdata->mac_addr;-off_toffset=(off_t)context;--if(!IS_BUILTIN(CONFIG_NVMEM)){-pr_warn("Cannot read MAC addr from EEPROM without CONFIG_NVMEM\n");-return;-}--/* Read MAC addr from EEPROM */-if(nvmem_device_read(nvmem,offset,ETH_ALEN,mac_addr)==ETH_ALEN)-pr_info("Read MAC addr from EEPROM: %pM\n",mac_addr);-}-staticint__initdavinci_init_id(structdavinci_soc_info*soc_info){inti;
From: Bartosz Golaszewski <redacted>
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-dm646x-evm.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
From: Bartosz Golaszewski <redacted>
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the at24_platform_data structure and replace it with an array
of property entries. Drop the byte_len/size property, as the model name
already implies the EEPROM's size.
Signed-off-by: Bartosz Golaszewski <redacted>
---
arch/arm/mach-davinci/board-da830-evm.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
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 driver.
Signed-off-by: Bartosz Golaszewski <redacted>
---
arch/arm/mach-davinci/board-da850-evm.c | 28 -------------------------
1 file changed, 28 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);
--
2.18.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
From: Bartosz Golaszewski <redacted>
Kernel users don't have any means of checking the names of nvmem
devices. Add a routine that returns the name of the nvmem provider.
This will be useful for nvmem notifier subscribers - otherwise they
can't check what device is being added/removed.
Signed-off-by: Bartosz Golaszewski <redacted>
---
drivers/nvmem/core.c | 6 ++++++
include/linux/nvmem-consumer.h | 7 +++++++
2 files changed, 13 insertions(+)
@@ -69,6 +69,8 @@ int nvmem_device_cell_write(struct nvmem_device *nvmem,intnvmem_register_notifier(structnotifier_block*nb);intnvmem_unregister_notifier(structnotifier_block*nb);++constchar*nvmem_device_name(structnvmem_device*nvmem);#elsestaticinlinestructnvmem_cell*nvmem_cell_get(structdevice*dev,
@@ -167,6 +169,11 @@ static inline int int nvmem_unregister_notifier(struct notifier_block *nb){return-ENOSYS;}++staticinlineconstchar*nvmem_device_name(structnvmem_device*nvmem)+{+returnERR_PTR(-ENOSYS);+}#endif /* CONFIG_NVMEM */#if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
--
2.18.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
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>
Acked-by: Srinivas Kandagatla <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: Wolfram Sang <hidden> Date: 2018-08-08 15:55:57
On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski <redacted>
This is a follow-up to the previously rejected series[1] which partially
removed the at24_platform_data structure. After further development and
taking reviews into account, this series finally removes that struct
completely but not without touching many different parts of the code
base.
Since I took over maintainership of the at24 driver I've been working
towards removing at24_platform_data in favor for device properties.
Wooha, nice work. I can't really comment on it but wondered how you want
to upstream it (after reviews)? Pull request of an immutable branch for
nvmem-tree sounds best to me. Then I could also pull it in if i2c needs
it. Probably same situation for arm-soc...
From: Andrew Lunn <andrew@lunn.ch> Date: 2018-08-08 16:15:42
On Wed, Aug 08, 2018 at 05:31:25PM +0200, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski <redacted>
Add a blocking notifier chain with two events (add and remove) so that
users can get notified about the addition of nvmem devices they're
waiting for.
We'll use this instead of the at24 setup callback in the mityomapl138
board file.
Hi Bartosz
What context is this notifier chain called in?
I did something similar using the i2c notifier to try to work around
the impending disappearing of the setup callback. But i got lockdep
splats, because the notifier was called while some locks were being
held, so it was not possible to register other i2c devices.
The at24 setup callback is done as part of probe, so no important
locks are held. Are any locks held when this notifier chain is called?
Thanks
Andrew
From: Andrew Lunn <andrew@lunn.ch> Date: 2018-08-08 16:22:03
On Wed, Aug 08, 2018 at 05:31:28PM +0200, Bartosz Golaszewski wrote:
quoted hunk
From: Alban Bedel <albeu@free.fr>
Allow drivers that use the nvmem API to read data stored on MTD devices.
For this the mtd devices are registered as read-only NVMEM providers.
On OF systems only devices that have the 'nvmem-provider' property
are registered, on non-OF system all MTD devices are registered.
@@ -570,6 +613,11 @@ int add_mtd_device(struct mtd_info *mtd) if (error) goto fail_added;+ /* Add the nvmem provider */+ error = mtd_nvmem_add(mtd);+ if (error)+ goto fail_nvmem_add;+
Hi Bartosz
Maybe it is hiding somewhere, but i don't see any code looking into
device tree looking for the 'nvmem-provider' property.
Andrew
2018-08-08 18:20 GMT+02:00 Andrew Lunn [off-list ref]:
On Wed, Aug 08, 2018 at 05:31:28PM +0200, Bartosz Golaszewski wrote:
quoted
From: Alban Bedel <albeu@free.fr>
Allow drivers that use the nvmem API to read data stored on MTD devices.
For this the mtd devices are registered as read-only NVMEM providers.
On OF systems only devices that have the 'nvmem-provider' property
are registered, on non-OF system all MTD devices are registered.
@@ -570,6 +613,11 @@ int add_mtd_device(struct mtd_info *mtd) if (error) goto fail_added;+ /* Add the nvmem provider */+ error = mtd_nvmem_add(mtd);+ if (error)+ goto fail_nvmem_add;+
Hi Bartosz
Maybe it is hiding somewhere, but i don't see any code looking into
device tree looking for the 'nvmem-provider' property.
Andrew
Ugh, I copied the commit message from Alban's patch. For the moment
there's no such thing, you're right. I'll fix it for v2.
Bart
2018-08-08 17:55 GMT+02:00 Wolfram Sang [off-list ref]:
On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote:
quoted
From: Bartosz Golaszewski <redacted>
This is a follow-up to the previously rejected series[1] which partially
removed the at24_platform_data structure. After further development and
taking reviews into account, this series finally removes that struct
completely but not without touching many different parts of the code
base.
Since I took over maintainership of the at24 driver I've been working
towards removing at24_platform_data in favor for device properties.
Wooha, nice work. I can't really comment on it but wondered how you want
to upstream it (after reviews)? Pull request of an immutable branch for
nvmem-tree sounds best to me. Then I could also pull it in if i2c needs
it. Probably same situation for arm-soc...
I initially wanted to merge small parts of it starting with v4.18, but
there were some voices against merging APIs without users. I'm not
sure how it should go in. There'll be a need for multiple immutable
branches most probably...
Bart
2018-08-08 18:13 GMT+02:00 Andrew Lunn [off-list ref]:
On Wed, Aug 08, 2018 at 05:31:25PM +0200, Bartosz Golaszewski wrote:
quoted
From: Bartosz Golaszewski <redacted>
Add a blocking notifier chain with two events (add and remove) so that
users can get notified about the addition of nvmem devices they're
waiting for.
We'll use this instead of the at24 setup callback in the mityomapl138
board file.
Hi Bartosz
What context is this notifier chain called in?
I did something similar using the i2c notifier to try to work around
the impending disappearing of the setup callback. But i got lockdep
splats, because the notifier was called while some locks were being
held, so it was not possible to register other i2c devices.
The at24 setup callback is done as part of probe, so no important
locks are held. Are any locks held when this notifier chain is called?
Thanks
Andrew
In the case of at24 it would be called from at24_probe() ->
nvmem_register() in process context. Would you mind testing it? Would
be great to see if it works on multiple setups.
Bart
From: Andrew Lunn <andrew@lunn.ch> Date: 2018-08-08 16:44:45
On Wed, Aug 08, 2018 at 06:27:25PM +0200, Bartosz Golaszewski wrote:
2018-08-08 17:55 GMT+02:00 Wolfram Sang [off-list ref]:
quoted
On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote:
quoted
From: Bartosz Golaszewski <redacted>
This is a follow-up to the previously rejected series[1] which partially
removed the at24_platform_data structure. After further development and
taking reviews into account, this series finally removes that struct
completely but not without touching many different parts of the code
base.
Since I took over maintainership of the at24 driver I've been working
towards removing at24_platform_data in favor for device properties.
Wooha, nice work. I can't really comment on it but wondered how you want
to upstream it (after reviews)? Pull request of an immutable branch for
nvmem-tree sounds best to me. Then I could also pull it in if i2c needs
it. Probably same situation for arm-soc...
I initially wanted to merge small parts of it starting with v4.18, but
there were some voices against merging APIs without users. I'm not
sure how it should go in. There'll be a need for multiple immutable
branches most probably...
Hi Bartosz
What this series does is show all the different parts are now
available, and can be reviewed as a whole. Once that review is
completed, merging in parts then becomes possible.
It looks like you could probably merge the nvmem, mtd and net parts
independently via there maintainers for 4.20, since i don't think
there are any dependencies. The arm-soc changes in 4.21, and the
removal of the platform data in 4.22?
Andrew
2018-08-08 18:44 GMT+02:00 Andrew Lunn [off-list ref]:
On Wed, Aug 08, 2018 at 06:27:25PM +0200, Bartosz Golaszewski wrote:
quoted
2018-08-08 17:55 GMT+02:00 Wolfram Sang [off-list ref]:
quoted
On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote:
quoted
From: Bartosz Golaszewski <redacted>
This is a follow-up to the previously rejected series[1] which partially
removed the at24_platform_data structure. After further development and
taking reviews into account, this series finally removes that struct
completely but not without touching many different parts of the code
base.
Since I took over maintainership of the at24 driver I've been working
towards removing at24_platform_data in favor for device properties.
Wooha, nice work. I can't really comment on it but wondered how you want
to upstream it (after reviews)? Pull request of an immutable branch for
nvmem-tree sounds best to me. Then I could also pull it in if i2c needs
it. Probably same situation for arm-soc...
I initially wanted to merge small parts of it starting with v4.18, but
there were some voices against merging APIs without users. I'm not
sure how it should go in. There'll be a need for multiple immutable
branches most probably...
Hi Bartosz
What this series does is show all the different parts are now
available, and can be reviewed as a whole. Once that review is
completed, merging in parts then becomes possible.
It looks like you could probably merge the nvmem, mtd and net parts
independently via there maintainers for 4.20, since i don't think
there are any dependencies. The arm-soc changes in 4.21, and the
removal of the platform data in 4.22?
Andrew
We need the first batch of SoC changes for the net part and then the
second batch depends on those net changes. Also: dragging the merge
for this over a year is a bit overkill.
Sekhar: I know you're usually provided with immutable branches from
framework maintainers for the SoC changes - is it ok for you to
provide the net maintainers with an immutable branch after applying
the first part of davinci board file changes?
Bart
From: Andy Shevchenko <hidden> Date: 2018-08-08 17:42:46
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski [off-list ref] wrote:
From: Bartosz Golaszewski <redacted>
Kernel users don't have any means of checking the names of nvmem
devices. Add a routine that returns the name of the nvmem provider.
This will be useful for nvmem notifier subscribers - otherwise they
can't check what device is being added/removed.
Just wondering if *_dev_name() is more common pattern in the kernel
(at least pci_dev_name() comes immediately to mind).
--
With Best Regards,
Andy Shevchenko
From: Andy Shevchenko <hidden> Date: 2018-08-08 17:51:02
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski [off-list ref] wrote:
From: Bartosz Golaszewski <redacted>
We want do add more sources from which to read the MAC address. In
order to avoid bloating this function too much, start by splitting it
into subroutines, each of which takes care of reading the MAC from
one source.
From: Andy Shevchenko <hidden> Date: 2018-08-08 17:54:12
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski [off-list ref] wrote:
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.
Yes, that exactly how device properties should be used instead of
legacy platform data!
Reviewed-by: Andy Shevchenko <redacted>
From: Andy Shevchenko <hidden> Date: 2018-08-08 17:55:23
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski [off-list ref] wrote:
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.
From: Andy Shevchenko <hidden> Date: 2018-08-08 17:55:50
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski [off-list ref] wrote:
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.
2.18.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Andy Shevchenko <hidden> Date: 2018-08-08 17:56:16
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski [off-list ref] wrote:
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.
From: Andy Shevchenko <hidden> Date: 2018-08-08 17:57:07
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski [off-list ref] wrote:
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.
From: Andy Shevchenko <hidden> Date: 2018-08-08 17:58:09
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski [off-list ref] wrote:
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.
2.18.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Andy Shevchenko <hidden> Date: 2018-08-08 17:59:29
On Wed, Aug 8, 2018 at 8:55 PM, Andy Shevchenko
[off-list ref] wrote:
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski [off-list ref] wrote:
quoted
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.
2.18.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Andy Shevchenko <hidden> Date: 2018-08-08 18:00:11
On Wed, Aug 8, 2018 at 8:57 PM, Andy Shevchenko
[off-list ref] wrote:
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski [off-list ref] wrote:
quoted
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.
From: Andy Shevchenko <hidden> Date: 2018-08-08 18:00:39
On Wed, Aug 8, 2018 at 8:58 PM, Andy Shevchenko
[off-list ref] wrote:
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski [off-list ref] wrote:
quoted
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.
2.18.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Andy Shevchenko <hidden> Date: 2018-08-08 18:03:38
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski [off-list ref] wrote:
From: Bartosz Golaszewski <redacted>
There are no more users of at24_platform_data. Remove the relevant
header and modify the driver code to not use it anymore.
Reviewed-by: Andy Shevchenko <redacted>
If you want me to test this on Intel Galileo Gen 2 board, give me a
public tree from where I can pull.
Thanks.
@@ -22,10 +22,24 @@#include<linux/i2c.h>#include<linux/nvmem-provider.h>#include<linux/regmap.h>-#include<linux/platform_data/at24.h>#include<linux/pm_runtime.h>#include<linux/gpio/consumer.h>+/* Address pointer is 16 bit. */+#define AT24_FLAG_ADDR16 BIT(7)+/* sysfs-entry will be read-only. */+#define AT24_FLAG_READONLY BIT(6)+/* sysfs-entry will be world-readable. */+#define AT24_FLAG_IRUGO BIT(5)+/* Take always 8 addresses (24c00). */+#define AT24_FLAG_TAKE8ADDR BIT(4)+/* Factory-programmed serial number. */+#define AT24_FLAG_SERIAL BIT(3)+/* Factory-programmed mac address. */+#define AT24_FLAG_MAC BIT(2)+/* Does not auto-rollover reads to the next slave address. */+#define AT24_FLAG_NO_RDROL BIT(1)+/**I2CEEPROMsfrommostvendorsareinexpensiveandmostlyinterchangeable.*Differencesbetweendifferentvendorproductlines(likeAtmelAT24Cor
@@ -124,10 +138,6 @@ MODULE_PARM_DESC(at24_write_timeout, "Time (in ms) to try writes (default 25)");usleep_range(1000,1500),op_time=jiffies)structat24_chip_data{-/*-*thesefieldsmirrortheirequivalentsin-*structat24_platform_data-*/u32byte_len;u8flags;};
@@ -467,46 +477,11 @@ static int at24_write(void *priv, unsigned int off, void *val, size_t count)return0;}-staticvoidat24_properties_to_pdata(structdevice*dev,-structat24_platform_data*chip)-{-interr;-u32val;--if(device_property_present(dev,"read-only"))-chip->flags|=AT24_FLAG_READONLY;-if(device_property_present(dev,"no-read-rollover"))-chip->flags|=AT24_FLAG_NO_RDROL;--err=device_property_read_u32(dev,"size",&val);-if(!err)-chip->byte_len=val;--err=device_property_read_u32(dev,"pagesize",&val);-if(!err){-chip->page_size=val;-}else{-/*-*Thisisslow,butwecan'tknowalleeproms,sowebetter-*playsafe.Specifyingcustomeeprom-typesviaplatform_data-*isrecommendedanyhow.-*/-chip->page_size=1;-}-}--staticintat24_get_pdata(structdevice*dev,structat24_platform_data*pdata)+staticconststructat24_chip_data*at24_get_chip_data(structdevice*dev){structdevice_node*of_node=dev->of_node;conststructat24_chip_data*cdata;conststructi2c_device_id*id;-structat24_platform_data*pd;--pd=dev_get_platdata(dev);-if(pd){-memcpy(pdata,pd,sizeof(*pdata));-return0;-}id=i2c_match_id(at24_ids,to_i2c_client(dev));
@@ -598,8 +569,9 @@ static int at24_probe(struct i2c_client *client){structregmap_configregmap_config={};structnvmem_confignvmem_config={};-structat24_platform_datapdata={};+conststructat24_chip_data*cdata;structdevice*dev=&client->dev;+u32byte_len,page_size,flags;booli2c_fn_i2c,i2c_fn_block;unsignedinti,num_addresses;structat24_data*at24;
@@ -613,35 +585,54 @@ static int at24_probe(struct i2c_client *client)i2c_fn_block=i2c_check_functionality(client->adapter,I2C_FUNC_SMBUS_WRITE_I2C_BLOCK);-err=at24_get_pdata(dev,&pdata);+cdata=at24_get_chip_data(dev);+if(IS_ERR(cdata))+returnPTR_ERR(cdata);++err=device_property_read_u32(dev,"pagesize",&page_size);+if(err)+/*+*Thisisslow,butwecan'tknowalleeproms,sowebetter+*playsafe.Specifyingcustomeeprom-typesviaplatform_data+*isrecommendedanyhow.+*/+page_size=1;++flags=cdata->flags;+if(device_property_present(dev,"read-only"))+flags|=AT24_FLAG_READONLY;+if(device_property_present(dev,"no-read-rollover"))+flags|=AT24_FLAG_NO_RDROL;++err=device_property_read_u32(dev,"size",&byte_len);if(err)-returnerr;+byte_len=cdata->byte_len;if(!i2c_fn_i2c&&!i2c_fn_block)-pdata.page_size=1;+page_size=1;-if(!pdata.page_size){+if(!page_size){dev_err(dev,"page_size must not be 0!\n");return-EINVAL;}-if(!is_power_of_2(pdata.page_size))+if(!is_power_of_2(page_size))dev_warn(dev,"page_size looks suspicious (no power of 2)!\n");-if(pdata.flags&AT24_FLAG_TAKE8ADDR)+if(flags&AT24_FLAG_TAKE8ADDR)num_addresses=8;else-num_addresses=DIV_ROUND_UP(pdata.byte_len,-(pdata.flags&AT24_FLAG_ADDR16)?65536:256);+num_addresses=DIV_ROUND_UP(byte_len,+(flags&AT24_FLAG_ADDR16)?65536:256);-if((pdata.flags&AT24_FLAG_SERIAL)&&(pdata.flags&AT24_FLAG_MAC)){+if((flags&AT24_FLAG_SERIAL)&&(flags&AT24_FLAG_MAC)){dev_err(dev,"invalid device data - cannot have both AT24_FLAG_SERIAL & AT24_FLAG_MAC.");return-EINVAL;}regmap_config.val_bits=8;-regmap_config.reg_bits=(pdata.flags&AT24_FLAG_ADDR16)?16:8;+regmap_config.reg_bits=(flags&AT24_FLAG_ADDR16)?16:8;regmap_config.disable_locking=true;regmap=devm_regmap_init_i2c(client,®map_config);
@@ -654,11 +645,11 @@ static int at24_probe(struct i2c_client *client)return-ENOMEM;mutex_init(&at24->lock);-at24->byte_len=pdata.byte_len;-at24->page_size=pdata.page_size;-at24->flags=pdata.flags;+at24->byte_len=byte_len;+at24->page_size=page_size;+at24->flags=flags;at24->num_addresses=num_addresses;-at24->offset_adj=at24_get_offset_adj(pdata.flags,pdata.byte_len);+at24->offset_adj=at24_get_offset_adj(flags,byte_len);at24->client[0].client=client;at24->client[0].regmap=regmap;
@@ -666,10 +657,10 @@ static int at24_probe(struct i2c_client *client)if(IS_ERR(at24->wp_gpio))returnPTR_ERR(at24->wp_gpio);-writable=!(pdata.flags&AT24_FLAG_READONLY);+writable=!(flags&AT24_FLAG_READONLY);if(writable){at24->write_max=min_t(unsignedint,-pdata.page_size,at24_io_limit);+page_size,at24_io_limit);if(!i2c_fn_i2c&&at24->write_max>I2C_SMBUS_BLOCK_MAX)at24->write_max=I2C_SMBUS_BLOCK_MAX;}
@@ -712,7 +703,7 @@ static int at24_probe(struct i2c_client *client)nvmem_config.priv=at24;nvmem_config.stride=1;nvmem_config.word_size=1;-nvmem_config.size=pdata.byte_len;+nvmem_config.size=byte_len;at24->nvmem=devm_nvmem_register(dev,&nvmem_config);if(IS_ERR(at24->nvmem)){
@@ -721,13 +712,9 @@ static int at24_probe(struct i2c_client *client)}dev_info(dev,"%u byte %s EEPROM, %s, %u bytes/write\n",-pdata.byte_len,client->name,+byte_len,client->name,writable?"writable":"read-only",at24->write_max);-/* export data to kernel code */-if(pdata.setup)-pdata.setup(at24->nvmem,pdata.context);-return0;err_clients:
@@ -1,60 +0,0 @@-/*- * at24.h - platform_data for the at24 (generic eeprom) driver- * (C) Copyright 2008 by Pengutronix- * (C) Copyright 2012 by Wolfram Sang- * same license as the driver- */--#ifndef _LINUX_AT24_H-#define _LINUX_AT24_H--#include <linux/types.h>-#include <linux/nvmem-consumer.h>-#include <linux/bitops.h>--/**- * struct at24_platform_data - data to set up at24 (generic eeprom) driver- * @byte_len: size of eeprom in byte- * @page_size: number of byte which can be written in one go- * @flags: tunable options, check AT24_FLAG_* defines- * @setup: an optional callback invoked after eeprom is probed; enables kernel- code to access eeprom via nvmem, see example- * @context: optional parameter passed to setup()- *- * If you set up a custom eeprom type, please double-check the parameters.- * Especially page_size needs extra care, as you risk data loss if your value- * is bigger than what the chip actually supports!- *- * An example in pseudo code for a setup() callback:- *- * void get_mac_addr(struct nvmem_device *nvmem, void *context)- * {- * u8 *mac_addr = ethernet_pdata->mac_addr;- * off_t offset = context;- *- * // Read MAC addr from EEPROM- * if (nvmem_device_read(nvmem, offset, ETH_ALEN, mac_addr) == ETH_ALEN)- * pr_info("Read MAC addr from EEPROM: %pM\n", mac_addr);- * }- *- * This function pointer and context can now be set up in at24_platform_data.- */--struct at24_platform_data {- u32 byte_len; /* size (sum of all addr) */- u16 page_size; /* for writes */- u8 flags;-#define AT24_FLAG_ADDR16 BIT(7) /* address pointer is 16 bit */-#define AT24_FLAG_READONLY BIT(6) /* sysfs-entry will be read-only */-#define AT24_FLAG_IRUGO BIT(5) /* sysfs-entry will be world-readable */-#define AT24_FLAG_TAKE8ADDR BIT(4) /* take always 8 addresses (24c00) */-#define AT24_FLAG_SERIAL BIT(3) /* factory-programmed serial number */-#define AT24_FLAG_MAC BIT(2) /* factory-programmed mac address */-#define AT24_FLAG_NO_RDROL BIT(1) /* does not auto-rollover reads to */- /* the next slave address */-- void (*setup)(struct nvmem_device *nvmem, void *context);- void *context;-};--#endif /* _LINUX_AT24_H */--
2018-08-08 19:50 GMT+02:00 Andy Shevchenko [off-list ref]:
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski [off-list ref] wrote:
quoted
From: Bartosz Golaszewski <redacted>
We want do add more sources from which to read the MAC address. In
order to avoid bloating this function too much, start by splitting it
into subroutines, each of which takes care of reading the MAC from
one source.
2018-08-08 20:03 GMT+02:00 Andy Shevchenko [off-list ref]:
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski [off-list ref] wrote:
quoted
From: Bartosz Golaszewski <redacted>
There are no more users of at24_platform_data. Remove the relevant
header and modify the driver code to not use it anymore.
Reviewed-by: Andy Shevchenko <redacted>
If you want me to test this on Intel Galileo Gen 2 board, give me a
public tree from where I can pull.
Thanks.
Yes, you can pull from git@github.com:brgl/linux.git
davinci-remove-at24-platform-data
Bart
2018-08-08 20:03 GMT+02:00 Andy Shevchenko [off-list ref]:
quoted
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski [off-list ref] wrote:
quoted
From: Bartosz Golaszewski <redacted>
There are no more users of at24_platform_data. Remove the relevant
header and modify the driver code to not use it anymore.
Reviewed-by: Andy Shevchenko <redacted>
If you want me to test this on Intel Galileo Gen 2 board, give me a
public tree from where I can pull.
Thanks.
Yes, you can pull from git@github.com:brgl/linux.git
davinci-remove-at24-platform-data
The branch is topic/davinci-remove-at24-platform-data
From: Sekhar Nori <hidden> Date: 2018-08-10 08:16:05
Hi Bart,
On Wednesday 08 August 2018 10:22 PM, Bartosz Golaszewski wrote:
2018-08-08 18:44 GMT+02:00 Andrew Lunn [off-list ref]:
quoted
On Wed, Aug 08, 2018 at 06:27:25PM +0200, Bartosz Golaszewski wrote:
quoted
2018-08-08 17:55 GMT+02:00 Wolfram Sang [off-list ref]:
quoted
On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote:
quoted
From: Bartosz Golaszewski <redacted>
This is a follow-up to the previously rejected series[1] which partially
removed the at24_platform_data structure. After further development and
taking reviews into account, this series finally removes that struct
completely but not without touching many different parts of the code
base.
Since I took over maintainership of the at24 driver I've been working
towards removing at24_platform_data in favor for device properties.
Wooha, nice work. I can't really comment on it but wondered how you want
to upstream it (after reviews)? Pull request of an immutable branch for
nvmem-tree sounds best to me. Then I could also pull it in if i2c needs
it. Probably same situation for arm-soc...
I initially wanted to merge small parts of it starting with v4.18, but
there were some voices against merging APIs without users. I'm not
sure how it should go in. There'll be a need for multiple immutable
branches most probably...
Hi Bartosz
What this series does is show all the different parts are now
available, and can be reviewed as a whole. Once that review is
completed, merging in parts then becomes possible.
It looks like you could probably merge the nvmem, mtd and net parts
independently via there maintainers for 4.20, since i don't think
there are any dependencies. The arm-soc changes in 4.21, and the
removal of the platform data in 4.22?
Andrew
We need the first batch of SoC changes for the net part and then the
second batch depends on those net changes. Also: dragging the merge
for this over a year is a bit overkill.
Sekhar: I know you're usually provided with immutable branches from
framework maintainers for the SoC changes - is it ok for you to
provide the net maintainers with an immutable branch after applying
the first part of davinci board file changes?
Yeah, sure. I will be happy to do that to speed merging. Will take a
look at v2 you posted.
Thanks,
Sekhar