* Re: [PATCH 4/5] net: phy: add XAUI and 10GBASE-KR PHY connection types
From: Russell King - ARM Linux @ 2017-06-01 17:32 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Rob Herring, Mark Rutland,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <fb1a81e0-b5b9-80e4-7852-cc65a574b9e9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Jun 01, 2017 at 09:56:48AM -0700, Florian Fainelli wrote:
> On 06/01/2017 03:26 AM, Russell King wrote:
> > XAUI allows XGMII to reach an extended distance by using a XGXS layer at
> > each end of the MAC to PHY link, operating over four Serdes lanes.
> >
> > 10GBASE-KR is a single lane Serdes backplane ethernet connection method
> > with autonegotiation on the link. Some PHYs use this to connect to the
> > ethernet interface at 10G speeds, switching to other connection types
> > when utilising slower speeds.
> >
> > 10GBASE-KR is also used for XFI and SFI to connect to XFP and SFP fiber
> > modules.
> >
> > Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
>
> This looks good, but you also need to update
> Documentation/ABI/testing/sysfs-class-net-phydev since we report
> phy_interface from sysfs.
Hmm, seems to be a new file recently merged into net-next. Ok, I'll
provide an update for that.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Cherry pick commit *net: better skb->sender_cpu and skb->napi_id cohabitation* to 4.4 series?
From: Paul Menzel @ 2017-06-01 17:32 UTC (permalink / raw)
To: David Miller
Cc: Eric Dumazet, netdev, ast, it+linux-netdev, Greg Kroah-Hartman
In-Reply-To: <20170601.121935.1801387892378122014.davem@davemloft.net>
Dear David,
On 06/01/17 18:19, David Miller wrote:
> Neither of us have anything to do with the 4.4 -stable series. We only
> manage stable backport submissions for the most recent two releases.
Thank you for the prompt response. Should the netdev FAQ be updated then
to contain that information?
> Q: How can I tell what patches are queued up for backporting to the
> various stable releases?
>
> A: Normally Greg Kroah-Hartman collects stable commits himself, but
> for networking, Dave collects up patches he deems critical for the
> networking subsystem, and then hands them off to Greg.
>
> There is a patchworks queue that you can see here:
> http://patchwork.ozlabs.org/bundle/davem/stable/?state=*
>
> It contains the patches which Dave has selected, but not yet handed
> off to Greg. If Greg already has the patch, then it will be here:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
>
> A quick way to find whether the patch is in this stable-queue is
> to simply clone the repo, and then git grep the mainline commit ID, e.g.
>
> stable-queue$ git grep -l 284041ef21fdf2e
> releases/3.0.84/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
> releases/3.4.51/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
> releases/3.9.8/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
> stable/stable-queue$
Kind regards,
Paul
[1] Documentation/networking/netdev-FAQ.txt
^ permalink raw reply
* Re: [PATCH 5/5] net: phy: add Marvell Alaska X 88X3310 10Gigabit PHY support
From: Florian Fainelli @ 2017-06-01 17:28 UTC (permalink / raw)
To: Russell King, Andrew Lunn; +Cc: netdev
In-Reply-To: <E1dGNJc-000442-8H@rmk-PC.armlinux.org.uk>
On 06/01/2017 03:26 AM, Russell King wrote:
> Add phylib support for the Marvell Alaska X 10 Gigabit PHY (MV88X3310).
> This phy is able to operate at 10G, 1G, 100M and 10M speeds, and only
> supports Clause 45 accesses.
>
> The PHY appears (based on the vendor IDs) to be two different vendors
> IP, with each devad containing several instances.
>
> This PHY driver has only been tested with the RJ45 copper port, fiber
> port and a Marvell Armada 8040-based ethernet interface.
>
> It should be noted that to use the full range of speeds, MAC drivers
> need to also reconfigure the link mode as per phydev->interface, since
> the PHY automatically changes its interface mode depending on the
> negotiated speed.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> MARVELL MVNETA ETHERNET DRIVER
> M: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> L: netdev@vger.kernel.org
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index 19eddf758c88..905990fece28 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -55,7 +55,7 @@ obj-$(CONFIG_ICPLUS_PHY) += icplus.o
> obj-$(CONFIG_INTEL_XWAY_PHY) += intel-xway.o
> obj-$(CONFIG_LSI_ET1011C_PHY) += et1011c.o
> obj-$(CONFIG_LXT_PHY) += lxt.o
> -obj-$(CONFIG_MARVELL_PHY) += marvell.o
> +obj-$(CONFIG_MARVELL_PHY) += marvell.o marvell10g.o
Could we introduce a CONFIG_MARVELL_10G_PHY symbol?
> +enum {
> + MV_PCS_BASE_T = 0x0000,
> + MV_PCS_BASE_R = 0x1000,
> + MV_PCS_1000BASEX = 0x2000,
> +
> + /* These registers appear at 0x800X and 0xa00X - the 0xa00X control
> + * registers appear to set themselves to the 0x800X when AN is
> + * restarted, but status registers appear readable from either.
> + */
> + MV_AN_CTRL1000 = 0x8000, /* 1000base-T control register */
> + MV_AN_STAT1000 = 0x8001, /* 1000base-T status register */
> +
> + /* This register appears to reflect the copper status */
> + MV_AN_RESULT = 0xa016,
> + MV_AN_RESULT_SPD_10 = BIT(12),
> + MV_AN_RESULT_SPD_100 = BIT(13),
> + MV_AN_RESULT_SPD_1000 = BIT(14),
> + MV_AN_RESULT_SPD_10000 = BIT(15),
> +};
Personal preference is not to use enums but jut plain #define, but
whatever works, really.
> +
> +static int mv3310_soft_reset(struct phy_device *phydev)
> +{
> + return 0;
> +}
You could use genphy_no_soft_reset(), although genphy sort of implies
C22 now, or we could export genphy10g_soft_reset() which also does nothing.
> + /* Ethtool does not support the WAN mode bits */
> + if (val & (MDIO_PMA_STAT2_10GBSR | MDIO_PMA_STAT2_10GBLR |
> + MDIO_PMA_STAT2_10GBER | MDIO_PMA_STAT2_10GBLX4 |
> + MDIO_PMA_STAT2_10GBSW | MDIO_PMA_STAT2_10GBLW |
> + MDIO_PMA_STAT2_10GBEW))
> + __set_bit(ETHTOOL_LINK_MODE_FIBRE_BIT, supported);
> + if (val & MDIO_PMA_STAT2_10GBSR)
> + __set_bit(ETHTOOL_LINK_MODE_10000baseSR_Full_BIT, supported);
> + if (val & MDIO_PMA_STAT2_10GBLR)
> + __set_bit(ETHTOOL_LINK_MODE_10000baseLR_Full_BIT, supported);
> + if (val & MDIO_PMA_STAT2_10GBER)
> + __set_bit(ETHTOOL_LINK_MODE_10000baseER_Full_BIT, supported);
> +
> + if (val & MDIO_PMA_STAT2_EXTABLE) {
> + val = phy_read_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_PMA_EXTABLE);
> + if (val < 0)
> + return val;
> +
> + if (val & (MDIO_PMA_EXTABLE_10GBT | MDIO_PMA_EXTABLE_1000BT |
> + MDIO_PMA_EXTABLE_100BTX | MDIO_PMA_EXTABLE_10BT))
> + __set_bit(ETHTOOL_LINK_MODE_TP_BIT, supported);
> + if (val & MDIO_PMA_EXTABLE_10GBLRM)
> + __set_bit(ETHTOOL_LINK_MODE_FIBRE_BIT, supported);
> + if (val & (MDIO_PMA_EXTABLE_10GBKX4 | MDIO_PMA_EXTABLE_10GBKR |
> + MDIO_PMA_EXTABLE_1000BKX))
> + __set_bit(ETHTOOL_LINK_MODE_Backplane_BIT, supported);
> + if (val & MDIO_PMA_EXTABLE_10GBLRM)
> + __set_bit(ETHTOOL_LINK_MODE_10000baseLRM_Full_BIT,
> + supported);
> + if (val & MDIO_PMA_EXTABLE_10GBT)
> + __set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
> + supported);
> + if (val & MDIO_PMA_EXTABLE_10GBKX4)
> + __set_bit(ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT,
> + supported);
> + if (val & MDIO_PMA_EXTABLE_10GBKR)
> + __set_bit(ETHTOOL_LINK_MODE_10000baseKR_Full_BIT,
> + supported);
> + if (val & MDIO_PMA_EXTABLE_1000BT)
> + __set_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
> + supported);
> + if (val & MDIO_PMA_EXTABLE_1000BKX)
> + __set_bit(ETHTOOL_LINK_MODE_1000baseKX_Full_BIT,
> + supported);
> + if (val & MDIO_PMA_EXTABLE_100BTX)
> + __set_bit(ETHTOOL_LINK_MODE_100baseT_Full_BIT,
> + supported);
> + if (val & MDIO_PMA_EXTABLE_10BT)
> + __set_bit(ETHTOOL_LINK_MODE_10baseT_Full_BIT,
> + supported);
> + }
> +
> + if (!ethtool_convert_link_mode_to_legacy_u32(&mask, supported))
> + dev_warn(&phydev->mdio.dev,
> + "PHY supports (%*pb) more modes than phylib supports, some modes not supported.\n",
> + __ETHTOOL_LINK_MODE_MASK_NBITS, supported);
> +
> + phydev->supported &= mask;
> + phydev->advertising &= phydev->supported;
Is not this a candidate for being moved into drivers/net/phy/phy-10g.c?
Past the phy interface mode check, the rest does not appear to be
particularly Marvell specific here.
Other than that, and making it a separate Kconfig option, this looks great!
--
Florian
^ permalink raw reply
* Re: [PATCH v2 net-next 0/8] Introduce bpf ID
From: Alexei Starovoitov @ 2017-06-01 17:24 UTC (permalink / raw)
To: David Ahern, Jakub Kicinski, Martin KaFai Lau,
Hannes Frederic Sowa
Cc: netdev, Daniel Borkmann, kernel-team
In-Reply-To: <3f269312-efd4-86fc-e8e2-814af5898648@gmail.com>
On 6/1/17 6:55 AM, David Ahern wrote:
> On 5/31/17 8:22 PM, Jakub Kicinski wrote:
>> On Wed, 31 May 2017 11:58:54 -0700, Martin KaFai Lau wrote:
>>> This patch series:
>>> 1) Introduce ID for both bpf_prog and bpf_map.
>>> 2) Add bpf commands to iterate the prog IDs and map
>>> IDs of the system.
>>> 3) Add bpf commands to get a prog/map fd from an ID
>>> 4) Add bpf command to get prog/map info from a fd.
>>> The prog/map info is a jump start in this patchset
>>> and it is not meant to be a complete list. They can
>>> be extended in the future patches.
>>
>> Hi! IIUC there were plans at some point to store the BPF byte code in
>> the kernel, the way it was loaded from the user space and before it
>> went through the verifier. Are you still planning on implementing that?
>> It would be handy for offloads to have the original byte code, things
>> like call inlining make translations of maps calls a bit challenging,
>> since we try to run through the verifier again..
>>
>
> Save the instructions:
> https://github.com/dsahern/linux/commit/5315578db7b0886a3e8e3bef6a56e828ae2bd2c4
>
> Let userspace read it back:
> https://github.com/dsahern/linux/commit/619982064b9b582fc5d4a504feffca1730610c4e
>
> One more in between in the branch:
> https://github.com/dsahern/linux/tree/bpf/retrieve-bpf-wip
>
> Now that the id code is in, it needs to be returned on link dumps, route
> dumps, etc and accessible via fdinfo. The id can be turned into an fd
> and the fd read using the above patches.
what problem are we trying to solve?
If we don't agree on the problem, we won't be able to agree on the solution.
Sounds to me that Jakub wants to translate lookup/update helper calls
for JITing and it's difficult due to inlining optimization.
In such case isn't the easiest solution to disable inlining when
JIT to NFP is on?
Dave's case is to be able to retrieve a cgroup_sock program used
for vrf. Such prog doesn't have any maps and I don't see why
returning real insns is not enough.
As Martin said there is work in progress patches that return IDs
for programs attached to everything: cgroup_sock hook, xdp, etc.
The user can get prog ID, convert to FD and dump all insns.
Why this is not enough for VRF introspection?
^ permalink raw reply
* Re: [PATCH linux-firmware v2] Mellanox: Add firmware for mlxsw_spectrum
From: Kyle McMartin @ 2017-06-01 17:18 UTC (permalink / raw)
To: Yotam Gigi; +Cc: idosch, jiri, eladr, arkadis, netdev, linux-firmware
In-Reply-To: <20170601062810.17813-1-yotamg@mellanox.com>
On Thu, Jun 01, 2017 at 09:28:10AM +0300, Yotam Gigi wrote:
> Add first firmware for the Mellanox Spectrum switch, as a followup to the
> recently added commit:
> 6b7421992b8d ("mlxsw: spectrum: Validate firmware revision on init")
>
> The version of the firmware release is 13.1420.122
>
applied, thanks Yotam.
--kyle
> Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
> ---
> mellanox/mlxsw_spectrum-13.1420.122.mfa2 | Bin 0 -> 860424 bytes
> 1 file changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 mellanox/mlxsw_spectrum-13.1420.122.mfa2
>
^ permalink raw reply
* Re: [PATCH 3/5] net: phy: split out 10G genphy support
From: Florian Fainelli @ 2017-06-01 17:17 UTC (permalink / raw)
To: Russell King, Andrew Lunn; +Cc: netdev
In-Reply-To: <E1dGNJR-00043n-ON@rmk-PC.armlinux.org.uk>
On 06/01/2017 03:26 AM, Russell King wrote:
> Move the old 10G genphy support to sit beside the new clause 45 library
> functions, so all the 10G phy code is together.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH 2/5] net: phy: hook up clause 45 autonegotiation restart
From: Florian Fainelli @ 2017-06-01 17:16 UTC (permalink / raw)
To: Russell King - ARM Linux, Andrew Lunn; +Cc: netdev
In-Reply-To: <20170601162417.GA14541@n2100.armlinux.org.uk>
On 06/01/2017 09:24 AM, Russell King - ARM Linux wrote:
> On Thu, Jun 01, 2017 at 04:47:35PM +0100, Russell King - ARM Linux wrote:
>> On Thu, Jun 01, 2017 at 03:19:55PM +0200, Andrew Lunn wrote:
>>> On Thu, Jun 01, 2017 at 02:09:00PM +0100, Russell King - ARM Linux wrote:
>>>> On Thu, Jun 01, 2017 at 03:05:27PM +0200, Andrew Lunn wrote:
>>>>> So you are saying a 10G PHY driver always needs to have a aneg_done
>>>>> callback, even if it just needs to call phygen_c45_aneg_done?
>>>>>
>>>>> This seems a bit error prone. I can see somebody writing a 10G driver,
>>>>> leaving out aneg_done() and having the c22 version called. Is the read
>>>>> of MII_BMSR likely to return 0xffff, since the register does not
>>>>> exist? If so, genphy_aneg_done() is likely to always return
>>>>> BMSR_ANEGCOMPLETE.
>>>>
>>>> Don't forget that the read will fail, so phy_read() will return a
>>>> negative number.
>>>
>>> By fail, you mean return something like -EIO or -ETIMEOUT? Is this
>>> guaranteed in the code somewhere? This particular Marvell PHY only
>>> does c45. But i could imagine some other PHYs answering a c22 request
>>> with 0xffff.
>>
>> Yes, C45 allows the PHYs to answer C22 as well, but then they have to
>> implement the C22 register set. Such a PHY would be out of spec,
>> especially as what you're suggesting is that it answers C22 cycles
>> and fails to implement MII_BMSR. I also think that there's a comment
>> in the 802.3 specs that says that unimplemented registers are to
>> return zero, not 0xffff.
>
> Checking 802.3-2015, in "22.2.4 Management functions", the first
> sentence requires all PHYs that respond to Clause 22 cycles to
> implement BMCR and BMSR. However, my statement about unimplemented
> registers returning zero seems to be a C45 thing, not a C22 thing,
> according to the C22 PICS and "45.2 MDIO Interface Registers"
>
> However, digging a bit further, "22.2.4.2.10 Auto-Negotiation complete"
> states that bit 5 shall be zero if aneg has not completed or if aneg is
> unimplemented.
>
So how about we are more defensive than that and if we are presented
with a C45 PHY driver that does not have an aneg_done() function pointer
set we return an error/warning during driver registration?
--
Florian
^ permalink raw reply
* Re: [PATCH 1/5] net: phy: add 802.3 clause 45 support to phylib
From: Florian Fainelli @ 2017-06-01 17:15 UTC (permalink / raw)
To: Russell King, Andrew Lunn; +Cc: netdev
In-Reply-To: <E1dGNJH-00043Y-Gl@rmk-PC.armlinux.org.uk>
On 06/01/2017 03:26 AM, Russell King wrote:
> Add generic helpers for 802.3 clause 45 PHYs for >= 10Gbps support.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> + ctrl1 &= ~MDIO_CTRL1_SPEEDSEL;
> + /* PMA/PMD type selection is 1.7.5:0 not 1.7.3:0. See 45.2.1.6.1. */
> + ctrl2 &= ~(MDIO_PMA_CTRL2_TYPE | 0x30);
You could add a define for this 0x30 to indicate that you are masking
off the reserved bits (there are more entries that are reserved
actually, but that would do for now).
With that:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> +
> + switch (phydev->speed) {
> + case SPEED_10:
> + ctrl2 |= MDIO_PMA_CTRL2_10BT;
> + break;
> + case SPEED_100:
> + ctrl1 |= MDIO_PMA_CTRL1_SPEED100;
> + ctrl2 |= MDIO_PMA_CTRL2_100BTX;
> + break;
> + case SPEED_1000:
> + ctrl1 |= MDIO_PMA_CTRL1_SPEED1000;
> + /* Assume 1000base-T */
> + ctrl2 |= MDIO_PMA_CTRL2_1000BT;
> + break;
> + case SPEED_10000:
> + ctrl1 |= MDIO_CTRL1_SPEED10G;
> + /* Assume 10Gbase-T */
> + ctrl2 |= MDIO_PMA_CTRL2_10GBT;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + ret = phy_write_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_CTRL1, ctrl1);
> + if (ret < 0)
> + return ret;
> +
> + return phy_write_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_CTRL2, ctrl2);
> +}
> +EXPORT_SYMBOL_GPL(genphy_c45_pma_setup_forced);
> +
> +/**
> + * genphy_c45_an_disable_aneg - disable auto-negotiation
> + * @phydev: target phy_device struct
> + *
> + * Disable auto-negotiation in the Clause 45 PHY. The link parameters
> + * parameters are controlled through the PMA/PMD MMD registers.
> + *
> + * Returns zero on success, negative errno code on failure.
> + */
> +int genphy_c45_an_disable_aneg(struct phy_device *phydev)
> +{
> + int val;
> +
> + val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1);
> + if (val < 0)
> + return val;
> +
> + val &= ~(MDIO_AN_CTRL1_ENABLE | MDIO_AN_CTRL1_RESTART);
> +
> + return phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1, val);
> +}
> +EXPORT_SYMBOL_GPL(genphy_c45_an_disable_aneg);
> +
> +/**
> + * genphy_c45_restart_aneg - Enable and restart auto-negotiation
> + * @phydev: target phy_device struct
> + *
> + * This assumes that the auto-negotiation MMD is present.
> + *
> + * Enable and restart auto-negotiation.
> + */
> +int genphy_c45_restart_aneg(struct phy_device *phydev)
> +{
> + int val;
> +
> + val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1);
> + if (val < 0)
> + return val;
> +
> + val |= MDIO_AN_CTRL1_ENABLE | MDIO_AN_CTRL1_RESTART;
> +
> + return phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1, val);
> +}
> +EXPORT_SYMBOL_GPL(genphy_c45_restart_aneg);
> +
> +/**
> + * genphy_c45_aneg_done - return auto-negotiation complete status
> + * @phydev: target phy_device struct
> + *
> + * This assumes that the auto-negotiation MMD is present.
> + *
> + * Reads the status register from the auto-negotiation MMD, returning:
> + * - positive if auto-negotiation is complete
> + * - negative errno code on error
> + * - zero otherwise
> + */
> +int genphy_c45_aneg_done(struct phy_device *phydev)
> +{
> + int val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_STAT1);
> +
> + return val < 0 ? val : val & MDIO_AN_STAT1_COMPLETE ? 1 : 0;
> +}
> +EXPORT_SYMBOL_GPL(genphy_c45_aneg_done);
> +
> +/**
> + * genphy_c45_read_link - read the overall link status from the MMDs
> + * @phydev: target phy_device struct
> + * @mmd_mask: MMDs to read status from
> + *
> + * Read the link status from the specified MMDs, and if they all indicate
> + * that the link is up, return positive. If an error is encountered,
> + * a negative errno will be returned, otherwise zero.
> + */
> +int genphy_c45_read_link(struct phy_device *phydev, u32 mmd_mask)
> +{
> + int val, devad;
> + bool link = true;
> +
> + while (mmd_mask) {
> + devad = __ffs(mmd_mask);
> + mmd_mask &= ~BIT(devad);
> +
> + /* The link state is latched low so that momentary link
> + * drops can be detected. Do not double-read the status
> + * register if the link is down.
> + */
> + val = phy_read_mmd(phydev, devad, MDIO_STAT1);
> + if (val < 0)
> + return val;
> +
> + if (!(val & MDIO_STAT1_LSTATUS))
> + link = false;
> + }
> +
> + return link;
> +}
> +EXPORT_SYMBOL_GPL(genphy_c45_read_link);
> +
> +/**
> + * genphy_c45_read_lpa - read the link partner advertisment and pause
> + * @phydev: target phy_device struct
> + *
> + * Read the Clause 45 defined base (7.19) and 10G (7.33) status registers,
> + * filling in the link partner advertisment, pause and asym_pause members
> + * in @phydev. This assumes that the auto-negotiation MMD is present, and
> + * the backplane bit (7.48.0) is clear. Clause 45 PHY drivers are expected
> + * to fill in the remainder of the link partner advert from vendor registers.
> + */
> +int genphy_c45_read_lpa(struct phy_device *phydev)
> +{
> + int val;
> +
> + /* Read the link partner's base page advertisment */
> + val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_AN_LPA);
> + if (val < 0)
> + return val;
> +
> + phydev->lp_advertising = mii_lpa_to_ethtool_lpa_t(val);
> + phydev->pause = val & LPA_PAUSE_CAP ? 1 : 0;
> + phydev->asym_pause = val & LPA_PAUSE_ASYM ? 1 : 0;
> +
> + /* Read the link partner's 10G advertisment */
> + val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_AN_10GBT_STAT);
> + if (val < 0)
> + return val;
> +
> + if (val & MDIO_AN_10GBT_STAT_LP10G)
> + phydev->lp_advertising |= ADVERTISED_10000baseT_Full;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(genphy_c45_read_lpa);
> +
> +/**
> + * genphy_c45_read_pma - read link speed etc from PMA
> + * @phydev: target phy_device struct
> + */
> +int genphy_c45_read_pma(struct phy_device *phydev)
> +{
> + int val;
> +
> + val = phy_read_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_CTRL1);
> + if (val < 0)
> + return val;
> +
> + switch (val & MDIO_CTRL1_SPEEDSEL) {
> + case 0:
> + phydev->speed = SPEED_10;
> + break;
> + case MDIO_PMA_CTRL1_SPEED100:
> + phydev->speed = SPEED_100;
> + break;
> + case MDIO_PMA_CTRL1_SPEED1000:
> + phydev->speed = SPEED_1000;
> + break;
> + case MDIO_CTRL1_SPEED10G:
> + phydev->speed = SPEED_10000;
> + break;
> + default:
> + phydev->speed = SPEED_UNKNOWN;
> + break;
> + }
> +
> + phydev->duplex = DUPLEX_FULL;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(genphy_c45_read_pma);
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 1219eeab69d1..040575dba98c 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1483,27 +1483,19 @@ EXPORT_SYMBOL(genphy_read_status);
>
> static int gen10g_read_status(struct phy_device *phydev)
> {
> - int devad, reg;
> u32 mmd_mask = phydev->c45_ids.devices_in_package;
> -
> - phydev->link = 1;
> + int ret;
>
> /* For now just lie and say it's 10G all the time */
> phydev->speed = SPEED_10000;
> phydev->duplex = DUPLEX_FULL;
>
> - for (devad = 0; mmd_mask; devad++, mmd_mask = mmd_mask >> 1) {
> - if (!(mmd_mask & 1))
> - continue;
> + /* Avoid reading the vendor MMDs */
> + mmd_mask &= ~(BIT(MDIO_MMD_VEND1) | BIT(MDIO_MMD_VEND2));
>
> - /* Read twice because link state is latched and a
> - * read moves the current state into the register
> - */
> - phy_read_mmd(phydev, devad, MDIO_STAT1);
> - reg = phy_read_mmd(phydev, devad, MDIO_STAT1);
> - if (reg < 0 || !(reg & MDIO_STAT1_LSTATUS))
> - phydev->link = 0;
> - }
> + ret = genphy_c45_read_link(phydev, mmd_mask);
> +
> + phydev->link = ret > 0 ? 1 : 0;
>
> return 0;
> }
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index e76e4adbc7c7..735ff1f98db3 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -816,6 +816,8 @@ static inline const char *phydev_name(const struct phy_device *phydev)
> void phy_attached_print(struct phy_device *phydev, const char *fmt, ...)
> __printf(2, 3);
> void phy_attached_info(struct phy_device *phydev);
> +
> +/* Clause 22 PHY */
> int genphy_config_init(struct phy_device *phydev);
> int genphy_setup_forced(struct phy_device *phydev);
> int genphy_restart_aneg(struct phy_device *phydev);
> @@ -830,6 +832,16 @@ static inline int genphy_no_soft_reset(struct phy_device *phydev)
> {
> return 0;
> }
> +
> +/* Clause 45 PHY */
> +int genphy_c45_restart_aneg(struct phy_device *phydev);
> +int genphy_c45_aneg_done(struct phy_device *phydev);
> +int genphy_c45_read_link(struct phy_device *phydev, u32 mmd_mask);
> +int genphy_c45_read_lpa(struct phy_device *phydev);
> +int genphy_c45_read_pma(struct phy_device *phydev);
> +int genphy_c45_pma_setup_forced(struct phy_device *phydev);
> +int genphy_c45_an_disable_aneg(struct phy_device *phydev);
> +
> void phy_driver_unregister(struct phy_driver *drv);
> void phy_drivers_unregister(struct phy_driver *drv, int n);
> int phy_driver_register(struct phy_driver *new_driver, struct module *owner);
>
--
Florian
^ permalink raw reply
* Re: [PATCH net] netlink: don't send unknown nsid
From: Flavio Leitner @ 2017-06-01 17:02 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: davem, netdev
In-Reply-To: <1496304007-1962-1-git-send-email-nicolas.dichtel@6wind.com>
On Thu, Jun 01, 2017 at 10:00:07AM +0200, Nicolas Dichtel wrote:
> The NETLINK_F_LISTEN_ALL_NSID otion enables to listen all netns that have a
> nsid assigned into the netns where the netlink socket is opened.
> The nsid is sent as metadata to userland, but the existence of this nsid is
> checked only for netns that are different from the socket netns. Thus, if
> no nsid is assigned to the socket netns, NETNSA_NSID_NOT_ASSIGNED is
> reported to the userland. This value is confusing and useless.
> After this patch, only valid nsid are sent to userland.
>
> Reported-by: Flavio Leitner <fbl@sysclose.org>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> net/netlink/af_netlink.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index ee841f00a6ec..7586d446d7dc 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -62,6 +62,7 @@
> #include <asm/cacheflush.h>
> #include <linux/hash.h>
> #include <linux/genetlink.h>
> +#include <linux/net_namespace.h>
>
> #include <net/net_namespace.h>
> #include <net/sock.h>
> @@ -1415,7 +1416,8 @@ static void do_one_broadcast(struct sock *sk,
> goto out;
> }
> NETLINK_CB(p->skb2).nsid = peernet2id(sock_net(sk), p->net);
> - NETLINK_CB(p->skb2).nsid_is_set = true;
> + if (NETLINK_CB(p->skb2).nsid != NETNSA_NSID_NOT_ASSIGNED)
> + NETLINK_CB(p->skb2).nsid_is_set = true;
> val = netlink_broadcast_deliver(sk, p->skb2);
> if (val < 0) {
> netlink_overrun(sk);
If the assumption is that nsid allocation can never fail or that if it
does, we can't report to userspace, then the patch is good, but it
doesn't sound like a good long term solution.
Let's consider that the allocation of an id fails for whatever reason.
I think that should be reported to userspace to allow it to retry, or
do something else to handle this situation properly. Not sending
anything means that it's in the same netns as the old kernels did,
which is incorrect.
On the other hand, with the original patch, if the socket and the
device are in the same netns, we don't need to report any ID. Previous
kernels did that, so we are not breaking anything. When the netns
differs, then we either should report the real ID or an error.
--
Flavio
^ permalink raw reply
* Re: [PATCH 4/5] net: phy: add XAUI and 10GBASE-KR PHY connection types
From: Florian Fainelli @ 2017-06-01 16:56 UTC (permalink / raw)
To: Russell King, Andrew Lunn; +Cc: Rob Herring, Mark Rutland, netdev, devicetree
In-Reply-To: <E1dGNJX-00043v-3M@rmk-PC.armlinux.org.uk>
On 06/01/2017 03:26 AM, Russell King wrote:
> XAUI allows XGMII to reach an extended distance by using a XGXS layer at
> each end of the MAC to PHY link, operating over four Serdes lanes.
>
> 10GBASE-KR is a single lane Serdes backplane ethernet connection method
> with autonegotiation on the link. Some PHYs use this to connect to the
> ethernet interface at 10G speeds, switching to other connection types
> when utilising slower speeds.
>
> 10GBASE-KR is also used for XFI and SFI to connect to XFP and SFP fiber
> modules.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
This looks good, but you also need to update
Documentation/ABI/testing/sysfs-class-net-phydev since we report
phy_interface from sysfs.
With that fixed:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH 0/5] Add phylib support for MV88X3310 10G phy
From: Russell King - ARM Linux @ 2017-06-01 16:54 UTC (permalink / raw)
To: David Miller
Cc: andrew-g2DYL2Zd6BY, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
netdev-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20170601.120736.670167741447008364.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thu, Jun 01, 2017 at 12:07:36PM -0400, David Miller wrote:
> From: Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
> Date: Thu, 1 Jun 2017 11:23:27 +0100
>
> > This patch series adds support for the Marvell 88x3310 PHY found on
> > the SolidRun Macchiatobin board.
>
> Andrew has asked for some comment documentation additions to patch #5
> so I'm expecting at least one respin of this series ;-)
Thanks.
It would help if Documentation/networking/phy.txt already contained
documentation about the adjust_link function beyond describing that it
exists. I'll try to write something to cover the existing usage and
this change over the next day or so.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: commit f5f99309 (sock: do not set sk_err in sock_dequeue_err_skb) has broken ping
From: Soheil Hassas Yeganeh @ 2017-06-01 16:42 UTC (permalink / raw)
To: Cyril Hrubis
Cc: David S. Miller, Shmulik Ladkani, Marcelo Ricardo Leitner,
Pravin B Shelar, Eric Dumazet, WANG Cong, Yaogong Wang,
Steffen Klassert, Al Viro, netdev, linux-kernel
In-Reply-To: <20170601153645.GC10526@rei.suse.de>
On Thu, Jun 1, 2017 at 11:36 AM, Cyril Hrubis <chrubis@suse.cz> wrote:
> It seems to repeatedly produce (until I plug the cable back):
>
> ee_errno = 113 ee_origin = 2 ee_type = 3 ee_code = 1 ee_info = 0 ee_data = 0
>
> So we get EHOSTUNREACH on SO_EE_ORIGIN_ICMP.
Thank you very much! I have a wild guess that, when we
have a train of skbs on the error queue starting from a local error,
we will see this issue.
Ping (without my patch) considers EAGAIN on a normal read as an
indication that there is nothing on the error queue, but that's a
flawed assumption.
Would you mind trying another shot in the darkness please? Thanks!
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 5a726161f4e4..097152a03c74 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3742,7 +3742,8 @@ EXPORT_SYMBOL(sock_queue_err_skb);
static bool is_icmp_err_skb(const struct sk_buff *skb)
{
return skb && (SKB_EXT_ERR(skb)->ee.ee_origin == SO_EE_ORIGIN_ICMP ||
- SKB_EXT_ERR(skb)->ee.ee_origin == SO_EE_ORIGIN_ICMP6);
+ SKB_EXT_ERR(skb)->ee.ee_origin == SO_EE_ORIGIN_ICMP6 ||
+ SKB_EXT_ERR(skb)->ee.ee_origin == SO_EE_ORIGIN_LOCAL);
}
struct sk_buff *sock_dequeue_err_skb(struct sock *sk)
@@ -3751,14 +3752,19 @@ struct sk_buff *sock_dequeue_err_skb(struct sock *sk)
struct sk_buff *skb, *skb_next = NULL;
bool icmp_next = false;
unsigned long flags;
+ int err = 0;
spin_lock_irqsave(&q->lock, flags);
skb = __skb_dequeue(q);
- if (skb && (skb_next = skb_peek(q)))
+ if (skb && (skb_next = skb_peek(q))) {
icmp_next = is_icmp_err_skb(skb_next);
+ err = SKB_EXT_ERR(skb_next)->ee.ee_origin;
+ }
spin_unlock_irqrestore(&q->lock, flags);
- if (is_icmp_err_skb(skb) && !icmp_next)
+ if (icmp_next)
+ sk->sk_err = err;
+ else if (is_icmp_err_skb(skb) && !icmp_next)
sk->sk_err = 0;
if (skb_next)
^ permalink raw reply related
* Re: [PATCH net-next 2/3] udp: avoid a cache miss on dequeue
From: Eric Dumazet @ 2017-06-01 16:40 UTC (permalink / raw)
To: Paolo Abeni; +Cc: Eric Dumazet, netdev, David S. Miller
In-Reply-To: <1496334113.9312.8.camel@redhat.com>
On Thu, Jun 1, 2017 at 9:21 AM, Paolo Abeni <pabeni@redhat.com> wrote:
> I'm sorry, I do not follow. I'm concerned about the secpath field (skb-
>>sp), which is the only one that can be not NULL in
> __udp_queue_rcv_skb().
>
> If the secpath is not NULL, calling there secpath_reset() (or the to-
> be-introduced skb_reset_head_state()), we will properly release it and
> we will clear the field, too.
>
> Calling skb_release_head_state() in the same scenario, we release the
> secpath, but we don't clear it. So if the packet is later dropped we
> will get a double free, unless we add and use a specialized a
> free_stateless_skb(), too.
Then simply use secpath_reset() instead of secpath_put() from
skb_release_head_state()
Clearly having these subtle differences bring confusion, for very little gain.
secpath_put() should be removed. Most of its callers simply set
skb->sp back to NULL anyway.
^ permalink raw reply
* Re: [PATCH net-next 1/4] net/flow_dissector: add support for dissection of misc ip header fields
From: David Miller @ 2017-06-01 16:35 UTC (permalink / raw)
To: gerlitz.or; +Cc: tom, jiri, ogerlitz, netdev, saeedm, roid, paulb
In-Reply-To: <CAJ3xEMgmmJOyvdhXeAk231Nqox64OcuPVjYYYuyd-oqOJJ0LQg@mail.gmail.com>
From: Or Gerlitz <gerlitz.or@gmail.com>
Date: Thu, 1 Jun 2017 19:08:56 +0300
> On Tue, May 30, 2017 at 7:18 PM, David Miller <davem@davemloft.net> wrote:
>
>> The top level merge commit explains everything, and since the patches
>> are grouped together logically, even if you just look at the merge
>> commit in the GIT tree, it is mentioned.
>
> Hi Dave,
>
> Do you want to see a repost here or you are going to process the
> series I submitted from patchworks?
There needs to be a repost.
^ permalink raw reply
* Re: [PATCH net] ibmvnic: Update module author
From: David Miller @ 2017-06-01 16:34 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev, nfont, jallen
In-Reply-To: <ca0058c6-ef92-da31-a4e9-50d4e930ed72@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Thu, 1 Jun 2017 10:53:13 -0500
> Would it be better to include a second or more authors and/or remove
> the original author's mailing address, which isn't valid anymore?
> How should this be handled?
You can remove the email address if it is no longer working.
^ permalink raw reply
* Re: [PATCH net] net: bridge: start hello timer only if device is up
From: David Miller @ 2017-06-01 16:31 UTC (permalink / raw)
To: nikolay; +Cc: netdev, roopa, lucien.xin, cera, sebott
In-Reply-To: <1496329675-11254-1-git-send-email-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Thu, 1 Jun 2017 18:07:55 +0300
> When the transition of NO_STP -> KERNEL_STP was fixed by always calling
> mod_timer in br_stp_start, it introduced a new regression which causes
> the timer to be armed even when the bridge is down, and since we stop
> the timers in its ndo_stop() function, they never get disabled if the
> device is destroyed before it's upped.
>
> To reproduce:
> $ while :; do ip l add br0 type bridge hello_time 100; brctl stp br0 on;
> ip l del br0; done;
>
> CC: Xin Long <lucien.xin@gmail.com>
> CC: Ivan Vecera <cera@cera.cz>
> CC: Sebastian Ott <sebott@linux.vnet.ibm.com>
> Reported-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
> Fixes: 6d18c732b95c ("bridge: start hello_timer when enabling KERNEL_STP in br_stp_start")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: spectrum: Implement the ethtool flash_device callback
From: David Miller @ 2017-06-01 16:25 UTC (permalink / raw)
To: yotamg; +Cc: netdev, idosch, eladr, ogerlitz, ilant, jiri, arkadis
In-Reply-To: <20170601132646.51869-1-yotamg@mellanox.com>
From: Yotam Gigi <yotamg@mellanox.com>
Date: Thu, 1 Jun 2017 16:26:46 +0300
> Add callback to the ethtool flash_device op. This callback uses the mlxfw
> module to flash the new firmware file to the device.
>
> As the firmware flash process takes about 20 seconds and ethtool takes the
> rtnl lock during the flash_device callback, release the rtnl lock at the
> beginning of the flash process and take it again before leaving the
> callback. This way, the rtnl is not held during the process. To make sure
> the device does not get deleted during the flash process, take a reference
> to it before releasing the rtnl lock.
>
> Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
You're going to have to implement some kind of sleeping synchronization
then, in order to prevent another thread coming in and starting another
flash at the same time.
Nevermind, I see you have to take the FSM lock to start the flash
operation so it should be fine.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/5] net: phy: hook up clause 45 autonegotiation restart
From: Russell King - ARM Linux @ 2017-06-01 16:24 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, netdev
In-Reply-To: <20170601154735.GB22219@n2100.armlinux.org.uk>
On Thu, Jun 01, 2017 at 04:47:35PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 01, 2017 at 03:19:55PM +0200, Andrew Lunn wrote:
> > On Thu, Jun 01, 2017 at 02:09:00PM +0100, Russell King - ARM Linux wrote:
> > > On Thu, Jun 01, 2017 at 03:05:27PM +0200, Andrew Lunn wrote:
> > > > So you are saying a 10G PHY driver always needs to have a aneg_done
> > > > callback, even if it just needs to call phygen_c45_aneg_done?
> > > >
> > > > This seems a bit error prone. I can see somebody writing a 10G driver,
> > > > leaving out aneg_done() and having the c22 version called. Is the read
> > > > of MII_BMSR likely to return 0xffff, since the register does not
> > > > exist? If so, genphy_aneg_done() is likely to always return
> > > > BMSR_ANEGCOMPLETE.
> > >
> > > Don't forget that the read will fail, so phy_read() will return a
> > > negative number.
> >
> > By fail, you mean return something like -EIO or -ETIMEOUT? Is this
> > guaranteed in the code somewhere? This particular Marvell PHY only
> > does c45. But i could imagine some other PHYs answering a c22 request
> > with 0xffff.
>
> Yes, C45 allows the PHYs to answer C22 as well, but then they have to
> implement the C22 register set. Such a PHY would be out of spec,
> especially as what you're suggesting is that it answers C22 cycles
> and fails to implement MII_BMSR. I also think that there's a comment
> in the 802.3 specs that says that unimplemented registers are to
> return zero, not 0xffff.
Checking 802.3-2015, in "22.2.4 Management functions", the first
sentence requires all PHYs that respond to Clause 22 cycles to
implement BMCR and BMSR. However, my statement about unimplemented
registers returning zero seems to be a C45 thing, not a C22 thing,
according to the C22 PICS and "45.2 MDIO Interface Registers"
However, digging a bit further, "22.2.4.2.10 Auto-Negotiation complete"
states that bit 5 shall be zero if aneg has not completed or if aneg is
unimplemented.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH net] bnx2x: Fix Multi-Cos
From: David Miller @ 2017-06-01 16:22 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev, eric.dumazet
In-Reply-To: <20170601125756.25019-1-Yuval.Mintz@cavium.com>
From: Yuval Mintz <Yuval.Mintz@cavium.com>
Date: Thu, 1 Jun 2017 15:57:56 +0300
> Apparently multi-cos isn't working for bnx2x quite some time -
> driver implements ndo_select_queue() to allow queue-selection
> for FCoE, but the regular L2 flow would cause it to modulo the
> fallback's result by the number of queues.
> The fallback would return a queue matching the needed tc
> [via __skb_tx_hash()], but since the modulo is by the number of TSS
> queues where number of TCs is not accounted, transmission would always
> be done by a queue configured into using TC0.
>
> Fixes: ada7c19e6d27 ("bnx2x: use XPS if possible for bnx2x_select_queue instead of pure hash")
> Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next 2/3] udp: avoid a cache miss on dequeue
From: Paolo Abeni @ 2017-06-01 16:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, David S. Miller, Eric Dumazet
In-Reply-To: <1496332699.27480.14.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, 2017-06-01 at 08:58 -0700, Eric Dumazet wrote:
> On Thu, 2017-06-01 at 12:39 +0200, Paolo Abeni wrote:
> > On Wed, 2017-05-31 at 10:00 -0700, Eric Dumazet wrote:
> > > On Mon, 2017-05-29 at 17:27 +0200, Paolo Abeni wrote:
> > > > Since UDP no more uses sk->destructor, we can clear completely
> > > > the skb head state before enqueuing.
> > >
> > > ...
> > >
> > > > @@ -1739,6 +1740,9 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> > > > sk_mark_napi_id_once(sk, skb);
> > > > }
> > > >
> > > > + /* drop all pending head states; dst, nf and sk are dropped by caller */
> > > > + secpath_reset(skb);
> > > > +
> > >
> > > I wonder if using skb_release_head_state() would be more appropriate ?
> > >
> > > Surely more descriptive and probably not more expensive since all
> > > cache lines should be already hot at this point.
> >
> > Thank you for reviewing this.
> >
> > I would prefer not adding more code to the core, but I think we would
> > need something new, like:
> >
> > skb_reset_head_state()
> > {
> > skb_dst_drop(skb);
> > secpath_reset(skb);
> > nf_reset(skb);
> > skb_orphan(skb);
> > }
> >
> > because elsewhere the skb could be in inconsistent state: skb->sp !=
> > NULL but with its refcount is already decremented. WDYT?
>
> I do not believe skb->sk is set anymore in UDP receive path.
>
> If early demux sets skb->sk for a moment, skb_steal_sock() would set
> skb->sk back to NULL
I'm sorry, I do not follow. I'm concerned about the secpath field (skb-
>sp), which is the only one that can be not NULL in
__udp_queue_rcv_skb().
If the secpath is not NULL, calling there secpath_reset() (or the to-
be-introduced skb_reset_head_state()), we will properly release it and
we will clear the field, too.
Calling skb_release_head_state() in the same scenario, we release the
secpath, but we don't clear it. So if the packet is later dropped we
will get a double free, unless we add and use a specialized a
free_stateless_skb(), too.
Paolo
^ permalink raw reply
* Re: Cherry pick commit *net: better skb->sender_cpu and skb->napi_id cohabitation* to 4.4 series?
From: David Miller @ 2017-06-01 16:19 UTC (permalink / raw)
To: pmenzel; +Cc: edumazet, netdev, ast, it+linux-netdev
In-Reply-To: <987d9047-08ac-0d53-2d1f-ef9189988ee2@molgen.mpg.de>
Neither of us have anything to do with the 4.4 -stable series. We only
manage stable backport submissions for the most recent two releases.
^ permalink raw reply
* Re: [PATCH net-next 00/11] qed: Status block changes
From: David Miller @ 2017-06-01 16:17 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev
In-Reply-To: <20170601122911.22493-1-Yuval.Mintz@cavium.com>
From: Yuval Mintz <Yuval.Mintz@cavium.com>
Date: Thu, 1 Jun 2017 15:29:00 +0300
> The device maintains a CAM mapping of the internal status blocks
> and the various PF/VF MSI-x vector mappings.
> During initialization, the driver reads the HW memory and constructs
> a shadow SW implementation which it would later use for manipulation
> of interrupts. E.g., when enabling VFs and setting their MSI-x tables.
>
> The driver currently has some very strict assumptions on the order the
> entries are placed in the CAM. Specifically, it assumes that all entries
> belonging to a PF would be consecutive and in-order in the CAM, and that
> the VF entries would then follow. But there's no actual HW constraint
> enforcing this assumption [although management firmware does set it
> accordingly to same assumption initially].
>
> Since the CAM is re-configurable, there are now SW flows employeed
> by other OSes that might cause the assumption to be invalid.
> Such flows allow the PF to forfeit some of it's available interrupts
> in favor of its VFs or vice versa.
> While those are not employeed today by qed, we want to relax the
> assumptions as much as we can -
> both to allow functionality after PDA as well as allowing future
> compatibility where the driver would be loaded after a newer one has
> 'dirtied' the CAM configuration.
>
> In addition to patches meant for the above relaxation, the series
> also contains various cleanups & refactoring for interrupt logic
> [most of which is !semantic].
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH][net-next] net: dsa: make function ksz_rcv static
From: David Miller @ 2017-06-01 16:12 UTC (permalink / raw)
To: colin.king
Cc: Woojung.Huh, UNGLinuxDriver, andrew, vivien.didelot, f.fainelli,
netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170601122242.14341-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Thu, 1 Jun 2017 13:22:42 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> function ksz_rcv can be made static as it does not need to be
> in global scope. Reformat arguments to make it checkpatch warning
> free too.
>
> Cleans up sparse warning: "symbol 'ksz_rcv' was not declared. Should
> it be static?"
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store
From: Jonathan Corbet @ 2017-06-01 16:11 UTC (permalink / raw)
To: Jia-Ju Bai
Cc: Larry Finger, kvalo, linux-wireless, b43-dev, netdev,
linux-kernel
In-Reply-To: <592F6843.9000204@163.com>
On Thu, 01 Jun 2017 09:05:07 +0800
Jia-Ju Bai <baijiaju1990@163.com> wrote:
> I admit my patches are not well tested, and they may not well fix the bugs.
> I am looking forward to opinions and suggestions :)
May I politely suggest that sending out untested locking changes is a
dangerous thing to do? You really should not be changing the locking in a
piece of kernel code without understanding very well what the lock is
protecting and being able to say why your changes are safe. Without that,
the risk of introducing subtle bugs is very high.
It looks like you have written a useful tool that could help us to make
the kernel more robust. If you are interested in my suggestion, I would
recommend that you post the sleep-in-atomic scenarios that you are
finding, but refrain from "fixing" them in any case where you cannot offer
a strong explanation of why your fix is correct.
Thanks for working to find bugs in the kernel!
jon
^ permalink raw reply
* Re: [PATCH net] cxgb4: update latest firmware version supported
From: David Miller @ 2017-06-01 16:10 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan
In-Reply-To: <1496317290-26368-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Thu, 1 Jun 2017 17:11:30 +0530
> Change t4fw_version.h to update latest firmware version
> number to 1.16.45.0.
>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ 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