* [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
* [PATCH net 3/3] net/smc: move sock lock in smc_ioctl()
From: Ursula Braun @ 2018-08-08 12:13 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl,
linux-kernel
In-Reply-To: <20180808121321.516-1-ubraun@linux.ibm.com>
When an SMC socket is connecting it is decided whether fallback to
TCP is needed. To avoid races between connect and ioctl move the
sock lock before the use_fallback check.
Reported-by: syzbot+5b2cece1a8ecb2ca77d8@syzkaller.appspotmail.com
Reported-by: syzbot+19557374321ca3710990@syzkaller.appspotmail.com
Fixes: 1992d99882af ("net/smc: take sock lock in smc_ioctl()")
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/af_smc.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 0ee7721afbe5..e7de5f282722 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1522,12 +1522,16 @@ static int smc_ioctl(struct socket *sock, unsigned int cmd,
smc = smc_sk(sock->sk);
conn = &smc->conn;
+ lock_sock(&smc->sk);
if (smc->use_fallback) {
- if (!smc->clcsock)
+ if (!smc->clcsock) {
+ release_sock(&smc->sk);
return -EBADF;
- return smc->clcsock->ops->ioctl(smc->clcsock, cmd, arg);
+ }
+ answ = smc->clcsock->ops->ioctl(smc->clcsock, cmd, arg);
+ release_sock(&smc->sk);
+ return answ;
}
- lock_sock(&smc->sk);
switch (cmd) {
case SIOCINQ: /* same as FIONREAD */
if (smc->sk.sk_state == SMC_LISTEN) {
--
2.16.4
^ permalink raw reply related
* [PATCH net 2/3] net/smc: allow sysctl rmem and wmem defaults for servers
From: Ursula Braun @ 2018-08-08 12:13 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl,
linux-kernel
In-Reply-To: <20180808121321.516-1-ubraun@linux.ibm.com>
Without setsockopt SO_SNDBUF and SO_RCVBUF settings, the sysctl
defaults net.ipv4.tcp_wmem and net.ipv4.tcp_rmem should be the base
for the sizes of the SMC sndbuf and rcvbuf. Any TCP buffer size
optimizations for servers should be ignored.
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/af_smc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 1288c7bf40d5..0ee7721afbe5 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1122,6 +1122,8 @@ static void smc_tcp_listen_work(struct work_struct *work)
sock_hold(lsk); /* sock_put in smc_listen_work */
INIT_WORK(&new_smc->smc_listen_work, smc_listen_work);
smc_copy_sock_settings_to_smc(new_smc);
+ new_smc->sk.sk_sndbuf = lsmc->sk.sk_sndbuf;
+ new_smc->sk.sk_rcvbuf = lsmc->sk.sk_rcvbuf;
sock_hold(&new_smc->sk); /* sock_put in passive closing */
if (!schedule_work(&new_smc->smc_listen_work))
sock_put(&new_smc->sk);
--
2.16.4
^ permalink raw reply related
* [PATCH net 1/3] net/smc: no shutdown in state SMC_LISTEN
From: Ursula Braun @ 2018-08-08 12:13 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl,
linux-kernel
In-Reply-To: <20180808121321.516-1-ubraun@linux.ibm.com>
Invoking shutdown for a socket in state SMC_LISTEN does not make
sense. Nevertheless programs like syzbot fuzzing the kernel may
try to do this. For SMC this means a socket refcounting problem.
This patch makes sure a shutdown call for an SMC socket in state
SMC_LISTEN simply returns with -ENOTCONN.
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/af_smc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 05e4ffe5aabd..1288c7bf40d5 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1397,8 +1397,7 @@ static int smc_shutdown(struct socket *sock, int how)
lock_sock(sk);
rc = -ENOTCONN;
- if ((sk->sk_state != SMC_LISTEN) &&
- (sk->sk_state != SMC_ACTIVE) &&
+ if ((sk->sk_state != SMC_ACTIVE) &&
(sk->sk_state != SMC_PEERCLOSEWAIT1) &&
(sk->sk_state != SMC_PEERCLOSEWAIT2) &&
(sk->sk_state != SMC_APPCLOSEWAIT1) &&
--
2.16.4
^ permalink raw reply related
* [PATCH] drivers/net/usb/r8152: change rtl8152_system_suspend to be void function
From: zhong jiang @ 2018-08-08 14:26 UTC (permalink / raw)
To: davem, edumazet; +Cc: netdev, linux-kernel
rtl8152_system_suspend defines the variable "ret", but it is not modified
after initialization. Further, I find that any of the callees do not
handle the return value. So It is safe to drop the variable and make it to
be void function.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/net/usb/r8152.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 124211a..cc51ac8 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -4412,10 +4412,9 @@ static int rtl8152_runtime_suspend(struct r8152 *tp)
return ret;
}
-static int rtl8152_system_suspend(struct r8152 *tp)
+static void rtl8152_system_suspend(struct r8152 *tp)
{
struct net_device *netdev = tp->netdev;
- int ret = 0;
netif_device_detach(netdev);
@@ -4429,8 +4428,6 @@ static int rtl8152_system_suspend(struct r8152 *tp)
tp->rtl_ops.down(tp);
napi_enable(napi);
}
-
- return ret;
}
static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
@@ -4443,7 +4440,7 @@ static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
if (PMSG_IS_AUTO(message))
ret = rtl8152_runtime_suspend(tp);
else
- ret = rtl8152_system_suspend(tp);
+ rtl8152_system_suspend(tp);
mutex_unlock(&tp->control);
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH net-next 2/5] net: aquantia: definitions for WOL patch
From: Andrew Lunn @ 2018-08-08 12:06 UTC (permalink / raw)
To: Igor Russkikh; +Cc: David S . Miller, netdev, Yana Esina, Nikita Danilov
In-Reply-To: <a3e119c80dd7afa6a4622f80eb0d1cc73dabbe81.1533650064.git.igor.russkikh@aquantia.com>
> -struct __packed hw_aq_atl_utils_fw_rpc {
> +struct __packed hw_atl_utils_fw_rpc {
> u32 msg_id;
Hi Igor
There is no explanation given as to why you decided to rename this
structure. Please do the rename as a standalone patch, no
functionality change. That makes it easier to review the new
functionality.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v6 10/11] net: sched: atomically check-allocate action
From: Vlad Buslov @ 2018-08-08 12:06 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Jiri Pirko, Alexei Starovoitov, Daniel Borkmann,
Yevgeny Kliteynik, Jiri Pirko
In-Reply-To: <CAM_iQpU+tWo4HVmQV+UCcLCmULd=kfsPZg+M+2rVvMbHN=2jww@mail.gmail.com>
On Wed 08 Aug 2018 at 01:20, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Thu, Jul 5, 2018 at 7:24 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>>
>> Implement function that atomically checks if action exists and either takes
>> reference to it, or allocates idr slot for action index to prevent
>> concurrent allocations of actions with same index. Use EBUSY error pointer
>> to indicate that idr slot is reserved.
>
> A dumb question:
>
> How could "concurrent allocations of actions with same index" happen
> as you already take idrinfo->lock for the whole
> tcf_idr_check_alloc()??
I guess my changelog is not precise enough in this description.
Let look into sequence of events of initialization of new action:
1) tcf_idr_check_alloc() is called by action init.
2) idrinfo->lock is taken.
3) Lookup in idr is performed to determine if action with specified
index already exists.
4) EBUSY pointer is inserted to indicate that id is taken.
5) idrinfo->lock is released.
6) tcf_idr_check_alloc() returns to action init code.
7) New action is allocated and initialized.
8) tcf_idr_insert() is called.
9) idrinfo->lock is taken.
10) EBUSY pointer is substituted with pointer to new action.
11) idrinfo->lock is released.
12) tcf_idr_insert() returns.
So in this case "concurrent allocations of actions with same index"
means not the allocation with same index during tcf_idr_check_alloc(),
but during the period when idrinfo->lock was released(6-8).
>
> For me, it should be only one allocation could succeed, all others
> should fail.
Correct! And this change is made specifically to enforce that rule.
Otherwise, multiple processes could try to create new action with same
id at the same time, and all processes that executed 3, before any
process reached 10, will "succeed" by overwriting each others action in
idr. (and leak memory while doing so)
>
> Maybe you are trying to prevent others treat it like existing one,
> but in that case you can just hold the idinfo->lock for all idr operations.
>
> And more importantly, upper layer is able to tell it is a creation or
> just replace, you don't have to check this in this complicated way.
>
> IOW, all of these complicated code should not exist.
Original code was simpler and didn't involve temporary EBUSY pointer.
This change was made according to Jiri's request. He wanted to have
unified API to be used by all actions and suggested this approach
specifically.
^ permalink raw reply
* [patch net-next] net: sched: fix block->refcnt decrement
From: Jiri Pirko @ 2018-08-08 12:04 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, vladbu, mlxsw
From: Jiri Pirko <jiri@mellanox.com>
Currently the refcnt is never decremented in case the value is not 1.
Fix it by adding decrement in case the refcnt is not 1.
Reported-by: Vlad Buslov <vladbu@mellanox.com>
Fixes: f71e0ca4db18 ("net: sched: Avoid implicit chain 0 creation")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/cls_api.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 194c2e0b2737..f922ce27ed5e 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -780,6 +780,8 @@ void tcf_block_put_ext(struct tcf_block *block, struct Qdisc *q,
block->refcnt--;
if (list_empty(&block->chain_list))
kfree(block);
+ } else {
+ block->refcnt--;
}
}
EXPORT_SYMBOL(tcf_block_put_ext);
--
2.14.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox