* [PATCH net-next v3 4/4] net: fec: add support for PTP system timestamping for MDIO devices
From: Hubert Feurstein @ 2019-08-20 8:48 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Hubert Feurstein, Andrew Lunn, Richard Cochran, Miroslav Lichvar,
Fugang Duan, Vladimir Oltean, David S. Miller
In-Reply-To: <20190820084833.6019-1-hubert.feurstein@vahle.at>
From: Hubert Feurstein <h.feurstein@gmail.com>
In order to improve the synchronisation precision of phc2sys (from
the linuxptp project) for devices like switches which are attached
to the MDIO bus, it is necessary the get the system timestamps as
close as possible to the access which causes the PTP timestamp
register to be snapshotted in the switch hardware. Usually this is
triggered by an MDIO write access, the snapshotted timestamp is then
transferred by several MDIO reads.
The ptp_read_system_*ts functions already check the ptp_sts pointer.
Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com>
---
drivers/net/ethernet/freescale/fec_main.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index c01d3ec3e9af..dd1253683ac0 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1815,10 +1815,12 @@ static int fec_enet_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
reinit_completion(&fep->mdio_done);
/* start a write op */
+ ptp_read_system_prets(bus->ptp_sts);
writel(FEC_MMFR_ST | FEC_MMFR_OP_WRITE |
FEC_MMFR_PA(mii_id) | FEC_MMFR_RA(regnum) |
FEC_MMFR_TA | FEC_MMFR_DATA(value),
fep->hwp + FEC_MII_DATA);
+ ptp_read_system_postts(bus->ptp_sts);
/* wait for end of transfer */
time_left = wait_for_completion_timeout(&fep->mdio_done,
@@ -1956,7 +1958,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
struct fec_enet_private *fep = netdev_priv(ndev);
struct device_node *node;
int err = -ENXIO;
- u32 mii_speed, holdtime;
+ u32 mii_speed, mii_period, holdtime;
/*
* The i.MX28 dual fec interfaces are not equal.
@@ -1993,6 +1995,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
* document.
*/
mii_speed = DIV_ROUND_UP(clk_get_rate(fep->clk_ipg), 5000000);
+ mii_period = div_u64((u64)mii_speed * 2 * NSEC_PER_SEC, clk_get_rate(fep->clk_ipg));
if (fep->quirks & FEC_QUIRK_ENET_MAC)
mii_speed--;
if (mii_speed > 63) {
@@ -2034,6 +2037,8 @@ static int fec_enet_mii_init(struct platform_device *pdev)
pdev->name, fep->dev_id + 1);
fep->mii_bus->priv = fep;
fep->mii_bus->parent = &pdev->dev;
+ fep->mii_bus->flags = MII_BUS_F_PTP_STS_SUPPORTED;
+ fep->mii_bus->ptp_sts_offset = 32 * mii_period;
node = of_get_child_by_name(pdev->dev.of_node, "mdio");
err = of_mdiobus_register(fep->mii_bus, node);
--
2.22.1
^ permalink raw reply related
* [PATCH net-next v3 3/4] net: dsa: mv88e6xxx: extend PTP gettime function to read system clock
From: Hubert Feurstein @ 2019-08-20 8:48 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Hubert Feurstein, Andrew Lunn, Richard Cochran, Miroslav Lichvar,
Vivien Didelot, Florian Fainelli, Vladimir Oltean,
David S. Miller
In-Reply-To: <20190820084833.6019-1-hubert.feurstein@vahle.at>
From: Hubert Feurstein <h.feurstein@gmail.com>
This adds support for the PTP_SYS_OFFSET_EXTENDED ioctl.
Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com>
---
Changes in v3:
- mv88e6xxx_smi_indirect_write: forward ptp_sts only on the last write
drivers/net/dsa/mv88e6xxx/chip.h | 2 ++
drivers/net/dsa/mv88e6xxx/ptp.c | 11 +++++++----
drivers/net/dsa/mv88e6xxx/smi.c | 7 ++++++-
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.h b/drivers/net/dsa/mv88e6xxx/chip.h
index a406be2f5652..1bfde0d8a5a3 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.h
+++ b/drivers/net/dsa/mv88e6xxx/chip.h
@@ -275,6 +275,8 @@ struct mv88e6xxx_chip {
struct ptp_clock_info ptp_clock_info;
struct delayed_work tai_event_work;
struct ptp_pin_desc pin_config[MV88E6XXX_MAX_GPIO];
+ struct ptp_system_timestamp *ptp_sts;
+
u16 trig_config;
u16 evcap_config;
u16 enable_count;
diff --git a/drivers/net/dsa/mv88e6xxx/ptp.c b/drivers/net/dsa/mv88e6xxx/ptp.c
index 073cbd0bb91b..cf6e52ee9e0a 100644
--- a/drivers/net/dsa/mv88e6xxx/ptp.c
+++ b/drivers/net/dsa/mv88e6xxx/ptp.c
@@ -235,14 +235,17 @@ static int mv88e6xxx_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
return 0;
}
-static int mv88e6xxx_ptp_gettime(struct ptp_clock_info *ptp,
- struct timespec64 *ts)
+static int mv88e6xxx_ptp_gettimex(struct ptp_clock_info *ptp,
+ struct timespec64 *ts,
+ struct ptp_system_timestamp *sts)
{
struct mv88e6xxx_chip *chip = ptp_to_chip(ptp);
u64 ns;
mv88e6xxx_reg_lock(chip);
+ chip->ptp_sts = sts;
ns = timecounter_read(&chip->tstamp_tc);
+ chip->ptp_sts = NULL;
mv88e6xxx_reg_unlock(chip);
*ts = ns_to_timespec64(ns);
@@ -426,7 +429,7 @@ static void mv88e6xxx_ptp_overflow_check(struct work_struct *work)
struct mv88e6xxx_chip *chip = dw_overflow_to_chip(dw);
struct timespec64 ts;
- mv88e6xxx_ptp_gettime(&chip->ptp_clock_info, &ts);
+ mv88e6xxx_ptp_gettimex(&chip->ptp_clock_info, &ts, NULL);
schedule_delayed_work(&chip->overflow_work,
MV88E6XXX_TAI_OVERFLOW_PERIOD);
@@ -472,7 +475,7 @@ int mv88e6xxx_ptp_setup(struct mv88e6xxx_chip *chip)
chip->ptp_clock_info.max_adj = MV88E6XXX_MAX_ADJ_PPB;
chip->ptp_clock_info.adjfine = mv88e6xxx_ptp_adjfine;
chip->ptp_clock_info.adjtime = mv88e6xxx_ptp_adjtime;
- chip->ptp_clock_info.gettime64 = mv88e6xxx_ptp_gettime;
+ chip->ptp_clock_info.gettimex64 = mv88e6xxx_ptp_gettimex;
chip->ptp_clock_info.settime64 = mv88e6xxx_ptp_settime;
chip->ptp_clock_info.enable = ptp_ops->ptp_enable;
chip->ptp_clock_info.verify = ptp_ops->ptp_verify;
diff --git a/drivers/net/dsa/mv88e6xxx/smi.c b/drivers/net/dsa/mv88e6xxx/smi.c
index 282fe08db050..1b5f78662158 100644
--- a/drivers/net/dsa/mv88e6xxx/smi.c
+++ b/drivers/net/dsa/mv88e6xxx/smi.c
@@ -45,7 +45,8 @@ static int mv88e6xxx_smi_direct_write(struct mv88e6xxx_chip *chip,
{
int ret;
- ret = mdiobus_write_nested(chip->bus, dev, reg, data);
+ ret = mdiobus_write_sts_nested(chip->bus, dev, reg, data,
+ chip->ptp_sts);
if (ret < 0)
return ret;
@@ -130,6 +131,7 @@ static int mv88e6xxx_smi_indirect_read(struct mv88e6xxx_chip *chip,
static int mv88e6xxx_smi_indirect_write(struct mv88e6xxx_chip *chip,
int dev, int reg, u16 data)
{
+ struct ptp_system_timestamp *ptp_sts = chip->ptp_sts;
int err;
err = mv88e6xxx_smi_direct_wait(chip, chip->sw_addr,
@@ -137,11 +139,14 @@ static int mv88e6xxx_smi_indirect_write(struct mv88e6xxx_chip *chip,
if (err)
return err;
+ chip->ptp_sts = NULL;
err = mv88e6xxx_smi_direct_write(chip, chip->sw_addr,
MV88E6XXX_SMI_DATA, data);
if (err)
return err;
+ /* Capture the PTP system timestamps only on *this* write operation */
+ chip->ptp_sts = ptp_sts;
err = mv88e6xxx_smi_direct_write(chip, chip->sw_addr,
MV88E6XXX_SMI_CMD,
MV88E6XXX_SMI_CMD_BUSY |
--
2.22.1
^ permalink raw reply related
* Re: [PATCH v2 10/11] vsock_test: skip read() in test_stream*close tests on a VMCI host
From: Stefan Hajnoczi @ 2019-08-20 8:32 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, kvm, Dexuan Cui, virtualization, David S. Miller,
Jorgen Hansen, linux-kernel
In-Reply-To: <20190801152541.245833-11-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 612 bytes --]
On Thu, Aug 01, 2019 at 05:25:40PM +0200, Stefano Garzarella wrote:
> When VMCI transport is used, if the guest closes a connection,
> all data is gone and EOF is returned, so we should skip the read
> of data written by the peer before closing the connection.
All transports should aim for identical semantics. I think virtio-vsock
should behave the same as VMCI since userspace applications should be
transport-independent.
Let's view this as a vsock bug. Is it feasible to change the VMCI
behavior so it's more like TCP sockets? If not, let's change the
virtio-vsock behavior to be compatible with VMCI.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 11/11] vsock_test: wait for the remote to close the connection
From: Stefan Hajnoczi @ 2019-08-20 8:28 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, kvm, Dexuan Cui, virtualization, David S. Miller,
Jorgen Hansen, linux-kernel
In-Reply-To: <20190801152541.245833-12-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]
On Thu, Aug 01, 2019 at 05:25:41PM +0200, Stefano Garzarella wrote:
> +/* Wait for the remote to close the connection */
> +void vsock_wait_remote_close(int fd)
> +{
> + struct epoll_event ev;
> + int epollfd, nfds;
> +
> + epollfd = epoll_create1(0);
> + if (epollfd == -1) {
> + perror("epoll_create1");
> + exit(EXIT_FAILURE);
> + }
> +
> + ev.events = EPOLLRDHUP | EPOLLHUP;
> + ev.data.fd = fd;
> + if (epoll_ctl(epollfd, EPOLL_CTL_ADD, fd, &ev) == -1) {
> + perror("epoll_ctl");
> + exit(EXIT_FAILURE);
> + }
> +
> + nfds = epoll_wait(epollfd, &ev, 1, TIMEOUT * 1000);
> + if (nfds == -1) {
> + perror("epoll_wait");
> + exit(EXIT_FAILURE);
> + }
> +
> + if (nfds == 0) {
> + fprintf(stderr, "epoll_wait timed out\n");
> + exit(EXIT_FAILURE);
> + }
> +
> + assert(nfds == 1);
> + assert(ev.events & (EPOLLRDHUP | EPOLLHUP));
> + assert(ev.data.fd == fd);
> +
> + close(epollfd);
> +}
Please use timeout_begin()/timeout_end() so that the test cannot hang.
> diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
> index 64adf45501ca..a664675bec5a 100644
> --- a/tools/testing/vsock/vsock_test.c
> +++ b/tools/testing/vsock/vsock_test.c
> @@ -84,6 +84,11 @@ static void test_stream_client_close_server(const struct test_opts *opts)
>
> control_expectln("CLOSED");
>
> + /* Wait for the remote to close the connection, before check
> + * -EPIPE error on send.
> + */
> + vsock_wait_remote_close(fd);
Is control_expectln("CLOSED") still necessary now that we're waiting for
the poll event? The control message was an attempt to wait until the
other side closed the socket.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v5 15/17] mfd: ioc3: Add driver for SGI IOC3 chip
From: Thomas Bogendoerfer @ 2019-08-20 8:17 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Jonathan Corbet, Ralf Baechle, Paul Burton, James Hogan,
Dmitry Torokhov, Lee Jones, David S. Miller, Srinivas Kandagatla,
Alessandro Zummo, Greg Kroah-Hartman, Jiri Slaby,
Evgeniy Polyakov, linux-doc, linux-kernel, linux-mips,
linux-input, netdev, linux-rtc, linux-serial
In-Reply-To: <20190820062308.GK3545@piout.net>
On Tue, 20 Aug 2019 08:23:08 +0200
Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:
> On 19/08/2019 18:31:38+0200, Thomas Bogendoerfer wrote:
> > diff --git a/drivers/mfd/ioc3.c b/drivers/mfd/ioc3.c
> > new file mode 100644
> > index 000000000000..5bcb3461a189
> > --- /dev/null
> > +++ b/drivers/mfd/ioc3.c
> > @@ -0,0 +1,586 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * SGI IOC3 multifunction device driver
> > + *
> > + * Copyright (C) 2018, 2019 Thomas Bogendoerfer <tbogendoerfer@suse.de>
> > + *
> > + * Based on work by:
> > + * Stanislaw Skowronek <skylark@unaligned.org>
> > + * Joshua Kinard <kumba@gentoo.org>
> > + * Brent Casavant <bcasavan@sgi.com> - IOC4 master driver
> > + * Pat Gefre <pfg@sgi.com> - IOC3 serial port IRQ demuxer
> > + */
> > +
> > +#include <linux/delay.h>
> > +#include <linux/errno.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/mfd/core.h>
> > +#include <linux/module.h>
> > +#include <linux/pci.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/platform_data/sgi-w1.h>
> > +#include <linux/rtc/ds1685.h>
> I don't think this include is necessary.
you are right. I'll move it to the patch where IP30 systemboard gets added.
Thanks,
Thomas.
--
SUSE Linux GmbH
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH net-next 0/6] Dynamic toggling of vlan_filtering for SJA1105 DSA
From: Vivien Didelot @ 2019-08-20 8:04 UTC (permalink / raw)
To: Vladimir Oltean
Cc: f.fainelli, andrew, idosch, roopa, nikolay, davem, netdev,
Vladimir Oltean
In-Reply-To: <20190820000002.9776-1-olteanv@gmail.com>
On Tue, 20 Aug 2019 02:59:56 +0300, Vladimir Oltean <olteanv@gmail.com> wrote:
> This patchset addresses a few limitations in DSA and the bridge core
> that made it impossible for this sequence of commands to work:
>
> ip link add name br0 type bridge
> ip link set dev swp2 master br0
> echo 1 > /sys/class/net/br0/bridge/vlan_filtering
>
> Only this sequence was previously working:
>
> ip link add name br0 type bridge vlan_filtering 1
> ip link set dev swp2 master br0
This is not quite true, these sequences of commands do "work". What I see
though is that with the first sequence, the PVID 1 won't be programmed in
the hardware. But the second sequence does program the hardware.
But following bridge members will be correctly programmed with the VLAN
though. The sequence below programs the hardware with VLAN 1 for swp3 as
well as CPU and DSA ports, but not for swp2:
ip link add name br0 type bridge
ip link set dev swp2 master br0
echo 1 > /sys/class/net/br0/bridge/vlan_filtering
ip link set dev swp3 master br0
This is unfortunately also true for any 802.1Q VLANs. For example, only VID
43 is programmed with the following sequence, but not VID 1 and VID 42:
ip link add name br0 type bridge
ip link set dev swp2 master br0
bridge vlan add dev swp2 vid 42
echo 1 > /sys/class/net/br0/bridge/vlan_filtering
bridge vlan add dev swp2 vid 43
So I understand that because VLANs are not propagated by DSA to the hardware
when VLAN filtering is disabled, a port may not be programmed with its
bridge's default PVID, and this is causing a problem for tag_8021q.
Please reword so that we understand better what is the issue being fixed here.
>
> On SJA1105, the situation is further complicated by the fact that
> toggling vlan_filtering is causing a switch reset. However, the hardware
> state restoration logic is already there in the driver. It is a matter
> of the layers above which need a few fixups.
>
> Also see this discussion thread:
> https://www.spinics.net/lists/netdev/msg581042.html
>
> Patch 1/6 is not functionally related but also related to dsa_8021q
> handling of VLANs and this is a good opportunity to bring up the subject
> for discussion.
So please send 1/6 as a separate patch and bring up the discussion there.
Thanks,
Vivien
^ permalink raw reply
* [PATCH net-next v4 0/2] dt-bindings: net: meson-dwmac: convert to yaml
From: Neil Armstrong @ 2019-08-20 7:57 UTC (permalink / raw)
To: davem, robh+dt
Cc: Neil Armstrong, martin.blumenstingl, devicetree, netdev,
linux-amlogic, linux-arm-kernel, linux-kernel
This patchsets converts the Amlogic Meson DWMAC glue bindings over to
YAML schemas using the already converted dwmac bindings.
The first patch is needed because the Amlogic glue needs a supplementary
reg cell to access the DWMAC glue registers.
Changes since v3:
- Specified net-next target tree
Changes since v2:
- Added review tags
- Updated allwinner,sun7i-a20-gmac.yaml reg maxItems
Neil Armstrong (2):
dt-bindings: net: snps,dwmac: update reg minItems maxItems
dt-bindings: net: meson-dwmac: convert to yaml
.../net/allwinner,sun7i-a20-gmac.yaml | 3 +
.../bindings/net/amlogic,meson-dwmac.yaml | 113 ++++++++++++++++++
.../devicetree/bindings/net/meson-dwmac.txt | 71 -----------
.../devicetree/bindings/net/snps,dwmac.yaml | 8 +-
4 files changed, 123 insertions(+), 72 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
delete mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
--
2.22.0
^ permalink raw reply
* [PATCH net-next v4 1/2] dt-bindings: net: snps,dwmac: update reg minItems maxItems
From: Neil Armstrong @ 2019-08-20 7:57 UTC (permalink / raw)
To: davem, robh+dt
Cc: Neil Armstrong, martin.blumenstingl, devicetree, netdev,
linux-amlogic, linux-arm-kernel, linux-kernel, Rob Herring,
Maxime Ripard
In-Reply-To: <20190820075742.14857-1-narmstrong@baylibre.com>
The Amlogic Meson DWMAC glue bindings needs a second reg cells for the
glue registers, thus update the reg minItems/maxItems to allow more
than a single reg cell.
Also update the allwinner,sun7i-a20-gmac.yaml derivative schema to specify
maxItems to 1.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml | 3 +++
Documentation/devicetree/bindings/net/snps,dwmac.yaml | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
index 06b1cc8bea14..ef446ae166f3 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
@@ -17,6 +17,9 @@ properties:
compatible:
const: allwinner,sun7i-a20-gmac
+ reg:
+ maxItems: 1
+
interrupts:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 76fea2be66ac..4377f511a51d 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -61,7 +61,8 @@ properties:
- snps,dwxgmac-2.10
reg:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
interrupts:
minItems: 1
--
2.22.0
^ permalink raw reply related
* [PATCH net-next v4 2/2] dt-bindings: net: meson-dwmac: convert to yaml
From: Neil Armstrong @ 2019-08-20 7:57 UTC (permalink / raw)
To: davem, robh+dt
Cc: Neil Armstrong, martin.blumenstingl, devicetree, netdev,
linux-amlogic, linux-arm-kernel, linux-kernel, Rob Herring
In-Reply-To: <20190820075742.14857-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Synopsys DWMAC Glue for Amlogic SoCs over to a YAML schemas.
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/net/amlogic,meson-dwmac.yaml | 113 ++++++++++++++++++
.../devicetree/bindings/net/meson-dwmac.txt | 71 -----------
.../devicetree/bindings/net/snps,dwmac.yaml | 5 +
3 files changed, 118 insertions(+), 71 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
delete mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
new file mode 100644
index 000000000000..ae91aa9d8616
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson DWMAC Ethernet controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+ - Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+# We need a select here so we don't match all nodes with 'snps,dwmac'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ required:
+ - compatible
+
+allOf:
+ - $ref: "snps,dwmac.yaml#"
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: GMAC main clock
+ - description: First parent clock of the internal mux
+ - description: Second parent clock of the internal mux
+
+ clock-names:
+ minItems: 3
+ maxItems: 3
+ items:
+ - const: stmmaceth
+ - const: clkin0
+ - const: clkin1
+
+ amlogic,tx-delay-ns:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description:
+ The internal RGMII TX clock delay (provided by this driver) in
+ nanoseconds. Allowed values are 0ns, 2ns, 4ns, 6ns.
+ When phy-mode is set to "rgmii" then the TX delay should be
+ explicitly configured. When not configured a fallback of 2ns is
+ used. When the phy-mode is set to either "rgmii-id" or "rgmii-txid"
+ the TX clock delay is already provided by the PHY. In that case
+ this property should be set to 0ns (which disables the TX clock
+ delay in the MAC to prevent the clock from going off because both
+ PHY and MAC are adding a delay).
+ Any configuration is ignored when the phy-mode is set to "rmii".
+
+properties:
+ compatible:
+ additionalItems: true
+ maxItems: 3
+ items:
+ - enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ contains:
+ enum:
+ - snps,dwmac-3.70a
+ - snps,dwmac
+
+ reg:
+ items:
+ - description:
+ The first register range should be the one of the DWMAC controller
+ - description:
+ The second range is is for the Amlogic specific configuration
+ (for example the PRG_ETHERNET register range on Meson8b and newer)
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - phy-mode
+
+examples:
+ - |
+ ethmac: ethernet@c9410000 {
+ compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+ reg = <0xc9410000 0x10000>, <0xc8834540 0x8>;
+ interrupts = <8>;
+ interrupt-names = "macirq";
+ clocks = <&clk_eth>, <&clkc_fclk_div2>, <&clk_mpll2>;
+ clock-names = "stmmaceth", "clkin0", "clkin1";
+ phy-mode = "rgmii";
+ };
diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt
deleted file mode 100644
index 1321bb194ed9..000000000000
--- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Amlogic Meson DWMAC Ethernet controller
-
-The device inherits all the properties of the dwmac/stmmac devices
-described in the file stmmac.txt in the current directory with the
-following changes.
-
-Required properties on all platforms:
-
-- compatible: Depending on the platform this should be one of:
- - "amlogic,meson6-dwmac"
- - "amlogic,meson8b-dwmac"
- - "amlogic,meson8m2-dwmac"
- - "amlogic,meson-gxbb-dwmac"
- - "amlogic,meson-axg-dwmac"
- Additionally "snps,dwmac" and any applicable more
- detailed version number described in net/stmmac.txt
- should be used.
-
-- reg: The first register range should be the one of the DWMAC
- controller. The second range is is for the Amlogic specific
- configuration (for example the PRG_ETHERNET register range
- on Meson8b and newer)
-
-Required properties on Meson8b, Meson8m2, GXBB and newer:
-- clock-names: Should contain the following:
- - "stmmaceth" - see stmmac.txt
- - "clkin0" - first parent clock of the internal mux
- - "clkin1" - second parent clock of the internal mux
-
-Optional properties on Meson8b, Meson8m2, GXBB and newer:
-- amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided
- by this driver) in nanoseconds. Allowed values
- are: 0ns, 2ns, 4ns, 6ns.
- When phy-mode is set to "rgmii" then the TX
- delay should be explicitly configured. When
- not configured a fallback of 2ns is used.
- When the phy-mode is set to either "rgmii-id"
- or "rgmii-txid" the TX clock delay is already
- provided by the PHY. In that case this
- property should be set to 0ns (which disables
- the TX clock delay in the MAC to prevent the
- clock from going off because both PHY and MAC
- are adding a delay).
- Any configuration is ignored when the phy-mode
- is set to "rmii".
-
-Example for Meson6:
-
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson6-dwmac", "snps,dwmac";
- reg = <0xc9410000 0x10000
- 0xc1108108 0x4>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clk81>;
- clock-names = "stmmaceth";
- }
-
-Example for GXBB:
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
- reg = <0x0 0xc9410000 0x0 0x10000>,
- <0x0 0xc8834540 0x0 0x8>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clkc CLKID_ETH>,
- <&clkc CLKID_FCLK_DIV2>,
- <&clkc CLKID_MPLL2>;
- clock-names = "stmmaceth", "clkin0", "clkin1";
- phy-mode = "rgmii";
- };
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 4377f511a51d..c78be15704b9 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -50,6 +50,11 @@ properties:
- allwinner,sun8i-r40-emac
- allwinner,sun8i-v3s-emac
- allwinner,sun50i-a64-emac
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
- snps,dwmac
- snps,dwmac-3.50a
- snps,dwmac-3.610
--
2.22.0
^ permalink raw reply related
* Re: [PATCH -next] bpf: Use PTR_ERR_OR_ZERO in xsk_map_inc()
From: Björn Töpel @ 2019-08-20 7:28 UTC (permalink / raw)
To: YueHaibing, magnus.karlsson, jonathan.lemon, ast, daniel, kafai,
songliubraving, yhs, john.fastabend
Cc: netdev, bpf, kernel-janitors
In-Reply-To: <20190820013652.147041-1-yuehaibing@huawei.com>
On 2019-08-20 03:36, YueHaibing wrote:
> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> kernel/bpf/xskmap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/xskmap.c b/kernel/bpf/xskmap.c
> index 4cc28e226398..942c662e2eed 100644
> --- a/kernel/bpf/xskmap.c
> +++ b/kernel/bpf/xskmap.c
> @@ -21,7 +21,7 @@ int xsk_map_inc(struct xsk_map *map)
> struct bpf_map *m = &map->map;
>
> m = bpf_map_inc(m, false);
> - return IS_ERR(m) ? PTR_ERR(m) : 0;
> + return PTR_ERR_OR_ZERO(m);
> }
>
> void xsk_map_put(struct xsk_map *map)
>
Acked-by: Björn Töpel <bjorn.topel@intel.com>
Thanks for the patch!
For future patches: Prefix AF_XDP socket work with "xsk:" and use "PATCH
bpf-next" to let the developers know what tree you're aiming for.
Cheers!
Björn
>
>
^ permalink raw reply
* Re: regression in ath10k dma allocation
From: Christoph Hellwig @ 2019-08-20 7:12 UTC (permalink / raw)
To: Hillf Danton
Cc: Christoph Hellwig, Tobias Klausmann, Nicolin Chen, kvalo, davem,
ath10k, linux-wireless, netdev, linux-kernel, m.szyprowski,
robin.murphy, iommu, tobias.klausmann
In-Reply-To: <20190820065833.1628-1-hdanton@sina.com>
On Tue, Aug 20, 2019 at 02:58:33PM +0800, Hillf Danton wrote:
>
> On Tue, 20 Aug 2019 05:05:14 +0200 Christoph Hellwig wrote:
> >
> > Tobias, plase try this patch:
> >
New version below:
---
From b8a805e93be5a5662323b8ac61fe686df839c4ac Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch@lst.de>
Date: Tue, 20 Aug 2019 11:45:49 +0900
Subject: dma-direct: fix zone selection after an unaddressable CMA allocation
The new dma_alloc_contiguous hides if we allocate CMA or regular
pages, and thus fails to retry a ZONE_NORMAL allocation if the CMA
allocation succeeds but isn't addressable. That means we either fail
outright or dip into a small zone that might not succeed either.
Thanks to Hillf Danton for debugging this issue.
Fixes: b1d2dc009dec ("dma-contiguous: add dma_{alloc,free}_contiguous() helpers")
Reported-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/iommu/dma-iommu.c | 3 +++
include/linux/dma-contiguous.h | 5 +----
kernel/dma/contiguous.c | 9 +++------
kernel/dma/direct.c | 10 +++++++++-
4 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index d991d40f797f..f68a62c3c32b 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -965,10 +965,13 @@ static void *iommu_dma_alloc_pages(struct device *dev, size_t size,
{
bool coherent = dev_is_dma_coherent(dev);
size_t alloc_size = PAGE_ALIGN(size);
+ int node = dev_to_node(dev);
struct page *page = NULL;
void *cpu_addr;
page = dma_alloc_contiguous(dev, alloc_size, gfp);
+ if (!page)
+ page = alloc_pages_node(node, gfp, get_order(alloc_size));
if (!page)
return NULL;
diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index c05d4e661489..03f8e98e3bcc 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -160,10 +160,7 @@ bool dma_release_from_contiguous(struct device *dev, struct page *pages,
static inline struct page *dma_alloc_contiguous(struct device *dev, size_t size,
gfp_t gfp)
{
- int node = dev ? dev_to_node(dev) : NUMA_NO_NODE;
- size_t align = get_order(PAGE_ALIGN(size));
-
- return alloc_pages_node(node, gfp, align);
+ return NULL;
}
static inline void dma_free_contiguous(struct device *dev, struct page *page,
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 2bd410f934b3..e6b450fdbeb6 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -230,9 +230,7 @@ bool dma_release_from_contiguous(struct device *dev, struct page *pages,
*/
struct page *dma_alloc_contiguous(struct device *dev, size_t size, gfp_t gfp)
{
- int node = dev ? dev_to_node(dev) : NUMA_NO_NODE;
- size_t count = PAGE_ALIGN(size) >> PAGE_SHIFT;
- size_t align = get_order(PAGE_ALIGN(size));
+ size_t count = size >> PAGE_SHIFT;
struct page *page = NULL;
struct cma *cma = NULL;
@@ -243,14 +241,12 @@ struct page *dma_alloc_contiguous(struct device *dev, size_t size, gfp_t gfp)
/* CMA can be used only in the context which permits sleeping */
if (cma && gfpflags_allow_blocking(gfp)) {
+ size_t align = get_order(size);
size_t cma_align = min_t(size_t, align, CONFIG_CMA_ALIGNMENT);
page = cma_alloc(cma, count, cma_align, gfp & __GFP_NOWARN);
}
- /* Fallback allocation of normal pages */
- if (!page)
- page = alloc_pages_node(node, gfp, align);
return page;
}
@@ -258,6 +254,7 @@ struct page *dma_alloc_contiguous(struct device *dev, size_t size, gfp_t gfp)
* dma_free_contiguous() - release allocated pages
* @dev: Pointer to device for which the pages were allocated.
* @page: Pointer to the allocated pages.
+ int node = dev ? dev_to_node(dev) : NUMA_NO_NODE;
* @size: Size of allocated pages.
*
* This function releases memory allocated by dma_alloc_contiguous(). As the
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 795c9b095d75..706113c6bebc 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -85,6 +85,8 @@ static bool dma_coherent_ok(struct device *dev, phys_addr_t phys, size_t size)
struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
{
+ size_t alloc_size = PAGE_ALIGN(size);
+ int node = dev_to_node(dev);
struct page *page = NULL;
u64 phys_mask;
@@ -95,8 +97,14 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
gfp &= ~__GFP_ZERO;
gfp |= __dma_direct_optimal_gfp_mask(dev, dev->coherent_dma_mask,
&phys_mask);
+ page = dma_alloc_contiguous(dev, alloc_size, gfp);
+ if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
+ dma_free_contiguous(dev, page, alloc_size);
+ page = NULL;
+ }
again:
- page = dma_alloc_contiguous(dev, size, gfp);
+ if (!page)
+ page = alloc_pages_node(node, gfp, get_order(alloc_size));
if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
dma_free_contiguous(dev, page, size);
page = NULL;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next] net: openvswitch: Set OvS recirc_id from tc chain
From: Paul Blakey @ 2019-08-20 7:08 UTC (permalink / raw)
To: Pravin Shelar, Marcelo Ricardo Leitner
Cc: Linux Kernel Network Developers, David S. Miller, Justin Pettit,
Simon Horman, Vlad Buslov, Jiri Pirko, Roi Dayan, Yossi Kuperman,
Rony Efraim, Oz Shlomo
In-Reply-To: <CAOrHB_ANDffyHx41TKEMGyrM25ZGuYBAqTqujS9BdRSDjRyFJA@mail.gmail.com>
On 8/20/2019 8:50 AM, Pravin Shelar wrote:
> On Mon, Aug 19, 2019 at 10:42 AM Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
>> On Sun, Aug 18, 2019 at 07:00:59PM +0300, Paul Blakey wrote:
>>> What do you guys say about the following diff on top of the last one?
>>> Use static key, and also have OVS_DP_CMD_SET command probe/enable the feature.
>>>
>>> This will allow userspace to probe the feature, and selectivly enable it via the
>>> OVS_DP_CMD_SET command.
>> I'm not convinced yet that we need something like this. Been
>> wondering, skb_ext_find() below is not that expensive if not in use.
>> It's just a bit check and that's it, it returns NULL.
>>
>> And drivers will only be setting this if they have tc-offloading
>> enabled (assuming they won't be seeing it for chain 0 all the time).
>> On which case, with tc offloading, we need this in order to work
>> properly.
>>
>> Is the bit checking really that worrysome?
>>
> Point is this would be completely unnecessary check for software only
> cases, that is what static key is used for, when you have a feature in
> datapath that is not used by majority of users. So I do not see any
> downside of having this static key.
Also it's good that I can now probe kernel support via OVS_DP_CMD_SET.
Since user can disable the kernel support or even use a different
version of the datapath module, it would silently bug on misses from tc.
Now I can set the recirc sharing feature in user_feature via SET op, and
check the returned new user_features or an error code.
If no error, and user_features contains the flag (won't be there for
older DPs that won't return error), then DP supports this feature and
kernel config is enabled.
^ permalink raw reply
* Re: [v3] ocelot_ace: fix action of trap
From: Allan W . Nielsen @ 2019-08-20 7:05 UTC (permalink / raw)
To: Yangbo Lu
Cc: netdev, David S . Miller, Alexandre Belloni,
Microchip Linux Driver Support, Andrew Lunn
In-Reply-To: <20190820042005.12776-1-yangbo.lu@nxp.com>
Hi,
This is fixing a bug introduced in b596229448dd2
Acked-by: Allan W. Nielsen <allan.nielsen@microchip.com>
/Allan
The 08/20/2019 12:20, Yangbo Lu wrote:
> External E-Mail
>
>
> The trap action should be copying the frame to CPU and
> dropping it for forwarding, but current setting was just
> copying frame to CPU.
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> ---
> drivers/net/ethernet/mscc/ocelot_ace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mscc/ocelot_ace.c b/drivers/net/ethernet/mscc/ocelot_ace.c
> index 39aca1a..86fc6e6 100644
> --- a/drivers/net/ethernet/mscc/ocelot_ace.c
> +++ b/drivers/net/ethernet/mscc/ocelot_ace.c
> @@ -317,7 +317,7 @@ static void is2_action_set(struct vcap_data *data,
> break;
> case OCELOT_ACL_ACTION_TRAP:
> VCAP_ACT_SET(PORT_MASK, 0x0);
> - VCAP_ACT_SET(MASK_MODE, 0x0);
> + VCAP_ACT_SET(MASK_MODE, 0x1);
> VCAP_ACT_SET(POLICE_ENA, 0x0);
> VCAP_ACT_SET(POLICE_IDX, 0x0);
> VCAP_ACT_SET(CPU_QU_NUM, 0x0);
> --
> 2.7.4
>
>
--
/Allan
^ permalink raw reply
* Re: Unable to create htb tc classes more than 64K
From: Akshat Kakkar @ 2019-08-20 6:26 UTC (permalink / raw)
To: Cong Wang, Anton Danilov; +Cc: NetFilter, lartc, netdev
In-Reply-To: <CAA5aLPjzX+9YFRGgCgceHjkU0=e6x8YMENfp_cC9fjfHYK3e+A@mail.gmail.com>
>> If your goal is merely having as many classes as you can, then yes.
My goal is not just to make as many classes as possible, but also to
use them to do rate limiting per ip per server. Say, I have a list of
10000 IPs and more than 100 servers. So simply if I want few IPs to
get speed of says 1Mbps per server but others say speed of 2 Mbps per
server. How can I achieve this without having 10000 x 100 classes.
These numbers can be large than this and hence I am looking for a
generic solution to this.
I am using ipset + iptables to classify and not filters.
Besides, if tc is allowing me to define qdisc (100:) -> classes
(100:1) -> qdisc(1: 2: 3: ) -> classes (1:1,1:2 2:1,2:2 3:1,
3:2 ...) sort of structure (ie like the one shown in ascii tree)
then how should those lowest child classes be actually used or
consumed or where it can be used?
^ permalink raw reply
* Re: [PATCH v5 15/17] mfd: ioc3: Add driver for SGI IOC3 chip
From: Alexandre Belloni @ 2019-08-20 6:23 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Jonathan Corbet, Ralf Baechle, Paul Burton, James Hogan,
Dmitry Torokhov, Lee Jones, David S. Miller, Srinivas Kandagatla,
Alessandro Zummo, Greg Kroah-Hartman, Jiri Slaby,
Evgeniy Polyakov, linux-doc, linux-kernel, linux-mips,
linux-input, netdev, linux-rtc, linux-serial
In-Reply-To: <20190819163144.3478-16-tbogendoerfer@suse.de>
Hi,
On 19/08/2019 18:31:38+0200, Thomas Bogendoerfer wrote:
> diff --git a/drivers/mfd/ioc3.c b/drivers/mfd/ioc3.c
> new file mode 100644
> index 000000000000..5bcb3461a189
> --- /dev/null
> +++ b/drivers/mfd/ioc3.c
> @@ -0,0 +1,586 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * SGI IOC3 multifunction device driver
> + *
> + * Copyright (C) 2018, 2019 Thomas Bogendoerfer <tbogendoerfer@suse.de>
> + *
> + * Based on work by:
> + * Stanislaw Skowronek <skylark@unaligned.org>
> + * Joshua Kinard <kumba@gentoo.org>
> + * Brent Casavant <bcasavan@sgi.com> - IOC4 master driver
> + * Pat Gefre <pfg@sgi.com> - IOC3 serial port IRQ demuxer
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/errno.h>
> +#include <linux/interrupt.h>
> +#include <linux/mfd/core.h>
> +#include <linux/module.h>
> +#include <linux/pci.h>
> +#include <linux/platform_device.h>
> +#include <linux/platform_data/sgi-w1.h>
> +#include <linux/rtc/ds1685.h>
I don't think this include is necessary.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next 4/6] net: dsa: Don't program the VLAN as pvid on the upstream port
From: Vivien Didelot @ 2019-08-20 6:07 UTC (permalink / raw)
To: Vladimir Oltean
Cc: f.fainelli, andrew, idosch, roopa, nikolay, davem, netdev,
Vladimir Oltean
In-Reply-To: <20190820000002.9776-5-olteanv@gmail.com>
On Tue, 20 Aug 2019 03:00:00 +0300, Vladimir Oltean <olteanv@gmail.com> wrote:
> Commit b2f81d304cee ("net: dsa: add CPU and DSA ports as VLAN members")
> programs the VLAN from the bridge into the specified port as well as the
> upstream port, with the same set of flags.
>
> Consider the typical case of installing pvid 1 on user port 1, pvid 2 on
> user port 2, etc. The upstream port would end up having a pvid equal to
> the last user port whose pvid was programmed from the bridge. Less than
> useful.
>
> So just don't change the pvid of the upstream port and let it be
> whatever the driver set it internally to be.
>
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> ---
> net/dsa/switch.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/net/dsa/switch.c b/net/dsa/switch.c
> index 84ab2336131e..02ccc53f1926 100644
> --- a/net/dsa/switch.c
> +++ b/net/dsa/switch.c
> @@ -239,17 +239,21 @@ dsa_switch_vlan_prepare_bitmap(struct dsa_switch *ds,
> const struct switchdev_obj_port_vlan *vlan,
> const unsigned long *bitmap)
> {
> + struct switchdev_obj_port_vlan v = *vlan;
> int port, err;
>
> if (!ds->ops->port_vlan_prepare || !ds->ops->port_vlan_add)
> return -EOPNOTSUPP;
>
> for_each_set_bit(port, bitmap, ds->num_ports) {
> - err = dsa_port_vlan_check(ds, port, vlan);
> + if (dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port))
> + v.flags &= ~BRIDGE_VLAN_INFO_PVID;
So you keep the BRIDGE_VLAN_INFO_PVID flag cleared for all other ports that
come after any CPU or DSA port?
> +
> + err = dsa_port_vlan_check(ds, port, &v);
> if (err)
> return err;
>
> - err = ds->ops->port_vlan_prepare(ds, port, vlan);
> + err = ds->ops->port_vlan_prepare(ds, port, &v);
> if (err)
> return err;
> }
> @@ -262,10 +266,14 @@ dsa_switch_vlan_add_bitmap(struct dsa_switch *ds,
> const struct switchdev_obj_port_vlan *vlan,
> const unsigned long *bitmap)
> {
> + struct switchdev_obj_port_vlan v = *vlan;
> int port;
>
> - for_each_set_bit(port, bitmap, ds->num_ports)
> - ds->ops->port_vlan_add(ds, port, vlan);
> + for_each_set_bit(port, bitmap, ds->num_ports) {
> + if (dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port))
> + v.flags &= ~BRIDGE_VLAN_INFO_PVID;
Same here. Did you intend to initialize your switchdev_obj_port_vlan structure
_within_ the for_each_set_bit loop maybe?
> + ds->ops->port_vlan_add(ds, port, &v);
> + }
> }
>
> static int dsa_switch_vlan_add(struct dsa_switch *ds,
Do you even test your patches?
^ permalink raw reply
* [PATCH][V2] net: fix __ip_mc_inc_group usage
From: Li RongQing @ 2019-08-20 5:52 UTC (permalink / raw)
To: netdev, f.fainelli
in ip_mc_inc_group, memory allocation flag, not mcast mode, is expected
by __ip_mc_inc_group
similar issue in __ip_mc_join_group, both mcase mode and gfp_t are needed
here, so use ____ip_mc_inc_group(...)
Fixes: 9fb20801dab4 ("net: Fix ip_mc_{dec,inc}_group allocation context")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
---
v1-->v2:
fixes "Fixes tag"
use ____ip_mc_inc_group in __ip_mc_join_group
net/ipv4/igmp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 180f6896b98b..480d0b22db1a 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1475,7 +1475,7 @@ EXPORT_SYMBOL(__ip_mc_inc_group);
void ip_mc_inc_group(struct in_device *in_dev, __be32 addr)
{
- __ip_mc_inc_group(in_dev, addr, MCAST_EXCLUDE);
+ __ip_mc_inc_group(in_dev, addr, GFP_KERNEL);
}
EXPORT_SYMBOL(ip_mc_inc_group);
@@ -2197,7 +2197,7 @@ static int __ip_mc_join_group(struct sock *sk, struct ip_mreqn *imr,
iml->sflist = NULL;
iml->sfmode = mode;
rcu_assign_pointer(inet->mc_list, iml);
- __ip_mc_inc_group(in_dev, addr, mode);
+ ____ip_mc_inc_group(in_dev, addr, mode, GFP_KERNEL);
err = 0;
done:
return err;
--
2.16.2
^ permalink raw reply related
* Re: [PATCH net-next 3/6] net: dsa: Delete the VID from the upstream port as well
From: Vivien Didelot @ 2019-08-20 5:51 UTC (permalink / raw)
To: Vladimir Oltean
Cc: f.fainelli, andrew, idosch, roopa, nikolay, davem, netdev,
Vladimir Oltean
In-Reply-To: <20190820000002.9776-4-olteanv@gmail.com>
Vladimir,
On Tue, 20 Aug 2019 02:59:59 +0300, Vladimir Oltean <olteanv@gmail.com> wrote:
> Commit b2f81d304cee ("net: dsa: add CPU and DSA ports as VLAN members")
> is littering a lot. After deleting a VLAN added on a DSA port, it still
> remains installed in the hardware filter of the upstream port. Fix this.
Littering a lot, really?
FYI we are not removing the target VLAN from the hardware yet because it would
be too expensive to cache data in DSA core in order to know if the VID is not
used by any other slave port of the fabric anymore, and thus safe to remove.
Keeping the VID programmed for DSA and CPU ports is simpler for the moment,
as an hardware VLAN with only these ports as members is unlikely to harm.
>
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> ---
> net/dsa/switch.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/net/dsa/switch.c b/net/dsa/switch.c
> index 09d9286b27cc..84ab2336131e 100644
> --- a/net/dsa/switch.c
> +++ b/net/dsa/switch.c
> @@ -295,11 +295,20 @@ static int dsa_switch_vlan_del(struct dsa_switch *ds,
> struct dsa_notifier_vlan_info *info)
> {
> const struct switchdev_obj_port_vlan *vlan = info->vlan;
> + int port;
>
> if (!ds->ops->port_vlan_del)
> return -EOPNOTSUPP;
>
> + /* Build a mask of VLAN members */
> + bitmap_zero(ds->bitmap, ds->num_ports);
> if (ds->index == info->sw_index)
> + set_bit(info->port, ds->bitmap);
> + for (port = 0; port < ds->num_ports; port++)
> + if (dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port))
> + set_bit(port, ds->bitmap);
> +
> + for_each_set_bit(port, ds->bitmap, ds->num_ports)
> return ds->ops->port_vlan_del(ds, info->port, vlan);
You return right away from the loop? You use info->port instead of port?
>
> return 0;
Even if you patch wasn't badly broken, "bridge vlan del" targeting a single
switch port would also remove the VLAN from the CPU port and thus breaking
offloaded 802.1q. It would also remove it from the DSA ports interconnecting
multiple switches, thus breaking the 802.1q conduit for the whole fabric.
So you're not fixing anything here, but you're breaking single-chip and
cross-chip hardware VLAN. Seriously wtf is this patch?
NAK!
Vivien
^ permalink raw reply
* Re: [PATCH net-next] net: openvswitch: Set OvS recirc_id from tc chain
From: Pravin Shelar @ 2019-08-20 5:52 UTC (permalink / raw)
To: Paul Blakey
Cc: Linux Kernel Network Developers, David S. Miller, Justin Pettit,
Simon Horman, Marcelo Ricardo Leitner, Vlad Buslov, Jiri Pirko,
Roi Dayan, Yossi Kuperman, Rony Efraim, Oz Shlomo
In-Reply-To: <1566144059-8247-1-git-send-email-paulb@mellanox.com>
On Sun, Aug 18, 2019 at 9:01 AM Paul Blakey <paulb@mellanox.com> wrote:
>
> What do you guys say about the following diff on top of the last one?
> Use static key, and also have OVS_DP_CMD_SET command probe/enable the feature.
>
> This will allow userspace to probe the feature, and selectivly enable it via the
> OVS_DP_CMD_SET command.
>
This approach looks good to me.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: openvswitch: Set OvS recirc_id from tc chain
From: Pravin Shelar @ 2019-08-20 5:50 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Paul Blakey, Linux Kernel Network Developers, David S. Miller,
Justin Pettit, Simon Horman, Vlad Buslov, Jiri Pirko, Roi Dayan,
Yossi Kuperman, Rony Efraim, Oz Shlomo
In-Reply-To: <20190819174241.GE2699@localhost.localdomain>
On Mon, Aug 19, 2019 at 10:42 AM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Sun, Aug 18, 2019 at 07:00:59PM +0300, Paul Blakey wrote:
> > What do you guys say about the following diff on top of the last one?
> > Use static key, and also have OVS_DP_CMD_SET command probe/enable the feature.
> >
> > This will allow userspace to probe the feature, and selectivly enable it via the
> > OVS_DP_CMD_SET command.
>
> I'm not convinced yet that we need something like this. Been
> wondering, skb_ext_find() below is not that expensive if not in use.
> It's just a bit check and that's it, it returns NULL.
>
> And drivers will only be setting this if they have tc-offloading
> enabled (assuming they won't be seeing it for chain 0 all the time).
> On which case, with tc offloading, we need this in order to work
> properly.
>
> Is the bit checking really that worrysome?
>
Point is this would be completely unnecessary check for software only
cases, that is what static key is used for, when you have a feature in
datapath that is not used by majority of users. So I do not see any
downside of having this static key.
^ permalink raw reply
* Re: [PATCH 1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot
From: Florian Westphal @ 2019-08-20 5:36 UTC (permalink / raw)
To: Leonardo Bras
Cc: netfilter-devel, coreteam, netdev, linux-kernel,
Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David S. Miller
In-Reply-To: <20190820005821.2644-1-leonardo@linux.ibm.com>
Leonardo Bras <leonardo@linux.ibm.com> wrote:
> If IPv6 is disabled on boot (ipv6.disable=1), but nft_fib_inet ends up
> dealing with a IPv6 package, it causes a kernel panic in
> fib6_node_lookup_1(), crashing in bad_page_fault.
>
> The panic is caused by trying to deference a very low address (0x38
> in ppc64le), due to ipv6.fib6_main_tbl = NULL.
> BUG: Kernel NULL pointer dereference at 0x00000038
>
> Fix this behavior by dropping IPv6 packages if !ipv6_mod_enabled().
Wouldn't fib_netdev.c have the same problem?
If so, might be better to place this test in both
nft_fib6_eval_type and nft_fib6_eval.
^ permalink raw reply
* Re: [PATCH] nfc: st-nci: Fix an incorrect skb_buff size in 'st_nci_i2c_read()'
From: Christophe JAILLET @ 2019-08-20 5:33 UTC (permalink / raw)
To: David Miller
Cc: tglx, gregkh, colin.king, allison, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <20190811.205719.198343441735959015.davem@davemloft.net>
Le 12/08/2019 à 05:57, David Miller a écrit :
> From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> Date: Tue, 6 Aug 2019 16:16:40 +0200
>
>> In 'st_nci_i2c_read()', we allocate a sk_buff with a size of
>> ST_NCI_I2C_MIN_SIZE + len.
>>
>> However, later on, we first 'skb_reserve()' ST_NCI_I2C_MIN_SIZE bytes, then
>> we 'skb_put()' ST_NCI_I2C_MIN_SIZE bytes.
>> Finally, if 'len' is not 0, we 'skb_put()' 'len' bytes.
>>
>> So we use ST_NCI_I2C_MIN_SIZE*2 + len bytes.
>>
>> This is incorrect and should already panic. I guess that it does not occur
>> because of extra memory allocated because of some rounding.
>>
>> Fix it and allocate enough room for the 'skb_reserve()' and the 'skb_put()'
>> calls.
>>
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>> ---
>> This patch is LIKELY INCORRECT. So think twice to what is the correct
>> solution before applying it.
>> Maybe the skb_reserve should be axed or some other sizes are incorrect.
>> There seems to be an issue, that's all I can say.
> The skb_reserve() should be removed,
I don't fully understand the potential implications, but looks ok to me.
At least, the allocated memory and the size of the used memory would match.
What I don't understand is why is does not BUG_ON with the current code.
Does my suspected "over allocation" because of rounding/aligment could
hide the issue?
A Tested-by: by someone who has the corresponding hardware would also be
useful IMHO.
> and the second memcpy() should remove
> the " + ST_NCI_I2C_MIN_SIZE".
Hmm, not sure on this one.
The skb is manipulated only with skb_put. So only the tail pointer and
len are updated. The data pointer remains at the same position, so there
should effectively be an offset of ST_NCI_I2C_MIN_SIZE for the 2nd memcpy.
Maybe, using skb_put_data would be cleaner here, in order to
"concatenate" these 2 parts without having to handle by hand the right
position in the buffer.
If you agree, I'll send a V2.
Thx for the review and comments.
CJ
> This SKB just get sent down to ndlc_recv() so the content returned from I2C
> should places at skb->data to be processed.
>
> Pretty clear this code was never tested.
^ permalink raw reply
* [PATCH v3] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
From: Jian-Hong Pan @ 2019-08-20 4:59 UTC (permalink / raw)
To: Yan-Hsuan Chuang, Kalle Valo, David S . Miller
Cc: linux-wireless, netdev, linux-kernel, linux, Jian-Hong Pan
In-Reply-To: <CAPpJ_edU68X-Ki+J61qfws+1-=zv54bcak9tzkMX=CkDS5mOMA@mail.gmail.com>
There is a mass of jobs between spin lock and unlock in the hardware
IRQ which will occupy much time originally. To make system work more
efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
reduce the time in hardware IRQ.
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
---
v2:
Change the spin_lock_irqsave/unlock_irqrestore to spin_lock/unlock in
rtw_pci_interrupt_handler. Because the interrupts are already disabled
in the hardware interrupt handler.
v3:
Extend the spin lock protecting area for the TX path in
rtw_pci_interrupt_threadfn by Realtek's suggestion
drivers/net/wireless/realtek/rtw88/pci.c | 33 +++++++++++++++++++-----
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
index 00ef229552d5..a8c17a01f318 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void *dev)
{
struct rtw_dev *rtwdev = dev;
struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
- u32 irq_status[4];
spin_lock(&rtwpci->irq_lock);
if (!rtwpci->irq_enabled)
goto out;
+ /* disable RTW PCI interrupt to avoid more interrupts before the end of
+ * thread function
+ */
+ rtw_pci_disable_interrupt(rtwdev, rtwpci);
+out:
+ spin_unlock(&rtwpci->irq_lock);
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
+{
+ struct rtw_dev *rtwdev = dev;
+ struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+ unsigned long flags;
+ u32 irq_status[4];
+
+ spin_lock_irqsave(&rtwpci->irq_lock, flags);
rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
if (irq_status[0] & IMR_MGNTDOK)
@@ -891,8 +908,10 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void *dev)
if (irq_status[0] & IMR_ROK)
rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
-out:
- spin_unlock(&rtwpci->irq_lock);
+ /* all of the jobs for this interrupt have been done */
+ if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
+ rtw_pci_enable_interrupt(rtwdev, rtwpci);
+ spin_unlock_irqrestore(&rtwpci->irq_lock, flags);
return IRQ_HANDLED;
}
@@ -1152,8 +1171,10 @@ static int rtw_pci_probe(struct pci_dev *pdev,
goto err_destroy_pci;
}
- ret = request_irq(pdev->irq, &rtw_pci_interrupt_handler,
- IRQF_SHARED, KBUILD_MODNAME, rtwdev);
+ ret = devm_request_threaded_irq(rtwdev->dev, pdev->irq,
+ rtw_pci_interrupt_handler,
+ rtw_pci_interrupt_threadfn,
+ IRQF_SHARED, KBUILD_MODNAME, rtwdev);
if (ret) {
ieee80211_unregister_hw(hw);
goto err_destroy_pci;
@@ -1192,7 +1213,7 @@ static void rtw_pci_remove(struct pci_dev *pdev)
rtw_pci_disable_interrupt(rtwdev, rtwpci);
rtw_pci_destroy(rtwdev, pdev);
rtw_pci_declaim(rtwdev, pdev);
- free_irq(rtwpci->pdev->irq, rtwdev);
+ devm_free_irq(rtwdev->dev, rtwpci->pdev->irq, rtwdev);
rtw_core_deinit(rtwdev);
ieee80211_free_hw(hw);
}
--
2.20.1
^ permalink raw reply related
* RE: [v2, 3/4] ocelot_ace: fix action of trap
From: Y.b. Lu @ 2019-08-20 4:23 UTC (permalink / raw)
To: Allan W . Nielsen
Cc: netdev@vger.kernel.org, David S . Miller, Alexandre Belloni,
Microchip Linux Driver Support
In-Reply-To: <20190813063011.7pwlzm7mtzlqwwkx@lx-anielsen.microsemi.net>
Hi,
> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> Behalf Of Allan W . Nielsen
> Sent: Tuesday, August 13, 2019 2:30 PM
> To: Y.b. Lu <yangbo.lu@nxp.com>
> Cc: netdev@vger.kernel.org; David S . Miller <davem@davemloft.net>;
> Alexandre Belloni <alexandre.belloni@bootlin.com>; Microchip Linux Driver
> Support <UNGLinuxDriver@microchip.com>
> Subject: Re: [v2, 3/4] ocelot_ace: fix action of trap
>
> The 08/13/2019 08:16, Allan W . Nielsen wrote:
> > The 08/13/2019 10:52, Yangbo Lu wrote:
> > > The trap action should be copying the frame to CPU and dropping it
> > > for forwarding, but current setting was just copying frame to CPU.
> > >
> > > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> > > ---
> > > Changes for v2:
> > > - None.
> > > ---
> > > drivers/net/ethernet/mscc/ocelot_ace.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/mscc/ocelot_ace.c
> > > b/drivers/net/ethernet/mscc/ocelot_ace.c
> > > index 91250f3..59ad590 100644
> > > --- a/drivers/net/ethernet/mscc/ocelot_ace.c
> > > +++ b/drivers/net/ethernet/mscc/ocelot_ace.c
> > > @@ -317,9 +317,9 @@ static void is2_action_set(struct vcap_data *data,
> > > break;
> > > case OCELOT_ACL_ACTION_TRAP:
> > > VCAP_ACT_SET(PORT_MASK, 0x0);
> > > - VCAP_ACT_SET(MASK_MODE, 0x0);
> > > - VCAP_ACT_SET(POLICE_ENA, 0x0);
> > > - VCAP_ACT_SET(POLICE_IDX, 0x0);
> > > + VCAP_ACT_SET(MASK_MODE, 0x1);
> > > + VCAP_ACT_SET(POLICE_ENA, 0x1);
> > > + VCAP_ACT_SET(POLICE_IDX, OCELOT_POLICER_DISCARD);
> > > VCAP_ACT_SET(CPU_QU_NUM, 0x0);
> > > VCAP_ACT_SET(CPU_COPY_ENA, 0x1);
> > > break;
> >
> > This is still wrong, please see the comments provided the first time
> > you submitted this.
> >
> > /Allan
>
> I believe this will make it work - but I have not tested it:
>
> case OCELOT_ACL_ACTION_TRAP:
> VCAP_ACT_SET(PORT_MASK, 0x0);
> - VCAP_ACT_SET(MASK_MODE, 0x0);
> + VCAP_ACT_SET(MASK_MODE, 0x1);
> VCAP_ACT_SET(CPU_QU_NUM, 0x0);
> VCAP_ACT_SET(CPU_COPY_ENA, 0x1);
> break;
>
[Y.b. Lu] It makes sense. And it worked.
I have sent out v3 which only included this one patch. I'd like to send the other patches once Felix driver is accepted, but I'd like to collect the suggestions :)
Thanks.
Sorry, I missed to add change logs for v3 patch...
https://patchwork.ozlabs.org/patch/1149770/
> --
> /Allan
^ permalink raw reply
* [v3] ocelot_ace: fix action of trap
From: Yangbo Lu @ 2019-08-20 4:20 UTC (permalink / raw)
To: netdev, David S . Miller, Allan W . Nielsen, Alexandre Belloni,
Microchip Linux Driver Support, Andrew Lunn
Cc: Yangbo Lu
The trap action should be copying the frame to CPU and
dropping it for forwarding, but current setting was just
copying frame to CPU.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
drivers/net/ethernet/mscc/ocelot_ace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mscc/ocelot_ace.c b/drivers/net/ethernet/mscc/ocelot_ace.c
index 39aca1a..86fc6e6 100644
--- a/drivers/net/ethernet/mscc/ocelot_ace.c
+++ b/drivers/net/ethernet/mscc/ocelot_ace.c
@@ -317,7 +317,7 @@ static void is2_action_set(struct vcap_data *data,
break;
case OCELOT_ACL_ACTION_TRAP:
VCAP_ACT_SET(PORT_MASK, 0x0);
- VCAP_ACT_SET(MASK_MODE, 0x0);
+ VCAP_ACT_SET(MASK_MODE, 0x1);
VCAP_ACT_SET(POLICE_ENA, 0x0);
VCAP_ACT_SET(POLICE_IDX, 0x0);
VCAP_ACT_SET(CPU_QU_NUM, 0x0);
--
2.7.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