Re: [PATCH V5 4/7] sparc/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT
From: Anshuman Khandual Date: Tue, 12 Apr 2022 10:08:45 +0530 > This defines and exports a platform specific custom vm_get_page_prot() via > subscribing ARCH_HAS_VM_GET_PAGE_PROT. It localizes arch_vm_get_page_prot() > as sparc_vm_get_page_prot() and moves near vm_get_page_prot(). > > Cc: "David S. Miller" > Cc: Khalid Aziz > Cc: sparcli...@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Reviewed-by: Khalid Aziz > Signed-off-by: Anshuman Khandual Acked-by: David S. Miller
Re: [PATCH] ibmvnic: remove default label from to_string switch
From: Lijun Pan Date: Mon, 3 May 2021 13:21:00 -0500 > On Mon, May 3, 2021 at 5:54 AM Michal Suchanek wrote: >> >> This way the compiler warns when a new value is added to the enum but >> not the string transation like: > > s/transation/translation/ > > This trick works. > Since the original code does not generate gcc warnings/errors, should > this patch be sent to net-next as an improvement? Yes.
Re: [PATCH v2] net: ethernet: fs_enet: Add missing MODULE_LICENSE
From: Michael Ellerman
Date: Tue, 5 Jan 2021 20:15:15 +1100
> Since commit 1d6cd3929360 ("modpost: turn missing MODULE_LICENSE()
> into error") the ppc32_allmodconfig build fails with:
>
> ERROR: modpost: missing MODULE_LICENSE() in
> drivers/net/ethernet/freescale/fs_enet/mii-fec.o
> ERROR: modpost: missing MODULE_LICENSE() in
> drivers/net/ethernet/freescale/fs_enet/mii-bitbang.o
>
> Add the missing MODULE_LICENSEs to fix the build. Both files include a
> copyright header indicating they are GPL v2.
>
> Signed-off-by: Michael Ellerman
Applied.
Re: [PATCH net v3 0/2] ibmvnic: Bug fixes for queue descriptor processing
From: Thomas Falcon Date: Tue, 1 Dec 2020 09:52:09 -0600 > This series resolves a few issues in the ibmvnic driver's > RX buffer and TX completion processing. The first patch > includes memory barriers to synchronize queue descriptor > reads. The second patch fixes a memory leak that could > occur if the device returns a TX completion with an error > code in the descriptor, in which case the respective socket > buffer and other relevant data structures may not be freed > or updated properly. > > v3: Correct length of Fixes tags, requested by Jakub Kicinski > > v2: Provide more detailed comments explaining specifically what > reads are being ordered, suggested by Michael Ellerman Series applied, thanks!
Re: [PATCH v4 net-next 0/2] Add Seville Ethernet switch to T1040RDB
From: Vladimir Oltean Date: Fri, 2 Oct 2020 16:41:04 +0300 > Seville is a DSA switch that is embedded inside the T1040 SoC, and > supported by the mscc_seville DSA driver inside drivers/net/dsa/ocelot. > > This series adds this switch to the SoC's dtsi files and to the T1040RDB > board file. > > I would like to send this series through net-next. There is no conflict > with other patches submitted to T1040 device tree. Maybe this could at > least get an ACK from devicetree maintainers. Series applied, thank you.
Re: [PATCH v3 devicetree 0/2] Add Seville Ethernet switch to T1040RDB
From: Vladimir Oltean Date: Thu, 1 Oct 2020 16:20:11 +0300 > Seville is a DSA switch that is embedded inside the T1040 SoC, and > supported by the mscc_seville DSA driver inside drivers/net/dsa/ocelot. > > This series adds this switch to the SoC's dtsi files and to the T1040RDB > board file. I am assuming the devicetree folks will pick this series up. Thanks.
Re: [PATCH -next] ide: Fix symbol undeclared warnings
From: Michael Ellerman Date: Thu, 17 Sep 2020 22:01:00 +1000 > Wang Wensheng writes: >> Build the object file with `C=2` and get the following warnings: >> make allmodconfig ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- >> make C=2 drivers/ide/pmac.o ARCH=powerpc64 >> CROSS_COMPILE=powerpc64-linux-gnu- >> >> drivers/ide/pmac.c:228:23: warning: symbol 'mdma_timings_33' was not >> declared. Should it be static? >> drivers/ide/pmac.c:241:23: warning: symbol 'mdma_timings_33k' was not >> declared. Should it be static? >> drivers/ide/pmac.c:254:23: warning: symbol 'mdma_timings_66' was not >> declared. Should it be static? >> drivers/ide/pmac.c:272:3: warning: symbol 'kl66_udma_timings' was not >> declared. Should it be static? >> drivers/ide/pmac.c:1418:12: warning: symbol 'pmac_ide_probe' was not >> declared. Should it be static? >> >> Signed-off-by: Wang Wensheng >> --- >> drivers/ide/pmac.c | 10 +- >> 1 file changed, 5 insertions(+), 5 deletions(-) > > TIL davem maintains IDE? > > But I suspect he isn't that interested in this powerpc only driver, so > I'll grab this. I did have it in my queue, but if you want to take it that's fine too :)
Re: [PATCH net] ibmvnic: update MAINTAINERS
From: Dany Madden Date: Mon, 14 Sep 2020 20:35:35 -0400 > Update supporters for IBM Power SRIOV Virtual NIC Device Driver. > Thomas Falcon is moving on to other works. Dany Madden, Lijun Pan > and Sukadev Bhattiprolu are the current supporters. > > Signed-off-by: Dany Madden Applied.
Re: [PATCH v2 3/4] sparc64: remove mm_cpumask clearing to fix kthread_use_mm race
From: Nicholas Piggin Date: Tue, 15 Sep 2020 13:24:07 +1000 > Excerpts from David Miller's message of September 15, 2020 5:59 am: >> From: Nicholas Piggin >> Date: Mon, 14 Sep 2020 14:52:18 +1000 >> >> ... >>> The basic fix for sparc64 is to remove its mm_cpumask clearing code. The >>> optimisation could be effectively restored by sending IPIs to mm_cpumask >>> members and having them remove themselves from mm_cpumask. This is more >>> tricky so I leave it as an exercise for someone with a sparc64 SMP. >>> powerpc has a (currently similarly broken) example. >>> >>> Signed-off-by: Nicholas Piggin >> >> Sad to see this optimization go away, but what can I do: >> >> Acked-by: David S. Miller >> > > Thanks Dave, any objection if we merge this via the powerpc tree > to keep the commits together? No objection.
Re: [PATCH v2 3/4] sparc64: remove mm_cpumask clearing to fix kthread_use_mm race
From: Nicholas Piggin Date: Mon, 14 Sep 2020 14:52:18 +1000 ... > The basic fix for sparc64 is to remove its mm_cpumask clearing code. The > optimisation could be effectively restored by sending IPIs to mm_cpumask > members and having them remove themselves from mm_cpumask. This is more > tricky so I leave it as an exercise for someone with a sparc64 SMP. > powerpc has a (currently similarly broken) example. > > Signed-off-by: Nicholas Piggin Sad to see this optimization go away, but what can I do: Acked-by: David S. Miller
Re: [PATCH net-next] net/wan/fsl_ucc_hdlc: Add MODULE_DESCRIPTION
From: YueHaibing Date: Sat, 29 Aug 2020 19:58:23 +0800 > Add missing MODULE_DESCRIPTION. > > Signed-off-by: YueHaibing Applied.
Re: [PATCH net v3] ibmvnic fix NULL tx_pools and rx_tools issue at do_reset
From: Dany Madden
Date: Tue, 25 Aug 2020 13:26:41 -0400
> From: Mingming Cao
>
> At the time of do_rest, ibmvnic tries to re-initalize the tx_pools
> and rx_pools to avoid re-allocating the long term buffer. However
> there is a window inside do_reset that the tx_pools and
> rx_pools were freed before re-initialized making it possible to deference
> null pointers.
>
> This patch fix this issue by always check the tx_pool
> and rx_pool are not NULL after ibmvnic_login. If so, re-allocating
> the pools. This will avoid getting into calling reset_tx/rx_pools with
> NULL adapter tx_pools/rx_pools pointer. Also add null pointer check in
> reset_tx_pools and reset_rx_pools to safe handle NULL pointer case.
>
> Signed-off-by: Mingming Cao
> Signed-off-by: Dany Madden
Applied, but:
> + if (!adapter->rx_pool)
> + return -1;
> +
This driver has poor error code usage, it's a random mix of hypervisor
error codes, normal error codes like -EINVAL, and internal error codes.
Sometimes used all in the same function.
For example:
static int ibmvnic_send_crq(struct ibmvnic_adapter *adapter,
union ibmvnic_crq *crq)
...
if (!adapter->crq.active &&
crq->generic.first != IBMVNIC_CRQ_INIT_CMD) {
dev_warn(dev, "Invalid request detected while CRQ is inactive,
possible device state change during reset\n");
return -EINVAL;
}
...
rc = plpar_hcall_norets(H_SEND_CRQ, ua,
cpu_to_be64(u64_crq[0]),
cpu_to_be64(u64_crq[1]));
if (rc) {
if (rc == H_CLOSED) {
...
return rc;
So obviously this function returns a mix of negative erro codes
and Hypervisor codes such as H_CLOSED.
And stuff like:
rc = __ibmvnic_open(netdev);
if (rc)
return IBMVNIC_OPEN_FAILED;
Re: [PATCH net v2] ibmvnic fix NULL tx_pools and rx_tools issue at do_reset
From: Dany Madden
Date: Tue, 25 Aug 2020 12:56:06 -0400
> @@ -2011,7 +2017,10 @@ static int do_reset(struct ibmvnic_adapter *adapter,
> adapter->req_rx_add_entries_per_subcrq !=
> old_num_rx_slots ||
> adapter->req_tx_entries_per_subcrq !=
> - old_num_tx_slots) {
> + old_num_tx_slots ||
> + !adapter->rx_pool ||
> + !adapter->tso_pool ||
> + !adapter->tx_pool) {
Please don't over indent these new lines, indent them identically as the
lines above where you are adding new conditions.
Thank you.
Re: [PATCH 17/29] fs_enet: Avoid comma separated statements
From: Joe Perches Date: Mon, 24 Aug 2020 21:56:14 -0700 > Use semicolons and braces. > > Signed-off-by: Joe Perches Applied.
Re: [PATCH net-next v2 0/4] refactoring of ibmvnic code
From: Lijun Pan Date: Wed, 19 Aug 2020 17:52:22 -0500 > This patch series refactor reset_init and init functions, > and make some other cosmetic changes to make the code > easier to read and debug. v2 removes __func__ and v1's 1/5. Series applied, thank you.
Re: [PATCH net-next 3/5] ibmvnic: improve ibmvnic_init and ibmvnic_reset_init
From: Lijun Pan
Date: Wed, 19 Aug 2020 00:35:10 -0500
> + if (rc) {
> + dev_err(dev, "%s: Send crq init failed with error %d\n",
> __func__, rc);
> + return rc;
Consistent with my feedback on patch #1, please get rid of this __func__ stuff.
Thank you.
Re: [PATCH net-next 1/5] ibmvnic: print caller in several error messages
From: Lijun Pan Date: Wed, 19 Aug 2020 00:35:08 -0500 > The error messages in the changed functions are exactly the same. > In order to differentiate them and make debugging easier, > we print the function names in the error messages. > > Signed-off-by: Lijun Pan I don't see any value in emitting function names in kernel error log messages. Sorry.
Re: [PATCH net 0/5] refactoring of ibmvnic code
From: Lijun Pan Date: Fri, 14 Aug 2020 02:59:16 -0500 > This patch series refactor reset_init and init functions, > improve the debugging messages, and make some other cosmetic changes > to make the code easier to read and debug. Cosmetic changes and cleanups are not appropriate at this time as the net-next tree is closed. Please repost these changes when the net-next tree opens back up.
Re: [PATCH net] ibmvnic: Fix IRQ mapping disposal in error path
From: Thomas Falcon Date: Wed, 29 Jul 2020 16:36:32 -0500 > RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ > error paths. Fix this and dispose of TX IRQ mappings correctly in > case of an error. > > Signed-off-by: Thomas Falcon Applied with Fixes: tag added and queued up for -stable.
Re: [PATCH net-next] net: fs_enet: remove redundant null check
From: Zhang Changzhong Date: Mon, 20 Jul 2020 19:12:33 +0800 > Because clk_prepare_enable and clk_disable_unprepare already > checked NULL clock parameter, so the additional checks are > unnecessary, just remove them. > > Signed-off-by: Zhang Changzhong Applied.
Re: [PATCH net-next] ibmvnic: Increase driver logging
From: Jakub Kicinski Date: Wed, 15 Jul 2020 17:06:32 -0700 > On Wed, 15 Jul 2020 18:51:55 -0500 Thomas Falcon wrote: >> free_netdev(netdev); >> dev_set_drvdata(>dev, NULL); >> +netdev_info(netdev, "VNIC client device has been successfully >> removed.\n"); > > A step too far, perhaps. > > In general this patch looks a little questionable IMHO, this amount of > logging output is not commonly seen in drivers. All the the info > messages are just static text, not even carrying any extra information. > In an era of ftrace, and bpftrace, do we really need this? Agreed, this is too much. This is debugging, and thus suitable for tracing facilities, at best.
Re: [PATCH v4 3/8] sparc64: Fix asm/percpu.h build error
From: Peter Zijlstra Date: Tue, 23 Jun 2020 10:36:48 +0200 > In order to break a header dependency between lockdep and task_struct, > I need per-cpu stuff from lockdep. > > Signed-off-by: Peter Zijlstra (Intel) Acked-by: David S. Miller
Re: [PATCH net] ibmvnic: continue to init in CRQ reset returns H_CLOSED
From: Dany Madden Date: Thu, 18 Jun 2020 15:24:13 -0400 > Continue the reset path when partner adapter is not ready or H_CLOSED is > returned from reset crq. This patch allows the CRQ init to proceed to > establish a valid CRQ for traffic to flow after reset. > > Signed-off-by: Dany Madden Applied, thanks.
Re: [PATCH net] ibmveth: Fix max MTU limit
From: Thomas Falcon Date: Thu, 18 Jun 2020 10:43:46 -0500 > The max MTU limit defined for ibmveth is not accounting for > virtual ethernet buffer overhead, which is twenty-two additional > bytes set aside for the ethernet header and eight additional bytes > of an opaque handle reserved for use by the hypervisor. Update the > max MTU to reflect this overhead. > > Signed-off-by: Thomas Falcon Applied with Fixes: tags added and queued up for -stable. Thank you.
Re: [PATCH net v2] ibmvnic: Harden device login requests
From: Thomas Falcon Date: Mon, 15 Jun 2020 10:29:23 -0500 > The VNIC driver's "login" command sequence is the final step > in the driver's initialization process with device firmware, > confirming the available device queue resources to be utilized > by the driver. Under high system load, firmware may not respond > to the request in a timely manner or may abort the request. In > such cases, the driver should reattempt the login command > sequence. In case of a device error, the number of retries > is bounded. > > Signed-off-by: Thomas Falcon > --- > v2: declare variables in Reverse Christmas tree format Applied, thanks.
Re: [PATCH net] ibmvnic: Flush existing work items before device removal
From: Thomas Falcon Date: Fri, 12 Jun 2020 13:34:41 -0500 > Ensure that all scheduled work items have completed before continuing > with device removal and after further event scheduling has been > halted. This patch fixes a bug where a scheduled driver reset event > is processed following device removal. > > Signed-off-by: Thomas Falcon Applied, thank you.
Re: [PATCH net] ibmvnic: Harden device login requests
From: Thomas Falcon
Date: Fri, 12 Jun 2020 13:31:39 -0500
> @@ -841,13 +841,14 @@ static int ibmvnic_login(struct net_device *netdev)
> {
> struct ibmvnic_adapter *adapter = netdev_priv(netdev);
> unsigned long timeout = msecs_to_jiffies(3);
> + int retries = 10;
> int retry_count = 0;
> bool retry;
> int rc;
Reverse christmas tree, please.
Re: [PATCH] net: ethernet: freescale: remove unneeded include for ucc_geth
From: Valentin Longchamp Date: Wed, 3 Jun 2020 23:28:23 +0200 > net/sch_generic.h does not need to be included, remove it. > > Signed-off-by: Valentin Longchamp Applied.
Re: [PATCH net] drivers/net/ibmvnic: Update VNIC protocol version reporting
From: Thomas Falcon Date: Thu, 28 May 2020 11:19:17 -0500 > VNIC protocol version is reported in big-endian format, but it > is not byteswapped before logging. Fix that, and remove version > comparison as only one protocol version exists at this time. > > Signed-off-by: Thomas Falcon Applied, thanks.
Re: [RFC][PATCH v3 1/5] sparc64: Fix asm/percpu.h build error
From: Peter Zijlstra
Date: Fri, 29 May 2020 23:35:51 +0200
> ../arch/sparc/include/asm/percpu_64.h:7:24: warning: call-clobbered register
> used for global register variable
> register unsigned long __local_per_cpu_offset asm("g5");
The "-ffixed-g5" option on the command line tells gcc that we are
using 'g5' as a fixed register, so some part of your build isn't using
the:
KBUILD_CFLAGS += -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare
from arch/sparc/Makefile for some reason.
Re: [PATCH] net/ethernet/freescale: rework quiesce/activate for ucc_geth
From: Valentin Longchamp Date: Wed, 20 May 2020 17:53:50 +0200 > ugeth_quiesce/activate are used to halt the controller when there is a > link change that requires to reconfigure the mac. > > The previous implementation called netif_device_detach(). This however > causes the initial activation of the netdevice to fail precisely because > it's detached. For details, see [1]. > > A possible workaround was the revert of commit > net: linkwatch: add check for netdevice being present to linkwatch_do_dev > However, the check introduced in the above commit is correct and shall be > kept. > > The netif_device_detach() is thus replaced with > netif_tx_stop_all_queues() that prevents any tranmission. This allows to > perform mac config change required by the link change, without detaching > the corresponding netdevice and thus not preventing its initial > activation. > > [1] https://lists.openwall.net/netdev/2020/01/08/201 > > Signed-off-by: Valentin Longchamp > Acked-by: Matteo Ghidoni Applied, thanks.
Re: [PATCH net] ibmvnic: Skip fatal error reset after passive init
From: Juliet Kim Date: Thu, 30 Apr 2020 13:22:11 -0500 > During MTU change, the following events may happen. > Client-driven CRQ initialization fails due to partner’s CRQ closed, > causing client to enqueue a reset task for FATAL_ERROR. Then passive > (server-driven) CRQ initialization succeeds, causing client to > release CRQ and enqueue a reset task for failover. If the passive > CRQ initialization occurs before the FATAL reset task is processed, > the FATAL error reset task would try to access a CRQ message queue > that was freed, causing an oops. The problem may be most likely to > occur during DLPAR add vNIC with a non-default MTU, because the DLPAR > process will automatically issue a change MTU request. > > Fix this by not processing fatal error reset if CRQ is passively > initialized after client-driven CRQ initialization fails. > > Signed-off-by: Juliet Kim Applied, thanks.
Re: [PATCH 00/37] net: manually convert files to ReST format - part 2
From: Mauro Carvalho Chehab Date: Thu, 30 Apr 2020 18:03:55 +0200 > That's the second part of my work to convert the networking > text files into ReST. it is based on today's linux-next (next-20200430). > > The full series (including those ones) are at: > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=net-docs > > I should be sending the remaining patches (another /38 series) > after getting those merged at -next. > > The documents, converted to HTML via the building system are at: > > https://www.infradead.org/~mchehab/kernel_docs/networking/ Series applied to net-next, thank you.
Re: [PATCH net v2] ibmvnic: Do not process device remove during device reset
From: Juliet Kim Date: Tue, 10 Mar 2020 09:23:58 -0500 > The ibmvnic driver does not check the device state when the device > is removed. If the device is removed while a device reset is being > processed, the remove may free structures needed by the reset, > causing an oops. > > Fix this by checking the device state before processing device remove. > > Signed-off-by: Juliet Kim Applied, thank you.
Re: [PATCH net] ibmvnic: Do not process device remove during device reset
From: Juliet Kim Date: Mon, 9 Mar 2020 19:02:04 -0500 > diff --git a/drivers/net/ethernet/ibm/ibmvnic.c > b/drivers/net/ethernet/ibm/ibmvnic.c > index c75239d8820f..7ef1ae0d49bc 100644 > --- a/drivers/net/ethernet/ibm/ibmvnic.c > +++ b/drivers/net/ethernet/ibm/ibmvnic.c > @@ -2144,6 +2144,8 @@ static void __ibmvnic_reset(struct work_struct *work) > struct ibmvnic_adapter *adapter; > u32 reset_state; > int rc = 0; > + unsigned long flags; > + bool saved_state = false; Please preserve the reverse christmas tree ordering of local variables. Thank you.
Re: [PATCH net-next 00/23] Clean driver, module and FW versions
From: Leon Romanovsky
Date: Sun, 1 Mar 2020 16:44:33 +0200
> From: Leon Romanovsky
>
> Hi,
>
> This is second batch of the series which removes various static versions
> in favour of globaly defined Linux kernel version.
>
> The first part with better cover letter can be found here
> https://lore.kernel.org/lkml/20200224085311.460338-1-l...@kernel.org
>
> The code is based on
> 68e2c37690b0 ("Merge branch 'hsr-several-code-cleanup-for-hsr-module'")
>
> and WIP branch is
> https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=ethtool
Series applied, thanks.
Re: [PATCH net-next 00/23] Clean driver, module and FW versions
From: Leon Romanovsky Date: Sun, 1 Mar 2020 16:44:33 +0200 > This is second batch of the series which removes various static versions > in favour of globaly defined Linux kernel version. This generally looks fine to me but I'll let it sit for a few days so that others can review.
Re: [PATCH][next] toshiba: Replace zero-length array with flexible-array member
From: "Gustavo A. R. Silva"
Date: Mon, 24 Feb 2020 10:32:52 -0600
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertently introduced[3] to the codebase from now on.
>
> Also, notice that, dynamic memory allocations won't be affected by
> this change:
>
> "Flexible array members have incomplete type, and so the sizeof operator
> may not be applied. As a quirk of the original implementation of
> zero-length arrays, sizeof evaluates to zero."[1]
>
> This issue was found with the help of Coccinelle.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
>
> Signed-off-by: Gustavo A. R. Silva
Applied.
Re: [PATCH v2 net-next] net: convert suitable drivers to use phy_do_ioctl_running
From: Heiner Kallweit Date: Tue, 21 Jan 2020 22:09:33 +0100 > Convert suitable drivers to use new helper phy_do_ioctl_running. > > Signed-off-by: Heiner Kallweit > --- > v2: I forgot the netdev mailing list Applied to net-next.
Re: [PATCH] ide: remove set but not used variable 'hwif'
From: Wang Hai
Date: Sat, 26 Oct 2019 09:57:38 +0800
> Fix the following gcc warning:
>
> drivers/ide/pmac.c: In function pmac_ide_setup_device:
> drivers/ide/pmac.c:1027:14: warning: variable hwif set but not used
> [-Wunused-but-set-variable]
>
> Fixes: d58b0c39e32f ("powerpc/macio: Rework hotplug media bay support")
> Reported-by: Hulk Robot
> Signed-off-by: Wang Hai
Applied.
Re: [PATCH] net/wan/fsl_ucc_hdlc: fix out of bounds write on array utdm_info
From: Colin King
Date: Tue, 14 Jan 2020 14:54:48 +
> From: Colin Ian King
>
> Array utdm_info is declared as an array of MAX_HDLC_NUM (4) elements
> however up to UCC_MAX_NUM (8) elements are potentially being written
> to it. Currently we have an array out-of-bounds write error on the
> last 4 elements. Fix this by making utdm_info UCC_MAX_NUM elements in
> size.
>
> Addresses-Coverity: ("Out-of-bounds write")
> Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
> Signed-off-by: Colin Ian King
Applied and queued up for -stable.
Re: [PATCH v6 00/49] QUICC Engine support on ARM, ARM64, PPC64
From: Li Yang Date: Mon, 2 Dec 2019 16:56:39 -0600 > On Mon, Dec 2, 2019 at 2:14 AM Rasmus Villemoes > wrote: >> >> On 01/12/2019 17.10, Timur Tabi wrote: >> > On 11/28/19 8:55 AM, Rasmus Villemoes wrote: >> >> There have been several attempts in the past few years to allow >> >> building the QUICC engine drivers for platforms other than PPC32. This >> >> is yet another attempt. >> >> >> >> v5 can be found >> >> here:https://lore.kernel.org/lkml/20191118112324.22725-1-li...@rasmusvillemoes.dk/ >> >> >> > >> > If it helps: >> > >> > Entire series: >> > Acked-by: Timur Tabi >> >> Thanks. I'll leave it to Li Yang whether to apply that - they already >> all (except for the last-minute build fix) have your R-b. >> >> Li Yang, any chance you could pick up these patches so they have plenty >> of time in -next until 5.6? > > Sure. I will. I'm waiting for the Ack from David on the networking side. Acked-by: David S. Miller
Re: [PATCH v6 44/49] net/wan/fsl_ucc_hdlc: avoid use of IS_ERR_VALUE()
From: Leo Li Date: Mon, 2 Dec 2019 22:51:57 + > > >> -Original Message- >> From: Rasmus Villemoes >> Sent: Thursday, November 28, 2019 8:56 AM >> To: Qiang Zhao ; Leo Li ; >> Christophe Leroy >> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; >> linux-ker...@vger.kernel.org; Scott Wood ; Timur Tabi >> ; Rasmus Villemoes ; >> net...@vger.kernel.org >> Subject: [PATCH v6 44/49] net/wan/fsl_ucc_hdlc: avoid use of >> IS_ERR_VALUE() > > Hi David, > > Would you help to review patch 44-47 in the series? If it is fine with you, > I can take these 4 patches with the whole series though soc tree to enable > the QE drivers on ARM and PPC64 with your ACK. Please take it via your tree, that's fine.
Re: [PATCH net v2 0/4] ibmvnic: Harden device commands and queries
From: Thomas Falcon Date: Mon, 25 Nov 2019 17:12:52 -0600 > This patch series fixes some shortcomings with the current > VNIC device command implementation. The first patch fixes > the initialization of driver completion structures used > for device commands. Additionally, all waits for device > commands are bounded with a timeout in the event that the > device does not respond or becomes inoperable. Finally, > serialize queries to retain the integrity of device return > codes. > > Changes in v2: > > - included header comment for ibmvnic_wait_for_completion > - removed open-coded loop in patch 3/4, suggested by Jakub > - ibmvnic_wait_for_completion accepts timeout value in milliseconds >instead of jiffies > - timeout calculations cleaned up and completed before wait loop > - included missing mutex_destroy calls, suggested by Jakub > - included comment before mutex declaration Series applied, thanks.
Re: [PATCH] drivers: net: Fix Kconfig indentation, continued
From: Krzysztof Kozlowski Date: Thu, 21 Nov 2019 21:28:28 +0800 > Adjust indentation from spaces to tab (+optional two spaces) as in > coding style. This fixes various indentation mixups (seven spaces, > tab+one space, etc). > > Signed-off-by: Krzysztof Kozlowski Applied to net-next.
Re: [PATCH net/ibmvnic 0/2] Support both XIVE and XICS modes in ibmvnic
From: Juliet Kim Date: Wed, 20 Nov 2019 10:50:02 -0500 > This series aims to support both XICS and XIVE with avoiding > a regression in behavior when a system runs in XICS mode. > > Patch 1 reverts commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab > (“net/ibmvnic: Fix EOI when running in XIVE mode.”) > > Patch 2 Ignore H_FUNCTION return from H_EOI to tolerate XIVE mode Series applied, thanks.
Re: [PATCH] net/ibmvnic: Fix EOI when running in XIVE mode.
From: Cédric Le Goater
Date: Fri, 11 Oct 2019 07:52:54 +0200
> pSeries machines on POWER9 processors can run with the XICS (legacy)
> interrupt mode or with the XIVE exploitation interrupt mode. These
> interrupt contollers have different interfaces for interrupt
> management : XICS uses hcalls and XIVE loads and stores on a page.
> H_EOI being a XICS interface the enable_scrq_irq() routine can fail
> when the machine runs in XIVE mode.
>
> Fix that by calling the EOI handler of the interrupt chip.
>
> Fixes: f23e0643cd0b ("ibmvnic: Clear pending interrupt after device reset")
> Signed-off-by: Cédric Le Goater
Applied and queued up for -stable, thanks.
Re: [PATCH v4 0/2] net/ibmvnic: serialization fixes
From: Juliet Kim Date: Fri, 20 Sep 2019 16:11:21 -0400 > This series includes two fixes. The first improves reset code to allow > linkwatch_event to proceed during reset. The second ensures that no more > than one thread runs in reset at a time. > > v2: > - Separate change param reset from do_reset() > - Return IBMVNIC_OPEN_FAILED if __ibmvnic_open fails > - Remove setting wait_for_reset to false from __ibmvnic_reset(), this > is done in wait_for_reset() > - Move the check for force_reset_recovery from patch 1 to patch 2 > > v3: > - Restore reset’s successful return in open failure case > > v4: > - Change resetting flag access to atomic Series applied, thank you.
Re: [PATCH] net/ibmvnic: Fix missing { in __ibmvnic_reset
From: Michal Suchanek
Date: Mon, 9 Sep 2019 22:44:51 +0200
> Commit 1c2977c09499 ("net/ibmvnic: free reset work of removed device from
> queue")
> adds a } without corresponding { causing build break.
>
> Fixes: 1c2977c09499 ("net/ibmvnic: free reset work of removed device from
> queue")
> Signed-off-by: Michal Suchanek
Applied.
Re: [PATCH] net/ibmvnic: free reset work of removed device from queue
From: Juliet Kim
Date: Thu, 5 Sep 2019 17:30:01 -0400
> Commit 36f1031c51a2 ("ibmvnic: Do not process reset during or after
> device removal") made the change to exit reset if the driver has been
> removed, but does not free reset work items of the adapter from queue.
>
> Ensure all reset work items are freed when breaking out of the loop early.
>
> Fixes: 36f1031c51a2 ("ibmnvic: Do not process reset during or after
> device removal”)
Please do not break up Fixes: tags into mutliple lines, also please do
not put an empty line between the Fixes: tag and other tags like the
Signed-off-by:
> Signed-off-by: Juliet Kim
Applied, thanks.
Re: [PATCH v2 7/9] sparc64: numa: check the node id consistently for sparc64
From: Yunsheng Lin Date: Mon, 2 Sep 2019 14:08:31 +0800 > The NUMA node id in sparc64 system is defined by DT semantics? Sometimes, and in other cases other methods are used to determine the NUMA node id.
Re: [PATCH v2 7/9] sparc64: numa: check the node id consistently for sparc64
From: Yunsheng Lin Date: Sat, 31 Aug 2019 16:57:04 +0800 > Did you mean sparc64 system does not has ACPI, the device's node id will > not specified by ACPI, so the ACPI is unrelated here? Yes, sparc64 never has and never will have ACPI. This is also true for several other platforms where you have made this change. The assumption of your entire patch set is that the semantics of the NUMA node ID are somehow completely defined by ACPI semantics. Which is not true.
Re: [PATCH v2 7/9] sparc64: numa: check the node id consistently for sparc64
From: Yunsheng Lin Date: Sat, 31 Aug 2019 13:58:21 +0800 > According to Section 6.2.14 from ACPI spec 6.3 [1], the setting > of proximity domain is optional, as below: What in the world does the ACPI spec have to do with sparc64 NUMA node ID checking?
Re: [PATCH net] ibmvnic: Do not process reset during or after device removal
From: Thomas Falcon Date: Tue, 27 Aug 2019 11:10:04 -0500 > Currently, the ibmvnic driver will not schedule device resets > if the device is being removed, but does not check the device > state before the reset is actually processed. This leads to a race > where a reset is scheduled with a valid device state but is > processed after the driver has been removed, resulting in an oops. > > Fix this by checking the device state before processing a queued > reset event. > > Reported-by: Abdul Haleem > Tested-by: Abdul Haleem > Signed-off-by: Thomas Falcon Applied.
Re: [PATCH 1/2] net/ibmvnic: unlock rtnl_lock in reset so linkwatch_event can run
From: Juliet Kim
Date: Tue, 20 Aug 2019 17:31:19 -0400
> Commit a5681e20b541 ("net/ibmnvic: Fix deadlock problem in reset")
> made the change to hold the RTNL lock during a reset to avoid deadlock
> but linkwatch_event is fired during the reset and needs the RTNL lock.
> That keeps linkwatch_event process from proceeding until the reset
> is complete. The reset process cannot tolerate the linkwatch_event
> processing after reset completes, so release the RTNL lock during the
> process to allow a chance for linkwatch_event to run during reset.
> This does not guarantee that the linkwatch_event will be processed as
> soon as link state changes, but is an improvement over the current code
> where linkwatch_event processing is always delayed, which prevents
> transmissions on the device from being deactivated leading transmit
> watchdog timer to time-out.
>
> Release the RTNL lock before link state change and re-acquire after
> the link state change to allow linkwatch_event to grab the RTNL lock
> and run during the reset.
>
> Fixes: a5681e20b541 ("net/ibmnvic: Fix deadlock problem in reset")
> Signed-off-by: Juliet Kim
Conditional locking, especialy such extensive use of conditional
locking as is being done here, is strongly discouraged and is always
indicative of bad design.
Please try to rework this change such that the code paths that want
to lock things a certain way are %100 segregated functionally into
different code paths and functions.
Or feel free to find a cleaner way to fix this.
Re: [PATCH net-next v2] ibmveth: Allow users to update reported speed and duplex
From: Jakub Kicinski Date: Tue, 6 Aug 2019 15:15:24 -0700 > On Tue, 6 Aug 2019 11:23:08 -0500, Thomas Falcon wrote: >> Reported ethtool link settings for the ibmveth driver are currently >> hardcoded and no longer reflect the actual capabilities of supported >> hardware. There is no interface designed for retrieving this information >> from device firmware nor is there any way to update current settings >> to reflect observed or expected link speeds. >> >> To avoid breaking existing configurations, retain current values as >> default settings but let users update them to match the expected >> capabilities of underlying hardware if needed. This update would >> allow the use of configurations that rely on certain link speed >> settings, such as LACP. This patch is based on the implementation >> in virtio_net. >> >> Signed-off-by: Thomas Falcon > > Looks like this is the third copy of the same code virtio and > netvsc have :( Is there a chance we could factor this out into > helpers in the core? Yeah, let's stop the duplication of code while we can. Thomas please perform the consolidation and respin. Thank you.
Re: [PATCH net] net/ibmvnic: Report last valid speed and duplex values to ethtool
From: Thomas Falcon Date: Thu, 27 Jun 2019 12:09:13 -0500 > This patch resolves an issue with sensitive bonding modes > that require valid speed and duplex settings to function > properly. Currently, the adapter will report that device > speed and duplex is unknown if the communication link > with firmware is unavailable. This decision can break LACP > configurations if the timing is right. > > For example, if invalid speeds are reported, the slave > device's link state is set to a transitional "fail" state > and the LACP port is disabled. However, if valid speeds > are reported later but the link state has not been altered, > the LACP port will remain disabled. If the link state then > transitions back to "up" from "fail," it results in a state > such that the slave reports valid speed/duplex and is up, > but the LACP port will remain disabled. > > Workaround this by reporting the last recorded speed > and duplex settings unless the device has never been > activated. In that case or when the hypervisor gives > invalid values, continue to report unknown speed or > duplex to ethtool. > > Signed-off-by: Thomas Falcon Like Andrew, I have my conerns about this. If the firmware is unavailable, the link is effectively down. So you should report link down and unknown link parameters. Bonding and LACP should do the right thing when the firwmare is reachable again after the migration and the link goes back up. If bonding/LACP isn't doing that, then the bug is there.
Re: [PATCH] ps3_gelic: Use [] to denote a flexible array member
From: Geert Uytterhoeven Date: Mon, 17 Jun 2019 13:50:44 +0200 > Flexible array members should be denoted using [] instead of [0], else > gcc will not warn when they are no longer at the end of a struct. > > Signed-off-by: Geert Uytterhoeven Applied to net-next, thanks.
Re: [PATCH net 0/3] ibmvnic: Fixes for device reset handling
From: Thomas Falcon Date: Fri, 7 Jun 2019 16:03:52 -0500 > This series contains three unrelated fixes to issues seen during > device resets. The first patch fixes an error when the driver requests > to deactivate the link of an uninitialized device, resulting in a > failure to reset. Next, a patch to fix multicast transmission > failures seen after a driver reset. The final patch fixes mishandling > of memory allocation failures during device initialization, which > caused a kernel oops. Series applied, thanks.
Re: RFC: switch the remaining architectures to use generic GUP v2
From: Christoph Hellwig Date: Sat, 1 Jun 2019 09:49:43 +0200 > below is a series to switch mips, sh and sparc64 to use the generic > GUP code so that we only have one codebase to touch for further > improvements to this code. I don't have hardware for any of these > architectures, and generally no clue about their page table > management, so handle with care. > > Changes since v1: > - fix various issues found by the build bot > - cherry pick and use the untagged_addr helper form Andrey > - add various refactoring patches to share more code over architectures > - move the powerpc hugepd code to mm/gup.c and sync it with the generic >hup semantics I will today look seriously at the sparc64 stuff wrt. tagged pointers.
Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
From: laurentiu.tu...@nxp.com Date: Thu, 30 May 2019 17:19:45 +0300 > Depends on this pull request: > > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/653554.html I'm not sure how you want me to handle this.
Re: [PATCH] net: ucc_geth - fix Oops when changing number of buffers in the ring
From: Christophe Leroy
Date: Fri, 3 May 2019 13:33:23 + (UTC)
> When changing the number of buffers in the RX ring while the interface
> is running, the following Oops is encountered due to the new number
> of buffers being taken into account immediately while their allocation
> is done when opening the device only.
...
> This patch forbids the modification of the number of buffers in the
> ring while the interface is running.
>
> Fixes: ac421852b3a0 ("ucc_geth: add ethtool support")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Christophe Leroy
Applied and queued up for -stable.
Re: [PATCH v3] dpaa_eth: fix SG frame cleanup
From: laurentiu.tu...@nxp.com Date: Fri, 3 May 2019 16:03:11 +0300 > From: Laurentiu Tudor > > Fix issue with the entry indexing in the sg frame cleanup code being > off-by-1. This problem showed up when doing some basic iperf tests and > manifested in traffic coming to a halt. > > Signed-off-by: Laurentiu Tudor > Acked-by: Madalin Bucur Applied and queued up for -stable.
Re: [PATCH v2 3/9] fsl/fman: backup and restore ICID registers
From: laurentiu.tu...@nxp.com
Date: Sat, 27 Apr 2019 10:10:25 +0300
> @@ -1914,7 +1936,10 @@ static int fman_reset(struct fman *fman)
> static int fman_init(struct fman *fman)
> {
> struct fman_cfg *cfg = NULL;
> - int err = 0, i, count;
> + int err = 0, count;
> +#ifdef CONFIG_PPC
> + int i;
> +#endif
>
> if (is_init_done(fman->cfg))
> return -EINVAL;
> @@ -1934,6 +1959,7 @@ static int fman_init(struct fman *fman)
> memset_io((void __iomem *)(fman->base_addr + CGP_OFFSET), 0,
> fman->state->fm_port_num_of_cg);
>
> +#ifdef CONFIG_PPC
> /* Save LIODN info before FMan reset
>* Skipping non-existent port 0 (i = 1)
>*/
Sorry, I'm not OK with littering a networking driver with arch ifdefs
all over the place.
Please create a proper abstraction and set of interfaces.
Thank you.
Re: [PATCH -next] ibmvnic: remove set but not used variable 'netdev'
From: Yue Haibing
Date: Wed, 3 Apr 2019 15:54:09 +0800
> From: YueHaibing
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/ibm/ibmvnic.c: In function '__ibmvnic_reset':
> drivers/net/ethernet/ibm/ibmvnic.c:1971:21: warning: variable 'netdev' set
> but not used [-Wunused-but-set-variable]
>
> It's never used since introduction in
> commit ed651a10875f ("ibmvnic: Updated reset handling")
>
> Signed-off-by: YueHaibing
Applied.
Re: [PATCH net-next] ibmveth: Make array ibmveth_stats static
From: Yue Haibing Date: Tue, 19 Mar 2019 22:42:37 +0800 > From: YueHaibing > > Fix sparse warning: > drivers/net/ethernet/ibm/ibmveth.c:96:21: > warning: symbol 'ibmveth_stats' was not declared. Should it be static? > > Signed-off-by: YueHaibing Applied.
Re: [PATCH v5 4/4] hugetlb: allow to free gigantic pages regardless of the configuration
From: Alexandre Ghiti Date: Wed, 6 Mar 2019 14:00:05 -0500 > On systems without CONTIG_ALLOC activated but that support gigantic pages, > boottime reserved gigantic pages can not be freed at all. This patch > simply enables the possibility to hand back those pages to memory > allocator. > > Signed-off-by: Alexandre Ghiti For sparc: Acked-by: David S. Miller
Re: [PATCH v5 2/4] sparc: Advertise gigantic page support
From: Alexandre Ghiti Date: Wed, 6 Mar 2019 14:00:03 -0500 > sparc actually supports gigantic pages and selecting > ARCH_HAS_GIGANTIC_PAGE allows it to allocate and free > gigantic pages at runtime. > > sparc allows configuration such as huge pages of 16GB, > pages of 8KB and MAX_ORDER = 13 (default): > HPAGE_SHIFT (34) - PAGE_SHIFT (13) = 21 >= MAX_ORDER (13) > > Signed-off-by: Alexandre Ghiti Much better. Acked-by: David S. Miller
Re: [PATCH][next] ptp_qoriq: don't pass a large struct by value but instead pass it by reference
From: Colin King Date: Tue, 19 Feb 2019 14:21:20 + > From: Colin Ian King > > Passing the struct ptp_clock_info caps by parameter is passing over 130 bytes > of data by value on the stack. Optimize this by passing it by reference > instead. > Also shinks the object code size: > > Before: >text data bss dec hex filename > 12596 2160 64 1482039e4 drivers/ptp/ptp_qoriq.o > > After: >text data bss dec hex filename > 12567 2160 64 1479139c7 drivers/ptp/ptp_qoriq.o > > Signed-off-by: Colin Ian King Looks good, applied, thanks.
Re: [PATCH net] net: fsl_ucc_hdlc: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
From: Yang Wei Date: Wed, 6 Feb 2019 00:14:51 +0800 > From: Yang Wei > > dev_consume_skb_irq() should be called in hdlc_tx_done() when skb > xmit done. It makes drop profiles(dropwatch, perf) more friendly. > > Signed-off-by: Yang Wei Applied.
Re: [PATCH] ucc_geth: Reset BQL queue when stopping device
From: Mathias Thore Date: Mon, 28 Jan 2019 10:07:47 +0100 > After a timeout event caused by for example a broadcast storm, when > the MAC and PHY are reset, the BQL TX queue needs to be reset as > well. Otherwise, the device will exhibit severe performance issues > even after the storm has ended. > > Co-authored-by: David Gounaris > Signed-off-by: Mathias Thore Applied and queued up for -stable, thanks.
Re: [PATCH] ucc_geth: Reset BQL queue when stopping device
From: Mathias Thore Date: Tue, 29 Jan 2019 08:07:54 + > Is there a scenario where we are clearing the TX ring but don't want to reset > the BQL TX queue? > > I think it makes sense to keep it in ucc_geth_free_tx since the > reason it is needed isn't the timeout per se, but rather the > clearing of the TX ring. This way, it will be performed no matter > why the driver ends up calling this function. I absolutely think the BQL reset should remain in ucc_geth_free_tx(). That way if another callsite for ucc_geth_free_tx() emerges that does need the BQL queue reset, it won't be "forgotten".
Re: [PATCH 15/21] sparc: add checks for the return value of memblock_alloc*()
From: Mike Rapoport Date: Wed, 16 Jan 2019 15:44:15 +0200 > Add panic() calls if memblock_alloc*() returns NULL. > > Most of the changes are simply addition of > > if(!ptr) > panic(); > > statements after the calls to memblock_alloc*() variants. > > Exceptions are pcpu_populate_pte() and kernel_map_range() that were > slightly refactored to accommodate the change. > > Signed-off-by: Mike Rapoport Acked-by: David S. Miller
Re: [RESEND PATCH v5] soc/fsl/qe: fix err handling of ucc_of_parse_tdm
From: Peng Hao Date: Thu, 3 Jan 2019 01:09:53 +0800 > From: Wen Yang > > Currently there are some issues with the ucc_of_parse_tdm function: > 1, a possible null pointer dereference in ucc_of_parse_tdm, > detected by the semantic patch deref_null.cocci, > with the following warning: > drivers/soc/fsl/qe/qe_tdm.c:177:21-24: ERROR: pdev is NULL but dereferenced. > 2, dev gets modified, so in any case that devm_iounmap() will fail > even when the new pdev is valid, because the iomap was done with a > different pdev. > 3, there is no driver bind with the "fsl,t1040-qe-si" or > "fsl,t1040-qe-siram" device. So allocating resources using devm_*() > with these devices won't provide a cleanup path for these resources > when the caller fails. > > This patch fixes them. > > Suggested-by: Li Yang > Suggested-by: Christophe LEROY > Signed-off-by: Wen Yang > Reviewed-by: Peng Hao Applied, thanks.
Re: [PATCH v4] soc/fsl/qe: fix err handling of ucc_of_parse_tdm
From: Peng Hao
Date: Sat, 29 Dec 2018 16:47:32 +0800
> +static struct resource *ucc_get_resource_by_nodename(char *name)
> +{
> + struct device_node *np;
> + struct platform_device *pdev;
> +
> + np = of_find_compatible_node(NULL, NULL, name);
> + if (!np)
> + return ERR_PTR(-EINVAL);
> +
> + pdev = of_find_device_by_node(np);
> + if (!pdev) {
> + pr_err("%pOFn: failed to lookup pdev\n", np);
> + of_node_put(np);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + of_node_put(np);
> + return platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +}
"of_find_device_by_node()" takes a reference to the underlying device
structure, and you never release that reference.
I am very concerned about your submission because there are many
serious problems in it. It is absolutely impossible for your v3 to
have been tested, and now this new v4 adds object reference leaks.
Re: [PATCH v3] soc/fsl/qe: fix err handling of ucc_of_parse_tdm
From: Peng Hao
Date: Wed, 26 Dec 2018 16:26:29 +0800
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index 839fa77..8ce4921f 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -1057,6 +1057,27 @@ static const struct net_device_ops uhdlc_ops = {
> .ndo_tx_timeout = uhdlc_tx_timeout,
> };
>
> +static int ucc_get_resource_by_nodename(char *name, struct resource *res)
> +{
...
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + return 0;
This assignment to 'res' doesn't do what you think it does. The caller never
sees the value you compute.
Re: [PATCH] net/wan/fsl_ucc_hdlc: Avoid double free in ucc_hdlc_probe()
From: Peng Hao Date: Wed, 26 Dec 2018 16:28:30 +0800 > From: Wen Yang > > This patch fixes potential double frees if register_hdlc_device() fails. > > Signed-off-by: Wen Yang > Reviewed-by: Peng Hao Applied.
Re: [PATCH] net/ibmvnic: Remove tests of member address
From: Wen Yang Date: Tue, 11 Dec 2018 12:20:46 +0800 > The driver was checking for non-NULL address. > - adapter->napi[i] > > This is pointless as these will be always non-NULL, since the > 'dapter->napi' is allocated in init_napi(). > It is safe to get rid of useless checks for addresses to fix the > coccinelle warning: >>>drivers/net/ethernet/ibm/ibmvnic.c: test of a variable/field address > Since such statements always return true, they are redundant. > > Signed-off-by: Wen Yang Applied.
Re: [PATCH net 0/2] net/ibmvnic: Fix reset work item locking bugs
From: Thomas Falcon Date: Mon, 10 Dec 2018 15:22:21 -0600 > This patch set fixes issues with scheduling reset work items in > a tasklet context. Since ibmvnic_reset can called in an interrupt, > it should not use a mutex or allocate memory non-atomically. Series applied, thanks.
Re: [PATCH] tty: Use of_node_name_{eq,prefix} for node name comparisons
From: Rob Herring Date: Wed, 5 Dec 2018 13:50:43 -0600 > Convert string compares of DT node names to use of_node_name_eq helper > instead. This removes direct access to the node name pointer. > > For hvc, the code can also be simplified by using of_stdout pointer > instead of searching again for the stdout node. > > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: Greg Kroah-Hartman > Cc: Jiri Slaby > Cc: "David S. Miller" > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux-ser...@vger.kernel.org > Cc: sparcli...@vger.kernel.org > Signed-off-by: Rob Herring Acked-by: David S. Miller
Re: [PATCH v2 16/20] sparc: perf/core: advertise PMU exclusion capability
From: Andrew Murray Date: Mon, 26 Nov 2018 11:12:32 + > The SPARC PMU has the capability to exclude events based on context > - let's advertise that we support the PERF_PMU_CAP_EXCLUDE > capability to ensure that perf doesn't prevent us from handling > events where any exclusion flags are set. > > Signed-off-by: Andrew Murray Acked-by: David S. Miller
Re: [PATCH v3 0/3] dpaa_eth: add ethtool coalesce control
From: Madalin Bucur Date: Wed, 21 Nov 2018 13:41:06 +0200 > Add control of the DPAA portal interrupt coalescing settings from > ethtool. > > changes from v2: read ithresh from HW, set previous values on failure > changes from v1: added range checking for the QMan APIs Series applied.
Re: [PATCH net 0/2] ibmvnic: Fix queue and buffer accounting errors
From: Thomas Falcon Date: Wed, 21 Nov 2018 11:17:57 -0600 > This series includes two small fixes. The first resolves a typo bug > in the code to clean up unused RX buffers during device queue removal. > The second ensures that device queue memory is updated to reflect new > supported queue ring sizes after migration to other backing hardware. Series applied.
Re: [PATCH net] net/ibmnvic: Fix deadlock problem in reset
From: Juliet Kim Date: Mon, 19 Nov 2018 15:59:22 -0600 > This patch changes to use rtnl_lock only during a reset to avoid > deadlock that could occur when a thread operating close is holding > rtnl_lock and waiting for reset_lock acquired by another thread, > which is waiting for rtnl_lock in order to set the number of tx/rx > queues during a reset. > > Also, we now setting the number of tx/rx queues during a soft reset > for failover or LPM events. > > Signed-off-by: Juliet Kim Applied.
Re: [PATCH] net/ibmnvic: Fix deadlock problem in reset
Your patch is completely corrupted by your email client. Please fix this. Then, email a test patch privately to yourself. Please do not post your patch to this mailing list again until you can successfully apply the test patch you email to yourself in the step above. Thank you.
Re: [PATCH net-next 0/6] Remove VLAN.CFI overload
From: Alexei Starovoitov Date: Fri, 16 Nov 2018 19:51:55 -0800 > Michal, could you please explain the reasoning? By treating VLAN.CFI specially as "VLAN TAG PRESENT" we prevent the usage of certain VLAN ID encodings. So he's trying to get rid of VLAN_TAG_PRESENT completely and this was the final patch series necessary to accomplish that.
Re: [PATCH v2 2/2] dpaa_eth: add ethtool coalesce control
From: Madalin Bucur
Date: Tue, 13 Nov 2018 18:29:51 +0200
> + for_each_cpu(cpu, cpus) {
> + portal = qman_get_affine_portal(cpu);
> + res = qman_portal_set_iperiod(portal, period);
> + if (res)
> + return res;
> + res = qman_dqrr_set_ithresh(portal, thresh);
> + if (res)
> + return res;
Nope, you can't do it like this.
If any intermediate change fails, you have to unwind all of the
changes made up until that point.
Which means you'll have to store the previous setting somewhere
and reinstall those saved values in the error path.
Re: [PATCH net-next 0/6] Remove VLAN.CFI overload
From: Michał Mirosław Date: Sat, 10 Nov 2018 19:58:29 +0100 > Fix BPF code/JITs to allow for separate VLAN_PRESENT flag > storage and finally move the flag to separate storage in skbuff. > > This is final step to make CLAN.CFI transparent to core Linux > networking stack. > > An #ifdef is introduced temporarily to mark fragments masking > VLAN_TAG_PRESENT. This is removed altogether in the final patch. Series applied, thank you.
Re: [PATCH net-next 0/6] Remove VLAN.CFI overload
From: Michał Mirosław Date: Sat, 10 Nov 2018 19:58:29 +0100 > Fix BPF code/JITs to allow for separate VLAN_PRESENT flag > storage and finally move the flag to separate storage in skbuff. > > This is final step to make CLAN.CFI transparent to core Linux > networking stack. > > An #ifdef is introduced temporarily to mark fragments masking > VLAN_TAG_PRESENT. This is removed altogether in the final patch. Daniel and Alexei, please review.
Re: [PATCH] net/wan/fsl_ucc_hdlc: add BQL support
From: Mathias Thore Date: Wed, 7 Nov 2018 09:09:45 +0100 > Add byte queue limits support in the fsl_ucc_hdlc driver. > > Signed-off-by: Mathias Thore Applied to net-next.
Re: [PATCH] net/wan/fsl_ucc_hdlc: add BQL support
From: Mathias Thore Date: Tue, 23 Oct 2018 13:48:32 +0200 > Add byte queue limits support in the fsl_ucc_hdlc driver. > > Signed-off-by: Mathias Thore > --- > > Note that this patch is created relative to another patch that was > applied recently: net/wan/fsl_ucc_hdlc: error counters net-next is closed, please resubmit this when net-next opens back up. Thank you.
Re: [PATCH] net/wan/fsl_ucc_hdlc: error counters
From: Mathias Thore Date: Mon, 22 Oct 2018 14:55:50 +0200 > Extract error information from rx and tx buffer descriptors, > and update error counters. > > Signed-off-by: Mathias Thore Applied.
Re: linux-next: Tree for Oct 15
From: Rob Herring Date: Mon, 15 Oct 2018 20:00:24 -0500 > David, Can you revert commit 0b9871a3a8cc. I'll have to find another approach. Ok.
Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions
From: Joel Fernandes Date: Fri, 12 Oct 2018 05:50:46 -0700 > If its an issue, then how do transparent huge pages work on Sparc? I don't > see the huge page code (move_huge_pages) during mremap doing anything special > for Sparc architecture when moving PMDs.. This is because all huge pages are larger than SHMLBA. So no cache flushing necessary. > Also, do we not flush the caches from any path when we munmap > address space? We do call do_munmap on the old mapping from mremap > after moving to the new one. Sparc makes sure that shared mapping have consistent colors. Therefore all that's left are private mappings and those will be initialized by block stores to clear the page out or similar. Also, when creating new mappings, we flush the D-cache when necessary in update_mmu_cache(). We also maintain a bit in the page struct to track when a page which was potentially written to on one cpu ends up mapped into another address space and flush as necessary. The cache is write-through, which simplifies the preconditions we have to maintain.
Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions
From: "Kirill A. Shutemov" Date: Fri, 12 Oct 2018 14:30:56 +0300 > I looked into the code more and noticed move_pte() helper called from > move_ptes(). It changes PTE entry to suite new address. > > It is only defined in non-trivial way on Sparc. I don't know much about > Sparc and it's hard for me to say if the optimization will break anything > there. > > I think it worth to disable the optimization if __HAVE_ARCH_MOVE_PTE is > defined. Or make architectures state explicitely that the optimization is > safe. What sparc is doing in move_pte() is flushing the data-cache (synchronously) if the virtual address color of the mapping changes. Hope this helps.
Re: [PATCH net-next 00/22] net: fix return type of ndo_start_xmit function
From: YueHaibing Date: Thu, 20 Sep 2018 20:32:44 +0800 > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, so make sure the implementation in > this driver has returns 'netdev_tx_t' value, and change the function > return type to netdev_tx_t. I would advise you not to send so many of these changes as a group. If one of the patches needs feedback addressed, which is already the case, you will have to resubmit the entire series all over again with the fixes.
Re: [PATCH net-next] net: toshiba: fix return type of ndo_start_xmit function
From: YueHaibing Date: Wed, 19 Sep 2018 18:23:39 +0800 > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, so make sure the implementation in > this driver has returns 'netdev_tx_t' value, and change the function > return type to netdev_tx_t. > > Found by coccinelle. > > Signed-off-by: YueHaibing Applied.
Re: [PATCH net-next] net: ibm: fix return type of ndo_start_xmit function
From: YueHaibing Date: Tue, 18 Sep 2018 14:35:47 +0800 > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, so make sure the implementation in > this driver has returns 'netdev_tx_t' value, and change the function > return type to netdev_tx_t. > > Found by coccinelle. > > Signed-off-by: YueHaibing Applied.
Re: [PATCH net] powerpc: use big endian to hash len and proto in csum_ipv6_magic
From: Xin Long
Date: Sat, 8 Sep 2018 18:15:12 +0800
> The function csum_ipv6_magic doesn't convert len and proto to big
> endian before doing ipv6 csum hash, which is not consistent with
> RFC and other arches.
>
> Jianlin found it when ICMPv6 packets from other hosts were dropped
> in the powerpc64 system.
>
> This patch is to fix it by using instruction 'lwbrx' to do this
> conversion in powerpc32/64 csum_ipv6_magic.
>
> Fixes: e9c4943a107b ("powerpc: Implement csum_ipv6_magic in assembly")
> Reported-by: Jianlin Shi
> Signed-off-by: Xin Long
Xin, please address the feedback you were given.
Thank you.
Re: [PATCH 0/5] introduce setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64 functions
If you are going to do this, please add for_each_set_bit64() and similar. For example, see: https://marc.info/?l=linux-netdev=153633391214025=2
