* [PATCH net] net: dsa: Bring back device detaching in dsa_slave_suspend()
From: Florian Fainelli @ 2017-01-25 17:10 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Andrew Lunn, Vivien Didelot, David S. Miller,
open list
Commit 448b4482c671 ("net: dsa: Add lockdep class to tx queues to avoid
lockdep splat") removed the netif_device_detach() call done in
dsa_slave_suspend() which is necessary, and paired with a corresponding
netif_device_attach(), bring it back.
Fixes: 448b4482c671 ("net: dsa: Add lockdep class to tx queues to avoid lockdep splat")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
David,
Can you also queue this for -stable? Thanks!
net/dsa/slave.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 68c9eea00518..020a28d5c93e 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1203,6 +1203,8 @@ int dsa_slave_suspend(struct net_device *slave_dev)
{
struct dsa_slave_priv *p = netdev_priv(slave_dev);
+ netif_device_detach(slave_dev);
+
if (p->phy) {
phy_stop(p->phy);
p->old_pause = -1;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support
From: David Miller @ 2017-01-25 17:22 UTC (permalink / raw)
To: tracywwnj; +Cc: w, eric.dumazet, netdev, edumazet, ycheng, weiwan
In-Reply-To: <CAC15z3izWNh7th_yxA_a90vgLnU5XzVDm6vyojq3cMDgQZ71YA@mail.gmail.com>
From: Wei Wang <tracywwnj@gmail.com>
Date: Wed, 25 Jan 2017 09:15:34 -0800
> Looks like you sent a separate patch on top of this patch series to
> address double connect(). Then I think this patch series should be
> good to go.
Indeed, Willy please give some kind of ACK.
Thanks.
^ permalink raw reply
* Re: [PATCH net] sctp: sctp_addr_id2transport should verify the addr before looking up assoc
From: David Miller @ 2017-01-25 17:27 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <2ba9d3e0b3aa05baa3791811c92248126d233c67.1485237713.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Tue, 24 Jan 2017 14:01:53 +0800
> sctp_addr_id2transport is a function for sockopt to look up assoc by
> address. As the address is from userspace, it can be a v4-mapped v6
> address. But in sctp protocol stack, it always handles a v4-mapped
> v6 address as a v4 address. So it's necessary to convert it to a v4
> address before looking up assoc by address.
>
> This patch is to fix it by calling sctp_verify_addr in which it can do
> this conversion before calling sctp_endpoint_lookup_assoc, just like
> what sctp_sendmsg and __sctp_connect do for the address from users.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Workaround missing PHY ID on mv88e6390
From: Gregory CLEMENT @ 2017-01-25 17:27 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David Miller, netdev, Vivien Didelot
In-Reply-To: <1485309314-23942-2-git-send-email-andrew@lunn.ch>
Hi Andrew,
On mer., janv. 25 2017, Andrew Lunn <andrew@lunn.ch> wrote:
> The internal PHYs of the mv88e6390 do not have a model ID. Trap any
> calls to the ID register, and if it is zero, return the ID for the
> mv88e6390. The Marvell PHY driver can then bind to this ID.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/dsa/mv88e6xxx/global2.c | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/mv88e6xxx/global2.c b/drivers/net/dsa/mv88e6xxx/global2.c
> index 353e26bea3c3..521a5511bd5f 100644
> --- a/drivers/net/dsa/mv88e6xxx/global2.c
> +++ b/drivers/net/dsa/mv88e6xxx/global2.c
> @@ -520,7 +520,21 @@ int mv88e6xxx_g2_smi_phy_read(struct mv88e6xxx_chip *chip,
> if (err)
> return err;
>
> - return mv88e6xxx_g2_read(chip, GLOBAL2_SMI_PHY_DATA, val);
> + err = mv88e6xxx_g2_read(chip, GLOBAL2_SMI_PHY_DATA, val);
> + if (err)
> + return err;
> +
> + if (reg == MII_PHYSID2) {
> + /* The mv88e6390 internal PHYS don't have a model number.
> + * Use the switch family model number instead.
> + */
> + if (!(*val & 0x3ff)) {
I tested this series on the Topaz switch but it failed because while I
said we read 0x1410C00 actually we read 0x01410C01. With the
MARVELL_PHY_ID_MASK we mask the 4 lower bits so that's why in my patch
"phy: marvell: Add support for the PHY embedded in the topaz switch" I
used the 0x01410C00 value for MARVELL_PHY_ID_88E6141.
However with the mask you use it doesn't work.
So this mask should be changed to 0x3f0 for the Topaz. Actually 0x3fe
would be enough but it seems more logical to use the same mask that for
MARVELL_PHY_ID_MASK.
We could either use the same mask for both family and still use 6390 as
they seem compatible or we use two different families based on the lower
bit.
Gregory
> + if (chip->info->family == MV88E6XXX_FAMILY_6390)
> + *val |= PORT_SWITCH_ID_PROD_NUM_6390;
> + }
> + }
> +
> + return 0;
> }
>
> int mv88e6xxx_g2_smi_phy_write(struct mv88e6xxx_chip *chip,
> --
> 2.11.0
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH net] sctp: sctp gso should set feature with NETIF_F_SG when calling skb_segment
From: David Miller @ 2017-01-25 17:29 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <7b4d081c051650e706ffda360fdfbd4baaa1a317.1485237916.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Tue, 24 Jan 2017 14:05:16 +0800
> Now sctp gso puts segments into skb's frag_list, then processes these
> segments in skb_segment. But skb_segment handles them only when gs is
> enabled, as it's in the same branch with skb's frags.
>
> Although almost all the NICs support sg other than some old ones, but
> since commit 1e16aa3ddf86 ("net: gso: use feature flag argument in all
> protocol gso handlers"), features &= skb->dev->hw_enc_features, and
> xfrm_output_gso call skb_segment with features = 0, which means sctp
> gso would call skb_segment with sg = 0, and skb_segment would not work
> as expected.
>
> This patch is to fix it by setting features param with NETIF_F_SG when
> calling skb_segment so that it can go the right branch to process the
> skb's frag_list.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v4] net: ethernet: faraday: To support device tree usage.
From: David Miller @ 2017-01-25 17:34 UTC (permalink / raw)
To: green.hu
Cc: netdev, devicetree, andrew, arnd, jiri, linux-kernel, f.fainelli,
robh+dt, mark.rutland
In-Reply-To: <20170124084606.GA11764@app09>
From: Greentime Hu <green.hu@gmail.com>
Date: Tue, 24 Jan 2017 16:46:14 +0800
> We also use the same binding document to describe the same faraday ethernet
> controller and add faraday to vendor-prefixes.txt.
>
> Signed-off-by: Greentime Hu <green.hu@gmail.com>
> ---
> Changes in v4:
> - Use the same binding document to describe the same faraday ethernet controller and add faraday to vendor-prefixes.txt.
> Changes in v3:
> - Nothing changed in this patch but I have committed andestech to vendor-prefixes.txt.
> Changes in v2:
> - Change atmac100_of_ids to ftmac100_of_ids
>
> ---
> .../net/{moxa,moxart-mac.txt => faraday,ftmac.txt} | 7 +++++--
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> drivers/net/ethernet/faraday/ftmac100.c | 7 +++++++
> 3 files changed, 13 insertions(+), 2 deletions(-)
> rename Documentation/devicetree/bindings/net/{moxa,moxart-mac.txt => faraday,ftmac.txt} (68%)
>
> diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt b/Documentation/devicetree/bindings/net/faraday,ftmac.txt
> similarity index 68%
> rename from Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
> rename to Documentation/devicetree/bindings/net/faraday,ftmac.txt
Why are you renaming the MOXA binding file instead of adding a completely new one
for faraday? The MOXA one should stick around, I don't see a justification for
removing it.
^ permalink raw reply
* Re: [PATCH] net: ethernet: mvneta: add support for 2.5G DRSGMII mode
From: David Miller @ 2017-01-25 17:38 UTC (permalink / raw)
To: jlu-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20170123142206.5390-1-jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
From: Jan Luebbe <jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Date: Mon, 23 Jan 2017 15:22:06 +0100
> The Marvell MVNETA Ethernet controller supports a 2.5 Gbps SGMII mode
> called DRSGMII.
>
> This patch adds a corresponding phy-mode string 'drsgmii' and parses it
> from DT. The MVNETA then configures the SERDES protocol value
> accordingly.
>
> It was successfully tested on a MV78460 connected to a FPGA.
>
> Signed-off-by: Jan Luebbe <jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
I still haven't seen a sufficient explanation as to why this change
works without any explicit MAC programming changes to this driver.
That really needs to be explained before I will apply this patch.
Thanks.
--
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: [PATCH net-next v7 1/1] net sched actions: Add support for user cookies
From: David Miller @ 2017-01-25 17:38 UTC (permalink / raw)
To: jhs
Cc: netdev, jiri, paulb, john.fastabend, simon.horman, mrv, hadarh,
ogerlitz, roid, xiyou.wangcong, daniel
In-Reply-To: <1485259361-16860-1-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Tue, 24 Jan 2017 07:02:41 -0500
> Introduce optional 128-bit action cookie.
Applied, but like Jiri I think you can use one buffer instead of two
to store the user's cookie data.
Thanks.
^ permalink raw reply
* Re: [patch net-next] tipc: uninitialized return code in tipc_setsockopt()
From: David Miller @ 2017-01-25 17:41 UTC (permalink / raw)
To: dan.carpenter
Cc: jon.maloy, ying.xue, netdev, tipc-discussion, kernel-janitors
In-Reply-To: <20170124094935.GA19984@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 24 Jan 2017 12:49:35 +0300
> We shuffled some code around and added some new case statements here and
> now "res" isn't initialized on all paths.
>
> Fixes: 01fd12bb189a ("tipc: make replicast a user selectable option")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: [PATCH RFC net-next] packet: always ensure that we pass hard_header_len bytes in skb_headlen() to the driver
From: David Miller @ 2017-01-25 17:45 UTC (permalink / raw)
To: sowmini.varadhan; +Cc: netdev
In-Reply-To: <1485274309-201670-1-git-send-email-sowmini.varadhan@oracle.com>
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Tue, 24 Jan 2017 08:11:49 -0800
> @@ -2685,21 +2685,22 @@ static inline int dev_parse_header(const struct sk_buff *skb,
> }
>
> /* ll_header must have at least hard_header_len allocated */
> -static inline bool dev_validate_header(const struct net_device *dev,
> +static inline int dev_validate_header(const struct net_device *dev,
> char *ll_header, int len)
> {
> if (likely(len >= dev->hard_header_len))
> - return true;
> + return len;
>
> if (capable(CAP_SYS_RAWIO)) {
> memset(ll_header + len, 0, dev->hard_header_len - len);
> - return true;
> + return dev->hard_header_len;
> }
>
> if (dev->header_ops && dev->header_ops->validate)
> - return dev->header_ops->validate(ll_header, len);
> + if (!dev->header_ops->validate(ll_header, len))
> + return -1;
>
> - return false;
> + return dev->hard_header_len;
> }
>
> typedef int gifconf_func_t(struct net_device * dev, char __user * bufptr, int len);
This mostly looks good. But I'm not so sure you handle the variable length header
case properly. That's why we have the header_ops->validate() callback, to accomodate
that.
In the variable length case, you'll end up having to return something other than
just hard_header_len. Probably you'll need to make header_ops->validate() return
that length.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Workaround missing PHY ID on mv88e6390
From: Vivien Didelot @ 2017-01-25 17:45 UTC (permalink / raw)
To: Gregory CLEMENT, Andrew Lunn; +Cc: David Miller, netdev
In-Reply-To: <87sho7123x.fsf@free-electrons.com>
Hi Gregory, Andrew,
Gregory CLEMENT <gregory.clement@free-electrons.com> writes:
>> + if (reg == MII_PHYSID2) {
>> + /* The mv88e6390 internal PHYS don't have a model number.
>> + * Use the switch family model number instead.
>> + */
>> + if (!(*val & 0x3ff)) {
>
> I tested this series on the Topaz switch but it failed because while I
> said we read 0x1410C00 actually we read 0x01410C01. With the
> MARVELL_PHY_ID_MASK we mask the 4 lower bits so that's why in my patch
> "phy: marvell: Add support for the PHY embedded in the topaz switch" I
> used the 0x01410C00 value for MARVELL_PHY_ID_88E6141.
>
> However with the mask you use it doesn't work.
>
> So this mask should be changed to 0x3f0 for the Topaz. Actually 0x3fe
> would be enough but it seems more logical to use the same mask that for
> MARVELL_PHY_ID_MASK.
>
> We could either use the same mask for both family and still use 6390 as
> they seem compatible or we use two different families based on the lower
> bit.
Since several chips have this issue, we can introduce a u16 physid2_mask
member in the mv88e6xxx_info structure and move the check in
mv88e6xxx_phy_read() so that the logic of device (as in Global2) helpers
are not affected by such (necessary) hack. Something like:
static int mv88e6xxx_phy_read(struct mv88e6xxx_chip *chip, int phy,
int reg, u16 *val)
{
...
err = chip->info->ops->phy_read(chip, bus, addr, reg, val);
if (err)
return err;
if (reg == MII_PHYSID2 && chip->info->physid2_mask) {
/* Some internal PHYs don't have a model number,
* so return the switch family model number directly.
*/
if (!(*val & chip->info->physid2_mask))
*val |= chip->info->prod_num;
}
return 0;
}
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Workaround missing PHY ID on mv88e6390
From: Florian Fainelli @ 2017-01-25 17:51 UTC (permalink / raw)
To: Gregory CLEMENT, Andrew Lunn; +Cc: David Miller, netdev, Vivien Didelot
In-Reply-To: <87sho7123x.fsf@free-electrons.com>
On 01/25/2017 09:27 AM, Gregory CLEMENT wrote:
> Hi Andrew,
>
> On mer., janv. 25 2017, Andrew Lunn <andrew@lunn.ch> wrote:
>
>> The internal PHYs of the mv88e6390 do not have a model ID. Trap any
>> calls to the ID register, and if it is zero, return the ID for the
>> mv88e6390. The Marvell PHY driver can then bind to this ID.
>>
>> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> drivers/net/dsa/mv88e6xxx/global2.c | 16 +++++++++++++++-
>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/dsa/mv88e6xxx/global2.c b/drivers/net/dsa/mv88e6xxx/global2.c
>> index 353e26bea3c3..521a5511bd5f 100644
>> --- a/drivers/net/dsa/mv88e6xxx/global2.c
>> +++ b/drivers/net/dsa/mv88e6xxx/global2.c
>> @@ -520,7 +520,21 @@ int mv88e6xxx_g2_smi_phy_read(struct mv88e6xxx_chip *chip,
>> if (err)
>> return err;
>>
>> - return mv88e6xxx_g2_read(chip, GLOBAL2_SMI_PHY_DATA, val);
>> + err = mv88e6xxx_g2_read(chip, GLOBAL2_SMI_PHY_DATA, val);
>> + if (err)
>> + return err;
>> +
>> + if (reg == MII_PHYSID2) {
>> + /* The mv88e6390 internal PHYS don't have a model number.
>> + * Use the switch family model number instead.
>> + */
>> + if (!(*val & 0x3ff)) {
>
> I tested this series on the Topaz switch but it failed because while I
> said we read 0x1410C00 actually we read 0x01410C01. With the
> MARVELL_PHY_ID_MASK we mask the 4 lower bits so that's why in my patch
> "phy: marvell: Add support for the PHY embedded in the topaz switch" I
> used the 0x01410C00 value for MARVELL_PHY_ID_88E6141.
>
> However with the mask you use it doesn't work.
>
> So this mask should be changed to 0x3f0 for the Topaz. Actually 0x3fe
> would be enough but it seems more logical to use the same mask that for
> MARVELL_PHY_ID_MASK.
>
> We could either use the same mask for both family and still use 6390 as
> they seem compatible or we use two different families based on the lower
> bit.
By convention, the lower 4 bits are used to carry revision information,
which is why most drivers use 0xxxxx_fff0, can you try to use that here
for the PHY mask value?
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Workaround missing PHY ID on mv88e6390
From: Andrew Lunn @ 2017-01-25 17:52 UTC (permalink / raw)
To: Gregory CLEMENT; +Cc: David Miller, netdev, Vivien Didelot
In-Reply-To: <87sho7123x.fsf@free-electrons.com>
> I tested this series on the Topaz switch but it failed because while I
> said we read 0x1410C00 actually we read 0x01410C01. With the
> MARVELL_PHY_ID_MASK we mask the 4 lower bits so that's why in my patch
> "phy: marvell: Add support for the PHY embedded in the topaz switch" I
> used the 0x01410C00 value for MARVELL_PHY_ID_88E6141.
O.K. The lower 4 bits seem to be the silicon revision. Marvells own
SDK ignores those bits. So lets do the same here, use
MARVELL_PHY_ID_MASK.
Andrew
^ permalink raw reply
* Re: [pull request][net-next 00/12] Mellanox mlx5 updates 2017-01-24
From: David Miller @ 2017-01-25 17:52 UTC (permalink / raw)
To: saeedm; +Cc: netdev, ogerlitz
In-Reply-To: <20170124201652.2920-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Tue, 24 Jan 2017 22:16:40 +0200
> This pull request includes one new feature to support offloading IPv6
> tunnels in switchdev mode, in addition to some small mlx5 updates.
> Details are down bleow.
>
> Please pull and let me know if there's any problem.
Pulled, thanks a lot.
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support
From: Willy Tarreau @ 2017-01-25 17:53 UTC (permalink / raw)
To: Wei Wang
Cc: Eric Dumazet, Linux Kernel Network Developers, David Miller,
Eric Dumazet, Yuchung Cheng, Wei Wang
In-Reply-To: <CAC15z3izWNh7th_yxA_a90vgLnU5XzVDm6vyojq3cMDgQZ71YA@mail.gmail.com>
Hi Wei,
On Wed, Jan 25, 2017 at 09:15:34AM -0800, Wei Wang wrote:
> Willy,
>
> Looks like you sent a separate patch on top of this patch series to address
> double connect().
Yes, sorry, I wanted to reply to this thread after the git-send-email
and got caught immediately after :-)
So as suggested by Eric in order to make the review easier, it was done
on top of your series.
> Then I think this patch series should be good to go.
> I will get your patch tested with our TFO test cases.
I think so as well. Thanks for running the tests. On my side I could fix
the haproxy bug which triggered this, and could verify the the whole
series works fine both with and without the haproxy fix. So I think we're
good now.
Thanks,
Willy
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support
From: Willy Tarreau @ 2017-01-25 17:54 UTC (permalink / raw)
To: David Miller; +Cc: tracywwnj, eric.dumazet, netdev, edumazet, ycheng, weiwan
In-Reply-To: <20170125.122205.9460825196595773.davem@davemloft.net>
On Wed, Jan 25, 2017 at 12:22:05PM -0500, David Miller wrote:
> From: Wei Wang <tracywwnj@gmail.com>
> Date: Wed, 25 Jan 2017 09:15:34 -0800
>
> > Looks like you sent a separate patch on top of this patch series to
> > address double connect(). Then I think this patch series should be
> > good to go.
>
> Indeed, Willy please give some kind of ACK.
Yes sorry David, for me it's OK. If Wei runs his whole series of tests
on it again, it should be perfect.
thanks,
Willy
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Workaround missing PHY ID on mv88e6390
From: Andrew Lunn @ 2017-01-25 18:00 UTC (permalink / raw)
To: Vivien Didelot; +Cc: Gregory CLEMENT, David Miller, netdev
In-Reply-To: <87o9yvyqwr.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
> Since several chips have this issue, we can introduce a u16 physid2_mask
> member in the mv88e6xxx_info structure and move the check in
> mv88e6xxx_phy_read() so that the logic of device (as in Global2) helpers
> are not affected by such (necessary) hack. Something like:
>
> static int mv88e6xxx_phy_read(struct mv88e6xxx_chip *chip, int phy,
> int reg, u16 *val)
> {
> ...
>
> err = chip->info->ops->phy_read(chip, bus, addr, reg, val);
> if (err)
> return err;
>
> if (reg == MII_PHYSID2 && chip->info->physid2_mask) {
> /* Some internal PHYs don't have a model number,
> * so return the switch family model number directly.
> */
> if (!(*val & chip->info->physid2_mask))
Hi Vivien
I don't see the need to have per switch masks. Lets just hard code it
to ignore the lower 4 bits.
> *val |= chip->info->prod_num;
and this is not good. I deliberately picked the family num, not the
product num. Otherwise for the 6390 family, we have 6 different PHY
IDs. And two more for Gregorys two switches.
Andrew
^ permalink raw reply
* Re: [PATCH net] net: dsa: Bring back device detaching in dsa_slave_suspend()
From: Andrew Lunn @ 2017-01-25 18:00 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, Vivien Didelot, David S. Miller, open list
In-Reply-To: <20170125171041.21442-1-f.fainelli@gmail.com>
On Wed, Jan 25, 2017 at 09:10:41AM -0800, Florian Fainelli wrote:
> Commit 448b4482c671 ("net: dsa: Add lockdep class to tx queues to avoid
> lockdep splat") removed the netif_device_detach() call done in
> dsa_slave_suspend() which is necessary, and paired with a corresponding
> netif_device_attach(), bring it back.
>
> Fixes: 448b4482c671 ("net: dsa: Add lockdep class to tx queues to avoid lockdep splat")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Sorry for accidentally removing it.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Workaround missing PHY ID on mv88e6390
From: Vivien Didelot @ 2017-01-25 18:03 UTC (permalink / raw)
To: Gregory CLEMENT, Andrew Lunn; +Cc: David Miller, netdev
In-Reply-To: <87o9yvyqwr.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
Andrew,
Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
> Since several chips have this issue, we can introduce a u16 physid2_mask
> member in the mv88e6xxx_info structure and move the check in
> mv88e6xxx_phy_read() so that the logic of device (as in Global2) helpers
> are not affected by such (necessary) hack. Something like:
>
> static int mv88e6xxx_phy_read(struct mv88e6xxx_chip *chip, int phy,
> int reg, u16 *val)
> {
> ...
>
> err = chip->info->ops->phy_read(chip, bus, addr, reg, val);
> if (err)
> return err;
>
> if (reg == MII_PHYSID2 && chip->info->physid2_mask) {
> /* Some internal PHYs don't have a model number,
> * so return the switch family model number directly.
> */
> if (!(*val & chip->info->physid2_mask))
> *val |= chip->info->prod_num;
if (reg == MII_PHYSID2 && (*val & 0xfff0) == 0)
*val |= chip->info->prod_num << 4;
then. Do you agree?
> }
>
> return 0;
> }
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH 0/6 v3] kvmalloc
From: Alexei Starovoitov @ 2017-01-25 18:14 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, Vlastimil Babka, Mel Gorman, Johannes Weiner,
linux-mm, LKML, Daniel Borkmann, netdev@vger.kernel.org
On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko <mhocko@kernel.org> wrote:
> On Wed 25-01-17 14:10:06, Michal Hocko wrote:
>> On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
>> > On Tue, Jan 24, 2017 at 04:17:52PM +0100, Michal Hocko wrote:
>> > > On Thu 12-01-17 16:37:11, Michal Hocko wrote:
>> > > > Hi,
>> > > > this has been previously posted as a single patch [1] but later on more
>> > > > built on top. It turned out that there are users who would like to have
>> > > > __GFP_REPEAT semantic. This is currently implemented for costly >64B
>> > > > requests. Doing the same for smaller requests would require to redefine
>> > > > __GFP_REPEAT semantic in the page allocator which is out of scope of
>> > > > this series.
>> > > >
>> > > > There are many open coded kmalloc with vmalloc fallback instances in
>> > > > the tree. Most of them are not careful enough or simply do not care
>> > > > about the underlying semantic of the kmalloc/page allocator which means
>> > > > that a) some vmalloc fallbacks are basically unreachable because the
>> > > > kmalloc part will keep retrying until it succeeds b) the page allocator
>> > > > can invoke a really disruptive steps like the OOM killer to move forward
>> > > > which doesn't sound appropriate when we consider that the vmalloc
>> > > > fallback is available.
>> > > >
>> > > > As it can be seen implementing kvmalloc requires quite an intimate
>> > > > knowledge if the page allocator and the memory reclaim internals which
>> > > > strongly suggests that a helper should be implemented in the memory
>> > > > subsystem proper.
>> > > >
>> > > > Most callers I could find have been converted to use the helper instead.
>> > > > This is patch 5. There are some more relying on __GFP_REPEAT in the
>> > > > networking stack which I have converted as well but considering we do
>> > > > not have a support for __GFP_REPEAT for requests smaller than 64kB I
>> > > > have marked it RFC.
>> > >
>> > > Are there any more comments? I would really appreciate to hear from
>> > > networking folks before I resubmit the series.
>> >
>> > while this patchset was baking the bpf side switched to use bpf_map_area_alloc()
>> > which fixes the issue with missing __GFP_NORETRY that we had to fix quickly.
>> > See commit d407bd25a204 ("bpf: don't trigger OOM killer under pressure with map alloc")
>> > it covers all kmalloc/vmalloc pairs instead of just one place as in this set.
>> > So please rebase and switch bpf_map_area_alloc() to use kvmalloc().
>>
>> OK, will do. Thanks for the heads up.
>
> Just for the record, I will fold the following into the patch 1
> ---
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 19b6129eab23..8697f43cf93c 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -53,21 +53,7 @@ void bpf_register_map_type(struct bpf_map_type_list *tl)
>
> void *bpf_map_area_alloc(size_t size)
> {
> - /* We definitely need __GFP_NORETRY, so OOM killer doesn't
> - * trigger under memory pressure as we really just want to
> - * fail instead.
> - */
> - const gfp_t flags = __GFP_NOWARN | __GFP_NORETRY | __GFP_ZERO;
> - void *area;
> -
> - if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) {
> - area = kmalloc(size, GFP_USER | flags);
> - if (area != NULL)
> - return area;
> - }
> -
> - return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM | flags,
> - PAGE_KERNEL);
> + return kvzalloc(size, GFP_USER);
> }
>
> void bpf_map_area_free(void *area)
Looks fine by me.
Daniel, thoughts?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net-next] tcp: reduce skb overhead in selected places
From: David Miller @ 2017-01-25 18:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1485298656.16328.355.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 24 Jan 2017 14:57:36 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> tcp_add_backlog() can use skb_condense() helper to get better
> gains and less SKB_TRUESIZE() magic. This only happens when socket
> backlog has to be used.
>
> Some attacks involve specially crafted out of order tiny TCP packets,
> clogging the ofo queue of (many) sockets.
> Then later, expensive collapse happens, trying to copy all these skbs
> into single ones.
> This unfortunately does not work if each skb has no neighbor in TCP
> sequence order.
>
> By using skb_condense() if the skb could not be coalesced to a prior
> one, we defeat these kind of threats, potentially saving 4K per skb
> (or more, since this is one page fragment).
>
> A typical NAPI driver allocates gro packets with GRO_MAX_HEAD bytes
> in skb->head, meaning the copy done by skb_condense() is limited to
> about 200 bytes.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next 0/3] BPF tracepoints
From: David Miller @ 2017-01-25 18:19 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev, linux-kernel
In-Reply-To: <cover.1485306168.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Wed, 25 Jan 2017 02:28:15 +0100
> This set adds tracepoints to BPF for better introspection and
> debugging. The first two patches are prerequisite for the actual
> third patch that adds the tracepoints. I think the first two are
> small and straight forward enough that they could ideally go via
> net-next, but I'm also open to other suggestions on how to route
> them in case that's not applicable (it would reduce potential
> merge conflicts on BPF side, though). For details, please see
> individual patches.
Looks great, series applied, thanks Daniel.
^ permalink raw reply
* Re: [PATCH net-next] Doc: DT: bindings: net: dsa: marvell.txt: Tabification
From: David Miller @ 2017-01-25 18:20 UTC (permalink / raw)
To: andrew; +Cc: netdev, vivien.didelot
In-Reply-To: <1485308688-23670-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Wed, 25 Jan 2017 02:44:48 +0100
> Replace spaces with tabs. Fix indentation to be multiples of tabs, not
> a mixture or tabs and spaces.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied, thanks for following up on this.
^ permalink raw reply
* Re: [PATCH net] tcp: correct memory barrier usage in tcp_check_space()
From: David Miller @ 2017-01-25 18:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: jbaron, netdev, oleg
In-Reply-To: <1485320017.16328.386.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 24 Jan 2017 20:53:37 -0800
> On Tue, 2017-01-24 at 21:49 -0500, Jason Baron wrote:
>> From: Jason Baron <jbaron@akamai.com>
>>
>> sock_reset_flag() maps to __clear_bit() not the atomic version clear_bit().
>> Thus, we need smp_mb(), smp_mb__after_atomic() is not sufficient.
>>
>> Fixes: 3c7151275c0c ("tcp: add memory barriers to write space paths")
>> Cc: Eric Dumazet <eric.dumazet@gmail.com>
>> Cc: Oleg Nesterov <oleg@redhat.com>
>> Signed-off-by: Jason Baron <jbaron@akamai.com>
>> ---
>> net/ipv4/tcp_input.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Acked-by: Eric Dumazet <edumazet@google.com>
>
> I believe this would need also this for proper attribution.
>
> Reported-by: Oleg Nesterov <oleg@redhat.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next] r8152: fix the wrong spelling
From: David Miller @ 2017-01-25 18:24 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-241-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Wed, 25 Jan 2017 13:41:45 +0800
> Replace rumtime with runtime.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied, thanks.
^ 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