* Re: [PATCH 2/2] RTL8153-BD is used in Dell DA300 type-C dongle. It should be added to the whitelist of devices to activate MAC address pass through.
From: David Chen @ 2019-02-18 8:24 UTC (permalink / raw)
To: Oliver Neukum
Cc: linux-kernel, linux-usb, netdev, kai.heng.feng, davem,
david.chen7, mario.limonciello, f.fainelli, edumazet, zhongjiang,
bigeasy, hayeswang, jslaby
In-Reply-To: <1550477077.11088.2.camel@suse.com>
Hi Oliver,
Thanks for reviewing. I have made some mistake, will correct it and resend.
Thanks and Regards,
-David
> Oliver Neukum <oneukum@suse.com> 於 2019年2月18日 下午4:04 寫道：
>
>> On Mo, 2019-02-18 at 11:48 +0800, David Chen wrote:
>> From: David Chen <david.chen7@dell.com>
>>
>> Per confirming with Realtek all devices containing RTL8153-BD should
>> activate MAC pass through and there won't use pass through bit on efuse
>> like in RTL8153-AD.
>>
>> Signed-off-by: David Chen <david.chen7@dell.com>
>> ---
>> drivers/net/usb/r8152.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
>> index ada6baf8847a..86c8c64fbb0f 100644
>> --- a/drivers/net/usb/r8152.c
>> +++ b/drivers/net/usb/r8152.c
>> @@ -1179,7 +1179,7 @@ static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
>> } else {
>> /* test for RTL8153-BND and RTL8153-BD */
>> ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_MISC_1);
>> - if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK)) {
>> + if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK) == 0) {
>
> You are inverting the second half of the test. How can this possibly be
> right? Had you dropped it, I would understand. But this? Are you sure?
>
> Regards
> Oliver
>
^ permalink raw reply
* Re: [PATCH bpf-next v4 0/2] libbpf: adding AF_XDP support
From: Magnus Karlsson @ 2019-02-18 8:20 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jesper Dangaard Brouer, Jonathan Lemon, Magnus Karlsson,
Björn Töpel, ast, Network Development, Jakub Kicinski,
Björn Töpel, Zhang, Qi Z, xiaolong.ye,
xdp-newbies@vger.kernel.org
In-Reply-To: <20ba7719-b660-462c-a6bf-6c749e1f2f30@iogearbox.net>
On Fri, Feb 15, 2019 at 5:48 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 02/13/2019 12:55 PM, Jesper Dangaard Brouer wrote:
> > On Wed, 13 Feb 2019 12:32:47 +0100
> > Magnus Karlsson <magnus.karlsson@gmail.com> wrote:
> >> On Mon, Feb 11, 2019 at 9:44 PM Jonathan Lemon <jonathan.lemon@gmail.com> wrote:
> >>> On 8 Feb 2019, at 5:05, Magnus Karlsson wrote:
> >>>
> >>>> This patch proposes to add AF_XDP support to libbpf. The main reason
> >>>> for this is to facilitate writing applications that use AF_XDP by
> >>>> offering higher-level APIs that hide many of the details of the AF_XDP
> >>>> uapi. This is in the same vein as libbpf facilitates XDP adoption by
> >>>> offering easy-to-use higher level interfaces of XDP
> >>>> functionality. Hopefully this will facilitate adoption of AF_XDP, make
> >>>> applications using it simpler and smaller, and finally also make it
> >>>> possible for applications to benefit from optimizations in the AF_XDP
> >>>> user space access code. Previously, people just copied and pasted the
> >>>> code from the sample application into their application, which is not
> >>>> desirable.
> >>>
> >>> I like the idea of encapsulating the boilerplate logic in a library.
> >>>
> >>> I do think there is an important missing piece though - there should be
> >>> some code which queries the netdev for how many queues are attached, and
> >>> create the appropriate number of umem/AF_XDP sockets.
> >>>
> >>> I ran into this issue when testing the current AF_XDP code - on my test
> >>> boxes, the mlx5 card has 55 channels (aka queues), so when the test program
> >>> binds only to channel 0, nothing works as expected, since not all traffic
> >>> is being intercepted. While obvious in hindsight, this took a while to
> >>> track down.
> >>
> >> Yes, agreed. You are not the first one to stumble upon this problem
> >> :-). Let me think a little bit on how to solve this in a good way. We
> >> need this to be simple and intuitive, as you say.
> >
> > I see people hitting this with AF_XDP all the time... I had some
> > backup-slides[2] in our FOSDEM presentation[1] that describe the issue,
> > give the performance reason why and propose a workaround.
>
> Magnus, I presume you're going to address this for the initial libbpf merge
> since the plan is to make it easier to consume for users?
I think the first thing we need is education and documentation. Have a
FAQ or "common mistakes" section in the Documentation. And of course,
sending Jesper around the world reminding people about this ;-).
To address this on a libbpf interface level, I think the best way is
to reprogram the NIC to send all traffic to the queue that you
provided in the xsk_socket__create call. This "set up NIC routing"
behavior can then be disable with a flag, just as the XDP program
loading can be disabled. The standard config of xsk_socket__create
will then set up as many things for the user as possible just to get
up and running quickly. More advanced users can then disable parts of
it to gain more flexibility. Does this sound OK? Do not want to go the
route of polling multiple sockets and aggregating the traffic as this
will have significant negative performance implications.
/Magnus
> Few more minor items in individual patches, will reply there.
>
> Thanks,
> Daniel
>
> > [1] https://github.com/xdp-project/xdp-project/tree/master/conference/FOSDEM2019
> > [2] https://github.com/xdp-project/xdp-project/blob/master/conference/FOSDEM2019/xdp_building_block.org#backup-slides
> >
> > Alternative work-around
> > * Create as many AF_XDP sockets as RXQs
> > * Have userspace poll()/select on all sockets
> >
>
^ permalink raw reply
* Re: [PATCH 2/2] RTL8153-BD is used in Dell DA300 type-C dongle. It should be added to the whitelist of devices to activate MAC address pass through.
From: Oliver Neukum @ 2019-02-18 8:04 UTC (permalink / raw)
To: David Chen, linux-kernel, linux-usb, netdev
Cc: kai.heng.feng, davem, david.chen7, mario.limonciello, f.fainelli,
edumazet, zhongjiang, bigeasy, hayeswang, jslaby
In-Reply-To: <20190218034817.7515-1-david0813@gmail.com>
On Mo, 2019-02-18 at 11:48 +0800, David Chen wrote:
> From: David Chen <david.chen7@dell.com>
>
> Per confirming with Realtek all devices containing RTL8153-BD should
> activate MAC pass through and there won't use pass through bit on efuse
> like in RTL8153-AD.
>
> Signed-off-by: David Chen <david.chen7@dell.com>
> ---
> drivers/net/usb/r8152.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index ada6baf8847a..86c8c64fbb0f 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -1179,7 +1179,7 @@ static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
> } else {
> /* test for RTL8153-BND and RTL8153-BD */
> ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_MISC_1);
> - if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK)) {
> + if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK) == 0) {
You are inverting the second half of the test. How can this possibly be
right? Had you dropped it, I would understand. But this? Are you sure?
Regards
Oliver
^ permalink raw reply
* [PATCH net-next] yellowfin: fix remove set but not used variable warning
From: YueHaibing @ 2019-02-18 8:15 UTC (permalink / raw)
To: David S . Miller, Yang Wei; +Cc: YueHaibing, netdev, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/packetengines/yellowfin.c: In function 'yellowfin_rx':
drivers/net/ethernet/packetengines/yellowfin.c:1053:18: warning:
variable 'yf_size' set but not used [-Wunused-but-set-variable]
This puts the variable declaration into the YF_PROTOTYPE macro.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/packetengines/yellowfin.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/packetengines/yellowfin.c b/drivers/net/ethernet/packetengines/yellowfin.c
index 6f8d6584f809..edc8cc7f0d0d 100644
--- a/drivers/net/ethernet/packetengines/yellowfin.c
+++ b/drivers/net/ethernet/packetengines/yellowfin.c
@@ -1050,8 +1050,11 @@ static int yellowfin_rx(struct net_device *dev)
struct sk_buff *rx_skb = yp->rx_skbuff[entry];
s16 frame_status;
u16 desc_status;
- int data_size, yf_size;
+ int data_size;
u8 *buf_addr;
+#ifdef YF_PROTOTYPE
+ int yf_size = sizeof(struct yellowfin_desc);
+#endif
if(!desc->result_status)
break;
@@ -1068,8 +1071,6 @@ static int yellowfin_rx(struct net_device *dev)
if (--boguscnt < 0)
break;
- yf_size = sizeof(struct yellowfin_desc);
-
if ( ! (desc_status & RX_EOP)) {
if (data_size != 0)
netdev_warn(dev, "Oversized Ethernet frame spanned multiple buffers, status %04x, data_size %d!\n",
^ permalink raw reply related
* [PATCH] brcmfmac: remove set but not used variable 'old_state'
From: YueHaibing @ 2019-02-18 8:08 UTC (permalink / raw)
To: Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo
Cc: YueHaibing, linux-wireless, netdev, brcm80211-dev-list.pdl,
brcm80211-dev-list, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function 'brcmf_usb_state_change':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:578:6: warning:
variable 'old_state' set but not used [-Wunused-but-set-variable]
It's never used and can be removed.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
index 76cfaf6999c8..398536b30b7a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
@@ -575,7 +575,6 @@ static void
brcmf_usb_state_change(struct brcmf_usbdev_info *devinfo, int state)
{
struct brcmf_bus *bcmf_bus = devinfo->bus_pub.bus;
- int old_state;
brcmf_dbg(USB, "Enter, current state=%d, new state=%d\n",
devinfo->bus_pub.state, state);
@@ -583,7 +582,6 @@ brcmf_usb_state_change(struct brcmf_usbdev_info *devinfo, int state)
if (devinfo->bus_pub.state == state)
return;
- old_state = devinfo->bus_pub.state;
devinfo->bus_pub.state = state;
/* update state of upper layer */
^ permalink raw reply related
* [PATCH] rtl818x_pci: Remove set but not used variables 'io_addr, mem_addr'
From: YueHaibing @ 2019-02-18 7:52 UTC (permalink / raw)
To: Kalle Valo, John W. Linville, Colin Ian King
Cc: YueHaibing, linux-wireless, netdev, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c: In function 'rtl8180_probe':
drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c:1727:15: warning:
variable 'io_addr' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c:1726:16: warning:
variable 'mem_addr' set but not used [-Wunused-but-set-variable]
They're never used since introduction.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c b/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c
index e2b1bfbcfbd4..d5f65372356b 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c
@@ -1723,8 +1723,8 @@ static int rtl8180_probe(struct pci_dev *pdev,
{
struct ieee80211_hw *dev;
struct rtl8180_priv *priv;
- unsigned long mem_addr, mem_len;
- unsigned int io_addr, io_len;
+ unsigned long mem_len;
+ unsigned int io_len;
int err;
const char *chip_name, *rf_name = NULL;
u32 reg;
@@ -1743,9 +1743,7 @@ static int rtl8180_probe(struct pci_dev *pdev,
goto err_disable_dev;
}
- io_addr = pci_resource_start(pdev, 0);
io_len = pci_resource_len(pdev, 0);
- mem_addr = pci_resource_start(pdev, 1);
mem_len = pci_resource_len(pdev, 1);
if (mem_len < sizeof(struct rtl818x_csr) ||
^ permalink raw reply related
* [PATCH] rsi: remove set but not used variables 'info, vif'
From: YueHaibing @ 2019-02-18 7:51 UTC (permalink / raw)
To: Amitkumar Karwar, Siva Rebbagondla, Kalle Valo
Cc: YueHaibing, linux-wireless, netdev, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/rsi/rsi_91x_main.c: In function 'rsi_prepare_skb':
drivers/net/wireless/rsi/rsi_91x_main.c:127:24: warning:
variable 'vif' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/rsi/rsi_91x_main.c:124:28: warning:
variable 'info' set but not used [-Wunused-but-set-variable]
They're not used any more since 160ee2a11ce0 ("rsi: fill rx_params only once.")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/rsi/rsi_91x_main.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_main.c b/drivers/net/wireless/rsi/rsi_91x_main.c
index ca3a55ed72e4..29d83049c5f5 100644
--- a/drivers/net/wireless/rsi/rsi_91x_main.c
+++ b/drivers/net/wireless/rsi/rsi_91x_main.c
@@ -121,11 +121,8 @@ static struct sk_buff *rsi_prepare_skb(struct rsi_common *common,
u32 pkt_len,
u8 extended_desc)
{
- struct ieee80211_tx_info *info;
struct sk_buff *skb = NULL;
u8 payload_offset;
- struct ieee80211_vif *vif;
- struct ieee80211_hdr *wh;
if (WARN(!pkt_len, "%s: Dummy pkt received", __func__))
return NULL;
@@ -144,10 +141,7 @@ static struct sk_buff *rsi_prepare_skb(struct rsi_common *common,
payload_offset = (extended_desc + FRAME_DESC_SZ);
skb_put(skb, pkt_len);
memcpy((skb->data), (buffer + payload_offset), skb->len);
- wh = (struct ieee80211_hdr *)skb->data;
- vif = rsi_get_vif(common->priv, wh->addr1);
- info = IEEE80211_SKB_CB(skb);
return skb;
}
^ permalink raw reply related
* [PATCH net-next] mlxsw: spectrum: Change IP2ME CPU policer rate and burst size values
From: Ido Schimmel @ 2019-02-18 7:19 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, mlxsw, Shalom Toledo,
Ido Schimmel
From: Shalom Toledo <shalomt@mellanox.com>
The IP2ME packet trap is triggered by packets hitting local routes.
After evaluating current defaults used by the driver it was decided to
reduce the amount of traffic generated by this trap to 1Kpps and
increase the burst size. This is inline with similarly deployed systems.
Signed-off-by: Shalom Toledo <shalomt@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index abac923a8d04..bc349d8ca08a 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -3739,8 +3739,8 @@ static int mlxsw_sp_cpu_policers_set(struct mlxsw_core *mlxsw_core)
burst_size = 7;
break;
case MLXSW_REG_HTGT_TRAP_GROUP_SP_IP2ME:
- rate = 4 * 1024;
- burst_size = 4;
+ rate = 1024;
+ burst_size = 7;
break;
default:
continue;
--
2.20.1
^ permalink raw reply related
* Re: [RFC PATCH] bonding: use mutex lock in bond_get_stats()
From: Kefeng Wang @ 2019-02-18 6:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, Willem de Bruijn, David S . Miller, Jay Vosburgh,
Veaceslav Falico, weiyongjun1
In-Reply-To: <CANn89iKXfrfsoYAvbq0Rwx+5FtBgQf0zYU3WAt2v_tpbS59how@mail.gmail.com>
On 2019/2/17 2:18, Eric Dumazet wrote:
> On Fri, Feb 15, 2019 at 9:36 PM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>>
>>
>> On 2019/2/15 21:57, Eric Dumazet wrote:
>>> On Fri, Feb 15, 2019 at 5:37 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>>>> With CONFIG_DEBUG_SPINLOCK=y, we find following stack,
>>>>
>>>> BUG: spinlock wrong CPU on CPU#0, ip/16047
>>>> lock: 0xffff803f5febc998, .magic: dead4ead, .owner: ip/16047, .owner_cpu: 0
>>>> CPU: 1 PID: 16047 Comm: ip Kdump: loaded Tainted: G E 4.19.12.aarch64 #1
>>>> Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS TaiShan 2280 V2 - B900 01/29/2019
>>>> Call trace:
>>>> dump_backtrace+0x0/0x1c0
>>>> show_stack+0x24/0x30
>>>> dump_stack+0x90/0xbc
>>>> spin_dump+0x84/0xa8
>>>> do_raw_spin_unlock+0xf8/0x100
>>>> _raw_spin_unlock+0x20/0x30
>>>> bond_get_stats+0x110/0x140 [bonding]
>>>> rtnl_fill_stats+0x50/0x150
>>>> rtnl_fill_ifinfo+0x4d4/0xd18
>>>> rtnl_dump_ifinfo+0x200/0x3a8
>>>> netlink_dump+0x100/0x2b0
>>>> netlink_recvmsg+0x310/0x3e8
>>>> sock_recvmsg+0x58/0x68
>>>> ___sys_recvmsg+0xd0/0x278
>>>> __sys_recvmsg+0x74/0xd0
>>>> __arm64_sys_recvmsg+0x2c/0x38
>>>> el0_svc_common+0x7c/0x118
>>>> el0_svc_handler+0x30/0x40
>>>> el0_svc+0x8/0xc
>>>>
>>>> and then lead to softlockup issue, fix this by using mutex lock instead
>>>> of spin lock.
>>>>
>>>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>>>> ---
>>>>
>>>> Not sure if this is right fix, please correct me if I'm wrong.
>>>>
>>> Make sure to also try :
>>>
>>> cat /proc/net/dev
>> Yes, no regression with this patch in our test or 'cat /proc/net/dev'
>>
> You really should have a warning showing up.
>
> Make sure you have : DEBUG_ATOMIC_SLEEP=y (I thought this was
> automatically selected with LOCKDEP on, maybe not...)
>
> Please take a look at net/core/net-procfs.c , functions
> dev_seq_start(), dev_seq_printf_stats(), dev_seq_show()
>
> We can not use a mutex in a section protected by rcu_read_lock()
ok, thanks for your direction, we will do more research and test.
> .
>
^ permalink raw reply
* [PATCH] net: hamradio: remove unused hweight*() defines
From: Masahiro Yamada @ 2019-02-18 6:35 UTC (permalink / raw)
To: David S . Miller, netdev
Cc: Masahiro Yamada, linux-hams, Thomas Sailer, linux-kernel
This file does not use hweight*() at all, and the definition is
surrounded by #if 0 ... #endif.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/net/hamradio/baycom_ser_fdx.c | 26 --------------------------
1 file changed, 26 deletions(-)
diff --git a/drivers/net/hamradio/baycom_ser_fdx.c b/drivers/net/hamradio/baycom_ser_fdx.c
index 190f66c..ed08416 100644
--- a/drivers/net/hamradio/baycom_ser_fdx.c
+++ b/drivers/net/hamradio/baycom_ser_fdx.c
@@ -203,32 +203,6 @@ static inline void ser12_set_divisor(struct net_device *dev,
*/
}
-/* --------------------------------------------------------------------- */
-
-#if 0
-static inline unsigned int hweight16(unsigned int w)
- __attribute__ ((unused));
-static inline unsigned int hweight8(unsigned int w)
- __attribute__ ((unused));
-
-static inline unsigned int hweight16(unsigned int w)
-{
- unsigned short res = (w & 0x5555) + ((w >> 1) & 0x5555);
- res = (res & 0x3333) + ((res >> 2) & 0x3333);
- res = (res & 0x0F0F) + ((res >> 4) & 0x0F0F);
- return (res & 0x00FF) + ((res >> 8) & 0x00FF);
-}
-
-static inline unsigned int hweight8(unsigned int w)
-{
- unsigned short res = (w & 0x55) + ((w >> 1) & 0x55);
- res = (res & 0x33) + ((res >> 2) & 0x33);
- return (res & 0x0F) + ((res >> 4) & 0x0F);
-}
-#endif
-
-/* --------------------------------------------------------------------- */
-
static __inline__ void ser12_rx(struct net_device *dev, struct baycom_state *bc, struct timespec64 *ts, unsigned char curs)
{
int timediff;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()
From: Masahiro Yamada @ 2019-02-18 5:59 UTC (permalink / raw)
To: Ingo Molnar, Thomas Gleixner, Borislav Petkov, H . Peter Anvin,
x86
Cc: Kalle Valo, linux-wireless, Christoph Hellwig, Masahiro Yamada,
David S. Miller, netdev, linux-kernel, Lorenzo Bianconi,
linux-mediatek, linux-arm-kernel, Felix Fietkau, Matthias Brugger
In-Reply-To: <1550469571-25933-1-git-send-email-yamada.masahiro@socionext.com>
__sw_hweight8() is just internal implementation.
Drivers should use the common API, hweight8().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
This patch should go to x86 tree along with 2/2.
Otherwise, all{yes,mod}config of x86 would be broken.
This patch is trivial enough.
I want ACK from the net/wireless maintainer
so that this can go in via x86 tree.
drivers/net/wireless/mediatek/mt76/mac80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 7b926df..c42e0d3 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -124,7 +124,7 @@ static void mt76_init_stream_cap(struct mt76_dev *dev,
bool vht)
{
struct ieee80211_sta_ht_cap *ht_cap = &sband->ht_cap;
- int i, nstream = __sw_hweight8(dev->antenna_mask);
+ int i, nstream = hweight8(dev->antenna_mask);
struct ieee80211_sta_vht_cap *vht_cap;
u16 mcs_map = 0;
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] x86: turn off wrongly enabled CONFIG_GENERIC_HWEIGHT
From: Masahiro Yamada @ 2019-02-18 5:59 UTC (permalink / raw)
To: Ingo Molnar, Thomas Gleixner, Borislav Petkov, H . Peter Anvin,
x86
Cc: Kalle Valo, linux-wireless, Christoph Hellwig, Masahiro Yamada,
David S. Miller, netdev, linux-kernel, Lorenzo Bianconi,
linux-mediatek, linux-arm-kernel, Felix Fietkau, Matthias Brugger
x86 should not enable CONFIG_GENERIC_HWEIGHT
because lib/hweight.c is not used by x86.
The only user is drivers/net/wireless/mediatek/mt76/mac80211.c
Of course, this driver is wrong since drivers should use the
generic API, hweight8().
After fixing it, x86 does not need to compile lib/hweight.c at all.
The real implementation is located in arch/x86/lib/hweight.S
Masahiro Yamada (2):
wireless: mt76: call hweight8() instead of __sw_hweight8()
x86: disable CONFIG_GENERIC_HWEIGHT and remove __HAVE_ARCH_SW_HWEIGHT
arch/x86/Kconfig | 3 ---
arch/x86/include/asm/arch_hweight.h | 2 --
drivers/net/wireless/mediatek/mt76/mac80211.c | 2 +-
lib/hweight.c | 4 ----
4 files changed, 1 insertion(+), 10 deletions(-)
--
2.7.4
^ permalink raw reply
* RE: [PATCH v3] arm64: dts: lx2160aqds: Add mdio mux nodes
From: Pankaj Bansal @ 2019-02-18 5:49 UTC (permalink / raw)
To: Leo Li, Rob Herring
Cc: Shawn Guo, Andrew Lunn, Florian Fainelli, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CADRPPNTua4AmYC6_AkDYKbyOXXzpR+7a1nLTe=_Qn-KhXck=8w@mail.gmail.com>
> -----Original Message-----
> From: Li Yang [mailto:leoyang.li@nxp.com]
> Sent: Friday, 15 February, 2019 04:03 AM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>; Rob Herring <robh+dt@kernel.org>
> Cc: Shawn Guo <shawnguo@kernel.org>; Andrew Lunn <andrew@lunn.ch>;
> Florian Fainelli <f.fainelli@gmail.com>; netdev@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v3] arm64: dts: lx2160aqds: Add mdio mux nodes
>
> On Tue, Feb 12, 2019 at 12:01 PM Li Yang <leoyang.li@nxp.com> wrote:
> >
> > On Mon, Feb 11, 2019 at 9:28 PM Pankaj Bansal <pankaj.bansal@nxp.com>
> wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Leo Li
> > > > Sent: Tuesday, 12 February, 2019 02:14 AM
> > > > To: Shawn Guo <shawnguo@kernel.org>; Pankaj Bansal
> > > > <pankaj.bansal@nxp.com>
> > > > Cc: Andrew Lunn <andrew@lunn.ch>; Florian Fainelli
> > > > <f.fainelli@gmail.com>; netdev@vger.kernel.org;
> > > > linux-arm-kernel@lists.infradead.org
> > > > Subject: RE: [PATCH v3] arm64: dts: lx2160aqds: Add mdio mux nodes
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Shawn Guo <shawnguo@kernel.org>
> > > > > Sent: Sunday, February 10, 2019 9:00 PM
> > > > > To: Pankaj Bansal <pankaj.bansal@nxp.com>
> > > > > Cc: Leo Li <leoyang.li@nxp.com>; Andrew Lunn <andrew@lunn.ch>;
> > > > > Florian Fainelli <f.fainelli@gmail.com>; netdev@vger.kernel.org;
> > > > > linux-arm- kernel@lists.infradead.org
> > > > > Subject: Re: [PATCH v3] arm64: dts: lx2160aqds: Add mdio mux
> > > > > nodes
> > > > >
> > > > > On Wed, Feb 06, 2019 at 09:40:33AM +0000, Pankaj Bansal wrote:
> > > > > > The two external MDIO buses used to communicate with phy
> > > > > > devices that are external to SOC are muxed in LX2160AQDS board.
> > > > > >
> > > > > > These buses can be routed to any one of the eight IO slots on
> > > > > > LX2160AQDS board depending on value in fpga register 0x54.
> > > > > >
> > > > > > Additionally the external MDIO1 is used to communicate to the
> > > > > > onboard RGMII phy devices.
> > > > > >
> > > > > > The mdio1 is controlled by bits 4-7 of fpga register and mdio2
> > > > > > is controlled by bits 0-3 of fpga register.
> > > > > >
> > > > > > Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> > > > > > ---
> > > > > >
> > > > > > Notes:
> > > > > > V3:
> > > > > > - Add status = disabled in soc file and status = okay in board file
> > > > > > for external MDIO nodes
> > > > > > - Add interrupts property in external mdio nodes in soc file
> > > > > > V2:
> > > > > > - removed unnecassary TODO statements
> > > > > > - removed device_type from mdio nodes
> > > > > > - change the case of hex number to lowercase
> > > > > > - removed board specific comments from soc file
> > > > > >
> > > > > > .../boot/dts/freescale/fsl-lx2160a-qds.dts | 123 +++++++++++++++++
> > > > > > .../boot/dts/freescale/fsl-lx2160a.dtsi | 22 +++
> > > > > > 2 files changed, 145 insertions(+)
> > > > > >
> > > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > > > > > b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > > > > > index 99a22abbe725..079264b391a2 100644
> > > > > > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > > > > > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > > > > > @@ -35,6 +35,14 @@
> > > > > > status = "okay";
> > > > > > };
> > > > > >
> > > > > > +&emdio1 {
> > > > > > + status = "okay";
> > > > > > +};
> > > > > > +
> > > > > > +&emdio2 {
> > > > > > + status = "okay";
> > > > > > +};
> > > > > > +
> > > > > > &esdhc0 {
> > > > > > status = "okay";
> > > > > > };
> > > > > > @@ -46,6 +54,121 @@
> > > > > > &i2c0 {
> > > > > > status = "okay";
> > > > > >
> > > > > > + fpga@66 {
> > > > > > + compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
> > > > > > + reg = <0x66>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > +
> > > > > > + mdio-mux-1@54 {
> > > > > > + mdio-parent-bus = <&emdio1>;
> > > > > > + reg = <0x54>; /* BRDCFG4 */
> > > > > > + mux-mask = <0xf8>; /* EMI1_MDIO */
> > > > > > + #address-cells=<1>;
> > > > > > + #size-cells = <0>;
> > > > > > +
> > > > > > + mdio@0 {
> > > > > > + reg = <0x00>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > >
> > > > > Please have a newline between nodes. It doesn't deserve a
> > > > > respin though. I can fix them up when applying if Leo is fine with this
> version.
> > > >
> > > > I think there should be a compatible string defined for the
> > > > binding of parent node mdio-mux, probably "mdio-mux-regmap", and
> > > > be used here in the device tree.
> > >
> > > I have two concerns :
> > > 1. The regmap is linux s/w construct, while device tree is h/w representation
> and is s/w agnostic. can we use regmap in device tree?
> >
> > Well, if we want to avoid using the regmap name, we probably can try
> > "mdio-mux-reg" or "mdio-mux-syscon"? With further search I also found
> > a more generic mux binding at Documentation/devicetree/bindings/mux/,
> > would be even better if we can use that to describe the mux.
>
>
> To make it more clear, with the use of
> Documentation/devicetree/bindings/mux/ binding, I think it would end up with
> something like this:
>
> i2c {
> fpga {
> compatible = "fsl,lx2160aqds-fpga", "syscon";
> ....
> mux: mux-controller {
> compatible = "mmio-mux"
The FPGA in LX2160AQDS is not mmio controlled but an I2c controlled FPGA.
As such there is no binding yet for mux nodes controlled by SPI or I2C devices.
Even the syscon binding is for MMIO controlled devices.
I have added such binding at https://patchwork.ozlabs.org/patch/1043790/
Let's see if this gets accepted or not? After that I will resend this patch.
> ...
> }
> }
> ...
> }
>
> mdio-mux {
> compatible = "mdio-mux"
> mux-controls = <&mux 0>;
> ....
> mdio {
> phy {
> }
> ...
> }
> mdio {
> ...
> }
> ...
> }
>
>
> }"
>
> >
> > > 2. By convention the device tree compatible binding is defined as
> "<manufacturer>,<model>" e.g. "fsl,mpc8349-uart". The mdio-mux node and it's
> sub nodes are a generic representation of mdio mux and it is not dependent on a
> particular manufacturer device. How to define the compatible in this case?
> >
> > The manufacturer prefix is for vendor specific bindings. If the
> > binding a suppose to be generic, we don't need the vendor prefix.
> >
> > >
> > > >
> > > > >
> > > > > Shawn
> > > > >
> > > > > > + mdio@40 {
> > > > > > + reg = <0x40>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + mdio@c0 {
> > > > > > + reg = <0xc0>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + mdio@c8 {
> > > > > > + reg = <0xc8>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + mdio@d0 {
> > > > > > + reg = <0xd0>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + mdio@d8 {
> > > > > > + reg = <0xd8>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + mdio@e0 {
> > > > > > + reg = <0xe0>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + mdio@e8 {
> > > > > > + reg = <0xe8>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + mdio@f0 {
> > > > > > + reg = <0xf0>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + mdio@f8 {
> > > > > > + reg = <0xf8>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + };
> > > > > > +
> > > > > > + mdio-mux-2@54 {
> > > > > > + mdio-parent-bus = <&emdio2>;
> > > > > > + reg = <0x54>; /* BRDCFG4 */
> > > > > > + mux-mask = <0x07>; /* EMI2_MDIO */
> > > > > > + #address-cells=<1>;
> > > > > > + #size-cells = <0>;
> > > > > > +
> > > > > > + mdio@0 {
> > > > > > + reg = <0x00>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + mdio@1 {
> > > > > > + reg = <0x01>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + mdio@2 {
> > > > > > + reg = <0x02>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + mdio@3 {
> > > > > > + reg = <0x03>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + mdio@4 {
> > > > > > + reg = <0x04>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + mdio@5 {
> > > > > > + reg = <0x05>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + mdio@6 {
> > > > > > + reg = <0x06>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + mdio@7 {
> > > > > > + reg = <0x07>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + };
> > > > > > + };
> > > > > > + };
> > > > > > +
> > > > > > i2c-mux@77 {
> > > > > > compatible = "nxp,pca9547";
> > > > > > reg = <0x77>;
> > > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > > > > > b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > > > > > index a79f5c1ea56d..7def5252ac1a 100644
> > > > > > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > > > > > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > > > > > @@ -762,5 +762,27 @@
> > > > > > <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
> > > > > > dma-coherent;
> > > > > > };
> > > > > > +
> > > > > > + /* WRIOP0: 0x8b8_0000, E-MDIO1: 0x1_6000 */
> > > > > > + emdio1: mdio@8b96000 {
> > > > > > + compatible = "fsl,fman-memac-mdio";
> > > > > > + reg = <0x0 0x8b96000 0x0 0x1000>;
> > > > > > + interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + little-endian; /* force the driver in LE mode */
> > > > > > + status = "disabled";
> > > > > > + };
> > > > > > +
> > > > > > + /* WRIOP0: 0x8b8_0000, E-MDIO2: 0x1_7000 */
> > > > > > + emdio2: mdio@8b97000 {
> > > > > > + compatible = "fsl,fman-memac-mdio";
> > > > > > + reg = <0x0 0x8b97000 0x0 0x1000>;
> > > > > > + interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > + little-endian; /* force the driver in LE mode */
> > > > > > + status = "disabled";
> > > > > > + };
> > > > > > };
> > > > > > };
> > > > > > --
> > > > > > 2.17.1
> > > > > >
^ permalink raw reply
* Re: [RFC net-next 1/4] net: Reserve protocol identifiers for EnOcean
From: Andreas Färber @ 2019-02-18 4:41 UTC (permalink / raw)
To: Alexander Aring
Cc: linux-lpwan, linux-wpan, Alexander Aring, Stefan Schmidt, netdev,
linux-kernel, support, Jonathan Cameron, Rob Herring
In-Reply-To: <20190201005613.2qt2sneva3eaxj2t@x220t>
Hi Alex,
Am 01.02.19 um 01:58 schrieb Alexander Aring:
> On Wed, Jan 30, 2019 at 02:42:29AM +0100, Andreas Färber wrote:
>> Am 29.01.19 um 13:57 schrieb Alexander Aring:
>>> On Tue, Jan 29, 2019 at 06:01:27AM +0100, Andreas Färber wrote:
>>>> EnOcean wireless technology is based on ASK (ERP1) and FSK (ERP2) modulations
>>>> for sub-GHz and on IEEE 802.15.4 for 2.4 GHz.
>>>
>>> I am not sure what you try to do here. If I see that correctly you
>>> want to add for some special protocol vendor specific transceiver which
>>> is underneath an 802.15.4 transceiver a new ARPHRD type and even more
>>> for each modulation what it supports?
>>
>> No. EnOcean uses a 4-byte node ID across PHY layers, which I am using a
>> single ARPHRD_ENOCEAN for (which you conveniently cut off above).
>>
>> As indicated above, the 868 MHz transceiver is _not_ using 802.15.4 PHY
>> or MAC to my knowledge. It does sound like you spotted "IEEE 802.15.4"
>> and literally blended out all the rest...
>>
>
> Ah okay, I am curious about that. As far I undetstood now this has
> nothing to do with LoRa? I was not getting that point.
Correct, this is about FSK, not LoRa. The two usually come together and
I therefore need to propose a way to make also FSK usable.
> Is the PHY layer open? Do they actually refer to 802.15.4 in their
> specs, but the PHY layer is changed by... preamble, phy header, MTU?
ERP1 PHY layer appears to be ASK, ERP2 PHY layer is described as FSK.
ERP seems a MAC / Data Link protocol (ERP2 also Network layer) on top of
multiple alternative PHYs.
ASK is amplitude-modulated; FSK is frequency-modulated; 802.15.4 is PSK,
i.e. phase-modulated. Therefore from my view they are unrelated
subsystems [*].
Further, as I stated above, 802.15.4 is being used for 2.4 GHz (for
which I currently don't have any EnOcean hard-MAC transceiver), whereas
I am using FSK on 868 MHz.
The ERP layer is openly described, whereas I have not found a lot about
802.15.4 framing except for the below mentioned commands in ESP3 layer.
The EnOcean Alliance depicts ZigBee:
https://www.enocean.com/technology/radio-technology/
If that is the case, I guess we can end the 802.15.4 discussion here? ;)
No concrete documentation on how BLE is used either.
[*] With the exception that both Nemeus and ST have Sigfox DBPSK
implementations based on FSK transceivers.
>>> If it's a 802.15.4 transceiver why not using the 802.15.4 subsystem?
>>>
>>> For me it sounds more like a HardMAC transceiver driver for doing the
>>> vendor protocol. The different modulations is part of a 802.15.4 phy
>>> device class. Similar like in wireless.
>>
>> I've tried to design this exactly so that one _could_ implement it based
>> on 802.15.4 PHY framework for 2.4 GHz or based on an FSK PHY for sub-GHz
>> as a soft-MAC, layered similarly to LoRaWAN vs. LoRa, alongside the ESP
>> serdev driver in this series.
>>
>> In ESP3 the only 802.15.4 specific operations are getting/setting the
>> channel (COMMAND_2_4 packet type), and there's a CO_GET_FREQUENCY_INFO
>> command to discover frequency and protocol, with 802.15.4 having a
>> different ID than ERP2 (and I spot a value 0x30 for "Long Range" :-)).
This appears to refer to 925 MHz FSK in Japan though, not LoRa.
>> So in theory it might be possible to instantiate an 802.15.4 PHY after
>> discovering that ESP3 value, but neither is this a generic 802.15.4 PHY
>> nor a generic FSK PHY, and none of that relates to above ARPHRD really.
>>
>
> I keep it in mind, thanks.
>
>> PF_PACKET with SOCK_DGRAM for ETH_P_ERP2 gives me the subtelegram
>> contents to transmit via ESP, whereas SOCK_RAW would give the full frame
>> to transmit via FSK PHY. By avoiding a custom PF_ENOCEAN we seem to lose
>> the ability to prepend any protocol headers on the skb for SOCK_DGRAM.
>>
>
> I am not quite following here. SOCK_RAW full frame and SOCK_DGRAM
> payload sounds like what I suppose it should work.
>
> A switch of protocol will do a switch from ESP to FSK which is a phy layer
> behaviour?
No. ESP is a serial communication protocol between host and transceiver.
It abstracts the underlying radio protocol. By using SOCK_DGRAM, as
implemented in this patchset, we can pass payload data from userspace
via ESP to ERP. We cannot transmit a full SOCK_RAW ERP frame via ESP though.
My point was that by not implementing a custom PF_ERP2 protocol family
we don't have a place to implement the framing for FSK or 802.15.4
ourselves and rely on the ESP abstraction for now. Or put differently,
userspace will always need to use SOCK_DGRAM for compatibility with ESP,
and each PHY (FSK, 802.15.4, etc.) would need to re-implement framing
that payload.
>> Did you actually read my P.S. in the cover letter? I was glad to avoid
>> much PF_ socket boilerplate code here (as a playground for LoRa), and
>> now you're complaining about a single ARPHRD constant! :-/
>> By that standard we could stop implementing anything new... If you're
>> worried about number space, why has no one commented on the values added
>> for LoRa and other previous wireless technologies? No one had any such
>> comments on my LoRa RFC, nor on Jian-Hong's LoRaWAN patches, so I've
>> been reserving new ARPHRD_ constants for each technology I work on. If
>> ARPHRD_NONE would be a better value to use for PHY layers, no one
>> bothered to point it out so far! Nor did anyone suggest to Jian-Hong to
>> reuse ARPHRD_EUI64! And yet I spot nothing more suitable for EnOcean
>> addresses than a custom value. Fact is, the net_device wants some value.
>> Note that you have two ARPHRD constants assigned for 802.15.4 alone, so
>> please be fair to others.
>>
>
> Indeed we only need one. :-)
>
>> An 802.15.4 PHY won't help me for 868 MHz FSK - by my reading 802.15.4
>> is PSK (BPSK/OQPSK), thus incompatible with ASK/OOK and FSK/MSK.
>>
>> As noted in the cover letter, Semtech chips have FSK and OOK support
>> alongside LoRa modulation; so I am looking into FSK PHY support, both
>> for those chips as well as for some pure FSK/OOK transceivers posted to
>> linux-lpwan list (and potentially more, given time):
>> https://lists.infradead.org/pipermail/linux-lpwan/2019-January/000116.html
>> https://lists.infradead.org/pipermail/linux-lpwan/2019-January/000117.html
>> https://en.opensuse.org/User:A_faerber/LoRa_interop
>>
>> Therefore an FSK PHY's netlink interface will need to be able to handle
>> the requirements of upper-layer protocols, such as:
>> * Wireless M-Bus (which I could not yet find a suitable 868MHz hard-MAC
>> for to test against, only 169MHz; Si4432 has an Application Note AN451),
>> * KNX RF (which I have not come across a hard-MAC for either),
>> * Sigfox downstream (cf. mm002 LoRa driver as hard-MAC; no public docs),
>> * Z-Wave (not enough docs to implement much more for now), and here
>> * EnOcean Radio Protocol 2.
>>
>> In general I want to make sure my implementations can work with both
>> soft- and hard-MAC hardware out there, as demonstrated for LoRaWAN.
>> Pointing a user with hard-MAC device to a theoretical generic subsystem
>> of your preference doesn't help them, nor does it help to split the
>> community into separate hard-MAC vs. soft-MAC implementation camps that
>> make it hard for users to switch.
>
> agree.
>
>> * For example, when looking for how to actually use the Pine64 Z-Wave
>> adapter, back in the day I merely found an OpenHAB Raspbian(?) image
>> that as an openSUSE contributor I would surely not block my board with;
>> no explanations, no instructions, nothing. And when you have a pure Java
>> application on the one hand and a C/Python/whatever application on the
>> other, chances are that the kernel is the only common point of reuse. I
>> surely mentioned that I hate any userspace applications that attempt to
>> detect hardware on spidev/i2c-dev/tty without using the kernel-provided
>> facilities such as DT; finally, serdev allows to move any such
>> hardware-dependent tty code into the kernel - we just need to figure out
>> how to best expose functionality there (and ideally grow some more
>> helpers). Just note how patch 3/4 reuses the kernel's crc8
>> implementation instead of re-implementing it from scratch. Similarly I'd
>> love for my AT based LoRa drivers to share more serdev code, despite
>> line ending and response styles differing greatly (think
>> serdev_device_readline w/args?); binary protocols like ESP here are
>> luckily not affected as much. It could also use some more/better
>> documentation, some of the return values are wrong.
>> * As another example, we seem to be lacking a generic SDR subsystem:
>> People with SDR hardware seem to use either downstream kernel modules,
>> possibly application-generated, or closed-source userspace libraries?
>> Neither seems able to currently reuse the net subsystem for protocols.
>> And yet I've been asked repeatedly to design drivers in a way they could
>> be used with SDR, too, but without any way to actually test that today.
>> Has anyone talked to the SDR chipset/equipment vendors to remedy that?
>> The one I was in contact with simply chose not to reply again to date...
>>
>> For ETH_P_ we seem to be far away from 0xffff, so I don't see a problem
>> there? Not just was it the easiest thing to implement & test short-term,
>> but as outlined in the cover letter I saw no way here to turn that into
>> a non-net-subsystem because the data transmitted is not self-describing
>> (mostly battery-less sensors/actuators with ca. 4 byte data payload).
>> You must know that your device with id 0x12345678 conforms to profile X.
>>
>> Is describing remote devices in DT an option? (CC'ing Rob and Jonathan)
>>
>> /.../uart@foo {
>> enocean {
>> compatible = "enocean,esp3";
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> window-handle@41424344 {
>> compatible = "manufacturer1,handle";
>> reg = <0x41424344>;
>> enocean,equipment-profile = <1 2 3>;
>
> What are these profiles? For declaring you actually can support some
> "window-handle"?
Window handles are an example type of EnOcean sensor: Turning the handle
is used for energy harvesting to send such a short radio message, which
then needs to be interpreted as "window tilted" and not as "button 2
pressed" or "temperature is 20°C" etc.
> Can this be changed during runtime?
Someone using this patchset can obviously send any data they want and
interpret incoming data any way they want. I don't think commercial
devices do that. But then again I'm not an expert.
> Is this some kind of device class specification by EnOcean which need to
> be set into their transceiver that a management layer handle it which is
> running by firmware?
The EnOcean Alliance profiles determine the interpretation of the
payload data and status bytes.
Since none of those sensor/actuator devices are likely to run Linux, I
don't think it matters how sensors implement their MCU firmware layers.
This DT example just being a sketch, we might just encode the profile
identifier triple in the compatible string, say "enocean,a5-02-01".
The actual manufacturer and model should then not have much influence.
Each profile could be a separate kernel driver. There's 25 4BS profiles
for temperature sensors, plus 6 profiles for combinations of multiple
sensors (temperature + humidity, light + temperature + occupancy), plus
one VLD profile with three types. The first hex number in the profile
identifier (e.g., A5-02-01) is the transmitted RORG field, the others
are arbitrary identifiers to select how to read the following data bytes.
Whether such a passively read as opposed to actively polled sensor is
suitable for the iio subsystem would be for Jonathan to comment on.
Presumably such an EnOcean profile driver would have a callback that
receives the payload data and its implementation would then store the
data until it is requested via iio?
Note: It seems that wM-Bus metering payload data beyond frame formats is
even less standardized or documented than EnOcean or Z-Wave. And for
home automation there are a number of entirely proprietary/undocumented
ones based on FSK, too, which then need to go into userspace.
But again, my primary focus before Netdevconf 0x13 will be the PHY
subsystems for LoRa and FSK, not application-specific higher-level
protocols like this one, nor driver frameworks on top as discussed here.
>> #io-channel-cells = <1>;
>> };
>>
>> light-switch@41424348 {
>> compatible = "manufacturer2,rocker";
>> reg = <0x41424348>;
>> enocean,equipment-profile = <4 5 6>;
>> #io-channel-cells = <2>;
>> };
>> };
>> };
>>
>> Pro: This would allow to abstract sensors (iio?) and actuators (gpio?).
>> Cf. https://patchwork.ozlabs.org/patch/1028209/ for comparison.
>> Con: How to deal with it on ACPI or on DT platforms without Overlays?
>> How would the kernel preserve remote device state across reboots?
>>
>> So no, I don't think we can or should shoehorn non-802.15.4 PHYs into
>> your ieee802154 PHY layer. If you see ways to share code between the
>> various wireless PHYs, that would be great, but at present it seems like
>> mostly boilerplate code with nothing in your phy struct applying to FSK
>> or LoRa. Compare my cfglora series pointed to and Xue Liu's recent sysfs
>> patch under discussion. If no more comments turn up on my cfglora series
>> I'll copy it into a cfgfsk, so that I can integrate both into sx127x as
>> a base for further discussions at Netdevconf. Thanks.
>>
>
> Share code always sounds like a good idea.
Well, if you have comments on how to go about that, such as on Xue Liu's
PHY device work, do let us know. :)
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* [PATCH 2/2] RTL8153-BD is used in Dell DA300 type-C dongle. It should be added to the whitelist of devices to activate MAC address pass through.
From: David Chen @ 2019-02-18 3:48 UTC (permalink / raw)
To: linux-usb, netdev, linux-kernel
Cc: davem, hayeswang, mario.limonciello, bigeasy, edumazet, jslaby,
f.fainelli, david.chen7, kai.heng.feng, zhongjiang
From: David Chen <david.chen7@dell.com>
Per confirming with Realtek all devices containing RTL8153-BD should
activate MAC pass through and there won't use pass through bit on efuse
like in RTL8153-AD.
Signed-off-by: David Chen <david.chen7@dell.com>
---
drivers/net/usb/r8152.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ada6baf8847a..86c8c64fbb0f 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1179,7 +1179,7 @@ static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
} else {
/* test for RTL8153-BND and RTL8153-BD */
ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_MISC_1);
- if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK)) {
+ if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK) == 0) {
netif_dbg(tp, probe, tp->netdev,
"Invalid variant for MAC pass through\n");
return -ENODEV;
--
2.19.1
^ permalink raw reply related
* neighbour entry incorrectly moved to NUD_REACHABLE
From: ash.millar @ 2019-02-18 2:43 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
We have encountered an issue resulting from commit 2724680bceee ("neigh: Keep neighbour cache entries if number of them is small enough."), which allows stale entries to remain in the neigh table indefinitely if the total number of entries is less than gc_thresh1.
This issue arises if:
- a stale entry has existed for a long time, so it has a sufficiently old neigh->confirmed value
- the neighbour itself has sinced change MAC address
- we then try to ping the neighbour
When we ping the neighbour, the entry moves into NUD_DELAY as expected. But then, within neigh_timer_handler(), an incorrect jiffie comparison causes time_before_eq(now, neigh->confirmed + NEIGH_VAR(neigh->parms, DELAY_PROBE_TIME)) to return true and the entry is erroneously moved to NUD_REACHABLE. The entry becomes stuck in this state, even though it is not actually reachable as the neighbour has since changed MAC address.
The necessary age of neigh->confirmed for this to occur depends on the platform. It occurs after approximitely 100 days on a 32-bit platform with 250HZ.
We have resolved this by setting gc_thresh1 = 0, which effectively undoes commit 2724680bceee.
I would like to know if anyone else has observed this or has an alternative solution.
Kind regards,
Ash
^ permalink raw reply
* Re: [net-next] net: crypto set sk to NULL when af_alg_release.
From: maowenan @ 2019-02-18 2:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev, xiyou.wangcong, linux-kernel
In-Reply-To: <20190217.154218.1671210082238894003.davem@davemloft.net>
On 2019/2/18 7:42, David Miller wrote:
> From: Mao Wenan <maowenan@huawei.com>
> Date: Fri, 15 Feb 2019 22:24:15 +0800
>
>> KASAN has found use-after-free in sockfs_setattr.
>> The existed commit 6d8c50dcb029 ("socket: close race condition between sock_close()
>> and sockfs_setattr()") is to fix this simillar issue, but it seems to ignore
>> that crypto module forgets to set the sk to NULL after af_alg_release.
>
> Please target this at 'net' since this is a bug fix.
Thank you, I have sent the v2 patch targets to "net" mail list.
>
> .
>
^ permalink raw reply
* [PATCH net v2] net: crypto set sk to NULL when af_alg_release.
From: Mao Wenan @ 2019-02-18 2:44 UTC (permalink / raw)
To: netdev, xiyou.wangcong, linux-kernel, davem
KASAN has found use-after-free in sockfs_setattr.
The existed commit 6d8c50dcb029 ("socket: close race condition between sock_close()
and sockfs_setattr()") is to fix this simillar issue, but it seems to ignore
that crypto module forgets to set the sk to NULL after af_alg_release.
KASAN report details as below:
BUG: KASAN: use-after-free in sockfs_setattr+0x120/0x150
Write of size 4 at addr ffff88837b956128 by task syz-executor0/4186
CPU: 2 PID: 4186 Comm: syz-executor0 Not tainted xxx + #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1ubuntu1 04/01/2014
Call Trace:
dump_stack+0xca/0x13e
print_address_description+0x79/0x330
? vprintk_func+0x5e/0xf0
kasan_report+0x18a/0x2e0
? sockfs_setattr+0x120/0x150
sockfs_setattr+0x120/0x150
? sock_register+0x2d0/0x2d0
notify_change+0x90c/0xd40
? chown_common+0x2ef/0x510
chown_common+0x2ef/0x510
? chmod_common+0x3b0/0x3b0
? __lock_is_held+0xbc/0x160
? __sb_start_write+0x13d/0x2b0
? __mnt_want_write+0x19a/0x250
do_fchownat+0x15c/0x190
? __ia32_sys_chmod+0x80/0x80
? trace_hardirqs_on_thunk+0x1a/0x1c
__x64_sys_fchownat+0xbf/0x160
? lockdep_hardirqs_on+0x39a/0x5e0
do_syscall_64+0xc8/0x580
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462589
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89
f7 48 89 d6 48 89
ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3
48 c7 c1 bc ff ff
ff f7 d8 64 89 01 48
RSP: 002b:00007fb4b2c83c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000104
RAX: ffffffffffffffda RBX: 000000000072bfa0 RCX: 0000000000462589
RDX: 0000000000000000 RSI: 00000000200000c0 RDI: 0000000000000007
RBP: 0000000000000005 R08: 0000000000001000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fb4b2c846bc
R13: 00000000004bc733 R14: 00000000006f5138 R15: 00000000ffffffff
Allocated by task 4185:
kasan_kmalloc+0xa0/0xd0
__kmalloc+0x14a/0x350
sk_prot_alloc+0xf6/0x290
sk_alloc+0x3d/0xc00
af_alg_accept+0x9e/0x670
hash_accept+0x4a3/0x650
__sys_accept4+0x306/0x5c0
__x64_sys_accept4+0x98/0x100
do_syscall_64+0xc8/0x580
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 4184:
__kasan_slab_free+0x12e/0x180
kfree+0xeb/0x2f0
__sk_destruct+0x4e6/0x6a0
sk_destruct+0x48/0x70
__sk_free+0xa9/0x270
sk_free+0x2a/0x30
af_alg_release+0x5c/0x70
__sock_release+0xd3/0x280
sock_close+0x1a/0x20
__fput+0x27f/0x7f0
task_work_run+0x136/0x1b0
exit_to_usermode_loop+0x1a7/0x1d0
do_syscall_64+0x461/0x580
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Syzkaller reproducer:
r0 = perf_event_open(&(0x7f0000000000)={0x0, 0x70, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, @perf_config_ext}, 0x0, 0x0,
0xffffffffffffffff, 0x0)
r1 = socket$alg(0x26, 0x5, 0x0)
getrusage(0x0, 0x0)
bind(r1, &(0x7f00000001c0)=@alg={0x26, 'hash\x00', 0x0, 0x0,
'sha256-ssse3\x00'}, 0x80)
r2 = accept(r1, 0x0, 0x0)
r3 = accept4$unix(r2, 0x0, 0x0, 0x0)
r4 = dup3(r3, r0, 0x0)
fchownat(r4, &(0x7f00000000c0)='\x00', 0x0, 0x0, 0x1000)
Fixes: 6d8c50dcb029 ("socket: close race condition between sock_close() and sockfs_setattr()")
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
v1->v2: target patch to "net" mail list.
crypto/af_alg.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 17eb09d222ff..ec78a04eb136 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -122,8 +122,10 @@ static void alg_do_release(const struct af_alg_type *type, void *private)
int af_alg_release(struct socket *sock)
{
- if (sock->sk)
+ if (sock->sk) {
sock_put(sock->sk);
+ sock->sk = NULL;
+ }
return 0;
}
EXPORT_SYMBOL_GPL(af_alg_release);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net 0/2] tcp: fix possible crash in tcp_v4_err()
From: Eric Dumazet @ 2019-02-18 2:20 UTC (permalink / raw)
To: David Miller, edumazet
Cc: netdev, eric.dumazet, ncardwell, ycheng, soukjin.bae
In-Reply-To: <20190217.154720.1503278506915285087.davem@davemloft.net>
On 02/17/2019 03:47 PM, David Miller wrote:
> From: Eric Dumazet <edumazet@google.com>
> Date: Fri, 15 Feb 2019 13:36:19 -0800
>
>> soukjin bae reported a crash in tcp_v4_err() that we
>> root caused to a missing initialization.
>>
>> Second patch adds a sanity check in tcp_v4_err() to avoid
>> future potential problems. Ignoring an ICMP message
>> is probably better than crashing a machine.
>
> Series applied, thanks Eric.
>
> Want me to queue these up for -stable?
>
Yes please, I put no Fixes: tag because it seemed to be a day-0 bug.
Thanks !
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: dsa: add support for bridge flags
From: Russell King - ARM Linux admin @ 2019-02-18 0:50 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Andrew Lunn, Vivien Didelot, David S. Miller, netdev
In-Reply-To: <0f607109-c037-2b7f-cf66-845ce4e7bf33@gmail.com>
On Sun, Feb 17, 2019 at 02:07:54PM -0800, Florian Fainelli wrote:
>
>
> On 2/17/2019 2:04 PM, Russell King - ARM Linux admin wrote:
> > On Sun, Feb 17, 2019 at 01:37:19PM -0800, Florian Fainelli wrote:
> >>
> >>
> >> On 2/17/2019 6:25 AM, Russell King wrote:
> >>> The Linux bridge implementation allows various properties of the bridge
> >>> to be controlled, such as flooding unknown unicast and multicast frames.
> >>> This patch adds the necessary DSA infrastructure to allow the Linux
> >>> bridge support to control these properties for DSA switches.
> >>>
> >>> We implement this by providing two new methods: one to get the switch-
> >>> wide support bitmask, and another to set the properties.
> >>>
> >>> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> >>> ---
> >>
> >> [snip]
> >>
> >>>
> >>> +int dsa_port_bridge_flags(const struct dsa_port *dp, unsigned long flags,
> >>> + struct switchdev_trans *trans)
> >>> +{
> >>> + struct dsa_switch *ds = dp->ds;
> >>> + int port = dp->index;
> >>> +
> >>> + if (switchdev_trans_ph_prepare(trans))
> >>> + return ds->ops->port_bridge_flags ? 0 : -EOPNOTSUPP;
> >>> +
> >>> + if (ds->ops->port_bridge_flags)
> >>> + ds->ops->port_bridge_flags(ds, port, flags);
> >>
> >> If you have a switch fabric with multiple switches, it seems to me that
> >> you also need to make sure that the DSA and CPU ports will have
> >> compatible flooding attribute, so just like the port_vlan_add()
> >> callback, you probably need to make this a switch fabric-wide event and
> >> use a notifier here. At least the DSA ports need to have MC flooding
> >> turned on for an user port to also have MC flooding working.
> >
> > mv88e6xxx already today detects CPU and DSA ports and sets unicast
> > and multicast flooding for these ports - see
> > mv88e6xxx_setup_egress_floods():
>
> Indeed, probably for historical reasons, since that type of logic should
> ideally be migrated to the core DSA layer, this is fine for now though.
From what I can see, the port_vlan_add()/port_vlan_del() implementation
is far from ideal, just like "always enabling flooding for CPU/DSA
ports" is not ideal.
From what I can see, when we add a vlan to any port in a group of
switches, we turn on forwarding of frames within that vlan to all
switches and the CPU port regardless of whether there are any ports
configured on those other switches.
If we apply the same logic to flooding (which is an egress control),
then as soon as we enable flooding on any port in a bridged group of
switches, we start forwarding flooded frames to all switches and the
CPU port regardless of whether anyone there is interested.
What would be more optimal is to only enable flooding in the direction
of switches that have an interest in those patches. For example, lets
assume we have three daisy-chained switches with three lan ports each,
with interfaces of the format swNlanN.
All of sw1's lan interfaces and one of sw2's lan interfaces are part
of a Linux bridge. Let's say we have enabled flooding on only one of
sw1's ports and the rest are disabled. With the way port_vlan_add()
works (which you're suggesting as a model for flooding too) we would
end up enabling flooding across all switches and to the CPU port, even
though:
- sw3 has no interest in any of the flooded frames as none of its ports
are part of the bridge
- sw2 has no interest in any of the frames flooded from sw1
Doesn't seem optimal.
Given that, is it worth applying the same implementation to flooding
as already exists for vlans? It would mean that as soon as we have
any single port in the group of switches that has flooding enabled,
we've enabled flooding across the entire group of switches. As we
are unable to access the neighbouring switches state, we're unable
to turn flooding off (just like we're already unable to disable vlan
forwarding on the CPU/DSA ports).
Maybe if DSA had some infrastructure to know what downstream and
upstream switches wanted in terms of which frames, we could do better
but I don't currently see any infrastructure for that.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the rdma tree
From: Stephen Rothwell @ 2019-02-18 0:05 UTC (permalink / raw)
To: David Miller, Networking, Doug Ledford, Jason Gunthorpe
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Leon Romanovsky, Mark Bloch, Bodong Wang, Saeed Mahameed
[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/infiniband/hw/mlx5/ib_rep.c
between commits:
459cc69fa4c1 ("RDMA: Provide safe ib_alloc_device() function")
fc9e4477f924 ("RDMA/mlx5: Fix memory leak in case we fail to add an IB device")
from the rdma tree and commit:
f0666f1f22b5 ("IB/mlx5: Use unified register/load function for uplink and VF vports")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/infiniband/hw/mlx5/ib_rep.c
index 95ac97af6166,4700cffb5a00..000000000000
--- a/drivers/infiniband/hw/mlx5/ib_rep.c
+++ b/drivers/infiniband/hw/mlx5/ib_rep.c
@@@ -48,29 -49,15 +49,15 @@@ static const struct mlx5_ib_profile vf_
static int
mlx5_ib_vport_rep_load(struct mlx5_core_dev *dev, struct mlx5_eswitch_rep *rep)
{
+ const struct mlx5_ib_profile *profile;
struct mlx5_ib_dev *ibdev;
+ if (rep->vport == MLX5_VPORT_UPLINK)
+ profile = &uplink_rep_profile;
+ else
+ profile = &vf_rep_profile;
+
- ibdev = (struct mlx5_ib_dev *)ib_alloc_device(sizeof(*ibdev));
+ ibdev = ib_alloc_device(mlx5_ib_dev, ib_dev);
if (!ibdev)
return -ENOMEM;
@@@ -78,10 -65,8 +65,10 @@@
ibdev->mdev = dev;
ibdev->num_ports = max(MLX5_CAP_GEN(dev, num_ports),
MLX5_CAP_GEN(dev, num_vhca_ports));
- if (!__mlx5_ib_add(ibdev, &rep_profile)) {
- if (!__mlx5_ib_add(ibdev, profile))
++ if (!__mlx5_ib_add(ibdev, profile)) {
+ ib_dealloc_device(&ibdev->ib_dev);
return -EINVAL;
+ }
rep->rep_if[REP_IB].priv = ibdev;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net: hns3: make function hclge_set_all_vf_rst() static
From: David Miller @ 2019-02-17 23:55 UTC (permalink / raw)
To: weiyongjun1
Cc: yisen.zhuang, salil.mehta, tanhuazhong, linyunsheng, lipeng321,
shenjian15, liangfuyun1, netdev, kernel-janitors
In-Reply-To: <20190216081552.91298-1-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Sat, 16 Feb 2019 08:15:52 +0000
> Fixes the following sparse warning:
>
> drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c:2431:5: warning:
> symbol 'hclge_set_all_vf_rst' was not declared. Should it be static?
>
> Fixes: aa5c4f175be6 ("net: hns3: add reset handling for VF when doing PF reset")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] ptr_ring: remove duplicated include from ptr_ring.h
From: David Miller @ 2019-02-17 23:53 UTC (permalink / raw)
To: yuehaibing; +Cc: mst, xiyou.wangcong, parri.andrea, linux-kernel, netdev
In-Reply-To: <20190216023756.23832-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Sat, 16 Feb 2019 10:37:56 +0800
> Remove duplicated include.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: sgi: use GFP_ATOMIC under spin lock
From: David Miller @ 2019-02-17 23:52 UTC (permalink / raw)
To: weiyongjun1; +Cc: yang.wei9, mcgrof, yuehaibing, hch, netdev, kernel-janitors
In-Reply-To: <20190216014809.142801-1-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Sat, 16 Feb 2019 01:48:09 +0000
> The function meth_init_tx_ring() is called from meth_tx_timeout(),
> in which spin_lock is held, so we should use GFP_ATOMIC instead.
>
> Fixes: 8d4c28fbc284 ("meth: pass struct device to DMA API functions")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied.
^ permalink raw reply
* Re: [net PATCH 0/2] Address recent issues found in netdev page_frag_alloc usage
From: David Miller @ 2019-02-17 23:50 UTC (permalink / raw)
To: alexander.duyck; +Cc: netdev, linux-mm, linux-kernel, jannh
In-Reply-To: <20190215223741.16881.84864.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Fri, 15 Feb 2019 14:44:05 -0800
> This patch set addresses a couple of issues that I had pointed out to Jann
> Horn in response to a recent patch submission.
>
> The first issue is that I wanted to avoid the need to read/modify/write the
> size value in order to generate the value for pagecnt_bias. Instead we can
> just use a fixed constant which reduces the need for memory read operations
> and the overall number of instructions to update the pagecnt bias values.
>
> The other, and more important issue is, that apparently we were letting tun
> access the napi_alloc_cache indirectly through netdev_alloc_frag and as a
> result letting it create unaligned accesses via unaligned allocations. In
> order to prevent this I have added a call to SKB_DATA_ALIGN for the fragsz
> field so that we will keep the offset in the napi_alloc_cache
> SMP_CACHE_BYTES aligned.
Series applied, thanks Alexander.
^ 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