Re: [PATCH v2 2/3] staging: vchiq: revert "switch to wait_for_completion_killable"

2019-05-06 Thread Dan Carpenter 
On Mon, May 06, 2019 at 04:40:29PM +0200, Nicolas Saenz Julienne wrote:
> The killable version of wait_for_completion() is meant to be used on
> situations where it should not fail at all costs, but still have the
> convenience of being able to kill it if really necessary. VCHIQ doesn't
> fit this criteria, as it's mainly used as an interface to V4L2 and ALSA
> devices.
> 
> Fixes: a772f116702e ("staging: vchiq: switch to wait_for_completion_killable")
> Signed-off-by: Nicolas Saenz Julienne 
> 
> This reverts commit a772f116702e3f0afdd7e6acadc1b8fb3b20b9ff.
> ---

Git just sets you up for failure with its revert.  That code was from
when git was really new and now everyone gets annoyed when they see a
raw git hash without a human readable subject.  Just say at the start of
the commit message:

This reverts commit a772f116702e ("staging: vchiq: switch to
wait_for_completion_killable").

The killable version of wait_for_completion() is meant to be used on
situations where it should not fail at all costs, but still have the
convenience of being able to kill it if really necessary. VCHIQ doesn't
fit this criteria, as it's mainly used as an interface to V4L2 and ALSA
devices.

Fixes: a772f116702e ("staging: vchiq: switch to wait_for_completion_killable")

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH AUTOSEL 4.14 57/95] staging: olpc_dcon: add a missing dependency

2019-05-06 Thread Sasha Levin 
From: Lubomir Rintel 

[ Upstream commit 33f49571d75024b1044cd02689ad2bdb4924cc80 ]

  WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE
Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n]
Selected by [y]:
- FB_OLPC_DCON [=y] && STAGING [=y] && X86 [=y] && OLPC [=y] && FB [=y]
&& I2C [=y] && (GPIO_CS5535 [=n] || GPIO_CS5535 [=n]=n)

Signed-off-by: Lubomir Rintel 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/staging/olpc_dcon/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/olpc_dcon/Kconfig 
b/drivers/staging/olpc_dcon/Kconfig
index d277f048789e..8c6cc61d634b 100644
--- a/drivers/staging/olpc_dcon/Kconfig
+++ b/drivers/staging/olpc_dcon/Kconfig
@@ -2,6 +2,7 @@ config FB_OLPC_DCON
tristate "One Laptop Per Child Display CONtroller support"
depends on OLPC && FB
depends on I2C
+   depends on BACKLIGHT_LCD_SUPPORT
depends on (GPIO_CS5535 || GPIO_CS5535=n)
select BACKLIGHT_CLASS_DEVICE
---help---
-- 
2.20.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android

2019-05-06 Thread Sultan Alsawaf 
This is a complete low memory killer solution for Android that is small
and simple. Processes are killed according to the priorities that
Android gives them, so that the least important processes are always
killed first. Processes are killed until memory deficits are satisfied,
as observed from kswapd struggling to free up pages. Simple LMK stops
killing processes when kswapd finally goes back to sleep.

The only tunables are the desired amount of memory to be freed per
reclaim event and desired frequency of reclaim events. Simple LMK tries
to free at least the desired amount of memory per reclaim and waits
until all of its victims' memory is freed before proceeding to kill more
processes.

Signed-off-by: Sultan Alsawaf 
---
Hello everyone,

I've addressed some of the concerns that were brought up with the first version
of the Simple LMK patch. I understand that a kernel-based solution like this
that contains policy decisions for a specific userspace is not the way to go,
but the Android ecosystem still has a pressing need for a low memory killer that
works well.

Most Android devices still use the ancient and deprecated lowmemorykiller.c
kernel driver; Simple LMK seeks to replace that, at the very least until PSI and
a userspace daemon utilizing PSI are ready for *all* Android devices, and not
just the privileged Pixel phone line.

The feedback I received last time was quite helpful. This Simple LMK patch works
significantly better than the first, improving memory management by a large
margin while being immune to transient spikes in memory usage (since the signal
to start killing processes is determined by how hard kswapd tries to free up
pages, which is something that occurs over a span of time and not a single point
in time).

I'd love to hear some feedback on this new patch. I do encourage those who are
interested to take it for a spin on an Android device. This patch has been
tested successfully on Android 4.4 and 4.9 kernels. For the sake of review here,
I have adapted the patch to 5.1.

Thanks,
Sultan

 drivers/android/Kconfig  |  33 
 drivers/android/Makefile |   1 +
 drivers/android/simple_lmk.c | 315 +++
 include/linux/mm_types.h |   4 +
 include/linux/simple_lmk.h   |  11 ++
 kernel/fork.c|  13 ++
 mm/vmscan.c  |  12 ++
 7 files changed, 389 insertions(+)
 create mode 100644 drivers/android/simple_lmk.c
 create mode 100644 include/linux/simple_lmk.h

diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
index 6fdf2abe4..bdd429338 100644
--- a/drivers/android/Kconfig
+++ b/drivers/android/Kconfig
@@ -54,6 +54,39 @@ config ANDROID_BINDER_IPC_SELFTEST
  exhaustively with combinations of various buffer sizes and
  alignments.
 
+config ANDROID_SIMPLE_LMK
+   bool "Simple Android Low Memory Killer"
+   depends on !ANDROID_LOW_MEMORY_KILLER && !MEMCG
+   ---help---
+ This is a complete low memory killer solution for Android that is
+ small and simple. Processes are killed according to the priorities
+ that Android gives them, so that the least important processes are
+ always killed first. Processes are killed until memory deficits are
+ satisfied, as observed from kswapd struggling to free up pages. Simple
+ LMK stops killing processes when kswapd finally goes back to sleep.
+
+if ANDROID_SIMPLE_LMK
+
+config ANDROID_SIMPLE_LMK_AGGRESSION
+   int "Reclaim frequency selection"
+   range 1 3
+   default 1
+   help
+ This value determines how frequently Simple LMK will perform memory
+ reclaims. A lower value corresponds to less frequent reclaims, which
+ maximizes memory usage. The range of values has a logarithmic
+ correlation; 2 is twice as aggressive as 1, and 3 is twice as
+ aggressive as 2, which makes 3 four times as aggressive as 1.
+
+config ANDROID_SIMPLE_LMK_MINFREE
+   int "Minimum MiB of memory to free per reclaim"
+   range 8 512
+   default 64
+   help
+ Simple LMK will try to free at least this much memory per reclaim.
+
+endif
+
 endif # if ANDROID
 
 endmenu
diff --git a/drivers/android/Makefile b/drivers/android/Makefile
index c7856e320..7c91293b6 100644
--- a/drivers/android/Makefile
+++ b/drivers/android/Makefile
@@ -3,3 +3,4 @@ ccflags-y += -I$(src)   # needed for trace 
events
 obj-$(CONFIG_ANDROID_BINDERFS) += binderfs.o
 obj-$(CONFIG_ANDROID_BINDER_IPC)   += binder.o binder_alloc.o
 obj-$(CONFIG_ANDROID_BINDER_IPC_SELFTEST) += binder_alloc_selftest.o
+obj-$(CONFIG_ANDROID_SIMPLE_LMK)   += simple_lmk.o
diff --git a/drivers/android/simple_lmk.c b/drivers/android/simple_lmk.c
new file mode 100644
index 0..a2ffb57b5
--- /dev/null
+++ b/drivers/android/simple_lmk.c
@@ -0,0 +1,315 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Sultan Alsawaf .
+ */
+
+#define pr_fmt(fmt)

Re: [PATCH] staging: erofs: set sb->s_root to NULL when failing from __getname()

2019-05-06 Thread Chao Yu 
On 2019/5/6 19:01, Chengguang Xu wrote:
> Set sb->s_root to NULL when failing from __getname(),
> so that we can avoid double dput and unnecessary operations
> in generic_shutdown_super().
> 
> Signed-off-by: Chengguang Xu 

Reviewed-by: Chao Yu 

Thanks,
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH net-next v2 4/4] net: usb: smsc: fix warning reported by kbuild test robot

2019-05-06 Thread Woojung.Huh 
> This patch fixes following warning reported by kbuild test robot:
> 
>  In function ‘memcpy’,
>  inlined from ‘smsc75xx_init_mac_address’ at 
> drivers/net/usb/smsc75xx.c:778:3,
>  inlined from ‘smsc75xx_bind’ at drivers/net/usb/smsc75xx.c:1501:2:
>  ./include/linux/string.h:355:9: warning: argument 2 null where non-null 
> expected [-Wnonnull]
>return __builtin_memcpy(p, q, size);
>   ^~~~
>  drivers/net/usb/smsc75xx.c: In function ‘smsc75xx_bind’:
>  ./include/linux/string.h:355:9: note: in a call to built-in function 
> ‘__builtin_memcpy’
> 
> I've replaced the offending memcpy with ether_addr_copy, because I'm
> 100% sure, that of_get_mac_address can't return NULL as it returns valid
> pointer or ERR_PTR encoded value, nothing else.
> 
> I'm hesitant to just change IS_ERR into IS_ERR_OR_NULL check, as this
> would make the warning disappear also, but it would be confusing to
> check for impossible return value just to make a compiler happy.
> 
> Fixes: adfb3cb2c52e ("net: usb: support of_get_mac_address new ERR_PTR error")
> Reported-by: kbuild test robot 
> Signed-off-by: Petr Štetiar 
> ---

Reviewed-by: Woojung Huh 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH net-next v2 4/4] net: usb: smsc: fix warning reported by kbuild test robot

2019-05-06 Thread Petr Štetiar 
This patch fixes following warning reported by kbuild test robot:

 In function ‘memcpy’,
 inlined from ‘smsc75xx_init_mac_address’ at 
