* Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically
From: AceLan Kao @ 2017-10-13 1:12 UTC (permalink / raw)
To: Daniel Drake
Cc: Kalle Valo, Christoph Hellwig, QCA ath9k Development,
linux-wireless, netdev, Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <CAFv23QkLJ0m112Y8iAGv+6DyFT52Hqnxq5Fy=ryWTWxu8oTXdw@mail.gmail.com>
Hi Daniel,
After applied the 2 commits you mentioned in the email, ath9k works.
https://marc.info/?l=linux-wireless&m=150631274108016&w=2
https://github.com/endlessm/linux/commit/739c7a924db8f4434a9617657
Best regards,
AceLan Kao.
2017-10-05 14:39 GMT+08:00 AceLan Kao <acelan.kao@canonical.com>:
> Hi all,
>
> Please drop my patches, Qualcomm is working internally and will submit
> the MSI patch by themselves.
> Thanks.
>
> Hi Daniel,
>
> I'll try your patches tomorrow.
>
> Best regards,
> AceLan Kao.
>
> 2017-10-02 12:21 GMT+08:00 Daniel Drake <drake@endlessm.com>:
>> Hi AceLan,
>>
>> On Thu, Sep 28, 2017 at 4:28 PM, AceLan Kao <acelan.kao@canonical.com> wrote:
>>> Hi Daniel,
>>>
>>> I've tried your patch, but it doesn't work for me.
>>> Wifi can scan AP, but can't get connected.
>>
>> Can you please clarify which patch(es) you have tried?
>>
>> This is the base patch which adds the infrastructure to request
>> specific MSI IRQ vectors:
>> https://marc.info/?l=linux-wireless&m=150631274108016&w=2
>>
>> This is the ath9k MSI patch which makes use of that:
>> https://github.com/endlessm/linux/commit/739c7a924db8f4434a9617657
>>
>> If you were already able to use ath9k MSI interrupts without specific
>> consideration for which MSI vector numbers were used, these are the
>> possible explanations that spring to mind:
>>
>> 1. You got lucky and it picked a vector number that is 4-aligned. You
>> can check this in the "lspci -vvv" output. You'll see something like:
>> Capabilities: [50] MSI: Enable+ Count=1/4 Maskable+ 64bit+
>> Address: 00000000fee0300c Data: 4142
>> The lower number is the vector number. In my example here 0x42 (66) is
>> not 4-aligned so the failure condition will be hit.
>>
>> 2. You are using interrupt remapping, which I suspect may provide a
>> high likelihood of MSI interrupt vectors being 4-aligned. See if
>> /proc/interrupts shows the IRQ type as IR-PCI-MSI
>> Unfortunately interrupt remapping is not available here,
>> https://lists.linuxfoundation.org/pipermail/iommu/2017-August/023717.html
>>
>> 3. My assumption that all ath9k hardware corrupts the MSI vector
>> number could wrong. However we've seen this on different wifi modules
>> in laptops produced by different OEMs and ODMs, so it seems to be a
>> somewhat widespread problem at least.
>>
>> 4. My assumption that ath9k hardware is corrupting the MSI vector
>> number could be wrong; maybe another component is to blame, could it
>> be a BIOS issue? Admittedly I don't really know how I can debug the
>> layers inbetween seeing the MSI Message Data value disagree with the
>> vector number being handled inside do_IRQ().
>>
>> Daniel
^ permalink raw reply
* Re: [PATCH] Add -target to clang switch while cross compiling.
From: Alexei Starovoitov @ 2017-10-13 1:14 UTC (permalink / raw)
To: Abhijit Ayarekar; +Cc: ast, daniel, netdev, linux-kernel
In-Reply-To: <1507852723-24677-1-git-send-email-abhijit.ayarekar@caviumnetworks.com>
On Thu, Oct 12, 2017 at 04:58:43PM -0700, Abhijit Ayarekar wrote:
> Update to llvm excludes assembly instructions.
> llvm git revision is below
>
> commit 2865ab6996164e7854d55c9e21c065fad7c26569
> Author: Yonghong Song <yhs@fb.com>
> Date: Mon Sep 18 23:29:36 2017 +0000
>
> bpf: add inline-asm support
>
> Signed-off-by: Yonghong Song <yhs@fb.com>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
>
> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313593 91177308-0d34-0410-b5e6-96231b3b80d8
correct way to reference a commit is
commit 81eb8447daae ("ipv6: take care of rt6_stats")
Also I think git-svn-id link is broken. I'm not sure why llvm keeps
adding it to commits. Kernel's git history doesn't need them.
So just mention llvm commit in kernel's cannonical way and
mention that it will be part of llvm release 6.0
^ permalink raw reply
* Re: [PATCH] tracing: bpf: Hide bpf trace events when they are not used
From: Alexei Starovoitov @ 2017-10-13 1:14 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Alexei Starovoitov, Daniel Borkmann, David S. Miller,
netdev
In-Reply-To: <20171012184002.0661a867@gandalf.local.home>
On Thu, Oct 12, 2017 at 06:40:02PM -0400, Steven Rostedt wrote:
> From: Steven Rostedt (VMware) <rostedt@goodmis.org>
>
> All the trace events defined in include/trace/events/bpf.h are only
> used when CONFIG_BPF_SYSCALL is defined. But this file gets included by
> include/linux/bpf_trace.h which is included by the networking code with
> CREATE_TRACE_POINTS defined.
>
> If a trace event is created but not used it still has data structures
> and functions created for its use, even though nothing is using them.
> To not waste space, do not define the BPF trace events in bpf.h unless
> CONFIG_BPF_SYSCALL is defined.
>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Looks fine.
Acked-by: Alexei Starovoitov <ast@kernel.org>
I'm assuming you want to take it through tracing tree along
with all other cleanups?
^ permalink raw reply
* Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically
From: Daniel Drake @ 2017-10-13 1:17 UTC (permalink / raw)
To: AceLan Kao
Cc: Kalle Valo, Christoph Hellwig, QCA ath9k Development,
linux-wireless, netdev, Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <CAFv23Q=dFRfxXQnY3pu_zV-yK9yaw-t3-Kn2q9YFFuyB9jJMog@mail.gmail.com>
On Fri, Oct 13, 2017 at 9:12 AM, AceLan Kao <acelan.kao@canonical.com> wrote:
> Hi Daniel,
>
> After applied the 2 commits you mentioned in the email, ath9k works.
>
> https://marc.info/?l=linux-wireless&m=150631274108016&w=2
> https://github.com/endlessm/linux/commit/739c7a924db8f4434a9617657
Thanks for testing. However the approach was basically rejected in this thread:
[PATCH] PCI MSI: allow alignment restrictions on vector allocation
https://marc.info/?t=150631283200001&r=1&w=2
So we still need an upstream solution.
I am curious what Qualcomm have to say about their hardware corrupting
the MSI Message Data value. Is there any news on them submitting the
MSI support patch?
Separately we have the option of seeing if Intel can help us unblock
the legacy interrupt (assuming it was simply blocked by the BIOS), or
adding an interrupt-polling fallback path to ath9k.
Daniel
^ permalink raw reply
* Re: [PATCH] tracing: bpf: Hide bpf trace events when they are not used
From: Steven Rostedt @ 2017-10-13 1:35 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: LKML, Alexei Starovoitov, Daniel Borkmann, David S. Miller,
netdev
In-Reply-To: <20171013011450.w2uqygdfzwf7ud64@ast-mbp>
On Thu, 12 Oct 2017 18:14:52 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Thu, Oct 12, 2017 at 06:40:02PM -0400, Steven Rostedt wrote:
> > From: Steven Rostedt (VMware) <rostedt@goodmis.org>
> >
> > All the trace events defined in include/trace/events/bpf.h are only
> > used when CONFIG_BPF_SYSCALL is defined. But this file gets included by
> > include/linux/bpf_trace.h which is included by the networking code with
> > CREATE_TRACE_POINTS defined.
> >
> > If a trace event is created but not used it still has data structures
> > and functions created for its use, even though nothing is using them.
> > To not waste space, do not define the BPF trace events in bpf.h unless
> > CONFIG_BPF_SYSCALL is defined.
> >
> > Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
>
> Looks fine.
> Acked-by: Alexei Starovoitov <ast@kernel.org>
>
> I'm assuming you want to take it through tracing tree along
> with all other cleanups?
Either way is fine. I have a few other ones. I believe Paul is taking
the RCU patch. There's no dependency.
I'll take it if it is easier for you. I just need the ack.
-- Steve
^ permalink raw reply
* Re: [PATCH net-next 1/3] sched: act: ife: move encode/decode check to init
From: Jamal Hadi Salim @ 2017-10-13 1:38 UTC (permalink / raw)
To: Alexander Aring
Cc: xiyou.wangcong, jiri, netdev, eric.dumazet, bjb, Yotam Gigi
In-Reply-To: <20171011211608.22692-2-aring@mojatatu.com>
On 17-10-11 05:16 PM, Alexander Aring wrote:
> This patch adds the check of the two possible ife handlings encode
> and decode to the init callback. The decode value is for usability
> aspect and used in userspace code only. The current code offers encode
> else decode only. This patch avoids any other option than this.
>
> Signed-off-by: Alexander Aring <aring@mojatatu.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] tracing: bpf: Hide bpf trace events when they are not used
From: Alexei Starovoitov @ 2017-10-13 1:38 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Alexei Starovoitov, Daniel Borkmann, David S. Miller,
netdev
In-Reply-To: <20171012213501.17fe6f8c@vmware.local.home>
On Thu, Oct 12, 2017 at 09:35:01PM -0400, Steven Rostedt wrote:
> On Thu, 12 Oct 2017 18:14:52 -0700
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> > On Thu, Oct 12, 2017 at 06:40:02PM -0400, Steven Rostedt wrote:
> > > From: Steven Rostedt (VMware) <rostedt@goodmis.org>
> > >
> > > All the trace events defined in include/trace/events/bpf.h are only
> > > used when CONFIG_BPF_SYSCALL is defined. But this file gets included by
> > > include/linux/bpf_trace.h which is included by the networking code with
> > > CREATE_TRACE_POINTS defined.
> > >
> > > If a trace event is created but not used it still has data structures
> > > and functions created for its use, even though nothing is using them.
> > > To not waste space, do not define the BPF trace events in bpf.h unless
> > > CONFIG_BPF_SYSCALL is defined.
> > >
> > > Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> >
> > Looks fine.
> > Acked-by: Alexei Starovoitov <ast@kernel.org>
> >
> > I'm assuming you want to take it through tracing tree along
> > with all other cleanups?
>
> Either way is fine. I have a few other ones. I believe Paul is taking
> the RCU patch. There's no dependency.
>
> I'll take it if it is easier for you. I just need the ack.
actually just noticed that xdp tracepoints are not covered by ifdef.
They depend on bpf_syscall too. So probably makes sense to wrap
them together.
bpf tracepoints are not being actively worked on whereas xdp tracepoints
keep evolving quickly, so the best is probalby to go via net-next
if you don't mind.
^ permalink raw reply
* Re: [PATCH net-next 2/3] sched: act: ife: migrate to use per-cpu counters
From: Jamal Hadi Salim @ 2017-10-13 1:39 UTC (permalink / raw)
To: Alexander Aring
Cc: xiyou.wangcong, jiri, netdev, eric.dumazet, bjb, Yotam Gigi
In-Reply-To: <20171011211608.22692-3-aring@mojatatu.com>
On 17-10-11 05:16 PM, Alexander Aring wrote:
> This patch migrates the current counter handling which is protected by a
> spinlock to a per-cpu counter handling. This reduce the time where the
> spinlock is being held.
>
> Signed-off-by: Alexander Aring <aring@mojatatu.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next 3/3] sched: act: ife: update parameters via rcu handling
From: Jamal Hadi Salim @ 2017-10-13 1:39 UTC (permalink / raw)
To: Alexander Aring; +Cc: xiyou.wangcong, jiri, netdev, eric.dumazet, bjb
In-Reply-To: <20171011211608.22692-4-aring@mojatatu.com>
On 17-10-11 05:16 PM, Alexander Aring wrote:
> This patch changes the parameter updating via RCU and not protected by a
> spinlock anymore. This reduce the time that the spinlock is being held.
>
> Signed-off-by: Alexander Aring <aring@mojatatu.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* [PATCH net-next v2 0/4] net: dsa: remove .set_addr
From: Vivien Didelot @ 2017-10-13 1:41 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
An Ethernet switch may support having a MAC address, which can be used
as the switch's source address in transmitted full-duplex Pause frames.
If a DSA switch supports the related .set_addr operation, the DSA core
sets the master's MAC address on the switch.
This won't make sense anymore in a multi-CPU ports system, because there
won't be a unique master device assigned to a switch tree.
Moreover this operation is confusing because it makes the user think
that it could be used to program the switch with the MAC address of the
CPU/management port such that MAC address learning can be disabled on
said port, but in fact, that's not how it is currently used.
To fix this, assign a random MAC address at setup time in the mv88e6060
and mv88e6xxx drivers before removing .set_addr completely from DSA.
Changes in v2:
- remove .set_addr implementation from drivers and use a random MAC.
Vivien Didelot (4):
net: dsa: mv88e6xxx: setup random mac address
net: dsa: mv88e6060: setup random mac address
net: dsa: dsa_loop: remove .set_addr
net: dsa: remove .set_addr
drivers/net/dsa/dsa_loop.c | 8 --------
drivers/net/dsa/mv88e6060.c | 30 +++++++++++++++++++-----------
drivers/net/dsa/mv88e6xxx/chip.c | 33 +++++++++++++++++----------------
include/net/dsa.h | 1 -
net/dsa/dsa2.c | 6 ------
net/dsa/legacy.c | 6 ------
6 files changed, 36 insertions(+), 48 deletions(-)
--
2.14.2
^ permalink raw reply
* [PATCH net-next v2 1/4] net: dsa: mv88e6xxx: setup random mac address
From: Vivien Didelot @ 2017-10-13 1:41 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20171013014113.29561-1-vivien.didelot@savoirfairelinux.com>
An Ethernet switch may support having a MAC address, which can be used
as the switch's source address in transmitted full-duplex Pause frames.
If a DSA switch supports the related .set_addr operation, the DSA core
sets the master's MAC address on the switch. This won't make sense
anymore in a multi-CPU ports system, because there won't be a unique
master device assigned to a switch tree.
Instead, setup the switch from within the Marvell driver with a random
MAC address, and remove the .set_addr implementation.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 33 +++++++++++++++++----------------
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index d74c7335c512..76cf383dcf90 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -932,6 +932,19 @@ static int mv88e6xxx_irl_setup(struct mv88e6xxx_chip *chip)
return 0;
}
+static int mv88e6xxx_mac_setup(struct mv88e6xxx_chip *chip)
+{
+ if (chip->info->ops->set_switch_mac) {
+ u8 addr[ETH_ALEN];
+
+ eth_random_addr(addr);
+
+ return chip->info->ops->set_switch_mac(chip, addr);
+ }
+
+ return 0;
+}
+
static int mv88e6xxx_pvt_map(struct mv88e6xxx_chip *chip, int dev, int port)
{
u16 pvlan = 0;
@@ -2013,6 +2026,10 @@ static int mv88e6xxx_setup(struct dsa_switch *ds)
if (err)
goto unlock;
+ err = mv88e6xxx_mac_setup(chip);
+ if (err)
+ goto unlock;
+
err = mv88e6xxx_phy_setup(chip);
if (err)
goto unlock;
@@ -2043,21 +2060,6 @@ static int mv88e6xxx_setup(struct dsa_switch *ds)
return err;
}
-static int mv88e6xxx_set_addr(struct dsa_switch *ds, u8 *addr)
-{
- struct mv88e6xxx_chip *chip = ds->priv;
- int err;
-
- if (!chip->info->ops->set_switch_mac)
- return -EOPNOTSUPP;
-
- mutex_lock(&chip->reg_lock);
- err = chip->info->ops->set_switch_mac(chip, addr);
- mutex_unlock(&chip->reg_lock);
-
- return err;
-}
-
static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
{
struct mv88e6xxx_mdio_bus *mdio_bus = bus->priv;
@@ -3785,7 +3787,6 @@ static const struct dsa_switch_ops mv88e6xxx_switch_ops = {
.probe = mv88e6xxx_drv_probe,
.get_tag_protocol = mv88e6xxx_get_tag_protocol,
.setup = mv88e6xxx_setup,
- .set_addr = mv88e6xxx_set_addr,
.adjust_link = mv88e6xxx_adjust_link,
.get_strings = mv88e6xxx_get_strings,
.get_ethtool_stats = mv88e6xxx_get_ethtool_stats,
--
2.14.2
^ permalink raw reply related
* [PATCH net-next v2 2/4] net: dsa: mv88e6060: setup random mac address
From: Vivien Didelot @ 2017-10-13 1:41 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20171013014113.29561-1-vivien.didelot@savoirfairelinux.com>
As for mv88e6xxx, setup the switch from within the mv88e6060 driver with
a random MAC address, and remove the .set_addr implementation.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/mv88e6060.c | 30 +++++++++++++++++++-----------
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/net/dsa/mv88e6060.c b/drivers/net/dsa/mv88e6060.c
index 621cdc46ad81..2f9d5e6a0f97 100644
--- a/drivers/net/dsa/mv88e6060.c
+++ b/drivers/net/dsa/mv88e6060.c
@@ -9,6 +9,7 @@
*/
#include <linux/delay.h>
+#include <linux/etherdevice.h>
#include <linux/jiffies.h>
#include <linux/list.h>
#include <linux/module.h>
@@ -188,6 +189,20 @@ static int mv88e6060_setup_port(struct dsa_switch *ds, int p)
return 0;
}
+static int mv88e6060_setup_addr(struct dsa_switch *ds)
+{
+ u8 addr[ETH_ALEN];
+
+ eth_random_addr(addr);
+
+ /* Use the same MAC Address as FD Pause frames for all ports */
+ REG_WRITE(REG_GLOBAL, GLOBAL_MAC_01, (addr[0] << 9) | addr[1]);
+ REG_WRITE(REG_GLOBAL, GLOBAL_MAC_23, (addr[2] << 8) | addr[3]);
+ REG_WRITE(REG_GLOBAL, GLOBAL_MAC_45, (addr[4] << 8) | addr[5]);
+
+ return 0;
+}
+
static int mv88e6060_setup(struct dsa_switch *ds)
{
int ret;
@@ -203,6 +218,10 @@ static int mv88e6060_setup(struct dsa_switch *ds)
if (ret < 0)
return ret;
+ ret = mv88e6060_setup_addr(ds);
+ if (ret < 0)
+ return ret;
+
for (i = 0; i < MV88E6060_PORTS; i++) {
ret = mv88e6060_setup_port(ds, i);
if (ret < 0)
@@ -212,16 +231,6 @@ static int mv88e6060_setup(struct dsa_switch *ds)
return 0;
}
-static int mv88e6060_set_addr(struct dsa_switch *ds, u8 *addr)
-{
- /* Use the same MAC Address as FD Pause frames for all ports */
- REG_WRITE(REG_GLOBAL, GLOBAL_MAC_01, (addr[0] << 9) | addr[1]);
- REG_WRITE(REG_GLOBAL, GLOBAL_MAC_23, (addr[2] << 8) | addr[3]);
- REG_WRITE(REG_GLOBAL, GLOBAL_MAC_45, (addr[4] << 8) | addr[5]);
-
- return 0;
-}
-
static int mv88e6060_port_to_phy_addr(int port)
{
if (port >= 0 && port < MV88E6060_PORTS)
@@ -256,7 +265,6 @@ static const struct dsa_switch_ops mv88e6060_switch_ops = {
.get_tag_protocol = mv88e6060_get_tag_protocol,
.probe = mv88e6060_drv_probe,
.setup = mv88e6060_setup,
- .set_addr = mv88e6060_set_addr,
.phy_read = mv88e6060_phy_read,
.phy_write = mv88e6060_phy_write,
};
--
2.14.2
^ permalink raw reply related
* [PATCH net-next v2 3/4] net: dsa: dsa_loop: remove .set_addr
From: Vivien Didelot @ 2017-10-13 1:41 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20171013014113.29561-1-vivien.didelot@savoirfairelinux.com>
The .set_addr function does nothing, remove the dsa_loop implementation
before getting rid of it completely in DSA.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
drivers/net/dsa/dsa_loop.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
index d55051abf4ed..3a3f4f7ba364 100644
--- a/drivers/net/dsa/dsa_loop.c
+++ b/drivers/net/dsa/dsa_loop.c
@@ -110,13 +110,6 @@ static void dsa_loop_get_ethtool_stats(struct dsa_switch *ds, int port,
data[i] = ps->ports[port].mib[i].val;
}
-static int dsa_loop_set_addr(struct dsa_switch *ds, u8 *addr)
-{
- dev_dbg(ds->dev, "%s\n", __func__);
-
- return 0;
-}
-
static int dsa_loop_phy_read(struct dsa_switch *ds, int port, int regnum)
{
struct dsa_loop_priv *ps = ds->priv;
@@ -263,7 +256,6 @@ static const struct dsa_switch_ops dsa_loop_driver = {
.get_strings = dsa_loop_get_strings,
.get_ethtool_stats = dsa_loop_get_ethtool_stats,
.get_sset_count = dsa_loop_get_sset_count,
- .set_addr = dsa_loop_set_addr,
.phy_read = dsa_loop_phy_read,
.phy_write = dsa_loop_phy_write,
.port_bridge_join = dsa_loop_port_bridge_join,
--
2.14.2
^ permalink raw reply related
* [PATCH net-next v2 4/4] net: dsa: remove .set_addr
From: Vivien Didelot @ 2017-10-13 1:41 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Vivien Didelot
In-Reply-To: <20171013014113.29561-1-vivien.didelot@savoirfairelinux.com>
Now that there is no user for the .set_addr function, remove it from
DSA. If a switch supports this feature (like mv88e6xxx), the
implementation can be done in the driver setup.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
include/net/dsa.h | 1 -
net/dsa/dsa2.c | 6 ------
net/dsa/legacy.c | 6 ------
3 files changed, 13 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index ce1d622734d7..2746741f74cf 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -291,7 +291,6 @@ struct dsa_switch_ops {
enum dsa_tag_protocol (*get_tag_protocol)(struct dsa_switch *ds);
int (*setup)(struct dsa_switch *ds);
- int (*set_addr)(struct dsa_switch *ds, u8 *addr);
u32 (*get_phy_flags)(struct dsa_switch *ds, int port);
/*
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 54ed054777bd..6ac9e11d385c 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -336,12 +336,6 @@ static int dsa_ds_apply(struct dsa_switch_tree *dst, struct dsa_switch *ds)
if (err)
return err;
- if (ds->ops->set_addr) {
- err = ds->ops->set_addr(ds, dst->cpu_dp->netdev->dev_addr);
- if (err < 0)
- return err;
- }
-
if (!ds->slave_mii_bus && ds->ops->phy_read) {
ds->slave_mii_bus = devm_mdiobus_alloc(ds->dev);
if (!ds->slave_mii_bus)
diff --git a/net/dsa/legacy.c b/net/dsa/legacy.c
index 19ff6e0a21dc..b0fefbffe082 100644
--- a/net/dsa/legacy.c
+++ b/net/dsa/legacy.c
@@ -172,12 +172,6 @@ static int dsa_switch_setup_one(struct dsa_switch *ds,
if (ret)
return ret;
- if (ops->set_addr) {
- ret = ops->set_addr(ds, master->dev_addr);
- if (ret < 0)
- return ret;
- }
-
if (!ds->slave_mii_bus && ops->phy_read) {
ds->slave_mii_bus = devm_mdiobus_alloc(ds->dev);
if (!ds->slave_mii_bus)
--
2.14.2
^ permalink raw reply related
* Re: [PATCH] tracing: bpf: Hide bpf trace events when they are not used
From: Steven Rostedt @ 2017-10-13 1:49 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: LKML, Alexei Starovoitov, Daniel Borkmann, David S. Miller,
netdev
In-Reply-To: <20171013013834.pxh3ancgutrm6m7t@ast-mbp>
On Thu, 12 Oct 2017 18:38:36 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> actually just noticed that xdp tracepoints are not covered by ifdef.
> They depend on bpf_syscall too. So probably makes sense to wrap
> them together.
> bpf tracepoints are not being actively worked on whereas xdp tracepoints
> keep evolving quickly, so the best is probalby to go via net-next
> if you don't mind.
Hmm, they didn't trigger a warning, with the exception of
trace_xdp_redirect_map. I have code to check if tracepoints are used or
not, and it appears that the xdp can be used without BPF_SYSCALL.
I don't think they should be wrapped together until we know why they
are used. I can still take this patch and just not touch the xdp ones.
Note, my kernel was using trace_xdp_redirect_map_err,
trace_xdp_redirect_err, trace_xdp_redirect and trace_xdp_exception.
As they did appear.
-- Steve
^ permalink raw reply
* Re: [PATCH net-next v2 1/1] bridge: return error code when deleting Vlan
From: Jamal Hadi Salim @ 2017-10-13 2:03 UTC (permalink / raw)
To: Nikolay Aleksandrov, Roman Mashak, David Ahern
Cc: David Miller, Stephen Hemminger, Linux Kernel Network Developers
In-Reply-To: <e4611694-4248-e796-5cca-24f3d07e0e9e@cumulusnetworks.com>
On 17-10-12 02:12 PM, Nikolay Aleksandrov wrote:
> On 12/10/17 21:07, Roman Mashak wrote:
>> For example, if you attempt to delete a non-existing vlan on a port,
>> the current code succeeds and also sends event :
>>
>> rtnetlink_rcv_msg
>> rtnl_bridge_dellink
>> br_dellink
>> br_afspec
>> br_vlan_info
>>
>> int br_dellink(..)
>> {
>> ...
>> err = br_afspec()
>> if (err == 0)
>> br_ifinfo_notify(RTM_NEWLINK, p);
>> }
>>
>> This is misleading, so a proper errcode has to be produced.
>>
>
> True, but you also change the expected behaviour because now a user can
> clear all vlans with one request (1 - 4094), and after the change that
> will fail with a partial delete if some vlan was missing.
>
The issue is more subtle (per Roman above):
Try to delete a vlan (that doesnt exist).
1) It says "success".
2) Worse: Another process listening (bridge monitor?) gets an _event_
that the vlan has been deleted (when it never existed in the first
place).
> This has been the behaviour forever and some script might depend on it.
> Also IMO, and as David also mentioned, doing a partial delete is not good.
>
I think this is a bug (especially the event part).
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next 0/2] Add mqprio hardware offload support in hns3 driver
From: Yunsheng Lin @ 2017-10-13 2:07 UTC (permalink / raw)
To: Yuval Mintz, davem@davemloft.net
Cc: huangdaode@hisilicon.com, xuwei5@hisilicon.com,
liguozhu@hisilicon.com, Yisen.Zhuang@huawei.com,
gabriele.paoloni@huawei.com, john.garry@huawei.com,
linuxarm@huawei.com, salil.mehta@huawei.com, lipeng321@huawei.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <AM0PR0502MB36837A27C3EAA2A08590D709BF4B0@AM0PR0502MB3683.eurprd05.prod.outlook.com>
Hi, Yuval
On 2017/10/13 4:21, Yuval Mintz wrote:
>> This patchset adds a new hardware offload type in mqprio before adding
>> mqprio hardware offload support in hns3 driver.
>
> I think one of the biggest issues in tying this to DCB configuration is the
> non-immediate [and possibly non persistent] configuration.
>
> Scenario #1:
> User is configuring mqprio offloaded with 3 TCs while device is in willing mode.
> Would you expect the driver to immediately respond with a success or instead
> delay the return until the DCBx negotiation is complete and the operational
> num of TCs is actually 3?
Well, when user requsts the mqprio offloaded by a hardware shared by DCB, I expect
the user is not using the dcb tool.
If user is still using dcb tool, then result is undefined.
The scenario you mention maybe can be enforced by setting willing to zero when user
is requesting the mqprio offload, and restore the willing bit when unloaded the mqprio
offload.
But I think the real issue is that dcb and mqprio shares the tc system in the stack,
the problem may be better to be fixed in the stack rather than in the driver, as you
suggested in the DCB patchset. What do you think?
>
> Scenario #2:
> Assume user explicitly offloaded mqprio with 3 TCs, but now DCB configuration
> has changed on the peer side and 4 TCs is the new negotiated operational value.
> Your current driver logic would change the number of TCs underneath the user
> configuration [and it would actually probably work due to mqprio being a crappy
> qdisc]. But was that the user actual intention?
> [I think the likely answer in this scenario is 'yes' since the alternative is no better.
> But I still thought it was worth mentioning]
You are right, the problem also have something to do with mqprio and dcb sharing
the tc in the stack.
Druing testing, when user explicitly offloaded mqprio with 3 TCs, all
queue has a default pfifo mqprio attached, after DCB changes the tc num to 4,
using tc qdisc shows some queue does not have a default pfifo mqprio attached.
Maybe we can add a callback to notify mqprio the configuration has changed.
Thanks
Yunsheng Lin
>
> Cheers,
> Yuval
>
>>
>> Yunsheng Lin (2):
>> mqprio: Add a new hardware offload type in mqprio
>> net: hns3: Add mqprio hardware offload support in hns3 driver
>>
>> drivers/net/ethernet/hisilicon/hns3/hnae3.h | 1 +
>> .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 23 +++++++++++
>> .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 46 ++++++++++++++-
>> -------
>> include/uapi/linux/pkt_sched.h | 1 +
>> 4 files changed, 55 insertions(+), 16 deletions(-)
>>
>> --
>> 1.9.1
>
>
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] mqprio: Add a new hardware offload type in mqprio
From: Yunsheng Lin @ 2017-10-13 2:12 UTC (permalink / raw)
To: Yuval Mintz, davem@davemloft.net
Cc: huangdaode@hisilicon.com, xuwei5@hisilicon.com,
liguozhu@hisilicon.com, Yisen.Zhuang@huawei.com,
gabriele.paoloni@huawei.com, john.garry@huawei.com,
linuxarm@huawei.com, salil.mehta@huawei.com, lipeng321@huawei.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <AM0PR0502MB3683208C0F411F67C70BF6B1BF4B0@AM0PR0502MB3683.eurprd05.prod.outlook.com>
Hi, Yuval
On 2017/10/13 4:10, Yuval Mintz wrote:
>> When a driver supports both dcb and hardware offloaded mqprio, and
>> user is running mqprio and dcb tool concurrently, the configuration
>> set by each tool may be conflicted with each other because the dcb
> (for second 'each') s/each/the
>
Will do, Thanks
>> and mqprio may be using the same hardwere offload component and share
> s/hardwere/hardware
Will do, Thanks
>
>> the tc system in the network stack.
>>
>> This patch adds a new offload type to indicate that the underlying
>> driver offload prio mapping as part of DCB. If the driver would be
> 'should' offload
Will do, Thanks
>
>> incapable of that it would refuse the offload. User would then have
>> to explicitly request that qdisc offload.
>
>
>
^ permalink raw reply
* Re: [PATCH net-next v2 1/1] bridge: return error code when deleting Vlan
From: Nikolay Aleksandrov @ 2017-10-13 2:15 UTC (permalink / raw)
To: Jamal Hadi Salim, Roman Mashak, David Ahern
Cc: David Miller, Stephen Hemminger, Linux Kernel Network Developers
In-Reply-To: <64292550-f043-c1f7-5b0e-004288832887@mojatatu.com>
On 13.10.2017 05:03, Jamal Hadi Salim wrote:
> On 17-10-12 02:12 PM, Nikolay Aleksandrov wrote:
>> On 12/10/17 21:07, Roman Mashak wrote:
>
>>> For example, if you attempt to delete a non-existing vlan on a port,
>>> the current code succeeds and also sends event :
>>>
>>> rtnetlink_rcv_msg
>>> rtnl_bridge_dellink
>>> br_dellink
>>> br_afspec
>>> br_vlan_info
>>>
>>> int br_dellink(..)
>>> {
>>> ...
>>> err = br_afspec()
>>> if (err == 0)
>>> br_ifinfo_notify(RTM_NEWLINK, p);
>>> }
>>>
>>> This is misleading, so a proper errcode has to be produced.
>>>
>>
>
>
>
>> True, but you also change the expected behaviour because now a user can
>> clear all vlans with one request (1 - 4094), and after the change that
>> will fail with a partial delete if some vlan was missing.
>>
>
> The issue is more subtle (per Roman above):
> Try to delete a vlan (that doesnt exist).
> 1) It says "success".
> 2) Worse: Another process listening (bridge monitor?) gets an _event_
> that the vlan has been deleted (when it never existed in the first
> place).
>
>> This has been the behaviour forever and some script might depend on it.
>> Also IMO, and as David also mentioned, doing a partial delete is not
>> good.
>>
>
> I think this is a bug (especially the event part).
>
> cheers,
> jamal
>
Fair enough, but after the patch you get the opposite effect too - you
delete a couple of vlans but you don't generate an event because of an
error in the middle. That at least can be taken care of.
I do agree it's a bug, but there might be scripts that rely on it and
don't check the return value when clearing vlans. They will end up with
a partial clear and wrongly assumed state, so maybe leave the
opportunistic delete but count if anything was actually deleted and send
an event only then ?
That should make everyone happy :-)
^ permalink raw reply
* linux-next: build failure after merge of the akpm-current tree
From: Mark Brown @ 2017-10-13 2:38 UTC (permalink / raw)
To: Andrew Morton, Jakub Kicinski, Simon Horman, David S. Miller
Cc: netdev, Linux-Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 808 bytes --]
Hi Andrew,
After merging the akpm-current tree, today's linux-next build
(x86 allmodconfig) failed like this:
CC [M] drivers/net/ethernet/netronome/nfp/nfp_app.o
In file included from /home/broonie/tmpfs/next/drivers/net/ethernet/netronome/nfp/nfp_asm.c:40:0:
/home/broonie/tmpfs/next/drivers/net/ethernet/netronome/nfp/nfp_asm.h: In function '__enc_swreg_lm':
/home/broonie/tmpfs/next/drivers/net/ethernet/netronome/nfp/nfp_asm.h:301:2: error: implicit declaration of function 'WARN_ON' [-Werror=implicit-function-declaration]
WARN_ON(id > 3 || (off && mode != NN_LM_MOD_NONE));
^
cc1: some warnings being treated as errors
Caused by some reliance on an implicit include being exposed by a header
reorganization in your tree. I'll add a patch for this which I'll post,
probably tomorrow morning.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [next-queue PATCH v7 4/6] net/sched: Introduce Credit Based Shaper (CBS) qdisc
From: Eric Dumazet @ 2017-10-13 2:42 UTC (permalink / raw)
To: Vinicius Costa Gomes
Cc: netdev, intel-wired-lan, jhs, xiyou.wangcong, jiri, andre.guedes,
ivan.briano, jesus.sanchez-palencia, boon.leong.ong,
richardcochran, henrik, levipearson, rodney.cummings
In-Reply-To: <20171013004005.17416-5-vinicius.gomes@intel.com>
On Thu, 2017-10-12 at 17:40 -0700, Vinicius Costa Gomes wrote:
> This queueing discipline implements the shaper algorithm defined by
> the 802.1Q-2014 Section 8.6.8.2 and detailed in Annex L.
>
> It's primary usage is to apply some bandwidth reservation to user
> defined traffic classes, which are mapped to different queues via the
> mqprio qdisc.
>
> Only a simple software implementation is added for now.
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> Signed-off-by: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
> ---
> +/* timediff is in ns, slope is in kbps */
> +static s64 timediff_to_credits(s64 timediff, s32 slope)
> +{
> + s64 credits = timediff * slope * BYTES_PER_KBIT;
> +
> + do_div(credits, NSEC_PER_SEC);
> +
> + return credits;
> +}
> +
> +static s64 delay_from_credits(s64 credits, s32 slope)
> +{
> + s64 rate = slope * BYTES_PER_KBIT;
> + s64 delay;
> +
> + if (unlikely(rate == 0))
> + return S64_MAX;
> +
> + delay = -credits * NSEC_PER_SEC;
> + do_div(delay, rate);
> +
> + return delay;
> +}
> +
> +static s64 credits_from_len(unsigned int len, s32 slope, s64 port_rate)
> +{
> + /* As do_div() only works on unsigned quantities, convert
> + * slope to a positive number here, and credits to a negative
> + * number before returning.
> + */
> + s64 rate = -slope * BYTES_PER_KBIT;
> + s64 credits;
> +
> + if (unlikely(port_rate == 0))
> + return S64_MAX;
> +
> + credits = len * rate;
> + do_div(credits, port_rate);
> +
> + return -credits;
> +}
> +
Your mixing of s64 and u64 is disturbing.
do_div() handles u64, not s64.
div64_s64() might be needed in place of do_div()
^ permalink raw reply
* [PATCH] nfp: Explicitly include linux/bug.h
From: Mark Brown @ 2017-10-13 2:50 UTC (permalink / raw)
To: davem, Jakub Kicinski, Simon Horman; +Cc: oss-drivers, netdev, Mark Brown
Today's -next build encountered an error due to a missing definition of
WARN_ON(), caused by some header reorganization removing an implicit
inclusion of linux/bug.h. Fix this with an explicit inclusion.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/net/ethernet/netronome/nfp/nfp_app.c | 1 +
drivers/net/ethernet/netronome/nfp/nfp_asm.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_app.c b/drivers/net/ethernet/netronome/nfp/nfp_app.c
index 82c290763529..5d9e2eba5b49 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_app.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_app.c
@@ -31,6 +31,7 @@
* SOFTWARE.
*/
+#include <linux/bug.h>
#include <linux/skbuff.h>
#include <linux/slab.h>
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_asm.h b/drivers/net/ethernet/netronome/nfp/nfp_asm.h
index c4c18dd5630a..aa397bf308e4 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_asm.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_asm.h
@@ -35,6 +35,7 @@
#define __NFP_ASM_H__ 1
#include <linux/bitfield.h>
+#include <linux/bug.h>
#include <linux/types.h>
#define REG_NONE 0
--
2.14.1
^ permalink raw reply related
* Re: [PATCH] nfp: Explicitly include linux/bug.h
From: Jakub Kicinski @ 2017-10-13 3:16 UTC (permalink / raw)
To: Mark Brown; +Cc: davem, Simon Horman, oss-drivers, netdev
In-Reply-To: <20171013025035.4450-1-broonie@kernel.org>
On Fri, 13 Oct 2017 03:50:35 +0100, Mark Brown wrote:
> Today's -next build encountered an error due to a missing definition of
> WARN_ON(), caused by some header reorganization removing an implicit
> inclusion of linux/bug.h. Fix this with an explicit inclusion.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Thank you!
^ permalink raw reply
* [PATCH v3] net: ftgmac100: Request clock and set speed
From: Joel Stanley @ 2017-10-13 4:16 UTC (permalink / raw)
To: David S . Miller, Benjamin Herrenschmidt
Cc: netdev, linux-kernel, Andrew Jeffery
According to the ASPEED datasheet, gigabit speeds require a clock of
100MHz or higher. Other speeds require 25MHz or higher. This patch
configures a 100MHz clock if the system has a direct-attached
PHY, or 25MHz if the system is running NC-SI which is limited to 100MHz.
There appear to be no other upstream users of the FTGMAC100 driver it is
hard to know the clocking requirements of other platforms. Therefore a
conservative approach was taken with enabling clocks. If the platform is
not ASPEED, both requesting the clock and configuring the speed is
skipped.
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
Andrew, can you please give this one a spin on hardware?
v3:
- Fix errors from v2
v2:
- only touch the clocks on Aspeed platforms
- unconditionally call clk_unprepare_disable
drivers/net/ethernet/faraday/ftgmac100.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
index 9ed8e4b81530..78db8e62a83f 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -21,6 +21,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include <linux/clk.h>
#include <linux/dma-mapping.h>
#include <linux/etherdevice.h>
#include <linux/ethtool.h>
@@ -59,6 +60,9 @@
/* Min number of tx ring entries before stopping queue */
#define TX_THRESHOLD (MAX_SKB_FRAGS + 1)
+#define FTGMAC_100MHZ 100000000
+#define FTGMAC_25MHZ 25000000
+
struct ftgmac100 {
/* Registers */
struct resource *res;
@@ -96,6 +100,7 @@ struct ftgmac100 {
struct napi_struct napi;
struct work_struct reset_task;
struct mii_bus *mii_bus;
+ struct clk *clk;
/* Link management */
int cur_speed;
@@ -1734,6 +1739,22 @@ static void ftgmac100_ncsi_handler(struct ncsi_dev *nd)
nd->link_up ? "up" : "down");
}
+static void ftgmac100_setup_clk(struct ftgmac100 *priv)
+{
+ priv->clk = devm_clk_get(priv->dev, NULL);
+ if (IS_ERR(priv->clk))
+ return;
+
+ clk_prepare_enable(priv->clk);
+
+ /* Aspeed specifies a 100MHz clock is required for up to
+ * 1000Mbit link speeds. As NCSI is limited to 100Mbit, 25MHz
+ * is sufficient
+ */
+ clk_set_rate(priv->clk, priv->use_ncsi ? FTGMAC_25MHZ :
+ FTGMAC_100MHZ);
+}
+
static int ftgmac100_probe(struct platform_device *pdev)
{
struct resource *res;
@@ -1830,6 +1851,9 @@ static int ftgmac100_probe(struct platform_device *pdev)
goto err_setup_mdio;
}
+ if (priv->is_aspeed)
+ ftgmac100_setup_clk(priv);
+
/* Default ring sizes */
priv->rx_q_entries = priv->new_rx_q_entries = DEF_RX_QUEUE_ENTRIES;
priv->tx_q_entries = priv->new_tx_q_entries = DEF_TX_QUEUE_ENTRIES;
@@ -1883,6 +1907,8 @@ static int ftgmac100_remove(struct platform_device *pdev)
unregister_netdev(netdev);
+ clk_disable_unprepare(priv->clk);
+
/* There's a small chance the reset task will have been re-queued,
* during stop, make sure it's gone before we free the structure.
*/
--
2.14.1
^ permalink raw reply related
* Waiting for your response to my numerous un-replied emails to you concerning your family inheritance fund ($7.5 million dollars). I seek your assistance and I assured of your capability to champion this business opportunity to remit $7.5 million dollars into your account, if you are interested let me know so that I can send you the details of this transaction. I agreed that 55% of this money will be for you 5% will be set aside for expenses incurred during the business and 40% would be for me. And if you are not willing to handle the transaction don’t border to reply me.
From: Enu Ofe @ 2017-10-13 4:23 UTC (permalink / raw)
^ 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