* Re: [PATCH net 2/3] lan78xx: Add support to dump lan78xx registers
From: Sasha Levin @ 2018-04-10 13:50 UTC (permalink / raw)
To: Sasha Levin, Raghuram Chary J, davem@davemloft.net
Cc: netdev@vger.kernel.org, unglinuxdriver@microchip.com,
stable@vger.kernel.org
In-Reply-To: <20180406061204.18257-3-raghuramchary.jallipalli@microchip.com>
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 55d7de9de6c3 Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver.
The bot has tested the following trees: v4.16.1, v4.15.16, v4.14.33, v4.9.93, v4.4.127.
v4.16.1: Build OK!
v4.15.16: Build OK!
v4.14.33: Build OK!
v4.9.93: Failed to apply! Possible dependencies:
6e76510e7e19 ("net: usb: lan78xx: use new api ethtool_{get|set}_link_ksettings")
v4.4.127: Failed to apply! Possible dependencies:
20ff55655a93 ("lan78xx: handle statistics counter rollover")
349e0c5e2237 ("lan78xx: add ethtool set & get pause functions")
6e76510e7e19 ("net: usb: lan78xx: use new api ethtool_{get|set}_link_ksettings")
^ permalink raw reply
* Re: [PATCH net 3/3] lan78xx: Lan7801 Support for Fixed PHY
From: Sasha Levin @ 2018-04-10 13:50 UTC (permalink / raw)
To: Sasha Levin, Raghuram Chary J, davem@davemloft.net
Cc: netdev@vger.kernel.org, unglinuxdriver@microchip.com,
stable@vger.kernel.org
In-Reply-To: <20180406061204.18257-4-raghuramchary.jallipalli@microchip.com>
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 55d7de9de6c3 Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver.
The bot has tested the following trees: v4.16.1, v4.15.16, v4.14.33, v4.9.93, v4.4.127.
v4.16.1: Build OK!
v4.15.16: Failed to apply! Possible dependencies:
3b51cc75eba2 ("lan78xx: remove redundant initialization of pointer 'phydev'")
v4.14.33: Failed to apply! Possible dependencies:
3b51cc75eba2 ("lan78xx: remove redundant initialization of pointer 'phydev'")
v4.9.93: Failed to apply! Possible dependencies:
02dc1f3d613d ("lan78xx: add LAN7801 MAC only support")
3b51cc75eba2 ("lan78xx: remove redundant initialization of pointer 'phydev'")
8c56ea410efb ("net: lan78xx: fix build errors when linux/phy*.h is removed from net/dsa.h")
cc89c323a30e ("lan78xx: Use irq_domain for phy interrupt from USB Int. EP")
v4.4.127: Failed to apply! Possible dependencies:
02dc1f3d613d ("lan78xx: add LAN7801 MAC only support")
3b51cc75eba2 ("lan78xx: remove redundant initialization of pointer 'phydev'")
8c56ea410efb ("net: lan78xx: fix build errors when linux/phy*.h is removed from net/dsa.h")
cc89c323a30e ("lan78xx: Use irq_domain for phy interrupt from USB Int. EP")
^ permalink raw reply
* Re: [PATCH net 1/3] lan78xx: PHY DSP registers initialization to address EEE link drop issues with long cables
From: Sasha Levin @ 2018-04-10 13:50 UTC (permalink / raw)
To: Sasha Levin, Raghuram Chary J, davem@davemloft.net
Cc: netdev@vger.kernel.org, unglinuxdriver@microchip.com,
stable@vger.kernel.org
In-Reply-To: <20180406061204.18257-2-raghuramchary.jallipalli@microchip.com>
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 55d7de9de6c3 Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver.
The bot has also determined it's probably a bug fixing patch. (score: 3.9486)
The bot has tested the following trees: v4.16.1, v4.15.16, v4.14.33, v4.9.93, v4.4.127.
v4.16.1: Build OK!
v4.15.16: Build OK!
v4.14.33: Build OK!
v4.9.93: Failed to apply! Possible dependencies:
f6e3ef3e4d35 ("lan78xx: relocate mdix setting to phy driver")
v4.4.127: Failed to apply! Possible dependencies:
f6e3ef3e4d35 ("lan78xx: relocate mdix setting to phy driver")
^ permalink raw reply
* Re: [PATCH] ARM: dts: ls1021a: Specify TBIPA register address
From: Sasha Levin @ 2018-04-10 13:50 UTC (permalink / raw)
To: Sasha Levin, Esben Haabendal, Esben Haabendal,
netdev@vger.kernel.org
Cc: Rob Herring, stable@vger.kernel.org
In-Reply-To: <20180406124635.12319-1-esben.haabendal@gmail.com>
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 22.1404)
The bot has tested the following trees: v4.16.1, v4.15.16, v4.14.33, v4.9.93, v4.4.127.
v4.16.1: Build OK!
v4.15.16: Build OK!
v4.14.33: Build OK!
v4.9.93: Build OK!
v4.4.127: Build OK!
Please let us know if you'd like to have this patch included in a stable tree.
^ permalink raw reply
* Re: [PATCH] dp83640: Ensure against premature access to PHY registers after reset
From: Sasha Levin @ 2018-04-10 13:50 UTC (permalink / raw)
To: Sasha Levin, Esben Haabendal, Esben Haabendal,
netdev@vger.kernel.org
Cc: Esben Haabendal, stable@vger.kernel.org
In-Reply-To: <20180406140540.13511-1-esben.haabendal@gmail.com>
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 6.8160)
The bot has tested the following trees: v4.16.1, v4.15.16, v4.14.33, v4.9.93, v4.4.127.
v4.16.1: Build OK!
v4.15.16: Build OK!
v4.14.33: Build OK!
v4.9.93: Build OK!
v4.4.127: Build OK!
Please let us know if you'd like to have this patch included in a stable tree.
^ permalink raw reply
* Re: [PATCH v2] dp83640: Ensure against premature access to PHY registers after reset
From: Sasha Levin @ 2018-04-10 13:50 UTC (permalink / raw)
To: Sasha Levin, Esben Haabendal, Esben Haabendal,
netdev@vger.kernel.org
Cc: andrew@lunn.ch, richardcochran@gmail.com, f.fainelli@gmail.com,
stable@vger.kernel.org
In-Reply-To: <20180406170844.4248-1-esben.haabendal@gmail.com>
Hi,
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 7.2454)
The bot has tested the following trees: v4.16.1, v4.15.16, v4.14.33, v4.9.93, v4.4.127.
v4.16.1: Build OK!
v4.15.16: Build OK!
v4.14.33: Build OK!
v4.9.93: Build OK!
v4.4.127: Build OK!
Please let us know if you'd like to have this patch included in a stable tree.
^ permalink raw reply
* [PATCH] net: wireless: b43legacy: Replace GFP_ATOMIC with GFP_KERNEL in dma_tx_fragment
From: Jia-Ju Bai @ 2018-04-10 13:54 UTC (permalink / raw)
To: Larry.Finger, kvalo
Cc: linux-wireless, b43-dev, netdev, linux-kernel, Jia-Ju Bai
dma_tx_fragment() is never called in atomic context.
dma_tx_fragment() is only called by b43legacy_dma_tx(), which is
only called by b43legacy_tx_work().
b43legacy_tx_work() is only set a parameter of INIT_WORK() in
b43legacy_wireless_init().
Despite never getting called from atomic context,
dma_tx_fragment() calls alloc_skb() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/net/wireless/broadcom/b43legacy/dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/b43legacy/dma.c b/drivers/net/wireless/broadcom/b43legacy/dma.c
index cfa617d..2f0c64c 100644
--- a/drivers/net/wireless/broadcom/b43legacy/dma.c
+++ b/drivers/net/wireless/broadcom/b43legacy/dma.c
@@ -1064,7 +1064,7 @@ static int dma_tx_fragment(struct b43legacy_dmaring *ring,
meta->dmaaddr = map_descbuffer(ring, skb->data, skb->len, 1);
/* create a bounce buffer in zone_dma on mapping failure. */
if (b43legacy_dma_mapping_error(ring, meta->dmaaddr, skb->len, 1)) {
- bounce_skb = alloc_skb(skb->len, GFP_ATOMIC | GFP_DMA);
+ bounce_skb = alloc_skb(skb->len, GFP_KERNEL | GFP_DMA);
if (!bounce_skb) {
ring->current_slot = old_top_slot;
ring->used_slots = old_used_slots;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] slip: Check if rstate is initialized before uncompressing
From: David Miller @ 2018-04-10 14:03 UTC (permalink / raw)
To: tejaswit; +Cc: netdev
In-Reply-To: <ed7bd53914f26c2225c6c00d16bffb35@codeaurora.org>
From: tejaswit@codeaurora.org
Date: Tue, 10 Apr 2018 11:28:10 +0530
> On 2018-04-09 20:34, David Miller wrote:
>> From: Tejaswi Tanikella <tejaswit@codeaurora.org>
>> Date: Mon, 9 Apr 2018 14:23:49 +0530
>>
>>> @@ -673,6 +677,7 @@ struct slcompress *
>>> if (cs->cs_tcp.doff > 5)
>>> memcpy(cs->cs_tcpopt, icp + ihl*4 + sizeof(struct tcphdr),
>>> (cs->cs_tcp.doff - 5) * 4);
>>> cs->cs_hsize = ihl*2 + cs->cs_tcp.doff*2;
>>> + cs->initialized = 1;
>>> /* Put headers back on packet
>> ...
>>> struct cstate {
>>> byte_t cs_this; /* connection id number (xmit) */
>>> + byte_t initialized; /* non-zero if initialized */
>> Please use 'bool' and true/false for 'initialized'.
>
> Made the changes.
Please, when you are asked to fix a patch, post it as a new posting
with '[PATCH v2 net] slip: ...' in the subject line.
And also not as an attachment, all patches must be inline.
Thank you.
^ permalink raw reply
* Re: aquantia - BUG: unable to handle kernel NULL pointer dereference at 0000000000000058 on reboot
From: Yanko Kaneti @ 2018-04-10 14:06 UTC (permalink / raw)
To: Igor Russkikh; +Cc: netdev
In-Reply-To: <6df8b628-cec5-9ce5-8430-e9a2cd27346d@aquantia.com>
On Tue, 2018-04-10 at 15:53 +0300, Igor Russkikh wrote:
> On 10.04.2018 15:42, Yanko Kaneti wrote:
> > Hello,
> >
> > Since 90869ddfefeb net: aquantia: Implement pci shutdown callback
> > I get the below oops on reboot. Without the callback everything works
> > as expected.
> >
>
> Thanks, we also recently found out that.
>
> Could you please try the below patch?
Works for me, as in, no crashes on reboot.
Thanks
-Yanko
>
>
> diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
> index c96a921..32f6d2e 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
> @@ -951,9 +951,11 @@ void aq_nic_shutdown(struct aq_nic_s *self)
>
> netif_device_detach(self->ndev);
>
> - err = aq_nic_stop(self);
> - if (err < 0)
> - goto err_exit;
> + if (netif_running(self->ndev)) {
> + err = aq_nic_stop(self);
> + if (err < 0)
> + goto err_exit;
> + }
> aq_nic_deinit(self);
>
> err_exit:
^ permalink raw reply
* Re: [patch net] devlink: convert occ_get op to separate registration
From: Jiri Pirko @ 2018-04-10 14:13 UTC (permalink / raw)
To: Sasha Levin
Cc: Jiri Pirko, netdev@vger.kernel.org, davem@davemloft.net,
idosch@mellanox.com, stable@vger.kernel.org
In-Reply-To: <DM5PR2101MB103228CD6B0A1EB82361E796FBBE0@DM5PR2101MB1032.namprd21.prod.outlook.com>
Tue, Apr 10, 2018 at 03:49:40PM CEST, Alexander.Levin@microsoft.com wrote:
>Hi,
>
>[This is an automated email]
>
>This commit has been processed because it contains a "Fixes:" tag,
>fixing commit: d9f9b9a4d05f devlink: Add support for resource abstraction.
I don't think we need this fix in stable. Thanks.
>
>The bot has tested the following trees: v4.16.1.
>
>v4.16.1: Failed to apply! Possible dependencies:
> 37923ed6b8ce ("netdevsim: Add simple FIB resource controller via devlink")
> 3ed898e8cd05 ("mlxsw: spectrum_kvdl: Make some functions static")
> 4f4bbf7c4e3d ("devlink: Perform cleanup of resource_set cb")
> 51d3c08e3371 ("mlxsw: spectrum_kvdl: Add support for linear division resources")
> 7f47b19bd744 ("mlxsw: spectrum_kvdl: Add support for per part occupancy")
> 88d2fbcda145 ("mlxsw: spectrum: Pass mlxsw_core as arg of mlxsw_sp_kvdl_resources_register()")
> c8276dd250e9 ("mlxsw: spectrum_kvdl: Fix handling of resource_size_param")
> f9b9120119ca ("mlxsw: Constify devlink_resource_ops")
>
>
>--
>Thanks,
>Sasha
^ permalink raw reply
* [PATCH] net: wimax: i2400m: Replace GFP_ATOMIC with GFP_KERNEL in i2400m_tx_setup
From: Jia-Ju Bai @ 2018-04-10 14:14 UTC (permalink / raw)
To: inaky.perez-gonzalez; +Cc: linux-wimax, netdev, linux-kernel, Jia-Ju Bai
i2400m_tx_setup() is never called in atomic context.
The call chains ending up at i2400m_tx_setup() are:
[1] i2400m_tx_setup() <- __i2400m_dev_start() <-
__i2400m_dev_reset_handle()
[2] i2400m_tx_setup() <- __i2400m_dev_start() <- i2400m_dev_start() <-
i2400m_setup() <- i2400mu_probe()
[3] i2400m_tx_setup() <- __i2400m_dev_start() <- i2400m_post_reset() <-
i2400mu_post_reset()
__i2400m_dev_reset_handle() is only set as a parameter of INIT_WORK() in
i2400m_init().
i2400mu_probe() is only set as ".probe" in struct usb_driver.
i2400mu_post_reset() is only set as ".post_reset" in struct usb_driver.
These functions are not called in atomic context.
Despite never getting called from atomic context,
i2400m_tx_setup() calls kmalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/net/wimax/i2400m/tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wimax/i2400m/tx.c b/drivers/net/wimax/i2400m/tx.c
index f20886a..cfbc187 100644
--- a/drivers/net/wimax/i2400m/tx.c
+++ b/drivers/net/wimax/i2400m/tx.c
@@ -973,7 +973,7 @@ int i2400m_tx_setup(struct i2400m *i2400m)
* the WS was scheduled on another CPU */
INIT_WORK(&i2400m->wake_tx_ws, i2400m_wake_tx_work);
- tx_buf = kmalloc(I2400M_TX_BUF_SIZE, GFP_ATOMIC);
+ tx_buf = kmalloc(I2400M_TX_BUF_SIZE, GFP_KERNEL);
if (tx_buf == NULL) {
result = -ENOMEM;
goto error_kmalloc;
--
1.9.1
^ permalink raw reply related
* Re: [RFC PATCH v2 00/14] Introducing AF_XDP support
From: William Tu @ 2018-04-10 14:14 UTC (permalink / raw)
To: Björn Töpel
Cc: Karlsson, Magnus, Alexander Duyck, Alexander Duyck,
John Fastabend, Alexei Starovoitov, Jesper Dangaard Brouer,
Willem de Bruijn, Daniel Borkmann,
Linux Kernel Network Developers, Björn Töpel,
michael.lundkvist, Brandeburg, Jesse, Anjali Singhai Jain,
Zhang, Qi Z, ravineet.singh
In-Reply-To: <CAJ+HfNgu+RE6G3=4dnyfaEZGxcw-NB1dAZKNgrZm0TFKooVdKQ@mail.gmail.com>
On Mon, Apr 9, 2018 at 11:47 PM, Björn Töpel <bjorn.topel@gmail.com> wrote:
> 2018-04-09 23:51 GMT+02:00 William Tu <u9012063@gmail.com>:
>> On Tue, Mar 27, 2018 at 9:59 AM, Björn Töpel <bjorn.topel@gmail.com> wrote:
>>> From: Björn Töpel <bjorn.topel@intel.com>
>>>
>>> This RFC introduces a new address family called AF_XDP that is
>>> optimized for high performance packet processing and, in upcoming
>>> patch sets, zero-copy semantics. In this v2 version, we have removed
>>> all zero-copy related code in order to make it smaller, simpler and
>>> hopefully more review friendly. This RFC only supports copy-mode for
>>> the generic XDP path (XDP_SKB) for both RX and TX and copy-mode for RX
>>> using the XDP_DRV path. Zero-copy support requires XDP and driver
>>> changes that Jesper Dangaard Brouer is working on. Some of his work is
>>> already on the mailing list for review. We will publish our zero-copy
>>> support for RX and TX on top of his patch sets at a later point in
>>> time.
>>>
>>> An AF_XDP socket (XSK) is created with the normal socket()
>>> syscall. Associated with each XSK are two queues: the RX queue and the
>>> TX queue. A socket can receive packets on the RX queue and it can send
>>> packets on the TX queue. These queues are registered and sized with
>>> the setsockopts XDP_RX_QUEUE and XDP_TX_QUEUE, respectively. It is
>>> mandatory to have at least one of these queues for each socket. In
>>> contrast to AF_PACKET V2/V3 these descriptor queues are separated from
>>> packet buffers. An RX or TX descriptor points to a data buffer in a
>>> memory area called a UMEM. RX and TX can share the same UMEM so that a
>>> packet does not have to be copied between RX and TX. Moreover, if a
>>> packet needs to be kept for a while due to a possible retransmit, the
>>> descriptor that points to that packet can be changed to point to
>>> another and reused right away. This again avoids copying data.
>>>
>>> This new dedicated packet buffer area is called a UMEM. It consists of
>>> a number of equally size frames and each frame has a unique frame
>>> id. A descriptor in one of the queues references a frame by
>>> referencing its frame id. The user space allocates memory for this
>>> UMEM using whatever means it feels is most appropriate (malloc, mmap,
>>> huge pages, etc). This memory area is then registered with the kernel
>>> using the new setsockopt XDP_UMEM_REG. The UMEM also has two queues:
>>> the FILL queue and the COMPLETION queue. The fill queue is used by the
>>> application to send down frame ids for the kernel to fill in with RX
>>> packet data. References to these frames will then appear in the RX
>>> queue of the XSK once they have been received. The completion queue,
>>> on the other hand, contains frame ids that the kernel has transmitted
>>> completely and can now be used again by user space, for either TX or
>>> RX. Thus, the frame ids appearing in the completion queue are ids that
>>> were previously transmitted using the TX queue. In summary, the RX and
>>> FILL queues are used for the RX path and the TX and COMPLETION queues
>>> are used for the TX path.
>>>
>> Can we register a UMEM to multiple device's queue?
>>
>
> No, one UMEM, one netdev queue in this RFC. That being said, there's
> nothing stopping a user from creating an additional UMEM, say UMEM',
> pointing to the same memory as UMEM, but bound to another
> netdev/queue. Note that the user space application has to make sure
> that the buffer handling is sane (user/kernel frame ownership).
>
> We used to allow to share UMEM between unrelated sockets, but after
> the introduction of the UMEM queues (fill/completion) that's no the
> case any more. For the zero-copy scenario, having to manage multiple
> DMA mappings per UMEM was a bit of a mess, so we went for the simpler
> (current) solution with one UMEM per netdev/queue.
>
>> So far the l2fwd sample code is sending/receiving from the same
>> queue. I'm thinking about forwarding packets from one device to another.
>> Now I'm copying packets from one device's RX desc to another device's TX
>> completion queue. But this introduces one extra copy.
>>
>
> So you've setup two identical UMEMs? Then you can just forward the
> incoming Rx descriptor to the other netdev's Tx queue. Note, that you
> only need to copy the descriptor, not the actual frame data.
>
Thanks!
I will give it a try, I guess you're saying I can do below:
int sfd1; // for device1
int sfd2; // for device2
...
// create 2 umem
umem1 = calloc(1, sizeof(*umem));
umem2 = calloc(1, sizeof(*umem));
// allocate 1 shared buffer, 1 xdp_umem_reg
posix_memalign(&bufs, ...)
mr.addr = (__u64)bufs; // shared for umem1,2
...
// umem reg the same mr
setsockopt(sfd1, SOL_XDP, XDP_UMEM_REG, &mr, sizeof(mr))
setsockopt(sfd2, SOL_XDP, XDP_UMEM_REG, &mr, sizeof(mr))
// setup fill, completion, mmap for sfd1 and sfd2
...
Since both device can put frame data in 'bufs', I only need to copy
the descs between 2 umem1 and umem2. Am I understand correct?
Regards,
William
^ permalink raw reply
* RE: [PATCH] lan78xx: Don't reset the interface on open
From: Nisar.Sayed @ 2018-04-10 14:16 UTC (permalink / raw)
To: phil, Woojung.Huh, UNGLinuxDriver, agraf, tbogendoerfer, netdev,
linux-usb, linux-kernel
In-Reply-To: <1523362705-30032-1-git-send-email-phil@raspberrypi.org>
Thanks Phil, for identifying the issues.
> - ret = lan78xx_reset(dev);
> - if (ret < 0)
> - goto done;
> -
> phy_start(net->phydev);
>
> netif_dbg(dev, ifup, dev->net, "phy initialised successfully");
> --
You may need to start the interrupts before "phy_start" instead of suppressing call to "lan78xx_reset".
+ if (dev->domain_data.phyirq > 0)
+ phy_start_interrupts(dev->net->phydev);
- Nisar
^ permalink raw reply
* Re: marvell switch
From: Ran Shalit @ 2018-04-10 14:21 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20180405204622.GE17495@lunn.ch>
On Thu, Apr 5, 2018 at 11:46 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> > Hi Ran
>> >
>> > The Marvell driver makes each port act like a normal Linux network
>> > interface. So if you want to enable a port, do
>> >
>> > ip link set lan0 up
>> >
>> > Want to add an ip address to a port
>> >
>> > ip addr add 10.42.42.42/24 dev lan0
>> >
I would please like to ask one more about it, if I may.
I thought I understood it all, but seems not.
The switch ports are connected to other PCs (except for one port which
is connected to cpu).
What is therefore the purpose of adding ip address to such ports (the
ip is configured externally in PC).
Thank you for the time,
ranran
>> > Want to bridge two ports
>> >
>> > ip link add name br0 type bridge
>> > ip link set dev br0 up
>> > ip link set dev lan0 master br0
>> > ip link set dev lan1 master br0
>> >
>> > Just treat them as normal interfaces.
>> >
>>
>> If I may please ask,
>> What is the purpose of using bridge for configuring switch interfaces.
>> Is it in order to isolate some ports from others?
>> I ask because according to my understanding the default configuration of
>> the driver is to enable switch in "flat" configuration, i.e. as if all
>> ports are connected to each other.
>
> Please think about what i said. They are standard Linux network
> interfaces. Do standard Linux network interfaces bridge themselves
> together by default? No, you need to configure a bridge.
>
> Andrew
^ permalink raw reply
* [PATCH] net: sbni: Replace mdelay with msleep in sbni_probe1
From: Jia-Ju Bai @ 2018-04-10 14:22 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-kernel, Jia-Ju Bai
sbni_probe1() is never called in atomic context.
The call chains ending up at sbni_probe1() are:
[1] sbni_probe1() <- sbni_init() <- sbni_probe() <- net_olddevs_init()
[2] sbni_probe1() <- sbni_isa_probe() <- sbni_init() <-
sbni_probe() <- net_olddevs_init()
[3] sbni_probe1() <- sbni_pci_probe() <- sbni_init() <-
sbni_probe() <- net_olddevs_init()
net_olddevs_init() is set as a parameter of device_initcall().
This function is not called in atomic context.
Despite never getting called from atomic context, sbni_probe1()
calls mdelay() to busily wait.
This is not necessary and can be replaced with msleep() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/net/wan/sbni.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/sbni.c b/drivers/net/wan/sbni.c
index bde8c03..b7dd665 100644
--- a/drivers/net/wan/sbni.c
+++ b/drivers/net/wan/sbni.c
@@ -361,7 +361,7 @@ static int __init sbni_init(struct net_device *dev)
irq_mask = probe_irq_on();
outb( EN_INT | TR_REQ, ioaddr + CSR0 );
outb( PR_RES, ioaddr + CSR1 );
- mdelay(50);
+ msleep(50);
irq = probe_irq_off(irq_mask);
outb( 0, ioaddr + CSR0 );
--
1.9.1
^ permalink raw reply related
* RE: [virtio-dev] Re: [RFC] vhost: introduce mdev based hardware vhost backend
From: Liang, Cunming @ 2018-04-10 14:23 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Paolo Bonzini, Bie, Tiwei, Jason Wang, alex.williamson@redhat.com,
ddutile@redhat.com, Duyck, Alexander H,
virtio-dev@lists.oasis-open.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
netdev@vger.kernel.org, Daly, Dan, Wang, Zhihong, Tan, Jianfeng,
Wang, Xiao W
In-Reply-To: <20180410163105-mutt-send-email-mst@kernel.org>
> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> Sent: Tuesday, April 10, 2018 9:36 PM
> To: Liang, Cunming <cunming.liang@intel.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>; Bie, Tiwei <tiwei.bie@intel.com>;
> Jason Wang <jasowang@redhat.com>; alex.williamson@redhat.com;
> ddutile@redhat.com; Duyck, Alexander H <alexander.h.duyck@intel.com>;
> virtio-dev@lists.oasis-open.org; linux-kernel@vger.kernel.org;
> kvm@vger.kernel.org; virtualization@lists.linux-foundation.org;
> netdev@vger.kernel.org; Daly, Dan <dan.daly@intel.com>; Wang, Zhihong
> <zhihong.wang@intel.com>; Tan, Jianfeng <jianfeng.tan@intel.com>; Wang, Xiao
> W <xiao.w.wang@intel.com>
> Subject: Re: [virtio-dev] Re: [RFC] vhost: introduce mdev based hardware vhost
> backend
>
> On Tue, Apr 10, 2018 at 09:23:53AM +0000, Liang, Cunming wrote:
> >
> >
> > > -----Original Message-----
> > > From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> > > Sent: Tuesday, April 10, 2018 3:52 PM
> > > To: Bie, Tiwei <tiwei.bie@intel.com>; Jason Wang
> > > <jasowang@redhat.com>
> > > Cc: mst@redhat.com; alex.williamson@redhat.com; ddutile@redhat.com;
> > > Duyck, Alexander H <alexander.h.duyck@intel.com>;
> > > virtio-dev@lists.oasis- open.org; linux-kernel@vger.kernel.org;
> > > kvm@vger.kernel.org; virtualization@lists.linux-foundation.org;
> > > netdev@vger.kernel.org; Daly, Dan <dan.daly@intel.com>; Liang,
> > > Cunming <cunming.liang@intel.com>; Wang, Zhihong
> > > <zhihong.wang@intel.com>; Tan, Jianfeng <jianfeng.tan@intel.com>;
> > > Wang, Xiao W <xiao.w.wang@intel.com>
> > > Subject: Re: [virtio-dev] Re: [RFC] vhost: introduce mdev based
> > > hardware vhost backend
> > >
> > > On 10/04/2018 06:57, Tiwei Bie wrote:
> > > >> So you just move the abstraction layer from qemu to kernel, and
> > > >> you still need different drivers in kernel for different device
> > > >> interfaces of accelerators. This looks even more complex than
> > > >> leaving it in qemu. As you said, another idea is to implement
> > > >> userspace vhost backend for accelerators which seems easier and
> > > >> could co-work with other parts of qemu without inventing new type of
> messages.
> > > >
> > > > I'm not quite sure. Do you think it's acceptable to add various
> > > > vendor specific hardware drivers in QEMU?
> > >
> > > I think so. We have vendor-specific quirks, and at some point there
> > > was an idea of using quirks to implement (vendor-specific) live
> > > migration support for assigned devices.
> >
> > Vendor-specific quirks of accessing VGA is a small portion. Other major portions
> are still handled by guest driver.
> >
> > While in this case, when saying various vendor specific drivers in QEMU, it says
> QEMU takes over and provides the entire user space device drivers. Some parts
> are even not relevant to vhost, they're basic device function enabling. Moreover,
> it could be different kinds of devices(network/block/...) under vhost. No matter
> # of vendors or # of types, total LOC is not small.
> >
> > The idea is to avoid introducing these extra complexity out of QEMU, keeping
> vhost adapter simple. As vhost protocol is de factor standard, it leverages kernel
> device driver to provide the diversity. Changing once in QEMU, then it supports
> multi-vendor devices whose drivers naturally providing kernel driver there.
> >
> > If QEMU is going to build a user space driver framework there, we're open mind
> on that, even leveraging DPDK as the underlay library. Looking forward to more
> others' comments from community.
> >
> > Steve
>
> Dependency on a kernel driver is fine IMHO. It's the dependency on a DPDK
> backend that makes people unhappy, since the functionality in question is setup-
> time only.
Agreed, we don't see dependency on kernel driver is a problem.
mdev based vhost backend (this patch set) is independent with vhost-user extension patch set. In fact, there're a few vhost-user providers, DPDK librte_vhost is one of them. FD.IO/VPP and snabbswitch have their own vhost-user providers. So I can't agree on vhost-user extension patch depends on DPDK backend. But anyway, that's the topic of another mail thread.
>
> As others said, we do not need to go overeboard. A couple of small vendor-
> specific quirks in qemu isn't a big deal.
It's quite challenge to identify it's small or not, there's no uniform metric.
It's only dependent on QEMU itself, that's the obvious benefit. Tradeoff is to build the entire device driver. We don't object to do that in QEMU, but wanna make sure to understand the boundary size clearly.
>
> > >
> > > Paolo
^ permalink raw reply
* Re: ath10k: avoid possible string overflow
From: Kalle Valo @ 2018-04-10 14:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kalle Valo, Arnd Bergmann, Manikanta Pubbisetty, Anilkumar Kolli,
Carl Huang, Gustavo A. R. Silva, Johannes Berg,
Maharaja Kennadyrajan, ath10k, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20180328220635.3704458-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> The way that 'strncat' is used here raised a warning in gcc-8:
>
> drivers/net/wireless/ath/ath10k/wmi.c: In function 'ath10k_wmi_tpc_stats_final_disp_tables':
> drivers/net/wireless/ath/ath10k/wmi.c:4649:4: error: 'strncat' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
>
> Effectively, this is simply a strcat() but the use of strncat() suggests
> some form of overflow check. Regardless of whether this might actually
> overflow, using strlcat() instead of strncat() avoids the warning and
> makes the code more robust.
>
> Fixes: bc64d05220f3 ("ath10k: debugfs support to get final TPC stats for 10.4 variants")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
6707ba0105a2 ath10k: avoid possible string overflow
--
https://patchwork.kernel.org/patch/10314201/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: avoid possible string overflow
From: Kalle Valo @ 2018-04-10 14:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Maharaja Kennadyrajan, Manikanta Pubbisetty, Johannes Berg,
Arnd Bergmann, netdev, Anilkumar Kolli, Carl Huang,
linux-wireless, linux-kernel, ath10k, Kalle Valo,
Gustavo A. R. Silva
In-Reply-To: <20180328220635.3704458-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> The way that 'strncat' is used here raised a warning in gcc-8:
>
> drivers/net/wireless/ath/ath10k/wmi.c: In function 'ath10k_wmi_tpc_stats_final_disp_tables':
> drivers/net/wireless/ath/ath10k/wmi.c:4649:4: error: 'strncat' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
>
> Effectively, this is simply a strcat() but the use of strncat() suggests
> some form of overflow check. Regardless of whether this might actually
> overflow, using strlcat() instead of strncat() avoids the warning and
> makes the code more robust.
>
> Fixes: bc64d05220f3 ("ath10k: debugfs support to get final TPC stats for 10.4 variants")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
6707ba0105a2 ath10k: avoid possible string overflow
--
https://patchwork.kernel.org/patch/10314201/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH net 1/2] tun: set the flags before registering the netdevice
From: Sabrina Dubroca @ 2018-04-10 14:28 UTC (permalink / raw)
To: netdev; +Cc: Sabrina Dubroca, Thomas Haller, Stefano Brivio
Otherwise, register_netdevice advertises the creation of the device with
the default flags, instead of what the user requested.
Reported-by: Thomas Haller <thaller@redhat.com>
Fixes: 1ec010e70593 ("tun: export flags, uid, gid, queue information over netlink")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
---
drivers/net/tun.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index a1ba262f40ad..c9e68fd76a37 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2564,6 +2564,9 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
*/
return 0;
}
+
+ tun->flags = (tun->flags & ~TUN_FEATURES) |
+ (ifr->ifr_flags & TUN_FEATURES);
}
else {
char *name;
@@ -2642,6 +2645,9 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
~(NETIF_F_HW_VLAN_CTAG_TX |
NETIF_F_HW_VLAN_STAG_TX);
+ tun->flags = (tun->flags & ~TUN_FEATURES) |
+ (ifr->ifr_flags & TUN_FEATURES);
+
INIT_LIST_HEAD(&tun->disabled);
err = tun_attach(tun, file, false, ifr->ifr_flags & IFF_NAPI);
if (err < 0)
@@ -2656,9 +2662,6 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
tun_debug(KERN_INFO, tun, "tun_set_iff\n");
- tun->flags = (tun->flags & ~TUN_FEATURES) |
- (ifr->ifr_flags & TUN_FEATURES);
-
/* Make sure persistent devices do not get stuck in
* xoff state.
*/
--
2.16.2
^ permalink raw reply related
* [PATCH net 2/2] tun: send netlink notification when the device is modified
From: Sabrina Dubroca @ 2018-04-10 14:28 UTC (permalink / raw)
To: netdev; +Cc: Sabrina Dubroca, Thomas Haller, Stefano Brivio
In-Reply-To: <0b61a3298ffa3a3fbc4ae0cae1573b368301a211.1523370272.git.sd@queasysnail.net>
I added dumping of link information about tun devices over netlink in
commit 1ec010e70593 ("tun: export flags, uid, gid, queue information
over netlink"), but didn't add the missing netlink notifications when
the device's exported properties change.
This patch adds notifications when owner/group or flags are modified,
when queues are attached/detached, and when a tun fd is closed.
Reported-by: Thomas Haller <thaller@redhat.com>
Fixes: 1ec010e70593 ("tun: export flags, uid, gid, queue information over netlink")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
---
drivers/net/tun.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index c9e68fd76a37..28583aa0c17d 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -743,8 +743,15 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
static void tun_detach(struct tun_file *tfile, bool clean)
{
+ struct tun_struct *tun;
+ struct net_device *dev;
+
rtnl_lock();
+ tun = rtnl_dereference(tfile->tun);
+ dev = tun ? tun->dev : NULL;
__tun_detach(tfile, clean);
+ if (dev)
+ netdev_state_change(dev);
rtnl_unlock();
}
@@ -2562,13 +2569,15 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
/* One or more queue has already been attached, no need
* to initialize the device again.
*/
+ netdev_state_change(dev);
return 0;
}
tun->flags = (tun->flags & ~TUN_FEATURES) |
(ifr->ifr_flags & TUN_FEATURES);
- }
- else {
+
+ netdev_state_change(dev);
+ } else {
char *name;
unsigned long flags = 0;
int queues = ifr->ifr_flags & IFF_MULTI_QUEUE ?
@@ -2808,6 +2817,9 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
} else
ret = -EINVAL;
+ if (ret >= 0)
+ netdev_state_change(tun->dev);
+
unlock:
rtnl_unlock();
return ret;
@@ -2848,6 +2860,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
unsigned int ifindex;
int le;
int ret;
+ bool do_notify = false;
if (cmd == TUNSETIFF || cmd == TUNSETQUEUE ||
(_IOC_TYPE(cmd) == SOCK_IOC_TYPE && cmd != SIOCGSKNS)) {
@@ -2944,10 +2957,12 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
if (arg && !(tun->flags & IFF_PERSIST)) {
tun->flags |= IFF_PERSIST;
__module_get(THIS_MODULE);
+ do_notify = true;
}
if (!arg && (tun->flags & IFF_PERSIST)) {
tun->flags &= ~IFF_PERSIST;
module_put(THIS_MODULE);
+ do_notify = true;
}
tun_debug(KERN_INFO, tun, "persist %s\n",
@@ -2962,6 +2977,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
break;
}
tun->owner = owner;
+ do_notify = true;
tun_debug(KERN_INFO, tun, "owner set to %u\n",
from_kuid(&init_user_ns, tun->owner));
break;
@@ -2974,6 +2990,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
break;
}
tun->group = group;
+ do_notify = true;
tun_debug(KERN_INFO, tun, "group set to %u\n",
from_kgid(&init_user_ns, tun->group));
break;
@@ -3133,6 +3150,9 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
break;
}
+ if (do_notify)
+ netdev_state_change(tun->dev);
+
unlock:
rtnl_unlock();
if (tun)
--
2.16.2
^ permalink raw reply related
* Re: [next] wil6210: fix potential null dereference of ndev before null check
From: Kalle Valo @ 2018-04-10 14:30 UTC (permalink / raw)
To: Colin Ian King
Cc: Maya Erez, linux-wireless, wil6210, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20180328174027.31551-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> The pointer ndev is being dereferenced before it is being null checked,
> hence there is a potential null pointer deference. Fix this by only
> dereferencing ndev after it has been null checked
>
> Detected by CoverityScan, CID#1467010 ("Dereference before null check")
>
> Fixes: e00243fab84b ("wil6210: infrastructure for multiple virtual interfaces")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Maya Erez <merez@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
db5a4d5e1073 wil6210: fix potential null dereference of ndev before null check
--
https://patchwork.kernel.org/patch/10313705/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: fix spelling mistake: "tiggers" -> "triggers"
From: Kalle Valo @ 2018-04-10 14:32 UTC (permalink / raw)
To: Colin Ian King
Cc: Kalle Valo, ath10k, linux-wireless, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20180329165949.29155-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> Trivial fix to spelling mistake in message text
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
6ce36faeac35 ath10k: fix spelling mistake: "tiggers" -> "triggers"
--
https://patchwork.kernel.org/patch/10315725/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: fix spelling mistake: "tiggers" -> "triggers"
From: Kalle Valo @ 2018-04-10 14:32 UTC (permalink / raw)
To: Colin Ian King
Cc: linux-wireless, netdev, kernel-janitors, linux-kernel, ath10k,
Kalle Valo
In-Reply-To: <20180329165949.29155-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> Trivial fix to spelling mistake in message text
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
6ce36faeac35 ath10k: fix spelling mistake: "tiggers" -> "triggers"
--
https://patchwork.kernel.org/patch/10315725/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath9k: dfs: remove accidental use of stack VLA
From: Kalle Valo @ 2018-04-10 14:33 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: QCA ath9k Development, linux-wireless, netdev, linux-kernel,
Gustavo A. R. Silva
In-Reply-To: <20180330183401.GA16758@embeddedgus>
"Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
> In preparation to enabling -Wvla, remove accidental use of stack VLA.
>
> This avoids an accidental stack VLA (since the compiler thinks
> the value of FFT_NUM_SAMPLES can change, even when marked
> "const"). This just replaces it with a #define.
>
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
9c27489a3454 ath9k: dfs: remove accidental use of stack VLA
--
https://patchwork.kernel.org/patch/10318271/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] lan78xx: Don't reset the interface on open
From: Phil Elwell @ 2018-04-10 14:33 UTC (permalink / raw)
To: Nisar.Sayed, Woojung.Huh, UNGLinuxDriver, agraf, tbogendoerfer,
netdev, linux-usb, linux-kernel
In-Reply-To: <CE371C1263339941885964188A0225FA3A3F82@CHN-SV-EXMX03.mchp-main.com>
Hi Nisar,
On 10/04/2018 15:16, Nisar.Sayed@microchip.com wrote:
> Thanks Phil, for identifying the issues.
>
>> - ret = lan78xx_reset(dev);
>> - if (ret < 0)
>> - goto done;
>> -
>> phy_start(net->phydev);
>>
>> netif_dbg(dev, ifup, dev->net, "phy initialised successfully");
>> --
>
> You may need to start the interrupts before "phy_start" instead of suppressing call to "lan78xx_reset".
>
> + if (dev->domain_data.phyirq > 0)
> + phy_start_interrupts(dev->net->phydev);
Shouldn't phy_connect_direct, called from lan78xx_phy_init, already have enabled interrupts for us?
This patch addresses two problems - time wasted by renegotiating the link after the reset and the
missed interrupt - and I'd like both to be fixed. Unless you can come up with a good reason for
performing the reset from the open handler I think it should be removed.
Phil
^ 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