* Re: [PATCH v4.1] phylib: Add device reset GPIO support
From: Richard Leitner @ 2017-12-04 16:20 UTC (permalink / raw)
To: Geert Uytterhoeven, David S . Miller, Andrew Lunn,
Florian Fainelli, Simon Horman, Magnus Damm
Cc: Sergei Shtylyov, Rob Herring, Mark Rutland, Nicolas Ferre, netdev,
devicetree, linux-renesas-soc, linux-kernel
In-Reply-To: <1512390905-28094-1-git-send-email-geert+renesas@glider.be>
On 12/04/2017 01:35 PM, Geert Uytterhoeven wrote:
> From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> The PHY devices sometimes do have their reset signal (maybe even power
> supply?) tied to some GPIO and sometimes it also does happen that a boot
> loader does not leave it deasserted. So far this issue has been attacked
> from (as I believe) a wrong angle: by teaching the MAC driver to manipulate
> the GPIO in question; that solution, when applied to the device trees, led
> to adding the PHY reset GPIO properties to the MAC device node, with one
> exception: Cadence MACB driver which could handle the "reset-gpios" prop
> in a PHY device subnode. I believe that the correct approach is to teach
> the 'phylib' to get the MDIO device reset GPIO from the device tree node
> corresponding to this device -- which this patch is doing...
>
> Note that I had to modify the AT803x PHY driver as it would stop working
> otherwise -- it made use of the reset GPIO for its own purposes...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Acked-by: Rob Herring <robh@kernel.org>
> [geert: Propagate actual errors from fwnode_get_named_gpiod()]
> [geert: Avoid destroying initial setup]
> [geert: Consolidate GPIO descriptor acquiring code]
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
Successfully tested this patch on a i.MX6SOLO based board containing a
LAN8710 PHY:
Tested-by: Richard Leitner <richard.leitner@skidata.com>
^ permalink raw reply
* Re: [PATCH net-next] net: phy: broadcom: re-add mistakenly removed config settings
From: David Miller @ 2017-12-04 16:17 UTC (permalink / raw)
To: hkallweit1; +Cc: f.fainelli, netdev
In-Reply-To: <ee8bb979-5aa3-9bd9-2bdc-e3bd35ffc382@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat, 2 Dec 2017 10:50:37 +0100
> Previous patch mistakenly removed three chip-specific config settings.
> Add them again.
>
> Fixes: 80274abafc60 "net: phy: remove generic settings for callbacks config_aneg and read_status from drivers"
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2] net: dsa: Allow compiling out legacy support
From: David Miller @ 2017-12-04 16:15 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20171202033141.18867-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 1 Dec 2017 19:31:41 -0800
> Introduce a configuration option: CONFIG_NET_DSA_LEGACY allowing to compile out
> support for the old platform device and Device Tree binding registration.
> Support for these configurations is scheduled to be removed in 4.17.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
This doesn't apply cleanly, please respin.
Thanks Florian.
^ permalink raw reply
* Re: [PATCH net-next 0/3] add ip6 gre and gretap collect_md mode
From: David Miller @ 2017-12-04 16:11 UTC (permalink / raw)
To: u9012063; +Cc: netdev
In-Reply-To: <1512170770-7866-1-git-send-email-u9012063@gmail.com>
From: William Tu <u9012063@gmail.com>
Date: Fri, 1 Dec 2017 15:26:07 -0800
> Similar to gre, vxlan, geneve, ipip tunnels, allow ip6gretap tunnels to
> operate in collect metadata mode. The first patch adds the support to
> ip6_gre.c. The second patch enables unsetting the csum for ipv6 tunnel,
> when using bpf_skb_[gs]et_tunnel_key() helpers. Finally, the last patch
> adds the ip6 gre and gretap tunnel test cases to BPF sample code.
>
> The corresponding iproute2 patch:
> https://marc.info/?l=linux-netdev&m=151216943128087&w=2
Series applied, thanks William.
^ permalink raw reply
* Re: [PATCH v2 00/31] Replacing net_mutex with rw_semaphore
From: Kirill Tkhai @ 2017-12-04 16:11 UTC (permalink / raw)
To: David Miller
Cc: ebiederm, vyasevic, kstewart, pombredanne, vyasevich,
mark.rutland, gregkh, adobriyan, fw, nicolas.dichtel,
xiyou.wangcong, roman.kapl, paul, dsahern, daniel, lucien.xin,
mschiffer, rshearma, linux-kernel, netdev, avagin, gorcunov,
eric.dumazet, stephen
In-Reply-To: <20171204.111018.1009267614467967882.davem@davemloft.net>
On 04.12.2017 19:10, David Miller wrote:
> From: Kirill Tkhai <ktkhai@virtuozzo.com>
> Date: Mon, 4 Dec 2017 18:54:51 +0300
>
>> Still no comments :(
>>
>> Ping, ping, ping.
>
> You cannot force people to prioritize reviewing your patch submission.
>
> Screaming "ping ping ping" doesn't help, in fact is hinders.
>
>> What will we do next?
>
> Be patient.
Ok, thanks
^ permalink raw reply
* Re: [PATCH v2 00/31] Replacing net_mutex with rw_semaphore
From: David Miller @ 2017-12-04 16:10 UTC (permalink / raw)
To: ktkhai
Cc: ebiederm, vyasevic, kstewart, pombredanne, vyasevich,
mark.rutland, gregkh, adobriyan, fw, nicolas.dichtel,
xiyou.wangcong, roman.kapl, paul, dsahern, daniel, lucien.xin,
mschiffer, rshearma, linux-kernel, netdev, avagin, gorcunov,
eric.dumazet, stephen
In-Reply-To: <a64aa72d-22f9-4784-9aef-b25e29c66382@virtuozzo.com>
From: Kirill Tkhai <ktkhai@virtuozzo.com>
Date: Mon, 4 Dec 2017 18:54:51 +0300
> Still no comments :(
>
> Ping, ping, ping.
You cannot force people to prioritize reviewing your patch submission.
Screaming "ping ping ping" doesn't help, in fact is hinders.
> What will we do next?
Be patient.
^ permalink raw reply
* Re: [PATCH] net: sh_eth: do not advertise Gigabit capabilities when not available
From: Sergei Shtylyov @ 2017-12-04 16:06 UTC (permalink / raw)
To: Thomas Petazzoni, David S. Miller, Niklas Söderlund,
Geert Uytterhoeven, Simon Horman
Cc: netdev, linux-renesas-soc
In-Reply-To: <20171204141346.17410-1-thomas.petazzoni@free-electrons.com>
Hello!
On 12/04/2017 05:13 PM, Thomas Petazzoni wrote:
> Not all variants of the sh_eth hardware have Gigabit
> support. Unfortunately, the current driver doesn't update
> phydev->supported depending on the MAC capabilities. Due to this, if
> you have a Gigabit capable PHY, the PHY will advertise its Gigabit
> capability and establish a link at 1Gbit/s, even though the MAC
> doesn't support it.
>
> In order to avoid this, we mark phydev->supported if we're running a
> non-Gigabit capable hardware.
I guess this (being a fix) was targeted to net.git?
> Tested on a SH7786 platform, with a Gigabit PHY.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[...]
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* RE: [PATCH 1/1] gianfar: fix a flooded alignment reports because of padding issue.
From: Claudiu Manoil @ 2017-12-04 16:06 UTC (permalink / raw)
To: Zumeng Chen, netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: davem@davemloft.net
In-Reply-To: <1512357722-12124-1-git-send-email-zumeng.chen@gmail.com>
>-----Original Message-----
>From: Zumeng Chen [mailto:zumeng.chen@gmail.com]
>Sent: Monday, December 04, 2017 5:22 AM
>To: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
>Cc: Claudiu Manoil <claudiu.manoil@nxp.com>; davem@davemloft.net
>Subject: [PATCH 1/1] gianfar: fix a flooded alignment reports because of padding
>issue.
>
>According to LS1021A RM, the value of PAL can be set so that the start of the
>IP header in the receive data buffer is aligned to a 32-bit boundary. Normally,
>setting PAL = 2 provides minimal padding to ensure such alignment of the IP
>header.
>
>However every incoming packet's 8-byte time stamp will be inserted into the
>packet data buffer as padding alignment bytes when hardware time stamping is
>enabled.
>
>So we set the padding 8+2 here to avoid the flooded alignment faults:
>
>root@128:~# cat /proc/cpu/alignment
>User: 0
>System: 17539 (inet_gro_receive+0x114/0x2c0)
>Skipped: 0
>Half: 0
>Word: 0
>DWord: 0
>Multi: 17539
>User faults: 2 (fixup)
>
[...]
>
> drivers/net/ethernet/freescale/gianfar.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/ethernet/freescale/gianfar.c
>b/drivers/net/ethernet/freescale/gianfar.c
>index e616b71..e47945f 100644
>--- a/drivers/net/ethernet/freescale/gianfar.c
>+++ b/drivers/net/ethernet/freescale/gianfar.c
>@@ -1413,9 +1413,11 @@ static int gfar_probe(struct platform_device *ofdev)
>
> gfar_init_addr_hash_table(priv);
>
>- /* Insert receive time stamps into padding alignment bytes */
>+ /* Insert receive time stamps into padding alignment bytes, and
>+ * plus 2 bytes padding to ensure the cpu alignment.
>+ */
> if (priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER)
>- priv->padding = 8;
>+ priv->padding = 8 + DEFAULT_PADDING;
>
> if (dev->features & NETIF_F_IP_CSUM ||
> priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER)
>--
>2.5.0
Why handle only the rx timestamp path (HAS_TIMER) when the issue, as presented
by you, should be applicable to the default path as well?
The code change according to the patch description should be more likely:
+ priv->padding = DEFAULT_PADDING;
/* Insert receive time stamps into padding alignment bytes */
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER)
- priv->padding = 8;
+ priv->padding += 8;
Do you have any performance numbers for this change?
Thanks,
Claudiu
^ permalink raw reply
* Re: Wifi RTL8723bu driver test: failed to scan
From: Mylene JOSSERAND @ 2017-12-04 15:54 UTC (permalink / raw)
To: Jes Sorensen
Cc: kvalo, linux-wireless, netdev, Thomas Petazzoni, Maxime Ripard
In-Reply-To: <75669dd0-1f25-fc7e-4a4d-a5549aeeb2cf@gmail.com>
Hello,
Le Tue, 28 Nov 2017 11:14:10 -0500,
Jes Sorensen <jes.sorensen@gmail.com> a écrit :
> On 11/22/2017 04:51 AM, Mylene JOSSERAND wrote:
> > Hello Jes Sorensen,
> >
> > I am currently testing a LM811 Wifi/BT USB dongle [1] on a Sinlinx
> > SinA33 Allwinner SoC board [2]. I saw that I should use the realtek
> > driver RTL8723BU for this USB dongle.
> >
> > Currently, I am only testing the Wifi and the mainline driver
> > (kernel 4.14-rc7) does not seem to work. At least, the scanning
> > does not output anything.
> >
> > I tested the driver recommended by LM Technologies [3] and it works
> > fine (scan, connect and ping are ok). Before investigating on the
> > differences between these two drivers, do you have any idea about
> > this issue?
> >
> > Here are the commands and output I got with mainline's driver:
>
> I have not looked at the driver these LM Technologies people are
> referring to, but I am guessing it's the vendor code.
Yes, it is.
>
> 8723bu is a little dicey because it has BT in the chip and if you
> enable that the two drivers need to interact, which rtl8xxxu
> currently doesn't know about. Check your dmesg output to make sure
> you don't have some BT thing loaded hijacking the chip.
Okay, I was also testing the BT so maybe, it was the case. I will
have a try without any BT drivers.
Anyway, thank you for your help!
Best regards,
--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 00/31] Replacing net_mutex with rw_semaphore
From: Kirill Tkhai @ 2017-12-04 15:54 UTC (permalink / raw)
To: davem, ebiederm
Cc: vyasevic, kstewart, pombredanne, vyasevich, mark.rutland, gregkh,
adobriyan, fw, nicolas.dichtel, xiyou.wangcong, roman.kapl, paul,
dsahern, daniel, lucien.xin, mschiffer, rshearma, linux-kernel,
netdev, avagin, gorcunov, eric.dumazet, stephen
In-Reply-To: <151120175301.3159.9577108443167812854.stgit@localhost.localdomain>
Still no comments :(
Ping, ping, ping.
Here is the second version of big patch set with Eric's commentaries accounted.
What will we do next?
On 20.11.2017 21:32, Kirill Tkhai wrote:
> Hi,
>
> there is the second version of patchset introducing net_sem
> instead of net_mutex. The patchset adds net_sem in addition
> to net_mutex and allows pernet_operations to be async. This
> flag means, the pernet_operations methods are safe to be
> executed with any othor pernet_operations (un)initializing
> another net.
>
> If there are only async pernet_operations in the system,
> net_mutex is not used either for setup_net() or for cleanup_net().
>
> The flag is little easier, then (un)register_pernet_sys(),
> as it changes one line only. Also, it requires less changes
> in code. In future, when all pernet_operations are async,
> we'll just remove this struct field.
>
> The pernet_operations converted in this patchset allow
> to create minimal .config to have network working, and
> the changes improve the performance like you may see
> below:
>
> %for i in {1..10000}; do unshare -n bash -c exit; done
>
> *before*
> real 1m40,377s
> user 0m9,672s
> sys 0m19,928s
>
> *after*
> real 0m17,007s
> user 0m5,311s
> sys 0m11,779
>
> (5.8 times faster)
> ---
>
> Kirill Tkhai (31):
> net: Assign net to net_namespace_list in setup_net()
> net: Cleanup copy_net_ns()
> net: Introduce net_sem for protection of pernet_list
> net: Move mutex_unlock() in cleanup_net() up
> net: Allow pernet_operations to be executed in parallel
> net: Convert proc_net_ns_ops
> net: Convert net_ns_ops methods
> net: Convert sysctl_pernet_ops
> net: Convert netfilter_net_ops
> net: Convert nf_log_net_ops
> net: Convert net_inuse_ops
> net: Convert net_defaults_ops
> net: Convert netlink_net_ops
> net: Convert rtnetlink_net_ops
> net: Convert audit_net_ops
> net: Convert uevent_net_ops
> net: Convert proto_net_ops
> net: Convert pernet_subsys ops, registered via net_dev_init()
> net: Convert fib_* pernet_operations, registered via subsys_initcall
> net: Convert subsys_initcall() registered pernet_operations from net/sched
> net: Convert genl_pernet_ops
> net: Convert wext_pernet_ops
> net: Convert sysctl_core_ops
> net: Convert pernet_subsys, registered from inet_init()
> net: Convert unix_net_ops
> net: Convert packet_net_ops
> net: Convert ipv4_sysctl_ops
> net: Convert addrconf_ops
> net: Convert loopback_net_ops
> net: Convert default_device_ops
> net: Convert diag_net_ops
>
>
> drivers/net/loopback.c | 1
> fs/proc/proc_net.c | 1
> include/linux/rtnetlink.h | 1
> include/net/net_namespace.h | 6 +++
> kernel/audit.c | 1
> lib/kobject_uevent.c | 1
> net/core/dev.c | 2 +
> net/core/fib_notifier.c | 1
> net/core/fib_rules.c | 1
> net/core/net-procfs.c | 2 +
> net/core/net_namespace.c | 94 +++++++++++++++++++++++++------------------
> net/core/rtnetlink.c | 5 +-
> net/core/sock.c | 2 +
> net/core/sock_diag.c | 1
> net/core/sysctl_net_core.c | 1
> net/ipv4/af_inet.c | 2 +
> net/ipv4/arp.c | 1
> net/ipv4/devinet.c | 1
> net/ipv4/fib_frontend.c | 1
> net/ipv4/icmp.c | 1
> net/ipv4/igmp.c | 1
> net/ipv4/ip_fragment.c | 1
> net/ipv4/ipmr.c | 1
> net/ipv4/ping.c | 1
> net/ipv4/proc.c | 1
> net/ipv4/raw.c | 1
> net/ipv4/route.c | 4 ++
> net/ipv4/sysctl_net_ipv4.c | 1
> net/ipv4/tcp_ipv4.c | 2 +
> net/ipv4/tcp_metrics.c | 1
> net/ipv4/udp.c | 1
> net/ipv4/udplite.c | 1
> net/ipv4/xfrm4_policy.c | 1
> net/ipv6/addrconf.c | 1
> net/netfilter/core.c | 1
> net/netfilter/nf_log.c | 1
> net/netlink/af_netlink.c | 1
> net/netlink/genetlink.c | 1
> net/packet/af_packet.c | 1
> net/sched/act_api.c | 1
> net/sched/sch_api.c | 1
> net/sysctl_net.c | 1
> net/unix/af_unix.c | 1
> net/wireless/wext-core.c | 1
> net/xfrm/xfrm_policy.c | 1
> 45 files changed, 114 insertions(+), 41 deletions(-)
>
> --
> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
>
^ permalink raw reply
* Re: [PATCH net-next resubmit 1/2] net: phy: core: remove now uneeded disabling of interrupts
From: Ard Biesheuvel @ 2017-12-04 15:51 UTC (permalink / raw)
To: David Miller
Cc: Heiner Kallweit, Florian Fainelli, Andrew Lunn,
<netdev@vger.kernel.org>
In-Reply-To: <20171204.105015.470701847194420222.davem@davemloft.net>
On 4 December 2017 at 15:50, David Miller <davem@davemloft.net> wrote:
> From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Date: Mon, 4 Dec 2017 15:46:55 +0000
>
>> On 4 December 2017 at 15:24, David Miller <davem@davemloft.net> wrote:
>>> From: Heiner Kallweit <hkallweit1@gmail.com>
>>> Date: Thu, 30 Nov 2017 23:55:15 +0100
>>>
>>>> After commits c974bdbc3e "net: phy: Use threaded IRQ, to allow IRQ from
>>>> sleeping devices" and 664fcf123a30 "net: phy: Threaded interrupts allow
>>>> some simplification" all relevant code pieces run in process context
>>>> anyway and I don't think we need the disabling of interrupts any longer.
>>>>
>>>> Interestingly enough, latter commit already removed the comment
>>>> explaining why interrupts need to be temporarily disabled.
>>>>
>>>> On my system phy interrupt mode works fine with this patch.
>>>> However I may miss something, especially in the context of shared phy
>>>> interrupts, therefore I'd appreciate if more people could test this.
>>>>
>>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>>> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>>
>>> Ok, applied.
>>>
>>> But if this causes regressions I'm reverting.
>>
>> Thanks. But please note that the code in question does seem to use the
>> interrupt API incorrectly, and tbh, I was expecting some more
>> discussion first. For reference, here's the commit log for the mostly
>> equivalent patch [0] I sent out almost at the same time:
>
> Yes, it seemed to me that when the code was converted to threaded IRQS
> this {enable,disable}_irq() stuff was not considered.
>
> Again, I read these patches over and I'm willing to own up to the
> changes for now. And if they cause regressions or someone screams
> loudly enough we can revert and talk about it some more.
Excellent, thanks.
^ permalink raw reply
* Re: [PATCH net-next resubmit 1/2] net: phy: core: remove now uneeded disabling of interrupts
From: David Miller @ 2017-12-04 15:50 UTC (permalink / raw)
To: ard.biesheuvel; +Cc: hkallweit1, f.fainelli, andrew, netdev
In-Reply-To: <CAKv+Gu-q7m_2uhE-Ghk0zmGjqVDwpBte2SwV8Mx-kPYA+uLwkA@mail.gmail.com>
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Mon, 4 Dec 2017 15:46:55 +0000
> On 4 December 2017 at 15:24, David Miller <davem@davemloft.net> wrote:
>> From: Heiner Kallweit <hkallweit1@gmail.com>
>> Date: Thu, 30 Nov 2017 23:55:15 +0100
>>
>>> After commits c974bdbc3e "net: phy: Use threaded IRQ, to allow IRQ from
>>> sleeping devices" and 664fcf123a30 "net: phy: Threaded interrupts allow
>>> some simplification" all relevant code pieces run in process context
>>> anyway and I don't think we need the disabling of interrupts any longer.
>>>
>>> Interestingly enough, latter commit already removed the comment
>>> explaining why interrupts need to be temporarily disabled.
>>>
>>> On my system phy interrupt mode works fine with this patch.
>>> However I may miss something, especially in the context of shared phy
>>> interrupts, therefore I'd appreciate if more people could test this.
>>>
>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>
>> Ok, applied.
>>
>> But if this causes regressions I'm reverting.
>
> Thanks. But please note that the code in question does seem to use the
> interrupt API incorrectly, and tbh, I was expecting some more
> discussion first. For reference, here's the commit log for the mostly
> equivalent patch [0] I sent out almost at the same time:
Yes, it seemed to me that when the code was converted to threaded IRQS
this {enable,disable}_irq() stuff was not considered.
Again, I read these patches over and I'm willing to own up to the
changes for now. And if they cause regressions or someone screams
loudly enough we can revert and talk about it some more.
^ permalink raw reply
* Re: [PATCH net-next resubmit 1/2] net: phy: core: remove now uneeded disabling of interrupts
From: Ard Biesheuvel @ 2017-12-04 15:46 UTC (permalink / raw)
To: David Miller
Cc: Heiner Kallweit, Florian Fainelli, Andrew Lunn,
<netdev@vger.kernel.org>
In-Reply-To: <20171204.102417.1919875184945871383.davem@davemloft.net>
On 4 December 2017 at 15:24, David Miller <davem@davemloft.net> wrote:
> From: Heiner Kallweit <hkallweit1@gmail.com>
> Date: Thu, 30 Nov 2017 23:55:15 +0100
>
>> After commits c974bdbc3e "net: phy: Use threaded IRQ, to allow IRQ from
>> sleeping devices" and 664fcf123a30 "net: phy: Threaded interrupts allow
>> some simplification" all relevant code pieces run in process context
>> anyway and I don't think we need the disabling of interrupts any longer.
>>
>> Interestingly enough, latter commit already removed the comment
>> explaining why interrupts need to be temporarily disabled.
>>
>> On my system phy interrupt mode works fine with this patch.
>> However I may miss something, especially in the context of shared phy
>> interrupts, therefore I'd appreciate if more people could test this.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Ok, applied.
>
> But if this causes regressions I'm reverting.
Thanks. But please note that the code in question does seem to use the
interrupt API incorrectly, and tbh, I was expecting some more
discussion first. For reference, here's the commit log for the mostly
equivalent patch [0] I sent out almost at the same time:
"""
The PHY interrupt handling code registers its interrupt as a oneshot
threaded interrupt, which guarantees that the interrupt will be masked
throughout both the primary and secondary handling stages.
However, the handling code still disables the interrupt by calling
disable_irq(), and re-enables it by calling enable_irq() after having
acked the interrupt in the PHY hardware.
This causes problems with hierarchical irqchip implementations built
on top of the GIC, because the core threaded interrupt code will only
EOI the interrupt if it is still masked after the secondary handler
completes. If this is not the case, the EOI is not emitted, and the
interrupt remains active, blocking further interrupts from the same
source. Disabling and enabling the interrupt will result in the secondary
handler completing with the interrupt unmasked, resulting in the above
behavior.
So remove the disable_irq/enable_irq, and rely on the fact that the
interrupt remains masked already.
"""
[0] https://marc.info/?l=linux-netdev&m=151016412011661&w=2
^ permalink raw reply
* Re: [PATCH net-next 0/2] allow setting gso_maximum values
From: David Miller @ 2017-12-04 15:40 UTC (permalink / raw)
To: stephen; +Cc: netdev, sthemmin
In-Reply-To: <20171201153001.4170f55d@xeon-e3>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 1 Dec 2017 15:30:01 -0800
> On Fri, 1 Dec 2017 12:11:56 -0800
> Stephen Hemminger <stephen@networkplumber.org> wrote:
>
>> This is another way of addressing the GSO maximum performance issues for
>> containers on Azure. What happens is that the underlying infrastructure uses
>> a overlay network such that GSO packets over 64K - vlan header end up cause
>> either guest or host to have do expensive software copy and fragmentation.
>>
>> The netvsc driver reports GSO maximum settings correctly, the issue
>> is that containers on veth devices still have the larger settings.
>> One solution that was examined was propogating the values back
>> through the bridge device, but this does not work for cases where
>> virtual container network is done on L3.
>>
>> This patch set punts the problem to the orchestration layer that sets
>> up the container network. It also enables other virtual devices
>> to have configurable settings for GSO maximum.
>>
>> Stephen Hemminger (2):
>> rtnetlink: allow GSO maximums to be passed to device
>> veth: allow configuring GSO maximums
>>
>> drivers/net/veth.c | 20 ++++++++++++++++++++
>> net/core/rtnetlink.c | 2 ++
>> 2 files changed, 22 insertions(+)
>>
>
> I would like a confirmation from Intel that is doing Docker testing
> that this works for them before merging.
Like David Ahern, I think you should allow this net netlink setting
during changelink as well as newlink.
Thanks.
^ permalink raw reply
* Re: [RFC][PATCHES] sock_alloc_file() cleanups and fixes
From: David Miller @ 2017-12-04 15:35 UTC (permalink / raw)
To: viro; +Cc: netdev
In-Reply-To: <20171201002027.GI21978@ZenIV.linux.org.uk>
From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Fri, 1 Dec 2017 00:20:27 +0000
> 1) massage sys_socketpair() (should be a pure cleanup)
> 2) fix and clean up kcm_clone() (-stable fodder)
> 3) switch sock_alloc_file() to new calling conventions.
>
> It got some local testing, but it certainly needs more review.
> Diffstat for the entire thing is
Series looks great to me:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH net-next resubmit 2/2] net: phy: core: don't disable device interrupts in phy_change
From: David Miller @ 2017-12-04 15:24 UTC (permalink / raw)
To: hkallweit1; +Cc: f.fainelli, andrew, netdev, ard.biesheuvel
In-Reply-To: <c5db9f65-bbbc-65b3-f2d9-6be2872ef5e8@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 30 Nov 2017 23:57:00 +0100
> If state is not PHY_HALTED I see no need to temporarily disable
> interrupts on the device. As long as the current interrupt isn't acked
> on the device no new interrupt can happen anyway.
>
> In addition remove a unneeded enabling of interrupts in the state
> machine when handling state PHY_CHANGELINK.
>
> Tested on a Odroid-C2 with RTL8211F phy in interrupt mode.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Also applied, and again if this regresses things I'm reverting.
^ permalink raw reply
* Re: [PATCH net-next resubmit 1/2] net: phy: core: remove now uneeded disabling of interrupts
From: David Miller @ 2017-12-04 15:24 UTC (permalink / raw)
To: hkallweit1; +Cc: f.fainelli, andrew, netdev, ard.biesheuvel
In-Reply-To: <ba11e1ae-dc21-e036-f918-1ed44c92a424@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 30 Nov 2017 23:55:15 +0100
> After commits c974bdbc3e "net: phy: Use threaded IRQ, to allow IRQ from
> sleeping devices" and 664fcf123a30 "net: phy: Threaded interrupts allow
> some simplification" all relevant code pieces run in process context
> anyway and I don't think we need the disabling of interrupts any longer.
>
> Interestingly enough, latter commit already removed the comment
> explaining why interrupts need to be temporarily disabled.
>
> On my system phy interrupt mode works fine with this patch.
> However I may miss something, especially in the context of shared phy
> interrupts, therefore I'd appreciate if more people could test this.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ok, applied.
But if this causes regressions I'm reverting.
^ permalink raw reply
* Re: [PATCH v3 3/6] perf: implement pmu perf_kprobe
From: Peter Zijlstra @ 2017-12-04 15:15 UTC (permalink / raw)
To: Song Liu; +Cc: rostedt, mingo, davem, netdev, linux-kernel, daniel, kernel-team
In-Reply-To: <20171130235023.1414663-6-songliubraving@fb.com>
On Thu, Nov 30, 2017 at 03:50:20PM -0800, Song Liu wrote:
> + tp_event = create_local_trace_kprobe(
> + func, (void *)(unsigned long)(p_event->attr.kprobe_addr),
> + p_event->attr.probe_offset, p_event->attr.config != 0);
So you want to explicitly test bit0 instead? That would leave the other
63 bits available for future extension. The current implementation
completely consumes all 64bits of that config space.
^ permalink raw reply
* Re: [PATCH INTERNAL V2 1/1] brcmfmac: add console log support with configurable read size
From: Kalle Valo @ 2017-12-04 15:15 UTC (permalink / raw)
To: Li Jin
Cc: Wright Feng, Chi-Hsien Lin, Hante Meuleman, Franky Lin,
Arend van Spriel, linux-kernel, netdev, brcm80211-dev-list,
brcm80211-dev-list.pdl, linux-wireless, Jason Uy
In-Reply-To: <1511313990-19334-1-git-send-email-li.jin@broadcom.com>
Li Jin <li.jin@broadcom.com> writes:
> From: Jason Uy <jason.uy@broadcom.com>
>
> Add support for configurable read size so that older wifi
> chips that have size restrictions can be supported.
>
> Signed-off-by: Jason Uy <jason.uy@broadcom.com>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Li Jin <li.jin@broadcom.com>
Arend, am I supposed to apply this even if there's this "INTERNAL" tag
in the Subject?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2] mwl8k: Expand non-DFS 5G channels
From: Kalle Valo @ 2017-12-04 15:13 UTC (permalink / raw)
To: Weixiao Zhang
Cc: Lennert Buytenhek, Johannes Berg, Andrew Zaborowski,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20171116075955.qbbqhwqn4lys3xco@ximibaba.lan>
Weixiao Zhang <waveletboy@gmail.com> writes:
> Add non-DFS 5G upper channels (149-165) besides existed 4 lower channels
> (36, 40, 44, 48).
> { .band = NL80211_BAND_5GHZ, .center_freq = 5745, .hw_value = 149, },
> { .band = NL80211_BAND_5GHZ, .center_freq = 5765, .hw_value = 153, },
> { .band = NL80211_BAND_5GHZ, .center_freq = 5785, .hw_value = 157, },
> { .band = NL80211_BAND_5GHZ, .center_freq = 5805, .hw_value = 161, },
> { .band = NL80211_BAND_5GHZ, .center_freq = 5825, .hw_value = 165, },
>
> Signed-off-by: Weixiao Zhang <waveletboy@gmail.com>
You don't need to copy the code from the patch to the commit log, I'll
remove that when I commit this.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] net: sh_eth: do not advertise Gigabit capabilities when not available
From: Andrew Lunn @ 2017-12-04 15:09 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: David S. Miller, Sergei Shtylyov, Niklas Söderlund,
Geert Uytterhoeven, Simon Horman, netdev, linux-renesas-soc
In-Reply-To: <20171204141346.17410-1-thomas.petazzoni@free-electrons.com>
On Mon, Dec 04, 2017 at 03:13:46PM +0100, Thomas Petazzoni wrote:
> Not all variants of the sh_eth hardware have Gigabit
> support. Unfortunately, the current driver doesn't update
> phydev->supported depending on the MAC capabilities. Due to this, if
> you have a Gigabit capable PHY, the PHY will advertise its Gigabit
> capability and establish a link at 1Gbit/s, even though the MAC
> doesn't support it.
>
> In order to avoid this, we mark phydev->supported if we're running a
> non-Gigabit capable hardware.
>
> Tested on a SH7786 platform, with a Gigabit PHY.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [RFC net-next 4/4] net: phy: Correctly process PHY_HALTED in phy_stop_machine()
From: Marc Gonzalez @ 2017-12-04 15:08 UTC (permalink / raw)
To: Geert Uytterhoeven, Florian Fainelli
Cc: netdev, David S. Miller, Andrew Lunn, Doug Berger, Mason,
David Daney, Geert Uytterhoeven
In-Reply-To: <CAMuHMdXcWRAxpFejgKE5EksGbLUK80wDo2kjmc0rxyukhahMHA@mail.gmail.com>
On 27/11/2017 08:48, Geert Uytterhoeven wrote:
> The MDIO bus callback is not called from the network device ...
>
>>> smsc hangs of [fec10000.bus, which is started only here --->
>>>
>>> Workqueue: events_power_efficient phy_state_machine
>>> [<c010f304>] (unwind_backtrace) from [<c010b7ec>] (show_stack+0x10/0x14)
>>> [<c010b7ec>] (show_stack) from [<c0551ab0>] (dump_stack+0xa4/0xdc)
>>> [<c0551ab0>] (dump_stack) from [<c0120480>] (__warn+0xcc/0xfc)
>>> [<c0120480>] (__warn) from [<c0120554>] (warn_slowpath_null+0x1c/0x24)
>>> [<c0120554>] (warn_slowpath_null) from [<c03ce264>] (__smsc911x_reg_read+0x1c/0x88)
>>> [<c03ce264>] (__smsc911x_reg_read) from [<c03cefc8>] (smsc911x_mac_read+0x4c/0x118)
>>> [<c03cefc8>] (smsc911x_mac_read) from [<c03cf320>] (smsc911x_mii_read+0x2c/0xa4)
>>> [<c03cf320>] (smsc911x_mii_read) from [<c03cd490>] (mdiobus_read+0x58/0x70)
>>> [<c03cd490>] (mdiobus_read) from [<c03cc4a0>] (genphy_update_link+0x18/0x50)
>>> [<c03cc4a0>] (genphy_update_link) from [<c03cc4e4>] (genphy_read_status+0xc/0x1cc)
>>> [<c03cc4e4>] (genphy_read_status) from [<c03ca3e4>] (phy_state_machine+0xa8/0x3f4)
>>> [<c03ca3e4>] (phy_state_machine) from [<c013a740>] (process_one_work+0x240/0x3fc)
>>> [<c013a740>] (process_one_work) from [<c013af28>] (worker_thread+0x2cc/0x40c)
>>> [<c013af28>] (worker_thread) from [<c014024c>] (kthread+0x124/0x144)
>
> ... but from the worker thread, which is unaware of PM states, unless it is
> a freezable workqueue.
>
> Cfr. my patch "[1/2] net: phy: Freeze PHY polling before suspending devices"
> (https://patchwork.kernel.org/patch/9915901/), which made it a freezable
> workqueue, like was done on PCI to solve similar issues with PME scanning.
Hello Geert, Florian,
Is there something I can do to help this patch move forward?
Should we look for a different solution than a synchronous call
to phy_state_machine() ? (Or should I call it from the device
driver, instead of expecting the phy framework to do it?)
Regards.
^ permalink raw reply
* Re: [PATCH v3 3/6] perf: implement pmu perf_kprobe
From: Peter Zijlstra @ 2017-12-04 14:51 UTC (permalink / raw)
To: Song Liu; +Cc: rostedt, mingo, davem, netdev, linux-kernel, daniel, kernel-team
In-Reply-To: <20171130235023.1414663-6-songliubraving@fb.com>
On Thu, Nov 30, 2017 at 03:50:20PM -0800, Song Liu wrote:
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 494eca1..49bbf46 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> static inline void perf_tp_register(void)
> {
> perf_pmu_register(&perf_tracepoint, "tracepoint", PERF_TYPE_TRACEPOINT);
> + perf_pmu_register(&perf_kprobe, "kprobe", -1);
Should we maybe not register this PMU when !KPROBE_EVENTS ? That looks
to save a bunch of #ifdeffery later on.
> }
^ permalink raw reply
* Re: [PATCH v3 3/6] perf: implement pmu perf_kprobe
From: Peter Zijlstra @ 2017-12-04 14:41 UTC (permalink / raw)
To: Song Liu; +Cc: rostedt, mingo, davem, netdev, linux-kernel, daniel, kernel-team
In-Reply-To: <20171130235023.1414663-6-songliubraving@fb.com>
On Thu, Nov 30, 2017 at 03:50:20PM -0800, Song Liu wrote:
> +static struct pmu perf_kprobe = {
> +};
> +static inline bool perf_event_is_tracing(struct perf_event *event)
> +{
> + return event->attr.type == PERF_TYPE_TRACEPOINT ||
> + strncmp(event->pmu->name, "kprobe", 6) == 0;
Why a strcmp here? Wouldn't something like:
event->pmu == &perf_kprobe
work much simpler?
> +}
^ permalink raw reply
* RE: [PATCH net-next 0/8] Hisilicon Network Subsystem 3 VF Ethernet Driver
From: Salil Mehta @ 2017-12-04 14:28 UTC (permalink / raw)
To: Or Gerlitz
Cc: davem@davemloft.net, Zhuangyuzeng (Yisen), lipeng (Y),
mehta.salil.lnk@gmail.com, netdev@vger.kernel.org,
andy@greyhouse.net, simon.horman@netronome.com, jiri@mellanox.com,
Linuxarm
In-Reply-To: <CAJ3xEMj78+9AabgeXS=1ZeiRbMyRtCr55W2zryTDbifqvzhJew@mail.gmail.com>
> -----Original Message-----
> From: Or Gerlitz [mailto:gerlitz.or@gmail.com]
> Sent: Monday, December 04, 2017 2:08 PM
> To: Salil Mehta <salil.mehta@huawei.com>
> Cc: davem@davemloft.net; Zhuangyuzeng (Yisen)
> <yisen.zhuang@huawei.com>; lipeng (Y) <lipeng321@huawei.com>;
> mehta.salil.lnk@gmail.com; netdev@vger.kernel.org; andy@greyhouse.net;
> simon.horman@netronome.com; jiri@mellanox.com
> Subject: Re: [PATCH net-next 0/8] Hisilicon Network Subsystem 3 VF
> Ethernet Driver
>
> On Mon, Dec 4, 2017 at 12:48 PM, Salil Mehta <salil.mehta@huawei.com>
> wrote:
> >> From: Or Gerlitz <gerlitz.or@gmail.com>
>
> >> I wasn't sure if/what PF side control plane user space APIs are
> >> supported by this series, can you elaborate on that?
>
> > Current VF driver just supports very basic functionality. Idea was to
> > push basic RX/TX/RSS/TSO support along with this version.
>
> I was referring to PF driver knobs to manage the e-switch, not to the
> VF driver.
Right. We have unified the Enet driver for VF and PF now which will have
all those hooks related to the switchdev once we decide to get down that
path. And since these are more related to PF they have to be taken care of
in separate patches.
>
> > We will support switchdev and other lined-up features after basic
> > version of the driver has gone through. We are in analysis phase
> right
> > now for all of these features.
>
> sounds good. You might want to consider supporting 1st or only the
> switchdev mode, this will make your PF driver a community leader..
Yes, we will consider it as part of our analysis.
Thanks
Salil
>
> Or.
^ 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