* RE: linux-next: Fixes tag needs some work in the net tree
From: Voon, Weifeng @ 2019-06-24 1:51 UTC (permalink / raw)
To: Stephen Rothwell, David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Ong, Boon Leong
In-Reply-To: <20190624074716.44b749d3@canb.auug.org.au>
> Hi all,
>
> In commit
>
> d0bb82fd6018 ("net: stmmac: set IC bit when transmitting frames with
> HW timestamp")
>
> Fixes tag
>
> Fixes: f748be531d70 ("net: stmmac: Rework coalesce timer and fix
> multi-queue races")
>
> has these problem(s):
>
> - Subject does not match target commit subject
> Just use
> git log -1 --format='Fixes: %h ("%s")'
>
> Fixes: f748be531d70 ("stmmac: support new GMAC4")
>
> or did you mean
>
> Fixes: 8fce33317023 ("net: stmmac: Rework coalesce timer and fix multi-
> queue races")
>
Sorry for the confusion, what I meant is:
Fixes: 8fce33317023 ("net: stmmac: Rework coalesce timer and fix multi-
queue races")
Regards,
Weifeng
> --
> Cheers,
> Stephen Rothwell
^ permalink raw reply
* Re: [PATCH v3 net-next 0/5] ipv6: avoid taking refcnt on dst during route lookup
From: David Miller @ 2019-06-23 20:24 UTC (permalink / raw)
To: dsahern; +Cc: tracywwnj, netdev, edumazet, kafai, maheshb, weiwan
In-Reply-To: <d458f7d7-656b-35ce-a0dc-8444e9562ec1@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Sun, 23 Jun 2019 13:29:27 -0600
> On 6/23/19 12:27 PM, David Miller wrote:
>> From: Wei Wang <tracywwnj@gmail.com>
>> Date: Thu, 20 Jun 2019 17:36:36 -0700
>>
>>> v2->v3:
>>> - Handled fib6_rule_lookup() when CONFIG_IPV6_MULTIPLE_TABLES is not
>>> configured in patch 03 (suggested by David Ahern)
>>> - Removed the renaming of l3mdev_link_scope_lookup() in patch 05
>>> (suggested by David Ahern)
>>> - Moved definition of ip6_route_output_flags() from an inline function
>>> in /net/ipv6/route.c to net/ipv6/route.c in order to address kbuild
>>> error in patch 05
>>
>> I'll give David A. a chance to review this before applying.
>>
>
> Hey Dave: I responded to the cover-letter on Friday.
Indeed, and so did tractor man.
Series applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH v3 net-next 0/5] ipv6: avoid taking refcnt on dst during route lookup
From: David Ahern @ 2019-06-23 19:29 UTC (permalink / raw)
To: David Miller, tracywwnj; +Cc: netdev, edumazet, kafai, maheshb, weiwan
In-Reply-To: <20190623.112716.2247998657903069805.davem@davemloft.net>
On 6/23/19 12:27 PM, David Miller wrote:
> From: Wei Wang <tracywwnj@gmail.com>
> Date: Thu, 20 Jun 2019 17:36:36 -0700
>
>> v2->v3:
>> - Handled fib6_rule_lookup() when CONFIG_IPV6_MULTIPLE_TABLES is not
>> configured in patch 03 (suggested by David Ahern)
>> - Removed the renaming of l3mdev_link_scope_lookup() in patch 05
>> (suggested by David Ahern)
>> - Moved definition of ip6_route_output_flags() from an inline function
>> in /net/ipv6/route.c to net/ipv6/route.c in order to address kbuild
>> error in patch 05
>
> I'll give David A. a chance to review this before applying.
>
Hey Dave: I responded to the cover-letter on Friday.
^ permalink raw reply
* Re: [PATCH v2 net] af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET
From: Neil Horman @ 2019-06-23 19:21 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Network Development, Matteo Croce, David S. Miller
In-Reply-To: <CAF=yD-L5Lu6L4Ji=OZgAkDb28zL=BVsM5HgqWMxMTiJ1YUZJDw@mail.gmail.com>
On Sun, Jun 23, 2019 at 10:39:12AM -0400, Willem de Bruijn wrote:
> On Sun, Jun 23, 2019 at 7:40 AM Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > On Sat, Jun 22, 2019 at 10:21:31PM -0400, Willem de Bruijn wrote:
> > > > > -static void __packet_set_status(struct packet_sock *po, void *frame, int status)
> > > > > +static void __packet_set_status(struct packet_sock *po, void *frame, int status,
> > > > > + bool call_complete)
> > > > > {
> > > > > union tpacket_uhdr h;
> > > > >
> > > > > @@ -381,6 +382,8 @@ static void __packet_set_status(struct packet_sock *po, void *frame, int status)
> > > > > BUG();
> > > > > }
> > > > >
> > > > > + if (po->wait_on_complete && call_complete)
> > > > > + complete(&po->skb_completion);
> > > >
> > > > This wake need not happen before the barrier. Only one caller of
> > > > __packet_set_status passes call_complete (tpacket_destruct_skb).
> > > > Moving this branch to the caller avoids a lot of code churn.
> > > >
> > > > Also, multiple packets may be released before the process is awoken.
> > > > The process will block until packet_read_pending drops to zero. Can
> > > > defer the wait_on_complete to that one instance.
> > >
> > > Eh no. The point of having this sleep in the send loop is that
> > > additional slots may be released for transmission (flipped to
> > > TP_STATUS_SEND_REQUEST) from another thread while this thread is
> > > waiting.
> > >
> > Thats incorrect. The entirety of tpacket_snd is protected by a mutex. No other
> > thread can alter the state of the frames in the vector from the kernel send path
> > while this thread is waiting.
>
> I meant another user thread updating the memory mapped ring contents.
>
Yes, thats true, and if that happens, we will loop through this path again (the
do..while section, picking up the next frame for transmit)
> > > Else, it would have been much simpler to move the wait below the send
> > > loop: send as many packets as possible, then wait for all of them
> > > having been released. Much clearer control flow.
> > >
> > Thats (almost) what happens now. The only difference is that with this
> > implementation, the waiting thread has the opportunity to see if userspace has
> > queued more frames for transmission during the wait period. We could
> > potentially change that, but thats outside the scope of this fix.
>
> Agreed. I think the current, more complex, behavior was intentional.
> We could still restructure to move it out of the loop and jump back.
> But, yes, definitely out of scope for a fix.
>
Yes, it was, though based on your comments I've moved the wait_for_completion
call to the bottom of the loop, so its only checked after we are guaranteed to
have sent at least one frame. I think that makes the code a bit more legible.
> > > Where to set and clear the wait_on_complete boolean remains. Integer
> > > assignment is fragile, as the compiler and processor may optimize or
> > > move simple seemingly independent operations. As complete() takes a
> > > spinlock, avoiding that in the DONTWAIT case is worthwhile. But probably
> > > still preferable to set when beginning waiting and clear when calling
> > > complete.
> > We avoid any call to wait_for_complete or complete already, based on the gating
> > of the need_wait variable in tpacket_snd. If the transmitting thread doesn't
> > set MSG_DONTWAIT in the flags of the msg structure, we will never set
> > wait_for_complete, and so we will never manipulate the completion queue.
>
> But we don't know the state of this at tpacket_destruct_skb time without
> wait_for_completion?
>
Sure we do, wait_for_complete is stored in the packet_sock structure, which is
available and stable at the time tpacket_destruct_skb is called.
po->wait_for_complete is set in tpacket_snd iff:
1) The MSG_DONTWAIT flag is clear
and
2) We have detected that the next frame in the memory mapped buffer does not
have its status set to TP_STATUS_SEND_REQUEST.
If those two conditions are true, we set po->wait_for_complete to 1, which
indicates that tpacket_destruct_skb should call complete, when all the frames
we've sent to the physical layer have been freed (i.e. when packet_read_pending
is zero).
If wait_for_complete is non-zero, we also can be confident that the
calling task is either:
a) Already blocking on wait_for_completion_interruptible_timeout
or
b) Will be waiting on it shortly
In case (a) the blocking/transmitting task will be woken up, and continue on its
way
In case (b) the transmitting task will call
wait_for_completion_interruptible_timeout, see that the completion has already
been called (based on the completion structs done variable being positive), and
return immediately.
I've made a slight update to the logic/comments in my next version to make that a little
more clear
Neil
^ permalink raw reply
* Re: [PATCH 04/15] ARM: exynos: cleanup cppcheck shifting error
From: Krzysztof Kozlowski @ 2019-06-23 19:12 UTC (permalink / raw)
To: Phong Tran
Cc: mark.rutland, kstewart, songliubraving, andrew, peterz, nsekhar,
ast, jolsa, netdev, gerg, lorenzo.pieralisi, will,
linux-samsung-soc@vger.kernel.org, daniel, festevam,
gregory.clement, allison, linux, haojian.zhuang, bgolaszewski,
tony, mingo, linux-imx, yhs, sebastian.hesselbarth,
illusionist.neo, jason, liviu.dudau, s.hauer, acme, lkundrak,
robert.jarzmik, dmg, swinslow, namhyung, tglx, linux-omap,
alexander.sverdlin, linux-arm-kernel, info, gregkh, linux-kernel,
alexander.shishkin, hsweeten, kgene, kernel, sudeep.holla, bpf,
shawnguo, kafai, daniel
In-Reply-To: <20190623151313.970-5-tranmanphong@gmail.com>
On Sun, 23 Jun 2019 at 17:14, Phong Tran <tranmanphong@gmail.com> wrote:
>
> [arch/arm/mach-exynos/suspend.c:288]: (error) Shifting signed 32-bit
> value by 31 bits is undefined behaviour
>
> Signed-off-by: Phong Tran <tranmanphong@gmail.com>
> ---
> arch/arm/mach-exynos/suspend.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Let's switch to BIT macro. It will solve the problem and is preferred
way of coding.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next] doc: phy: document some PHY_INTERFACE_MODE_xxx settings
From: David Miller @ 2019-06-23 18:35 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, hkallweit1, corbet, netdev, linux-doc
In-Reply-To: <E1heL0P-00075z-An@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Fri, 21 Jun 2019 15:59:09 +0100
> There seems to be some confusion surrounding three PHY interface modes,
> specifically 1000BASE-X, 2500BASE-X and SGMII. Add some documentation
> to phylib detailing precisely what these interface modes refer to.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/4] cxgb4: Re-work the logic for mps refcounting
From: David Miller @ 2019-06-23 18:34 UTC (permalink / raw)
To: rajur; +Cc: netdev, nirranjan, dt
In-Reply-To: <20190621143636.20422-2-rajur@chelsio.com>
From: Raju Rangoju <rajur@chelsio.com>
Date: Fri, 21 Jun 2019 20:06:33 +0530
> +struct mps_entries_ref {
> + struct list_head list;
> + u8 addr[ETH_ALEN];
> + u8 mask[ETH_ALEN];
> + u16 idx;
> + atomic_t refcnt;
> +};
Since you're making this change, please use refcnt_t.
^ permalink raw reply
* Re: [PATCH] net/sched: cbs: Fix error path of cbs_module_init
From: David Miller @ 2019-06-23 18:33 UTC (permalink / raw)
To: yuehaibing; +Cc: jhs, xiyou.wangcong, jiri, linux-kernel, netdev
In-Reply-To: <20190621134437.4252-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Fri, 21 Jun 2019 21:44:37 +0800
> If register_qdisc fails, we should unregister
> netdevice notifier.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: e0a7683d30e9 ("net/sched: cbs: fix port_rate miscalculation")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3 net-next 0/5] ipv6: avoid taking refcnt on dst during route lookup
From: David Miller @ 2019-06-23 18:27 UTC (permalink / raw)
To: tracywwnj; +Cc: netdev, edumazet, kafai, dsahern, maheshb, weiwan
In-Reply-To: <20190621003641.168591-1-tracywwnj@gmail.com>
From: Wei Wang <tracywwnj@gmail.com>
Date: Thu, 20 Jun 2019 17:36:36 -0700
> v2->v3:
> - Handled fib6_rule_lookup() when CONFIG_IPV6_MULTIPLE_TABLES is not
> configured in patch 03 (suggested by David Ahern)
> - Removed the renaming of l3mdev_link_scope_lookup() in patch 05
> (suggested by David Ahern)
> - Moved definition of ip6_route_output_flags() from an inline function
> in /net/ipv6/route.c to net/ipv6/route.c in order to address kbuild
> error in patch 05
I'll give David A. a chance to review this before applying.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: mv88e6xxx: introduce helpers for handling chip->reg_lock
From: David Miller @ 2019-06-23 18:25 UTC (permalink / raw)
To: rasmus.villemoes
Cc: andrew, vivien.didelot, f.fainelli, Rasmus.Villemoes, netdev,
linux-kernel
In-Reply-To: <20190620135034.24986-1-rasmus.villemoes@prevas.dk>
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Date: Thu, 20 Jun 2019 13:50:42 +0000
> This is a no-op that simply moves all locking and unlocking of
> ->reg_lock into trivial helpers. I did that to be able to easily add
> some ad hoc instrumentation to those helpers to get some information
> on contention and hold times of the mutex. Perhaps others want to do
> something similar at some point, so this frees them from doing the
> 'sed -i' yoga, and have a much smaller 'git diff' while fiddling.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Applied.
^ permalink raw reply
* Re: [PATCH -next] inet: fix compilation warnings in fqdir_pre_exit()
From: David Miller @ 2019-06-23 18:25 UTC (permalink / raw)
To: cai; +Cc: edumazet, netdev, linux-kernel
In-Reply-To: <1561042360-20480-1-git-send-email-cai@lca.pw>
From: Qian Cai <cai@lca.pw>
Date: Thu, 20 Jun 2019 10:52:40 -0400
> The linux-next commit "inet: fix various use-after-free in defrags
> units" [1] introduced compilation warnings,
>
> ./include/net/inet_frag.h:117:1: warning: 'inline' is not at beginning
> of declaration [-Wold-style-declaration]
> static void inline fqdir_pre_exit(struct fqdir *fqdir)
> ^~~~~~
> In file included from ./include/net/netns/ipv4.h:10,
> from ./include/net/net_namespace.h:20,
> from ./include/linux/netdevice.h:38,
> from ./include/linux/icmpv6.h:13,
> from ./include/linux/ipv6.h:86,
> from ./include/net/ipv6.h:12,
> from ./include/rdma/ib_verbs.h:51,
> from ./include/linux/mlx5/device.h:37,
> from ./include/linux/mlx5/driver.h:51,
> from
> drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:37:
>
> [1] https://lore.kernel.org/netdev/20190618180900.88939-3-edumazet@google.com/
>
> Signed-off-by: Qian Cai <cai@lca.pw>
Applied.
^ permalink raw reply
* Re: [PATCH] FDDI: defza: Include linux/io-64-nonatomic-lo-hi.h
From: David Miller @ 2019-06-23 18:25 UTC (permalink / raw)
To: paul.burton
Cc: macro, netdev, pburton, Sergey.Semin, linux-mips, linux-kernel
In-Reply-To: <20190620221224.27352-1-paul.burton@mips.com>
From: Paul Burton <paul.burton@mips.com>
Date: Thu, 20 Jun 2019 22:13:58 +0000
> Currently arch/mips/include/asm/io.h provides 64b memory accessor
> functions such as readq & writeq even on MIPS32 platforms where those
> accessors cannot actually perform a 64b memory access. They instead
> BUG(). This is unfortunate for drivers which either #ifdef on the
> presence of these accessors, or can function with non-atomic
> implementations of them found in either linux/io-64-nonatomic-lo-hi.h or
> linux/io-64-nonatomic-hi-lo.h. As such we're preparing to remove the
> definitions of these 64b accessor functions for MIPS32 kernels.
>
> In preparation for this, include linux/io-64-nonatomic-lo-hi.h in
> defza.c in order to provide a non-atomic implementation of the
> readq_relaxed & writeq_relaxed functions that are used by this code. In
> practice this will have no runtime effect, since use of the 64b accessor
> functions is conditional upon sizeof(unsigned long) == 8, ie. upon
> CONFIG_64BIT=y. This means the calls to these non-atomic readq & writeq
> implementations will be optimized out anyway, but we need their
> definitions to keep the compiler happy.
>
> For 64bit kernels using this code this change should also have no effect
> because asm/io.h will continue to provide the definitions of
> readq_relaxed & writeq_relaxed, which linux/io-64-nonatomic-lo-hi.h
> checks for before defining itself.
>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
...
> Maciej, David, if you'd be happy to provide an Ack so that I can take
> this through the mips-next branch that would be great; that'll let me
> apply it prior to the asm/io.h change.
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: network unstable on odroid-c1/meson8b.
From: Aymeric @ 2019-06-23 18:16 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Martin Blumenstingl, netdev, linux-amlogic
In-Reply-To: <fc416bf0-3f3c-72a8-0500-4e487d8f3a27@aplu.fr>
Le 20/06/2019 à 22:54, Aymeric a écrit :
> Le 20/06/2019 à 17:53, Heiner Kallweit a écrit :
>> On 20.06.2019 09:55, Aymeric wrote:
>>> Hi,
>>> On 2019-06-20 00:14, Heiner Kallweit wrote:
>>>> On 19.06.2019 22:18, Aymeric wrote:
>>>>> Hello all,
>>>>>
>>>> Kernel 3.10 didn't have a dedicated RTL8211F PHY driver yet, therefore
>>>> I assume the genphy driver was used. Do you have a line with
>>>> "attached PHY driver" in dmesg output of the vendor kernel?
>>> No.
>>> Here is the full output of the dmesg from vendor kernel [¹].
>>>
>>> I've also noticed something strange, it might be linked, but mac address of the board is set to a random value when using mainline kernel and I've to set it manually but not when using vendor kernel.
>>>
>>>> The dedicated PHY driver takes care of the tx delay, if the genphy
>>>> driver is used we have to rely on what uboot configured.
>>>> But if we indeed had an issue with a misconfigured delay, I think
>>>> the connection shouldn't be fine with just another link partner.
>>>> Just to have it tested you could make rtl8211f_config_init() in
>>>> drivers/net/phy/realtek.c a no-op (in current kernels).
>>>>
>>> I'm not an expert here, just adding a "return 0;" here[²] would be enough?
>>>
>>>> And you could compare at least the basic PHY registers 0x00 - 0x30
>>>> with both kernel versions, e.g. with phytool.
>>>>
>>> They are not the same but I don't know what I'm looking for, so for kernel 3.10 [³] and for kernel 5.1.12 [⁴].
>>>
>>> Aymeric
>>>
>>> [¹]: https://paste.aplu.fr/?38ef95b44ebdbfc3#G666/YbhgU+O+tdC/2HaimUCigm8ZTB44qvQip/HJ5A=
>>> [²]: https://github.com/torvalds/linux/blob/241e39004581475b2802cd63c111fec43bb0123e/drivers/net/phy/realtek.c#L164
>>> [³]: https://paste.aplu.fr/?2dde1c32d5c68f4c#6xIa8MjTm6jpI6citEJAqFTLMMHDjFZRet/M00/EwjU=
>>> [⁴]: https://paste.aplu.fr/?32130e9bcb05dde7#N/xdnvb5GklcJtiOxMpTCm+9gsUliRwH8X3dcwSV+ng=
>>>
>> The vendor kernel has some, but not really much magic:
>> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/drivers/amlogic/ethernet/phy/am_rtl8211f.c
>> The write to RTL8211F_PHYCR2 is overwritten later, therefore we don't have to consider it.
>>
>> The following should make the current Realtek PHY driver behave like in the vendor driver.
>> Could you test it?
> (sending again for mailing list, sorry, I forgot to force it in plaintext…)
>
> I've applied your patch and tried but it doesn't change anything.
>
> Here is dmesg output and phytool results.
>
> https://paste.aplu.fr/?9735c99907528929#SeCgwR45cgnbDA1tXIVBHCBT8RNct2r41jU6vsguLVc=
>
Hello all,
I had some news from a friend who have the same issue than me, his board
is connected to an "intelligent" switch a Ubiquiti EdgeSwitch.
Also, when he force the link to 100 it is stable.
Aymeric.
--
Aymeric
^ permalink raw reply
* Re: [PATCH][net-next] hinic: fix dereference of pointer hwdev before it is null checked
From: David Miller @ 2019-06-23 18:08 UTC (permalink / raw)
To: colin.king
Cc: xuechaojing, aviad.krawczyk, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20190620132751.26438-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Thu, 20 Jun 2019 14:27:51 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently pointer hwdev is dereferenced when assigning hwif before
> hwdev is null checked. Fix this by only derefencing hwdev after the
> null check.
>
> Addresses-Coverity: ("Dereference before null check")
> Fixes: 4fdc51bb4e92 ("hinic: add support for rss parameters with ethtool")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] vxlan: do not destroy fdb if register_netdevice() is failed
From: David Miller @ 2019-06-23 18:07 UTC (permalink / raw)
To: ap420073; +Cc: netdev
In-Reply-To: <20190620115108.5701-1-ap420073@gmail.com>
From: Taehee Yoo <ap420073@gmail.com>
Date: Thu, 20 Jun 2019 20:51:08 +0900
> __vxlan_dev_create() destroys FDB using specific pointer which indicates
> a fdb when error occurs.
> But that pointer should not be used when register_netdevice() fails because
> register_netdevice() internally destroys fdb when error occurs.
>
> In order to avoid un-registered dev's notification, fdb destroying routine
> checks dev's register status before notification.
Simply pass do_notify as false in this failure code path of __vxlan_dev_create(),
thank you.
^ permalink raw reply
* Re: [PATCH net-next 10/16] qlge: Factor out duplicated expression
From: David Miller @ 2019-06-23 18:00 UTC (permalink / raw)
To: bpoirier; +Cc: manishc, GR-Linux-NIC-Dev, netdev
In-Reply-To: <20190623.105935.2293591576103857913.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 23 Jun 2019 10:59:35 -0700 (PDT)
> "(u16) 65536" is zero and the range of these values is 0 -- 65536.
>
> This whole expression is way overdone.
Also, when you post the next revision of this patch series, please
provide a proper "[PATCH net-next 00/16]" header posting explaining
what this patch series does logically at the high level, how it is
doing it, and why it is doing it that way.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next 10/16] qlge: Factor out duplicated expression
From: David Miller @ 2019-06-23 17:59 UTC (permalink / raw)
To: bpoirier; +Cc: manishc, GR-Linux-NIC-Dev, netdev
In-Reply-To: <20190617074858.32467-10-bpoirier@suse.com>
From: Benjamin Poirier <bpoirier@suse.com>
Date: Mon, 17 Jun 2019 16:48:52 +0900
> Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
> ---
> drivers/net/ethernet/qlogic/qlge/qlge.h | 6 ++++++
> drivers/net/ethernet/qlogic/qlge/qlge_main.c | 18 ++++++------------
> 2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qlge/qlge.h b/drivers/net/ethernet/qlogic/qlge/qlge.h
> index 5a4b2520cd2a..0bb7ccdca6a7 100644
> --- a/drivers/net/ethernet/qlogic/qlge/qlge.h
> +++ b/drivers/net/ethernet/qlogic/qlge/qlge.h
> @@ -77,6 +77,12 @@
> #define LSD(x) ((u32)((u64)(x)))
> #define MSD(x) ((u32)((((u64)(x)) >> 32)))
>
> +#define QLGE_FIT16(value) \
> +({ \
> + typeof(value) _value = value; \
> + (_value) == 65536 ? 0 : (u16)(_value); \
> +})
> +
"(u16) 65536" is zero and the range of these values is 0 -- 65536.
This whole expression is way overdone.
^ permalink raw reply
* RE: [PATCH net-next 3/3] mlxsw: core: Add support for negative temperature readout
From: Vadim Pasternak @ 2019-06-23 16:34 UTC (permalink / raw)
To: Andrew Lunn
Cc: Ido Schimmel, netdev@vger.kernel.org, davem@davemloft.net,
Jiri Pirko, mlxsw, Ido Schimmel
In-Reply-To: <20190623162537.GF28942@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Sunday, June 23, 2019 7:26 PM
> To: Vadim Pasternak <vadimp@mellanox.com>
> Cc: Ido Schimmel <idosch@idosch.org>; netdev@vger.kernel.org;
> davem@davemloft.net; Jiri Pirko <jiri@mellanox.com>; mlxsw
> <mlxsw@mellanox.com>; Ido Schimmel <idosch@mellanox.com>
> Subject: Re: [PATCH net-next 3/3] mlxsw: core: Add support for negative
> temperature readout
>
> > > Why the > 0?
> >
> > We don't consider negative temperature for thermal control.
>
> Is this because the thermal control is also broken and does not support negative
> values? This is just a workaround papering over the cracks?
We just have system hardware requirements for minimal speed for system
PWM. It could not be less than 20%.
So for temperature ~40C or below it PWM will set to this speed.
>
> I've worked on some systems where the thermal subsystem has controller a
> heater. Mostly industrial systems, extended temperature range, and you have to
> make sure the hardware is kept above -25C, otherwise the DRAM timing goes to
> pot and the system crashed and froze.
Interesting input. I didn't know about such feature.
We don't have heaters within our systems.
Maybe we should think about it for the next generatin systems.
>
> Andrew
^ permalink raw reply
* Re: [PATCH] sis900: increment revision number
From: Joe Perches @ 2019-06-23 16:26 UTC (permalink / raw)
To: David Miller, venza; +Cc: sergej.benilov, netdev
In-Reply-To: <20190623.083724.172652862205625872.davem@davemloft.net>
On Sun, 2019-06-23 at 08:37 -0700, David Miller wrote:
> From: Daniele Venzano <venza@brownhat.org>
> Date: Sun, 23 Jun 2019 11:13:28 +0200
>
> > Hello,
> >
> > I think it is good to know just by looking at the sources that the
> > driver is still kept up-to-date, so I am in favor of this patch.
>
> I absolutely, strongly, disagree.
>
> These are pointless.
Perhaps (most)? all the .get_drvinfo function calls where the
driver version is returned should use the default release.
This is similar to net/wireless/ethtool.c
Maybe:
---
net/core/ethtool.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 4d1011b2e24f..644a2043714c 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -23,6 +23,7 @@
#include <linux/rtnetlink.h>
#include <linux/sched/signal.h>
#include <linux/net.h>
+#include <linux/utsname.h>
#include <net/devlink.h>
#include <net/xdp_sock.h>
#include <net/flow_offload.h>
@@ -806,6 +807,8 @@ static noinline_for_stack int ethtool_get_drvinfo(struct net_device *dev,
devlink_compat_running_version(dev, info.fw_version,
sizeof(info.fw_version));
+ strlcpy(info.version, init_utsname()->release, sizeof(info.version));
+
if (copy_to_user(useraddr, &info, sizeof(info)))
return -EFAULT;
return 0;
^ permalink raw reply related
* Re: [PATCH net-next 3/3] mlxsw: core: Add support for negative temperature readout
From: Andrew Lunn @ 2019-06-23 16:25 UTC (permalink / raw)
To: Vadim Pasternak
Cc: Ido Schimmel, netdev@vger.kernel.org, davem@davemloft.net,
Jiri Pirko, mlxsw, Ido Schimmel
In-Reply-To: <AM6PR05MB5224C6BC97D0F90391DA9B0FA2E10@AM6PR05MB5224.eurprd05.prod.outlook.com>
> > Why the > 0?
>
> We don't consider negative temperature for thermal control.
Is this because the thermal control is also broken and does not
support negative values? This is just a workaround papering over the
cracks?
I've worked on some systems where the thermal subsystem has controller
a heater. Mostly industrial systems, extended temperature range, and
you have to make sure the hardware is kept above -25C, otherwise the
DRAM timing goes to pot and the system crashed and froze.
Andrew
^ permalink raw reply
* RE: [PATCH net-next 3/3] mlxsw: core: Add support for negative temperature readout
From: Vadim Pasternak @ 2019-06-23 16:11 UTC (permalink / raw)
To: Andrew Lunn, Ido Schimmel
Cc: netdev@vger.kernel.org, davem@davemloft.net, Jiri Pirko, mlxsw,
Ido Schimmel
In-Reply-To: <AM6PR05MB5224C6BC97D0F90391DA9B0FA2E10@AM6PR05MB5224.eurprd05.prod.outlook.com>
> -----Original Message-----
> From: Vadim Pasternak
> Sent: Sunday, June 23, 2019 7:01 PM
> To: Andrew Lunn <andrew@lunn.ch>; Ido Schimmel <idosch@idosch.org>
> Cc: netdev@vger.kernel.org; davem@davemloft.net; Jiri Pirko
> <jiri@mellanox.com>; mlxsw <mlxsw@mellanox.com>; Ido Schimmel
> <idosch@mellanox.com>
> Subject: RE: [PATCH net-next 3/3] mlxsw: core: Add support for negative
> temperature readout
>
>
>
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: Sunday, June 23, 2019 6:44 PM
> > To: Ido Schimmel <idosch@idosch.org>
> > Cc: netdev@vger.kernel.org; davem@davemloft.net; Jiri Pirko
> > <jiri@mellanox.com>; mlxsw <mlxsw@mellanox.com>; Vadim Pasternak
> > <vadimp@mellanox.com>; Ido Schimmel <idosch@mellanox.com>
> > Subject: Re: [PATCH net-next 3/3] mlxsw: core: Add support for
> > negative temperature readout
> >
> > > --- a/drivers/net/ethernet/mellanox/mlxsw/core_hwmon.c
> > > +++ b/drivers/net/ethernet/mellanox/mlxsw/core_hwmon.c
> > > @@ -52,8 +52,7 @@ static ssize_t mlxsw_hwmon_temp_show(struct device
> > *dev,
> > > container_of(attr, struct mlxsw_hwmon_attr,
> > dev_attr);
> > > struct mlxsw_hwmon *mlxsw_hwmon = mlwsw_hwmon_attr->hwmon;
> > > char mtmp_pl[MLXSW_REG_MTMP_LEN];
> > > - unsigned int temp;
> > > - int index;
> > > + int temp, index;
> > > int err;
> > >
> > > index = mlxsw_hwmon_get_attr_index(mlwsw_hwmon_attr-
> > >type_index,
> > > @@ -65,7 +64,7 @@ static ssize_t mlxsw_hwmon_temp_show(struct device
> > *dev,
> > > return err;
> > > }
> > > mlxsw_reg_mtmp_unpack(mtmp_pl, &temp, NULL, NULL);
> > > - return sprintf(buf, "%u\n", temp);
> > > + return sprintf(buf, "%d\n", temp);
> > > }
> >
> > If you had used the hwmon core, rather than implementing it yourself,
> > you could of avoided this part of the bug.
> >
>
> Hi Andrew.
>
> Yes.
> But before we handle only positive temperature.
> And currently support for the negative readouts has been added.
>
> > > static ssize_t mlxsw_hwmon_temp_rst_store(struct device *dev, @@
> > > -215,8 +213,8 @@ static ssize_t mlxsw_hwmon_module_temp_show(struct
> > device *dev,
> > > container_of(attr, struct mlxsw_hwmon_attr,
> > dev_attr);
> > > struct mlxsw_hwmon *mlxsw_hwmon = mlwsw_hwmon_attr->hwmon;
> > > char mtmp_pl[MLXSW_REG_MTMP_LEN];
> > > - unsigned int temp;
> > > u8 module;
> > > + int temp;
> > > int err;
> > >
> > > module = mlwsw_hwmon_attr->type_index - mlxsw_hwmon-
> sensor_count;
> >
> > I think you missed changing the %u to %d in this function.
>
> If I am not wrong, I think you refer to mlxsw_hwmon_fan_rpm_show(), where it
> should be %u.
>
O, I see what you mentioned.
This is mlxsw_hwmon_module_temp_show().
Yes, right it should be %d.
Thank you.
> >
> > > @@ -519,14 +519,14 @@ static int
> > > mlxsw_thermal_module_temp_get(struct
> > thermal_zone_device *tzdev,
> > > return 0;
> > > }
> > > mlxsw_reg_mtmp_unpack(mtmp_pl, &temp, NULL, NULL);
> > > - *p_temp = (int) temp;
> > > + *p_temp = temp;
> > >
> > > if (!temp)
> > > return 0;
> > >
> > > /* Update trip points. */
> > > err = mlxsw_thermal_module_trips_update(dev, thermal->core, tz);
> > > - if (!err)
> > > + if (!err && temp > 0)
> > > mlxsw_thermal_tz_score_update(thermal, tzdev, tz->trips,
> > temp);
> >
> > Why the > 0?
>
> We don't consider negative temperature for thermal control.
>
> >
> > Andrew
^ permalink raw reply
* RE: [PATCH net-next 3/3] mlxsw: core: Add support for negative temperature readout
From: Vadim Pasternak @ 2019-06-23 16:00 UTC (permalink / raw)
To: Andrew Lunn, Ido Schimmel
Cc: netdev@vger.kernel.org, davem@davemloft.net, Jiri Pirko, mlxsw,
Ido Schimmel
In-Reply-To: <20190623154407.GE28942@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Sunday, June 23, 2019 6:44 PM
> To: Ido Schimmel <idosch@idosch.org>
> Cc: netdev@vger.kernel.org; davem@davemloft.net; Jiri Pirko
> <jiri@mellanox.com>; mlxsw <mlxsw@mellanox.com>; Vadim Pasternak
> <vadimp@mellanox.com>; Ido Schimmel <idosch@mellanox.com>
> Subject: Re: [PATCH net-next 3/3] mlxsw: core: Add support for negative
> temperature readout
>
> > --- a/drivers/net/ethernet/mellanox/mlxsw/core_hwmon.c
> > +++ b/drivers/net/ethernet/mellanox/mlxsw/core_hwmon.c
> > @@ -52,8 +52,7 @@ static ssize_t mlxsw_hwmon_temp_show(struct device
> *dev,
> > container_of(attr, struct mlxsw_hwmon_attr,
> dev_attr);
> > struct mlxsw_hwmon *mlxsw_hwmon = mlwsw_hwmon_attr->hwmon;
> > char mtmp_pl[MLXSW_REG_MTMP_LEN];
> > - unsigned int temp;
> > - int index;
> > + int temp, index;
> > int err;
> >
> > index = mlxsw_hwmon_get_attr_index(mlwsw_hwmon_attr-
> >type_index,
> > @@ -65,7 +64,7 @@ static ssize_t mlxsw_hwmon_temp_show(struct device
> *dev,
> > return err;
> > }
> > mlxsw_reg_mtmp_unpack(mtmp_pl, &temp, NULL, NULL);
> > - return sprintf(buf, "%u\n", temp);
> > + return sprintf(buf, "%d\n", temp);
> > }
>
> If you had used the hwmon core, rather than implementing it yourself, you could
> of avoided this part of the bug.
>
Hi Andrew.
Yes.
But before we handle only positive temperature.
And currently support for the negative readouts has been added.
> > static ssize_t mlxsw_hwmon_temp_rst_store(struct device *dev, @@
> > -215,8 +213,8 @@ static ssize_t mlxsw_hwmon_module_temp_show(struct
> device *dev,
> > container_of(attr, struct mlxsw_hwmon_attr,
> dev_attr);
> > struct mlxsw_hwmon *mlxsw_hwmon = mlwsw_hwmon_attr->hwmon;
> > char mtmp_pl[MLXSW_REG_MTMP_LEN];
> > - unsigned int temp;
> > u8 module;
> > + int temp;
> > int err;
> >
> > module = mlwsw_hwmon_attr->type_index - mlxsw_hwmon-
> >sensor_count;
>
> I think you missed changing the %u to %d in this function.
If I am not wrong, I think you refer to mlxsw_hwmon_fan_rpm_show(),
where it should be %u.
>
> > @@ -519,14 +519,14 @@ static int mlxsw_thermal_module_temp_get(struct
> thermal_zone_device *tzdev,
> > return 0;
> > }
> > mlxsw_reg_mtmp_unpack(mtmp_pl, &temp, NULL, NULL);
> > - *p_temp = (int) temp;
> > + *p_temp = temp;
> >
> > if (!temp)
> > return 0;
> >
> > /* Update trip points. */
> > err = mlxsw_thermal_module_trips_update(dev, thermal->core, tz);
> > - if (!err)
> > + if (!err && temp > 0)
> > mlxsw_thermal_tz_score_update(thermal, tzdev, tz->trips,
> temp);
>
> Why the > 0?
We don't consider negative temperature for thermal control.
>
> Andrew
^ permalink raw reply
* Re: [PATCH net-next 3/3] mlxsw: core: Add support for negative temperature readout
From: Andrew Lunn @ 2019-06-23 15:44 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, davem, jiri, mlxsw, Vadim Pasternak, Ido Schimmel
In-Reply-To: <20190623125645.2663-4-idosch@idosch.org>
> --- a/drivers/net/ethernet/mellanox/mlxsw/core_hwmon.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/core_hwmon.c
> @@ -52,8 +52,7 @@ static ssize_t mlxsw_hwmon_temp_show(struct device *dev,
> container_of(attr, struct mlxsw_hwmon_attr, dev_attr);
> struct mlxsw_hwmon *mlxsw_hwmon = mlwsw_hwmon_attr->hwmon;
> char mtmp_pl[MLXSW_REG_MTMP_LEN];
> - unsigned int temp;
> - int index;
> + int temp, index;
> int err;
>
> index = mlxsw_hwmon_get_attr_index(mlwsw_hwmon_attr->type_index,
> @@ -65,7 +64,7 @@ static ssize_t mlxsw_hwmon_temp_show(struct device *dev,
> return err;
> }
> mlxsw_reg_mtmp_unpack(mtmp_pl, &temp, NULL, NULL);
> - return sprintf(buf, "%u\n", temp);
> + return sprintf(buf, "%d\n", temp);
> }
If you had used the hwmon core, rather than implementing it yourself,
you could of avoided this part of the bug.
> static ssize_t mlxsw_hwmon_temp_rst_store(struct device *dev,
> @@ -215,8 +213,8 @@ static ssize_t mlxsw_hwmon_module_temp_show(struct device *dev,
> container_of(attr, struct mlxsw_hwmon_attr, dev_attr);
> struct mlxsw_hwmon *mlxsw_hwmon = mlwsw_hwmon_attr->hwmon;
> char mtmp_pl[MLXSW_REG_MTMP_LEN];
> - unsigned int temp;
> u8 module;
> + int temp;
> int err;
>
> module = mlwsw_hwmon_attr->type_index - mlxsw_hwmon->sensor_count;
I think you missed changing the %u to %d in this function.
> @@ -519,14 +519,14 @@ static int mlxsw_thermal_module_temp_get(struct thermal_zone_device *tzdev,
> return 0;
> }
> mlxsw_reg_mtmp_unpack(mtmp_pl, &temp, NULL, NULL);
> - *p_temp = (int) temp;
> + *p_temp = temp;
>
> if (!temp)
> return 0;
>
> /* Update trip points. */
> err = mlxsw_thermal_module_trips_update(dev, thermal->core, tz);
> - if (!err)
> + if (!err && temp > 0)
> mlxsw_thermal_tz_score_update(thermal, tzdev, tz->trips, temp);
Why the > 0?
Andrew
^ permalink raw reply
* Re: [PATCH V1 net-next] net: ena: Fix bug where ring allocation backoff stopped too late
From: David Miller @ 2019-06-23 15:39 UTC (permalink / raw)
To: sameehj
Cc: netdev, dwmw, zorik, matua, saeedb, msw, aliguori, nafea, gtzalik,
netanel, alisaidi, benh, akiyano
In-Reply-To: <20190623071110.18687-1-sameehj@amazon.com>
From: <sameehj@amazon.com>
Date: Sun, 23 Jun 2019 10:11:10 +0300
> From: Sameeh Jubran <sameehj@amazon.com>
>
> The current code of create_queues_with_size_backoff() allows the ring size
> to become as small as ENA_MIN_RING_SIZE/2. This is a bug since we don't
> want the queue ring to be smaller than ENA_MIN_RING_SIZE
>
> In this commit we change the loop's termination condition to look at the
> queue size of the next iteration instead of that of the current one,
> so that the minimal queue size again becomes ENA_MIN_RING_SIZE.
>
> Fixes: eece4d2ab9d2 ("net: ena: add ethtool function for changing io queue sizes")
>
> Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
> Signed-off-by: Sameeh Jubran <sameehj@amazon.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] sis900: increment revision number
From: David Miller @ 2019-06-23 15:37 UTC (permalink / raw)
To: venza; +Cc: joe, sergej.benilov, netdev
In-Reply-To: <7038d64e-0d3c-6b13-04fd-b614efbf5162@brownhat.org>
From: Daniele Venzano <venza@brownhat.org>
Date: Sun, 23 Jun 2019 11:13:28 +0200
> Hello,
>
> I think it is good to know just by looking at the sources that the
> driver is still kept up-to-date, so I am in favor of this patch.
I absolutely, strongly, disagree.
These are pointless.
^ 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