* [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
* 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:24 UTC (permalink / raw)
^ permalink raw reply
* Re: [PATCH net-next 0/2] Fix IFE meta modules loading
From: David Miller @ 2017-10-13 5:13 UTC (permalink / raw)
To: mrv; +Cc: netdev, jhs
In-Reply-To: <85lgkgw19o.fsf@mojatatu.com>
From: Roman Mashak <mrv@mojatatu.com>
Date: Thu, 12 Oct 2017 16:37:39 -0400
> David Miller <davem@davemloft.net> writes:
>
>> From: Roman Mashak <mrv@mojatatu.com>
>> Date: Wed, 11 Oct 2017 10:50:28 -0400
>>
>>> Adjust module alias names of IFE meta modules and fix the bug that
>>> prevented auto-loading IFE modules in run-time.
>>
>> Anyone using the existing alises will be broken by these changes
>> no?
>
> Actually aliases never worked, the bug existed since the day act_meta_*
> modules have been introduced. I suspect everyone compiles them in-kernel
> rather then as modules.
Fair enough, series applied, thanks for explaining.
^ permalink raw reply
* Re: [PATCH net-next 0/3] sched: act: ife: UAPI checks and performance tweaks
From: David Miller @ 2017-10-13 5:23 UTC (permalink / raw)
To: aring; +Cc: jhs, xiyou.wangcong, jiri, netdev, eric.dumazet, bjb
In-Reply-To: <20171011211608.22692-1-aring@mojatatu.com>
From: Alexander Aring <aring@mojatatu.com>
Date: Wed, 11 Oct 2017 17:16:05 -0400
> this patch series contains at first a patch which adds a check for
> IFE_ENCODE and IFE_DECODE when a ife act gets created or updated and adding
> handling of these cases only inside the act callback only.
>
> The second patch use per-cpu counters and move the spinlock around so that
> the spinlock is less being held in act callback.
>
> The last patch use rcu for update parameters and also move the spinlock for
> the same purpose as in patch 2.
>
> Notes:
> - There is still a spinlock around for protecting the metalist and a
> rw-lock for another list. Should be migrated to a rcu list, ife
> possible.
>
> - I use still dereference in dump callback, so I think what I didn't
> got was what happened when rcu_assign_pointer will do when rcu read
> lock is held. I suppose the pointer will be updated, then we don't
> have any issue here.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next 0/4] tc-testing: Test suite updates
From: David Miller @ 2017-10-13 5:31 UTC (permalink / raw)
To: lucasb; +Cc: netdev, xiyou.wangcong, jiri, jhs, aring, mrv
In-Reply-To: <1507756614-30333-1-git-send-email-lucasb@mojatatu.com>
From: Lucas Bates <lucasb@mojatatu.com>
Date: Wed, 11 Oct 2017 17:16:50 -0400
> This patch series is a roundup of changes to the tc-testing
> suite:
>
> - Add test cases for police and mirred modules and some coverage
> in already-submitted test categories
> - Break the test case files down into more user-friendly sizes
> - Bug fix to the tdc.py script's handling of the -l argument
Some of the newly added files lack final newlines, and as you can
see in the git patch output a warning is generated.
Please fix this up and resubmit.
Thanks.
^ permalink raw reply
* Re: [PATCH next] ipvlan: always use the current L2 addr of the master
From: David Miller @ 2017-10-13 5:54 UTC (permalink / raw)
To: mahesh; +Cc: netdev, edumazet, maheshb
In-Reply-To: <20171012001626.3255-1-mahesh@bandewar.net>
From: Mahesh Bandewar <mahesh@bandewar.net>
Date: Wed, 11 Oct 2017 17:16:26 -0700
> From: Mahesh Bandewar <maheshb@google.com>
>
> If the underlying master ever changes its L2 (e.g. bonding device),
> then make sure that the IPvlan slaves always emit packets with the
> current L2 of the master instead of the stale mac addr which was
> copied during the device creation. The problem can be seen with
> following script -
>
> #!/bin/bash
> # Create a vEth pair
> ip link add dev veth0 type veth peer name veth1
> ip link set veth0 up
> ip link set veth1 up
> ip link show veth0
> ip link show veth1
> # Create an IPvlan device on one end of this vEth pair.
> ip link add link veth0 dev ipvl0 type ipvlan mode l2
> ip link show ipvl0
> # Change the mac-address of the vEth master.
> ip link set veth0 address 02:11:22:33:44:55
>
> Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.")
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ip: update policy routing config help
From: David Miller @ 2017-10-13 5:57 UTC (permalink / raw)
To: stephen; +Cc: netdev, sthemmin
In-Reply-To: <20171012031031.8415-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Wed, 11 Oct 2017 20:10:31 -0700
> The kernel config help for policy routing was still pointing at
> an ancient document from 2000 that refers to Linux 2.1. Update it
> to point to something that is at least occasionally updated.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] net: support bgmac with B50212E B1 PHY
From: David Miller @ 2017-10-13 5:59 UTC (permalink / raw)
To: zajec5
Cc: netdev, andrew, f.fainelli, hauke, jon.mason, steven.lin1,
tklauser, bcm-kernel-feedback-list, rafal
In-Reply-To: <20171012082126.30660-1-zajec5@gmail.com>
From: Rafał Miłecki <zajec5@gmail.com>
Date: Thu, 12 Oct 2017 10:21:24 +0200
> From: Rafał Miłecki <rafal@milecki.pl>
>
> I got a report that a board with BCM47189 SoC and B50212E B1 PHY doesn't
> work well some devices as there is massive ping loss. After analyzing
> PHY state it has appeared that is runs in slave mode and doesn't auto
> switch to master properly when needed.
>
> This patchset fixes this by:
> 1) Adding new flag support to the PHY driver for setting master mode
> 2) Modifying bgmac to request master mode for reported hardware
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] ravb: Consolidate clock handling
From: David Miller @ 2017-10-13 6:01 UTC (permalink / raw)
To: geert+renesas
Cc: sergei.shtylyov, horms+renesas, niklas.soderlund+renesas, netdev,
linux-renesas-soc
In-Reply-To: <1507796693-14268-1-git-send-email-geert+renesas@glider.be>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Thu, 12 Oct 2017 10:24:53 +0200
> The module clock is used for two purposes:
> - Wake-on-LAN (WoL), which is optional,
> - gPTP Timer Increment (GTI) configuration, which is mandatory.
>
> As the clock is needed for GTI configuration anyway, WoL is always
> available. Hence remove duplication and repeated obtaining of the clock
> by making GTI use the stored clock for WoL use.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/8] cxgb4: add support to get hardware debug logs via ethtool
From: David Miller @ 2017-10-13 6:04 UTC (permalink / raw)
To: rahul.lakkireddy; +Cc: netdev, ganeshgr, nirranjan, indranil
In-Reply-To: <cover.1507795407.git.rahul.lakkireddy@chelsio.com>
From: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date: Thu, 12 Oct 2017 13:54:37 +0530
> This series of patches add support to collect hardware debug logs
> via ethtool --get-dump facility.
There is a lot of global namespace pollution added by these
changes.
A lot of the global symbols you add in this new code have very
poorly namespaced names like "collect_mem_info()"
If the driver is built statically into the kernel this will pollute
the global namespace and conflict with any symbols elsewhere in the
kernel that have the same name.
So please use a proper "cxgb4_" or similar prefix for any non-static
symbols in the driver.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] selftests: rtnetlink: add a small macsec test case
From: David Miller @ 2017-10-13 6:06 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <20171012091122.28133-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Thu, 12 Oct 2017 11:11:22 +0200
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/1] net/smc: add SMC rendezvous protocol
From: David Miller @ 2017-10-13 6:06 UTC (permalink / raw)
To: fw
Cc: ubraun, netdev, linux-s390, jwi, schwidefsky, heiko.carstens,
raspl, hwippel
In-Reply-To: <20171012111429.GG26835@breakpoint.cc>
From: Florian Westphal <fw@strlen.de>
Date: Thu, 12 Oct 2017 13:14:29 +0200
> Ursula Braun <ubraun@linux.vnet.ibm.com> wrote:
>> On 10/11/2017 11:06 PM, David Miller wrote:
>> > From: Ursula Braun <ubraun@linux.vnet.ibm.com>
>> > Date: Tue, 10 Oct 2017 16:14:19 +0200
>> >
>> >> The goal of this patch is to leave common TCP code unmodified. Thus,
>> >> it uses netfilter hooks to intercept TCP SYN and SYN/ACK
>> >> packets. For outgoing packets originating from SMC sockets, the
>> >> experimental option is added. For inbound packets destined for SMC
>> >> sockets, the experimental option is checked.
>> >
>> > I think this really isn't going to pass.
>> >
>> > It's a user experience nightmare when the kernel inserts and
>> > deletes filtering rules outside of what the user configures
>> > on their system.
>
> It depends if the hook is passive or not (i.e. mangles
> payload/metadata or returns verdict other than NF_ACCEPT).
>
> OUTPUT hook added here is not passive as it mangles tcp options.
>
>> > This approach was also considerd for ipv6 ILA, and the same
>> > pushback was given.
>
> ahem.
> net/ipv6/ila/ila_xlat.c: err = nf_register_net_hooks(net, ila_nf_hook_ops,
My bad, I thought we had decided against that.
Oh well.
^ permalink raw reply
* Re: [patch net-next 00/34] net: sched: allow qdiscs to share filter block instances
From: Jiri Pirko @ 2017-10-13 6:21 UTC (permalink / raw)
To: David Miller
Cc: netdev, jhs, xiyou.wangcong, mlxsw, andrew, vivien.didelot,
f.fainelli, michael.chan, ganeshgr, jeffrey.t.kirsher, saeedm,
matanb, leonro, idosch, jakub.kicinski, ast, daniel, simon.horman,
pieter.jansenvanvuuren, john.hurley, edumazet, dsahern,
alexander.h.duyck, john.fastabend, willemb
In-Reply-To: <20171012.102148.580269505585324793.davem@davemloft.net>
Thu, Oct 12, 2017 at 07:21:48PM CEST, davem@davemloft.net wrote:
>
>Jiri I'm not looking at a 34 patch set, it's too large.
>
>Break this up into groups of a dozen or so patches each, no
>more. Submit them one at a time and wait for each series
>to be fully reviewed and integrated before moving onto the
>next one.
Yeah. As I stated in the beginning of the cover letter, I did not find a
way to do it. I could split into 2 of 3 patchsets, problem is that I
would introduce interfaces in first patchset that would be only used in
patchset 2 or 3. I believe that is not ok. Do you think that I can do it
like this this time?
Thanks
^ 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