* [PATCH net-next 2/7] net: dsa: Have the switch driver allocate there own private memory
From: Andrew Lunn @ 2016-04-11 19:50 UTC (permalink / raw)
To: David Miller; +Cc: Florian Fainelli, netdev, Vivien Didelot, Andrew Lunn
In-Reply-To: <1460404209-32083-1-git-send-email-andrew@lunn.ch>
Now the switch devices have a dev pointer, make use of it for allocating
the drivers private data structures using a devm_kzalloc().
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
v2: Added missing assignment of priv to ds->priv.
---
drivers/net/dsa/bcm_sf2.c | 10 ++++++++--
drivers/net/dsa/mv88e6060.c | 3 ++-
drivers/net/dsa/mv88e6123.c | 17 ++++++++++++++---
drivers/net/dsa/mv88e6131.c | 17 ++++++++++++++---
drivers/net/dsa/mv88e6171.c | 17 ++++++++++++++---
drivers/net/dsa/mv88e6352.c | 17 ++++++++++++++---
drivers/net/dsa/mv88e6xxx.c | 6 ++++--
drivers/net/dsa/mv88e6xxx.h | 3 +++
include/net/dsa.h | 10 ++++++++--
net/dsa/dsa.c | 8 +++++---
10 files changed, 86 insertions(+), 22 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 18a79579141f..7d62802a66d5 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -136,8 +136,15 @@ static int bcm_sf2_sw_get_sset_count(struct dsa_switch *ds)
}
static char *bcm_sf2_sw_probe(struct device *dsa_dev, struct device *host_dev,
- int sw_addr)
+ int sw_addr, void **_priv)
{
+ struct bcm_sf2_priv *priv;
+
+ priv = devm_kzalloc(dsa_dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return NULL;
+ *_priv = priv;
+
return "Broadcom Starfighter 2";
}
@@ -1363,7 +1370,6 @@ static int bcm_sf2_sw_set_wol(struct dsa_switch *ds, int port,
static struct dsa_switch_driver bcm_sf2_switch_driver = {
.tag_protocol = DSA_TAG_PROTO_BRCM,
- .priv_size = sizeof(struct bcm_sf2_priv),
.probe = bcm_sf2_sw_probe,
.setup = bcm_sf2_sw_setup,
.set_addr = bcm_sf2_sw_set_addr,
diff --git a/drivers/net/dsa/mv88e6060.c b/drivers/net/dsa/mv88e6060.c
index 34d0f9fe19db..41195f1417f1 100644
--- a/drivers/net/dsa/mv88e6060.c
+++ b/drivers/net/dsa/mv88e6060.c
@@ -58,11 +58,12 @@ static int reg_write(struct dsa_switch *ds, int addr, int reg, u16 val)
})
static char *mv88e6060_probe(struct device *dsa_dev, struct device *host_dev,
- int sw_addr)
+ int sw_addr, void **priv)
{
struct mii_bus *bus = dsa_host_dev_to_mii_bus(host_dev);
int ret;
+ *priv = NULL;
if (bus == NULL)
return NULL;
diff --git a/drivers/net/dsa/mv88e6123.c b/drivers/net/dsa/mv88e6123.c
index ede4c6f0b31a..bcab3ef22448 100644
--- a/drivers/net/dsa/mv88e6123.c
+++ b/drivers/net/dsa/mv88e6123.c
@@ -30,10 +30,20 @@ static const struct mv88e6xxx_switch_id mv88e6123_table[] = {
};
static char *mv88e6123_probe(struct device *dsa_dev, struct device *host_dev,
- int sw_addr)
+ int sw_addr, void **priv)
{
- return mv88e6xxx_lookup_name(host_dev, sw_addr, mv88e6123_table,
+ struct mv88e6xxx_priv_state *ps;
+ char *name;
+
+ name = mv88e6xxx_lookup_name(host_dev, sw_addr, mv88e6123_table,
ARRAY_SIZE(mv88e6123_table));
+ if (name) {
+ ps = devm_kzalloc(dsa_dev, sizeof(*ps), GFP_KERNEL);
+ if (!ps)
+ return NULL;
+ *priv = ps;
+ }
+ return name;
}
static int mv88e6123_setup_global(struct dsa_switch *ds)
@@ -74,6 +84,8 @@ static int mv88e6123_setup(struct dsa_switch *ds)
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
int ret;
+ ps->ds = ds;
+
ret = mv88e6xxx_setup_common(ds);
if (ret < 0)
return ret;
@@ -103,7 +115,6 @@ static int mv88e6123_setup(struct dsa_switch *ds)
struct dsa_switch_driver mv88e6123_switch_driver = {
.tag_protocol = DSA_TAG_PROTO_EDSA,
- .priv_size = sizeof(struct mv88e6xxx_priv_state),
.probe = mv88e6123_probe,
.setup = mv88e6123_setup,
.set_addr = mv88e6xxx_set_addr_indirect,
diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
index bfadfd2cbb8d..b9f9b009f65a 100644
--- a/drivers/net/dsa/mv88e6131.c
+++ b/drivers/net/dsa/mv88e6131.c
@@ -26,10 +26,20 @@ static const struct mv88e6xxx_switch_id mv88e6131_table[] = {
};
static char *mv88e6131_probe(struct device *dsa_dev, struct device *host_dev,
- int sw_addr)
+ int sw_addr, void **priv)
{
- return mv88e6xxx_lookup_name(host_dev, sw_addr, mv88e6131_table,
+ struct mv88e6xxx_priv_state *ps;
+ char *name;
+
+ name = mv88e6xxx_lookup_name(host_dev, sw_addr, mv88e6131_table,
ARRAY_SIZE(mv88e6131_table));
+ if (name) {
+ ps = devm_kzalloc(dsa_dev, sizeof(*ps), GFP_KERNEL);
+ if (!ps)
+ return NULL;
+ *priv = ps;
+ }
+ return name;
}
static int mv88e6131_setup_global(struct dsa_switch *ds)
@@ -92,6 +102,8 @@ static int mv88e6131_setup(struct dsa_switch *ds)
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
int ret;
+ ps->ds = ds;
+
ret = mv88e6xxx_setup_common(ds);
if (ret < 0)
return ret;
@@ -160,7 +172,6 @@ mv88e6131_phy_write(struct dsa_switch *ds,
struct dsa_switch_driver mv88e6131_switch_driver = {
.tag_protocol = DSA_TAG_PROTO_DSA,
- .priv_size = sizeof(struct mv88e6xxx_priv_state),
.probe = mv88e6131_probe,
.setup = mv88e6131_setup,
.set_addr = mv88e6xxx_set_addr_direct,
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index fb35d3ac1644..15200928cecc 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -25,10 +25,20 @@ static const struct mv88e6xxx_switch_id mv88e6171_table[] = {
};
static char *mv88e6171_probe(struct device *dsa_dev, struct device *host_dev,
- int sw_addr)
+ int sw_addr, void **priv)
{
- return mv88e6xxx_lookup_name(host_dev, sw_addr, mv88e6171_table,
+ struct mv88e6xxx_priv_state *ps;
+ char *name;
+
+ name = mv88e6xxx_lookup_name(host_dev, sw_addr, mv88e6171_table,
ARRAY_SIZE(mv88e6171_table));
+ if (name) {
+ ps = devm_kzalloc(dsa_dev, sizeof(*ps), GFP_KERNEL);
+ if (!ps)
+ return NULL;
+ *priv = ps;
+ }
+ return name;
}
static int mv88e6171_setup_global(struct dsa_switch *ds)
@@ -70,6 +80,8 @@ static int mv88e6171_setup(struct dsa_switch *ds)
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
int ret;
+ ps->ds = ds;
+
ret = mv88e6xxx_setup_common(ds);
if (ret < 0)
return ret;
@@ -89,7 +101,6 @@ static int mv88e6171_setup(struct dsa_switch *ds)
struct dsa_switch_driver mv88e6171_switch_driver = {
.tag_protocol = DSA_TAG_PROTO_EDSA,
- .priv_size = sizeof(struct mv88e6xxx_priv_state),
.probe = mv88e6171_probe,
.setup = mv88e6171_setup,
.set_addr = mv88e6xxx_set_addr_indirect,
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index 577ab2cfa944..7081a78a67e1 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -38,10 +38,20 @@ static const struct mv88e6xxx_switch_id mv88e6352_table[] = {
};
static char *mv88e6352_probe(struct device *dsa_dev, struct device *host_dev,
- int sw_addr)
+ int sw_addr, void **priv)
{
- return mv88e6xxx_lookup_name(host_dev, sw_addr, mv88e6352_table,
+ struct mv88e6xxx_priv_state *ps;
+ char *name;
+
+ name = mv88e6xxx_lookup_name(host_dev, sw_addr, mv88e6352_table,
ARRAY_SIZE(mv88e6352_table));
+ if (name) {
+ ps = devm_kzalloc(dsa_dev, sizeof(*ps), GFP_KERNEL);
+ if (!ps)
+ return NULL;
+ *priv = ps;
+ }
+ return name;
}
static int mv88e6352_setup_global(struct dsa_switch *ds)
@@ -82,6 +92,8 @@ static int mv88e6352_setup(struct dsa_switch *ds)
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
int ret;
+ ps->ds = ds;
+
ret = mv88e6xxx_setup_common(ds);
if (ret < 0)
return ret;
@@ -303,7 +315,6 @@ static int mv88e6352_set_eeprom(struct dsa_switch *ds,
struct dsa_switch_driver mv88e6352_switch_driver = {
.tag_protocol = DSA_TAG_PROTO_EDSA,
- .priv_size = sizeof(struct mv88e6xxx_priv_state),
.probe = mv88e6352_probe,
.setup = mv88e6352_setup,
.set_addr = mv88e6xxx_set_addr_indirect,
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 62320fca6712..085fc4a49eb2 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -281,7 +281,7 @@ static void mv88e6xxx_ppu_reenable_work(struct work_struct *ugly)
ps = container_of(ugly, struct mv88e6xxx_priv_state, ppu_work);
if (mutex_trylock(&ps->ppu_mutex)) {
- struct dsa_switch *ds = ((struct dsa_switch *)ps) - 1;
+ struct dsa_switch *ds = ps->ds;
if (mv88e6xxx_ppu_enable(ds) == 0)
ps->ppu_disabled = 0;
@@ -2322,7 +2322,7 @@ static void mv88e6xxx_bridge_work(struct work_struct *work)
int port;
ps = container_of(work, struct mv88e6xxx_priv_state, bridge_work);
- ds = ((struct dsa_switch *)ps) - 1;
+ ds = ps->ds;
mutex_lock(&ps->smi_mutex);
@@ -2670,6 +2670,8 @@ int mv88e6xxx_setup_common(struct dsa_switch *ds)
{
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ ps->ds = ds;
+
mutex_init(&ps->smi_mutex);
ps->id = REG_READ(REG_PORT(0), PORT_SWITCH_ID) & 0xfff0;
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index 236bcaa606e7..0322e3e0e7d9 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -397,6 +397,9 @@ struct mv88e6xxx_priv_port {
};
struct mv88e6xxx_priv_state {
+ /* The dsa_switch this private structure is related to */
+ struct dsa_switch *ds;
+
/* When using multi-chip addressing, this mutex protects
* access to the indirect access registers. (In single-chip
* mode, this mutex is effectively useless.)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 0f9f6f38f255..7bc7bd9b5ded 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -130,6 +130,12 @@ struct dsa_switch {
int index;
/*
+ * Give the switch driver somewhere to hang its private data
+ * structure.
+ */
+ void *priv;
+
+ /*
* Tagging protocol understood by this switch
*/
enum dsa_tag_protocol tag_protocol;
@@ -213,7 +219,7 @@ struct dsa_switch_driver {
* Probing and setup.
*/
char *(*probe)(struct device *dsa_dev, struct device *host_dev,
- int sw_addr);
+ int sw_addr, void **priv);
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);
@@ -342,7 +348,7 @@ struct mii_bus *dsa_host_dev_to_mii_bus(struct device *dev);
static inline void *ds_to_priv(struct dsa_switch *ds)
{
- return (void *)(ds + 1);
+ return ds->priv;
}
static inline bool dsa_uses_tagged_protocol(struct dsa_switch_tree *dst)
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index c06275311cb2..7ef8a92a9e39 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -52,7 +52,7 @@ EXPORT_SYMBOL_GPL(unregister_switch_driver);
static struct dsa_switch_driver *
dsa_switch_probe(struct device *parent, struct device *host_dev, int sw_addr,
- char **_name)
+ char **_name, void **priv)
{
struct dsa_switch_driver *ret;
struct list_head *list;
@@ -67,7 +67,7 @@ dsa_switch_probe(struct device *parent, struct device *host_dev, int sw_addr,
drv = list_entry(list, struct dsa_switch_driver, list);
- name = drv->probe(parent, host_dev, sw_addr);
+ name = drv->probe(parent, host_dev, sw_addr, priv);
if (name != NULL) {
ret = drv;
break;
@@ -384,11 +384,12 @@ dsa_switch_setup(struct dsa_switch_tree *dst, int index,
struct dsa_switch *ds;
int ret;
char *name;
+ void *priv;
/*
* Probe for switch model.
*/
- drv = dsa_switch_probe(parent, host_dev, pd->sw_addr, &name);
+ drv = dsa_switch_probe(parent, host_dev, pd->sw_addr, &name, &priv);
if (drv == NULL) {
netdev_err(dst->master_netdev, "[%d]: could not detect attached switch\n",
index);
@@ -409,6 +410,7 @@ dsa_switch_setup(struct dsa_switch_tree *dst, int index,
ds->index = index;
ds->pd = pd;
ds->drv = drv;
+ ds->priv = priv;
ds->tag_protocol = drv->tag_protocol;
ds->master_dev = host_dev;
--
2.7.0
^ permalink raw reply related
* Re: FWD: [PATCH v2] Marvell phy: add fiber status check for some components
From: Florian Fainelli @ 2016-04-11 19:47 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, charles-antoine.couret
In-Reply-To: <20160404132552.GH21828@lunn.ch>
On 04/04/16 06:25, Andrew Lunn wrote:
>> >From 564b767163d19355a3b5efaad195e93796570c71 Mon Sep 17 00:00:00 2001
>> From: Charles-Antoine Couret <charles-antoine.couret@nexvision.fr>
>> Date: Fri, 1 Apr 2016 16:16:35 +0200
>> Subject: [PATCH] Marvell phy: add fiber status check for some components
>>
>> Marvell's phy could have two modes: fiber and copper. Currently, the driver
>> checks only the copper mode registers to get the status link which could be
>> wrong.
>>
>> This commit add a handler to check fiber then copper status link.
>> If the fiber link is activated, the driver would use this information.
>> Else, it would use the copper status.
>
> Hi Florian
>
> What do you think about this?
>
> This works for basic status information. But what about other ethtool
> options? Setting the speed and duplex, turning pause on/off, etc.
Agreed, it seems like a PHY configured for fiber will need to provide
these informations differently, or does the standard BMSR register
provide accurate information already?
>
> Do we actually need to stay on page 1 if fibre is in use? How do we
> initially change to page 1 when the fibre link is still down?
I also do not feel very comfortable with reading the fiber status first,
and then copper and then combine these two. At the very best, could we
do something like:
- identify if the PHY is configured for fiber in drv->probe or
drv->config_init, retain that information
- have two paths in drv->read_status which take care of reading one
status or the other?
Are there other side effects for other register accesses (say,
statistics, or auto-negotiation) that need to be fiber vs. copper aware?
>
> Should we be using the old mechanism to swap between TP, BNC and AUI
> to swap between copper and fibre?
Did you mean using ethtool -s <iface> port fibre for instance?
--
Florian
^ permalink raw reply
* Re: [Lsf] [Lsf-pc] [LSF/MM TOPIC] Generic page-pool recycle facility?
From: Jesper Dangaard Brouer @ 2016-04-11 19:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: lsf, netdev@vger.kernel.org, Brenden Blanco, James Bottomley,
linux-mm, Mel Gorman, Tom Herbert, lsf-pc, Mel Gorman,
Alexei Starovoitov, brouer, Alexander Duyck, Waskiewicz, PJ
In-Reply-To: <1460393634.6473.560.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, 11 Apr 2016 09:53:54 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2016-04-11 at 18:19 +0200, Jesper Dangaard Brouer wrote:
>
> > Drivers also do tricks where they fallback to smaller order pages. E.g.
> > lookup function mlx4_alloc_pages(). I've tried to simulate that
> > function here:
> > https://github.com/netoptimizer/prototype-kernel/blob/91d323fc53/kernel/mm/bench/page_bench01.c#L69
>
> We use order-0 pages on mlx4 at Google, as order-3 pages are very
> dangerous for some kind of attacks...
Interesting!
> An out of order TCP packet can hold an order-3 pages, while claiming to
> use 1.5 KBvia skb->truesize.
>
> order-0 only pages allow the page recycle trick used by Intel driver,
> and we hardly see any page allocations in typical workloads.
Yes, I looked at the Intel ixgbe drivers page recycle trick.
It is actually quite cool, but code wise it is a little hard to
follow. I started to look at the variant in i40e, specifically
function i40e_clean_rx_irq_ps() explains it a bit more explicit.
> While order-3 pages are 'nice' for friendly datacenter kind of
> traffic, they also are a higher risk on hosts connected to the wild
> Internet.
>
> Maybe I should upstream this patch ;)
Definitely!
Does this patch also include a page recycle trick? Else how do you get
around the cost of allocating a single order-0 page?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH net-next] net: mdio: Fix lockdep falls positive splat
From: Andrew Lunn @ 2016-04-11 19:40 UTC (permalink / raw)
To: David Miller; +Cc: Florian Fainelli, netdev, Vivien Didelot, Andrew Lunn
MDIO devices can be stacked upon each other. The current code supports
two levels, which until recently has been enough for a DSA mdio bus on
top of another bus. Now we have hardware which has an MDIO mux in the
middle.
Define an MDIO MUTEX class with three levels.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/phy/mdio-mux.c | 10 ++--------
drivers/net/phy/mdio_bus.c | 4 ++--
include/linux/mdio.h | 11 +++++++++++
3 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/net/phy/mdio-mux.c b/drivers/net/phy/mdio-mux.c
index 308ade0eb1b6..5c81d6faf304 100644
--- a/drivers/net/phy/mdio-mux.c
+++ b/drivers/net/phy/mdio-mux.c
@@ -45,13 +45,7 @@ static int mdio_mux_read(struct mii_bus *bus, int phy_id, int regnum)
struct mdio_mux_parent_bus *pb = cb->parent;
int r;
- /* In theory multiple mdio_mux could be stacked, thus creating
- * more than a single level of nesting. But in practice,
- * SINGLE_DEPTH_NESTING will cover the vast majority of use
- * cases. We use it, instead of trying to handle the general
- * case.
- */
- mutex_lock_nested(&pb->mii_bus->mdio_lock, SINGLE_DEPTH_NESTING);
+ mutex_lock_nested(&pb->mii_bus->mdio_lock, MDIO_MUTEX_MUX);
r = pb->switch_fn(pb->current_child, cb->bus_number, pb->switch_data);
if (r)
goto out;
@@ -76,7 +70,7 @@ static int mdio_mux_write(struct mii_bus *bus, int phy_id,
int r;
- mutex_lock_nested(&pb->mii_bus->mdio_lock, SINGLE_DEPTH_NESTING);
+ mutex_lock_nested(&pb->mii_bus->mdio_lock, MDIO_MUTEX_MUX);
r = pb->switch_fn(pb->current_child, cb->bus_number, pb->switch_data);
if (r)
goto out;
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 0cba64f1ecf4..751202a285a6 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -457,7 +457,7 @@ int mdiobus_read_nested(struct mii_bus *bus, int addr, u32 regnum)
BUG_ON(in_interrupt());
- mutex_lock_nested(&bus->mdio_lock, SINGLE_DEPTH_NESTING);
+ mutex_lock_nested(&bus->mdio_lock, MDIO_MUTEX_NESTED);
retval = bus->read(bus, addr, regnum);
mutex_unlock(&bus->mdio_lock);
@@ -509,7 +509,7 @@ int mdiobus_write_nested(struct mii_bus *bus, int addr, u32 regnum, u16 val)
BUG_ON(in_interrupt());
- mutex_lock_nested(&bus->mdio_lock, SINGLE_DEPTH_NESTING);
+ mutex_lock_nested(&bus->mdio_lock, MDIO_MUTEX_NESTED);
err = bus->write(bus, addr, regnum, val);
mutex_unlock(&bus->mdio_lock);
diff --git a/include/linux/mdio.h b/include/linux/mdio.h
index 5bfd99d1a40a..bf9d1d750693 100644
--- a/include/linux/mdio.h
+++ b/include/linux/mdio.h
@@ -13,6 +13,17 @@
struct mii_bus;
+/* Multiple levels of nesting are possible. However typically this is
+ * limited to nested DSA like layer, a MUX layer, and the normal
+ * user. Instead of trying to handle the general case, just define
+ * these cases.
+ */
+enum mdio_mutex_lock_class {
+ MDIO_MUTEX_NORMAL,
+ MDIO_MUTEX_MUX,
+ MDIO_MUTEX_NESTED,
+};
+
struct mdio_device {
struct device dev;
--
2.7.0
^ permalink raw reply related
* Re: [PATCH 0/9] RxRPC: 2nd rewrite part 1
From: David Miller @ 2016-04-11 19:35 UTC (permalink / raw)
To: dhowells; +Cc: linux-afs, netdev, linux-kernel
In-Reply-To: <20160407162256.21283.47849.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Thu, 07 Apr 2016 17:22:56 +0100
> Okay, I'm in the process of rewriting the RxRPC rewrite. The primary aim of
> this second rewrite is to strictly control the number of active connections we
> know about and to get rid of connections we don't need much more quickly.
>
> On top of this, there are fixes to the protocol handling which will all occur
> in later parts.
Series applied, but I had to fix up some trailing whitespace (reported by GIT)
by hand.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] fix udp pull header breakage
From: David Miller @ 2016-04-11 19:31 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, fcooper, samanthakumar, willemb
In-Reply-To: <1460043899-56894-1-git-send-email-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Thu, 7 Apr 2016 11:44:57 -0400
> Commit e6afc8ace6dd ("udp: remove headers from UDP packets before
> queueing") modified udp receive processing to pull headers before
> enqueue and to not expect them on dequeue.
>
> The patch missed protocols on top of udp with in-kernel
> implementations that have their own skb_recv_datagram calls and
> dequeue logic. Modify these datapaths to also no longer expect
> a udp header at skb->data.
>
> Sunrpc and rxrpc are the only two protocols that call this
> function and contain references to udphr (some others, like tipc,
> are based on encap_rcv, which acts before enqueue, before the
> the header pull).
Series applied, thanks for fixing this regression so quickly.
^ permalink raw reply
* Re: [PATCH RFT 1/2] phylib: add device reset GPIO support
From: Sergei Shtylyov @ 2016-04-11 19:28 UTC (permalink / raw)
To: Rob Herring
Cc: grant.likely-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160411192521.GA6896@rob-hp-laptop>
On 04/11/2016 10:25 PM, Rob Herring wrote:
>> The PHY devices sometimes do have their reset signal (maybe even power
>> supply?) tied to some GPIO and sometimes it also does happen that a boot
>> loader does not leave it deasserted. So far this issue has been attacked
>> from (as I believe) a wrong angle: by teaching the MAC driver to manipulate
>> the GPIO in question; that solution, when applied to the device trees,
>> led to adding the PHY reset GPIO properties to the MAC device node, with
>> one exception: Cadence MACB driver which could handle the "reset-gpios"
>> prop in a PHY device subnode. I believe that the correct approach is to
>> teach the 'phylib' to get the MDIO device reset GPIO from the device tree
>> node corresponding to this device -- which this patch is doing...
>>
>> Note that I had to modify the AT803x PHY driver as it would stop working
>> otherwise as it made use of the reset GPIO for its own purposes...
>
> Lots of double spaces in here. Please fix.
Oh, it's you again! :-D
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
>>
>> ---
>> Documentation/devicetree/bindings/net/phy.txt | 2 +
>> drivers/net/phy/at803x.c | 19 ++------------
>> drivers/net/phy/mdio_bus.c | 4 +++
>> drivers/net/phy/mdio_device.c | 27 +++++++++++++++++++--
>> drivers/net/phy/phy_device.c | 33 ++++++++++++++++++++++++--
>> drivers/of/of_mdio.c | 16 ++++++++++++
>> include/linux/mdio.h | 3 ++
>> include/linux/phy.h | 5 +++
>> 8 files changed, 89 insertions(+), 20 deletions(-)
>
> [...]
>
>> Index: net-next/drivers/of/of_mdio.c
>> ===================================================================
>> --- net-next.orig/drivers/of/of_mdio.c
>> +++ net-next/drivers/of/of_mdio.c
>> @@ -44,6 +44,7 @@ static int of_get_phy_id(struct device_n
>> static int of_mdiobus_register_phy(struct mii_bus *mdio, struct device_node *child,
>> u32 addr)
>> {
>> + struct gpio_desc *gpiod;
>> struct phy_device *phy;
>> bool is_c45;
>> int rc;
>> @@ -52,10 +53,17 @@ static int of_mdiobus_register_phy(struc
>> is_c45 = of_device_is_compatible(child,
>> "ethernet-phy-ieee802.3-c45");
>>
>> + gpiod = fwnode_get_named_gpiod(&child->fwnode, "reset-gpios");
>
> Calling fwnode_* functions in a DT specific file/function? That doesn't
> make sense.
Really?! 8-)
Where is a DT-only analog I wonder...
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Lsf] [Lsf-pc] [LSF/MM TOPIC] Generic page-pool recycle facility?
From: Jesper Dangaard Brouer @ 2016-04-11 19:26 UTC (permalink / raw)
To: Mel Gorman
Cc: Mel Gorman, James Bottomley, netdev@vger.kernel.org,
Brenden Blanco, lsf, linux-mm, Tom Herbert, lsf-pc,
Alexei Starovoitov, brouer
In-Reply-To: <20160411180703.GA27534@suse.de>
On Mon, 11 Apr 2016 19:07:03 +0100
Mel Gorman <mgorman@suse.de> wrote:
> On Mon, Apr 11, 2016 at 06:19:07PM +0200, Jesper Dangaard Brouer wrote:
> > > http://git.kernel.org/cgit/linux/kernel/git/mel/linux.git/log/?h=mm-vmscan-node-lru-v4r5
> > >
> >
> > The cost decreased to: 228 cycles(tsc), but there are some variations,
> > sometimes it increase to 238 cycles(tsc).
> >
>
> In the free path, a bulk pcp free adds to the cycles. In the alloc path,
> a refill of the pcp lists costs quite a bit. Either option introduces
> variances. The bulk free path can be optimised a little so I chucked
> some additional patches at it that are not released yet but I suspect the
> benefit will be marginal. The real heavy costs there are splitting/merging
> buddies. Fixing that is much more fundamental but even fronting the allocator
> with a new recycle allocator would not offset that as the refill of the
> page-recycling thing would incur high costs.
>
Yes, re-filling page-pool (in the non-steady state) could be
problematic for performance. That is why I'm very motivated in helping
out with a bulk alloc/free scheme for the page allocator.
> > Nice, but there is still a looong way to my performance target, where I
> > can spend 201 cycles for the entire forwarding path....
> >
>
> While I accept the cost is still too high, I think the effort should still
> be spent on improving the allocator in general than trying to bypass it.
>
I do think improving the page allocator is very important work.
I just don't see how we can ever reach my performance target, without a
page-pool recycle facility.
I work in the area, where I think the cost of a single atomic operation
is too high. I work on amortizing the individual atomic operations.
That is what I did for the SLUB allocator, with the bulk API. see:
Commit d0ecd894e3d5 ("slub: optimize bulk slowpath free by detached freelist")
https://git.kernel.org/torvalds/c/d0ecd894e3d5
Commit fbd02630c6e3 ("slub: initial bulk free implementation")
https://git.kernel.org/torvalds/c/fbd02630c6e3
This is now also used in the network stack:
Commit 3134b9f019f2 ("Merge branch 'net-mitigate-kmem_free-slowpath'")
Commit a3a8749d34d8 ("ixgbe: bulk free SKBs during TX completion cleanup cycle")
> > > This is an unreleased series that contains both the page allocator
> > > optimisations and the one-LRU-per-node series which in combination remove a
> > > lot of code from the page allocator fast paths. I have no data on how the
> > > combined series behaves but each series individually is known to improve
> > > page allocator performance.
> > >
> > > Once you have that, do a hackjob to remove the debugging checks from both the
> > > alloc and free path and see what that leaves. They could be bypassed properly
> > > with a __GFP_NOACCT flag used only by drivers that absolutely require pages
> > > as quickly as possible and willing to be less safe to get that performance.
> >
> > I would be interested in testing/benchmarking a patch where you remove
> > the debugging checks...
> >
>
> Right now, I'm not proposing to remove the debugging checks despite their
> cost. They catch really difficult problems in the field unfortunately
> including corruption from buggy hardware. A GFP flag that disables them
> for a very specific case would be ok but I expect it to be resisted by
> others if it's done for the general case. Even a static branch for runtime
> debugging checks may be resisted.
>
> Even if GFP flags are tight, I have a patch that deletes __GFP_COLD on
> the grounds it is of questionable value. Applying that would free a flag
> for __GFP_NOACCT that bypasses debugging checks and statistic updates.
> That would work for the allocation side at least but doing the same for
> the free side would be hard (potentially impossible) to do transparently
> for drivers.
Before spending too much work on something, I usually try to determine
what the maximum benefit of something would be. Thus, I propose you
create a patch that hack remove all the debug checks that you think
could be beneficial to remove. And then benchmark it yourself or send
it to me for benchmarking... that is the quickest way to determine if
this is worth spending time on.
> > You are also welcome to try out my benchmarking modules yourself:
> > https://github.com/netoptimizer/prototype-kernel/blob/master/getting_started.rst
> >
>
> I took a quick look and functionally it's similar to the systemtap-based
> microbenchmark I'm using in mmtests so I don't think we have a problem
> with reproduction at the moment.
>
> > > Be aware that compound order allocs like this are a double edged sword as
> > > it'll be fast sometimes and other times require reclaim/compaction which
> > > can stall for prolonged periods of time.
> >
> > Yes, I've notice that there can be a fairly high variation, when doing
> > compound order allocs, which is not so nice! I really don't like these
> > variations....
> >
>
> They can cripple you which is why I'm very wary of performance patches that
> require compound pages. It tends to look great only on benchmarks and then
> the corner cases hit in the real world and the bug reports are unpleasant.
That confirms Eric's experience at Google, where they disabled this
compound order page feature in the driver...
> > Drivers also do tricks where they fallback to smaller order pages. E.g.
> > lookup function mlx4_alloc_pages(). I've tried to simulate that
> > function here:
> > https://github.com/netoptimizer/prototype-kernel/blob/91d323fc53/kernel/mm/bench/page_bench01.c#L69
> >
> > It does not seem very optimal. I tried to mem pressure the system a bit
> > to cause the alloc_pages() to fail, and then the result were very bad,
> > something like 2500 cycles, and it usually got the next order pages.
>
> The options for fallback tend to have one hazard after the next. It's
> partially why the last series focused on order-0 pages only.
Other places in the network stack, this falling down through the
order's got removed, and replaced with a single "falldown" to order-0
pages. (due to people reporting bad experiences of latency spikes)
> > > > I've measured order 3 (32KB) alloc_pages(order=3) + __free_pages() to
> > > > cost approx 500 cycles(tsc). That was more expensive, BUT an order=3
> > > > page 32Kb correspond to 8 pages (32768/4096), thus 500/8 = 62.5
> > > > cycles. Usually a network RX-frame only need to be 2048 bytes, thus
> > > > the "bulk" effect speed up is x16 (32768/2048), thus 31.25 cycles.
> >
> > The order=3 cost were reduced to: 417 cycles(tsc), nice! But I've also
> > seen it jump to 611 cycles.
> >
>
> The corner cases can be minimised to some extent -- lazy buddy merging for
> example but it unfortunately has other consequences for users that require
> high-order pages for functional reasons. I tried something like that once
> (http://thread.gmane.org/gmane.linux.kernel/807683) but didn't pursue it
> to the end as it was a small part of the problem I was dealing with at the
> time. It shouldn't be ruled out but it should be considered a last resort.
>
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH RFT 1/2] phylib: add device reset GPIO support
From: Rob Herring @ 2016-04-11 19:25 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: grant.likely, devicetree, f.fainelli, netdev, frowand.list,
pawel.moll, mark.rutland, ijc+devicetree, galak, linux-kernel
In-Reply-To: <3381543.SDQLqND8Pp@wasted.cogentembedded.com>
On Sat, Apr 09, 2016 at 01:22:47AM +0300, Sergei Shtylyov wrote:
> The PHY devices sometimes do have their reset signal (maybe even power
> supply?) tied to some GPIO and sometimes it also does happen that a boot
> loader does not leave it deasserted. So far this issue has been attacked
> from (as I believe) a wrong angle: by teaching the MAC driver to manipulate
> the GPIO in question; that solution, when applied to the device trees,
> led to adding the PHY reset GPIO properties to the MAC device node, with
> one exception: Cadence MACB driver which could handle the "reset-gpios"
> prop in a PHY device subnode. I believe that the correct approach is to
> teach the 'phylib' to get the MDIO device reset GPIO from the device tree
> node corresponding to this device -- which this patch is doing...
>
> Note that I had to modify the AT803x PHY driver as it would stop working
> otherwise as it made use of the reset GPIO for its own purposes...
Lots of double spaces in here. Please fix.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> Documentation/devicetree/bindings/net/phy.txt | 2 +
> drivers/net/phy/at803x.c | 19 ++------------
> drivers/net/phy/mdio_bus.c | 4 +++
> drivers/net/phy/mdio_device.c | 27 +++++++++++++++++++--
> drivers/net/phy/phy_device.c | 33 ++++++++++++++++++++++++--
> drivers/of/of_mdio.c | 16 ++++++++++++
> include/linux/mdio.h | 3 ++
> include/linux/phy.h | 5 +++
> 8 files changed, 89 insertions(+), 20 deletions(-)
[...]
> Index: net-next/drivers/of/of_mdio.c
> ===================================================================
> --- net-next.orig/drivers/of/of_mdio.c
> +++ net-next/drivers/of/of_mdio.c
> @@ -44,6 +44,7 @@ static int of_get_phy_id(struct device_n
> static int of_mdiobus_register_phy(struct mii_bus *mdio, struct device_node *child,
> u32 addr)
> {
> + struct gpio_desc *gpiod;
> struct phy_device *phy;
> bool is_c45;
> int rc;
> @@ -52,10 +53,17 @@ static int of_mdiobus_register_phy(struc
> is_c45 = of_device_is_compatible(child,
> "ethernet-phy-ieee802.3-c45");
>
> + gpiod = fwnode_get_named_gpiod(&child->fwnode, "reset-gpios");
Calling fwnode_* functions in a DT specific file/function? That doesn't
make sense.
> + /* Deassert the reset signal */
> + if (!IS_ERR(gpiod))
> + gpiod_direction_output(gpiod, 0);
> if (!is_c45 && !of_get_phy_id(child, &phy_id))
> phy = phy_device_create(mdio, addr, phy_id, 0, NULL);
> else
> phy = get_phy_device(mdio, addr, is_c45);
> + /* Assert the reset signal again */
> + if (!IS_ERR(gpiod))
> + gpiod_set_value(gpiod, 1);
> if (IS_ERR_OR_NULL(phy))
> return 1;
>
^ permalink raw reply
* Re: [PATCH RFC 5/5] ARM: dts: sun8i: Enable Ethernet controller on the Orange PI PC
From: Florian Fainelli @ 2016-04-11 19:25 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, LABBE Corentin, Andrew Lunn
In-Reply-To: <1459786954-12649-6-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
On 04/04/16 09:22, Chen-Yu Tsai wrote:
> The Orange PI PC uses the H3's internal Ethernet PHY with the EMAC
> Ethernet controller.
>
> Set a proper address for the PHY and enable the EMAC.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> ---
>
> This patch depends on "ARM: dts: sun8i-h3: Add Ethernet controller device",
> which uses an binding still in development.
>
> Do not merge.
>
> ---
> arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
> index daf50b9a6657..f01e10df812a 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
> @@ -102,6 +102,20 @@
> status = "okay";
> };
>
> +&ephy {
> + allwinner,ephy-addr = <0x1>;
> +};
> +
> +&emac {
> + phy = <&phy1>;
> + phy-mode = "mii";
> + status = "okay";
> +
> + phy1: ethernet-phy@1 {
> + reg = <1>;
> + };
> +};
As commented in patch 1, the fact that you have to put the Ethernet PHY
address twice here is not really a good thing, because they cannot be
dissociated from eath other, I would rather have a standard Ethernet PHY
DT node represent the desired PHY address, and have your glue/SHIM
SUN8I_H3_EMAC driver scan the Device Tree to know what address to
program for the Ethernet PHY.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RFC 1/5] net: phy: sun8i-h3-ephy: Add bindings for Allwinner H3 Ethernet PHY
From: Florian Fainelli @ 2016-04-11 19:23 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala
Cc: netdev, linux-arm-kernel, linux-kernel, devicetree,
LABBE Corentin, Andrew Lunn
In-Reply-To: <1459786954-12649-2-git-send-email-wens@csie.org>
On 04/04/16 09:22, Chen-Yu Tsai wrote:
> The Allwinner H3 SoC incorporates an Ethernet PHY. This is enabled and
> configured through a memory mapped hardware register.
>
> This same register also configures the MAC interface mode and TX clock
> source. Also covered by the register, but not supported in these bindings,
> are TX/RX clock delay chains and inverters, and an RMII module.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> .../bindings/net/allwinner,sun8i-h3-ephy.txt | 44 ++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun8i-h3-ephy.txt
>
> diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-h3-ephy.txt b/Documentation/devicetree/bindings/net/allwinner,sun8i-h3-ephy.txt
> new file mode 100644
> index 000000000000..146f227e6d88
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-h3-ephy.txt
> @@ -0,0 +1,44 @@
> +* Allwinner H3 E(thernet) PHY
> +
> +The Allwinner H3 integrates an MII ethernet PHY. As with external PHYs,
> +before it can be configured over the MDIO bus and used, certain hardware
> +features must be configured, such as the PHY address and LED polarity.
Is the internal PHY address really configurable? Not that there is
anything wrong with it, this is good.
> +The PHY must also be powered on and brought out of reset.
> +
> +This is accomplished with regulators and pull-up/downs for external PHYs.
> +For this internal PHY, a hardware register is programmed.
> +
> +The same hardware register also contains clock and interface controls
> +for the MAC. This is also present in earlier SoCs, and is covered by
> +"allwinner,sun7i-a20-gmac-clk". The controls in the H3 are slightly
> +different due to the inclusion of what appears to be an RMII-MII
> +bridge.
> +
> +Required properties:
> +- compatible: should be "allwinner,sun8i-h3-ephy"
> +- reg: address and length of the register set for the device
> +- clocks: A phandle to the reference clock for this device
> +- resets: A phandle to the reset control for this device
> +
> +Ethernet PHY related properties:
> +- allwinner,ephy-addr: the MDIO bus address the PHY should respond to.
> + If this is not set, the external PHY is used, and
> + everything else in this section is ignored.
So we are going to put the same value here, and in the actual Ethernet
PHY device tree node that should be hanging off the EMAC/MDIO bus
controller, this is confusing and error prone.
> +- allwinner,leds-active-low: LEDs are active low. Without this, LEDs are
> + active high.
> +
> +Ethernet MAC clock related properties:
> +- #clock-cells: should be 0
> +- clock-output-names: "mac_tx"
> +
> +Example:
> +
> +ethernet-phy@01c00030 {
> + compatible = "allwinner,sun8i-h3-ephy";
> + reg = <0x01c00030 0x4>;
Looking at this register space this looks more like an internal PHY SHIM
that is needed to be configured before the internal PHY can be access,
not a proper Ethernet PHY per-se, see replies in aptch 2.
Should not this block be a second cell associated with the Ethernet MAC
block? One or the other are not going to be very useful without
knowledge of each other.
--
Florian
^ permalink raw reply
* Re: [PATCH RFC 2/5] net: phy: sun8i-h3-ephy: Add driver for Allwinner H3 Ethernet PHY
From: Florian Fainelli @ 2016-04-11 19:23 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, LABBE Corentin, Andrew Lunn
In-Reply-To: <1459786954-12649-3-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
On 04/04/16 09:22, Chen-Yu Tsai wrote:
> The Allwinner H3 SoC incorporates an Ethernet PHY. This is enabled and
> configured through a memory mapped hardware register.
>
> This same register also configures the MAC interface mode and TX clock
> source. Also covered by the register, but not supported in this driver,
> are TX/RX clock delay chains and inverters, and an RMII module.
This is not really a PHY driver, more a driver for a special piece of
hardware responsible for properly configuring a more standard integrated
PHY which is then driven via standard MDIO accesses, right?
The intention to make this driver re-usable is fine, but still makes me
wonder if it should not be put in a file which is linked into the
Ethernet MAC driver, and utilized by this one in a way that may be more
"ad-hoc" than what you are proposing here.
One thing that is not obvious here, is how is the device parenting done?
Are we able to associate a phy_device to this SUN8I_H3_EPHY platform
device here?
Another thing is that the Ethernet MAC driver is fully aware of when
putting an Ethernet PHY into suspend, shutdown, or fully functional
power state should occur, if you have a separate platform driver here
which does not listen for such kinds of events (hint: none are generated
right now), then you cannot implement a working power state interface
between the MAC, SHIM and PHY here, even though you would want that.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net 0/2] tipc: name distributor pernet queue
From: David Miller @ 2016-04-11 19:22 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, paul.gortmaker, parthasarathy.bhuvaragan, richard.alpe,
ying.xue, maloy, tipc-discussion
In-Reply-To: <1460040044-30770-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Thu, 7 Apr 2016 10:40:42 -0400
> Commit #1 fixes a potential issue with deferred binding table
> updates being pushed to the wrong namespace.
>
> Commit #2 solves a problem with deferred binding table updates
> remaining in the the defer queue after the issuing node has gone
> down.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v6 net-next] net: ipv4: Consider failed nexthops in multipath routes
From: David Miller @ 2016-04-11 19:18 UTC (permalink / raw)
To: dsa; +Cc: netdev, ja
In-Reply-To: <1460038860-25670-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Thu, 7 Apr 2016 07:21:00 -0700
> Multipath route lookups should consider knowledge about next hops and not
> select a hop that is known to be failed.
>
> Example:
...
> The failed path can be avoided by considering known neighbor information
> when selecting next hops. If the neighbor lookup fails we have no
> knowledge about the nexthop, so give it a shot. If there is an entry
> then only select the nexthop if the state is sane. This is similar to
> what fib_detect_death does.
>
> To maintain backward compatibility use of the neighbor information is
> based on a new sysctl, fib_multipath_use_neigh.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/2] drivers: net: cpsw: fix ale calls and drop host_port field from cpsw_priv
From: David Miller @ 2016-04-11 19:12 UTC (permalink / raw)
To: grygorii.strashko; +Cc: netdev, mugunthanvnm, nsekhar, linux-kernel, linux-omap
In-Reply-To: <1460031404-28594-1-git-send-email-grygorii.strashko@ti.com>
From: Grygorii Strashko <grygorii.strashko@ti.com>
Date: Thu, 7 Apr 2016 15:16:42 +0300
> This clean up series intended to:
> - fix port_mask parameters in ale calls and drop unnecessary shifts
> - drop host_port field from struct cpsw_priv
>
> Nothing critical. Tested on am437x-idk-evm in dual mac and switch modes.
Looks good, series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] vxlan: fix incorrect type
From: David Miller @ 2016-04-11 19:04 UTC (permalink / raw)
To: jbenc; +Cc: netdev, dan.carpenter
In-Reply-To: <b870830205240e7eb0732ddfdaa6534ab061fb1c.1460387151.git.jbenc@redhat.com>
From: Jiri Benc <jbenc@redhat.com>
Date: Mon, 11 Apr 2016 17:06:08 +0200
> The protocol is 16bit, not 32bit.
>
> Fixes: e1e5314de08ba ("vxlan: implement GPE")
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: fjes: Use resource_size
From: David Miller @ 2016-04-11 19:02 UTC (permalink / raw)
To: vaishali.thakkar; +Cc: izumi.taku, netdev, linux-kernel
In-Reply-To: <1460370497-10221-1-git-send-email-vaishali.thakkar@oracle.com>
From: Vaishali Thakkar <vaishali.thakkar@oracle.com>
Date: Mon, 11 Apr 2016 15:58:17 +0530
> Use the function resource_size instead of explicit computation.
>
> Problem found using Coccinelle.
>
> Signed-off-by: Vaishali Thakkar <vaishali.thakkar@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH RFT 2/2] macb: kill PHY reset code
From: Sergei Shtylyov @ 2016-04-11 19:01 UTC (permalink / raw)
To: Andrew Lunn
Cc: nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160411185115.GA30623-g2DYL2Zd6BY@public.gmane.org>
On 04/11/2016 09:51 PM, Andrew Lunn wrote:
>>>>> The code you are deleting would of ignored the flags in the gpio
>>>>> property, i.e. active low.
>>>>
>>>> Hm, you're right -- I forgot about that... :-/
>>>>
>>>>> The new code in the previous patch does
>>>>> however take the flags into account. Did you check if there are any
>>>>> device trees which have flags, which were never used, but are now
>>>>> going to be used and thus break...
>>>>
>>>> Checked this now and found out arch/arm/boot/dts/ar91-vinco.dts.
>>>> Looks like it needs to be fixed indeed...
>>>>
>>> And this is where it gets tricky. You are breaking backwards
>>> compatibility by now respecting the flag. An old DT blob is not going
>>> to work.
>>
>> Do we care that much about the DT blobs that are just *wrong*?
>
> Wrong, but currently works.
Note that it's not only using GPIO_ACTIVE_HIGH but does that against what
the MACB binding documents.
>>> You potentially need to add a new property and deprecate the old one.
>>
>> I would like to avoid that...
>
> You will need the agreement from the at91-vinco maintainer.
I'll try submitting a formal DT patch...
> Andrew
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 0/4] bnxt_en: Update for net-next
From: David Miller @ 2016-04-11 18:59 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1460362274-21771-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Mon, 11 Apr 2016 04:11:10 -0400
> Misc. changes for link speed and VF MAC address change.
Applied, thanks Michael.
^ permalink raw reply
* Re: [Lsf] [Lsf-pc] [LSF/MM TOPIC] Generic page-pool recycle facility?
From: Bart Van Assche @ 2016-04-11 18:53 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Thadeu Lima de Souza Cascardo
Cc: lsf@lists.linux-foundation.org, netdev@vger.kernel.org,
Brenden Blanco, James Bottomley, linux-mm, Mel Gorman,
Tom Herbert, Matthew Wilcox, lsf-pc@lists.linux-foundation.org,
Mel Gorman, Alexei Starovoitov
In-Reply-To: <20160411203738.58a6adb2@redhat.com>
On 04/11/2016 11:37 AM, Jesper Dangaard Brouer wrote:
> On Mon, 11 Apr 2016 14:46:25 -0300
> Thadeu Lima de Souza Cascardo <cascardo@redhat.com> wrote:
>
>> So, Jesper, please take into consideration that this pool design
>> would rather be per device. Otherwise, we allow some device to write
>> into another's device/driver memory.
>
> Yes, that was my intended use. I want to have a page-pool per device.
> I actually, want to go as far as a page-pool per NIC HW RX-ring queue.
>
> Because the other use-case for the page-pool is zero-copy RX.
>
> The NIC HW trick is that we today can create a HW filter in the NIC
> (via ethtool) and place that traffic into a separate RX queue in the
> NIC. Lets say matching NFS traffic or guest traffic. Then we can allow
> RX zero-copy of these pages, into the application/guest, somehow
> binding it to RX queue, e.g. introducing a "cross-domain-id" in the
> page-pool page that need to match.
I think it is important to keep in mind that using a page pool for
zero-copy RX is specific to protocols that are based on TCP/IP.
Protocols like FC, SRP and iSER have been designed such that the side
that allocates the buffers also initiates the data transfer (the target
side). With TCP/IP however transferring data and allocating receive
buffers happens by opposite sides of the connection.
Bart.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH RFT 2/2] macb: kill PHY reset code
From: Andrew Lunn @ 2016-04-11 18:51 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <570BEF46.7060105-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On Mon, Apr 11, 2016 at 09:39:02PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 04/11/2016 09:19 PM, Andrew Lunn wrote:
>
> >>>The code you are deleting would of ignored the flags in the gpio
> >>>property, i.e. active low.
> >>
> >> Hm, you're right -- I forgot about that... :-/
> >>
> >>>The new code in the previous patch does
> >>>however take the flags into account. Did you check if there are any
> >>>device trees which have flags, which were never used, but are now
> >>>going to be used and thus break...
> >>
> >> Checked this now and found out arch/arm/boot/dts/ar91-vinco.dts.
> >>Looks like it needs to be fixed indeed...
> >>
> >And this is where it gets tricky. You are breaking backwards
> >compatibility by now respecting the flag. An old DT blob is not going
> >to work.
>
> Do we care that much about the DT blobs that are just *wrong*?
Wrong, but currently works.
> >You potentially need to add a new property and deprecate the old one.
>
> I would like to avoid that...
You will need the agreement from the at91-vinco maintainer.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RFT 2/2] macb: kill PHY reset code
From: Sergei Shtylyov @ 2016-04-11 18:39 UTC (permalink / raw)
To: Andrew Lunn; +Cc: nicolas.ferre, netdev, linux-kernel, devicetree
In-Reply-To: <20160411181904.GB29709@lunn.ch>
Hello.
On 04/11/2016 09:19 PM, Andrew Lunn wrote:
>>> The code you are deleting would of ignored the flags in the gpio
>>> property, i.e. active low.
>>
>> Hm, you're right -- I forgot about that... :-/
>>
>>> The new code in the previous patch does
>>> however take the flags into account. Did you check if there are any
>>> device trees which have flags, which were never used, but are now
>>> going to be used and thus break...
>>
>> Checked this now and found out arch/arm/boot/dts/ar91-vinco.dts.
>> Looks like it needs to be fixed indeed...
>>
> And this is where it gets tricky. You are breaking backwards
> compatibility by now respecting the flag. An old DT blob is not going
> to work.
Do we care that much about the DT blobs that are just *wrong*?
> You potentially need to add a new property and deprecate the old one.
I would like to avoid that...
> Andrew
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] mwifiex: fix possible NULL dereference
From: Christian Daudt @ 2016-04-11 18:38 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Sudip Mukherjee
In-Reply-To: <1460388459-21090-1-git-send-email-sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Apr 11, 2016 at 8:27 AM, Sudip Mukherjee
<sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> From: Sudip Mukherjee <sudip.mukherjee-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org>
>
> We have a check for card just after dereferencing it. So if it is NULL
> we have already dereferenced it before its check. Lets dereference it
> after checking card for NULL.
>
> Signed-off-by: Sudip Mukherjee <sudip.mukherjee-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org>
> ---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index edf8b07..84562d0 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -2884,10 +2884,11 @@ static void mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
> {
> struct pcie_service_card *card = adapter->card;
> const struct mwifiex_pcie_card_reg *reg;
> - struct pci_dev *pdev = card->dev;
> + struct pci_dev *pdev;
you might want to move the variable declaration into the if block
below to avoid it being left undefined
> int i;
>
> if (card) {
> + pdev = card->dev;
to here
+ struct pci_dev pdev = card->dev;
>
> if (card->msix_enable) {
> for (i = 0; i < MWIFIEX_NUM_MSIX_VECTORS; i++)
> synchronize_irq(card->msix_entries[i].vector);
>
cheers,
csd
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Lsf] [Lsf-pc] [LSF/MM TOPIC] Generic page-pool recycle facility?
From: Jesper Dangaard Brouer @ 2016-04-11 18:37 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: Matthew Wilcox, Mel Gorman, James Bottomley,
netdev@vger.kernel.org, Brenden Blanco, lsf, linux-mm, Mel Gorman,
Tom Herbert, lsf-pc, Alexei Starovoitov, brouer
In-Reply-To: <20160411174625.GH1845@indiana.gru.redhat.com>
On Mon, 11 Apr 2016 14:46:25 -0300
Thadeu Lima de Souza Cascardo <cascardo@redhat.com> wrote:
> So, Jesper, please take into consideration that this pool design
> would rather be per device. Otherwise, we allow some device to write
> into another's device/driver memory.
Yes, that was my intended use. I want to have a page-pool per device.
I actually, want to go as far as a page-pool per NIC HW RX-ring queue.
Because the other use-case for the page-pool is zero-copy RX.
The NIC HW trick is that we today can create a HW filter in the NIC
(via ethtool) and place that traffic into a separate RX queue in the
NIC. Lets say matching NFS traffic or guest traffic. Then we can allow
RX zero-copy of these pages, into the application/guest, somehow
binding it to RX queue, e.g. introducing a "cross-domain-id" in the
page-pool page that need to match.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net v2] net: sched: do not requeue a NULL skb
From: Eric Dumazet @ 2016-04-11 18:30 UTC (permalink / raw)
To: Cong Wang
Cc: Lars Persson, Lars Persson, Linux Kernel Network Developers,
Jamal Hadi Salim, LKML
In-Reply-To: <1460399171.6473.562.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, 2016-04-11 at 11:26 -0700, Eric Dumazet wrote:
> On Mon, 2016-04-11 at 11:02 -0700, Cong Wang wrote:
>
> > I am fine with either way as long as the loop stops on failure.
Note that skb that could not be validated is already freed.
So I do not see any value from stopping the loop, since
we need to schedule the queue to avoid tx hang.
Just process following skb if there is one, fact that skb is sent or
dropped does not matter.
^ 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