drivers/net/usb/smsc75xx.c:778:3,
 inlined from ‘smsc75xx_bind’ at drivers/net/usb/smsc75xx.c:1501:2:
 ./include/linux/string.h:355:9: warning: argument 2 null where non-null 
expected [-Wnonnull]
   return __builtin_memcpy(p, q, size);
  ^~~~
 drivers/net/usb/smsc75xx.c: In function ‘smsc75xx_bind’:
 ./include/linux/string.h:355:9: note: in a call to built-in function 
‘__builtin_memcpy’

I've replaced the offending memcpy with ether_addr_copy, because I'm
100% sure, that of_get_mac_address can't return NULL as it returns valid
pointer or ERR_PTR encoded value, nothing else.

I'm hesitant to just change IS_ERR into IS_ERR_OR_NULL check, as this
would make the warning disappear also, but it would be confusing to
check for impossible return value just to make a compiler happy.

Fixes: adfb3cb2c52e ("net: usb: support of_get_mac_address new ERR_PTR error")
Reported-by: kbuild test robot 
Signed-off-by: Petr Štetiar 
---
 drivers/net/usb/smsc75xx.c | 2 +-
 drivers/net/usb/smsc95xx.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index d27b627..e4c2f3a 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -775,7 +775,7 @@ static void smsc75xx_init_mac_address(struct usbnet *dev)
/* maybe the boot loader passed the MAC address in devicetree */
mac_addr = of_get_mac_address(dev->udev->dev.of_node);
if (!IS_ERR(mac_addr)) {
-   memcpy(dev->net->dev_addr, mac_addr, ETH_ALEN);
+   ether_addr_copy(dev->net->dev_addr, mac_addr);
return;
}
 
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index ab23911..a0e1199 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -918,7 +918,7 @@ static void smsc95xx_init_mac_address(struct usbnet *dev)
/* maybe the boot loader passed the MAC address in devicetree */
mac_addr = of_get_mac_address(dev->udev->dev.of_node);
if (!IS_ERR(mac_addr)) {
-   memcpy(dev->net->dev_addr, mac_addr, ETH_ALEN);
+   ether_addr_copy(dev->net->dev_addr, mac_addr);
return;
}
 
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH net-next v2 2/4] net: dsa: support of_get_mac_address new ERR_PTR error

2019-05-06 Thread Petr Štetiar 
There was NVMEM support added to of_get_mac_address, so it could now
return ERR_PTR encoded error values, so we need to adjust all current
users of of_get_mac_address to this new fact.

While at it, remove superfluous is_valid_ether_addr as the MAC address
returned from of_get_mac_address is always valid and checked by
is_valid_ether_addr anyway.

Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
Signed-off-by: Petr Štetiar 
---
 net/dsa/slave.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 316bce9..fe7b6a6 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1418,7 +1418,7 @@ int dsa_slave_create(struct dsa_port *port)
NETIF_F_HW_VLAN_CTAG_FILTER;
slave_dev->hw_features |= NETIF_F_HW_TC;
slave_dev->ethtool_ops = _slave_ethtool_ops;
-   if (port->mac && is_valid_ether_addr(port->mac))
+   if (!IS_ERR_OR_NULL(port->mac))
ether_addr_copy(slave_dev->dev_addr, port->mac);
else
eth_hw_addr_inherit(slave_dev, master);
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH net-next v2 3/4] staging: octeon-ethernet: Fix of_get_mac_address ERR_PTR check

