According to AM335x TRM[1] 14.3.6.2, AM437x TRM[2] 15.3.6.2 and
DRA7 TRM[3] 24.11.4.8.7.3.3, in-band mode in EXT_EN(bit18) register is only
available when PHY is configured in RGMII mode with 10Mbps speed. It will
cause some networking issues without RGMII mode, such as carrier sense
errors and low
Hi Arnd,
On Wed, 14 Mar 2018 16:35:13 +0100
Arnd Bergmann wrote:
> Hi driver maintainers,
>
> I just posted one series with the removal of eight architectures,
> see https://lkml.org/lkml/2018/3/14/505 for details, or
> https://lwn.net/Articles/748074/ for more background.
>
> These are the de
Hi Netdev
https://goo.gl/UjB6a9
Avery
On 03/14/2018 08:10 PM, John Fastabend wrote:
> On 03/14/2018 06:53 PM, Eric Dumazet wrote:
>> syzbot reported one use-after-free in pfifo_fast_enqueue() [1]
>>
>> Issue here is that we can not reuse skb after a successful
>> skb_array_produce()
>> since another cpu might have consumed it already.
On Wed, 14 Mar 2018, Nicolas Pitre wrote:
> On Wed, 14 Mar 2018, Arnd Bergmann wrote:
>
> > The m32r architecture is getting removed, so this part can be
> > cleaned up as well.
> >
> > Signed-off-by: Arnd Bergmann
>
> Acked-by: Nicolas Pitre
>
> > ---
> > drivers/net/ethernet/smsc/Kconfig
On Wed, Mar 14, 2018 at 05:17:54PM -0700, Eric Dumazet wrote:
>
>
> On 03/14/2018 11:41 AM, Alexei Starovoitov wrote:
> > On Wed, Mar 14, 2018 at 11:00 AM, Alexei Starovoitov
> > wrote:
> >>
> >>> It seems this is exactly the case where a netns would be the correct
> >>> answer.
> >>
> >> Unfor
On Wed, Mar 14, 2018 at 08:14:53PM -0700, David Ahern wrote:
> On 3/13/18 2:13 PM, Jason Gunthorpe wrote:
> > Could you pull the uapi headers from linux-next? That tree will have
> > both netdev and rdma stuff merged together properly.
>
> What's the merge history between linux-next, Linus' tree,
On 3/13/18 2:13 PM, Jason Gunthorpe wrote:
> Could you pull the uapi headers from linux-next? That tree will have
> both netdev and rdma stuff merged together properly.
What's the merge history between linux-next, Linus' tree, net-next +
rdma-next?
On 03/14/2018 06:53 PM, Eric Dumazet wrote:
> syzbot reported one use-after-free in pfifo_fast_enqueue() [1]
>
> Issue here is that we can not reuse skb after a successful skb_array_produce()
> since another cpu might have consumed it already.
>
> I believe a similar problem exists in try_bulk_de
From: Matthew Wilcox
The mlx5 driver calls ida_pre_get() in a loop for no readily apparent
reason. The driver uses ida_simple_get() which will call ida_pre_get()
by itself and there's no need to use ida_pre_get() unless using
ida_get_new().
Signed-off-by: Matthew Wilcox
diff --git a/drivers/n
The use of stack Variable Length Arrays needs to be avoided, as they
can be a vector for stack exhaustion, which can be both a runtime bug
(kernel Oops) or a security flaw (overwriting memory beyond the
stack). Also, in general, as code evolves it is easy to lose track of
how big a VLA can get. Thu
On Wed, Mar 14, 2018 at 05:26:24PM -0500, Grygorii Strashko wrote:
> Some ethernet drivers (like TI CPSW) may connect and manage >1 Net PHYs per
> one netdevice, as result such drivers will produce warning during system
> boot and fail to connect second phy to netdevice when PHYLIB framework
> will
On 3/14/2018 9:44 PM, Alexander Duyck wrote:
> On Wed, Mar 14, 2018 at 3:57 PM, Sinan Kaya wrote:
>> Hi Alexander,
>>
>> On 3/14/2018 5:49 PM, Alexander Duyck wrote:
>>> On Wed, Mar 14, 2018 at 5:13 AM, wrote:
On 2018-03-14 01:08, Timur Tabi wrote:
>
> On 3/13/18 10:20 PM, Sinan Kay
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/ipv4/xfrm4_policy.c
between commit:
d52e5a7e7ca4 ("ipv4: lock mtu in fnhe when received PMTU <
net.ipv4.route.min_pmtu")
from the net tree and commit:
68e813aa4307 ("net/ipv4: Remove fib table id from rtable")
On Wed, Mar 14, 2018 at 6:48 PM Eric Dumazet wrote:
> syzbot reported one use-after-free in pfifo_fast_enqueue() [1]
> Issue here is that we can not reuse skb after a successful
skb_array_produce()
> since another cpu might have consumed it already.
> I believe a similar problem exists in try_b
On Tue, Mar 13, 2018 at 8:19 PM, Sinan Kaya wrote:
> Code includes wmb() followed by writel(). writel() already has a barrier
> on some architectures like arm64.
>
> This ends up CPU observing two barriers back to back before executing the
> register write.
>
> Since code already has an explicit b
syzbot reported one use-after-free in pfifo_fast_enqueue() [1]
Issue here is that we can not reuse skb after a successful skb_array_produce()
since another cpu might have consumed it already.
I believe a similar problem exists in try_bulk_dequeue_skb_slow()
in case we put an skb into qdisc_enqueu
On Tue, Mar 13, 2018 at 8:20 PM, Sinan Kaya wrote:
> Code includes wmb() followed by writel(). writel() already has a barrier
> on some architectures like arm64.
>
> This ends up CPU observing two barriers back to back before executing the
> register write.
>
> Since code already has an explicit b
On Tue, Mar 13, 2018 at 8:20 PM, Sinan Kaya wrote:
> Code includes wmb() followed by writel(). writel() already has a barrier
> on some architectures like arm64.
>
> This ends up CPU observing two barriers back to back before executing the
> register write.
>
> Since code already has an explicit b
syzbot reported one use-after-free in pfifo_fast_enqueue() [1]
Issue here is that we can not reuse skb after a successful skb_array_produce()
since another cpu might have consumed it already.
I believe a similar problem exists in try_bulk_dequeue_skb_slow()
in case we put an skb into qdisc_enqueu
On Tue, Mar 13, 2018 at 8:20 PM, Sinan Kaya wrote:
> Code includes wmb() followed by writel() in multiple places. writel()
> already has a barrier on some architectures like arm64.
>
> This ends up CPU observing two barriers back to back before executing the
> register write.
>
> Since code alread
On Tue, Mar 13, 2018 at 8:20 PM, Sinan Kaya wrote:
> Code includes wmb() followed by writel() in multiple places. writel()
> already has a barrier on some architectures like arm64.
>
> This ends up CPU observing two barriers back to back before executing the
> register write.
>
> Since code alread
On Wed, Mar 14, 2018 at 3:57 PM, Sinan Kaya wrote:
> Hi Alexander,
>
> On 3/14/2018 5:49 PM, Alexander Duyck wrote:
>> On Wed, Mar 14, 2018 at 5:13 AM, wrote:
>>> On 2018-03-14 01:08, Timur Tabi wrote:
On 3/13/18 10:20 PM, Sinan Kaya wrote:
>
>> Actually I would argue this whole patch
On Tue, Mar 13, 2018 at 8:20 PM, Sinan Kaya wrote:
> Code includes wmb() followed by writel(). writel() already has a barrier
> on some architectures like arm64.
>
> This ends up CPU observing two barriers back to back before executing the
> register write.
>
> Since code already has an explicit b
From: Subash Abhinov Kasiviswanathan
Date: Wed, 14 Mar 2018 13:27:41 -0600
>> Please address Joe's feedback and only update the copyright date on
>> files that actually had changes this year.
>> Thank you.
>
> Hi David
>
> I have fixed that now in v3.
> However, patchwork is not showing the ent
On 03/14/2018 05:16 PM, Eric Dumazet wrote:
>
> typical use after free...
>
> diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
> index
> 190570f21b208d5a17943360a3a6f85e1c2a2187..663e016491773f40f81d9bbfeab3dd68e1c2fc5c
> 100644
> --- a/net/sched/sch_generic.c
> +++ b/net/sched
> On Mar 14, 2018, at 5:29 PM, Daniel Borkmann wrote:
>
> On 03/14/2018 06:23 PM, Song Liu wrote:
>> Changes v4 -> v6:
>>
>> 1. When kernel stack is added to stackmap with build_id, use fallback
>> mechanism to store ip (status == BPF_STACK_BUILD_ID_IP).
>>
>> Changes v4 -> v5:
>>
>> 1. On
On 3/14/18 4:27 PM, Daniel Borkmann wrote:
On 03/14/2018 07:11 PM, Alexei Starovoitov wrote:
On Wed, Mar 14, 2018 at 03:37:01PM +0100, Daniel Borkmann wrote:
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -133,6 +133,8 @@ enum bpf_prog_type {
BPF_PROG_TYPE_SOCK_OPS,
On 03/14/2018 06:23 PM, Song Liu wrote:
> Changes v4 -> v6:
>
> 1. When kernel stack is added to stackmap with build_id, use fallback
>mechanism to store ip (status == BPF_STACK_BUILD_ID_IP).
>
> Changes v4 -> v5:
>
> 1. Only allow build_id lookup in non-nmi context. Added comment and
>c
On 03/14/2018 11:41 AM, Alexei Starovoitov wrote:
> On Wed, Mar 14, 2018 at 11:00 AM, Alexei Starovoitov
> wrote:
>>
>>> It seems this is exactly the case where a netns would be the correct answer.
>>
>> Unfortuantely that's not the case. That's what I tried to explain
>> in the cover letter:
>>
On 03/14/2018 04:30 PM, syzbot wrote:
> syzbot has found reproducer for the following crash on net-next commit
> a870a02cc963de35452bbed932560ed69725c4f2 (Tue Mar 13 20:58:39 2018 +)
> pktgen: use dynamic allocation for debug print buffer
>
> So far this crash happened 7 times on mmots, net-
This patch adds a receive method to NETLINK_KOBJECT_UEVENT netlink sockets
to allow sending uevent messages into the network namespace the socket
belongs to.
Currently non-initial network namespaces are already isolated and don't
receive uevents. There are a number of cases where it is beneficial
On 03/14/2018 01:16 PM, Heiner Kallweit wrote:
> Currently phy_stop() just sets the state to PHY_HALTED and relies on the
> state machine to do the remaining work. It can take up to 1s until the
> state machine runs again what causes issues in situations where e.g.
> driver / device is brought down
On 03/14/2018 01:10 PM, Heiner Kallweit wrote:
> This patch series aims to tackle few issues with phylib:
>
> - address issues with patch series [1] (smsc911x + phylib changes)
> - make phy_stop synchronous
> - get rid of phy_start/stop_machine and handle it in phy_start/phy_stop
> - in mdio_susp
On 03/14/2018 01:16 PM, Heiner Kallweit wrote:
> Currently the PHY is unconditionally resumed in mdio_bus_phy_suspend().
> In cases where the PHY was sleepinh before suspending or if somebody else
> takes care of resuming later, this is not needed and wastes energy.
>
> Also start the state machin
On Wed, Mar 14, 2018 at 10:55:52AM -0500, Razvan Stefanescu wrote:
> This patchset introduces the Ethernet Switch Driver for Freescale/NXP SoCs
> with DPAA2 (DataPath Acceleration Architecture v2). The driver manages
> switch objects discovered on the fsl-mc bus. A description of the driver
> can b
On Wed, Mar 14, 2018 at 02:54:35PM -0700, Vinicius Costa Gomes wrote:
> Hi,
>
> Changes from v1:
> - Fixed comments from Willem de Bruijn, about the order of the
> options passed to getopt();
> - Added Reviewed-by and Fixes tags to patch (2);
>
> Changes from the RFC:
> - tweaked commit messa
On 03/14/2018 07:11 PM, Alexei Starovoitov wrote:
> On Wed, Mar 14, 2018 at 03:37:01PM +0100, Daniel Borkmann wrote:
>>> --- a/include/uapi/linux/bpf.h
>>> +++ b/include/uapi/linux/bpf.h
>>> @@ -133,6 +133,8 @@ enum bpf_prog_type {
>>> BPF_PROG_TYPE_SOCK_OPS,
>>> BPF_PROG_TYPE_SK_SKB,
>>>
> @@ -2082,8 +2082,6 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
>
> dev->fc_autoneg = phydev->autoneg;
>
> - phy_start(phydev);
> -
> netif_dbg(dev, ifup, dev->net, "phy initialised successfully");
>
> return 0;
> @@ -2512,9 +2510,7 @@ static int lan78xx_ope
From: Raghu Vatsavayi
Signed-off-by: Raghu Vatsavayi
Acked-by: Derek Chickles
Signed-off-by: Felix Manlunas
---
drivers/net/ethernet/cavium/liquidio/lio_core.c| 23
drivers/net/ethernet/cavium/liquidio/lio_main.c| 25 +-
drivers/net/ethernet/ca
Hi Alexander,
On 3/14/2018 5:49 PM, Alexander Duyck wrote:
> On Wed, Mar 14, 2018 at 5:13 AM, wrote:
>> On 2018-03-14 01:08, Timur Tabi wrote:
>>>
>>> On 3/13/18 10:20 PM, Sinan Kaya wrote:
> Actually I would argue this whole patch set is pointless. For starters
> why is it we are only updating
> I've got additional testing data and this actually a *regression*, because
> second CPSW Port became broken after above commits due to Net PHY
> connection failure.
Hi Grygorii
I'm not sure this works by design, more by chance. And i think this is
the only MAC driver which does this. Can i su
hello Cong, thank you for reviewing this.
On Wed, 2018-03-14 at 11:41 -0700, Cong Wang wrote:
> On Tue, Mar 13, 2018 at 7:13 PM, Davide Caratti wrote:
>
> Looks like we just need to replace the tcf_idr_cleanup() with
> tcf_idr_release()? Which is also simpler.
I just tried it on act_simple, and
On 2018-03-14 16:08, Kalle Valo wrote:
Arend van Spriel writes:
On 3/14/2018 3:24 PM, Kalle Valo wrote:
+config BRCMFMAC_IAPP
>+ bool "Partial support for obsoleted Inter-Access Point Protocol"
>+ depends on BRCMFMAC
>+ ---help---
>+ Most of Broadcom's firmwares can send 802.11f ADD
The sysfs_create_link_nowarn() is going to be used in phylib framework in
suseuent patch which can be built as module. Hence, export
sysfs_create_link_nowarn() to avoid build errors.
Cc: Florian Fainelli
Fixes: a3995460491d ("net: phy: Relax error checking on sysfs_create_link()")
Signed-off-by:
Some ethernet drivers (like TI CPSW) may connect and manage >1 Net PHYs per
one netdevice, as result such drivers will produce warning during system
boot and fail to connect second phy to netdevice when PHYLIB framework
will try to create sysfs link netdev->phydev for second PHY
in phy_attach_direc
Some ethernet drivers (like TI CPSW) may connect and manage >1 Net PHYs per
one netdevice, as result such drivers will produce warning during system
boot and fail to connect second phy to netdevice when PHYLIB framework
will try to create sysfs link netdev->phydev for second PHY
in phy_attach_direc
On Mon, 2018-03-12 at 19:05 -0700, Shannon Nelson wrote:
> On 3/9/2018 9:21 AM, Anirudh Venkataramanan wrote:
> > A control queue is a hardware interface which is used by the driver
> > to interact with other subsystems (like firmware, PHY, etc.). It is
> > implemented as a producer-consumer ring.
On Mon, 2018-03-12 at 19:05 -0700, Shannon Nelson wrote:
> On 3/9/2018 9:21 AM, Anirudh Venkataramanan wrote:
> > This patch implements multiple pieces of the initialization flow
> > as follows:
> >
> > 1) A reset is issued to ensure a clean device state, followed
> > by initialization of admi
When errors are enqueued to the error queue via sock_queue_err_skb()
function, it is possible that the waiting application is not notified.
Calling 'sk->sk_data_ready()' would not notify applications that
selected only POLLERR events in poll() (for example).
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2
Add a way to configure if poll() should wait forever for an event, the
number of packets that should be sent for each and if there should be
any delay between packets.
Signed-off-by: Vinicius Costa Gomes
---
.../selftests/networking/timestamping/txtimestamp.c | 21 ++---
1 file c
Hi,
Changes from v1:
- Fixed comments from Willem de Bruijn, about the order of the
options passed to getopt();
- Added Reviewed-by and Fixes tags to patch (2);
Changes from the RFC:
- tweaked commit messages;
Original cover letter:
This is actually a "bug report"-RFC instead of the more us
On Wed, Mar 14, 2018 at 5:13 AM, wrote:
> On 2018-03-14 01:08, Timur Tabi wrote:
>>
>> On 3/13/18 10:20 PM, Sinan Kaya wrote:
>>>
>>> +/* Assumes caller has executed a write barrier to order memory and
>>> device
>>> + * requests.
>>> + */
>>> static inline void ixgbevf_write_tail(struct ixgbev
On (03/14/18 14:28), Eric Dumazet wrote:
>
>
> spin_lock_bh(&rds_tcp_conn_lock);/spin_unlock_bh(&rds_tcp_conn_lock); in
> rds_tcp_conn_free()
>
> is in conflict with the spin_lock_irqsave(&rds_conn_lock, flags);
> in __rds_conn_create()
yes I was going to look into this and fix it later.
> Har
This will allow usage of vsock from 32-bit binaries on a 64-bit
kernel.
Signed-off-by: Sonny Rao
---
drivers/vhost/vsock.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index 0d14e2ff19f16..ee0c385d9fe54 100644
--- a/drivers/vhost/
On 03/14/2018 01:11 PM, syzbot wrote:
Hello,
syzbot hit the following crash on net-next commit
be9fc0971a5c27b791608cf9705a04fe96dbd395 (Tue Mar 13 11:44:53 2018 +)
net: fix sysctl_fb_tunnels_only_for_init_net link error
So far this crash happened 2 times on net-next.
Unfortunately, I don
If the optional regulator is deferrred, we must release some resources.
They will be re-allocated when the probe function will be called again.
Fixes: 6eacf31139bf ("ethernet: arc: Add support for Rockchip SoC layer device
tree bindings")
Signed-off-by: Christophe JAILLET
---
drivers/net/ethern
On 3/14/2018 5:10 PM, Kalle Valo wrote:
Rafał Miłecki writes:
+ unsigned char *eth_data = skb_mac_header(skb) + ETH_HLEN;
+#if !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
#ifndef?
I followed what is used in the include/linux/etherdevice.h. Is that a
good exceuse? Could it be the
On Wed, Mar 14, 2018 at 08:46:21PM +, Al Viro wrote:
> use proc_remove_subtree() for subtree removal, both on setup failure
> halfway through and on teardown. No need to make simple things
> complex...
... and sctp_dbg_objcnt_exit() can be removed as well - remove_proc_subtree()
will get that
use proc_remove_subtree() for subtree removal, both on setup failure
halfway through and on teardown. No need to make simple things
complex...
Signed-off-by: Al Viro
---
include/net/sctp/sctp.h | 9 +
net/sctp/proc.c | 90
+--
On 3/14/2018 4:57 PM, Rafał Miłecki wrote:
On 2018-03-14 16:39, Rafał Miłecki wrote:
On 2018-03-14 13:58, Arend van Spriel wrote:
On 3/14/2018 12:01 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
Testing brcmfmac with more recent firmwares resulted in AP interfaces
not working in some specific
On 2018-03-14 16:39, Rafał Miłecki wrote:
On 2018-03-14 13:58, Arend van Spriel wrote:
On 3/14/2018 12:01 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
Testing brcmfmac with more recent firmwares resulted in AP interfaces
not working in some specific setups. Debugging resulted in
discovering
From: Gustavo A R Silva
It seems this is a copy-paste error and that the proper variable to use
in this particular case is _src_ instead of _dst_.
Addresses-Coverity-ID: 1465282 ("Copy-paste error")
Fixes: 0075fa0fadd0 ("i40evf: Add support to apply cloud filters")
Signed-off-by: Gustavo A R Sil
From: Filip Sadowski
When VF requests adding of MAC filters the checking is done against number
of already present MAC filters not adding them at the same time. It makes
it possible to add a bunch of filters at once possibly exceeding
acceptable limit of I40E_VC_MAX_MAC_ADDR_PER_VF filters.
This
This series contains updates to i40e and i40evf only.
Corentin Labbe cleans up the left over FCoE files in the i40e driver.
Gustavo A R Silva fixes a cut and paste error.
Paweł fixes a race condition when the VF driver is loaded on a host and
virsh is trying to attach it to the virtual machine a
From: Jacob Keller
When hardware has trouble with a particular filter, we delete it from
the list. Unfortunately, we did not properly update the per-filter
statistic when doing so.
Create a helper function to handle this, and properly reduce the
necessary counter so that it tracks the number of
From: Corentin Labbe
i40e_fcoe support was removed via commit 9eed69a9147c ("i40e: Drop FCoE code
from core driver files")
But this left files in place but un-compilable.
Let's finish the cleaning.
Signed-off-by: Corentin Labbe
Tested-by: Andrew Bowers
Signed-off-by: Jeff Kirsher
---
driver
From: Paweł Jabłoński
Fix for "Resource temporarily unavailable" problem when virsh is
trying to attach a device to VM. When the VF driver is loaded on
host and virsh is trying to attach it to the VM and set a MAC
address, it ends with a race condition between i40e_reset_vf and
i40e_ndo_set_vf_ma
From: Jacob Keller
A future patch needs to expand on the logic for re-enabling ATR. Doing
so would cause some code to break the 80-character line limit.
To reduce the level of indentation, factor out helper functions for
re-enabling ATR and SB rules.
Signed-off-by: Jacob Keller
Tested-by: Andr
From: Jacob Keller
When we re-enable ATR we need to restore the input set for TCPv4
filters, in order for ATR to function correctly. We already do this for
the normal case of re-enabling ATR when disabling ntuple support.
However, when re-enabling ATR after the last TCPv4 filter is removed (but
w
From: Mariusz Stachura
This patch overwrites number of ports for X722 devices with support
for OCP PHY mezzanine.
The old method with checking if port is disabled in the PRTGEN_CNF
register cannot be used in this case. When the OCP is removed, ports
were seen as disabled, which resulted in wrong
From: Jacob Keller
We used to use the function i40e_vlan_rx_register as a way to hook
into the now defunct .ndo_vlan_rx_register netdev hook. This was
removed but we kept the function around because we still used it
internally to control enabling or disabling of VLAN stripping.
As pointed out in
On Wed, Mar 14, 2018 at 12:05 PM, Michael S. Tsirkin wrote:
> On Wed, Mar 14, 2018 at 10:26:05AM -0700, Sonny Rao wrote:
>> This will allow usage of vsock from 32-bit binaries on a 64-bit
>> kernel.
>>
>> Signed-off-by: Sonny Rao
>
> I think you need to convert the pointer argument though.
> Some
When errors are enqueued to the error queue via sock_queue_err_skb()
function, it is possible that the waiting application is not notified.
Calling 'sk->sk_data_ready()' would not notify applications that
selected only POLLERR events in poll() (for example).
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2
Hello,
For example, it can be fixed in such way (patch is below):
- split handling of default and all/any
- set needed attributes in get_addr: PREFIXLEN_SPECIFIED flag for default
- and AF_UNSPEC for all/any
In this case "ip route show default" shows only default route and "ip
route show all" sh
On 03/14/2018 02:50 PM, Florian Fainelli wrote:
> On 03/14/2018 12:40 PM, Grygorii Strashko wrote:
>>
>>
>> On 02/26/2018 02:16 PM, Florian Fainelli wrote:
>>> On 02/26/2018 12:08 PM, Grygorii Strashko wrote:
Hi Florian,
The TI CPSW driver produces warning as below when booted in s
On Wed, Mar 14, 2018 at 11:19:53AM +0200, Kalle Valo wrote:
> "Tobin C. Harding" writes:
>
> > Added Konstantin in case he is in charge of administering
> > patchwork.kernel.org?
> >
> > On Tue, Mar 13, 2018 at 07:53:34PM -0700, Kees Cook wrote:
> >> On Tue, Mar 13, 2018 at 7:11 PM, Tobin C. Har
Currently the PHY is unconditionally resumed in mdio_bus_phy_suspend().
In cases where the PHY was sleepinh before suspending or if somebody else
takes care of resuming later, this is not needed and wastes energy.
Also start the state machine only if it's used by the driver (indicated
by the adjus
This patch improves and unifies checking for when PHY is allowed to
suspend. New is a check for the parent of the MDIO bus being
runtime-suspended. In this case the MDIO bus may not be accessible and
therefore we don't try to suspend the PHY. Instead we rely on the
parent to suspend all devices on
Currently phy_stop() just sets the state to PHY_HALTED and relies on the
state machine to do the remaining work. It can take up to 1s until the
state machine runs again what causes issues in situations where e.g.
driver / device is brought down directly after executing phy_stop().
Fix this by exec
Now that the functionality of phy_stop() was integrated to __phy_stop()
we can remove phy_stop_machine().
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/phy.c| 18 --
drivers/net/phy/phy_device.c | 2 --
include/linux/phy.h | 1 -
3 files changed, 21 deleti
nlmsg_multicast() consumes always the skb, thus the original skb must be
freed only when this function is called with a clone.
Fixes: cb9f7a9a5c96 ("netlink: ensure to loop over all netns in
genlmsg_multicast_allns()")
Reported-by: Ben Hutchings
Signed-off-by: Nicolas Dichtel
---
net/netlink/g
Use new function phy_stop_suspending() in mdio_bus_phy_suspend() to also
disable interrupts and set link state to down.
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/phy_device.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/driver
Now that phy_start() integrated the functionality of phy_start_machine()
we can remove it.
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/phy.c| 16
drivers/net/phy/phy_device.c | 1 -
drivers/net/phy/phylink.c| 1 -
include/linux/phy.h | 1 -
4 files
In subsequent patches of this series interrupts will be disabled during
system suspend, also we will have to resume the PHY in states other than
PHY_HALTED. To prepare for this unconditionally resume and re-enable
interrupts in phy_start().
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/phy.
This patch series aims to tackle few issues with phylib:
- address issues with patch series [1] (smsc911x + phylib changes)
- make phy_stop synchronous
- get rid of phy_start/stop_machine and handle it in phy_start/phy_stop
- in mdio_suspend consider runtime pm state of mdio bus parent
- consider
Hi,
"Brown, Aaron F" writes:
>> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
>> Behalf Of Vinicius Costa Gomes
>> Sent: Wednesday, March 7, 2018 4:37 PM
>> To: intel-wired-...@lists.osuosl.org
>> Cc: netdev@vger.kernel.org; Sanchez-Palencia, Jesus > palen...@intel.com>
>>
On 03/14/2018 12:40 PM, Grygorii Strashko wrote:
>
>
> On 02/26/2018 02:16 PM, Florian Fainelli wrote:
>> On 02/26/2018 12:08 PM, Grygorii Strashko wrote:
>>> Hi Florian,
>>>
>>> The TI CPSW driver produces warning as below when booted in switch mode:
>>> [8.882295] sysfs: cannot create dupli
On Thu, Mar 15, 2018 at 12:12:32AM +0800, Xin Long wrote:
> On Wed, Mar 14, 2018 at 9:59 PM, Neil Horman wrote:
> > On Wed, Mar 14, 2018 at 07:05:30PM +0800, Xin Long wrote:
> >> With refcnt support for sh_key, chunks auth sh_keys can be decided
> >> before enqueuing it. Changing the active key la
On 02/26/2018 02:16 PM, Florian Fainelli wrote:
> On 02/26/2018 12:08 PM, Grygorii Strashko wrote:
>> Hi Florian,
>>
>> The TI CPSW driver produces warning as below when booted in switch mode:
>> [8.882295] sysfs: cannot create duplicate filename
>> '/devices/platform/4400.ocp/48484000.e
Hi,
Willem de Bruijn writes:
>> Another interesting fact is that if the POLLIN event is added to the
>> poll() .events, poll() no longer becomes stuck,
>
> The process has registered interest only in POLLIN, which the call to
> sk_data_read (sock_def_readable) will trigger.
>
>> and more interes
Please address Joe's feedback and only update the copyright date on
files that actually had changes this year.
Thank you.
Hi David
I have fixed that now in v3.
However, patchwork is not showing the entire series.
It shows only the first patch for some reason even if I search with me
as submit
This patch adds rtnl_lock_killable() to one of hot path
using rtnl_lock().
Signed-off-by: Kirill Tkhai
---
net/core/dev.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 12a9aad0b057..d8887cc38e7b 100644
--- a/net/core/dev.c
+++ b/ne
rtnl_lock() is widely used mutex in kernel. Some of kernel code
does memory allocations under it. In case of memory deficit this
may invoke OOM killer, but the problem is a killed task can't
exit if it's waiting for the mutex. This may be a reason of deadlock
and panic.
This patchset adds a new pr
rtnl_lock() is widely used mutex in kernel. Some of kernel code
does memory allocations under it. In case of memory deficit this
may invoke OOM killer, but the problem is a killed task can't
exit if it's waiting for the mutex. This may be a reason of deadlock
and panic.
This patch adds a new primi
On Wed, Mar 14, 2018 at 10:26:05AM -0700, Sonny Rao wrote:
> This will allow usage of vsock from 32-bit binaries on a 64-bit
> kernel.
>
> Signed-off-by: Sonny Rao
I think you need to convert the pointer argument though.
Something along the lines of:
#ifdef CONFIG_COMPAT
static long vhost_vsock
This is needed to query the mux_id and flags of a rmnet device.
Signed-off-by: Subash Abhinov Kasiviswanathan
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
b/d
Signed-off-by: Subash Abhinov Kasiviswanathan
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.h | 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c| 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
Fix warnings which were reported when running with sparse
(make C=1 CF=-D__CHECK_ENDIAN__)
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:81:15:
warning: cast to restricted __be16
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:271:37:
warning: incorrect type in assignment (different ba
Device of the de-aggregated skb is correctly assigned after inspecting
the mux_id, so remove the assignment in rmnet_map_deaggregate().
Signed-off-by: Subash Abhinov Kasiviswanathan
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/driver
1 - 100 of 267 matches
Mail list logo
