* Re: No traffic with Marvell switch and latest linux-next
From: Andrew Lunn @ 2019-02-24 17:04 UTC (permalink / raw)
To: Florian Fainelli
Cc: Russell King - ARM Linux admin, Heiner Kallweit,
netdev@vger.kernel.org
In-Reply-To: <7005686d-45cb-a8af-de34-873c9e34a021@gmail.com>
> The added difficulty here and the reason why Andrew went with the
> approach that is used by the code currently is because neither do the
> CPU or DSA ports are backed by a net_device. It is somewhere on my TODO
> to permit the use of PHYLINK without the need of a net_device to cover
> those specific DSA cases unless we just brute force the whole thing and
> allocate a net_device structure but not register that net_device? Yes in
> fact, why don't we do that?
Hi Florian
At the moment, we are using a phydev which is not connected to a
MAC. That is rather odd, but the phylib maintainers mostly know about
this, and keep an eye out for changes which might break any
assumptions. And the phylib API is quite small.
How many assumptions are going to break with a netdev which is not
registered? The API is much bigger, more people hack on it, and it is
going to be much harder to review changes to make sure assumptions are
not changed.
If we are going to do something odd, we should keep the scope as small
as possible.
Andrew
^ permalink raw reply
* Re: [PATCH iproute2-next v2 00/19] Export object IDs to users
From: Leon Romanovsky @ 2019-02-24 17:23 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, RDMA mailing list, Stephen Hemminger, Steve Wise
In-Reply-To: <c5995a79-e0d6-c88d-44d4-52d5477f2662@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 675 bytes --]
On Sun, Feb 24, 2019 at 10:16:37AM -0500, David Ahern wrote:
> On 2/23/19 4:15 AM, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > Changelog:
> > v1->v2:
> > * Fixed commit messages
> > * Added Steve's ROB
> > v0->v1:
> > * Rebased to latest iproute2-next
> > * Added latest rdma_netlink.h and updated commit message to point
> > to kernel SHA commit.
> >
> > This series adds ability to present and query all known to rdmatool
> > object by their respective, unique IDs (e.g. pdn. mrn, cqn e.t.c).
> > All objects which have "parent" object has this information too.
> >
>
> applied to iproute2-next. Thanks, Leon.
Thanks, a lot.
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: No traffic with Marvell switch and latest linux-next
From: Andrew Lunn @ 2019-02-24 17:28 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Heiner Kallweit, Florian Fainelli, netdev@vger.kernel.org
In-Reply-To: <20190224153125.f2n3xfjyjswd7ioa@shell.armlinux.org.uk>
On Sun, Feb 24, 2019 at 03:31:26PM +0000, Russell King - ARM Linux admin wrote:
> On Sun, Feb 24, 2019 at 12:42:35AM +0100, Andrew Lunn wrote:
> > Looking forward, at some point we are going to have to make fixed-link
> > support higher speeds. That probably means we need a swphy-c45 which
> > emulates the standard registers for 2.5G, 5G and 10G. At that point
> > genphy will not work...
>
> Do we _need_ to emulate Clause 45 PHYs?
Hi Russell
One use case would be a mv88e6390X port 9 or 10 connected to a SoC
which can only do 2.5G.
We have defined that DSA drivers should configure CPU and DSA ports to
their maximum speed. So if port 9 or 10 is used, it should be
configured to 10G.
We then need some way to reconfigure the MAC to a slower speed.
We need to do this with ZII boards. We do this with:
port@0 {
reg = <0>;
label = "cpu";
ethernet = <&fec1>;
fixed-link {
speed = <100>;
full-duplex;
};
};
The FEC can only do 100Mbs, but the switch defaults to 1G. So the
fixed link it used to tell the switch MAC to use 100/Full.
In the example of the 6390X, we would want to set the link speed to
2500, which we cannot do at the moment. Either we need fixed-link to
support higher speeds, or we need a different mechanism.
We also have a similar issue on the SoC side. The FEC has no PHY
connected to it. It needs to be told what speed to do:
&fec1 {
phy-mode = "rmii";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_fec1>;
status = "okay";
fixed-link {
speed = <100>;
full-duplex;
};
In the case of a SoC with an interface which can do 2.5G, you need to
tell it to do 2.5G. Ideally we want a mechanism that allows a MAC to
'see' a PHY operating at 2.5G using the standard phylib/phylink API.
In the past this has been achieved with an emulated PHY. But so long
as the phydev/phylink structure has the correct values, it does not
matter how they get those values.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: phy: improve auto-neg emulation in swphy
From: Andrew Lunn @ 2019-02-24 17:56 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Florian Fainelli, David Miller, Russell King - ARM Linux,
netdev@vger.kernel.org
In-Reply-To: <a290442f-fdae-26da-6073-3675bf635af1@gmail.com>
On Sun, Feb 24, 2019 at 05:41:47PM +0100, Heiner Kallweit wrote:
> Auto-neg emulation currently doesn't set bit BMCR_ANENABLE in BMCR,
> add this. Users will ignore speed and duplex settings in BMCR because
> we're emulating auto-neg, therefore we can remove related code.
> See also following discussion [0].
>
> [0] https://marc.info/?t=155041784900002&r=1&w=2
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net] net: phy: fix reading fixed phy status
From: Andrew Lunn @ 2019-02-24 17:57 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <7ab8732d-bcc1-cc49-4bc8-34826e78038b@gmail.com>
On Sun, Feb 24, 2019 at 06:01:18PM +0100, Heiner Kallweit wrote:
> With the switch to phy_resolve_aneg_linkmode() we don't read from the
> chip any longer what is advertised but use phydev->advertising directly.
> For a fixed phy however this bitmap is empty so far, what results in
> no common mode being found. This breaks DSA. Fix this by advertising
> everything that is supported. For a normal phy this done by phy_probe().
>
> Fixes: 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
But i tested on net-next, not net.
Andrew
> ---
> drivers/net/phy/fixed_phy.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
> index b0d1368c3..1acd8bfdb 100644
> --- a/drivers/net/phy/fixed_phy.c
> +++ b/drivers/net/phy/fixed_phy.c
> @@ -22,6 +22,7 @@
> #include <linux/seqlock.h>
> #include <linux/idr.h>
> #include <linux/netdevice.h>
> +#include <linux/linkmode.h>
>
> #include "swphy.h"
>
> @@ -300,6 +301,8 @@ static struct phy_device *__fixed_phy_register(unsigned int irq,
> phy->supported);
> }
>
> + linkmode_copy(phy->advertising, phy->supported);
> +
> ret = phy_device_register(phy);
> if (ret) {
> phy_device_free(phy);
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH v2 bpf-next 2/9] bpf: Add bpf helper bpf_tcp_enter_cwr
From: Eric Dumazet @ 2019-02-24 18:00 UTC (permalink / raw)
To: Martin Lau, Eric Dumazet
Cc: Lawrence Brakmo, netdev, Alexei Starovoitov, Daniel Borkmann,
Kernel Team
In-Reply-To: <20190224030845.imwjbkoaxipuzb75@kafai-mbp.dhcp.thefacebook.com>
On 02/23/2019 07:08 PM, Martin Lau wrote:
> On Sat, Feb 23, 2019 at 05:32:14PM -0800, Eric Dumazet wrote:
>>
>>
>> On 02/22/2019 05:06 PM, brakmo wrote:
>>> From: Martin KaFai Lau <kafai@fb.com>
>>>
>>> This patch adds a new bpf helper BPF_FUNC_tcp_enter_cwr
>>> "int bpf_tcp_enter_cwr(struct bpf_tcp_sock *tp)".
>>> It is added to BPF_PROG_TYPE_CGROUP_SKB which can be attached
>>> to the egress path where the bpf prog is called by
>>> ip_finish_output() or ip6_finish_output(). The verifier
>>> ensures that the parameter must be a tcp_sock.
>>>
>>> This helper makes a tcp_sock enter CWR state. It can be used
>>> by a bpf_prog to manage egress network bandwidth limit per
>>> cgroupv2. A later patch will have a sample program to
>>> show how it can be used to limit bandwidth usage per cgroupv2.
>>>
>>> To ensure it is only called from BPF_CGROUP_INET_EGRESS, the
>>> attr->expected_attach_type must be specified as BPF_CGROUP_INET_EGRESS
>>> during load time if the prog uses this new helper.
>>> The newly added prog->enforce_expected_attach_type bit will also be set
>>> if this new helper is used. This bit is for backward compatibility reason
>>> because currently prog->expected_attach_type has been ignored in
>>> BPF_PROG_TYPE_CGROUP_SKB. During attach time,
>>> prog->expected_attach_type is only enforced if the
>>> prog->enforce_expected_attach_type bit is set.
>>> i.e. prog->expected_attach_type is only enforced if this new helper
>>> is used by the prog.
>>>
>>
>> BTW, it seems to me that BPF_CGROUP_INET_EGRESS can be used while the socket lock is not held.
> Thanks for pointing it out.
>
> ic. I just noticed the comments at ip6_xmit():
> /*
> * xmit an sk_buff (used by TCP, SCTP and DCCP)
> * Note : socket lock is not held for SYNACK packets, but might be modified
> * by calls to skb_set_owner_w() and ipv6_local_error(),
> * which are using proper atomic operations or spinlocks.
> */
> Is there other cases other than SYNACK?
Well, I was referring to various virtual devices, re-entering ip stack.
Since we can have a qdisc on any netdev, there is no way we can guarantee the socket is
locked by the current thread.
Random example :
ipvlan_process_v4_outbound()
...
err = ip_local_out(net, skb->sk, skb);
...
^ permalink raw reply
* Re: [PATCH net] net: phy: fix reading fixed phy status
From: Heiner Kallweit @ 2019-02-24 18:00 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <20190224175710.GL26626@lunn.ch>
On 24.02.2019 18:57, Andrew Lunn wrote:
> On Sun, Feb 24, 2019 at 06:01:18PM +0100, Heiner Kallweit wrote:
>> With the switch to phy_resolve_aneg_linkmode() we don't read from the
>> chip any longer what is advertised but use phydev->advertising directly.
>> For a fixed phy however this bitmap is empty so far, what results in
>> no common mode being found. This breaks DSA. Fix this by advertising
>> everything that is supported. For a normal phy this done by phy_probe().
>>
>> Fixes: 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>
> Tested-by: Andrew Lunn <andrew@lunn.ch>
>
> But i tested on net-next, not net.
>
You're right, it should be net-next. I just had the wrong automatism
fix = net in my mind.
> Andrew
>
>
Heiner
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: Add support for 200Gbps (50Gbps per lane) link mode
From: Michal Kubecek @ 2019-02-24 18:11 UTC (permalink / raw)
To: Tariq Toukan; +Cc: John W. Linville, netdev, Eran Ben Elisha, Aya Levin
In-Reply-To: <1551020901-20257-1-git-send-email-tariqt@mellanox.com>
On Sun, Feb 24, 2019 at 05:08:21PM +0200, Tariq Toukan wrote:
> From: Aya Levin <ayal@mellanox.com>
>
> Introduce 50Gbps per lane link modes and 200Gbps speed, update print
> functions and initialization functions accordingly.
> In addition, update related man page accordingly.
>
> Signed-off-by: Aya Levin <ayal@mellanox.com>
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> ---
> ethtool-copy.h | 19 ++++++++++++++++++-
> ethtool.8.in | 15 +++++++++++++++
> ethtool.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 85 insertions(+), 1 deletion(-)
>
> diff --git a/ethtool-copy.h b/ethtool-copy.h
> index 6bfbb85f9402..de459900b2d3 100644
> --- a/ethtool-copy.h
> +++ b/ethtool-copy.h
> @@ -1455,15 +1455,31 @@ enum ethtool_link_mode_bit_indices {
> ETHTOOL_LINK_MODE_FEC_NONE_BIT = 49,
> ETHTOOL_LINK_MODE_FEC_RS_BIT = 50,
> ETHTOOL_LINK_MODE_FEC_BASER_BIT = 51,
> + ETHTOOL_LINK_MODE_50000baseKR_Full_BIT = 52,
> + ETHTOOL_LINK_MODE_50000baseSR_Full_BIT = 53,
> + ETHTOOL_LINK_MODE_50000baseCR_Full_BIT = 54,
> + ETHTOOL_LINK_MODE_50000baseLR_ER_FR_Full_BIT = 55,
> + ETHTOOL_LINK_MODE_50000baseDR_Full_BIT = 56,
> + ETHTOOL_LINK_MODE_100000baseKR2_Full_BIT = 57,
> + ETHTOOL_LINK_MODE_100000baseSR2_Full_BIT = 58,
> + ETHTOOL_LINK_MODE_100000baseCR2_Full_BIT = 59,
> + ETHTOOL_LINK_MODE_100000baseLR2_ER2_FR2_Full_BIT = 60,
> + ETHTOOL_LINK_MODE_100000baseDR2_Full_BIT = 61,
> + ETHTOOL_LINK_MODE_200000baseKR4_Full_BIT = 62,
> + ETHTOOL_LINK_MODE_200000baseSR4_Full_BIT = 63,
> + ETHTOOL_LINK_MODE_200000baseLR4_ER4_FR4_Full_BIT = 64,
> + ETHTOOL_LINK_MODE_200000baseDR4_Full_BIT = 65,
> + ETHTOOL_LINK_MODE_200000baseCR4_Full_BIT = 66,
>
> /* Last allowed bit for __ETHTOOL_LINK_MODE_LEGACY_MASK is bit
> * 31. Please do NOT define any SUPPORTED_* or ADVERTISED_*
> * macro for bits > 31. The only way to use indices > 31 is to
> * use the new ETHTOOL_GLINKSETTINGS/ETHTOOL_SLINKSETTINGS API.
> */
> + ETHTOOL_LINK_MODE_LAST,
>
> __ETHTOOL_LINK_MODE_LAST
> - = ETHTOOL_LINK_MODE_FEC_BASER_BIT,
> + = ETHTOOL_LINK_MODE_LAST - 1,
> };
The name ETHTOOL_LINK_MODE_LAST is a bit misleading, maybe it should
rather be called ETHTOOL_LINK_MODE_COUNT. Also, there should be
parentheses around the expression to avoid surprises when
__ETHTOOL_LINK_MODE_LAST is used in an expression.
But this change is not in kernel include/uapi/linux/ethtool.h in
mainline, net or net-next. As ethtool-copy.h is supposed to be a copy of
sanitized kernel uapi header, you should make the change there first and
then sync the header to ethtool.
Michal Kubecek
^ permalink raw reply
* Re: [GIT] Networking
From: pr-tracker-bot @ 2019-02-24 18:15 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20190223.185710.866316846403242352.davem@davemloft.net>
The pull request you sent on Sat, 23 Feb 2019 18:57:10 -0800 (PST):
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git refs/heads/master
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c4eb1e1852df60d61e04a6b580a0490460c9e31b
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: Add support for 200Gbps (50Gbps per lane) link mode
From: Michal Kubecek @ 2019-02-24 18:40 UTC (permalink / raw)
To: Andrew Lunn
Cc: Tariq Toukan, John W. Linville, netdev, Eran Ben Elisha,
Aya Levin
In-Reply-To: <20190224164751.GG26626@lunn.ch>
On Sun, Feb 24, 2019 at 05:47:51PM +0100, Andrew Lunn wrote:
> On Sun, Feb 24, 2019 at 05:08:21PM +0200, Tariq Toukan wrote:
> > From: Aya Levin <ayal@mellanox.com>
> > index 5a26cff5fb33..64ce0711ad5f 100644
> > --- a/ethtool.8.in
> > +++ b/ethtool.8.in
> > @@ -650,6 +650,11 @@ lB l lB.
> > 0x400000000 50000baseCR2 Full
> > 0x800000000 50000baseKR2 Full
> > 0x10000000000 50000baseSR2 Full
> > +0x10000000000000 50000baseKR Full
> > +0x20000000000000 50000baseSR Full
> > +0x40000000000000 50000baseCR Full
> > +0x80000000000000 50000baseLR_ER_FR Full
> > +0x100000000000000 50000baseDR Full
> > 0x8000000 56000baseKR4 Full
> > 0x10000000 56000baseCR4 Full
> > 0x20000000 56000baseSR4 Full
> > @@ -658,6 +663,16 @@ lB l lB.
> > 0x2000000000 100000baseSR4 Full
> > 0x4000000000 100000baseCR4 Full
> > 0x8000000000 100000baseLR4_ER4 Full
> > +0x200000000000000 100000baseKR2 Full
> > +0x400000000000000 100000baseSR2 Full
> > +0x800000000000000 100000baseCR2 Full
> > +0x1000000000000000 100000baseLR2_ER2_FR2 Full
> > +0x2000000000000000 100000baseDR2 Full
> > +0x4000000000000000 200000baseKR4 Full
> > +0x8000000000000000 200000baseSR4 Full
> > +0x10000000000000000 200000baseLR4_ER4_FR4 Full
> > +0x20000000000000000 200000baseDR4 Full
> > +0x40000000000000000 200000baseCR4 Full
>
> This is getting less friendly all the time, and it was never very
> friendly to start with. We have the strings which represent these link
> modes in the table used for dumping caps. How about allowing the user
> to list a comma separate list of modes.
>
> ethtool -s lan42 advertise 100000baseKR2/Full,100000baseSR2/Full,100000baseCR2/Full
In my preliminary netlink patchset, I'm adding support for e.g.
ethtool -s eth0 advertise 100baseT/Half off 1000baseT/Full on
I'm not sure what would be more useful, if switching individual modes or
listing the whole set. After all, we can also support both. But I fully
agree that the numeric bitmaps are already too inconvenient.
> > + adv_bit = ETHTOOL_LINK_MODE_200000baseKR4_Full_BIT &
> > + ETHTOOL_LINK_MODE_200000baseSR4_Full_BIT &
> > + ETHTOOL_LINK_MODE_200000baseLR4_ER4_FR4_Full_BIT &
> > + ETHTOOL_LINK_MODE_200000baseDR4_Full_BIT &
> > + ETHTOOL_LINK_MODE_200000baseCR4_Full_BIT;
>
> Maybe i'm wrong, but this looks odd.
>
> enum ethtool_link_mode_bit_indices {
> ETHTOOL_LINK_MODE_10baseT_Half_BIT = 0,
> ETHTOOL_LINK_MODE_10baseT_Full_BIT = 1,
> ETHTOOL_LINK_MODE_100baseT_Half_BIT = 2,
> ETHTOOL_LINK_MODE_100baseT_Full_BIT = 3,
> ETHTOOL_LINK_MODE_1000baseT_Half_BIT = 4,
> ETHTOOL_LINK_MODE_1000baseT_Full_BIT = 5,
>
> These are numbers, not bitmasks, so & them together does not look
> correct.
Yes, this is wrong. Even if bit masks were used, the operator should be
"|" but here adv_bit is interpreted as an index, not mask. It's obvious
this part of the code was designed when speed and duplex identified the
mode uniquely which is no longer the case. (Which is probably also why
there are no branches for speeds over 10G.)
And there is another problem:
+ else if (speed_wanted == SPEED_20000 &&
+ duplex_wanted == DUPLEX_FULL)
+ adv_bit = ETHTOOL_LINK_MODE_200000baseKR4_Full_BIT &
+ ETHTOOL_LINK_MODE_200000baseSR4_Full_BIT &
+ ETHTOOL_LINK_MODE_200000baseLR4_ER4_FR4_Full_BIT &
+ ETHTOOL_LINK_MODE_200000baseDR4_Full_BIT &
+ ETHTOOL_LINK_MODE_200000baseCR4_Full_BIT;
The test is for SPEED_20000 but then 200G modes are added.
Michal
^ permalink raw reply
* Re: [PATCH] Documentation: networking: switchdev: Update port parent ID section
From: David Miller @ 2019-02-24 19:26 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, idosch, jiri
In-Reply-To: <c796b361-d19a-1b73-ea17-2cbedb10f241@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Sun, 24 Feb 2019 08:46:59 -0800
> Looks like you applied this to the "net" tree, and I missed prefixing
> the patch to indicate this was targeted at the "net-next" tree. Are you
> planning a merge from "net" to "net-next" anytime soon?
Yes, I am working on that right now.
^ permalink raw reply
* Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault
From: Andy Lutomirski @ 2019-02-24 19:35 UTC (permalink / raw)
To: Nadav Amit
Cc: Andy Lutomirski, Jann Horn, Alexei Starovoitov, Steven Rostedt,
Linus Torvalds, Masami Hiramatsu, Linux List Kernel Mailing,
Ingo Molnar, Andrew Morton, Changbin Du, Kees Cook,
Daniel Borkmann, Network Development, bpf@vger.kernel.org,
Rick Edgecombe, Dave Hansen, Peter Zijlstra (Intel), Igor Stoppa
In-Reply-To: <7E4E5362-4C13-40FA-B5A8-F88D3E60827F@vmware.com>
On Sat, Feb 23, 2019 at 12:30 AM Nadav Amit <namit@vmware.com> wrote:
>
> > On Feb 22, 2019, at 3:59 PM, Andy Lutomirski <luto@kernel.org> wrote:
> >
> > On Fri, Feb 22, 2019 at 3:02 PM Jann Horn <jannh@google.com> wrote:
> >> On Fri, Feb 22, 2019 at 11:39 PM Nadav Amit <namit@vmware.com> wrote:
> >>>> On Feb 22, 2019, at 2:21 PM, Nadav Amit <namit@vmware.com> wrote:
> >>>>
> >>>>> On Feb 22, 2019, at 2:17 PM, Jann Horn <jannh@google.com> wrote:
> >>>>>
> >>>>> On Fri, Feb 22, 2019 at 11:08 PM Nadav Amit <namit@vmware.com> wrote:
> >>>>>>> On Feb 22, 2019, at 1:43 PM, Jann Horn <jannh@google.com> wrote:
> >>>>>>>
> >>>>>>> (adding some people from the text_poke series to the thread, removing stable@)
> >>>>>>>
> >>>>>>> On Fri, Feb 22, 2019 at 8:55 PM Andy Lutomirski <luto@amacapital.net> wrote:
> >>>>>>>>> On Feb 22, 2019, at 11:34 AM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> >>>>>>>>>> On Fri, Feb 22, 2019 at 02:30:26PM -0500, Steven Rostedt wrote:
> >>>>>>>>>> On Fri, 22 Feb 2019 11:27:05 -0800
> >>>>>>>>>> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>>>> On Fri, Feb 22, 2019 at 09:43:14AM -0800, Linus Torvalds wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Then we should still probably fix up "__probe_kernel_read()" to not
> >>>>>>>>>>>> allow user accesses. The easiest way to do that is actually likely to
> >>>>>>>>>>>> use the "unsafe_get_user()" functions *without* doing a
> >>>>>>>>>>>> uaccess_begin(), which will mean that modern CPU's will simply fault
> >>>>>>>>>>>> on a kernel access to user space.
> >>>>>>>>>>>
> >>>>>>>>>>> On bpf side the bpf_probe_read() helper just calls probe_kernel_read()
> >>>>>>>>>>> and users pass both user and kernel addresses into it and expect
> >>>>>>>>>>> that the helper will actually try to read from that address.
> >>>>>>>>>>>
> >>>>>>>>>>> If __probe_kernel_read will suddenly start failing on all user addresses
> >>>>>>>>>>> it will break the expectations.
> >>>>>>>>>>> How do we solve it in bpf_probe_read?
> >>>>>>>>>>> Call probe_kernel_read and if that fails call unsafe_get_user byte-by-byte
> >>>>>>>>>>> in the loop?
> >>>>>>>>>>> That's doable, but people already complain that bpf_probe_read() is slow
> >>>>>>>>>>> and shows up in their perf report.
> >>>>>>>>>>
> >>>>>>>>>> We're changing kprobes to add a specific flag to say that we want to
> >>>>>>>>>> differentiate between kernel or user reads. Can this be done with
> >>>>>>>>>> bpf_probe_read()? If it's showing up in perf report, I doubt a single
> >>>>>>>>>
> >>>>>>>>> so you're saying you will break existing kprobe scripts?
> >>>>>>>>> I don't think it's a good idea.
> >>>>>>>>> It's not acceptable to break bpf_probe_read uapi.
> >>>>>>>>
> >>>>>>>> If so, the uapi is wrong: a long-sized number does not reliably identify an address if you don’t separately know whether it’s a user or kernel address. s390x and 4G:4G x86_32 are the notable exceptions. I have lobbied for RISC-V and future x86_64 to join the crowd. I don’t know whether I’ll win this fight, but the uapi will probably have to change for at least s390x.
> >>>>>>>>
> >>>>>>>> What to do about existing scripts is a different question.
> >>>>>>>
> >>>>>>> This lack of logical separation between user and kernel addresses
> >>>>>>> might interact interestingly with the text_poke series, specifically
> >>>>>>> "[PATCH v3 05/20] x86/alternative: Initialize temporary mm for
> >>>>>>> patching" (https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2F20190221234451.17632-6-rick.p.edgecombe%40intel.com%2F&data=02%7C01%7Cnamit%40vmware.com%7Cbab53e52cc5c4ac4419008d69921d1f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636864767879731941&sdata=2tqD7udTCfNbcNLcj5SFpZt8WwK5NwtgaWMKm1Ye1EE%3D&reserved=0)
> >>>>>>> and "[PATCH v3 06/20] x86/alternative: Use temporary mm for text
> >>>>>>> poking" (https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2F20190221234451.17632-7-rick.p.edgecombe%40intel.com%2F&data=02%7C01%7Cnamit%40vmware.com%7Cbab53e52cc5c4ac4419008d69921d1f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636864767879731941&sdata=7%2BLShgLKnra6xzSkxdJrCclCacfdE5IdczwScW83nuE%3D&reserved=0),
> >>>>>>> right? If someone manages to get a tracing BPF program to trigger in a
> >>>>>>> task that has switched to the patching mm, could they use
> >>>>>>> bpf_probe_write_user() - which uses probe_kernel_write() after
> >>>>>>> checking that KERNEL_DS isn't active and that access_ok() passes - to
> >>>>>>> overwrite kernel text that is mapped writable in the patching mm?
> >>>>>>
> >>>>>> Yes, this is a good point. I guess text_poke() should be defined with
> >>>>>> “__kprobes” and open-code memcpy.
> >>>>>>
> >>>>>> Does it sound reasonable?
> >>>>>
> >>>>> Doesn't __text_poke() as implemented in the proposed patch use a
> >>>>> couple other kernel functions, too? Like switch_mm_irqs_off() and
> >>>>> pte_clear() (which can be a call into a separate function on paravirt
> >>>>> kernels)?
> >>>>
> >>>> I will move the pte_clear() to be done after the poking mm was unloaded.
> >>>> Give me a few minutes to send a sketch of what I think should be done.
> >>>
> >>> Err.. You are right, I don’t see an easy way of preventing a kprobe from
> >>> being set on switch_mm_irqs_off(), and open-coding this monster is too ugly.
> >>>
> >>> The reasonable solution seems to me as taking all the relevant pieces of
> >>> code (and data) that might be used during text-poking and encapsulating them, so they
> >>> will be set in a memory area which cannot be kprobe'd. This can also be
> >>> useful to write-protect data structures of code that calls text_poke(),
> >>> e.g., static-keys. It can also protect data on that stack that is used
> >>> during text_poke() from being overwritten from another core.
> >>>
> >>> This solution is somewhat similar to Igor Stoppa’s idea of using “enclaves”
> >>> when doing write-rarely operations.
> >>>
> >>> Right now, I think that text_poke() will keep being susceptible to such
> >>> an attack, unless you have a better suggestion.
> >>
> >> A relatively simple approach might be to teach BPF not to run kprobe
> >> programs and such in contexts where current->mm isn't the active mm?
> >> Maybe using nmi_uaccess_okay(), or something like that? It looks like
> >> perf_callchain_user() also already uses that. Except that a lot of
> >> this code is x86-specific...
> >
> > This sounds like exactly the right solution. If you're running from
> > some unknown context (like NMI or tracing), then you should check
> > nmi_uaccess_okay(). I think we should just promote that to be a
> > non-arch-specific function (that returns true by default) and check it
> > the relevant bpf_probe_xyz() functions.
>
> I can do that, but notice that switch_mm_irqs_off() writes to
> cpu_tlbstate.loaded_mm before it actually writes to CR3. So there are still
> a couple of instructions (and the load_new_mm_cr3()) in between that a
> kprobe can be set on, no?
But you can't mark then as no-nmi :) See the comment in
nmi_uaccess_ok() -- the code is intended to work correctly during this
window.
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: Add support for 200Gbps (50Gbps per lane) link mode
From: Andrew Lunn @ 2019-02-24 19:40 UTC (permalink / raw)
To: Michal Kubecek
Cc: Tariq Toukan, John W. Linville, netdev, Eran Ben Elisha,
Aya Levin
In-Reply-To: <20190224184046.GB1914@unicorn.suse.cz>
> > This is getting less friendly all the time, and it was never very
> > friendly to start with. We have the strings which represent these link
> > modes in the table used for dumping caps. How about allowing the user
> > to list a comma separate list of modes.
> >
> > ethtool -s lan42 advertise 100000baseKR2/Full,100000baseSR2/Full,100000baseCR2/Full
>
> In my preliminary netlink patchset, I'm adding support for e.g.
>
> ethtool -s eth0 advertise 100baseT/Half off 1000baseT/Full on
>
> I'm not sure what would be more useful, if switching individual modes or
> listing the whole set. After all, we can also support both. But I fully
> agree that the numeric bitmaps are already too inconvenient.
Hi Michal
So are you doing a read/modify/write? In that case, off/on makes
sense. For a pure write, i don't see the need for off/on.
I've not had to use this much, so i don't know how it is typically
used. When i have used it, it is because i've got an SFP which can do
1G and 2.5G, but the peer can only do 1G. I've needed to remove the
2.5G in order to get link. So in that case, read/modify/write with an
off would make sense.
Andrew
> And there is another problem:
>
> + else if (speed_wanted == SPEED_20000 &&
> + duplex_wanted == DUPLEX_FULL)
> + adv_bit = ETHTOOL_LINK_MODE_200000baseKR4_Full_BIT &
> + ETHTOOL_LINK_MODE_200000baseSR4_Full_BIT &
> + ETHTOOL_LINK_MODE_200000baseLR4_ER4_FR4_Full_BIT &
> + ETHTOOL_LINK_MODE_200000baseDR4_Full_BIT &
> + ETHTOOL_LINK_MODE_200000baseCR4_Full_BIT;
>
> The test is for SPEED_20000 but then 200G modes are added.
Oh, yes. Easy to miss. Maybe we should consider adding aliases,
#define SPEED_200G SPEED_200000, and
#define ETHTOOL_LINK_MODE_200GbaseCR4_Full_BIT ETHTOOL_LINK_MODE_200000baseCR4_Full_BIT
Andrew
^ permalink raw reply
* Re: No traffic with Marvell switch and latest linux-next
From: Russell King - ARM Linux admin @ 2019-02-24 19:41 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Heiner Kallweit, Florian Fainelli, netdev@vger.kernel.org
In-Reply-To: <20190224172848.GI26626@lunn.ch>
On Sun, Feb 24, 2019 at 06:28:48PM +0100, Andrew Lunn wrote:
> On Sun, Feb 24, 2019 at 03:31:26PM +0000, Russell King - ARM Linux admin wrote:
> > On Sun, Feb 24, 2019 at 12:42:35AM +0100, Andrew Lunn wrote:
> > > Looking forward, at some point we are going to have to make fixed-link
> > > support higher speeds. That probably means we need a swphy-c45 which
> > > emulates the standard registers for 2.5G, 5G and 10G. At that point
> > > genphy will not work...
> >
> > Do we _need_ to emulate Clause 45 PHYs?
>
> Hi Russell
>
> One use case would be a mv88e6390X port 9 or 10 connected to a SoC
> which can only do 2.5G.
>
> We have defined that DSA drivers should configure CPU and DSA ports to
> their maximum speed. So if port 9 or 10 is used, it should be
> configured to 10G.
>
> We then need some way to reconfigure the MAC to a slower speed.
>
> We need to do this with ZII boards. We do this with:
>
> port@0 {
> reg = <0>;
> label = "cpu";
> ethernet = <&fec1>;
>
> fixed-link {
> speed = <100>;
> full-duplex;
> };
> };
>
> The FEC can only do 100Mbs, but the switch defaults to 1G. So the
> fixed link it used to tell the switch MAC to use 100/Full.
>
> In the example of the 6390X, we would want to set the link speed to
> 2500, which we cannot do at the moment. Either we need fixed-link to
> support higher speeds, or we need a different mechanism.
>
> We also have a similar issue on the SoC side. The FEC has no PHY
> connected to it. It needs to be told what speed to do:
>
> &fec1 {
> phy-mode = "rmii";
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_fec1>;
> status = "okay";
>
> fixed-link {
> speed = <100>;
> full-duplex;
> };
>
> In the case of a SoC with an interface which can do 2.5G, you need to
> tell it to do 2.5G. Ideally we want a mechanism that allows a MAC to
> 'see' a PHY operating at 2.5G using the standard phylib/phylink API.
>
> In the past this has been achieved with an emulated PHY. But so long
> as the phydev/phylink structure has the correct values, it does not
> matter how they get those values.
You'll get a mac_config() with the mode set to MLO_AN_FIXED.
state->speed set to whatever was set in the "speed =" and state->duplex
set according to the duplex property. If pause modes are also defined,
you'll get those through state->pause MLO_PAUSE_SYM and MLO_PAUSE_ASYM,
but there won't be any resolution of those modes since a fixed link
doesn't know the other ends properties, and of course AN is disabled.
Apart from the pause modes, the information passed to the MAC for a
fixed link is exactly the same as if it came from a PHY in phylib,
which basically means the MAC side doesn't actually need to care
whether it has a PHY or fixed-link - but without the complication of
needing phylib to provide an emulated PHY to the network driver.
phylink does provide an emulated PHY for the mii ioctls since that is
an established interface for speeds <= 1G.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* [PATCH net-next] dsa: Remove phydev parameter from disable_port call
From: Andrew Lunn @ 2019-02-24 19:44 UTC (permalink / raw)
To: David Miller
Cc: netdev, Florian Fainelli, Vivien Didelot, hauke, Woojung.Huh,
sean.wang, linus.walleij, Andrew Lunn
No current DSA driver makes use of the phydev parameter passed to the
disable_port call. Remove it.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/b53/b53_common.c | 4 ++--
drivers/net/dsa/b53/b53_priv.h | 2 +-
drivers/net/dsa/bcm_sf2.c | 9 ++++-----
drivers/net/dsa/lan9303-core.c | 3 +--
drivers/net/dsa/lantiq_gswip.c | 5 ++---
drivers/net/dsa/microchip/ksz_common.c | 2 +-
drivers/net/dsa/microchip/ksz_common.h | 2 +-
drivers/net/dsa/mt7530.c | 5 ++---
drivers/net/dsa/mv88e6xxx/chip.c | 3 +--
drivers/net/dsa/qca8k.c | 3 +--
drivers/net/dsa/rtl8366rb.c | 3 +--
drivers/net/dsa/vitesse-vsc73xx.c | 3 +--
include/net/dsa.h | 3 +--
net/dsa/dsa_priv.h | 2 +-
net/dsa/port.c | 4 ++--
net/dsa/slave.c | 2 +-
16 files changed, 23 insertions(+), 32 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 0e4bbdcc614f..50cebb96e685 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -534,7 +534,7 @@ int b53_enable_port(struct dsa_switch *ds, int port, struct phy_device *phy)
}
EXPORT_SYMBOL(b53_enable_port);
-void b53_disable_port(struct dsa_switch *ds, int port, struct phy_device *phy)
+void b53_disable_port(struct dsa_switch *ds, int port)
{
struct b53_device *dev = ds->priv;
u8 reg;
@@ -944,7 +944,7 @@ static int b53_setup(struct dsa_switch *ds)
if (dsa_is_cpu_port(ds, port))
b53_enable_cpu_port(dev, port);
else if (dsa_is_unused_port(ds, port))
- b53_disable_port(ds, port, NULL);
+ b53_disable_port(ds, port);
}
return ret;
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index ec796482792d..6b315ae52a79 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -353,7 +353,7 @@ enum dsa_tag_protocol b53_get_tag_protocol(struct dsa_switch *ds, int port);
void b53_mirror_del(struct dsa_switch *ds, int port,
struct dsa_mall_mirror_tc_entry *mirror);
int b53_enable_port(struct dsa_switch *ds, int port, struct phy_device *phy);
-void b53_disable_port(struct dsa_switch *ds, int port, struct phy_device *phy);
+void b53_disable_port(struct dsa_switch *ds, int port);
void b53_brcm_hdr_setup(struct dsa_switch *ds, int port);
void b53_eee_enable_set(struct dsa_switch *ds, int port, bool enable);
int b53_eee_init(struct dsa_switch *ds, int port, struct phy_device *phy);
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 5193da67dcdc..aade0aa39aed 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -221,8 +221,7 @@ static int bcm_sf2_port_setup(struct dsa_switch *ds, int port,
return b53_enable_port(ds, port, phy);
}
-static void bcm_sf2_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phy)
+static void bcm_sf2_port_disable(struct dsa_switch *ds, int port)
{
struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
u32 reg;
@@ -241,7 +240,7 @@ static void bcm_sf2_port_disable(struct dsa_switch *ds, int port,
if (priv->int_phy_mask & 1 << port && priv->hw_params.num_gphy == 1)
bcm_sf2_gphy_enable_set(ds, false);
- b53_disable_port(ds, port, phy);
+ b53_disable_port(ds, port);
/* Power down the port memory */
reg = core_readl(priv, CORE_MEM_PSM_VDD_CTRL);
@@ -692,7 +691,7 @@ static int bcm_sf2_sw_suspend(struct dsa_switch *ds)
*/
for (port = 0; port < DSA_MAX_PORTS; port++) {
if (dsa_is_user_port(ds, port) || dsa_is_cpu_port(ds, port))
- bcm_sf2_port_disable(ds, port, NULL);
+ bcm_sf2_port_disable(ds, port);
}
return 0;
@@ -786,7 +785,7 @@ static int bcm_sf2_sw_setup(struct dsa_switch *ds)
else if (dsa_is_cpu_port(ds, port))
bcm_sf2_imp_setup(ds, port);
else
- bcm_sf2_port_disable(ds, port, NULL);
+ bcm_sf2_port_disable(ds, port);
}
b53_configure_vlan(ds);
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index b4f6e1a67dd9..2ffab7ee3d80 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -1091,8 +1091,7 @@ static int lan9303_port_enable(struct dsa_switch *ds, int port,
return lan9303_enable_processing_port(chip, port);
}
-static void lan9303_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phy)
+static void lan9303_port_disable(struct dsa_switch *ds, int port)
{
struct lan9303 *chip = ds->priv;
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 27d092cab40e..ee1455758764 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -480,8 +480,7 @@ static int gswip_port_enable(struct dsa_switch *ds, int port,
return 0;
}
-static void gswip_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phy)
+static void gswip_port_disable(struct dsa_switch *ds, int port)
{
struct gswip_priv *priv = ds->priv;
@@ -549,7 +548,7 @@ static int gswip_setup(struct dsa_switch *ds)
/* disable port fetch/store dma on all ports */
for (i = 0; i < priv->hw_info->max_ports; i++)
- gswip_port_disable(ds, i, NULL);
+ gswip_port_disable(ds, i);
/* enable Switch */
gswip_mdio_mask(priv, 0, GSWIP_MDIO_GLOB_ENABLE, GSWIP_MDIO_GLOB);
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 8a5111f9414c..b83337e1566f 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -247,7 +247,7 @@ int ksz_enable_port(struct dsa_switch *ds, int port, struct phy_device *phy)
}
EXPORT_SYMBOL_GPL(ksz_enable_port);
-void ksz_disable_port(struct dsa_switch *ds, int port, struct phy_device *phy)
+void ksz_disable_port(struct dsa_switch *ds, int port)
{
struct ksz_device *dev = ds->priv;
diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h
index 2dd832de0d52..ee3fc9bba292 100644
--- a/drivers/net/dsa/microchip/ksz_common.h
+++ b/drivers/net/dsa/microchip/ksz_common.h
@@ -30,7 +30,7 @@ void ksz_port_mdb_add(struct dsa_switch *ds, int port,
int ksz_port_mdb_del(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_mdb *mdb);
int ksz_enable_port(struct dsa_switch *ds, int port, struct phy_device *phy);
-void ksz_disable_port(struct dsa_switch *ds, int port, struct phy_device *phy);
+void ksz_disable_port(struct dsa_switch *ds, int port);
/* Common register access functions */
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index c2b61500f958..0390c5e8271a 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -729,8 +729,7 @@ mt7530_port_enable(struct dsa_switch *ds, int port,
}
static void
-mt7530_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phy)
+mt7530_port_disable(struct dsa_switch *ds, int port)
{
struct mt7530_priv *priv = ds->priv;
@@ -1301,7 +1300,7 @@ mt7530_setup(struct dsa_switch *ds)
if (dsa_is_cpu_port(ds, i))
mt7530_cpu_port_enable(priv, i);
else
- mt7530_port_disable(ds, i, NULL);
+ mt7530_port_disable(ds, i);
}
/* Flush the FDB table */
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 835f126adedf..058ea5d0ab7e 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2388,8 +2388,7 @@ static int mv88e6xxx_port_enable(struct dsa_switch *ds, int port,
return err;
}
-static void mv88e6xxx_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phydev)
+static void mv88e6xxx_port_disable(struct dsa_switch *ds, int port)
{
struct mv88e6xxx_chip *chip = ds->priv;
diff --git a/drivers/net/dsa/qca8k.c b/drivers/net/dsa/qca8k.c
index a4b6cda38016..6d5bfe39265f 100644
--- a/drivers/net/dsa/qca8k.c
+++ b/drivers/net/dsa/qca8k.c
@@ -789,8 +789,7 @@ qca8k_port_enable(struct dsa_switch *ds, int port,
}
static void
-qca8k_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phy)
+qca8k_port_disable(struct dsa_switch *ds, int port)
{
struct qca8k_priv *priv = (struct qca8k_priv *)ds->priv;
diff --git a/drivers/net/dsa/rtl8366rb.c b/drivers/net/dsa/rtl8366rb.c
index a4d5049df692..40b3974970c6 100644
--- a/drivers/net/dsa/rtl8366rb.c
+++ b/drivers/net/dsa/rtl8366rb.c
@@ -1073,8 +1073,7 @@ rtl8366rb_port_enable(struct dsa_switch *ds, int port,
}
static void
-rtl8366rb_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phy)
+rtl8366rb_port_disable(struct dsa_switch *ds, int port)
{
struct realtek_smi *smi = ds->priv;
int ret;
diff --git a/drivers/net/dsa/vitesse-vsc73xx.c b/drivers/net/dsa/vitesse-vsc73xx.c
index 9f1b5f2e8a64..d4780610ea8a 100644
--- a/drivers/net/dsa/vitesse-vsc73xx.c
+++ b/drivers/net/dsa/vitesse-vsc73xx.c
@@ -1013,8 +1013,7 @@ static int vsc73xx_port_enable(struct dsa_switch *ds, int port,
return 0;
}
-static void vsc73xx_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phy)
+static void vsc73xx_port_disable(struct dsa_switch *ds, int port)
{
struct vsc73xx *vsc = ds->priv;
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 7f2a668ef2cc..d7af808d8500 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -364,8 +364,7 @@ struct dsa_switch_ops {
*/
int (*port_enable)(struct dsa_switch *ds, int port,
struct phy_device *phy);
- void (*port_disable)(struct dsa_switch *ds, int port,
- struct phy_device *phy);
+ void (*port_disable)(struct dsa_switch *ds, int port);
/*
* Port's MAC EEE settings
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 1f4972dab9f2..01ff6e606d46 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -143,7 +143,7 @@ static inline struct net_device *dsa_master_find_slave(struct net_device *dev,
int dsa_port_set_state(struct dsa_port *dp, u8 state,
struct switchdev_trans *trans);
int dsa_port_enable(struct dsa_port *dp, struct phy_device *phy);
-void dsa_port_disable(struct dsa_port *dp, struct phy_device *phy);
+void dsa_port_disable(struct dsa_port *dp);
int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br);
void dsa_port_bridge_leave(struct dsa_port *dp, struct net_device *br);
int dsa_port_vlan_filtering(struct dsa_port *dp, bool vlan_filtering,
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 2d7e01b23572..17c55ce75c39 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -85,7 +85,7 @@ int dsa_port_enable(struct dsa_port *dp, struct phy_device *phy)
return 0;
}
-void dsa_port_disable(struct dsa_port *dp, struct phy_device *phy)
+void dsa_port_disable(struct dsa_port *dp)
{
struct dsa_switch *ds = dp->ds;
int port = dp->index;
@@ -93,7 +93,7 @@ void dsa_port_disable(struct dsa_port *dp, struct phy_device *phy)
dsa_port_set_state_now(dp, BR_STATE_DISABLED);
if (ds->ops->port_disable)
- ds->ops->port_disable(ds, port, phy);
+ ds->ops->port_disable(ds, port);
}
int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 2e5e7c04821b..8f3f090b7e2d 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -122,7 +122,7 @@ static int dsa_slave_close(struct net_device *dev)
phylink_stop(dp->pl);
- dsa_port_disable(dp, dev->phydev);
+ dsa_port_disable(dp);
dev_mc_unsync(master, dev);
dev_uc_unsync(master, dev);
--
2.20.1
^ permalink raw reply related
* Re: stmmac / meson8b-dwmac
From: Sebastian Gottschall @ 2019-02-24 19:42 UTC (permalink / raw)
To: Simon Huelck, Jerome Brunet, Jose Abreu, Martin Blumenstingl
Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue,
Emiliano Ingrassia, netdev
In-Reply-To: <8ec64936-c8fa-1f0e-68bf-2ad1d6e8f5d9@gmx.de>
> **
>
> **its clearly visible when i activated the other stream for getting
> duplex load ... The highest rate also stays alot under the possible
> 930MBits that i have seen earlier with 4.14.
> **
>
> **
> **
>
> **the parallel stream reached around 450Mbits , which almost sums up to
> 660Mbits. This is what i meant when i said that duplex might be broken.
> **
>
> **
> **
>
> **Connecting to host 10.10.11.100, port 5201
> [ 5] local 10.10.11.1 port 38658 connected to 10.10.11.100 port 5201
> [ ID] Interval Transfer Bitrate Retr Cwnd
> [ 5] 0.00-1.00 sec 62.9 MBytes 528 Mbits/sec 0 65.6 KBytes
> [ 5] 1.00-2.00 sec 56.9 MBytes 477 Mbits/sec 0 65.6 KBytes
> [ 5] 2.00-3.00 sec 55.9 MBytes 469 Mbits/sec 0 65.6 KBytes
> [ 5] 3.00-4.00 sec 53.0 MBytes 445 Mbits/sec 0 65.6 KBytes
> [ 5] 4.00-5.00 sec 54.3 MBytes 455 Mbits/sec 0 65.6 KBytes
> [ 5] 5.00-6.00 sec 54.8 MBytes 460 Mbits/sec 0 65.6 KBytes
> [ 5] 6.00-7.00 sec 45.3 MBytes 380 Mbits/sec 0 65.6 KBytes
> [ 5] 7.00-8.00 sec 51.2 MBytes 429 Mbits/sec 0 65.6 KBytes
> [ 5] 8.00-9.00 sec 56.1 MBytes 470 Mbits/sec 0 65.6 KBytes
> [ 5] 9.00-10.00 sec 55.3 MBytes 464 Mbits/sec 0 65.6 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.00 sec 546 MBytes 458 Mbits/sec 0 sender
> [ 5] 0.00-10.00 sec 545 MBytes 457 Mbits/sec
> receiver**
>
> **
> **
>
> **regards,**
>
> **Simon
> **
>
> **
> **
which stmac device are you talking about? its not your windows pc. if
its a ipq8064 based device or something like that you should look
on a very different location. this platform like the r7800 has stmac
performance problems since the kernel clk code for this device is lets
say "very wrong".
so alot of clocks arent correct and so the ethernet performance will
suffer.
i can tell you that i'm able to get 930 mbit on a stmmac based device.
but as i said. the kernel needs other numerous fixes to get a good
performance
root@TEW827:~# iperf3 -c 10.88.193.134 -i 1
Connecting to host 10.88.193.134, port 5201
[ 5] local 10.88.193.90 port 36024 connected to 10.88.193.134 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 108 MBytes 903 Mbits/sec 0 5.17 MBytes
[ 5] 1.00-2.00 sec 112 MBytes 943 Mbits/sec 0 5.17 MBytes
[ 5] 2.00-3.00 sec 109 MBytes 913 Mbits/sec 0 6.02 MBytes
[ 5] 3.00-4.00 sec 112 MBytes 944 Mbits/sec 0 6.02 MBytes
[ 5] 4.00-5.00 sec 109 MBytes 910 Mbits/sec 1 6.02 MBytes
[ 5] 5.00-6.00 sec 111 MBytes 935 Mbits/sec 0 6.02 MBytes
[ 5] 6.00-7.00 sec 109 MBytes 912 Mbits/sec 1 6.02 MBytes
^C[ 5] 7.00-7.51 sec 56.2 MBytes 935 Mbits/sec 0 6.02 MBytes
>
>
^ permalink raw reply
* [PATCH net-next 0/2] net: phy: aquantia: add hwmon support
From: Heiner Kallweit @ 2019-02-24 20:06 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
This series adds HWMON support for the temperature sensor and the
related alarms on the 107/108/109 chips.
Heiner Kallweit (2):
net: phy: aquantia: rename aquantia.c to aquantia_main.c
net: phy: aquantia: add hwmon support
drivers/net/phy/Makefile | 1 +
drivers/net/phy/aquantia_hwmon.c | 263 ++++++++++++++++++
drivers/net/phy/aquantia_hwmon.h | 15 +
.../net/phy/{aquantia.c => aquantia_main.c} | 4 +
4 files changed, 283 insertions(+)
create mode 100644 drivers/net/phy/aquantia_hwmon.c
create mode 100644 drivers/net/phy/aquantia_hwmon.h
rename drivers/net/phy/{aquantia.c => aquantia_main.c} (98%)
--
2.20.1
^ permalink raw reply
* [PATCH net-next 1/2] net: phy: aquantia: rename aquantia.c to aquantia_main.c
From: Heiner Kallweit @ 2019-02-24 20:07 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <0a05279a-ab9e-a978-df4d-f09869c3bba2@gmail.com>
Rename aquantia.c to aquantia_main.c to be prepared for adding new
functionality to separate source code files.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/Makefile | 1 +
drivers/net/phy/{aquantia.c => aquantia_main.c} | 0
2 files changed, 1 insertion(+)
rename drivers/net/phy/{aquantia.c => aquantia_main.c} (100%)
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 5805c0b7d..b0845adaf 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -45,6 +45,7 @@ sfp-obj-$(CONFIG_SFP) += sfp-bus.o
obj-y += $(sfp-obj-y) $(sfp-obj-m)
obj-$(CONFIG_AMD_PHY) += amd.o
+aquantia-objs += aquantia_main.o
obj-$(CONFIG_AQUANTIA_PHY) += aquantia.o
obj-$(CONFIG_ASIX_PHY) += asix.o
obj-$(CONFIG_AT803X_PHY) += at803x.o
diff --git a/drivers/net/phy/aquantia.c b/drivers/net/phy/aquantia_main.c
similarity index 100%
rename from drivers/net/phy/aquantia.c
rename to drivers/net/phy/aquantia_main.c
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 2/2] net: phy: aquantia: add hwmon support
From: Heiner Kallweit @ 2019-02-24 20:09 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <0a05279a-ab9e-a978-df4d-f09869c3bba2@gmail.com>
This adds HWMON support for the temperature sensor and the related
alarms on the 107/108/109 chips. This patch is based on work from
Nikita and Andrew. I added:
- support for changing alarm thresholds via sysfs
- move HWMON code to a separate source file to improve maintainability
- smaller changes like using IS_REACHABLE instead of ifdef
(avoids problems if PHY driver is built in and HWMON is a module)
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/Makefile | 2 +-
drivers/net/phy/aquantia_hwmon.c | 263 +++++++++++++++++++++++++++++++
drivers/net/phy/aquantia_hwmon.h | 15 ++
drivers/net/phy/aquantia_main.c | 4 +
4 files changed, 283 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/phy/aquantia_hwmon.c
create mode 100644 drivers/net/phy/aquantia_hwmon.h
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index b0845adaf..c48596626 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -45,7 +45,7 @@ sfp-obj-$(CONFIG_SFP) += sfp-bus.o
obj-y += $(sfp-obj-y) $(sfp-obj-m)
obj-$(CONFIG_AMD_PHY) += amd.o
-aquantia-objs += aquantia_main.o
+aquantia-objs += aquantia_main.o aquantia_hwmon.o
obj-$(CONFIG_AQUANTIA_PHY) += aquantia.o
obj-$(CONFIG_ASIX_PHY) += asix.o
obj-$(CONFIG_AT803X_PHY) += at803x.o
diff --git a/drivers/net/phy/aquantia_hwmon.c b/drivers/net/phy/aquantia_hwmon.c
new file mode 100644
index 000000000..c0dd695f6
--- /dev/null
+++ b/drivers/net/phy/aquantia_hwmon.c
@@ -0,0 +1,263 @@
+// SPDX-License-Identifier: GPL-2.0
+/* HWMON driver for Aquantia PHY
+ *
+ * Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
+ * Author: Andrew Lunn <andrew@lunn.ch>
+ * Author: Heiner Kallweit <hkallweit1@gmail.com>
+ */
+
+#include <linux/phy.h>
+#include <linux/device.h>
+#include <linux/ctype.h>
+#include <linux/hwmon.h>
+
+#include "aquantia_hwmon.h"
+
+/* Vendor specific 1, MDIO_MMD_VEND1 */
+#define VEND1_THERMAL_PROV_HIGH_TEMP_FAIL 0xc421
+#define VEND1_THERMAL_PROV_LOW_TEMP_FAIL 0xc422
+#define VEND1_THERMAL_PROV_HIGH_TEMP_WARN 0xc423
+#define VEND1_THERMAL_PROV_LOW_TEMP_WARN 0xc424
+#define VEND1_THERMAL_STAT1 0xc820
+#define VEND1_THERMAL_STAT2 0xc821
+#define VEND1_THERMAL_STAT2_VALID BIT(0)
+#define VEND1_GENERAL_STAT1 0xc830
+#define VEND1_GENERAL_STAT1_HIGH_TEMP_FAIL BIT(14)
+#define VEND1_GENERAL_STAT1_LOW_TEMP_FAIL BIT(13)
+#define VEND1_GENERAL_STAT1_HIGH_TEMP_WARN BIT(12)
+#define VEND1_GENERAL_STAT1_LOW_TEMP_WARN BIT(11)
+
+struct aqr_priv {
+ struct device *hwmon_dev;
+ char *hwmon_name;
+};
+
+#if IS_REACHABLE(CONFIG_HWMON)
+
+static umode_t aqr_hwmon_is_visible(const void *data,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ if (type != hwmon_temp)
+ return 0;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ case hwmon_temp_min_alarm:
+ case hwmon_temp_max_alarm:
+ case hwmon_temp_lcrit_alarm:
+ case hwmon_temp_crit_alarm:
+ return 0444;
+ case hwmon_temp_min:
+ case hwmon_temp_max:
+ case hwmon_temp_lcrit:
+ case hwmon_temp_crit:
+ return 0644;
+ default:
+ return 0;
+ }
+}
+
+static int aqr_hwmon_get(struct phy_device *phydev, int reg, long *value)
+{
+ int temp = phy_read_mmd(phydev, MDIO_MMD_VEND1, reg);
+
+ if (temp < 0)
+ return temp;
+
+ /* register value is 2's complement with LSB = 1/256th degree Celsius */
+ if (temp > 0x8000)
+ temp -= 0x10000;
+
+ *value = temp * 1000 / 256;
+
+ return 0;
+}
+
+static int aqr_hwmon_set(struct phy_device *phydev, int reg, long value)
+{
+ int temp;
+
+ if (value >= 128000 || value < -128000)
+ return -ERANGE;
+
+ temp = value * 256 / 1000;
+
+ if (temp < 0)
+ temp += 0x10000;
+
+ return phy_write_mmd(phydev, MDIO_MMD_VEND1, reg, temp);
+}
+
+static int aqr_hwmon_status1(struct phy_device *phydev, int bit, long *value)
+{
+ int reg = phy_read_mmd(phydev, MDIO_MMD_VEND1, VEND1_GENERAL_STAT1);
+
+ if (reg < 0)
+ return reg;
+
+ *value = !!(reg & bit);
+
+ return 0;
+}
+
+static int aqr_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *value)
+{
+ struct phy_device *phydev = dev_get_drvdata(dev);
+ int reg;
+
+ if (type != hwmon_temp)
+ return -EOPNOTSUPP;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ reg = phy_read_mmd(phydev, MDIO_MMD_VEND1,
+ VEND1_THERMAL_STAT2);
+ if (reg < 0)
+ return reg;
+ if (!(reg & VEND1_THERMAL_STAT2_VALID))
+ return -EIO;
+
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_STAT1, value);
+
+ case hwmon_temp_lcrit:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_LOW_TEMP_FAIL,
+ value);
+ case hwmon_temp_min:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_LOW_TEMP_WARN,
+ value);
+ case hwmon_temp_max:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_WARN,
+ value);
+ case hwmon_temp_crit:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_FAIL,
+ value);
+ case hwmon_temp_lcrit_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_LOW_TEMP_FAIL,
+ value);
+ case hwmon_temp_min_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_LOW_TEMP_WARN,
+ value);
+ case hwmon_temp_max_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_HIGH_TEMP_WARN,
+ value);
+ case hwmon_temp_crit_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_HIGH_TEMP_FAIL,
+ value);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int aqr_hwmon_write(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long value)
+{
+ struct phy_device *phydev = dev_get_drvdata(dev);
+
+ if (type != hwmon_temp)
+ return -EOPNOTSUPP;
+
+ switch (attr) {
+ case hwmon_temp_lcrit:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_LOW_TEMP_FAIL,
+ value);
+ case hwmon_temp_min:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_LOW_TEMP_WARN,
+ value);
+ case hwmon_temp_max:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_WARN,
+ value);
+ case hwmon_temp_crit:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_FAIL,
+ value);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static const struct hwmon_ops aqr_hwmon_ops = {
+ .is_visible = aqr_hwmon_is_visible,
+ .read = aqr_hwmon_read,
+ .write = aqr_hwmon_write,
+};
+
+static u32 aqr_hwmon_chip_config[] = {
+ HWMON_C_REGISTER_TZ,
+ 0,
+};
+
+static const struct hwmon_channel_info aqr_hwmon_chip = {
+ .type = hwmon_chip,
+ .config = aqr_hwmon_chip_config,
+};
+
+static u32 aqr_hwmon_temp_config[] = {
+ HWMON_T_INPUT |
+ HWMON_T_MAX | HWMON_T_MIN |
+ HWMON_T_MAX_ALARM | HWMON_T_MIN_ALARM |
+ HWMON_T_CRIT | HWMON_T_LCRIT |
+ HWMON_T_CRIT_ALARM | HWMON_T_LCRIT_ALARM,
+ 0,
+};
+
+static const struct hwmon_channel_info aqr_hwmon_temp = {
+ .type = hwmon_temp,
+ .config = aqr_hwmon_temp_config,
+};
+
+static const struct hwmon_channel_info *aqr_hwmon_info[] = {
+ &aqr_hwmon_chip,
+ &aqr_hwmon_temp,
+ NULL,
+};
+
+static const struct hwmon_chip_info aqr_hwmon_chip_info = {
+ .ops = &aqr_hwmon_ops,
+ .info = aqr_hwmon_info,
+};
+
+static int aqr_hwmon_really_probe(struct phy_device *phydev)
+{
+ struct device *dev = &phydev->mdio.dev;
+ struct aqr_priv *priv = phydev->priv;
+ int i, j;
+
+ priv->hwmon_name = devm_kstrdup(dev, dev_name(dev), GFP_KERNEL);
+ if (!priv->hwmon_name)
+ return -ENOMEM;
+
+ for (i = j = 0; priv->hwmon_name[i]; i++) {
+ if (isalnum(priv->hwmon_name[i])) {
+ if (i != j)
+ priv->hwmon_name[j] = priv->hwmon_name[i];
+ j++;
+ }
+ }
+ priv->hwmon_name[j] = '\0';
+
+ priv->hwmon_dev = devm_hwmon_device_register_with_info(dev,
+ priv->hwmon_name, phydev,
+ &aqr_hwmon_chip_info, NULL);
+
+ return PTR_ERR_OR_ZERO(priv->hwmon_dev);
+}
+
+int aqr_hwmon_probe(struct phy_device *phydev)
+{
+ struct aqr_priv *priv;
+
+ priv = devm_kzalloc(&phydev->mdio.dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ phydev->priv = priv;
+
+ return aqr_hwmon_really_probe(phydev);
+}
+
+#endif
diff --git a/drivers/net/phy/aquantia_hwmon.h b/drivers/net/phy/aquantia_hwmon.h
new file mode 100644
index 000000000..607e68758
--- /dev/null
+++ b/drivers/net/phy/aquantia_hwmon.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0
+ * HWMON driver for Aquantia PHY
+ *
+ * Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
+ * Author: Andrew Lunn <andrew@lunn.ch>
+ * Author: Heiner Kallweit <hkallweit1@gmail.com>
+ */
+
+#include <linux/phy.h>
+
+#if IS_REACHABLE(CONFIG_HWMON)
+int aqr_hwmon_probe(struct phy_device *phydev);
+#else
+static inline int aqr_hwmon_probe(struct phy_device *phydev) { return 0; }
+#endif
diff --git a/drivers/net/phy/aquantia_main.c b/drivers/net/phy/aquantia_main.c
index 0f0eb5682..af6dc3588 100644
--- a/drivers/net/phy/aquantia_main.c
+++ b/drivers/net/phy/aquantia_main.c
@@ -12,6 +12,8 @@
#include <linux/delay.h>
#include <linux/phy.h>
+#include "aquantia_hwmon.h"
+
#define PHY_ID_AQ1202 0x03a1b445
#define PHY_ID_AQ2104 0x03a1b460
#define PHY_ID_AQR105 0x03a1b4a2
@@ -231,6 +233,7 @@ static struct phy_driver aqr_driver[] = {
.name = "Aquantia AQR107",
.aneg_done = genphy_c45_aneg_done,
.get_features = genphy_c45_pma_read_abilities,
+ .probe = aqr_hwmon_probe,
.config_aneg = aqr_config_aneg,
.config_intr = aqr_config_intr,
.ack_interrupt = aqr_ack_interrupt,
@@ -241,6 +244,7 @@ static struct phy_driver aqr_driver[] = {
.name = "Aquantia AQCS109",
.aneg_done = genphy_c45_aneg_done,
.get_features = genphy_c45_pma_read_abilities,
+ .probe = aqr_hwmon_probe,
.config_init = aqcs109_config_init,
.config_aneg = aqr_config_aneg,
.config_intr = aqr_config_intr,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] Documentation: networking: switchdev: Update port parent ID section
From: David Miller @ 2019-02-24 20:13 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, idosch, jiri
In-Reply-To: <20190224.112630.1072776894762356933.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 24 Feb 2019 11:26:30 -0800 (PST)
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Sun, 24 Feb 2019 08:46:59 -0800
>
>> Looks like you applied this to the "net" tree, and I missed prefixing
>> the patch to indicate this was targeted at the "net-next" tree. Are you
>> planning a merge from "net" to "net-next" anytime soon?
>
> Yes, I am working on that right now.
This is now done.
^ permalink raw reply
* marvell10g.c merge into net-next
From: David Miller @ 2019-02-24 20:15 UTC (permalink / raw)
To: hkallweit1; +Cc: netdev
Heiner, please look at net-next which I just merged net into.
Net had a bug fix wherein the MDIO_AN_10GBT_CTRL_ADV_NBT_MASK
bits are cleared in the 10gbt control register to work around
a problem with some marvell10g phy chips.
In the merge I preserved your usage of the generic c45 helpers
in this area, but I suspect part of that will have to be undone
in order to accomodate the above fix.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: aquantia: add hwmon support
From: Andrew Lunn @ 2019-02-24 20:29 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <590d1e26-999e-3b09-fcd9-6d570cadb3bf@gmail.com>
> diff --git a/drivers/net/phy/aquantia_hwmon.c b/drivers/net/phy/aquantia_hwmon.c
> new file mode 100644
> index 000000000..c0dd695f6
> --- /dev/null
> +++ b/drivers/net/phy/aquantia_hwmon.c
> @@ -0,0 +1,263 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* HWMON driver for Aquantia PHY
> + *
> + * Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> + * Author: Andrew Lunn <andrew@lunn.ch>
> + * Author: Heiner Kallweit <hkallweit1@gmail.com>
> + */
> +
> +#include <linux/phy.h>
> +#include <linux/device.h>
> +#include <linux/ctype.h>
> +#include <linux/hwmon.h>
> +
> +#include "aquantia_hwmon.h"
> +
> +/* Vendor specific 1, MDIO_MMD_VEND1 */
> +#define VEND1_THERMAL_PROV_HIGH_TEMP_FAIL 0xc421
> +#define VEND1_THERMAL_PROV_LOW_TEMP_FAIL 0xc422
> +#define VEND1_THERMAL_PROV_HIGH_TEMP_WARN 0xc423
> +#define VEND1_THERMAL_PROV_LOW_TEMP_WARN 0xc424
> +#define VEND1_THERMAL_STAT1 0xc820
> +#define VEND1_THERMAL_STAT2 0xc821
> +#define VEND1_THERMAL_STAT2_VALID BIT(0)
> +#define VEND1_GENERAL_STAT1 0xc830
> +#define VEND1_GENERAL_STAT1_HIGH_TEMP_FAIL BIT(14)
> +#define VEND1_GENERAL_STAT1_LOW_TEMP_FAIL BIT(13)
> +#define VEND1_GENERAL_STAT1_HIGH_TEMP_WARN BIT(12)
> +#define VEND1_GENERAL_STAT1_LOW_TEMP_WARN BIT(11)
> +
> +struct aqr_priv {
> + struct device *hwmon_dev;
> + char *hwmon_name;
> +};
Hi Heiner
It seems a bit odd having the driver private structure here. I expect
with time we are going to need other things in it which are not
HWMON. e.g many of the statistics counters are clear on read. So we
need to keep the running totals somewhere.
I would keep the probe code and the allocation of this structure in
the main driver file.
Andrew
^ permalink raw reply
* Re: [PATCH 5/5] net: dsa: fix a leaked reference by adding missing of_node_put
From: David Miller @ 2019-02-24 20:32 UTC (permalink / raw)
To: wen.yang99
Cc: linus.walleij, andrew, vivien.didelot, f.fainelli, netdev,
linux-kernel, alexandre.belloni, UNGLinuxDriver, nbd,
lorenzo.bianconi83, kvalo, matthias.bgg, linux-wireless,
linux-arm-kernel, linux-mediatek, anirudh, John.Linn,
michal.simek, wang.yi59
In-Reply-To: <1550819742-32155-5-git-send-email-wen.yang99@zte.com.cn>
From: Wen Yang <wen.yang99@zte.com.cn>
Date: Fri, 22 Feb 2019 15:15:42 +0800
> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
> index 8c431e0..89823f0 100644
> --- a/net/dsa/dsa2.c
> +++ b/net/dsa/dsa2.c
> @@ -613,7 +613,7 @@ static int dsa_switch_parse_ports_of(struct dsa_switch *ds,
> struct device_node *ports, *port;
> struct dsa_port *dp;
> u32 reg;
> - int err;
> + int err = 0;
Please preserve the reverse christmas tree ordering of variables here.
Thank you.
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: Add support for 200Gbps (50Gbps per lane) link mode
From: Michal Kubecek @ 2019-02-24 20:33 UTC (permalink / raw)
To: Andrew Lunn
Cc: Tariq Toukan, John W. Linville, netdev, Eran Ben Elisha,
Aya Levin
In-Reply-To: <20190224194015.GM26626@lunn.ch>
On Sun, Feb 24, 2019 at 08:40:15PM +0100, Andrew Lunn wrote:
> > > This is getting less friendly all the time, and it was never very
> > > friendly to start with. We have the strings which represent these link
> > > modes in the table used for dumping caps. How about allowing the user
> > > to list a comma separate list of modes.
> > >
> > > ethtool -s lan42 advertise 100000baseKR2/Full,100000baseSR2/Full,100000baseCR2/Full
> >
> > In my preliminary netlink patchset, I'm adding support for e.g.
> >
> > ethtool -s eth0 advertise 100baseT/Half off 1000baseT/Full on
> >
> > I'm not sure what would be more useful, if switching individual modes or
> > listing the whole set. After all, we can also support both. But I fully
> > agree that the numeric bitmaps are already too inconvenient.
>
> Hi Michal
>
> So are you doing a read/modify/write? In that case, off/on makes
> sense. For a pure write, i don't see the need for off/on.
When using netlink interface, the read/modify/write cycle is limited to
kernel code and is done under rtnl_lock. The netlink interface allows
userspace to send only attributes it wants to change and for bit sets
(like link modes) to tell kernel which bits it wants to change so that
there is no need to read current values first (and open a race window).
When using ioctl interface, ethtool does read the value first even now
as ETHTOOL_SLINKSETTINGS command uses struct ethtool_link_usettings
which has also other members and there is no way to say we only want to
change advertised link modes.
Michal
^ permalink raw reply
* Re: stmmac / meson8b-dwmac
From: Simon Huelck @ 2019-02-24 20:34 UTC (permalink / raw)
To: Sebastian Gottschall, Jerome Brunet, Jose Abreu,
Martin Blumenstingl
Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue,
Emiliano Ingrassia, netdev
In-Reply-To: <f08f2659-dde0-41ec-9233-6b4d5f375ffe@newmedia-net.de>
Am 24.02.2019 um 20:42 schrieb Sebastian Gottschall:
> vice are you talking about? its not your windows pc. if its a ipq8064
> based device or something like that you should look
> on a very different location. this platform like the r7800 has stmac
> performance problems since the kernel clk code for this device is lets
> say "very wrong".
> so alot of clocks arent correct and so the ethernet performance will
> suffer.
>
> i can tell you that i'm able to get 930 mbit on a stmmac based device.
> but as i said. the kernel needs other numerous fixes to get a good
> performance
Hi,
the topic is about ODROID C2 / Amlogic S905X since the start. we have a
performance regression since 4.14.
regards,
Simon
^ 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