* [PATCH] sh_eth: fix EESIPR values for SH77{34|63}
From: Sergei Shtylyov @ 2017-01-04 19:18 UTC (permalink / raw)
To: netdev, linux-renesas-soc
As the SH77{34|63} manuals are freely available, I've checked the EESIPR
values written against the manuals, and they appeared to set the reserved
bits 11-15 (which should be 0 on write). Fix those EESIPR values.
Fixes: 380af9e390ec ("net: sh_eth: CPU dependency code collect to "struct sh_eth_cpu_data"")
Fixes: f5d12767c8fd ("sh_eth: get SH77{34|63} support out of #ifdef")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
This patch is against DaveM's 'net.git' repo.
drivers/net/ethernet/renesas/sh_eth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: net/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net/drivers/net/ethernet/renesas/sh_eth.c
@@ -802,7 +802,7 @@ static struct sh_eth_cpu_data sh7734_dat
.ecsr_value = ECSR_ICD | ECSR_MPD,
.ecsipr_value = ECSIPR_LCHNGIP | ECSIPR_ICDIP | ECSIPR_MPDIP,
- .eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
+ .eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003f07ff,
.tx_check = EESR_TC1 | EESR_FTC,
.eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
@@ -831,7 +831,7 @@ static struct sh_eth_cpu_data sh7763_dat
.ecsr_value = ECSR_ICD | ECSR_MPD,
.ecsipr_value = ECSIPR_LCHNGIP | ECSIPR_ICDIP | ECSIPR_MPDIP,
- .eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
+ .eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003f07ff,
.tx_check = EESR_TC1 | EESR_FTC,
.eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
^ permalink raw reply
* Re: [PATCH net] sfc: don't report RX hash keys to ethtool when RSS wasn't enabled
From: David Miller @ 2017-01-04 19:18 UTC (permalink / raw)
To: ecree; +Cc: linux-net-drivers, bkenward, netdev
In-Reply-To: <5a4ac10d-3b4b-bf48-e4ca-c435eed29dc3@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Wed, 4 Jan 2017 15:10:56 +0000
> If we failed to set up RSS on EF10 (e.g. because firmware declared
> RX_RSS_LIMITED), ethtool --show-nfc $dev rx-flow-hash ... should report
> no fields, rather than confusingly reporting what fields we _would_ be
> hashing on if RSS was working.
>
> Fixes: dcb4123cbec0 ("sfc: disable RSS when unsupported")
> Signed-off-by: Edward Cree <ecree@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next rfc 5/6] net-tc: convert tc_at to tc_at_ingress
From: Willem de Bruijn @ 2017-01-04 19:26 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Network Development, David Miller, Florian Westphal, dborkman,
Jamal Hadi Salim, Alexei Starovoitov, Willem de Bruijn
In-Reply-To: <586D4A6F.7020009@iogearbox.net>
>> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
>> index ef53ede..be4e18d 100644
>> --- a/net/sched/sch_api.c
>> +++ b/net/sched/sch_api.c
>> @@ -1865,6 +1865,7 @@ int tc_classify(struct sk_buff *skb, const struct
>> tcf_proto *tp,
>> const struct tcf_proto *old_tp = tp;
>> int limit = 0;
>>
>> + skb->tc_at_ingress = !!(tp && tp->q->flags & TCQ_F_INGRESS);
>
>
> I'd prefer if skb->tc_at_ingress is set directly to 0/1 in
> sch_handle_ingress()
> and __dev_queue_xmit() as we do right now, this would avoid above tests in
> fast
> path and it would also avoid to set the same thing in tc_classify() multiple
> times f.e. on egress path walking through multiple qdiscs. I don't see
> anything
> in layers above tc that would read it and expect an AT_STACK-like
> equivalent.
> skb_reset_tc() could thus still remain as you have above in fast-path like
> __netif_receive_skb_core().
I had been thinking about that. After submitting this I noticed that Florian's
patchset had an elegant solution to avoid the branch: set tc_at_ingress in
handle_ing before tc_classify and clear it on the return path.
Then we only set + clear it once on ingress regardless of the depth
of classifiers and do not touch it at all in other code.
https://patchwork.ozlabs.org/patch/472698/
What do you think of that approach?
^ permalink raw reply
* Re: [PATCH] sh_eth: fix EESIPR values for SH77{34|63}
From: Sergei Shtylyov @ 2017-01-04 19:27 UTC (permalink / raw)
To: netdev, linux-renesas-soc
In-Reply-To: <1819012.0ROIJmx7mp@wasted.cogentembedded.com>
On 01/04/2017 10:18 PM, Sergei Shtylyov wrote:
> As the SH77{34|63} manuals are freely available, I've checked the EESIPR
> values written against the manuals, and they appeared to set the reserved
> bits 11-15 (which should be 0 on write). Fix those EESIPR values.
>
> Fixes: 380af9e390ec ("net: sh_eth: CPU dependency code collect to "struct sh_eth_cpu_data"")
For SH7763 the bug is older than this commit but the code was common for
all SH SoCs supported back then and so couldn't be fixed w/o affecting other
SoCs. However, I suspect that the mask was incorrect even for the other SoCs...
> Fixes: f5d12767c8fd ("sh_eth: get SH77{34|63} support out of #ifdef")
That's the point where SH7734/63 data were split...
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH net-next] liquidio VF: fix incorrect struct being used
From: Felix Manlunas @ 2017-01-04 19:31 UTC (permalink / raw)
To: davem; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
From: Prasad Kanneganti <prasad.kanneganti@cavium.com>
The VF driver is using the wrong struct when sending commands to the NIC
firmware, sometimes causing adverse effects in the firmware. The right
struct is the one that the PF is using, so make the VF use that as well.
Signed-off-by: Prasad Kanneganti <prasad.kanneganti@cavium.com>
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
---
drivers/net/ethernet/cavium/liquidio/octeon_nic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_nic.c b/drivers/net/ethernet/cavium/liquidio/octeon_nic.c
index c3d6a82..0243be8 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_nic.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_nic.c
@@ -49,7 +49,7 @@ octeon_alloc_soft_command_resp(struct octeon_device *oct,
/* Add in the response related fields. Opcode and Param are already
* there.
*/
- if (OCTEON_CN23XX_PF(oct)) {
+ if (OCTEON_CN23XX_PF(oct) || OCTEON_CN23XX_VF(oct)) {
ih3 = (struct octeon_instr_ih3 *)&sc->cmd.cmd3.ih3;
rdp = (struct octeon_instr_rdp *)&sc->cmd.cmd3.rdp;
irh = (struct octeon_instr_irh *)&sc->cmd.cmd3.irh;
@@ -70,7 +70,7 @@ octeon_alloc_soft_command_resp(struct octeon_device *oct,
*sc->status_word = COMPLETION_WORD_INIT;
- if (OCTEON_CN23XX_PF(oct))
+ if (OCTEON_CN23XX_PF(oct) || OCTEON_CN23XX_VF(oct))
sc->cmd.cmd3.rptr = sc->dmarptr;
else
sc->cmd.cmd2.rptr = sc->dmarptr;
^ permalink raw reply related
* Re: [PATCH net-next rfc 5/6] net-tc: convert tc_at to tc_at_ingress
From: Daniel Borkmann @ 2017-01-04 19:51 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Network Development, David Miller, Florian Westphal, dborkman,
Jamal Hadi Salim, Alexei Starovoitov, Willem de Bruijn
In-Reply-To: <CAF=yD-+x7zP2Z5Ctsn9-_uYz7sfdZMf4n414CE1-bzVQcN3nBA@mail.gmail.com>
On 01/04/2017 08:26 PM, Willem de Bruijn wrote:
>>> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
>>> index ef53ede..be4e18d 100644
>>> --- a/net/sched/sch_api.c
>>> +++ b/net/sched/sch_api.c
>>> @@ -1865,6 +1865,7 @@ int tc_classify(struct sk_buff *skb, const struct
>>> tcf_proto *tp,
>>> const struct tcf_proto *old_tp = tp;
>>> int limit = 0;
>>>
>>> + skb->tc_at_ingress = !!(tp && tp->q->flags & TCQ_F_INGRESS);
>>
>> I'd prefer if skb->tc_at_ingress is set directly to 0/1 in
>> sch_handle_ingress()
>> and __dev_queue_xmit() as we do right now, this would avoid above tests in
>> fast
>> path and it would also avoid to set the same thing in tc_classify() multiple
>> times f.e. on egress path walking through multiple qdiscs. I don't see
>> anything
>> in layers above tc that would read it and expect an AT_STACK-like
>> equivalent.
>> skb_reset_tc() could thus still remain as you have above in fast-path like
>> __netif_receive_skb_core().
>
> I had been thinking about that. After submitting this I noticed that Florian's
> patchset had an elegant solution to avoid the branch: set tc_at_ingress in
> handle_ing before tc_classify and clear it on the return path.
>
> Then we only set + clear it once on ingress regardless of the depth
> of classifiers and do not touch it at all in other code.
>
> https://patchwork.ozlabs.org/patch/472698/
>
> What do you think of that approach?
I think this approach might not work, it would certainly change semantics
since right now *before* going into tc_classify() we always update skb->tc_verd's
"at" location. After the patch we'd set TC_AT_INGRESS in ingress and could
redirect within tc_classify() [and we'd skip that skb->tc_verd = 0 we have in
__netif_receive_skb_core() for these] to xmit from there where next call into
classifier from __dev_queue_xmit() call-site misses that we're not at ingress
anymore but already at egress, so it would do wrong pull/push of headers in
some cls, for example. I mentioned above that I think your skb_reset_tc() for
the __netif_receive_skb_core() fast-path could stay as you have it in that patch
as afaik there's no user that reads out this value in above layers, so if we
keep the "at" info always correct before going into tc_classify(), we should
be good.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH] phy state machine: failsafe leave invalid RUNNING state
From: kbuild test robot @ 2017-01-04 20:07 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: kbuild-all, netdev, f.fainelli, andrew
In-Reply-To: <1483542298-9747-1-git-send-email-zefir.kurtisi@neratec.com>
[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]
Hi Zefir,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.10-rc2 next-20170104]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Zefir-Kurtisi/phy-state-machine-failsafe-leave-invalid-RUNNING-state/20170105-033018
config: x86_64-kexec (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/phy/phy.c: In function 'phy_state_machine':
>> drivers/net/phy/phy.c:1075:20: error: 'struct phy_device' has no member named 'dev'; did you mean 'drv'?
dev_warn(&phydev->dev, "no link in PHY_RUNNING\n");
^~
vim +1075 drivers/net/phy/phy.c
1069 * Failsafe: check that nobody set phydev->link=0 between two
1070 * poll cycles, otherwise we won't leave RUNNING state as long
1071 * as link remains down.
1072 */
1073 if (!phydev->link && phydev->state == PHY_RUNNING) {
1074 phydev->state = PHY_CHANGELINK;
> 1075 dev_warn(&phydev->dev, "no link in PHY_RUNNING\n");
1076 }
1077 break;
1078 case PHY_CHANGELINK:
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24448 bytes --]
^ permalink raw reply
* [PATCH] sh_eth: enable RX descriptor word 0 shift on SH7734
From: Sergei Shtylyov @ 2017-01-04 20:10 UTC (permalink / raw)
To: netdev, linux-renesas-soc
The RX descriptor word 0 on SH7734 has the RFS[9:0] field in bits 16-25
(bits 0-15 usually used for that are occupied by the packet checksum).
Thus we need to set the 'shift_rd0' field in the SH7734 SoC data...
Fixes: f0e81fecd4f8 ("net: sh_eth: Add support SH7734")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
The patch is against DaveM's 'net.git' repo.
drivers/net/ethernet/renesas/sh_eth.c | 1 +
1 file changed, 1 insertion(+)
Index: net/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net/drivers/net/ethernet/renesas/sh_eth.c
@@ -819,6 +819,7 @@ static struct sh_eth_cpu_data sh7734_dat
.tsu = 1,
.hw_crc = 1,
.select_mii = 1,
+ .shift_rd0 = 1,
};
/* SH7763 */
^ permalink raw reply
* Re: [PATCH net-next 0/6] Prepare BPF for VLAN_TAG_PRESENT cleanup
From: Daniel Borkmann @ 2017-01-04 20:11 UTC (permalink / raw)
To: Michał Mirosław, netdev; +Cc: alexei.starovoitov
In-Reply-To: <cover.1483492355.git.mirq-linux@rere.qmqm.pl>
On 01/04/2017 02:18 AM, Michał Mirosław wrote:
> Those patches prepare BPF ant its JITs for removal of VLAN_TAG_PRESENT.
> The set depends on "Preparation for VLAN_TAG_PRESENT cleanup" patchset.
>
> The series is supposed to be bisect-friendly and that requires temporary
> insertion of #define VLAN_TAG_PRESENT in BPF code to be able to split
> JIT changes per architecture.
>
> Michał Mirosław (6):
> net/skbuff: add macros for VLAN_PRESENT bit
> net/bpf_jit: ARM: split VLAN_PRESENT bit handling from VLAN_TCI
> net/bpf_jit: MIPS: split VLAN_PRESENT bit handling from VLAN_TCI
> net/bpf_jit: PPC: split VLAN_PRESENT bit handling from VLAN_TCI
> net/bpf_jit: SPARC: split VLAN_PRESENT bit handling from VLAN_TCI
> net/bpf: split VLAN_PRESENT bit handling from VLAN_TCI
Please add a proper changelog to all the individual patches, right now
they have none. Also, how was this runtime tested? Did you run BPF selftest
suite with them? Seems like they weren't even compile tested properly
given the kbuild bot barking on sparc ...
> arch/arm/net/bpf_jit_32.c | 16 ++++++++++------
> arch/mips/net/bpf_jit.c | 18 ++++++++++--------
> arch/powerpc/net/bpf_jit_comp.c | 17 +++++++++--------
> arch/sparc/net/bpf_jit_comp.c | 18 ++++++++++--------
> include/linux/skbuff.h | 6 ++++++
> net/core/filter.c | 19 +++++++++----------
> 6 files changed, 54 insertions(+), 40 deletions(-)
>
^ permalink raw reply
* Re: [RESEND net-next PATCH v5] net: dummy: Introduce dummy virtual functions
From: Phil Sutter @ 2017-01-04 20:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sd
In-Reply-To: <20170104.140914.1059886799372716512.davem@davemloft.net>
On Wed, Jan 04, 2017 at 02:09:14PM -0500, David Miller wrote:
> From: Phil Sutter <phil@nwl.cc>
> Date: Wed, 4 Jan 2017 14:44:06 +0100
>
> > The idea for this was born when testing VF support in iproute2 which was
> > impeded by hardware requirements. In fact, not every VF-capable hardware
> > driver implements all netdev ops, so testing the interface is still hard
> > to do even with a well-sorted hardware shelf.
> >
> > To overcome this and allow for testing the user-kernel interface, this
> > patch allows to turn dummy into a PF with a configurable amount of VFs.
> >
> > Due to the assumption that all PFs are PCI devices, this implementation
> > is not completely straightforward: In order to allow for
> > rtnl_fill_ifinfo() to see the dummy VFs, a fake PCI parent device is
> > attached to the dummy netdev. This has to happen at the right spot so
> > register_netdevice() does not get confused. This patch abuses
> > ndo_fix_features callback for that. In ndo_uninit callback, the fake
> > parent is removed again for the same purpose.
> >
> > Joint work with Sabrina Dubroca.
> >
> > Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
>
> First of all I really applaud any effort to make the kernel interfaces
> more testable, and less dependent upon having specific pieces of hardware.
>
> That being said, all of this seems to be fighting the problem from the
> wrong direction.
>
> The device layer is really kidding itself by having what seems like a
> generic method in the form of dev_num_vf(), which actually just tests
> the bus type and calls a bus specific function on a match.
>
> There is no reason in the world that this cannot be done via proper
> device method call, that any bus type or whatever can implement.
Yes, this is certainly the proper way to do this. Thanks for your
confirmation!
> Then you don't need any of this stuff, you just hook up the proper
> device method to the dummy device and you're good.
My goal with this (admittedly fugly) hack was to be least intrusive as
possible, allowing people to use the module solely for testing purposes
in case the patch was rejected for other reasons.
I'm glad to see you're not against this practically useless enhancement
of dummy.c per se and so will try to come up with a proper fix for
dev_num_vf() paving the way for a hack-free version of it.
Thanks, Phil
^ permalink raw reply
* Re: [PATCH net-next rfc 5/6] net-tc: convert tc_at to tc_at_ingress
From: Willem de Bruijn @ 2017-01-04 20:20 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Network Development, David Miller, Florian Westphal, dborkman,
Jamal Hadi Salim, Alexei Starovoitov, Willem de Bruijn
In-Reply-To: <586D5231.5080706@iogearbox.net>
On Wed, Jan 4, 2017 at 2:51 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 01/04/2017 08:26 PM, Willem de Bruijn wrote:
>>>>
>>>> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
>>>> index ef53ede..be4e18d 100644
>>>> --- a/net/sched/sch_api.c
>>>> +++ b/net/sched/sch_api.c
>>>> @@ -1865,6 +1865,7 @@ int tc_classify(struct sk_buff *skb, const struct
>>>> tcf_proto *tp,
>>>> const struct tcf_proto *old_tp = tp;
>>>> int limit = 0;
>>>>
>>>> + skb->tc_at_ingress = !!(tp && tp->q->flags & TCQ_F_INGRESS);
>>>
>>>
>>> I'd prefer if skb->tc_at_ingress is set directly to 0/1 in
>>> sch_handle_ingress()
>>> and __dev_queue_xmit() as we do right now, this would avoid above tests
>>> in
>>> fast
>>> path and it would also avoid to set the same thing in tc_classify()
>>> multiple
>>> times f.e. on egress path walking through multiple qdiscs. I don't see
>>> anything
>>> in layers above tc that would read it and expect an AT_STACK-like
>>> equivalent.
>>> skb_reset_tc() could thus still remain as you have above in fast-path
>>> like
>>> __netif_receive_skb_core().
>>
>>
>> I had been thinking about that. After submitting this I noticed that
>> Florian's
>> patchset had an elegant solution to avoid the branch: set tc_at_ingress in
>> handle_ing before tc_classify and clear it on the return path.
>>
>> Then we only set + clear it once on ingress regardless of the depth
>> of classifiers and do not touch it at all in other code.
>>
>> https://patchwork.ozlabs.org/patch/472698/
>>
>> What do you think of that approach?
>
>
> I think this approach might not work, it would certainly change semantics
> since right now *before* going into tc_classify() we always update
> skb->tc_verd's
> "at" location. After the patch we'd set TC_AT_INGRESS in ingress and could
> redirect within tc_classify() [and we'd skip that skb->tc_verd = 0 we have
> in
> __netif_receive_skb_core() for these] to xmit from there where next call
> into
> classifier from __dev_queue_xmit() call-site misses that we're not at
> ingress
> anymore but already at egress, so it would do wrong pull/push of headers in
> some cls, for example.
Oh, yes, of course. Okay, I will follow the existing code in v1. Thanks, Daniel.
^ permalink raw reply
* Re: [PATCH] phy state machine: failsafe leave invalid RUNNING state
From: kbuild test robot @ 2017-01-04 20:23 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: kbuild-all, netdev, f.fainelli, andrew
In-Reply-To: <1483542298-9747-1-git-send-email-zefir.kurtisi@neratec.com>
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
Hi Zefir,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.10-rc2 next-20170104]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Zefir-Kurtisi/phy-state-machine-failsafe-leave-invalid-RUNNING-state/20170105-033018
config: i386-randconfig-i1-201701 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/net/phy/phy.c: In function 'phy_state_machine':
>> drivers/net/phy/phy.c:1075:20: error: 'struct phy_device' has no member named 'dev'
dev_warn(&phydev->dev, "no link in PHY_RUNNING\n");
^
vim +1075 drivers/net/phy/phy.c
1069 * Failsafe: check that nobody set phydev->link=0 between two
1070 * poll cycles, otherwise we won't leave RUNNING state as long
1071 * as link remains down.
1072 */
1073 if (!phydev->link && phydev->state == PHY_RUNNING) {
1074 phydev->state = PHY_CHANGELINK;
> 1075 dev_warn(&phydev->dev, "no link in PHY_RUNNING\n");
1076 }
1077 break;
1078 case PHY_CHANGELINK:
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29567 bytes --]
^ permalink raw reply
* [PATCH net] amd-xgbe: Fix IRQ processing when running in single IRQ mode
From: Tom Lendacky @ 2017-01-04 21:07 UTC (permalink / raw)
To: netdev; +Cc: David Miller
When running in single IRQ mode, the additional IRQ routines were being
skipped because only the XGMAC interrupt status was being checked.
Update the code so that the additional IRQ routines are checked whenever
an interrupt is received.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
index 155190d..9943629 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -539,6 +539,7 @@ static irqreturn_t xgbe_isr(int irq, void *data)
}
}
+isr_done:
/* If there is not a separate AN irq, handle it here */
if (pdata->dev_irq == pdata->an_irq)
pdata->phy_if.an_isr(irq, pdata);
@@ -551,7 +552,6 @@ static irqreturn_t xgbe_isr(int irq, void *data)
if (pdata->vdata->i2c_support && (pdata->dev_irq == pdata->i2c_irq))
pdata->i2c_if.i2c_isr(irq, pdata);
-isr_done:
return IRQ_HANDLED;
}
^ permalink raw reply related
* Re: [PATCH repost net-next] dsa: mv88e6xxx: Optimise atu_get
From: David Miller @ 2017-01-04 21:11 UTC (permalink / raw)
To: andrew; +Cc: volodymyr.bendiuga, vivien.didelot, f.fainelli, netdev
In-Reply-To: <1483556184-4176-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Wed, 4 Jan 2017 19:56:24 +0100
> +static inline u64 ether_addr_to_u64(const u8 *addr)
> +{
> + u64 u = 0;
> + int i;
> +
> + for (i = 0; i < ETH_ALEN; i++)
> + u = u << 8 | addr[i];
> +
> + return u;
> +}
...
> +static inline void u64_to_ether_addr(u64 u, u8 *addr)
> +{
> + int i;
> +
> + for (i = ETH_ALEN - 1; i >= 0; i--) {
> + addr[i] = u & 0xff;
> + u = u >> 8;
> + }
> +}
I think these two routines behave differently on big vs little
endian. And I doubt this was your intention.
^ permalink raw reply
* Re: [PATCH] sh_eth: enable RX descriptor word 0 shift on SH7734
From: David Miller @ 2017-01-04 21:12 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <1893574.OD9Leu8Ck8@wasted.cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Wed, 04 Jan 2017 23:10:23 +0300
> The RX descriptor word 0 on SH7734 has the RFS[9:0] field in bits 16-25
> (bits 0-15 usually used for that are occupied by the packet checksum).
> Thus we need to set the 'shift_rd0' field in the SH7734 SoC data...
>
> Fixes: f0e81fecd4f8 ("net: sh_eth: Add support SH7734")
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH repost net-next] dsa: mv88e6xxx: Optimise atu_get
From: Andrew Lunn @ 2017-01-04 21:19 UTC (permalink / raw)
To: David Miller; +Cc: volodymyr.bendiuga, vivien.didelot, f.fainelli, netdev
In-Reply-To: <20170104.161103.175830630875484681.davem@davemloft.net>
On Wed, Jan 04, 2017 at 04:11:03PM -0500, David Miller wrote:
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Wed, 4 Jan 2017 19:56:24 +0100
>
> > +static inline u64 ether_addr_to_u64(const u8 *addr)
> > +{
> > + u64 u = 0;
> > + int i;
> > +
> > + for (i = 0; i < ETH_ALEN; i++)
> > + u = u << 8 | addr[i];
> > +
> > + return u;
> > +}
> ...
> > +static inline void u64_to_ether_addr(u64 u, u8 *addr)
> > +{
> > + int i;
> > +
> > + for (i = ETH_ALEN - 1; i >= 0; i--) {
> > + addr[i] = u & 0xff;
> > + u = u >> 8;
> > + }
> > +}
>
> I think these two routines behave differently on big vs little
> endian. And I doubt this was your intention.
I don't have a big endian system to test on.
I tried to avoid the usual pitfalls. I don't cast a collection of
bytes to a u64, which i know has no chance of working. Accessing a MAC
address as a byte array should be endian safe. The shift operation
should also be endian safe.
What exactly do you think will behave differently?
Andrew
^ permalink raw reply
* Re: [PATCH repost net-next] dsa: mv88e6xxx: Optimise atu_get
From: Florian Fainelli @ 2017-01-04 21:27 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: volodymyr.bendiuga, vivien.didelot, netdev
In-Reply-To: <20170104211957.GD4229@lunn.ch>
On 01/04/2017 01:19 PM, Andrew Lunn wrote:
> On Wed, Jan 04, 2017 at 04:11:03PM -0500, David Miller wrote:
>> From: Andrew Lunn <andrew@lunn.ch>
>> Date: Wed, 4 Jan 2017 19:56:24 +0100
>>
>>> +static inline u64 ether_addr_to_u64(const u8 *addr)
>>> +{
>>> + u64 u = 0;
>>> + int i;
>>> +
>>> + for (i = 0; i < ETH_ALEN; i++)
>>> + u = u << 8 | addr[i];
>>> +
>>> + return u;
>>> +}
>> ...
>>> +static inline void u64_to_ether_addr(u64 u, u8 *addr)
>>> +{
>>> + int i;
>>> +
>>> + for (i = ETH_ALEN - 1; i >= 0; i--) {
>>> + addr[i] = u & 0xff;
>>> + u = u >> 8;
>>> + }
>>> +}
>>
>> I think these two routines behave differently on big vs little
>> endian. And I doubt this was your intention.
>
> I don't have a big endian system to test on.
You could build the driver for e.g: a MIPS Malta board and use the
qemu-system-mips to validate this, there could be a way to do that on
ARM too although it's a different kind of BE (BE8 vs. BE32) AFAIR.
>
> I tried to avoid the usual pitfalls. I don't cast a collection of
> bytes to a u64, which i know has no chance of working. Accessing a MAC
> address as a byte array should be endian safe. The shift operation
> should also be endian safe.
>
> What exactly do you think will behave differently?
>
> Andrew
>
--
Florian
^ permalink raw reply
* Re: [PATCH repost net-next] dsa: mv88e6xxx: Optimise atu_get
From: David Miller @ 2017-01-04 21:27 UTC (permalink / raw)
To: andrew; +Cc: volodymyr.bendiuga, vivien.didelot, f.fainelli, netdev
In-Reply-To: <20170104211957.GD4229@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Wed, 4 Jan 2017 22:19:57 +0100
> On Wed, Jan 04, 2017 at 04:11:03PM -0500, David Miller wrote:
>> From: Andrew Lunn <andrew@lunn.ch>
>> Date: Wed, 4 Jan 2017 19:56:24 +0100
>>
>> > +static inline u64 ether_addr_to_u64(const u8 *addr)
>> > +{
>> > + u64 u = 0;
>> > + int i;
>> > +
>> > + for (i = 0; i < ETH_ALEN; i++)
>> > + u = u << 8 | addr[i];
>> > +
>> > + return u;
>> > +}
>> ...
>> > +static inline void u64_to_ether_addr(u64 u, u8 *addr)
>> > +{
>> > + int i;
>> > +
>> > + for (i = ETH_ALEN - 1; i >= 0; i--) {
>> > + addr[i] = u & 0xff;
>> > + u = u >> 8;
>> > + }
>> > +}
>>
>> I think these two routines behave differently on big vs little
>> endian. And I doubt this was your intention.
>
> I don't have a big endian system to test on.
>
> I tried to avoid the usual pitfalls. I don't cast a collection of
> bytes to a u64, which i know has no chance of working. Accessing a MAC
> address as a byte array should be endian safe. The shift operation
> should also be endian safe.
>
> What exactly do you think will behave differently?
Maybe I over-reacted.
I just ran some test programs in userspace on both little and big
endian and they checked out.
Sorry for the false alarm.
I'll apply this, thanks.
^ permalink raw reply
* [PATCH] sh_eth: R8A7740 supports packet shecksumming
From: Sergei Shtylyov @ 2017-01-04 21:29 UTC (permalink / raw)
To: netdev, linux-renesas-soc
The R8A7740 GEther controller supports the packet checksum offloading
but the 'hw_crc' (bad name, I'll fix it) flag isn't set in the R8A7740
data, thus CSMR isn't cleared...
Fixes: 73a0d907301e ("net: sh_eth: add support R8A7740")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
This patch is against DaveM's 'net.git' repo plus the fixes sent recently...
drivers/net/ethernet/renesas/sh_eth.c | 1 +
1 file changed, 1 insertion(+)
Index: net/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net/drivers/net/ethernet/renesas/sh_eth.c
@@ -574,6 +574,7 @@ static struct sh_eth_cpu_data r8a7740_da
.rpadir_value = 2 << 16,
.no_trimd = 1,
.no_ade = 1,
+ .hw_crc = 1,
.tsu = 1,
.select_mii = 1,
.shift_rd0 = 1,
^ permalink raw reply
* Re: [PATCH net-next 0/6] Prepare BPF for VLAN_TAG_PRESENT cleanup
From: Michał Mirosław @ 2017-01-04 21:30 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, alexei.starovoitov
In-Reply-To: <586D570D.9060800@iogearbox.net>
On Wed, Jan 04, 2017 at 09:11:57PM +0100, Daniel Borkmann wrote:
> On 01/04/2017 02:18 AM, Michał Mirosław wrote:
> > Those patches prepare BPF ant its JITs for removal of VLAN_TAG_PRESENT.
> > The set depends on "Preparation for VLAN_TAG_PRESENT cleanup" patchset.
> >
> > The series is supposed to be bisect-friendly and that requires temporary
> > insertion of #define VLAN_TAG_PRESENT in BPF code to be able to split
> > JIT changes per architecture.
> >
> > Michał Mirosław (6):
> > net/skbuff: add macros for VLAN_PRESENT bit
> > net/bpf_jit: ARM: split VLAN_PRESENT bit handling from VLAN_TCI
> > net/bpf_jit: MIPS: split VLAN_PRESENT bit handling from VLAN_TCI
> > net/bpf_jit: PPC: split VLAN_PRESENT bit handling from VLAN_TCI
> > net/bpf_jit: SPARC: split VLAN_PRESENT bit handling from VLAN_TCI
> > net/bpf: split VLAN_PRESENT bit handling from VLAN_TCI
>
> Please add a proper changelog to all the individual patches, right now
> they have none. Also, how was this runtime tested? Did you run BPF selftest
> suite with them? Seems like they weren't even compile tested properly
> given the kbuild bot barking on sparc ...
Compile bot is barking because it doesn't have patches, which this set depends on.
Sorry about that.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH] phy state machine: failsafe leave invalid RUNNING state
From: Florian Fainelli @ 2017-01-04 21:44 UTC (permalink / raw)
To: Zefir Kurtisi, netdev; +Cc: andrew
In-Reply-To: <8521b51f-04f7-aeef-f862-bb150257cfa4@neratec.com>
On 01/04/2017 08:10 AM, Zefir Kurtisi wrote:
> On 01/04/2017 04:30 PM, Florian Fainelli wrote:
>>
>>
>> On 01/04/2017 07:27 AM, Zefir Kurtisi wrote:
>>> On 01/04/2017 04:13 PM, Florian Fainelli wrote:
>>>>
>>>>
>>>> On 01/04/2017 07:04 AM, Zefir Kurtisi wrote:
>>>>> While in RUNNING state, phy_state_machine() checks for link changes by
>>>>> comparing phydev->link before and after calling phy_read_status().
>>>>> This works as long as it is guaranteed that phydev->link is never
>>>>> changed outside the phy_state_machine().
>>>>>
>>>>> If in some setups this happens, it causes the state machine to miss
>>>>> a link loss and remain RUNNING despite phydev->link being 0.
>>>>>
>>>>> This has been observed running a dsa setup with a process continuously
>>>>> polling the link states over ethtool each second (SNMPD RFC-1213
>>>>> agent). Disconnecting the link on a phy followed by a ETHTOOL_GSET
>>>>> causes dsa_slave_get_settings() / dsa_slave_get_link_ksettings() to
>>>>> call phy_read_status() and with that modify the link status - and
>>>>> with that bricking the phy state machine.
>>>>
>>>> That's the interesting part of the analysis, how does this brick the PHY
>>>> state machine? Is the PHY driver changing the link status in the
>>>> read_status callback that it implements?
>>>>
>>> phydev->read_status points to genphy_read_status(), where the first call goes to
>>> genphy_update_link() which updates the link status.
>>>
>>> Thereafter phy_state_machine():RUNNING won't be able to detect the link loss
>>> anymore unless the link state changes again.
>>>
>>>
>>> I was trying to figure out if there is a rule that forbids changing phydev->link
>>> from outside the state machine, but found several places where it happens (either
>>> directly, or over genphy_read_status() or over genphy_update_link()).
>>>
>>> Curious how this did not show up before, since within the dsa setup it is very
>>> easy to trigger:
>>> a) physically disconnect link
>>> b) within one second run ethtool ethX
>>
>> You need to be more specific here about what "the dsa setup" is, drivers
>> involved, which ports of the switch you are seeing this with (user
>> facing, CPU port, DSA port?) etc.
>>
> I am working on top of LEDE and with that at kernel 4.4.21 - alas I checked the
> related source files and believe the effect should be reproducible with HEAD.
>
> The setup is as follows:
> mv88e6321:
> * ports 0+1 connected to fibre-optics transceivers at fixed 100 Mbps
> * port 4 is CPU port
> * custom phy driver (replacement for marvell.ko) only populated with
> * .config_init to
> * set fixed speed for ports 0+1 (when in FO mode)
> * run genphy_config_init() for all other modes (here: CPU port)
> * .config_aneg=genphy_config_aneg, .read_status=genphy_read_status
>
>
> To my understanding, the exact setup is irrelevant - to reproduce the issue it is
> enough to have a means of running genphy_update_link() (as done in e.g.
> mediatek/mtk_eth_soc.c, dsa/slave.c), or genphy_read_status() (as done in e.g.
> hisilicon/hns/hns_enet.c) or phy_read_status() (as done in e.g.
> ethernet/ti/netcp_ethss.c, ethernet/aeroflex/greth.c, etc.). In the observed
> drivers it is mostly implemented in the ETHTOOL_GSET execution path.
>
> Once you get the link state updated outside the phy state machine, it remains in
> invalid RUNNING. To prevent that invalid state, to my understanding upper layer
> drivers (Ethernet, dsa) must not modify link-states in any case (including calling
> the functions noted above), or we need the proposed fail-safe mechanism to prevent
> getting stuck.
OK, I see the code path involved now, sorry -ENOCOFFEE when I initially
responded. Yes, clearly, we should not be mangling the PHY device's link
by calling genphy_read_status(). At first glance, none of the users
below should be doing what they are doing, but let's kick a separate
patch series to collect feedback from the driver writes.
Thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH repost net-next] dsa: mv88e6xxx: Optimise atu_get
From: Andrew Lunn @ 2017-01-04 21:45 UTC (permalink / raw)
To: David Miller; +Cc: volodymyr.bendiuga, vivien.didelot, f.fainelli, netdev
In-Reply-To: <20170104.162718.86114638722981428.davem@davemloft.net>
> Maybe I over-reacted.
I'm happy somebody other than me is thinking about this.
> I just ran some test programs in userspace on both little and big
> endian and they checked out.
Great, thanks for testing.
Andrew
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2017-01-04 21:45 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) stmmac_drv_probe() can race with stmmac_open() because we register the
netdevice too early. Fix from Florian Fainelli.
2) UFO handling in __ip6_append_data() and ip6_finish_output() use different
tests for deciding whether a frame will be fragmented or not, put them
in sync. Fix from Zheng Li.
3) The rtnetlink getstats handlers need to validate that the netlink
request is large enough, fix from Mathias Krause.
4) Use after free in mlx4 driver, from Jack Morgenstein.
5) Fix setting of garbage UID value in sockets during setattr() calls,
from Eric Biggers.
6) Packet drop_monitor doesn't format the netlink messages properly such
that nlmsg_next fails to work, fix from Reiter Wolfgang.
7) Fix handling of wildcard addresses in l2tp lookups, from Guillaume
Nault.
8) __skb_flow_dissect() can crash on pptp packets, from Ian Kumlien.
9) IGMP code doesn't reset group query timers properly, from Michal
Tesar.
10) Fix overzealous MAIN/LOCAL route table combining in ipv4, from
Alexander Duyck.
11) vxlan offload check needs to be more strict in be2net driver,
from Sabrina Dubroca.
12) Moving l3mdev to packet hooks lost RX stat counters unintentionally,
fix from David Ahern.
Please pull, thanks a lot!
The following changes since commit 8f18e4d03ed8fa5e4a300c94550533bd8ce4ff9a:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2016-12-27 16:04:37 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 71eae1ca77fd6be218d8a952d97bba827e56516d:
sh_eth: enable RX descriptor word 0 shift on SH7734 (2017-01-04 16:12:14 -0500)
----------------------------------------------------------------
Alexander Alemayhu (1):
Documentation/networking: fix typo in mpls-sysctl
Alexander Duyck (1):
ipv4: Do not allow MAIN to be alias for new LOCAL w/ custom rules
Augusto Mecking Caringi (1):
net: atm: Fix warnings in net/atm/lec.c when !CONFIG_PROC_FS
Bartosz Folta (1):
net: macb: Updated resource allocation function calls to new version of API.
Colin Ian King (1):
net: wan: slic_ds26522: fix spelling mistake: "configurated" -> "configured"
Daniel Jurgens (1):
net/mlx5: Cancel recovery work in remove flow
David Ahern (2):
net: ipv4: dst for local input routes should use l3mdev if relevant
net: vrf: Add missing Rx counters
David S. Miller (7):
Merge branch 'mlx5-fixes'
Merge branch 'mlx4-misc-fixes'
Merge branch 'l2tp-socket-lookup-fixes'
Merge tag 'mac80211-for-davem-2017-01-02' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'dwmac-oxnas-leaks'
Merge branch 'systemport-padding-and-TSB-insertion'
Merge branch 'dpaa_eth-fixes'
Edward Cree (1):
sfc: don't report RX hash keys to ethtool when RSS wasn't enabled
Eli Cohen (1):
net/mlx5: Avoid shadowing numa_node
Eric Biggers (1):
net: socket: don't set sk_uid to garbage value in ->setattr()
Eugenia Emantayev (1):
net/mlx4_en: Fix bad WQE issue
Florian Fainelli (4):
net: stmmac: Fix race between stmmac_drv_probe and stmmac_open
net: stmmac: Fix error path after register_netdev move
net: systemport: Utilize skb_put_padto()
net: systemport: Pad packet before inserting TSB
Gal Pressman (2):
Revert "net/mlx5e: Expose PCIe statistics to ethtool"
Revert "net/mlx5: Add MPCNT register infrastructure"
Guillaume Nault (2):
l2tp: consider '::' as wildcard address in l2tp_ip6 socket lookup
l2tp: take remote address into account in l2tp_ip and l2tp_ip6 socket lookups
Huy Nguyen (1):
net/mlx5e: Check ets capability before initializing ets settings
Ian Kumlien (1):
flow_dissector: Update pptp handling to avoid null pointer deref.
Jack Morgenstein (2):
net/mlx4_core: Use-after-free causes a resource leak in flow-steering detach
net/mlx4_core: Fix raw qp flow steering rules under SRIOV
Johan Hovold (3):
net: stmmac: dwmac-oxnas: fix of-node leak
net: stmmac: dwmac-oxnas: fix fixed-link-phydev leaks
net: stmmac: dwmac-oxnas: use generic pm implementation
Johannes Berg (1):
mac80211: initialize fast-xmit 'info' later
Leon Romanovsky (1):
net/mlx4: Remove BUG_ON from ICM allocation routine
Madalin Bucur (1):
dpaa_eth: cleanup after init_phy() failure
Maor Gottlieb (2):
net/mlx5: Mask destination mac value in ethtool steering rules
net/mlx5: Release FTE lock in error flow
Mathias Krause (1):
rtnl: stats - add missing netlink message size checks
Michal Tesar (1):
igmp: Make igmp group member RFC 3376 compliant
Mohamad Haj Yahia (1):
net/mlx5: Prevent setting multicast macs for VFs
Nicolas Pitre (1):
LiquidIO VF: s/select/imply/ for PTP_1588_CLOCK
Noa Osherovich (1):
net/mlx5: Check FW limitations on log_max_qp before setting it
Or Gerlitz (1):
net/mlx5: Disable RoCE on the e-switch management port under switchdev mode
Paul Blakey (1):
net/sched: cls_flower: Fix missing addr_type in classify
Peter Chen (1):
net: usb: asix_devices: add .reset_resume for USB PM
Reiter Wolfgang (2):
drop_monitor: add missing call to genlmsg_end
drop_monitor: consider inserted data in genlmsg_end
Roy Pledge (1):
dpaa_eth: Initialize CGR structure before init
Sabrina Dubroca (1):
benet: stricter vxlan offloading check in be_features_check
Saeed Mahameed (2):
net/mlx5e: Don't sync netdev state when not registered
net/mlx5e: Disable netdev after close
Sergei Shtylyov (2):
sh_eth: fix branch prediction in sh_eth_interrupt()
sh_eth: enable RX descriptor word 0 shift on SH7734
Slava Shwartsman (1):
net/mlx4_en: Fix type mismatch for 32-bit systems
Varun Prakash (1):
libcxgb: fix error check for ip6_route_output()
Wei Zhang (1):
net: fix incorrect original ingress device index in PKTINFO
Zheng Li (1):
ipv6: Should use consistent conditional judgement for ip6 fragment between __ip6_append_data and ip6_finish_output
Documentation/networking/mpls-sysctl.txt | 4 ++--
drivers/infiniband/hw/mlx4/main.c | 14 ++++++++++++--
drivers/net/ethernet/broadcom/bcmsysport.c | 23 +++++++++++------------
drivers/net/ethernet/cadence/macb_pci.c | 27 ++++++++++-----------------
drivers/net/ethernet/cavium/Kconfig | 2 +-
drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.c | 12 +++++-------
drivers/net/ethernet/emulex/benet/be_main.c | 4 +++-
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 6 +++++-
drivers/net/ethernet/mellanox/mlx4/en_clock.c | 8 ++------
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 8 +++++++-
drivers/net/ethernet/mellanox/mlx4/icm.c | 7 ++++++-
drivers/net/ethernet/mellanox/mlx4/main.c | 18 ++++++++++++++++++
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 28 +++++-----------------------
drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 3 +++
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 17 -----------------
drivers/net/ethernet/mellanox/mlx5/core/en_fs_ethtool.c | 1 +
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 51 ++++++++++++++++-----------------------------------
drivers/net/ethernet/mellanox/mlx5/core/en_stats.h | 32 +-------------------------------
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 11 +++++++++++
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 1 +
drivers/net/ethernet/mellanox/mlx5/core/main.c | 15 +++++++++++----
drivers/net/ethernet/renesas/sh_eth.c | 3 ++-
drivers/net/ethernet/sfc/ef10.c | 3 ++-
drivers/net/ethernet/sfc/ethtool.c | 2 ++
drivers/net/ethernet/sfc/net_driver.h | 2 ++
drivers/net/ethernet/sfc/siena.c | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 89 +++++++++++++++++++++++++++++++++--------------------------------------------------------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 23 +++++++++++++----------
drivers/net/usb/asix_devices.c | 1 +
drivers/net/vrf.c | 3 +++
drivers/net/wan/slic_ds26522.c | 2 +-
include/linux/mlx4/device.h | 2 ++
include/linux/mlx5/device.h | 5 -----
include/linux/mlx5/driver.h | 1 -
include/linux/mlx5/mlx5_ifc.h | 93 ---------------------------------------------------------------------------------------------
net/atm/lec.c | 2 ++
net/core/drop_monitor.c | 39 ++++++++++++++++++++++++++++++---------
net/core/flow_dissector.c | 5 +++--
net/core/rtnetlink.c | 6 ++++++
net/ipv4/fib_frontend.c | 2 +-
net/ipv4/igmp.c | 7 ++++++-
net/ipv4/ip_sockglue.c | 8 +++++++-
net/ipv4/route.c | 3 ++-
net/ipv6/ip6_output.c | 2 +-
net/l2tp/l2tp_ip.c | 19 ++++++-------------
net/l2tp/l2tp_ip6.c | 24 ++++++++----------------
net/mac80211/tx.c | 3 ++-
net/sched/cls_flower.c | 4 ++++
net/socket.c | 2 +-
50 files changed, 273 insertions(+), 377 deletions(-)
^ permalink raw reply
* [PATCH net-next] net: dsa: b53: Utilize common helpers for u64/MAC
From: Florian Fainelli @ 2017-01-04 21:53 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, volodymyr.bendiuga,
Florian Fainelli
Utilize the two functions recently introduced: u64_to_ether() and
ether_to_u64() instead of our own versions.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/b53/b53_common.c | 2 +-
drivers/net/dsa/b53/b53_priv.h | 23 ++---------------------
2 files changed, 3 insertions(+), 22 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 947adda3397d..d5370c227043 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1137,7 +1137,7 @@ static int b53_arl_op(struct b53_device *dev, int op, int port,
int ret;
/* Convert the array into a 64-bit MAC */
- mac = b53_mac_to_u64(addr);
+ mac = ether_addr_to_u64(addr);
/* Perform a read for the given MAC and VID */
b53_write48(dev, B53_ARLIO_PAGE, B53_MAC_ADDR_IDX, mac);
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index f192a673caba..d9833540fe26 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -325,25 +325,6 @@ struct b53_arl_entry {
u8 is_static:1;
};
-static inline void b53_mac_from_u64(u64 src, u8 *dst)
-{
- unsigned int i;
-
- for (i = 0; i < ETH_ALEN; i++)
- dst[ETH_ALEN - 1 - i] = (src >> (8 * i)) & 0xff;
-}
-
-static inline u64 b53_mac_to_u64(const u8 *src)
-{
- unsigned int i;
- u64 dst = 0;
-
- for (i = 0; i < ETH_ALEN; i++)
- dst |= (u64)src[ETH_ALEN - 1 - i] << (8 * i);
-
- return dst;
-}
-
static inline void b53_arl_to_entry(struct b53_arl_entry *ent,
u64 mac_vid, u32 fwd_entry)
{
@@ -352,14 +333,14 @@ static inline void b53_arl_to_entry(struct b53_arl_entry *ent,
ent->is_valid = !!(fwd_entry & ARLTBL_VALID);
ent->is_age = !!(fwd_entry & ARLTBL_AGE);
ent->is_static = !!(fwd_entry & ARLTBL_STATIC);
- b53_mac_from_u64(mac_vid, ent->mac);
+ u64_to_ether_addr(mac_vid, ent->mac);
ent->vid = mac_vid >> ARLTBL_VID_S;
}
static inline void b53_arl_from_entry(u64 *mac_vid, u32 *fwd_entry,
const struct b53_arl_entry *ent)
{
- *mac_vid = b53_mac_to_u64(ent->mac);
+ *mac_vid = ether_addr_to_u64(ent->mac);
*mac_vid |= (u64)(ent->vid & ARLTBL_VID_MASK) << ARLTBL_VID_S;
*fwd_entry = ent->port & ARLTBL_DATA_PORT_ID_MASK;
if (ent->is_valid)
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next] net: dsa: b53: Utilize common helpers for u64/MAC
From: Andrew Lunn @ 2017-01-04 22:07 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, davem, vivien.didelot, volodymyr.bendiuga
In-Reply-To: <20170104215320.19293-1-f.fainelli@gmail.com>
On Wed, Jan 04, 2017 at 01:53:20PM -0800, Florian Fainelli wrote:
> Utilize the two functions recently introduced: u64_to_ether() and
> ether_to_u64() instead of our own versions.
:-)
And i expect these have been tested on big endian systems. I never
thought to look if one of the other drivers already had them.
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ 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