* Re: [PATCH net-next] net: phy: realtek: load driver for all PHYs with a Realtek OUI
From: David Miller @ 2018-11-08 6:19 UTC (permalink / raw)
To: hkallweit1; +Cc: f.fainelli, andrew, netdev
In-Reply-To: <a1a08754-1f94-3689-f26b-076283d9cc03@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 7 Nov 2018 08:52:46 +0100
> Instead of listing every single PHYID, load the driver for every PHYID
> with a Realtek OUI, independent of model number and revision.
>
> This patch also improves two further aspects:
> - constify realtek_tbl[]
> - the mask should have been 0xffffffff instead of 0x001fffff so far,
> by masking out some bits a PHY from another vendor could have been
> matched
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net/wan/fsl_ucc_hdlc: add BQL support
From: David Miller @ 2018-11-08 6:21 UTC (permalink / raw)
To: mathias.thore
Cc: qiang.zhao, linuxppc-dev, netdev, joakim.tjernlund,
david.gounaris
In-Reply-To: <20181107080945.30651-1-mathias.thore@infinera.com>
From: Mathias Thore <mathias.thore@infinera.com>
Date: Wed, 7 Nov 2018 09:09:45 +0100
> Add byte queue limits support in the fsl_ucc_hdlc driver.
>
> Signed-off-by: Mathias Thore <mathias.thore@infinera.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next v2 3/5] virtio_ring: add packed ring support
From: Michael S. Tsirkin @ 2018-11-08 15:56 UTC (permalink / raw)
To: Tiwei Bie
Cc: Jason Wang, virtualization, linux-kernel, netdev, virtio-dev,
wexu, jfreimann
In-Reply-To: <20181108115148.GA15701@debian>
On Thu, Nov 08, 2018 at 07:51:48PM +0800, Tiwei Bie wrote:
> On Thu, Nov 08, 2018 at 04:18:25PM +0800, Jason Wang wrote:
> >
> > On 2018/11/8 上午9:38, Tiwei Bie wrote:
> > > > > +
> > > > > + if (vq->vq.num_free < descs_used) {
> > > > > + pr_debug("Can't add buf len %i - avail = %i\n",
> > > > > + descs_used, vq->vq.num_free);
> > > > > + /* FIXME: for historical reasons, we force a notify here if
> > > > > + * there are outgoing parts to the buffer. Presumably the
> > > > > + * host should service the ring ASAP. */
> > > > I don't think we have a reason to do this for packed ring.
> > > > No historical baggage there, right?
> > > Based on the original commit log, it seems that the notify here
> > > is just an "optimization". But I don't quite understand what does
> > > the "the heuristics which KVM uses" refer to. If it's safe to drop
> > > this in packed ring, I'd like to do it.
> >
> >
> > According to the commit log, it seems like a workaround of lguest networking
> > backend.
>
> Do you know why removing this notify in Tx will break "the
> heuristics which KVM uses"? Or what does "the heuristics
> which KVM uses" refer to?
Yes. QEMU has a mode where it disables notifications and processes TX
ring periodically from a timer. It's off by default but used to be on
by default a long time ago. If ring becomes full this causes traffic
stalls. As a work-around Rusty put in this hack to kick on ring full
even with notifications disabled. It's easy enough to make sure QEMU
does not combine devices with packed ring support with the timer hack.
And I am guessing it's safe enough to also block that option completely
e.g. when virtio 1.0 is enabled.
>
> > I agree to drop it, we should not have such burden.
> >
> > But we should notice that, with this removed, the compare between packed vs
> > split is kind of unfair. Consider the removal of lguest support recently,
> > maybe we can drop this for split ring as well?
> >
> > Thanks
> >
> >
> > >
> > > commit 44653eae1407f79dff6f52fcf594ae84cb165ec4
> > > Author: Rusty Russell<rusty@rustcorp.com.au>
> > > Date: Fri Jul 25 12:06:04 2008 -0500
> > >
> > > virtio: don't always force a notification when ring is full
> > > We force notification when the ring is full, even if the host has
> > > indicated it doesn't want to know. This seemed like a good idea at
> > > the time: if we fill the transmit ring, we should tell the host
> > > immediately.
> > > Unfortunately this logic also applies to the receiving ring, which is
> > > refilled constantly. We should introduce real notification thesholds
> > > to replace this logic. Meanwhile, removing the logic altogether breaks
> > > the heuristics which KVM uses, so we use a hack: only notify if there are
> > > outgoing parts of the new buffer.
> > > Here are the number of exits with lguest's crappy network implementation:
> > > Before:
> > > network xmit 7859051 recv 236420
> > > After:
> > > network xmit 7858610 recv 118136
> > > Signed-off-by: Rusty Russell<rusty@rustcorp.com.au>
> > >
> > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > > index 72bf8bc09014..21d9a62767af 100644
> > > --- a/drivers/virtio/virtio_ring.c
> > > +++ b/drivers/virtio/virtio_ring.c
> > > @@ -87,8 +87,11 @@ static int vring_add_buf(struct virtqueue *_vq,
> > > if (vq->num_free < out + in) {
> > > pr_debug("Can't add buf len %i - avail = %i\n",
> > > out + in, vq->num_free);
> > > - /* We notify*even if* VRING_USED_F_NO_NOTIFY is set here. */
> > > - vq->notify(&vq->vq);
> > > + /* FIXME: for historical reasons, we force a notify here if
> > > + * there are outgoing parts to the buffer. Presumably the
> > > + * host should service the ring ASAP. */
> > > + if (out)
> > > + vq->notify(&vq->vq);
> > > END_USE(vq);
> > > return -ENOSPC;
> > > }
> > >
> > >
^ permalink raw reply
* Re: [PATCH net-next] tun: compute the RFS hash only if needed.
From: David Miller @ 2018-11-08 6:23 UTC (permalink / raw)
To: pabeni; +Cc: netdev, jasowang
In-Reply-To: <12347537bd5fd8b1176ca62ddf51ea9080fe1b41.1541436099.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Wed, 7 Nov 2018 10:34:36 +0100
> The tun XDP sendmsg code path, unconditionally computes the symmetric
> hash of each packet for RFS's sake, even when we could skip it. e.g.
> when the device has a single queue.
>
> This change adds the check already in-place for the skb sendmsg path
> to avoid unneeded hashing.
>
> The above gives small, but measurable, performance gain for VM xmit
> path when zerocopy is not enabled.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: vlan: add support for tunnel offload
From: David Miller @ 2018-11-08 6:23 UTC (permalink / raw)
To: dcaratti; +Cc: xiyou.wangcong, netdev, fbl, fw
In-Reply-To: <b55216ca2bf962175a3f79c73e08607deb4c6e7d.1541586443.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Wed, 7 Nov 2018 11:28:18 +0100
> GSO tunneled packets are always segmented in software before they are
> transmitted by a VLAN, even when the lower device can offload tunnel
> encapsulation and VLAN together (i.e., some bits in NETIF_F_GSO_ENCAP_ALL
> mask are set in the lower device 'vlan_features'). If we let VLANs have
> the same tunnel offload capabilities as their lower device, throughput
> can improve significantly when CPU is limited on the transmitter side.
>
> - set NETIF_F_GSO_ENCAP_ALL bits in the VLAN 'hw_features', to ensure
> that 'features' will have those bits zeroed only when the lower device
> has no hardware support for tunnel encapsulation.
> - for the same reason, copy GSO-related bits of 'hw_enc_features' from
> lower device to VLAN, and ensure to update that value when the lower
> device changes its features.
> - set NETIF_F_HW_CSUM bit in the VLAN 'hw_enc_features' if 'real_dev'
> is able to compute checksums at least for a kind of packets, like done
> with commit 8403debeead8 ("vlan: Keep NETIF_F_HW_CSUM similar to other
> software devices"). This avoids software segmentation due to mismatching
> checksum capabilities between VLAN's 'features' and 'hw_enc_features'.
>
> Reported-by: Flavio Leitner <fbl@redhat.com>
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Applied.
^ permalink raw reply
* [PATCH resend] can: rcar_can: convert to SPDX identifiers
From: Kuninori Morimoto @ 2018-11-08 6:33 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde; +Cc: linux-can, netdev
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
This patch updates license to use SPDX-License-Identifier
instead of verbose license text.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
---
drivers/net/can/rcar/Kconfig | 1 +
drivers/net/can/rcar/Makefile | 1 +
drivers/net/can/rcar/rcar_can.c | 6 +-----
drivers/net/can/rcar/rcar_canfd.c | 6 +-----
4 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/can/rcar/Kconfig b/drivers/net/can/rcar/Kconfig
index 7b03a3a..bd5a8fc 100644
--- a/drivers/net/can/rcar/Kconfig
+++ b/drivers/net/can/rcar/Kconfig
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
config CAN_RCAR
tristate "Renesas R-Car CAN controller"
depends on ARCH_RENESAS || ARM
diff --git a/drivers/net/can/rcar/Makefile b/drivers/net/can/rcar/Makefile
index 08de36a..c9185b0 100644
--- a/drivers/net/can/rcar/Makefile
+++ b/drivers/net/can/rcar/Makefile
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
#
# Makefile for the Renesas R-Car CAN & CAN FD controller drivers
#
diff --git a/drivers/net/can/rcar/rcar_can.c b/drivers/net/can/rcar/rcar_can.c
index 11662f4..06f90a0 100644
--- a/drivers/net/can/rcar/rcar_can.c
+++ b/drivers/net/can/rcar/rcar_can.c
@@ -1,12 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
/* Renesas R-Car CAN device driver
*
* Copyright (C) 2013 Cogent Embedded, Inc. <source@cogentembedded.com>
* Copyright (C) 2013 Renesas Solutions Corp.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
*/
#include <linux/module.h>
diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
index 602c19e..0541000 100644
--- a/drivers/net/can/rcar/rcar_canfd.c
+++ b/drivers/net/can/rcar/rcar_canfd.c
@@ -1,11 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
/* Renesas R-Car CAN FD device driver
*
* Copyright (C) 2015 Renesas Electronics Corp.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
*/
/* The R-Car CAN FD controller can operate in either one of the below two modes
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] ibmvnic: fix accelerated VLAN handling
From: David Miller @ 2018-11-08 6:37 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, tlfalcon, jallen
In-Reply-To: <3cad1feb702479b9db69b3cdb393e9b331fe4ce7.1541609304.git.mirq-linux@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Wed, 07 Nov 2018 17:50:52 +0100
> Don't request tag insertion when it isn't present in outgoing skb.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] qlcnic: remove assumption that vlan_tci != 0
From: David Miller @ 2018-11-08 6:38 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, Shahed.Shaikh, manish.chopra, Dept-GELinuxNICDev
In-Reply-To: <aada372e836662d36115ccd292f4191016a4e02d.1541609304.git.mirq-linux@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Wed, 07 Nov 2018 17:50:53 +0100
> VLAN.TCI == 0 is perfectly valid (802.1p), so allow it to be accelerated.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/4] net/vlan: prepare for removal of VLAN_TAG_PRESENT
From: David Miller @ 2018-11-08 6:41 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev
In-Reply-To: <cover.1541610138.git.mirq-linux@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Wed, 07 Nov 2018 18:07:02 +0100
> This is a preparatory patchset before removing the use of VLAN_TAG_PRESENT
> bit in skb->vlan_tci as indication of VLAN offload. This set includes
> only cleanups that allow abstracting of code testing VLAN tag presence
> in drivers and networking code.
Series applied.
^ permalink raw reply
* Re: [net-next 06/12] i40e/ixgbe/igb: fail on new WoL flag setting WAKE_MAGICSECURE
From: Michal Kubecek @ 2018-11-08 6:42 UTC (permalink / raw)
To: Kevin Easton
Cc: Jeff Kirsher, davem, Todd Fujinaka, netdev, nhorman, sassmann
In-Reply-To: <20181108060526.GA11230@ip-172-31-15-78>
On Thu, Nov 08, 2018 at 06:05:26AM +0000, Kevin Easton wrote:
> On Wed, Nov 07, 2018 at 02:48:24PM -0800, Jeff Kirsher wrote:
> > From: Todd Fujinaka <todd.fujinaka@intel.com>
> >
> > There's a new flag for setting WoL filters that is only
> > enabled on one manufacturer's NICs, and it's not ours. Fail
> > with EOPNOTSUPP.
> >
> > Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
> > Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> > drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 3 ++-
> > drivers/net/ethernet/intel/igb/igb_ethtool.c | 2 +-
> > drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 3 ++-
> > 3 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> > index 9f8464f80783..9c1211ad2c6b 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> > @@ -2377,7 +2377,8 @@ static int i40e_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol)
> > return -EOPNOTSUPP;
> >
> > /* only magic packet is supported */
> > - if (wol->wolopts && (wol->wolopts != WAKE_MAGIC))
> > + if (wol->wolopts && (wol->wolopts != WAKE_MAGIC)
> > + | (wol->wolopts != WAKE_FILTER))
> > return -EOPNOTSUPP;
>
> This doesn't look right. WAKE_MAGIC and WAKE_FILTER are distinct, so
>
> (wol->wolopts != WAKE_MAGIC) | (wol->wolopts != WAKE_FILTER)
>
> will always be 1.
Right. Also, using "|" with logical values is rather confusing. While
the result works as expected, its priority is higher than priority of
&& (which would not be true for ||), making the code counterintuitive.
BtW, the patch subject is also wrong, the newly added flag it is dealing
with is WAKE_FILTER, not WAKE_MAGICSECURE.
> It looks like the existing test in this driver was fine - it *only*
> accepted wol->wolopts of either 0 or WAKE_MAGIC, it was already
> rejecting everything else including WAKE_FILTER.
Another way to write the check would be
if (wol->wolopts & ~WAKE_MAGIC)
> > diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> > index 5acf3b743876..c57671068245 100644
> > --- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
> > +++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> > @@ -2113,7 +2113,7 @@ static int igb_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol)
> > {
> > struct igb_adapter *adapter = netdev_priv(netdev);
> >
> > - if (wol->wolopts & (WAKE_ARP | WAKE_MAGICSECURE))
> > + if (wol->wolopts & (WAKE_ARP | WAKE_MAGICSECURE | WAKE_FILTER))
> > return -EOPNOTSUPP;
> >
> > if (!(adapter->flags & IGB_FLAG_WOL_SUPPORTED))
I would also suggest taking the opposite approach here, i.e. listing the
flags which _are_ supported so that we don't have to update the code if
another wol flag is added (or userspace sends an invalid one):
#define SUPPORTED_WOL_MODES \
(WAKE_PHY | WAKE_UCAST | WAKE_MCAST | WAKE_BCAST | WAKE_MAGIC)
...
if (wol->wolopts & ~SUPPORTED_WOL_MODES)
return -EOPNOTSUPP;
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> > index 732b1e6ecc43..acba067cc15a 100644
> > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> > @@ -2206,7 +2206,8 @@ static int ixgbe_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol)
> > {
> > struct ixgbe_adapter *adapter = netdev_priv(netdev);
> >
> > - if (wol->wolopts & (WAKE_PHY | WAKE_ARP | WAKE_MAGICSECURE))
> > + if (wol->wolopts & (WAKE_PHY | WAKE_ARP | WAKE_MAGICSECURE |
> > + WAKE_FILTER))
> > return -EOPNOTSUPP;
> >
> > if (ixgbe_wol_exclusion(adapter, wol))
...and here.
Michal Kubecek
^ permalink raw reply
* Re: [RFC PATCH 12/12] soc: qcom: ipa: build and "ipa_i.h"
From: Alex Elder @ 2018-11-08 16:22 UTC (permalink / raw)
To: Randy Dunlap, davem, arnd, bjorn.andersson, ilias.apalodimas
Cc: netdev, devicetree, linux-arm-msm, linux-soc, linux-arm-kernel,
linux-kernel, syadagir, mjavid, robh+dt, mark.rutland
In-Reply-To: <cebe0d3c-4a24-60a4-88c8-5195a5d0da4b@infradead.org>
On 11/6/18 6:40 PM, Randy Dunlap wrote:
> Hi-
Thanks Randy, I've fixed this in my own tree. -Alex
>
> On 11/6/18 4:32 PM, Alex Elder wrote:
>> diff --git a/drivers/net/ipa/Kconfig b/drivers/net/ipa/Kconfig
>> new file mode 100644
>> index 000000000000..f8ea9363f532
>> --- /dev/null
>> +++ b/drivers/net/ipa/Kconfig
>> @@ -0,0 +1,30 @@
>> +config IPA
>> + tristate "Qualcomm IPA support"
>> + depends on NET
>> + select QCOM_QMI_HELPERS
>> + select QCOM_MDT_LOADER
>> + default n
>> + help
>> + Choose Y here to include support for the Qualcomm IP
>> + Accelerator (IPA), a hardware block present in some
>> + Qualcomm SoCs. The IPA is a programmable protocol
>> + processor that is capable of generic hardware handling
>> + of IP packets, including routing, filtering, and NAT.
>> + Currently the IPA driver supports only basic transport
>> + of network traffic between the AP and modem, on the
>> + Qualcomm SDM845 SoC.
>> +
>> + If unsure, say N.
>> +
>> +config IPA_ASSERT
>> + bool "Enable IPA assertions"
>> + depends on IPA
>> + default y
>> + help
>> + Incorporate IPA assertion verification in the build. This
>> + cause various design assumptions to be checked at runtime,
>
> causes
>
>> + generating a report (and a crash) if any assumed condition
>> + does not hold. You may wish to disable this to avoid the
>> + overhead of checking.
>> +
>> + If unsure doubt, say "Y" here.
>
>
^ permalink raw reply
* Re: [PATCH net-next] sfc: add missing NVRAM partition types for EF10
From: David Miller @ 2018-11-08 6:58 UTC (permalink / raw)
To: ecree; +Cc: linux-net-drivers, netdev
In-Reply-To: <690d4b01-c19d-e8ec-7fb6-f293bf6dd278@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Wed, 7 Nov 2018 18:12:42 +0000
> Expose the MUM/SUC Firmware, UEFI Expansion ROM and MC Status partitions
> of the NIC's NVRAM as MTDs if found on the NIC. The first two are needed
> in order to properly update them when performing firmware updates; the MC
> Status partition is used to determine whether a signed firmware image was
> accepted or rejected by a Secure NIC.
>
> Signed-off-by: Edward Cree <ecree@solarflare.com>
Applied, thanks.
^ permalink raw reply
* [PATCH][net-next][v2] net/ipv6: compute anycast address hash only if dev is null
From: Li RongQing @ 2018-11-08 6:58 UTC (permalink / raw)
To: netdev
avoid to compute the hash value if dev is not null, since
hash value is not used
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/ipv6/anycast.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index 94999058e110..cca3b3603c42 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -433,7 +433,6 @@ static bool ipv6_chk_acast_dev(struct net_device *dev, const struct in6_addr *ad
bool ipv6_chk_acast_addr(struct net *net, struct net_device *dev,
const struct in6_addr *addr)
{
- unsigned int hash = inet6_acaddr_hash(net, addr);
struct net_device *nh_dev;
struct ifacaddr6 *aca;
bool found = false;
@@ -441,7 +440,9 @@ bool ipv6_chk_acast_addr(struct net *net, struct net_device *dev,
rcu_read_lock();
if (dev)
found = ipv6_chk_acast_dev(dev, addr);
- else
+ else {
+ unsigned int hash = inet6_acaddr_hash(net, addr);
+
hlist_for_each_entry_rcu(aca, &inet6_acaddr_lst[hash],
aca_addr_lst) {
nh_dev = fib6_info_nh_dev(aca->aca_rt);
@@ -452,6 +453,7 @@ bool ipv6_chk_acast_addr(struct net *net, struct net_device *dev,
break;
}
}
+ }
rcu_read_unlock();
return found;
}
--
2.16.2
^ permalink raw reply related
* Re: [PATCH net-next 0/3] nfp: add and use tunnel netdev helpers
From: David Miller @ 2018-11-08 7:00 UTC (permalink / raw)
To: john.hurley; +Cc: netdev, oss-drivers, jakub.kicinski
In-Reply-To: <1541615570-523-1-git-send-email-john.hurley@netronome.com>
From: John Hurley <john.hurley@netronome.com>
Date: Wed, 7 Nov 2018 18:32:47 +0000
> A recent patch introduced the function netif_is_vxlan() to verify the
> tunnel type of a given netdev as vxlan.
>
> Add a similar function to detect geneve netdevs and make use of this
> function in the NFP driver. Also make use of the vxlan helper where
> applicable.
Series applied.
^ permalink raw reply
* [PATCH 1/3] ath6kl: Only use match sets when firmware supports it
From: Kyle Roeschley @ 2018-11-08 16:36 UTC (permalink / raw)
To: Kalle Valo
Cc: David S . Miller, linux-wireless, netdev, linux-kernel,
Kyle Roeschley
Commit dd45b7598f1c ("ath6kl: Include match ssid list in scheduled scan")
merged the probed and matched SSID lists before sending them to the
firmware. In the process, it assumed match set support is always available
in ath6kl_set_probed_ssids, which breaks scans for hidden SSIDs. Now, check
that the firmware supports matching SSIDs in scheduled scans before setting
MATCH_SSID_FLAG.
Fixes: dd45b7598f1c ("ath6kl: Include match ssid list in scheduled scan")
Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index e121187f371f..6c98d7903ffb 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -939,7 +939,7 @@ static int ath6kl_set_probed_ssids(struct ath6kl *ar,
else
ssid_list[i].flag = ANY_SSID_FLAG;
- if (n_match_ssid == 0)
+ if (ar->wiphy->max_match_sets != 0 && n_match_ssid == 0)
ssid_list[i].flag |= MATCH_SSID_FLAG;
}
--
2.19.1
^ permalink raw reply related
* [PATCH 2/3] ath6kl: Fix off by one error in scan completion
From: Kyle Roeschley @ 2018-11-08 16:36 UTC (permalink / raw)
To: Kalle Valo
Cc: David S . Miller, linux-wireless, netdev, linux-kernel,
Kyle Roeschley
In-Reply-To: <20181108163659.19535-1-kyle.roeschley@ni.com>
When ath6kl was reworked to share code between regular and scheduled scans
in commit 3b8ffc6a22ba ("ath6kl: Configure probed SSID list consistently"),
probed SSID entry changed from 1-index to 0-indexed. However,
ath6kl_cfg80211_scan_complete_event() was missed in that change. Fix its
indexing so that we correctly clear out the probed SSID list.
Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 6c98d7903ffb..d7c626d9594e 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -1093,7 +1093,7 @@ void ath6kl_cfg80211_scan_complete_event(struct ath6kl_vif *vif, bool aborted)
if (vif->scan_req->n_ssids && vif->scan_req->ssids[0].ssid_len) {
for (i = 0; i < vif->scan_req->n_ssids; i++) {
ath6kl_wmi_probedssid_cmd(ar->wmi, vif->fw_vif_idx,
- i + 1, DISABLE_SSID_FLAG,
+ i, DISABLE_SSID_FLAG,
0, NULL);
}
}
--
2.19.1
^ permalink raw reply related
* Re: [net-next 00/12][pull request] Intel Wired LAN Driver Updates 2018-11-07
From: David Miller @ 2018-11-08 7:07 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20181107224830.9737-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 7 Nov 2018 14:48:18 -0800
> This series contains updates to almost all of the Intel wired LAN
> drivers.
...
> The following are changes since commit 7c588c7468ea3f9b2fc8fa6840bed6262b5d1b00:
> Merge branch 'net-systemport-Unmap-queues-upon-DSA-unregister-event'
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 1GbE
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next 0/5] net: phy: improve and simplify phylib state machine
From: Heiner Kallweit @ 2018-11-08 7:20 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <67c3bafb-5b4b-c33e-fd84-4cc6919b4bcb@gmail.com>
On 07.11.2018 21:45, Heiner Kallweit wrote:
> On 07.11.2018 21:21, Andrew Lunn wrote:
>> On Wed, Nov 07, 2018 at 09:05:49PM +0100, Heiner Kallweit wrote:
>>> On 07.11.2018 20:48, Andrew Lunn wrote:
>>>> On Wed, Nov 07, 2018 at 08:41:52PM +0100, Heiner Kallweit wrote:
>>>>> This patch series is based on two axioms:
>>>>>
>>>>> - During autoneg a PHY always reports the link being down
>>>>
>>>> Hi Heiner
>>>>
>>>> I think that is a risky assumption to make.
>>>>
>>> I wasn't sure initially too (found no clear rule in 802.3 clause 22)
>>> and therefore asked around. Florian agrees to the assumption,
>>> see here: https://www.spinics.net/lists/netdev/msg519242.html
>>>
>>> If a PHY reports the link as up then every user would assume that
>>> data can be transferred. But that's not the case during aneg.
>>> Therefore reporting the link as up during aneg wouldn't make sense.
>>
>> Hi Heiner
>>
>> If auto-neg has already been completed once before, i can see a lazy
>> hardware designed not reporting link down, or at least, not until
>> auto-neg actually fails.
>>
> "aneg finished" flag means that the aneg parameters in the register set
> are valid. Once the link goes down that's not necessarily the case any
> longer. E.g. some PHYs have an "auto speed down" feature and reduce
> the speed to save power once they detect the link is down.
> Of course I can not rule out that there are broken designs (or as you
> stated more politely: lazy designs) out there. But in this case I assume
> we would see issues already. And we would have to think about whether we
> want to support such broken / lazy designs in phylib.
>
Had one more look at the changes to check what happens if "link up" and
"aneg done" are not in sync.
When link goes down the changes don't change current behavior. We just
check the "link up" bit.
When link goes up and aneg isn't finished yet, then we would report
"link is up" earlier to userspace than we do now. If userspace starts
some network activity based on the "link up" event then they may fail.
But it really would be a major flaw if a PHY signals "link up" whilst
it's not actually ready yet to transfer data.
In case of such a broken design we would have issues with the current
code already, at least if interrupts are used. The "link up" interrupt
would cause the state machine to go to PHY_CHANGELINK which doesn't
check for aneg status.
>> And what about if link is down for too short a time for us to notice?
>> I've seen some code fail because the kernel went off and did something
>> else for too long, and a state change was missed.
>>
> This is a case we have already, independent of my change.
> genphy_update_link() reads BMSR twice, thus ignoring potential latched
> info about a temporary link failure. When polling phylib ignores
> everything that happens between two poll intervals.
>
>>>> What happens if this assumption is incorrect?
>>>>
>>> Then we have to flush this patch series down the drain ;)
>>> At least I would have to check in detail which parts need to be
>>> changed. I clearly mention the assumptions so that every
>>> reviewer can check whether he agrees.
>>
>> Thanks for doing that. I want to be happy this is safe, and not going
>> to introduce regressions.
>>
>> Andrew
>>
>
^ permalink raw reply
* [RFC PATCH 0/3] acpi: Add acpi mdio support code
From: Wang Dongsheng @ 2018-11-08 7:21 UTC (permalink / raw)
To: andrew, timur
Cc: Wang Dongsheng, yu.zheng, f.fainelli, rjw, linux-acpi, netdev
In-Reply-To: <20181029124044.GB9174@lunn.ch>
Originally I just push "phy-handle" support for ACPI on the QCOM QDF2400
platform. After some discussion and following Andrew's advice, I send
out with a generic version of ACPI.
Current there is no clear documentation about MDIO/PHY for ACPI, so when
I reading some documents about ACPI [1], I think we just need to reuse the
DT binding in the ACPI.[2]. However, this series of patches are not
fully compatible with all contents specified in DT binding.
The most important thing about this iseries is link the phy device and
fwnode of acpi. Besides, we need to carry out bus scan at the mdio
register. Therefore, I am not compatible with more DT binding properties
in this series of patches. More support will be in the follow-up patches
support, or some people do the support.
Example:
Based on ACPI doc:
Documentation/acpi/dsd/data-node-references.txt
Documentation/acpi/dsd/graph.txt
With _DSD device properties we can finally do this:
Device (MDIO) {
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () { Package () { "ethernet-phy@0", PHY0 }, }
})
Name (PHY0, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () { "reg", 0x0 }, }
})
}
Device (MACO) {
Name (_DSD, Package () {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
})
}
Tested: QDF2400 (ACPI), buildin/insmod/rmmod
[1]:
Documentation/acpi/dsd/data-node-references.txt
Documentation/acpi/dsd/graph.txt
[2]:
Documentation/devicetree/bindings/phy/phy-bindings.txt
https://lore.kernel.org/patchwork/patch/597296/
Wang Dongsheng (3):
acpi: Add acpi mdio support code
net: qcom/emac: split phy_config to mdio bus create and get phy device
net: qcom/emac: add phy-handle support for ACPI
drivers/acpi/Kconfig | 6 +
drivers/acpi/Makefile | 1 +
drivers/acpi/acpi_mdio.c | 167 ++++++++++++++++++
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 19 +-
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 142 ++++++++++-----
drivers/net/phy/mdio_bus.c | 3 +
include/linux/acpi_mdio.h | 82 +++++++++
7 files changed, 369 insertions(+), 51 deletions(-)
create mode 100644 drivers/acpi/acpi_mdio.c
create mode 100644 include/linux/acpi_mdio.h
--
2.18.0
^ permalink raw reply
* [RFC PATCH 1/3] acpi: Add acpi mdio support code
From: Wang Dongsheng @ 2018-11-08 7:22 UTC (permalink / raw)
To: andrew, timur
Cc: Wang Dongsheng, yu.zheng, f.fainelli, rjw, linux-acpi, netdev
In-Reply-To: <cover.1541660504.git.dongsheng.wang@hxt-semitech.com>
Add support for parsing the ACPI data node for PHY devices on an MDIO bus.
The current implementation depend on mdio bus scan.
With _DSD device properties we can finally do this:
Device (MDIO) {
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () { Package () { "ethernet-phy@0", PHY0 }, }
})
Name (PHY0, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () { "reg", 0x0 }, }
})
}
Device (MACO) {
Name (_DSD, Package () {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
})
}
Documentations:
The DT "phy-handle" binding that we reuse for ACPI is documented in
Documentation/devicetree/bindings/phy/phy-bindings.txt
Documentation/acpi/dsd/data-node-references.txt
Documentation/acpi/dsd/graph.txt
Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
---
drivers/acpi/Kconfig | 6 ++
drivers/acpi/Makefile | 1 +
drivers/acpi/acpi_mdio.c | 167 +++++++++++++++++++++++++++++++++++++
drivers/net/phy/mdio_bus.c | 3 +
include/linux/acpi_mdio.h | 82 ++++++++++++++++++
5 files changed, 259 insertions(+)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 9705fc986da9..0fefa3410ce9 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -252,6 +252,12 @@ config ACPI_PROCESSOR_IDLE
config ACPI_MCFG
bool
+config ACPI_MDIO
+ def_tristate PHYLIB
+ depends on PHYLIB
+ help
+ ACPI MDIO bus (Ethernet PHY) accessors
+
config ACPI_CPPC_LIB
bool
depends on ACPI_PROCESSOR
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 6d59aa109a91..ec7461a064fc 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -41,6 +41,7 @@ acpi-y += ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o
obj-$(CONFIG_ACPI_MCFG) += pci_mcfg.o
+acpi-$(CONFIG_ACPI_MDIO) += acpi_mdio.o
acpi-y += acpi_lpss.o acpi_apd.o
acpi-y += acpi_platform.o
acpi-y += acpi_pnp.o
diff --git a/drivers/acpi/acpi_mdio.c b/drivers/acpi/acpi_mdio.c
new file mode 100644
index 000000000000..293bf9a63197
--- /dev/null
+++ b/drivers/acpi/acpi_mdio.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Lots of code in this file is copy from drivers/of/of_mdio.c
+// Copyright (c) 2018 Huaxintong Semiconductor Technology Co., Ltd.
+
+#include <linux/acpi.h>
+#include <linux/acpi_mdio.h>
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/netdevice.h>
+#include <linux/err.h>
+#include <linux/phy.h>
+#include <linux/phy_fixed.h>
+
+/* Helper function for acpi_phy_find_device */
+static int phy_match(struct device *dev, void *fwnode)
+{
+ return dev->fwnode == fwnode;
+}
+
+/**
+ * acpi_phy_find_device - Give a PHY fwnode, find the phy_device
+ * @fwnode: Pointer to the phy's acpi data node
+ *
+ * If successful, returns a pointer to the phy_device with the embedded
+ * struct device refcount incremented by one, or NULL on failure.
+ */
+struct phy_device *acpi_phy_find_device(struct fwnode_handle *fwnode)
+{
+ struct device *d;
+ struct mdio_device *mdiodev;
+
+ if (!fwnode)
+ return NULL;
+
+ d = bus_find_device(&mdio_bus_type, NULL, fwnode, phy_match);
+ if (d) {
+ mdiodev = to_mdio_device(d);
+ if (mdiodev->flags & MDIO_DEVICE_FLAG_PHY)
+ return to_phy_device(d);
+ put_device(d);
+ }
+ return NULL;
+}
+EXPORT_SYMBOL(acpi_phy_find_device);
+
+static int do_acpi_mdiodev_match(struct fwnode_handle *fwnode,
+ struct mdio_device *mdiodev)
+{
+ struct device *dev = &mdiodev->dev;
+ struct fwnode_handle *child_node;
+ int addr;
+ int ret;
+
+ fwnode_for_each_child_node(fwnode, child_node) {
+ do {
+ addr = acpi_mdio_parse_addr(dev, child_node);
+ if (addr < 0)
+ break;
+
+ if (mdiodev->addr != addr)
+ break;
+
+ dev->fwnode = child_node;
+ return 0;
+ } while (0);
+
+ /* Walk hierarchical extension data nodes */
+ ret = do_acpi_mdiodev_match(child_node, mdiodev);
+ if (!ret)
+ return 0;
+ }
+
+ return -ENODEV;
+}
+
+/* Walk the list of subnodes of a mdio bus and look for a node that
+ * matches the mdio device's address with its 'reg' property. If
+ * found, set the fwnode pointer for the mdio device.
+ */
+void acpi_mdiobus_link_mdiodev(struct mii_bus *bus,
+ struct mdio_device *mdiodev)
+{
+ struct device *dev = &mdiodev->dev;
+
+ if (dev->fwnode || !bus->dev.fwnode)
+ return;
+
+ if (!has_acpi_companion(&bus->dev))
+ return;
+
+ do_acpi_mdiodev_match(bus->dev.fwnode, mdiodev);
+}
+
+/**
+ * acpi_phy_connect - Connect to the phy
+ * @dev: pointer to net_device claiming the phy
+ * @fwnode: Pointer to ACPI data node for the PHY
+ * @hndlr: Link state callback for the network device
+ * @flags: flags to pass to the PHY
+ * @iface: PHY data interface type
+ *
+ * If successful, returns a pointer to the phy_device with the embedded
+ * struct device refcount incremented by one, or NULL on failure. The
+ * refcount must be dropped by calling phy_disconnect() or phy_detach().
+ */
+struct phy_device *acpi_phy_connect(struct net_device *dev,
+ struct fwnode_handle *fwnode,
+ void (*hndlr)(struct net_device *),
+ u32 flags,
+ phy_interface_t iface)
+{
+ struct phy_device *phy = acpi_phy_find_device(fwnode);
+ int ret;
+
+ if (!phy)
+ return NULL;
+
+ phy->dev_flags = flags;
+
+ ret = phy_connect_direct(dev, phy, hndlr, iface);
+
+ /* refcount is held by phy_connect_direct() on success */
+ put_device(&phy->mdio.dev);
+
+ return ret ? NULL : phy;
+}
+EXPORT_SYMBOL(acpi_phy_connect);
+
+static int acpi_mdio_node_verify(struct fwnode_handle *fwnode)
+{
+ return is_acpi_device_node(fwnode) ? 0 : -ENODEV;
+}
+
+static int fwnode_mdiobus_verify_node(struct fwnode_handle *fwnode)
+{
+ if (!is_acpi_node(fwnode))
+ return -ENODEV;
+ return acpi_mdio_node_verify(fwnode);
+}
+
+/**
+ * acpi_mdiobus_register - Register mii_bus and create PHYs
+ * @mdio: pointer to mii_bus structure
+ * @fwnode: pointer to fw_node of MDIO bus.
+ *
+ * This function registers the mii_bus structure and scan the phy_devices
+ * for each child node of @fwnode.
+ */
+int acpi_mdiobus_register(struct mii_bus *mdio, struct fwnode_handle *fwnode)
+{
+ int ret;
+
+ if (!fwnode)
+ return mdiobus_register(mdio);
+
+ ret = fwnode_mdiobus_verify_node(fwnode);
+ if (ret)
+ return ret;
+
+ /* Scan PHYs on MDIO bus */
+ mdio->phy_mask = 0;
+ mdio->dev.fwnode = fwnode;
+
+ /* Register the MDIO bus */
+ return mdiobus_register(mdio);
+}
+EXPORT_SYMBOL(acpi_mdiobus_register);
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 2e59a8419b17..d7bca2145d0f 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -13,6 +13,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include <linux/acpi_mdio.h>
#include <linux/kernel.h>
#include <linux/string.h>
#include <linux/errno.h>
@@ -516,6 +517,8 @@ struct phy_device *mdiobus_scan(struct mii_bus *bus, int addr)
* in the bus node, and set the of_node pointer in this case.
*/
of_mdiobus_link_mdiodev(bus, &phydev->mdio);
+ /* Link the phy device with ACPI phy fwnode. */
+ acpi_mdiobus_link_mdiodev(bus, &phydev->mdio);
err = phy_device_register(phydev);
if (err) {
diff --git a/include/linux/acpi_mdio.h b/include/linux/acpi_mdio.h
new file mode 100644
index 000000000000..1a4a30258ebc
--- /dev/null
+++ b/include/linux/acpi_mdio.h
@@ -0,0 +1,82 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+// Copyright (c) 2018 Huaxintong Semiconductor Technology Co., Ltd.
+
+#ifndef __LINUX_ACPI_MDIO_H
+#define __LINUX_ACPI_MDIO_H
+
+#include <linux/acpi.h>
+#include <linux/device.h>
+#include <linux/phy.h>
+#include <linux/property.h>
+
+#if IS_ENABLED(CONFIG_ACPI_MDIO)
+static inline int acpi_mdio_parse_addr(struct device *dev,
+ const struct fwnode_handle *fwnode)
+{
+ u32 addr;
+
+ if (!is_acpi_data_node(fwnode))
+ return -ENODEV;
+
+ if (!fwnode_property_present(fwnode, "reg"))
+ return -ENODEV;
+
+ if (fwnode_property_read_u32(fwnode, "reg", &addr)) {
+ dev_err(dev, "Invalid PHY address\n");
+ return -ENODEV;
+ }
+
+ /* A PHY must have a reg property in the range [0-31] */
+ if (addr >= PHY_MAX_ADDR) {
+ dev_err(dev, "PHY address %i is too large\n", addr);
+ return -EINVAL;
+ }
+
+ return addr;
+}
+
+struct phy_device *acpi_phy_find_device(struct fwnode_handle *fwnode);
+struct phy_device *acpi_phy_connect(struct net_device *dev,
+ struct fwnode_handle *fwnode,
+ void (*hndlr)(struct net_device *),
+ u32 flags, phy_interface_t iface);
+int acpi_mdiobus_register(struct mii_bus *mdio, struct fwnode_handle *fwnode);
+void acpi_mdiobus_link_mdiodev(struct mii_bus *bus,
+ struct mdio_device *mdiodev);
+#else
+static inline int acpi_mdio_parse_addr(struct device *dev,
+ const struct fwnode_handle *fwnode)
+{
+ return -EINVAL;
+}
+
+static inline struct phy_device *
+acpi_phy_find_device(struct fwnode_handle *fwnode)
+{
+ return NULL;
+}
+
+static inline struct phy_device *
+acpi_phy_connect(struct net_device *dev, struct fwnode_handle *fwnode,
+ void (*hndlr)(struct net_device *), u32 flags,
+ phy_interface_t iface)
+{
+ return NULL;
+}
+
+static inline int acpi_mdiobus_register(struct mii_bus *mdio,
+ struct fwnode_handle *fwnode)
+{
+ return -ENODEV;
+}
+
+static inline void
+acpi_mdiobus_link_mdiodev(struct mii_bus *bus, struct mdio_device *mdiodev) { }
+#endif
+
+static inline struct fwnode_handle *acpi_get_phy_node(struct phy_device *phydev)
+{
+ return !phydev ? NULL : phydev->mdio.dev.fwnode;
+}
+
+#endif /* __LINUX_ACPI_MDIO_H */
--
2.18.0
^ permalink raw reply related
* [RFC PATCH 2/3] net: qcom/emac: split phy_config to mdio bus create and get phy device
From: Wang Dongsheng @ 2018-11-08 7:22 UTC (permalink / raw)
To: andrew, timur
Cc: Wang Dongsheng, yu.zheng, f.fainelli, rjw, linux-acpi, netdev
In-Reply-To: <cover.1541660504.git.dongsheng.wang@hxt-semitech.com>
This patch separate emac_mdio_bus_create and emac_get_phydev from
emac_phy_config, and do some codes clean.
Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
---
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 96 +++++++++++--------
1 file changed, 56 insertions(+), 40 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-phy.c b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
index 53dbf1e163a8..8289fdda4be7 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-phy.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
@@ -96,15 +96,15 @@ static int emac_mdio_write(struct mii_bus *bus, int addr, int regnum, u16 val)
return 0;
}
-/* Configure the MDIO bus and connect the external PHY */
-int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
+static int emac_mdio_bus_create(struct platform_device *pdev,
+ struct emac_adapter *adpt)
{
struct device_node *np = pdev->dev.of_node;
struct mii_bus *mii_bus;
int ret;
/* Create the mii_bus object for talking to the MDIO bus */
- adpt->mii_bus = mii_bus = devm_mdiobus_alloc(&pdev->dev);
+ mii_bus = devm_mdiobus_alloc(&pdev->dev);
if (!mii_bus)
return -ENOMEM;
@@ -115,50 +115,66 @@ int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
mii_bus->parent = &pdev->dev;
mii_bus->priv = adpt;
- if (has_acpi_companion(&pdev->dev)) {
- u32 phy_addr;
-
- ret = mdiobus_register(mii_bus);
- if (ret) {
- dev_err(&pdev->dev, "could not register mdio bus\n");
- return ret;
- }
- ret = device_property_read_u32(&pdev->dev, "phy-channel",
- &phy_addr);
- if (ret)
- /* If we can't read a valid phy address, then assume
- * that there is only one phy on this mdio bus.
- */
- adpt->phydev = phy_find_first(mii_bus);
- else
- adpt->phydev = mdiobus_get_phy(mii_bus, phy_addr);
-
- /* of_phy_find_device() claims a reference to the phydev,
- * so we do that here manually as well. When the driver
- * later unloads, it can unilaterally drop the reference
- * without worrying about ACPI vs DT.
- */
- if (adpt->phydev)
- get_device(&adpt->phydev->mdio.dev);
- } else {
- struct device_node *phy_np;
-
- ret = of_mdiobus_register(mii_bus, np);
- if (ret) {
- dev_err(&pdev->dev, "could not register mdio bus\n");
- return ret;
- }
+ ret = of_mdiobus_register(mii_bus, has_acpi_companion(&pdev->dev) ?
+ NULL : np);
+ if (ret)
+ dev_err(&pdev->dev, "Could not register mdio bus\n");
+
+ adpt->mii_bus = ret ? NULL : mii_bus;
+ return ret;
+}
+
+static int emac_get_phydev(struct platform_device *pdev,
+ struct emac_adapter *adpt)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct mii_bus *bus = adpt->mii_bus;
+ struct device_node *phy_np;
+ struct phy_device *phydev;
+ u32 phy_addr;
+ int ret;
+
+ if (!has_acpi_companion(&pdev->dev)) {
phy_np = of_parse_phandle(np, "phy-handle", 0);
adpt->phydev = of_phy_find_device(phy_np);
of_node_put(phy_np);
+ return adpt->phydev ? 0 : -ENODEV;
}
- if (!adpt->phydev) {
- dev_err(&pdev->dev, "could not find external phy\n");
- mdiobus_unregister(mii_bus);
+ ret = device_property_read_u32(&pdev->dev, "phy-channel",
+ &phy_addr);
+ /* If we can't read a valid phy address, then assume
+ * that there is only one phy on this mdio bus.
+ */
+ phydev = ret ? phy_find_first(bus) : mdiobus_get_phy(bus, phy_addr);
+ if (!phydev)
return -ENODEV;
- }
+ /* of_phy_find_device() claims a reference to the phydev,
+ * so we do that here manually as well. When the driver
+ * later unloads, it can unilaterally drop the reference
+ * without worrying about ACPI vs DT.
+ */
+ get_device(&phydev->mdio.dev);
+ adpt->phydev = phydev;
return 0;
}
+
+/* Configure the MDIO bus and connect the external PHY */
+int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
+{
+ int ret;
+
+ ret = emac_mdio_bus_create(pdev, adpt);
+ if (ret)
+ return ret;
+
+ ret = emac_get_phydev(pdev, adpt);
+ if (ret) {
+ dev_err(&pdev->dev, "Could not find external phy\n");
+ mdiobus_unregister(adpt->mii_bus);
+ }
+
+ return ret;
+}
--
2.18.0
^ permalink raw reply related
* [RFC PATCH 3/3] net: qcom/emac: add phy-handle support for ACPI
From: Wang Dongsheng @ 2018-11-08 7:22 UTC (permalink / raw)
To: andrew, timur
Cc: Wang Dongsheng, yu.zheng, f.fainelli, rjw, linux-acpi, netdev
In-Reply-To: <cover.1541660504.git.dongsheng.wang@hxt-semitech.com>
Use "phy-handle" to point to an internal MDIO device port.
Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
---
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 19 ++---
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 78 ++++++++++++++-----
2 files changed, 70 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.c b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
index 031f6e6ee9c1..74cfe7b95bb3 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-mac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
@@ -13,6 +13,7 @@
/* Qualcomm Technologies, Inc. EMAC Ethernet Controller MAC layer support
*/
+#include <linux/acpi_mdio.h>
#include <linux/tcp.h>
#include <linux/ip.h>
#include <linux/ipv6.h>
@@ -939,28 +940,28 @@ static void emac_adjust_link(struct net_device *netdev)
int emac_mac_up(struct emac_adapter *adpt)
{
struct net_device *netdev = adpt->netdev;
- int ret;
+ struct phy_device *phydev = adpt->phydev;
+ struct fwnode_handle *phy_np = acpi_get_phy_node(phydev);
emac_mac_rx_tx_ring_reset_all(adpt);
emac_mac_config(adpt);
emac_mac_rx_descs_refill(adpt, &adpt->rx_q);
- adpt->phydev->irq = PHY_POLL;
- ret = phy_connect_direct(netdev, adpt->phydev, emac_adjust_link,
- PHY_INTERFACE_MODE_SGMII);
- if (ret) {
+ phydev->irq = PHY_POLL;
+ phydev = acpi_phy_connect(netdev, phy_np, emac_adjust_link,
+ 0, PHY_INTERFACE_MODE_SGMII);
+ if (!phydev) {
netdev_err(adpt->netdev, "could not connect phy\n");
- return ret;
+ return -ENODEV;
}
- phy_attached_print(adpt->phydev, NULL);
+ phy_attached_print(phydev, NULL);
/* enable mac irq */
writel((u32)~DIS_INT, adpt->base + EMAC_INT_STATUS);
writel(adpt->irq.mask, adpt->base + EMAC_INT_MASK);
- phy_start(adpt->phydev);
-
+ phy_start(phydev);
napi_enable(&adpt->rx_q.napi);
netif_start_queue(netdev);
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-phy.c b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
index 8289fdda4be7..6616014292b0 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-phy.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
@@ -17,6 +17,7 @@
#include <linux/phy.h>
#include <linux/iopoll.h>
#include <linux/acpi.h>
+#include <linux/acpi_mdio.h>
#include "emac.h"
/* EMAC base register offsets */
@@ -96,10 +97,60 @@ static int emac_mdio_write(struct mii_bus *bus, int addr, int regnum, u16 val)
return 0;
}
+static struct phy_device *
+emac_acpi_get_phydev_from_phy_handle(struct platform_device *pdev)
+{
+ struct fwnode_reference_args args = {0};
+ struct fwnode_handle *fw_node;
+ struct phy_device *phydev;
+ int ret;
+
+ /* Get PHY Port reference from phy-handle */
+ fw_node = acpi_fwnode_handle(ACPI_COMPANION(&pdev->dev));
+ ret = acpi_node_get_property_reference(fw_node, "phy-handle", 0,
+ &args);
+ if (ret)
+ return ERR_PTR(-ENODEV);
+
+ if (!is_acpi_data_node(args.fwnode))
+ return ERR_PTR(-ENODEV);
+
+ phydev = acpi_phy_find_device(args.fwnode);
+ return phydev ? phydev : ERR_PTR(-ENODEV);
+}
+
+static struct phy_device *
+emac_acpi_get_phydev(struct platform_device *pdev, struct emac_adapter *adpt)
+{
+ struct phy_device *phydev = NULL;
+ int phy_addr;
+ int ret;
+
+ /* Compatible with "phy-channel" */
+ ret = device_property_read_u32(&pdev->dev, "phy-channel",
+ &phy_addr);
+ if (!ret)
+ phydev = mdiobus_get_phy(adpt->mii_bus, phy_addr);
+ if (phydev)
+ return phydev;
+
+ /* Get PHY Port reference from phy-handle */
+ phydev = emac_acpi_get_phydev_from_phy_handle(pdev);
+ if (!IS_ERR(phydev))
+ return phydev;
+
+ /* If we can't read a valid phy address from "phy-channel"/"phy-handle",
+ * then assume that there is only one phy on local mdio bus.
+ */
+ phydev = phy_find_first(adpt->mii_bus);
+ return phydev ? phydev : ERR_PTR(-ENODEV);
+}
+
static int emac_mdio_bus_create(struct platform_device *pdev,
struct emac_adapter *adpt)
{
struct device_node *np = pdev->dev.of_node;
+ struct fwnode_handle *fwnode = pdev->dev.fwnode;
struct mii_bus *mii_bus;
int ret;
@@ -115,8 +166,8 @@ static int emac_mdio_bus_create(struct platform_device *pdev,
mii_bus->parent = &pdev->dev;
mii_bus->priv = adpt;
- ret = of_mdiobus_register(mii_bus, has_acpi_companion(&pdev->dev) ?
- NULL : np);
+ ret = is_of_node(fwnode) ? of_mdiobus_register(mii_bus, np) :
+ acpi_mdiobus_register(mii_bus, fwnode);
if (ret)
dev_err(&pdev->dev, "Could not register mdio bus\n");
@@ -128,13 +179,9 @@ static int emac_get_phydev(struct platform_device *pdev,
struct emac_adapter *adpt)
{
struct device_node *np = pdev->dev.of_node;
- struct mii_bus *bus = adpt->mii_bus;
struct device_node *phy_np;
struct phy_device *phydev;
- u32 phy_addr;
- int ret;
-
if (!has_acpi_companion(&pdev->dev)) {
phy_np = of_parse_phandle(np, "phy-handle", 0);
adpt->phydev = of_phy_find_device(phy_np);
@@ -142,14 +189,9 @@ static int emac_get_phydev(struct platform_device *pdev,
return adpt->phydev ? 0 : -ENODEV;
}
- ret = device_property_read_u32(&pdev->dev, "phy-channel",
- &phy_addr);
- /* If we can't read a valid phy address, then assume
- * that there is only one phy on this mdio bus.
- */
- phydev = ret ? phy_find_first(bus) : mdiobus_get_phy(bus, phy_addr);
- if (!phydev)
- return -ENODEV;
+ phydev = emac_acpi_get_phydev(pdev, adpt);
+ if (IS_ERR(phydev))
+ return PTR_ERR(phydev);
/* of_phy_find_device() claims a reference to the phydev,
* so we do that here manually as well. When the driver
@@ -171,10 +213,10 @@ int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
return ret;
ret = emac_get_phydev(pdev, adpt);
- if (ret) {
- dev_err(&pdev->dev, "Could not find external phy\n");
- mdiobus_unregister(adpt->mii_bus);
- }
+ if (!ret)
+ return 0;
+ dev_err(&pdev->dev, "Could not find external phy\n");
+ mdiobus_unregister(adpt->mii_bus);
return ret;
}
--
2.18.0
^ permalink raw reply related
* Re: [PATCH net] ipv6/mcast: update mc_qrv when join new group
From: Hangbin Liu @ 2018-11-08 7:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1540521054-17825-1-git-send-email-liuhangbin@gmail.com>
On Fri, Oct 26, 2018 at 10:30:54AM +0800, Hangbin Liu wrote:
> Currently we only set mc_qrv to sysctl_mld_qrv when interface up. If we
> change sysctl_mld_qrv after interface up, it will has no effect.
>
> Fix it by assigning latest sysctl_mld_qrv to idev mc_qrv when join new group.
>
> Reported-by: Ying Xu <yinxu@redhat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Hi David,
Any comments for this patch?
Thanks
Hangbin
> ---
> net/ipv6/mcast.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
> index dbab62e..bed4890 100644
> --- a/net/ipv6/mcast.c
> +++ b/net/ipv6/mcast.c
> @@ -680,6 +680,7 @@ static void igmp6_group_added(struct ifmcaddr6 *mc)
> if (!(dev->flags & IFF_UP) || (mc->mca_flags & MAF_NOREPORT))
> return;
>
> + mc->idev->mc_qrv = sysctl_mld_qrv;
> if (mld_in_v1_mode(mc->idev)) {
> igmp6_join_group(mc);
> return;
> --
> 2.5.5
>
^ permalink raw reply
* Re: [RFC PATCH 1/3] acpi: Add acpi mdio support code
From: Rafael J. Wysocki @ 2018-11-08 7:45 UTC (permalink / raw)
To: Wang Dongsheng; +Cc: andrew, timur, yu.zheng, f.fainelli, linux-acpi, netdev
In-Reply-To: <2bf82b60c52bd3fc38b733e38fd991c9d31af6b9.1541660504.git.dongsheng.wang@hxt-semitech.com>
On Thursday, November 8, 2018 8:22:16 AM CET Wang Dongsheng wrote:
> Add support for parsing the ACPI data node for PHY devices on an MDIO bus.
> The current implementation depend on mdio bus scan.
> With _DSD device properties we can finally do this:
>
> Device (MDIO) {
> Name (_DSD, Package () {
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () { Package () { "ethernet-phy@0", PHY0 }, }
> })
> Name (PHY0, Package() {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "reg", 0x0 }, }
> })
> }
>
> Device (MACO) {
> Name (_DSD, Package () {
> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
> })
> }
>
> Documentations:
> The DT "phy-handle" binding that we reuse for ACPI is documented in
> Documentation/devicetree/bindings/phy/phy-bindings.txt
>
> Documentation/acpi/dsd/data-node-references.txt
> Documentation/acpi/dsd/graph.txt
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
> ---
> drivers/acpi/Kconfig | 6 ++
> drivers/acpi/Makefile | 1 +
> drivers/acpi/acpi_mdio.c | 167 +++++++++++++++++++++++++++++++++++++
> drivers/net/phy/mdio_bus.c | 3 +
> include/linux/acpi_mdio.h | 82 ++++++++++++++++++
> 5 files changed, 259 insertions(+)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 9705fc986da9..0fefa3410ce9 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -252,6 +252,12 @@ config ACPI_PROCESSOR_IDLE
> config ACPI_MCFG
> bool
>
> +config ACPI_MDIO
> + def_tristate PHYLIB
> + depends on PHYLIB
> + help
> + ACPI MDIO bus (Ethernet PHY) accessors
> +
> config ACPI_CPPC_LIB
> bool
> depends on ACPI_PROCESSOR
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 6d59aa109a91..ec7461a064fc 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -41,6 +41,7 @@ acpi-y += ec.o
> acpi-$(CONFIG_ACPI_DOCK) += dock.o
> acpi-y += pci_root.o pci_link.o pci_irq.o
> obj-$(CONFIG_ACPI_MCFG) += pci_mcfg.o
> +acpi-$(CONFIG_ACPI_MDIO) += acpi_mdio.o
> acpi-y += acpi_lpss.o acpi_apd.o
> acpi-y += acpi_platform.o
> acpi-y += acpi_pnp.o
> diff --git a/drivers/acpi/acpi_mdio.c b/drivers/acpi/acpi_mdio.c
> new file mode 100644
> index 000000000000..293bf9a63197
> --- /dev/null
> +++ b/drivers/acpi/acpi_mdio.c
> @@ -0,0 +1,167 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Lots of code in this file is copy from drivers/of/of_mdio.c
Would it be possible to re-factor that code and share it instead?
Thanks,
Rafael
^ permalink raw reply
* Re: [RFC PATCH 1/3] acpi: Add acpi mdio support code
From: Wang, Dongsheng @ 2018-11-08 7:55 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: andrew@lunn.ch, timur@kernel.org, Zheng, Joey,
f.fainelli@gmail.com, linux-acpi@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <2150057.QtixCRFV9x@aspire.rjw.lan>
On 2018/11/8 15:44, Rafael J. Wysocki wrote:
> On Thursday, November 8, 2018 8:22:16 AM CET Wang Dongsheng wrote:
>> Add support for parsing the ACPI data node for PHY devices on an MDIO bus.
>> The current implementation depend on mdio bus scan.
>> With _DSD device properties we can finally do this:
>>
>> Device (MDIO) {
>> Name (_DSD, Package () {
>> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
>> Package () { Package () { "ethernet-phy@0", PHY0 }, }
>> })
>> Name (PHY0, Package() {
>> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> Package () { Package () { "reg", 0x0 }, }
>> })
>> }
>>
>> Device (MACO) {
>> Name (_DSD, Package () {
>> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
>> })
>> }
>>
>> Documentations:
>> The DT "phy-handle" binding that we reuse for ACPI is documented in
>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>> Documentation/acpi/dsd/data-node-references.txt
>> Documentation/acpi/dsd/graph.txt
>>
>> Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
>> ---
>> drivers/acpi/Kconfig | 6 ++
>> drivers/acpi/Makefile | 1 +
>> drivers/acpi/acpi_mdio.c | 167 +++++++++++++++++++++++++++++++++++++
>> drivers/net/phy/mdio_bus.c | 3 +
>> include/linux/acpi_mdio.h | 82 ++++++++++++++++++
>> 5 files changed, 259 insertions(+)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 9705fc986da9..0fefa3410ce9 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -252,6 +252,12 @@ config ACPI_PROCESSOR_IDLE
>> config ACPI_MCFG
>> bool
>>
>> +config ACPI_MDIO
>> + def_tristate PHYLIB
>> + depends on PHYLIB
>> + help
>> + ACPI MDIO bus (Ethernet PHY) accessors
>> +
>> config ACPI_CPPC_LIB
>> bool
>> depends on ACPI_PROCESSOR
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 6d59aa109a91..ec7461a064fc 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -41,6 +41,7 @@ acpi-y += ec.o
>> acpi-$(CONFIG_ACPI_DOCK) += dock.o
>> acpi-y += pci_root.o pci_link.o pci_irq.o
>> obj-$(CONFIG_ACPI_MCFG) += pci_mcfg.o
>> +acpi-$(CONFIG_ACPI_MDIO) += acpi_mdio.o
>> acpi-y += acpi_lpss.o acpi_apd.o
>> acpi-y += acpi_platform.o
>> acpi-y += acpi_pnp.o
>> diff --git a/drivers/acpi/acpi_mdio.c b/drivers/acpi/acpi_mdio.c
>> new file mode 100644
>> index 000000000000..293bf9a63197
>> --- /dev/null
>> +++ b/drivers/acpi/acpi_mdio.c
>> @@ -0,0 +1,167 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +// Lots of code in this file is copy from drivers/of/of_mdio.c
> Would it be possible to re-factor that code and share it instead?
I thought about it, we can actually do it with fwnode.
But I don't have a lot of concentrate to do this. I'm going to focus on
a few other things...:(
Maybe in the second half of 2019 I can re-factor them if there is no one
re-factor them.
Cheers,
Dongsheng
> Thanks,
> Rafael
>
>
^ 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