Re: [PATCH] ibmvnic: remove default label from to_string switch

2021-05-03 Thread David Miller
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

2021-01-05 Thread David Miller
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

2020-12-01 Thread David Miller
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

2020-10-03 Thread David Miller
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

2020-10-01 Thread David Miller
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

2020-09-17 Thread David Miller
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

2020-09-15 Thread David Miller
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

2020-09-15 Thread David Miller
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

2020-09-14 Thread David Miller
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

2020-08-31 Thread David Miller
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

2020-08-25 Thread David Miller
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

2020-08-25 Thread David Miller
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

2020-08-25 Thread David Miller
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

2020-08-20 Thread David Miller
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

2020-08-19 Thread David Miller
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

2020-08-19 Thread David Miller
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

2020-08-14 Thread David Miller
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

2020-07-29 Thread David Miller
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

2020-07-20 Thread David Miller
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

2020-07-15 Thread David Miller
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

2020-06-23 Thread David Miller
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

2020-06-20 Thread David Miller
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

2020-06-19 Thread David Miller
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

2020-06-15 Thread David Miller
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

2020-06-12 Thread David Miller
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

2020-06-12 Thread David Miller
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

2020-06-04 Thread David Miller
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

2020-05-29 Thread David Miller
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

2020-05-29 Thread David Miller
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

2020-05-22 Thread David Miller
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

2020-04-30 Thread David Miller
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

2020-04-30 Thread David Miller
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

2020-03-10 Thread David Miller
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

2020-03-09 Thread David Miller
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

2020-03-03 Thread David Miller
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

2020-03-01 Thread David Miller
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

2020-02-24 Thread David Miller
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

2020-01-23 Thread David Miller
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'

2020-01-20 Thread David Miller
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

2020-01-15 Thread David Miller
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

2019-12-02 Thread David Miller
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()

2019-12-02 Thread David Miller
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

2019-11-26 Thread David Miller
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

2019-11-21 Thread David Miller
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

2019-11-20 Thread David Miller
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.

2019-10-13 Thread David Miller
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

2019-09-25 Thread David Miller
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

2019-09-10 Thread David Miller
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

2019-09-07 Thread David Miller
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

2019-09-02 Thread David Miller
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

2019-08-31 Thread David Miller
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

2019-08-31 Thread David Miller
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

2019-08-28 Thread David Miller
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

2019-08-21 Thread David Miller
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

2019-08-09 Thread David Miller
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

2019-07-02 Thread David Miller
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

2019-06-18 Thread David Miller
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

2019-06-09 Thread David Miller
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

2019-06-01 Thread David Miller
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

2019-05-30 Thread David Miller
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

2019-05-05 Thread David Miller
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

2019-05-05 Thread David Miller
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

2019-04-27 Thread David Miller
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'

2019-04-04 Thread David Miller
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

2019-03-19 Thread David Miller
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

2019-03-06 Thread David Miller
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

2019-03-06 Thread David Miller
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

2019-02-19 Thread David Miller
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

2019-02-06 Thread David Miller
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

2019-01-30 Thread David Miller
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

2019-01-29 Thread David Miller
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*()

2019-01-16 Thread David Miller
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

2019-01-04 Thread David Miller
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

2018-12-30 Thread David Miller
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

2018-12-28 Thread David Miller
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()

2018-12-27 Thread David Miller
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

2018-12-14 Thread David Miller
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

2018-12-10 Thread David Miller
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

2018-12-05 Thread David Miller
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

2018-11-26 Thread David Miller
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

2018-11-23 Thread David Miller
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

2018-11-22 Thread David Miller
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

2018-11-19 Thread David Miller
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

2018-11-17 Thread David Miller


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

2018-11-16 Thread David Miller
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

2018-11-16 Thread David Miller
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

2018-11-16 Thread David Miller
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

2018-11-10 Thread David Miller
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

2018-11-07 Thread David Miller
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

2018-10-23 Thread David Miller
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

2018-10-22 Thread David Miller
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

2018-10-15 Thread David Miller
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

2018-10-12 Thread David Miller
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

2018-10-12 Thread David Miller
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

2018-09-20 Thread David Miller
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

2018-09-19 Thread David Miller
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

2018-09-18 Thread David Miller
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

2018-09-12 Thread David Miller
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

2018-09-07 Thread David Miller


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


Re: [PATCH v3 0/6] Ethernet over hdlc

2018-09-04 Thread David Miller
From: David Gounaris 
Date: Mon,  3 Sep 2018 14:47:24 +0200

> Here is what has been changed in v3 after the review comments from v2.
> 
> v3-0001: corrected style problems
> v3-0002: corrected style problems
> v3-0003: corrected style problems
> v3-0004: corrected style problems
> v3-0005: corrected style problems
> v3-0006: corrected style problems
> 
> Sorry for that, I did not know about scripts/checkpatch.pl.

Series applied to net-next.


  1   2   3   4   5   6   7   8   9   10   >