* [PATCH 11/28] ARM: davinci: mityomapl138: add nvmem cells lookup entries
From: Bartosz Golaszewski @ 2018-08-08 15:31 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: <20180808153150.23444-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..b5be51c0451e 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -21,6 +21,7 @@
#include <linux/etherdevice.h>
#include <linux/spi/spi.h>
#include <linux/spi/flash.h>
+#include <linux/nvmem-provider.h>
#include <asm/io.h>
#include <asm/mach-types.h>
@@ -160,6 +161,25 @@ static void read_factory_config(struct nvmem_device *nvmem, void *context)
mityomapl138_cpufreq_init(partnum);
}
+static struct nvmem_cell_lookup mityomapl138_nvmem_cells[] = {
+ {
+ .info = {
+ .name = "factory-config",
+ .offset = 0x0,
+ .bytes = sizeof(struct factory_config),
+ },
+ .nvmem_name = "1-00500",
+ },
+ {
+ .info = {
+ .name = "mac-address",
+ .offset = 0x64,
+ .bytes = ETH_ALEN,
+ },
+ .nvmem_name = "1-00500",
+ }
+};
+
static struct at24_platform_data mityomapl138_fd_chip = {
.byte_len = 256,
.page_size = 8,
@@ -534,6 +554,8 @@ static void __init mityomapl138_init(void)
if (ret)
pr_warn("spi 1 registration failed: %d\n", ret);
+ nvmem_add_lookup_table(mityomapl138_nvmem_cells,
+ ARRAY_SIZE(mityomapl138_nvmem_cells));
mityomapl138_config_emac();
ret = da8xx_register_rtc();
--
2.18.0
^ permalink raw reply related
* [PATCH 09/28] ARM: davinci: dm646x-evm: use nvmem lookup for mac address
From: Bartosz Golaszewski @ 2018-08-08 15:31 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: <20180808153150.23444-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-dm646x-evm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index 584064fdabf5..5a9de47bc8a2 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -37,6 +37,7 @@
#include <linux/platform_data/i2c-davinci.h>
#include <linux/platform_data/mtd-davinci.h>
#include <linux/platform_data/mtd-davinci-aemif.h>
+#include <linux/nvmem-provider.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -310,6 +311,15 @@ static struct pcf857x_platform_data pcf_data = {
* - ... newer boards may have more
*/
+static struct nvmem_cell_lookup dm646x_evm_mac_address_cell = {
+ .info = {
+ .name = "mac-address",
+ .offset = 0x7f00,
+ .bytes = ETH_ALEN,
+ },
+ .nvmem_name = "1-00500",
+};
+
static struct at24_platform_data eeprom_info = {
.byte_len = (256*1024) / 8,
.page_size = 64,
@@ -802,6 +812,8 @@ static __init void evm_init(void)
davinci_init_ide();
soc_info->emac_pdata->phy_id = DM646X_EVM_PHY_ID;
+
+ nvmem_add_lookup_table(&dm646x_evm_mac_address_cell, 1);
}
MACHINE_START(DAVINCI_DM6467_EVM, "DaVinci DM646x EVM")
--
2.18.0
^ permalink raw reply related
* [PATCH 08/28] ARM: davinci: dm644-evm: use nvmem lookup for mac address
From: Bartosz Golaszewski @ 2018-08-08 15:31 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,
Florian Fainelli, Ivan Khoronzhuk, Sven Van Asbroeck
Cc: linux-doc, netdev, linux-kernel, Bartosz Golaszewski, linux-mtd,
linux-i2c, linux-omap, linux-arm-kernel
In-Reply-To: <20180808153150.23444-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-dm644x-evm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 48436f74fd71..6d35c6e1b0bd 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -28,6 +28,7 @@
#include <linux/v4l2-dv-timings.h>
#include <linux/export.h>
#include <linux/leds.h>
+#include <linux/nvmem-provider.h>
#include <media/i2c/tvp514x.h>
@@ -476,6 +477,15 @@ static struct pcf857x_platform_data pcf_data_u35 = {
* - ... newer boards may have more
*/
+static struct nvmem_cell_lookup dm6446evm_mac_address_cell = {
+ .info = {
+ .name = "mac-address",
+ .offset = 0x7f00,
+ .bytes = ETH_ALEN,
+ },
+ .nvmem_name = "1-00500",
+};
+
static struct at24_platform_data eeprom_info = {
.byte_len = (256*1024) / 8,
.page_size = 64,
@@ -828,6 +838,8 @@ static __init void davinci_evm_init(void)
phy_register_fixup_for_uid(LXT971_PHY_ID, LXT971_PHY_MASK,
davinci_phy_fixup);
}
+
+ nvmem_add_lookup_table(&dm6446evm_mac_address_cell, 1);
}
MACHINE_START(DAVINCI_EVM, "DaVinci DM644x EVM")
--
2.18.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related
* [PATCH 07/28] ARM: davinci: dm365-evm: use nvmem lookup for mac address
From: Bartosz Golaszewski @ 2018-08-08 15:31 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: <20180808153150.23444-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-dm365-evm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index 435f7ec7d9af..cb0ac92a278e 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -28,6 +28,7 @@
#include <linux/spi/spi.h>
#include <linux/spi/eeprom.h>
#include <linux/v4l2-dv-timings.h>
+#include <linux/nvmem-provider.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -169,6 +170,15 @@ static struct platform_device davinci_nand_device = {
},
};
+static struct nvmem_cell_lookup dm365evm_mac_address_cell = {
+ .info = {
+ .name = "mac-address",
+ .offset = 0x7f00,
+ .bytes = ETH_ALEN,
+ },
+ .nvmem_name = "1-00500",
+};
+
static struct at24_platform_data eeprom_info = {
.byte_len = (256*1024) / 8,
.page_size = 64,
@@ -769,6 +779,8 @@ static __init void dm365_evm_init(void)
dm365_init_spi0(BIT(0), dm365_evm_spi_info,
ARRAY_SIZE(dm365_evm_spi_info));
+
+ nvmem_add_lookup_table(&dm365evm_mac_address_cell, 1);
}
MACHINE_START(DAVINCI_DM365_EVM, "DaVinci DM365 EVM")
--
2.18.0
^ permalink raw reply related
* [PATCH 06/28] mtd: Add support for reading MTD devices via the nvmem API
From: Bartosz Golaszewski @ 2018-08-08 15:31 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: <20180808153150.23444-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.
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 <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 05/28] nvmem: remove the name field from struct nvmem_device
From: Bartosz Golaszewski @ 2018-08-08 15:31 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: <20180808153150.23444-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_device_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 b040370292a7..6c825ce866b6 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_device_name(nvmem));
mutex_lock(&nvmem_mutex);
nvmem->users--;
--
2.18.0
^ permalink raw reply related
* [PATCH 04/28] nvmem: provide nvmem_device_name()
From: Bartosz Golaszewski @ 2018-08-08 15:31 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,
Florian Fainelli, Ivan Khoronzhuk, Sven Van Asbroeck
Cc: linux-doc, netdev, linux-kernel, Bartosz Golaszewski, linux-mtd,
linux-i2c, linux-omap, linux-arm-kernel
In-Reply-To: <20180808153150.23444-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..b040370292a7 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_device_name(struct nvmem_device *nvmem)
+{
+ return dev_name(&nvmem->dev);
+}
+EXPORT_SYMBOL_GPL(nvmem_device_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..c4000a218f67 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_device_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_device_name(struct nvmem_device *nvmem)
+{
+ return ERR_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/
^ permalink raw reply related
* [PATCH 03/28] nvmem: add a notifier chain
From: Bartosz Golaszewski @ 2018-08-08 15:31 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: <20180808153150.23444-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
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 <bgolaszewski@baylibre.com>
---
drivers/nvmem/core.c | 20 ++++++++++++++++++++
include/linux/nvmem-consumer.h | 18 ++++++++++++++++++
2 files changed, 38 insertions(+)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 329ea5b8f809..128c8e51bff2 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -65,6 +65,8 @@ static DEFINE_MUTEX(nvmem_cells_mutex);
static LIST_HEAD(nvmem_cell_lookups);
static DEFINE_MUTEX(nvmem_lookup_mutex);
+static BLOCKING_NOTIFIER_HEAD(nvmem_notifier);
+
#ifdef CONFIG_DEBUG_LOCK_ALLOC
static struct lock_class_key eeprom_lock_key;
#endif
@@ -479,6 +481,18 @@ static int nvmem_setup_compat(struct nvmem_device *nvmem,
return 0;
}
+int nvmem_register_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(&nvmem_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(nvmem_register_notifier);
+
+int nvmem_unregister_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(&nvmem_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(nvmem_unregister_notifier);
+
/**
* nvmem_register() - Register a nvmem device for given nvmem_config.
* Also creates an binary entry in /sys/bus/nvmem/devices/dev-name/nvmem
@@ -559,6 +573,10 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
if (config->cells)
nvmem_add_cells(nvmem, config->cells, config->ncells);
+ rval = blocking_notifier_call_chain(&nvmem_notifier, NVMEM_ADD, nvmem);
+ if (rval)
+ goto err_device_del;
+
return nvmem;
err_device_del:
@@ -586,6 +604,8 @@ int nvmem_unregister(struct nvmem_device *nvmem)
}
mutex_unlock(&nvmem_mutex);
+ blocking_notifier_call_chain(&nvmem_notifier, NVMEM_REMOVE, nvmem);
+
if (nvmem->flags & FLAG_COMPAT)
device_remove_bin_file(nvmem->base_dev, &nvmem->eeprom);
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index f4b5d3186e94..ae4d30347602 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -14,6 +14,7 @@
#include <linux/err.h>
#include <linux/errno.h>
+#include <linux/notifier.h>
struct device;
struct device_node;
@@ -35,6 +36,11 @@ struct nvmem_cell_lookup {
const char *nvmem_name;
};
+enum {
+ NVMEM_ADD = 1,
+ NVMEM_REMOVE,
+};
+
#if IS_ENABLED(CONFIG_NVMEM)
/* Cell based interface */
@@ -61,6 +67,8 @@ ssize_t nvmem_device_cell_read(struct nvmem_device *nvmem,
int nvmem_device_cell_write(struct nvmem_device *nvmem,
struct nvmem_cell_info *info, void *buf);
+int nvmem_register_notifier(struct notifier_block *nb);
+int nvmem_unregister_notifier(struct notifier_block *nb);
#else
static inline struct nvmem_cell *nvmem_cell_get(struct device *dev,
@@ -149,6 +157,16 @@ static inline int nvmem_device_write(struct nvmem_device *nvmem,
{
return -ENOSYS;
}
+
+static inline int nvmem_register_notifier(struct notifier_block *nb)
+{
+ return -ENOSYS;
+}
+
+static inline int int nvmem_unregister_notifier(struct notifier_block *nb)
+{
+ return -ENOSYS;
+}
#endif /* CONFIG_NVMEM */
#if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
--
2.18.0
^ permalink raw reply related
* [PATCH 02/28] Documentation: nvmem: document lookup entries
From: Bartosz Golaszewski @ 2018-08-08 15:31 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: <20180808153150.23444-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Describe the usage of nvmem cell lookup tables.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
Documentation/nvmem/nvmem.txt | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/Documentation/nvmem/nvmem.txt b/Documentation/nvmem/nvmem.txt
index 8d8d8f58f96f..9d5e3ca2b4f3 100644
--- a/Documentation/nvmem/nvmem.txt
+++ b/Documentation/nvmem/nvmem.txt
@@ -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
+++++++++++++++
--
2.18.0
^ permalink raw reply related
* [PATCH 01/28] nvmem: add support for cell lookups
From: Bartosz Golaszewski @ 2018-08-08 15:31 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,
Florian Fainelli, Ivan Khoronzhuk, Sven Van Asbroeck
Cc: linux-doc, netdev, linux-kernel, Bartosz Golaszewski, linux-mtd,
linux-i2c, linux-omap, linux-arm-kernel
In-Reply-To: <20180808153150.23444-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
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 <bgolaszewski@baylibre.com>
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
drivers/nvmem/core.c | 77 +++++++++++++++++++++++++++++++++-
include/linux/nvmem-consumer.h | 6 +++
include/linux/nvmem-provider.h | 10 +++++
3 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 514d1dfc5630..329ea5b8f809 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -62,6 +62,9 @@ static DEFINE_IDA(nvmem_ida);
static LIST_HEAD(nvmem_cells);
static DEFINE_MUTEX(nvmem_cells_mutex);
+static LIST_HEAD(nvmem_cell_lookups);
+static DEFINE_MUTEX(nvmem_lookup_mutex);
+
#ifdef CONFIG_DEBUG_LOCK_ALLOC
static struct lock_class_key eeprom_lock_key;
#endif
@@ -247,6 +250,41 @@ static const struct attribute_group *nvmem_ro_root_dev_groups[] = {
NULL,
};
+/**
+ * nvmem_add_lookup_table() - register a number of nvmem cell lookup entries
+ *
+ * @lookup: array of nvmem cell lookup entries
+ * @nentries: number of lookup entries in the array
+ */
+void nvmem_add_lookup_table(struct nvmem_cell_lookup *lookup, size_t nentries)
+{
+ int i;
+
+ mutex_lock(&nvmem_lookup_mutex);
+ for (i = 0; i < nentries; i++)
+ list_add_tail(&lookup[i].list, &nvmem_cell_lookups);
+ mutex_unlock(&nvmem_lookup_mutex);
+}
+EXPORT_SYMBOL_GPL(nvmem_add_lookup_table);
+
+/**
+ * nvmem_del_lookup_table() - unregister a set of previously added nvmem cell
+ * lookup entries
+ *
+ * @lookup: array of nvmem cell lookup entries
+ * @nentries: number of lookup entries in the array
+ */
+void nvmem_del_lookup_table(struct nvmem_cell_lookup *lookup, size_t nentries)
+{
+ int i;
+
+ mutex_lock(&nvmem_lookup_mutex);
+ for (i = 0; i < nentries; i++)
+ list_del(&lookup[i].list);
+ mutex_unlock(&nvmem_lookup_mutex);
+}
+EXPORT_SYMBOL_GPL(nvmem_del_lookup_table);
+
static void nvmem_release(struct device *dev)
{
struct nvmem_device *nvmem = to_nvmem_device(dev);
@@ -916,6 +954,39 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
EXPORT_SYMBOL_GPL(of_nvmem_cell_get);
#endif
+static struct nvmem_cell *nvmem_cell_from_lookup(const char *cell_id)
+{
+ struct nvmem_cell *cell = ERR_PTR(-ENOENT);
+ struct nvmem_cell_lookup *lookup;
+ struct nvmem_device *nvmem;
+ int rc;
+
+ mutex_lock(&nvmem_lookup_mutex);
+
+ list_for_each_entry(lookup, &nvmem_cell_lookups, list) {
+ if (strcmp(cell_id, lookup->info.name) == 0) {
+ nvmem = nvmem_find(lookup->nvmem_name);
+ if (!nvmem) {
+ cell = ERR_PTR(-EPROBE_DEFER);
+ goto out;
+ }
+
+ rc = nvmem_add_cells(nvmem, &lookup->info, 1);
+ if (rc) {
+ cell = ERR_PTR(rc);
+ goto out;
+ }
+
+ cell = nvmem_cell_get_from_list(cell_id);
+ break;
+ }
+ }
+
+out:
+ mutex_unlock(&nvmem_lookup_mutex);
+ return cell;
+}
+
/**
* nvmem_cell_get() - Get nvmem cell of device form a given cell name
*
@@ -940,7 +1011,11 @@ struct nvmem_cell *nvmem_cell_get(struct device *dev, const char *cell_id)
if (!cell_id)
return ERR_PTR(-EINVAL);
- return nvmem_cell_get_from_list(cell_id);
+ cell = nvmem_cell_get_from_list(cell_id);
+ if (!IS_ERR(cell) || PTR_ERR(cell) == -EPROBE_DEFER)
+ return cell;
+
+ return nvmem_cell_from_lookup(cell_id);
}
EXPORT_SYMBOL_GPL(nvmem_cell_get);
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index 4e85447f7860..f4b5d3186e94 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -29,6 +29,12 @@ struct nvmem_cell_info {
unsigned int nbits;
};
+struct nvmem_cell_lookup {
+ struct nvmem_cell_info info;
+ struct list_head list;
+ const char *nvmem_name;
+};
+
#if IS_ENABLED(CONFIG_NVMEM)
/* Cell based interface */
diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
index 24def6ad09bb..6a17d722062b 100644
--- a/include/linux/nvmem-provider.h
+++ b/include/linux/nvmem-provider.h
@@ -17,6 +17,7 @@
struct nvmem_device;
struct nvmem_cell_info;
+struct nvmem_cell_lookup;
typedef int (*nvmem_reg_read_t)(void *priv, unsigned int offset,
void *val, size_t bytes);
typedef int (*nvmem_reg_write_t)(void *priv, unsigned int offset,
@@ -72,6 +73,9 @@ struct nvmem_config {
struct nvmem_device *nvmem_register(const struct nvmem_config *cfg);
int nvmem_unregister(struct nvmem_device *nvmem);
+void nvmem_add_lookup_table(struct nvmem_cell_lookup *lookup, size_t nentries);
+void nvmem_del_lookup_table(struct nvmem_cell_lookup *lookup, size_t nentries);
+
struct nvmem_device *devm_nvmem_register(struct device *dev,
const struct nvmem_config *cfg);
@@ -92,6 +96,12 @@ static inline int nvmem_unregister(struct nvmem_device *nvmem)
return -ENOSYS;
}
+static inline void
+nvmem_add_lookup_table(struct nvmem_cell_lookup *lookup, size_t nentries) {}
+
+static inline void
+nvmem_del_lookup_table(struct nvmem_cell_lookup *lookup, size_t nentries) {}
+
static inline struct nvmem_device *
devm_nvmem_register(struct device *dev, const struct nvmem_config *c)
{
--
2.18.0
^ permalink raw reply related
* [PATCH 00/28] at24: remove at24_platform_data
From: Bartosz Golaszewski @ 2018-08-08 15:31 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
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
^ permalink raw reply
* Re: [PATCH iproute2] tc: bpf: update list of archs with eBPF support in manpage
From: Daniel Borkmann @ 2018-08-08 13:10 UTC (permalink / raw)
To: Tobias Klauser, netdev; +Cc: stephen
In-Reply-To: <20180808123340.18446-1-tklauser@distanz.ch>
On 08/08/2018 02:33 PM, Tobias Klauser wrote:
> Update the list of architectures supporting eBPF JIT as of Linux 4.18.
> Also mention the Linux version where support for a particular
> architecture was introduced. Finally, reformat the list of architectures
> as a bullet list in order to make it more readable.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Thanks, Tobias!
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: Is it currently possible to connect SFP to dsa port?
From: Marek Behún @ 2018-08-08 13:00 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Russell King - ARM Linux
In-Reply-To: <20180807195820.GA7275@lunn.ch>
On Tue, 7 Aug 2018 21:58:20 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
> Hi Marek
>
> I'm currently working on exactly this!
>
> My primary aim is to allow SFP on ports 9 and 10. ports 2-7 can also
> be connected to SFPs, but that is a bit harder, so it is going to take
> me a little longer.
>
> I hope i can post patches in the next few days.
>
> Andrew
Hi, this is cool :-) On our board it will be possible to connect
SFP extender board to port 10, and I was afraid it might have been me
to write the support for this :).
Let me know when you have the first version ready, I will try it. Our
router can connect SFP board directly to the CPU board, or there may up
to three mv88e6190 switch boards between SFP board and cpu board.
Do you already have a stable dts binding for how to bind sfp to dsa
port?
Btw: some SFP modules can operate in 2500BASE-X mode. Currently the SFP
driver does not support this, and there even isn't code in the
mainline kernel for mvneta to switch to 2500BASEX. On Armada 3720 this
has to be done by configuring comphy, which is currently done in
u-boot. As a side project I am working on supporting Armada 3720 comphy
in the kernel, so that it will be possible to set 2500BASE-X mode.
The mv88e6190/6390 can configure ports 9 and 10 to either
1000BASE-X/SGMII od 2500BASE-X, but this has to be done by setting a
pin and reseting the switch. Our board is able to configure this pin,
and the plan is to do this in u-boot when SFP board is detected to be
connected to the switch board. In this case the port is configured to
1000BASE-X.
I am wondering how complicated would it be to support changing these
modes for port 9 and 10 in mv88exxxx driver. There could be GPIO port
definitions in devicetree for P9_MODE and P10_MODE (and RESET), and
then the driver would be able to change these modes.
Since the switch has to be reseted to change the mode I think all the
dsa lan ports would have to be unused when doing this, correct?
And still how more complicated would it be if for example the RESET
gpio is shared between multiple switches, while the P9_MODE and
P10_MODE gpios are unique for each switch, like this:
RESET-----+--------+--------+
| | |
+-----+ +--+--+ +--+--+ +--+--+ +-----+
| cpu |==| sw1 |==| sw2 |==| sw3 |==| sfp |
+-----+ +-+-+-+ +-+-+-+ +-+-+-+ +-----+
| | | | | |
P9_MODE[1]--+ | | | | |
P10_MODE[1]----+ | | | | == means SGMII/2500BASE-X
P9_MODE[2]-----------+ | | | connection
P10_MODE[2]-------------+ | |
P9_MODE[3]--------------------+ |
P10_MODE[3]----------------------+
Marek
^ permalink raw reply
* Re: [PATCH] net: dsa: rtl8366rb: Support port 4 (WAN)
From: Andrew Lunn @ 2018-08-08 12:57 UTC (permalink / raw)
To: Linus Walleij
Cc: Vivien Didelot, Florian Fainelli, netdev, openwrt-devel,
LEDE Development List
In-Reply-To: <20180808123855.18729-1-linus.walleij@linaro.org>
On Wed, Aug 08, 2018 at 02:38:55PM +0200, Linus Walleij wrote:
> The totally undocumented IO mode needs to be set to enumerator
> 0 to enable port 4 also known as WAN in most configurations,
> for ordinary traffic. The 3 bits in the register come up as
> 010 after reset, but need to be set to 000.
>
> The Realtek source code contains a name for these bits, but
> no explanation of what the 8 different IO modes may be.
Hi Linus
I'm guessing this is MII, RMII, GMII, RGMII etc.
If it is, using phy-mode would be good. But that can wait until we
actually know.
> Set it to zero for the time being and drop a comment so
> people know what is going on if they run into trouble. This
> "mode zero" works fine with the D-Link DIR-685 with
> RTL8366RB.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH lora-next 01/10] net: lora: sx1301: add register, bit-fields, and helpers for regmap
From: Andreas Färber @ 2018-08-08 12:51 UTC (permalink / raw)
To: Ben Whitten, Ben Whitten
Cc: starnight@g.ncu.edu.tw, hasnain.virk@arm.com,
netdev@vger.kernel.org
In-Reply-To: <BY1PR02MB11148226468391B114163BDAE7260@BY1PR02MB1114.namprd02.prod.outlook.com>
Am 08.08.2018 um 14:32 schrieb Ben Whitten:
>>> drivers/net/lora/Kconfig | 1 +
>>> drivers/net/lora/sx1301.c | 282
>> +++++++++++++++++++++++++++++++++++++++++++---
>>> drivers/net/lora/sx1301.h | 169
>> +++++++++++++++++++++++++++
>>> 3 files changed, 439 insertions(+), 13 deletions(-)
>>> create mode 100644 drivers/net/lora/sx1301.h
>>
>> My main concern about this patch is its sheer size. Normally
>> for
>> #defines the rule is not to add unused ones. Here I see for
>> example FSK
>> RSSI fields that we're surely not using yet. Any chance to
>> strip this
>> down some more?
>
> Sure, I'll strip the reg_fields down to those only required for
> loading firmware and setting clocks that will be used in the
> immediate term. This does clutter the driver a bit
> unnecessarily at the moment.
> I would like to keep the full register dump in the header file
> though as its self-contained and gives a full picture of the chip.
Could you do that in more steps though? I'm thinking, convert only the
registers in use to regmap (that'll make it easier to review), then add
more registers, then convert to regmap fields?
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: spectrum_flower: use PTR_ERR_OR_ZERO()
From: Ido Schimmel @ 2018-08-08 15:08 UTC (permalink / raw)
To: YueHaibing; +Cc: davem, jiri, linux-kernel, netdev
In-Reply-To: <20180808122908.13664-1-yuehaibing@huawei.com>
On Wed, Aug 08, 2018 at 08:29:08PM +0800, YueHaibing wrote:
> Fix ptr_ret.cocci warnings:
> drivers/net/ethernet/mellanox/mlxsw/spectrum_flower.c:543:1-3: WARNING: PTR_ERR_OR_ZERO can be used
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Thanks!
^ permalink raw reply
* [PATCH] net: dsa: rtl8366rb: Support port 4 (WAN)
From: Linus Walleij @ 2018-08-08 12:38 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli
Cc: netdev, openwrt-devel, LEDE Development List, Linus Walleij
The totally undocumented IO mode needs to be set to enumerator
0 to enable port 4 also known as WAN in most configurations,
for ordinary traffic. The 3 bits in the register come up as
010 after reset, but need to be set to 000.
The Realtek source code contains a name for these bits, but
no explanation of what the 8 different IO modes may be.
Set it to zero for the time being and drop a comment so
people know what is going on if they run into trouble. This
"mode zero" works fine with the D-Link DIR-685 with
RTL8366RB.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/net/dsa/rtl8366rb.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/net/dsa/rtl8366rb.c b/drivers/net/dsa/rtl8366rb.c
index 1e55b9bf8b56..a4d5049df692 100644
--- a/drivers/net/dsa/rtl8366rb.c
+++ b/drivers/net/dsa/rtl8366rb.c
@@ -48,6 +48,23 @@
#define RTL8366RB_SSCR2 0x0004
#define RTL8366RB_SSCR2_DROP_UNKNOWN_DA BIT(0)
+/* Port Mode Control registers */
+#define RTL8366RB_PMC0 0x0005
+#define RTL8366RB_PMC0_SPI BIT(0)
+#define RTL8366RB_PMC0_EN_AUTOLOAD BIT(1)
+#define RTL8366RB_PMC0_PROBE BIT(2)
+#define RTL8366RB_PMC0_DIS_BISR BIT(3)
+#define RTL8366RB_PMC0_ADCTEST BIT(4)
+#define RTL8366RB_PMC0_SRAM_DIAG BIT(5)
+#define RTL8366RB_PMC0_EN_SCAN BIT(6)
+#define RTL8366RB_PMC0_P4_IOMODE_SHIFT 7
+#define RTL8366RB_PMC0_P4_IOMODE_MASK GENMASK(9, 7)
+#define RTL8366RB_PMC0_P5_IOMODE_SHIFT 10
+#define RTL8366RB_PMC0_P5_IOMODE_MASK GENMASK(12, 10)
+#define RTL8366RB_PMC0_SDSMODE_SHIFT 13
+#define RTL8366RB_PMC0_SDSMODE_MASK GENMASK(15, 13)
+#define RTL8366RB_PMC1 0x0006
+
/* Port Mirror Control Register */
#define RTL8366RB_PMCR 0x0007
#define RTL8366RB_PMCR_SOURCE_PORT(a) (a)
@@ -860,6 +877,19 @@ static int rtl8366rb_setup(struct dsa_switch *ds)
if (ret)
return ret;
+ /* Port 4 setup: this enables Port 4, usually the WAN port,
+ * common PHY IO mode is apparently mode 0, and this is not what
+ * the port is initialized to. There is no explanation of the
+ * IO modes in the Realtek source code, if your WAN port is
+ * connected to something exotic such as fiber, then this might
+ * be worth experimenting with.
+ */
+ ret = regmap_update_bits(smi->map, RTL8366RB_PMC0,
+ RTL8366RB_PMC0_P4_IOMODE_MASK,
+ 0 << RTL8366RB_PMC0_P4_IOMODE_SHIFT);
+ if (ret)
+ return ret;
+
/* Discard VLAN tagged packets if the port is not a member of
* the VLAN with which the packets is associated.
*/
--
2.17.1
^ permalink raw reply related
* [PATCH iproute2] tc: bpf: update list of archs with eBPF support in manpage
From: Tobias Klauser @ 2018-08-08 12:33 UTC (permalink / raw)
To: netdev; +Cc: stephen, daniel
Update the list of architectures supporting eBPF JIT as of Linux 4.18.
Also mention the Linux version where support for a particular
architecture was introduced. Finally, reformat the list of architectures
as a bullet list in order to make it more readable.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
man/man8/tc-bpf.8 | 37 +++++++++++++++++++++++++++++++++----
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/man/man8/tc-bpf.8 b/man/man8/tc-bpf.8
index d311f295615b..b2f9344f5e28 100644
--- a/man/man8/tc-bpf.8
+++ b/man/man8/tc-bpf.8
@@ -79,10 +79,39 @@ In Linux, it's generally considered that eBPF is the successor of cBPF.
The kernel internally transforms cBPF expressions into eBPF expressions and
executes the latter. Execution of them can be performed in an interpreter
or at setup time, they can be just-in-time compiled (JIT'ed) to run as
-native machine code. Currently, x86_64, ARM64, s390, ppc64 and sparc64
-architectures have eBPF JIT support, whereas PPC, SPARC, ARM and MIPS have
-cBPF, but did not (yet) switch to eBPF JIT support.
-
+native machine code.
+.PP
+Currently, the eBPF JIT compiler is available for the following architectures:
+.IP * 4
+x86_64 (since Linux 3.18)
+.PD 0
+.IP *
+arm64 (since Linux 3.18)
+.IP *
+s390 (since Linux 4.1)
+.IP *
+ppc64 (since Linux 4.8)
+.IP *
+sparc64 (since Linux 4.12)
+.IP *
+mips64 (since Linux 4.13)
+.IP *
+arm32 (since Linux 4.14)
+.IP *
+x86_32 (since Linux 4.18)
+.PD
+.PP
+Whereas the following architectures have cBPF, but did not (yet) switch to eBPF
+JIT support:
+.IP * 4
+ppc32
+.PD 0
+.IP *
+sparc32
+.IP *
+mips32
+.PD
+.PP
eBPF's instruction set has similar underlying principles as the cBPF
instruction set, it however is modelled closer to the underlying
architecture to better mimic native instruction sets with the aim to
--
2.18.0.130.g98da2f6b3e4a
^ permalink raw reply related
* Re: [PATCH net-next 13/14] net: core: add new/replace rate estimator lock parameter
From: Vlad Buslov @ 2018-08-08 12:30 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: netdev, davem, jhs, xiyou.wangcong, jiri, pablo, kadlec, fw, ast,
daniel, edumazet, keescook
In-Reply-To: <20180808013724.GE14666@localhost.localdomain>
On Wed 08 Aug 2018 at 01:37, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote:
> On Mon, Aug 06, 2018 at 09:54:24AM +0300, Vlad Buslov wrote:
>> Extend rate estimator 'new' and 'replace' APIs with additional spinlock
>> parameter to be used by rtnl-unlocked actions to protect rate_est pointer
>> from concurrent modification.
>
> I'm wondering if this additional parameter is really needed. So far,
> the only case in which it is not NULL, the same lock that is used to
> protect the stats is also used in this new parameter.
>
> ...
>
>> --- a/net/sched/act_police.c
>> +++ b/net/sched/act_police.c
>> @@ -138,7 +138,7 @@ static int tcf_act_police_init(struct net *net, struct nlattr *nla,
>>
>> if (est) {
>> err = gen_replace_estimator(&police->tcf_bstats, NULL,
>> - &police->tcf_rate_est,
>> + &police->tcf_rate_est, NULL,
>> &police->tcf_lock,
>> NULL, est);
>
> Which is here, and this new NULL arg is replaced by &police->tcf_lock
> in the next patch.
>
> Do you foresee a case in which a different lock will be used?
Not in my use-case, no.
> Or maybe it is because the current one is explicitly aimed towards the
> stats?
Yes, stats lock is only taken when fetching counters. You think better
approach would be to rely on the fact that, in case of police action,
same lock is already passed as stats lock? Having it as standalone
argument looked like cleaner approach to me. If you think this change is
too much code for very little benefit, I can reuse stats lock.
>
> Marcelo
Thank you for reviewing my code!
^ permalink raw reply
* RE: [PATCH lora-next 01/10] net: lora: sx1301: add register, bit-fields, and helpers for regmap
From: Ben Whitten @ 2018-08-08 12:32 UTC (permalink / raw)
To: Andreas Färber, Ben Whitten
Cc: starnight@g.ncu.edu.tw, hasnain.virk@arm.com,
netdev@vger.kernel.org
In-Reply-To: <6faee71e-1226-9f24-6e0d-46a9dbb4d6c2@suse.de>
> Subject: Re: [PATCH lora-next 01/10] net: lora: sx1301: add
> register, bit-fields, and helpers for regmap
>
> Am 07.08.2018 um 19:32 schrieb Ben Whitten:
> > From: Ben Whitten <ben.whitten@lairdtech.com>
> >
> > The register and bit-field definitions are taken from the
> SX1301
> > datasheet version 2.01 dated June 2014 with the revision
> information
> > 'First released version'.
> >
> > The reset state and RW capability of each field is not
> reflected in this
> > patch however from the datasheet:
> > "Bits and registers that are not documented are reserved.
> They may
> > include calibration values. It is important not to modify
> these bits and
> > registers. If specific bits must be changed in a register with
> reserved
> > bits, the register must be read first, specific bits modified
> while
> > masking reserved bits and then the register can be
> written."
> >
> > Then goes on to state:
> > "Reserved bits should be written with their reset state,
> they may be
> > read different states."
> >
> > Caching is currently disabled.
> >
> > The version is read back using regmap_read to verify
> regmap operation,
> > in doing so needs to be moved after priv and regmap
> allocation.
> >
> > Signed-off-by: Ben Whitten
> <ben.whitten@lairdtech.com>
> > ---
> > drivers/net/lora/Kconfig | 1 +
> > drivers/net/lora/sx1301.c | 282
> +++++++++++++++++++++++++++++++++++++++++++---
> > drivers/net/lora/sx1301.h | 169
> +++++++++++++++++++++++++++
> > 3 files changed, 439 insertions(+), 13 deletions(-)
> > create mode 100644 drivers/net/lora/sx1301.h
>
> My main concern about this patch is its sheer size. Normally
> for
> #defines the rule is not to add unused ones. Here I see for
> example FSK
> RSSI fields that we're surely not using yet. Any chance to
> strip this
> down some more?
Sure, I'll strip the reg_fields down to those only required for
loading firmware and setting clocks that will be used in the
immediate term. This does clutter the driver a bit
unnecessarily at the moment.
I would like to keep the full register dump in the header file
though as its self-contained and gives a full picture of the chip.
Thanks,
Ben
^ permalink raw reply
* Re: [PATCH net-next 5/5] net: aquantia: bump driver version
From: Andrew Lunn @ 2018-08-08 12:32 UTC (permalink / raw)
To: Igor Russkikh; +Cc: David S . Miller, netdev
In-Reply-To: <5ad3aff3900698f8b27c7bb327427256ae847241.1533650064.git.igor.russkikh@aquantia.com>
On Wed, Aug 08, 2018 at 01:57:15PM +0300, Igor Russkikh wrote:
> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
> ---
> drivers/net/ethernet/aquantia/atlantic/ver.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/aquantia/atlantic/ver.h b/drivers/net/ethernet/aquantia/atlantic/ver.h
> index 94efc64..b482601 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/ver.h
> +++ b/drivers/net/ethernet/aquantia/atlantic/ver.h
> @@ -12,7 +12,7 @@
>
> #define NIC_MAJOR_DRIVER_VERSION 2
> #define NIC_MINOR_DRIVER_VERSION 0
> -#define NIC_BUILD_DRIVER_VERSION 3
> +#define NIC_BUILD_DRIVER_VERSION 4
> #define NIC_REVISION_DRIVER_VERSION 0
>
> #define AQ_CFG_DRV_VERSION_SUFFIX "-kern"
Hi Igor
Driver versions are pretty much useless. Say somebody backports this
driver into a vendor kernel. Vendor kernels are typically based on an
old kernel, plus thousands of patches. Is 2.0.4 on such a kernel the
same as 2.0.4 in 4.19?
You probably want to remove this, just the avoid people thinking is
means something.
Andrew
^ permalink raw reply
* [PATCH] net: macb: do not disable MDIO bus when closing interface
From: Anssi Hannula @ 2018-08-08 12:19 UTC (permalink / raw)
To: Nicolas Ferre, David S. Miller; +Cc: netdev
macb_close() calls macb_reset_hw() which zeroes NCR register, including
the MPE (Management Port Enable) bit.
This will prevent accessing any other PHYs for other Ethernet MACs on
the MDIO bus which is still registered.
Fix that by keeping the MPE bit set.
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
---
drivers/net/ethernet/cadence/macb_main.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index dc09f9a8a49b..3ca98fc32144 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -2030,12 +2030,13 @@ static void macb_reset_hw(struct macb *bp)
unsigned int q;
/* Disable RX and TX (XXX: Should we halt the transmission
- * more gracefully?)
+ * more gracefully?) but keep management port open since there
+ * may be other users of the mdio bus
*/
- macb_writel(bp, NCR, 0);
+ macb_writel(bp, NCR, MACB_BIT(MPE));
/* Clear the stats registers (XXX: Update stats first?) */
- macb_writel(bp, NCR, MACB_BIT(CLRSTAT));
+ macb_writel(bp, NCR, MACB_BIT(CLRSTAT) | MACB_BIT(MPE));
/* Clear all status flags */
macb_writel(bp, TSR, -1);
--
2.16.3
^ permalink raw reply related
* Re: [PATCH net-next 4/5] net: aquantia: implement EEE support
From: Andrew Lunn @ 2018-08-08 12:27 UTC (permalink / raw)
To: Igor Russkikh; +Cc: David S . Miller, netdev, Yana Esina, Nikita Danilov
In-Reply-To: <3e548f24d79bc03a14e3b8cdb6708c5db6a61cc4.1533650064.git.igor.russkikh@aquantia.com>
> +static int aq_ethtool_get_eee(struct net_device *ndev, struct ethtool_eee *eee)
> +{
> + struct aq_nic_s *aq_nic = netdev_priv(ndev);
> + int err = 0;
> +
> + u32 rate, supported_rates;
Please keep all local variables together and sort them as reverse
christmas tree. This should apply to all new code you are adding.
> index 3c94cff..a021dc4 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_a0_internal.h
> +++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_a0_internal.h
> @@ -62,12 +62,6 @@
> #define HW_ATL_A0_MPI_SPEED_MSK 0xFFFFU
> #define HW_ATL_A0_MPI_SPEED_SHIFT 16U
>
> -#define HW_ATL_A0_RATE_10G BIT(0)
> -#define HW_ATL_A0_RATE_5G BIT(1)
> -#define HW_ATL_A0_RATE_2G5 BIT(3)
> -#define HW_ATL_A0_RATE_1G BIT(4)
> -#define HW_ATL_A0_RATE_100M BIT(5)
> -
> #define HW_ATL_A0_TXBUF_MAX 160U
> #define HW_ATL_A0_RXBUF_MAX 320U
>
> diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
> index 0ad6ac5..7bd1bea 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
> @@ -40,6 +40,11 @@
> #define HW_ATL_FW2X_CTRL_ASYMMETRIC_PAUSE BIT(CTRL_ASYMMETRIC_PAUSE)
> #define HW_ATL_FW2X_CTRL_FORCE_RECONNECT BIT(CTRL_FORCE_RECONNECT)
>
> +#define HW_ATL_FW2X_CAP_EEE_1G_MASK BIT(CAPS_HI_1000BASET_FD_EEE)
> +#define HW_ATL_FW2X_CAP_EEE_2G5_MASK BIT(CAPS_HI_2P5GBASET_FD_EEE)
> +#define HW_ATL_FW2X_CAP_EEE_5G_MASK BIT(CAPS_HI_5GBASET_FD_EEE)
> +#define HW_ATL_FW2X_CAP_EEE_10G_MASK BIT(CAPS_HI_10GBASET_FD_EEE)
Please do this rename as a separate patch, so we can clearly see new
EEE code which needs close review, from the simple renaming which
needs little review.
In general, it is better to have lots of simple patches, which do just
one things, rather than a big patch making lots of unrelated changes.
Andrew
^ permalink raw reply
* RE: [PATCH lora-next 01/10] net: lora: sx1301: add register, bit-fields, and helpers for regmap
From: Ben Whitten @ 2018-08-08 12:24 UTC (permalink / raw)
To: Andreas Färber, Ben Whitten
Cc: starnight@g.ncu.edu.tw, hasnain.virk@arm.com,
netdev@vger.kernel.org
In-Reply-To: <e041fa89-9375-b0f2-db4d-8a64793cb78a@suse.de>
> Subject: Re: [PATCH lora-next 01/10] net: lora: sx1301: add
> register, bit-fields, and helpers for regmap
>
> Am 07.08.2018 um 19:32 schrieb Ben Whitten:
> > diff --git a/drivers/net/lora/sx1301.c
> b/drivers/net/lora/sx1301.c
> > index 5342b61..49958f0 100644
> > --- a/drivers/net/lora/sx1301.c
> > +++ b/drivers/net/lora/sx1301.c
> [...]
> > @@ -76,8 +287,29 @@ struct sx1301_priv {
> > struct gpio_desc *rst_gpio;
> > u8 cur_page;
> > struct spi_controller *radio_a_ctrl, *radio_b_ctrl;
> > + struct regmap *regmap;
> > + struct regmap_field
> *regmap_fields[ARRAY_SIZE(sx1301_reg_fields)];
> > };
> >
> > +static int sx1301_field_read(struct sx1301_priv *priv,
> > + enum sx1301_fields field_id)
> > +{
> > + int ret;
> > + int val;
> > +
> > + ret = regmap_field_read(priv-
> >regmap_fields[field_id], &val);
> > + if (ret)
> > + return ret;
> > +
> > + return val;
>
> This strikes me as a bad idea. Please keep returning the
> value by
> pointer, so that we can clearly distinguish from error values.
Good point, will change it.
> > +}
> > +
> > +static int sx1301_field_write(struct sx1301_priv *priv,
> > + enum sx1301_fields field_id, u8 val)
> > +{
> > + return regmap_field_write(priv-
> >regmap_fields[field_id], val);
> > +}
> > +
> > static int sx1301_read_burst(struct spi_device *spi, u8
> reg, u8 *val, size_t len)
> > {
> > u8 addr = reg & 0x7f;
> [snip]
>
> It looks to me as if both of those static functions are unused
> in this
> patch? Please keep things bisectable.
Sure, it was a prep patch bit I can include these functions in the
next one along where they are actually used.
Thanks,
Ben
^ permalink raw reply
* Re: [PATCH net-next 3/5] net: aquantia: implement WOL support
From: Andrew Lunn @ 2018-08-08 12:16 UTC (permalink / raw)
To: Igor Russkikh; +Cc: David S . Miller, netdev, Yana Esina, Nikita Danilov
In-Reply-To: <4b6c2d73c19dac481fbf2656f7a24da90966130b.1533650064.git.igor.russkikh@aquantia.com>
> --- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
> @@ -889,11 +889,13 @@ void aq_nic_deinit(struct aq_nic_s *self)
> self->aq_vecs > i; ++i, aq_vec = self->aq_vec[i])
> aq_vec_deinit(aq_vec);
>
> - if (self->power_state == AQ_HW_POWER_STATE_D0) {
> - (void)self->aq_fw_ops->deinit(self->aq_hw);
> - } else {
> - (void)self->aq_hw_ops->hw_set_power(self->aq_hw,
> - self->power_state);
> + (void)self->aq_fw_ops->deinit(self->aq_hw);
These void casts look a bit ugly. Are they needed? Is the compiler
complaining? If it is complaining, it suggests you should not be
casting anyway...
> + if (wol_enabled) {
> + rpc_size = sizeof(prpc->msg_id) + sizeof(prpc->msg_wol);
> +
> + prpc->msg_id = HAL_ATLANTIC_UTILS_FW_MSG_WOL_ADD;
> + prpc->msg_wol.priority = 0x10000000; /* normal priority */
> + prpc->msg_wol.pattern_id = 1U;
> + prpc->msg_wol.wol_packet_type = 2U; /* Magic Packet */
Maybe add #defines for these magic numbers?
> +
> + ether_addr_copy((u8 *)&prpc->msg_wol.wol_pattern, mac);
> + } else {
> + rpc_size = sizeof(prpc->msg_id) + sizeof(prpc->msg_del_id);
> +
> + prpc->msg_id = HAL_ATLANTIC_UTILS_FW_MSG_WOL_DEL;
> + prpc->msg_wol.pattern_id = 1U;
> + }
> +
> + err = hw_atl_utils_fw_rpc_call(self, rpc_size);
> +
> +err_exit:
> + return err;
> +}
Andrew
^ permalink raw reply
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