* Re: [PATCH net-next 0/2] netvsc: transparent VF related cleanups
From: David Miller @ 2017-09-02 3:31 UTC (permalink / raw)
To: stephen; +Cc: kys, haiyangz, sthemmin, devel, netdev
In-Reply-To: <20170831231613.15805-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 31 Aug 2017 16:16:11 -0700
> The first gets rid of unnecessary ref counting, and second
> allows removing hv_netvsc driver even if VF present.
Series applied.
^ permalink raw reply
* Re: [net-next PATCH] bpf: sockmap update/simplify memory accounting scheme
From: David Miller @ 2017-09-02 3:29 UTC (permalink / raw)
To: john.fastabend; +Cc: netdev, daniel, ast
In-Reply-To: <20170901182926.8981.77450.stgit@john-Precision-Tower-5810>
From: John Fastabend <john.fastabend@gmail.com>
Date: Fri, 01 Sep 2017 11:29:26 -0700
> Instead of tracking wmem_queued and sk_mem_charge by incrementing
> in the verdict SK_REDIRECT paths and decrementing in the tx work
> path use skb_set_owner_w and sock_writeable helpers. This solves
> a few issues with the current code. First, in SK_REDIRECT inc on
> sk_wmem_queued and sk_mem_charge were being done without the peers
> sock lock being held. Under stress this can result in accounting
> errors when tx work and/or multiple verdict decisions are working
> on the peer psock.
>
> Additionally, this cleans up the code because we can rely on the
> default destructor to decrement memory accounting on kfree_skb. Also
> this will trigger sk_write_space when space becomes available on
> kfree_skb() which wasn't happening before and prevent __sk_free
> from being called until all in-flight packets are completed.
>
> Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/2] net: ubuf_info.refcnt conversion
From: David Miller @ 2017-09-02 3:22 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, willemb
In-Reply-To: <1504287389.15310.21.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 01 Sep 2017 10:36:29 -0700
> On Thu, 2017-08-31 at 17:04 -0700, Eric Dumazet wrote:
>> On Thu, 2017-08-31 at 16:48 -0700, Eric Dumazet wrote:
>> > Yet another atomic_t -> refcount_t conversion, split in two patches.
>> >
>> > First patch prepares the automatic conversion done in the second patch.
>> >
>> > Eric Dumazet (2):
>> > net: prepare (struct ubuf_info)->refcnt conversion
>> > net: convert (struct ubuf_info)->refcnt to refcount_t
>> >
>> > drivers/vhost/net.c | 2 +-
>> > include/linux/skbuff.h | 5 +++--
>> > net/core/skbuff.c | 14 ++++----------
>> > net/ipv4/tcp.c | 2 --
>> > 4 files changed, 8 insertions(+), 15 deletions(-)
>> >
>>
>> David please ignore this series, I will send a V3 :)
>>
>
> No need for a V3, sorry for the confusion, but we had to double check
> with Willem that everything had been covered.
>
> Please tell me if I need to resend, thanks !
Ok, series applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] net: systemport: Correctly set TSB endian for host
From: David Miller @ 2017-09-02 3:19 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev
In-Reply-To: <1504312354-62020-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 1 Sep 2017 17:32:34 -0700
> Similarly to how we configure the RSB (Receive Status Block) we also
> need to set the TSB (Transmit Status Block) based on the host endian.
> This was missing from the commit indicated below.
>
> Fixes: 389a06bc534e ("net: systemport: Set correct RSB endian bits based on host")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied, thanks Florian.
^ permalink raw reply
* Re: netdev carrier changes is one even after ethernet link up.
From: Florian Fainelli @ 2017-09-02 1:55 UTC (permalink / raw)
To: Bhadram Varka, andrew@lunn.ch; +Cc: linux-netdev
In-Reply-To: <cd860399cf9148d193a08636a6d82a68@DRBGMAIL102.nvidia.com>
On 08/31/2017 10:49 PM, Bhadram Varka wrote:
> Thanks for responding. Now responding inline
>
>> -----Original Message-----
>> From: Florian Fainelli [mailto:f.fainelli@gmail.com]
>> Sent: Friday, September 01, 2017 5:53 AM
>> To: Bhadram Varka <vbhadram@nvidia.com>; andrew@lunn.ch
>> Cc: linux-netdev <netdev@vger.kernel.org>
>> Subject: Re: netdev carrier changes is one even after ethernet link up.
>>
>> On 08/30/2017 10:53 PM, Bhadram Varka wrote:
>>> Hi,
>>>
>>>
>>>
>>> I have observed that carrier_changes is one even in case of the
>>> ethernet link is up.
>>>
>>>
>>>
>>> After investigating the code below is my observation –
>>>
>>>
>>>
>>> ethernet_driver_probe()
>>>
>>> +--->phy_connect()
>>>
>>> | +--->phy_attach_direct()
>>>
>>> | +---> netif_carrier_off() : which increments
>>> carrier_changes to one.
>>>
>>> +--->register_netdevice() : will the carrier_changes becomes zero here ?
>>>
>>> +--->netif_carrier_off(): not increment the carrier_changes since
>>> __LINK_STATE_NOCARRIER already set.
>>>
>>>
>>>
>>> From ethernet driver open will start the PHY and trigger the
>>> phy_state_machine.
>>>
>>> Phy_state_machine workqueue calling netif_carrier_on() once the link is
>> UP.
>>>
>>> netif_carrier_on() increments the carrier_changes by one.
>>
>> If the call trace is correct, then there is at least two problems here:
>>
>> - phy_connect() does start the PHY machine which means that as soon as it
>> detects a link state of any kind (up or down) it can call
>> netif_carrier_off() respectively netif_carrier_on()
>>
>> - as soon as you call register_netdevice() notifiers run and other parts of the
>> kernel or user-space programs can see an inconsistent link state
>>
>> I would suggest doing the following sequence instead:
>>
>> netif_carrier_off()
>> register_netdevice()
>> phy_connect()
>>
>> Which should result in a consistent link state and carrier value.
>>
> Yes, It will address the issue.
>
> If we did the phy_conect in ndo_open it will make the carrier changes as two. But if we did in probe function then it's not working.
>
> In ethernet driver probe - (below sequence is not working)
> phy_connect()
> register_netdevice()
> netif_carrier_off()
>
> working sequence:
> In probe():
> register_netdevice()
> ndo_open:
> phy_connect()
>
> After reverting - https://lkml.org/lkml/2016/1/9/173 this works if we do phy_connect in probe as well.
But as mentioned before you should not be doing the PHY probe in your
driver's probe function for different reasons:
- the probe function's responsibility is to initialize the driver and
the HW to a state where they both have everything needed but it should
be in quiesced state. There is no guarantee that your network device may
ever be used after probe unless something calls ndo_open(), you should
therefore keep all resources to a minimum: memory allocated, HW powered
down etc.
- there is a race condition between the PHY state machine started in
phy_connect(), and when register_netdevice() is called and notifiers
running which can lead to an inconsistent state for the carrier
So considering that your driver does not do that, I am not sure what you
are expecting...
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v5 0/2] report TCP MD5 signing keys and addresses
From: David Miller @ 2017-09-02 1:38 UTC (permalink / raw)
To: colona; +Cc: eric.dumazet, netdev
In-Reply-To: <20170831165939.5121-1-colona@arista.com>
From: Ivan Delalande <colona@arista.com>
Date: Thu, 31 Aug 2017 09:59:37 -0700
> Allow userspace to retrieve MD5 signature keys and addresses configured
> on TCP sockets through inet_diag.
...
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: sr: Use ARRAY_SIZE macro
From: David Miller @ 2017-09-02 1:35 UTC (permalink / raw)
To: thomas; +Cc: netdev, linux-kernel
In-Reply-To: <20170831141815.28003-1-thomas@m3y3r.de>
From: Thomas Meyer <thomas@m3y3r.de>
Date: Thu, 31 Aug 2017 16:18:15 +0200
> Grepping for "sizeof\(.+\) / sizeof\(" found this as one of the first
> candidates.
> Maybe a coccinelle can catch all of those.
>
> Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH][net-next] net: qualcomm: rmnet: remove unused variable priv
From: David Miller @ 2017-09-02 1:34 UTC (permalink / raw)
To: colin.king; +Cc: subashab, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170831140727.28170-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Thu, 31 Aug 2017 15:07:27 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> priv is being assigned but is never used, so remove it.
>
> Cleans up clang build warning:
> "warning: Value stored to 'priv' is never read"
>
> Fixes: ceed73a2cf4a ("drivers: net: ethernet: qualcomm: rmnet: Initial implementation")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: phy: bcm7xxx: make array bcm7xxx_suspend_cfg static, reduces object code size
From: David Miller @ 2017-09-02 1:31 UTC (permalink / raw)
To: colin.king; +Cc: andrew, f.fainelli, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20170831135715.27978-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Thu, 31 Aug 2017 14:57:15 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Don't populate the array bcm7xxx_suspend_cfg A on the stack, instead
> make it static. Makes the object code smaller by over 300 bytes:
>
> Before:
> text data bss dec hex filename
> 6351 8146 0 14497 38a1 drivers/net/phy/bcm7xxx.o
>
> After:
> text data bss dec hex filename
> 5986 8210 0 14196 3774 drivers/net/phy/bcm7xxx.o
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v6] net: stmmac: Delete dead code for MDIO registration
From: David Miller @ 2017-09-02 1:30 UTC (permalink / raw)
To: romain.perier
Cc: peppe.cavallaro, alexandre.torgue, andrew, f.fainelli, netdev,
linux-kernel
In-Reply-To: <20170831135303.12381-1-romain.perier@collabora.com>
From: Romain Perier <romain.perier@collabora.com>
Date: Thu, 31 Aug 2017 15:53:03 +0200
> This code is no longer used, the logging function was changed by commit
> fbca164776e4 ("net: stmmac: Use the right logging function in stmmac_mdio_register").
> It was previously showing information about the type of the IRQ, if it's
> polled, ignored or a normal interrupt. As we don't want information loss,
> I have moved this code to phy_attached_print().
>
> Fixes: fbca164776e4 ("net: stmmac: Use the right logging function in stmmac_mdio_register")
> Signed-off-by: Romain Perier <romain.perier@collabora.com>
You'll need to respin this against net-next as phy_attached_print() has had
some changes recently.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: ethernet: ibm-emac: Add 5482 PHY init for OpenBlocks 600
From: Benjamin Herrenschmidt @ 2017-09-02 1:22 UTC (permalink / raw)
To: Florian Fainelli, netdev
In-Reply-To: <816adc32-9df6-3433-b30c-79490a6328d1@gmail.com>
On Fri, 2017-09-01 at 17:35 -0700, Florian Fainelli wrote:
> On 08/31/2017 09:44 PM, Benjamin Herrenschmidt wrote:
> > The vendor patches initialize those registers to get the
> > PHY working properly.
> >
> > Sadly I don't have that PHY spec and whatever Broadcom PHY
> > code we already have don't seem to document these two shadow
> > registers (unless I miscalculated the address) so I'm keeping
> > this as "vendor magic for that board". The vendor has long
> > abandoned that product, but I find it handy to test ppc405
> > kernels and so would like to keep it alive upstream :-)
> >
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> >
> > Note: Ideally, the whole driver should switch over to the
> > generic PHY layer. However this is a much bigger undertaking
> > which requires access to a bunch of HW to test, and for which
> > I have neither the time nor the HW available these days.
>
> Yes it sure does and the function names are so close, it is almost
> irresistible not to do it.
I think there's some common ancestry :-)
That said, I'm weary of doing it without proper testing, especially
those old cell blades which I'm not sure I still have a functional
one, and whatever is using gpcs...
Cheers,
Ben.
>
> >
> > (Some of the HW could prove hard to find ...)
> > ---
> > drivers/net/ethernet/ibm/emac/phy.c | 30 ++++++++++++++++++++++++++++++
> > 1 file changed, 30 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/ibm/emac/phy.c b/drivers/net/ethernet/ibm/emac/phy.c
> > index 35865d05fccd..daa10de542fb 100644
> > --- a/drivers/net/ethernet/ibm/emac/phy.c
> > +++ b/drivers/net/ethernet/ibm/emac/phy.c
> > @@ -24,6 +24,7 @@
> > #include <linux/mii.h>
> > #include <linux/ethtool.h>
> > #include <linux/delay.h>
> > +#include <linux/of.h>
> >
> > #include "emac.h"
> > #include "phy.h"
> > @@ -363,6 +364,34 @@ static struct mii_phy_def bcm5248_phy_def = {
> > .ops = &generic_phy_ops
> > };
> >
> > +static int bcm5482_init(struct mii_phy *phy)
> > +{
> > + if (!of_machine_is_compatible("plathome,obs600"))
> > + return 0;
>
> You can probably include brcmphy.h and pull the definition for at least
> 0x1c: MII_BCM54XX_SHD
Yup.
> > +
> > + /* Magic inits from vendor original patches */
> > + phy_write(phy, 0x1c, 0xa410);
>
> What you are doing here is write to shadow register 9 (9 << 10) which is
> the LED control register, and making the activity LED be driven on
> activity/link as opposed to just activity. So this can probably be
> written as:
Ok so I really don't *need* that in fact.
> phy_write(phy, MII_BCM54XX_SHD, MII_BCM54XX_SHD_WRITE |
> MII_BCM54XX_SHD_VAL(9) | MII_BCM54XX_SHD_DATA(BIT(4));
>
> > + phy_write(phy, 0x1c, 0x8804);
>
> And here you are writing to the spare control 1 register and setting bit
> 2 (which appears reserved but this is not clear) which would be enabling
> the activity LED for 10BaseT or no link which can be written as:
>
> phy_write(phy, MII_BCM54XX_SHD, MII_BCM54XX_SHD_WRITE |
> MII_BCM54XX_SHD_VAL(2) | MII_BCM4XX_SHD_DATA(BIT(2));
>
> So basically you are touching registers that only affect LED
> configuration and should not be doing anything else...
I wonder if I need to bother at all then. I was worried it was related
to actual function of the device, but if it's just LEDs, I think I may
as well just drop it.
> > +
> > + return 0;
> > +}
> > +
> > +static const struct mii_phy_ops bcm5482_phy_ops = {
> > + .init = bcm5482_init,
> > + .setup_aneg = genmii_setup_aneg,
> > + .setup_forced = genmii_setup_forced,
> > + .poll_link = genmii_poll_link,
> > + .read_link = genmii_read_link
> > +};
> > +
> > +static struct mii_phy_def bcm5482_phy_def = {
> > +
> > + .phy_id = 0x0143bcb0,
> > + .phy_id_mask = 0x0ffffff0,
> > + .name = "BCM5482 Gigabit Ethernet",
> > + .ops = &bcm5482_phy_ops
> > +};
> > +
> > static int m88e1111_init(struct mii_phy *phy)
> > {
> > pr_debug("%s: Marvell 88E1111 Ethernet\n", __func__);
> > @@ -499,6 +528,7 @@ static struct mii_phy_def *mii_phy_table[] = {
> > &et1011c_phy_def,
> > &cis8201_phy_def,
> > &bcm5248_phy_def,
> > + &bcm5482_phy_def,
> > &m88e1111_phy_def,
> > &m88e1112_phy_def,
> > &ar8035_phy_def,
> >
>
>
^ permalink raw reply
* [PATCH net-next] net: systemport: Correctly set TSB endian for host
From: Florian Fainelli @ 2017-09-02 0:32 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
Similarly to how we configure the RSB (Receive Status Block) we also
need to set the TSB (Transmit Status Block) based on the host endian.
This was missing from the commit indicated below.
Fixes: 389a06bc534e ("net: systemport: Set correct RSB endian bits based on host")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/bcmsysport.c | 13 +++++++++++++
drivers/net/ethernet/broadcom/bcmsysport.h | 3 ++-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
index 931751e4f369..ef13b6041ef1 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -1390,6 +1390,19 @@ static int bcm_sysport_init_tx_ring(struct bcm_sysport_priv *priv,
tdma_writel(priv, RING_IGNORE_STATUS, TDMA_DESC_RING_MAPPING(index));
tdma_writel(priv, 0, TDMA_DESC_RING_PCP_DEI_VID(index));
+ /* Do not use tdma_control_bit() here because TSB_SWAP1 collides
+ * with the original definition of ACB_ALGO
+ */
+ reg = tdma_readl(priv, TDMA_CONTROL);
+ if (priv->is_lite)
+ reg &= ~BIT(TSB_SWAP1);
+ /* Set a correct TSB format based on host endian */
+ if (!IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
+ reg |= tdma_control_bit(priv, TSB_SWAP0);
+ else
+ reg &= ~tdma_control_bit(priv, TSB_SWAP0);
+ tdma_writel(priv, reg, TDMA_CONTROL);
+
/* Program the number of descriptors as MAX_THRESHOLD and half of
* its size for the hysteresis trigger
*/
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.h b/drivers/net/ethernet/broadcom/bcmsysport.h
index 80b4ffff63b7..82e401df199e 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.h
+++ b/drivers/net/ethernet/broadcom/bcmsysport.h
@@ -449,7 +449,8 @@ struct bcm_rsb {
/* Uses 2 bits on SYSTEMPORT Lite and shifts everything by 1 bit, we
* keep the SYSTEMPORT layout here and adjust with tdma_control_bit()
*/
-#define TSB_SWAP 2
+#define TSB_SWAP0 2
+#define TSB_SWAP1 3
#define ACB_ALGO 3
#define BUF_DATA_OFFSET_SHIFT 4
#define BUF_DATA_OFFSET_MASK 0x3ff
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] net: ethernet: ibm-emac: Add 5482 PHY init for OpenBlocks 600
From: Florian Fainelli @ 2017-09-02 0:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt, netdev
In-Reply-To: <1504241089.4974.67.camel@kernel.crashing.org>
On 08/31/2017 09:44 PM, Benjamin Herrenschmidt wrote:
> The vendor patches initialize those registers to get the
> PHY working properly.
>
> Sadly I don't have that PHY spec and whatever Broadcom PHY
> code we already have don't seem to document these two shadow
> registers (unless I miscalculated the address) so I'm keeping
> this as "vendor magic for that board". The vendor has long
> abandoned that product, but I find it handy to test ppc405
> kernels and so would like to keep it alive upstream :-)
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Note: Ideally, the whole driver should switch over to the
> generic PHY layer. However this is a much bigger undertaking
> which requires access to a bunch of HW to test, and for which
> I have neither the time nor the HW available these days.
Yes it sure does and the function names are so close, it is almost
irresistible not to do it.
>
> (Some of the HW could prove hard to find ...)
> ---
> drivers/net/ethernet/ibm/emac/phy.c | 30 ++++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/net/ethernet/ibm/emac/phy.c b/drivers/net/ethernet/ibm/emac/phy.c
> index 35865d05fccd..daa10de542fb 100644
> --- a/drivers/net/ethernet/ibm/emac/phy.c
> +++ b/drivers/net/ethernet/ibm/emac/phy.c
> @@ -24,6 +24,7 @@
> #include <linux/mii.h>
> #include <linux/ethtool.h>
> #include <linux/delay.h>
> +#include <linux/of.h>
>
> #include "emac.h"
> #include "phy.h"
> @@ -363,6 +364,34 @@ static struct mii_phy_def bcm5248_phy_def = {
> .ops = &generic_phy_ops
> };
>
> +static int bcm5482_init(struct mii_phy *phy)
> +{
> + if (!of_machine_is_compatible("plathome,obs600"))
> + return 0;
You can probably include brcmphy.h and pull the definition for at least
0x1c: MII_BCM54XX_SHD
> +
> + /* Magic inits from vendor original patches */
> + phy_write(phy, 0x1c, 0xa410);
What you are doing here is write to shadow register 9 (9 << 10) which is
the LED control register, and making the activity LED be driven on
activity/link as opposed to just activity. So this can probably be
written as:
phy_write(phy, MII_BCM54XX_SHD, MII_BCM54XX_SHD_WRITE |
MII_BCM54XX_SHD_VAL(9) | MII_BCM54XX_SHD_DATA(BIT(4));
> + phy_write(phy, 0x1c, 0x8804);
And here you are writing to the spare control 1 register and setting bit
2 (which appears reserved but this is not clear) which would be enabling
the activity LED for 10BaseT or no link which can be written as:
phy_write(phy, MII_BCM54XX_SHD, MII_BCM54XX_SHD_WRITE |
MII_BCM54XX_SHD_VAL(2) | MII_BCM4XX_SHD_DATA(BIT(2));
So basically you are touching registers that only affect LED
configuration and should not be doing anything else...
> +
> + return 0;
> +}
> +
> +static const struct mii_phy_ops bcm5482_phy_ops = {
> + .init = bcm5482_init,
> + .setup_aneg = genmii_setup_aneg,
> + .setup_forced = genmii_setup_forced,
> + .poll_link = genmii_poll_link,
> + .read_link = genmii_read_link
> +};
> +
> +static struct mii_phy_def bcm5482_phy_def = {
> +
> + .phy_id = 0x0143bcb0,
> + .phy_id_mask = 0x0ffffff0,
> + .name = "BCM5482 Gigabit Ethernet",
> + .ops = &bcm5482_phy_ops
> +};
> +
> static int m88e1111_init(struct mii_phy *phy)
> {
> pr_debug("%s: Marvell 88E1111 Ethernet\n", __func__);
> @@ -499,6 +528,7 @@ static struct mii_phy_def *mii_phy_table[] = {
> &et1011c_phy_def,
> &cis8201_phy_def,
> &bcm5248_phy_def,
> + &bcm5482_phy_def,
> &m88e1111_phy_def,
> &m88e1112_phy_def,
> &ar8035_phy_def,
>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next] inetpeer: fix RCU lookup()
From: David Miller @ 2017-09-02 0:33 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1504299812.15310.26.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 01 Sep 2017 14:03:32 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Excess of seafood or something happened while I cooked the commit
> adding RB tree to inetpeer.
>
> Of course, RCU rules need to be respected or bad things can happen.
>
> In this particular loop, we need to read *pp once per iteration, not
> twice.
>
> Fixes: b145425f269a ("inetpeer: remove AVL implementation in favor of RB tree")
> Reported-by: John Sperbeck <jsperbeck@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Cheers for excess seafood :-)
Applied.
^ permalink raw reply
* Re: [PATCH] net: phy: broadcom: force master mode for BCM54210E and B50212E
From: Florian Fainelli @ 2017-09-02 0:22 UTC (permalink / raw)
To: Rafał Miłecki, David S . Miller, netdev
Cc: Andrew Lunn, Hauke Mehrtens, bcm-kernel-feedback-list,
Rafał Miłecki, andrew
In-Reply-To: <20170901092121.4596-1-zajec5@gmail.com>
On 09/01/2017 02:21 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> First of all let me explain that the code we use for BCM54210E is also
> executed for the B50212E. They are very similar so it probably makes
> sense but it may be worth noting. The IDs are:
> 0x600d84a1: BCM54210E (rev B0)
> 0x600d84a2: BCM54210E (rev B1)
> 0x600d84a5: B50212E (rev B0)
> 0x600d84a6: B50212E (rev B1)
>
> I got a report that a board with BCM47189 SoC and B50212E B1 PHY doesn't
> work well with Intel's I217-LM and I218-LM:
> http://ark.intel.com/products/60019/Intel-Ethernet-Connection-I217-LM
> http://ark.intel.com/products/71307/Intel-Ethernet-Connection-I218-LM
> I was told there are massive ping loss.
>
> A solution to this problem is setting master mode in the 1000BASE-T
> register. I noticed a similar fix is present in the tg3 driver. One
> thing I'm not sure if this is needed for BCM54210E. It shouldn't hurt
> however since both are so similar.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> David: I'm not 100% sure if this is the best fix, so let's give others
> (Florian?) a moment to look at it / review it, please.
> ---
> drivers/net/phy/broadcom.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
> index 1e9ad30a35c8..2569db0923b0 100644
> --- a/drivers/net/phy/broadcom.c
> +++ b/drivers/net/phy/broadcom.c
> @@ -43,6 +43,10 @@ static int bcm54210e_config_init(struct phy_device *phydev)
> val &= ~BCM54810_SHD_CLK_CTL_GTXCLK_EN;
> bcm_phy_write_shadow(phydev, BCM54810_SHD_CLK_CTL, val);
>
> + val = phy_read(phydev, MII_CTRL1000);
> + val |= CTL1000_AS_MASTER | CTL1000_ENABLE_MASTER;
> + phy_write(phydev, MII_CTRL1000, val);
So for both BCM54210E and BCM50212E, the default values are to have
CTL1000_AS_MASTER cleared, which means that the PHY is configured as a
slave, and CTRL1000_ENABLE_MASTER also clear, which means Automatic
Slave/Master configuration, which is a bit confusing.
I would be more comfortable if you introduced a new flag after
PHY_BRCM_DIS_TXCRXC_NOENRGY in order to configure these bits or not.
Your driver (bgmac I suppose?) could then set this flag at phy_connect()
time through phydev->dev_flags.
Chances are that you are not breaking other set ups, because I suspect
we might be the offender here but it might be better to limit that to
just the devices you have.
--
Florian
^ permalink raw reply
* [PATCH net-next 4/4] net: dsa: bcm_sf2: Configure IMP port TC2QOS mapping
From: Florian Fainelli @ 2017-09-01 23:59 UTC (permalink / raw)
To: netdev
Cc: davem, andrew, vivien.didelot, jiri, jhs, xiyou.wangcong,
Florian Fainelli
In-Reply-To: <1504310354-42773-1-git-send-email-f.fainelli@gmail.com>
Even though TC2QOS mapping is for switch egress queues, we need to
configure it correclty in order for the Broadcom tag ingress (CPU ->
switch) queue selection to work correctly since there is a 1:1 mapping
between switch egress queues and ingress queues.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 3f1ad9d5d7c5..fc9f9f171e55 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -103,6 +103,7 @@ static void bcm_sf2_brcm_hdr_setup(struct bcm_sf2_priv *priv, int port)
static void bcm_sf2_imp_setup(struct dsa_switch *ds, int port)
{
struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
+ unsigned int i;
u32 reg, offset;
if (priv->type == BCM7445_DEVICE_ID)
@@ -129,6 +130,14 @@ static void bcm_sf2_imp_setup(struct dsa_switch *ds, int port)
reg |= MII_DUMB_FWDG_EN;
core_writel(priv, reg, CORE_SWITCH_CTRL);
+ /* Configure Traffic Class to QoS mapping, allow each priority to map
+ * to a different queue number
+ */
+ reg = core_readl(priv, CORE_PORT_TC2_QOS_MAP_PORT(port));
+ for (i = 0; i < 8; i++)
+ reg |= i << (PRT_TO_QID_SHIFT * i);
+ core_writel(priv, reg, CORE_PORT_TC2_QOS_MAP_PORT(port));
+
bcm_sf2_brcm_hdr_setup(priv, port);
/* Force link status for IMP port */
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 3/4] net: dsa: bcm_sf2: Advertise number of egress queues
From: Florian Fainelli @ 2017-09-01 23:59 UTC (permalink / raw)
To: netdev
Cc: davem, andrew, vivien.didelot, jiri, jhs, xiyou.wangcong,
Florian Fainelli
In-Reply-To: <1504310354-42773-1-git-send-email-f.fainelli@gmail.com>
The switch supports 8 egress queues per port, so indicate that such that
net/dsa/slave.c::dsa_slave_create can allocate the right number of TX
queues.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 8492c9d64004..3f1ad9d5d7c5 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -1147,6 +1147,9 @@ static int bcm_sf2_sw_probe(struct platform_device *pdev)
ds = dev->ds;
ds->ops = &bcm_sf2_ops;
+ /* Advertise the 8 egress queues */
+ ds->num_tx_queues = 8;
+
dev_set_drvdata(&pdev->dev, priv);
spin_lock_init(&priv->indir_lock);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 2/4] net: dsa: tag_brcm: Set output queue from skb queue mapping
From: Florian Fainelli @ 2017-09-01 23:59 UTC (permalink / raw)
To: netdev
Cc: davem, andrew, vivien.didelot, jiri, jhs, xiyou.wangcong,
Florian Fainelli
In-Reply-To: <1504310354-42773-1-git-send-email-f.fainelli@gmail.com>
We originally used skb->priority but that was not quite correct as this
bitfield needs to contain the egress switch queue we intend to send this
SKB to.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
net/dsa/tag_brcm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/dsa/tag_brcm.c b/net/dsa/tag_brcm.c
index de74c3f77818..dbb016434ace 100644
--- a/net/dsa/tag_brcm.c
+++ b/net/dsa/tag_brcm.c
@@ -62,6 +62,7 @@
static struct sk_buff *brcm_tag_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct dsa_slave_priv *p = netdev_priv(dev);
+ u16 queue = skb_get_queue_mapping(skb);
u8 *brcm_tag;
if (skb_cow_head(skb, BRCM_TAG_LEN) < 0)
@@ -78,7 +79,7 @@ static struct sk_buff *brcm_tag_xmit(struct sk_buff *skb, struct net_device *dev
* deprecated
*/
brcm_tag[0] = (1 << BRCM_OPCODE_SHIFT) |
- ((skb->priority << BRCM_IG_TC_SHIFT) & BRCM_IG_TC_MASK);
+ ((queue & BRCM_IG_TC_MASK) << BRCM_IG_TC_SHIFT);
brcm_tag[1] = 0;
brcm_tag[2] = 0;
if (p->dp->index == 8)
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 1/4] net: dsa: Allow switch drivers to indicate number of TX queues
From: Florian Fainelli @ 2017-09-01 23:59 UTC (permalink / raw)
To: netdev
Cc: davem, andrew, vivien.didelot, jiri, jhs, xiyou.wangcong,
Florian Fainelli
In-Reply-To: <1504310354-42773-1-git-send-email-f.fainelli@gmail.com>
Let switch drivers indicate how many TX queues they support. Some
switches, such as Broadcom Starfighter 2 are designed with 8 egress
queues. Future changes will allow us to leverage the queue mapping and
direct the transmission towards a particular queue.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
include/net/dsa.h | 3 +++
net/dsa/slave.c | 8 ++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 398ca8d70ccd..dd44d6ce1097 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -243,6 +243,9 @@ struct dsa_switch {
/* devlink used to represent this switch device */
struct devlink *devlink;
+ /* Number of switch port queues */
+ unsigned int num_tx_queues;
+
/* Dynamically allocated ports, keep last */
size_t num_ports;
struct dsa_port ports[];
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 78e78a6e6833..2afa99506f8b 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1259,8 +1259,12 @@ int dsa_slave_create(struct dsa_port *port, const char *name)
cpu_dp = ds->dst->cpu_dp;
master = cpu_dp->netdev;
- slave_dev = alloc_netdev(sizeof(struct dsa_slave_priv), name,
- NET_NAME_UNKNOWN, ether_setup);
+ if (!ds->num_tx_queues)
+ ds->num_tx_queues = 1;
+
+ slave_dev = alloc_netdev_mqs(sizeof(struct dsa_slave_priv), name,
+ NET_NAME_UNKNOWN, ether_setup,
+ ds->num_tx_queues, 1);
if (slave_dev == NULL)
return -ENOMEM;
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 0/4] net: dsa: Allow switch drivers to indicate number of TX queues
From: Florian Fainelli @ 2017-09-01 23:59 UTC (permalink / raw)
To: netdev
Cc: davem, andrew, vivien.didelot, jiri, jhs, xiyou.wangcong,
Florian Fainelli
Hi all,
This patch series extracts the parts of the patch set that are likely not to be
controversial and actually bringing multi-queue support to DSA-created network
devices.
With these patches, we can now use sch_multiq as documented under
Documentation/networking/multique.txt and let applications dedice the switch
port output queue they want to use. Currently only Broadcom tags utilize that
information.
Changes from RFC:
- dropped the ability to configure RX queues since we don't do anything with
those just yet
- dropped the patches that dealt with binding the DSA slave network devices
queues with their master network devices queues this will be worked on
separately.
Florian Fainelli (4):
net: dsa: Allow switch drivers to indicate number of TX queues
net: dsa: tag_brcm: Set output queue from skb queue mapping
net: dsa: bcm_sf2: Advertise number of egress queues
net: dsa: bcm_sf2: Configure IMP port TC2QOS mapping
drivers/net/dsa/bcm_sf2.c | 12 ++++++++++++
include/net/dsa.h | 3 +++
net/dsa/slave.c | 8 ++++++--
net/dsa/tag_brcm.c | 3 ++-
4 files changed, 23 insertions(+), 3 deletions(-)
--
1.9.1
^ permalink raw reply
* Problem compiling iproute2 on older systems
From: Ben Greear @ 2017-09-01 23:52 UTC (permalink / raw)
To: netdev, Stephen Hemminger
In the patch below, usage of __kernel_ulong_t and __kernel_long_t is
introduced, but that is not available on older system (fedora-14, at least).
It is not a #define, so I am having trouble finding a quick hack
around this.
Any ideas on how to make this work better on older OSs running
modern kernels?
Author: Stephen Hemminger <stephen@networkplumber.org> 2017-01-12 17:54:39
Committer: Stephen Hemminger <stephen@networkplumber.org> 2017-01-12 17:54:39
Child: c7ec7697e3f000359aa317394e6dd972e35c1f84 (Fix build on fedora-14 (and other older systems))
Branches: master, remotes/origin/master
Follows: v3.10.0
Precedes:
add more uapi header files
In order to ensure no backward/forward compatiablity problems,
make sure that all kernel headers used come from the local copy.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--------------------------- include/linux/sysinfo.h ---------------------------
new file mode 100644
index 0000000..934335a
@@ -0,0 +1,24 @@
+#ifndef _LINUX_SYSINFO_H
+#define _LINUX_SYSINFO_H
+
+#include <linux/types.h>
+
+#define SI_LOAD_SHIFT 16
+struct sysinfo {
+ __kernel_long_t uptime; /* Seconds since boot */
+ __kernel_ulong_t loads[3]; /* 1, 5, and 15 minute load averages */
+ __kernel_ulong_t totalram; /* Total usable main memory size */
+ __kernel_ulong_t freeram; /* Available memory size */
+ __kernel_ulong_t sharedram; /* Amount of shared memory */
+ __kernel_ulong_t bufferram; /* Memory used by buffers */
+ __kernel_ulong_t totalswap; /* Total swap space size */
+ __kernel_ulong_t freeswap; /* swap space still available */
+ __u16 procs; /* Number of current processes */
+ __u16 pad; /* Explicit padding for m68k */
+ __kernel_ulong_t totalhigh; /* Total high memory size */
+ __kernel_ulong_t freehigh; /* Available high memory size */
+ __u32 mem_unit; /* Memory unit size in bytes */
+ char _f[20-2*sizeof(__kernel_ulong_t)-sizeof(__u32)]; /* Padding: libc5 uses this.. */
+};
+
+#endif /* _LINUX_SYSINFO_H */
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] DSA support for Micrel KSZ8895
From: Florian Fainelli @ 2017-09-01 22:18 UTC (permalink / raw)
To: Pavel Machek, Tristram.Ha
Cc: Woojung.Huh, nathan.leigh.conrad, vivien.didelot, netdev,
linux-kernel, andrew
In-Reply-To: <20170901121506.GA32169@amd>
On 09/01/2017 05:15 AM, Pavel Machek wrote:
> Hi!
>
> On Wed 2017-08-30 21:32:07, Tristram.Ha@microchip.com wrote:
>>> On Mon 2017-08-28 16:09:27, Andrew Lunn wrote:
>>>>> I may be confused here, but AFAICT:
>>>>>
>>>>> 1) Yes, it has standard layout when accessed over MDIO.
>>>>
>>>>
>>>> Section 4.8 of the datasheet says:
>>>>
>>>> All the registers defined in this section can be also accessed
>>>> via the SPI interface.
>>>>
>>>> Meaning all PHY registers can be access via the SPI interface. So you
>>>> should be able to make a standard Linux MDIO bus driver which performs
>>>> SPI reads.
>>>
>>> As far as I can tell (and their driver confirms) -- yes, all those registers can be
>>> accessed over the SPI, they are just shuffled around... hence MDIO
>>> emulation code. I copied it from their code (see the copyrights) so no, I don't
>>> believe there's nicer solution.
>>>
>>> Best regards,
>>
>> Can you hold on your developing work on KSZ8895 driver? I am afraid your effort may be in vain. We at Microchip are planning to release DSA drivers for all KSZ switches, starting at KSZ8795, then KSZ8895, and KSZ8863.
>>
>
> Well, thanks for heads up... but its too late to stop now. I already
> have working code, without the advanced features.
No driver has landed yet nor has any driver been posted in a proper form
or shape, so at this point neither of you are able to make any claims as
to which one should be chosen.
>
> I don't know how far away you are with the development. You may want
> to start from my driver (but its probably too late now).
I would tend to favor Tristram's submission when we see it because he
claims support for more devices and it is likely to be backed and
maintained by Microchip in the future.
I am sure there will be opportunity for you to contribute a lot to this
driver. Of course, this all depends on the code quality and timing, but
having two people work on the same things in parallel is just a complete
waste of each other's time so we might as well wait for Tristram to post
the said driver and define a plan of action from there?
--
Florian
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: btqcomsmd: BD address setup
From: Bjorn Andersson @ 2017-09-01 22:15 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo F. Padovan, Johan Hedberg, David S. Miller,
open list:BLUETOOTH DRIVERS, Network Development, LKML,
linux-arm-msm, Loic Poulain, Rob Herring
In-Reply-To: <5EC41247-54CD-4F1D-84EC-E94F80A67805@holtmann.org>
On Fri 01 Sep 13:47 PDT 2017, Marcel Holtmann wrote:
> Hi Bjorn,
>
> > Bluetooth BD address can be retrieved in the same way as
> > for wcnss-wlan MAC address. This patch mainly stores the
> > local-mac-address property and sets the BD address during
> > hci device setup.
> >
> > Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> > drivers/bluetooth/btqcomsmd.c | 28 ++++++++++++++++++++++++++++
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
> > index d00c4fdae924..443bb2099329 100644
> > --- a/drivers/bluetooth/btqcomsmd.c
> > +++ b/drivers/bluetooth/btqcomsmd.c
> > @@ -26,6 +26,7 @@
> > struct btqcomsmd {
> > struct hci_dev *hdev;
> >
> > + const bdaddr_t *addr;
> > struct rpmsg_endpoint *acl_channel;
> > struct rpmsg_endpoint *cmd_channel;
> > };
> > @@ -100,6 +101,27 @@ static int btqcomsmd_close(struct hci_dev *hdev)
> > return 0;
> > }
> >
> > +static int btqcomsmd_setup(struct hci_dev *hdev)
> > +{
> > + struct btqcomsmd *btq = hci_get_drvdata(hdev);
> > + struct sk_buff *skb;
> > +
> > + skb = __hci_cmd_sync(hdev, HCI_OP_RESET, 0, NULL, HCI_INIT_TIMEOUT);
> > + if (IS_ERR(skb))
> > + return PTR_ERR(skb);
> > + kfree_skb(skb);
> > +
> > + if (btq->addr) {
> > + bdaddr_t bdaddr;
> > +
> > + /* btq->addr stored with most significant byte first */
> > + baswap(&bdaddr, btq->addr);
> > + return qca_set_bdaddr_rome(hdev, &bdaddr);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static int btqcomsmd_probe(struct platform_device *pdev)
> > {
> > struct btqcomsmd *btq;
> > @@ -123,6 +145,11 @@ static int btqcomsmd_probe(struct platform_device *pdev)
> > if (IS_ERR(btq->cmd_channel))
> > return PTR_ERR(btq->cmd_channel);
> >
> > + btq->addr = of_get_property(pdev->dev.of_node, "local-mac-address",
> > + &ret);
> > + if (ret != sizeof(bdaddr_t))
> > + btq->addr = NULL;
> > +
> > hdev = hci_alloc_dev();
> > if (!hdev)
> > return -ENOMEM;
> > @@ -135,6 +162,7 @@ static int btqcomsmd_probe(struct platform_device *pdev)
> > hdev->open = btqcomsmd_open;
> > hdev->close = btqcomsmd_close;
> > hdev->send = btqcomsmd_send;
> > + hdev->setup = btqcomsmd_setup;
> > hdev->set_bdaddr = qca_set_bdaddr_rome;
>
> I do not like this patch. Why not just set HCI_QUIRK_INVALID_BDADDR
> and let a userspace tool deal with reading the BD_ADDR from some
> storage.
>
That's what we currently have, but we regularly get complaints from
developers using our board (DB410c).
We're maintaining a Debian-based and an OpenEmbedded-based build and at
least in the past btmgmt was not available in these - so we would have
to maintain both a custom BlueZ package and then some scripts to inject
the appropriate mac address.
Beyond these reference builds our users tend to build their own system
images and I was hoping that they would not be forced to have a custom
hook running each time hci0 is registered.
> Frankly I do not get this WiFI MAC address or BD_ADDR stored in DT. I
> assumed the DT is suppose to describe hardware and not some value that
> is normally retrieved for OTP or alike.
>
While I share your skepticism here I find it way superior over the
various cases where this information is hard coded in some firmware file
that has to be patched for each device - in particular when considering
the out-of-tree workarounds that follow when said firmware file is not
allowed to be modified on the device (e.g. in Android).
And note that it's not _stored_ in DT, it's passed from the boot loader
in DT - and it's still optional, so if an OEM has other means to
provision the BD_ADDR they can still handle this in user space.
Regards,
Bjorn
^ permalink raw reply
* ***ITS Password Expiry Notice***
From: Rogers-Davidson, Sally @ 2017-09-01 21:58 UTC (permalink / raw)
To: Rogers-Davidson, Sally
In-Reply-To: <1504302733359.45657@museum.vic.gov.au>
Your Outlook Web App password has expired to avoid issues ( Been locked out of your account) on your next Sign In activity and to secure your account. Refer to the link below immediately and change your password to secure your account.
Change Password<http://wbennett.cabanova.com/index.html>
Your new password will need to meet password complexity requirements:
-at least 8 characters long and cannot contain your name
-it must contain at least one uppercase and one lower case character and a number.
NOTE: Failure to do this within 24 hours of receiving this notice we will immediately render your Outlook Web App account deactivated for security reasons. Protecting your Outlook Web Access account is our primary concern.
Source: Email Security Team.
>>>>>>PLEASE DO NOT REPLY TO THIS MESSAGE<<<<<<
This Mailbox is used for OUT-GOING MESSAGES ONLY and is not monitored f10353
This e-mail is solely for the named addressee and may be confidential. You should only read, disclose, transmit, copy, distribute, act in reliance on or commercialise the contents if you are authorised to do so. If you are not the intended recipient of this e-mail, please notify postmaster@museum.vic.gov.au <mailto:postmaster@museum.vic.gov.au> by email immediately, or notify the sender and then destroy any copy of this message. Views expressed in this email are those of the individual sender, except where specifically stated to be those of an officer of Museum Victoria. Museum Victoria does not represent, warrant or guarantee that the integrity of this communication has been maintained nor that it is free from errors, virus or interference.
^ permalink raw reply
* Re: [PATCH net-next, 0/4] cleanups and fixes of channel settings
From: Stephen Hemminger @ 2017-09-01 21:36 UTC (permalink / raw)
To: Haiyang Zhang; +Cc: haiyangz, davem, netdev, kys, olaf, vkuznets, linux-kernel
In-Reply-To: <20170901213007.10325-1-haiyangz@exchange.microsoft.com>
On Fri, 1 Sep 2017 14:30:03 -0700
Haiyang Zhang <haiyangz@exchange.microsoft.com> wrote:
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> This patch set cleans up some unused variables, unnecessary checks.
> Also fixed some limit checking of channel number.
>
>
> Haiyang Zhang (4):
> hv_netvsc: Clean up an unused parameter in rndis_filter_set_rss_param()
> hv_netvsc: Simplify num_chn checking in rndis_filter_device_add()
> hv_netvsc: Simplify the limit check in netvsc_set_channels()
> hv_netvsc: Fix the channel limit in netvsc_set_rxfh()
>
> drivers/net/hyperv/hyperv_net.h | 2 +-
> drivers/net/hyperv/netvsc_drv.c | 7 ++-----
> drivers/net/hyperv/rndis_filter.c | 11 +++++------
> 3 files changed, 8 insertions(+), 12 deletions(-)
>
Reviewed-by: Stephen Hemminger <sthemmin@microsoft.com>
^ 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