* [PATCH v4 0/2] net/ibmvnic: serialization fixes
From: Juliet Kim @ 2019-09-20 20:11 UTC (permalink / raw)
To: netdev; +Cc: julietk, tlfalcon, linuxppc-dev
This series includes two fixes. The first improves reset code to allow
linkwatch_event to proceed during reset. The second ensures that no more
than one thread runs in reset at a time.
v2:
- Separate change param reset from do_reset()
- Return IBMVNIC_OPEN_FAILED if __ibmvnic_open fails
- Remove setting wait_for_reset to false from __ibmvnic_reset(), this
is done in wait_for_reset()
- Move the check for force_reset_recovery from patch 1 to patch 2
v3:
- Restore reset’s successful return in open failure case
v4:
- Change resetting flag access to atomic
Juliet Kim (2):
net/ibmvnic: unlock rtnl_lock in reset so linkwatch_event can run
net/ibmvnic: prevent more than one thread from running in reset
drivers/net/ethernet/ibm/ibmvnic.c | 262 ++++++++++++++++++++++++++-----------
drivers/net/ethernet/ibm/ibmvnic.h | 6 +-
2 files changed, 190 insertions(+), 78 deletions(-)
--
2.16.4
^ permalink raw reply
* Re: [PATCH net-next] tuntap: Fallback to automq on TUNSETSTEERINGEBPF prog negative return
From: Matt Cover @ 2019-09-20 19:45 UTC (permalink / raw)
To: davem, ast, daniel, kafai, songliubraving, yhs, Jason Wang,
Eric Dumazet, Stanislav Fomichev, mst, Matthew Cover, mail,
pabeni, Nicolas Dichtel, wangli39, lifei.shirley, tglx, netdev,
linux-kernel, bpf
In-Reply-To: <20190920185843.4096-1-matthew.cover@stackpath.com>
On Fri, Sep 20, 2019 at 11:59 AM Matthew Cover <werekraken@gmail.com> wrote:
>
> Treat a negative return from a TUNSETSTEERINGEBPF bpf prog as a signal
> to fallback to tun_automq_select_queue() for tx queue selection.
>
> Compilation of this exact patch was tested.
>
> For functional testing 3 additional printk()s were added.
>
> Functional testing results (on 2 txq tap device):
>
> [Fri Sep 20 18:33:27 2019] ========== tun no prog ==========
> [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '-1'
> [Fri Sep 20 18:33:27 2019] tuntap: tun_automq_select_queue() ran
> [Fri Sep 20 18:33:27 2019] ========== tun prog -1 ==========
> [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '-1'
> [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '-1'
> [Fri Sep 20 18:33:27 2019] tuntap: tun_automq_select_queue() ran
> [Fri Sep 20 18:33:27 2019] ========== tun prog 0 ==========
> [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '0'
> [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '0'
> [Fri Sep 20 18:33:27 2019] ========== tun prog 1 ==========
> [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '1'
> [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '1'
> [Fri Sep 20 18:33:27 2019] ========== tun prog 2 ==========
> [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '2'
> [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '0'
>
> Signed-off-by: Matthew Cover <matthew.cover@stackpath.com>
> ---
> drivers/net/tun.c | 20 +++++++++++---------
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index aab0be4..173d159 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -583,35 +583,37 @@ static u16 tun_automq_select_queue(struct tun_struct *tun, struct sk_buff *skb)
> return txq;
> }
>
> -static u16 tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff *skb)
> +static int tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff *skb)
> {
> struct tun_prog *prog;
> u32 numqueues;
> - u16 ret = 0;
> + int ret = -1;
>
> numqueues = READ_ONCE(tun->numqueues);
> if (!numqueues)
> return 0;
>
> + rcu_read_lock();
> prog = rcu_dereference(tun->steering_prog);
> if (prog)
> ret = bpf_prog_run_clear_cb(prog->prog, skb);
> + rcu_read_unlock();
>
> - return ret % numqueues;
> + if (ret >= 0)
> + ret %= numqueues;
> +
> + return ret;
> }
>
> static u16 tun_select_queue(struct net_device *dev, struct sk_buff *skb,
> struct net_device *sb_dev)
> {
> struct tun_struct *tun = netdev_priv(dev);
> - u16 ret;
> + int ret;
>
> - rcu_read_lock();
> - if (rcu_dereference(tun->steering_prog))
> - ret = tun_ebpf_select_queue(tun, skb);
> - else
> + ret = tun_ebpf_select_queue(tun, skb);
> + if (ret < 0)
> ret = tun_automq_select_queue(tun, skb);
> - rcu_read_unlock();
>
> return ret;
> }
> --
> 1.8.3.1
>
Sorry for sending this while net-next is closed... I
should have been more careful.
Please let me know if I should resubmit once net-next
is open again.
^ permalink raw reply
* [PATCH] ieee802154: mcr20a: simplify a bit 'mcr20a_handle_rx_read_buf_complete()'
From: Christophe JAILLET @ 2019-09-20 19:45 UTC (permalink / raw)
To: liuxuenetmail, alex.aring, stefan, davem
Cc: linux-wpan, netdev, linux-kernel, kernel-janitors,
Christophe JAILLET
Use a 'skb_put_data()' variant instead of rewritting it.
The __skb_put_data variant is safe here. It is obvious that the skb can
not overflow. It has just been allocated a few lines above with the same
'len'.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/net/ieee802154/mcr20a.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
index 17f2300e63ee..8dc04e2590b1 100644
--- a/drivers/net/ieee802154/mcr20a.c
+++ b/drivers/net/ieee802154/mcr20a.c
@@ -800,7 +800,7 @@ mcr20a_handle_rx_read_buf_complete(void *context)
if (!skb)
return;
- memcpy(skb_put(skb, len), lp->rx_buf, len);
+ __skb_put_data(skb, lp->rx_buf, len);
ieee802154_rx_irqsafe(lp->hw, skb, lp->rx_lqi[0]);
print_hex_dump_debug("mcr20a rx: ", DUMP_PREFIX_OFFSET, 16, 1,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2] ethernet: lantiq_xrx200: Use devm_platform_ioremap_resource() in xrx200_probe()
From: Hauke Mehrtens @ 2019-09-20 19:23 UTC (permalink / raw)
To: Markus Elfring, netdev, David S. Miller, Radhey Shyam Pandey
Cc: LKML, kernel-janitors
In-Reply-To: <43bed158-2af9-c518-2f97-a473c2b84eb7@web.de>
[-- Attachment #1.1: Type: text/plain, Size: 2328 bytes --]
On 9/20/19 12:57 PM, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 20 Sep 2019 11:48:33 +0200
>
> Simplify this function implementation by using the wrapper function
> “devm_platform_ioremap_resource” instead of calling the functions
> “platform_get_resource” and “devm_ioremap_resource” directly.
>
> * Thus reduce also a bit of exception handling code here.
> * Delete the local variable “res”.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
But this can also wait till kernel 5.5.
> ---
>
> v2:
> Further changes were requested by Radhey Shyam Pandey.
>
> https://lore.kernel.org/r/CH2PR02MB700047AFFFE08FE5FD563541C78E0@CH2PR02MB7000.namprd02.prod.outlook.com/
>
>
>
> * Updates for three modules were split into a separate patch for each driver.
>
> * The commit description was adjusted.
>
>
>
>
>
> drivers/net/ethernet/lantiq_xrx200.c | 11 +----------
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/lantiq_xrx200.c b/drivers/net/ethernet/lantiq_xrx200.c
> index 900affbdcc0e..0a7ea45b9e59 100644
> --- a/drivers/net/ethernet/lantiq_xrx200.c
> +++ b/drivers/net/ethernet/lantiq_xrx200.c
> @@ -424,7 +424,6 @@ static int xrx200_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> struct device_node *np = dev->of_node;
> - struct resource *res;
> struct xrx200_priv *priv;
> struct net_device *net_dev;
> const u8 *mac;
> @@ -443,15 +442,7 @@ static int xrx200_probe(struct platform_device *pdev)
> SET_NETDEV_DEV(net_dev, dev);
> net_dev->min_mtu = ETH_ZLEN;
> net_dev->max_mtu = XRX200_DMA_DATA_LEN;
> -
> - /* load the memory ranges */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(dev, "failed to get resources\n");
> - return -ENOENT;
> - }
> -
> - priv->pmac_reg = devm_ioremap_resource(dev, res);
> + priv->pmac_reg = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(priv->pmac_reg)) {
> dev_err(dev, "failed to request and remap io ranges\n");
> return PTR_ERR(priv->pmac_reg);
> --
> 2.23.0
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH bpf] libbpf: fix version identification on busybox
From: Ivan Khoronzhuk @ 2019-09-20 19:19 UTC (permalink / raw)
To: Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann, Martin Lau,
Andrii Nakryiko, Yonghong Song, Networking, bpf, open list
In-Reply-To: <20190920183449.GA2760@khorivan>
On Fri, Sep 20, 2019 at 09:34:51PM +0300, Ivan Khoronzhuk wrote:
>On Fri, Sep 20, 2019 at 09:41:54AM -0700, Andrii Nakryiko wrote:
>>On Fri, Sep 20, 2019 at 1:22 AM Ivan Khoronzhuk
>><ivan.khoronzhuk@linaro.org> wrote:
>>>
>>>On Thu, Sep 19, 2019 at 01:02:40PM -0700, Andrii Nakryiko wrote:
>>>>On Thu, Sep 19, 2019 at 11:22 AM Ivan Khoronzhuk
>>>><ivan.khoronzhuk@linaro.org> wrote:
>>>>>
>>>>> It's very often for embedded to have stripped version of sort in
>>>>> busybox, when no -V option present. It breaks build natively on target
>>>>> board causing recursive loop.
>>>>>
>>>>> BusyBox v1.24.1 (2019-04-06 04:09:16 UTC) multi-call binary. \
>>>>> Usage: sort [-nrugMcszbdfimSTokt] [-o FILE] [-k \
>>>>> start[.offset][opts][,end[.offset][opts]] [-t CHAR] [FILE]...
>>>>>
>>>>> Lets modify command a little to avoid -V option.
>>>>>
>>>>> Fixes: dadb81d0afe732 ("libbpf: make libbpf.map source of truth for libbpf version")
>>>>>
>>>>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>>>>> ---
>>>>>
>>>>> Based on bpf/master
>>>>>
>>>>> tools/lib/bpf/Makefile | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
>>>>> index c6f94cffe06e..a12490ad6215 100644
>>>>> --- a/tools/lib/bpf/Makefile
>>>>> +++ b/tools/lib/bpf/Makefile
>>>>> @@ -3,7 +3,7 @@
>>>>>
>>>>> LIBBPF_VERSION := $(shell \
>>>>> grep -oE '^LIBBPF_([0-9.]+)' libbpf.map | \
>>>>> - sort -rV | head -n1 | cut -d'_' -f2)
>>>>> + cut -d'_' -f2 | sort -r | head -n1)
>>>>
>>>>You can't just sort alphabetically, because:
>>>>
>>>>1.2
>>>>1.11
>>>>
>>>>should be in that order. See discussion on mailing thread for original commit.
>>>
>>>if X1.X2.X3, where X = {0,1,....99999}
>>>Then it can be:
>>>
>>>-LIBBPF_VERSION := $(shell \
>>>- grep -oE '^LIBBPF_([0-9.]+)' libbpf.map | \
>>>- sort -rV | head -n1 | cut -d'_' -f2)
>>>+_LBPFLIST := $(patsubst %;,%,$(patsubst LIBBPF_%,%,$(filter LIBBPF_%, \
>>>+ $(shell cat libbpf.map))))
>>>+_LBPFLIST2 := $(foreach v,$(_LBPFLIST), \
>>>+ $(subst $() $(),,$(foreach n,$(subst .,$() $(),$(v)), \
>>>+ $(shell printf "%05d" $(n)))))
>>>+_LBPF_VER := $(word $(words $(sort $(_LBPFLIST2))), $(sort $(_LBPFLIST2)))
>>>+LIBBPF_VERSION := $(patsubst %_$(_LBPF_VER),%,$(filter %_$(_LBPF_VER), \
>>>+ $(join $(addsuffix _, $(_LBPFLIST)),$(_LBPFLIST2))))
>>>
>>>It's bigger but avoids invocations of grep/sort/cut/head, only cat/printf
>>>, thus -V option also.
>>>
>>
>>No way, this is way too ugly (and still unreliable, if we ever have
>>X.Y.Z.W or something). I'd rather go with my original approach of
>Yes, forgot to add
>X1,X2,X3,...XN, where X = {0,1,....99999} and N = const for all versions.
>But frankly, 1.0.0 looks too far.
It actually works for any numbs of X1.X2...X100
but not when you have couple kindof:
X1.X2.X3
and
X1.X2.X3.X4
But, no absolutely any problem to extend this solution to handle all cases,
by just adding leading 0 to every "transformed version", say limit it to 10
possible 'dots' (%5*10d) and it will work as clocks. Advantage - mostly make
functions.
Here can be couple more solutions with sed, not sure it can look less maniac.
>
>>fetching the last version in libbpf.map file. See
>>https://www.spinics.net/lists/netdev/msg592703.html.
Yes it's nice but, no sort, no X1.X2.X3....XN
Main is to solve it for a long time.
>>
>>>>
>>>>> LIBBPF_MAJOR_VERSION := $(firstword $(subst ., ,$(LIBBPF_VERSION)))
>>>>>
>>>>> MAKEFLAGS += --no-print-directory
>>>>> --
>>>>> 2.17.1
>>>>>
>>>
>>>--
>>>Regards,
>>>Ivan Khoronzhuk
>
>--
>Regards,
>Ivan Khoronzhuk
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [PATCH 2/2] net/phy/mdio-mscc-miim: Move the setting of mii_bus structure members in mscc_miim_probe()
From: Andrew Lunn @ 2019-09-20 19:13 UTC (permalink / raw)
To: Markus Elfring
Cc: netdev, Alexandre Belloni, Florian Fainelli, David S. Miller,
Heiner Kallweit, LKML, kernel-janitors
In-Reply-To: <fe3ecdd2-a011-e4ed-5ef2-c3a8a02b343c@web.de>
On Fri, Sep 20, 2019 at 09:03:57PM +0200, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 20 Sep 2019 20:42:42 +0200
>
> Move the modification of some members in the data structure “mii_bus”
> for the local variable “bus” directly before the call of
> the function “of_mdiobus_register” so that this change will be performed
> only after previous resource allocations succeeded.
Hi Markus
I'm not sure it is worth making this change. The resource allocations
succeeds 99.9999% of the time. It is a chunk of MMIO, not some gpio,
or i2c device which might give us EPROBE_DEFERRED. So we are not
wasting anything in reality.
Andrew
^ permalink raw reply
* Re: [PATCH 1/2] net/phy/mdio-mscc-miim: Use devm_platform_ioremap_resource() in mscc_miim_probe()
From: Andrew Lunn @ 2019-09-20 19:09 UTC (permalink / raw)
To: Markus Elfring
Cc: netdev, Alexandre Belloni, Florian Fainelli, David S. Miller,
Heiner Kallweit, LKML, kernel-janitors
In-Reply-To: <506889a6-4148-89f9-302e-4be069595bb4@web.de>
On Fri, Sep 20, 2019 at 09:02:40PM +0200, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 20 Sep 2019 20:20:34 +0200
>
> Simplify this function implementation by using a known wrapper function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH 2/2] net/phy/mdio-mscc-miim: Move the setting of mii_bus structure members in mscc_miim_probe()
From: Markus Elfring @ 2019-09-20 19:03 UTC (permalink / raw)
To: netdev, Alexandre Belloni, Andrew Lunn, Florian Fainelli,
David S. Miller, Heiner Kallweit
Cc: LKML, kernel-janitors
In-Reply-To: <189ccfc3-d5a6-79fd-29b8-1f7140e9639a@web.de>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 20 Sep 2019 20:42:42 +0200
Move the modification of some members in the data structure “mii_bus”
for the local variable “bus” directly before the call of
the function “of_mdiobus_register” so that this change will be performed
only after previous resource allocations succeeded.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/phy/mdio-mscc-miim.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/phy/mdio-mscc-miim.c b/drivers/net/phy/mdio-mscc-miim.c
index b36fe81b6e6d..c46e0c78402e 100644
--- a/drivers/net/phy/mdio-mscc-miim.c
+++ b/drivers/net/phy/mdio-mscc-miim.c
@@ -123,13 +123,6 @@ static int mscc_miim_probe(struct platform_device *pdev)
if (!bus)
return -ENOMEM;
- bus->name = "mscc_miim";
- bus->read = mscc_miim_read;
- bus->write = mscc_miim_write;
- bus->reset = mscc_miim_reset;
- snprintf(bus->id, MII_BUS_ID_SIZE, "%s-mii", dev_name(&pdev->dev));
- bus->parent = &pdev->dev;
-
dev = bus->priv;
dev->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(dev->regs)) {
@@ -143,6 +136,12 @@ static int mscc_miim_probe(struct platform_device *pdev)
return PTR_ERR(dev->phy_regs);
}
+ bus->name = "mscc_miim";
+ bus->read = mscc_miim_read;
+ bus->write = mscc_miim_write;
+ bus->reset = mscc_miim_reset;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%s-mii", dev_name(&pdev->dev));
+ bus->parent = &pdev->dev;
ret = of_mdiobus_register(bus, pdev->dev.of_node);
if (ret < 0) {
dev_err(&pdev->dev, "Cannot register MDIO bus (%d)\n", ret);
--
2.23.0
^ permalink raw reply related
* [PATCH 1/2] net/phy/mdio-mscc-miim: Use devm_platform_ioremap_resource() in mscc_miim_probe()
From: Markus Elfring @ 2019-09-20 19:02 UTC (permalink / raw)
To: netdev, Alexandre Belloni, Andrew Lunn, Florian Fainelli,
David S. Miller, Heiner Kallweit
Cc: LKML, kernel-janitors
In-Reply-To: <189ccfc3-d5a6-79fd-29b8-1f7140e9639a@web.de>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 20 Sep 2019 20:20:34 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/phy/mdio-mscc-miim.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/net/phy/mdio-mscc-miim.c b/drivers/net/phy/mdio-mscc-miim.c
index badbc99bedd3..b36fe81b6e6d 100644
--- a/drivers/net/phy/mdio-mscc-miim.c
+++ b/drivers/net/phy/mdio-mscc-miim.c
@@ -115,15 +115,10 @@ static int mscc_miim_reset(struct mii_bus *bus)
static int mscc_miim_probe(struct platform_device *pdev)
{
- struct resource *res;
struct mii_bus *bus;
struct mscc_miim_dev *dev;
int ret;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENODEV;
-
bus = devm_mdiobus_alloc_size(&pdev->dev, sizeof(*dev));
if (!bus)
return -ENOMEM;
@@ -136,19 +131,16 @@ static int mscc_miim_probe(struct platform_device *pdev)
bus->parent = &pdev->dev;
dev = bus->priv;
- dev->regs = devm_ioremap_resource(&pdev->dev, res);
+ dev->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(dev->regs)) {
dev_err(&pdev->dev, "Unable to map MIIM registers\n");
return PTR_ERR(dev->regs);
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (res) {
- dev->phy_regs = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(dev->phy_regs)) {
- dev_err(&pdev->dev, "Unable to map internal phy registers\n");
- return PTR_ERR(dev->phy_regs);
- }
+ dev->phy_regs = devm_platform_ioremap_resource(pdev, 1);
+ if (IS_ERR(dev->phy_regs)) {
+ dev_err(&pdev->dev, "Unable to map internal phy registers\n");
+ return PTR_ERR(dev->phy_regs);
}
ret = of_mdiobus_register(bus, pdev->dev.of_node);
--
2.23.0
^ permalink raw reply related
* [PATCH 0/2] net/phy/mdio-mscc-miim: Adjustments for mscc_miim_probe()
From: Markus Elfring @ 2019-09-20 19:00 UTC (permalink / raw)
To: netdev, Alexandre Belloni, Andrew Lunn, Florian Fainelli,
David S. Miller, Heiner Kallweit
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 20 Sep 2019 20:52:25 +0200
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Use devm_platform_ioremap_resource()
Move the setting of mii_bus structure members
drivers/net/phy/mdio-mscc-miim.c | 31 +++++++++++--------------------
1 file changed, 11 insertions(+), 20 deletions(-)
--
2.23.0
^ permalink raw reply
* [PATCH net-next] tuntap: Fallback to automq on TUNSETSTEERINGEBPF prog negative return
From: Matthew Cover @ 2019-09-20 18:58 UTC (permalink / raw)
To: davem, ast, daniel, kafai, songliubraving, yhs, jasowang,
edumazet, sdf, mst, matthew.cover, mail, pabeni, nicolas.dichtel,
wangli39, lifei.shirley, tglx, netdev, linux-kernel, bpf
Treat a negative return from a TUNSETSTEERINGEBPF bpf prog as a signal
to fallback to tun_automq_select_queue() for tx queue selection.
Compilation of this exact patch was tested.
For functional testing 3 additional printk()s were added.
Functional testing results (on 2 txq tap device):
[Fri Sep 20 18:33:27 2019] ========== tun no prog ==========
[Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '-1'
[Fri Sep 20 18:33:27 2019] tuntap: tun_automq_select_queue() ran
[Fri Sep 20 18:33:27 2019] ========== tun prog -1 ==========
[Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '-1'
[Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '-1'
[Fri Sep 20 18:33:27 2019] tuntap: tun_automq_select_queue() ran
[Fri Sep 20 18:33:27 2019] ========== tun prog 0 ==========
[Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '0'
[Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '0'
[Fri Sep 20 18:33:27 2019] ========== tun prog 1 ==========
[Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '1'
[Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '1'
[Fri Sep 20 18:33:27 2019] ========== tun prog 2 ==========
[Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '2'
[Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '0'
Signed-off-by: Matthew Cover <matthew.cover@stackpath.com>
---
drivers/net/tun.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index aab0be4..173d159 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -583,35 +583,37 @@ static u16 tun_automq_select_queue(struct tun_struct *tun, struct sk_buff *skb)
return txq;
}
-static u16 tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff *skb)
+static int tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff *skb)
{
struct tun_prog *prog;
u32 numqueues;
- u16 ret = 0;
+ int ret = -1;
numqueues = READ_ONCE(tun->numqueues);
if (!numqueues)
return 0;
+ rcu_read_lock();
prog = rcu_dereference(tun->steering_prog);
if (prog)
ret = bpf_prog_run_clear_cb(prog->prog, skb);
+ rcu_read_unlock();
- return ret % numqueues;
+ if (ret >= 0)
+ ret %= numqueues;
+
+ return ret;
}
static u16 tun_select_queue(struct net_device *dev, struct sk_buff *skb,
struct net_device *sb_dev)
{
struct tun_struct *tun = netdev_priv(dev);
- u16 ret;
+ int ret;
- rcu_read_lock();
- if (rcu_dereference(tun->steering_prog))
- ret = tun_ebpf_select_queue(tun, skb);
- else
+ ret = tun_ebpf_select_queue(tun, skb);
+ if (ret < 0)
ret = tun_automq_select_queue(tun, skb);
- rcu_read_unlock();
return ret;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next] net: usb: ax88179_178a: allow optionally getting mac address from device tree
From: Jakub Kicinski @ 2019-09-20 18:54 UTC (permalink / raw)
To: Peter Fink; +Cc: netdev, pfink, davem, linux
In-Reply-To: <1568962710-14845-2-git-send-email-pedro@pixelbox.red>
On Fri, 20 Sep 2019 08:58:30 +0200, Peter Fink wrote:
> From: Peter Fink <pfink@christ-es.de>
>
> Adopt and integrate the feature to pass the MAC address via device tree
> from asix_device.c (03fc5d4) also to other ax88179 based asix chips.
> E.g. the bootloader fills in local-mac-address and the driver will then
> pick up and use this MAC address.
>
> Signed-off-by: Peter Fink <pfink@christ-es.de>
net-next is now closed [1], and will reopen some time after the merge
window is over. Hopefully you can gather feedback now, but I'm dropping
the patch from patchwork, and you'll have to resubmit once Dave opens
net-next again.
[1] https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html
^ permalink raw reply
* Re: [PATCH] mt7601u: phy: simplify zero check on val
From: Jakub Kicinski @ 2019-09-20 18:45 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Colin King, Kalle Valo, David S . Miller, Matthias Brugger,
linux-wireless, netdev, linux-arm-kernel, linux-mediatek,
kernel-janitors, linux-kernel
In-Reply-To: <20190920135817.GC6456@localhost.localdomain>
On Fri, 20 Sep 2019 15:58:17 +0200, Lorenzo Bianconi wrote:
> I think this is not correct since (not considering the cast) we should break
> from the loop if val != 0 and val != 0xff, so the right approach I guess is:
>
> diff --git a/drivers/net/wireless/mediatek/mt7601u/phy.c b/drivers/net/wireless/mediatek/mt7601u/phy.c
> index 06f5702ab4bd..d863ab4a66c9 100644
> --- a/drivers/net/wireless/mediatek/mt7601u/phy.c
> +++ b/drivers/net/wireless/mediatek/mt7601u/phy.c
> @@ -213,7 +213,7 @@ int mt7601u_wait_bbp_ready(struct mt7601u_dev *dev)
>
> do {
> val = mt7601u_bbp_rr(dev, MT_BBP_REG_VERSION);
> - if (val && ~val)
> + if (val && val != 0xff)
> break;
> } while (--i);
Yup, feel free to add my ack if you post this, Lorenzo.
^ permalink raw reply
* Re: [PATCH bpf] libbpf: fix version identification on busybox
From: Ivan Khoronzhuk @ 2019-09-20 18:34 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Alexei Starovoitov, Daniel Borkmann, Martin Lau, Andrii Nakryiko,
Yonghong Song, Networking, bpf, open list
In-Reply-To: <CAEf4BzaVuaN3HhMu8W_i9z4n-2zfjqxBXyOEOaQHexxZq7b3qg@mail.gmail.com>
On Fri, Sep 20, 2019 at 09:41:54AM -0700, Andrii Nakryiko wrote:
>On Fri, Sep 20, 2019 at 1:22 AM Ivan Khoronzhuk
><ivan.khoronzhuk@linaro.org> wrote:
>>
>> On Thu, Sep 19, 2019 at 01:02:40PM -0700, Andrii Nakryiko wrote:
>> >On Thu, Sep 19, 2019 at 11:22 AM Ivan Khoronzhuk
>> ><ivan.khoronzhuk@linaro.org> wrote:
>> >>
>> >> It's very often for embedded to have stripped version of sort in
>> >> busybox, when no -V option present. It breaks build natively on target
>> >> board causing recursive loop.
>> >>
>> >> BusyBox v1.24.1 (2019-04-06 04:09:16 UTC) multi-call binary. \
>> >> Usage: sort [-nrugMcszbdfimSTokt] [-o FILE] [-k \
>> >> start[.offset][opts][,end[.offset][opts]] [-t CHAR] [FILE]...
>> >>
>> >> Lets modify command a little to avoid -V option.
>> >>
>> >> Fixes: dadb81d0afe732 ("libbpf: make libbpf.map source of truth for libbpf version")
>> >>
>> >> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> >> ---
>> >>
>> >> Based on bpf/master
>> >>
>> >> tools/lib/bpf/Makefile | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
>> >> index c6f94cffe06e..a12490ad6215 100644
>> >> --- a/tools/lib/bpf/Makefile
>> >> +++ b/tools/lib/bpf/Makefile
>> >> @@ -3,7 +3,7 @@
>> >>
>> >> LIBBPF_VERSION := $(shell \
>> >> grep -oE '^LIBBPF_([0-9.]+)' libbpf.map | \
>> >> - sort -rV | head -n1 | cut -d'_' -f2)
>> >> + cut -d'_' -f2 | sort -r | head -n1)
>> >
>> >You can't just sort alphabetically, because:
>> >
>> >1.2
>> >1.11
>> >
>> >should be in that order. See discussion on mailing thread for original commit.
>>
>> if X1.X2.X3, where X = {0,1,....99999}
>> Then it can be:
>>
>> -LIBBPF_VERSION := $(shell \
>> - grep -oE '^LIBBPF_([0-9.]+)' libbpf.map | \
>> - sort -rV | head -n1 | cut -d'_' -f2)
>> +_LBPFLIST := $(patsubst %;,%,$(patsubst LIBBPF_%,%,$(filter LIBBPF_%, \
>> + $(shell cat libbpf.map))))
>> +_LBPFLIST2 := $(foreach v,$(_LBPFLIST), \
>> + $(subst $() $(),,$(foreach n,$(subst .,$() $(),$(v)), \
>> + $(shell printf "%05d" $(n)))))
>> +_LBPF_VER := $(word $(words $(sort $(_LBPFLIST2))), $(sort $(_LBPFLIST2)))
>> +LIBBPF_VERSION := $(patsubst %_$(_LBPF_VER),%,$(filter %_$(_LBPF_VER), \
>> + $(join $(addsuffix _, $(_LBPFLIST)),$(_LBPFLIST2))))
>>
>> It's bigger but avoids invocations of grep/sort/cut/head, only cat/printf
>> , thus -V option also.
>>
>
>No way, this is way too ugly (and still unreliable, if we ever have
>X.Y.Z.W or something). I'd rather go with my original approach of
Yes, forgot to add
X1,X2,X3,...XN, where X = {0,1,....99999} and N = const for all versions.
But frankly, 1.0.0 looks too far.
>fetching the last version in libbpf.map file. See
>https://www.spinics.net/lists/netdev/msg592703.html.
>
>> >
>> >> LIBBPF_MAJOR_VERSION := $(firstword $(subst ., ,$(LIBBPF_VERSION)))
>> >>
>> >> MAKEFLAGS += --no-print-directory
>> >> --
>> >> 2.17.1
>> >>
>>
>> --
>> Regards,
>> Ivan Khoronzhuk
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [PATCH] dimlib: make DIMLIB a hidden symbol
From: Uwe Kleine-König @ 2019-09-20 17:58 UTC (permalink / raw)
To: Tal Gilboa, Saeed Mahameed, Arthur Kiyanovski
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <670cc72f-fef0-a8cf-eb03-25fdb608eea8@mellanox.com>
[-- Attachment #1.1: Type: text/plain, Size: 830 bytes --]
Hello,
On 9/20/19 7:02 PM, Tal Gilboa wrote:
> On 9/20/2019 4:31 PM, Uwe Kleine-König wrote:
>> diff --git a/lib/Kconfig b/lib/Kconfig
>> index cc04124ed8f7..9fe8a21fd183 100644
>> --- a/lib/Kconfig
>> +++ b/lib/Kconfig
>> @@ -555,8 +555,7 @@ config SIGNATURE
>> Implementation is done using GnuPG MPI library
>>
>> config DIMLIB
>> - bool "DIM library"
>> - default y
>> + bool
>> help
>> Dynamic Interrupt Moderation library.
>> Implements an algorithm for dynamically change CQ moderation values
>>
> There's a pending series using DIM which didn't add the select clause
> [1]. Arthur, FYI. Other than that LGTM.
IMHO this should be fixed, as otherwise the config with the new code
enabled and DIMLIB disabled will fail to build also without my change.
Best regards
Uwe
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH RFC] cfg80211: add new command for reporting wiphy crashes
From: Jakub Kicinski @ 2019-09-20 17:56 UTC (permalink / raw)
To: Rafał Miłecki, Johannes Berg
Cc: David S . Miller, linux-wireless, netdev, linux-kernel,
Jouni Malinen, hostap, openwrt-devel, Rafał Miłecki
In-Reply-To: <20190920133708.15313-1-zajec5@gmail.com>
On Fri, 20 Sep 2019 15:37:08 +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Hardware or firmware instability may result in unusable wiphy. In such
> cases usually a hardware reset is needed. To allow a full recovery
> kernel has to indicate problem to the user space.
>
> This new nl80211 command lets user space known wiphy has crashed and has
> been just recovered. When applicable it should result in supplicant or
> authenticator reconfiguring all interfaces.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> I'd like to use this new cfg80211_crash_report() in brcmfmac after a
> successful recovery from a FullMAC firmware crash.
>
> Later on I'd like to modify hostapd to reconfigure wiphy using a
> previously used setup.
>
> I'm OpenWrt developer & user and I got annoyed by my devices not auto
> recovering after various failures. There are things I cannot fix (hw
> failures or closed fw crashes) but I still expect my devices to get
> back to operational state as soon as possible on their own.
Perhaps a slightly larger point, but I think it should be raised -
is there any chance for reusing debugging, reset and recovery work done
in devlink originally for complex Ethernet devices?
WiFi drivers have been dealing with more complex/FW heavy designs for a
while so maybe you've grow your own interfaces, and maybe they
necessarily need to be 802.11-centric, but I'm a little surprised that:
linux $ git grep devlink -- drivers/net/wireless/
linux $
^ permalink raw reply
* Re: [PATCH] dimlib: make DIMLIB a hidden symbol
From: Randy Dunlap @ 2019-09-20 17:41 UTC (permalink / raw)
To: Tal Gilboa, Uwe Kleine-König, Saeed Mahameed,
Arthur Kiyanovski
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <670cc72f-fef0-a8cf-eb03-25fdb608eea8@mellanox.com>
On 9/20/19 10:02 AM, Tal Gilboa wrote:
> On 9/20/2019 4:31 PM, Uwe Kleine-König wrote:
>> According to Tal Gilboa the only benefit from DIM comes from a driver
>> that uses it. So it doesn't make sense to make this symbol user visible,
>> instead all drivers that use it should select it (as is already the case
>> AFAICT).
>>
>> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
>> ---
>> lib/Kconfig | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/lib/Kconfig b/lib/Kconfig
>> index cc04124ed8f7..9fe8a21fd183 100644
>> --- a/lib/Kconfig
>> +++ b/lib/Kconfig
>> @@ -555,8 +555,7 @@ config SIGNATURE
>> Implementation is done using GnuPG MPI library
>>
>> config DIMLIB
>> - bool "DIM library"
>> - default y
>> + bool
>> help
>> Dynamic Interrupt Moderation library.
>> Implements an algorithm for dynamically change CQ moderation values
>>
> There's a pending series using DIM which didn't add the select clause
> [1]. Arthur, FYI. Other than that LGTM.
That's easy enough to fix.
> [1] https://www.mail-archive.com/netdev@vger.kernel.org/msg314304.html
for the patch:
Acked-by: Randy Dunlap <rdunlap@infradead.org>
--
~Randy
^ permalink raw reply
* Re: [PATCH v3 0/2] net: stmmac: Enhanced addressing mode for DWMAC 4.10
From: Florian Fainelli @ 2019-09-20 17:02 UTC (permalink / raw)
To: Thierry Reding, David S . Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, Jon Hunter,
Bitan Biswas, netdev, linux-tegra
In-Reply-To: <20190920170036.22610-1-thierry.reding@gmail.com>
On 9/20/19 10:00 AM, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> The DWMAC 4.10 supports the same enhanced addressing mode as later
> generations. Parse this capability from the hardware feature registers
> and set the EAME (Enhanced Addressing Mode Enable) bit when necessary.
Do you think these two patches should have companion Fixes: tag? They
are definitively bug fixes, but maybe you would also want those to be
back ported to -stable trees?
>
> Thierry
>
> Thierry Reding (2):
> net: stmmac: Only enable enhanced addressing mode when needed
> net: stmmac: Support enhanced addressing mode for DWMAC 4.10
>
> drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 1 +
> .../ethernet/stmicro/stmmac/dwmac4_descs.c | 4 ++--
> .../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 22 +++++++++++++++++++
> .../net/ethernet/stmicro/stmmac/dwmac4_dma.h | 3 +++
> .../ethernet/stmicro/stmmac/dwxgmac2_dma.c | 5 ++++-
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++
> include/linux/stmmac.h | 1 +
> 7 files changed, 39 insertions(+), 3 deletions(-)
>
--
Florian
^ permalink raw reply
* Re: [PATCH] dimlib: make DIMLIB a hidden symbol
From: Tal Gilboa @ 2019-09-20 17:02 UTC (permalink / raw)
To: Uwe Kleine-König, Saeed Mahameed, Arthur Kiyanovski
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20190920133115.12802-1-uwe@kleine-koenig.org>
On 9/20/2019 4:31 PM, Uwe Kleine-König wrote:
> According to Tal Gilboa the only benefit from DIM comes from a driver
> that uses it. So it doesn't make sense to make this symbol user visible,
> instead all drivers that use it should select it (as is already the case
> AFAICT).
>
> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
> ---
> lib/Kconfig | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/lib/Kconfig b/lib/Kconfig
> index cc04124ed8f7..9fe8a21fd183 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -555,8 +555,7 @@ config SIGNATURE
> Implementation is done using GnuPG MPI library
>
> config DIMLIB
> - bool "DIM library"
> - default y
> + bool
> help
> Dynamic Interrupt Moderation library.
> Implements an algorithm for dynamically change CQ moderation values
>
There's a pending series using DIM which didn't add the select clause
[1]. Arthur, FYI. Other than that LGTM.
[1] https://www.mail-archive.com/netdev@vger.kernel.org/msg314304.html
^ permalink raw reply
* [PATCH] net: stmmac: Fix page pool size
From: Thierry Reding @ 2019-09-20 17:01 UTC (permalink / raw)
To: David S . Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Florian Fainelli, Jon Hunter, Bitan Biswas, netdev, linux-tegra
From: Thierry Reding <treding@nvidia.com>
The size of individual pages in the page pool in given by an order. The
order is the binary logarithm of the number of pages that make up one of
the pages in the pool. However, the driver currently passes the number
of pages rather than the order, so it ends up wasting quite a bit of
memory.
Fix this by taking the binary logarithm and passing that in the order
field.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index ecd461207dbc..f8c90dba6db8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1550,13 +1550,15 @@ static int alloc_dma_rx_desc_resources(struct stmmac_priv *priv)
for (queue = 0; queue < rx_count; queue++) {
struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
struct page_pool_params pp_params = { 0 };
+ unsigned int num_pages;
rx_q->queue_index = queue;
rx_q->priv_data = priv;
pp_params.flags = PP_FLAG_DMA_MAP;
pp_params.pool_size = DMA_RX_SIZE;
- pp_params.order = DIV_ROUND_UP(priv->dma_buf_sz, PAGE_SIZE);
+ num_pages = DIV_ROUND_UP(priv->dma_buf_sz, PAGE_SIZE);
+ pp_params.order = ilog2(num_pages);
pp_params.nid = dev_to_node(priv->device);
pp_params.dev = priv->device;
pp_params.dma_dir = DMA_FROM_DEVICE;
--
2.23.0
^ permalink raw reply related
* [PATCH v3 2/2] net: stmmac: Support enhanced addressing mode for DWMAC 4.10
From: Thierry Reding @ 2019-09-20 17:00 UTC (permalink / raw)
To: David S . Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Florian Fainelli, Jon Hunter, Bitan Biswas, netdev, linux-tegra
In-Reply-To: <20190920170036.22610-1-thierry.reding@gmail.com>
From: Thierry Reding <treding@nvidia.com>
The address width of the controller can be read from hardware feature
registers much like on XGMAC. Add support for parsing the ADDR64 field
so that the DMA mask can be set accordingly.
This avoids getting swiotlb involved for DMA on Tegra186 and later.
Also make sure that the upper 32 bits of the DMA address are written to
the DMA descriptors when enhanced addressing mode is used. Similarily,
for each channel, the upper 32 bits of the DMA descriptor ring's base
address also need to be programmed to make sure the correct memory can
be fetched when the DMA descriptor ring is located beyond the 32-bit
boundary.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v3:
- unconditionally write upper 32 bits
Changes in v2:
- also program the upper 32 bits of the DMA descriptor base address for
each channel
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 1 +
.../ethernet/stmicro/stmmac/dwmac4_descs.c | 4 ++--
.../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 22 +++++++++++++++++++
.../net/ethernet/stmicro/stmmac/dwmac4_dma.h | 3 +++
4 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index 2ed11a581d80..f634fa09dffc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -183,6 +183,7 @@ enum power_event {
#define GMAC_HW_HASH_TB_SZ GENMASK(25, 24)
#define GMAC_HW_FEAT_AVSEL BIT(20)
#define GMAC_HW_TSOEN BIT(18)
+#define GMAC_HW_ADDR64 GENMASK(15, 14)
#define GMAC_HW_TXFIFOSIZE GENMASK(10, 6)
#define GMAC_HW_RXFIFOSIZE GENMASK(4, 0)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index dbde23e7e169..d546041d2fcd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -431,8 +431,8 @@ static void dwmac4_get_addr(struct dma_desc *p, unsigned int *addr)
static void dwmac4_set_addr(struct dma_desc *p, dma_addr_t addr)
{
- p->des0 = cpu_to_le32(addr);
- p->des1 = 0;
+ p->des0 = cpu_to_le32(lower_32_bits(addr));
+ p->des1 = cpu_to_le32(upper_32_bits(addr));
}
static void dwmac4_clear(struct dma_desc *p)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 3ed5508586ef..8439dd84f786 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -79,6 +79,7 @@ static void dwmac4_dma_init_rx_chan(void __iomem *ioaddr,
value = value | (rxpbl << DMA_BUS_MODE_RPBL_SHIFT);
writel(value, ioaddr + DMA_CHAN_RX_CONTROL(chan));
+ writel(upper_32_bits(dma_rx_phy), ioaddr + DMA_CHAN_RX_BASE_ADDR_HI(chan));
writel(lower_32_bits(dma_rx_phy), ioaddr + DMA_CHAN_RX_BASE_ADDR(chan));
}
@@ -97,6 +98,7 @@ static void dwmac4_dma_init_tx_chan(void __iomem *ioaddr,
writel(value, ioaddr + DMA_CHAN_TX_CONTROL(chan));
+ writel(upper_32_bits(dma_tx_phy), ioaddr + DMA_CHAN_TX_BASE_ADDR_HI(chan));
writel(lower_32_bits(dma_tx_phy), ioaddr + DMA_CHAN_TX_BASE_ADDR(chan));
}
@@ -132,6 +134,9 @@ static void dwmac4_dma_init(void __iomem *ioaddr,
if (dma_cfg->aal)
value |= DMA_SYS_BUS_AAL;
+ if (dma_cfg->eame)
+ value |= DMA_SYS_BUS_EAME;
+
writel(value, ioaddr + DMA_SYS_BUS_MODE);
}
@@ -354,6 +359,23 @@ static void dwmac4_get_hw_feature(void __iomem *ioaddr,
dma_cap->hash_tb_sz = (hw_cap & GMAC_HW_HASH_TB_SZ) >> 24;
dma_cap->av = (hw_cap & GMAC_HW_FEAT_AVSEL) >> 20;
dma_cap->tsoen = (hw_cap & GMAC_HW_TSOEN) >> 18;
+
+ dma_cap->addr64 = (hw_cap & GMAC_HW_ADDR64) >> 14;
+ switch (dma_cap->addr64) {
+ case 0:
+ dma_cap->addr64 = 32;
+ break;
+ case 1:
+ dma_cap->addr64 = 40;
+ break;
+ case 2:
+ dma_cap->addr64 = 48;
+ break;
+ default:
+ dma_cap->addr64 = 32;
+ break;
+ }
+
/* RX and TX FIFO sizes are encoded as log2(n / 128). Undo that by
* shifting and store the sizes in bytes.
*/
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
index b66da0237d2a..5299fa1001a3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
@@ -65,6 +65,7 @@
#define DMA_SYS_BUS_MB BIT(14)
#define DMA_AXI_1KBBE BIT(13)
#define DMA_SYS_BUS_AAL BIT(12)
+#define DMA_SYS_BUS_EAME BIT(11)
#define DMA_AXI_BLEN256 BIT(7)
#define DMA_AXI_BLEN128 BIT(6)
#define DMA_AXI_BLEN64 BIT(5)
@@ -91,7 +92,9 @@
#define DMA_CHAN_CONTROL(x) DMA_CHANX_BASE_ADDR(x)
#define DMA_CHAN_TX_CONTROL(x) (DMA_CHANX_BASE_ADDR(x) + 0x4)
#define DMA_CHAN_RX_CONTROL(x) (DMA_CHANX_BASE_ADDR(x) + 0x8)
+#define DMA_CHAN_TX_BASE_ADDR_HI(x) (DMA_CHANX_BASE_ADDR(x) + 0x10)
#define DMA_CHAN_TX_BASE_ADDR(x) (DMA_CHANX_BASE_ADDR(x) + 0x14)
+#define DMA_CHAN_RX_BASE_ADDR_HI(x) (DMA_CHANX_BASE_ADDR(x) + 0x18)
#define DMA_CHAN_RX_BASE_ADDR(x) (DMA_CHANX_BASE_ADDR(x) + 0x1c)
#define DMA_CHAN_TX_END_ADDR(x) (DMA_CHANX_BASE_ADDR(x) + 0x20)
#define DMA_CHAN_RX_END_ADDR(x) (DMA_CHANX_BASE_ADDR(x) + 0x28)
--
2.23.0
^ permalink raw reply related
* [PATCH v3 1/2] net: stmmac: Only enable enhanced addressing mode when needed
From: Thierry Reding @ 2019-09-20 17:00 UTC (permalink / raw)
To: David S . Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Florian Fainelli, Jon Hunter, Bitan Biswas, netdev, linux-tegra
In-Reply-To: <20190920170036.22610-1-thierry.reding@gmail.com>
From: Thierry Reding <treding@nvidia.com>
Enhanced addressing mode is only required when more than 32 bits need to
be addressed. Add a DMA configuration parameter to enable this mode only
when needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 5 ++++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 ++++++
include/linux/stmmac.h | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
index 64956465c030..3e00fd8befcf 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
@@ -27,7 +27,10 @@ static void dwxgmac2_dma_init(void __iomem *ioaddr,
if (dma_cfg->aal)
value |= XGMAC_AAL;
- writel(value | XGMAC_EAME, ioaddr + XGMAC_DMA_SYSBUS_MODE);
+ if (dma_cfg->eame)
+ value |= XGMAC_EAME;
+
+ writel(value, ioaddr + XGMAC_DMA_SYSBUS_MODE);
}
static void dwxgmac2_dma_init_chan(void __iomem *ioaddr,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 06ccd216ae90..ecd461207dbc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4497,6 +4497,12 @@ int stmmac_dvr_probe(struct device *device,
if (!ret) {
dev_info(priv->device, "Using %d bits DMA width\n",
priv->dma_cap.addr64);
+
+ /*
+ * If more than 32 bits can be addressed, make sure to
+ * enable enhanced addressing mode.
+ */
+ priv->plat->dma_cfg->eame = true;
} else {
ret = dma_set_mask_and_coherent(device, DMA_BIT_MASK(32));
if (ret) {
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 7ad7ae35cf88..d300ac907c76 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -92,6 +92,7 @@ struct stmmac_dma_cfg {
int fixed_burst;
int mixed_burst;
bool aal;
+ bool eame;
};
#define AXI_BLEN 7
--
2.23.0
^ permalink raw reply related
* [PATCH v3 0/2] net: stmmac: Enhanced addressing mode for DWMAC 4.10
From: Thierry Reding @ 2019-09-20 17:00 UTC (permalink / raw)
To: David S . Miller
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Florian Fainelli, Jon Hunter, Bitan Biswas, netdev, linux-tegra
From: Thierry Reding <treding@nvidia.com>
The DWMAC 4.10 supports the same enhanced addressing mode as later
generations. Parse this capability from the hardware feature registers
and set the EAME (Enhanced Addressing Mode Enable) bit when necessary.
Thierry
Thierry Reding (2):
net: stmmac: Only enable enhanced addressing mode when needed
net: stmmac: Support enhanced addressing mode for DWMAC 4.10
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 1 +
.../ethernet/stmicro/stmmac/dwmac4_descs.c | 4 ++--
.../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 22 +++++++++++++++++++
.../net/ethernet/stmicro/stmmac/dwmac4_dma.h | 3 +++
.../ethernet/stmicro/stmmac/dwxgmac2_dma.c | 5 ++++-
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++
include/linux/stmmac.h | 1 +
7 files changed, 39 insertions(+), 3 deletions(-)
--
2.23.0
^ permalink raw reply
* Re: [PATCH net v2 1/3] net: sched: sch_htb: don't call qdisc_put() while holding tree lock
From: Cong Wang @ 2019-09-20 16:53 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller
In-Reply-To: <vbfv9tnzdnb.fsf@mellanox.com>
On Thu, Sep 19, 2019 at 11:27 PM Vlad Buslov <vladbu@mellanox.com> wrote:
>
>
> On Fri 20 Sep 2019 at 04:05, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > On Thu, Sep 19, 2019 at 1:14 PM Vlad Buslov <vladbu@mellanox.com> wrote:
> >> Notes:
> >> Changes V1 -> V2:
> >>
> >> - Extend sch API with new qdisc_put_empty() function that has same
> >> implementation as regular qdisc_put() but skips parts that reset qdisc
> >> and free all packet buffers from gso_skb and skb_bad_txq queues.
> >
> > I don't understand why you need a new API here, as long as qdisc_reset()
> > gets called before releasing sch tree lock, the ->reset() inside qdisc_put(),
> > after releasing sch tree lock, should be a nop, right?
>
> Yes, but I wanted to make it explicit, so anyone else looking at the
> code of those Qdiscs would know that manual reset with appropriate
> locking is required. And it didn't require much new code because
> qdisc_put() and qidsc_put_empty() just reuse same __qdisc_put(). I'll
> revert it back, if you suggest that original approach is better.
It is unnecessary for -net/-stable. And you can always add a comment
to explain this if it is not clear.
Thanks.
^ permalink raw reply
* Re: [PATCH 4/4] mt76: mt7615: sync with mt7603 rate control changes
From: Gustavo A. R. Silva @ 2019-09-20 23:44 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless, Lorenzo Bianconi, Roy Luo,
Kalle Valo, David S. Miller, Matthias Brugger, Networking,
linux-arm-kernel, linux-mediatek, Linux Kernel Mailing List,
Ryder Lee
In-Reply-To: <20190704155324.56693-4-nbd@nbd.name>
Hi all,
On 7/4/19 10:53, Felix Fietkau wrote:
[..]
> + for (i = 0, idx = first_idx; count && idx <= last_idx; idx++) {
> + struct ieee80211_tx_rate *cur_rate;
> + int cur_count;
>
> - info->status.rates[i].count = cur_count;
> - final_idx = i;
> + cur_rate = &rs->rates[idx / 2];
> + cur_count = min_t(int, MT7615_RATE_RETRY, count);
> count -= cur_count;
> +
> + if (idx && (cur_rate->idx != info->status.rates[i].idx ||
> + cur_rate->flags != info->status.rates[i].flags)) {
> + i++;
> + if (i == ARRAY_SIZE(info->status.rates))
Is this actually possible ^^^^^^^ ?? in case it is, see my comments below...
> + break;
> +
> + info->status.rates[i] = *cur_rate;
> + info->status.rates[i].count = 0;
> + }
> +
> + info->status.rates[i].count += cur_count;
> }
>
> out:
> - final_rate_flags = info->status.rates[final_idx].flags;
> + final_rate_flags = info->status.rates[i].flags;
There is an out-of-bounds access here........^^^ and see below...
>
> switch (FIELD_GET(MT_TX_RATE_MODE, final_rate)) {
> case MT_PHY_TYPE_CCK:
> @@ -713,8 +778,8 @@ static bool mt7615_fill_txs(struct mt7615_dev *dev, struct mt7615_sta *sta,
> return false;
> }
>
> - info->status.rates[final_idx].idx = final_rate;
> - info->status.rates[final_idx].flags = final_rate_flags;
> + info->status.rates[i].idx = final_rate;
> + info->status.rates[i].flags = final_rate_flags;
here too ............... ^^^^
>
> return true;
> }
--
Gustavo
^ 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