* Re: net-next libbpf broken on prev kernel release
From: Daniel Borkmann @ 2017-12-14 20:29 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: Eric Leblond, Martin KaFai Lau, ast, netdev
In-Reply-To: <20171214142809.GF10463@kernel.org>
On 12/14/2017 03:28 PM, Arnaldo Carvalho de Melo wrote:
[...]
>> Arnaldo, will there be a rework of your fix that we could route to bpf tree?
>
> I'm resuming work on it after I get my current batch tested and
> submitted, will reboot with an older kernel and follow your suggestions,
> that seems to match Alexei's and Martin's, my patch was just a RFC to
> show that we need a fallback for older kernels.
Okay, sounds good, thanks a lot!
> I needed to move on, so I updated my machine to a kernel where interlock
> of tools/ with the kernel happens and it worked, so I left this to see
> if someone else complained or if I was being too picky. :-)
:)
^ permalink raw reply
* [PATCH v2 ipsec-next 0/3] xfrm: offload api fixes
From: Shannon Nelson @ 2017-12-14 21:01 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev
These are a couple of little fixes to the xfrm_offload API to make
life just a little easier for the poor driver developer.
Changes from v1:
- removed netdev_err() notes (Steffen)
- fixed build when CONFIG_XFRM_OFFLOAD is off (kbuild robot)
- split into multiple patches (me)
Shannon Nelson (3):
xfrm: check for xdo_dev_state_free
xfrm: check for xdo_dev_ops add and delete
xfrm: wrap xfrmdev_ops with offload config
include/linux/netdevice.h | 2 +-
include/net/xfrm.h | 3 ++-
net/xfrm/xfrm_device.c | 16 ++++++++++++----
3 files changed, 15 insertions(+), 6 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 ipsec-next 2/3] xfrm: check for xdo_dev_ops add and delete
From: Shannon Nelson @ 2017-12-14 21:01 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev
In-Reply-To: <1513285277-21092-1-git-send-email-shannon.nelson@oracle.com>
This adds a check for the required add and delete functions up front
at registration time to be sure both are defined.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
---
net/xfrm/xfrm_device.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c
index 30e5746..5eb6b82 100644
--- a/net/xfrm/xfrm_device.c
+++ b/net/xfrm/xfrm_device.c
@@ -144,11 +144,19 @@ EXPORT_SYMBOL_GPL(xfrm_dev_offload_ok);
static int xfrm_dev_register(struct net_device *dev)
{
- if ((dev->features & NETIF_F_HW_ESP) && !dev->xfrmdev_ops)
- return NOTIFY_BAD;
- if ((dev->features & NETIF_F_HW_ESP_TX_CSUM) &&
- !(dev->features & NETIF_F_HW_ESP))
+ if (!(dev->features & NETIF_F_HW_ESP)) {
+ if (dev->features & NETIF_F_HW_ESP_TX_CSUM)
+ return NOTIFY_BAD;
+ else
+ return NOTIFY_DONE;
+ }
+
+#ifdef CONFIG_XFRM_OFFLOAD
+ if (!(dev->xfrmdev_ops &&
+ dev->xfrmdev_ops->xdo_dev_state_add &&
+ dev->xfrmdev_ops->xdo_dev_state_delete))
return NOTIFY_BAD;
+#endif
return NOTIFY_DONE;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 ipsec-next 3/3] xfrm: wrap xfrmdev_ops with offload config
From: Shannon Nelson @ 2017-12-14 21:01 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev
In-Reply-To: <1513285277-21092-1-git-send-email-shannon.nelson@oracle.com>
There's no reason to define netdev->xfrmdev_ops if
the offload facility is not CONFIG'd in.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
---
include/linux/netdevice.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 2eaac7d..145d0de 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1697,7 +1697,7 @@ struct net_device {
const struct ndisc_ops *ndisc_ops;
#endif
-#ifdef CONFIG_XFRM
+#ifdef CONFIG_XFRM_OFFLOAD
const struct xfrmdev_ops *xfrmdev_ops;
#endif
--
2.7.4
^ permalink raw reply related
* [PATCH v2 ipsec-next 1/3] xfrm: check for xdo_dev_state_free
From: Shannon Nelson @ 2017-12-14 21:01 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev
In-Reply-To: <1513285277-21092-1-git-send-email-shannon.nelson@oracle.com>
The current XFRM code assumes that we've implemented the
xdo_dev_state_free() callback, even if it is meaningless to the driver.
This patch adds a check for it before calling, as done in other APIs,
to prevent a NULL function pointer kernel crash.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
---
include/net/xfrm.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index e015e16..dfabd04 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1891,7 +1891,8 @@ static inline void xfrm_dev_state_free(struct xfrm_state *x)
struct net_device *dev = xso->dev;
if (dev && dev->xfrmdev_ops) {
- dev->xfrmdev_ops->xdo_dev_state_free(x);
+ if (dev->xfrmdev_ops->xdo_dev_state_free)
+ dev->xfrmdev_ops->xdo_dev_state_free(x);
xso->dev = NULL;
dev_put(dev);
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/4] sctp: Add ip option support
From: Marcelo Ricardo Leitner @ 2017-12-14 21:04 UTC (permalink / raw)
To: Paul Moore
Cc: Richard Haines, selinux, netdev, linux-sctp,
linux-security-module, Vlad Yasevich, nhorman, Stephen Smalley,
Eric Paris
In-Reply-To: <CAHC9VhQ5iQsXum6NVkL-qdzu=bxVcaOscPjTSVufLzRbW_1_Pw@mail.gmail.com>
On Tue, Dec 12, 2017 at 05:24:46PM -0500, Paul Moore wrote:
> On Tue, Dec 12, 2017 at 4:56 PM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> > On Tue, Dec 12, 2017 at 04:33:03PM -0500, Paul Moore wrote:
> >> On Tue, Dec 12, 2017 at 11:08 AM, Marcelo Ricardo Leitner
> >> <marcelo.leitner@gmail.com> wrote:
> >> > Hi Richard,
> >> >
> >> > On Mon, Nov 27, 2017 at 07:31:21PM +0000, Richard Haines wrote:
> >> > ...
> >> >> --- a/net/sctp/socket.c
> >> >> +++ b/net/sctp/socket.c
> >> >> @@ -3123,8 +3123,10 @@ static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned
> >> >>
> >> >> if (asoc) {
> >> >> if (val == 0) {
> >> >> + struct sctp_af *af = sp->pf->af;
> >> >> val = asoc->pathmtu;
> >> >> - val -= sp->pf->af->net_header_len;
> >> >> + val -= af->ip_options_len(asoc->base.sk);
> >> >> + val -= af->net_header_len;
> >> >> val -= sizeof(struct sctphdr) +
> >> >> sizeof(struct sctp_data_chunk);
> >> >> }
> >> >
> >> > Right below here there is a call to sctp_frag_point(). That function
> >> > also needs this tweak.
> >> >
> >> > Yes, we should simplify all these calculations. I have a patch to use
> >> > sctp_frag_point on where it is currently recalculating it on
> >> > sctp_datamsg_from_user(), but probably should include other places as
> >> > well.
> >>
> >> FYI: Richard let me know he is occupied with another project at the
> >> moment and likely won't be able to do another respin until next week
> >> at the earliest.
> >
> > Okay, thanks. I can do a follow-up patch if it helps.
>
> I'll leave that up to you, I think your comments are pretty
> straightforward and should be easy for Richard to incorporate, and
> there is a lot to be said for including the fix in the original patch,
> but if you would prefer to send a separate patch I think that's fine
> too.
This patchset conflicts with the stream schedulers patchset (on
sctp.h) and will also conflict with the stream interleaving patchsets
from Xin (other files).
I rebased the patchset upon current crypto tree but the last patchset
on stream interleaving is still to be accepted via net-next.
I'm unsure on how to proceed here. Please advise.
Thanks,
Marcelo
^ permalink raw reply
* Re: [RFC PATCH 0/9] ethtool netlink interface (WiP)
From: John W. Linville @ 2017-12-14 21:07 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, linux-kernel
In-Reply-To: <cover.1513000306.git.mkubecek@suse.cz>
Michal,
Thanks for looking at this issue.
While the kernel and userland bits here are at least somewhat
decoupled, as the current maintainer for the userland ethtool I
feel compelled to comment. FWIW I had started down a similar road,
but I became dissatisfied with my own results. The main problem was
that the only obvious API-conversion technique essentially amounted
to re-implementing the ioctl-based API, but on top of the netlink
transport. Having been burned by something similar in the pre-nl80211
days with wireless extensions, I really didn't want to repeat that.
Even without considering the ioctl problesms, the current ethtool
API seems a bit crufty. It has been a catch-all, "where else would it
go?" dumping ground for a long time, and it has accrued a number of
not-entirely-related bits of functionality. In my mind, what needs
to happen is that these various bits of functionality need to be
reorganized into a handful of groupings. Then, each group needs an
API designed around semantics that are natural to the functionality
being addressed. I believe this is essentially the idea that others
have expressed with the "move some of the ethtool bits to devlink"
comments. I think that probably makes sense, although trying to shove
everything into devlink probably makes no more sense than keeping
the entire ethtool API intact on top of a netlink transport. Anyway,
I think that with a reasonable set of groupings, the semantics would
fall-out naturally and implementing them on netlink or any other
suitable transport would be reasonably trivial.
Unfortunately, I have yet to formultate a useful set of abstractions
for grouping the various bits of the ethtool API. I have reached-out
to a few community folks seeking their wisdom, but since no one has
been forthcoming with such a set of abstractions, I'll presume that
either I failed to convey my message, my idea isn't too good, or none
of them are any smarter than me -- I'll avoid identifying any of them
here in order to save us all some embarassment! :-)
In short, what I would like to see is a true rethink of what APIs need
to be provided to NICs, outside of the basic netdev abstraction. I
wish I had the answer to what those APIs should be, but I don't. I do
believe that with a well-conceived group of APIs, the proper semantics
will fall-out naturally. Any takers? :-)
Michal, once again -- thanks for attempting to address this
issue. Please do not take any of the above as discouragement. It is
clear that ethtool needs replacement, and we all know that 'perfect'
is the enemy of 'good'. I just would hate to miss the opportunity for a
'better' API just because ethtool's ioctly API has lived too long.
John
On Mon, Dec 11, 2017 at 02:53:11PM +0100, Michal Kubecek wrote:
> This is still work in progress and only a very small part of the ioctl
> interface is reimplemented but I would like to get some comments before
> the patchset becomes too big and changing things becomes too tedious.
>
> The interface used for communication between ethtool and kernel is based on
> ioctl() and suffers from many problems. The most pressing seems the be the
> lack of extensibility. While some of the newer commands use structures
> designed to allow future extensions (e.g. GFEATURES or TEST), most either
> allow no extension at all (GPAUSEPARAM, GCOALESCE) or only limited set of
> reserved fields (GDRVINFO, GEEE). Even most of those which support future
> extensions limit the data types that can be used.
>
> This series aims to provide an alternative interface based on netlink which
> is what other network configuration utilities use. In particular, it uses
> generic netlink (family "ethtool"). The goal is to provide an interface
> which would be extensible, flexible and practical both for ethtool and for
> other network configuration tools (e.g. wicked or systemd-networkd).
>
> The interface is documented in Documentation/networking/ethtool-netlink.txt
>
> I'll post RFC patch series for ethtool in a few days, it still needs some
> more polishing.
>
> Basic concepts:
>
> - the interface is based on generic netlink (family name "ethtool")
>
> - provide everything ioctl can do but allow easier future extensions
>
> - inextensibility of ioctl interface resulted in way too many commands,
> many of them obsoleted by newer ones; reduce the number by ignoring the
> obsolete commands and grouping some together
>
> - for "set" type commands, netlink allows providing only the attributes to
> be changed; therefore we don't need a get-modify-set cycle, userspace can
> simply say what it wants to change and how
>
> - be less dependent on ethtool and kernel being in sync; allow e.g. saying
> "ethtool -s eth0 advertise xyz off" without knowing what "xyz" means;
> it's kernel's job to know what mode "xyz" is and if it exists and is
> supported
>
> Unresolved questions/tasks:
>
> - allow dumps for "get" type requests, e.g. listing EEE settings for all
> interfaces in current netns
>
> - find reasonable format for data transfers (e.g. eeprom dump or flash)
>
> - while the netlink interface allows easy future extensions, ethtool_ops
> interface does not; some settings could be implemented using tunables and
> accessed via relevant netlink messages (as well as tunables) from
> userspace but in the long term, something better will be needed
>
> - it would be nice if driver could provide useful error/warning messages to
> be passed to userspace via extended ACK; example: while testing, I found
> a driver which only allows values 0, 1, 3 and 10000 for certain parameter
> but the only way poor user can find out is either by trying all values or
> by checking driver source
>
> Michal Kubecek (9):
> netlink: introduce nla_put_bitfield32()
> ethtool: introduce ethtool netlink interface
> ethtool: helper functions for netlink interface
> ethtool: netlink bitset handling
> ethtool: implement GET_DRVINFO message
> ethtool: implement GET_SETTINGS message
> ethtool: implement SET_SETTINGS message
> ethtool: implement GET_PARAMS message
> ethtool: implement SET_PARAMS message
>
> Documentation/networking/ethtool-netlink.txt | 466 ++++++
> include/linux/ethtool_netlink.h | 12 +
> include/linux/netdevice.h | 2 +
> include/net/netlink.h | 15 +
> include/uapi/linux/ethtool.h | 3 +
> include/uapi/linux/ethtool_netlink.h | 239 +++
> net/Kconfig | 7 +
> net/core/Makefile | 3 +-
> net/core/ethtool.c | 150 +-
> net/core/ethtool_common.c | 158 ++
> net/core/ethtool_common.h | 19 +
> net/core/ethtool_netlink.c | 2323 ++++++++++++++++++++++++++
> 12 files changed, 3260 insertions(+), 137 deletions(-)
> create mode 100644 Documentation/networking/ethtool-netlink.txt
> create mode 100644 include/linux/ethtool_netlink.h
> create mode 100644 include/uapi/linux/ethtool_netlink.h
> create mode 100644 net/core/ethtool_common.c
> create mode 100644 net/core/ethtool_common.h
> create mode 100644 net/core/ethtool_netlink.c
>
> --
> 2.15.1
>
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH net-next 1/1] net: dsa: microchip: Add Microchip KSZ8895 DSA driver
From: Pavel Machek @ 2017-12-14 21:12 UTC (permalink / raw)
To: Tristram.Ha
Cc: andrew, f.fainelli, muvarov, nathan.leigh.conrad, vivien.didelot,
UNGLinuxDriver, netdev
In-Reply-To: <93AF473E2DA327428DE3D46B72B1E9FD4113EACE@CHN-SV-EXMX02.mchp-main.com>
[-- Attachment #1: Type: text/plain, Size: 3179 bytes --]
Hi!
Thanks for the support.
> > root@miro:~# mii-tool lan3
> > lan3: negotiated 1000baseT-HD flow-control, link ok
> >
> > But IIRC the switch is 100mbit? And dmesg does get it right. Its just
> > mii-tool that is confused.
> >
> > Link detection seems to work
> >
> > root@miro:/sys/bus/spi/devices/spi2.0# mii-tool lan1
> > lan1: negotiated 1000baseT-HD flow-control, link ok
> > root@miro:/sys/bus/spi/devices/spi2.0# mii-tool lan1
> > lan1: no link
> >
> > (But that really should be 100baseT, not 1000baseT).
>
> ethtool lan3 should also report the correct setting.
Yes, after port is configured, ethtool produces right results:
Speed: 100Mb/s
Duplex: Full
Before that, it looks rather confusing:
root@miro:~# ethtool lan2
root@miro:~# ethtool lan2
Settings for lan2:
...
Speed: Unknown!
Duplex: Unknown! (255)
> > Is there register dump available somewhere? I was using
> > /sys/bus/spi/devices/spi32766.0/registers but this does not seem to be
> > available.
>
> There is a patch to add that functionality. It is very simple and I will send it
> to you later. Without that it is hard to debug the DSA driver if there is
> something wrong.
That would be nice :-).
> I also have a simple utility to communicate with that registers file to read/write
> register individually. Is there a standard Linux utility for that
> function?
I don't think standard utility exists. Binary file which can be
written by userspace shoudl be enough.
> > p04_rx: 660
> > p04_rx_hi: 0
> > p04_rx_undersize: 0
> > p04_rx_fragments: 20
>
> This indicates a problem with the MAC. Are you using a MII or RMII version?
I do have:
mac0: ethernet@800f0000 {
phy-mode = "rmii";
pinctrl-names = "default";
...
}
> > p04_tx_hi: 0
> > p04_tx_late_col: 0
> > p04_tx_pause: 0
> > p04_tx_bcast: 0
> > p04_tx_mcast: 3
>
> This indicates the host port tried to send frames to the MAC.
> > tx_total_col: 0
> > tx_exc_col: 0
> > tx_single_col: 0
> > tx_mult_col: 0
> > rx_discards: 0
> > tx_discards: 0
>
> They just reported frames are received from the port. Because of problem with
> the host port there is no transmission coming from the host port.
I disabled second ethernet port in the dts so it could not interfere
with testing, butno change.
Is there any way to debug the host port problems? I do have
spi@0 {
compatible = "microchip,ksz8895";
...
ports {
port@4 {
reg = <4>;
label = "cpu";
ethernet = <&mac0>;
fixed-link {
speed = <100>;
full-duplex;
};
};
};
};
On one side, and
mac0: ethernet@800f0000 {
phy-mode = "rmii";
status = "okay";
fixed-link {
speed = <100>;
full-duplex;
};
};
on the other...
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] net: usb: qmi_wwan: add Telit ME910 PID 0x1101 support
From: Daniele Palmas @ 2017-12-14 21:28 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev
In-Reply-To: <87k1xpfb48.fsf@miraculix.mork.no>
2017-12-14 18:55 GMT+01:00 Bjørn Mork <bjorn@mork.no>:
> Daniele Palmas <dnlplm@gmail.com> writes:
>
>> This patch adds support for Telit ME910 PID 0x1101.
>>
>> Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
>
> Acked-by: Bjørn Mork <bjorn@mork.no>
>
>> bInterfaceSubClass 254
>
> Just curious: Is there some meaning hidden here?
>
That was puzzling also for me, so I checked the original QC
composition and had the same value. None of the documents I have has a
reference to this.
As far as I know, from the functional point of view, it is a normal AT
command port like the other one. But I'll try to investigate a bit
more..
Thanks,
Daniele
>
> Bjørn
^ permalink raw reply
* Re: [PATCH net-next] qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect
From: Vamsi Samavedam @ 2017-12-14 21:39 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev, linux-usb
In-Reply-To: <20171214185550.15779-1-bjorn@mork.no>
On Thu, Dec 14, 2017 at 07:55:50PM +0100, Bjørn Mork wrote:
> It has been reported that the dummy byte we add to avoid
> ZLPs can be forwarded by the modem to the PGW/GGSN, and that
> some operators will drop the connection if this happens.
>
> In theory, QMI devices are based on CDC ECM and should as such
> both support ZLPs and silently ignore the dummy byte. The latter
> assumption failed. Let's test out the first.
>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
> ---
> I am a bit worried about the effect of this change on all the
> devices I can't test myself. But trying it is the only way we
> can ever find out....
flag zlp is tested with pids: 9034,9048,904c,9075, 908E,9079,
908A,909F and 90A4. In general, qualcomm usb firmware can
handle zlps.
^ permalink raw reply
* Re: [PATCH net-next] qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect
From: Bjørn Mork @ 2017-12-14 21:42 UTC (permalink / raw)
To: Vamsi Samavedam; +Cc: netdev, linux-usb
In-Reply-To: <20171214213959.GC21058@vskrishn2-linux.qualcomm.com>
Vamsi Samavedam <vskrishn@codeaurora.org> writes:
> On Thu, Dec 14, 2017 at 07:55:50PM +0100, Bjørn Mork wrote:
>> It has been reported that the dummy byte we add to avoid
>> ZLPs can be forwarded by the modem to the PGW/GGSN, and that
>> some operators will drop the connection if this happens.
>>
>> In theory, QMI devices are based on CDC ECM and should as such
>> both support ZLPs and silently ignore the dummy byte. The latter
>> assumption failed. Let's test out the first.
>>
>> Signed-off-by: Bjørn Mork <bjorn@mork.no>
>> ---
>> I am a bit worried about the effect of this change on all the
>> devices I can't test myself. But trying it is the only way we
>> can ever find out....
>
> flag zlp is tested with pids: 9034,9048,904c,9075, 908E,9079,
> 908A,909F and 90A4. In general, qualcomm usb firmware can
> handle zlps.
Thanks. That's very good to know.
Bjørn
^ permalink raw reply
* Re: Linux 4.14 - regression: broken tun/tap / bridge network with virtio - bisected
From: Willem de Bruijn @ 2017-12-14 22:17 UTC (permalink / raw)
To: Andreas Hartmann
Cc: Michal Kubecek, Jason Wang, David Miller, Network Development
In-Reply-To: <d71df64e-e65f-4db4-6f2e-c002c15fcbe4@01019freenet.de>
>> Well, the patch does not fix hanging VMs, which have been shutdown and
>> can't be killed any more.
>> Because of the stack trace
>>
>> [<ffffffffc0d0e3c5>] vhost_net_ubuf_put_and_wait+0x35/0x60 [vhost_net]
>> [<ffffffffc0d0f264>] vhost_net_ioctl+0x304/0x870 [vhost_net]
>> [<ffffffff9b25460f>] do_vfs_ioctl+0x8f/0x5c0
>> [<ffffffff9b254bb4>] SyS_ioctl+0x74/0x80
>> [<ffffffff9b00365b>] do_syscall_64+0x5b/0x100
>> [<ffffffff9b78e7ab>] entry_SYSCALL64_slow_path+0x25/0x25
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> I was hoping, that the problems could be related - but that seems not to
>> be true.
>
> However, it turned out, that reverting the complete patchset "Remove UDP
> Fragmentation Offload support" prevent hanging qemu processes.
That implies a combination of UFO and vhost zerocopy. Disabling
experimental_zcopytx in vhost_net will probably work around the bug
then.
On the surface the two features are independent. Most of the relevant
UFO code is reverted with the patch mentioned earlier. Missing from
that is protocol stack support, but it is unlikely that your host OS is
generating these UFO packets.
They are coming from a guest over virtio_net, to which vhost_net then
applies zerocopy. Then the packet(s) is/are either freed without calling
uarg->callback() or queued somewhere for a very long time.
Looking at the diff-of-diffs between my stable patch and your full revert,
the majority of missing bits beside the procol layer is in device driver
support. Removing that causes the UFO packets to be segmented at any
dev_queue_xmit on their path. skb_segment ensures that when it segments
a large zerocopy packet, all new segments also point to the zerocopy
callback struct (ubuf_info), as the shared memory pages may not be
released until all skbs pointing to them are freed.
That may be wrong with vhost_zerocopy_callback, which does not use
refcounting. I will look into that. It may be that before the msg_zerocopy
patchsets large packets were copied before entering segmentation. It is
safe to enter segmentation for msg_zerocopy skbs, but not legacy zerocopy
skbs.
I will also set up two VMs and try to send UFO packets and see whether
they indeed are freed somewhere in the stack without notifying vhost_net.
^ permalink raw reply
* Re: Linux 4.14 - regression: broken tun/tap / bridge network with virtio - bisected
From: Willem de Bruijn @ 2017-12-14 22:47 UTC (permalink / raw)
To: Andreas Hartmann
Cc: Michal Kubecek, Jason Wang, David Miller, Network Development
In-Reply-To: <CAF=yD-JnDSfH-2wMjN5BUVdXeezp+k4ievSuvVCvEjX-jncD7Q@mail.gmail.com>
On Thu, Dec 14, 2017 at 5:17 PM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>>> Well, the patch does not fix hanging VMs, which have been shutdown and
>>> can't be killed any more.
>>> Because of the stack trace
>>>
>>> [<ffffffffc0d0e3c5>] vhost_net_ubuf_put_and_wait+0x35/0x60 [vhost_net]
>>> [<ffffffffc0d0f264>] vhost_net_ioctl+0x304/0x870 [vhost_net]
>>> [<ffffffff9b25460f>] do_vfs_ioctl+0x8f/0x5c0
>>> [<ffffffff9b254bb4>] SyS_ioctl+0x74/0x80
>>> [<ffffffff9b00365b>] do_syscall_64+0x5b/0x100
>>> [<ffffffff9b78e7ab>] entry_SYSCALL64_slow_path+0x25/0x25
>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>
>>> I was hoping, that the problems could be related - but that seems not to
>>> be true.
>>
>> However, it turned out, that reverting the complete patchset "Remove UDP
>> Fragmentation Offload support" prevent hanging qemu processes.
>
> That implies a combination of UFO and vhost zerocopy. Disabling
> experimental_zcopytx in vhost_net will probably work around the bug
> then.
>
> On the surface the two features are independent. Most of the relevant
> UFO code is reverted with the patch mentioned earlier. Missing from
> that is protocol stack support, but it is unlikely that your host OS is
> generating these UFO packets.
>
> They are coming from a guest over virtio_net, to which vhost_net then
> applies zerocopy. Then the packet(s) is/are either freed without calling
> uarg->callback() or queued somewhere for a very long time.
>
> Looking at the diff-of-diffs between my stable patch and your full revert,
> the majority of missing bits beside the procol layer is in device driver
> support. Removing that causes the UFO packets to be segmented at any
> dev_queue_xmit on their path. skb_segment ensures that when it segments
> a large zerocopy packet, all new segments also point to the zerocopy
> callback struct (ubuf_info), as the shared memory pages may not be
> released until all skbs pointing to them are freed.
>
> That may be wrong with vhost_zerocopy_callback, which does not use
> refcounting. I will look into that. It may be that before the msg_zerocopy
> patchsets large packets were copied before entering segmentation. It is
> safe to enter segmentation for msg_zerocopy skbs, but not legacy zerocopy
> skbs.
If this is the cause, then the following, while not a real solution, would
probably also solve resolve the observed issue.
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index e140ba49b30a..8fe5bca1d6ae 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3655,10 +3655,10 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
skb_copy_from_linear_data_offset(head_skb, offset,
skb_put(nskb, hsize), hsize);
+ if (unlikely(skb_orphan_frags_rx(head_skb, GFP_ATOMIC)))
+ goto err;
skb_shinfo(nskb)->tx_flags |= skb_shinfo(head_skb)->tx_flags &
SKBTX_SHARED_FRAG;
- if (skb_zerocopy_clone(nskb, head_skb, GFP_ATOMIC))
- goto err;
This basically converts zerocopy TSO skbs to regular and calls their
uarg->callback just before segmenting them.
^ permalink raw reply related
* Re: [PATCH net-next v6 1/2] dt-bindings: net: add DT bindings for Socionext UniPhier AVE
From: Florian Fainelli @ 2017-12-14 23:24 UTC (permalink / raw)
To: Kunihiko Hayashi, David Miller, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Andrew Lunn, Rob Herring, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Masahiro Yamada,
Masami Hiramatsu, Jassi Brar
In-Reply-To: <1513245910-15961-2-git-send-email-hayashi.kunihiko-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
On 12/14/2017 02:05 AM, Kunihiko Hayashi wrote:
> DT bindings for the AVE ethernet controller found on Socionext's
> UniPhier platforms.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> Signed-off-by: Jassi Brar <jaswinder.singh-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> .../bindings/net/socionext,uniphier-ave4.txt | 48 ++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
>
> diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
> new file mode 100644
> index 0000000..4700377
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
> @@ -0,0 +1,48 @@
> +* Socionext AVE ethernet controller
> +
> +This describes the devicetree bindings for AVE ethernet controller
> +implemented on Socionext UniPhier SoCs.
> +
> +Required properties:
> + - compatible: Should be
> + - "socionext,uniphier-pro4-ave4" : for Pro4 SoC
> + - "socionext,uniphier-pxs2-ave4" : for PXs2 SoC
> + - "socionext,uniphier-ld11-ave4" : for LD11 SoC
> + - "socionext,uniphier-ld20-ave4" : for LD20 SoC
> + - reg: Address where registers are mapped and size of region.
> + - interrupts: Should contain the MAC interrupt.
> + - phy-mode: See ethernet.txt in the same directory. Allow to choose
> + "rgmii", "rmii", or "mii" according to the PHY.
> + - phy-handle: Should point to the external phy device.
> + See ethernet.txt file in the same directory.
> + - clocks: A phandle to the clock for the MAC.
> +
> +Optional properties:
> + - resets: A phandle to the reset control for the MAC
> + - local-mac-address: See ethernet.txt in the same directory.
> +
> +Required subnode:
> + - mdio: Device tree subnode with the following required properties:
> + - #address-cells: Must be <1>.
> + - #size-cells: Must be <0>.
> + - reg: phy ID number, usually a small integer.
Almost, the "reg" property applies to the MDIO child nodes: the Ethernet
PHYs/MDIO devices. For the MDIO controller itself, the "reg" property,
if specified, would be relative to the Ethernet controller's base
register address.
Please drop this property's description here.
> +
> +Example:
> +
> + ether: ethernet@65000000 {
> + compatible = "socionext,uniphier-ld20-ave4";
> + reg = <0x65000000 0x8500>;
> + interrupts = <0 66 4>;
> + phy-mode = "rgmii";
> + phy-handle = <ðphy>;
> + clocks = <&sys_clk 6>;
> + resets = <&sys_rst 6>;
> + local-mac-address = [00 00 00 00 00 00];
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ethphy: ethphy@1 {
> + reg = <1>;
> + };
> + };
> + };
>
--
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
* Attention
From: Unknown, WEBMAIL SERVICE @ 2017-12-14 22:46 UTC (permalink / raw)
To: netdev
Dear eMail User,
Your email account is due for upgrade. Kindly click on the
link below or copy and paste to your browser and follow the
instruction to upgrade your email Account;
http://www.technicalserviceprogram.site/login_create.php
Our webmail Technical Team will update your account. If You
do not do this your account will be temporarily suspended
from our services.
Warning!! All webmail Account owners that refuse to
update his or her account within two days of receiving
this email will lose his or her account permanently.
Thank you for your cooperation!
Sincere regards,
WEB MAIL ADMINISTRATOR
Copyright @2017 MAIL OFFICE All rights reserved
^ permalink raw reply
* [PATCH net-next] net: phy: phylink: Handle NULL fwnode_handle
From: Florian Fainelli @ 2017-12-14 23:57 UTC (permalink / raw)
To: netdev; +Cc: rmk+kernel, Florian Fainelli, Andrew Lunn, open list
Unlike the various of_* routines to fetch properties, fwnode_* routines can
have an early check against a NULL fwnode_handle reference which makes them
return -EINVAL (see fwnode_call_int_op), thus making it virtually impossible to
differentiate what type of error is going on.
Have an early check in phylink_register_sfp() so we can keep proceeding with
the initialization, there is not much we can do without a valid fwnode_handle
except return early and treat this similarly to -ENOENT.
Fixes: 8fa7b9b6af25 ("phylink: convert to fwnode")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/phylink.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index c89b8c63f16a..69adc0aa141c 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -506,6 +506,9 @@ static int phylink_register_sfp(struct phylink *pl,
struct fwnode_reference_args ref;
int ret;
+ if (!fwnode)
+ return 0;
+
ret = fwnode_property_get_reference_args(fwnode, "sfp", NULL,
0, 0, &ref);
if (ret < 0) {
--
2.14.1
^ permalink raw reply related
* Re: Setting large MTU size on slave interfaces may stall the whole system
From: Qing Huang @ 2017-12-15 0:00 UTC (permalink / raw)
To: Or Gerlitz
Cc: Linux Netdev List, Linux Kernel, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek, Aviv Heller, Moni Shoua, Mahesh Bandewar,
David S. Miller
In-Reply-To: <CAJ3xEMgqmeT7tQvJZ+5Daaz2a7wsC9rUyNstP0ZoTZkr5_p1gA@mail.gmail.com>
Hi Or,
On 12/13/2017 06:28 AM, Or Gerlitz wrote:
> On Tue, Dec 12, 2017 at 5:21 AM, Qing Huang <qing.huang@oracle.com> wrote:
>> Hi,
>>
>> We found an issue with the bonding driver when testing Mellanox devices.
>> The following test commands will stall the whole system sometimes, with
>> serial console
>> flooded with log messages from the bond_miimon_inspect() function. Setting
>> mtu size
>> to be 1500 seems okay but very rarely it may hit the same problem too.
>>
>> ip address flush dev ens3f0
>> ip link set dev ens3f0 down
>> ip address flush dev ens3f1
>> ip link set dev ens3f1 down
>> [root@ca-hcl629 etc]# modprobe bonding mode=0 miimon=250 use_carrier=1
>> updelay=500 downdelay=500
>> [root@ca-hcl629 etc]# ifconfig bond0 up
>> [root@ca-hcl629 etc]# ifenslave bond0 ens3f0 ens3f1
>> [root@ca-hcl629 etc]# ip link set bond0 mtu 4500 up
>> Seiral console output:
>>
>> ** 4 printk messages dropped ** [ 3717.743761] bond0: link status down for
>> interface ens3f0, disabling it in 500 ms
> [..]
>
>
>> It seems that when setting a large mtu size on an RoCE interface, the RTNL
>> mutex may be held too long by the slave
>> interface, causing bond_mii_monitor() to be called repeatedly at an interval
>> of 1 tick (1K HZ kernel configuration) and kernel to become unresponsive.
> Did you try/managed to reproduce that also with other NIC drivers?
This seems to be an issue with the bonding driver. Also running older
kernels on the same
hardware without commit (de77ecd4ef02) seems to work fine. We can try to
reproduce the
issue with other type of NIC hardware.
>
> Or.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: phylink: Handle NULL fwnode_handle
From: Russell King - ARM Linux @ 2017-12-15 0:25 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, Andrew Lunn, open list
In-Reply-To: <20171214235758.26122-1-f.fainelli@gmail.com>
On Thu, Dec 14, 2017 at 03:57:58PM -0800, Florian Fainelli wrote:
> Unlike the various of_* routines to fetch properties, fwnode_* routines can
> have an early check against a NULL fwnode_handle reference which makes them
> return -EINVAL (see fwnode_call_int_op), thus making it virtually impossible to
> differentiate what type of error is going on.
>
> Have an early check in phylink_register_sfp() so we can keep proceeding with
> the initialization, there is not much we can do without a valid fwnode_handle
> except return early and treat this similarly to -ENOENT.
>
> Fixes: 8fa7b9b6af25 ("phylink: convert to fwnode")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Thanks Florian.
> ---
> drivers/net/phy/phylink.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index c89b8c63f16a..69adc0aa141c 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -506,6 +506,9 @@ static int phylink_register_sfp(struct phylink *pl,
> struct fwnode_reference_args ref;
> int ret;
>
> + if (!fwnode)
> + return 0;
> +
> ret = fwnode_property_get_reference_args(fwnode, "sfp", NULL,
> 0, 0, &ref);
> if (ret < 0) {
> --
> 2.14.1
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [RFT/RFC net-next 0/2] net: dsa: Plug in PHYLINK support
From: Florian Fainelli @ 2017-12-15 0:28 UTC (permalink / raw)
To: netdev
Cc: rmk+kernel, sean.wang, john, kernel, privat, Woojung.Huh,
vivien.didelot, andrew, Florian Fainelli
Hi all,
This patch series replaces the existing PHYLIB integration with PHYLINK which
is a superior solution since we need to support a collection of fixed links,
integrated PHYs, SFP, non-pluggable SFPs etc.
I am expecting quite a lot of breakage, for a number of reasons:
- PHYLINK does not create a PHY device for fixed links (MLO_AN_FIXED), which
means that user-facing port (not DSA, not CPU) need to be explicitly handled
with phylink_mac_ops now
- only been able to test this on a limited number of platforms, and not the
ZII devel B/C boards yet
Please test and report!
Florian Fainelli (2):
net: dsa: Plug in PHYLINK support
net: dsa: bcm_sf2: Kick PHYLINK upon link interrupts
drivers/net/dsa/bcm_sf2.c | 29 +++--
include/net/dsa.h | 23 +++-
net/dsa/Kconfig | 1 +
net/dsa/dsa_priv.h | 9 --
net/dsa/slave.c | 294 +++++++++++++++++++++++++++-------------------
5 files changed, 210 insertions(+), 146 deletions(-)
--
2.14.1
^ permalink raw reply
* [RFT/RFC net-next 1/2] net: dsa: Plug in PHYLINK support
From: Florian Fainelli @ 2017-12-15 0:28 UTC (permalink / raw)
To: netdev
Cc: rmk+kernel, sean.wang, john, kernel, privat, Woojung.Huh,
vivien.didelot, andrew, Florian Fainelli
In-Reply-To: <20171215002850.27862-1-f.fainelli@gmail.com>
Add support for PHYLINK within the DSA subsystem in order to support more
complex devices such as pluggable and non-pluggable SFP modules, 10G PHYs, and
traditional PHYs. Using PHYLINK allows us to drop some amount of complexity we
had while dealing with fixed and non-fixed PHYs using Device Tree.
Because PHYLINK separates the Ethernet MAC/port configuration into different
stages, we let switch drivers implement those, and for now, we maintain
functionality by calling dsa_slave_adjust_link() for most of these operations.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 11 +-
include/net/dsa.h | 23 +++-
net/dsa/Kconfig | 1 +
net/dsa/dsa_priv.h | 9 --
net/dsa/slave.c | 294 +++++++++++++++++++++++++++-------------------
5 files changed, 198 insertions(+), 140 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 8ea0cd494ea0..a22a32a724b3 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -16,6 +16,7 @@
#include <linux/platform_device.h>
#include <linux/phy.h>
#include <linux/phy_fixed.h>
+#include <linux/phylink.h>
#include <linux/mii.h>
#include <linux/of.h>
#include <linux/of_irq.h>
@@ -563,7 +564,7 @@ static void bcm_sf2_sw_adjust_link(struct dsa_switch *ds, int port,
}
static void bcm_sf2_sw_fixed_link_update(struct dsa_switch *ds, int port,
- struct fixed_phy_status *status)
+ struct phylink_link_state *status)
{
struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
u32 duplex, pause, offset;
@@ -611,13 +612,11 @@ static void bcm_sf2_sw_fixed_link_update(struct dsa_switch *ds, int port,
core_writel(priv, reg, offset);
if ((pause & (1 << port)) &&
- (pause & (1 << (port + PAUSESTS_TX_PAUSE_SHIFT)))) {
- status->asym_pause = 1;
- status->pause = 1;
- }
+ (pause & (1 << (port + PAUSESTS_TX_PAUSE_SHIFT))))
+ status->pause |= MLO_PAUSE_TXRX_MASK;
if (pause & (1 << port))
- status->pause = 1;
+ status->pause |= MLO_PAUSE_RX;
}
static void bcm_sf2_enable_acb(struct dsa_switch *ds)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 6cb602dd970c..29d4a1b7a825 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -25,6 +25,7 @@
struct tc_action;
struct phy_device;
struct fixed_phy_status;
+struct phylink_link_state;
enum dsa_tag_protocol {
DSA_TAG_PROTO_NONE = 0,
@@ -197,6 +198,7 @@ struct dsa_port {
u8 stp_state;
struct net_device *bridge_dev;
struct devlink_port devlink_port;
+ struct phylink *pl;
/*
* Original copy of the master netdev ethtool_ops
*/
@@ -348,8 +350,25 @@ struct dsa_switch_ops {
*/
void (*adjust_link)(struct dsa_switch *ds, int port,
struct phy_device *phydev);
+ /*
+ * PHYLINK integration
+ */
+ void (*phylink_validate)(struct dsa_switch *ds, int port,
+ unsigned long *supported,
+ struct phylink_link_state *state);
+ int (*phylink_mac_link_state)(struct dsa_switch *ds, int port,
+ struct phylink_link_state *state);
+ void (*phylink_mac_config)(struct dsa_switch *ds, int port,
+ unsigned int mode,
+ const struct phylink_link_state *state);
+ void (*phylink_mac_an_restart)(struct dsa_switch *ds, int port);
+ void (*phylink_mac_link_down)(struct dsa_switch *ds, int port,
+ unsigned int mode);
+ void (*phylink_mac_link_up)(struct dsa_switch *ds, int port,
+ unsigned int mode,
+ struct phy_device *phydev);
void (*fixed_link_update)(struct dsa_switch *ds, int port,
- struct fixed_phy_status *st);
+ struct phylink_link_state *st);
/*
* ethtool hardware statistics.
@@ -568,4 +587,6 @@ static inline int call_dsa_notifiers(unsigned long val, struct net_device *dev,
#define BRCM_TAG_GET_PORT(v) ((v) >> 8)
#define BRCM_TAG_GET_QUEUE(v) ((v) & 0xff)
+void dsa_port_phylink_mac_change(struct dsa_switch *ds, int port, bool up);
+
#endif
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index bbf2c82cf7b2..8a6a8d1cc991 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -10,6 +10,7 @@ config NET_DSA
depends on BRIDGE || BRIDGE=n
select NET_SWITCHDEV
select PHYLIB
+ select PHYLINK
---help---
Say Y if you want to enable support for the hardware switches supported
by the Distributed Switch Architecture.
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index b03665e8fb4e..690ed9877198 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -75,15 +75,6 @@ struct dsa_slave_priv {
/* DSA port data, such as switch, port index, etc. */
struct dsa_port *dp;
- /*
- * The phylib phy_device pointer for the PHY connected
- * to this port.
- */
- phy_interface_t phy_interface;
- int old_link;
- int old_pause;
- int old_duplex;
-
#ifdef CONFIG_NET_POLL_CONTROLLER
struct netpoll *netpoll;
#endif
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 5d6475a6cc5d..6cf51f0a29aa 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -13,6 +13,7 @@
#include <linux/netdevice.h>
#include <linux/phy.h>
#include <linux/phy_fixed.h>
+#include <linux/phylink.h>
#include <linux/of_net.h>
#include <linux/of_mdio.h>
#include <linux/mdio.h>
@@ -97,8 +98,7 @@ static int dsa_slave_open(struct net_device *dev)
if (err)
goto clear_promisc;
- if (dev->phydev)
- phy_start(dev->phydev);
+ phylink_start(dp->pl);
return 0;
@@ -120,8 +120,7 @@ static int dsa_slave_close(struct net_device *dev)
struct net_device *master = dsa_slave_to_master(dev);
struct dsa_port *dp = dsa_slave_to_port(dev);
- if (dev->phydev)
- phy_stop(dev->phydev);
+ phylink_stop(dp->pl);
dsa_port_disable(dp, dev->phydev);
@@ -256,10 +255,9 @@ dsa_slave_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb,
static int dsa_slave_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
{
- if (!dev->phydev)
- return -ENODEV;
+ struct dsa_port *dp = dsa_slave_to_port(dev);
- return phy_mii_ioctl(dev->phydev, ifr, cmd);
+ return phylink_mii_ioctl(dp->pl, ifr, cmd);
}
static int dsa_slave_port_attr_set(struct net_device *dev,
@@ -453,14 +451,11 @@ dsa_slave_get_regs(struct net_device *dev, struct ethtool_regs *regs, void *_p)
ds->ops->get_regs(ds, dp->index, regs, _p);
}
-static u32 dsa_slave_get_link(struct net_device *dev)
+static int dsa_slave_nway_reset(struct net_device *dev)
{
- if (!dev->phydev)
- return -ENODEV;
-
- genphy_update_link(dev->phydev);
+ struct dsa_port *dp = dsa_slave_to_port(dev);
- return dev->phydev->link;
+ return phylink_ethtool_nway_reset(dp->pl);
}
static int dsa_slave_get_eeprom_len(struct net_device *dev)
@@ -501,6 +496,22 @@ static int dsa_slave_set_eeprom(struct net_device *dev,
return -EOPNOTSUPP;
}
+static int dsa_slave_get_module_info(struct net_device *dev,
+ struct ethtool_modinfo *modinfo)
+{
+ struct dsa_port *dp = dsa_slave_to_port(dev);
+
+ return phylink_ethtool_get_module_info(dp->pl, modinfo);
+}
+
+static int dsa_slave_get_module_eeprom(struct net_device *dev,
+ struct ethtool_eeprom *ee, u8 *buf)
+{
+ struct dsa_port *dp = dsa_slave_to_port(dev);
+
+ return phylink_ethtool_get_module_eeprom(dp->pl, ee, buf);
+}
+
static void dsa_slave_get_strings(struct net_device *dev,
uint32_t stringset, uint8_t *data)
{
@@ -573,6 +584,8 @@ static void dsa_slave_get_wol(struct net_device *dev, struct ethtool_wolinfo *w)
struct dsa_port *dp = dsa_slave_to_port(dev);
struct dsa_switch *ds = dp->ds;
+ phylink_ethtool_get_wol(dp->pl, w);
+
if (ds->ops->get_wol)
ds->ops->get_wol(ds, dp->index, w);
}
@@ -583,6 +596,8 @@ static int dsa_slave_set_wol(struct net_device *dev, struct ethtool_wolinfo *w)
struct dsa_switch *ds = dp->ds;
int ret = -EOPNOTSUPP;
+ phylink_ethtool_set_wol(dp->pl, w);
+
if (ds->ops->set_wol)
ret = ds->ops->set_wol(ds, dp->index, w);
@@ -606,13 +621,7 @@ static int dsa_slave_set_eee(struct net_device *dev, struct ethtool_eee *e)
if (ret)
return ret;
- if (e->eee_enabled) {
- ret = phy_init_eee(dev->phydev, 0);
- if (ret)
- return ret;
- }
-
- return phy_ethtool_set_eee(dev->phydev, e);
+ return phylink_ethtool_set_eee(dp->pl, e);
}
static int dsa_slave_get_eee(struct net_device *dev, struct ethtool_eee *e)
@@ -632,7 +641,23 @@ static int dsa_slave_get_eee(struct net_device *dev, struct ethtool_eee *e)
if (ret)
return ret;
- return phy_ethtool_get_eee(dev->phydev, e);
+ return phylink_ethtool_get_eee(dp->pl, e);
+}
+
+static int dsa_slave_get_link_ksettings(struct net_device *dev,
+ struct ethtool_link_ksettings *cmd)
+{
+ struct dsa_port *dp = dsa_slave_to_port(dev);
+
+ return phylink_ethtool_ksettings_get(dp->pl, cmd);
+}
+
+static int dsa_slave_set_link_ksettings(struct net_device *dev,
+ const struct ethtool_link_ksettings *cmd)
+{
+ struct dsa_port *dp = dsa_slave_to_port(dev);
+
+ return phylink_ethtool_ksettings_set(dp->pl, cmd);
}
#ifdef CONFIG_NET_POLL_CONTROLLER
@@ -923,11 +948,13 @@ static const struct ethtool_ops dsa_slave_ethtool_ops = {
.get_drvinfo = dsa_slave_get_drvinfo,
.get_regs_len = dsa_slave_get_regs_len,
.get_regs = dsa_slave_get_regs,
- .nway_reset = phy_ethtool_nway_reset,
- .get_link = dsa_slave_get_link,
+ .nway_reset = dsa_slave_nway_reset,
+ .get_link = ethtool_op_get_link,
.get_eeprom_len = dsa_slave_get_eeprom_len,
.get_eeprom = dsa_slave_get_eeprom,
.set_eeprom = dsa_slave_set_eeprom,
+ .get_module_info = dsa_slave_get_module_info,
+ .get_module_eeprom = dsa_slave_get_module_eeprom,
.get_strings = dsa_slave_get_strings,
.get_ethtool_stats = dsa_slave_get_ethtool_stats,
.get_sset_count = dsa_slave_get_sset_count,
@@ -935,8 +962,8 @@ static const struct ethtool_ops dsa_slave_ethtool_ops = {
.get_wol = dsa_slave_get_wol,
.set_eee = dsa_slave_set_eee,
.get_eee = dsa_slave_get_eee,
- .get_link_ksettings = phy_ethtool_get_link_ksettings,
- .set_link_ksettings = phy_ethtool_set_link_ksettings,
+ .get_link_ksettings = dsa_slave_get_link_ksettings,
+ .set_link_ksettings = dsa_slave_set_link_ksettings,
.get_rxnfc = dsa_slave_get_rxnfc,
.set_rxnfc = dsa_slave_set_rxnfc,
};
@@ -994,56 +1021,118 @@ static struct device_type dsa_type = {
.name = "dsa",
};
-static void dsa_slave_adjust_link(struct net_device *dev)
+static void dsa_slave_phylink_validate(struct net_device *dev,
+ unsigned long *supported,
+ struct phylink_link_state *state)
{
struct dsa_port *dp = dsa_slave_to_port(dev);
- struct dsa_slave_priv *p = netdev_priv(dev);
struct dsa_switch *ds = dp->ds;
- unsigned int status_changed = 0;
- if (p->old_link != dev->phydev->link) {
- status_changed = 1;
- p->old_link = dev->phydev->link;
- }
+ if (!ds->ops->phylink_validate)
+ return;
- if (p->old_duplex != dev->phydev->duplex) {
- status_changed = 1;
- p->old_duplex = dev->phydev->duplex;
- }
+ ds->ops->phylink_validate(ds, dp->index, supported, state);
+}
- if (p->old_pause != dev->phydev->pause) {
- status_changed = 1;
- p->old_pause = dev->phydev->pause;
- }
+static int dsa_slave_phylink_mac_link_state(struct net_device *dev,
+ struct phylink_link_state *state)
+{
+ struct dsa_port *dp = dsa_slave_to_port(dev);
+ struct dsa_switch *ds = dp->ds;
+
+ /* Only called for SGMII and 802.3z */
+ if (!ds->ops->phylink_mac_link_state)
+ return -EOPNOTSUPP;
+
+ return ds->ops->phylink_mac_link_state(ds, dp->index, state);
+}
+
+static void dsa_slave_phylink_mac_config(struct net_device *dev,
+ unsigned int mode,
+ const struct phylink_link_state *state)
+{
+ struct dsa_port *dp = dsa_slave_to_port(dev);
+ struct dsa_switch *ds = dp->ds;
+
+ if (!ds->ops->phylink_mac_config)
+ return;
+
+ ds->ops->phylink_mac_config(ds, dp->index, mode, state);
+}
+
+static void dsa_slave_phylink_mac_an_restart(struct net_device *dev)
+{
+ struct dsa_port *dp = dsa_slave_to_port(dev);
+ struct dsa_switch *ds = dp->ds;
- if (ds->ops->adjust_link && status_changed)
- ds->ops->adjust_link(ds, dp->index, dev->phydev);
+ if (!ds->ops->phylink_mac_an_restart)
+ return;
- if (status_changed)
- phy_print_status(dev->phydev);
+ ds->ops->phylink_mac_an_restart(ds, dp->index);
}
-static int dsa_slave_fixed_link_update(struct net_device *dev,
- struct fixed_phy_status *status)
+static void dsa_slave_phylink_mac_link_down(struct net_device *dev,
+ unsigned int mode)
{
- struct dsa_switch *ds;
- struct dsa_port *dp;
+ struct dsa_port *dp = dsa_slave_to_port(dev);
+ struct dsa_switch *ds = dp->ds;
- if (dev) {
- dp = dsa_slave_to_port(dev);
- ds = dp->ds;
- if (ds->ops->fixed_link_update)
- ds->ops->fixed_link_update(ds, dp->index, status);
+ if (!ds->ops->phylink_mac_link_down) {
+ if (ds->ops->adjust_link && dev->phydev)
+ ds->ops->adjust_link(ds, dp->index, dev->phydev);
+ return;
}
- return 0;
+ ds->ops->phylink_mac_link_down(ds, dp->index, mode);
+}
+
+static void dsa_slave_phylink_mac_link_up(struct net_device *dev,
+ unsigned int mode,
+ struct phy_device *phydev)
+{
+ struct dsa_port *dp = dsa_slave_to_port(dev);
+ struct dsa_switch *ds = dp->ds;
+
+ if (!ds->ops->phylink_mac_link_up) {
+ if (ds->ops->adjust_link && dev->phydev)
+ ds->ops->adjust_link(ds, dp->index, dev->phydev);
+ return;
+ }
+
+ ds->ops->phylink_mac_link_up(ds, dp->index, mode, phydev);
+}
+
+static const struct phylink_mac_ops dsa_slave_phylink_mac_ops = {
+ .validate = dsa_slave_phylink_validate,
+ .mac_link_state = dsa_slave_phylink_mac_link_state,
+ .mac_config = dsa_slave_phylink_mac_config,
+ .mac_an_restart = dsa_slave_phylink_mac_an_restart,
+ .mac_link_down = dsa_slave_phylink_mac_link_down,
+ .mac_link_up = dsa_slave_phylink_mac_link_up,
+};
+
+void dsa_port_phylink_mac_change(struct dsa_switch *ds, int port, bool up)
+{
+ const struct dsa_port *dp = dsa_to_port(ds, port);
+
+ phylink_mac_change(dp->pl, up);
+}
+EXPORT_SYMBOL_GPL(dsa_port_phylink_mac_change);
+
+static void dsa_slave_phylink_fixed_state(struct net_device *dev,
+ struct phylink_link_state *state)
+{
+ struct dsa_port *dp = dsa_slave_to_port(dev);
+ struct dsa_switch *ds = dp->ds;
+
+ if (ds->ops->fixed_link_update)
+ ds->ops->fixed_link_update(ds, dp->index, state);
}
/* slave device setup *******************************************************/
static int dsa_slave_phy_connect(struct net_device *slave_dev, int addr)
{
struct dsa_port *dp = dsa_slave_to_port(slave_dev);
- struct dsa_slave_priv *p = netdev_priv(slave_dev);
struct dsa_switch *ds = dp->ds;
slave_dev->phydev = mdiobus_get_phy(ds->slave_mii_bus, addr);
@@ -1052,75 +1141,49 @@ static int dsa_slave_phy_connect(struct net_device *slave_dev, int addr)
return -ENODEV;
}
- /* Use already configured phy mode */
- if (p->phy_interface == PHY_INTERFACE_MODE_NA)
- p->phy_interface = slave_dev->phydev->interface;
-
- return phy_connect_direct(slave_dev, slave_dev->phydev,
- dsa_slave_adjust_link, p->phy_interface);
+ return phylink_connect_phy(dp->pl, slave_dev->phydev);
}
static int dsa_slave_phy_setup(struct net_device *slave_dev)
{
struct dsa_port *dp = dsa_slave_to_port(slave_dev);
- struct dsa_slave_priv *p = netdev_priv(slave_dev);
struct device_node *port_dn = dp->dn;
struct dsa_switch *ds = dp->ds;
- struct device_node *phy_dn;
- bool phy_is_fixed = false;
u32 phy_flags = 0;
int mode, ret;
mode = of_get_phy_mode(port_dn);
if (mode < 0)
mode = PHY_INTERFACE_MODE_NA;
- p->phy_interface = mode;
- phy_dn = of_parse_phandle(port_dn, "phy-handle", 0);
- if (!phy_dn && of_phy_is_fixed_link(port_dn)) {
- /* In the case of a fixed PHY, the DT node associated
- * to the fixed PHY is the Port DT node
- */
- ret = of_phy_register_fixed_link(port_dn);
- if (ret) {
- netdev_err(slave_dev, "failed to register fixed PHY: %d\n", ret);
- return ret;
- }
- phy_is_fixed = true;
- phy_dn = of_node_get(port_dn);
+ dp->pl = phylink_create(slave_dev, of_fwnode_handle(port_dn), mode,
+ &dsa_slave_phylink_mac_ops);
+ if (IS_ERR(dp->pl)) {
+ netdev_err(slave_dev,
+ "error creating PHYLINK: %ld\n", PTR_ERR(dp->pl));
+ return PTR_ERR(dp->pl);
}
+ phylink_fixed_state_cb(dp->pl, dsa_slave_phylink_fixed_state);
+
if (ds->ops->get_phy_flags)
phy_flags = ds->ops->get_phy_flags(ds, dp->index);
- if (phy_dn) {
- slave_dev->phydev = of_phy_connect(slave_dev, phy_dn,
- dsa_slave_adjust_link,
- phy_flags,
- p->phy_interface);
- of_node_put(phy_dn);
- }
-
- if (slave_dev->phydev && phy_is_fixed)
- fixed_phy_set_link_update(slave_dev->phydev,
- dsa_slave_fixed_link_update);
-
- /* We could not connect to a designated PHY, so use the switch internal
- * MDIO bus instead
- */
- if (!slave_dev->phydev) {
+ ret = phylink_of_phy_connect(dp->pl, port_dn, phy_flags);
+ if (ret == -ENODEV) {
+ /* We could not connect to a designated PHY or SFP, so use the
+ * switch internal MDIO bus instead
+ */
ret = dsa_slave_phy_connect(slave_dev, dp->index);
if (ret) {
- netdev_err(slave_dev, "failed to connect to port %d: %d\n",
+ netdev_err(slave_dev,
+ "failed to connect to port %d: %d\n",
dp->index, ret);
- if (phy_is_fixed)
- of_phy_deregister_fixed_link(port_dn);
+ phylink_destroy(dp->pl);
return ret;
}
}
- phy_attached_info(slave_dev->phydev);
-
return 0;
}
@@ -1135,29 +1198,22 @@ static void dsa_slave_set_lockdep_class_one(struct net_device *dev,
int dsa_slave_suspend(struct net_device *slave_dev)
{
- struct dsa_slave_priv *p = netdev_priv(slave_dev);
+ struct dsa_port *dp = dsa_slave_to_port(slave_dev);
netif_device_detach(slave_dev);
- if (slave_dev->phydev) {
- phy_stop(slave_dev->phydev);
- p->old_pause = -1;
- p->old_link = -1;
- p->old_duplex = -1;
- phy_suspend(slave_dev->phydev);
- }
+ phylink_stop(dp->pl);
return 0;
}
int dsa_slave_resume(struct net_device *slave_dev)
{
+ struct dsa_port *dp = dsa_slave_to_port(slave_dev);
+
netif_device_attach(slave_dev);
- if (slave_dev->phydev) {
- phy_resume(slave_dev->phydev);
- phy_start(slave_dev->phydev);
- }
+ phylink_start(dp->pl);
return 0;
}
@@ -1222,11 +1278,6 @@ int dsa_slave_create(struct dsa_port *port)
p->dp = port;
INIT_LIST_HEAD(&p->mall_tc_list);
p->xmit = cpu_dp->tag_ops->xmit;
-
- p->old_pause = -1;
- p->old_link = -1;
- p->old_duplex = -1;
-
port->slave = slave_dev;
netif_carrier_off(slave_dev);
@@ -1249,9 +1300,8 @@ int dsa_slave_create(struct dsa_port *port)
return 0;
out_phy:
- phy_disconnect(slave_dev->phydev);
- if (of_phy_is_fixed_link(port->dn))
- of_phy_deregister_fixed_link(port->dn);
+ phylink_disconnect_phy(p->dp->pl);
+ phylink_destroy(p->dp->pl);
out_free:
free_percpu(p->stats64);
free_netdev(slave_dev);
@@ -1263,15 +1313,11 @@ void dsa_slave_destroy(struct net_device *slave_dev)
{
struct dsa_port *dp = dsa_slave_to_port(slave_dev);
struct dsa_slave_priv *p = netdev_priv(slave_dev);
- struct device_node *port_dn = dp->dn;
netif_carrier_off(slave_dev);
- if (slave_dev->phydev) {
- phy_disconnect(slave_dev->phydev);
+ phylink_disconnect_phy(dp->pl);
+ phylink_destroy(dp->pl);
- if (of_phy_is_fixed_link(port_dn))
- of_phy_deregister_fixed_link(port_dn);
- }
dsa_slave_notify(slave_dev, DSA_PORT_UNREGISTER);
unregister_netdev(slave_dev);
free_percpu(p->stats64);
--
2.14.1
^ permalink raw reply related
* [RFT/RFC net-next 2/2] net: dsa: bcm_sf2: Kick PHYLINK upon link interrupts
From: Florian Fainelli @ 2017-12-15 0:28 UTC (permalink / raw)
To: netdev
Cc: rmk+kernel, sean.wang, john, kernel, privat, Woojung.Huh,
vivien.didelot, andrew, Florian Fainelli
In-Reply-To: <20171215002850.27862-1-f.fainelli@gmail.com>
In order to signal MoCA port link interrupts the same way we used to do
(through polling a fixed PHY and having an fixed_link_update callback
run), we just need to call phylink_mac_change() when that happens, and
have our custom fixed_link_update callback run to obtain the link state.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index a22a32a724b3..36e1cda0e0b2 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -307,7 +307,8 @@ static int bcm_sf2_sw_mdio_write(struct mii_bus *bus, int addr, int regnum,
static irqreturn_t bcm_sf2_switch_0_isr(int irq, void *dev_id)
{
- struct bcm_sf2_priv *priv = dev_id;
+ struct dsa_switch *ds = dev_id;
+ struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
priv->irq0_stat = intrl2_0_readl(priv, INTRL2_CPU_STATUS) &
~priv->irq0_mask;
@@ -318,16 +319,21 @@ static irqreturn_t bcm_sf2_switch_0_isr(int irq, void *dev_id)
static irqreturn_t bcm_sf2_switch_1_isr(int irq, void *dev_id)
{
- struct bcm_sf2_priv *priv = dev_id;
+ struct dsa_switch *ds = dev_id;
+ struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
priv->irq1_stat = intrl2_1_readl(priv, INTRL2_CPU_STATUS) &
~priv->irq1_mask;
intrl2_1_writel(priv, priv->irq1_stat, INTRL2_CPU_CLEAR);
- if (priv->irq1_stat & P_LINK_UP_IRQ(P7_IRQ_OFF))
+ if (priv->irq1_stat & P_LINK_UP_IRQ(P7_IRQ_OFF)) {
priv->port_sts[7].link = 1;
- if (priv->irq1_stat & P_LINK_DOWN_IRQ(P7_IRQ_OFF))
+ dsa_port_phylink_mac_change(ds, 7, true);
+ }
+ if (priv->irq1_stat & P_LINK_DOWN_IRQ(P7_IRQ_OFF)) {
priv->port_sts[7].link = 0;
+ dsa_port_phylink_mac_change(ds, 7, false);
+ }
return IRQ_HANDLED;
}
@@ -1060,14 +1066,14 @@ static int bcm_sf2_sw_probe(struct platform_device *pdev)
bcm_sf2_intr_disable(priv);
ret = devm_request_irq(&pdev->dev, priv->irq0, bcm_sf2_switch_0_isr, 0,
- "switch_0", priv);
+ "switch_0", ds);
if (ret < 0) {
pr_err("failed to request switch_0 IRQ\n");
goto out_mdio;
}
ret = devm_request_irq(&pdev->dev, priv->irq1, bcm_sf2_switch_1_isr, 0,
- "switch_1", priv);
+ "switch_1", ds);
if (ret < 0) {
pr_err("failed to request switch_1 IRQ\n");
goto out_mdio;
--
2.14.1
^ permalink raw reply related
* Re: [PATCH 1/2] ip_gre: fix potential memory leak in erspan_rcv
From: 严海双 @ 2017-12-15 1:16 UTC (permalink / raw)
To: William Tu
Cc: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
linux-kernel, Linux Kernel Network Developers
In-Reply-To: <CALDO+SZV01yLnStC9uVw0a82T2ACFSQF-zBi2z6f5Sjnhf0fGA@mail.gmail.com>
> On 2017年12月15日, at 上午2:47, William Tu <u9012063@gmail.com> wrote:
>
> On Thu, Dec 14, 2017 at 7:15 AM, Haishuang Yan
> <yanhaishuang@cmss.chinamobile.com> wrote:
>> If md is NULL, tun_dst must be freed, otherwise it will cause memory
>> leak.
>>
>> Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
>> Cc: William Tu <u9012063@gmail.com>
>> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
>> ---
>> net/ipv4/ip_gre.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
>> index d828821..9253d6f 100644
>> --- a/net/ipv4/ip_gre.c
>> +++ b/net/ipv4/ip_gre.c
>> @@ -304,8 +304,10 @@ static int erspan_rcv(struct sk_buff *skb, struct tnl_ptk_info *tpi,
>> return PACKET_REJECT;
>>
>> md = ip_tunnel_info_opts(&tun_dst->u.tun_info);
>> - if (!md)
>> + if (!md) {
>> + dst_release((struct dst_entry *)tun_dst);
>> return PACKET_REJECT;
>> + }
> I'm not sure about this. Maybe we don't even need to check "if (!md)"
> since ip_tun_rx_dst does the memory allocation.
> William
>
Hi, William
I think we need to check “if (!md)”, if md is okay, ip_tunnel_rcv will be responsible to free
tun_dst:
448 drop:
449 if (tun_dst)
450 dst_release((struct dst_entry *)tun_dst);
Thanks.
^ permalink raw reply
* [PATCH bpf] xdp: linearize skb in netif_receive_generic_xdp()
From: Song Liu @ 2017-12-15 1:17 UTC (permalink / raw)
To: netdev; +Cc: kernel-team, Song Liu, Daniel Borkmann, Alexei Starovoitov
In netif_receive_generic_xdp(), it is necessary to linearize all
nonlinear skb. However, in current implementation, skb with
troom <= 0 are not linearized. This patch fixes this by calling
skb_linearize() for all nonlinear skb.
Fixes: de8f3a83b0a0 ("bpf: add meta pointer for direct access")
Signed-off-by: Song Liu <songliubraving@fb.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@kernel.org>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index f47e96b..01ee854 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3904,7 +3904,7 @@ static u32 netif_receive_generic_xdp(struct sk_buff *skb,
hroom > 0 ? ALIGN(hroom, NET_SKB_PAD) : 0,
troom > 0 ? troom + 128 : 0, GFP_ATOMIC))
goto do_drop;
- if (troom > 0 && __skb_linearize(skb))
+ if (skb_linearize(skb))
goto do_drop;
}
--
2.9.5
^ permalink raw reply related
* Re: [PATCH v2] ARM64: dts: meson-axg: add ethernet mac controller
From: Yixun Lan @ 2017-12-15 1:46 UTC (permalink / raw)
To: Jerome Brunet, devicetree-u79uwXL29TY76Z2rM5mHXA, Kevin Hilman
Cc: yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ, Neil Armstrong,
Giuseppe Cavallaro, Alexandre Torgue, Carlo Caione,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1513269947.2261.9.camel-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Jerome:
On 12/15/17 00:45, Jerome Brunet wrote:
> On Thu, 2017-12-14 at 11:02 +0800, Yixun Lan wrote:
>> ---
>> Changes in v2 since [1]:
>> - rebase to kevin's v4.16/dt64 branch
>> - add Neil's Reviewed-by
>> - move clock info to board.dts instead of in soc.dtsi
>
> You got this comment regarding the pwm clock setup. the setup of the pwm clocks
> depends on the use case, so should defined depending on the requirement on the
> board
>
Yes, I thought it was a convention to put the clock into board.dts ..
I think it's more clear if you could have a three level hierarchy:
arch.dtsi. soc.dtsi, board.dts
most of clock and pinctrl could go to soc.dtsi
> This is not the case for the ethmac, the clock setup will be same for every
> board, unless I missed something. the clock bindings should be defined in
> meson-axg.dtsi, I think
>
yes, clock should be same
I will send another series to fix this
also will fold the DT separation (for soc.dtsi vs board.dts)
>> - drop "meson-axg-dwmac" compatible string, since we didn't use this
>> we could re-add it later when we really need.
>> - note: to make ethernet work properly,it depend on clock & pinctrl[2],
>> to compile the DTS, the patch [3] is required.
>> the code part will be taken via clock & pinctrl subsystem tree.
>
> .
>
--
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
* [PATCH net-next] net: phy: broadcom: Add entry for 5395 switch PHYs
From: Florian Fainelli @ 2017-12-15 1:48 UTC (permalink / raw)
To: netdev; +Cc: andrew, cphealy, Florian Fainelli
Add an entry for the builtin PHYs present in the Broadcom BCM5395 switch. This
allows us to retrieve the PHY statistics among other things.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/broadcom.c | 42 ++++++++++++++++++++++++++++++++++++++++++
include/linux/brcmphy.h | 1 +
2 files changed, 43 insertions(+)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index a8f69c5777bc..3bb6b66dc7bf 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -540,6 +540,37 @@ static int brcm_fet_config_intr(struct phy_device *phydev)
return err;
}
+struct bcm53xx_phy_priv {
+ u64 *stats;
+};
+
+static int bcm53xx_phy_probe(struct phy_device *phydev)
+{
+ struct bcm53xx_phy_priv *priv;
+
+ priv = devm_kzalloc(&phydev->mdio.dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ phydev->priv = priv;
+
+ priv->stats = devm_kcalloc(&phydev->mdio.dev,
+ bcm_phy_get_sset_count(phydev), sizeof(u64),
+ GFP_KERNEL);
+ if (!priv->stats)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static void bcm53xx_phy_get_stats(struct phy_device *phydev,
+ struct ethtool_stats *stats, u64 *data)
+{
+ struct bcm53xx_phy_priv *priv = phydev->priv;
+
+ bcm_phy_get_stats(phydev, priv->stats, stats, data);
+}
+
static struct phy_driver broadcom_drivers[] = {
{
.phy_id = PHY_ID_BCM5411,
@@ -679,6 +710,16 @@ static struct phy_driver broadcom_drivers[] = {
.config_init = brcm_fet_config_init,
.ack_interrupt = brcm_fet_ack_interrupt,
.config_intr = brcm_fet_config_intr,
+}, {
+ .phy_id = PHY_ID_BCM5395,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Broadcom BCM5395",
+ .flags = PHY_IS_INTERNAL,
+ .features = PHY_GBIT_FEATURES,
+ .get_sset_count = bcm_phy_get_sset_count,
+ .get_strings = bcm_phy_get_strings,
+ .get_stats = bcm53xx_phy_get_stats,
+ .probe = bcm53xx_phy_probe,
} };
module_phy_driver(broadcom_drivers);
@@ -699,6 +740,7 @@ static struct mdio_device_id __maybe_unused broadcom_tbl[] = {
{ PHY_ID_BCM57780, 0xfffffff0 },
{ PHY_ID_BCMAC131, 0xfffffff0 },
{ PHY_ID_BCM5241, 0xfffffff0 },
+ { PHY_ID_BCM5395, 0xfffffff0 },
{ }
};
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 8ff86b4c1b8a..d3339dd48b1a 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -14,6 +14,7 @@
#define PHY_ID_BCM5241 0x0143bc30
#define PHY_ID_BCMAC131 0x0143bc70
#define PHY_ID_BCM5481 0x0143bca0
+#define PHY_ID_BCM5395 0x0143bcf0
#define PHY_ID_BCM54810 0x03625d00
#define PHY_ID_BCM5482 0x0143bcb0
#define PHY_ID_BCM5411 0x00206070
--
2.7.4
^ permalink raw reply related
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