* Re: [PATCH net-next 0/4] net: switchdev: Avoid sleep in atomic with DSA
From: Florian Fainelli @ 2017-01-11 1:42 UTC (permalink / raw)
To: Ido Schimmel, Jiri Pirko; +Cc: netdev, davem, vivien.didelot, andrew
In-Reply-To: <20170110160852.GA18050@splinter.mtl.com>
On 01/10/2017 08:08 AM, Ido Schimmel wrote:
> On Tue, Jan 10, 2017 at 03:18:07PM +0100, Jiri Pirko wrote:
>> Tue, Jan 10, 2017 at 02:25:06PM CET, idosch@idosch.org wrote:
>>> On Tue, Jan 10, 2017 at 01:08:46PM +0100, Jiri Pirko wrote:
>>>> Mon, Jan 09, 2017 at 10:14:36PM CET, idosch@idosch.org wrote:
>>>>> On Mon, Jan 09, 2017 at 12:56:48PM -0800, Florian Fainelli wrote:
>>>>>> On 01/09/2017 12:48 PM, Ido Schimmel wrote:
>>>>>>> Hi Florian,
>>>>>>>
>>>>>>> On Mon, Jan 09, 2017 at 11:44:59AM -0800, Florian Fainelli wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> This patch series is to resolve a sleeping function called in atomic context
>>>>>>>> debug splat that we observe with DSA.
>>>>>>>>
>>>>>>>> Let me know what you think, I was also wondering if we should just always
>>>>>>>> make switchdev_port_vlan_fill() set SWITCHDEV_F_DEFER, but was afraid this
>>>>>>>> could cause invalid contexts to be used for rocker, mlxsw, i40e etc.
>>>>>>>
>>>>>>> Isn't this a bit of overkill? All the drivers you mention fill the VLAN
>>>>>>> dump from their cache and don't require sleeping. Even b53 that you
>>>>>>> mention in the last patch does that, but reads the PVID from the device,
>>>>>>> which entails taking a mutex.
>>>>>>
>>>>>> Correct.
>>>>>>
>>>>>>>
>>>>>>> Can't you just cache the PVID as well? I think this will solve your
>>>>>>> problem. Didn't look too much into the b53 code, so maybe I'm missing
>>>>>>> something. Seems that mv88e6xxx has a similar problem.
>>>>>>
>>>>>> I suppose we could indeed cache the PVID for b53, but for mv88e6xxx it
>>>>>> seems like we need to perform a bunch of VTU operations, and those
>>>>>> access HW registers, Andrew, Vivien, how do you want to solve that, do
>>>>>> we want to introduce a general VLAN cache somewhere in switchdev/DSA/driver?
>>>>>
>>>>> Truth be told, I don't quite understand why switchdev infra even tries
>>>>> to dump the VLANs from the device. Like, in which situations is this
>>>>> going to be different from what the software bridge reports? Sure, you
>>>>> can set the VLAN filters with SELF and skip the software bridge, but how
>>>>> does that make sense in a model where you want to reflect the software
>>>>> datapath?
>>>>
>>>> But the vlans added by rtnl_bridge_setlink & SELF are not tracked by the
>>>> bridge and therefore driver needs to dump them. You would have to pass
>>>> some flag down to driver when adding SWITCHDEV_OBJ_ID_PORT_VLAN
>>>> indicating the need to track the vlan and dump it. Right?
>>>
>>> Right, but back to my question - what's the use case for the SELF flag
>>> in the switchdev model? Why would I configure a VLAN filter in the
>>> hardware but not in the software bridge? The whole point is reflecting
>>> the software bridge to the hardware.
>>
>> I agree. For the bridge-switchdev usecase, I don't see a reason to use
>> SELF for vlans as well. Do you suggest to simply remove this possibility?
>
> Yes. This would also solve Florian's problem.
>
> Florian, what do you think?
I don't really see a value for configuring a VLAN in HW exclusively and
not at the SW bridge level as well (unless you wanted some kind of
discarding of packets?). Even with the patch proposed a while back to
decouple the bridge master device, we would still end up with the same
VLAN attributes programmed in HW and SW.
Vivien, Andrew, are you aware of an use case where we have the HW
programmed with a superset of VLANs wrt. the SW bridge?
--
Florian
^ permalink raw reply
* Re: [PATCH] net: qrtr: Mark 'buf' as little endian
From: David Miller @ 2017-01-11 1:45 UTC (permalink / raw)
To: sboyd; +Cc: linux-kernel, netdev, bjorn.andersson
In-Reply-To: <20170109223158.29255-1-sboyd@codeaurora.org>
From: Stephen Boyd <sboyd@codeaurora.org>
Date: Mon, 9 Jan 2017 14:31:58 -0800
> Failure to mark this pointer as __le32 causes checkers like
> sparse to complain:
>
> net/qrtr/qrtr.c:274:16: warning: incorrect type in assignment (different base types)
> net/qrtr/qrtr.c:274:16: expected unsigned int [unsigned] [usertype] <noident>
> net/qrtr/qrtr.c:274:16: got restricted __le32 [usertype] <noident>
> net/qrtr/qrtr.c:275:16: warning: incorrect type in assignment (different base types)
> net/qrtr/qrtr.c:275:16: expected unsigned int [unsigned] [usertype] <noident>
> net/qrtr/qrtr.c:275:16: got restricted __le32 [usertype] <noident>
> net/qrtr/qrtr.c:276:16: warning: incorrect type in assignment (different base types)
> net/qrtr/qrtr.c:276:16: expected unsigned int [unsigned] [usertype] <noident>
> net/qrtr/qrtr.c:276:16: got restricted __le32 [usertype] <noident>
>
> Silence it.
>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH next v2] ipvlan: improvise dev_id generation logic in IPvlan
From: David Miller @ 2017-01-11 1:47 UTC (permalink / raw)
To: mahesh; +Cc: netdev, maheshb, edumazet, davem
In-Reply-To: <20170109230554.38328-1-mahesh@bandewar.net>
From: Mahesh Bandewar <mahesh@bandewar.net>
Date: Mon, 9 Jan 2017 15:05:54 -0800
> From: Mahesh Bandewar <maheshb@google.com>
>
> The patch 009146d117b ("ipvlan: assign unique dev-id for each slave
> device.") used ida_simple_get() to generate dev_ids assigned to the
> slave devices. However (Eric has pointed out that) there is a shortcoming
> with that approach as it always uses the first available ID. This
> becomes a problem when a slave gets deleted and a new slave gets added.
> The ID gets reassigned causing the new slave to get the same link-local
> address. This side-effect is undesirable.
>
> This patch adds a per-port variable that keeps track of the IDs
> assigned and used as the stat-base for the IDR api. This base will be
> wrapped around when it reaches the MAX (0xFFFE) value possibly on a
> busy system where slaves are added and deleted routinely.
>
> Fixes: 009146d117b ("ipvlan: assign unique dev-id for each slave device.")
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> CC: Eric Dumazet <edumazet@google.com>
> CC: David Miller <davem@davemloft.org>
> ---
> v1 -> v2
> Implemented Dave's comments and reinstated IDR API.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: add the AF_QIPCRTR entries to family name tables
From: David Miller @ 2017-01-11 1:52 UTC (permalink / raw)
To: s-anna; +Cc: netdev, linux-kernel, courtney.cavin, bjorn.andersson
In-Reply-To: <20170110034856.49721-1-s-anna@ti.com>
From: Suman Anna <s-anna@ti.com>
Date: Mon, 9 Jan 2017 21:48:56 -0600
> Commit bdabad3e363d ("net: Add Qualcomm IPC router") introduced a
> new address family. Update the family name tables accordingly so
> that the lockdep initialization can use the proper names for this
> family.
>
> Cc: Courtney Cavin <courtney.cavin@sonymobile.com>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Suman Anna <s-anna@ti.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 3/4] net: ethernet: ti: cpsw: don't duplicate ndev_running
From: Ivan Khoronzhuk @ 2017-01-11 1:56 UTC (permalink / raw)
To: Grygorii Strashko; +Cc: netdev, mugunthanvnm, linux-omap, linux-kernel
In-Reply-To: <c6dfedc3-d346-b9a4-f398-96ac7e57d0b8@ti.com>
On Mon, Jan 09, 2017 at 11:25:38AM -0600, Grygorii Strashko wrote:
>
>
> On 01/08/2017 10:41 AM, Ivan Khoronzhuk wrote:
> > No need to create additional vars to identify if interface is running.
> > So simplify code by removing redundant var and checking usage counter
> > instead.
> >
> > Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> > ---
> > drivers/net/ethernet/ti/cpsw.c | 14 ++++----------
> > 1 file changed, 4 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> > index 40d7fc9..daae87f 100644
> > --- a/drivers/net/ethernet/ti/cpsw.c
> > +++ b/drivers/net/ethernet/ti/cpsw.c
> > @@ -357,7 +357,6 @@ struct cpsw_slave {
> > struct phy_device *phy;
> > struct net_device *ndev;
> > u32 port_vlan;
> > - u32 open_stat;
> > };
> >
> > static inline u32 slave_read(struct cpsw_slave *slave, u32 offset)
> > @@ -1241,7 +1240,7 @@ static int cpsw_common_res_usage_state(struct cpsw_common *cpsw)
> > u32 usage_count = 0;
> >
> > for (i = 0; i < cpsw->data.slaves; i++)
> > - if (cpsw->slaves[i].open_stat)
> > + if (netif_running(cpsw->slaves[i].ndev))
> > usage_count++;
>
> Not sure this will work as you expected, but may be I've missed smth :(
I've changed conditions, will work.
>
> code in static int __dev_open(struct net_device *dev)
> ..
> set_bit(__LINK_STATE_START, &dev->state);
>
> if (ops->ndo_validate_addr)
> ret = ops->ndo_validate_addr(dev);
>
> if (!ret && ops->ndo_open)
> ret = ops->ndo_open(dev);
>
> netpoll_poll_enable(dev);
>
> if (ret)
> clear_bit(__LINK_STATE_START, &dev->state);
> ..
>
> so, netif_running(ndev) will start returning true before calling ops->ndo_open(dev);
Yes, It's done bearing it in mind of course.
>
> >
> > return usage_count;
> > @@ -1502,7 +1501,7 @@ static int cpsw_ndo_open(struct net_device *ndev)
> > CPSW_RTL_VERSION(reg));
> >
> > /* initialize host and slave ports */
> > - if (!cpsw_common_res_usage_state(cpsw))
> > + if (cpsw_common_res_usage_state(cpsw) < 2)
>
> Ah. You've changed the condition here.
>
> I think it might be reasonable to hide this inside cpsw_common_res_usage_state()
> and seems it can be renamed to smth like cpsw_is_running().
It probably needs to be renamed to smth a little different,
like cpsw_get_usage_count ...or cpsw_get_open_ndev_count
>
>
> > cpsw_init_host_port(priv);
> > for_each_slave(priv, cpsw_slave_open, priv);
> >
> > @@ -1513,7 +1512,7 @@ static int cpsw_ndo_open(struct net_device *ndev)
> > cpsw_ale_add_vlan(cpsw->ale, cpsw->data.default_vlan,
> > ALE_ALL_PORTS, ALE_ALL_PORTS, 0, 0);
> >
> > - if (!cpsw_common_res_usage_state(cpsw)) {
> > + if (cpsw_common_res_usage_state(cpsw) < 2) {
> > /* disable priority elevation */
> > __raw_writel(0, &cpsw->regs->ptype);
> >
> > @@ -1556,9 +1555,6 @@ static int cpsw_ndo_open(struct net_device *ndev)
> > cpdma_ctlr_start(cpsw->dma);
> > cpsw_intr_enable(cpsw);
> >
> > - if (cpsw->data.dual_emac)
> > - cpsw->slaves[priv->emac_port].open_stat = true;
> > -
> > return 0;
> >
> > err_cleanup:
> > @@ -1578,7 +1574,7 @@ static int cpsw_ndo_stop(struct net_device *ndev)
> > netif_tx_stop_all_queues(priv->ndev);
> > netif_carrier_off(priv->ndev);
> >
> > - if (cpsw_common_res_usage_state(cpsw) <= 1) {
> > + if (!cpsw_common_res_usage_state(cpsw)) {
>
> and here __LINK_STATE_START will be cleared before calling ops->ndo_stop(dev);
Actually it's changed because of it.
> So, from one side netif_running(ndev) usage will simplify cpsw_common_res_usage_state() internals,
> but from another side - it will make places where it's used even more entangled :( as for me,
> because when cpsw_common_res_usage_state() will return 1 in cpsw_ndo_open() it will mean
> "no interfaces is really running yet", but the same value 1 in cpsw_ndo_stop()
why not? no interfaces running, except the one excuting ndo_open now.
It's more clear then duplicating it and using two different ways in
different places for identifing running devices. Current way more
close to some testing code, not final version. Just to be consistent
better to change it.
Yes, it returns different results when it's called from ndo_close and
ndo_open. Maybe name for the function is not very close to an action
it's doing, it declares more intention, and even not for every case.
What about to rename it to some cpsw_get_open_ndev_count and add
comments in several places explaining what it actually do.
> will mean "there are still one is running".
>
> > napi_disable(&cpsw->napi_rx);
> > napi_disable(&cpsw->napi_tx);
> > cpts_unregister(cpsw->cpts);
> > @@ -1592,8 +1588,6 @@ static int cpsw_ndo_stop(struct net_device *ndev)
> > cpsw_split_res(ndev);
> >
> > pm_runtime_put_sync(cpsw->dev);
> > - if (cpsw->data.dual_emac)
> > - cpsw->slaves[priv->emac_port].open_stat = false;
> > return 0;
> > }
> >
> >
>
> --
> regards,
> -grygorii
^ permalink raw reply
* Re: [PATCH net] ipv6: sr: fix BUG in HMAC init when preemption is enabled
From: David Miller @ 2017-01-11 2:00 UTC (permalink / raw)
To: david.lebrun; +Cc: netdev
In-Reply-To: <1484055562-6414-1-git-send-email-david.lebrun@uclouvain.be>
From: David Lebrun <david.lebrun@uclouvain.be>
Date: Tue, 10 Jan 2017 14:39:22 +0100
> When CONFIG_PREEMPT=y, CONFIG_IPV6=m and CONFIG_SEG6_HMAC=y,
> seg6_hmac_init() is called during the initialization of the ipv6 module.
> This causes a subsequent call to smp_processor_id() with preemption
> enabled, resulting in the following trace.
...
> This patch disable BHs in seg6_hmac_init() and seg6_hmac_exit(). BHs are
> re-enabled for the call to crypto_alloc_shash. Indeed, this function might
> call try_module_get(), which cannot be called in atomic context.
>
> Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
...
> - char *ring = kzalloc(SEG6_HMAC_RING_SIZE, GFP_KERNEL);
> + char *ring = kzalloc(SEG6_HMAC_RING_SIZE, GFP_ATOMIC);
I agree with Eric that moving to GFP_ATOMIC in this spots is a major step
backwards, and that fixing the per-cpu access during this initializer
is a much better direction to go.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] bpf: Remove unused but set variable in __bpf_lru_list_shrink_inactive()
From: David Miller @ 2017-01-11 2:01 UTC (permalink / raw)
To: tklauser; +Cc: netdev, ast, kafai
In-Reply-To: <20170110140207.26480-1-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Tue, 10 Jan 2017 15:02:07 +0100
> Remove the unused but set variable 'first_node' in
> __bpf_lru_list_shrink_inactive() to fix the following GCC warning when
> building with 'W=1':
>
> kernel/bpf/bpf_lru_list.c:216:41: warning: variable ‘first_node’ set but not used [-Wunused-but-set-variable]
>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bpf: Make unnecessarily global functions static
From: David Miller @ 2017-01-11 2:01 UTC (permalink / raw)
To: tklauser; +Cc: netdev, ast, kafai
In-Reply-To: <20170110140216.26550-1-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Tue, 10 Jan 2017 15:02:16 +0100
> Make the functions __local_list_pop_free(), __local_list_pop_pending(),
> bpf_common_lru_populate() and bpf_percpu_lru_populate() static as they
> are not used outide of bpf_lru_list.c
>
> This fixes the following GCC warnings when building with 'W=1':
>
> kernel/bpf/bpf_lru_list.c:363:22: warning: no previous prototype for ‘__local_list_pop_free’ [-Wmissing-prototypes]
> kernel/bpf/bpf_lru_list.c:376:22: warning: no previous prototype for ‘__local_list_pop_pending’ [-Wmissing-prototypes]
> kernel/bpf/bpf_lru_list.c:560:6: warning: no previous prototype for ‘bpf_common_lru_populate’ [-Wmissing-prototypes]
> kernel/bpf/bpf_lru_list.c:577:6: warning: no previous prototype for ‘bpf_percpu_lru_populate’ [-Wmissing-prototypes]
>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] packet: pdiag_put_ring() should return TX_RING info for TPACKET_V3
From: David Miller @ 2017-01-11 2:03 UTC (permalink / raw)
To: sowmini.varadhan; +Cc: netdev, daniel, willemb
In-Reply-To: <b1ae12eaef34ce413e2dc3bc5075a3c0198d7ad1.1484060892.git.sowmini.varadhan@oracle.com>
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Tue, 10 Jan 2017 07:47:15 -0800
> Commit 7f953ab2ba46 ("af_packet: TX_RING support for TPACKET_V3")
> now makes it possible to use TX_RING with TPACKET_V3, so make the
> the relevant information available via 'ss -e -a --packet'
>
> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] netvsc: add rcu_read locking to netvsc callback
From: David Miller @ 2017-01-11 2:06 UTC (permalink / raw)
To: stephen; +Cc: netdev, sthemmin
In-Reply-To: <20170110155016.4897-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 10 Jan 2017 07:50:16 -0800
> Lockdep finds a case where netvsc receive processing is incorrectly
> assuming it is in RCU safe zone. The driver is using RCU to handle
> VF reference but RCU read lock not held.
>
> Fixes 0c9d3ba9a87b ("hv_netvsc: use RCU to protect vf_netdev")
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Fixes tag must have a colon character after "Fixes", you must also
not put any empty lines in between the Fixes tag and the other
tags like signoffs.
Futhermore 0c9d3ba9a87b is not a valid GIT SHA1 ID.
[davem@kkuri net]$ git describe 0c9d3ba9a87b
fatal: Not a valid object name 0c9d3ba9a87b
^ permalink raw reply
* Re: [PATCH net 1/1] net/af_iucv: don't use paged skbs for TX on HiperSockets
From: David Miller @ 2017-01-11 2:07 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, stable
In-Reply-To: <20170110161034.82445-2-ubraun@linux.vnet.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Tue, 10 Jan 2017 17:10:34 +0100
> From: Julian Wiedmann <jwi@linux.vnet.ibm.com>
>
> With commit e53743994e21
> ("af_iucv: use paged SKBs for big outbound messages"),
> we transmit paged skbs for both of AF_IUCV's transport modes
> (IUCV or HiperSockets).
> The qeth driver for Layer 3 HiperSockets currently doesn't
> support NETIF_F_SG, so these skbs would just be linearized again
> by the stack.
> Avoid that overhead by using paged skbs only for IUCV transport.
>
> cc stable, since this also circumvents a significant skb leak when
> sending large messages (where the skb then needs to be linearized).
>
> Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
> Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
> Cc: <stable@vger.kernel.org> # v4.8+
> Fixes: e53743994e21 ("af_iucv: use paged SKBs for big outbound messages")
Applied.
^ permalink raw reply
* Re: [PATCH] vxlan: Set flow*_dport when doing route lookups
From: David Miller @ 2017-01-11 2:10 UTC (permalink / raw)
To: martynas; +Cc: netdev
In-Reply-To: <20170110172945.24676-1-martynas@weave.works>
From: Martynas Pumputis <martynas@weave.works>
Date: Tue, 10 Jan 2017 17:29:45 +0000
> Otherwise, no xfrm policy with dport being set can be matched.
>
> Signed-off-by: Martynas Pumputis <martynas@weave.works>
And likewise you should also be adding the source port, since it is
available, to the route lookup as well.
^ permalink raw reply
* Re: [PATCH net v2] mlx4: Return EOPNOTSUPP instead of ENOTSUPP
From: David Miller @ 2017-01-11 2:17 UTC (permalink / raw)
To: kafai; +Cc: netdev, saeedm, tariqt, kernel-team
In-Reply-To: <1484070109-105991-1-git-send-email-kafai@fb.com>
From: Martin KaFai Lau <kafai@fb.com>
Date: Tue, 10 Jan 2017 09:41:49 -0800
> In commit b45f0674b997 ("mlx4: xdp: Allow raising MTU up to one page minus eth and vlan hdrs"),
> it changed EOPNOTSUPP to ENOTSUPP by mistake. This patch fixes it.
>
> Fixes: b45f0674b997 ("mlx4: xdp: Allow raising MTU up to one page minus eth and vlan hdrs")
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 5/8] net: dsa: Export dev_to_net_device()
From: David Miller @ 2017-01-11 2:24 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, jason, andrew, sebastian.hesselbarth, gregory.clement,
linux, vivien.didelot, tremyfr, schwidefsky, gregkh, stuart.yoder,
ingo.tuchscherer, linux-arm-kernel, linux-kernel
In-Reply-To: <20170110201235.21771-6-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 10 Jan 2017 12:12:32 -0800
> @@ -491,7 +491,7 @@ struct mii_bus *dsa_host_dev_to_mii_bus(struct device *dev)
> }
> EXPORT_SYMBOL_GPL(dsa_host_dev_to_mii_bus);
>
> -static struct net_device *dev_to_net_device(struct device *dev)
> +struct net_device *dev_to_net_device(struct device *dev)
> {
> struct device *d;
>
> @@ -508,6 +508,7 @@ static struct net_device *dev_to_net_device(struct device *dev)
>
> return NULL;
> }
> +EXPORT_SYMBOL_GPL(dev_to_net_device);
Something like this, a public interface with a very high level generic name,
doesn't belong in the DSA layer. It belongs in net/core/dev.c or something
like that.
^ permalink raw reply
* Re: [PATCH net] gro: Enter slow-path if there is no tailroom
From: David Miller @ 2017-01-11 2:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, herbert, slavash, willemb, edumazet
In-Reply-To: <1484079841.21472.35.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 10 Jan 2017 12:24:01 -0800
> From: Herbert Xu <herbert@gondor.apana.org.au>
>
> The GRO path has a fast-path where we avoid calling pskb_may_pull
> and pskb_expand by directly accessing frag0. However, this should
> only be done if we have enough tailroom in the skb as otherwise
> we'll have to expand it later anyway.
>
> This patch adds the check by capping frag0_len with the skb tailroom.
>
> Fixes: cb18978cbf45 ("gro: Open-code final pskb_may_pull")
> Reported-by: Slava Shwartsman <slavash@mellanox.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] gro: Disable frag0 optimization on IPv6 ext headers
From: David Miller @ 2017-01-11 2:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, herbert, slavash, willemb, edumazet
In-Reply-To: <1484079855.21472.36.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 10 Jan 2017 12:24:15 -0800
> From: Herbert Xu <herbert@gondor.apana.org.au>
>
> The GRO fast path caches the frag0 address. This address becomes
> invalid if frag0 is modified by pskb_may_pull or its variants.
> So whenever that happens we must disable the frag0 optimization.
>
> This is usually done through the combination of gro_header_hard
> and gro_header_slow, however, the IPv6 extension header path did
> the pulling directly and would continue to use the GRO fast path
> incorrectly.
>
> This patch fixes it by disabling the fast path when we enter the
> IPv6 extension header path.
>
> Fixes: 78a478d0efd9 ("gro: Inline skb_gro_header and cache frag0 virtual address")
> Reported-by: Slava Shwartsman <slavash@mellanox.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net 00/10] Mellanox mlx5 fixes and cleanups 2017-01-10
From: David Miller @ 2017-01-11 2:35 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <1484080419-24256-1-git-send-email-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Tue, 10 Jan 2017 22:33:29 +0200
> This series includes some mlx5e general cleanups from Daniel, Gil, Hadar
> and myself.
> Also it includes some critical mlx5e TC offloads fixes from Or Gerlitz.
Series applied, thanks.
> For -stable:
> - net/mlx5e: Remove WARN_ONCE from adaptive moderation code
>
> Although this fix doesn't affect any functionality, I thought it is
> better to clean this -WARN_ONCE- up for -stable in case someone hits
> such corner case.
Queued up for -stable, thanks.
^ permalink raw reply
* Re: linux-next: build failure after merge of the selinux tree
From: Paul Moore @ 2017-01-11 3:11 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, linux-next, linux-kernel, Ursula Braun,
Stephen Smalley
In-Reply-To: <20170110122703.2dbdfd18@canb.auug.org.au>
On Mon, Jan 9, 2017 at 8:27 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Paul,
>
> After merging the selinux tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from /home/sfr/next/next/security/selinux/avc.c:35:0:
> /home/sfr/next/next/security/selinux/include/classmap.h:242:2: error: #error New address family defined, please update secclass_map.
> #error New address family defined, please update secclass_map.
> ^
> /home/sfr/next/next/security/selinux/hooks.c: In function 'socket_type_to_security_class':
> /home/sfr/next/next/security/selinux/hooks.c:1409:2: error: #error New address family defined, please update this function.
>
> Caused by commit
>
> da69a5306ab9 ("selinux: support distinctions among all network address families")
>
> interacting with commit
>
> ac7138746e14 ("smc: establish new socket family")
>
> from the net-next tree.
>
> I added the following merge fix patch:
Thanks Stephen.
There are still some concerns around which protocol/address families
require their own SELinux object class, but it looks like SMC should
have it's own object class. If the "selinux: support distinctions
among all network address families" commit doesn't go up to Linus
during the next merge window I'll make sure it is updated for PF_SMC.
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 10 Jan 2017 12:22:21 +1100
> Subject: [PATCH] selinux: merge fix for "smc: establish new socket family"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> security/selinux/hooks.c | 4 +++-
> security/selinux/include/classmap.h | 4 +++-
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index bada3cd42b9c..712fd0e7c91d 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1405,7 +1405,9 @@ static inline u16 socket_type_to_security_class(int family, int type, int protoc
> return SECCLASS_KCM_SOCKET;
> case PF_QIPCRTR:
> return SECCLASS_QIPCRTR_SOCKET;
> -#if PF_MAX > 43
> + case PF_SMC:
> + return SECCLASS_SMC_SOCKET;
> +#if PF_MAX > 44
> #error New address family defined, please update this function.
> #endif
> }
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index 0dfd26d0b8d8..40f1d4f8bc2a 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -235,9 +235,11 @@ struct security_class_mapping secclass_map[] = {
> { COMMON_SOCK_PERMS, NULL } },
> { "qipcrtr_socket",
> { COMMON_SOCK_PERMS, NULL } },
> + { "smc_socket",
> + { COMMON_SOCK_PERMS, NULL } },
> { NULL }
> };
>
> -#if PF_MAX > 43
> +#if PF_MAX > 44
> #error New address family defined, please update secclass_map.
> #endif
> --
> 2.10.2
>
> --
> Cheers,
> Stephen Rothwell
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256
From: Andy Lutomirski @ 2017-01-11 3:11 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Andy Lutomirski, Netdev, LKML, Linux Crypto Mailing List,
Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Alexei Starovoitov
In-Reply-To: <58758169.2020408@iogearbox.net>
On Tue, Jan 10, 2017 at 4:50 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 01/11/2017 12:24 AM, Andy Lutomirski wrote:
>>
>> This makes it easier to add another digest algorithm down the road if
>> needed. It also serves to force any programs that might have been
>> written against a kernel that had the old field name to notice the
>> change and make any necessary changes.
>>
>> This shouldn't violate any stable API policies, as no released kernel
>> has ever had TCA*BPF_DIGEST.
>
>
> Imho, this and patch 6/8 is not really needed. Should there ever
> another digest alg be used (doubt it), then you'd need a new nl
> attribute and fdinfo line anyway to keep existing stuff intact.
> Nobody made the claim that you can just change this underneath
> and not respecting abi for existing applications when I read from
> above that such apps now will get "forced" to notice a change.
Fair enough. I was more concerned about prerelease iproute2 versions,
but maybe that's a nonissue. I'll drop these two patches.
--Andy
^ permalink raw reply
* [net:master 16/18] net/core/dev.c:4444:33: note: in expansion of macro 'min'
From: kbuild test robot @ 2017-01-11 3:25 UTC (permalink / raw)
To: Herbert Xu; +Cc: kbuild-all, netdev, Eric Dumazet
[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
head: 6c711c8691bf91d0e830ff4215b08e51c0626769
commit: 1272ce87fa017ca4cf32920764d879656b7a005a [16/18] gro: Enter slow-path if there is no tailroom
config: i386-randconfig-x004-201702 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 1272ce87fa017ca4cf32920764d879656b7a005a
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from include/linux/sched.h:17:0,
from include/linux/uaccess.h:4,
from net/core/dev.c:75:
net/core/dev.c: In function 'skb_gro_reset_offset':
include/linux/kernel.h:753:16: warning: comparison of distinct pointer types lacks a cast
(void) (&min1 == &min2); \
^
include/linux/kernel.h:756:2: note: in expansion of macro '__min'
__min(typeof(x), typeof(y), \
^~~~~
>> net/core/dev.c:4444:33: note: in expansion of macro 'min'
NAPI_GRO_CB(skb)->frag0_len = min(skb_frag_size(frag0),
^~~
vim +/min +4444 net/core/dev.c
4428 }
4429 }
4430
4431 static void skb_gro_reset_offset(struct sk_buff *skb)
4432 {
4433 const struct skb_shared_info *pinfo = skb_shinfo(skb);
4434 const skb_frag_t *frag0 = &pinfo->frags[0];
4435
4436 NAPI_GRO_CB(skb)->data_offset = 0;
4437 NAPI_GRO_CB(skb)->frag0 = NULL;
4438 NAPI_GRO_CB(skb)->frag0_len = 0;
4439
4440 if (skb_mac_header(skb) == skb_tail_pointer(skb) &&
4441 pinfo->nr_frags &&
4442 !PageHighMem(skb_frag_page(frag0))) {
4443 NAPI_GRO_CB(skb)->frag0 = skb_frag_address(frag0);
> 4444 NAPI_GRO_CB(skb)->frag0_len = min(skb_frag_size(frag0),
4445 skb->end - skb->tail);
4446 }
4447 }
4448
4449 static void gro_pull_from_frag0(struct sk_buff *skb, int grow)
4450 {
4451 struct skb_shared_info *pinfo = skb_shinfo(skb);
4452
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29102 bytes --]
^ permalink raw reply
* Re: [PATCH] net: netcp: correct netcp_get_stats function signature
From: Keerthy @ 2017-01-11 3:28 UTC (permalink / raw)
To: David Miller
Cc: w-kwok2, m-karicheri2, netdev, linux-kernel, stephen, m-scherban
In-Reply-To: <20170110.115213.1856085394233309828.davem@davemloft.net>
On Tuesday 10 January 2017 10:22 PM, David Miller wrote:
> From: Keerthy <j-keerthy@ti.com>
> Date: Tue, 10 Jan 2017 16:56:25 +0530
>
>> @@ -1909,7 +1909,7 @@ static int netcp_setup_tc(struct net_device *dev, u32 handle, __be16 proto,
>> return 0;
>> }
>>
>> -static struct rtnl_link_stats64 *
>> +void
>> netcp_get_stats(struct net_device *ndev, struct rtnl_link_stats64 *stats)
>
> Please do not remove the static qualifier.
Sure. I will add that back.
>
^ permalink raw reply
* [PATCH v2] net: netcp: correct netcp_get_stats function signature
From: Keerthy @ 2017-01-11 3:33 UTC (permalink / raw)
To: w-kwok2, m-karicheri2
Cc: netdev, linux-kernel, stephen, m-scherban, j-keerthy
Commit: bc1f44709cf2 - net: make ndo_get_stats64 a void function
and
Commit: 6a8162e99ef3 - net: netcp: store network statistics in 64 bits.
The commit 6a8162e99ef3 adds ndo_get_stats64 function as per old
signature which causes compilation error:
drivers/net/ethernet/ti/netcp_core.c:1951:28: error:
initialization from incompatible pointer type
.ndo_get_stats64 = netcp_get_stats,
Hence correct netcp_get_stats function signature as per
the latest definition.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Fixes: 6a8162e99ef344fc("net: netcp: store network statistics in 64 bits")
---
Changes in v2:
* Added the static in the function definition.
This is due patches crossing at the same time.
Fixes the compilation error. Only build tested. It would be
good if someone can boot test.
Applies on top of latest next branch.
drivers/net/ethernet/ti/netcp_core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ti/netcp_core.c b/drivers/net/ethernet/ti/netcp_core.c
index 68a75cc..34852f2 100644
--- a/drivers/net/ethernet/ti/netcp_core.c
+++ b/drivers/net/ethernet/ti/netcp_core.c
@@ -1909,7 +1909,7 @@ static int netcp_setup_tc(struct net_device *dev, u32 handle, __be16 proto,
return 0;
}
-static struct rtnl_link_stats64 *
+static void
netcp_get_stats(struct net_device *ndev, struct rtnl_link_stats64 *stats)
{
struct netcp_intf *netcp = netdev_priv(ndev);
@@ -1938,8 +1938,6 @@ static int netcp_setup_tc(struct net_device *dev, u32 handle, __be16 proto,
stats->rx_errors = p->rx_errors;
stats->rx_dropped = p->rx_dropped;
stats->tx_dropped = p->tx_dropped;
-
- return stats;
}
static const struct net_device_ops netcp_netdev_ops = {
--
1.9.1
^ permalink raw reply related
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: Jason Wang @ 2017-01-11 3:37 UTC (permalink / raw)
To: Michael S. Tsirkin, John Fastabend
Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <20170110065056-mutt-send-email-mst@kernel.org>
On 2017年01月10日 13:00, Michael S. Tsirkin wrote:
> On Mon, Jan 09, 2017 at 08:25:43PM -0800, John Fastabend wrote:
>> On 17-01-09 07:55 PM, Michael S. Tsirkin wrote:
>>> On Mon, Jan 09, 2017 at 07:30:34PM -0800, John Fastabend wrote:
>>>> On 17-01-09 06:51 PM, Michael S. Tsirkin wrote:
>>>>> On Tue, Jan 10, 2017 at 10:29:39AM +0800, Jason Wang wrote:
>>>>>> On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
>>>>>>> On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
>>>>>>>> On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
>>>>>>>>> On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
>>>>>>>>>> On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
>>>>>>>>>>> On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
>>>>>>>>>>>> On 2017年01月05日 02:57, John Fastabend wrote:
>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2017年01月04日 00:48, John Fastabend wrote:
>>>>>>>>>>>>>>> On 17-01-02 10:14 PM, Jason Wang wrote:
>>>>>>>>>>>>>>>> On 2017年01月03日 06:30, John Fastabend wrote:
>>>>>>>>>>>>>>>>> XDP programs can not consume multiple pages so we cap the MTU to
>>>>>>>>>>>>>>>>> avoid this case. Virtio-net however only checks the MTU at XDP
>>>>>>>>>>>>>>>>> program load and does not block MTU changes after the program
>>>>>>>>>>>>>>>>> has loaded.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
>>>>>>>>>>>>>>> needs to read the mtu via
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> virtio_cread16(vdev, ...)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> or we may break the negotiated mtu.
>>>>>>>>>>>>>> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
>>>>>>>>>>>>>> the device about the mtu in this case which is not supported by virtio now.
>>>>>>>>>>>>> Note this is not really a XDP specific problem. The guest can change the MTU
>>>>>>>>>>>>> after init time even without XDP which I assume should ideally result in a
>>>>>>>>>>>>> notification if the MTU is negotiated.
>>>>>>>>>>>> Yes, Michael, do you think we need add some mechanism to notify host about
>>>>>>>>>>>> MTU change in this case?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>> Why does host care?
>>>>>>>>>>>
>>>>>>>>>> Well the guest will drop packets after mtu has been reduced.
>>>>>>>>> I didn't know. What place in code does this?
>>>>>>>>>
>>>>>>>> hmm in many of the drivers it is convention to use the mtu to set the rx
>>>>>>>> buffer sizes and a receive side max length filter. For example in the Intel
>>>>>>>> drivers if a packet with length greater than MTU + some headroom is received we
>>>>>>>> drop it. I guess in the networking stack RX path though nothing forces this and
>>>>>>>> virtio doesn't have any code to drop packets on rx size.
>>>>>>>>
>>>>>>>> In virtio I don't see any existing case currently. In the XDP case though we
>>>>>>>> need to ensure packets fit in a page for the time being which is why I was
>>>>>>>> looking at this code and generated this patch.
>>>>>>> I'd say just look at the hardware max mtu. Ignore the configured mtu.
>>>>>>>
>>>>>>>
>>>>>> Does this work for small buffers consider it always allocate skb with size
>>>>>> of GOOD_PACKET_LEN?
>>>>> Spec says hardware won't send in packets > max mtu in config space.
>>>>>
>>>>>> I think in any case, we should limit max_mtu to
>>>>>> GOOD_PACKET_LEN for small buffers.
>>>>>>
>>>>>> Thanks
>>>>> XDP seems to have a bunch of weird restrictions, I just
>>>>> do not like it that the logic spills out to all drivers.
>>>>> What if someone decides to extend it to two pages in the future?
>>>>> Recode it all in all drivers ...
>>>>>
>>>>> Why can't net core enforce mtu?
>>>>>
>>>> OK I agree I'll put most the logic in rtnetlink.c when the program is added
>>>> or removed.
>>>>
>>>> But, I'm looking at the non-XDP receive_small path now and wondering how does
>>>> multiple buffer receives work (e.g. packet larger than GOOD_PACKET_LEN?)
>>> I don't understand the question. Look at add_recvbuf_small,
>>> it adds a tiny buffer for head and then the skb.
>>>
>> Specifically this seems to fail with mergeable buffers disabled
>>
>> On the host:
>>
>> # ip link set dev tap0 mtu 9000
>> # ping 22.2 -s 2048
>>
>> On the guest:
>>
>> # insmod ./drivers/net/virtio_net.ko
>> # ip link set dev eth0 mtu 9000
> Why would it work? You are sending a packet larger than ethernet MTU.
Ok, does it mean virtio-net does not support Jumbo frame? And if it
can't work, use MAX_MTU as max_mtu is a bug to me.
>
>> With mergeable buffers enabled no problems it works as I expect at least.
> We don't expect to get these packets but
> mergeable is able to process them anyway.
> It's an accident:)
>
But path MTU discovery indeed benefits from this "accident".
Thanks
^ permalink raw reply
* [PATCH net] gro: use min_t() in skb_gro_reset_offset()
From: Eric Dumazet @ 2017-01-11 3:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev, herbert, slavash, willemb, edumazet
In-Reply-To: <20170110.212911.71346127320993214.davem@davemloft.net>
From: Eric Dumazet <edumazet@google.com>
On 32bit arches, (skb->end - skb->data) is not 'unsigned int',
so we shall use min_t() instead of min() to avoid a compiler error.
Fixes: 1272ce87fa01 ("gro: Enter slow-path if there is no tailroom")
Reported-by: kernel test robot <fengguang.wu@intel.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/dev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 88d2907ca2cda3438a7a1c0c179051a5038aa1e1..07b307b0b414730688b64fdb2295b0fa1b721e51 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4441,8 +4441,9 @@ static void skb_gro_reset_offset(struct sk_buff *skb)
pinfo->nr_frags &&
!PageHighMem(skb_frag_page(frag0))) {
NAPI_GRO_CB(skb)->frag0 = skb_frag_address(frag0);
- NAPI_GRO_CB(skb)->frag0_len = min(skb_frag_size(frag0),
- skb->end - skb->tail);
+ NAPI_GRO_CB(skb)->frag0_len = min_t(unsigned int,
+ skb_frag_size(frag0),
+ skb->end - skb->tail);
}
}
^ permalink raw reply related
* Re: [PATCH v2 2/2] stmmac: rename it to synopsys
From: Jie Deng @ 2017-01-11 4:00 UTC (permalink / raw)
To: Joao Pinto, davem
Cc: lars.persson, niklass, peppe.cavallaro, alexandre.torgue, netdev,
CARLOS.PALMINHA
In-Reply-To: <c74e6665ca14a4ca03b38cd3442ef0644d9e250d.1484059674.git.jpinto@synopsys.com>
Hi Joao,
On 2017/1/10 22:52, Joao Pinto wrote:
> This patch renames stmicro/stmmac to synopsys/ since it is a standard
> ethernet software package regarding synopsys ethernet controllers, supporting
> the majority of Synopsys Ethernet IPs. The config IDs remain the same, for
> retro-compatibility, only the description was changed.
>
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
> ---
> changes v1->v2:
> - nothing changed. Just to keep up with patch set version
>
> @@ -1,5 +1,5 @@
> config STMMAC_ETH
> - tristate "STMicroelectronics 10/100/1000 Ethernet driver"
> + tristate "Synopsys Ethernet drivers"
> depends on HAS_IOMEM && HAS_DMA
> select MII
> select PHYLIB
> @@ -14,7 +14,7 @@ config STMMAC_ETH
> if STMMAC_ETH
>
"Synopsys Ethernet drivers" is too generic. The name should reflect the
controller. This driver is for Synopsys GMAC 10M/100M/1G IPs. We will submit a
driver for the new 25G/40G/50G/100G XLGMAC IP in the future.
> config STMMAC_PLATFORM
> - tristate "STMMAC Platform bus support"
> + tristate "Platform bus support"
> depends on STMMAC_ETH
> select MFD_SYSCON
> default y
> @@ -149,13 +149,13 @@ config DWMAC_SUNXI
> endif
>
> config STMMAC_PCI
> - tristate "STMMAC PCI bus support"
> + tristate "PCI bus support"
> depends on STMMAC_ETH && PCI
> ---help---
> This is to select the Synopsys DWMAC available on PCI devices,
> if you have a controller with this interface, say Y or M here.
>
> - This PCI support is tested on XLINX XC2V3000 FF1152AMT0221
> + This PCI support was tested on XLINX XC2V3000 FF1152AMT0221
> D1215994A VIRTEX FPGA board.
The name is also too generic. Please try to reflect the controller.
Thanks,
Jie
^ 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