* [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
* [PATCH v2 19/29] ARM: davinci: mityomapl138: don't read the MAC address from machine code
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 is now done by the emac driver using a registered nvmem cell.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/board-mityomapl138.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 48a9bae76e4a..35b2b6068a7a 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -120,7 +120,6 @@ static void read_factory_config(struct nvmem_device *nvmem, void *context)
{
int ret;
const char *partnum = NULL;
- struct davinci_soc_info *soc_info = &davinci_soc_info;
if (!IS_BUILTIN(CONFIG_NVMEM)) {
pr_warn("Factory Config not available without CONFIG_NVMEM\n");
@@ -146,13 +145,6 @@ static void read_factory_config(struct nvmem_device *nvmem, void *context)
goto bad_config;
}
- pr_info("Found MAC = %pM\n", factory_config.mac);
- if (is_valid_ether_addr(factory_config.mac))
- memcpy(soc_info->emac_pdata->mac_addr,
- factory_config.mac, ETH_ALEN);
- else
- pr_warn("Invalid MAC found in factory config block\n");
-
partnum = factory_config.partnum;
pr_info("Part Number = %s\n", partnum);
--
2.18.0
^ permalink raw reply related
* [PATCH v2 18/29] ARM: davinci: da850-evm: remove dead MTD code
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 no longer need to register the MTD notifier to read the MAC address
as it's now being done in the emac driver.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/board-da850-evm.c | 28 -------------------------
1 file changed, 28 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 521a26b5c20d..1df796b67b82 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -137,32 +137,6 @@ static struct spi_board_info da850evm_spi_info[] = {
},
};
-#ifdef CONFIG_MTD
-static void da850_evm_m25p80_notify_add(struct mtd_info *mtd)
-{
- char *mac_addr = davinci_soc_info.emac_pdata->mac_addr;
- size_t retlen;
-
- if (!strcmp(mtd->name, "MAC-Address")) {
- mtd_read(mtd, 0, ETH_ALEN, &retlen, mac_addr);
- if (retlen == ETH_ALEN)
- pr_info("Read MAC addr from SPI Flash: %pM\n",
- mac_addr);
- }
-}
-
-static struct mtd_notifier da850evm_spi_notifier = {
- .add = da850_evm_m25p80_notify_add,
-};
-
-static void da850_evm_setup_mac_addr(void)
-{
- register_mtd_user(&da850evm_spi_notifier);
-}
-#else
-static void da850_evm_setup_mac_addr(void) { }
-#endif
-
static struct mtd_partition da850_evm_norflash_partition[] = {
{
.name = "bootloaders + env",
@@ -1470,8 +1444,6 @@ static __init void da850_evm_init(void)
if (ret)
pr_warn("%s: SATA registration failed: %d\n", __func__, ret);
- da850_evm_setup_mac_addr();
-
ret = da8xx_register_rproc();
if (ret)
pr_warn("%s: dsp/rproc registration failed: %d\n",
--
2.18.0
^ permalink raw reply related
* [PATCH v2 17/29] net: davinci_emac: use eth_platform_get_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 in eth_platform_get_mac_address() and all boards
have the mac-address cells defined. Stop getting the MAC from pdata
and use the dedicated helper.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/net/ethernet/ti/davinci_emac.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index f270beebb428..5d01bad4baa5 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1700,7 +1700,6 @@ davinci_emac_of_get_pdata(struct platform_device *pdev, struct emac_priv *priv)
const struct of_device_id *match;
const struct emac_platform_data *auxdata;
struct emac_platform_data *pdata = NULL;
- const u8 *mac_addr;
if (!IS_ENABLED(CONFIG_OF) || !pdev->dev.of_node)
return dev_get_platdata(&pdev->dev);
@@ -1712,12 +1711,6 @@ davinci_emac_of_get_pdata(struct platform_device *pdev, struct emac_priv *priv)
np = pdev->dev.of_node;
pdata->version = EMAC_VERSION_2;
- if (!is_valid_ether_addr(pdata->mac_addr)) {
- mac_addr = of_get_mac_address(np);
- if (mac_addr)
- ether_addr_copy(pdata->mac_addr, mac_addr);
- }
-
of_property_read_u32(np, "ti,davinci-ctrl-reg-offset",
&pdata->ctrl_reg_offset);
@@ -1819,8 +1812,11 @@ static int davinci_emac_probe(struct platform_device *pdev)
goto err_free_netdev;
}
+ rc = eth_platform_get_mac_address(&pdev->dev, priv->mac_addr);
+ if (rc == -EPROBE_DEFER)
+ return -EPROBE_DEFER; /* We'll get the MAC address later. */
+
/* MAC addr and PHY mask , RMII enable info from platform_data */
- memcpy(priv->mac_addr, pdata->mac_addr, ETH_ALEN);
priv->phy_id = pdata->phy_id;
priv->rmii_en = pdata->rmii_en;
priv->version = pdata->version;
--
2.18.0
^ permalink raw reply related
* [PATCH v2 16/29] net: add support for nvmem to eth_platform_get_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>
Many non-DT platforms read the MAC address from EEPROM. Usually it's
either done with callbacks defined in board files or from SoC-specific
ethernet drivers.
In order to generalize this, try to read the MAC from nvmem in
eth_platform_get_mac_address() using a standard lookup name:
"mac-address".
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
net/ethernet/eth.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index d01dd55de037..f6f6af05fb58 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -54,6 +54,7 @@
#include <linux/if_ether.h>
#include <linux/of_net.h>
#include <linux/pci.h>
+#include <linux/nvmem-consumer.h>
#include <net/dst.h>
#include <net/arp.h>
#include <net/sock.h>
@@ -557,6 +558,39 @@ static int mac_address_from_arch(u8 *mac_addr)
return 0;
}
+static int mac_address_from_nvmem(struct device *dev, u8 *mac_addr)
+{
+ const unsigned char *addr;
+ struct nvmem_cell *cell;
+ size_t alen;
+ int rv = 0;
+
+ cell = nvmem_cell_get(dev, "mac-address");
+ if (IS_ERR(cell))
+ return PTR_ERR(cell);
+
+ addr = nvmem_cell_read(cell, &alen);
+ if (IS_ERR(addr)) {
+ rv = PTR_ERR(addr);
+ goto put_nvmem;
+ }
+
+ if (alen != ETH_ALEN || !is_valid_ether_addr(addr)) {
+ rv = -ENODEV;
+ goto free_addr;
+ }
+
+ ether_addr_copy(mac_addr, addr);
+
+free_addr:
+ kfree(addr);
+
+put_nvmem:
+ nvmem_cell_put(cell);
+
+ return rv;
+}
+
int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr)
{
int rv;
@@ -569,6 +603,10 @@ int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr)
if (!rv)
return 0;
+ rv = mac_address_from_nvmem(dev, mac_addr);
+ if (!rv)
+ return 0;
+
return -ENODEV;
}
EXPORT_SYMBOL(eth_platform_get_mac_address);
--
2.18.0
^ permalink raw reply related
* [PATCH v2 15/29] net: split eth_platform_get_mac_address() into subroutines
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 do add more sources from which to read the MAC address. In
order to avoid bloating this function too much, start by splitting it
into subroutines, each of which takes care of reading the MAC from
one source.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
net/ethernet/eth.c | 44 ++++++++++++++++++++++++++++++++++++--------
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index 7f08105402c8..d01dd55de037 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -525,22 +525,50 @@ unsigned char * __weak arch_get_platform_mac_address(void)
return NULL;
}
-int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr)
+static int mac_address_from_of(struct device *dev, u8 *mac_addr)
{
const unsigned char *addr;
- struct device_node *dp;
+ struct device_node *np;
- dp = dev->of_node;
- addr = NULL;
- if (dp)
- addr = of_get_mac_address(dp);
- if (!addr)
- addr = arch_get_platform_mac_address();
+ np = dev->of_node;
+ if (!np)
+ return -ENODEV;
+ addr = of_get_mac_address(np);
if (!addr)
return -ENODEV;
+ if (!addr || !is_valid_ether_addr(addr))
+ return -ENODEV;
+
ether_addr_copy(mac_addr, addr);
return 0;
}
+
+static int mac_address_from_arch(u8 *mac_addr)
+{
+ const unsigned char *addr;
+
+ addr = arch_get_platform_mac_address();
+ if (!addr || !is_valid_ether_addr(addr))
+ return -ENODEV;
+
+ ether_addr_copy(mac_addr, addr);
+ return 0;
+}
+
+int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr)
+{
+ int rv;
+
+ rv = mac_address_from_of(dev, mac_addr);
+ if (!rv)
+ return 0;
+
+ rv = mac_address_from_arch(mac_addr);
+ if (!rv)
+ return 0;
+
+ return -ENODEV;
+}
EXPORT_SYMBOL(eth_platform_get_mac_address);
--
2.18.0
^ permalink raw reply related
* [PATCH v2 13/29] ARM: davinci: da850-evm: remove unnecessary include
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 include file for at24_platform_data is not needed in this file.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/board-da850-evm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 5a634a04ec69..521a26b5c20d 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -20,7 +20,6 @@
#include <linux/kernel.h>
#include <linux/leds.h>
#include <linux/i2c.h>
-#include <linux/platform_data/at24.h>
#include <linux/platform_data/pca953x.h>
#include <linux/input.h>
#include <linux/input/tps6507x-ts.h>
--
2.18.0
^ permalink raw reply related
* [PATCH v2 10/29] ARM: davinci: da830-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-da830-evm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 14a6fc061744..9a055ebba081 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -21,6 +21,7 @@
#include <linux/platform_data/at24.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
+#include <linux/nvmem-provider.h>
#include <linux/spi/spi.h>
#include <linux/spi/flash.h>
#include <linux/platform_data/gpio-davinci.h>
@@ -409,6 +410,15 @@ static inline void da830_evm_init_lcdc(int mux_mode)
static inline void da830_evm_init_lcdc(int mux_mode) { }
#endif
+static struct nvmem_cell_lookup da830_evm_mac_address_cell = {
+ .info = {
+ .name = "mac-address",
+ .offset = 0x7f00,
+ .bytes = ETH_ALEN,
+ },
+ .nvmem_name = "1-00500",
+};
+
static struct at24_platform_data da830_evm_i2c_eeprom_info = {
.byte_len = SZ_256K / 8,
.page_size = 64,
@@ -618,6 +628,8 @@ static __init void da830_evm_init(void)
pr_warn("%s: spi 0 registration failed: %d\n", __func__, ret);
regulator_has_full_constraints();
+
+ nvmem_add_lookup_table(&da830_evm_mac_address_cell, 1);
}
#ifdef CONFIG_SERIAL_8250_CONSOLE
--
2.18.0
^ permalink raw reply related
* [PATCH v2 09/29] ARM: davinci: dm646x-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-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..943ab0ca6db8 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -31,6 +31,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
+#include <linux/nvmem-provider.h>
#include <linux/clk.h>
#include <linux/export.h>
#include <linux/platform_data/gpio-davinci.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 v2 08/29] ARM: davinci: dm644-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-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..829fa1c8d0b4 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -22,6 +22,7 @@
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/physmap.h>
+#include <linux/nvmem-provider.h>
#include <linux/phy.h>
#include <linux/clk.h>
#include <linux/videodev2.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
^ permalink raw reply related
* [PATCH v2 07/29] ARM: davinci: dm365-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-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..cf3f2e611228 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -22,6 +22,7 @@
#include <linux/leds.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
+#include <linux/nvmem-provider.h>
#include <linux/slab.h>
#include <linux/mtd/rawnand.h>
#include <linux/input.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 v2 03/29] nvmem: add a notifier chain
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>
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 v2 02/29] Documentation: nvmem: document lookup entries
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
In-Reply-To: <20180810080526.27207-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 v2 01/29] nvmem: add support for cell lookups
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,
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: <20180810080526.27207-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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related
* [PATCH] net: chelsio: cxgb2: remove unused array pci_speed
From: Colin King @ 2018-08-10 8:02 UTC (permalink / raw)
To: David S . Miller, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Array pci_speed is defined but is never used hence it is redundant
and can be removed.
Cleans up clang warning:
warning: 'pci_speed' defined but not used [-Wunused-const-variable=]
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/chelsio/cxgb/cxgb2.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb/cxgb2.c b/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
index 8623be13bf86..0ccdde366ae1 100644
--- a/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
+++ b/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
@@ -109,10 +109,6 @@ static int disable_msi = 0;
module_param(disable_msi, int, 0);
MODULE_PARM_DESC(disable_msi, "Disable Message Signaled Interrupt (MSI)");
-static const char pci_speed[][4] = {
- "33", "66", "100", "133"
-};
-
/*
* Setup MAC to receive the types of packets we want.
*/
--
2.17.1
^ permalink raw reply related
* Re: [BUG] net: xfrm: Two possible sleep-in-atomic-context bugs
From: Jia-Ju Bai @ 2018-08-10 7:30 UTC (permalink / raw)
To: Steffen Klassert; +Cc: herbert, davem, netdev, linux-kernel
In-Reply-To: <20180810053604.uopy5ziikf736p5o@gauss3.secunet.de>
Thanks for your reply :)
On 2018/8/10 13:36, Steffen Klassert wrote:
> On Fri, Aug 10, 2018 at 10:02:42AM +0800, bai wrote:
>> The code may sleep in interrupt handler.
>> xfrm_trans_reinject() is an interrupt handler set in tasklet_init().
>> The function call paths (from bottom to top) in Linux-4.16 are:
>>
>> [FUNC] schedule_timeout
>> net/core/sock.c, 2044: schedule_timeout in sock_wait_for_wmem
>> net/core/sock.c, 2083: sock_wait_for_wmem in sock_alloc_send_pskb
>> net/core/sock.c, 2102: sock_alloc_send_pskb in sock_alloc_send_skb
>> net/ipv6/mcast.c, 1989: sock_alloc_send_skb in igmp6_send
> igmp6_send calls sock_alloc_send_skb with 'noblock = 1',
> this means that sock_wait_for_wmem is not executed in
> sock_alloc_send_pskb.
>
>> net/ipv6/mcast.c, 2391: igmp6_send in igmp6_join_group
>> net/ipv6/mcast.c, 670: igmp6_join_group in igmp6_group_added
>> net/ipv6/mcast.c, 914: igmp6_group_added in ipv6_dev_mc_inc
>> net/ipv6/ndisc.c, 379: ipv6_dev_mc_inc in pndisc_constructor
>> net/core/neighbour.c, 640: [FUNC_PTR]pndisc_constructor in pneigh_lookup
>> net/ipv6/ip6_output.c, 483: pneigh_lookup in ip6_forward
>> ./include/net/dst.h, 449: [FUNC_PTR]ip6_forward in dst_input
>> net/ipv6/ip6_input.c, 71: dst_input in ip6_rcv_finish
>> net/xfrm/xfrm_input.c, 511: [FUNC_PTR]ip6_rcv_finish in xfrm_trans_reinject
>>
>> [FUNC] kmalloc(GFP_KERNEL)
>> net/core/neighbour.c, 630: kmalloc in pneigh_lookup
>> net/ipv6/ip6_output.c, 483: pneigh_lookup in ip6_forward
> ip6_forward calls pneigh_lookup with 'creat = 0',
> this means that pneigh_lookup does not do the kmalloc.
>
>> ./include/net/dst.h, 449: [FUNC_PTR]ip6_forward in dst_input
>> net/ipv6/ip6_input.c, 71: dst_input in ip6_rcv_finish
>> net/xfrm/xfrm_input.c, 511: [FUNC_PTR]ip6_rcv_finish in xfrm_trans_reinject
>>
>> Note that [FUNC_PTR] means a function pointer call is used.
>>
>> I do not find a good way to fix them, so I only report.
>> These possible bugs are found by my static analysis tool (DSAC) and checked
>> by my code review.
> Both codepaths are ok, maybe you should fix your tool ;-)
It seems that the path condition checking in my tool needs to be improved.
I will do it, thanks :)
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* [PATCH net-next] vxge: remove set but not used variable 'req_out','status' and 'ret'
From: YueHaibing @ 2018-08-10 6:08 UTC (permalink / raw)
To: davem, jdmason, keescook, colin.king
Cc: linux-kernel, netdev, gustavo, bhelgaas, YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/neterion/vxge/vxge-config.c:1097:6: warning:
variable 'ret' set but not used [-Wunused-but-set-variable]
drivers/net/ethernet/neterion/vxge/vxge-config.c:2263:6: warning:
variable 'req_out' set but not used [-Wunused-but-set-variable]
drivers/net/ethernet/neterion/vxge/vxge-config.c:2262:22: warning:
variable 'status' set but not used [-Wunused-but-set-variable]
drivers/net/ethernet/neterion/vxge/vxge-config.c:2360:22: warning:
variable 'status' set but not used [-Wunused-but-set-variable]
enum vxge_hw_status status = VXGE_HW_OK;
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/neterion/vxge/vxge-config.c | 27 ++++++------------------
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/neterion/vxge/vxge-config.c b/drivers/net/ethernet/neterion/vxge/vxge-config.c
index ae81498..398011c 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-config.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-config.c
@@ -1094,12 +1094,9 @@ static void __vxge_hw_blockpool_destroy(struct __vxge_hw_blockpool *blockpool)
{
struct __vxge_hw_device *hldev;
struct list_head *p, *n;
- u16 ret;
- if (blockpool == NULL) {
- ret = 1;
- goto exit;
- }
+ if (!blockpool)
+ return;
hldev = blockpool->hldev;
@@ -1122,8 +1119,7 @@ static void __vxge_hw_blockpool_destroy(struct __vxge_hw_blockpool *blockpool)
list_del(&((struct __vxge_hw_blockpool_entry *)p)->item);
kfree((void *)p);
}
- ret = 0;
-exit:
+
return;
}
@@ -2259,14 +2255,11 @@ static void vxge_hw_blockpool_block_add(struct __vxge_hw_device *devh,
struct __vxge_hw_blockpool *blockpool;
struct __vxge_hw_blockpool_entry *entry = NULL;
dma_addr_t dma_addr;
- enum vxge_hw_status status = VXGE_HW_OK;
- u32 req_out;
blockpool = &devh->block_pool;
if (block_addr == NULL) {
blockpool->req_out--;
- status = VXGE_HW_FAIL;
goto exit;
}
@@ -2276,7 +2269,6 @@ static void vxge_hw_blockpool_block_add(struct __vxge_hw_device *devh,
if (unlikely(pci_dma_mapping_error(devh->pdev, dma_addr))) {
vxge_os_dma_free(devh->pdev, block_addr, &acc_handle);
blockpool->req_out--;
- status = VXGE_HW_FAIL;
goto exit;
}
@@ -2291,7 +2283,7 @@ static void vxge_hw_blockpool_block_add(struct __vxge_hw_device *devh,
else
list_del(&entry->item);
- if (entry != NULL) {
+ if (entry) {
entry->length = length;
entry->memblock = block_addr;
entry->dma_addr = dma_addr;
@@ -2299,13 +2291,10 @@ static void vxge_hw_blockpool_block_add(struct __vxge_hw_device *devh,
entry->dma_handle = dma_h;
list_add(&entry->item, &blockpool->free_block_list);
blockpool->pool_size++;
- status = VXGE_HW_OK;
- } else
- status = VXGE_HW_ERR_OUT_OF_MEMORY;
+ }
blockpool->req_out--;
- req_out = blockpool->req_out;
exit:
return;
}
@@ -2357,7 +2346,6 @@ static void *__vxge_hw_blockpool_malloc(struct __vxge_hw_device *devh, u32 size,
struct __vxge_hw_blockpool_entry *entry = NULL;
struct __vxge_hw_blockpool *blockpool;
void *memblock = NULL;
- enum vxge_hw_status status = VXGE_HW_OK;
blockpool = &devh->block_pool;
@@ -2367,10 +2355,8 @@ static void *__vxge_hw_blockpool_malloc(struct __vxge_hw_device *devh, u32 size,
&dma_object->handle,
&dma_object->acc_handle);
- if (memblock == NULL) {
- status = VXGE_HW_ERR_OUT_OF_MEMORY;
+ if (!memblock)
goto exit;
- }
dma_object->addr = pci_map_single(devh->pdev, memblock, size,
PCI_DMA_BIDIRECTIONAL);
@@ -2379,7 +2365,6 @@ static void *__vxge_hw_blockpool_malloc(struct __vxge_hw_device *devh, u32 size,
dma_object->addr))) {
vxge_os_dma_free(devh->pdev, memblock,
&dma_object->acc_handle);
- status = VXGE_HW_ERR_OUT_OF_MEMORY;
goto exit;
}
--
2.7.0
^ permalink raw reply related
* RE: [PATCH 1/1] selftest/net: fix FILE_SIZE for 32 bit architecture.
From: Maninder Singh @ 2018-08-10 6:03 UTC (permalink / raw)
To: David Laight, Eric Dumazet, davem@davemloft.net
Cc: shuahkh@osg.samsung.com, netdev@vger.kernel.org,
linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
edumazet@google.com, PANKAJ MISHRA, AMIT SAHRAWAT, Vaneet Narang
In-Reply-To: <4f2c8d694dce4125a609e8d5383ebe36@AcuMS.aculab.com>
>> >
>> >What about using more conventional size_t instead of "unsigned long long" ?
>>
>> size_t is also equivalent to unsigned long and it will not hold value of (1 << 35) for 32 bit system.
>> So we can do two things.
>
>Wouldn't the 'correct' type be off_t ?
>In any case, IIRC, you have to do really horrid things in Linux to
>access files larger than 2G on 32bit systems.
>
> David
Any inputs.
Thanks,
Maninder Singh
^ permalink raw reply
* Re: [PATCH 0/2] net/sched: Add hardware specific counters to TC actions
From: Jakub Kicinski @ 2018-08-10 3:26 UTC (permalink / raw)
To: Eelco Chaudron; +Cc: netdev, davem, jhs, xiyou.wangcong, jiri, Simon Horman
In-Reply-To: <20180809150118.5275.63824.stgit@wsfd-netdev20.ntdv.lab.eng.bos.redhat.com>
On Thu, 9 Aug 2018 11:01:18 -0400, Eelco Chaudron wrote:
> Add hardware specific counters to TC actions which will be exported
> through the netlink API. This makes troubleshooting TC flower offload
> easier, as it possible to differentiate the packets being offloaded.
It is not immediately clear why this is needed. The memory and
updating two sets of counters won't come for free, so perhaps a
stronger justification than troubleshooting is due? :S
Netdev has counters for fallback vs forwarded traffic, so you'd know
that traffic hits the SW datapath, plus the rules which are in_hw will
most likely not match as of today for flower (assuming correctness).
I'm slightly concerned about potential performance impact, would you
be able to share some numbers for non-trivial number of flows (100k
active?)?
^ permalink raw reply
* Re: [PATCH bpf-next 1/3] bpf: add bpf queue map
From: Alexei Starovoitov @ 2018-08-10 3:09 UTC (permalink / raw)
To: Mauricio Vasquez; +Cc: Daniel Borkmann, Alexei Starovoitov, netdev
In-Reply-To: <4d92f158-8fea-cfeb-09c9-0353c0ffd8d5@polito.it>
On Thu, Aug 09, 2018 at 06:41:54PM -0500, Mauricio Vasquez wrote:
>
>
> On 08/09/2018 11:23 AM, Alexei Starovoitov wrote:
> > On Thu, Aug 09, 2018 at 09:51:49AM -0500, Mauricio Vasquez wrote:
> > > > Agree that existing ops are not the right alias, but deferring to user
> > > > space as inline function also doesn't really seem like a good fit, imho,
> > > > so I'd prefer rather to have something native. (Aside from that, the
> > > > above inline bpf_pop() would also race between CPUs.)
> > > I think we should have push/pop/peek syscalls as well, having a bpf_pop()
> > > that is race prone would create problems. Users expected maps operations to
> > > be safe, so having one that is not will confuse them.
> > agree the races are not acceptable.
> > How about a mixed solution:
> > - introduce bpf_push/pop/peak helpers that programs will use, so
> > they don't need to pass useless key=NULL
> > - introduce map->ops->lookup_and_delete and map->ops->lookup_or_init
> > that prog-side helpers can use and syscall has 1-1 mapping for
> I think if is a fair solution.
> > Native lookup_or_init() helper for programs and syscall is badly missing.
> > Most of the bcc scripts use it and bcc has a racy workaround.
> > Similarly lookup_and_delete() syscall is 1-1 to pop() for stack/queue
> > and useful for regular hash maps.
> >
> > At the end for stack/queue map the programs will use:
> > int bpf_push(map, value);
>
> Also flags should be passed here.
Good point about flags. Indeed flags should be there for
extensibility, but I cannot think of use case for them at the moment.
hash's exist/noexist don't apply here.
Would be good to have at least one bit in use from the start.
>
> > value_or_null = bpf_pop(map); // guaranteed non-racy for multi-cpu
> > value_or_null = bpf_peak(map); // racy if 2+ cpus doing it
> Is there any reason for it to be racy?
because two cpus will be looking at the same element?
whethere implementation is array based or link list with rcu
the race is still there.
^ permalink raw reply
* Re: [BUG] net: xfrm: Two possible sleep-in-atomic-context bugs
From: Steffen Klassert @ 2018-08-10 5:36 UTC (permalink / raw)
To: bai; +Cc: herbert, davem, netdev, linux-kernel
In-Reply-To: <b74ebf58-16c0-4a51-a004-7ce9e6abde7a@gmail.com>
On Fri, Aug 10, 2018 at 10:02:42AM +0800, bai wrote:
> The code may sleep in interrupt handler.
> xfrm_trans_reinject() is an interrupt handler set in tasklet_init().
> The function call paths (from bottom to top) in Linux-4.16 are:
>
> [FUNC] schedule_timeout
> net/core/sock.c, 2044: schedule_timeout in sock_wait_for_wmem
> net/core/sock.c, 2083: sock_wait_for_wmem in sock_alloc_send_pskb
> net/core/sock.c, 2102: sock_alloc_send_pskb in sock_alloc_send_skb
> net/ipv6/mcast.c, 1989: sock_alloc_send_skb in igmp6_send
igmp6_send calls sock_alloc_send_skb with 'noblock = 1',
this means that sock_wait_for_wmem is not executed in
sock_alloc_send_pskb.
> net/ipv6/mcast.c, 2391: igmp6_send in igmp6_join_group
> net/ipv6/mcast.c, 670: igmp6_join_group in igmp6_group_added
> net/ipv6/mcast.c, 914: igmp6_group_added in ipv6_dev_mc_inc
> net/ipv6/ndisc.c, 379: ipv6_dev_mc_inc in pndisc_constructor
> net/core/neighbour.c, 640: [FUNC_PTR]pndisc_constructor in pneigh_lookup
> net/ipv6/ip6_output.c, 483: pneigh_lookup in ip6_forward
> ./include/net/dst.h, 449: [FUNC_PTR]ip6_forward in dst_input
> net/ipv6/ip6_input.c, 71: dst_input in ip6_rcv_finish
> net/xfrm/xfrm_input.c, 511: [FUNC_PTR]ip6_rcv_finish in xfrm_trans_reinject
>
> [FUNC] kmalloc(GFP_KERNEL)
> net/core/neighbour.c, 630: kmalloc in pneigh_lookup
> net/ipv6/ip6_output.c, 483: pneigh_lookup in ip6_forward
ip6_forward calls pneigh_lookup with 'creat = 0',
this means that pneigh_lookup does not do the kmalloc.
> ./include/net/dst.h, 449: [FUNC_PTR]ip6_forward in dst_input
> net/ipv6/ip6_input.c, 71: dst_input in ip6_rcv_finish
> net/xfrm/xfrm_input.c, 511: [FUNC_PTR]ip6_rcv_finish in xfrm_trans_reinject
>
> Note that [FUNC_PTR] means a function pointer call is used.
>
> I do not find a good way to fix them, so I only report.
> These possible bugs are found by my static analysis tool (DSAC) and checked
> by my code review.
Both codepaths are ok, maybe you should fix your tool ;-)
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: enable btf for use in all maps
From: Alexei Starovoitov @ 2018-08-10 2:13 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: ast, netdev, yhs
In-Reply-To: <ac996dfb-afc8-8b96-d06e-bda723af90e5@iogearbox.net>
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.
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.
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.
> > 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
* [net-next:master 1941/1953] drivers/net/ethernet/qlogic/qede/qede_filter.c:2048:38: sparse: restricted __be16 degrades to integer
From: kbuild test robot @ 2018-08-10 2:12 UTC (permalink / raw)
To: Manish Chopra; +Cc: kbuild-all, netdev, Ariel Elior
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 36d2f761b5aa688567b6aebdc6d68e73682275d4
commit: 2ce9c93eaca6c67e3fa8828a471738a32cd66770 [1941/1953] qede: Ingress tc flower offload (drop action) support.
reproduce:
# apt-get install sparse
git checkout 2ce9c93eaca6c67e3fa8828a471738a32cd66770
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
include/linux/overflow.h:220:13: sparse: undefined identifier '__builtin_mul_overflow'
include/linux/overflow.h:220:13: sparse: incorrect type in conditional
include/linux/overflow.h:220:13: got void
>> drivers/net/ethernet/qlogic/qede/qede_filter.c:2048:38: sparse: restricted __be16 degrades to integer
drivers/net/ethernet/qlogic/qede/qede_filter.c:2049:38: sparse: restricted __be16 degrades to integer
>> drivers/net/ethernet/qlogic/qede/qede_filter.c:2115:38: sparse: restricted __be32 degrades to integer
drivers/net/ethernet/qlogic/qede/qede_filter.c:2116:38: sparse: restricted __be32 degrades to integer
include/linux/overflow.h:220:13: sparse: call with no type!
vim +2048 drivers/net/ethernet/qlogic/qede/qede_filter.c
2032
2033 static int
2034 qede_tc_parse_ports(struct qede_dev *edev,
2035 struct tc_cls_flower_offload *f,
2036 struct qede_arfs_tuple *t)
2037 {
2038 if (dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_PORTS)) {
2039 struct flow_dissector_key_ports *key, *mask;
2040
2041 key = skb_flow_dissector_target(f->dissector,
2042 FLOW_DISSECTOR_KEY_PORTS,
2043 f->key);
2044 mask = skb_flow_dissector_target(f->dissector,
2045 FLOW_DISSECTOR_KEY_PORTS,
2046 f->mask);
2047
> 2048 if ((key->src && mask->src != U16_MAX) ||
2049 (key->dst && mask->dst != U16_MAX)) {
2050 DP_NOTICE(edev, "Do not support ports masks\n");
2051 return -EINVAL;
2052 }
2053
2054 t->src_port = key->src;
2055 t->dst_port = key->dst;
2056 }
2057
2058 return 0;
2059 }
2060
2061 static int
2062 qede_tc_parse_v6_common(struct qede_dev *edev,
2063 struct tc_cls_flower_offload *f,
2064 struct qede_arfs_tuple *t)
2065 {
2066 struct in6_addr zero_addr, addr;
2067
2068 memset(&zero_addr, 0, sizeof(addr));
2069 memset(&addr, 0xff, sizeof(addr));
2070
2071 if (dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_IPV6_ADDRS)) {
2072 struct flow_dissector_key_ipv6_addrs *key, *mask;
2073
2074 key = skb_flow_dissector_target(f->dissector,
2075 FLOW_DISSECTOR_KEY_IPV6_ADDRS,
2076 f->key);
2077 mask = skb_flow_dissector_target(f->dissector,
2078 FLOW_DISSECTOR_KEY_IPV6_ADDRS,
2079 f->mask);
2080
2081 if ((memcmp(&key->src, &zero_addr, sizeof(addr)) &&
2082 memcmp(&mask->src, &addr, sizeof(addr))) ||
2083 (memcmp(&key->dst, &zero_addr, sizeof(addr)) &&
2084 memcmp(&mask->dst, &addr, sizeof(addr)))) {
2085 DP_NOTICE(edev,
2086 "Do not support IPv6 address prefix/mask\n");
2087 return -EINVAL;
2088 }
2089
2090 memcpy(&t->src_ipv6, &key->src, sizeof(addr));
2091 memcpy(&t->dst_ipv6, &key->dst, sizeof(addr));
2092 }
2093
2094 if (qede_tc_parse_ports(edev, f, t))
2095 return -EINVAL;
2096
2097 return qede_set_v6_tuple_to_profile(edev, t, &zero_addr);
2098 }
2099
2100 static int
2101 qede_tc_parse_v4_common(struct qede_dev *edev,
2102 struct tc_cls_flower_offload *f,
2103 struct qede_arfs_tuple *t)
2104 {
2105 if (dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_IPV4_ADDRS)) {
2106 struct flow_dissector_key_ipv4_addrs *key, *mask;
2107
2108 key = skb_flow_dissector_target(f->dissector,
2109 FLOW_DISSECTOR_KEY_IPV4_ADDRS,
2110 f->key);
2111 mask = skb_flow_dissector_target(f->dissector,
2112 FLOW_DISSECTOR_KEY_IPV4_ADDRS,
2113 f->mask);
2114
> 2115 if ((key->src && mask->src != U32_MAX) ||
2116 (key->dst && mask->dst != U32_MAX)) {
2117 DP_NOTICE(edev, "Do not support ipv4 prefix/masks\n");
2118 return -EINVAL;
2119 }
2120
2121 t->src_ipv4 = key->src;
2122 t->dst_ipv4 = key->dst;
2123 }
2124
2125 if (qede_tc_parse_ports(edev, f, t))
2126 return -EINVAL;
2127
2128 return qede_set_v4_tuple_to_profile(edev, t);
2129 }
2130
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH 4.9-stable] tcp: add tcp_ooo_try_coalesce() helper
From: maowenan @ 2018-08-10 2:02 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?
ok, i will try.
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH 4.9-stable] tcp: add tcp_ooo_try_coalesce() helper
From: maowenan @ 2018-08-10 1:56 UTC (permalink / raw)
To: Greg KH
Cc: David Woodhouse, davem, edumazet, juha-matti.tilli, ycheng,
soheil, netdev, eric.dumazet, dwmw2, jdw
In-Reply-To: <20180809124726.GA9500@kroah.com>
On 2018/8/9 20:47, Greg KH wrote:
> On Thu, Aug 09, 2018 at 08:37:13PM +0800, maowenan wrote:
>>
>>
>> On 2018/8/7 21:22, Greg KH wrote:
>>> On Sat, Aug 04, 2018 at 10:10:00AM +0100, David Woodhouse wrote:
>>>> From: Eric Dumazet <edumazet@google.com>
>>>>
>>>> commit 58152ecbbcc6a0ce7fddd5bf5f6ee535834ece0c upstream.
>>>>
>>>> In case skb in out_or_order_queue is the result of
>>>> multiple skbs coalescing, we would like to get a proper gso_segs
>>>> counter tracking, so that future tcp_drop() can report an accurate
>>>> number.
>>>>
>>>> I chose to not implement this tracking for skbs in receive queue,
>>>> since they are not dropped, unless socket is disconnected.
>>>>
>>>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>>>> Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
>>>> Acked-by: Yuchung Cheng <ycheng@google.com>
>>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>>> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
>>>> ---
>>>> net/ipv4/tcp_input.c | 23 +++++++++++++++++++++--
>>>> 1 file changed, 21 insertions(+), 2 deletions(-)
>>>
>>> Now applied, thanks,
>>>
>>> greg k-h
>>>
>>> .
>>>
>>
>> Hello,
>>
>> 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.
I have verified that in linux 4.18-rc3(no fixed patches), and 4.18 rc7(with 5 fixed patches),
it works well and cpu usage drops from 95% to 27%.
>
> thnaks,
>
> greg k-h
>
> .
>
^ 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