* Re: Reference counting struct inet_peer
From: David Miller @ 2017-01-24 19:20 UTC (permalink / raw)
To: dwindsor; +Cc: netdev, keescook, elena.reshetova, ishkamiel
In-Reply-To: <CAEXv5_j1cz1EUPgmAKO5OHxKcoHVLuPPVRs316CWyMpw8UtpRw@mail.gmail.com>
From: David Windsor <dwindsor@gmail.com>
Date: Mon, 23 Jan 2017 07:42:51 -0500
> struct inet_peer objects get freed when their reference count
> becomes -1, not 0 as is the usual case. Is there a reason why this
> is so?
inet peer entries that sit in the tree, but have no other reference
taken, have a reference count of zero.
Therefore, any entry which has a reference count of zero can be
safely garbage collected from the tree.
When the garbage collector purges entries with a zero refcnt, it
atomically sets the refcnt to -1 so that other threads of control
in RCU protected sections that still see this entry in the tree
will not be able to grab it for use.
The -1 marker is used as a synchronization mechanism between the
GC and lookup paths.
Once -1 is atomically set, the GC code knows that no external
reference can be created.
^ permalink raw reply
* Re: [Patch net] af_unix: move unix_mknod() out of bindlock
From: David Miller @ 2017-01-24 19:31 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, dvyukov, rweikusat, viro
In-Reply-To: <1485199055-2342-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 23 Jan 2017 11:17:35 -0800
> Dmitry reported a deadlock scenario:
>
> unix_bind() path:
> u->bindlock ==> sb_writer
>
> do_splice() path:
> sb_writer ==> pipe->mutex ==> u->bindlock
>
> In the unix_bind() code path, unix_mknod() does not have to
> be done with u->bindlock held, since it is a pure fs operation,
> so we can just move unix_mknod() out.
>
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Tested-by: Dmitry Vyukov <dvyukov@google.com>
> Cc: Rainer Weikusat <rweikusat@mobileactivedefense.com>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* network status
From: Sriram V @ 2017-01-24 19:39 UTC (permalink / raw)
To: netdev
Hello,
Apologies in case, this is not the right list of this question.
I wanted to check, How can i find out if a network status has changed
1. How can the user application find out if the link status has changed?
2. what changes do i need to add in the driver to indicate to the user
applications that ethernet cable has been plugged in or unplugged.
3. How should a user application know the status change (Should the
userapp poll on the interface/is there an uevent interface to indicate
the link status change)
Thanks.
Sriram
^ permalink raw reply
* Re: [PATCH for-next V2 00/11] Mellanox mlx5 core and ODP updates 2017-01-01
From: Doug Ledford @ 2017-01-24 19:39 UTC (permalink / raw)
To: Leon Romanovsky, Saeed Mahameed
Cc: David Miller, Saeed Mahameed, Linux Netdev List,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, ilyal-VPRAkNaXOzVWk0Htik3J/w,
artemyko-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <20170103072344.GF12077-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]
On Tue, 2017-01-03 at 09:23 +0200, Leon Romanovsky wrote:
> On Tue, Jan 03, 2017 at 01:30:16AM +0200, Saeed Mahameed wrote:
> >
> > On Mon, Jan 2, 2017 at 10:53 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> > wrote:
> > >
> > > From: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> > > Date: Mon, 2 Jan 2017 11:37:37 +0200
> > >
> > > >
> > > > The following eleven patches mainly come from Artemy Kovalyov
> > > > who expanded mlx5 on-demand-paging (ODP) support. In addition
> > > > there are three cleanup patches which don't change any
> > > > functionality,
> > > > but are needed to align codebase prior accepting other patches.
> > >
> > > Series applied to net-next, thanks.
> >
> > Whoops,
> >
> > This series was meant as a pull request, you can blame it on me I
> > kinda messed up the V2 title.
> > Doug will have to pull same patches later, will this produce a
> > conflict on merge window ?
>
> Yes, but it can be easily avoided.
>
> Doug,
>
> We have another pull request to send and we will base its code on the
> Dave's tree instead of Linus's rc tag. In such way, you will have the
> same commits as Dave and won't have merge failures.
>
> Please don't apply manually this specific patchset.
>
> Sorry for the inconvenience.
Hi Leon and Saeed,
As I understand it, Dave took this series, but I have not. You were
going to base another pull request on top of this so I could get both.
However, I believe that was the attempt to reorg the driver pull
request, which David NAKed. That means I have not picked this up. Are
all of the other for-next patches you posted against the RDMA list
going to go in cleanly without this series, or should I expect
conflicts between Dave's tree and my own?
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] virtio_net: fix PAGE_SIZE > 64k
From: David Miller @ 2017-01-24 19:42 UTC (permalink / raw)
To: mst; +Cc: netdev, john.fastabend, linux-kernel, virtualization
In-Reply-To: <1485197869-11350-1-git-send-email-mst@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 23 Jan 2017 21:37:52 +0200
> I don't have any guests with PAGE_SIZE > 64k but the
> code seems to be clearly broken in that case
> as PAGE_SIZE / MERGEABLE_BUFFER_ALIGN will need
> more than 8 bit and so the code in mergeable_ctx_to_buf_address
> does not give us the actual true size.
>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Applied, thanks Michael.
I am really trying to be patient, but we are about to run out of
time for fixing the adjust header XDP stuff.
That should have been resolved in a week or two, but now we're
basically a month or so later.
Please come to some kind of agreement about how to implement this
because we can't let v4.10 go out without this being resolved.
Thank you.
^ permalink raw reply
* Re: [net PATCH v5 1/6] virtio_net: use dev_kfree_skb for small buffer XDP receive
From: David Miller @ 2017-01-24 19:43 UTC (permalink / raw)
To: mst
Cc: john.fastabend, jasowang, john.r.fastabend, netdev,
alexei.starovoitov, daniel
In-Reply-To: <20170123230809-mutt-send-email-mst@kernel.org>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 23 Jan 2017 23:08:35 +0200
> On Tue, Jan 17, 2017 at 02:19:50PM -0800, John Fastabend wrote:
>> In the small buffer case during driver unload we currently use
>> put_page instead of dev_kfree_skb. Resolve this by adding a check
>> for virtnet mode when checking XDP queue type. Also name the
>> function so that the code reads correctly to match the additional
>> check.
>>
>> Fixes: bb91accf2733 ("virtio-net: XDP support for small buffers")
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> Acked-by: Jason Wang <jasowang@redhat.com>
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
> I think we definitely want this one in -net as it's
> a bugfix.
This whole series is a bug fix, we must have adjust_header XDP
support in the virtio_net driver before v4.10 goes out, it is
a requires base feature for XDP.
^ permalink raw reply
* Re: [PATCH net-next 0/5] Misc BPF improvements
From: David Miller @ 2017-01-24 19:49 UTC (permalink / raw)
To: daniel; +Cc: netdev, ast
In-Reply-To: <cover.1485214851.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Tue, 24 Jan 2017 01:06:25 +0100
> This series adds various misc improvements to BPF, f.e. allowing
> skb_load_bytes() helper to be used with filter/reuseport programs
> to facilitate programming, test cases for program tag, etc. For
> details, please see individual patches.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] virtio_net: fix PAGE_SIZE > 64k
From: Michael S. Tsirkin @ 2017-01-24 19:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, john.fastabend, linux-kernel, virtualization
In-Reply-To: <20170124.144227.2017106704873029028.davem@davemloft.net>
On Tue, Jan 24, 2017 at 02:42:27PM -0500, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@redhat.com>
> Date: Mon, 23 Jan 2017 21:37:52 +0200
>
> > I don't have any guests with PAGE_SIZE > 64k but the
> > code seems to be clearly broken in that case
> > as PAGE_SIZE / MERGEABLE_BUFFER_ALIGN will need
> > more than 8 bit and so the code in mergeable_ctx_to_buf_address
> > does not give us the actual true size.
> >
> > Cc: John Fastabend <john.fastabend@gmail.com>
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> Applied, thanks Michael.
>
> I am really trying to be patient, but we are about to run out of
> time for fixing the adjust header XDP stuff.
>
> That should have been resolved in a week or two, but now we're
> basically a month or so later.
>
> Please come to some kind of agreement about how to implement this
> because we can't let v4.10 go out without this being resolved.
>
> Thank you.
I didn't realise. Why can't we? I thought that adjust_header is an
optional feature that userspace can test for, so no rush.
--
MST
^ permalink raw reply
* Re: [PATCH v2 net 0/2] ipv6: fix ip6_tnl_parse_tlv_enc_lim() issues
From: David Miller @ 2017-01-24 19:54 UTC (permalink / raw)
To: edumazet; +Cc: netdev, willemb, ast, eric.dumazet
In-Reply-To: <20170124004306.19236-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 23 Jan 2017 16:43:04 -0800
> First patch fixes ip6_tnl_parse_tlv_enc_lim() callers,
> bug added in linux-3.7
>
> Second patch fixes ip6_tnl_parse_tlv_enc_lim() itself,
> bug predates linux-2.6.12
>
> Based on a report from Dmitry Vyukov, thanks to KASAN.
Series applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next 5/5] net: dsa: mv88e6xxx: Implement the 6390 external MDIO bus
From: Andrew Lunn @ 2017-01-24 19:54 UTC (permalink / raw)
To: Vivien Didelot; +Cc: David Miller, netdev, Florian Fainelli
In-Reply-To: <871svscpt9.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
On Tue, Jan 24, 2017 at 12:48:02PM -0500, Vivien Didelot wrote:
> Hi Andrew,
>
> Sorry but the previous patches with a list of MDIO busses and refactored
> PHY ops still seems too much complex to just toggle a bit.
>
> We know which switch port has an external PHY attached to it, right?
No, not really. We have the full flexibility of phandles in the device
tree. The PHYs on the external bus might not even be connected to the
switch, they could be for the host interfaces, for example. And you
don't even need to use the internal PHYs. If you are using the SERDES
interfaces, you could have an external SGMII PHY connect to a
port. This would make sense with SFP cages, with a copper PHY inserted
into the cage. All ports of the 6390 allow this.
The hardware has two really separate MDIO busses. Both busses could
have a PHY on the same address. We should really model this as two
Linux MDIO devices.
It is actually a shame older chips don't have this. Early versions of
the ClearFog have a hardware design error. The external PHY on port6
is using address 0. So it clashes with the internal PHY on port0. Two
MDIO busses would solve this. And i actually expect quite a few
designs using the 6390 will put an external phy at address 0 and 1,
not 9 and 10. Few PHYs have that many strapping pins for address
selection.
Andrew
^ permalink raw reply
* Re: [PATCH] net: ks8851: Drop eeprom_size structure member
From: David Miller @ 2017-01-24 19:56 UTC (permalink / raw)
To: stephen.boyd; +Cc: linux-kernel, netdev
In-Reply-To: <20170124014920.644-1-stephen.boyd@linaro.org>
From: Stephen Boyd <stephen.boyd@linaro.org>
Date: Mon, 23 Jan 2017 17:49:20 -0800
> After commit 51b7b1c34e19 (KSZ8851-SNL: Add ethtool support for
> EEPROM via eeprom_93cx6, 2011-11-21) this structure member is
> unused. Delete it.
>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH v5 0/2] Add support for the ethernet switch on the ESPRESSObin
From: Andrew Lunn @ 2017-01-24 19:57 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: David Miller, vivien.didelot, f.fainelli, netdev, linux-kernel,
jason, sebastian.hesselbarth, thomas.petazzoni, linux-arm-kernel,
nadavh, dingwei, kostap, shjzhou, jpannell
In-Reply-To: <87r33s2ynp.fsf@free-electrons.com>
On Tue, Jan 24, 2017 at 05:47:06PM +0100, Gregory CLEMENT wrote:
> Hi David,
>
> On ven., janv. 20 2017, David Miller <davem@davemloft.net> wrote:
>
> > From: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > Date: Thu, 19 Jan 2017 22:49:32 +0100
> >
> >> I created a new family for this switch and filled the ops structure
> >> by selecting which seems the more appropriate functions. I rebased
> >> the series on net-next/master which allowed me to benefit to the
> >> eeprom functions introduced for the 6390.
> >
> > It looks like there will be at least one more respin of this series,
> > specifically to remove the new family as Vivien seems to object to
> > this.
>
> I am about to send a new version. However about removing the new family,
> I thought that with the confirmation from Andrew we could keep it.
Hi Gregory
Yes, keep it. It will hopefully be short lived, but it is needed at
the moment.
Andrew
^ permalink raw reply
* Re: [PATCH for-next V2 00/11] Mellanox mlx5 core and ODP updates 2017-01-01
From: Leon Romanovsky @ 2017-01-24 19:58 UTC (permalink / raw)
To: Doug Ledford
Cc: Saeed Mahameed, David Miller, Saeed Mahameed, Linux Netdev List,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, ilyal-VPRAkNaXOzVWk0Htik3J/w,
artemyko-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <1485286799.43764.49.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3060 bytes --]
On Tue, Jan 24, 2017 at 02:39:59PM -0500, Doug Ledford wrote:
> On Tue, 2017-01-03 at 09:23 +0200, Leon Romanovsky wrote:
> > On Tue, Jan 03, 2017 at 01:30:16AM +0200, Saeed Mahameed wrote:
> > >
> > > On Mon, Jan 2, 2017 at 10:53 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> > > wrote:
> > > >
> > > > From: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> > > > Date: Mon, 2 Jan 2017 11:37:37 +0200
> > > >
> > > > >
> > > > > The following eleven patches mainly come from Artemy Kovalyov
> > > > > who expanded mlx5 on-demand-paging (ODP) support. In addition
> > > > > there are three cleanup patches which don't change any
> > > > > functionality,
> > > > > but are needed to align codebase prior accepting other patches.
> > > >
> > > > Series applied to net-next, thanks.
> > >
> > > Whoops,
> > >
> > > This series was meant as a pull request, you can blame it on me I
> > > kinda messed up the V2 title.
> > > Doug will have to pull same patches later, will this produce a
> > > conflict on merge window ?
> >
> > Yes, but it can be easily avoided.
> >
> > Doug,
> >
> > We have another pull request to send and we will base its code on the
> > Dave's tree instead of Linus's rc tag. In such way, you will have the
> > same commits as Dave and won't have merge failures.
> >
> > Please don't apply manually this specific patchset.
> >
> > Sorry for the inconvenience.
>
> Hi Leon and Saeed,
>
> As I understand it, Dave took this series, but I have not. You were
> going to base another pull request on top of this so I could get both.
We did it, ODP was our first pull request and 4K UAR was second one.
http://marc.info/?l=linux-rdma&m=148398855416090&w=2
Dave pulled this tag:
https://git.kernel.org/cgit/linux/kernel/git/mellanox/linux.git/tag/?h=mlx5-4kuar-for-4.11
Since 4K UAR tag was based on ODP, by pulling mlx5-4kuar-for-4.11 tag you
will get ODP too.
> However, I believe that was the attempt to reorg the driver pull
> request, which David NAKed.
It was our third pull request
http://marc.info/?l=linux-rdma&m=148424983101796&w=2
https://git.kernel.org/cgit/linux/kernel/git/mellanox/linux.git/tag/?h=mlx5-dir-layout-reorg
> That means I have not picked this up. Are
> all of the other for-next patches you posted against the RDMA list
> going to go in cleanly without this series, or should I expect
> conflicts between Dave's tree and my own?
All patches sent by me are based on mlx5-4kuar-for-4.11 tag which
exists in Dave's tree and everything will apply cleanly on your
k.o/for-4.11 branch and won't have merge conflicts between your tree and
Dave's net-next tree.
For you convenience, my submission queue can be found at:
https://git.kernel.org/cgit/linux/kernel/git/leon/linux-rdma.git/log/?h=rdma-next
Thanks
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> GPG KeyID: B826A3330E572FDD
>
> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: Drop WARN() in tag_brcm.c
From: David Miller @ 2017-01-24 20:00 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20170124031907.28328-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 23 Jan 2017 19:19:07 -0800
> We may be able to see invalid Broadcom tags when the hardware and drivers are
> misconfigured, or just while exercising the error path. Instead of flooding
> the console with messages, flat out drop the packet.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] vxlan: misc fdb fixes
From: David Miller @ 2017-01-24 20:02 UTC (permalink / raw)
To: roopa; +Cc: netdev, ramanb, stephen, jbenc, pshelar
In-Reply-To: <1485233073-11391-1-git-send-email-roopa@cumulusnetworks.com>
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 5/5] gtp: let userspace handle packets for invalid tunnels
From: Andreas Schultz @ 2017-01-24 20:02 UTC (permalink / raw)
To: pablo; +Cc: netdev, Lionel Gauthier, openbsc, laforge
In-Reply-To: <20170124190349.GA9757@salvia>
Hi Pablo,
----- On Jan 24, 2017, at 8:03 PM, pablo pablo@netfilter.org wrote:
> Hi Andreas,
>
> On Tue, Jan 24, 2017 at 06:24:02PM +0100, Andreas Schultz wrote:
>> enable userspace to send error replies for invalid tunnels
>>
>> Signed-off-by: Andreas Schultz <aschultz@tpip.net>
>> ---
>> drivers/net/gtp.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
>> index 912721e..c607333 100644
>> --- a/drivers/net/gtp.c
>> +++ b/drivers/net/gtp.c
>> @@ -198,12 +198,12 @@ static int gtp0_udp_encap_recv(struct gtp_dev *gtp, struct
>> sk_buff *skb,
>> pctx = gtp0_pdp_find(gtp, be64_to_cpu(gtp0->tid));
>> if (!pctx) {
>> netdev_dbg(gtp->dev, "No PDP ctx to decap skb=%p\n", skb);
>> - return -1;
>> + return 1;
>> }
>>
>> if (!gtp_check_src_ms(skb, pctx, hdrlen)) {
>> netdev_dbg(gtp->dev, "No PDP ctx for this MS\n");
>> - return -1;
>> + return 1;
>
> So userspace gets the packet that we cannot forward. I guess your
> userspace codebase performs this sanity checks again so you can send
> the appropriate error reply?
For TEID /= 0, the only reply is a T-PDU of type error indication. There
is no cause specified. So I don't actually have to repeat the check.
TEID == 0 is more interesting, this tells userspace that it tried to
send on an invalid tunnel and should tear it down.
If you like, you can have a look at the userspace code. The relevant piece
is at https://github.com/travelping/gtp_u_kmod/blob/master/src/gtp_u_kmod_port.erl#L231
But be warned, it's written in Erlang ;-)
Andreas
>
>> }
>>
>> /* Get rid of the GTP + UDP headers. */
>> @@ -247,12 +247,12 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp,
>> struct sk_buff *skb,
>> pctx = gtp1_pdp_find(gtp, ntohl(gtp1->tid));
>> if (!pctx) {
>> netdev_dbg(gtp->dev, "No PDP ctx to decap skb=%p\n", skb);
>> - return -1;
>> + return 1;
>> }
>>
>> if (!gtp_check_src_ms(skb, pctx, hdrlen)) {
>> netdev_dbg(gtp->dev, "No PDP ctx for this MS\n");
>> - return -1;
>> + return 1;
>> }
>>
>> /* Get rid of the GTP + UDP headers. */
>> --
>> 2.10.2
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: leds: Fix truncated LED trigger names
From: Andrew Lunn @ 2017-01-24 20:03 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David S. Miller, Zach Brown, Volodymyr Bendiuga,
Magnus Öberg, Florian Fainelli, netdev, linux-renesas-soc,
linux-kernel
In-Reply-To: <1485272470-3497-3-git-send-email-geert+renesas@glider.be>
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 5c9d2529685fe215..f6ab919528ab3627 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -25,7 +25,6 @@
> #include <linux/timer.h>
> #include <linux/workqueue.h>
> #include <linux/mod_devicetable.h>
> -#include <linux/phy_led_triggers.h>
>
> #include <linux/atomic.h>
>
> @@ -339,6 +338,8 @@ struct phy_c45_device_ids {
> u32 device_ids[8];
> };
>
> +#include <linux/phy_led_triggers.h>
> +
> /* phy_device: An instance of a PHY
> *
> * drv: Pointer to the driver for this PHY instance
> diff --git a/include/linux/phy_led_triggers.h b/include/linux/phy_led_triggers.h
> index a2daea0a37d2ae14..69dffb4fc5a294e9 100644
> --- a/include/linux/phy_led_triggers.h
> +++ b/include/linux/phy_led_triggers.h
> @@ -20,9 +20,8 @@
> #include <linux/leds.h>
>
> #define PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE 10
> -#define PHY_MII_BUS_ID_SIZE (20 - 3)
>
> -#define PHY_LINK_LED_TRIGGER_NAME_SIZE (PHY_MII_BUS_ID_SIZE + \
> +#define PHY_LINK_LED_TRIGGER_NAME_SIZE (MII_BUS_ID_SIZE + \
> FIELD_SIZEOF(struct mdio_device, addr)+\
> PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE)
Hi Geert
Using the macro is great, but it does seem a bit ugly having the
include in the middle of the file.
As far as i can see, phy.h only uses a pointer to a struct
phy_led_trigger, not struct phy_led_trigger itself. Could you try
removing the header file all together and just have a forward
declaration of phy_led_trigger?
Thanks
Andrew
^ permalink raw reply
* Re: [net PATCH v5 1/6] virtio_net: use dev_kfree_skb for small buffer XDP receive
From: Michael S. Tsirkin @ 2017-01-24 20:08 UTC (permalink / raw)
To: David Miller
Cc: john.fastabend, jasowang, john.r.fastabend, netdev,
alexei.starovoitov, daniel
In-Reply-To: <20170124.144328.2195698124358175034.davem@davemloft.net>
On Tue, Jan 24, 2017 at 02:43:28PM -0500, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@redhat.com>
> Date: Mon, 23 Jan 2017 23:08:35 +0200
>
> > On Tue, Jan 17, 2017 at 02:19:50PM -0800, John Fastabend wrote:
> >> In the small buffer case during driver unload we currently use
> >> put_page instead of dev_kfree_skb. Resolve this by adding a check
> >> for virtnet mode when checking XDP queue type. Also name the
> >> function so that the code reads correctly to match the additional
> >> check.
> >>
> >> Fixes: bb91accf2733 ("virtio-net: XDP support for small buffers")
> >> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> >> Acked-by: Jason Wang <jasowang@redhat.com>
> >
> > Acked-by: Michael S. Tsirkin <mst@redhat.com>
> >
> > I think we definitely want this one in -net as it's
> > a bugfix.
>
> This whole series is a bug fix, we must have adjust_header XDP
> support in the virtio_net driver before v4.10 goes out, it is
> a requires base feature for XDP.
I have to say device resets outside probe have a huge potential
to uncover hypervisor bugs. I am rather uncomfortable
doing that after -rc1.
How about a module option to disable it by default?
We can then ship a partial implementation in 4.10
and work on completing it in 4.11.
--
MST
^ permalink raw reply
* Re: [PATCH v2] virtio_net: fix PAGE_SIZE > 64k
From: David Miller @ 2017-01-24 20:09 UTC (permalink / raw)
To: mst; +Cc: linux-kernel, jasowang, virtualization, netdev, john.fastabend
In-Reply-To: <20170124215214-mutt-send-email-mst@kernel.org>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Tue, 24 Jan 2017 21:53:13 +0200
> I didn't realise. Why can't we? I thought that adjust_header is an
> optional feature that userspace can test for, so no rush.
No, we want the base set of XDP features to be present in all drivers
supporting XDP.
^ permalink raw reply
* [PATCH net-next v6 0/4] Add support for the ethernet switch on the ESPRESSObin
From: Gregory CLEMENT @ 2017-01-24 20:10 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, netdev,
linux-kernel
Cc: David S. Miller, Jason Cooper, Sebastian Hesselbarth,
Gregory CLEMENT, Thomas Petazzoni, linux-arm-kernel, Nadav Haklai,
Wilson Ding, Kostya Porotchkin, Joe Zhou, Jon Pannell
Hi,
This set of patches adds support for the Marvell Ethernet Topaz switch
family (88E6141/88E6341) which is found on the ESPRESSObin. With this
series the network is usable on this board.
I rebased the series again on the very last net-next/master which
allowed me this time to benefit to the temperature support introduced
by Andrew Lunn.
I still do not have a datasheet about the PHY embedded in the switch
but thanks to the help of Andrew I was able to retrieve the PHY
ID. Then, by using the 88E1510 operations I was able to get temperature
with credible values.
In this series I also added the support of the 88E6141 which is
actually the switch on the boards I tested. The difference with the
88E6341, is the absence of the TCAM on the 88E6141, however I don't
think this feature is used in the driver, so currently for Linux there
is no difference except the switch ID.
Thanks,
Gregory
Changelog:
v5 -> v6:
- rebased on net-next/master (d140199af510)
- Fix the redundant check on mv88e6xxx_6341_family (reported by Julia
Lawall)
- Add support for the 88E6141
- Move support for temperature sensor in the phy part
Gregory CLEMENT (3):
net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341
net: dsa: mv88e6xxx: Add support for ethernet switch 88E6141
phy: marvell: Add support for the PHY embedded in the topaz switch
Romain Perier (1):
net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports
drivers/net/dsa/mv88e6xxx/chip.c | 102 ++++++++++++++++++++++++---
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 21 +++++-
drivers/net/phy/marvell.c | 21 ++++++-
include/linux/marvell_phy.h | 1 +-
4 files changed, 135 insertions(+), 10 deletions(-)
base-commit: 1d0ec6626e558f9eb0043352745c02c42ff13a11
--
git-series 0.9.1
^ permalink raw reply
* [PATCH net-next v6 1/4] net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports
From: Gregory CLEMENT @ 2017-01-24 20:10 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, netdev,
linux-kernel
Cc: David S. Miller, Jason Cooper, Sebastian Hesselbarth,
Gregory CLEMENT, Thomas Petazzoni, linux-arm-kernel, Nadav Haklai,
Wilson Ding, Kostya Porotchkin, Joe Zhou, Jon Pannell
In-Reply-To: <cover.b0e18efe751186768e720c341693117fdd4d3c16.1485288602.git-series.gregory.clement@free-electrons.com>
From: Romain Perier <romain.perier@free-electrons.com>
Some Marvell ethernet switches have internal ethernet transceivers with
hardcoded phy addresses. These addresses can be greater than the number
of ports or its value might be different than the associated port number.
This is for example the case for MV88E6341 that has 6 ports and internal
Port 1 to Port4 PHYs mapped at SMI addresses from 0x11 to 0x14.
This commits fixes the issue by removing the condition in MDIO callbacks.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index c7e08e13bb54..7d942f8a42a7 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2882,9 +2882,6 @@ static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
u16 val;
int err;
- if (phy >= mv88e6xxx_num_ports(chip))
- return 0xffff;
-
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_phy_read(chip, phy, reg, &val);
mutex_unlock(&chip->reg_lock);
@@ -2897,9 +2894,6 @@ static int mv88e6xxx_mdio_write(struct mii_bus *bus, int phy, int reg, u16 val)
struct mv88e6xxx_chip *chip = bus->priv;
int err;
- if (phy >= mv88e6xxx_num_ports(chip))
- return 0xffff;
-
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_phy_write(chip, phy, reg, val);
mutex_unlock(&chip->reg_lock);
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH net-next v6 2/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341
From: Gregory CLEMENT @ 2017-01-24 20:10 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, netdev,
linux-kernel
Cc: David S. Miller, Jason Cooper, Sebastian Hesselbarth,
Gregory CLEMENT, Thomas Petazzoni, linux-arm-kernel, Nadav Haklai,
Wilson Ding, Kostya Porotchkin, Joe Zhou, Jon Pannell
In-Reply-To: <cover.b0e18efe751186768e720c341693117fdd4d3c16.1485288602.git-series.gregory.clement@free-electrons.com>
The Marvell 88E6341 device is single-chip, 6-port Ethernet switch with
four integrated 10/100/1000Mbps Ethernet transceivers and one high speed
SerDes interfaces. It is partially compatible with switches of family
88E6352 and switches of family 88E6390.
This commit adds an initial support for this switch by describing its
capabilities to the driver and introducing a new family.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 54 ++++++++++++++++++++++++++--
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 19 +++++++++-
2 files changed, 69 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 7d942f8a42a7..00db33ca1696 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -664,6 +664,11 @@ static bool mv88e6xxx_6320_family(struct mv88e6xxx_chip *chip)
return chip->info->family == MV88E6XXX_FAMILY_6320;
}
+static bool mv88e6xxx_6341_family(struct mv88e6xxx_chip *chip)
+{
+ return chip->info->family == MV88E6XXX_FAMILY_6341;
+}
+
static bool mv88e6xxx_6351_family(struct mv88e6xxx_chip *chip)
{
return chip->info->family == MV88E6XXX_FAMILY_6351;
@@ -1688,7 +1693,8 @@ static int _mv88e6xxx_vtu_new(struct mv88e6xxx_chip *chip, u16 vid,
: GLOBAL_VTU_DATA_MEMBER_TAG_NON_MEMBER;
if (mv88e6xxx_6097_family(chip) || mv88e6xxx_6165_family(chip) ||
- mv88e6xxx_6351_family(chip) || mv88e6xxx_6352_family(chip)) {
+ mv88e6xxx_6351_family(chip) || mv88e6xxx_6352_family(chip) ||
+ mv88e6xxx_6341_family(chip)) {
struct mv88e6xxx_vtu_entry vstp;
/* Adding a VTU entry requires a valid STU entry. As VSTP is not
@@ -2543,7 +2549,7 @@ static int mv88e6xxx_setup_port(struct mv88e6xxx_chip *chip, int port)
if (mv88e6xxx_6352_family(chip) || mv88e6xxx_6351_family(chip) ||
mv88e6xxx_6165_family(chip) || mv88e6xxx_6097_family(chip) ||
mv88e6xxx_6095_family(chip) || mv88e6xxx_6320_family(chip) ||
- mv88e6xxx_6185_family(chip))
+ mv88e6xxx_6185_family(chip) || mv88e6xxx_6341_family(chip))
reg = PORT_CONTROL_2_MAP_DA;
if (mv88e6xxx_6095_family(chip) || mv88e6xxx_6185_family(chip)) {
@@ -2597,7 +2603,7 @@ static int mv88e6xxx_setup_port(struct mv88e6xxx_chip *chip, int port)
if (mv88e6xxx_6352_family(chip) || mv88e6xxx_6351_family(chip) ||
mv88e6xxx_6165_family(chip) || mv88e6xxx_6097_family(chip) ||
- mv88e6xxx_6320_family(chip)) {
+ mv88e6xxx_6320_family(chip) || mv88e6xxx_6341_family(chip)) {
/* Port ATU control: disable limiting the number of
* address database entries that this port is allowed
* to use.
@@ -3566,6 +3572,34 @@ static const struct mv88e6xxx_ops mv88e6352_ops = {
.reset = mv88e6352_g1_reset,
};
+static const struct mv88e6xxx_ops mv88e6341_ops = {
+ /* MV88E6XXX_FAMILY_6341 */
+ .get_eeprom = mv88e6xxx_g2_get_eeprom8,
+ .set_eeprom = mv88e6xxx_g2_set_eeprom8,
+ .set_switch_mac = mv88e6xxx_g2_set_switch_mac,
+ .phy_read = mv88e6xxx_g2_smi_phy_read,
+ .phy_write = mv88e6xxx_g2_smi_phy_write,
+ .port_set_link = mv88e6xxx_port_set_link,
+ .port_set_duplex = mv88e6xxx_port_set_duplex,
+ .port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay,
+ .port_set_speed = mv88e6390_port_set_speed,
+ .port_tag_remap = mv88e6095_port_tag_remap,
+ .port_set_frame_mode = mv88e6351_port_set_frame_mode,
+ .port_set_egress_unknowns = mv88e6351_port_set_egress_unknowns,
+ .port_set_ether_type = mv88e6351_port_set_ether_type,
+ .port_jumbo_config = mv88e6165_port_jumbo_config,
+ .port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
+ .port_pause_config = mv88e6097_port_pause_config,
+ .stats_snapshot = mv88e6390_g1_stats_snapshot,
+ .stats_get_sset_count = mv88e6320_stats_get_sset_count,
+ .stats_get_strings = mv88e6320_stats_get_strings,
+ .stats_get_stats = mv88e6390_stats_get_stats,
+ .g1_set_cpu_port = mv88e6390_g1_set_cpu_port,
+ .g1_set_egress_port = mv88e6390_g1_set_egress_port,
+ .mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
+ .reset = mv88e6352_g1_reset,
+};
+
static const struct mv88e6xxx_ops mv88e6390_ops = {
/* MV88E6XXX_FAMILY_6390 */
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
@@ -3953,6 +3987,20 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.ops = &mv88e6321_ops,
},
+ [MV88E6341] = {
+ .prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
+ .family = MV88E6XXX_FAMILY_6341,
+ .name = "Marvell 88E6341",
+ .num_databases = 4096,
+ .num_ports = 6,
+ .port_base_addr = 0x10,
+ .global1_addr = 0x1b,
+ .age_time_coeff = 15000,
+ .tag_protocol = DSA_TAG_PROTO_EDSA,
+ .flags = MV88E6XXX_FLAGS_FAMILY_6341,
+ .ops = &mv88e6341_ops,
+ },
+
[MV88E6350] = {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6350,
.family = MV88E6XXX_FAMILY_6351,
diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
index ce8b43b14e96..e0527db0ef6e 100644
--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
@@ -100,6 +100,7 @@
#define PORT_SWITCH_ID_PROD_NUM_6240 0x240
#define PORT_SWITCH_ID_PROD_NUM_6290 0x290
#define PORT_SWITCH_ID_PROD_NUM_6321 0x310
+#define PORT_SWITCH_ID_PROD_NUM_6341 0x341
#define PORT_SWITCH_ID_PROD_NUM_6352 0x352
#define PORT_SWITCH_ID_PROD_NUM_6350 0x371
#define PORT_SWITCH_ID_PROD_NUM_6351 0x375
@@ -382,7 +383,7 @@
#define GLOBAL2_EEPROM_CMD_WRITE_EN BIT(10)
#define GLOBAL2_EEPROM_CMD_ADDR_MASK 0xff
#define GLOBAL2_EEPROM_DATA 0x15
-#define GLOBAL2_EEPROM_ADDR 0x15 /* 6390 */
+#define GLOBAL2_EEPROM_ADDR 0x15 /* 6390, 6341 */
#define GLOBAL2_PTP_AVB_OP 0x16
#define GLOBAL2_PTP_AVB_DATA 0x17
#define GLOBAL2_SMI_PHY_CMD 0x18
@@ -433,6 +434,7 @@ enum mv88e6xxx_model {
MV88E6290,
MV88E6320,
MV88E6321,
+ MV88E6341,
MV88E6350,
MV88E6351,
MV88E6352,
@@ -448,6 +450,7 @@ enum mv88e6xxx_family {
MV88E6XXX_FAMILY_6165, /* 6123 6161 6165 */
MV88E6XXX_FAMILY_6185, /* 6108 6121 6122 6131 6152 6155 6182 6185 */
MV88E6XXX_FAMILY_6320, /* 6320 6321 */
+ MV88E6XXX_FAMILY_6341, /* 6141 6341 */
MV88E6XXX_FAMILY_6351, /* 6171 6175 6350 6351 */
MV88E6XXX_FAMILY_6352, /* 6172 6176 6240 6352 */
MV88E6XXX_FAMILY_6390, /* 6190 6190X 6191 6290 6390 6390X */
@@ -601,6 +604,20 @@ enum mv88e6xxx_cap {
MV88E6XXX_FLAGS_MULTI_CHIP | \
MV88E6XXX_FLAGS_PVT)
+#define MV88E6XXX_FLAGS_FAMILY_6341 \
+ (MV88E6XXX_FLAG_EEE | \
+ MV88E6XXX_FLAG_G1_ATU_FID | \
+ MV88E6XXX_FLAG_G1_VTU_FID | \
+ MV88E6XXX_FLAG_GLOBAL2 | \
+ MV88E6XXX_FLAG_G2_INT | \
+ MV88E6XXX_FLAG_G2_POT | \
+ MV88E6XXX_FLAG_STU | \
+ MV88E6XXX_FLAG_VTU | \
+ MV88E6XXX_FLAGS_IRL | \
+ MV88E6XXX_FLAGS_MULTI_CHIP | \
+ MV88E6XXX_FLAGS_PVT | \
+ MV88E6XXX_FLAGS_SERDES)
+
#define MV88E6XXX_FLAGS_FAMILY_6351 \
(MV88E6XXX_FLAG_G1_ATU_FID | \
MV88E6XXX_FLAG_G1_VTU_FID | \
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH net-next v6 3/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6141
From: Gregory CLEMENT @ 2017-01-24 20:10 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, netdev,
linux-kernel
Cc: David S. Miller, Jason Cooper, Sebastian Hesselbarth,
Gregory CLEMENT, Thomas Petazzoni, linux-arm-kernel, Nadav Haklai,
Wilson Ding, Kostya Porotchkin, Joe Zhou, Jon Pannell
In-Reply-To: <cover.b0e18efe751186768e720c341693117fdd4d3c16.1485288602.git-series.gregory.clement@free-electrons.com>
The Marvell 88E6341 device is single-chip, 6-port Ethernet switch with
four integrated 10/100/1000Mbps Ethernet transceivers and one high speed
SerDes interfaces.
It belongs to the Topaz family and unlike the 88E6341 it does not have
a TCAM.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 42 ++++++++++++++++++++++++++++-
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 2 +-
2 files changed, 44 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 00db33ca1696..cdb8c7c4accd 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3572,6 +3572,34 @@ static const struct mv88e6xxx_ops mv88e6352_ops = {
.reset = mv88e6352_g1_reset,
};
+static const struct mv88e6xxx_ops mv88e6141_ops = {
+ /* MV88E6XXX_FAMILY_6341 */
+ .get_eeprom = mv88e6xxx_g2_get_eeprom8,
+ .set_eeprom = mv88e6xxx_g2_set_eeprom8,
+ .set_switch_mac = mv88e6xxx_g2_set_switch_mac,
+ .phy_read = mv88e6xxx_g2_smi_phy_read,
+ .phy_write = mv88e6xxx_g2_smi_phy_write,
+ .port_set_link = mv88e6xxx_port_set_link,
+ .port_set_duplex = mv88e6xxx_port_set_duplex,
+ .port_set_rgmii_delay = mv88e6390_port_set_rgmii_delay,
+ .port_set_speed = mv88e6390_port_set_speed,
+ .port_tag_remap = mv88e6095_port_tag_remap,
+ .port_set_frame_mode = mv88e6351_port_set_frame_mode,
+ .port_set_egress_unknowns = mv88e6351_port_set_egress_unknowns,
+ .port_set_ether_type = mv88e6351_port_set_ether_type,
+ .port_jumbo_config = mv88e6165_port_jumbo_config,
+ .port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
+ .port_pause_config = mv88e6097_port_pause_config,
+ .stats_snapshot = mv88e6390_g1_stats_snapshot,
+ .stats_get_sset_count = mv88e6320_stats_get_sset_count,
+ .stats_get_strings = mv88e6320_stats_get_strings,
+ .stats_get_stats = mv88e6390_stats_get_stats,
+ .g1_set_cpu_port = mv88e6390_g1_set_cpu_port,
+ .g1_set_egress_port = mv88e6390_g1_set_egress_port,
+ .mgmt_rsvd2cpu = mv88e6390_g1_mgmt_rsvd2cpu,
+ .reset = mv88e6352_g1_reset,
+};
+
static const struct mv88e6xxx_ops mv88e6341_ops = {
/* MV88E6XXX_FAMILY_6341 */
.get_eeprom = mv88e6xxx_g2_get_eeprom8,
@@ -3987,6 +4015,20 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.ops = &mv88e6321_ops,
},
+ [MV88E6141] = {
+ .prod_num = PORT_SWITCH_ID_PROD_NUM_6141,
+ .family = MV88E6XXX_FAMILY_6341,
+ .name = "Marvell 88E6341",
+ .num_databases = 4096,
+ .num_ports = 6,
+ .port_base_addr = 0x10,
+ .global1_addr = 0x1b,
+ .age_time_coeff = 15000,
+ .tag_protocol = DSA_TAG_PROTO_EDSA,
+ .flags = MV88E6XXX_FLAGS_FAMILY_6341,
+ .ops = &mv88e6141_ops,
+ },
+
[MV88E6341] = {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
.family = MV88E6XXX_FAMILY_6341,
diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
index e0527db0ef6e..94d1e98d4e2c 100644
--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
@@ -87,6 +87,7 @@
#define PORT_SWITCH_ID_PROD_NUM_6131 0x106
#define PORT_SWITCH_ID_PROD_NUM_6320 0x115
#define PORT_SWITCH_ID_PROD_NUM_6123 0x121
+#define PORT_SWITCH_ID_PROD_NUM_6141 0x340
#define PORT_SWITCH_ID_PROD_NUM_6161 0x161
#define PORT_SWITCH_ID_PROD_NUM_6165 0x165
#define PORT_SWITCH_ID_PROD_NUM_6171 0x171
@@ -420,6 +421,7 @@ enum mv88e6xxx_model {
MV88E6097,
MV88E6123,
MV88E6131,
+ MV88E6141,
MV88E6161,
MV88E6165,
MV88E6171,
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH net-next v6 4/4] phy: marvell: Add support for the PHY embedded in the topaz switch
From: Gregory CLEMENT @ 2017-01-24 20:10 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, netdev,
linux-kernel
Cc: David S. Miller, Jason Cooper, Sebastian Hesselbarth,
Gregory CLEMENT, Thomas Petazzoni, linux-arm-kernel, Nadav Haklai,
Wilson Ding, Kostya Porotchkin, Joe Zhou, Jon Pannell
In-Reply-To: <cover.b0e18efe751186768e720c341693117fdd4d3c16.1485288602.git-series.gregory.clement@free-electrons.com>
The PHY with the ID 0x1410C00 can be found embedded in the Marvell Topaz
switches (88E6141/88E6341). It is compatible with the 88E1510 (at least for
the temperature information), so add support for it, using the 88E1510
specific functions.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/net/phy/marvell.c | 21 +++++++++++++++++++++
include/linux/marvell_phy.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 64229976ace1..8b9338a746b8 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -2141,6 +2141,26 @@ static struct phy_driver marvell_drivers[] = {
.get_strings = marvell_get_strings,
.get_stats = marvell_get_stats,
},
+ {
+ .phy_id = MARVELL_PHY_ID_88E6141,
+ .phy_id_mask = MARVELL_PHY_ID_MASK,
+ .name = "Marvell 88E6141",
+ .probe = m88e1510_probe,
+ .remove = &marvell_remove,
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = &marvell_config_init,
+ .config_aneg = &m88e1510_config_aneg,
+ .read_status = &marvell_read_status,
+ .ack_interrupt = &marvell_ack_interrupt,
+ .config_intr = &marvell_config_intr,
+ .did_interrupt = &m88e1121_did_interrupt,
+ .resume = &genphy_resume,
+ .suspend = &genphy_suspend,
+ .get_sset_count = marvell_get_sset_count,
+ .get_strings = marvell_get_strings,
+ .get_stats = marvell_get_stats,
+ },
};
module_phy_driver(marvell_drivers);
@@ -2159,6 +2179,7 @@ static struct mdio_device_id __maybe_unused marvell_tbl[] = {
{ MARVELL_PHY_ID_88E1510, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E1540, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E3016, MARVELL_PHY_ID_MASK },
+ { MARVELL_PHY_ID_88E6141, MARVELL_PHY_ID_MASK },
{ }
};
diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
index a57f0dfb6db7..6f33b73f2044 100644
--- a/include/linux/marvell_phy.h
+++ b/include/linux/marvell_phy.h
@@ -5,6 +5,7 @@
#define MARVELL_PHY_ID_MASK 0xfffffff0
/* Known PHY IDs */
+#define MARVELL_PHY_ID_88E6141 0x01410c00
#define MARVELL_PHY_ID_88E1101 0x01410c60
#define MARVELL_PHY_ID_88E1112 0x01410c90
#define MARVELL_PHY_ID_88E1111 0x01410cc0
--
git-series 0.9.1
^ permalink raw reply related
* Re: [net PATCH v5 1/6] virtio_net: use dev_kfree_skb for small buffer XDP receive
From: David Miller @ 2017-01-24 20:11 UTC (permalink / raw)
To: mst
Cc: john.fastabend, jasowang, john.r.fastabend, netdev,
alexei.starovoitov, daniel
In-Reply-To: <20170124215412-mutt-send-email-mst@kernel.org>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Tue, 24 Jan 2017 22:08:33 +0200
> On Tue, Jan 24, 2017 at 02:43:28PM -0500, David Miller wrote:
>> From: "Michael S. Tsirkin" <mst@redhat.com>
>> Date: Mon, 23 Jan 2017 23:08:35 +0200
>>
>> > On Tue, Jan 17, 2017 at 02:19:50PM -0800, John Fastabend wrote:
>> >> In the small buffer case during driver unload we currently use
>> >> put_page instead of dev_kfree_skb. Resolve this by adding a check
>> >> for virtnet mode when checking XDP queue type. Also name the
>> >> function so that the code reads correctly to match the additional
>> >> check.
>> >>
>> >> Fixes: bb91accf2733 ("virtio-net: XDP support for small buffers")
>> >> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> >> Acked-by: Jason Wang <jasowang@redhat.com>
>> >
>> > Acked-by: Michael S. Tsirkin <mst@redhat.com>
>> >
>> > I think we definitely want this one in -net as it's
>> > a bugfix.
>>
>> This whole series is a bug fix, we must have adjust_header XDP
>> support in the virtio_net driver before v4.10 goes out, it is
>> a requires base feature for XDP.
>
> I have to say device resets outside probe have a huge potential
> to uncover hypervisor bugs. I am rather uncomfortable
> doing that after -rc1.
>
> How about a module option to disable it by default?
> We can then ship a partial implementation in 4.10
> and work on completing it in 4.11.
XDP programmers must be able to assume a base set of features being
present, adjust_header is one of them.
^ 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