2019-05-06 Thread Petr Štetiar 
Commit 284eb160681c ("staging: octeon-ethernet: support
of_get_mac_address new ERR_PTR error") has introduced checking for
ERR_PTR encoded error value from of_get_mac_address with IS_ERR macro,
which is not sufficient in this case, as the mac variable is set to NULL
initialy and if the kernel is compiled without DT support this NULL
would get passed to IS_ERR, which would lead to the wrong decision and
would pass that NULL pointer and invalid MAC address further.

Fixes: 284eb160681c ("staging: octeon-ethernet: support of_get_mac_address new 
ERR_PTR error")
Signed-off-by: Petr Štetiar 
---
 drivers/staging/octeon/ethernet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/octeon/ethernet.c 
b/drivers/staging/octeon/ethernet.c
index 2b03018..8847a11c2 100644
--- a/drivers/staging/octeon/ethernet.c
+++ b/drivers/staging/octeon/ethernet.c
@@ -421,7 +421,7 @@ int cvm_oct_common_init(struct net_device *dev)
if (priv->of_node)
mac = of_get_mac_address(priv->of_node);
 
-   if (!IS_ERR(mac))
+   if (!IS_ERR_OR_NULL(mac))
ether_addr_copy(dev->dev_addr, mac);
else
eth_hw_addr_random(dev);
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH net-next v2 1/4] net: ethernet: support of_get_mac_address new ERR_PTR error

2019-05-06 Thread Petr Štetiar 
There was NVMEM support added to of_get_mac_address, so it could now
return ERR_PTR encoded error values, so we need to adjust all current
users of of_get_mac_address to this new fact.

While at it, remove superfluous is_valid_ether_addr as the MAC address
returned from of_get_mac_address is always valid and checked by
is_valid_ether_addr anyway.

Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
Signed-off-by: Petr Štetiar 
---

 This is defacto v5 of the previous 05/10 patch in the series, but since the
 v4 of this 05/10 patch wasn't picked up by the patchwork for some unknown
 reason, this patch wasn't applied with the other 9 patches in the series, so
 I'm resending it as a separate patch of this fixup series.

 Changes since v1:

  * added Fixes: tag

 Previous changelog (Patch 05/10):

  Changes since v3:

   * IS_ERR_OR_NULL -> IS_ERR

  Changes since v4:

   * I've just blindly replaced IS_ERR_OR_NULL with IS_ERR, but I've just
 realized, that in some cases we still need to check for NULL, so I've
 corrected it in following drivers/files:

  - broadcom/bgmac-bcma.c
  - marvell/pxa168_eth.c
  - samsung/sxgbe/sxgbe_platform.c
  - stmicro/stmmac/stmmac_main.c
  - wiznet/w5100.c
  - ethernet/eth.c

 drivers/net/ethernet/aeroflex/greth.c | 2 +-
 drivers/net/ethernet/allwinner/sun4i-emac.c   | 2 +-
 drivers/net/ethernet/altera/altera_tse_main.c | 2 +-
 drivers/net/ethernet/arc/emac_main.c  | 2 +-
 drivers/net/ethernet/aurora/nb8800.c  | 2 +-
 drivers/net/ethernet/broadcom/bcmsysport.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-bcma.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-platform.c| 2 +-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c| 2 +-
 drivers/net/ethernet/cavium/octeon/octeon_mgmt.c  | 2 +-
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 2 +-
 drivers/net/ethernet/davicom/dm9000.c | 2 +-
 drivers/net/ethernet/ethoc.c  | 2 +-
 drivers/net/ethernet/ezchip/nps_enet.c| 2 +-
 drivers/net/ethernet/freescale/fec_main.c | 2 +-
 drivers/net/ethernet/freescale/fec_mpc52xx.c  | 2 +-
 drivers/net/ethernet/freescale/fman/mac.c | 2 +-
 drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 2 +-
 drivers/net/ethernet/freescale/gianfar.c  | 2 +-
 drivers/net/ethernet/freescale/ucc_geth.c | 2 +-
 drivers/net/ethernet/hisilicon/hisi_femac.c   | 2 +-
 drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 2 +-
 drivers/net/ethernet/lantiq_xrx200.c  | 2 +-
 drivers/net/ethernet/marvell/mv643xx_eth.c| 2 +-
 drivers/net/ethernet/marvell/mvneta.c | 2 +-
 drivers/net/ethernet/marvell/pxa168_eth.c | 2 +-
 drivers/net/ethernet/marvell/sky2.c   | 2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 2 +-
 drivers/net/ethernet/micrel/ks8851.c  | 2 +-
 drivers/net/ethernet/micrel/ks8851_mll.c  | 2 +-
 drivers/net/ethernet/nxp/lpc_eth.c| 2 +-
 drivers/net/ethernet/qualcomm/qca_spi.c   | 2 +-
 drivers/net/ethernet/qualcomm/qca_uart.c  | 2 +-
 drivers/net/ethernet/renesas/ravb_main.c  | 2 +-
 drivers/net/ethernet/renesas/sh_eth.c | 2 +-
 drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c   | 2 +-
 drivers/net/ethernet/socionext/sni_ave.c  | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 drivers/net/ethernet/ti/cpsw.c| 2 +-
 drivers/net/ethernet/ti/netcp_core.c  | 2 +-
 drivers/net/ethernet/wiznet/w5100.c   | 2 +-
 drivers/net/ethernet/xilinx/ll_temac_main.c   | 2 +-
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +-
 drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 +-
 net/ethernet/eth.c| 2 +-
 45 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/drivers/net/ethernet/aeroflex/greth.c 
b/drivers/net/ethernet/aeroflex/greth.c
index 47e5984..7c5cf02 100644
--- a/drivers/net/ethernet/aeroflex/greth.c
+++ b/drivers/net/ethernet/aeroflex/greth.c
@@ -1459,7 +1459,7 @@ static int greth_of_probe(struct platform_device *ofdev)
const u8 *addr;
 
addr = of_get_mac_address(ofdev->dev.of_node);
-   if (addr) {
+   if (!IS_ERR(addr)) {
for (i = 0; i < 6; i++)
macaddr[i] = (unsigned int) addr[i];
} else {
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c 
b/drivers/net/ethernet/allwinner/sun4i-emac.c
index e1acafa..37ebd89 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -870,7 +870,7 @@ static int emac_probe(struct

[PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes

2019-05-06 Thread Petr Štetiar 
Hi,

this patch series is an attempt to fix the mess, I've somehow managed to
introduce.

First patch in this series is defacto v5 of the previous 05/10 patch in the
series, but since the v4 of this 05/10 patch wasn't picked up by the
patchwork for some unknown reason, this patch wasn't applied with the other
9 patches in the series, so I'm resending it as a separate patch of this
fixup series again.

Second patch is a result of this rebase against net-next tree, where I was
checking again all current users of of_get_mac_address and found out, that
there's new one in DSA, so I've converted this user to the new ERR_PTR
encoded error value as well.

Third patch which was sent as v5 wasn't considered for merge, but I still
think, that we need to check for possible NULL value, thus current IS_ERR
check isn't sufficient and we need to use IS_ERR_OR_NULL instead.

Fourth patch fixes warning reported by kbuild test robot.

Cheers,

Petr

Petr Štetiar (4):
  net: ethernet: support of_get_mac_address new ERR_PTR error
  net: dsa: support of_get_mac_address new ERR_PTR error
  staging: octeon-ethernet: Fix of_get_mac_address ERR_PTR check
  net: usb: smsc: fix warning reported by kbuild test robot

 drivers/net/ethernet/aeroflex/greth.c | 2 +-
 drivers/net/ethernet/allwinner/sun4i-emac.c   | 2 +-
 drivers/net/ethernet/altera/altera_tse_main.c | 2 +-
 drivers/net/ethernet/arc/emac_main.c  | 2 +-
 drivers/net/ethernet/aurora/nb8800.c  | 2 +-
 drivers/net/ethernet/broadcom/bcmsysport.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-bcma.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-platform.c| 2 +-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c| 2 +-
 drivers/net/ethernet/cavium/octeon/octeon_mgmt.c  | 2 +-
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 2 +-
 drivers/net/ethernet/davicom/dm9000.c | 2 +-
 drivers/net/ethernet/ethoc.c  | 2 +-
 drivers/net/ethernet/ezchip/nps_enet.c| 2 +-
 drivers/net/ethernet/freescale/fec_main.c | 2 +-
 drivers/net/ethernet/freescale/fec_mpc52xx.c  | 2 +-
 drivers/net/ethernet/freescale/fman/mac.c | 2 +-
 drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 2 +-
 drivers/net/ethernet/freescale/gianfar.c  | 2 +-
 drivers/net/ethernet/freescale/ucc_geth.c | 2 +-
 drivers/net/ethernet/hisilicon/hisi_femac.c   | 2 +-
 drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 2 +-
 drivers/net/ethernet/lantiq_xrx200.c  | 2 +-
 drivers/net/ethernet/marvell/mv643xx_eth.c| 2 +-
 drivers/net/ethernet/marvell/mvneta.c | 2 +-
 drivers/net/ethernet/marvell/pxa168_eth.c | 2 +-
 drivers/net/ethernet/marvell/sky2.c   | 2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 2 +-
 drivers/net/ethernet/micrel/ks8851.c  | 2 +-
 drivers/net/ethernet/micrel/ks8851_mll.c  | 2 +-
 drivers/net/ethernet/nxp/lpc_eth.c| 2 +-
 drivers/net/ethernet/qualcomm/qca_spi.c   | 2 +-
 drivers/net/ethernet/qualcomm/qca_uart.c  | 2 +-
 drivers/net/ethernet/renesas/ravb_main.c  | 2 +-
 drivers/net/ethernet/renesas/sh_eth.c | 2 +-
 drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c   | 2 +-
 drivers/net/ethernet/socionext/sni_ave.c  | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 drivers/net/ethernet/ti/cpsw.c| 2 +-
 drivers/net/ethernet/ti/netcp_core.c  | 2 +-
 drivers/net/ethernet/wiznet/w5100.c   | 2 +-
 drivers/net/ethernet/xilinx/ll_temac_main.c   | 2 +-
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +-
 drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 +-
 drivers/net/usb/smsc75xx.c| 2 +-
 drivers/net/usb/smsc95xx.c| 2 +-
 drivers/staging/octeon/ethernet.c | 2 +-
 net/dsa/slave.c   | 2 +-
 net/ethernet/eth.c| 2 +-
 49 files changed, 49 insertions(+), 49 deletions(-)

-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 0/3] staging: vchiq: use interruptible waits

2019-05-06 Thread Nicolas Saenz Julienne 
On Mon, 2019-05-06 at 20:12 +0200, Stefan Wahren wrote:
> Hi Nicolas,
> 
> Am 06.05.19 um 16:40 schrieb Nicolas Saenz Julienne:
> > Hi,
> > ...
> > 
> > Regards,
> > Nicolas
> > 
> > [1] https://github.com/raspberrypi/linux/issues/2881
> > [2] https://archlinuxarm.org/forum/viewtopic.php?f=65=13485
> > [3] 
> > 
https://lists.fedoraproject.org/archives/list/a...@lists.fedoraproject.org/message/GBXGJ7DOV5CQQXFPOZCXTRD6W4BEPT4Q/
> > 
> > --
> > 
> > Changes since v1:
> >   - Proplery format revert commits
> >   - Add code comment to remind of this issue
> >   - Add Fixes tags
> > 
> > Nicolas Saenz Julienne (3):
> >   staging: vchiq_2835_arm: revert "quit using custom
> > down_interruptible()"
> >   staging: vchiq: revert "switch to wait_for_completion_killable"
> >   staging: vchiq: make wait events interruptible
> > 
> >  .../interface/vchiq_arm/vchiq_2835_arm.c  |  2 +-
> >  .../interface/vchiq_arm/vchiq_arm.c   | 21 +++--
> >  .../interface/vchiq_arm/vchiq_core.c  | 31 ---
> >  .../interface/vchiq_arm/vchiq_util.c  |  6 ++--
> >  4 files changed, 35 insertions(+), 25 deletions(-)
> > 
> against which tree should this series apply?
> 
> Since the merge window opened the current staging-linus wont be
> available soon.

I don't know if that's what you meant, but I guess we should wait for 5.2-rc1
and then push it, the fixes will eventually get into the stable version of 5.1.


Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 0/3] staging: vchiq: use interruptible waits

2019-05-06 Thread Stefan Wahren 
Hi Nicolas,

Am 06.05.19 um 16:40 schrieb Nicolas Saenz Julienne:
> Hi,
> ...
>
> Regards,
> Nicolas
>
> [1] https://github.com/raspberrypi/linux/issues/2881
> [2] https://archlinuxarm.org/forum/viewtopic.php?f=65=13485
> [3] 
> https://lists.fedoraproject.org/archives/list/a...@lists.fedoraproject.org/message/GBXGJ7DOV5CQQXFPOZCXTRD6W4BEPT4Q/
>
> --
>
> Changes since v1:
>   - Proplery format revert commits
>   - Add code comment to remind of this issue
>   - Add Fixes tags
>
> Nicolas Saenz Julienne (3):
>   staging: vchiq_2835_arm: revert "quit using custom
> down_interruptible()"
>   staging: vchiq: revert "switch to wait_for_completion_killable"
>   staging: vchiq: make wait events interruptible
>
>  .../interface/vchiq_arm/vchiq_2835_arm.c  |  2 +-
>  .../interface/vchiq_arm/vchiq_arm.c   | 21 +++--
>  .../interface/vchiq_arm/vchiq_core.c  | 31 ---
>  .../interface/vchiq_arm/vchiq_util.c  |  6 ++--
>  4 files changed, 35 insertions(+), 25 deletions(-)
>
against which tree should this series apply?

Since the merge window opened the current staging-linus wont be
available soon.

Stefan

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 2/3] staging: vchiq: revert "switch to wait_for_completion_killable"

2019-05-06 Thread Stefan Wahren 
Hi Nicolas,

Am 06.05.19 um 17:59 schrieb Nicolas Saenz Julienne:
> Hi Dan, thanks for reviewing.
>
> On Mon, 2019-05-06 at 18:20 +0300, Dan Carpenter wrote:
>> On Mon, May 06, 2019 at 04:40:29PM +0200, Nicolas Saenz Julienne wrote:
>>> @@ -1740,7 +1740,8 @@ parse_rx_slots(struct vchiq_state *state)
>>> >bulk_rx : >bulk_tx;
>>>  
>>> DEBUG_TRACE(PARSE_LINE);
>>> -   if (mutex_lock_killable(>bulk_mutex)) {
>>> +   if (mutex_lock_killable(
>>> +   >bulk_mutex) != 0) {
>> This series does't add != 0 consistently...  Personally, I would prefer
>> we just leave it out.  I use != 0 for two things.  1)  When I'm talking
>> about the number zero.
>>
>>  if (len == 0) {
>>
>> Or with strcmp():
>>
>>  if (strcmp(a, b) == 0) { // a equals b
>>  if (strcmp(a, b) < 0) {  // a less than b.
>>
>> But here zero means no errors, so I would just leave it out...
> I agree, I'll fix it.

i also agree with Dan, but this specific patch should revert the changes
of a772f116702e3f0afdd7e6acadc1b8fb3b20b9ff . So mentioned style issue
should be fixed in a separate patch.

Regards Stefan

>
> Regards,
> Nicolas
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH RESEND net-next 3/3] staging: octeon-ethernet: Fix of_get_mac_address ERR_PTR check

2019-05-06 Thread Petr Štetiar 
Commit 284eb160681c ("staging: octeon-ethernet: support
of_get_mac_address new ERR_PTR error") has introduced checking for
ERR_PTR encoded error value from of_get_mac_address with IS_ERR macro,
which is not sufficient in this case, as the mac variable is set to NULL
initialy and if the kernel is compiled without DT support this NULL
would get passed to IS_ERR, which would lead to the wrong decision and
would pass that NULL pointer and invalid MAC address further.

Fixes: 284eb160681c ("staging: octeon-ethernet: support of_get_mac_address new 
ERR_PTR error")
Signed-off-by: Petr Štetiar 
---
 drivers/staging/octeon/ethernet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/octeon/ethernet.c 
b/drivers/staging/octeon/ethernet.c
index 2b03018..8847a11c2 100644
--- a/drivers/staging/octeon/ethernet.c
+++ b/drivers/staging/octeon/ethernet.c
@@ -421,7 +421,7 @@ int cvm_oct_common_init(struct net_device *dev)
if (priv->of_node)
mac = of_get_mac_address(priv->of_node);
 
-   if (!IS_ERR(mac))
+   if (!IS_ERR_OR_NULL(mac))
ether_addr_copy(dev->dev_addr, mac);
else
eth_hw_addr_random(dev);
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH RESEND net-next 1/3] net: ethernet: support of_get_mac_address new ERR_PTR error

2019-05-06 Thread Petr Štetiar 
There was NVMEM support added to of_get_mac_address, so it could now return
ERR_PTR encoded error values, so we need to adjust all current users of
of_get_mac_address to this new fact.

While at it, remove superfluous is_valid_ether_addr as the MAC address
returned from of_get_mac_address is always valid and checked by
is_valid_ether_addr anyway.

Signed-off-by: Petr Štetiar 
---

 This is defacto v5 of the previous 05/10 patch in the series, but since the
 v4 of this 05/10 patch wasn't picked up by the patchwork for some unknown
 reason, this patch wasn't applied with the other 9 patches in the series, so
 I'm resending it as a separate patch of this fixup series.

 Changes since v3:

  * IS_ERR_OR_NULL -> IS_ERR

 Changes since v4:

  * I've just blindly replaced IS_ERR_OR_NULL with IS_ERR, but I've just
realized, that in some cases we still need to check for NULL, so I've
corrected it in following drivers/files:

 - broadcom/bgmac-bcma.c
 - marvell/pxa168_eth.c
 - samsung/sxgbe/sxgbe_platform.c
 - stmicro/stmmac/stmmac_main.c
 - wiznet/w5100.c
 - ethernet/eth.c

 drivers/net/ethernet/aeroflex/greth.c | 2 +-
 drivers/net/ethernet/allwinner/sun4i-emac.c   | 2 +-
 drivers/net/ethernet/altera/altera_tse_main.c | 2 +-
 drivers/net/ethernet/arc/emac_main.c  | 2 +-
 drivers/net/ethernet/aurora/nb8800.c  | 2 +-
 drivers/net/ethernet/broadcom/bcmsysport.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-bcma.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-platform.c| 2 +-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c| 2 +-
 drivers/net/ethernet/cavium/octeon/octeon_mgmt.c  | 2 +-
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 2 +-
 drivers/net/ethernet/davicom/dm9000.c | 2 +-
 drivers/net/ethernet/ethoc.c  | 2 +-
 drivers/net/ethernet/ezchip/nps_enet.c| 2 +-
 drivers/net/ethernet/freescale/fec_main.c | 2 +-
 drivers/net/ethernet/freescale/fec_mpc52xx.c  | 2 +-
 drivers/net/ethernet/freescale/fman/mac.c | 2 +-
 drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 2 +-
 drivers/net/ethernet/freescale/gianfar.c  | 2 +-
 drivers/net/ethernet/freescale/ucc_geth.c | 2 +-
 drivers/net/ethernet/hisilicon/hisi_femac.c   | 2 +-
 drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 2 +-
 drivers/net/ethernet/lantiq_xrx200.c  | 2 +-
 drivers/net/ethernet/marvell/mv643xx_eth.c| 2 +-
 drivers/net/ethernet/marvell/mvneta.c | 2 +-
 drivers/net/ethernet/marvell/pxa168_eth.c | 2 +-
 drivers/net/ethernet/marvell/sky2.c   | 2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 2 +-
 drivers/net/ethernet/micrel/ks8851.c  | 2 +-
 drivers/net/ethernet/micrel/ks8851_mll.c  | 2 +-
 drivers/net/ethernet/nxp/lpc_eth.c| 2 +-
 drivers/net/ethernet/qualcomm/qca_spi.c   | 2 +-
 drivers/net/ethernet/qualcomm/qca_uart.c  | 2 +-
 drivers/net/ethernet/renesas/ravb_main.c  | 2 +-
 drivers/net/ethernet/renesas/sh_eth.c | 2 +-
 drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c   | 2 +-
 drivers/net/ethernet/socionext/sni_ave.c  | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 drivers/net/ethernet/ti/cpsw.c| 2 +-
 drivers/net/ethernet/ti/netcp_core.c  | 2 +-
 drivers/net/ethernet/wiznet/w5100.c   | 2 +-
 drivers/net/ethernet/xilinx/ll_temac_main.c   | 2 +-
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +-
 drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 +-
 net/ethernet/eth.c| 2 +-
 45 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/drivers/net/ethernet/aeroflex/greth.c 
b/drivers/net/ethernet/aeroflex/greth.c
index 47e5984..7c5cf02 100644
--- a/drivers/net/ethernet/aeroflex/greth.c
+++ b/drivers/net/ethernet/aeroflex/greth.c
@@ -1459,7 +1459,7 @@ static int greth_of_probe(struct platform_device *ofdev)
const u8 *addr;
 
addr = of_get_mac_address(ofdev->dev.of_node);
-   if (addr) {
+   if (!IS_ERR(addr)) {
for (i = 0; i < 6; i++)
macaddr[i] = (unsigned int) addr[i];
} else {
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c 
b/drivers/net/ethernet/allwinner/sun4i-emac.c
index e1acafa..37ebd89 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -870,7 +870,7 @@ static int emac_probe(struct platform_device *pdev)
 
/* Read MAC-address from DT */
mac_addr = of_get_mac_address(np);
-   if (mac_addr)
+   if (!IS_ERR(mac_addr))

[PATCH RESEND net-next 2/3] net: dsa: support of_get_mac_address new ERR_PTR error

2019-05-06 Thread Petr Štetiar 
There was NVMEM support added to of_get_mac_address, so it could now
return ERR_PTR encoded error values, so we need to adjust all current
users of of_get_mac_address to this new fact.

While at it, remove superfluous is_valid_ether_addr as the MAC address
returned from of_get_mac_address is always valid and checked by
is_valid_ether_addr anyway.

Signed-off-by: Petr Štetiar 
---
 net/dsa/slave.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 316bce9..2e1deef 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1418,7 +1418,7 @@ int dsa_slave_create(struct dsa_port *port)
NETIF_F_HW_VLAN_CTAG_FILTER;
slave_dev->hw_features |= NETIF_F_HW_TC;
slave_dev->ethtool_ops = _slave_ethtool_ops;
-   if (port->mac && is_valid_ether_addr(port->mac))
+   if (!IS_ERR_OR_NULL(port->mac))
ether_addr_copy(slave_dev->dev_addr, port->mac);
else
eth_hw_addr_inherit(slave_dev, master);
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH RESEND net-next 0/3] of_get_mac_address ERR_PTR fixes

2019-05-06 Thread Petr Štetiar 
Hi,

this patch series is an attempt to fix the mess, I've somehow managed to
introduce.

First patch in this series is defacto v5 of the previous 05/10 patch in the
series, but since the v4 of this 05/10 patch wasn't picked up by the
patchwork for some unknown reason, this patch wasn't applied with the other
9 patches in the series, so I'm resending it as a separate patch of this
fixup series again.

Second patch is a result of this rebase against net-next tree, where I was
checking again all current users of of_get_mac_address and found out, that
there's new one in DSA, so I've converted this user to the new ERR_PTR
encoded error value as well.

Third patch which was sent as v5 wasn't considered for merge, but I still
think, that we need to check for possible NULL value, thus current IS_ERR
check isn't sufficient and we need to use IS_ERR_OR_NULL instead.

Cheers,

Petr

Petr Štetiar (3):
  net: ethernet: support of_get_mac_address new ERR_PTR error
  net: dsa: support of_get_mac_address new ERR_PTR error
  staging: octeon-ethernet: Fix of_get_mac_address ERR_PTR check

 drivers/net/ethernet/aeroflex/greth.c | 2 +-
 drivers/net/ethernet/allwinner/sun4i-emac.c   | 2 +-
 drivers/net/ethernet/altera/altera_tse_main.c | 2 +-
 drivers/net/ethernet/arc/emac_main.c  | 2 +-
 drivers/net/ethernet/aurora/nb8800.c  | 2 +-
 drivers/net/ethernet/broadcom/bcmsysport.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-bcma.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-platform.c| 2 +-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c| 2 +-
 drivers/net/ethernet/cavium/octeon/octeon_mgmt.c  | 2 +-
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 2 +-
 drivers/net/ethernet/davicom/dm9000.c | 2 +-
 drivers/net/ethernet/ethoc.c  | 2 +-
 drivers/net/ethernet/ezchip/nps_enet.c| 2 +-
 drivers/net/ethernet/freescale/fec_main.c | 2 +-
 drivers/net/ethernet/freescale/fec_mpc52xx.c  | 2 +-
 drivers/net/ethernet/freescale/fman/mac.c | 2 +-
 drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 2 +-
 drivers/net/ethernet/freescale/gianfar.c  | 2 +-
 drivers/net/ethernet/freescale/ucc_geth.c | 2 +-
 drivers/net/ethernet/hisilicon/hisi_femac.c   | 2 +-
 drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 2 +-
 drivers/net/ethernet/lantiq_xrx200.c  | 2 +-
 drivers/net/ethernet/marvell/mv643xx_eth.c| 2 +-
 drivers/net/ethernet/marvell/mvneta.c | 2 +-
 drivers/net/ethernet/marvell/pxa168_eth.c | 2 +-
 drivers/net/ethernet/marvell/sky2.c   | 2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 2 +-
 drivers/net/ethernet/micrel/ks8851.c  | 2 +-
 drivers/net/ethernet/micrel/ks8851_mll.c  | 2 +-
 drivers/net/ethernet/nxp/lpc_eth.c| 2 +-
 drivers/net/ethernet/qualcomm/qca_spi.c   | 2 +-
 drivers/net/ethernet/qualcomm/qca_uart.c  | 2 +-
 drivers/net/ethernet/renesas/ravb_main.c  | 2 +-
 drivers/net/ethernet/renesas/sh_eth.c | 2 +-
 drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c   | 2 +-
 drivers/net/ethernet/socionext/sni_ave.c  | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 drivers/net/ethernet/ti/cpsw.c| 2 +-
 drivers/net/ethernet/ti/netcp_core.c  | 2 +-
 drivers/net/ethernet/wiznet/w5100.c   | 2 +-
 drivers/net/ethernet/xilinx/ll_temac_main.c   | 2 +-
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +-
 drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 +-
 drivers/staging/octeon/ethernet.c | 2 +-
 net/dsa/slave.c   | 2 +-
 net/ethernet/eth.c| 2 +-
 47 files changed, 47 insertions(+), 47 deletions(-)

-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 2/3] staging: vchiq: revert "switch to wait_for_completion_killable"

2019-05-06 Thread Nicolas Saenz Julienne 
Hi Dan, thanks for reviewing.

On Mon, 2019-05-06 at 18:20 +0300, Dan Carpenter wrote:
> On Mon, May 06, 2019 at 04:40:29PM +0200, Nicolas Saenz Julienne wrote:
> > @@ -1740,7 +1740,8 @@ parse_rx_slots(struct vchiq_state *state)
> > >bulk_rx : >bulk_tx;
> >  
> > DEBUG_TRACE(PARSE_LINE);
> > -   if (mutex_lock_killable(>bulk_mutex)) {
> > +   if (mutex_lock_killable(
> > +   >bulk_mutex) != 0) {
> 
> This series does't add != 0 consistently...  Personally, I would prefer
> we just leave it out.  I use != 0 for two things.  1)  When I'm talking
> about the number zero.
> 
>   if (len == 0) {
> 
> Or with strcmp():
> 
>   if (strcmp(a, b) == 0) { // a equals b
>   if (strcmp(a, b) < 0) {  // a less than b.
> 
> But here zero means no errors, so I would just leave it out...

I agree, I'll fix it.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: RFC: kpc2000 driver naming

2019-05-06 Thread Matt Sickler 
>-Original Message-
>From: 'gre...@linuxfoundation.org' 
>On Sun, May 05, 2019 at 10:14:17PM +, Matt Sickler wrote:
>> The I2C and SPI drivers don't depend on anything other than the I2C
>> and SPI subsystems.  Actually, they might be depending on the kp2000
>> driver having the PCIe registers mapped into kernel space instead of doing
>> that themselves.
>> I'm not sure if that's the correct thing to do or not, so that might
>> be something to look closely at with all these drivers.
>
>Are all of these drivers needed for this hardware to work?  Should they even
>be separate drivers or should they all be mushed into one?  Can anyone do
>anything useful with just one of them?
>
>> Yes, all 4 drivers are required for proper functioning of the card.
>> SPI is used to reprogram the flash chips that store the FPGA
>> bitstream.  I2C is used for monitoring and programming clock
>> generators.  DMA is required for some parts of other cores.
>
>So should we just merge this into one driver at link time?  That would make
>more sense, right?

Yes.  All the drivers are required for the hardware to work.
In some sense, they "could" be used independently, but most likely only within
Daktronics hardware.  I guess if someone else had an FPGA design that needed a
SPI controller, they could reuse our driver as long as their FPGA implemented
a compatible SPI controller.

One thing I would be concerned with would be future FPGA designs that need to
mix-and-match.
For example (using new names), today we have the P2K card which uses the dak-p2k
main driver, and dak-i2c, dak-spi, and dak-dma "sub-drivers".
Perhaps the next generation hardware would need to use a new dak-p3k main driver
but can reuse the dak-i2c and dak-dma sub-drivers.  And maybe it needs a new
dak-spi-v2 driver (because something in the hardware changed in an incompatible
way).  This is all hypothetical though - it could range from complete driver
reuse to needing all new drivers for everything - we won't know for sure until
the new hardware designs ramp up in the next 6-12 months.

If there's a way to do link-time trickery to get all 4 drivers compiled into
one .ko, I'd be fine with that.  I do think it's a good idea to keep them at
least slightly separated to facilitate that mix-and-match scenario as well as
just ease of maintaining the code.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 2/3] staging: vchiq: revert "switch to wait_for_completion_killable"

2019-05-06 Thread Dan Carpenter 
On Mon, May 06, 2019 at 04:40:29PM +0200, Nicolas Saenz Julienne wrote:
> @@ -1740,7 +1740,8 @@ parse_rx_slots(struct vchiq_state *state)
>   >bulk_rx : >bulk_tx;
>  
>   DEBUG_TRACE(PARSE_LINE);
> - if (mutex_lock_killable(>bulk_mutex)) {
> + if (mutex_lock_killable(
> + >bulk_mutex) != 0) {

This series does't add != 0 consistently...  Personally, I would prefer
we just leave it out.  I use != 0 for two things.  1)  When I'm talking
about the number zero.

if (len == 0) {

Or with strcmp():

if (strcmp(a, b) == 0) { // a equals b
if (strcmp(a, b) < 0) {  // a less than b.

But here zero means no errors, so I would just leave it out...

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: RFC: kpc2000 driver naming

2019-05-06 Thread 'gre...@linuxfoundation.org' 
On Mon, May 06, 2019 at 02:38:16PM +, Matt Sickler wrote:
> >-Original Message-
> >From: 'gre...@linuxfoundation.org' 
> >On Sun, May 05, 2019 at 10:14:17PM +, Matt Sickler wrote:
> >> The I2C and SPI drivers don't depend on anything other than the I2C
> >> and SPI subsystems.  Actually, they might be depending on the kp2000
> >> driver having the PCIe registers mapped into kernel space instead of doing
> >> that themselves.
> >> I'm not sure if that's the correct thing to do or not, so that might
> >> be something to look closely at with all these drivers.
> >
> >Are all of these drivers needed for this hardware to work?  Should they even
> >be separate drivers or should they all be mushed into one?  Can anyone do
> >anything useful with just one of them?
> >
> >> Yes, all 4 drivers are required for proper functioning of the card.
> >> SPI is used to reprogram the flash chips that store the FPGA
> >> bitstream.  I2C is used for monitoring and programming clock
> >> generators.  DMA is required for some parts of other cores.
> >
> >So should we just merge this into one driver at link time?  That would make
> >more sense, right?
> 
> Yes.  All the drivers are required for the hardware to work.
> In some sense, they "could" be used independently, but most likely only within
> Daktronics hardware.  I guess if someone else had an FPGA design that needed a
> SPI controller, they could reuse our driver as long as their FPGA implemented
> a compatible SPI controller.
> 
> One thing I would be concerned with would be future FPGA designs that need to
> mix-and-match.
> For example (using new names), today we have the P2K card which uses the 
> dak-p2k
> main driver, and dak-i2c, dak-spi, and dak-dma "sub-drivers".
> Perhaps the next generation hardware would need to use a new dak-p3k main 
> driver
> but can reuse the dak-i2c and dak-dma sub-drivers.  And maybe it needs a new
> dak-spi-v2 driver (because something in the hardware changed in an 
> incompatible
> way).  This is all hypothetical though - it could range from complete driver
> reuse to needing all new drivers for everything - we won't know for sure until
> the new hardware designs ramp up in the next 6-12 months.
> 
> If there's a way to do link-time trickery to get all 4 drivers compiled into
> one .ko, I'd be fine with that.  I do think it's a good idea to keep them at
> least slightly separated to facilitate that mix-and-match scenario as well as
> just ease of maintaining the code.

Ok, keeping them separate is fine, just wanted to make sure, thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH net-next 1/3] net: ethernet: support of_get_mac_address new ERR_PTR error

2019-05-06 Thread Dan Carpenter 
On Mon, May 06, 2019 at 11:58:35AM +0200, Petr Štetiar wrote:
> There was NVMEM support added to of_get_mac_address, so it could now return
> ERR_PTR encoded error values, so we need to adjust all current users of
> of_get_mac_address to this new fact.

We need a Fixes tag so we can look at the commit which adds NVMEM
support.

It's not clear to me that anyone ever applied that patch.  If not then
who hoo!  Let's not apply it.  But if it has been committed then it has
a git hash.

regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 3/3] staging: vchiq: make wait events interruptible

2019-05-06 Thread Nicolas Saenz Julienne 
The killable version of wait_event() is meant to be used on situations
where it should not fail at all costs, but still have the convenience of
being able to kill it if really necessary. Wait events in VCHIQ doesn't
fit this criteria, as it's mainly used as an interface to V4L2 and ALSA
devices.

Fixes: 852b2876a8a8 ("staging: vchiq: rework remove_event handling")
Signed-off-by: Nicolas Saenz Julienne 
---
 .../vc04_services/interface/vchiq_arm/vchiq_core.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 50189223f05b..9676f83dcf78 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -425,13 +425,21 @@ remote_event_create(wait_queue_head_t *wq, struct 
remote_event *event)
init_waitqueue_head(wq);
 }
 
+/*
+ * All the event waiting routines in VCHIQ used a custom semaphore
+ * implementation that filtered most signals. This achieved a behaviour similar
+ * to the "killable" family of functions. While cleaning up this code all the
+ * routines where switched to the "interruptible" family of functions, as the
+ * former was deemed unjustified and the use "killable" set all VCHIQ's
+ * threads in D state.
+ */
 static inline int
 remote_event_wait(wait_queue_head_t *wq, struct remote_event *event)
 {
if (!event->fired) {
event->armed = 1;
dsb(sy);
-   if (wait_event_killable(*wq, event->fired)) {
+   if (wait_event_interruptible(*wq, event->fired)) {
event->armed = 0;
return 0;
}
-- 
2.21.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 2/3] staging: vchiq: revert "switch to wait_for_completion_killable"

2019-05-06 Thread Nicolas Saenz Julienne 
The killable version of wait_for_completion() is meant to be used on
situations where it should not fail at all costs, but still have the
convenience of being able to kill it if really necessary. VCHIQ doesn't
fit this criteria, as it's mainly used as an interface to V4L2 and ALSA
devices.

Fixes: a772f116702e ("staging: vchiq: switch to wait_for_completion_killable")
Signed-off-by: Nicolas Saenz Julienne 

This reverts commit a772f116702e3f0afdd7e6acadc1b8fb3b20b9ff.
---
 .../interface/vchiq_arm/vchiq_arm.c   | 21 ++-
 .../interface/vchiq_arm/vchiq_core.c  | 21 ++-
 .../interface/vchiq_arm/vchiq_util.c  |  6 +++---
 3 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 064d0db4c51e..ccfb8218b83c 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -560,7 +560,8 @@ add_completion(VCHIQ_INSTANCE_T instance, VCHIQ_REASON_T 
reason,
vchiq_log_trace(vchiq_arm_log_level,
"%s - completion queue full", __func__);
DEBUG_COUNT(COMPLETION_QUEUE_FULL_COUNT);
-   if (wait_for_completion_killable( >remove_event)) {
+   if (wait_for_completion_interruptible(
+   >remove_event)) {
vchiq_log_info(vchiq_arm_log_level,
"service_callback interrupted");
return VCHIQ_RETRY;
@@ -671,7 +672,7 @@ service_callback(VCHIQ_REASON_T reason, struct vchiq_header 
*header,
}
 
DEBUG_TRACE(SERVICE_CALLBACK_LINE);
-   if (wait_for_completion_killable(
+   if (wait_for_completion_interruptible(
_service->remove_event)
!= 0) {
vchiq_log_info(vchiq_arm_log_level,
@@ -1006,7 +1007,7 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned 
long arg)
   has been closed until the client library calls the
   CLOSE_DELIVERED ioctl, signalling close_event. */
if (user_service->close_pending &&
-   wait_for_completion_killable(
+   wait_for_completion_interruptible(
_service->close_event))
status = VCHIQ_RETRY;
break;
@@ -1182,7 +1183,7 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned 
long arg)
 
DEBUG_TRACE(AWAIT_COMPLETION_LINE);
mutex_unlock(>completion_mutex);
-   rc = wait_for_completion_killable(
+   rc = wait_for_completion_interruptible(
>insert_event);
mutex_lock(>completion_mutex);
if (rc != 0) {
@@ -1352,7 +1353,7 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned 
long arg)
do {
spin_unlock(_queue_spinlock);
DEBUG_TRACE(DEQUEUE_MESSAGE_LINE);
-   if (wait_for_completion_killable(
+   if (wait_for_completion_interruptible(
_service->insert_event)) {
vchiq_log_info(vchiq_arm_log_level,
"DEQUEUE_MESSAGE interrupted");
@@ -2360,7 +2361,7 @@ vchiq_keepalive_thread_func(void *v)
while (1) {
long rc = 0, uc = 0;
 
-   if (wait_for_completion_killable(_state->ka_evt)
+   if (wait_for_completion_interruptible(_state->ka_evt)
!= 0) {
vchiq_log_error(vchiq_susp_log_level,
"%s interrupted", __func__);
@@ -2611,7 +2612,7 @@ block_resume(struct vchiq_arm_state *arm_state)
write_unlock_bh(_state->susp_res_lock);
vchiq_log_info(vchiq_susp_log_level, "%s wait for previously "
"blocked clients", __func__);
-   if (wait_for_completion_killable_timeout(
+   if (wait_for_completion_interruptible_timeout(
_state->blocked_blocker, timeout_val)
<= 0) {
vchiq_log_error(vchiq_susp_log_level, "%s wait for "
@@ -2637,7 +2638,7 @@ block_resume(struct vchiq_arm_state *arm_state)
write_unlock_bh(_state->susp_res_lock);
vchiq_log_info(vchiq_susp_log_level, "%s wait for resume",
__func__);
-

[PATCH v2 1/3] staging: vchiq_2835_arm: revert "quit using custom down_interruptible()"

2019-05-06 Thread Nicolas Saenz Julienne 
The killable version of down() is meant to be used on situations where
it should not fail at all costs, but still have the convenience of being
able to kill it if really necessary. VCHIQ doesn't fit this criteria, as
it's mainly used as an interface to V4L2 and ALSA devices.

Fixes: ff5979ad8636 ("staging: vchiq_2835_arm: quit using custom 
down_interruptible()")
Signed-off-by: Nicolas Saenz Julienne 
---
 .../staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index dd4898861b83..bfc064a5f884 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -541,7 +541,7 @@ create_pagelist(char __user *buf, size_t count, unsigned 
short type)
(g_cache_line_size - 1 {
char *fragments;
 
-   if (down_killable(_free_fragments_sema)) {
+   if (down_interruptible(_free_fragments_sema) != 0) {
cleanup_pagelistinfo(pagelistinfo);
return NULL;
}
-- 
2.21.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 0/3] staging: vchiq: use interruptible waits

2019-05-06 Thread Nicolas Saenz Julienne 
Hi,
this series tries to address an issue that came up in Raspbian's kernel
tree [1] and upstream distros [2][3].

We adopted some changes that moved wait calls from a custom
implementation to the more standard killable family of functions. Users
complained that all the VCHIQ threads showed up in D state (which is the
expected behaviour).

The custom implementation we deleted tried to mimic the killable family
of functions, yet accepted more signals than the later; SIGKILL |
SIGINT | SIGQUIT | SIGTRAP | SIGSTOP | SIGCONT for the custom
implementation as opposed to plain old SIGKILL.

Raspbian maintainers decided roll back some of those changes and leave
the wait functions as interruptible. Hence creating some divergence
between both trees.

One could argue that not liking having the threads stuck in D state is
not really a software issue. It's more a cosmetic thing that can scare
people when they look at "uptime". On the other hand, if we are ever to
unstage this driver, we'd really need a proper justification for using
the killable family of functions. Which I think it's not really clear at
the moment.

As Raspbian's kernel has been working for a while with interruptible
waits I propose we follow through. If needed we can always go back to
killable. But at least we'll have a proper understanding on the actual
needs. In the end the driver is in staging, and the potential for errors
small.

Regards,
Nicolas

[1] https://github.com/raspberrypi/linux/issues/2881
[2] https://archlinuxarm.org/forum/viewtopic.php?f=65=13485
[3] 
https://lists.fedoraproject.org/archives/list/a...@lists.fedoraproject.org/message/GBXGJ7DOV5CQQXFPOZCXTRD6W4BEPT4Q/

--

Changes since v1:
  - Proplery format revert commits
  - Add code comment to remind of this issue
  - Add Fixes tags

Nicolas Saenz Julienne (3):
  staging: vchiq_2835_arm: revert "quit using custom
down_interruptible()"
  staging: vchiq: revert "switch to wait_for_completion_killable"
  staging: vchiq: make wait events interruptible

 .../interface/vchiq_arm/vchiq_2835_arm.c  |  2 +-
 .../interface/vchiq_arm/vchiq_arm.c   | 21 +++--
 .../interface/vchiq_arm/vchiq_core.c  | 31 ---
 .../interface/vchiq_arm/vchiq_util.c  |  6 ++--
 4 files changed, 35 insertions(+), 25 deletions(-)

-- 
2.21.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/4] staging: iio: ad7150: use FIELD_GET and GENMASK

2019-05-06 Thread Ardelean, Alexandru 
On Sat, 2019-05-04 at 13:43 +0300, Alexandru Ardelean wrote:
> [External]
> 
> 
> On Sat, May 4, 2019 at 1:25 AM Melissa Wen  wrote:
> > 
> > Use the bitfield macro FIELD_GET, and GENMASK to do the shift and mask
> > in
> > one go. This makes the code more readable than explicit masking
> > followed
> > by a shift.
> > 
> 
> This looks neat.
> I'd have to remember to ack it from my work email.

Acked-by: Alexandru Ardelean 

> 
> One minor comment inline, which would be the object of a new patch.
> 
> > Signed-off-by: Melissa Wen 
> > ---
> >  drivers/staging/iio/cdc/ad7150.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/iio/cdc/ad7150.c
> > b/drivers/staging/iio/cdc/ad7150.c
> > index 24601ba7db88..4ba46fb6ac02 100644
> > --- a/drivers/staging/iio/cdc/ad7150.c
> > +++ b/drivers/staging/iio/cdc/ad7150.c
> > @@ -5,6 +5,7 @@
> >   * Copyright 2010-2011 Analog Devices Inc.
> >   */
> > 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -44,6 +45,9 @@
> >  #define AD7150_SN0_REG 0x16
> >  #define AD7150_ID_REG  0x17
> > 
> > +/* AD7150 masks */
> > +#define AD7150_THRESHTYPE_MSK  GENMASK(6, 5)
> > +
> >  /**
> >   * struct ad7150_chip_info - instance specific chip data
> >   * @client: i2c client for this device
> > @@ -136,7 +140,7 @@ static int ad7150_read_event_config(struct iio_dev
> > *indio_dev,
> > if (ret < 0)
> > return ret;
> > 
> > -   threshtype = (ret >> 5) & 0x03;
> > +   threshtype = FIELD_GET(AD7150_THRESHTYPE_MSK, ret);
> > adaptive = !!(ret & 0x80);
> 
> Why not also do something similar for the `adaptive` value ?
> 
> > 
> > switch (type) {
> > --
> > 2.20.1
> > 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: erofs: set sb->s_root to NULL when failing from __getname()

2019-05-06 Thread Gao Xiang 
Hi Chengguang,

On 2019/5/6 ??7:01, Chengguang Xu wrote:
> Set sb->s_root to NULL when failing from __getname(),
> so that we can avoid double dput and unnecessary operations
> in generic_shutdown_super().
> 
> Signed-off-by: Chengguang Xu 

Thanks for catching this issue and it makes sense.

Reviewed-by: Gao Xiang 

Thanks,
Gao Xiang

> ---
>  drivers/staging/erofs/super.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c
> index 15c784fba879..c8981662a49b 100644
> --- a/drivers/staging/erofs/super.c
> +++ b/drivers/staging/erofs/super.c
> @@ -459,6 +459,7 @@ static int erofs_read_super(struct super_block *sb,
>*/
>  err_devname:
>   dput(sb->s_root);
> + sb->s_root = NULL;
>  err_iget:
>  #ifdef EROFS_FS_HAS_MANAGED_CACHE
>   iput(sbi->managed_cache);
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: erofs: set sb->s_root to NULL when failing from __getname()

2019-05-06 Thread Chengguang Xu 
Set sb->s_root to NULL when failing from __getname(),
so that we can avoid double dput and unnecessary operations
in generic_shutdown_super().

Signed-off-by: Chengguang Xu 
---
 drivers/staging/erofs/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c
index 15c784fba879..c8981662a49b 100644
--- a/drivers/staging/erofs/super.c
+++ b/drivers/staging/erofs/super.c
@@ -459,6 +459,7 @@ static int erofs_read_super(struct super_block *sb,
 */
 err_devname:
dput(sb->s_root);
+   sb->s_root = NULL;
 err_iget:
 #ifdef EROFS_FS_HAS_MANAGED_CACHE
iput(sbi->managed_cache);
-- 
2.20.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH net-next 1/3] net: ethernet: support of_get_mac_address new ERR_PTR error

2019-05-06 Thread Petr Štetiar 
There was NVMEM support added to of_get_mac_address, so it could now return
ERR_PTR encoded error values, so we need to adjust all current users of
of_get_mac_address to this new fact.

While at it, remove superfluous is_valid_ether_addr as the MAC address
returned from of_get_mac_address is always valid and checked by
is_valid_ether_addr anyway.

Signed-off-by: Petr Štetiar 
---

 This is defacto v5 of the previous 05/10 patch in the series, but since the
 v4 of this 05/10 patch wasn't picked up by the patchwork for some unknown
 reason, this patch wasn't applied with the other 9 patches in the series, so
 I'm resending it as a separate patch of this fixup series.

 Changes since v3:

  * IS_ERR_OR_NULL -> IS_ERR

 Changes since v4:

  * I've just blindly replaced IS_ERR_OR_NULL with IS_ERR, but I've just
realized, that in some cases we still need to check for NULL, so I've
corrected it in following drivers/files:

 - broadcom/bgmac-bcma.c
 - marvell/pxa168_eth.c
 - samsung/sxgbe/sxgbe_platform.c
 - stmicro/stmmac/stmmac_main.c
 - wiznet/w5100.c
 - ethernet/eth.c

 drivers/net/ethernet/aeroflex/greth.c | 2 +-
 drivers/net/ethernet/allwinner/sun4i-emac.c   | 2 +-
 drivers/net/ethernet/altera/altera_tse_main.c | 2 +-
 drivers/net/ethernet/arc/emac_main.c  | 2 +-
 drivers/net/ethernet/aurora/nb8800.c  | 2 +-
 drivers/net/ethernet/broadcom/bcmsysport.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-bcma.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-platform.c| 2 +-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c| 2 +-
 drivers/net/ethernet/cavium/octeon/octeon_mgmt.c  | 2 +-
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 2 +-
 drivers/net/ethernet/davicom/dm9000.c | 2 +-
 drivers/net/ethernet/ethoc.c  | 2 +-
 drivers/net/ethernet/ezchip/nps_enet.c| 2 +-
 drivers/net/ethernet/freescale/fec_main.c | 2 +-
 drivers/net/ethernet/freescale/fec_mpc52xx.c  | 2 +-
 drivers/net/ethernet/freescale/fman/mac.c | 2 +-
 drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 2 +-
 drivers/net/ethernet/freescale/gianfar.c  | 2 +-
 drivers/net/ethernet/freescale/ucc_geth.c | 2 +-
 drivers/net/ethernet/hisilicon/hisi_femac.c   | 2 +-
 drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 2 +-
 drivers/net/ethernet/lantiq_xrx200.c  | 2 +-
 drivers/net/ethernet/marvell/mv643xx_eth.c| 2 +-
 drivers/net/ethernet/marvell/mvneta.c | 2 +-
 drivers/net/ethernet/marvell/pxa168_eth.c | 2 +-
 drivers/net/ethernet/marvell/sky2.c   | 2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 2 +-
 drivers/net/ethernet/micrel/ks8851.c  | 2 +-
 drivers/net/ethernet/micrel/ks8851_mll.c  | 2 +-
 drivers/net/ethernet/nxp/lpc_eth.c| 2 +-
 drivers/net/ethernet/qualcomm/qca_spi.c   | 2 +-
 drivers/net/ethernet/qualcomm/qca_uart.c  | 2 +-
 drivers/net/ethernet/renesas/ravb_main.c  | 2 +-
 drivers/net/ethernet/renesas/sh_eth.c | 2 +-
 drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c   | 2 +-
 drivers/net/ethernet/socionext/sni_ave.c  | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 drivers/net/ethernet/ti/cpsw.c| 2 +-
 drivers/net/ethernet/ti/netcp_core.c  | 2 +-
 drivers/net/ethernet/wiznet/w5100.c   | 2 +-
 drivers/net/ethernet/xilinx/ll_temac_main.c   | 2 +-
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +-
 drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 +-
 net/ethernet/eth.c| 2 +-
 45 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/drivers/net/ethernet/aeroflex/greth.c 
b/drivers/net/ethernet/aeroflex/greth.c
index 47e5984..7c5cf02 100644
--- a/drivers/net/ethernet/aeroflex/greth.c
+++ b/drivers/net/ethernet/aeroflex/greth.c
@@ -1459,7 +1459,7 @@ static int greth_of_probe(struct platform_device *ofdev)
const u8 *addr;
 
addr = of_get_mac_address(ofdev->dev.of_node);
-   if (addr) {
+   if (!IS_ERR(addr)) {
for (i = 0; i < 6; i++)
macaddr[i] = (unsigned int) addr[i];
} else {
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c 
b/drivers/net/ethernet/allwinner/sun4i-emac.c
index e1acafa..37ebd89 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -870,7 +870,7 @@ static int emac_probe(struct platform_device *pdev)
 
/* Read MAC-address from DT */
mac_addr = of_get_mac_address(np);
-   if (mac_addr)
+   if (!IS_ERR(mac_addr))

[PATCH net-next 2/3] net: dsa: support of_get_mac_address new ERR_PTR error

2019-05-06 Thread Petr Štetiar 
There was NVMEM support added to of_get_mac_address, so it could now
return ERR_PTR encoded error values, so we need to adjust all current
users of of_get_mac_address to this new fact.

While at it, remove superfluous is_valid_ether_addr as the MAC address
returned from of_get_mac_address is always valid and checked by
is_valid_ether_addr anyway.

Signed-off-by: Petr Štetiar 
---
 net/dsa/slave.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 316bce9..2e1deef 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1418,7 +1418,7 @@ int dsa_slave_create(struct dsa_port *port)
NETIF_F_HW_VLAN_CTAG_FILTER;
slave_dev->hw_features |= NETIF_F_HW_TC;
slave_dev->ethtool_ops = _slave_ethtool_ops;
-   if (port->mac && is_valid_ether_addr(port->mac))
+   if (!IS_ERR_OR_NULL(port->mac))
ether_addr_copy(slave_dev->dev_addr, port->mac);
else
eth_hw_addr_inherit(slave_dev, master);
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH net-next 3/3] staging: octeon-ethernet: Fix of_get_mac_address ERR_PTR check

2019-05-06 Thread Petr Štetiar 
Commit 284eb160681c ("staging: octeon-ethernet: support
of_get_mac_address new ERR_PTR error") has introduced checking for
ERR_PTR encoded error value from of_get_mac_address with IS_ERR macro,
which is not sufficient in this case, as the mac variable is set to NULL
initialy and if the kernel is compiled without DT support this NULL
would get passed to IS_ERR, which would lead to the wrong decision and
would pass that NULL pointer and invalid MAC address further.

Fixes: 284eb160681c ("staging: octeon-ethernet: support of_get_mac_address new 
ERR_PTR error")
Signed-off-by: Petr Štetiar 
---
 drivers/staging/octeon/ethernet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/octeon/ethernet.c 
b/drivers/staging/octeon/ethernet.c
index 2b03018..8847a11c2 100644
--- a/drivers/staging/octeon/ethernet.c
+++ b/drivers/staging/octeon/ethernet.c
@@ -421,7 +421,7 @@ int cvm_oct_common_init(struct net_device *dev)
if (priv->of_node)
mac = of_get_mac_address(priv->of_node);
 
-   if (!IS_ERR(mac))
+   if (!IS_ERR_OR_NULL(mac))
ether_addr_copy(dev->dev_addr, mac);
else
eth_hw_addr_random(dev);
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH net-next 0/3] of_get_mac_address ERR_PTR fixes

2019-05-06 Thread Petr Štetiar 
Hi,

this patch series is an attempt to fix the mess, I've somehow managed to
introduce.

First patch in this series is defacto v5 of the previous 05/10 patch in the
series, but since the v4 of this 05/10 patch wasn't picked up by the
patchwork for some unknown reason, this patch wasn't applied with the other
9 patches in the series, so I'm resending it as a separate patch of this
fixup series again.

Second patch is a result of this rebase against net-next tree, where I was
checking again all current users of of_get_mac_address and found out, that
there's new one in DSA, so I've converted this user to the new ERR_PTR
encoded error value as well.

Third patch which was sent as v5 wasn't considered for merge, but I still
think, that we need to check for possible NULL value, thus current IS_ERR
check isn't sufficient and we need to use IS_ERR_OR_NULL instead.

Cheers,

Petr

Petr Štetiar (3):
  net: ethernet: support of_get_mac_address new ERR_PTR error
  net: dsa: support of_get_mac_address new ERR_PTR error
  staging: octeon-ethernet: Fix of_get_mac_address ERR_PTR check

 drivers/net/ethernet/aeroflex/greth.c | 2 +-
 drivers/net/ethernet/allwinner/sun4i-emac.c   | 2 +-
 drivers/net/ethernet/altera/altera_tse_main.c | 2 +-
 drivers/net/ethernet/arc/emac_main.c  | 2 +-
 drivers/net/ethernet/aurora/nb8800.c  | 2 +-
 drivers/net/ethernet/broadcom/bcmsysport.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-bcma.c| 2 +-
 drivers/net/ethernet/broadcom/bgmac-platform.c| 2 +-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c| 2 +-
 drivers/net/ethernet/cavium/octeon/octeon_mgmt.c  | 2 +-
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 2 +-
 drivers/net/ethernet/davicom/dm9000.c | 2 +-
 drivers/net/ethernet/ethoc.c  | 2 +-
 drivers/net/ethernet/ezchip/nps_enet.c| 2 +-
 drivers/net/ethernet/freescale/fec_main.c | 2 +-
 drivers/net/ethernet/freescale/fec_mpc52xx.c  | 2 +-
 drivers/net/ethernet/freescale/fman/mac.c | 2 +-
 drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 2 +-
 drivers/net/ethernet/freescale/gianfar.c  | 2 +-
 drivers/net/ethernet/freescale/ucc_geth.c | 2 +-
 drivers/net/ethernet/hisilicon/hisi_femac.c   | 2 +-
 drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 2 +-
 drivers/net/ethernet/lantiq_xrx200.c  | 2 +-
 drivers/net/ethernet/marvell/mv643xx_eth.c| 2 +-
 drivers/net/ethernet/marvell/mvneta.c | 2 +-
 drivers/net/ethernet/marvell/pxa168_eth.c | 2 +-
 drivers/net/ethernet/marvell/sky2.c   | 2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 2 +-
 drivers/net/ethernet/micrel/ks8851.c  | 2 +-
 drivers/net/ethernet/micrel/ks8851_mll.c  | 2 +-
 drivers/net/ethernet/nxp/lpc_eth.c| 2 +-
 drivers/net/ethernet/qualcomm/qca_spi.c   | 2 +-
 drivers/net/ethernet/qualcomm/qca_uart.c  | 2 +-
 drivers/net/ethernet/renesas/ravb_main.c  | 2 +-
 drivers/net/ethernet/renesas/sh_eth.c | 2 +-
 drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c   | 2 +-
 drivers/net/ethernet/socionext/sni_ave.c  | 2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 drivers/net/ethernet/ti/cpsw.c| 2 +-
 drivers/net/ethernet/ti/netcp_core.c  | 2 +-
 drivers/net/ethernet/wiznet/w5100.c   | 2 +-
 drivers/net/ethernet/xilinx/ll_temac_main.c   | 2 +-
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +-
 drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 +-
 drivers/staging/octeon/ethernet.c | 2 +-
 net/dsa/slave.c   | 2 +-
 net/ethernet/eth.c| 2 +-
 47 files changed, 47 insertions(+), 47 deletions(-)

-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 00/26] compat_ioctl: cleanups

2019-05-06 Thread Andy Shevchenko 
On Tue, Apr 16, 2019 at 11:23 PM Arnd Bergmann  wrote:
>
> Hi Al,
>
> It took me way longer than I had hoped to revisit this series, see
> https://lore.kernel.org/lkml/20180912150142.157913-1-a...@arndb.de/
> for the previously posted version.
>
> I've come to the point where all conversion handlers and most
> COMPATIBLE_IOCTL() entries are gone from this file, but for
> now, this series only has the parts that have either been reviewed
> previously, or that are simple enough to include.
>
> The main missing piece is the SG_IO/SG_GET_REQUEST_TABLE conversion.
> I'll post the patches I made for that later, as they need more
> testing and review from the scsi maintainers.
>
> I hope you can still take these for the coming merge window, unless
> new problems come up.

>  drivers/platform/x86/wmi.c  |   2 +-

Acked-by: Andy Shevchenko 

-- 
With Best Regards,
Andy Shevchenko
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: RFC: kpc2000 driver naming

2019-05-06 Thread 'gre...@linuxfoundation.org' 
On Sun, May 05, 2019 at 10:14:17PM +, Matt Sickler wrote:
> 
> >-Original Message-
> >From: 'gre...@linuxfoundation.org' 
> >On Fri, May 03, 2019 at 10:24:00PM +, Matt Sickler wrote:
> >> Hello,
> >>
> >> Recently Greg KH posted the first set of drivers for our PCIe device
> >(kpc2000) and shortly after that I posted the kpc2000_dma driver.   I was
> >wondering about naming / structure standards in the Linux kernel.
> >> First, a real quick background on these devices:  Daktronics makes a PCIe
> >card with an FPGA on it to drive our LED displays (and other processing 
> >tasks).
> >Inside the FPGA, we use something similar to AXI-4 to divide the PCIe BAR
> >register space [1] into separate "IP cores".  The kpc2000 driver is 
> >responsible
> >for probing the PCIe device, doing some basic setup (mapping the BAR,
> >setting up an IRQ, PCIe configuration, etc) and then enumerating these
> >"cores".  Enumeration of the cores is facilitated by the "board info" core 
> >that is
> >always at the beginning of the BAR and has a defined format.   Most of the
> >cores are controlled entirely by userspace - the driver will add a UIO sub
> >device for each one which userspace uses to control FPGA registers.   Only 3
> >core types are handled by drivers: DMA, I2C, SPI.  These are IP cores inside
> >the FPGA that (in the case of i2c and spi) interact with other physical 
> >devices
> >on the PCIe card.
> >> Currently, we only have the one PCIe device (the "P2K" card) but we have
> >more on our roadmap (one we've been calling "p3k" internally).   I'm 99%
> >confident that the I2C and SPI cores will be exactly the same on the new FPGA
> >design.   I'm 80% confident that the DMA engines themselves will be exactly
> >the same on the new FPGA design.   The next card PCIe driver will quite 
> >likely
> >be separate from the kpc2000 driver because how bitstreams are stored /
> >loaded / configured is changing due to using a newer FPGA.  There will likely
> >be common code between the two.
> >
> >Please wrap your emails at a sane column, otherwise this is just a huge wall 
> >of
> >text that is hard to read/understand.
> 
> We use Outlook and Office 365, so I figured the emails were going to be
> formatted badly.  Just for clarity, are you saying I should hard wrap (insert
> newlines myself) at an 80-column boundary?

If your email client forces that to be the only way, yes :(

> >> Now on to my actual questions: Once the drivers are "good enough" to be
> >moved outside of staging, I'm wondering where the drivers will end up and
> >what their names will/should be.
> >> Since the I2C and SPI drivers are single-file, I'm guessing they're going 
> >> to
> >move to drivers/i2c/busses/i2c-dak/ and drivers/spi/spi-dak/, respectively.  
> >I
> >tweaked the names, since "i2c-dak" and "spi-dak" make more sense to me
> >than "kpc_i2c" and "kpc_spi".
> >
> >Feel free to rename them to whatever you want, I just randomly picked a
> >name when I did the import of the drivers.
> >
> >> So that leaves the DMA and main PCIe drivers.  Where do those end up in
> >the tree?   Would "dak-dma" and "dak-p2k" (and eventually "dak-p3k") make
> >more sense as names for those drivers?
> >
> >Maybe, as long as it is a "unique" name, that's all that should matter.
> >The subsystem maintainers of those areas might care more, but you can deal
> >with that when you get closer to moving the code out of staging.
> >
> >> The final question relates to how Kconfig entries are setup.   The
> >> I2C, SPI, and DMA drivers could be "selected" on their own (even if
> >> the "dak-p2k" and "dak-p3k" drivers aren't selected), but that doesn't
> >> make much sense because they'd never get used in that configuration.
> >> Conversely, if you select the "dak-p2k" driver, the I2C, SPI, and DMA
> >> drivers better get selected too, otherwise the device won't function
> >> correctly.  From what I can tell with Kconfig, if A depends on B, you
> >> can't even see (let alone select) A without already selecting B.
> >> Right now, the Kconfig entries are setup like this (using the current 
> >> names,
> >not the new ones presented above):
> >>   KPC2000_DMA depends on KPC2000 (this compiles the kpc2000_dma
> >driver)
> >>   KPC2000_I2C depends on KPC2000 && I2C (this compiles the kpc2000_i2c
> >driver)
> >>   KPC2000_SPI depends on KPC2000 && SPI (this compiles the kpc2000_spi
> >driver)
> >>   KPC2000_CORE depends on  KPC2000
> >>   KPC2000 depends on PCI (this compiles the kpc2000 driver) Greg,
> >> what is the purpose of the KPC2000_CORE config option?  Nothing (that I
> >see) depends on it, and it doesn't cause any code to get compiled.
> >
> >I don't remember, I guess I thought that was a chunk of code the others all
> >depended on being present?  If that's not the case, please send a patch to 
> >fix
> >that up.
> 
> The I2C and SPI drivers don't depend on anything other than the I2C and SPI
> subsystems.  Actually, they might be depending