* Re: [PATCH] net: netsec: reduce DMA mask to 40 bits
From: Robin Murphy @ 2018-05-25 19:37 UTC (permalink / raw)
To: Jassi Brar
Cc: Ard Biesheuvel, netdev, David S. Miller, Masahisa Kojima,
Ilias Apalodimas, nd
In-Reply-To: <CAJe_ZhfeEuRUTncyueb2ZRJq1uKrV44eiYVvfNrFufXdbDFRAw@mail.gmail.com>
On Sat, 26 May 2018 00:33:05 +0530
Jassi Brar <jaswinder.singh@linaro.org> wrote:
> On 25 May 2018 at 18:20, Ard Biesheuvel <ard.biesheuvel@linaro.org>
> wrote:
> > The netsec network controller IP can drive 64 address bits for DMA,
> > and the DMA mask is set accordingly in the driver. However, the
> > SynQuacer SoC, which is the only silicon incorporating this IP at
> > the moment, integrates this IP in a manner that leaves address bits
> > [63:40] unconnected.
> >
> > Up until now, this has not resulted in any problems, given that the
> > DDR controller doesn't decode those bits to begin with. However,
> > recent firmware updates for platforms incorporating this SoC allow
> > the IOMMU to be enabled, which does decode address bits [47:40],
> > and allocates top down from the IOVA space, producing DMA addresses
> > that have bits set that have been left unconnected.
> >
> > Both the DT and ACPI (IORT) descriptions of the platform take this
> > into account, and only describe a DMA address space of 40 bits
> > (using either dma-ranges DT properties, or DMA address limits in
> > IORT named component nodes). However, even though our IOMMU and bus
> > layers may take such limitations into account by setting a narrower
> > DMA mask when creating the platform device, the netsec probe()
> > entrypoint follows the common practice of setting the DMA mask
> > uncondionally, according to the capabilities of the IP block itself
> > rather than to its integration into the chip.
> >
> > It is currently unclear what the correct fix is here. We could hack
> > around it by only setting the DMA mask if it deviates from its
> > default value of DMA_BIT_MASK(32). However, this makes it
> > impossible for the bus layer to use DMA_BIT_MASK(32) as the bus
> > limit, and so it appears that a more comprehensive approach is
> > required to take DMA limits imposed by the SoC as a whole into
> > account.
> >
> > In the mean time, let's limit the DMA mask to 40 bits. Given that
> > there is currently only one SoC that incorporates this IP, this is
> > a reasonable approach that can be backported to -stable and buys us
> > some time to come up with a proper fix going forward.
> >
> I am sure you already thought about it, but why not let the platform
> specify the bit mask for the driver (via some "bus-width" property),
> to override the default 64 bit mask?
Because lack of a property to describe the integration is not the
problem. There are already at least two ways: the general DT/IORT
properties for describing DMA addressing - which it would be a bit
ungainly for a driver to parse for this reason, but not impossible -
and inferring it from a SoC-specific compatible - which is more
appropriate, and what we happen to be able to do here.
Robin.
^ permalink raw reply
* Re: [PATCH net-next] vrf: add CRC32c offload to device features
From: David Miller @ 2018-05-25 19:36 UTC (permalink / raw)
To: dcaratti; +Cc: dsa, vyasevich, marcelo.leitner, linux-sctp, netdev
In-Reply-To: <bb3aa69eaef613f033f8f52674740286ba67dc31.1527175921.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Thu, 24 May 2018 17:49:35 +0200
> SCTP sockets originated in a VRF can improve their performance if CRC32c
> computation is delegated to underlying devices: update device features,
> setting NETIF_F_SCTP_CRC. Iterating the following command in the topology
> proposed with [1],
>
> # ip vrf exec vrf-h2 netperf -H 192.0.2.1 -t SCTP_STREAM -- -m 10K
>
> the measured throughput in Mbit/s improved from 2395 ± 1% to 2720 ± 1%.
>
> [1] https://www.spinics.net/lists/netdev/msg486007.html
>
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
David A., please review.
^ permalink raw reply
* Re: [PATCH] PCI: allow drivers to limit the number of VFs to 0
From: Don Dutile @ 2018-05-25 19:27 UTC (permalink / raw)
To: Bjorn Helgaas, Jakub Kicinski
Cc: Bjorn Helgaas, linux-pci, netdev, Sathya Perla, Felix Manlunas,
alexander.duyck, john.fastabend, Jacob Keller, oss-drivers,
Christoph Hellwig
In-Reply-To: <20180525140223.GA45098@bhelgaas-glaptop.roam.corp.google.com>
On 05/25/2018 10:02 AM, Bjorn Helgaas wrote:
> On Thu, May 24, 2018 at 06:20:15PM -0700, Jakub Kicinski wrote:
>> Hi Bjorn!
>>
>> On Thu, 24 May 2018 18:57:48 -0500, Bjorn Helgaas wrote:
>>> On Mon, Apr 02, 2018 at 03:46:52PM -0700, Jakub Kicinski wrote:
>>>> Some user space depends on enabling sriov_totalvfs number of VFs
>>>> to not fail, e.g.:
>>>>
>>>> $ cat .../sriov_totalvfs > .../sriov_numvfs
>>>>
>>>> For devices which VF support depends on loaded FW we have the
>>>> pci_sriov_{g,s}et_totalvfs() API. However, this API uses 0 as
>>>> a special "unset" value, meaning drivers can't limit sriov_totalvfs
>>>> to 0. Remove the special values completely and simply initialize
>>>> driver_max_VFs to total_VFs. Then always use driver_max_VFs.
>>>> Add a helper for drivers to reset the VF limit back to total.
>>>
>>> I still can't really make sense out of the changelog.
>>>
>>> I think part of the reason it's confusing is because there are two
>>> things going on:
>>>
>>> 1) You want this:
>>>
>>> pci_sriov_set_totalvfs(dev, 0);
>>> x = pci_sriov_get_totalvfs(dev)
>>>
>>> to return 0 instead of total_VFs. That seems to connect with
>>> your subject line. It means "sriov_totalvfs" in sysfs could be
>>> 0, but I don't know how that is useful (I'm sure it is; just
>>> educate me :))
>>
>> Let me just quote the bug report that got filed on our internal bug
>> tracker :)
>>
>> When testing Juju Openstack with Ubuntu 18.04, enabling SR-IOV causes
>> errors because Juju gets the sriov_totalvfs for SR-IOV-capable device
>> then tries to set that as the sriov_numvfs parameter.
>>
>> For SR-IOV incapable FW, the sriov_totalvfs parameter should be 0,
>> but it's set to max. When FW is switched to flower*, the correct
>> sriov_totalvfs value is presented.
>>
>> * flower is a project name
>
> From the point of view of the PCI core (which knows nothing about
> device firmware and relies on the architected config space described
> by the PCIe spec), this sounds like an erratum: with some firmware
> installed, the device is not capable of SR-IOV, but still advertises
> an SR-IOV capability with "TotalVFs > 0".
>
> Regardless of whether that's an erratum, we do allow PF drivers to use
> pci_sriov_set_totalvfs() to limit the number of VFs that may be
> enabled by writing to the PF's "sriov_numvfs" sysfs file.
>
+1.
> But the current implementation does not allow a PF driver to limit VFs
> to 0, and that does seem nonsensical.
>
Well, not really -- claiming to support VFs, and then wanting it to be 0...
I could certainly argue is non-sensical.
From a sw perspective, sure, see if we can set VFs to 0 (and reset to another value later).
/me wishes that implementers would follow the architecture vs torquing it into strange shapes.
>> My understanding is OpenStack uses sriov_totalvfs to determine how many
>> VFs can be enabled, looks like this is the code:
>>
>> http://git.openstack.org/cgit/openstack/charm-neutron-openvswitch/tree/hooks/neutron_ovs_utils.py#n464
>>
>>> 2) You're adding the pci_sriov_reset_totalvfs() interface. I'm not
>>> sure what you intend for this. Is *every* driver supposed to
>>> call it in .remove()? Could/should this be done in the core
>>> somehow instead of depending on every driver?
>>
>> Good question, I was just thinking yesterday we may want to call it
>> from the core, but I don't think it's strictly necessary nor always
>> sufficient (we may reload FW without re-probing).
>>
>> We have a device which supports different number of VFs based on the FW
>> loaded. Some legacy FWs does not inform the driver how many VFs it can
>> support, because it supports max. So the flow in our driver is this:
>>
>> load_fw(dev);
>> ...
>> max_vfs = ask_fw_for_max_vfs(dev);
>> if (max_vfs >= 0)
>> return pci_sriov_set_totalvfs(dev, max_vfs);
>> else /* FW didn't tell us, assume max */
>> return pci_sriov_reset_totalvfs(dev);
>>
>> We also reset the max on device remove, but that's not strictly
>> necessary.
>>
>> Other users of pci_sriov_set_totalvfs() always know the value to set
>> the total to (either always get it from FW or it's a constant).
>>
>> If you prefer we can work out the correct max for those legacy cases in
>> the driver as well, although it seemed cleaner to just ask the core,
>> since it already has total_VFs value handy :)
>>
>>> I'm also having a hard time connecting your user-space command example
>>> with the rest of this. Maybe it will make more sense to me tomorrow
>>> after some coffee.
>>
>> OpenStack assumes it will always be able to set sriov_numvfs to
>> sriov_totalvfs, see this 'if':
>>
>> http://git.openstack.org/cgit/openstack/charm-neutron-openvswitch/tree/hooks/neutron_ovs_utils.py#n512
>
> Thanks for educating me. I think there are two issues here that we
> can separate. I extracted the patch below for the first.
>
> The second is the question of resetting driver_max_VFs. I think we
> currently have a general issue in the core:
>
> - load PF driver 1
> - driver calls pci_sriov_set_totalvfs() to reduce driver_max_VFs
> - unload PF driver 1
> - load PF driver 2
>
> Now driver_max_VFs is still stuck at the lower value set by driver 1.
> I don't think that's the way this should work.
>
> I guess this is partly a consequence of setting driver_max_VFs in
> sriov_init(), which is called before driver attach and should only
um, if it's at sriov_init() how is max changed by a PF driver?
or am I missing something subtle (a new sysfs param) as to what is being changed?
> depend on hardware characteristics, so it is related to the patch
> below. But I think we should fix it in general, not just for
> netronome.
>
>
> commit 4a338bc6f94b9ad824ac944f5dfc249d6838719c
> Author: Jakub Kicinski <jakub.kicinski@netronome.com>
> Date: Fri May 25 08:18:34 2018 -0500
>
> PCI/IOV: Allow PF drivers to limit total_VFs to 0
>
> Some SR-IOV PF drivers implement .sriov_configure(), which allows
> user-space to enable VFs by writing the desired number of VFs to the sysfs
> "sriov_numvfs" file (see sriov_numvfs_store()).
>
> The PCI core limits the number of VFs to the TotalVFs advertised by the
> device in its SR-IOV capability. The PF driver can limit the number of VFs
> to even fewer (it may have pre-allocated data structures or knowledge of
> device limitations) by calling pci_sriov_set_totalvfs(), but previously it
> could not limit the VFs to 0.
>
> Change pci_sriov_get_totalvfs() so it always respects the VF limit imposed
> by the PF driver, even if the limit is 0.
>
> This sequence:
>
> pci_sriov_set_totalvfs(dev, 0);
> x = pci_sriov_get_totalvfs(dev);
>
> previously set "x" to TotalVFs from the SR-IOV capability. Now it will set
> "x" to 0.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index 192b82898a38..d0d73dbbd5ca 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -469,6 +469,7 @@ static int sriov_init(struct pci_dev *dev, int pos)
> iov->nres = nres;
> iov->ctrl = ctrl;
> iov->total_VFs = total;
> + iov->driver_max_VFs = total;
> pci_read_config_word(dev, pos + PCI_SRIOV_VF_DID, &iov->vf_device);
> iov->pgsz = pgsz;
> iov->self = dev;
> @@ -827,10 +828,7 @@ int pci_sriov_get_totalvfs(struct pci_dev *dev)
> if (!dev->is_physfn)
> return 0;
>
> - if (dev->sriov->driver_max_VFs)
> - return dev->sriov->driver_max_VFs;
> -
> - return dev->sriov->total_VFs;
> + return dev->sriov->driver_max_VFs;
> }
> EXPORT_SYMBOL_GPL(pci_sriov_get_totalvfs);
>
>
^ permalink raw reply
* Re: [PATCH net] sctp: not allow to set rto_min with a value below 200 msecs
From: Neil Horman @ 2018-05-25 19:13 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp, davem, David Ahern, Eric Dumazet,
Marcelo Ricardo Leitner, syzkaller
In-Reply-To: <dc48b7c6a6dd1d8f19215cea6713d5723779d564.1527270062.git.lucien.xin@gmail.com>
On Sat, May 26, 2018 at 01:41:02AM +0800, Xin Long wrote:
> syzbot reported a rcu_sched self-detected stall on CPU which is caused
> by too small value set on rto_min with SCTP_RTOINFO sockopt. With this
> value, hb_timer will get stuck there, as in its timer handler it starts
> this timer again with this value, then goes to the timer handler again.
>
> This problem is there since very beginning, and thanks to Eric for the
> reproducer shared from a syzbot mail.
>
> This patch fixes it by not allowing to set rto_min with a value below
> 200 msecs, which is based on TCP's, by either setsockopt or sysctl.
>
> Reported-by: syzbot+3dcd59a1f907245f891f@syzkaller.appspotmail.com
> Suggested-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> include/net/sctp/constants.h | 1 +
> net/sctp/socket.c | 10 +++++++---
> net/sctp/sysctl.c | 3 ++-
> 3 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h
> index 20ff237..2ee7a7b 100644
> --- a/include/net/sctp/constants.h
> +++ b/include/net/sctp/constants.h
> @@ -277,6 +277,7 @@ enum { SCTP_MAX_GABS = 16 };
> #define SCTP_RTO_INITIAL (3 * 1000)
> #define SCTP_RTO_MIN (1 * 1000)
> #define SCTP_RTO_MAX (60 * 1000)
> +#define SCTP_RTO_HARD_MIN 200
>
> #define SCTP_RTO_ALPHA 3 /* 1/8 when converted to right shifts. */
> #define SCTP_RTO_BETA 2 /* 1/4 when converted to right shifts. */
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index ae7e7c6..6ef12c7 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -3029,7 +3029,8 @@ static int sctp_setsockopt_nodelay(struct sock *sk, char __user *optval,
> * be changed.
> *
> */
> -static int sctp_setsockopt_rtoinfo(struct sock *sk, char __user *optval, unsigned int optlen)
> +static int sctp_setsockopt_rtoinfo(struct sock *sk, char __user *optval,
> + unsigned int optlen)
> {
> struct sctp_rtoinfo rtoinfo;
> struct sctp_association *asoc;
> @@ -3056,10 +3057,13 @@ static int sctp_setsockopt_rtoinfo(struct sock *sk, char __user *optval, unsigne
> else
> rto_max = asoc ? asoc->rto_max : sp->rtoinfo.srto_max;
>
> - if (rto_min)
> + if (rto_min) {
> + if (rto_min < SCTP_RTO_HARD_MIN)
> + return -EINVAL;
> rto_min = asoc ? msecs_to_jiffies(rto_min) : rto_min;
> - else
> + } else {
> rto_min = asoc ? asoc->rto_min : sp->rtoinfo.srto_min;
> + }
>
> if (rto_min > rto_max)
> return -EINVAL;
> diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c
> index 33ca5b7..7ec854a 100644
> --- a/net/sctp/sysctl.c
> +++ b/net/sctp/sysctl.c
> @@ -52,6 +52,7 @@ static int rto_alpha_min = 0;
> static int rto_beta_min = 0;
> static int rto_alpha_max = 1000;
> static int rto_beta_max = 1000;
> +static int rto_hard_min = SCTP_RTO_HARD_MIN;
>
> static unsigned long max_autoclose_min = 0;
> static unsigned long max_autoclose_max =
> @@ -116,7 +117,7 @@ static struct ctl_table sctp_net_table[] = {
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_sctp_do_rto_min,
> - .extra1 = &one,
> + .extra1 = &rto_hard_min,
> .extra2 = &init_net.sctp.rto_max
> },
> {
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Patch looks fine, you probably want to note this hard minimum in man(7) sctp as
well
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH net] selftests/net: Add missing config options for PMTU tests
From: David Miller @ 2018-05-25 19:11 UTC (permalink / raw)
To: sbrivio; +Cc: naresh.kamboju, linux-kselftest, shuahkh, netdev
In-Reply-To: <53b70df32d1d92df98a9c8deaae90e9e7ad37fbc.1527170629.git.sbrivio@redhat.com>
From: Stefano Brivio <sbrivio@redhat.com>
Date: Thu, 24 May 2018 16:10:12 +0200
> PMTU tests in pmtu.sh need support for VTI, VTI6 and dummy
> interfaces: add them to config file.
>
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Fixes: d1f1b9cbf34c ("selftests: net: Introduce first PMTU test")
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4/cxgb4vf: Notify link changes to OS-dependent code
From: David Miller @ 2018-05-25 19:11 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, leedom, arjun, santosh
In-Reply-To: <1527170617-29905-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Thu, 24 May 2018 19:33:37 +0530
> From: Arjun Vynipadath <arjun@chelsio.com>
>
> We have a confusion of two different abstractions in the Common
> Code: Physical Link (Port) and Logical Network Interface (Virtual
> Interface), and we haven't been properly managing the state of the
> intersection of those two abstractions.
> On the one hand we have the Physical state of the Link -- up or down --
> and on the other we have the logical state of the VI, enabled or not.
> {ethN} refers to both the Physical and Logical State. In this case,
> ifconfig only affects/interrogates the Logical State of a VI,
> and ethtool only deals with the Physical State. And these are different.
>
> So, just because we disable the VI, we don't really want to change the
> Physical Link Up/Down state. Thus, the previous hack to set
> "lc->link_ok = 0" when we disable a VI is completely incorrect.
>
> Where we get into trouble is where the Physical Link State and the
> Logical VI State cross swords. And that happens in
> t4_handle_get_port_info() where we need to manage/safe the Physical
> Link State, but we also need to know when the Logical VI State has
> changed and pass that back up to the OS-dependent Driver routine
> t4_os_link_changed() which is concerned about the Logical Interface.
>
> So we enable a VI and that causes Firmware to send us a new Port
> Information message, but if none of the Physical Link State
> particulars have changed, we don't call t4_os_link_changed().
>
> This fix uses the existing OS Contract APIs for the Common Code to
> inform the OS-dependent portion of the Host Driver when the "Link" (really
> Logical Network Interface) is "up" or "down". A new API
> t4_enable_pi_params() is added which calls t4_enable_vi_params() and,
> if that is successful, then calls back to the OS Contract API
> t4_os_link_changed() notifying the OS-dependent layer of the
> potential Link State change.
>
> Original Work by : Casey Leedom <leedom@chelsio.com>
>
> Signed-off-by: Santosh Rastapur <santosh@chelsio.com>
> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: netsec: reduce DMA mask to 40 bits
From: Jassi Brar @ 2018-05-25 19:03 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: netdev, David S. Miller, Robin Murphy, Masahisa Kojima,
Ilias Apalodimas
In-Reply-To: <20180525125037.779-1-ard.biesheuvel@linaro.org>
On 25 May 2018 at 18:20, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> The netsec network controller IP can drive 64 address bits for DMA, and
> the DMA mask is set accordingly in the driver. However, the SynQuacer
> SoC, which is the only silicon incorporating this IP at the moment,
> integrates this IP in a manner that leaves address bits [63:40]
> unconnected.
>
> Up until now, this has not resulted in any problems, given that the DDR
> controller doesn't decode those bits to begin with. However, recent
> firmware updates for platforms incorporating this SoC allow the IOMMU
> to be enabled, which does decode address bits [47:40], and allocates
> top down from the IOVA space, producing DMA addresses that have bits
> set that have been left unconnected.
>
> Both the DT and ACPI (IORT) descriptions of the platform take this into
> account, and only describe a DMA address space of 40 bits (using either
> dma-ranges DT properties, or DMA address limits in IORT named component
> nodes). However, even though our IOMMU and bus layers may take such
> limitations into account by setting a narrower DMA mask when creating
> the platform device, the netsec probe() entrypoint follows the common
> practice of setting the DMA mask uncondionally, according to the
> capabilities of the IP block itself rather than to its integration into
> the chip.
>
> It is currently unclear what the correct fix is here. We could hack around
> it by only setting the DMA mask if it deviates from its default value of
> DMA_BIT_MASK(32). However, this makes it impossible for the bus layer to
> use DMA_BIT_MASK(32) as the bus limit, and so it appears that a more
> comprehensive approach is required to take DMA limits imposed by the
> SoC as a whole into account.
>
> In the mean time, let's limit the DMA mask to 40 bits. Given that there
> is currently only one SoC that incorporates this IP, this is a reasonable
> approach that can be backported to -stable and buys us some time to come
> up with a proper fix going forward.
>
I am sure you already thought about it, but why not let the platform
specify the bit mask for the driver (via some "bus-width" property),
to override the default 64 bit mask?
Cheers!
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: clean up init_one
From: David Miller @ 2018-05-25 19:01 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, leedom
In-Reply-To: <1527166935-26051-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Thu, 24 May 2018 18:32:15 +0530
> clean up init_one and use chip_ver consistently throughout
> init_one() for chip version.
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2] cxgb4/cxgb4vf: link management changes for new SFP
From: David Miller @ 2018-05-25 18:56 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, leedom
In-Reply-To: <1527164370-16486-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Thu, 24 May 2018 17:49:30 +0530
> newer SFPs like SFP28 and QSFP28 Transceiver Modules present
> several new possibilities which we haven't faced before. Fix the
> assumptions in the code reflecting the more limited capabilities
> of previous Transceiver Module systems
>
> Original work by Casey Leedom <leedom@chelsio.com>
>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
> ---
> V2: Was not getting applied on net-next, respining on net-next
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 0/4] pull request for net: batman-adv 2018-05-24
From: David Miller @ 2018-05-25 18:54 UTC (permalink / raw)
To: sw; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20180524115325.15355-1-sw@simonwunderlich.de>
From: Simon Wunderlich <sw@simonwunderlich.de>
Date: Thu, 24 May 2018 13:53:21 +0200
> here are a couple of bugfixes which we would like to have integrated into net.
>
> Please pull or let me know of any problem!
Looks good, pulled, thanks Simon.
^ permalink raw reply
* Re: [PATCH net-next] net: fec: remove stale comment
From: David Miller @ 2018-05-25 18:53 UTC (permalink / raw)
To: yuehaibing; +Cc: fugang.duan, netdev, linux-kernel
In-Reply-To: <20180524112707.3580-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 24 May 2018 19:27:07 +0800
> This comment is outdated as fec_ptp_ioctl has been replaced by fec_ptp_set/fec_ptp_get
> since commit 1d5244d0e43b ("fec: Implement the SIOCGHWTSTAMP ioctl")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2 net-next] sfc: stop the TX queue before pushing new buffers
From: David Miller @ 2018-05-25 18:50 UTC (permalink / raw)
To: mhabets; +Cc: linux-net-drivers, netdev, jarod
In-Reply-To: <f2749cb0-f1ce-4572-04fe-f1c11fe09237@solarflare.com>
From: Martin Habets <mhabets@solarflare.com>
Date: Thu, 24 May 2018 10:14:00 +0100
> efx_enqueue_skb() can push new buffers for the xmit_more functionality.
> We must stops the TX queue before this or else the TX queue does not get
> restarted and we get a netdev watchdog.
>
> In the error handling we may now need to unwind more than 1 packet, and
> we may need to push the new buffers onto the partner queue.
>
> v2: In the error leg also push this queue if xmit_more is set
>
> Fixes: e9117e5099ea ("sfc: Firmware-Assisted TSO version 2")
> Reported-by: Jarod Wilson <jarod@redhat.com>
> Tested-by: Jarod Wilson <jarod@redhat.com>
> Signed-off-by: Martin Habets <mhabets@solarflare.com>
> ---
>
> Dave, could you please also queue this patch up for stable?
Applied to net-next.
As per -stable, only patches that go into my 'net' tree may be proposed
for -stable.
^ permalink raw reply
* Re: [PATCH v2] ath6kl: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2018-05-25 18:48 UTC (permalink / raw)
To: Steve deRosier
Cc: Kalle Valo, davem, sergei.shtylyov, linux-wireless,
Network Development, LKML
In-Reply-To: <CALLGbRLFU5xH7PogXmjNSFkayLyo2Q1w1+8hQWgOSDYxS_GgUQ@mail.gmail.com>
On 05/25/2018 01:27 PM, Steve deRosier wrote:
> On Fri, May 25, 2018 at 11:23 AM Gustavo A. R. Silva
> <gustavo@embeddedor.com>
> wrote:
>
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>> ---
>> Changes in v2:
>> - Place code comments on a line of their own.
>
>> drivers/net/wireless/ath/ath6kl/cfg80211.c | 3 +++
>> 1 file changed, 3 insertions(+)
>
>> diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c
> b/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> index 2ba8cf3..a16ee5d 100644
>> --- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> @@ -3899,16 +3899,19 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
>> switch (ar->hw.cap) {
>> case WMI_11AN_CAP:
>> ht = true;
>> + /* fall through */
>> case WMI_11A_CAP:
>> band_5gig = true;
>> break;
>> case WMI_11GN_CAP:
>> ht = true;
>> + /* fall through */
>> case WMI_11G_CAP:
>> band_2gig = true;
>> break;
>> case WMI_11AGN_CAP:
>> ht = true;
>> + /* fall through */
>> case WMI_11AG_CAP:
>> band_2gig = true;
>> band_5gig = true;
>> --
>> 2.7.4
>
>
> Gustavo,
>
> Thanks for the adjustment. It now looks good to me.
>
Glad to help. :)
> Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
>
Thanks
--
Gustavo
^ permalink raw reply
* Re: [PATCH net-next] net:sched: add action inheritdsfield to skbmod
From: Cong Wang @ 2018-05-25 18:47 UTC (permalink / raw)
To: Fu, Qiaobin
Cc: Marcelo Ricardo Leitner, davem@davemloft.net,
netdev@vger.kernel.org, jhs@mojatatu.com, Michel Machado
In-Reply-To: <C7516012-947F-4485-B5DA-DD9AD45427F8@bu.edu>
On Thu, May 24, 2018 at 10:45 PM, Fu, Qiaobin <qiaobinf@bu.edu> wrote:
> The new action inheritdsfield copies the field DS of
> IPv4 and IPv6 packets into skb->priority. This enables
> later classification of packets based on the DS field.
Please move it to skbedit.
^ permalink raw reply
* Re: [PATCH net-next] net: bridge: add support for port isolation
From: David Miller @ 2018-05-25 18:46 UTC (permalink / raw)
To: nikolay; +Cc: netdev, roopa, stephen, bridge
In-Reply-To: <20180524085648.5934-1-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Thu, 24 May 2018 11:56:48 +0300
> This patch adds support for a new port flag - BR_ISOLATED. If it is set
> then isolated ports cannot communicate between each other, but they can
> still communicate with non-isolated ports. The same can be achieved via
> ACLs but they can't scale with large number of ports and also the
> complexity of the rules grows. This feature can be used to achieve
> isolated vlan functionality (similar to pvlan) as well, though currently
> it will be port-wide (for all vlans on the port). The new test in
> should_deliver uses data that is already cache hot and the new boolean
> is used to avoid an additional source port test in should_deliver.
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied, thanks Nikolay.
^ permalink raw reply
* [PATCH net-next 12/12] net: hns3: Fixes initalization of RoCE handle and makes it conditional
From: Salil Mehta @ 2018-05-25 18:43 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Lijun Ou, Zhou Wang
In-Reply-To: <20180525184307.36288-1-salil.mehta@huawei.com>
From: Lijun Ou <oulijun@huawei.com>
When register a RoCE client with hnae3vf device, it needs to judge
the device whether support RoCE vf function. Otherwise, it will
lead to calltrace when RoCE is not support vf function and remove
roce device.
The calltrace as follows:
[ 93.156614] Unable to handle kernel NULL pointer dereference at virtual address 00000015
<SNIP>
[ 93.278784] Call trace:
[ 93.278788] hnae3_match_n_instantiate+0x24/0xd8 [hnae3]
[ 93.278790] hnae3_register_client+0xcc/0x150 [hnae3]
[ 93.278801] hns_roce_hw_v2_init+0x18/0x1000 [hns_roce_hw_v2]
[ 93.278805] do_one_initcall+0x58/0x160
[ 93.278807] do_init_module+0x64/0x1d8
[ 93.278809] load_module+0x135c/0x15c8
[ 93.278811] SyS_finit_module+0x100/0x118
[ 93.278816] __sys_trace_return+0x0/0x4
[ 93.278827] Code: aa0003f5 12001c56 aa1e03e0 d503201f (b9402660)
Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support")
Reported-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Reported-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index 2b0e329..266cdcb 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -1500,10 +1500,12 @@ static int hclgevf_init_instance(struct hclgevf_dev *hdev,
return ret;
break;
case HNAE3_CLIENT_ROCE:
- hdev->roce_client = client;
- hdev->roce.client = client;
+ if (hnae3_dev_roce_supported(hdev)) {
+ hdev->roce_client = client;
+ hdev->roce.client = client;
+ }
- if (hdev->roce_client && hnae3_dev_roce_supported(hdev)) {
+ if (hdev->roce_client && hdev->nic_client) {
ret = hclgevf_init_roce_base_info(hdev);
if (ret)
return ret;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 11/12] net: hns3: Adds support for led locate command for copper port
From: Salil Mehta @ 2018-05-25 18:43 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Jian Shen
In-Reply-To: <20180525184307.36288-1-salil.mehta@huawei.com>
From: Jian Shen <shenjian15@huawei.com>
Firmware now supports control of all leds. Existing HNS3 driver code
only supported led locate command over SFP Fibre ports. But now it
is also supported over copper port.
This patch removes existing not needed code for the led locate
command and updates the led control command between driver and
firmware.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 12 ++------
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 35 +++-------------------
2 files changed, 6 insertions(+), 41 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index de2f6f1..d9aaa76 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -817,21 +817,13 @@ struct hclge_reset_cmd {
#define HCLGE_NIC_CMQ_DESC_NUM 1024
#define HCLGE_NIC_CMQ_DESC_NUM_S 3
-#define HCLGE_LED_PORT_SPEED_STATE_S 0
-#define HCLGE_LED_PORT_SPEED_STATE_M GENMASK(5, 0)
-#define HCLGE_LED_ACTIVITY_STATE_S 0
-#define HCLGE_LED_ACTIVITY_STATE_M GENMASK(1, 0)
-#define HCLGE_LED_LINK_STATE_S 0
-#define HCLGE_LED_LINK_STATE_M GENMASK(1, 0)
#define HCLGE_LED_LOCATE_STATE_S 0
#define HCLGE_LED_LOCATE_STATE_M GENMASK(1, 0)
struct hclge_set_led_state_cmd {
- u8 port_speed_led_config;
- u8 link_led_config;
- u8 activity_led_config;
+ u8 rsv1[3];
u8 locate_led_config;
- u8 rsv[20];
+ u8 rsv2[20];
};
int hclge_cmd_init(struct hclge_dev *hdev);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 20988aa..6916685 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -5991,9 +5991,7 @@ static void hclge_get_regs(struct hnae3_handle *handle, u32 *version,
"Get 64 bit register failed, ret = %d.\n", ret);
}
-static int hclge_set_led_status_sfp(struct hclge_dev *hdev, u8 speed_led_status,
- u8 act_led_status, u8 link_led_status,
- u8 locate_led_status)
+static int hclge_set_led_status(struct hclge_dev *hdev, u8 locate_led_status)
{
struct hclge_set_led_state_cmd *req;
struct hclge_desc desc;
@@ -6002,12 +6000,6 @@ static int hclge_set_led_status_sfp(struct hclge_dev *hdev, u8 speed_led_status,
hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_LED_STATUS_CFG, false);
req = (struct hclge_set_led_state_cmd *)desc.data;
- hnae_set_field(req->port_speed_led_config, HCLGE_LED_PORT_SPEED_STATE_M,
- HCLGE_LED_PORT_SPEED_STATE_S, speed_led_status);
- hnae_set_field(req->link_led_config, HCLGE_LED_ACTIVITY_STATE_M,
- HCLGE_LED_ACTIVITY_STATE_S, act_led_status);
- hnae_set_field(req->activity_led_config, HCLGE_LED_LINK_STATE_M,
- HCLGE_LED_LINK_STATE_S, link_led_status);
hnae_set_field(req->locate_led_config, HCLGE_LED_LOCATE_STATE_M,
HCLGE_LED_LOCATE_STATE_S, locate_led_status);
@@ -6028,36 +6020,17 @@ enum hclge_led_status {
static int hclge_set_led_id(struct hnae3_handle *handle,
enum ethtool_phys_id_state status)
{
-#define BLINK_FREQUENCY 2
struct hclge_vport *vport = hclge_get_vport(handle);
struct hclge_dev *hdev = vport->back;
- struct phy_device *phydev = hdev->hw.mac.phydev;
- int ret = 0;
-
- if (phydev || hdev->hw.mac.media_type != HNAE3_MEDIA_TYPE_FIBER)
- return -EOPNOTSUPP;
switch (status) {
case ETHTOOL_ID_ACTIVE:
- ret = hclge_set_led_status_sfp(hdev,
- HCLGE_LED_NO_CHANGE,
- HCLGE_LED_NO_CHANGE,
- HCLGE_LED_NO_CHANGE,
- HCLGE_LED_ON);
- break;
+ return hclge_set_led_status(hdev, HCLGE_LED_ON);
case ETHTOOL_ID_INACTIVE:
- ret = hclge_set_led_status_sfp(hdev,
- HCLGE_LED_NO_CHANGE,
- HCLGE_LED_NO_CHANGE,
- HCLGE_LED_NO_CHANGE,
- HCLGE_LED_OFF);
- break;
+ return hclge_set_led_status(hdev, HCLGE_LED_OFF);
default:
- ret = -EINVAL;
- break;
+ return -EINVAL;
}
-
- return ret;
}
static void hclge_get_link_mode(struct hnae3_handle *handle,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 10/12] net: hns3: Remove unused led control code
From: Salil Mehta @ 2018-05-25 18:43 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Jian Shen
In-Reply-To: <20180525184307.36288-1-salil.mehta@huawei.com>
From: Jian Shen <shenjian15@huawei.com>
In the previous implementation of led control for fibre port , parses the
port speed configuration, checks the link status and traffic status per
second, and updates the blink status of link led, traffic led and speed
led.
Now, the firmware takes responsibility to handle the led, the dirver just
needs to deal with locate command.
So the codes for link led, traffic led and speed led are useless now. This
patch removes these redundant codes.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 1 -
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 109 ---------------------
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 2 -
3 files changed, 112 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index e9be6aa..de2f6f1 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -115,7 +115,6 @@ enum hclge_opcode_type {
HCLGE_OPC_QUERY_LINK_STATUS = 0x0307,
HCLGE_OPC_CONFIG_MAX_FRM_SIZE = 0x0308,
HCLGE_OPC_CONFIG_SPEED_DUP = 0x0309,
- HCLGE_OPC_STATS_MAC_TRAFFIC = 0x0314,
/* MACSEC command */
/* PFC/Pause CMD*/
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 8ad8f62..20988aa 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -39,7 +39,6 @@ static int hclge_set_mta_filter_mode(struct hclge_dev *hdev,
static int hclge_set_mtu(struct hnae3_handle *handle, int new_mtu);
static int hclge_init_vlan_config(struct hclge_dev *hdev);
static int hclge_reset_ae_dev(struct hnae3_ae_dev *ae_dev);
-static int hclge_update_led_status(struct hclge_dev *hdev);
static struct hnae3_ae_algo ae_algo;
@@ -504,38 +503,6 @@ static int hclge_32_bit_update_stats(struct hclge_dev *hdev)
return 0;
}
-static int hclge_mac_get_traffic_stats(struct hclge_dev *hdev)
-{
- struct hclge_mac_stats *mac_stats = &hdev->hw_stats.mac_stats;
- struct hclge_desc desc;
- __le64 *desc_data;
- int ret;
-
- /* for fiber port, need to query the total rx/tx packets statstics,
- * used for data transferring checking.
- */
- if (hdev->hw.mac.media_type != HNAE3_MEDIA_TYPE_FIBER)
- return 0;
-
- if (test_bit(HCLGE_STATE_STATISTICS_UPDATING, &hdev->state))
- return 0;
-
- hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_STATS_MAC_TRAFFIC, true);
- ret = hclge_cmd_send(&hdev->hw, &desc, 1);
- if (ret) {
- dev_err(&hdev->pdev->dev,
- "Get MAC total pkt stats fail, ret = %d\n", ret);
-
- return ret;
- }
-
- desc_data = (__le64 *)(&desc.data[0]);
- mac_stats->mac_tx_total_pkt_num += le64_to_cpu(*desc_data++);
- mac_stats->mac_rx_total_pkt_num += le64_to_cpu(*desc_data);
-
- return 0;
-}
-
static int hclge_mac_update_stats(struct hclge_dev *hdev)
{
#define HCLGE_MAC_CMD_NUM 21
@@ -2916,20 +2883,13 @@ static void hclge_service_task(struct work_struct *work)
struct hclge_dev *hdev =
container_of(work, struct hclge_dev, service_task);
- /* The total rx/tx packets statstics are wanted to be updated
- * per second. Both hclge_update_stats_for_all() and
- * hclge_mac_get_traffic_stats() can do it.
- */
if (hdev->hw_stats.stats_timer >= HCLGE_STATS_TIMER_INTERVAL) {
hclge_update_stats_for_all(hdev);
hdev->hw_stats.stats_timer = 0;
- } else {
- hclge_mac_get_traffic_stats(hdev);
}
hclge_update_speed_duplex(hdev);
hclge_update_link_status(hdev);
- hclge_update_led_status(hdev);
hclge_service_complete(hdev);
}
@@ -6100,75 +6060,6 @@ static int hclge_set_led_id(struct hnae3_handle *handle,
return ret;
}
-enum hclge_led_port_speed {
- HCLGE_SPEED_LED_FOR_1G,
- HCLGE_SPEED_LED_FOR_10G,
- HCLGE_SPEED_LED_FOR_25G,
- HCLGE_SPEED_LED_FOR_40G,
- HCLGE_SPEED_LED_FOR_50G,
- HCLGE_SPEED_LED_FOR_100G,
-};
-
-static u8 hclge_led_get_speed_status(u32 speed)
-{
- u8 speed_led;
-
- switch (speed) {
- case HCLGE_MAC_SPEED_1G:
- speed_led = HCLGE_SPEED_LED_FOR_1G;
- break;
- case HCLGE_MAC_SPEED_10G:
- speed_led = HCLGE_SPEED_LED_FOR_10G;
- break;
- case HCLGE_MAC_SPEED_25G:
- speed_led = HCLGE_SPEED_LED_FOR_25G;
- break;
- case HCLGE_MAC_SPEED_40G:
- speed_led = HCLGE_SPEED_LED_FOR_40G;
- break;
- case HCLGE_MAC_SPEED_50G:
- speed_led = HCLGE_SPEED_LED_FOR_50G;
- break;
- case HCLGE_MAC_SPEED_100G:
- speed_led = HCLGE_SPEED_LED_FOR_100G;
- break;
- default:
- speed_led = HCLGE_LED_NO_CHANGE;
- }
-
- return speed_led;
-}
-
-static int hclge_update_led_status(struct hclge_dev *hdev)
-{
- u8 port_speed_status, link_status, activity_status;
- u64 rx_pkts, tx_pkts;
-
- if (hdev->hw.mac.media_type != HNAE3_MEDIA_TYPE_FIBER)
- return 0;
-
- port_speed_status = hclge_led_get_speed_status(hdev->hw.mac.speed);
-
- rx_pkts = hdev->hw_stats.mac_stats.mac_rx_total_pkt_num;
- tx_pkts = hdev->hw_stats.mac_stats.mac_tx_total_pkt_num;
- if (rx_pkts != hdev->rx_pkts_for_led ||
- tx_pkts != hdev->tx_pkts_for_led)
- activity_status = HCLGE_LED_ON;
- else
- activity_status = HCLGE_LED_OFF;
- hdev->rx_pkts_for_led = rx_pkts;
- hdev->tx_pkts_for_led = tx_pkts;
-
- if (hdev->hw.mac.link)
- link_status = HCLGE_LED_ON;
- else
- link_status = HCLGE_LED_OFF;
-
- return hclge_set_led_status_sfp(hdev, port_speed_status,
- activity_status, link_status,
- HCLGE_LED_NO_CHANGE);
-}
-
static void hclge_get_link_mode(struct hnae3_handle *handle,
unsigned long *supported,
unsigned long *advertising)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
index 677f1e4..7fcabde 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
@@ -563,8 +563,6 @@ struct hclge_dev {
struct hclge_vlan_type_cfg vlan_type_cfg;
- u64 rx_pkts_for_led;
- u64 tx_pkts_for_led;
unsigned long vlan_table[VLAN_N_VID][BITS_TO_LONGS(HCLGE_VPORT_NUM)];
};
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 09/12] net: hns3: Clear TX/RX rings when stopping port & un-initializing client
From: Salil Mehta @ 2018-05-25 18:43 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Fuyun Liang
In-Reply-To: <20180525184307.36288-1-salil.mehta@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
When we down the port, some packets are left in TX/RX buffer. When we
up the port again, these old packets are forwarded to protocol stack
or are sent to internet. It will make some problem. TX/RX buffer should
be cleared when stopping port. This patch adds some function to ensure
the buffer is clean when port is started. We should clear the rings
when clients are being un-initialized as well.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 115 +++++++++++++++++++--
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 1 +
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 4 +
3 files changed, 110 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 4c13c52..0529012 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -25,6 +25,9 @@
#include "hnae3.h"
#include "hns3_enet.h"
+static void hns3_clear_all_ring(struct hnae3_handle *h);
+static void hns3_force_clear_all_rx_ring(struct hnae3_handle *h);
+
static const char hns3_driver_name[] = "hns3";
const char hns3_driver_version[] = VERMAGIC_STRING;
static const char hns3_driver_string[] =
@@ -273,6 +276,10 @@ static int hns3_nic_net_up(struct net_device *netdev)
int i, j;
int ret;
+ ret = hns3_nic_reset_all_ring(h);
+ if (ret)
+ return ret;
+
/* get irq resource for all vectors */
ret = hns3_nic_init_irq(priv);
if (ret) {
@@ -333,17 +340,19 @@ static void hns3_nic_net_down(struct net_device *netdev)
if (test_and_set_bit(HNS3_NIC_STATE_DOWN, &priv->state))
return;
+ /* disable vectors */
+ for (i = 0; i < priv->vector_num; i++)
+ hns3_vector_disable(&priv->tqp_vector[i]);
+
/* stop ae_dev */
ops = priv->ae_handle->ae_algo->ops;
if (ops->stop)
ops->stop(priv->ae_handle);
- /* disable vectors */
- for (i = 0; i < priv->vector_num; i++)
- hns3_vector_disable(&priv->tqp_vector[i]);
-
/* free irq resources */
hns3_nic_uninit_irq(priv);
+
+ hns3_clear_all_ring(priv->ae_handle);
}
static int hns3_nic_net_stop(struct net_device *netdev)
@@ -2939,8 +2948,6 @@ int hns3_init_all_ring(struct hns3_nic_priv *priv)
goto out_when_alloc_ring_memory;
}
- hns3_init_ring_hw(priv->ring_data[i].ring);
-
u64_stats_init(&priv->ring_data[i].ring->syncp);
}
@@ -3102,6 +3109,8 @@ static void hns3_client_uninit(struct hnae3_handle *handle, bool reset)
if (netdev->reg_state != NETREG_UNINITIALIZED)
unregister_netdev(netdev);
+ hns3_force_clear_all_rx_ring(handle);
+
ret = hns3_nic_uninit_vector_data(priv);
if (ret)
netdev_err(netdev, "uninit vector error\n");
@@ -3218,12 +3227,46 @@ static void hns3_recover_hw_addr(struct net_device *ndev)
static void hns3_clear_tx_ring(struct hns3_enet_ring *ring)
{
while (ring->next_to_clean != ring->next_to_use) {
+ ring->desc[ring->next_to_clean].tx.bdtp_fe_sc_vld_ra_ri = 0;
hns3_free_buffer_detach(ring, ring->next_to_clean);
ring_ptr_move_fw(ring, next_to_clean);
}
}
-static void hns3_clear_rx_ring(struct hns3_enet_ring *ring)
+static int hns3_clear_rx_ring(struct hns3_enet_ring *ring)
+{
+ struct hns3_desc_cb res_cbs;
+ int ret;
+
+ while (ring->next_to_use != ring->next_to_clean) {
+ /* When a buffer is not reused, it's memory has been
+ * freed in hns3_handle_rx_bd or will be freed by
+ * stack, so we need to replace the buffer here.
+ */
+ if (!ring->desc_cb[ring->next_to_use].reuse_flag) {
+ ret = hns3_reserve_buffer_map(ring, &res_cbs);
+ if (ret) {
+ u64_stats_update_begin(&ring->syncp);
+ ring->stats.sw_err_cnt++;
+ u64_stats_update_end(&ring->syncp);
+ /* if alloc new buffer fail, exit directly
+ * and reclear in up flow.
+ */
+ netdev_warn(ring->tqp->handle->kinfo.netdev,
+ "reserve buffer map failed, ret = %d\n",
+ ret);
+ return ret;
+ }
+ hns3_replace_buffer(ring, ring->next_to_use,
+ &res_cbs);
+ }
+ ring_ptr_move_fw(ring, next_to_use);
+ }
+
+ return 0;
+}
+
+static void hns3_force_clear_rx_ring(struct hns3_enet_ring *ring)
{
while (ring->next_to_use != ring->next_to_clean) {
/* When a buffer is not reused, it's memory has been
@@ -3240,6 +3283,19 @@ static void hns3_clear_rx_ring(struct hns3_enet_ring *ring)
}
}
+static void hns3_force_clear_all_rx_ring(struct hnae3_handle *h)
+{
+ struct net_device *ndev = h->kinfo.netdev;
+ struct hns3_nic_priv *priv = netdev_priv(ndev);
+ struct hns3_enet_ring *ring;
+ u32 i;
+
+ for (i = 0; i < h->kinfo.num_tqps; i++) {
+ ring = priv->ring_data[i + h->kinfo.num_tqps].ring;
+ hns3_force_clear_rx_ring(ring);
+ }
+}
+
static void hns3_clear_all_ring(struct hnae3_handle *h)
{
struct net_device *ndev = h->kinfo.netdev;
@@ -3257,10 +3313,51 @@ static void hns3_clear_all_ring(struct hnae3_handle *h)
netdev_tx_reset_queue(dev_queue);
ring = priv->ring_data[i + h->kinfo.num_tqps].ring;
+ /* Continue to clear other rings even if clearing some
+ * rings failed.
+ */
hns3_clear_rx_ring(ring);
}
}
+int hns3_nic_reset_all_ring(struct hnae3_handle *h)
+{
+ struct net_device *ndev = h->kinfo.netdev;
+ struct hns3_nic_priv *priv = netdev_priv(ndev);
+ struct hns3_enet_ring *rx_ring;
+ int i, j;
+ int ret;
+
+ for (i = 0; i < h->kinfo.num_tqps; i++) {
+ h->ae_algo->ops->reset_queue(h, i);
+ hns3_init_ring_hw(priv->ring_data[i].ring);
+
+ /* We need to clear tx ring here because self test will
+ * use the ring and will not run down before up
+ */
+ hns3_clear_tx_ring(priv->ring_data[i].ring);
+ priv->ring_data[i].ring->next_to_clean = 0;
+ priv->ring_data[i].ring->next_to_use = 0;
+
+ rx_ring = priv->ring_data[i + h->kinfo.num_tqps].ring;
+ hns3_init_ring_hw(rx_ring);
+ ret = hns3_clear_rx_ring(rx_ring);
+ if (ret)
+ return ret;
+
+ /* We can not know the hardware head and tail when this
+ * function is called in reset flow, so we reuse all desc.
+ */
+ for (j = 0; j < rx_ring->desc_num; j++)
+ hns3_reuse_buffer(rx_ring, j);
+
+ rx_ring->next_to_clean = 0;
+ rx_ring->next_to_use = 0;
+ }
+
+ return 0;
+}
+
static int hns3_reset_notify_down_enet(struct hnae3_handle *handle)
{
struct hnae3_knic_private_info *kinfo = &handle->kinfo;
@@ -3330,7 +3427,7 @@ static int hns3_reset_notify_uninit_enet(struct hnae3_handle *handle)
struct hns3_nic_priv *priv = netdev_priv(netdev);
int ret;
- hns3_clear_all_ring(handle);
+ hns3_force_clear_all_rx_ring(handle);
ret = hns3_nic_uninit_vector_data(priv);
if (ret) {
@@ -3466,8 +3563,6 @@ int hns3_set_channels(struct net_device *netdev,
if (if_running)
hns3_nic_net_stop(netdev);
- hns3_clear_all_ring(h);
-
ret = hns3_nic_uninit_vector_data(priv);
if (ret) {
dev_err(&netdev->dev,
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 38e91ca..3b083d5a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -625,6 +625,7 @@ int hns3_set_channels(struct net_device *netdev,
bool hns3_clean_tx_ring(struct hns3_enet_ring *ring, int budget);
int hns3_init_all_ring(struct hns3_nic_priv *priv);
int hns3_uninit_all_ring(struct hns3_nic_priv *priv);
+int hns3_nic_reset_all_ring(struct hnae3_handle *h);
netdev_tx_t hns3_nic_net_xmit(struct sk_buff *skb, struct net_device *netdev);
int hns3_clean_rx_ring(
struct hns3_enet_ring *ring, int budget,
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index c16bb6c..8f8cc24 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -108,6 +108,10 @@ static int hns3_lp_up(struct net_device *ndev, enum hnae3_loop loop_mode)
if (!h->ae_algo->ops->start)
return -EOPNOTSUPP;
+ ret = hns3_nic_reset_all_ring(h);
+ if (ret)
+ return ret;
+
ret = h->ae_algo->ops->start(h);
if (ret) {
netdev_err(ndev,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 08/12] net: hns3: Removes unnecessary check when clearing TX/RX rings
From: Salil Mehta @ 2018-05-25 18:43 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Fuyun Liang
In-Reply-To: <20180525184307.36288-1-salil.mehta@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
Our code will ensure that hns3_clear_tx_ring is not used to cleared
RX rings and hns3_clear_rx_ring is not used to cleared TX rings. So
the ring type check is unnecessary.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index d1ef104..4c13c52 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -3217,9 +3217,6 @@ static void hns3_recover_hw_addr(struct net_device *ndev)
static void hns3_clear_tx_ring(struct hns3_enet_ring *ring)
{
- if (!HNAE3_IS_TX_RING(ring))
- return;
-
while (ring->next_to_clean != ring->next_to_use) {
hns3_free_buffer_detach(ring, ring->next_to_clean);
ring_ptr_move_fw(ring, next_to_clean);
@@ -3228,9 +3225,6 @@ static void hns3_clear_tx_ring(struct hns3_enet_ring *ring)
static void hns3_clear_rx_ring(struct hns3_enet_ring *ring)
{
- if (HNAE3_IS_TX_RING(ring))
- return;
-
while (ring->next_to_use != ring->next_to_clean) {
/* When a buffer is not reused, it's memory has been
* freed in hns3_handle_rx_bd or will be freed by
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 07/12] net: hns3: Fixes the init of the VALID BD info in the descriptor
From: Salil Mehta @ 2018-05-25 18:43 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Fuyun Liang
In-Reply-To: <20180525184307.36288-1-salil.mehta@huawei.com>
From: Fuyun Liang <liangfuyun1@huawei.com>
RX Buffer Descriptor contains a VALID bit which indicates if the BD
is valid and has some data. This field is set by HNS3 hardware to
intimate the driver of some valid data present in the BD. nd should
be reset by the driver when BD is being used again. In the existing
code this bit was not being (re-)initialized properly and hence was
causing problems.
Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
Signed-off-by: Fuyun Liang <liangfuyun1@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 1bcb676..d1ef104 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1819,6 +1819,7 @@ static void hns3_replace_buffer(struct hns3_enet_ring *ring, int i,
hns3_unmap_buffer(ring, &ring->desc_cb[i]);
ring->desc_cb[i] = *res_cb;
ring->desc[i].addr = cpu_to_le64(ring->desc_cb[i].dma);
+ ring->desc[i].rx.bd_base_info = 0;
}
static void hns3_reuse_buffer(struct hns3_enet_ring *ring, int i)
@@ -1826,6 +1827,7 @@ static void hns3_reuse_buffer(struct hns3_enet_ring *ring, int i)
ring->desc_cb[i].reuse_flag = 0;
ring->desc[i].addr = cpu_to_le64(ring->desc_cb[i].dma
+ ring->desc_cb[i].page_offset);
+ ring->desc[i].rx.bd_base_info = 0;
}
static void hns3_nic_reclaim_one_desc(struct hns3_enet_ring *ring, int *bytes,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 06/12] net: hns3: Fixes the state to indicate client-type initialization
From: Salil Mehta @ 2018-05-25 18:43 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm
In-Reply-To: <20180525184307.36288-1-salil.mehta@huawei.com>
From: Peng Li <lipeng321@huawei.com>
HNAE3 module supports kernel nic driver, user nic driver and roce driver,
and there are 3 client types. Driver uses one bit(HNAE3_CLIENT_INITED_B)
to indicate the client initialization state, it will cause confusion
for 3 client types. This patch fixes it by use 3 bits to indicate the
initialization state.
Fixes: 38caee9d3ee8 ("net: hns3: Add support of the HNAE3 framework")
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.c | 49 +++++++++++++++++++++++++++--
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 4 ++-
2 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index 63d7dbf..9d79dad 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -36,6 +36,49 @@ static bool hnae3_client_match(enum hnae3_client_type client_type,
return false;
}
+static void hnae3_set_client_init_flag(struct hnae3_client *client,
+ struct hnae3_ae_dev *ae_dev, int inited)
+{
+ switch (client->type) {
+ case HNAE3_CLIENT_KNIC:
+ hnae_set_bit(ae_dev->flag, HNAE3_KNIC_CLIENT_INITED_B, inited);
+ break;
+ case HNAE3_CLIENT_UNIC:
+ hnae_set_bit(ae_dev->flag, HNAE3_UNIC_CLIENT_INITED_B, inited);
+ break;
+ case HNAE3_CLIENT_ROCE:
+ hnae_set_bit(ae_dev->flag, HNAE3_ROCE_CLIENT_INITED_B, inited);
+ break;
+ default:
+ break;
+ }
+}
+
+static int hnae3_get_client_init_flag(struct hnae3_client *client,
+ struct hnae3_ae_dev *ae_dev)
+{
+ int inited = 0;
+
+ switch (client->type) {
+ case HNAE3_CLIENT_KNIC:
+ inited = hnae_get_bit(ae_dev->flag,
+ HNAE3_KNIC_CLIENT_INITED_B);
+ break;
+ case HNAE3_CLIENT_UNIC:
+ inited = hnae_get_bit(ae_dev->flag,
+ HNAE3_UNIC_CLIENT_INITED_B);
+ break;
+ case HNAE3_CLIENT_ROCE:
+ inited = hnae_get_bit(ae_dev->flag,
+ HNAE3_ROCE_CLIENT_INITED_B);
+ break;
+ default:
+ break;
+ }
+
+ return inited;
+}
+
static int hnae3_match_n_instantiate(struct hnae3_client *client,
struct hnae3_ae_dev *ae_dev, bool is_reg)
{
@@ -56,14 +99,14 @@ static int hnae3_match_n_instantiate(struct hnae3_client *client,
return ret;
}
- hnae_set_bit(ae_dev->flag, HNAE3_CLIENT_INITED_B, 1);
+ hnae3_set_client_init_flag(client, ae_dev, 1);
return 0;
}
- if (hnae_get_bit(ae_dev->flag, HNAE3_CLIENT_INITED_B)) {
+ if (hnae3_get_client_init_flag(client, ae_dev)) {
ae_dev->ops->uninit_client_instance(client, ae_dev);
- hnae_set_bit(ae_dev->flag, HNAE3_CLIENT_INITED_B, 0);
+ hnae3_set_client_init_flag(client, ae_dev, 0);
}
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 45c571e..f250c59 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -54,7 +54,9 @@
#define HNAE3_DEV_INITED_B 0x0
#define HNAE3_DEV_SUPPORT_ROCE_B 0x1
#define HNAE3_DEV_SUPPORT_DCB_B 0x2
-#define HNAE3_CLIENT_INITED_B 0x3
+#define HNAE3_KNIC_CLIENT_INITED_B 0x3
+#define HNAE3_UNIC_CLIENT_INITED_B 0x4
+#define HNAE3_ROCE_CLIENT_INITED_B 0x5
#define HNAE3_DEV_SUPPORT_ROCE_DCB_BITS (BIT(HNAE3_DEV_SUPPORT_DCB_B) |\
BIT(HNAE3_DEV_SUPPORT_ROCE_B))
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 05/12] net: hns3: Fix for PF mailbox receving unknown message
From: Salil Mehta @ 2018-05-25 18:43 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm, Xi Wang
In-Reply-To: <20180525184307.36288-1-salil.mehta@huawei.com>
From: Xi Wang <wangxi11@huawei.com>
Before the firmware updates the crq's tail pointer, if the PF driver
reads the data in the crq, the data may be incomplete at this time,
which will lead to the driver read an unknown message.
This patch fixes it by checking if crq is not empty before reading the
message.
Fixes: c1a81619d73a ("net: hns3: Add mailbox interrupt handling to PF driver")
Signed-off-by: Xi Wang <wangxi11@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 23 +++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
index b6ae26b..31f3d9a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
@@ -382,6 +382,13 @@ static void hclge_reset_vf(struct hclge_vport *vport,
hclge_func_reset_cmd(hdev, mbx_req->mbx_src_vfid);
}
+static bool hclge_cmd_crq_empty(struct hclge_hw *hw)
+{
+ u32 tail = hclge_read_dev(hw, HCLGE_NIC_CRQ_TAIL_REG);
+
+ return tail == hw->cmq.crq.next_to_use;
+}
+
void hclge_mbx_handler(struct hclge_dev *hdev)
{
struct hclge_cmq_ring *crq = &hdev->hw.cmq.crq;
@@ -390,12 +397,23 @@ void hclge_mbx_handler(struct hclge_dev *hdev)
struct hclge_desc *desc;
int ret, flag;
- flag = le16_to_cpu(crq->desc[crq->next_to_use].flag);
/* handle all the mailbox requests in the queue */
- while (hnae_get_bit(flag, HCLGE_CMDQ_RX_OUTVLD_B)) {
+ while (!hclge_cmd_crq_empty(&hdev->hw)) {
desc = &crq->desc[crq->next_to_use];
req = (struct hclge_mbx_vf_to_pf_cmd *)desc->data;
+ flag = le16_to_cpu(crq->desc[crq->next_to_use].flag);
+ if (unlikely(!hnae_get_bit(flag, HCLGE_CMDQ_RX_OUTVLD_B))) {
+ dev_warn(&hdev->pdev->dev,
+ "dropped invalid mailbox message, code = %d\n",
+ req->msg[0]);
+
+ /* dropping/not processing this invalid message */
+ crq->desc[crq->next_to_use].flag = 0;
+ hclge_mbx_ring_ptr_move_crq(crq);
+ continue;
+ }
+
vport = &hdev->vport[req->mbx_src_vfid];
switch (req->msg[0]) {
@@ -470,7 +488,6 @@ void hclge_mbx_handler(struct hclge_dev *hdev)
}
crq->desc[crq->next_to_use].flag = 0;
hclge_mbx_ring_ptr_move_crq(crq);
- flag = le16_to_cpu(crq->desc[crq->next_to_use].flag);
}
/* Write back CMDQ_RQ header pointer, M7 need this pointer */
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 04/12] net: hns3: Add support to enable TX/RX promisc mode for H/W rev(0x21)
From: Salil Mehta @ 2018-05-25 18:42 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm
In-Reply-To: <20180525184307.36288-1-salil.mehta@huawei.com>
From: Peng Li <lipeng321@huawei.com>
HCLGE_PROMISC_TX_EN_B and HCLGE_PROMISC_RX_EN_B are not supported
on pdev revision(0x20), new revision(0x21) supports them.
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 2 ++
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 9 ++++++++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 3fa08f7..e9be6aa 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -484,6 +484,8 @@ struct hclge_promisc_param {
u8 enable;
};
+#define HCLGE_PROMISC_TX_EN_B BIT(4)
+#define HCLGE_PROMISC_RX_EN_B BIT(5)
#define HCLGE_PROMISC_EN_B 1
#define HCLGE_PROMISC_EN_ALL 0x7
#define HCLGE_PROMISC_EN_UC 0x1
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index c0b8d5a..8ad8f62 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3586,7 +3586,14 @@ int hclge_cmd_set_promisc_mode(struct hclge_dev *hdev,
req = (struct hclge_promisc_cfg_cmd *)desc.data;
req->vf_id = param->vf_id;
- req->flag = (param->enable << HCLGE_PROMISC_EN_B);
+
+ /* HCLGE_PROMISC_TX_EN_B and HCLGE_PROMISC_RX_EN_B are not supported on
+ * pdev revision(0x20), new revision support them. The
+ * value of this two fields will not return error when driver
+ * send command to fireware in revision(0x20).
+ */
+ req->flag = (param->enable << HCLGE_PROMISC_EN_B) |
+ HCLGE_PROMISC_TX_EN_B | HCLGE_PROMISC_RX_EN_B;
ret = hclge_cmd_send(&hdev->hw, &desc, 1);
if (ret) {
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 03/12] net: hns3: Add STRP_TAGP field support for hardware revision 0x21
From: Salil Mehta @ 2018-05-25 18:42 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil, netdev,
linux-kernel, linuxarm
In-Reply-To: <20180525184307.36288-1-salil.mehta@huawei.com>
From: Peng Li <lipeng321@huawei.com>
Hardware Revision(0x21) Buffer Descriptor adds a field STRP_TAGP
for vlan stripped processed indication. STRP_TAGP field has 2 bits,
bit 0 is stripped indication of the vlan tag in outer vlan tag
field, bit 1 is stripped indication of the vlan tag in inner vlan
tag field. For each bit, 0 indicates the tag is not stripped and
1 indicates the tag is stripped.
This patch adds STRP_TAGP support for revision(0x21), and does not
change the revision(0x20) action.
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 42 ++++++++++++++++++++++---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 3 ++
2 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index ae8d749..1bcb676 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2066,6 +2066,39 @@ static void hns3_rx_skb(struct hns3_enet_ring *ring, struct sk_buff *skb)
napi_gro_receive(&ring->tqp_vector->napi, skb);
}
+static u16 hns3_parse_vlan_tag(struct hns3_enet_ring *ring,
+ struct hns3_desc *desc, u32 l234info)
+{
+ struct pci_dev *pdev = ring->tqp->handle->pdev;
+ u16 vlan_tag;
+
+ if (pdev->revision == 0x20) {
+ vlan_tag = le16_to_cpu(desc->rx.ot_vlan_tag);
+ if (!(vlan_tag & VLAN_VID_MASK))
+ vlan_tag = le16_to_cpu(desc->rx.vlan_tag);
+
+ return vlan_tag;
+ }
+
+#define HNS3_STRP_OUTER_VLAN 0x1
+#define HNS3_STRP_INNER_VLAN 0x2
+
+ switch (hnae_get_field(l234info, HNS3_RXD_STRP_TAGP_M,
+ HNS3_RXD_STRP_TAGP_S)) {
+ case HNS3_STRP_OUTER_VLAN:
+ vlan_tag = le16_to_cpu(desc->rx.ot_vlan_tag);
+ break;
+ case HNS3_STRP_INNER_VLAN:
+ vlan_tag = le16_to_cpu(desc->rx.vlan_tag);
+ break;
+ default:
+ vlan_tag = 0;
+ break;
+ }
+
+ return vlan_tag;
+}
+
static int hns3_handle_rx_bd(struct hns3_enet_ring *ring,
struct sk_buff **out_skb, int *out_bnum)
{
@@ -2155,6 +2188,9 @@ static int hns3_handle_rx_bd(struct hns3_enet_ring *ring,
}
*out_bnum = bnum;
+
+ l234info = le32_to_cpu(desc->rx.l234_info);
+
/* Based on hw strategy, the tag offloaded will be stored at
* ot_vlan_tag in two layer tag case, and stored at vlan_tag
* in one layer tag case.
@@ -2162,17 +2198,13 @@ static int hns3_handle_rx_bd(struct hns3_enet_ring *ring,
if (netdev->features & NETIF_F_HW_VLAN_CTAG_RX) {
u16 vlan_tag;
- vlan_tag = le16_to_cpu(desc->rx.ot_vlan_tag);
- if (!(vlan_tag & VLAN_VID_MASK))
- vlan_tag = le16_to_cpu(desc->rx.vlan_tag);
+ vlan_tag = hns3_parse_vlan_tag(ring, desc, l234info);
if (vlan_tag & VLAN_VID_MASK)
__vlan_hwaccel_put_tag(skb,
htons(ETH_P_8021Q),
vlan_tag);
}
- l234info = le32_to_cpu(desc->rx.l234_info);
-
if (unlikely(!hnae_get_bit(bd_base_info, HNS3_RXD_VLD_B))) {
netdev_err(netdev, "no valid bd,%016llx,%016llx\n",
((u64 *)desc)[0], ((u64 *)desc)[1]);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 5b40f5a..38e91ca 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -104,6 +104,9 @@ enum hns3_nic_state {
#define HNS3_RXD_L4ID_S 8
#define HNS3_RXD_L4ID_M (0xf << HNS3_RXD_L4ID_S)
#define HNS3_RXD_FRAG_B 12
+#define HNS3_RXD_STRP_TAGP_S 13
+#define HNS3_RXD_STRP_TAGP_M (0x3 << HNS3_RXD_STRP_TAGP_S)
+
#define HNS3_RXD_L2E_B 16
#define HNS3_RXD_L3E_B 17
#define HNS3_RXD_L4E_B 18
--
2.7.4
^ permalink raw reply related
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