* Re: [PATCH] net: stmmac: add flexible PPS to dwmac 4.10a
From: Antonio Borneo @ 2020-11-24 14:23 UTC (permalink / raw)
To: Ahmad Fatoum, Jakub Kicinski
Cc: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
netdev, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel, Pengutronix Kernel Team, has
In-Reply-To: <42960ede-9355-1277-9a6f-4eac3c22365c@pengutronix.de>
On Tue, 2020-11-24 at 15:15 +0100, Ahmad Fatoum wrote:
> Hello Jakub,
>
> On 10.10.19 00:26, Jakub Kicinski wrote:
> > On Mon, 7 Oct 2019 17:43:06 +0200, Antonio Borneo wrote:
> > > All the registers and the functionalities used in the callback
> > > dwmac5_flex_pps_config() are common between dwmac 4.10a [1] and
> > > 5.00a [2].
> > >
> > > Reuse the same callback for dwmac 4.10a too.
> > >
> > > Tested on STM32MP15x, based on dwmac 4.10a.
> > >
> > > [1] DWC Ethernet QoS Databook 4.10a October 2014
> > > [2] DWC Ethernet QoS Databook 5.00a September 2017
> > >
> > > Signed-off-by: Antonio Borneo <antonio.borneo@st.com>
> >
> > Applied to net-next.
>
> This patch seems to have been fuzzily applied at the wrong location.
> The diff describes extension of dwmac 4.10a and so does the @@ line:
>
> @@ -864,6 +864,7 @@ const struct stmmac_ops dwmac410_ops = {
>
> The patch was applied mainline as 757926247836 ("net: stmmac: add
> flexible PPS to dwmac 4.10a"), but it extends dwmac4_ops instead:
>
> @@ -938,6 +938,7 @@ const struct stmmac_ops dwmac4_ops = {
>
> I don't know if dwmac4 actually supports FlexPPS, so I think it's
> better to be on the safe side and revert 757926247836 and add the
> change for the correct variant.
Agree,
the patch get applied to the wrong place!
Antonio
>
> Cheers,
> Ahmad
>
>
^ permalink raw reply
* Re: [PATCH] net: stmmac: add flexible PPS to dwmac 4.10a
From: Ahmad Fatoum @ 2020-11-24 14:27 UTC (permalink / raw)
To: Antonio Borneo, Jakub Kicinski
Cc: Pengutronix Kernel Team, has, Alexandre Torgue, netdev,
linux-kernel, linux-stm32, Jose Abreu, Maxime Coquelin,
Giuseppe Cavallaro, David S. Miller, linux-arm-kernel
In-Reply-To: <42960ede-9355-1277-9a6f-4eac3c22365c@pengutronix.de>
To += Jakub's new address
On 24.11.20 15:15, Ahmad Fatoum wrote:
> Hello Jakub,
>
> On 10.10.19 00:26, Jakub Kicinski wrote:
>> On Mon, 7 Oct 2019 17:43:06 +0200, Antonio Borneo wrote:
>>> All the registers and the functionalities used in the callback
>>> dwmac5_flex_pps_config() are common between dwmac 4.10a [1] and
>>> 5.00a [2].
>>>
>>> Reuse the same callback for dwmac 4.10a too.
>>>
>>> Tested on STM32MP15x, based on dwmac 4.10a.
>>>
>>> [1] DWC Ethernet QoS Databook 4.10a October 2014
>>> [2] DWC Ethernet QoS Databook 5.00a September 2017
>>>
>>> Signed-off-by: Antonio Borneo <antonio.borneo@st.com>
>>
>> Applied to net-next.
>
> This patch seems to have been fuzzily applied at the wrong location.
> The diff describes extension of dwmac 4.10a and so does the @@ line:
>
> @@ -864,6 +864,7 @@ const struct stmmac_ops dwmac410_ops = {
>
> The patch was applied mainline as 757926247836 ("net: stmmac: add
> flexible PPS to dwmac 4.10a"), but it extends dwmac4_ops instead:
>
> @@ -938,6 +938,7 @@ const struct stmmac_ops dwmac4_ops = {
>
> I don't know if dwmac4 actually supports FlexPPS, so I think it's
> better to be on the safe side and revert 757926247836 and add the
> change for the correct variant.
>
> Cheers,
> Ahmad
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [EXT] [PATCH] aquantia: Remove the build_skb path
From: Igor Russkikh @ 2020-11-24 14:29 UTC (permalink / raw)
To: Ramsay, Lincoln, David S. Miller, Jakub Kicinski, netdev,
Dmitry Bogdanov [C]
In-Reply-To: <CY4PR1001MB23115129ED895150C388E12CE8FD0@CY4PR1001MB2311.namprd10.prod.outlook.com>
On 23/11/2020 7:20 am, Ramsay, Lincoln wrote:
>> Yep, that could be the only way to fix this for now.
>> Have you tried to estimate any performance drops from this?
>
> Unfortunately, I am not in a very good position to do this. The 10G
> interfaces on our device don't actually have enough raw PCI bandwidth
> available to hit 10G transfer rates.
>
> I did use iperf3 and saw bursts over 2Gbit/sec (with average closer to
> 1.3Gbit/sec on a good run). There was no significant difference between
> running with and without the patch. I am told that this is about as good
> as can be expected.
>
> Make of that what you will :)
Thats not very useful, but since we anyway have to fix that - lets do it.
I'll try to estimate potential perf drop on my setup when possible.
Thanks,
Igor
^ permalink raw reply
* Re: [PATCH net] netdevice.h: Fix unintentional disable of ALL_FOR_ALL features on upper device
From: Tariq Toukan @ 2020-11-24 14:30 UTC (permalink / raw)
To: Eric Dumazet, Herbert Xu
Cc: Tariq Toukan, David S. Miller, Jakub Kicinski, netdev,
Moshe Shemesh, Maxim Mikityanskiy, Saeed Mahameed
In-Reply-To: <CANn89iK8MXp0QmZbBKdMDHxi7A4afrVdBtgQq7cSY5SRefwraA@mail.gmail.com>
On 11/24/2020 12:48 PM, Eric Dumazet wrote:
> On Mon, Nov 23, 2020 at 5:15 PM Tariq Toukan <ttoukan.linux@gmail.com> wrote:
>>
>>
>>
>> On 11/23/2020 4:55 PM, Eric Dumazet wrote:
>>> On Mon, Nov 23, 2020 at 3:13 PM Tariq Toukan <tariqt@nvidia.com> wrote:
>>>>
>>>> Calling netdev_increment_features() on upper/master device from
>>>> netdev_add_tso_features() implies unintentional clearance of ALL_FOR_ALL
>>>> features supported by all slaves. Fix it by passing ALL_FOR_ALL in
>>>> addition to ALL_TSO.
>>>>
>>>> Fixes: b0ce3508b25e ("bonding: allow TSO being set on bonding master")
>>>
>>> I think you should give more details to your bug report, because
>>> netdev_add_tso_features() is used from different
>>> places.
>>>
>>> Thanks.
>>>
>>
>> Right. I'll include these in the re-spin:
>> Fixes: 247f6d0f8667 ("team: allow TSO being set on master")
>> Fixes: f902e8812ef6 ("bridge: Add ability to enable TSO")
>
> I was more thinking about what exact issue you had, and how we can
> reproduce it, and test the fix.
>
Issue reproduction is very simple:
Pick any of the features under ALL_FOR_ALL, like tx-nocache-copy.
Turn it on for all slaves.
Turn it on for the bond.
You'll still not be able to use it:
tx-nocache-copy: off [requested on]
Reason is that the call to netdev_add_tso_features() being considered as
a "dummy" slave that has this feature bit cleared, breaking ALL_FOR_ALL
logic.
>>
>> I wonder though if netdev_increment_features() is expected to clear
>> features that are not part of the mask.
>
> Well, the 'increment' part was suggesting the function was adding
> flags, not removing them.
>
Yes, that's confusing... Although ALL_FOR_ALL logic is just about
removing, unlike ONE_FOR_ALL.
> We might ask Herbert Xu if we :
>
> 1) Need to comment the function, or change its name to be more descriptive.
> 2) Change the behavior (as you suggested)
> 3) Other choice.
>
^ permalink raw reply
* Re: [PATCH v7 3/3] net: ax88796c: ASIX AX88796C SPI Ethernet Adapter Driver
From: Lukasz Stelmach @ 2020-11-24 14:29 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrew Lunn, jim.cromie, Heiner Kallweit, David S. Miller,
Jakub Kicinski, Rob Herring, Kukjin Kim, Russell King, netdev,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
Bartłomiej Żolnierkiewicz, Marek Szyprowski
In-Reply-To: <20201124121742.GA35334@kozik-lap>
[-- Attachment #1: Type: text/plain, Size: 3358 bytes --]
It was <2020-11-24 wto 13:17>, when Krzysztof Kozlowski wrote:
> On Tue, Nov 24, 2020 at 01:03:30PM +0100, Łukasz Stelmach wrote:
>> ASIX AX88796[1] is a versatile ethernet adapter chip, that can be
>> connected to a CPU with a 8/16-bit bus or with an SPI. This driver
>> supports SPI connection.
>>
>> The driver has been ported from the vendor kernel for ARTIK5[2]
>> boards. Several changes were made to adapt it to the current kernel
>> which include:
>>
>> + updated DT configuration,
>> + clock configuration moved to DT,
>> + new timer, ethtool and gpio APIs,
>> + dev_* instead of pr_* and custom printk() wrappers,
>> + removed awkward vendor power managemtn.
>> + introduced ethtool tunable to control SPI compression
>>
>> [1]
>> https://protect2.fireeye.com/v1/url?k=400e2614-1f951ecd-400fad5b-0cc47a3356b2-10d6caf77ede1dd5&q=1&e=8ef355b1-1777-4137-878d-2b11d6ef0003&u=https%3A%2F%2Fwww.asix.com.tw%2Fproducts.php%3Fop%3DpItemdetail%26PItemID%3D104%3B65%3B86%26PLine%3D65
>> [2]
>> https://protect2.fireeye.com/v1/url?k=519692a9-0e0daa70-519719e6-0cc47a3356b2-b5daaace05887741&q=1&e=8ef355b1-1777-4137-878d-2b11d6ef0003&u=https%3A%2F%2Fgit.tizen.org%2Fcgit%2Fprofile%2Fcommon%2Fplatform%2Fkernel%2Flinux-3.10-artik%2F
>>
>> The other ax88796 driver is for NE2000 compatible AX88796L chip. These
>> chips are not compatible. Hence, two separate drivers are required.
>>
>> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
>> ---
>> MAINTAINERS | 6 +
>> drivers/net/ethernet/Kconfig | 1 +
>> drivers/net/ethernet/Makefile | 1 +
>> drivers/net/ethernet/asix/Kconfig | 35 +
>> drivers/net/ethernet/asix/Makefile | 6 +
>> drivers/net/ethernet/asix/ax88796c_ioctl.c | 221 ++++
>> drivers/net/ethernet/asix/ax88796c_ioctl.h | 26 +
>> drivers/net/ethernet/asix/ax88796c_main.c | 1132 ++++++++++++++++++++
>> drivers/net/ethernet/asix/ax88796c_main.h | 561 ++++++++++
>> drivers/net/ethernet/asix/ax88796c_spi.c | 112 ++
>> drivers/net/ethernet/asix/ax88796c_spi.h | 69 ++
>> include/uapi/linux/ethtool.h | 1 +
>> net/ethtool/common.c | 1 +
>> 13 files changed, 2172 insertions(+)
>> create mode 100644 drivers/net/ethernet/asix/Kconfig
>> create mode 100644 drivers/net/ethernet/asix/Makefile
>> create mode 100644 drivers/net/ethernet/asix/ax88796c_ioctl.c
>> create mode 100644 drivers/net/ethernet/asix/ax88796c_ioctl.h
>> create mode 100644 drivers/net/ethernet/asix/ax88796c_main.c
>> create mode 100644 drivers/net/ethernet/asix/ax88796c_main.h
>> create mode 100644 drivers/net/ethernet/asix/ax88796c_spi.c
>> create mode 100644 drivers/net/ethernet/asix/ax88796c_spi.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 14b8ec0bb58b..930dc859d4f7 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -2812,6 +2812,12 @@ S: Maintained
>> F: Documentation/hwmon/asc7621.rst
>> F: drivers/hwmon/asc7621.c
>>
>> +ASIX AX88796C SPI ETHERNET ADAPTER
>> +M: Łukasz Stelmach <l.stelmach@samsung.com>
>> +S: Maintained
>> +F: Documentation/devicetree/bindings/net/asix,ax99706c-spi.yaml
>
> Wrong file name.
Fixed. Thanks.
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply
* Re: netconsole deadlock with virtnet
From: Steven Rostedt @ 2020-11-24 14:31 UTC (permalink / raw)
To: Jason Wang
Cc: Jakub Kicinski, Leon Romanovsky, Sergey Senozhatsky,
Michael S. Tsirkin, Petr Mladek, John Ogness, virtualization,
Amit Shah, Itay Aveksis, Ran Rozenstein, netdev
In-Reply-To: <1133f1a4-6772-8aa3-41dd-edbc1ee76cee@redhat.com>
On Tue, 24 Nov 2020 11:22:03 +0800
Jason Wang <jasowang@redhat.com> wrote:
> Btw, have a quick search, there are several other drivers that uses tx
> lock in the tx NAPI.
tx NAPI is not the issue. The issue is that write_msg() (in netconsole.c)
calls this polling logic with the target_list_lock held.
Are those other drivers called by netconsole? If not, then this is unique
to virtio-net.
-- Steve
^ permalink raw reply
* Re: [PATCH bpf-next V7 8/8] bpf/selftests: activating bpf_check_mtu BPF-helper
From: Jesper Dangaard Brouer @ 2020-11-24 14:33 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: bpf, Networking, Daniel Borkmann, Alexei Starovoitov,
Maciej Żenczykowski, Lorenz Bauer, shaun, Lorenzo Bianconi,
Marek Majkowski, John Fastabend, Jakub Kicinski, eyal.birger,
colrack, brouer
In-Reply-To: <CAEf4BzbfqvCiHDaZk3yQCPfzwpGJ-35XBw3qaGuPNYkfBHR2Kw@mail.gmail.com>
On Fri, 20 Nov 2020 23:41:11 -0800
Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> On Fri, Nov 20, 2020 at 8:21 AM Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
> >
> > Adding selftest for BPF-helper bpf_check_mtu(). Making sure
> > it can be used from both XDP and TC.
> >
> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > ---
> > tools/testing/selftests/bpf/prog_tests/check_mtu.c | 37 ++++++++++++++++++++
> > tools/testing/selftests/bpf/progs/test_check_mtu.c | 33 ++++++++++++++++++
> > 2 files changed, 70 insertions(+)
> > create mode 100644 tools/testing/selftests/bpf/prog_tests/check_mtu.c
> > create mode 100644 tools/testing/selftests/bpf/progs/test_check_mtu.c
> >
> > diff --git a/tools/testing/selftests/bpf/prog_tests/check_mtu.c b/tools/testing/selftests/bpf/prog_tests/check_mtu.c
> > new file mode 100644
> > index 000000000000..09b8f986a17b
> > --- /dev/null
> > +++ b/tools/testing/selftests/bpf/prog_tests/check_mtu.c
> > @@ -0,0 +1,37 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* Copyright (c) 2020 Red Hat */
> > +#include <uapi/linux/bpf.h>
> > +#include <linux/if_link.h>
> > +#include <test_progs.h>
> > +
> > +#include "test_check_mtu.skel.h"
> > +#define IFINDEX_LO 1
> > +
> > +void test_check_mtu_xdp(struct test_check_mtu *skel)
>
> this should be static func, otherwise it's treated as an independent selftest.
Ok, fixed.
> > +{
> > + int err = 0;
> > + int fd;
> > +
> > + fd = bpf_program__fd(skel->progs.xdp_use_helper);
> > + err = bpf_set_link_xdp_fd(IFINDEX_LO, fd, XDP_FLAGS_SKB_MODE);
> > + if (CHECK_FAIL(err))
>
> please use CHECK() or one of ASSERT_xxx() helpers. CHECK_FAIL() should
> be used for high-volume unlikely to fail test (i.e., very rarely).
I could not get CHECK() macro working. I now realize that this is
because I've not defined a global static variable named 'duration'.
static __u32 duration;
I wonder, are there any best-practice documentation or blogpost on
howto write these bpf-selftests?
Below signature is the compile error for others to Google for, and
solution above.
-
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
$ make
TEST-OBJ [test_progs] check_mtu.test.o
In file included from /home/jbrouer/git/kernel/bpf-next/tools/testing/selftests/bpf/prog_tests/check_mtu.c:6:
/home/jbrouer/git/kernel/bpf-next/tools/testing/selftests/bpf/prog_tests/check_mtu.c: In function ‘test_check_mtu’:
./test_progs.h:129:25: error: ‘duration’ undeclared (first use in this function)
129 | _CHECK(condition, tag, duration, format)
| ^~~~~~~~
./test_progs.h:111:25: note: in definition of macro ‘_CHECK’
111 | __func__, tag, duration); \
| ^~~~~~~~
/home/jbrouer/git/kernel/bpf-next/tools/testing/selftests/bpf/prog_tests/check_mtu.c:33:6: note: in expansion of macro ‘CHECK’
33 | if (CHECK(!skel, "open and load skel", "failed"))
| ^~~~~
./test_progs.h:129:25: note: each undeclared identifier is reported only once for each function it appears in
129 | _CHECK(condition, tag, duration, format)
| ^~~~~~~~
./test_progs.h:111:25: note: in definition of macro ‘_CHECK’
111 | __func__, tag, duration); \
| ^~~~~~~~
/home/jbrouer/git/kernel/bpf-next/tools/testing/selftests/bpf/prog_tests/check_mtu.c:33:6: note: in expansion of macro ‘CHECK’
33 | if (CHECK(!skel, "open and load skel", "failed"))
| ^~~~~
make: *** [Makefile:396: /home/jbrouer/git/kernel/bpf-next/tools/testing/selftests/bpf/check_mtu.test.o] Error 1
^ permalink raw reply
* Re: [PATCH 108/141] netfilter: ipt_REJECT: Fix fall-through warnings for Clang
From: Gustavo A. R. Silva @ 2020-11-24 14:37 UTC (permalink / raw)
To: Florian Westphal
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, David S. Miller,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Jakub Kicinski,
netfilter-devel, coreteam, netdev, linux-kernel, linux-hardening
In-Reply-To: <20201120224905.GS15137@breakpoint.cc>
On Fri, Nov 20, 2020 at 11:49:05PM +0100, Florian Westphal wrote:
> Gustavo A. R. Silva <gustavoars@kernel.org> wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
>
> Acked-by: Florian Westphal <fw@strlen.de>
Thanks, Florian.
--
Gustavo
^ permalink raw reply
* [PATCH] net: phy: fix auto-negotiation in case of 'down-shift'
From: Antonio Borneo @ 2020-11-24 14:38 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Jakub Kicinski, netdev, Yonglong Liu
Cc: Antonio Borneo, stable, linuxarm, Salil Mehta, linux-stm32,
linux-kernel
If the auto-negotiation fails to establish a gigabit link, the phy
can try to 'down-shift': it resets the bits in MII_CTRL1000 to
stop advertising 1Gbps and retries the negotiation at 100Mbps.
From commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode
in genphy_read_status") the content of MII_CTRL1000 is not checked
anymore at the end of the negotiation, preventing the detection of
phy 'down-shift'.
In case of 'down-shift' phydev->advertising gets out-of-sync wrt
MII_CTRL1000 and still includes modes that the phy have already
dropped. The link partner could still advertise higher speeds,
while the link is established at one of the common lower speeds.
The logic 'and' in phy_resolve_aneg_linkmode() between
phydev->advertising and phydev->lp_advertising will report an
incorrect mode.
Issue detected with a local phy rtl8211f connected with a gigabit
capable router through a two-pairs network cable.
After auto-negotiation, read back MII_CTRL1000 and mask-out from
phydev->advertising the modes that have been eventually discarded
due to the 'down-shift'.
Fixes: 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
Cc: stable@vger.kernel.org # v5.1+
Signed-off-by: Antonio Borneo <antonio.borneo@st.com>
Link: https://lore.kernel.org/r/478f871a-583d-01f1-9cc5-2eea56d8c2a7@huawei.com
---
To: Andrew Lunn <andrew@lunn.ch>
To: Heiner Kallweit <hkallweit1@gmail.com>
To: Russell King <linux@armlinux.org.uk>
To: "David S. Miller" <davem@davemloft.net>
To: Jakub Kicinski <kuba@kernel.org>
To: netdev@vger.kernel.org
To: Yonglong Liu <liuyonglong@huawei.com>
Cc: linuxarm@huawei.com
Cc: Salil Mehta <salil.mehta@huawei.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-kernel@vger.kernel.org
Cc: Antonio Borneo <antonio.borneo@st.com>
drivers/net/phy/phy_device.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 5dab6be6fc38..5d1060aa1b25 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -2331,7 +2331,7 @@ EXPORT_SYMBOL(genphy_read_status_fixed);
*/
int genphy_read_status(struct phy_device *phydev)
{
- int err, old_link = phydev->link;
+ int adv, err, old_link = phydev->link;
/* Update the link, but return if there was an error */
err = genphy_update_link(phydev);
@@ -2356,6 +2356,14 @@ int genphy_read_status(struct phy_device *phydev)
return err;
if (phydev->autoneg == AUTONEG_ENABLE && phydev->autoneg_complete) {
+ if (phydev->is_gigabit_capable) {
+ adv = phy_read(phydev, MII_CTRL1000);
+ if (adv < 0)
+ return adv;
+ /* update advertising in case of 'down-shift' */
+ mii_ctrl1000_mod_linkmode_adv_t(phydev->advertising,
+ adv);
+ }
phy_resolve_aneg_linkmode(phydev);
} else if (phydev->autoneg == AUTONEG_DISABLE) {
err = genphy_read_status_fixed(phydev);
base-commit: d549699048b4b5c22dd710455bcdb76966e55aa3
--
2.29.2
^ permalink raw reply related
* Re: [PATCH] [v7] wireless: Initial driver submission for pureLiFi STA devices
From: Kalle Valo @ 2020-11-24 14:44 UTC (permalink / raw)
To: Srinivasan Raju
In-Reply-To: <20201116092253.1302196-1-srini.raju@purelifi.com>
Srinivasan Raju <srini.raju@purelifi.com> wrote:
> This introduces the pureLiFi LiFi driver for LiFi-X, LiFi-XC
> and LiFi-XL USB devices.
>
> This driver implementation has been based on the zd1211rw driver.
>
> Driver is based on 802.11 softMAC Architecture and uses
> native 802.11 for configuration and management.
>
> The driver is compiled and tested in ARM, x86 architectures and
> compiled in powerpc architecture.
>
> Signed-off-by: Srinivasan Raju <srini.raju@purelifi.com>
>
> Changes v6->v7:
> - Magic numbers removed and used IEEE80211 macors
> - usb.c is split into two files firmware.c and dbgfs.c
> - Other code style and timer function fixes (mod_timer)
> Changes v5->v6:
> - Code style fix patch from Joe Perches
> Changes v4->v5:
> - Code refactoring for clarity and redundnacy removal
> - Fix warnings from kernel test robot
> Changes v3->v4:
> - Code refactoring based on kernel code guidelines
> - Remove multi level macors and use kernel debug macros
> Changes v2->v3:
> - Code style fixes kconfig fix
> Changes v1->v2:
> - v1 was submitted to staging, v2 submitted to wireless-next
> - Code style fixes and copyright statement fix
I haven't had a chance to review this yet but we have some documentation for new drivers:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#new_driver
Is the firmware publically available?
--
https://patchwork.kernel.org/project/linux-wireless/patch/20201116092253.1302196-1-srini.raju@purelifi.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 000/141] Fix fall-through warnings for Clang
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan,
keyrings, linux1394-devel, linux-acpi, linux-afs,
linux-arm-kernel, linux-arm-msm, linux-atm-general, linux-block,
linux-can, linux-cifs, linux-crypto, linux-decnet-user,
linux-ext4, linux-fbdev, linux-geode, linux-gpio, linux-hams,
linux-hwmon, linux-i3c, linux-ide, linux-iio, linux-input,
linux-integrity, linux-mediatek, linux-media, linux-mmc, linux-mm,
linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
linux-sctp, linux-security-module, linux-stm32, linux-usb,
linux-watchdog, linux-wireless, netdev, netfilter-devel, nouveau,
op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
samba-technical, selinux, target-devel, tipc-discussion,
usb-storage, virtualization, wcn36xx, x86, xen-devel,
linux-hardening, Nick Desaulniers, Nathan Chancellor,
Miguel Ojeda, Joe Perches, Kees Cook
In-Reply-To: <20201123200345.GA38546@nvidia.com>
On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
>
> > IB/hfi1: Fix fall-through warnings for Clang
> > IB/mlx4: Fix fall-through warnings for Clang
> > IB/qedr: Fix fall-through warnings for Clang
> > RDMA/mlx5: Fix fall-through warnings for Clang
>
> I picked these four to the rdma tree, thanks
Awesome. :)
Thank you, Jason.
--
Gustavo
^ permalink raw reply
* Re: [PATCH 000/141] Fix fall-through warnings for Clang
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
To: Mark Brown
Cc: linux-kernel, linux-crypto, linux-sctp, Nathan Chancellor,
linux-hardening, usb-storage, linux-block, linux-security-module,
bridge, GR-Linux-NIC-Dev, rds-devel, dri-devel, linux-media,
wcn36xx, linux-wireless, linux-mediatek, reiserfs-devel,
oss-drivers, linux-arm-kernel, alsa-devel, virtualization,
Joe Perches, patches, linux-gpio, linux-hwmon, linux-cifs,
coreteam, Kees Cook, Nick Desaulniers, linux-scsi, linux-afs,
netfilter-devel, linux-geode, drbd-dev, linux-ext4, linux-hams,
target-devel, samba-technical, tipc-discussion, linux-stm32,
linux-renesas-soc, linux-input, amd-gfx, linux-nfs, devel,
selinux, linux-atm-general, linux-iio, linux-i3c, Miguel Ojeda,
linux-can, linux-integrity, GR-everest-linux-l2, keyrings,
intel-wired-lan, linux-usb, nouveau, x86, xen-devel, linux-mm,
cluster-devel, linux1394-devel, linux-decnet-user, op-tee,
linux-ide, intel-gfx, linux-acpi, dm-devel, linux-watchdog,
linux-rdma, linux-mtd, ceph-devel, linux-arm-msm, linux-mmc,
linux-fbdev, netdev
In-Reply-To: <160616392671.21180.16517492185091399884.b4-ty@kernel.org>
On Mon, Nov 23, 2020 at 08:38:46PM +0000, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> >
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> >
> > [...]
>
> Applied to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
>
> Thanks!
>
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
> commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5
Thank you, Mark.
--
Gustavo
^ permalink raw reply
* RE: [PATCH v4 6/6] igb: avoid transmit queue timeout in xdp path
From: Penigalapati, Sandeep @ 2020-11-24 14:49 UTC (permalink / raw)
To: sven.auhagen@voleatech.de, Nguyen, Anthony L, Fijalkowski, Maciej,
kuba@kernel.org
Cc: davem@davemloft.net, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
brouer@redhat.com, pmenzel@molgen.mpg.de
In-Reply-To: <20201111170453.32693-7-sven.auhagen@voleatech.de>
From: sven.auhagen@voleatech.de <sven.auhagen@voleatech.de>
Sent: Wednesday, November 11, 2020 10:35 PM
To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Fijalkowski, Maciej <maciej.fijalkowski@intel.com>; kuba@kernel.org
Cc: davem@davemloft.net; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; nhorman@redhat.com; sassmann@redhat.com; Penigalapati, Sandeep <sandeep.penigalapati@intel.com>; brouer@redhat.com; pmenzel@molgen.mpg.de
Subject: [PATCH v4 6/6] igb: avoid transmit queue timeout in xdp path
From: Sven Auhagen <sven.auhagen@voleatech.de>
Since we share the transmit queue with the network stack, it is possible that we run into a transmit queue timeout.
This will reset the queue.
This happens under high load when XDP is using the transmit queue pretty much exclusively.
netdev_start_xmit() sets the trans_start variable of the transmit queue to jiffies which is later utilized by dev_watchdog(), so to avoid timeout, let stack know that XDP xmit happened by bumping the trans_start within XDP Tx routines to jiffies.
Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de>
---
drivers/net/ethernet/intel/igb/igb_main.c | 5 +++++
1 file changed, 5 insertions(+)
Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com>
^ permalink raw reply
* Re: [PATCH] net: phy: fix auto-negotiation in case of 'down-shift'
From: Russell King - ARM Linux admin @ 2020-11-24 14:56 UTC (permalink / raw)
To: Antonio Borneo
Cc: Andrew Lunn, Heiner Kallweit, David S. Miller, Jakub Kicinski,
netdev, Yonglong Liu, stable, linuxarm, Salil Mehta, linux-stm32,
linux-kernel
In-Reply-To: <20201124143848.874894-1-antonio.borneo@st.com>
On Tue, Nov 24, 2020 at 03:38:48PM +0100, Antonio Borneo wrote:
> If the auto-negotiation fails to establish a gigabit link, the phy
> can try to 'down-shift': it resets the bits in MII_CTRL1000 to
> stop advertising 1Gbps and retries the negotiation at 100Mbps.
>
> From commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode
> in genphy_read_status") the content of MII_CTRL1000 is not checked
> anymore at the end of the negotiation, preventing the detection of
> phy 'down-shift'.
> In case of 'down-shift' phydev->advertising gets out-of-sync wrt
> MII_CTRL1000 and still includes modes that the phy have already
> dropped. The link partner could still advertise higher speeds,
> while the link is established at one of the common lower speeds.
> The logic 'and' in phy_resolve_aneg_linkmode() between
> phydev->advertising and phydev->lp_advertising will report an
> incorrect mode.
>
> Issue detected with a local phy rtl8211f connected with a gigabit
> capable router through a two-pairs network cable.
>
> After auto-negotiation, read back MII_CTRL1000 and mask-out from
> phydev->advertising the modes that have been eventually discarded
> due to the 'down-shift'.
Sorry, but no. While your solution will appear to work, in
introduces unexpected changes to the user visible APIs.
> if (phydev->autoneg == AUTONEG_ENABLE && phydev->autoneg_complete) {
> + if (phydev->is_gigabit_capable) {
> + adv = phy_read(phydev, MII_CTRL1000);
> + if (adv < 0)
> + return adv;
> + /* update advertising in case of 'down-shift' */
> + mii_ctrl1000_mod_linkmode_adv_t(phydev->advertising,
> + adv);
If a down-shift occurs, this will cause the configured advertising
mask to lose the 1G speed, which will be visible to userspace.
Userspace doesn't expect the advertising mask to change beneath it.
Since updates from userspace are done using a read-modify-write of
the ksettings, this can have the undesired effect of removing 1G
from the configured advertising mask.
We've had other PHYs have this behaviour; the correct solution is for
the PHY driver to implement reading the resolution from the PHY rather
than relying on the generic implementation if it can down-shift.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: cw1200: replace a set of atomic_add()
From: Kalle Valo @ 2020-11-24 14:59 UTC (permalink / raw)
To: Yejune Deng
Cc: pizza, davem, kuba, linux-wireless, netdev, linux-kernel,
yejune.deng
In-Reply-To: <1604991491-27908-1-git-send-email-yejune.deng@gmail.com>
Yejune Deng <yejune.deng@gmail.com> wrote:
> a set of atomic_inc() looks more readable
>
> Signed-off-by: Yejune Deng <yejune.deng@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
07f995ca1951 cw1200: replace a set of atomic_add()
--
https://patchwork.kernel.org/project/linux-wireless/patch/1604991491-27908-1-git-send-email-yejune.deng@gmail.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] brcmfmac: fix error return code in brcmf_cfg80211_connect()
From: Kalle Valo @ 2020-11-24 15:00 UTC (permalink / raw)
To: Zhang Changzhong
Cc: arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, davem, kuba, stanley.hsu, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, netdev, linux-kernel
In-Reply-To: <1605248896-16812-1-git-send-email-zhangchangzhong@huawei.com>
Zhang Changzhong <zhangchangzhong@huawei.com> wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: 3b1e0a7bdfee ("brcmfmac: add support for SAE authentication offload")
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
> Reviewed-by: Chi-hsien Lin <chi-hsien.lin@infineon.com>
Patch applied to wireless-drivers-next.git, thanks.
37ff144d29ac brcmfmac: fix error return code in brcmf_cfg80211_connect()
--
https://patchwork.kernel.org/project/linux-wireless/patch/1605248896-16812-1-git-send-email-zhangchangzhong@huawei.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net] qtnfmac: fix error return code in qtnf_pcie_probe()
From: Kalle Valo @ 2020-11-24 15:03 UTC (permalink / raw)
To: Wang Hai
Cc: davem, kuba, imitsyanko, geomatsi, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20201114123347.29632-1-wanghai38@huawei.com>
Wang Hai <wanghai38@huawei.com> wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: b7da53cd6cd1 ("qtnfmac_pcie: use single PCIe driver for all platforms")
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Wang Hai <wanghai38@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
31e07aa33fa7 qtnfmac: fix error return code in qtnf_pcie_probe()
--
https://patchwork.kernel.org/project/linux-wireless/patch/20201114123347.29632-1-wanghai38@huawei.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] net: phy: fix auto-negotiation in case of 'down-shift'
From: Heiner Kallweit @ 2020-11-24 15:03 UTC (permalink / raw)
To: Antonio Borneo, Andrew Lunn, Russell King, David S. Miller,
Jakub Kicinski, netdev, Yonglong Liu
Cc: stable, linuxarm, Salil Mehta, linux-stm32, linux-kernel
In-Reply-To: <20201124143848.874894-1-antonio.borneo@st.com>
Am 24.11.2020 um 15:38 schrieb Antonio Borneo:
> If the auto-negotiation fails to establish a gigabit link, the phy
> can try to 'down-shift': it resets the bits in MII_CTRL1000 to
> stop advertising 1Gbps and retries the negotiation at 100Mbps.
>
I see that Russell answered already. My 2cts:
Are you sure all PHY's supporting downshift adjust the
advertisement bits? IIRC an Aquantia PHY I dealt with does not.
And if a PHY does so I'd consider this problematic:
Let's say you have a broken cable and the PHY downshifts to
100Mbps. If you change the cable then the PHY would still negotiate
100Mbps only.
Also I think phydev->advertising reflects what the user wants to
advertise, as mentioned by Russell before.
>>From commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode
> in genphy_read_status") the content of MII_CTRL1000 is not checked
> anymore at the end of the negotiation, preventing the detection of
> phy 'down-shift'.
> In case of 'down-shift' phydev->advertising gets out-of-sync wrt
> MII_CTRL1000 and still includes modes that the phy have already
> dropped. The link partner could still advertise higher speeds,
> while the link is established at one of the common lower speeds.
> The logic 'and' in phy_resolve_aneg_linkmode() between
> phydev->advertising and phydev->lp_advertising will report an
> incorrect mode.
>
> Issue detected with a local phy rtl8211f connected with a gigabit
> capable router through a two-pairs network cable.
>
> After auto-negotiation, read back MII_CTRL1000 and mask-out from
> phydev->advertising the modes that have been eventually discarded
> due to the 'down-shift'.
>
> Fixes: 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
> Cc: stable@vger.kernel.org # v5.1+
> Signed-off-by: Antonio Borneo <antonio.borneo@st.com>
> Link: https://lore.kernel.org/r/478f871a-583d-01f1-9cc5-2eea56d8c2a7@huawei.com
> ---
> To: Andrew Lunn <andrew@lunn.ch>
> To: Heiner Kallweit <hkallweit1@gmail.com>
> To: Russell King <linux@armlinux.org.uk>
> To: "David S. Miller" <davem@davemloft.net>
> To: Jakub Kicinski <kuba@kernel.org>
> To: netdev@vger.kernel.org
> To: Yonglong Liu <liuyonglong@huawei.com>
> Cc: linuxarm@huawei.com
> Cc: Salil Mehta <salil.mehta@huawei.com>
> Cc: linux-stm32@st-md-mailman.stormreply.com
> Cc: linux-kernel@vger.kernel.org
> Cc: Antonio Borneo <antonio.borneo@st.com>
>
> drivers/net/phy/phy_device.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 5dab6be6fc38..5d1060aa1b25 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -2331,7 +2331,7 @@ EXPORT_SYMBOL(genphy_read_status_fixed);
> */
> int genphy_read_status(struct phy_device *phydev)
> {
> - int err, old_link = phydev->link;
> + int adv, err, old_link = phydev->link;
>
> /* Update the link, but return if there was an error */
> err = genphy_update_link(phydev);
> @@ -2356,6 +2356,14 @@ int genphy_read_status(struct phy_device *phydev)
> return err;
>
> if (phydev->autoneg == AUTONEG_ENABLE && phydev->autoneg_complete) {
> + if (phydev->is_gigabit_capable) {
> + adv = phy_read(phydev, MII_CTRL1000);
> + if (adv < 0)
> + return adv;
> + /* update advertising in case of 'down-shift' */
> + mii_ctrl1000_mod_linkmode_adv_t(phydev->advertising,
> + adv);
> + }
> phy_resolve_aneg_linkmode(phydev);
> } else if (phydev->autoneg == AUTONEG_DISABLE) {
> err = genphy_read_status_fixed(phydev);
>
> base-commit: d549699048b4b5c22dd710455bcdb76966e55aa3
>
^ permalink raw reply
* Re: [PATCH] brcmsmac: ampdu: Check BA window size before checking block ack
From: Kalle Valo @ 2020-11-24 15:04 UTC (permalink / raw)
To: Dmitry Safonov
Cc: linux-kernel, Dmitry Safonov, Arend van Spriel, Franky Lin,
Hante Meuleman, Chi-Hsien Lin, Wright Feng, David S. Miller,
Jakub Kicinski, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, netdev, Dmitry Safonov, Yuji Nakao
In-Reply-To: <20201116030635.645811-1-dima@arista.com>
Dmitry Safonov <dima@arista.com> wrote:
> bindex can be out of BA window (64):
> tid 0 seq 2983, start_seq 2915, bindex 68, index 39
> tid 0 seq 2984, start_seq 2915, bindex 69, index 40
> tid 0 seq 2985, start_seq 2915, bindex 70, index 41
> tid 0 seq 2986, start_seq 2915, bindex 71, index 42
> tid 0 seq 2879, start_seq 2915, bindex 4060, index 63
> tid 0 seq 2854, start_seq 2915, bindex 4035, index 38
> tid 0 seq 2795, start_seq 2915, bindex 3976, index 43
> tid 0 seq 2989, start_seq 2924, bindex 65, index 45
> tid 0 seq 2992, start_seq 2924, bindex 68, index 48
> tid 0 seq 2993, start_seq 2924, bindex 69, index 49
> tid 0 seq 2994, start_seq 2924, bindex 70, index 50
> tid 0 seq 2997, start_seq 2924, bindex 73, index 53
> tid 0 seq 2795, start_seq 2941, bindex 3950, index 43
> tid 0 seq 2921, start_seq 2941, bindex 4076, index 41
> tid 0 seq 2929, start_seq 2941, bindex 4084, index 49
> tid 0 seq 3011, start_seq 2946, bindex 65, index 3
> tid 0 seq 3012, start_seq 2946, bindex 66, index 4
> tid 0 seq 3013, start_seq 2946, bindex 67, index 5
>
> In result isset() will try to dereference something on the stack,
> causing panics:
> BUG: unable to handle page fault for address: ffffa742800ed01f
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page
> PGD 6a4e9067 P4D 6a4e9067 PUD 6a4ec067 PMD 6a4ed067 PTE 0
> Oops: 0000 [#1] PREEMPT SMP PTI
> CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Not tainted 5.8.5-arch1-1-kdump #1
> Hardware name: Apple Inc. MacBookAir3,1/Mac-942452F5819B1C1B, BIOS MBA31.88Z.0061.B07.1201241641 01/24/12
> RIP: 0010:brcms_c_ampdu_dotxstatus+0x343/0x9f0 [brcmsmac]
> Code: 54 24 20 66 81 e2 ff 0f 41 83 e4 07 89 d1 0f b7 d2 66 c1 e9 03 0f b7 c9 4c 8d 5c 0c 48 49 8b 4d 10 48 8b 79 68 41 57 44 89 e1 <41> 0f b6 33 41 d3 e0 48 c7 c1 38 e0 ea c0 48 83 c7 10 44 21 c6 4c
> RSP: 0018:ffffa742800ecdd0 EFLAGS: 00010207
> RAX: 0000000000000019 RBX: 000000000000000b RCX: 0000000000000006
> RDX: 0000000000000ffe RSI: 0000000000000004 RDI: ffff8fc6ad776800
> RBP: ffff8fc6855acb00 R08: 0000000000000001 R09: 00000000000005d9
> R10: 00000000fffffffe R11: ffffa742800ed01f R12: 0000000000000006
> R13: ffff8fc68d75a000 R14: 00000000000005db R15: 0000000000000019
> FS: 0000000000000000(0000) GS:ffff8fc6aad00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffffa742800ed01f CR3: 000000002480a000 CR4: 00000000000406e0
> Call Trace:
> <IRQ>
> brcms_c_dpc+0xb46/0x1020 [brcmsmac]
> ? wlc_intstatus+0xc8/0x180 [brcmsmac]
> ? __raise_softirq_irqoff+0x1a/0x80
> brcms_dpc+0x37/0xd0 [brcmsmac]
> tasklet_action_common.constprop.0+0x51/0xb0
> __do_softirq+0xff/0x340
> ? handle_level_irq+0x1a0/0x1a0
> asm_call_on_stack+0x12/0x20
> </IRQ>
> do_softirq_own_stack+0x5f/0x80
> irq_exit_rcu+0xcb/0x120
> common_interrupt+0xd1/0x200
> asm_common_interrupt+0x1e/0x40
> RIP: 0010:cpuidle_enter_state+0xb3/0x420
>
> Check if the block is within BA window and only then check block's
> status. Otherwise as Behan wrote: "When I came back to Dublin I
> was courtmartialed in my absence and sentenced to death in my absence,
> so I said they could shoot me in my absence."
>
> Also reported:
> https://bbs.archlinux.org/viewtopic.php?id=258428
> https://lore.kernel.org/linux-wireless/87tuwgi92n.fsf@yujinakao.com/
>
> Reported-by: Yuji Nakao <contact@yujinakao.com>
> Signed-off-by: Dmitry Safonov <dima@arista.com>
Patch applied to wireless-drivers-next.git, thanks.
01c195de620b brcmsmac: ampdu: Check BA window size before checking block ack
--
https://patchwork.kernel.org/project/linux-wireless/patch/20201116030635.645811-1-dima@arista.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rsi: fix error return code in rsi_reset_card()
From: Kalle Valo @ 2020-11-24 15:05 UTC (permalink / raw)
To: Zhang Changzhong
Cc: amitkarwar, siva8118, davem, kuba, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1605582454-39649-1-git-send-email-zhangchangzhong@huawei.com>
Zhang Changzhong <zhangchangzhong@huawei.com> wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: 17ff2c794f39 ("rsi: reset device changes for 9116")
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
fb21d14694bd rsi: fix error return code in rsi_reset_card()
--
https://patchwork.kernel.org/project/linux-wireless/patch/1605582454-39649-1-git-send-email-zhangchangzhong@huawei.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH][next] mwifiex: Fix fall-through warnings for Clang
From: Kalle Valo @ 2020-11-24 15:06 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Amitkumar Karwar, Ganapathi Bhat, Xinming Hu, David S. Miller,
Jakub Kicinski, linux-wireless, netdev, linux-kernel,
Gustavo A. R. Silva, linux-hardening
In-Reply-To: <20201117160958.GA18807@embeddedor>
"Gustavo A. R. Silva" <gustavoars@kernel.org> wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple break statements instead of
> letting the code fall through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Patch applied to wireless-drivers-next.git, thanks.
003317581372 mwifiex: Fix fall-through warnings for Clang
--
https://patchwork.kernel.org/project/linux-wireless/patch/20201117160958.GA18807@embeddedor/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 1/4 resend] rtlwifi: rtl8188ee: avoid accessing the data mapped to streaming DMA
From: Kalle Valo @ 2020-11-24 15:07 UTC (permalink / raw)
To: Jia-Ju Bai
Cc: pkshih, davem, kuba, Larry.Finger, linux-wireless, netdev,
linux-kernel, Jia-Ju Bai
In-Reply-To: <20201119015127.12033-1-baijiaju1990@gmail.com>
Jia-Ju Bai <baijiaju1990@gmail.com> wrote:
> In rtl88ee_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on
> line 677:
> dma_addr_t mapping = dma_map_single(..., skb->data, ...);
>
> On line 680, skb->data is assigned to hdr after cast:
> struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);
>
> Then hdr->frame_control is accessed on line 681:
> __le16 fc = hdr->frame_control;
>
> This DMA access may cause data inconsistency between CPU and hardwre.
>
> To fix this bug, hdr->frame_control is accessed before the DMA mapping.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
4 patches applied to wireless-drivers-next.git, thanks.
6df3c293d284 rtlwifi: rtl8188ee: avoid accessing the data mapped to streaming DMA
c7ba0ea0df37 rtlwifi: rtl8192ce: avoid accessing the data mapped to streaming DMA
ff7654833894 rtlwifi: rtl8192de: avoid accessing the data mapped to streaming DMA
8b2c13b2e5da rtlwifi: rtl8723ae: avoid accessing the data mapped to streaming DMA
--
https://patchwork.kernel.org/project/linux-wireless/patch/20201119015127.12033-1-baijiaju1990@gmail.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwifiex: Remove duplicated REG_PORT definition
From: Kalle Valo @ 2020-11-24 15:07 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Amitkumar Karwar, Ganapathi Bhat, Xinming Hu, David S. Miller,
Jakub Kicinski, linux-wireless, netdev, linux-kernel
In-Reply-To: <20201119101204.72fd5f0a@xhacker.debian>
Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
> The REG_PORT is defined twice, so remove one of them.
>
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Patch applied to wireless-drivers-next.git, thanks.
3c72d3843e22 mwifiex: Remove duplicated REG_PORT definition
--
https://patchwork.kernel.org/project/linux-wireless/patch/20201119101204.72fd5f0a@xhacker.debian/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: cw1200: fix missing destroy_workqueue() on error in cw1200_init_common
From: Kalle Valo @ 2020-11-24 15:08 UTC (permalink / raw)
To: Qinglang Miao
Cc: Solomon Peachy, David S. Miller, Jakub Kicinski, linux-wireless,
netdev, linux-kernel, Qinglang Miao
In-Reply-To: <20201119070842.1011-1-miaoqinglang@huawei.com>
Qinglang Miao <miaoqinglang@huawei.com> wrote:
> Add the missing destroy_workqueue() before return from
> cw1200_init_common in the error handling case.
>
> Fixes: a910e4a94f69 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets")
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
7ec8a926188e cw1200: fix missing destroy_workqueue() on error in cw1200_init_common
--
https://patchwork.kernel.org/project/linux-wireless/patch/20201119070842.1011-1-miaoqinglang@huawei.com/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net-next 0/2] TLS TX HW offload for Bond
From: Tariq Toukan @ 2020-11-24 15:08 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Jarod Wilson, Tariq Toukan, David S. Miller, netdev,
Saeed Mahameed, Moshe Shemesh, Maor Gottlieb
In-Reply-To: <20201123102040.338f32c7@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On 11/23/2020 8:20 PM, Jakub Kicinski wrote:
> On Sun, 22 Nov 2020 14:48:04 +0200 Tariq Toukan wrote:
>> On 11/19/2020 6:38 PM, Jakub Kicinski wrote:
>>> On Thu, 19 Nov 2020 17:59:38 +0200 Tariq Toukan wrote:
>>>> On 11/19/2020 2:02 AM, Jakub Kicinski wrote:
>>>>> On Sun, 15 Nov 2020 15:42:49 +0200 Tariq Toukan wrote:
>>>>>> This series opens TLS TX HW offload for bond interfaces.
>>>>>> This allows bond interfaces to benefit from capable slave devices.
>>>>>>
>>>>>> The first patch adds real_dev field in TLS context structure, and aligns
>>>>>> usages in TLS module and supporting drivers.
>>>>>> The second patch opens the offload for bond interfaces.
>>>>>>
>>>>>> For the configuration above, SW kTLS keeps picking the same slave
>>>>>> To keep simple track of the HW and SW TLS contexts, we bind each socket to
>>>>>> a specific slave for the socket's whole lifetime. This is logically valid
>>>>>> (and similar to the SW kTLS behavior) in the following bond configuration,
>>>>>> so we restrict the offload support to it:
>>>>>>
>>>>>> ((mode == balance-xor) or (mode == 802.3ad))
>>>>>> and xmit_hash_policy == layer3+4.
>>>>>
>>>>> This does not feel extremely clean, maybe you can convince me otherwise.
>>>>>
>>>>> Can we extend netdev_get_xmit_slave() and figure out the output dev
>>>>> (and if it's "stable") in a more generic way? And just feed that dev
>>>>> into TLS handling?
>>>>
>>>> I don't see we go through netdev_get_xmit_slave(), but through
>>>> .ndo_start_xmit (bond_start_xmit).
>>>
>>> I may be misunderstanding the purpose of netdev_get_xmit_slave(),
>>> please correct me if I'm wrong. AFAIU it's supposed to return a
>>> lower netdev that the skb should then be xmited on.
>>
>> That's true. It was recently added and used by the RDMA team. Not used
>> or integrated in the Eth networking stack.
>>
>>> So what I was thinking was either construct an skb or somehow reshuffle
>>> the netdev_get_xmit_slave() code to take a flow dissector output or
>>> ${insert other ideas}. Then add a helper in the core that would drill
>>> down from the socket netdev to the "egress" netdev. Have TLS call
>>> that helper, and talk to the "egress" netdev from the start, rather
>>> than the socket's netdev. Then loosen the checks on software devices.
>>
>> As I understand it, best if we can even generalize this to apply to all
>> kinds of traffic: bond driver won't do the xmit itself anymore, it just
>> picks an egress dev and returns it. The core infrastructure will call
>> the xmit function for the egress dev.
>
> I think you went way further than I was intending :) I was only
> considering the control path. Leave the datapath unchanged.
>
> AFAIK you're making 3 changes:
> - forwarding tls ops
> - pinning flows
> - handling features
>
> Pinning of the TLS device to a leg of the bond looks like ~15LoC.
> I think we can live with that.
>
Good.
You mean the changes under __bond_start_xmit ?
> It's the 150 LoC of forwarding TLS ops and duplicating dev selection
> logic in bond_sk_hash_l34() that I'd rather avoid.
>
I see.
But there are several issues with this:
1. The .ndo_get_xmit_slave acts on an SKB, not a socket. Hence, it
doesn't fit for the stage of calling tls_dev_add, unless the ndo goes
through some refactoring before the feature itself.
2. Existing hash logic acts on an SKB. We must have one that acts on a
socket to be used inside get_slave(sk). Hence, I don't really see how
the logic under bond_sk_hash_l34() are going to disappear, maybe just
move around to a new place.
> Handling features is probably fine, too, I haven't thought about that
> much.
>
Good.
>> I like the idea, it can generalize code structures for all kinds of
>> upper-devices and sockets, taking them into a common place in core,
>> which reduces code duplications.
>>
>> If we go only half the way, i.e. keep xmit logic in bond for
>> non-TLS-offloaded traffic, then we have to let TLS module (and others in
>> the future) act deferentially for different kinds of devs (upper/lower)
>> which IMHO reduces generality.
>
> How so? I was expecting TLS to just do something like:
>
> netdev = sk_get_xmit_dev_lowest(sk);
>
> which would recursively call get_xmit_slave(CONST) until it reaches
> a device which doesn't resolve further.
>
> BTW is the flow pinning to bond legs actually a must-do? I don't know
> much about bonding but wouldn't that mean that if the selected leg goes
> down we'd lose connectivity, rather than falling back to SW crypto?
>
Right. As long as we don't have logic for un-offloading.
Currently in TLS, the device-offloaded connections has some
"independence" once they are created, it's hard to modify them and apply
configuration modifications to them (example: interaction with tx csum
offload).
So I think there is a missing un-offloading mechanism in TLS that should
address all of these together.
This fits with your comments below.
>> I'm in favor of the deeper change. It will be on a larger scale, and
>> totally orthogonal to the current TLS offload support in bond.
>>
>> If we decide to apply the idea only to TLS sockets (or any subset of
>> sockets) we're actually taking a generic one-flow (the xmit patch of a
>> bond dev) and turning it into two (or potentially more) flows, depending
>> on the socket type. This also reduces generality.
>
> I don't follow this part.
>
>>> I'm probably missing the problem you're trying to explain to me :S
>>
>> I kept the patch minimal, and kept the TLS offload logic internal to the
>> bond driver, just like it is internal to the device drivers (mlx5e, and
>> others), with no core infrastructure modification.
>>
>>> Side note - Jarod, I'd be happy to take a patch renaming
>>> netdev_get_xmit_slave() and the ndo, if you have the cycles to send
>>> a patch. It's a recent addition, and in the core we should make more
>>> of an effort to avoid sensitive terms.
>>>
>>>> Currently I have my check there to
>>>> catch all skbs belonging to offloaded TLS sockets.
>>>>
>>>> The TLS offload get_slave() logic decision is per socket, so the result
>>>> cannot be saved in the bond memory. Currently I save the real_dev field
>>>> in the TLS context structure.
>>>
>>> Right, but we could just have ctx->netdev be the "egress" netdev
>>> always, right? Do we expect somewhere that it's going to be matching
>>> the socket's dst?
>>
>> So once the offload context is established we totally bypass the bond
>> dev? and lose interaction or reference to it?
>
> Yup, I don't think we need it.
>
>> What if the egress dev is detached form the bond? We must then be
>> notified somehow.
>
> Do we notify TLS when routing changes? I think it's a separate topic.
>
> If we have the code to "un-offload" a flow we could handle clearing
> features better and notify from sk_validate_xmit_skb that the flow
> started hitting unexpected dev, hence it should be re-offloaded.
>
> I don't think we need an explicit invalidation from the particular
> drivers here.
>
Agree.
^ 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