* Re: [PATCH net 0/2] action fixes for flow_offload infra compatibility
From: David Miller @ 2019-08-06 21:15 UTC (permalink / raw)
To: vladbu; +Cc: netdev, pieter.jansenvanvuuren, jhs, xiyou.wangcong, jiri
In-Reply-To: <20190803133619.10574-1-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Sat, 3 Aug 2019 16:36:17 +0300
> Fix rcu warnings due to usage of action helpers that expect rcu read lock
> protection from rtnl-protected context of flow_offload infra.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next 0/2] Two small fq_codel optimizations
From: David Miller @ 2019-08-06 21:18 UTC (permalink / raw)
To: dave.taht; +Cc: netdev
In-Reply-To: <1564875449-12122-1-git-send-email-dave.taht@gmail.com>
From: Dave Taht <dave.taht@gmail.com>
Date: Sat, 3 Aug 2019 16:37:27 -0700
> These two patches improve fq_codel performance
> under extreme network loads. The first patch
> more rapidly escalates the codel count under
> overload, the second just kills a totally useless
> statistic.
>
> (sent together because they'd otherwise conflict)
>
> Signed-off-by: Dave Taht <dave.taht@gmail.com>
Series applied.
^ permalink raw reply
* Re: [PATCH net-next] r8169: remove access to legacy register MultiIntr
From: David Miller @ 2019-08-06 21:20 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <d550e704-3854-d91e-22fd-253ede944c3e@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun, 4 Aug 2019 09:42:57 +0200
> This code piece was inherited from RTL8139 code, the register at
> address 0x5c however has a different meaning on RTL8169 and is unused.
> So we can remove this.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] r8169: add helper r8168_mac_ocp_modify
From: David Miller @ 2019-08-06 21:20 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <dc905b86-2852-86c2-be14-22164bd4a06d@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun, 4 Aug 2019 09:47:51 +0200
> Add a helper for MAC OCP read-modify-write operations.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] r8169: sync PCIe PHY init with vendor driver 8.047.01
From: David Miller @ 2019-08-06 21:20 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <52b6804e-b2d4-0724-9b71-45ec46f4b1b4@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun, 4 Aug 2019 09:52:33 +0200
> Synchronize PCIe PHY initialization with vendor driver version 8.047.01.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-next 0/8][pull request] 100GbE Intel Wired LAN Driver Updates 2019-08-04
From: David Miller @ 2019-08-06 21:21 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20190804115926.31944-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sun, 4 Aug 2019 04:59:18 -0700
> This series contains more updates to fm10k from Jake Keller.
>
> Jake removes the unnecessary initialization of some variables to help
> resolve static code checker warnings. Explicitly return success during
> resume, since the value of 'err' is always success. Fixed a issue with
> incrementing a void pointer, which can produce undefined behavior. Used
> the __always_unused macro for function templates that are passed as
> parameters in functions, but are not used. Simplified the code by
> removing an unnecessary macro in determining the value of NON_Q_VECTORS.
> Fixed an issue, using bitwise operations to prevent the low address
> overwriting the high portion of the address.
Pulled, thanks Jeff.
^ permalink raw reply
* linux-next: Fixes tag needs some work in the net tree
From: Stephen Rothwell @ 2019-08-06 21:22 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Roman Mashak
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
Hi all,
In commit
b35475c5491a ("net sched: update vlan action for batched events operations")
Fixes tag
Fixes: c7e2b9689 ("sched: introduce vlan action")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 00/10] Support tunnels over VLAN in NFP
From: David Miller @ 2019-08-06 21:24 UTC (permalink / raw)
To: john.hurley; +Cc: netdev, simon.horman, jakub.kicinski, oss-drivers
In-Reply-To: <1564931351-1036-1-git-send-email-john.hurley@netronome.com>
From: John Hurley <john.hurley@netronome.com>
Date: Sun, 4 Aug 2019 16:09:02 +0100
> This patchset deals with tunnel encap and decap when the end-point IP
> address is on an internal port (for example and OvS VLAN port). Tunnel
> encap without VLAN is already supported in the NFP driver. This patchset
> extends that to include a push VLAN along with tunnel header push.
>
> Patches 1-4 extend the flow_offload IR API to include actions that use
> skbedit to set the ptype of an SKB and that send a packet to port ingress
> from the act_mirred module. Such actions are used in flower rules that
> forward tunnel packets to internal ports where they can be decapsulated.
> OvS and its TC API is an example of a user-space app that produces such
> rules.
>
> Patch 5 modifies the encap offload code to allow the pushing of a VLAN
> header after a tunnel header push.
>
> Patches 6-10 deal with tunnel decap when the end-point is on an internal
> port. They detect 'pre-tunnel rules' which do not deal with tunnels
> themselves but, rather, forward packets to internal ports where they
> can be decapped if required. Such rules are offloaded to a table in HW
> along with an indication of whether packets need to be passed to this
> table of not (based on their destination MAC address). Matching against
> this table prior to decapsulation in HW allows the correct parsing and
> handling of outer VLANs on tunnelled packets and the correct updating of
> stats for said 'pre-tunnel' rules.
Series applied, thanks John.
^ permalink raw reply
* Re: [PATCH v2] net/mlx5e: Use refcount_t for refcount
From: Saeed Mahameed @ 2019-08-06 21:25 UTC (permalink / raw)
To: davem@davemloft.net
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
hslester96@gmail.com, linux-rdma@vger.kernel.org, leon@kernel.org
In-Reply-To: <20190806.134848.2232719643712591918.davem@davemloft.net>
On Tue, 2019-08-06 at 13:48 -0700, David Miller wrote:
> From: Saeed Mahameed <saeedm@mellanox.com>
> Date: Tue, 6 Aug 2019 20:42:56 +0000
>
> > On Sat, 2019-08-03 at 00:48 +0800, Chuhong Yuan wrote:
> > > refcount_t is better for reference counters since its
> > > implementation can prevent overflows.
> > > So convert atomic_t ref counters to refcount_t.
> > >
> > > Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> > > ---
> > > Changes in v2:
> > > - Add #include.
> > >
> >
> > Acked-by: Saeed Mahameed <saeedm@mellanox.com>
> >
> > Dave, up to you take it, or leave it to me :).
>
> Please take it, thank you.
Ok, running some build tests will apply shortly to net-next-mlx5.
Thanks everyone!
^ permalink raw reply
* Re: [PATCH net 0/5] Fixes for SJA1105 DSA: FDBs, Learning and PTP
From: David Miller @ 2019-08-06 21:38 UTC (permalink / raw)
To: olteanv; +Cc: f.fainelli, vivien.didelot, andrew, netdev
In-Reply-To: <20190804223848.31676-1-olteanv@gmail.com>
From: Vladimir Oltean <olteanv@gmail.com>
Date: Mon, 5 Aug 2019 01:38:43 +0300
> This is an assortment of functional fixes for the sja1105 switch driver
> targeted for the "net" tree (although they apply on net-next just as
> well).
>
> Patch 1/5 ("net: dsa: sja1105: Fix broken learning with vlan_filtering
> disabled") repairs a breakage introduced in the early development stages
> of the driver: support for traffic from the CPU has broken "normal"
> frame forwarding (based on DMAC) - there is connectivity through the
> switch only because all frames are flooded.
> I debated whether this patch qualifies as a fix, since it puts the
> switch into a mode it has never operated in before (aka SVL). But
> "normal" forwarding did use to work before the "Traffic support for
> SJA1105 DSA driver" patchset, and arguably this patch should have been
> part of that.
> Also, it would be strange for this feature to be broken in the 5.2 LTS.
>
> Patch 2/5 ("net: dsa: sja1105: Use the LOCKEDS bit for SJA1105 E/T as
> well") is a simplification of a previous FDB-related patch that is
> currently in the 5.3 rc's.
>
> Patches 3/5 - 5/5 fix various crashes found while running linuxptp over the
> switch ports for extended periods of time, or in conjunction with other
> error conditions. The fixed-up commits were all introduced in 5.2.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next v2] openvswitch: Print error when ovs_execute_actions() fails
From: David Miller @ 2019-08-06 21:38 UTC (permalink / raw)
To: pkusunyifeng; +Cc: netdev, pshelar, gvrose8192
In-Reply-To: <1564973771-22542-1-git-send-email-pkusunyifeng@gmail.com>
From: Yifeng Sun <pkusunyifeng@gmail.com>
Date: Sun, 4 Aug 2019 19:56:11 -0700
> Currently in function ovs_dp_process_packet(), return values of
> ovs_execute_actions() are silently discarded. This patch prints out
> an debug message when error happens so as to provide helpful hints
> for debugging.
> ---
> v1->v2: Fixed according to Pravin's review.
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/5] r8152: replace array with linking list for rx information
From: Jakub Kicinski @ 2019-08-06 21:40 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <20190806125342.4620a94f@cakuba.netronome.com>
On Tue, 6 Aug 2019 12:53:42 -0700, Jakub Kicinski wrote:
> > @@ -744,6 +745,8 @@ struct r8152 {
> > void (*autosuspend_en)(struct r8152 *tp, bool enable);
> > } rtl_ops;
> >
> > + atomic_t rx_count;
>
> I wonder what the advantage of rx_count being atomic is, perhpas it
> could be protected by the same lock as the list head?
Okay, I see you're using it to test the queue length without the lock in
a later patch.
^ permalink raw reply
* Re: [net-next v2 0/8][pull request] 40GbE Intel Wired LAN Driver Updates 2019-08-05
From: David Miller @ 2019-08-06 21:41 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20190805185459.12846-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 5 Aug 2019 11:54:51 -0700
> This series contains updates to i40e driver only.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH] net: dsa: qca8k: Add of_node_put() in qca8k_setup_mdio_bus()
From: David Miller @ 2019-08-06 21:35 UTC (permalink / raw)
To: nishkadg.linux; +Cc: andrew, vivien.didelot, f.fainelli, netdev
In-Reply-To: <20190804153019.2317-1-nishkadg.linux@gmail.com>
From: Nishka Dasgupta <nishkadg.linux@gmail.com>
Date: Sun, 4 Aug 2019 21:00:18 +0530
> Each iteration of for_each_available_child_of_node() puts the previous
> node, but in the case of a return from the middle of the loop, there
> is no put, thus causing a memory leak. Hence add an of_node_put() before
> the return.
> Additionally, the local variable ports in the function
> qca8k_setup_mdio_bus() takes the return value of of_get_child_by_name(),
> which gets a node but does not put it. If the function returns without
> putting ports, it may cause a memory leak. Hence put ports before the
> mid-loop return statement, and also outside the loop after its last usage
> in this function.
> Issues found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Appplied.
^ permalink raw reply
* Re: [PATCH net-next v4 2/2] net: phy: broadcom: add 1000Base-X support for BCM54616S
From: Tao Ren @ 2019-08-06 21:42 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit, David S . Miller,
Arun Parameswaran, Justin Chen, Vladimir Oltean,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <20190806210931.3723590-1-taoren@fb.com>
Hi Andrew / Heiner / Vladimir,
On 8/6/19 2:09 PM, Tao Ren wrote:
> The BCM54616S PHY cannot work properly in RGMII->1000Base-KX mode (for
> example, on Facebook CMM BMC platform), mainly because genphy functions
> are designed for copper links, and 1000Base-X (clause 37) auto negotiation
> needs to be handled differently.
>
> This patch enables 1000Base-X support for BCM54616S by customizing 3
> driver callbacks:
>
> - probe: probe callback detects PHY's operation mode based on
> INTERF_SEL[1:0] pins and 1000X/100FX selection bit in SerDES 100-FX
> Control register.
>
> - config_aneg: bcm54616s_config_aneg_1000bx function is added for auto
> negotiation in 1000Base-X mode.
>
> - read_status: BCM54616S and BCM5482 PHY share the same read_status
> callback which manually set link speed and duplex mode in 1000Base-X
> mode.
>
> Signed-off-by: Tao Ren <taoren@fb.com>
I customized config_aneg function for BCM54616S 1000Base-X mode and link-down issue is also fixed: the patch is tested on Facebook CMM and Minipack BMC and everything looks normal. Please kindly review when you have bandwidth and let me know if you have further suggestions.
BTW, I would be happy to help if we decide to add a set of genphy functions for clause 37, although that may mean I need more help/guidance from you :-)
Cheers,
Tao
^ permalink raw reply
* Re: [PATCH v4 3/4] net: phy: realtek: Add helpers for accessing RTL8211E extension pages
From: Matthias Kaehlcke @ 2019-08-06 21:58 UTC (permalink / raw)
To: Heiner Kallweit
Cc: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, netdev, devicetree, linux-kernel,
Douglas Anderson
In-Reply-To: <71d817b9-7bcc-9f83-331d-1c3958c41f51@gmail.com>
On Sun, Aug 04, 2019 at 10:33:30AM +0200, Heiner Kallweit wrote:
> On 01.08.2019 21:07, Matthias Kaehlcke wrote:
> > The RTL8211E has extension pages, which can be accessed after
> > selecting a page through a custom method. Add a function to
> > modify bits in a register of an extension page and a helper for
> > selecting an ext page. Use rtl8211e_modify_ext_paged() in
> > rtl8211e_config_init() instead of doing things 'manually'.
> >
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> > Changes in v4:
> > - don't add constant RTL8211E_EXT_PAGE, it's only used once,
> > use a literal instead
> > - pass 'oldpage' to phy_restore_page() in rtl8211e_select_ext_page(),
> > not 'page'
> > - return 'oldpage' in rtl8211e_select_ext_page()
> > - use __phy_modify() in rtl8211e_modify_ext_paged() instead of
> > reimplementing __phy_modify_changed()
> > - in rtl8211e_modify_ext_paged() return directly when
> > rtl8211e_select_ext_page() fails
> > ---
> > drivers/net/phy/realtek.c | 48 +++++++++++++++++++++++++++------------
> > 1 file changed, 34 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> > index a669945eb829..e09d3b0da2c7 100644
> > --- a/drivers/net/phy/realtek.c
> > +++ b/drivers/net/phy/realtek.c
> > @@ -53,6 +53,36 @@ static int rtl821x_write_page(struct phy_device *phydev, int page)
> > return __phy_write(phydev, RTL821x_PAGE_SELECT, page);
> > }
> >
> > +static int rtl8211e_select_ext_page(struct phy_device *phydev, int page)
>
> The "extended page" mechanism doesn't exist on RTL8211E only. A prefix
> rtl821x like in other functions may be better therefore.
Sounds good, I'll change it in the next revision
Thanks
Matthias
^ permalink raw reply
* Re: [PATCH net-next v4 2/2] net: phy: broadcom: add 1000Base-X support for BCM54616S
From: Heiner Kallweit @ 2019-08-06 22:00 UTC (permalink / raw)
To: Tao Ren, Andrew Lunn, Florian Fainelli, David S . Miller,
Arun Parameswaran, Justin Chen, Vladimir Oltean, netdev,
linux-kernel, openbmc
In-Reply-To: <20190806210931.3723590-1-taoren@fb.com>
On 06.08.2019 23:09, Tao Ren wrote:
> The BCM54616S PHY cannot work properly in RGMII->1000Base-KX mode (for
> example, on Facebook CMM BMC platform), mainly because genphy functions
> are designed for copper links, and 1000Base-X (clause 37) auto negotiation
> needs to be handled differently.
>
> This patch enables 1000Base-X support for BCM54616S by customizing 3
> driver callbacks:
>
> - probe: probe callback detects PHY's operation mode based on
> INTERF_SEL[1:0] pins and 1000X/100FX selection bit in SerDES 100-FX
> Control register.
>
> - config_aneg: bcm54616s_config_aneg_1000bx function is added for auto
> negotiation in 1000Base-X mode.
>
> - read_status: BCM54616S and BCM5482 PHY share the same read_status
> callback which manually set link speed and duplex mode in 1000Base-X
> mode.
>
> Signed-off-by: Tao Ren <taoren@fb.com>
> ---
> Changes in v4:
> - add bcm54616s_config_aneg_1000bx() to deal with auto negotiation in
> 1000Base-X mode.
> Changes in v3:
> - rename bcm5482_read_status to bcm54xx_read_status so the callback can
> be shared by BCM5482 and BCM54616S.
> Changes in v2:
> - Auto-detect PHY operation mode instead of passing DT node.
> - move PHY mode auto-detect logic from config_init to probe callback.
> - only set speed (not including duplex) in read_status callback.
> - update patch description with more background to avoid confusion.
> - patch #1 in the series ("net: phy: broadcom: set features explicitly
> for BCM54616") is dropped: the fix should go to get_features callback
> which may potentially depend on this patch.
>
> drivers/net/phy/broadcom.c | 62 ++++++++++++++++++++++++++++++++++----
> include/linux/brcmphy.h | 10 ++++--
> 2 files changed, 64 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
> index 937d0059e8ac..bf61ed8451e5 100644
> --- a/drivers/net/phy/broadcom.c
> +++ b/drivers/net/phy/broadcom.c
> @@ -383,9 +383,9 @@ static int bcm5482_config_init(struct phy_device *phydev)
> /*
> * Select 1000BASE-X register set (primary SerDes)
> */
> - reg = bcm_phy_read_shadow(phydev, BCM5482_SHD_MODE);
> - bcm_phy_write_shadow(phydev, BCM5482_SHD_MODE,
> - reg | BCM5482_SHD_MODE_1000BX);
> + reg = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
> + bcm_phy_write_shadow(phydev, BCM54XX_SHD_MODE,
> + reg | BCM54XX_SHD_MODE_1000BX);
>
> /*
> * LED1=ACTIVITYLED, LED3=LINKSPD[2]
> @@ -409,7 +409,7 @@ static int bcm5482_config_init(struct phy_device *phydev)
> return err;
> }
>
> -static int bcm5482_read_status(struct phy_device *phydev)
> +static int bcm54xx_read_status(struct phy_device *phydev)
> {
> int err;
>
> @@ -451,12 +451,60 @@ static int bcm5481_config_aneg(struct phy_device *phydev)
> return ret;
> }
>
> +static int bcm54616s_probe(struct phy_device *phydev)
> +{
> + int val, intf_sel;
> +
> + val = bcm_phy_read_shadow(phydev, BCM54XX_SHD_MODE);
> + if (val < 0)
> + return val;
> +
> + /* The PHY is strapped in RGMII to fiber mode when INTERF_SEL[1:0]
> + * is 01b.
> + */
> + intf_sel = (val & BCM54XX_SHD_INTF_SEL_MASK) >> 1;
> + if (intf_sel == 1) {
> + val = bcm_phy_read_shadow(phydev, BCM54616S_SHD_100FX_CTRL);
> + if (val < 0)
> + return val;
> +
> + /* Bit 0 of the SerDes 100-FX Control register, when set
> + * to 1, sets the MII/RGMII -> 100BASE-FX configuration.
> + * When this bit is set to 0, it sets the GMII/RGMII ->
> + * 1000BASE-X configuration.
> + */
> + if (!(val & BCM54616S_100FX_MODE))
> + phydev->dev_flags |= PHY_BCM_FLAGS_MODE_1000BX;
> + }
> +
> + return 0;
> +}
> +
> +static int bcm54616s_config_aneg_1000bx(struct phy_device *phydev)
> +{
> + int err;
> + int adv = 0;
> +
> + if (linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseX_Full_BIT,
> + phydev->supported))
> + adv |= ADVERTISE_1000XFULL;
> +
> + err = phy_modify_changed(phydev, MII_ADVERTISE, 0, adv);
The "0" parameter is wrong, it must be ADVERTISE_1000XFULL.
First you reset the bit, and then you set it or not.
> + if (err > 0)
> + err = genphy_restart_aneg(phydev);
> +
> + return err;
> +}
> +
> static int bcm54616s_config_aneg(struct phy_device *phydev)
> {
> int ret;
>
> /* Aneg firsly. */
> - ret = genphy_config_aneg(phydev);
> + if (phydev->dev_flags & PHY_BCM_FLAGS_MODE_1000BX)
> + ret = bcm54616s_config_aneg_1000bx(phydev);
> + else
> + ret = genphy_config_aneg(phydev);
>
> /* Then we can set up the delay. */
> bcm54xx_config_clock_delay(phydev);
> @@ -655,6 +703,8 @@ static struct phy_driver broadcom_drivers[] = {
> .config_aneg = bcm54616s_config_aneg,
> .ack_interrupt = bcm_phy_ack_intr,
> .config_intr = bcm_phy_config_intr,
> + .read_status = bcm54xx_read_status,
If you use aneg, you should also read what was negotiated.
But this function reads neither negotiated duplex mode nor
pause settings.
> + .probe = bcm54616s_probe,
> }, {
> .phy_id = PHY_ID_BCM5464,
> .phy_id_mask = 0xfffffff0,
> @@ -689,7 +739,7 @@ static struct phy_driver broadcom_drivers[] = {
> .name = "Broadcom BCM5482",
> /* PHY_GBIT_FEATURES */
> .config_init = bcm5482_config_init,
> - .read_status = bcm5482_read_status,
> + .read_status = bcm54xx_read_status,
> .ack_interrupt = bcm_phy_ack_intr,
> .config_intr = bcm_phy_config_intr,
> }, {
> diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
> index 6db2d9a6e503..b475e7f20d28 100644
> --- a/include/linux/brcmphy.h
> +++ b/include/linux/brcmphy.h
> @@ -200,9 +200,15 @@
> #define BCM5482_SHD_SSD 0x14 /* 10100: Secondary SerDes control */
> #define BCM5482_SHD_SSD_LEDM 0x0008 /* SSD LED Mode enable */
> #define BCM5482_SHD_SSD_EN 0x0001 /* SSD enable */
> -#define BCM5482_SHD_MODE 0x1f /* 11111: Mode Control Register */
> -#define BCM5482_SHD_MODE_1000BX 0x0001 /* Enable 1000BASE-X registers */
>
> +/* 10011: SerDes 100-FX Control Register */
> +#define BCM54616S_SHD_100FX_CTRL 0x13
> +#define BCM54616S_100FX_MODE BIT(0) /* 100-FX SerDes Enable */
> +
> +/* 11111: Mode Control Register */
> +#define BCM54XX_SHD_MODE 0x1f
> +#define BCM54XX_SHD_INTF_SEL_MASK GENMASK(2, 1) /* INTERF_SEL[1:0] */
> +#define BCM54XX_SHD_MODE_1000BX BIT(0) /* Enable 1000-X registers */
>
> /*
> * EXPANSION SHADOW ACCESS REGISTERS. (PHY REG 0x15, 0x16, and 0x17)
>
^ permalink raw reply
* Re: [PATCH net-next 4/5] r8152: support skb_add_rx_frag
From: Jakub Kicinski @ 2019-08-06 22:08 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-293-albertk@realtek.com>
On Tue, 6 Aug 2019 19:18:03 +0800, Hayes Wang wrote:
> Use skb_add_rx_frag() to reduce the memory copy for rx data.
>
> Use a new list of rx_used to store the rx buffer which couldn't be
> reused yet.
>
> Besides, the total number of rx buffer may be increased or decreased
> dynamically. And it is limited by RTL8152_MAX_RX_AGG.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 401e56112365..1615900c8592 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -584,6 +584,9 @@ enum rtl_register_content {
> #define TX_ALIGN 4
> #define RX_ALIGN 8
>
> +#define RTL8152_MAX_RX_AGG (10 * RTL8152_MAX_RX)
> +#define RTL8152_RXFG_HEADSZ 256
> +
> #define INTR_LINK 0x0004
>
> #define RTL8152_REQT_READ 0xc0
> @@ -720,7 +723,7 @@ struct r8152 {
> struct net_device *netdev;
> struct urb *intr_urb;
> struct tx_agg tx_info[RTL8152_MAX_TX];
> - struct list_head rx_info;
> + struct list_head rx_info, rx_used;
I don't see where entries on the rx_used list get freed when driver is
unloaded, could you explain how that's taken care of?
> struct list_head rx_done, tx_free;
> struct sk_buff_head tx_queue, rx_queue;
> spinlock_t rx_lock, tx_lock;
> @@ -1476,7 +1479,7 @@ static void free_rx_agg(struct r8152 *tp, struct rx_agg *agg)
> list_del(&agg->info_list);
>
> usb_free_urb(agg->urb);
> - __free_pages(agg->page, get_order(tp->rx_buf_sz));
> + put_page(agg->page);
> kfree(agg);
>
> atomic_dec(&tp->rx_count);
> @@ -1493,7 +1496,7 @@ static struct rx_agg *alloc_rx_agg(struct r8152 *tp, gfp_t mflags)
> if (rx_agg) {
> unsigned long flags;
>
> - rx_agg->page = alloc_pages(mflags, order);
> + rx_agg->page = alloc_pages(mflags | __GFP_COMP, order);
> if (!rx_agg->page)
> goto free_rx;
>
> @@ -1951,6 +1954,50 @@ static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc *rx_desc)
> return checksum;
> }
>
> +static inline bool rx_count_exceed(struct r8152 *tp)
> +{
> + return atomic_read(&tp->rx_count) > RTL8152_MAX_RX;
> +}
> +
> +static inline int agg_offset(struct rx_agg *agg, void *addr)
> +{
> + return (int)(addr - agg->buffer);
> +}
> +
> +static struct rx_agg *rtl_get_free_rx(struct r8152 *tp, gfp_t mflags)
> +{
> + struct list_head *cursor, *next;
> + struct rx_agg *agg_free = NULL;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&tp->rx_lock, flags);
> +
> + list_for_each_safe(cursor, next, &tp->rx_used) {
> + struct rx_agg *agg;
> +
> + agg = list_entry(cursor, struct rx_agg, list);
> +
> + if (page_count(agg->page) == 1) {
> + if (!agg_free) {
> + list_del_init(cursor);
> + agg_free = agg;
> + continue;
> + } else if (rx_count_exceed(tp)) {
nit: else unnecessary after continue
> + list_del_init(cursor);
> + free_rx_agg(tp, agg);
> + }
> + break;
> + }
> + }
> +
> + spin_unlock_irqrestore(&tp->rx_lock, flags);
> +
> + if (!agg_free && atomic_read(&tp->rx_count) < RTL8152_MAX_RX_AGG)
> + agg_free = alloc_rx_agg(tp, mflags);
> +
> + return agg_free;
> +}
> +
> static int rx_bottom(struct r8152 *tp, int budget)
> {
> unsigned long flags;
^ permalink raw reply
* Re: [PATCH net-next 5/5] r8152: change rx_frag_head_sz and rx_max_agg_num dynamically
From: Jakub Kicinski @ 2019-08-06 22:10 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-294-albertk@realtek.com>
On Tue, 6 Aug 2019 19:18:04 +0800, Hayes Wang wrote:
> Let rx_frag_head_sz and rx_max_agg_num could be modified dynamically
> through the sysfs.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Please don't expose those via sysfs. Ethtool's copybreak and descriptor
count should be applicable here, I think.
^ permalink raw reply
* Re: [PATCH net-next v2] ibmveth: Allow users to update reported speed and duplex
From: Jakub Kicinski @ 2019-08-06 22:15 UTC (permalink / raw)
To: Thomas Falcon; +Cc: mpe, netdev, linuxppc-dev
In-Reply-To: <1565108588-17331-1-git-send-email-tlfalcon@linux.ibm.com>
On Tue, 6 Aug 2019 11:23:08 -0500, Thomas Falcon wrote:
> Reported ethtool link settings for the ibmveth driver are currently
> hardcoded and no longer reflect the actual capabilities of supported
> hardware. There is no interface designed for retrieving this information
> from device firmware nor is there any way to update current settings
> to reflect observed or expected link speeds.
>
> To avoid breaking existing configurations, retain current values as
> default settings but let users update them to match the expected
> capabilities of underlying hardware if needed. This update would
> allow the use of configurations that rely on certain link speed
> settings, such as LACP. This patch is based on the implementation
> in virtio_net.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Looks like this is the third copy of the same code virtio and
netvsc have :( Is there a chance we could factor this out into
helpers in the core?
^ permalink raw reply
* Re: [PATCH net] netdevsim: Restore per-network namespace accounting for fib entries
From: Jakub Kicinski @ 2019-08-06 22:32 UTC (permalink / raw)
To: David Ahern; +Cc: davem, netdev, jiri, David Ahern
In-Reply-To: <20190806191517.8713-1-dsahern@kernel.org>
On Tue, 6 Aug 2019 12:15:17 -0700, David Ahern wrote:
> From: David Ahern <dsahern@gmail.com>
>
> Prior to the commit in the fixes tag, the resource controller in netdevsim
> tracked fib entries and rules per network namespace. Restore that behavior.
>
> Fixes: 5fc494225c1e ("netdevsim: create devlink instance per netdevsim instance")
> Signed-off-by: David Ahern <dsahern@gmail.com>
Thanks.
Let's see what Jiri says, but to me this patch seems to indeed restore
the original per-namespace accounting when the more natural way forward
may perhaps be to make nsim only count the fib entries where
fib_info->net == devlink_net(devlink)
> -void nsim_fib_destroy(struct nsim_fib_data *data)
> +int nsim_fib_init(void)
> {
> - unregister_fib_notifier(&data->fib_nb);
> - kfree(data);
> + int err;
> +
> + err = register_pernet_subsys(&nsim_fib_net_ops);
> + if (err < 0) {
> + pr_err("Failed to register pernet subsystem\n");
> + goto err_out;
> + }
> +
> + err = register_fib_notifier(&nsim_fib_nb, nsim_fib_dump_inconsistent);
> + if (err < 0) {
> + pr_err("Failed to register fib notifier\n");
unregister_pernet_subsys(&nsim_fib_net_ops);
?
> + goto err_out;
> + }
> +
> +err_out:
> + return err;
> }
^ permalink raw reply
* Re: [PATCH -next] iwlwifi: dbg: work around clang bug by marking debug strings static
From: Nick Desaulniers @ 2019-08-06 22:37 UTC (permalink / raw)
To: Johannes Berg
Cc: Michael Ellerman, Kalle Valo, Luca Coelho, Arnd Bergmann,
Nathan Chancellor, Emmanuel Grumbach, Intel Linux Wireless,
David S. Miller, Shahar S Matityahu, Sara Sharon, linux-wireless,
netdev, LKML, clang-built-linux
In-Reply-To: <3a2b6d4f9356d54ab8e83fbf25ba9c5f50181f0d.camel@sipsolutions.net>
On Thu, Aug 1, 2019 at 12:11 AM Johannes Berg <johannes@sipsolutions.net> wrote:
>
>
> > Luca, you said this was already fixed in your internal tree, and the fix
> > would appear soon in next, but I don't see anything in linux-next?
>
> Luca is still on vacation, but I just sent out a version of the patch we
> had applied internally.
>
> Also turns out it wasn't actually _fixed_, just _moved_, so those
> internal patches wouldn't have helped anyway.
Thanks for the report. Do you have a link?
I'll rebase my patch then.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH] net: sched: sch_taprio: fix memleak in error path for sched list parse
From: Ivan Khoronzhuk @ 2019-08-06 22:42 UTC (permalink / raw)
To: David Miller
Cc: vinicius.gomes, jhs, xiyou.wangcong, jiri, netdev, linux-kernel
In-Reply-To: <20190806.114114.1672670570404825284.davem@davemloft.net>
On Tue, Aug 06, 2019 at 11:41:14AM -0700, David Miller wrote:
>From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>Date: Tue, 6 Aug 2019 13:04:25 +0300
>
>> Based on net/master
>
>I wonder about that because:
Applies cleanly on net/master, but line num is not correct.
I've sent v2.
>
>> --- a/net/sched/sch_taprio.c
>> +++ b/net/sched/sch_taprio.c
>> @@ -1451,7 +1451,8 @@ static int taprio_change(struct Qdisc *sch, struct nlattr *opt,
>> spin_unlock_bh(qdisc_lock(sch));
>>
>> free_sched:
>> - kfree(new_admin);
>> + if (new_admin)
>> + call_rcu(&new_admin->rcu, taprio_free_sched_cb);
>>
>> return err;
>
>In my tree the context around line 1451 is:
>
> nla_nest_end(skb, sched_nest);
>
>done:
> rcu_read_unlock();
>
> return nla_nest_end(skb, nest);
>
>
>which is part of function taprio_dump().
>
>Please respin this properly against current 'net' sources.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* [PATCH v2] net: sched: sch_taprio: fix memleak in error path for sched list parse
From: Ivan Khoronzhuk @ 2019-08-06 22:45 UTC (permalink / raw)
To: vinicius.gomes, davem
Cc: jhs, xiyou.wangcong, jiri, netdev, linux-kernel, Ivan Khoronzhuk
In error case, all entries should be freed from the sched list
before deleting it. For simplicity use rcu way.
Fixes: 5a781ccbd19e46 ("tc: Add support for configuring the taprio scheduler")
Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
net/sched/sch_taprio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
index c39db507ba3f..e25d414ae12f 100644
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@ -1195,7 +1195,8 @@ static int taprio_change(struct Qdisc *sch, struct nlattr *opt,
spin_unlock_bh(qdisc_lock(sch));
free_sched:
- kfree(new_admin);
+ if (new_admin)
+ call_rcu(&new_admin->rcu, taprio_free_sched_cb);
return err;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v1 2/2] net: npcm: add NPCM7xx EMC 10/100 Ethernet driver
From: Willem de Bruijn @ 2019-08-06 22:51 UTC (permalink / raw)
To: Avi Fishman
Cc: Patrick Venture, Nancy Yuen, Benjamin Fair, David Miller,
Rob Herring, Mark Rutland, Greg Kroah-Hartman, Tomer Maimon,
Tali Perry, OpenBMC Maillist, Network Development, devicetree,
linux-kernel, Thomas Gleixner
In-Reply-To: <CAKKbWA6hjxupFQNnTUOfeKLXd2wtZ9+g7uUpe34CeErn5kBAaA@mail.gmail.com>
> > Does this device support stacked VLAN?
> I am not familiar with stacked VLAN.
> Our HW for sure there is no support. can the SW stack handle it for me?
> Does it mean that the packets can be larger?
If the device does not support it, I believe it's fine to leave it to S/W.
> > Is this really the device maximum?
>
> The device can support upto 64KB, but of course I will not allocate
> for each RX data such a big buffer.
> Can I know what is the maximum value the network stack may request? I
> saw many driver allocating 1536 for each packet.
The maximum is the minimum of the link layer and device h/w limits,
but you indeed don't want to allocate for worst case if that is highly
unlikely.
Your choice of 1500 is fine for this initial commit, really. More on
MTU below with ndo_change_mtu
> > > + rxd_offset = (readl((ether->reg + REG_CRXDSA)) -
> > > + readl((ether->reg + REG_RXDLSA)))
> > > + / sizeof(struct npcm7xx_txbd);
> > > + DUMP_PRINT("RXD offset %6d\n", rxd_offset);
> > > + DUMP_PRINT("cur_rx %6d\n", ether->cur_rx);
> > > + DUMP_PRINT("rx_err %6d\n", ether->rx_err);
> > > + ether->rx_err = 0;
> > > + DUMP_PRINT("rx_berr %6d\n", ether->rx_berr);
> > > + ether->rx_berr = 0;
> > > + DUMP_PRINT("rx_stuck %6d\n", ether->rx_stuck);
> > > + ether->rx_stuck = 0;
> > > + DUMP_PRINT("rdu %6d\n", ether->rdu);
> > > + ether->rdu = 0;
> > > + DUMP_PRINT("rxov rx %6d\n", ether->rxov);
> > > + ether->rxov = 0;
> > > + /* debug counters */
> > > + DUMP_PRINT("rx_int_count %6d\n", ether->rx_int_count);
> > > + ether->rx_int_count = 0;
> > > + DUMP_PRINT("rx_err_count %6d\n", ether->rx_err_count);
> > > + ether->rx_err_count = 0;
> >
> > Basic counters like tx_packets and rx_errors are probably better
> > exported regardless of debug level as net_device_stats. And then don't
> > need to be copied in debug output.
>
> They are also exported there, see below ether->stats.tx_packets++; and
> ether->stats.rx_errors++;
> those are different counters for debug since we had HW issues that we
> needed to workaround and might need them for future use.
> Currently the driver is stable on millions of parts in the field.
>
> >
> > Less standard counters like tx interrupt count are probably better
> > candidates for ethtool -S.
>
> I don't have support for ethtool.
> is it a must? it is quite some work and this driver is already in the
> field for quite some years.
Your driver includes a struct ethtool_ops. Implementing its callback
.get_ethtool_stats seems straightforward?
David also requested using standard infrastructure over this custom
debug logic. Ethool stats appear the most logical choice to me. But
there may be others.
> > > +static struct sk_buff *get_new_skb(struct net_device *netdev, u32 i)
> > > +{
> > > + __le32 buffer;
> > > + struct npcm7xx_ether *ether = netdev_priv(netdev);
> > > + struct sk_buff *skb = netdev_alloc_skb(netdev,
> > > + roundup(MAX_PACKET_SIZE_W_CRC, 4));
> > > +
> > > + if (unlikely(!skb)) {
> > > + if (net_ratelimit())
> > > + netdev_warn(netdev, "failed to allocate rx skb\n");
> >
> > can use net_warn_ratelimited (here and elsewhere)
>
> should I replace every netdev_warn/err/info with net_warn/err/inf_ratelimited?
> I saw in drivers that are using net_warn_ratelimited, that many time
> uses also netdev_warn/err/info
They probably use the second in non-ratelimited cases?
> > > +static irqreturn_t npcm7xx_tx_interrupt(int irq, void *dev_id)
> > > +{
> > > + struct npcm7xx_ether *ether;
> > > + struct platform_device *pdev;
> > > + struct net_device *netdev;
> > > + __le32 status;
> > > + unsigned long flags;
> > > +
> > > + netdev = dev_id;
> > > + ether = netdev_priv(netdev);
> > > + pdev = ether->pdev;
> > > +
> > > + npcm7xx_get_and_clear_int(netdev, &status, 0xFFFF0000);
> > > +
> > > + ether->tx_int_count++;
> > > +
> > > + if (status & MISTA_EXDEF)
> > > + dev_err(&pdev->dev, "emc defer exceed interrupt status=0x%08X\n"
> > > + , status);
> > > + else if (status & MISTA_TXBERR) {
> > > + dev_err(&pdev->dev, "emc bus error interrupt status=0x%08X\n",
> > > + status);
> > > +#ifdef CONFIG_NPCM7XX_EMC_ETH_DEBUG
> > > + npcm7xx_info_print(netdev);
> > > +#endif
> > > + spin_lock_irqsave(ðer->lock, flags);
> >
> > irqsave in hard interrupt context?
>
> I need to protect my REG_MIEN register that is changed in other places.
> I think that spin_lock_irqsave() is relevant when working in SMP,
> since other CPU may still be running.
> Isn't it?
This is an interesting case. The hardware interrupt handler will not
interrupt itself. But it is architecture dependent whether all
interrupts are disabled when a particular interrupt handler is running
(as per the unreliable guide to locking).
So even in absence of SMP, this would indeed need spin_lock_irqsave if
there are multiple hardware interrupt handlers potentially accessing
the same data. That sounds unlikely in general, but does happen here
for REG_MIEN, in npcm7xx_tx_interrupt and npcm7xx_rx_interrupt. So I
was mistaken, this is not only the most conservative locking method,
it is indeed required.
>
> >
> > > + writel(0, (ether->reg + REG_MIEN)); /* disable any interrupt */
> > > + spin_unlock_irqrestore(ðer->lock, flags);
> > > + ether->need_reset = 1;
> > > + } else if (status & ~(MISTA_TXINTR | MISTA_TXCP | MISTA_TDU))
> > > + dev_err(&pdev->dev, "emc other error interrupt status=0x%08X\n",
> > > + status);
> > > +
> > > + /* if we got MISTA_TXCP | MISTA_TDU remove those interrupt and call napi */
> >
> > The goal of napi is to keep interrupts disabled until napi completes.
>
> We have a HW issue that because of it I still enabled TX complete interrupt,
> I will see if I can disable all interrupts and only leave the error interrupts
Please do. I'm not sure what happens when trying to schedule napi
while it is already scheduled or running. Even in the best case
(nothing), these spurious interrupts are inefficient.
> >
> > > + if (status & (MISTA_TXCP | MISTA_TDU) &
> > > + readl((ether->reg + REG_MIEN))) {
> > > + __le32 reg_mien;
> > > +
> > > + spin_lock_irqsave(ðer->lock, flags);
> > > + reg_mien = readl((ether->reg + REG_MIEN));
> > > + if (reg_mien & ENTDU)
> > > + /* Disable TDU interrupt */
> > > + writel(reg_mien & (~ENTDU), (ether->reg + REG_MIEN));
> > > +
> > > + spin_unlock_irqrestore(ðer->lock, flags);
> > > +
> > > + if (status & MISTA_TXCP)
> > > + ether->tx_cp_i++;
> > > + if (status & MISTA_TDU)
> > > + ether->tx_tdu_i++;
> > > + } else {
> > > + dev_dbg(&pdev->dev, "status=0x%08X\n", status);
> > > + }
> > > +
> > > + napi_schedule(ðer->napi);
> > > +
> > > + return IRQ_HANDLED;
> > > +}
> > > +
> > > +static irqreturn_t npcm7xx_rx_interrupt(int irq, void *dev_id)
> > > +{
> > > + struct net_device *netdev = (struct net_device *)dev_id;
> > > + struct npcm7xx_ether *ether = netdev_priv(netdev);
> > > + struct platform_device *pdev = ether->pdev;
> > > + __le32 status;
> > > + unsigned long flags;
> > > + unsigned int any_err = 0;
> > > + __le32 rxfsm;
> > > +
> > > + npcm7xx_get_and_clear_int(netdev, &status, 0xFFFF);
> >
> > Same here
>
> in non error case I do leave only the error interrupts and schedule napi.
Oh, so the Rx interrupt remains suppressed. Then that's fine.
> > > +static const struct net_device_ops npcm7xx_ether_netdev_ops = {
> > > + .ndo_open = npcm7xx_ether_open,
> > > + .ndo_stop = npcm7xx_ether_close,
> > > + .ndo_start_xmit = npcm7xx_ether_start_xmit,
> > > + .ndo_get_stats = npcm7xx_ether_stats,
> > > + .ndo_set_rx_mode = npcm7xx_ether_set_rx_mode,
> > > + .ndo_set_mac_address = npcm7xx_set_mac_address,
> > > + .ndo_do_ioctl = npcm7xx_ether_ioctl,
> > > + .ndo_validate_addr = eth_validate_addr,
> > > + .ndo_change_mtu = eth_change_mtu,
> >
> > This is marked as deprecated. Also in light of the hardcoded
> > MAX_PACKET_SIZE, probably want to set dev->max_mtu.
>
> can I just not set .ndo_change_mtu? or I must add my own implementation?
> setting of dev->max_mtu, can be done in probe, yes?
It's fine to just not have it. The patchset that introduced max_mtu
(61e84623ace3, a52ad514fdf3) removed many.
One reason to have a callback function is to bring the device down/up
with different sized rx buffers.
But handling that might be too much extra complexity for the initial
patch. It's fine to keep the fixed rx alloc size as is.
> BTW, I see that currently the mtu is 1500 but I do get transactions
> with len of 1514 (I didn't compile with VLAN)
That is to be expected, as MTU excludes link layer header (and FCS,
and perhaps also vlan?)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox