* [PATCH v2 12/29] ARM: davinci: da850-evm: use nvmem lookup for mac address
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We now support nvmem lookups for machine code. Add a lookup for
mac-address.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/board-da850-evm.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 6d5beb11bd96..5a634a04ec69 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -29,6 +29,7 @@
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/physmap.h>
+#include <linux/nvmem-provider.h>
#include <linux/platform_device.h>
#include <linux/platform_data/gpio-davinci.h>
#include <linux/platform_data/mtd-davinci.h>
@@ -99,6 +100,19 @@ static struct mtd_partition da850evm_spiflash_part[] = {
},
};
+static struct nvmem_cell_lookup da850evm_mac_address_cell = {
+ .info = {
+ .name = "mac-address",
+ .offset = 0x0,
+ .bytes = ETH_ALEN,
+ },
+ /*
+ * The nvmem name differs from the partition name because of the
+ * internal works of the nvmem framework.
+ */
+ .nvmem_name = "MAC-Address0",
+};
+
static struct flash_platform_data da850evm_spiflash_data = {
.name = "m25p80",
.parts = da850evm_spiflash_part,
@@ -1447,6 +1461,8 @@ static __init void da850_evm_init(void)
pr_warn("%s: spi info registration failed: %d\n", __func__,
ret);
+ nvmem_add_lookup_table(&da850evm_mac_address_cell, 1);
+
ret = da8xx_register_spi_bus(1, ARRAY_SIZE(da850evm_spi_info));
if (ret)
pr_warn("%s: SPI 1 registration failed: %d\n", __func__, ret);
--
2.18.0
^ permalink raw reply related
* [PATCH v2 11/29] ARM: davinci: mityomapl138: add nvmem cells lookup entries
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We now support nvmem lookups for machine code. Add a lookup for
mac-address.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/board-mityomapl138.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 37b3e48a21d1..48a9bae76e4a 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -15,6 +15,7 @@
#include <linux/console.h>
#include <linux/platform_device.h>
#include <linux/mtd/partitions.h>
+#include <linux/nvmem-provider.h>
#include <linux/regulator/machine.h>
#include <linux/i2c.h>
#include <linux/platform_data/at24.h>
@@ -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();
--
2.18.0
^ permalink raw reply related
* [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
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.
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 <bgolaszewski@baylibre.com>
---
drivers/mtd/Kconfig | 1 +
drivers/mtd/mtdcore.c | 50 +++++++++++++++++++++++++++++++++++++++++
include/linux/mtd/mtd.h | 2 ++
3 files changed, 53 insertions(+)
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 46ab7feec6b6..f5549482d0df 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -1,5 +1,6 @@
menuconfig MTD
tristate "Memory Technology Device (MTD) support"
+ imply NVMEM
help
Memory Technology Devices are flash, RAM and similar chips, often
used for solid state file systems on embedded devices. This option
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 42395df06be9..a57302eaceb5 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -488,6 +488,49 @@ int mtd_pairing_groups(struct mtd_info *mtd)
}
EXPORT_SYMBOL_GPL(mtd_pairing_groups);
+static int mtd_nvmem_reg_read(void *priv, unsigned int offset,
+ void *val, size_t bytes)
+{
+ struct mtd_info *mtd = priv;
+ size_t retlen;
+ int err;
+
+ err = mtd_read(mtd, offset, bytes, &retlen, val);
+ if (err && err != -EUCLEAN)
+ return err;
+
+ return retlen == bytes ? 0 : -EIO;
+}
+
+static int mtd_nvmem_add(struct mtd_info *mtd)
+{
+ struct nvmem_config config = { };
+
+ config.dev = &mtd->dev;
+ config.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");
+ return PTR_ERR(mtd->nvmem);
+ }
+ }
+
+ return 0;
+}
+
static struct dentry *dfs_dir_mtd;
/**
@@ -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;
+
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);
return 0;
+fail_nvmem_add:
+ device_unregister(&mtd->dev);
fail_added:
of_node_put(mtd_get_of_node(mtd));
idr_remove(&mtd_idr, i);
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index a86c4fa93115..8121c6582285 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -25,6 +25,7 @@
#include <linux/notifier.h>
#include <linux/device.h>
#include <linux/of.h>
+#include <linux/nvmem-provider.h>
#include <mtd/mtd-abi.h>
@@ -339,6 +340,7 @@ struct mtd_info {
struct device dev;
int usecount;
struct mtd_debug_info dbg;
+ struct nvmem_device *nvmem;
};
int mtd_ooblayout_ecc(struct mtd_info *mtd, int section,
--
2.18.0
^ permalink raw reply related
* [PATCH v2 05/29] nvmem: remove the name field from struct nvmem_device
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This field is never set and is only used in a single error message.
Remove the field and use nvmem_dev_name() instead.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/nvmem/core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 31df2e6d6f72..ab3ced2d9a84 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -26,7 +26,6 @@
#include <linux/slab.h>
struct nvmem_device {
- const char *name;
struct module *owner;
struct device dev;
int stride;
@@ -712,7 +711,7 @@ static struct nvmem_device *__nvmem_device_get(struct device_node *np,
if (!try_module_get(nvmem->owner)) {
dev_err(&nvmem->dev,
"could not increase module refcount for cell %s\n",
- nvmem->name);
+ nvmem_dev_name(nvmem));
mutex_lock(&nvmem_mutex);
nvmem->users--;
--
2.18.0
^ permalink raw reply related
* [PATCH v2 04/29] nvmem: provide nvmem_dev_name()
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
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 <bgolaszewski@baylibre.com>
---
drivers/nvmem/core.c | 6 ++++++
include/linux/nvmem-consumer.h | 7 +++++++
2 files changed, 13 insertions(+)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 128c8e51bff2..31df2e6d6f72 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -1440,6 +1440,12 @@ int nvmem_device_write(struct nvmem_device *nvmem,
}
EXPORT_SYMBOL_GPL(nvmem_device_write);
+const char *nvmem_dev_name(struct nvmem_device *nvmem)
+{
+ return dev_name(&nvmem->dev);
+}
+EXPORT_SYMBOL_GPL(nvmem_dev_name);
+
static int __init nvmem_init(void)
{
return bus_register(&nvmem_bus_type);
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index ae4d30347602..14bb86a7a78d 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -69,6 +69,8 @@ int nvmem_device_cell_write(struct nvmem_device *nvmem,
int nvmem_register_notifier(struct notifier_block *nb);
int nvmem_unregister_notifier(struct notifier_block *nb);
+
+const char *nvmem_dev_name(struct nvmem_device *nvmem);
#else
static inline struct nvmem_cell *nvmem_cell_get(struct device *dev,
@@ -167,6 +169,11 @@ static inline int int nvmem_unregister_notifier(struct notifier_block *nb)
{
return -ENOSYS;
}
+
+static inline const char *nvmem_dev_name(struct nvmem_device *nvmem)
+{
+ return NULL;
+}
#endif /* CONFIG_NVMEM */
#if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
--
2.18.0
^ permalink raw reply related
* [PATCH v2 00/29] at24: remove at24_platform_data
From: Bartosz Golaszewski @ 2018-08-10 8:04 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
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
v1 -> v2:
PATCH 4/29:
- change name to nvmem_dev_name()
- return NULL instead of ERR_PTR(-ENOSYS) from nvmem_dev_name() if nvmem is
not configured
PATCH 5/29:
- s/nvmem_device_name/nvmem_dev_name/
PATCH 6/29:
- fix the commit message: remove the part mentioning the OF systems
PATCH 7/29:
- fix ordering of includes
PATCH 8/29:
- fix ordering of includes
PATCH 9/29:
- fix ordering of includes
PATCH 10/29:
- fix ordering of includes
PATCH 11/29:
- fix ordering of includes
PATCH 14/29:
- new patch
PATCH 22/29:
- added missing terminator
PATCH 25/29:
- removed unneeded coma
PATCH 27/29:
- s/nvmem_device_name/nvmem_dev_name/
- fix ordering of includes
PATCH 28/29:
- added missing terminator
Alban Bedel (1):
mtd: Add support for reading MTD devices via the nvmem API
Bartosz Golaszewski (28):
nvmem: add support for cell lookups
Documentation: nvmem: document lookup entries
nvmem: add a notifier chain
nvmem: provide nvmem_dev_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: simplify eth_platform_get_mac_address()
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 | 25 ++--
arch/arm/mach-davinci/board-dm646x-evm.c | 25 ++--
arch/arm/mach-davinci/board-mityomapl138.c | 60 +++++++---
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 | 84 ++++++++++++--
21 files changed, 492 insertions(+), 255 deletions(-)
delete mode 100644 include/linux/platform_data/at24.h
--
2.18.0
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: enable btf for use in all maps
From: Daniel Borkmann @ 2018-08-10 7:55 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: ast, netdev, yhs
In-Reply-To: <20180810021337.dmuwiyrygd3h2dbd@ast-mbp.dhcp.thefacebook.com>
On 08/10/2018 04:13 AM, Alexei Starovoitov wrote:
> On Fri, Aug 10, 2018 at 12:43:20AM +0200, Daniel Borkmann wrote:
>> On 08/09/2018 11:44 PM, Alexei Starovoitov wrote:
>>> On Thu, Aug 09, 2018 at 11:30:52PM +0200, Daniel Borkmann wrote:
>>>> On 08/09/2018 11:14 PM, Alexei Starovoitov wrote:
>>>>> On Thu, Aug 09, 2018 at 09:42:20PM +0200, Daniel Borkmann wrote:
>>>>>> Commit a26ca7c982cb ("bpf: btf: Add pretty print support to
>>>>>> the basic arraymap") enabled support for BTF and dumping via
>>>>>> BPF fs for arraymap. However, both can be decoupled from each
>>>>>> other such that all BPF maps can be supported for attaching
>>>>>> BTF key/value information, while not all maps necessarily
>>>>>> need to dump via map_seq_show_elem() callback.
>>>>>>
>>>>>> The check in array_map_check_btf() can be generalized as
>>>>>> ultimatively the key and value size is the only contraint
>>>>>> that needs to match for the map. The fact that the key needs
>>>>>> to be of type int is optional; it could be any data type as
>>>>>> long as it matches the 4 byte key size, just like hash table
>>>>>> key or others could be of any data type as well.
>>>>>>
>>>>>> Minimal example of a hash table dump which then works out
>>>>>> of the box for bpftool:
>>>>>>
>>>>>> # bpftool map dump id 19
>>>>>> [{
>>>>>> "key": {
>>>>>> "": {
>>>>>> "vip": 0,
>>>>>> "vipv6": []
>>>>>> },
>>>>>> "port": 0,
>>>>>> "family": 0,
>>>>>> "proto": 0
>>>>>> },
>>>>>> "value": {
>>>>>> "flags": 0,
>>>>>> "vip_num": 0
>>>>>> }
>>>>>> }
>>>>>> ]
>>>>>>
>>>>>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>>>>>> Cc: Yonghong Song <yhs@fb.com>
>>>>>> ---
>>>>>> include/linux/bpf.h | 4 +---
>>>>>> kernel/bpf/arraymap.c | 27 ---------------------------
>>>>>> kernel/bpf/inode.c | 3 ++-
>>>>>> kernel/bpf/syscall.c | 24 ++++++++++++++++++++----
>>>>>> 4 files changed, 23 insertions(+), 35 deletions(-)
>>>>>>
>>>>>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>>>>>> index cd8790d..eb76e8e 100644
>>>>>> --- a/include/linux/bpf.h
>>>>>> +++ b/include/linux/bpf.h
>>>>>> @@ -48,8 +48,6 @@ struct bpf_map_ops {
>>>>>> u32 (*map_fd_sys_lookup_elem)(void *ptr);
>>>>>> void (*map_seq_show_elem)(struct bpf_map *map, void *key,
>>>>>> struct seq_file *m);
>>>>>> - int (*map_check_btf)(const struct bpf_map *map, const struct btf *btf,
>>>>>> - u32 key_type_id, u32 value_type_id);
>>>>>> };
>>>>>>
>>>>>> struct bpf_map {
>>>>>> @@ -118,7 +116,7 @@ static inline bool bpf_map_offload_neutral(const struct bpf_map *map)
>>>>>>
>>>>>> static inline bool bpf_map_support_seq_show(const struct bpf_map *map)
>>>>>> {
>>>>>> - return map->ops->map_seq_show_elem && map->ops->map_check_btf;
>>>>>> + return map->btf && map->ops->map_seq_show_elem;
>>>>>> }
>>>>>>
>>>>>> extern const struct bpf_map_ops bpf_map_offload_ops;
>>>>>> diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
>>>>>> index 2aa55d030..67f0bdf 100644
>>>>>> --- a/kernel/bpf/arraymap.c
>>>>>> +++ b/kernel/bpf/arraymap.c
>>>>>> @@ -358,32 +358,6 @@ static void array_map_seq_show_elem(struct bpf_map *map, void *key,
>>>>>> rcu_read_unlock();
>>>>>> }
>>>>>>
>>>>>> -static int array_map_check_btf(const struct bpf_map *map, const struct btf *btf,
>>>>>> - u32 btf_key_id, u32 btf_value_id)
>>>>>> -{
>>>>>> - const struct btf_type *key_type, *value_type;
>>>>>> - u32 key_size, value_size;
>>>>>> - u32 int_data;
>>>>>> -
>>>>>> - key_type = btf_type_id_size(btf, &btf_key_id, &key_size);
>>>>>> - if (!key_type || BTF_INFO_KIND(key_type->info) != BTF_KIND_INT)
>>>>>> - return -EINVAL;
>>>>>> -
>>>>>> - int_data = *(u32 *)(key_type + 1);
>>>>>> - /* bpf array can only take a u32 key. This check makes
>>>>>> - * sure that the btf matches the attr used during map_create.
>>>>>> - */
>>>>>> - if (BTF_INT_BITS(int_data) != 32 || key_size != 4 ||
>>>>>> - BTF_INT_OFFSET(int_data))
>>>>>> - return -EINVAL;
>>>>>
>>>>> I think most of these checks are still necessary for array type.
>>>>> Relaxing BTF array key from BTF_KIND_INT to, for example, BTF_KIND_ENUM
>>>>> is probably ok, but key being BTF_KIND_PTR or BTF_KIND_ARRAY doesn't makes sense.
>>>>
>>>> Hmm, so on 64 bit archs BTF_KIND_PTR would get rejected for array,
>>>> on 32 bit it may be allowed due to sizeof(void *) == 4. BTF_KIND_ARRAY
>>>> could be array of u8 foo[4], for example, or u16 foo[2]. But how would
>>>> it ultimately be different from e.g. having 'struct a' versus 'struct b'
>>>> where both are of same size and while actual key has 'struct a', the one
>>>> who writes the prog resp. loads the BTF into the kernel would lie about
>>>> it stating it's of type 'struct b' instead? It's basically trusting the
>>>> app that it advertised sane key types which kernel is propagating back.
>>>
>>> for hash map - yes. the kernel cannot yet catch the lie that
>>> key == 'struct a' that user said in BTF is not what program used
>>> (which used 'struct b' of the same size).
>>> Eventually we will annotate all load/store in the program and will
>>> make sure that memory access match what BTF said.
>>
>> But in that case, would you reject the program? E.g. from prog point of
>> view, it's just a buffer of x bytes, so key could be casted to different
>> struct/types potentially and used for lookup; similar with value if you
>> would go the route to annotate all access into it. I don't think this
>> serves as a security feature (since you might as well just load the prog
>> without BTF just fine), but it can be used to help verifier to perform
>> rewrites like in tracing for implicit bpf_probe_read() based on member
>> access. But also in that case, if you might have e.g. stale or wrong BTF
>> data e.g. of the whole kernel or some application it would follow/walk
>> that one instead. But such user error would be "acceptable" since it serves
>> as a hint, roughly similar to (explicitly) walking the data structures
>> based on the headers today, you do have better control in terms of header
>> mismatches in that you can ship the BTF directly from the build, but there's
>> still no guarantee in that sense that you "verified" that these bytes
>> originally were mapped to struct foo somewhere in a C program.
>
> I wouldn't view such key checks as safety feature, but rather
> as honesty check. Meaning that user space shouldn't be able to cheat
> by passing completely bogus BTF into the kernel that only
> statisfies single size check.
Ok, meaning, we agree that BTF is passed as a hint to the kernel. It is
a 'should not cheat' requirement but not 'cannot cheat', meaning if it
was the latter, BTF is core part of the verifier's safety analysis /
checks, but as it's optional on top of it (well, due to compatibility it
kind of needs to be anyway), it doesn't affect kernel's safety in
relation to what the program is doing internally.
> Say, BTF has a key that is a 4 byte struct { char a,b,c,d; };
> but program operates with it as u32. I very much would like
> the verifier to notice and reject such program, since if C code
> has struct { char a,b,c,d; }; the compiler won't generate u32 access
> to it unless C code type casts, but then llvm will warn. So for u32
> to legitimately appear in the generated code the struct should be:
> union {
> struct { char a,b,c,d;}
> u32 e;
> };
> Narrow access (like u8 load/store in the bpf prog form u32 BTF field)
> is ok, since that's normal compiler optimization, but any other
> field/size mismatch the verifier should reject to prevent cheating.
>
> In other words even proprietary bpf programs should not be able to cheat.
> If they provide BTF to the kernel, it should correspond exactly to the program.
> That's the key to _trusted_ introspection.
But then wouldn't this artificially force users into programming /
thinking style that verifier dictates upon them similar as we have
today as opposed to further moving away from it to allow more C-style
programs to be accepted?
But even if that is the goal, it is still used as a hint today, e.g.
even for an array I could tell the compiler that the key is '__u32'
for BTF sake while using the underlying key differently (e.g. as struct,
enum, etc) in order to pass the array_map_check_btf() check in the
kernel. Those type of programs would still need to be accepted due
to compatibility reasons. Same if we only test on size match in other
maps, it's nothing different. I don't see how verifier would start
enforcing programs to be rejected based on access patterns on the
types; while it might work for newly added program types that this
could be enforced, it cannot for all the many existing program types,
but I also don't really think it needs to be. Unless it is declared
a safety feature for future program types.
> Admin that ssh-es into the box and operates with bpftool should be
> certain that the map introspection represent the real situation of
> the program. If proprietary prog is paranoid about layout of map
> it shouldn't be using BTF, but if it does, BTF should match.
> In the future I'd like to enfore availability of BTF for
> new program types.
Sure, and in vast majority / normal cases it will represent the real
situation. Do you mistrust DWARF debugging data that gets shipped with
your distro, for example? pahole and other tools on top of it? It is
pretty much the same situation. Given gdb example below, does gdb do
any verification of the binary in order to analyze load/store patterns
and whether it matches with what sits in DWARF as types? It would just
as well map the types into memory and dump it as pretty print instead.
And that's okay, the one thing that needs to be verified for correctness
resp. validity is the debugging format itself so it can be used for
that.
>>> For array we can catch the lie today that key is not 4 byte int,
>>> since it matters from pretty printing point of view.
>>> If it's PTR or ARRAY or STRUCT, the printer will go nuts.
>>
>> In that case, would you enforce a hash map key size of 4 also to INT-only
>> instead of e.g. allowing STRUCT and various others?
>
> hash map key of 4 bytes can be anything and printing is ideally
> done similar to the way gdb prints stl c++:
> #include <map>
>
> struct K {
> int a, b;
> };
> struct V {
> int c, d;
> };
> int operator<(const K& a, const K& b) {return a.a < b.a;}
> std::map<K, V> m;
>
> int main()
> {
> K k1 = {1, 2};
> K k2 = {3, 4};
> V v1 = {5, 6};
> V v2 = {7, 8};
> m[k1] = v1;
> m[k2] = v2;
> ...
> (gdb) p m
> $3 = std::map with 2 elements = {[{a = 1, b = 2}] = {c = 5, d = 6}, [{a = 3, b = 4}] = {c = 7, d = 8}}
> (gdb) set print pretty on
> (gdb) p m
> $4 = std::map with 2 elements = {
> [{
> a = 1,
> b = 2
> }] = {
> c = 5,
> d = 6
> },
> [{
> a = 3,
> b = 4
> }] = {
> c = 7,
> d = 8
> }
> }
^ permalink raw reply
* [PATCH] mlxsw: remove unused arrays mlxsw_i2c_driver_name and mlxsw_pci_driver_name
From: Colin King @ 2018-08-10 7:53 UTC (permalink / raw)
To: Jiri Pirko, Ido Schimmel, David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Arrays mlxsw_i2c_driver_name and mlxsw_pci_driver_name are defined
but never used hence they are redundant and can be removed.
Cleans up clang warnings:
warning: 'mlxsw_i2c_driver_name' defined but not used
warning: 'mlxsw_pci_driver_name' defined but not used
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/mellanox/mlxsw/i2c.c | 2 --
drivers/net/ethernet/mellanox/mlxsw/pci.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/i2c.c b/drivers/net/ethernet/mellanox/mlxsw/i2c.c
index 25f9915ebd82..11a664eb5ce7 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/i2c.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/i2c.c
@@ -46,8 +46,6 @@
#include "core.h"
#include "i2c.h"
-static const char mlxsw_i2c_driver_name[] = "mlxsw_i2c";
-
#define MLXSW_I2C_CIR2_BASE 0x72000
#define MLXSW_I2C_CIR_STATUS_OFF 0x18
#define MLXSW_I2C_CIR2_OFF_STATUS (MLXSW_I2C_CIR2_BASE + \
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.c b/drivers/net/ethernet/mellanox/mlxsw/pci.c
index fc4557245ff4..ce9157aeb0aa 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.c
@@ -53,8 +53,6 @@
#include "port.h"
#include "resources.h"
-static const char mlxsw_pci_driver_name[] = "mlxsw_pci";
-
#define mlxsw_pci_write32(mlxsw_pci, reg, val) \
iowrite32be(val, (mlxsw_pci)->hw_addr + (MLXSW_PCI_ ## reg))
#define mlxsw_pci_read32(mlxsw_pci, reg) \
--
2.17.1
^ permalink raw reply related
* [query] about recent mvneta patches
From: Jisheng Zhang @ 2018-08-10 6:58 UTC (permalink / raw)
To: Gregory CLEMENT, Andrew Lunn, Yelena Krivosheev, David S. Miller,
Thomas Petazzoni
Cc: Sebastian Hesselbarth, linux-arm-kernel, Marcin Wojtas, netdev
Hi,
Today I have a look at recent mvneta patches in net-next, I worried two patches:
1. commit 562e2f467e71 ("net: mvneta: Improve the buffer allocation method
for SWBM") sets rx_offset_correction as 0 for SW BM, but IIRC, the offset
is introduced to support 64bit platforms. So in theory the commit could break
arm64 platforms with mvneta SW BM.
Fortunately, commit d93277b9839b ("Revert "arm64: Increase the max granular
size") makes arm64 L1_CACHE_BYTES equal to 64 again, thus NET_SKB_PAD is 64
too, so the commit 562e2f467e71 doesn't introduce regression, but it hides
the bug we tried to fix in commit 8d5047cf9ca ("net: mvneta: Convert to be 64
bits compatible)
IMHO, this patch need to be updated to not introduce regression even the
L1_CACHE_BYTES is larger than 64B, what do you think?
2. commit f945cec88cb ("net: mvneta: Verify hardware checksum only when
offload checksum feature is set"), I agree with the point. But
MVNETA_RX_CSUM_WITH_PSEUDO_HDR bit is always set, so the RX CSUM is always
generated no matter we set NETIF_F_RXCSUM or not, so IMHO, we should
always set NETIF_F_RXCSUM. And since we enabled GRO, so what about something
as below:
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index bc80a678abc3..a5043b27bf37 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -4598,7 +4598,8 @@ static int mvneta_probe(struct platform_device *pdev)
}
}
- dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM | NETIF_F_TSO;
+ dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
+ NETIF_F_RXCSUM | NETIF_F_TSO | NETIF_F_GRO;
dev->hw_features |= dev->features;
dev->vlan_features |= dev->features;
dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
^ permalink raw reply related
* Re: [PATCH 4.9-stable] tcp: add tcp_ooo_try_coalesce() helper
From: maowenan @ 2018-08-10 6:26 UTC (permalink / raw)
To: David Woodhouse, Greg KH
Cc: davem, edumazet, juha-matti.tilli, ycheng, soheil, netdev,
eric.dumazet, jdw
In-Reply-To: <1533819122.5775.12.camel@infradead.org>
On 2018/8/9 20:52, David Woodhouse wrote:
> On Thu, 2018-08-09 at 14:47 +0200, Greg KH wrote:
>> On Thu, Aug 09, 2018 at 08:37:13PM +0800, maowenan wrote:
>>> There are two patches in stable branch linux-4.4, but I have tested with below patches, and found that the cpu usage was very high.
>>> dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
>>> 5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
>>>
>>> test results:
>>> with fix patch： 78.2% ksoftirqd
>>> no fix patch： 90% ksoftirqd
>>>
>>> there is %0 when no attack packets.
>>>
>>> so please help verify that fixed patches are enough in linux-stable 4.4.
>>>
>>
>> I do not know, I am not a network developer. Please try to reproduce
>> the same thing on a newer kernel release and see if the result is the
>> same or not. If you can find a change that I missed, please let me know
>> and I will be glad to apply it.
>
> maowenan, there were five patches in the original upstream set to
> address SegmentSmack:
>
> tcp: free batches of packets in tcp_prune_ofo_queue()
> tcp: avoid collapses in tcp_prune_queue() if possible
> tcp: detect malicious patterns in tcp_collapse_ofo_queue()
> t
> cp: call tcp_drop() from tcp_data_queue_ofo()
> tcp: add
> tcp_ooo_try_coalesce() helper
>
> I believe that the first one, "free batches of packets..." is not
> needed in 4.4 because we only have a simple queue of packets there
> anyway, so we're dropping everything each time and don't need the
> heuristics for how many to drop.
>
> That leaves two more which have so far not been backported to 4.4; can
> you try applying them and see if it resolves the problem for you?
I have tried to add below two patches in 4.4 stable, since I can't apply
tcp: add tcp_ooo_try_coalesce() helper because conflicts, it has the same result
after testing, and the cpu usage has not obviously been improved.
tcp: call tcp_drop() from tcp_data_queue_ofo()
tcp: increment sk_drops for dropped rx packets
@Eric Dumazet, do you have any comments about this, and shall we apply which patches
to fix in stable branch?
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH] net: macb: do not disable MDIO bus when closing interface
From: Anssi Hannula @ 2018-08-10 6:22 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Claudiu Beznea, Nicolas Ferre, David S. Miller, netdev
In-Reply-To: <20180809151433.GB20006@lunn.ch>
On 9.8.2018 18:14, Andrew Lunn wrote:
> Hi Anssi
Hi!
>> macb_reset_hw() is called in init path too, though, so maybe clearing
>> all bits is intentional / wanted to get the controller to a known state,
>> even though the comment only mentions TX/RX?
> You need to be careful here. Once of_mdiobus_register() is called, the
> MDIO should be usable. If you happen to have an Ethernet switch on the
> bus, it could be probed then. The DSA driver will start using the bus.
> Or if you have a second PHY, connected to some other MAC, it could be
> used by the other MAC. This all happens in the macb_probe function.
>
> Sometime later, the interface will be up'ed. At this point macb_open()
> is called, which calls macb_init_hw(), which calls
> macb_reset_hw(). What you don't want happening is changes to the NCR
> at this point breaking an MDIO transaction which might be going on.
>
> Ideally, the MPE should be enabled before of_mdiobus_register(), and
> left alone until mdiobus_unregister() is called in macb_remove().
Yep, fixing the use case of having PHYs of other MACs is why I wrote the
patch :)
Currently the reset code disables MPE while other MACs are using PHYs on
the bus.
--
Anssi Hannula / Bitwise Oy
+358 503803997
^ permalink raw reply
* [PATCH] net: Provide stub for __netif_set_xps_queue if there is no CONFIG_XPS
From: Krzysztof Kozlowski @ 2018-08-10 8:47 UTC (permalink / raw)
To: David S. Miller, netdev, linux-kernel; +Cc: Andrei Vagin, Krzysztof Kozlowski
Building virtio_net driver without CONFIG_XPS fails with:
drivers/net/virtio_net.c: In function ‘virtnet_set_affinity’:
drivers/net/virtio_net.c:1910:3: error: implicit declaration of function ‘__netif_set_xps_queue’ [-Werror=implicit-function-declaration]
__netif_set_xps_queue(vi->dev, mask, i, false);
^
Fixes: 4d99f6602cb5 ("net: allow to call netif_reset_xps_queues() under cpus_read_lock")
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
include/linux/netdevice.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 282e2e95ad5b..c38e774494a3 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3412,6 +3412,12 @@ static inline int netif_set_xps_queue(struct net_device *dev,
{
return 0;
}
+static inline int __netif_set_xps_queue(struct net_device *dev,
+ const unsigned long *mask,
+ u16 index, bool is_rxqs_map)
+{
+ return 0;
+}
#endif
/**
--
2.7.4
^ permalink raw reply related
* Re: pull-request: bpf 2018-08-10
From: David Miller @ 2018-08-10 6:18 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20180809232149.5194-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri, 10 Aug 2018 01:21:49 +0200
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
...
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Pulled, thanks Daniel.
^ permalink raw reply
* [net-next, PATCH 2/2 v2] net: socionext: Increase descriptors to 256
From: Ilias Apalodimas @ 2018-08-10 6:12 UTC (permalink / raw)
To: netdev, jaswinder.singh
Cc: ard.biesheuvel, masami.hiramatsu, arnd, Ilias Apalodimas
In-Reply-To: <1533881559-18589-1-git-send-email-ilias.apalodimas@linaro.org>
Increasing descriptors to 256 from 128 and adjusting the NAPI weight
to 64 increases performace on Rx by ~20% on 64byte packets
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
---
drivers/net/ethernet/socionext/netsec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/socionext/netsec.c b/drivers/net/ethernet/socionext/netsec.c
index 334b618..7aa5ebb 100644
--- a/drivers/net/ethernet/socionext/netsec.c
+++ b/drivers/net/ethernet/socionext/netsec.c
@@ -232,8 +232,7 @@
#define NETSEC_EEPROM_PKT_ME_ADDRESS 0x20
#define NETSEC_EEPROM_PKT_ME_SIZE 0x24
-#define DESC_NUM 128
-#define NAPI_BUDGET (DESC_NUM / 2)
+#define DESC_NUM 256
#define DESC_SZ sizeof(struct netsec_de)
@@ -1659,7 +1658,7 @@ static int netsec_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "hardware revision %d.%d\n",
hw_ver >> 16, hw_ver & 0xffff);
- netif_napi_add(ndev, &priv->napi, netsec_napi_poll, NAPI_BUDGET);
+ netif_napi_add(ndev, &priv->napi, netsec_napi_poll, NAPI_POLL_WEIGHT);
ndev->netdev_ops = &netsec_netdev_ops;
ndev->ethtool_ops = &netsec_ethtool_ops;
--
2.7.4
^ permalink raw reply related
* [net-next, PATCH 1/2 v2] net: socionext: Use descriptor info instead of MMIO reads on Rx
From: Ilias Apalodimas @ 2018-08-10 6:12 UTC (permalink / raw)
To: netdev, jaswinder.singh
Cc: ard.biesheuvel, masami.hiramatsu, arnd, Ilias Apalodimas
In-Reply-To: <1533881559-18589-1-git-send-email-ilias.apalodimas@linaro.org>
MMIO reads for remaining packets in queue occur (at least)twice per
invocation of netsec_process_rx(). We can use the packet descriptor to
identify if it's owned by the hardware and break out, avoiding the more
expensive MMIO read operations. This has a ~2% increase on the pps of the
Rx path when tested with 64byte packets
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
---
drivers/net/ethernet/socionext/netsec.c | 25 ++++++++++---------------
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/socionext/netsec.c b/drivers/net/ethernet/socionext/netsec.c
index 01589b6..334b618 100644
--- a/drivers/net/ethernet/socionext/netsec.c
+++ b/drivers/net/ethernet/socionext/netsec.c
@@ -642,8 +642,6 @@ static struct sk_buff *netsec_get_rx_pkt_data(struct netsec_priv *priv,
tmp_skb = netsec_alloc_skb(priv, &td);
- dma_rmb();
-
tail = dring->tail;
if (!tmp_skb) {
@@ -657,8 +655,6 @@ static struct sk_buff *netsec_get_rx_pkt_data(struct netsec_priv *priv,
/* move tail ahead */
dring->tail = (dring->tail + 1) % DESC_NUM;
- dring->pkt_cnt--;
-
return skb;
}
@@ -731,25 +727,24 @@ static int netsec_process_rx(struct netsec_priv *priv, int budget)
struct netsec_desc_ring *dring = &priv->desc_ring[NETSEC_RING_RX];
struct net_device *ndev = priv->ndev;
struct netsec_rx_pkt_info rx_info;
- int done = 0, rx_num = 0;
+ int done = 0;
struct netsec_desc desc;
struct sk_buff *skb;
u16 len;
while (done < budget) {
- if (!rx_num) {
- rx_num = netsec_read(priv, NETSEC_REG_NRM_RX_PKTCNT);
- dring->pkt_cnt += rx_num;
+ u16 idx = dring->tail;
+ struct netsec_de *de = dring->vaddr + (DESC_SZ * idx);
- /* move head 'rx_num' */
- dring->head = (dring->head + rx_num) % DESC_NUM;
+ if (de->attr & (1U << NETSEC_RX_PKT_OWN_FIELD))
+ break;
- rx_num = dring->pkt_cnt;
- if (!rx_num)
- break;
- }
+ /* This barrier is needed to keep us from reading
+ * any other fields out of the netsec_de until we have
+ * verified the descriptor has been written back
+ */
+ dma_rmb();
done++;
- rx_num--;
skb = netsec_get_rx_pkt_data(priv, &rx_info, &desc, &len);
if (unlikely(!skb) || rx_info.err_flag) {
netif_err(priv, drv, priv->ndev,
--
2.7.4
^ permalink raw reply related
* [net-next, PATCH 0/2 v2] netsec driver improvements
From: Ilias Apalodimas @ 2018-08-10 6:12 UTC (permalink / raw)
To: netdev, jaswinder.singh
Cc: ard.biesheuvel, masami.hiramatsu, arnd, Ilias Apalodimas
This patchset introduces some improvements on socionext netsec driver.
- patch 1/2, avoids unneeded MMIO reads on the Rx path
- patch 2/2, is adjusting the numbers of descriptors used
Changes since v1:
- Move dma_rmb() to protect descriptor accesses until the device
has updated the NETSEC_RX_PKT_OWN_FIELD bit
Ilias Apalodimas (2):
net: socionext: Use descriptor info instead of MMIO reads on Rx
net: socionext: Increase descriptors to 256
drivers/net/ethernet/socionext/netsec.c | 30 ++++++++++++------------------
1 file changed, 12 insertions(+), 18 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH 00/28] at24: remove at24_platform_data
From: Sekhar Nori @ 2018-08-10 8:12 UTC (permalink / raw)
To: Bartosz Golaszewski, Andrew Lunn
Cc: Wolfram Sang, Srinivas Kandagatla, linux-i2c,
Mauro Carvalho Chehab, Marek Vasut, Rob Herring, Florian Fainelli,
Jonathan Corbet, Richard Weinberger, linux-doc, Russell King,
Bartosz Golaszewski, Paolo Abeni, Dan Carpenter,
Grygorii Strashko, David Lechner, Arnd Bergmann,
Sven Van Asbroeck, Boris Brezillon, linux-mtd, Linux-OMAP,
arm-soc
In-Reply-To: <CAMRc=McfSZQvdXgrKDagb_TE1g-WzEhSpst1z_o5Z994cv3MjA@mail.gmail.com>
Hi Bart,
On Wednesday 08 August 2018 10:22 PM, Bartosz Golaszewski wrote:
> 2018-08-08 18:44 GMT+02:00 Andrew Lunn <andrew@lunn.ch>:
>> On Wed, Aug 08, 2018 at 06:27:25PM +0200, Bartosz Golaszewski wrote:
>>> 2018-08-08 17:55 GMT+02:00 Wolfram Sang <wsa@the-dreams.de>:
>>>> On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote:
>>>>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>>>
>>>>> 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
^ permalink raw reply
* [PATCH v2 29/29] eeprom: at24: kill at24_platform_data
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
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 <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
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
diff --git a/MAINTAINERS b/MAINTAINERS
index 7cebd5bba8a8..8eb87a3548f8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2328,7 +2328,6 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
S: Maintained
F: Documentation/devicetree/bindings/eeprom/at24.txt
F: drivers/misc/eeprom/at24.c
-F: include/linux/platform_data/at24.h
ATA OVER ETHERNET (AOE) DRIVER
M: "Ed L. Cashin" <ed.cashin@acm.org>
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index f5cc517d1131..93642b4b47c5 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -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)
+
/*
* I2C EEPROMs from most vendors are inexpensive and mostly interchangeable.
* Differences between different vendor product lines (like Atmel AT24C or
@@ -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)
struct at24_chip_data {
- /*
- * these fields mirror their equivalents in
- * struct at24_platform_data
- */
u32 byte_len;
u8 flags;
};
@@ -467,46 +477,11 @@ static int at24_write(void *priv, unsigned int off, void *val, size_t count)
return 0;
}
-static void at24_properties_to_pdata(struct device *dev,
- struct at24_platform_data *chip)
-{
- int err;
- u32 val;
-
- 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 {
- /*
- * This is slow, but we can't know all eeproms, so we better
- * play safe. Specifying custom eeprom-types via platform_data
- * is recommended anyhow.
- */
- chip->page_size = 1;
- }
-}
-
-static int at24_get_pdata(struct device *dev, struct at24_platform_data *pdata)
+static const struct at24_chip_data *at24_get_chip_data(struct device *dev)
{
struct device_node *of_node = dev->of_node;
const struct at24_chip_data *cdata;
const struct i2c_device_id *id;
- struct at24_platform_data *pd;
-
- pd = dev_get_platdata(dev);
- if (pd) {
- memcpy(pdata, pd, sizeof(*pdata));
- return 0;
- }
id = i2c_match_id(at24_ids, to_i2c_client(dev));
@@ -523,13 +498,9 @@ static int at24_get_pdata(struct device *dev, struct at24_platform_data *pdata)
cdata = acpi_device_get_match_data(dev);
if (!cdata)
- return -ENODEV;
+ return ERR_PTR(-ENODEV);
- pdata->byte_len = cdata->byte_len;
- pdata->flags = cdata->flags;
- at24_properties_to_pdata(dev, pdata);
-
- return 0;
+ return cdata;
}
static void at24_remove_dummy_clients(struct at24_data *at24)
@@ -598,8 +569,9 @@ static int at24_probe(struct i2c_client *client)
{
struct regmap_config regmap_config = { };
struct nvmem_config nvmem_config = { };
- struct at24_platform_data pdata = { };
+ const struct at24_chip_data *cdata;
struct device *dev = &client->dev;
+ u32 byte_len, page_size, flags;
bool i2c_fn_i2c, i2c_fn_block;
unsigned int i, num_addresses;
struct at24_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))
+ return PTR_ERR(cdata);
+
+ err = device_property_read_u32(dev, "pagesize", &page_size);
+ if (err)
+ /*
+ * This is slow, but we can't know all eeproms, so we better
+ * play safe. Specifying custom eeprom-types via platform_data
+ * is recommended anyhow.
+ */
+ 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)
- return err;
+ 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))
return PTR_ERR(at24->wp_gpio);
- writable = !(pdata.flags & AT24_FLAG_READONLY);
+ writable = !(flags & AT24_FLAG_READONLY);
if (writable) {
at24->write_max = min_t(unsigned int,
- 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);
-
return 0;
err_clients:
diff --git a/include/linux/platform_data/at24.h b/include/linux/platform_data/at24.h
deleted file mode 100644
index 63507ff464ee..000000000000
--- a/include/linux/platform_data/at24.h
+++ /dev/null
@@ -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 */
--
2.18.0
^ permalink raw reply related
* [PATCH v2 28/29] ARM: davinci: mityomapl138: use device properties for at24 eeprom
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
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 <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
arch/arm/mach-davinci/board-mityomapl138.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index dacc5292f9bd..db50fcce5976 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -14,13 +14,13 @@
#include <linux/init.h>
#include <linux/console.h>
#include <linux/platform_device.h>
+#include <linux/property.h>
#include <linux/mtd/partitions.h>
#include <linux/notifier.h>
#include <linux/nvmem-consumer.h>
#include <linux/nvmem-provider.h>
#include <linux/regulator/machine.h>
#include <linux/i2c.h>
-#include <linux/platform_data/at24.h>
#include <linux/etherdevice.h>
#include <linux/spi/spi.h>
#include <linux/spi/flash.h>
@@ -185,10 +185,10 @@ static struct nvmem_cell_lookup mityomapl138_nvmem_cells[] = {
}
};
-static struct at24_platform_data mityomapl138_fd_chip = {
- .byte_len = 256,
- .page_size = 8,
- .flags = AT24_FLAG_READONLY | AT24_FLAG_IRUGO,
+static const struct property_entry mityomapl138_fd_chip_properties[] = {
+ PROPERTY_ENTRY_U32("pagesize", 8),
+ PROPERTY_ENTRY_BOOL("read-only"),
+ { }
};
static struct davinci_i2c_platform_data mityomap_i2c_0_pdata = {
@@ -317,7 +317,7 @@ static struct i2c_board_info __initdata mityomap_tps65023_info[] = {
},
{
I2C_BOARD_INFO("24c02", 0x50),
- .platform_data = &mityomapl138_fd_chip,
+ .properties = mityomapl138_fd_chip_properties,
},
};
--
2.18.0
^ permalink raw reply related
* [PATCH v2 27/29] ARM: davinci: mityomapl138: use nvmem notifiers
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Stop using the at24_platform_data setup callback in favor of nvmem
notifiers.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/board-mityomapl138.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 35b2b6068a7a..dacc5292f9bd 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -15,6 +15,8 @@
#include <linux/console.h>
#include <linux/platform_device.h>
#include <linux/mtd/partitions.h>
+#include <linux/notifier.h>
+#include <linux/nvmem-consumer.h>
#include <linux/nvmem-provider.h>
#include <linux/regulator/machine.h>
#include <linux/i2c.h>
@@ -116,10 +118,15 @@ static void mityomapl138_cpufreq_init(const char *partnum)
static void mityomapl138_cpufreq_init(const char *partnum) { }
#endif
-static void read_factory_config(struct nvmem_device *nvmem, void *context)
+static int read_factory_config(struct notifier_block *nb,
+ unsigned long event, void *data)
{
int ret;
const char *partnum = NULL;
+ struct nvmem_device *nvmem = data;
+
+ if (strcmp(nvmem_dev_name(nvmem), "1-00500") != 0)
+ return NOTIFY_DONE;
if (!IS_BUILTIN(CONFIG_NVMEM)) {
pr_warn("Factory Config not available without CONFIG_NVMEM\n");
@@ -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);
+
+ return NOTIFY_STOP;
}
+static struct notifier_block mityomapl138_nvmem_notifier = {
+ .notifier_call = read_factory_config,
+};
+
static struct nvmem_cell_lookup mityomapl138_nvmem_cells[] = {
{
.info = {
@@ -176,8 +189,6 @@ static struct at24_platform_data mityomapl138_fd_chip = {
.byte_len = 256,
.page_size = 8,
.flags = AT24_FLAG_READONLY | AT24_FLAG_IRUGO,
- .setup = read_factory_config,
- .context = NULL,
};
static struct davinci_i2c_platform_data mityomap_i2c_0_pdata = {
@@ -546,6 +557,7 @@ static void __init mityomapl138_init(void)
if (ret)
pr_warn("spi 1 registration failed: %d\n", ret);
+ nvmem_register_notifier(&mityomapl138_nvmem_notifier);
nvmem_add_lookup_table(mityomapl138_nvmem_cells,
ARRAY_SIZE(mityomapl138_nvmem_cells));
mityomapl138_config_emac();
--
2.18.0
^ permalink raw reply related
* [PATCH v2 26/29] ARM: davinci: remove dead code related to MAC address reading
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
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 <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/common.c | 15 ---------------
include/linux/davinci_emac.h | 2 --
2 files changed, 17 deletions(-)
diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
index bcb6a7ba84e9..0c6cc354a4aa 100644
--- a/arch/arm/mach-davinci/common.c
+++ b/arch/arm/mach-davinci/common.c
@@ -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;
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index 05b97144d342..19888b27706d 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -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
--
2.18.0
^ permalink raw reply related
* [PATCH v2 25/29] ARM: davinci: sffsdr: use device properties for at24 eeprom
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
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 <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
arch/arm/mach-davinci/board-sffsdr.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c
index f6a4d094cbc3..4f3bc78e8154 100644
--- a/arch/arm/mach-davinci/board-sffsdr.c
+++ b/arch/arm/mach-davinci/board-sffsdr.c
@@ -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)
--
2.18.0
^ permalink raw reply related
* [PATCH v2 24/29] ARM: davinci: sffsdr: fix the at24 eeprom device name
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
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 <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/board-sffsdr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c
index e7c1728b0833..f6a4d094cbc3 100644
--- a/arch/arm/mach-davinci/board-sffsdr.c
+++ b/arch/arm/mach-davinci/board-sffsdr.c
@@ -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:
--
2.18.0
^ permalink raw reply related
* [PATCH v2 23/29] ARM: davinci: dm646x-evm: use device properties for at24 eeprom
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
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 <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
arch/arm/mach-davinci/board-dm646x-evm.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index 943ab0ca6db8..04d293096962 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -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),
--
2.18.0
^ permalink raw reply related
* [PATCH v2 22/29] ARM: davinci: dm644x-evm: use device properties for at24 eeprom
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
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 <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
arch/arm/mach-davinci/board-dm644x-evm.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 829fa1c8d0b4..954296d23297 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -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,9 @@ 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 +598,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),
--
2.18.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox