[PATCH AUTOSEL 4.19 86/97] net/mlx5e: Remove the false indication of software timestamping support

2018-12-26 Thread Sasha Levin
From: Alaa Hleihel 

[ Upstream commit 4765420439e758bfa4808392d18b0a4cb6f06065 ]

mlx5 driver falsely advertises support of software timestamping.
Fix it by removing the false indication.

Fixes: ef9814deafd0 ("net/mlx5e: Add HW timestamping (TS) support")
Signed-off-by: Alaa Hleihel 
Reviewed-by: Tariq Toukan 
Signed-off-by: Saeed Mahameed 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
index 98dd3e0ada72..5e5423076b03 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
@@ -1101,11 +1101,6 @@ int mlx5e_ethtool_get_ts_info(struct mlx5e_priv *priv,
  struct ethtool_ts_info *info)
 {
struct mlx5_core_dev *mdev = priv->mdev;
-   int ret;
-
-   ret = ethtool_op_get_ts_info(priv->netdev, info);
-   if (ret)
-   return ret;
 
info->phc_index = mlx5_clock_get_ptp_index(mdev);
 
@@ -1113,9 +1108,9 @@ int mlx5e_ethtool_get_ts_info(struct mlx5e_priv *priv,
info->phc_index == -1)
return 0;
 
-   info->so_timestamping |= SOF_TIMESTAMPING_TX_HARDWARE |
-SOF_TIMESTAMPING_RX_HARDWARE |
-SOF_TIMESTAMPING_RAW_HARDWARE;
+   info->so_timestamping = SOF_TIMESTAMPING_TX_HARDWARE |
+   SOF_TIMESTAMPING_RX_HARDWARE |
+   SOF_TIMESTAMPING_RAW_HARDWARE;
 
info->tx_types = BIT(HWTSTAMP_TX_OFF) |
 BIT(HWTSTAMP_TX_ON);
-- 
2.19.1



[PATCH AUTOSEL 4.19 94/97] qmi_wwan: Add support for Fibocom NL678 series

2018-12-26 Thread Sasha Levin
From: Jörgen Storvist 

[ Upstream commit 7c3db4105ce8d69bcb5c04bfa9acd1e9119af8d5 ]

Added support for Fibocom NL678 series cellular module QMI interface.
Using QMI_QUIRK_SET_DTR required for Qualcomm MDM9x40 series chipsets.

Signed-off-by: Jörgen Storvist 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index c8872dd5ff5e..f5bac5075386 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1265,6 +1265,7 @@ static const struct usb_device_id products[] = {
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0121, 4)}, /* Quectel EC21 Mini PCIe */
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0191, 4)}, /* Quectel EG91 */
{QMI_FIXED_INTF(0x2c7c, 0x0296, 4)},/* Quectel BG96 */
+   {QMI_QUIRK_SET_DTR(0x2cb7, 0x0104, 4)}, /* Fibocom NL678 series */
 
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
-- 
2.19.1



[PATCH AUTOSEL 4.19 73/97] net: macb: fix random memory corruption on RX with 64-bit DMA

2018-12-26 Thread Sasha Levin
From: Anssi Hannula 

[ Upstream commit e100a897bf9b19089e57f236f2398c9e0538900e ]

64-bit DMA addresses are split in upper and lower halves that are
written in separate fields on GEM. For RX, bit 0 of the address is used
as the ownership bit (RX_USED). When the RX_USED bit is unset the
controller is allowed to write data to the buffer.

The driver does not guarantee that the controller already sees the upper
half when the RX_USED bit is cleared, possibly resulting in the
controller writing an incoming frame to an address with an incorrect
upper half and therefore possibly corrupting unrelated system memory.

Fix that by adding the necessary DMA memory barrier between the writes.

This corruption was observed on a ZynqMP based system.

Fixes: fff8019a08b6 ("net: macb: Add 64 bit addressing support for GEM")
Signed-off-by: Anssi Hannula 
Acked-by: Harini Katakam 
Tested-by: Claudiu Beznea 
Cc: Nicolas Ferre 
Cc: Michal Simek 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/cadence/macb_main.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index 240fd36b5074..2de9197df074 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -682,6 +682,11 @@ static void macb_set_addr(struct macb *bp, struct 
macb_dma_desc *desc, dma_addr_
if (bp->hw_dma_cap & HW_DMA_CAP_64B) {
desc_64 = macb_64b_desc(bp, desc);
desc_64->addrh = upper_32_bits(addr);
+   /* The low bits of RX address contain the RX_USED bit, clearing
+* of which allows packet RX. Make sure the high bits are also
+* visible to HW at that point.
+*/
+   dma_wmb();
}
 #endif
desc->addr = lower_32_bits(addr);
-- 
2.19.1



[PATCH AUTOSEL 4.19 77/97] lan78xx: Resolve issue with changing MAC address

2018-12-26 Thread Sasha Levin
From: Jason Martinsen 

[ Upstream commit 1551569659c502003926a2067ee76176148a ]

Current state for the lan78xx driver does not allow for changing the
MAC address of the interface, without either removing the module (if
you compiled it that way) or rebooting the machine.  If you attempt to
change the MAC address, ifconfig will show the new address, however,
the system/interface will not respond to any traffic using that
configuration.  A few short-term options to work around this are to
unload the module and reload it with the new MAC address, change the
interface to "promisc", or reboot with the correct configuration to
change the MAC.

This patch enables the ability to change the MAC address via fairly normal 
means...
ifdown 
modify entry in /etc/network/interfaces OR a similar method
ifup 
Then test via any network communication, such as ICMP requests to gateway.

My only test platform for this patch has been a raspberry pi model 3b+.

Signed-off-by: Jason Martinsen 

-

Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/usb/lan78xx.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index c3c9ba44e2a1..8d140495da79 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2335,6 +2335,10 @@ static int lan78xx_set_mac_addr(struct net_device 
*netdev, void *p)
ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
 
+   /* Added to support MAC address changes */
+   ret = lan78xx_write_reg(dev, MAF_LO(0), addr_lo);
+   ret = lan78xx_write_reg(dev, MAF_HI(0), addr_hi | MAF_HI_VALID_);
+
return 0;
 }
 
-- 
2.19.1



[PATCH AUTOSEL 4.19 69/97] x86/mtrr: Don't copy uninitialized gentry fields back to userspace

2018-12-26 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit 32043fa065b51e0b1433e48d118821c71b5cd65d ]

Currently the copy_to_user of data in the gentry struct is copying
uninitiaized data in field _pad from the stack to userspace.

Fix this by explicitly memset'ing gentry to zero, this also will zero any
compiler added padding fields that may be in struct (currently there are
none).

Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")

Fixes: b263b31e8ad6 ("x86, mtrr: Use explicit sizing and padding for the 64-bit 
ioctls")
Signed-off-by: Colin Ian King 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Tyler Hicks 
Cc: secur...@kernel.org
Link: https://lkml.kernel.org/r/20181218172956.1440-1-colin.k...@canonical.com
Signed-off-by: Sasha Levin 
---
 arch/x86/kernel/cpu/mtrr/if.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/cpu/mtrr/if.c b/arch/x86/kernel/cpu/mtrr/if.c
index 40eee6cc4124..254683b503a9 100644
--- a/arch/x86/kernel/cpu/mtrr/if.c
+++ b/arch/x86/kernel/cpu/mtrr/if.c
@@ -165,6 +165,8 @@ mtrr_ioctl(struct file *file, unsigned int cmd, unsigned 
long __arg)
struct mtrr_gentry gentry;
void __user *arg = (void __user *) __arg;
 
+   memset(, 0, sizeof(gentry));
+
switch (cmd) {
case MTRRIOC_ADD_ENTRY:
case MTRRIOC_SET_ENTRY:
-- 
2.19.1



[PATCH AUTOSEL 4.19 62/97] net: hns: Add mac pcs config when enable|disable mac

2018-12-26 Thread Sasha Levin
From: Yonglong Liu 

[ Upstream commit 726ae5c9e5f0c18eca8ea5296b526242c3e89822 ]

In some case, when mac enable|disable and adjust link, may cause hard to
link(or abnormal) between mac and phy. This patch adds the code for rx PCS
to avoid this bug.

Disable the rx PCS when driver disable the gmac, and enable the rx PCS
when driver enable the mac.

Signed-off-by: Yonglong Liu 
Signed-off-by: Peng Li 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 14 ++
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h  |  1 +
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
index 09e4061d1fa6..aa2c25d7a61d 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
@@ -67,11 +67,14 @@ static void hns_gmac_enable(void *mac_drv, enum 
mac_commom_mode mode)
struct mac_driver *drv = (struct mac_driver *)mac_drv;
 
/*enable GE rX/tX */
-   if ((mode == MAC_COMM_MODE_TX) || (mode == MAC_COMM_MODE_RX_AND_TX))
+   if (mode == MAC_COMM_MODE_TX || mode == MAC_COMM_MODE_RX_AND_TX)
dsaf_set_dev_bit(drv, GMAC_PORT_EN_REG, GMAC_PORT_TX_EN_B, 1);
 
-   if ((mode == MAC_COMM_MODE_RX) || (mode == MAC_COMM_MODE_RX_AND_TX))
+   if (mode == MAC_COMM_MODE_RX || mode == MAC_COMM_MODE_RX_AND_TX) {
+   /* enable rx pcs */
+   dsaf_set_dev_bit(drv, GMAC_PCS_RX_EN_REG, 0, 0);
dsaf_set_dev_bit(drv, GMAC_PORT_EN_REG, GMAC_PORT_RX_EN_B, 1);
+   }
 }
 
 static void hns_gmac_disable(void *mac_drv, enum mac_commom_mode mode)
@@ -79,11 +82,14 @@ static void hns_gmac_disable(void *mac_drv, enum 
mac_commom_mode mode)
struct mac_driver *drv = (struct mac_driver *)mac_drv;
 
/*disable GE rX/tX */
-   if ((mode == MAC_COMM_MODE_TX) || (mode == MAC_COMM_MODE_RX_AND_TX))
+   if (mode == MAC_COMM_MODE_TX || mode == MAC_COMM_MODE_RX_AND_TX)
dsaf_set_dev_bit(drv, GMAC_PORT_EN_REG, GMAC_PORT_TX_EN_B, 0);
 
-   if ((mode == MAC_COMM_MODE_RX) || (mode == MAC_COMM_MODE_RX_AND_TX))
+   if (mode == MAC_COMM_MODE_RX || mode == MAC_COMM_MODE_RX_AND_TX) {
+   /* disable rx pcs */
+   dsaf_set_dev_bit(drv, GMAC_PCS_RX_EN_REG, 0, 1);
dsaf_set_dev_bit(drv, GMAC_PORT_EN_REG, GMAC_PORT_RX_EN_B, 0);
+   }
 }
 
 /* hns_gmac_get_en - get port enable
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index f171d11b9b44..b9733b0b8482 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -534,6 +534,7 @@
 #define GMAC_LD_LINK_COUNTER_REG   0x01D0UL
 #define GMAC_LOOP_REG  0x01DCUL
 #define GMAC_RECV_CONTROL_REG  0x01E0UL
+#define GMAC_PCS_RX_EN_REG 0x01E4UL
 #define GMAC_VLAN_CODE_REG 0x01E8UL
 #define GMAC_RX_OVERRUN_CNT_REG0x01ECUL
 #define GMAC_RX_LENGTHFIELD_ERR_CNT_REG0x01F4UL
-- 
2.19.1



[PATCH AUTOSEL 4.19 52/97] qmi_wwan: Added support for Telit LN940 series

2018-12-26 Thread Sasha Levin
From: Jörgen Storvist 

[ Upstream commit 1986af16e8ed355822600c24b3d2f0be46b573df ]

Added support for the Telit LN940 series cellular modules QMI interface.
QMI_QUIRK_SET_DTR quirk requied for Qualcomm MDM9x40 chipset.

Signed-off-by: Jörgen Storvist 
Acked-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index dada68f279bc..c8872dd5ff5e 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1230,6 +1230,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1bc7, 0x1101, 3)},/* Telit ME910 dual modem */
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)},/* Telit LE920 */
{QMI_QUIRK_SET_DTR(0x1bc7, 0x1201, 2)}, /* Telit LE920, LE920A4 */
+   {QMI_QUIRK_SET_DTR(0x1bc7, 0x1900, 1)}, /* Telit LN940 series */
{QMI_FIXED_INTF(0x1c9e, 0x9801, 3)},/* Telewell TW-3G HSPA+ */
{QMI_FIXED_INTF(0x1c9e, 0x9803, 4)},/* Telewell TW-3G HSPA+ */
{QMI_FIXED_INTF(0x1c9e, 0x9b01, 3)},/* XS Stick W100-2 from 4G 
Systems */
-- 
2.19.1



[PATCH AUTOSEL 4.19 57/97] net: hns: Fixed bug that netdev was opened twice

2018-12-26 Thread Sasha Levin
From: Yonglong Liu 

[ Upstream commit 5778b13b64eca5549d242686f2f91a2c80c8fa40 ]

After resetting dsaf to try to repair chip error such as ecc error,
the net device will be open if net interface is up. But at this time
if there is the users set the net device up with the command ifconfig,
the net device will be opened twice consecutively.

Function napi_enable was called when open device. And Kernel panic will
be occurred if it was called twice consecutively. Such as follow:
static inline void napi_enable(struct napi_struct *n)
{
 BUG_ON(!test_bit(NAPI_STATE_SCHED, >state));
 smp_mb__before_clear_bit();
 clear_bit(NAPI_STATE_SCHED, >state);
}

[37255.571996] Kernel panic - not syncing: BUG!
[37255.595234] Call trace:
[37255.597694] [] dump_backtrace+0x0/0x1a0
[37255.603114] [] show_stack+0x20/0x28
[37255.608187] [] dump_stack+0x98/0xb8
[37255.613258] [] panic+0x10c/0x26c
[37255.618070] [] hns_nic_net_up+0x30c/0x4e0
[37255.623664] [] hns_nic_net_open+0x94/0x12c
[37255.629346] [] __dev_open+0xf4/0x168
[37255.634504] [] __dev_change_flags+0x98/0x15c
[37255.640359] [] dev_change_flags+0x2c/0x68
[37255.769580] [] devinet_ioctl+0x650/0x704
[37255.775086] [] inet_ioctl+0x98/0xb4
[37255.780159] [] sock_do_ioctl+0x44/0x84
[37255.785490] [] sock_ioctl+0x248/0x30c
[37255.790737] [] do_vfs_ioctl+0x480/0x618
[37255.796156] [] SyS_ioctl+0x90/0xa4
[37255.801139] SMP: stopping secondary CPUs
[37255.805079] kbox: catch panic event.
[37255.809586] collected_len = 128928, LOG_BUF_LEN_LOCAL = 131072
[37255.816103] flush cache 0x80003f00  size 0x80
[37255.822192] flush cache 0x80003f00  size 0x80
[37255.828289] flush cache 0x80003f00  size 0x80
[37255.834378] kbox: no notify die func register. no need to notify
[37255.840413] ---[ end Kernel panic - not syncing: BUG!

This patchset fix this bug according to the flag NIC_STATE_DOWN.

Signed-off-by: Yonglong Liu 
Signed-off-by: Peng Li 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/hisilicon/hns/hns_enet.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c 
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index c205a0e4b64b..c9454c4784cb 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -1333,6 +1333,9 @@ static int hns_nic_net_up(struct net_device *ndev)
int i, j;
int ret;
 
+   if (!test_bit(NIC_STATE_DOWN, >state))
+   return 0;
+
ret = hns_nic_init_irq(priv);
if (ret != 0) {
netdev_err(ndev, "hns init irq failed! ret=%d\n", ret);
-- 
2.19.1



[PATCH AUTOSEL 4.19 60/97] net: hns: Avoid net reset caused by pause frames storm

2018-12-26 Thread Sasha Levin
From: Yonglong Liu 

[ Upstream commit a57275d35576fdd89d8c771eedf1e7cf97e0dfa6 ]

There will be a large number of MAC pause frames on the net,
which caused tx timeout of net device. And then the net device
was reset to try to recover it. So that is not useful, and will
cause some other problems.

So need doubled ndev->watchdog_timeo if device watchdog occurred
until watchdog_timeo up to 40s and then try resetting to recover
it.

When collecting dfx information such as hardware registers when tx timeout.
Some registers for count were cleared when read. So need move this task
before update net state which also read the count registers.

Signed-off-by: Yonglong Liu 
Signed-off-by: Peng Li 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/hisilicon/hns/hns_enet.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c 
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 03d959c7a39f..8a53c82c72b4 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -1509,11 +1509,19 @@ static int hns_nic_net_stop(struct net_device *ndev)
 }
 
 static void hns_tx_timeout_reset(struct hns_nic_priv *priv);
+#define HNS_TX_TIMEO_LIMIT (40 * HZ)
 static void hns_nic_net_timeout(struct net_device *ndev)
 {
struct hns_nic_priv *priv = netdev_priv(ndev);
 
-   hns_tx_timeout_reset(priv);
+   if (ndev->watchdog_timeo < HNS_TX_TIMEO_LIMIT) {
+   ndev->watchdog_timeo *= 2;
+   netdev_info(ndev, "watchdog_timo changed to %d.\n",
+   ndev->watchdog_timeo);
+   } else {
+   ndev->watchdog_timeo = HNS_NIC_TX_TIMEOUT;
+   hns_tx_timeout_reset(priv);
+   }
 }
 
 static int hns_nic_do_ioctl(struct net_device *netdev, struct ifreq *ifr,
@@ -2076,11 +2084,11 @@ static void hns_nic_service_task(struct work_struct 
*work)
= container_of(work, struct hns_nic_priv, service_task);
struct hnae_handle *h = priv->ae_handle;
 
+   hns_nic_reset_subtask(priv);
hns_nic_update_link_status(priv->netdev);
h->dev->ops->update_led_status(h);
hns_nic_update_stats(priv->netdev);
 
-   hns_nic_reset_subtask(priv);
hns_nic_service_event_complete(priv);
 }
 
-- 
2.19.1



[PATCH AUTOSEL 4.19 49/97] net/tls: Init routines in create_ctx

2018-12-26 Thread Sasha Levin
From: Atul Gupta 

[ Upstream commit 6c0563e442528733219afe15c749eb2cc365da3f ]

create_ctx is called from tls_init and tls_hw_prot
hence initialize function pointers in common routine.

Signed-off-by: Atul Gupta 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/tls/tls_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index 523622dc74f8..be9c6545e53d 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -555,6 +555,9 @@ static struct tls_context *create_ctx(struct sock *sk)
return NULL;
 
icsk->icsk_ulp_data = ctx;
+   ctx->setsockopt = sk->sk_prot->setsockopt;
+   ctx->getsockopt = sk->sk_prot->getsockopt;
+   ctx->sk_proto_close = sk->sk_prot->close;
return ctx;
 }
 
@@ -685,9 +688,6 @@ static int tls_init(struct sock *sk)
rc = -ENOMEM;
goto out;
}
-   ctx->setsockopt = sk->sk_prot->setsockopt;
-   ctx->getsockopt = sk->sk_prot->getsockopt;
-   ctx->sk_proto_close = sk->sk_prot->close;
 
/* Build IPv6 TLS whenever the address of tcpv6 _prot changes */
if (ip_ver == TLSV6 &&
-- 
2.19.1



[PATCH AUTOSEL 4.19 58/97] net: hns: Clean rx fbd when ae stopped.

2018-12-26 Thread Sasha Levin
From: Yonglong Liu 

[ Upstream commit 31f6b61d810654fb3ef43f4d8afda0f44b142fad ]

If there are packets in hardware when changing the speed or duplex,
it may cause hardware hang up.

This patch adds the code to wait rx fbd clean up when ae stopped.

Signed-off-by: Yonglong Liu 
Signed-off-by: Peng Li 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c 
b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index b52029e26d15..ad1779fc410e 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -379,6 +379,9 @@ static void hns_ae_stop(struct hnae_handle *handle)
 
hns_ae_ring_enable_all(handle, 0);
 
+   /* clean rx fbd. */
+   hns_rcb_wait_fbd_clean(handle->qs, handle->q_num, RCB_INT_FLAG_RX);
+
(void)hns_mac_vm_config_bc_en(mac_cb, 0, false);
 }
 
-- 
2.19.1



[PATCH AUTOSEL 4.19 42/97] scsi: target: iscsi: cxgbit: add missing spin_lock_init()

2018-12-26 Thread Sasha Levin
From: Varun Prakash 

[ Upstream commit 9e6371d3c6913ff1707fb2c0274c9925f7aaef80 ]

Add missing spin_lock_init() for cdev->np_lock.

Signed-off-by: Varun Prakash 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/target/iscsi/cxgbit/cxgbit_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/target/iscsi/cxgbit/cxgbit_main.c 
b/drivers/target/iscsi/cxgbit/cxgbit_main.c
index f3f8856bfb68..c011c826fc26 100644
--- a/drivers/target/iscsi/cxgbit/cxgbit_main.c
+++ b/drivers/target/iscsi/cxgbit/cxgbit_main.c
@@ -58,6 +58,7 @@ static void *cxgbit_uld_add(const struct cxgb4_lld_info *lldi)
return ERR_PTR(-ENOMEM);
 
kref_init(>kref);
+   spin_lock_init(>np_lock);
 
cdev->lldi = *lldi;
 
-- 
2.19.1



[PATCH AUTOSEL 4.19 27/97] ibmvnic: Fix non-atomic memory allocation in IRQ context

2018-12-26 Thread Sasha Levin
From: Thomas Falcon 

[ Upstream commit 1d1bbc37f89b0559c9e913682f2489d89cfde6b8 ]

ibmvnic_reset allocated new reset work item objects in a non-atomic
context. This can be called from a tasklet, generating the output below.
Allocate work items with the GFP_ATOMIC flag instead.

BUG: sleeping function called from invalid context at mm/slab.h:421
in_atomic(): 1, irqs_disabled(): 1, pid: 93, name: kworker/0:2
INFO: lockdep is turned off.
irq event stamp: 66049
hardirqs last  enabled at (66048): [] 
tasklet_action_common.isra.12+0x78/0x1c0
hardirqs last disabled at (66049): [] 
_raw_spin_lock_irqsave+0x48/0xf0
softirqs last  enabled at (66044): [] 
dev_deactivate_queue.constprop.28+0xc8/0x160
softirqs last disabled at (66045): [] 
call_do_softirq+0x14/0x24
CPU: 0 PID: 93 Comm: kworker/0:2 Kdump: loaded Not tainted 
4.20.0-rc6-1-g1b50a8f03706 #7
Workqueue: events linkwatch_event
Call Trace:
[c003fffe7ae0] [c0bc83e4] dump_stack+0xe8/0x164 (unreliable)
[c003fffe7b30] [c015ba0c] ___might_sleep+0x2dc/0x320
[c003fffe7bb0] [c0391514] kmem_cache_alloc_trace+0x3e4/0x440
[c003fffe7c30] [d5b2309c] ibmvnic_reset+0x16c/0x360 [ibmvnic]
[c003fffe7cc0] [d5b29834] ibmvnic_tasklet+0x1054/0x2010 [ibmvnic]
[c003fffe7e00] [c01224c8] tasklet_action_common.isra.12+0xd8/0x1c0
[c003fffe7e60] [c0bf1238] __do_softirq+0x1a8/0x64c
[c003fffe7f90] [c00306e0] call_do_softirq+0x14/0x24
[c003f3967980] [c001ba50] do_softirq_own_stack+0x60/0xb0
[c003f39679c0] [c01218a8] do_softirq+0xa8/0x100
[c003f39679f0] [c0121a74] __local_bh_enable_ip+0x174/0x180
[c003f3967a60] [c0bf003c] _raw_spin_unlock_bh+0x5c/0x80
[c003f3967a90] [c0a8ac78] 
dev_deactivate_queue.constprop.28+0xc8/0x160
[c003f3967ad0] [c0a8c8b0] dev_deactivate_many+0xd0/0x520
[c003f3967b70] [c0a8cd40] dev_deactivate+0x40/0x60
[c003f3967ba0] [c0a5e0c4] linkwatch_do_dev+0x74/0xd0
[c003f3967bd0] [c0a5e694] __linkwatch_run_queue+0x1a4/0x1f0
[c003f3967c30] [c0a5e728] linkwatch_event+0x48/0x60
[c003f3967c50] [c01444e8] process_one_work+0x238/0x710
[c003f3967d20] [c0144a48] worker_thread+0x88/0x4e0
[c003f3967db0] [c014e3a8] kthread+0x178/0x1c0
[c003f3967e20] [c000bfd0] ret_from_kernel_thread+0x5c/0x6c

Signed-off-by: Thomas Falcon 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 5058bd83bdd6..c8704b1690eb 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2055,7 +2055,7 @@ static int ibmvnic_reset(struct ibmvnic_adapter *adapter,
}
}
 
-   rwi = kzalloc(sizeof(*rwi), GFP_KERNEL);
+   rwi = kzalloc(sizeof(*rwi), GFP_ATOMIC);
if (!rwi) {
spin_unlock_irqrestore(>rwi_lock, flags);
ibmvnic_close(netdev);
-- 
2.19.1



[PATCH AUTOSEL 4.19 30/97] x86/mm: Fix guard hole handling

2018-12-26 Thread Sasha Levin
From: "Kirill A. Shutemov" 

[ Upstream commit 16877a5570e0c5f4270d5b17f9bab427bcae9514 ]

There is a guard hole at the beginning of the kernel address space, also
used by hypervisors. It occupies 16 PGD entries.

This reserved range is not defined explicitely, it is calculated relative
to other entities: direct mapping and user space ranges.

The calculation got broken by recent changes of the kernel memory layout:
LDT remap range is now mapped before direct mapping and makes the
calculation invalid.

The breakage leads to crash on Xen dom0 boot[1].

Define the reserved range explicitely. It's part of kernel ABI (hypervisors
expect it to be stable) and must not depend on changes in the rest of
kernel memory layout.

[1] https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html

Fixes: d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level 
paging")
Reported-by: Hans van Kranenburg 
Signed-off-by: Kirill A. Shutemov 
Signed-off-by: Thomas Gleixner 
Tested-by: Hans van Kranenburg 
Reviewed-by: Juergen Gross 
Cc: b...@alien8.de
Cc: h...@zytor.com
Cc: dave.han...@linux.intel.com
Cc: l...@kernel.org
Cc: pet...@infradead.org
Cc: boris.ostrov...@oracle.com
Cc: b...@redhat.com
Cc: linux...@kvack.org
Cc: xen-de...@lists.xenproject.org
Link: 
https://lkml.kernel.org/r/20181130202328.65359-2-kirill.shute...@linux.intel.com
Signed-off-by: Sasha Levin 
---
 arch/x86/include/asm/pgtable_64_types.h |  5 +
 arch/x86/mm/dump_pagetables.c   |  8 
 arch/x86/xen/mmu_pv.c   | 11 ++-
 3 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h
index 84bd9bdc1987..88bca456da99 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -111,6 +111,11 @@ extern unsigned int ptrs_per_p4d;
  */
 #define MAXMEM (1UL << MAX_PHYSMEM_BITS)
 
+#define GUARD_HOLE_PGD_ENTRY   -256UL
+#define GUARD_HOLE_SIZE(16UL << PGDIR_SHIFT)
+#define GUARD_HOLE_BASE_ADDR   (GUARD_HOLE_PGD_ENTRY << PGDIR_SHIFT)
+#define GUARD_HOLE_END_ADDR(GUARD_HOLE_BASE_ADDR + GUARD_HOLE_SIZE)
+
 #define LDT_PGD_ENTRY  -240UL
 #define LDT_BASE_ADDR  (LDT_PGD_ENTRY << PGDIR_SHIFT)
 #define LDT_END_ADDR   (LDT_BASE_ADDR + PGDIR_SIZE)
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index a12afff146d1..073755c89126 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -493,11 +493,11 @@ static inline bool is_hypervisor_range(int idx)
 {
 #ifdef CONFIG_X86_64
/*
-* 8000 - 87ff is reserved for
-* the hypervisor.
+* A hole in the beginning of kernel address space reserved
+* for a hypervisor.
 */
-   return  (idx >= pgd_index(__PAGE_OFFSET) - 16) &&
-   (idx <  pgd_index(__PAGE_OFFSET));
+   return  (idx >= pgd_index(GUARD_HOLE_BASE_ADDR)) &&
+   (idx <  pgd_index(GUARD_HOLE_END_ADDR));
 #else
return false;
 #endif
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 2c84c6ad8b50..c8f011e07a15 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -640,19 +640,20 @@ static int __xen_pgd_walk(struct mm_struct *mm, pgd_t 
*pgd,
  unsigned long limit)
 {
int i, nr, flush = 0;
-   unsigned hole_low, hole_high;
+   unsigned hole_low = 0, hole_high = 0;
 
/* The limit is the last byte to be touched */
limit--;
BUG_ON(limit >= FIXADDR_TOP);
 
+#ifdef CONFIG_X86_64
/*
 * 64-bit has a great big hole in the middle of the address
-* space, which contains the Xen mappings.  On 32-bit these
-* will end up making a zero-sized hole and so is a no-op.
+* space, which contains the Xen mappings.
 */
-   hole_low = pgd_index(USER_LIMIT);
-   hole_high = pgd_index(PAGE_OFFSET);
+   hole_low = pgd_index(GUARD_HOLE_BASE_ADDR);
+   hole_high = pgd_index(GUARD_HOLE_END_ADDR);
+#endif
 
nr = pgd_index(limit) + 1;
for (i = 0; i < nr; i++) {
-- 
2.19.1



[PATCH AUTOSEL 4.19 54/97] net: hns: Incorrect offset address used for some registers.

2018-12-26 Thread Sasha Levin
From: Yonglong Liu 

[ Upstream commit 4e1d4be681b2c26fd874adbf584bf034573ac45d ]

According to the hip06 Datasheet:
1. The offset of INGRESS_SW_VLAN_TAG_DISC should be 0x1A00+4*all_chn_num
2. The offset of INGRESS_IN_DATA_STP_DISC should be 0x1A50+4*all_chn_num

Signed-off-by: Yonglong Liu 
Signed-off-by: Peng Li 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index e557a4ef5996..dc9215a565c9 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -2166,9 +2166,9 @@ void hns_dsaf_update_stats(struct dsaf_device *dsaf_dev, 
u32 node_num)
DSAF_INODE_LOCAL_ADDR_FALSE_NUM_0_REG + 0x80 * (u64)node_num);
 
hw_stats->vlan_drop += dsaf_read_dev(dsaf_dev,
-   DSAF_INODE_SW_VLAN_TAG_DISC_0_REG + 0x80 * (u64)node_num);
+   DSAF_INODE_SW_VLAN_TAG_DISC_0_REG + 4 * (u64)node_num);
hw_stats->stp_drop += dsaf_read_dev(dsaf_dev,
-   DSAF_INODE_IN_DATA_STP_DISC_0_REG + 0x80 * (u64)node_num);
+   DSAF_INODE_IN_DATA_STP_DISC_0_REG + 4 * (u64)node_num);
 
/* pfc pause frame statistics stored in dsaf inode*/
if ((node_num < DSAF_SERVICE_NW_NUM) && !is_ver1) {
-- 
2.19.1



[PATCH AUTOSEL 4.19 55/97] net: hns: All ports can not work when insmod hns ko after rmmod.

2018-12-26 Thread Sasha Levin
From: Yonglong Liu 

[ Upstream commit 308c6cafde0147616da45e3a928adae55c428deb ]

There are two test cases:
1. Remove the 4 modules:hns_enet_drv/hns_dsaf/hnae/hns_mdio,
   and install them again, must use "ifconfig down/ifconfig up"
   command pair to bring port to work.

   This patch calls phy_stop function when init phy to fix this bug.

2. Remove the 2 modules:hns_enet_drv/hns_dsaf, and install them again,
   all ports can not use anymore, because of the phy devices register
   failed(phy devices already exists).

   Phy devices are registered when hns_dsaf installed, this patch
   removes them when hns_dsaf removed.

The two cases are sometimes related, fixing the second case also requires
fixing the first case, so fix them together.

Signed-off-by: Yonglong Liu 
Signed-off-by: Peng Li 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 15 +++
 drivers/net/ethernet/hisilicon/hns/hns_enet.c |  3 +++
 2 files changed, 18 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index 6ed6f142427e..cfdc92de9dc0 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -778,6 +778,17 @@ static int hns_mac_register_phy(struct hns_mac_cb *mac_cb)
return rc;
 }
 
+static void hns_mac_remove_phydev(struct hns_mac_cb *mac_cb)
+{
+   if (!to_acpi_device_node(mac_cb->fw_port) || !mac_cb->phy_dev)
+   return;
+
+   phy_device_remove(mac_cb->phy_dev);
+   phy_device_free(mac_cb->phy_dev);
+
+   mac_cb->phy_dev = NULL;
+}
+
 #define MAC_MEDIA_TYPE_MAX_LEN 16
 
 static const struct {
@@ -1117,7 +1128,11 @@ void hns_mac_uninit(struct dsaf_device *dsaf_dev)
int max_port_num = hns_mac_get_max_port_num(dsaf_dev);
 
for (i = 0; i < max_port_num; i++) {
+   if (!dsaf_dev->mac_cb[i])
+   continue;
+
dsaf_dev->misc_op->cpld_reset_led(dsaf_dev->mac_cb[i]);
+   hns_mac_remove_phydev(dsaf_dev->mac_cb[i]);
dsaf_dev->mac_cb[i] = NULL;
}
 }
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c 
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 28e907831b0e..c205a0e4b64b 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -1186,6 +1186,9 @@ int hns_nic_init_phy(struct net_device *ndev, struct 
hnae_handle *h)
if (h->phy_if == PHY_INTERFACE_MODE_XGMII)
phy_dev->autoneg = false;
 
+   if (h->phy_if == PHY_INTERFACE_MODE_SGMII)
+   phy_stop(phy_dev);
+
return 0;
 }
 
-- 
2.19.1



[PATCH AUTOSEL 4.19 34/97] ixgbe: Fix race when the VF driver does a reset

2018-12-26 Thread Sasha Levin
From: Ross Lagerwall 

[ Upstream commit 96d1a731611f711f0cb82cea93363ae2ea8cb028 ]

When the VF driver does a reset, it (at least the Linux one) writes to
the VFCTRL register to issue a reset and then immediately sends a reset
message using the mailbox API. This is racy because when the PF driver
detects that the VFCTRL register reset pin has been asserted, it clears
the mailbox memory. Depending on ordering, the reset message sent by
the VF could be cleared by the PF driver. It then responds to the
cleared message with a NACK which causes the VF driver to malfunction.
Fix this by deferring clearing the mailbox memory until the reset
message is received.

Fixes: 939b701ad633 ("ixgbe: fix driver behaviour after issuing VFLR")
Signed-off-by: Ross Lagerwall 
Tested-by: Andrew Bowers 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index eea63a99f29c..f6ffd9fb2079 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -699,7 +699,6 @@ static inline void ixgbe_vf_reset_event(struct 
ixgbe_adapter *adapter, u32 vf)
u8 num_tcs = adapter->hw_tcs;
u32 reg_val;
u32 queue;
-   u32 word;
 
/* remove VLAN filters beloning to this VF */
ixgbe_clear_vf_vlans(adapter, vf);
@@ -754,6 +753,14 @@ static inline void ixgbe_vf_reset_event(struct 
ixgbe_adapter *adapter, u32 vf)
}
}
 
+   IXGBE_WRITE_FLUSH(hw);
+}
+
+static void ixgbe_vf_clear_mbx(struct ixgbe_adapter *adapter, u32 vf)
+{
+   struct ixgbe_hw *hw = >hw;
+   u32 word;
+
/* Clear VF's mailbox memory */
for (word = 0; word < IXGBE_VFMAILBOX_SIZE; word++)
IXGBE_WRITE_REG_ARRAY(hw, IXGBE_PFMBMEM(vf), word, 0);
@@ -827,6 +834,8 @@ static int ixgbe_vf_reset_msg(struct ixgbe_adapter 
*adapter, u32 vf)
/* reset the filters for the device */
ixgbe_vf_reset_event(adapter, vf);
 
+   ixgbe_vf_clear_mbx(adapter, vf);
+
/* set vf mac address */
if (!is_zero_ether_addr(vf_mac))
ixgbe_set_vf_mac(adapter, vf, vf_mac);
-- 
2.19.1



[PATCH AUTOSEL 4.19 33/97] USB: hso: Fix OOB memory access in hso_probe/hso_get_config_data

2018-12-26 Thread Sasha Levin
From: Hui Peng 

[ Upstream commit 5146f95df782b0ac61abde36567e718692725c89 ]

The function hso_probe reads if_num from the USB device (as an u8) and uses
it without a length check to index an array, resulting in an OOB memory read
in hso_probe or hso_get_config_data.

Add a length check for both locations and updated hso_probe to bail on
error.

This issue has been assigned CVE-2018-19985.

Reported-by: Hui Peng 
Reported-by: Mathias Payer 
Signed-off-by: Hui Peng 
Signed-off-by: Mathias Payer 
Reviewed-by: Sebastian Andrzej Siewior 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/usb/hso.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 184c24baca15..d6916f787fce 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -2807,6 +2807,12 @@ static int hso_get_config_data(struct usb_interface 
*interface)
return -EIO;
}
 
+   /* check if we have a valid interface */
+   if (if_num > 16) {
+   kfree(config_data);
+   return -EINVAL;
+   }
+
switch (config_data[if_num]) {
case 0x0:
result = 0;
@@ -2877,10 +2883,18 @@ static int hso_probe(struct usb_interface *interface,
 
/* Get the interface/port specification from either driver_info or from
 * the device itself */
-   if (id->driver_info)
+   if (id->driver_info) {
+   /* if_num is controlled by the device, driver_info is a 0 
terminated
+* array. Make sure, the access is in bounds! */
+   for (i = 0; i <= if_num; ++i)
+   if (((u32 *)(id->driver_info))[i] == 0)
+   goto exit;
port_spec = ((u32 *)(id->driver_info))[if_num];
-   else
+   } else {
port_spec = hso_get_config_data(interface);
+   if (port_spec < 0)
+   goto exit;
+   }
 
/* Check if we need to switch to alt interfaces prior to port
 * configuration */
-- 
2.19.1



[PATCH AUTOSEL 4.19 23/97] scsi: bnx2fc: Fix NULL dereference in error handling

2018-12-26 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit 9ae4f8420ed7be4b13c96600e3568c144d101a23 ]

If "interface" is NULL then we can't release it and trying to will only
lead to an Oops.

Fixes: aea71a024914 ("[SCSI] bnx2fc: Introduce interface structure for each 
vlan interface")
Signed-off-by: Dan Carpenter 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c 
b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index f00045813378..3f97ec4aac4b 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -2371,7 +2371,7 @@ static int _bnx2fc_create(struct net_device *netdev,
if (!interface) {
printk(KERN_ERR PFX "bnx2fc_interface_create failed\n");
rc = -ENOMEM;
-   goto ifput_err;
+   goto netdev_err;
}
 
if (is_vlan_dev(netdev)) {
-- 
2.19.1



[PATCH AUTOSEL 4.19 18/97] xfrm: Fix NULL pointer dereference in xfrm_input when skb_dst_force clears the dst_entry.

2018-12-26 Thread Sasha Levin
From: Steffen Klassert 

[ Upstream commit 0152eee6fc3b84298bb6a79961961734e8afa5b8 ]

Since commit 222d7dbd258d ("net: prevent dst uses after free")
skb_dst_force() might clear the dst_entry attached to the skb.
The xfrm code doesn't expect this to happen, so we crash with
a NULL pointer dereference in this case.

Fix it by checking skb_dst(skb) for NULL after skb_dst_force()
and drop the packet in case the dst_entry was cleared. We also
move the skb_dst_force() to a codepath that is not used when
the transformation was offloaded, because in this case we
don't have a dst_entry attached to the skb.

The output and forwarding path was already fixed by
commit 9e1437937807 ("xfrm: Fix NULL pointer dereference when
skb_dst_force clears the dst_entry.")

Fixes: 222d7dbd258d ("net: prevent dst uses after free")
Reported-by: Jean-Philippe Menil 
Signed-off-by: Steffen Klassert 
Signed-off-by: Sasha Levin 
---
 net/xfrm/xfrm_input.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index be3520e429c9..790b514f86b6 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -346,6 +346,12 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 
spi, int encap_type)
 
skb->sp->xvec[skb->sp->len++] = x;
 
+   skb_dst_force(skb);
+   if (!skb_dst(skb)) {
+   XFRM_INC_STATS(net, LINUX_MIB_XFRMINERROR);
+   goto drop;
+   }
+
 lock:
spin_lock(>lock);
 
@@ -385,7 +391,6 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 
spi, int encap_type)
XFRM_SKB_CB(skb)->seq.input.low = seq;
XFRM_SKB_CB(skb)->seq.input.hi = seq_hi;
 
-   skb_dst_force(skb);
dev_hold(skb->dev);
 
if (crypto_done)
-- 
2.19.1



[PATCH AUTOSEL 4.19 12/97] powerpc/mm: Fallback to RAM if the altmap is unusable

2018-12-26 Thread Sasha Levin
From: Oliver O'Halloran 

[ Upstream commit 9ef34630a4614ee1cd478f9859ebea55d55f10ec ]

The "altmap" is used to provide a pool of memory that is reserved for
the vmemmap backing of hot-plugged memory. This is useful when adding
large amount of ZONE_DEVICE memory to a system with a limited amount of
normal memory.

On ppc64 we use huge pages to map the vmemmap which requires the backing
storage to be contigious and aligned to the hugepage size. The altmap
implementation allows for the altmap provider to reserve a few PFNs at
the start of the range for it's own uses and when this occurs the
first chunk of the altmap is not usable for hugepage mappings. On hash
there is no sane way to fall back to a normal sized page mapping so we
fail the allocation. This results in memory hotplug failing with
ENOMEM when the new range doesn't fall into an existing vmemmap block.

This patch handles this case by falling back to using system memory
rather than failing if we cannot allocate from the altmap. This
fallback should only ever be used for the first vmemmap block so it
should not cause excess memory consumption.

Fixes: 7b73d978a5d0 ("mm: pass the vmem_altmap to vmemmap_populate")
Signed-off-by: Oliver O'Halloran 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/mm/init_64.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index 7a9886f98b0c..a5091c034747 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -188,15 +188,20 @@ int __meminit vmemmap_populate(unsigned long start, 
unsigned long end, int node,
pr_debug("vmemmap_populate %lx..%lx, node %d\n", start, end, node);
 
for (; start < end; start += page_size) {
-   void *p;
+   void *p = NULL;
int rc;
 
if (vmemmap_populated(start, page_size))
continue;
 
+   /*
+* Allocate from the altmap first if we have one. This may
+* fail due to alignment issues when using 16MB hugepages, so
+* fall back to system memory if the altmap allocation fail.
+*/
if (altmap)
p = altmap_alloc_block_buf(page_size, altmap);
-   else
+   if (!p)
p = vmemmap_alloc_block_buf(page_size, node);
if (!p)
return -ENOMEM;
@@ -255,8 +260,15 @@ void __ref vmemmap_free(unsigned long start, unsigned long 
end,
 {
unsigned long page_size = 1 << mmu_psize_defs[mmu_vmemmap_psize].shift;
unsigned long page_order = get_order(page_size);
+   unsigned long alt_start = ~0, alt_end = ~0;
+   unsigned long base_pfn;
 
start = _ALIGN_DOWN(start, page_size);
+   if (altmap) {
+   alt_start = altmap->base_pfn;
+   alt_end = altmap->base_pfn + altmap->reserve +
+ altmap->free + altmap->alloc + altmap->align;
+   }
 
pr_debug("vmemmap_free %lx...%lx\n", start, end);
 
@@ -280,8 +292,9 @@ void __ref vmemmap_free(unsigned long start, unsigned long 
end,
page = pfn_to_page(addr >> PAGE_SHIFT);
section_base = pfn_to_page(vmemmap_section_start(start));
nr_pages = 1 << page_order;
+   base_pfn = PHYS_PFN(addr);
 
-   if (altmap) {
+   if (base_pfn >= alt_start && base_pfn < alt_end) {
vmem_altmap_free(altmap, nr_pages);
} else if (PageReserved(page)) {
/* allocated from bootmem */
-- 
2.19.1



[PATCH AUTOSEL 4.19 05/97] powerpc/mm: Fix linux page tables build with some configs

2018-12-26 Thread Sasha Levin
From: Michael Ellerman 

[ Upstream commit 462951cd32e1496dc64b00051dfb777efc8ae5d8 ]

For some configs the build fails with:

  arch/powerpc/mm/dump_linuxpagetables.c: In function 'populate_markers':
  arch/powerpc/mm/dump_linuxpagetables.c:306:39: error: 'PKMAP_BASE' undeclared 
(first use in this function)
  arch/powerpc/mm/dump_linuxpagetables.c:314:50: error: 'LAST_PKMAP' undeclared 
(first use in this function)

These come from highmem.h, including that fixes the build.

Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/mm/dump_linuxpagetables.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/mm/dump_linuxpagetables.c 
b/arch/powerpc/mm/dump_linuxpagetables.c
index bdf33b989f98..8464c2c01c0c 100644
--- a/arch/powerpc/mm/dump_linuxpagetables.c
+++ b/arch/powerpc/mm/dump_linuxpagetables.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.19.1



[PATCH AUTOSEL 4.19 02/97] pinctrl: meson: fix pull enable register calculation

2018-12-26 Thread Sasha Levin
From: Jerome Brunet 

[ Upstream commit 614b1868a125a0ba24be08f3a7fa832ddcde6bca ]

We just changed the code so we apply bias disable on the correct
register but forgot to align the register calculation. The result
is that we apply the change on the correct register, but possibly
at the incorrect offset/bit

This went undetected because offsets tends to be the same between
REG_PULL and REG_PULLEN for a given pin the EE controller. This
is not true for the AO controller.

Fixes: e39f9dd8206a ("pinctrl: meson: fix pinconf bias disable")
Signed-off-by: Jerome Brunet 
Acked-by: Neil Armstrong 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
---
 drivers/pinctrl/meson/pinctrl-meson.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/meson/pinctrl-meson.c 
b/drivers/pinctrl/meson/pinctrl-meson.c
index 4f3ab18636a3..c8eff70fdb1c 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.c
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -191,7 +191,8 @@ static int meson_pinconf_set(struct pinctrl_dev *pcdev, 
unsigned int pin,
case PIN_CONFIG_BIAS_DISABLE:
dev_dbg(pc->dev, "pin %u: disable bias\n", pin);
 
-   meson_calc_reg_and_bit(bank, pin, REG_PULL, , );
+   meson_calc_reg_and_bit(bank, pin, REG_PULLEN, ,
+  );
ret = regmap_update_bits(pc->reg_pullen, reg,
 BIT(bit), 0);
if (ret)
-- 
2.19.1



[PATCH AUTOSEL 4.19 01/97] ARM: dts: sun8i: a83t: bananapi-m3: increase vcc-pd voltage to 3.3V

2018-12-26 Thread Sasha Levin
From: Corentin Labbe 

[ Upstream commit 5f8208f557065163f9a8089ea2ea7888f9d96922 ]

Since commit d7c5f6863550 ("ARM: dts: sun8i: a83t: bananapi-m3: Add
AXP813 regulator nodes") my BPIM3 no longer works at gigabit speed.

With the default setting, dldo3 is regulated at 2.9v which seems
sufficient for the PHY but the aforementioned commit drops it to 2.5V
which is insufficient. Note that this behaviour is random for all BPIM3.
Some work with 2.5V, but some don't.

Finnaly, someone from Bananapi confirmed that this regulator must be set
to 3.3V.

Fixes: d7c5f6863550 ("ARM: dts: sun8i: a83t: bananapi-m3: Add AXP813
  regulator nodes")
Signed-off-by: Corentin Labbe 
[w...@csie.org: Reworked commit message]
Signed-off-by: Chen-Yu Tsai 
Signed-off-by: Sasha Levin 
---
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts 
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index c7ce4158d6c8..f250b20af493 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -309,8 +309,8 @@
 
 _dldo3 {
regulator-always-on;
-   regulator-min-microvolt = <250>;
-   regulator-max-microvolt = <250>;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
regulator-name = "vcc-pd";
 };
 
-- 
2.19.1



Re: [PATCH] hmm: Warn on devres_release failure

2018-12-26 Thread Jerome Glisse
On Wed, Dec 26, 2018 at 12:09:04PM -0600, Aditya Pakki wrote:
> devres_release can return -ENOENT if the device is not freed. The fix
> throws a warning consistent with other invocations.
> 
> Signed-off-by: Aditya Pakki 

Reviewed-by: Jérôme Glisse 

> ---
>  mm/hmm.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 90c34f3d1243..b06e3f092fbf 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
> @@ -1183,8 +1183,12 @@ static int hmm_devmem_match(struct device *dev, void 
> *data, void *match_data)
>  
>  static void hmm_devmem_pages_remove(struct hmm_devmem *devmem)
>  {
> - devres_release(devmem->device, _devmem_release,
> -_devmem_match, devmem->resource);
> + int rc;
> +
> + rc = devres_release(devmem->device, _devmem_release,
> + _devmem_match, devmem->resource);
> + if (rc)
> + WARN_ON(rc);
>  }
>  
>  /*
> -- 
> 2.17.1
> 


Re: [PATCH] char: hw_random: Fix missing check during driver release

2018-12-26 Thread Michael Büsch
On Wed, 26 Dec 2018 11:23:31 -0600
Aditya Pakki  wrote:

> devres_release can return -ENOENT if the device is not freed. The fix
> throws a warning consistent with other invocations.
> 
> Signed-off-by: Aditya Pakki 
> ---
>  drivers/char/hw_random/core.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> index 95be7228f327..582d983fa93f 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -578,7 +578,11 @@ EXPORT_SYMBOL_GPL(devm_hwrng_register);
>  
>  void devm_hwrng_unregister(struct device *dev, struct hwrng *rng)
>  {
> - devres_release(dev, devm_hwrng_release, devm_hwrng_match, rng);
> + int rc;
> +
> + rc = devres_release(dev, devm_hwrng_release, devm_hwrng_match, rng);
> + if (rc)

The if statement is redundant and can be removed.

> + WARN_ON(rc);
>  }
>  EXPORT_SYMBOL_GPL(devm_hwrng_unregister);
>  

-- 
Michael


pgpVKn6fiRO6Y.pgp
Description: OpenPGP digital signature


Re: [PATCH v5 1/5] Bluetooth: hci_qca: use wait_until_sent() for power pulses

2018-12-26 Thread Matthias Kaehlcke
On Wed, Dec 26, 2018 at 12:01:51PM +0530, Balakrishna Godavarthi wrote:
> Hi Matthias,
> 
> On 2018-12-22 07:29, Matthias Kaehlcke wrote:
> > On Thu, Dec 20, 2018 at 08:16:35PM +0530, Balakrishna Godavarthi wrote:
> > > wcn3990 requires a power pulse to turn ON/OFF along with
> > > regulators. Sometimes we are observing the power pulses are sent
> > > out with some time delay, due to queuing these commands. This is
> > > causing synchronization issues with chip, which intern delay the
> > > chip setup or may end up with communication issues.
> > > 
> > > Signed-off-by: Balakrishna Godavarthi 
> > > ---
> > >  drivers/bluetooth/hci_qca.c | 38
> > > ++---
> > >  1 file changed, 14 insertions(+), 24 deletions(-)
> > > 
> > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > > index f036c8f98ea3..5a07c2370289 100644
> > > --- a/drivers/bluetooth/hci_qca.c
> > > +++ b/drivers/bluetooth/hci_qca.c
> > > @@ -1013,11 +1013,9 @@ static inline void host_set_baudrate(struct
> > > hci_uart *hu, unsigned int speed)
> > >   hci_uart_set_baudrate(hu, speed);
> > >  }
> > > 
> > > -static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd)
> > > +static int qca_send_power_pulse(struct hci_uart *hu, u8 cmd)
> > >  {
> > > - struct hci_uart *hu = hci_get_drvdata(hdev);
> > > - struct qca_data *qca = hu->priv;
> > > - struct sk_buff *skb;
> > > + int ret;
> > > 
> > >   /* These power pulses are single byte command which are sent
> > >* at required baudrate to wcn3990. On wcn3990, we have an external
> > > @@ -1029,19 +1027,16 @@ static int qca_send_power_pulse(struct
> > > hci_dev *hdev, u8 cmd)
> > >* save power. Disabling hardware flow control is mandatory while
> > >* sending power pulses to SoC.
> > >*/
> > > - bt_dev_dbg(hdev, "sending power pulse %02x to SoC", cmd);
> > > -
> > > - skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
> > > - if (!skb)
> > > - return -ENOMEM;
> > > -
> > > + bt_dev_dbg(hu->hdev, "sending power pulse %02x to SoC", cmd);
> > >   hci_uart_set_flow_control(hu, true);
> > > + ret = serdev_device_write_buf(hu->serdev, , sizeof(cmd));
> > > + if (ret < 0) {
> > > + bt_dev_err(hu->hdev, "failed to send power pulse %02x to SoC",
> > > +cmd);
> > > + return ret;
> > > + }
> > > 
> > > - skb_put_u8(skb, cmd);
> > > - hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
> > > -
> > > - skb_queue_tail(>txq, skb);
> > > - hci_uart_tx_wakeup(hu);
> > > + serdev_device_wait_until_sent(hu->serdev, 0);
> > 
> > serdev_device_wait_until_sent() might only guarantee that the UART
> > circular buffer is empty (see
> > https://elixir.bootlin.com/linux/v4.19/source/drivers/tty/tty_ioctl.c#L225),
> > not that the data has actually sent (e.g. it might be sitting in
> > the UART FIFO). However with this:
> > 
> > >   /* Wait for 100 uS for SoC to settle down */
> > >   usleep_range(100, 200);
> > 
> > we should probably be fine, unless there's tons of data in the
> > FIFO.
> > 
> > You currently call serdev_device_write_flush() in
> > qca_power_shutdown(), I wonder if it would make sense to call it in
> > qca_send_power_pulse(), regardless of whether it's an on or off
> 
> [Bala]: during sending the ON pulse we will not have any data in the
> UART circular buffer as this is the first command to send and we are
> sending it as soon as we open the port.
> so i taught why should be flush the circular as it is already empty.

> > pulse. In any case we don't care if the chip receives any 'pending'
> > data when we switch it on or off, right?
> > 
> 
> [Bala]: during on we freshly open port and i see that flush() called while
> port opening.
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/tty/serial/serial_core.c#L207

I would argue that the serdev_device_write_flush() call in
qca_power_shutdown() is related with/needed for sending the power off
pulse, hence it should be part of qca_send_power_pulse(), unless it
adds a significant overhead and we really want to call it only in the
shutdown case.

Flushing the buffer should be fairly lightweight and power pulses are
only sent when the device is switched on or off, so the overhead
should be negligible. You *could* restrict the flush to the power off
pulse, assuming that the driver always re-opens the port in
qca_wcn3990_init() (tests with this patch set suggest this might not
be needed) and that serdev_device_open() flushes the buffer (which
seems a sane assumption). Yet given the minimal overhead I'd suggest
to not make assumptions about what happened previously in other code
and avoid the clutter of a condition that doesn't add much value.

Cheers

Matthias


Re: WIP Droid 4 voice calls, GNSS & PM with a TS 27.010 serdev driver

2018-12-26 Thread Pavel Machek
Hi!

> > root@devuan:/my/ko# ls -al /dev/ttyS0
> > crw-rw 1 root dialout 4, 64 Dec 23 11:52 /dev/ttyS0
> > 
> > but not gsm multiplex:
> > 
> > root@devuan:/my/ko# ls -al /dev/gsm*
> > ls: cannot access '/dev/gsm*': No such file or directory
> 
> Hmm with serdev you should not get /dev/ttyS0, so maybe you're missing:
> 
> CONFIG_SERIAL_DEV_BUS=y
> CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
> 
> Probably the Kconfig dependency should be for SERIAL_DEV_CTRL_TTYPORT
> instead of SERIAL_DEV_BUS in these patches if that helps.
> 
> Or else you're missing the serdev related dts changes?

Seems like I was missing the dts changes. I was using kexec (did not
want to replace a working kernel) and that seems to use the old dtb.

gnss0 now seems to work, and I do get some kind of replies from the AT
modem. Thanks!

I'll reply to the original email with bad news and more details...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


[PATCH] ASoC: xlnx: fix error handling in xlnx_formatter_pcm_probe

2018-12-26 Thread Gustavo A. R. Silva
Currently, if platform_get_irq_byname() fails, the returned error
turns into a huge value, once it is being store into a variable
of type unsigned int, hence never actually reporting any error
and causing unexpected behavior when using the values stored
in aud_drv_data->s2mm_irq and aud_drv_data->mm2s_irq.

Fix this by changing the type of variables s2mm_irq and mm2s_irq in
structure xlnx_pcm_drv_data from unsigned int to int.

Addresses-Coverity-ID: 1476096 ("Unsigned compared against 0")
Fixes: 796175a94a7f ("ASoC: xlnx: add pcm formatter platform driver")
Signed-off-by: Gustavo A. R. Silva 
---
 sound/soc/xilinx/xlnx_formatter_pcm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/xilinx/xlnx_formatter_pcm.c 
b/sound/soc/xilinx/xlnx_formatter_pcm.c
index f7235f7664d7..d2194da928e7 100644
--- a/sound/soc/xilinx/xlnx_formatter_pcm.c
+++ b/sound/soc/xilinx/xlnx_formatter_pcm.c
@@ -76,8 +76,8 @@ struct xlnx_pcm_drv_data {
void __iomem *mmio;
bool s2mm_presence;
bool mm2s_presence;
-   unsigned int s2mm_irq;
-   unsigned int mm2s_irq;
+   int s2mm_irq;
+   int mm2s_irq;
struct snd_pcm_substream *play_stream;
struct snd_pcm_substream *capture_stream;
struct clk *axi_clk;
-- 
2.20.1



Re: [GIT PULL] x86/cache updates for 4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Sun, 23 Dec 2018 13:48:59 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cache-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a52fb43a5faa40507cb164a793a7fa08da863ac7

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] x86/microcode updates for 4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Sun, 23 Dec 2018 13:51:38 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> x86-microcode-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/72af84151fa7e98720a0482b59de2d90ec7f10a7

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] RAS updates for 4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Sun, 23 Dec 2018 13:53:39 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git ras-core-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/eed9688f8513189295887e5a27ec7f576754b60e

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


[PATCH v1 5/7] drm: remove include of drmP.h from drm_encoder_slave.h

2018-12-26 Thread Sam Ravnborg
No further changes required.

Signed-off-by: Sam Ravnborg 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 include/drm/drm_encoder_slave.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/drm/drm_encoder_slave.h b/include/drm/drm_encoder_slave.h
index 1107b4b1c599..a09864f6d684 100644
--- a/include/drm/drm_encoder_slave.h
+++ b/include/drm/drm_encoder_slave.h
@@ -27,7 +27,6 @@
 #ifndef __DRM_ENCODER_SLAVE_H__
 #define __DRM_ENCODER_SLAVE_H__
 
-#include 
 #include 
 #include 
 
-- 
2.12.0



[PATCH v1 6/7] drm: remove include of drmP.h from drm_modeset_helper.h

2018-12-26 Thread Sam Ravnborg
Fix fallout in various files/drivers by adding missing include files.

Signed-off-by: Sam Ravnborg 
Cc: Alexey Brodkin 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: Kieran Bingham 
---
 drivers/gpu/drm/arc/arcpgu_sim.c | 1 +
 drivers/gpu/drm/bridge/cdns-dsi.c| 2 ++
 drivers/gpu/drm/drm_modeset_helper.c | 2 ++
 drivers/gpu/drm/rcar-du/rcar_lvds.c  | 1 +
 include/drm/drm_modeset_helper.h | 2 --
 5 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index 68629e614990..3b7556f62230 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -14,6 +14,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
b/drivers/gpu/drm/bridge/cdns-dsi.c
index ce9496d13986..4b73d0969468 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -8,11 +8,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/drm_modeset_helper.c 
b/drivers/gpu/drm/drm_modeset_helper.c
index f1c24ab0ef09..680cb6a5978c 100644
--- a/drivers/gpu/drm/drm_modeset_helper.c
+++ b/drivers/gpu/drm/drm_modeset_helper.c
@@ -23,8 +23,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 /**
  * DOC: aux kms helpers
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c 
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 173d7ad0b991..f1043458cbd8 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/drm/drm_modeset_helper.h b/include/drm/drm_modeset_helper.h
index efa337f03129..82ead67dfa36 100644
--- a/include/drm/drm_modeset_helper.h
+++ b/include/drm/drm_modeset_helper.h
@@ -23,8 +23,6 @@
 #ifndef __DRM_KMS_HELPER_H__
 #define __DRM_KMS_HELPER_H__
 
-#include 
-
 void drm_helper_move_panel_connectors_to_head(struct drm_device *);
 
 void drm_helper_mode_fill_fb_struct(struct drm_device *dev,
-- 
2.12.0



[PATCH v1 3/7] drm: move drm_can_sleep() to drm_util.h

2018-12-26 Thread Sam Ravnborg
Move drm_can_sleep() out of drmP.h to allow users
to get rid of the drmP.h include.

There was no header file that was a good match for this helper function.
So add this to drm_util with the relevant includes.

Add include of drm_util.h to all users.

Signed-off-by: Sam Ravnborg 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: "David (ChunMing) Zhou" 
Cc: Gerd Hoffmann 
Cc: Rob Clark 
Cc: Tomi Valkeinen 
Cc: Eric Anholt 
---
 drivers/gpu/drm/amd/amdgpu/atom.c   |  2 ++
 drivers/gpu/drm/ast/ast_fb.c|  1 +
 drivers/gpu/drm/cirrus/cirrus_fbdev.c   |  1 +
 drivers/gpu/drm/drm_flip_work.c |  1 +
 drivers/gpu/drm/mgag200/mgag200_fb.c|  1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c|  1 +
 drivers/gpu/drm/omapdrm/omap_fbdev.c|  1 +
 drivers/gpu/drm/qxl/qxl_cmd.c   |  2 ++
 drivers/gpu/drm/radeon/atom.c   |  2 ++
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |  1 +
 drivers/gpu/drm/vc4/vc4_drv.h   |  1 +
 include/drm/drmP.h  |  8 
 include/drm/drm_util.h  | 13 +
 13 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c 
b/drivers/gpu/drm/amd/amdgpu/atom.c
index e9934de1b9cf..dd30f4e61a8c 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 
+#include 
+
 #define ATOM_DEBUG
 
 #include "atom.h"
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index de26df0c6044..fb56fe848e81 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -38,6 +38,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "ast_drv.h"
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 68ab1821e15b..1544fa55d1ff 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -10,6 +10,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/drm_flip_work.c b/drivers/gpu/drm/drm_flip_work.c
index 12dea16f22a8..3da3bf5af405 100644
--- a/drivers/gpu/drm/drm_flip_work.c
+++ b/drivers/gpu/drm/drm_flip_work.c
@@ -22,6 +22,7 @@
  */
 
 #include 
+#include 
 #include 
 
 /**
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index 30726c9fe28c..6893934b26c0 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -12,6 +12,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
index 96c2b828dba4..fa2d1d8995ee 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
@@ -16,6 +16,7 @@
  * this program.  If not, see .
  */
 
+#include 
 
 #include "mdp5_kms.h"
 #include "mdp5_smp.h"
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index aee99194499f..851c59f07eb1 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -16,6 +16,7 @@
  */
 
 #include 
+#include 
 #include 
 
 #include "omap_drv.h"
diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
index 208af9f37914..d17676824377 100644
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -25,6 +25,8 @@
 
 /* QXL cmd/ring handling */
 
+#include 
+
 #include "qxl_drv.h"
 #include "qxl_object.h"
 
diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index e55cbeee7a53..ac98ad561870 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 
+#include 
+
 #define ATOM_DEBUG
 
 #include "atom.h"
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c 
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index 222a1fa41d7c..7e3257e8fd56 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -24,6 +24,7 @@
  *  Alex Deucher
  */
 #include 
+#include 
 #include 
 #include 
 #include "radeon.h"
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index bd6ef1f31822..79c6bcc4f509 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2ba786820052..a77c9ee43b68 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -95,12 +95,4 @@ struct dma_buf_attachment;
 struct pci_dev;
 struct pci_controller;
 
-/* returns true if currently okay to sleep */
-static inline bool drm_can_sleep(void)
-{
-  

[PATCH v1 7/7] drm: remove include of drmP.h from drm_gem_cma_helper.h

2018-12-26 Thread Sam Ravnborg
Fix fallout in various files/drivers.

Signed-off-by: Sam Ravnborg 
Cc: Alexey Brodkin 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Yannick Fertre 
Cc: Philippe Cornu 
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Cc: Maxime Coquelin 
Cc: Alexandre Torgue 
Cc: "Noralf Trønnes" 
Cc: David Lechner 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c  | 2 ++
 drivers/gpu/drm/arc/arcpgu_drv.c   | 6 ++
 drivers/gpu/drm/stm/drv.c  | 3 +++
 drivers/gpu/drm/stm/ltdc.c | 9 -
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c| 1 +
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 2 ++
 drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c| 1 +
 drivers/gpu/drm/tinydrm/ili9225.c  | 1 +
 drivers/gpu/drm/tinydrm/mipi-dbi.c | 3 +++
 include/drm/drm_file.h | 1 +
 include/drm/drm_gem_cma_helper.h   | 5 -
 include/drm/tinydrm/tinydrm.h  | 1 +
 12 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 965cda48dc13..41e8bbfe2806 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -16,8 +16,10 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index f067de4e1e82..cca897341921 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -16,11 +16,17 @@
 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
 
 #include "arcpgu.h"
 #include "arcpgu_regs.h"
diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index f2021b23554d..6d41b0fb165f 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -9,12 +9,15 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 808d9fb627e9..8f6249368450 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -10,17 +10,24 @@
 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 255341ee4eb9..cc4f4c6a6cb4 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * DOC: overview
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index dcd390163a4a..d4ec6bcc39b2 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -9,10 +9,12 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
index 7e8e24d0b7a7..652b596070e6 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct tinydrm_connector {
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
index 455fefe012f5..fbd94fe8b36f 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -21,6 +21,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index cb3441e51d5f..c61f5539e58e 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -9,10 +9,13 @@
  * (at your option) any later version.
  */
 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 26485acc51d7..931b072d0aa9 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -30,6 +30,7 @@
 #ifndef _DRM_FILE_H_
 #define _DRM_FILE_H_
 
+#include 
 #include 
 #include 
 
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 19777145cf8e..83907bd1cf53 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -2,9 +2,12 @@
 #ifndef __DRM_GEM_CMA_HELPER_H__
 #define __DRM_GEM_CMA_HELPER_H__
 
-#include 
+#include 
+#include 
 #include 
 
+struct drm_mode_create_dumb;
+
 /**
  * struct drm_gem_cma_object - GEM object backed by 

[PATCH v1 4/7] drm: remove include of drmP.h from bridge/dw_hdmi.h

2018-12-26 Thread Sam Ravnborg
Add missing includes in dw_hdmi.h and
fix fallout in drivers.

Signed-off-by: Sam Ravnborg 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Kieran Bingham 
Cc: Fabio Estevam 
Cc: Neil Armstrong 
Cc: Maxime Ripard 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 4 
 drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c  | 1 +
 include/drm/bridge/dw_hdmi.h| 5 -
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index 8f9c8a6b46de..c61ec4caaa84 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -8,6 +8,10 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+
+#include 
+#include 
+
 #include 
 
 #include 
diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c 
b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
index 75490a3e0a2a..f5b07a2e3f59 100644
--- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
+++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index ccb5aa8468e0..b0218ee75a65 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -10,7 +10,10 @@
 #ifndef __DW_HDMI__
 #define __DW_HDMI__
 
-#include 
+#include 
+
+#include 
+#include 
 
 struct dw_hdmi;
 
-- 
2.12.0



[PATCH v1 2/7] drm: move DRM_SWITCH_POWER defines to drm_device.h

2018-12-26 Thread Sam Ravnborg
Move DRM_SWITCH_POWER out of drmP.h to allow users
to get rid of the drmP include.

DRM_SWITCH_POWER defines are used in combination
with drm_device.switch_power_state.

Move the DRM_SWITCH_POWER defines to the file where
drm_device.switch_power_state is defined.

Signed-off-by: Sam Ravnborg 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 include/drm/drmP.h   | 5 -
 include/drm/drm_device.h | 9 +
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index b6b8436b5123..2ba786820052 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -95,11 +95,6 @@ struct dma_buf_attachment;
 struct pci_dev;
 struct pci_controller;
 
-#define DRM_SWITCH_POWER_ON 0
-#define DRM_SWITCH_POWER_OFF 1
-#define DRM_SWITCH_POWER_CHANGING 2
-#define DRM_SWITCH_POWER_DYNAMIC_OFF 3
-
 /* returns true if currently okay to sleep */
 static inline bool drm_can_sleep(void)
 {
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 42411b3ea0c8..c3da194d25f9 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -24,6 +24,13 @@ struct inode;
 struct pci_dev;
 struct pci_controller;
 
+
+/* Used by drm_device.switch_power_state */
+#define DRM_SWITCH_POWER_ON 0
+#define DRM_SWITCH_POWER_OFF 1
+#define DRM_SWITCH_POWER_CHANGING 2
+#define DRM_SWITCH_POWER_DYNAMIC_OFF 3
+
 /**
  * DRM device structure. This structure represent a complete card that
  * may contain multiple heads.
@@ -222,6 +229,8 @@ struct drm_device {
struct idr object_name_idr;
struct drm_vma_offset_manager *vma_offset_manager;
/*@} */
+
+   /* See DRM_SWITCH_POWER defines */
int switch_power_state;
 
/**
-- 
2.12.0



[PATCH v1 1/7] drm: move DRM_IF_VERSION to drm_internal.h

2018-12-26 Thread Sam Ravnborg
Move DRM_IF_VERSION out of drmP.h to allow users
to get rid of the drmP include.

Signed-off-by: Sam Ravnborg 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_internal.h | 2 ++
 include/drm/drmP.h | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 51e06defc8d8..e9374cd43610 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -26,6 +26,8 @@
 #define DRM_IF_MAJOR 1
 #define DRM_IF_MINOR 4
 
+#define DRM_IF_VERSION(maj, min) (maj << 16 | min)
+
 struct drm_prime_file_private;
 struct dma_buf;
 
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 05350424a4d3..b6b8436b5123 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -95,8 +95,6 @@ struct dma_buf_attachment;
 struct pci_dev;
 struct pci_controller;
 
-#define DRM_IF_VERSION(maj, min) (maj << 16 | min)
-
 #define DRM_SWITCH_POWER_ON 0
 #define DRM_SWITCH_POWER_OFF 1
 #define DRM_SWITCH_POWER_CHANGING 2
-- 
2.12.0



Re: [PATCH v2] net: dsa: bcm_sf2: Propagate error value from mdio_write

2018-12-26 Thread kbuild test robot
Hi Kangjie,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]
[also build test WARNING on v4.20 next-20181224]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Kangjie-Lu/net-dsa-bcm_sf2-Propagate-error-value-from-mdio_write/20181227-042915
config: x86_64-randconfig-x002-201851 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/net//dsa/bcm_sf2.c: In function 'bcm_sf2_sw_mdio_write':
>> drivers/net//dsa/bcm_sf2.c:310:1: warning: control reaches end of non-void 
>> function [-Wreturn-type]
}
^

vim +310 drivers/net//dsa/bcm_sf2.c

461cd1b03 Florian Fainelli 2016-06-07  296  
461cd1b03 Florian Fainelli 2016-06-07  297  static int 
bcm_sf2_sw_mdio_write(struct mii_bus *bus, int addr, int regnum,
461cd1b03 Florian Fainelli 2016-06-07  298   u16 
val)
461cd1b03 Florian Fainelli 2016-06-07  299  {
461cd1b03 Florian Fainelli 2016-06-07  300  struct bcm_sf2_priv *priv = 
bus->priv;
461cd1b03 Florian Fainelli 2016-06-07  301  
461cd1b03 Florian Fainelli 2016-06-07  302  /* Intercept writes to the 
Broadcom pseudo-PHY address, else,
461cd1b03 Florian Fainelli 2016-06-07  303   * send them to our master MDIO 
bus controller
461cd1b03 Florian Fainelli 2016-06-07  304   */
461cd1b03 Florian Fainelli 2016-06-07  305  if (addr == 
BRCM_PSEUDO_PHY_ADDR && priv->indir_phy_mask & BIT(addr))
461cd1b03 Florian Fainelli 2016-06-07  306  
bcm_sf2_sw_indir_rw(priv, 0, addr, regnum, val);
461cd1b03 Florian Fainelli 2016-06-07  307  else
9d3b8e48b Kangjie Lu   2018-12-26  308  return 
mdiobus_write_nested(priv->master_mii_bus,
9d3b8e48b Kangjie Lu   2018-12-26  309  addr, 
regnum, val);
461cd1b03 Florian Fainelli 2016-06-07 @310  }
461cd1b03 Florian Fainelli 2016-06-07  311  

:: The code at line 310 was first introduced by commit
:: 461cd1b03e321e9c4ed1b831c80965c69a7b761b net: dsa: bcm_sf2: Register our 
slave MDIO bus

:: TO: Florian Fainelli 
:: CC: David S. Miller 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


[PATCH v1 0/7] drm: minimize drmP.h dependencies

2018-12-26 Thread Sam Ravnborg
The goal with this small series is to remove the last bits
that prevents us from removing drmP.h file by file.

- drmP.h is now stripped down to include files and forward declarations.
- All header files in include/drm/ no longer include drmP.h.

The series was made on top of 4.20.
Build tested using arm and x86 all{yes,mod}config

Most of the work was to remove the include and fix fallout.

The patches are trivial but touches a lot of files,
so a lot of people on cc: for the individual patches.

I expect the full series to be applied to drm-misc.

There are still ~900 uses of drmP.h so a long way ahead of
us to get rid of the header file.

Sam

Sam Ravnborg (7):
  drm: move DRM_IF_VERSION to drm_internal.h
  drm: move DRM_SWITCH_POWER defines to drm_device.h
  drm: move drm_can_sleep() to drm_util.h
  drm: remove include of drmP.h from bridge/dw_hdmi.h
  drm: remove include of drmP.h from drm_encoder_slave.h
  drm: remove include of drmP.h from drm_modeset_helper.h
  drm: remove include of drmP.h from drm_gem_cma_helper.h

 drivers/gpu/drm/amd/amdgpu/atom.c   |  2 ++
 drivers/gpu/drm/arc/arcpgu_crtc.c   |  2 ++
 drivers/gpu/drm/arc/arcpgu_drv.c|  6 ++
 drivers/gpu/drm/arc/arcpgu_sim.c|  1 +
 drivers/gpu/drm/ast/ast_fb.c|  1 +
 drivers/gpu/drm/bridge/cdns-dsi.c   |  2 ++
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c |  4 
 drivers/gpu/drm/cirrus/cirrus_fbdev.c   |  1 +
 drivers/gpu/drm/drm_flip_work.c |  1 +
 drivers/gpu/drm/drm_internal.h  |  2 ++
 drivers/gpu/drm/drm_modeset_helper.c|  2 ++
 drivers/gpu/drm/mgag200/mgag200_fb.c|  1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c|  1 +
 drivers/gpu/drm/omapdrm/omap_fbdev.c|  1 +
 drivers/gpu/drm/qxl/qxl_cmd.c   |  2 ++
 drivers/gpu/drm/radeon/atom.c   |  2 ++
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |  1 +
 drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c  |  1 +
 drivers/gpu/drm/rcar-du/rcar_lvds.c |  1 +
 drivers/gpu/drm/stm/drv.c   |  3 +++
 drivers/gpu/drm/stm/ltdc.c  |  9 -
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c |  1 +
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c  |  2 ++
 drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c |  1 +
 drivers/gpu/drm/tinydrm/ili9225.c   |  1 +
 drivers/gpu/drm/tinydrm/mipi-dbi.c  |  3 +++
 drivers/gpu/drm/vc4/vc4_drv.h   |  1 +
 include/drm/bridge/dw_hdmi.h|  5 -
 include/drm/drmP.h  | 15 ---
 include/drm/drm_device.h|  9 +
 include/drm/drm_encoder_slave.h |  1 -
 include/drm/drm_file.h  |  1 +
 include/drm/drm_gem_cma_helper.h|  5 -
 include/drm/drm_modeset_helper.h|  2 --
 include/drm/drm_util.h  | 13 +
 include/drm/tinydrm/tinydrm.h   |  1 +
 36 files changed, 86 insertions(+), 21 deletions(-)


Re: [GIT PULL] x86/cache updates for 4.21

2018-12-26 Thread Linus Torvalds
On Wed, Dec 26, 2018 at 12:56 PM Borislav Petkov  wrote:
>
> The intent is, AFAIU, to keep at least the user interface in the resctrl
> fs the same as on x86 so that there's no unnecessary user confusion. And
> from peeking at that patchset a bit, it looks like we'll need a generic
>
> CONFIG_RESCTRL
>
> which should enable the arch-agnostic piece in fs/ and then
> the arch-specific counterpart which we'll probably put behind
> CONFIG_X86_RESCTRL and CONFIG_ARM64_RESCTRL, respectively.
>
> I guess I can send you a patch renaming the x86 config option to
> X86_RESCTRL and the ARM64 side will fall into place when ready. And
> it'll extract the generic bits into that separate generic config option.
>
> Thoughts?

That sounds mostly good to me. Except I still think that
"CONFIG_RESCTRL" is too generic, because it's really not about
resources in general, it's literally about specific CPU resources.

So I'd prefer to call the option for the generic code
"CONFIG_CPU_RESCTRL", which is then selected by the arch option (ie
CONFIG_{X86,ARM64}_RESCTRL).

Anyway, this is mostly bikeshedding, but naming is fairly important.
But not time-critical at this point,

 Linus


Re: [GIT PULL] x86/cache updates for 4.21

2018-12-26 Thread Borislav Petkov
On Wed, Dec 26, 2018 at 12:26:12PM -0800, Linus Torvalds wrote:
> I've pulled this, but I think the new config option name is bad.
> 
> I think it should probably have been called "X86_RESCTRL" instead of
> just "RESCTRL". That's way too generic a name for something that is
> (at least currently) very much an x86 feature.

Right you are...

> It not only is x86-specific right now, it's specific to very few
> resources. It's not like this is some generic resource control, it's
> very much about low-level CPU resources. That should show in the name.
> 
> I've left it alone, and maybe it might even be cross-architecture some
> day (there's already a hack in the scheduler),
> but I think it's a bit misleading to have so a common name for such a
> specialized thing.
>
> Even if it some day gets to be cross-architecture and isn't limited to
> x86, at that point it _still_ wouldn't be "RESCTRL", it would be
> "CPU_RESCTRL" or something.

... and yap, that is already going in the cross-arch direction as
apparently there's work to have a similar thing on the ARM64 side:

https://lore.kernel.org/lkml/20180824104519.11203-1-james.mo...@arm.com/T/#u

The intent is, AFAIU, to keep at least the user interface in the resctrl
fs the same as on x86 so that there's no unnecessary user confusion. And
from peeking at that patchset a bit, it looks like we'll need a generic

CONFIG_RESCTRL

which should enable the arch-agnostic piece in fs/ and then
the arch-specific counterpart which we'll probably put behind
CONFIG_X86_RESCTRL and CONFIG_ARM64_RESCTRL, respectively.

I guess I can send you a patch renaming the x86 config option to
X86_RESCTRL and the ARM64 side will fall into place when ready. And
it'll extract the generic bits into that separate generic config option.

Thoughts?

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)


Re: [PATCH v14] i2c: Add drivers for the AMD PCIe MP2 I2C controller

2018-12-26 Thread kbuild test robot
Hi Elie,

I love your patch! Yet something to improve:

[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on v4.20 next-20181224]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Elie-Morisse/i2c-Add-drivers-for-the-AMD-PCIe-MP2-I2C-controller/20181223-034458
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
i2c/for-next
config: i386-randconfig-x013-12261115 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/i2c/busses/i2c-amd-mp2-plat.c: In function 'i2c_amd_probe':
>> drivers/i2c/busses/i2c-amd-mp2-plat.c:294:17: error: 'struct amd_i2c_common' 
>> has no member named 'suspend'
 i2c_dev->common.suspend = _amd_suspend;
^
>> drivers/i2c/busses/i2c-amd-mp2-plat.c:294:29: error: 'i2c_amd_suspend' 
>> undeclared (first use in this function); did you mean 'i2c_amd_func'?
 i2c_dev->common.suspend = _amd_suspend;
^~~
i2c_amd_func
   drivers/i2c/busses/i2c-amd-mp2-plat.c:294:29: note: each undeclared 
identifier is reported only once for each function it appears in
>> drivers/i2c/busses/i2c-amd-mp2-plat.c:295:18: error: 'struct amd_i2c_common' 
>> has no member named 'resume'; did you mean 'reqcmd'?
 i2c_dev->common.resume = _amd_resume;
 ^~
 reqcmd
>> drivers/i2c/busses/i2c-amd-mp2-plat.c:295:28: error: 'i2c_amd_resume' 
>> undeclared (first use in this function); did you mean 'i2c_amd_probe'?
 i2c_dev->common.resume = _amd_resume;
   ^~
   i2c_amd_probe

vim +294 drivers/i2c/busses/i2c-amd-mp2-plat.c

   263  
   264  static int i2c_amd_probe(struct platform_device *pdev)
   265  {
   266  int ret;
   267  struct amd_i2c_dev *i2c_dev;
   268  acpi_handle handle = ACPI_HANDLE(>dev);
   269  struct acpi_device *adev;
   270  struct amd_mp2_dev *mp2_dev;
   271  const char *uid;
   272  
   273  if (acpi_bus_get_device(handle, ))
   274  return -ENODEV;
   275  
   276  /* The ACPI namespace doesn't contain information about which 
MP2 PCI
   277   * device an AMDI0011 ACPI device is related to, so assume that 
there's
   278   * only one MP2 PCI device per system.
   279   */
   280  mp2_dev = amd_mp2_find_device();
   281  if (!mp2_dev)
   282  /* The MP2 PCI device might get probed later */
   283  return -EPROBE_DEFER;
   284  
   285  i2c_dev = devm_kzalloc(>dev, sizeof(*i2c_dev), 
GFP_KERNEL);
   286  if (!i2c_dev)
   287  return -ENOMEM;
   288  
   289  i2c_dev->common.mp2_dev = mp2_dev;
   290  i2c_dev->pdev = pdev;
   291  platform_set_drvdata(pdev, i2c_dev);
   292  
   293  i2c_dev->common.cmd_completion = _amd_cmd_completion;
 > 294  i2c_dev->common.suspend = _amd_suspend;
 > 295  i2c_dev->common.resume = _amd_resume;
   296  
   297  uid = adev->pnp.unique_id;
   298  if (!uid) {
   299  dev_err(>dev, "missing UID/bus id!\n");
   300  return -EINVAL;
   301  } else if (strcmp(uid, "0") == 0) {
   302  i2c_dev->common.bus_id = 0;
   303  } else if (strcmp(uid, "1") == 0) {
   304  i2c_dev->common.bus_id = 1;
   305  } else {
   306  dev_err(>dev, "incorrect UID/bus id \"%s\"!\n", 
uid);
   307  return -EINVAL;
   308  }
   309  dev_dbg(>dev, "bus id is %u\n", i2c_dev->common.bus_id);
   310  
   311  /* Register the adapter */
   312  amd_mp2_pm_runtime_get(mp2_dev);
   313  
   314  i2c_dev->common.reqcmd = i2c_none;
   315  if (amd_mp2_register_cb(_dev->common))
   316  return -EINVAL;
   317  device_link_add(_dev->pdev->dev, _dev->pci_dev->dev,
   318  DL_FLAG_AUTOREMOVE_CONSUMER);
   319  
   320  i2c_dev->common.i2c_speed = i2c_amd_get_bus_speed(pdev);
   321  
   322  /* Setup i2c adapter description */
   323  i2c_dev->adap.owner = THIS_MODULE;
   324  i2c_dev->adap.algo = _amd_algorithm;
   325  i2c_dev->adap.quirks = _i2c_dev_quirks;
   326  i2c_dev->adap.dev.parent = >dev;
   327  i2c_dev->adap.algo_data = i2c_dev;
   328  i2c_dev->adap.nr = pdev->id;
   329  i2c_dev->adap.timeout = AMD_I2C_TIMEOUT;
   330  ACPI_COMPANION_SET(_dev->adap.dev, 
ACPI_COMPANION(>dev));
   331  i2c_dev->adap.dev.of_node = pdev->dev.of_node;
   332  

Re: [PATCH v2] vfat: don't read garbage after last dirent

2018-12-26 Thread Matteo Croce
On Mon, Dec 24, 2018 at 1:14 PM OGAWA Hirofumi
 wrote:
>
> Matteo Croce  writes:
>
> > The FAT32 File System Specification[1] states that:
> >
> > If DIR_Name[0] == 0x00, then the directory entry is free, and there
> > are no allocated directory entries after this one.
> >
> > The special 0 value, indicates to FAT file system driver code that
> > the rest of the entries in this directory do not need to be examined
> > because they are all free.
> >
> > This is not enforced by Linux, and is possible to read garbage if not
> > all dirents after the last one are filled with zeroes.
> >
> > [1] 
> > http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc
> >
> > Reported-by: Timothy Redaelli 
> > Signed-off-by: Matteo Croce 
>
> We have to handle all paths that is using fat_get_entry(), to make
> consistent behavior.
>
> With quick check, there are still several issues remaining. Please check
> more. For example, looks like fat_parse_long()/fat_search_long() path is
> missing, and fat_get_dotdot_entry(), fat_subdirs() too.
>

If I put the check in fat_get_short_entry(), then
fat_get_dotdot_entry() and fat_subdirs() are covered too.
Is there any drawback in doing this?

> (while adding new entry, if we found zeroed entry, we would be better to
> warn about fsck.)
>

Ok

> Thanks.
> --
> OGAWA Hirofumi 

Thanks,
-- 
Matteo Croce
per aspera ad upstream


[PATCH][next] KVM: x86: Fix bit shifting in update_intel_pt_cfg

2018-12-26 Thread Gustavo A. R. Silva
ctl_bitmask in pt_desc is of type u64. When an integer like 0xf is
being left shifted more than 32 bits, the behavior is undefined.

Fix this by adding suffix ULL to integer 0xf.

Addresses-Coverity-ID: 1476095 ("Bad bit shift operation")
Fixes: 6c0f0bba85a0 ("KVM: x86: Introduce a function to initialize the PT 
configuration")
Signed-off-by: Gustavo A. R. Silva 
---
 arch/x86/kvm/vmx/vmx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index cbd55e7aeae5..251c68a74bbe 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -7012,7 +7012,7 @@ static void update_intel_pt_cfg(struct kvm_vcpu *vcpu)
 
/* unmask address range configure area */
for (i = 0; i < vmx->pt_desc.addr_range; i++)
-   vmx->pt_desc.ctl_bitmask &= ~(0xf << (32 + i * 4));
+   vmx->pt_desc.ctl_bitmask &= ~(0xfULL << (32 + i * 4));
 }
 
 static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
-- 
2.20.1



Re: [PATCH] net: dsa: bcm_sf2: Propagate error value from mdio_write

2018-12-26 Thread David Miller
From: Heiner Kallweit 
Date: Wed, 26 Dec 2018 20:13:15 +0100

> On 26.12.2018 19:21, Kangjie Lu wrote:
>> Both bcm_sf2_sw_indir_rw and mdiobus_write_nested could fail, so let's
>> return their error codes upstream.
>> 
>> Signed-off-by: Kangjie Lu 
>> ---
>>  drivers/net/dsa/bcm_sf2.c | 7 +++
>>  1 file changed, 3 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
>> index 2eb68769562c..236815700fba 100644
>> --- a/drivers/net/dsa/bcm_sf2.c
>> +++ b/drivers/net/dsa/bcm_sf2.c
>> @@ -303,11 +303,10 @@ static int bcm_sf2_sw_mdio_write(struct mii_bus *bus, 
>> int addr, int regnum,
>>   * send them to our master MDIO bus controller
>>   */
>>  if (addr == BRCM_PSEUDO_PHY_ADDR && priv->indir_phy_mask & BIT(addr))
>> -bcm_sf2_sw_indir_rw(priv, 0, addr, regnum, val);
>> +return bcm_sf2_sw_indir_rw(priv, 0, addr, regnum, val);
> This is wrong. Please get familiar with what the function does.
> And test changes before submitting them!

This is getting rediculous.

You are making completely untested changes, resubmitting very quickly
without any care or consideration whatsoever, and wasting a lot of
developer time with your carelessness.

Please stop doing this.


Re: [PATCH 3/3] soc: qcom: Add AOSS QMP genpd provider

2018-12-26 Thread Bjorn Andersson
On Mon 26 Nov 19:31 PST 2018, Sai Prakash Ranjan wrote:

> Hi Bjorn,
> 

Thanks for your review Sai!

> On 11/12/2018 1:35 PM, Bjorn Andersson wrote:
[..]
> > +static int qmp_pd_clock_toggle(struct qmp_pd *res, bool enable)
> > +{
> > +   char buf[96];
> > +   size_t n;
> > +
> > +   n = snprintf(buf, sizeof(buf), "{class: clock, res: %s, val: %d}",
> > +res->name, !!enable);
> > +   return qmp_send(res->qmp, buf, n);
> > +}
> > +
> 
> I was trying to get QDSS working with these patches and found one issue
> in qmp_send of qmp_pd_clock_toggle.
> 
> The third return value should be sizeof(buf) instead of n because n just
> returns len as 33 and the below check in qmp send will always fail and
> trigger WARN_ON's.
> 
>  if (WARN_ON(len % sizeof(u32))) {
>  dev_err(qmp->dev, "message not 32-bit aligned\n");
>  return -EINVAL;
>  }
> 
> Also I observed that multiple "ucore will not ack channel" messages with
> len being returned n instead of buf size.
> 

I must have been "lucky" when I did my final pass of cleanups and
retests, thanks for spotting this!

> One more thing is do we really require *WARN_ON and dev_err* both because it
> just spams the kernel logs, I think dev_err message is clear
> enough to be able to understand the error condition.
> 

No, that's just unnecessary.

Regards,
Bjorn


Re: [PATCH 2/3] soc: qcom: Add AOSS QMP communication driver

2018-12-26 Thread Bjorn Andersson
On Tue 20 Nov 04:22 PST 2018, Arun Kumar Neelakantam wrote:

Thanks for the review Arun.

> On 11/12/2018 1:35 PM, Bjorn Andersson wrote:
[..]
> > +int qmp_send(struct qmp *qmp, const void *data, size_t len)
> > +{
> > +   int ret;
> > +
> > +   if (WARN_ON(len + sizeof(u32) > qmp->size)) {
> > +   dev_err(qmp->dev, "message too long\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   if (WARN_ON(len % sizeof(u32))) {
> > +   dev_err(qmp->dev, "message not 32-bit aligned\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   mutex_lock(>tx_lock);
> > +
> > +   if (!qmp_message_empty(qmp)) {
> > +   dev_err(qmp->dev, "mailbox left busy\n");
> > +   ret = -EINVAL;
> should it be -EBUSY ?

That makes more sense.

> And qmp_messge_empty will be done either by remote if it process the data
> else by this driver in TIMEOUT case, so does we need this check for every TX
> ? I think we can just reset to Zero once in open time.

Didn't think about that, should we really make the QMP link ready again
when we get a timeout? Can we expect that the firmware of the remote
side is ready to serve future messages?


Should we keep this check and remove the writel() below?

> > +   goto out_unlock;
> > +   }
> > +
> > +   /* The message RAM only implements 32-bit accesses */
> > +   __iowrite32_copy(qmp->msgram + qmp->offset + sizeof(u32),
> > +data, len / sizeof(u32));
> > +   writel(len, qmp->msgram + qmp->offset);
> > +   qmp_kick(qmp);
> > +
> > +   ret = wait_event_interruptible_timeout(qmp->event,
> > +  qmp_message_empty(qmp), HZ);
> > +   if (!ret) {
> > +   dev_err(qmp->dev, "ucore did not ack channel\n");
> > +   ret = -ETIMEDOUT;
> > +
> > +   writel(0, qmp->msgram + qmp->offset);
> > +   } else {
> > +   ret = 0;
> > +   }
> > +
> > +out_unlock:
> > +   mutex_unlock(>tx_lock);
> > +
> > +   return ret;
> > +}

Regards,
Bjorn


Re: [GIT PULL] x86/cache updates for 4.21

2018-12-26 Thread Linus Torvalds
On Sun, Dec 23, 2018 at 4:49 AM Borislav Petkov  wrote:
>
>  - The generalization of the RDT code to accommodate the addition of AMD's
>very similar implementation of the cache monitoring feature.

I've pulled this, but I think the new config option name is bad.

I think it should probably have been called "X86_RESCTRL" instead of
just "RESCTRL". That's way too generic a name for something that is
(at least currently) very much an x86 feature.

It not only is x86-specific right now, it's specific to very few
resources. It's not like this is some generic resource control, it's
very much about low-level CPU resources. That should show in the name.

I've left it alone, and maybe it might even be cross-architecture some
day (there's already a hack in the scheduler), but I think it's a bit
misleading to have so a common name for such a specialized thing.

Even if it some day gets to be cross-architecture and isn't limited to
x86, at that point it _still_ wouldn't be "RESCTRL", it would be
"CPU_RESCTRL" or something.

No?

Linus


Re: [PATCH v5 2/5] Bluetooth: hci_qca: Deassert RTS while baudrate change command

2018-12-26 Thread Matthias Kaehlcke
Hi Balakrishna,

On Wed, Dec 26, 2018 at 11:15:30AM +0530, Balakrishna Godavarthi wrote:
> Hi Matthias,
> 
> On 2018-12-22 06:01, Matthias Kaehlcke wrote:
> > On Thu, Dec 20, 2018 at 08:16:36PM +0530, Balakrishna Godavarthi wrote:
> > > This patch will help to stop frame reassembly errors while changing
> > > the baudrate. This is because host send a change baudrate request
> > > command to the chip with 115200 bps, Whereas chip will change their
> > > UART clocks to the enable for new baudrate and sends the response
> > > for the change request command with newer baudrate, On host side
> > > we are still operating in 115200 bps which results of reading garbage
> > > data. Here we are pulling RTS line, so that chip we will wait to
> > > send data
> > > to host until host change its baudrate.
> > > 
> > > Signed-off-by: Balakrishna Godavarthi 
> > > Tested-by: Matthias Kaehlcke 
> > > Reviewed-by: Matthias Kaehlcke 
> > > ---
> > >  drivers/bluetooth/hci_qca.c | 24 +---
> > >  1 file changed, 13 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > > index 5a07c2370289..1680ead6cc3d 100644
> > > --- a/drivers/bluetooth/hci_qca.c
> > > +++ b/drivers/bluetooth/hci_qca.c
> > > @@ -963,7 +963,6 @@ static int qca_set_baudrate(struct hci_dev
> > > *hdev, uint8_t baudrate)
> > >   struct hci_uart *hu = hci_get_drvdata(hdev);
> > >   struct qca_data *qca = hu->priv;
> > >   struct sk_buff *skb;
> > > - struct qca_serdev *qcadev;
> > >   u8 cmd[] = { 0x01, 0x48, 0xFC, 0x01, 0x00 };
> > > 
> > >   if (baudrate > QCA_BAUDRATE_320)
> > > @@ -977,13 +976,6 @@ static int qca_set_baudrate(struct hci_dev
> > > *hdev, uint8_t baudrate)
> > >   return -ENOMEM;
> > >   }
> > > 
> > > - /* Disabling hardware flow control is mandatory while
> > > -  * sending change baudrate request to wcn3990 SoC.
> > > -  */
> > > - qcadev = serdev_device_get_drvdata(hu->serdev);
> > > - if (qcadev->btsoc_type == QCA_WCN3990)
> > > - hci_uart_set_flow_control(hu, true);
> > > -
> > >   /* Assign commands to change baudrate and packet type. */
> > >   skb_put_data(skb, cmd, sizeof(cmd));
> > >   hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
> > > @@ -999,9 +991,6 @@ static int qca_set_baudrate(struct hci_dev
> > > *hdev, uint8_t baudrate)
> > >   schedule_timeout(msecs_to_jiffies(BAUDRATE_SETTLE_TIMEOUT_MS));
> > >   set_current_state(TASK_RUNNING);
> > > 
> > > - if (qcadev->btsoc_type == QCA_WCN3990)
> > > - hci_uart_set_flow_control(hu, false);
> > > -
> > >   return 0;
> > >  }
> > > 
> > > @@ -1086,6 +1075,7 @@ static int qca_check_speeds(struct hci_uart *hu)
> > >  static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type
> > > speed_type)
> > >  {
> > >   unsigned int speed, qca_baudrate;
> > > + struct qca_serdev *qcadev;
> > >   int ret;
> > > 
> > >   if (speed_type == QCA_INIT_SPEED) {
> > > @@ -1097,6 +1087,15 @@ static int qca_set_speed(struct hci_uart *hu,
> > > enum qca_speed_type speed_type)
> > >   if (!speed)
> > >   return 0;
> > > 
> > > + /* Deassert RTS while changing the baudrate of chip and host.
> > > +  * This will prevent chip from transmitting its response with
> > > +  * the new baudrate while the host port is still operating at
> > > +  * the old speed.
> > > +  */
> > > + qcadev = serdev_device_get_drvdata(hu->serdev);
> > > + if (qcadev->btsoc_type == QCA_WCN3990)
> > > + serdev_device_set_rts(hu->serdev, false);
> > > +
> > >   qca_baudrate = qca_get_baudrate_value(speed);
> > >   bt_dev_dbg(hu->hdev, "Set UART speed to %d", speed);
> > >   ret = qca_set_baudrate(hu->hdev, qca_baudrate);
> > > @@ -1104,6 +1103,9 @@ static int qca_set_speed(struct hci_uart *hu,
> > > enum qca_speed_type speed_type)
> > >   return ret;
> > > 
> > >   host_set_baudrate(hu, speed);
> > > +
> > > + if (qcadev->btsoc_type == QCA_WCN3990)
> > > + serdev_device_set_rts(hu->serdev, true);
> > >   }
> > > 
> > >   return 0;
> > 
> > I looked for ways to do without this change, but didn't find a good
> > solution. There are several possible problems with baudrate changes:
> > 
> > 1) send request to BT controller to change the baudrate
> > 
> >   this is an asynchronous operation, the actual baudrate change can
> >   be delayed for multiple reasons, e.g.:
> > 
> >   - request sits in the BT driver's TX queue
> > 
> > this could be worked around by checking skb_queue_empty()
> > 
> >   - request sits in the UART buffer
> > 
> > a workaround for this could be calling
> > serdev_device_wait_until_sent() (only available with serdev though)
> > 
> >   - the request sits in the UART FIFO
> > 
> > will be sent out 'immediately'. no neat solution available AFAIK,
> > a short sleep could be an effective workaround
> > 
> >   - the controller may 

Re: [GIT PULL] xen: features and fixes for 4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Thu, 20 Dec 2018 19:28:23 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
> for-linus-4.21-rc1-tag

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/460023a5d1d2aa0f733b6708b2fae5ea9f9dfec0

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] Changes for KVM 4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Sun, 23 Dec 2018 10:14:15 +0100:

> https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/42b00f122cfbfed79fc29b0b3610f3abbb1e3864

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [PATCH] input/touchscreen: Fix a missing check on regmap_bulk_read

2018-12-26 Thread Dmitry Torokhov
Hi,

On Mon, Dec 24, 2018 at 12:37:19PM -0600, Aditya Pakki wrote:
> regmap_bulk_read() can return a non zero value on failure. The fix
> checks if the function call succeeded before calling mod_timer.
> 
> Signed-off-by: Aditya Pakki 
> ---
>  drivers/input/touchscreen/ad7879.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/ad7879.c 
> b/drivers/input/touchscreen/ad7879.c
> index 6bad23ee47a1..735cb4c0d913 100644
> --- a/drivers/input/touchscreen/ad7879.c
> +++ b/drivers/input/touchscreen/ad7879.c
> @@ -247,11 +247,12 @@ static void ad7879_timer(struct timer_list *t)
>  static irqreturn_t ad7879_irq(int irq, void *handle)
>  {
>   struct ad7879 *ts = handle;
> + int ret;
>  
> - regmap_bulk_read(ts->regmap, AD7879_REG_XPLUS,
> -  ts->conversion_data, AD7879_NR_SENSE);
> + ret = regmap_bulk_read(ts->regmap, AD7879_REG_XPLUS,
> + ts->conversion_data, AD7879_NR_SENSE);

I'd probably say:

error = regmap_bulk_read(...);
if (error)
dev_err_ratelimited(...);
else if (!ad7879_report(ts))
mod_timer(>timer, jiffies + TS_PEN_UP_TIMEOUT);

Were the failures observed in real life or it is some kind of class
project?

>  
> - if (!ad7879_report(ts))
> + if (!ret && !ad7879_report(ts))
>   mod_timer(>timer, jiffies + TS_PEN_UP_TIMEOUT);
>  
>   return IRQ_HANDLED;
> -- 
> 2.17.1
> 

Thanks.

-- 
Dmitry


Re: [PATCH v3 08/11] ASoC: Intel: atom: Make PCI dependency explicit

2018-12-26 Thread Sinan Kaya
On Wed, Dec 26, 2018 at 8:35 PM Pierre-Louis Bossart
 wrote:
>
>
> On 12/23/18 5:25 PM, Sinan Kaya wrote:
> > Code does unconditional select for IOSF_MBI. IOSF_MBI driver depends on
> > CONFIG_PCI set but this is not specified anywhere.
>
> Can you please share the .config that exposes this problem? This hasn't
> changed in a long time and I wonder why this pops up now. You have
> similar cases elsewhere, e.g. arch/x86/Kconfig
>
Here is the background :

I have a changeset that was added to 4.21-rc1 that decouples  ACPI from
PCI. PCI was automatically selected when ACPI was chosen before.

This is no longer true.

If a code needs PCI support, it now needs to explicitly state that.

This allows usecase for smaller kernels and component isolation.

> config X86_INTEL_LPSS
>  bool "Intel Low Power Subsystem Support"
>  depends on X86 && ACPI
>  select COMMON_CLK
>  select PINCTRL
>  select IOSF_MBI
>
> or for the MMC.
>
> config MMC_SDHCI_ACPI
>  tristate "SDHCI support for ACPI enumerated SDHCI controllers"
>  depends on MMC_SDHCI && ACPI
>  select IOSF_MBI if X86
>
> The use of IOSF_MBI is only for the Baytrail-CR detection and there are
> already in-flight patches to change the code and move it to a helper.
>
> My understanding is that for compilation you only need CONFIG_x86 since
> there are fall-back routines available in iosf_mbi.h
>
> Thanks!
>
> >
> > Signed-off-by: Sinan Kaya 
> > ---
> >   sound/soc/intel/Kconfig | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
> > index 2fd1b61e8331..b0764b2fe001 100644
> > --- a/sound/soc/intel/Kconfig
> > +++ b/sound/soc/intel/Kconfig
> > @@ -91,7 +91,7 @@ config SND_SST_ATOM_HIFI2_PLATFORM_PCI
> >   config SND_SST_ATOM_HIFI2_PLATFORM_ACPI
> >   tristate "ACPI HiFi2 (Baytrail, Cherrytrail) Platforms"
> >   default ACPI
> > - depends on X86 && ACPI
> > + depends on X86 && ACPI && PCI
> >   select SND_SST_IPC_ACPI
> >   select SND_SST_ATOM_HIFI2_PLATFORM
> >   select SND_SOC_ACPI_INTEL_MATCH


Re: [PATCH v2] touchscreen: elants: fix a missing check of return values

2018-12-26 Thread Dmitry Torokhov
Hi,

On Mon, Dec 24, 2018 at 10:36:13PM -0600, Kangjie Lu wrote:
> elants_i2c_send() may fail, let's check its return values. The fix does
> the check and reports an error message upon the failure.
> 
> Signed-off-by: Kangjie Lu 
> ---
>  drivers/input/touchscreen/elants_i2c.c | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/elants_i2c.c 
> b/drivers/input/touchscreen/elants_i2c.c
> index f2cb23121833..8ccba4ccee37 100644
> --- a/drivers/input/touchscreen/elants_i2c.c
> +++ b/drivers/input/touchscreen/elants_i2c.c
> @@ -245,8 +245,22 @@ static int elants_i2c_calibrate(struct elants_data *ts)
>   ts->state = ELAN_WAIT_RECALIBRATION;
>   reinit_completion(>cmd_done);
>  
> - elants_i2c_send(client, w_flashkey, sizeof(w_flashkey));
> - elants_i2c_send(client, rek, sizeof(rek));
> + error = elants_i2c_send(client, w_flashkey, sizeof(w_flashkey));
> + if (error) {
> + dev_err(>dev,
> + "error in sending the w_flashkey command for 
> calibration: %d\n",
> + error);
> + enable_irq(client->irq);
> + return error;
> + }
> +  error = elants_i2c_send(client, rek, sizeof(rek));

Messed up formatting.

> + if (error) {
> + dev_err(>dev,
> + "error in sending the rek command for 
> calibration: %d\n",
> + error);
> + enable_irq(client->irq);
> + return error;

This also leaves the touchscreen in ELAN_WAIT_RECALIBRATION state. I
think all in all I'd rather leave the code as it was.

> + }
>  
>   enable_irq(client->irq);
>  
> -- 
> 2.17.2 (Apple Git-113)
> 

Thanks.

-- 
Dmitry


Re: [PATCH] keyboard: (samsung) fix a missing check of return value

2018-12-26 Thread Dmitry Torokhov
Hi,

On Tue, Dec 25, 2018 at 07:51:29PM -0600, Kangjie Lu wrote:
> of_device_is_compatible() returns false if the device is incompatible.
> The fix adds a check for its return value;
> 
> Signed-off-by: Kangjie Lu 
> ---
>  drivers/input/keyboard/samsung-keypad.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/input/keyboard/samsung-keypad.c 
> b/drivers/input/keyboard/samsung-keypad.c
> index 1fe1aa2adf85..5ba940f3f76e 100644
> --- a/drivers/input/keyboard/samsung-keypad.c
> +++ b/drivers/input/keyboard/samsung-keypad.c
> @@ -387,9 +387,13 @@ static int samsung_keypad_probe(struct platform_device 
> *pdev)
>   keypad->stopped = true;
>   init_waitqueue_head(>wait);
>  
> - if (pdev->dev.of_node)
> - keypad->type = of_device_is_compatible(pdev->dev.of_node,
> - "samsung,s5pv210-keypad");
> + if (pdev->dev.of_node) {
> + error = of_device_is_compatible(pdev->dev.of_node,
> + "samsung,s5pv210-keypad");
> + if (!error)
> + return -EINVAL;

What makes you think that not matching on this compatible is an error?
Have you looked at the rest of the dirver?

> + keypad->type = error;
> + }
>   else
>   keypad->type = platform_get_device_id(pdev)->driver_data;
>  
> -- 
> 2.17.2 (Apple Git-113)
> 

-- 
Dmitry


Re: [PATCH] infiniband: fix a missing check of nla_put

2018-12-26 Thread Leon Romanovsky
On Tue, Dec 25, 2018 at 08:05:48PM -0600, Kangjie Lu wrote:
> nla_put() may fail. The fix adds a check for its return value, and
> returns -EMSGSIZE if it fails.
>
> Signed-off-by: Kangjie Lu 
> ---
>  drivers/infiniband/core/addr.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

The same comment as on previous patch, lack of netlink cancel.

Thanks

>
> diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
> index 0dce94e3c495..32d033ebaa5b 100644
> --- a/drivers/infiniband/core/addr.c
> +++ b/drivers/infiniband/core/addr.c
> @@ -178,7 +178,8 @@ static int ib_nl_ip_send_msg(struct rdma_dev_addr 
> *dev_addr,
>   /* Construct the family header first */
>   header = skb_put(skb, NLMSG_ALIGN(sizeof(*header)));
>   header->ifindex = dev_addr->bound_dev_if;
> - nla_put(skb, attrtype, size, daddr);
> + if (nla_put(skb, attrtype, size, daddr))
> + return -EMSGSIZE;
>
>   /* Repair the nlmsg header length */
>   nlmsg_end(skb, nlh);
> --
> 2.17.2 (Apple Git-113)
>


signature.asc
Description: PGP signature


Re: [PATCH] infiniband: add checks for the status of nla_put

2018-12-26 Thread Leon Romanovsky
On Tue, Dec 25, 2018 at 08:11:39PM -0600, Kangjie Lu wrote:
> The fix inserts multiple checks for nla_put, and issues warnings if it
> fails.
>
> Signed-off-by: Kangjie Lu 
> ---

I didn't look very close, but it strange that failure in nla_put()
doesn't follow by canceling of netlink message.

Plus extensive usage of pr_warn() is not needed here.

Thanks



>  drivers/infiniband/core/sa_query.c | 39 ++
>  1 file changed, 24 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/infiniband/core/sa_query.c 
> b/drivers/infiniband/core/sa_query.c
> index be5ba5e15496..0e5d7a6dde36 100644
> --- a/drivers/infiniband/core/sa_query.c
> +++ b/drivers/infiniband/core/sa_query.c
> @@ -775,28 +775,37 @@ static void ib_nl_set_path_rec_attrs(struct sk_buff 
> *skb,
>   /* Now build the attributes */
>   if (comp_mask & IB_SA_PATH_REC_SERVICE_ID) {
>   val64 = be64_to_cpu(sa_rec->service_id);
> - nla_put(skb, RDMA_NLA_F_MANDATORY | LS_NLA_TYPE_SERVICE_ID,
> - sizeof(val64), );
> + if (nla_put(skb, RDMA_NLA_F_MANDATORY | LS_NLA_TYPE_SERVICE_ID,
> + sizeof(val64), ))
> + pr_warn("nla_put failed\n");
> + }
> + if (comp_mask & IB_SA_PATH_REC_DGID) {
> + if (nla_put(skb, RDMA_NLA_F_MANDATORY | LS_NLA_TYPE_DGID,
> + sizeof(sa_rec->dgid), _rec->dgid))
> + pr_warn("nla_put failed\n");
> + }
> + if (comp_mask & IB_SA_PATH_REC_SGID) {
> + if (nla_put(skb, RDMA_NLA_F_MANDATORY | LS_NLA_TYPE_SGID,
> + sizeof(sa_rec->sgid), _rec->sgid))
> + pr_warn("nla_put failed\n");
> + }
> + if (comp_mask & IB_SA_PATH_REC_TRAFFIC_CLASS) {
> + if (nla_put(skb, RDMA_NLA_F_MANDATORY | LS_NLA_TYPE_TCLASS,
> + sizeof(sa_rec->traffic_class), _rec->traffic_class))
> + pr_warn("nla_put failed\n");
>   }
> - if (comp_mask & IB_SA_PATH_REC_DGID)
> - nla_put(skb, RDMA_NLA_F_MANDATORY | LS_NLA_TYPE_DGID,
> - sizeof(sa_rec->dgid), _rec->dgid);
> - if (comp_mask & IB_SA_PATH_REC_SGID)
> - nla_put(skb, RDMA_NLA_F_MANDATORY | LS_NLA_TYPE_SGID,
> - sizeof(sa_rec->sgid), _rec->sgid);
> - if (comp_mask & IB_SA_PATH_REC_TRAFFIC_CLASS)
> - nla_put(skb, RDMA_NLA_F_MANDATORY | LS_NLA_TYPE_TCLASS,
> - sizeof(sa_rec->traffic_class), _rec->traffic_class);
>
>   if (comp_mask & IB_SA_PATH_REC_PKEY) {
>   val16 = be16_to_cpu(sa_rec->pkey);
> - nla_put(skb, RDMA_NLA_F_MANDATORY | LS_NLA_TYPE_PKEY,
> - sizeof(val16), );
> + if (nla_put(skb, RDMA_NLA_F_MANDATORY | LS_NLA_TYPE_PKEY,
> + sizeof(val16), ))
> + pr_warn("nla_put failed\n");
>   }
>   if (comp_mask & IB_SA_PATH_REC_QOS_CLASS) {
>   val16 = be16_to_cpu(sa_rec->qos_class);
> - nla_put(skb, RDMA_NLA_F_MANDATORY | LS_NLA_TYPE_QOS_CLASS,
> - sizeof(val16), );
> + if (nla_put(skb, RDMA_NLA_F_MANDATORY | LS_NLA_TYPE_QOS_CLASS,
> + sizeof(val16), ))
> + pr_warn("nla_put failed\n");
>   }
>  }
>
> --
> 2.17.2 (Apple Git-113)
>


signature.asc
Description: PGP signature


Re: [PATCH] perf python: Do not force closing original perf descriptor in evlist.get_pollfd

2018-12-26 Thread Arnaldo Carvalho de Melo
Em Wed, Dec 26, 2018 at 12:21:21PM +0100, Jiri Olsa escreveu:
> Ondřej reported that when compiled with python3, the python
> extension regress in evlist.get_pollfd function behaviour.
> 
> The evlist.get_pollfd creates file objects from evlist's fds
> and returns them in the list. The python3 version also sets
> them to 'close the original descriptor' when the object die
> (is closed), by passing True via 'closefd' arg in PyFile_FromFd
> call.
> 
> The python's closefd doc says:
>   If closefd is False, the underlying file descriptor will be kept open
>   when the file is closed.
> 
> That's why following line in python3 closes all evlist fds:
>   evlist.get_pollfd()
> 
> the returned list is immediately destroyed and that takes
> down the original events fds.
> 
> Passing closefd as False to PyFile_FromFd to fix this.

Applied.

- Arnaldo
 
> Reported-by: Ondřej Lysoněk 
> Link: http://lkml.kernel.org/n/tip-ru9hmsaliew8p01kr0050...@git.kernel.org
> Signed-off-by: Jiri Olsa 
> ---
>  tools/perf/util/python.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
> index 47628e85c5eb..dda0ac978b1e 100644
> --- a/tools/perf/util/python.c
> +++ b/tools/perf/util/python.c
> @@ -939,7 +939,8 @@ static PyObject *pyrf_evlist__get_pollfd(struct 
> pyrf_evlist *pevlist,
>  
>   file = PyFile_FromFile(fp, "perf", "r", NULL);
>  #else
> - file = PyFile_FromFd(evlist->pollfd.entries[i].fd, "perf", "r", 
> -1, NULL, NULL, NULL, 1);
> + file = PyFile_FromFd(evlist->pollfd.entries[i].fd, "perf", "r", 
> -1,
> +  NULL, NULL, NULL, 0);
>  #endif
>   if (file == NULL)
>   goto free_list;
> -- 
> 2.17.2

-- 

- Arnaldo


Re: [v6] PCI: imx: make msi work without CONFIG_PCIEPORTBUS=y

2018-12-26 Thread Trent Piepho
On Fri, 2018-12-21 at 04:33 +, Richard Zhu wrote:
> The MSI Enable bit in the MSI Capability (PCIe r4.0, sec 7.7.1.2)
> controls whether a Function can request service using MSI.
> 
> i.MX6 Root Ports implement the MSI Capability and may use MSI to
> request service for events like PME, hotplug, AER, etc.  In
> addition, on i.MX6, the MSI Enable bit controls delivery of MSI
> interrupts from components below the Root Port.
> 
> Prior to commit f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig
> selection
> of CONFIG_PCIEPORTBUS"), enabling CONFIG_PCI_IMX6 automatically also
> enabled CONFIG_PCIEPORTBUS, and when portdrv claimed the Root Ports,
> it set the MSI Enable bit so it could use PME, hotplug, AER, etc.
> As a side effect, that also enabled delivery of MSI interrupts from
> downstream components.
> 
> After f3fdfc4ac3a2, the imx6q-pcie driver can operate without
> portdrv, but that means imx6q-pcie must set the MSI Enable bit
> itself if downstream components use MSI.
> 
> Fixes: f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of
> CONFIG_PCIEPORTBUS")
> 
> Signed-off-by: Richard Zhu 
> Reviewed-by: Lucas Stach 
> Tested-by: Sven Van Asbroeck 
> Acked-by: Lorenzo Pieralisi 

Tested on IMX7d, allows MSI to work without enabling PCIEPORTBUS, which
fails without this patch.


Re: [PATCH 1/5] perf session: Get rid of file_size variable

2018-12-26 Thread Arnaldo Carvalho de Melo
Em Wed, Dec 26, 2018 at 02:51:28PM +0100, Jiri Olsa escreveu:
> It's not needed and removing it makes the code little
> more simple for upcoming changes.
> 
> It's safe to replace file_size with data_size, because
> perf_data__size value is never smaller than data_offset
> + data_size.

This is not applying to my perf/core branch, can you check?

- Arnaldo
 
> Link: http://lkml.kernel.org/n/tip-ocz7zwwkkx11v0mkxrtcd...@git.kernel.org
> Signed-off-by: Jiri Olsa 
> ---
>  tools/perf/util/session.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> index 3972f081a8f4..d6c1d3853f27 100644
> --- a/tools/perf/util/session.c
> +++ b/tools/perf/util/session.c
> @@ -1818,7 +1818,6 @@ static int __perf_session__process_events(struct 
> perf_session *session)
>   struct ordered_events *oe = >ordered_events;
>   struct perf_tool *tool = session->tool;
>   int fd = perf_data__fd(session->data);
> - u64 file_size = perf_data__size(session->data);
>   u64 data_offset = session->header.data_offset;
>   u64 data_size = session->header.data_size;
>   u64 head, page_offset, file_offset, file_pos, size;
> @@ -1838,14 +1837,13 @@ static int __perf_session__process_events(struct 
> perf_session *session)
>   if (data_size == 0)
>   goto out;
>  
> - if (data_offset + data_size < file_size)
> - file_size = data_offset + data_size;
> + ui_progress__init_size(, data_size, "Processing events...");
>  
> - ui_progress__init_size(, file_size, "Processing events...");
> + data_size += data_offset;
>  
>   mmap_size = MMAP_SIZE;
> - if (mmap_size > file_size) {
> - mmap_size = file_size;
> + if (mmap_size > data_size) {
> + mmap_size = data_size;
>   session->one_mmap = true;
>   }
>  
> @@ -1910,7 +1908,7 @@ static int __perf_session__process_events(struct 
> perf_session *session)
>   if (session_done())
>   goto out;
>  
> - if (file_pos < file_size)
> + if (file_pos < data_size)
>   goto more;
>  
>  out:
> -- 
> 2.17.2

-- 

- Arnaldo


[PATCH] mm: compaction.c: Propagate return value upstream

2018-12-26 Thread Aditya Pakki
In sysctl_extfrag_handler(), proc_dointvec_minmax() can return an
error. The fix propagates the error upstream in case of failure.

Signed-off-by: Aditya Pakki 
---
 mm/compaction.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 7c607479de4a..d108974d0867 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1879,9 +1879,7 @@ int sysctl_compaction_handler(struct ctl_table *table, 
int write,
 int sysctl_extfrag_handler(struct ctl_table *table, int write,
void __user *buffer, size_t *length, loff_t *ppos)
 {
-   proc_dointvec_minmax(table, write, buffer, length, ppos);
-
-   return 0;
+   return proc_dointvec_minmax(table, write, buffer, length, ppos);
 }
 
 #if defined(CONFIG_SYSFS) && defined(CONFIG_NUMA)
-- 
2.17.1



Re: [PATCH] net: dsa: bcm_sf2: Propagate error value from mdio_write

2018-12-26 Thread Heiner Kallweit
On 26.12.2018 20:32, Kangjie Lu wrote:
> 
> 
> On Wed, Dec 26, 2018 at 1:13 PM Heiner Kallweit  > wrote:
> 
> On 26.12.2018 19:21, Kangjie Lu wrote:
> > Both bcm_sf2_sw_indir_rw and mdiobus_write_nested could fail, so let's
> > return their error codes upstream.
> >
> > Signed-off-by: Kangjie Lu mailto:k...@umn.edu>>
> > ---
> >  drivers/net/dsa/bcm_sf2.c | 7 +++
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
> > index 2eb68769562c..236815700fba 100644
> > --- a/drivers/net/dsa/bcm_sf2.c
> > +++ b/drivers/net/dsa/bcm_sf2.c
> > @@ -303,11 +303,10 @@ static int bcm_sf2_sw_mdio_write(struct mii_bus 
> *bus, int addr, int regnum,
> >        * send them to our master MDIO bus controller
> >        */
> >       if (addr == BRCM_PSEUDO_PHY_ADDR && priv->indir_phy_mask & 
> BIT(addr))
> > -             bcm_sf2_sw_indir_rw(priv, 0, addr, regnum, val);
> > +             return bcm_sf2_sw_indir_rw(priv, 0, addr, regnum, val);
> This is wrong. Please get familiar with what the function does.
> And test changes before submitting them!
> 
>  
> bcm_sf2_sw_indir_rw() doesn't return an error code, so we don't propagate its 
> return value but return 0 after it.
> 
> For mdiobus_write_nested(), since it does return an error code, we propagate 
> its error code upstream. 
> 
> Does this sound right to you?
>  
Better. You should test a change before submitting (and better not only 
compile-test).
And please no HTML mails. Get familiar with the basics of kernel development
before submitting. Read document "SubmittingPatches" and the following for 
netdev:
https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.txt
By the way: net-next is closed currently.

> 
> 
> >       else
> > -             mdiobus_write_nested(priv->master_mii_bus, addr, regnum, 
> val);
> > -
> > -     return 0;
> > +             return mdiobus_write_nested(priv->master_mii_bus,
> > +                             addr, regnum, val);
> >  }
> > 
> >  static irqreturn_t bcm_sf2_switch_0_isr(int irq, void *dev_id)
> >
> 
> 
> 
> -- 
> Kangjie Lu
> Assistant Professor
> Department of Computer Science and Engineering
> University of Minnesota
> Personal homepage 



Re: [PATCH v1] cpufreq: qcom: Read voltage LUT and populate OPP

2018-12-26 Thread Matthias Kaehlcke
Hi Taniya,

On Mon, Dec 24, 2018 at 12:29:18AM +0530, Taniya Das wrote:
> Hello Matthias,
> 
> Thanks for your review comments.
> 
> On 12/22/2018 2:27 AM, Matthias Kaehlcke wrote:
> > Hi Taniya,
> > 
> > On Fri, Dec 21, 2018 at 11:36:48PM +0530, Taniya Das wrote:
> > > Add support to read the voltage look up table and populate OPP for all
> > > corresponding CPUS.
> > > 
> > > Signed-off-by: Taniya Das 
> > > ---
> > >   drivers/cpufreq/qcom-cpufreq-hw.c | 32 ++--
> > >   1 file changed, 30 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c 
> > > b/drivers/cpufreq/qcom-cpufreq-hw.c
> > > index d83939a..7559b87 100644
> > > --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> > > +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> > > @@ -10,18 +10,21 @@
> > >   #include 
> > >   #include 
> > >   #include 
> > > +#include 
> > >   #include 
> > > 
> > >   #define LUT_MAX_ENTRIES 40U
> > >   #define LUT_SRC GENMASK(31, 30)
> > >   #define LUT_L_VAL   GENMASK(7, 0)
> > >   #define LUT_CORE_COUNT  GENMASK(18, 16)
> > > +#define LUT_VOLT GENMASK(11, 0)
> > >   #define LUT_ROW_SIZE32
> > >   #define CLK_HW_DIV  2
> > > 
> > >   /* Register offsets */
> > >   #define REG_ENABLE  0x0
> > > -#define REG_LUT_TABLE0x110
> > > +#define REG_FREQ_LUT_TABLE   0x110
> > > +#define REG_VOLT_LUT_TABLE   0x114
> > 
> > The new names suggest that there is a LUT for frequencies and another
> > one for voltages. I don't have access to hardware documentation, but
> > from the code and offsets in this driver it seems there is a single
> > table at offset 0x110, with a 'row' of 32 bytes per OPP. Within this
> > row the frequency (and other values) is located at offset 0, the
> > voltage at offset 4.
> > 
> > I'd suggest to keep REG_LUT_TABLE, add a define LUT_OFFSET_VOLTAGE/MV
> > (or similar) and adjust the math in qcom_cpufreq_hw_read_lut() to use
 > > REG_LUT_TABLE as base offset.
> > 
> 
> These names are as per HW documentation and the math is kept as per the
> documentation for reading the voltage.

The HW documentation is confusing then and I'm not convinced this
should be carried over 1:1 to the driver. In any case this
documentation is only available to a reduced audience, why make it
harder for everyone else?

I think something like this would be preferable (removed _TABLE suffix,
since that's already part of LUT):

#define OFFSET_LUT  0x110
#define REG_FREQ_LUT0x00
#define REG_VOLT_LUT0x04

freq = read(OFFSET_LUT + (LUT_ROW_SIZE * i) + REG_FREQ_LUT);
volt = read(OFFSET_LUT + (LUT_ROW_SIZE * i) + REG_VOLT_LUT);

or probably better:

row_addr = OFFSET_LUT + (LUT_ROW_SIZE * i);
freq = read(row_addr + REG_FREQ_LUT);
volt = read(row_addr + REG_VOLT_LUT);

> > >   #define REG_PERF_STATE  0x920
> > > 
> > >   static unsigned long cpu_hw_rate, xo_rate;
> > > @@ -75,19 +78,26 @@ static int qcom_cpufreq_hw_read_lut(struct device 
> > > *dev,
> > >   void __iomem *base)
> > >   {
> > >   u32 data, src, lval, i, core_count, prev_cc = 0, prev_freq = 0, 
> > > freq;
> > > + u32 volt;
> > >   unsigned int max_cores = cpumask_weight(policy->cpus);
> > >   struct cpufreq_frequency_table  *table;
> > > + unsigned long cpu_r;
> > 
> > nit: why 'cpu_r' and not just 'cpu'?
> > 
> > (if it is needed at all, see my comment below)
> > 
> > > 
> > >   table = kcalloc(LUT_MAX_ENTRIES + 1, sizeof(*table), 
> > > GFP_KERNEL);
> > >   if (!table)
> > >   return -ENOMEM;
> > > 
> > >   for (i = 0; i < LUT_MAX_ENTRIES; i++) {
> > > - data = readl_relaxed(base + REG_LUT_TABLE + i * LUT_ROW_SIZE);
> > > + data = readl_relaxed(base + REG_FREQ_LUT_TABLE +
> > > +   i * LUT_ROW_SIZE);
> > >   src = FIELD_GET(LUT_SRC, data);
> > >   lval = FIELD_GET(LUT_L_VAL, data);
> > >   core_count = FIELD_GET(LUT_CORE_COUNT, data);
> > > 
> > > + data = readl_relaxed(base + REG_VOLT_LUT_TABLE +
> > > +   i * LUT_ROW_SIZE);
> > > + volt = FIELD_GET(LUT_VOLT, data) * 1000;
> > > +
> > >   if (src)
> > >   freq = xo_rate * lval / 1000;
> > >   else
> > > @@ -123,6 +133,10 @@ static int qcom_cpufreq_hw_read_lut(struct device 
> > > *dev,
> > > 
> > >   prev_cc = core_count;
> > >   prev_freq = freq;
> > > +
> > > + freq *= 1000;
> > > + for_each_cpu(cpu_r, policy->cpus)
> > > + dev_pm_opp_add(get_cpu_device(cpu_r), freq, volt);
> > 
> > Are you sure we want to duplicate the OPP entries for all CPUs in the
> > cluster? IIUC the 

CPUs blocking in update_blocked_averages -- 4.19.12

2018-12-26 Thread Sargun Dhillon
We're seeing an issue introduced in 4.18, and that still persists in
4.19.12 (we upgraded from 4.9), where update_blocked_averages is
blocking. We're running a workload where a majority of our workloads
are  confined by cgroups. This exhibits itself due to a softlockup on
a CPU which is waiting on a lock that's held by
update_blocked_averages. I don't have access to any bare metal
hardware at the moment, and these are all systems running under KVM.
This kernel has CONFIG_FAIR_GROUP_SCHED on.

The Softlocked CPU:
crash> bt
PID: 29314  TASK: 99b5f0671f00  CPU: 0   COMMAND: "ag"
 #0 [99b67b203d58] machine_kexec at 91a602f3
 #1 [99b67b203db0] __crash_kexec at 91b49011
 #2 [99b67b203e70] panic at 91a896d1
 #3 [99b67b203ef8] watchdog_timer_fn at 91b816af
 #4 [99b67b203f28] __hrtimer_run_queues at 91b26359
 #5 [99b67b203f88] hrtimer_interrupt at 91b26de2
 #6 [99b67b203fd8] smp_apic_timer_interrupt at 92402b06
 #7 [99b67b203ff0] apic_timer_interrupt at 92401a9f
---  ---
 #8 [a49fa1acbc08] apic_timer_interrupt at 92401a9f
[exception RIP: smp_call_function_many+543]
RIP: 91b3e84f  RSP: a49fa1acbcb0  RFLAGS: 0202
RAX: 0010  RBX: 99b67b224fc0  RCX: 99b67b6286a0
RDX: 0001  RSI: 0200  RDI: 99b67b224fc8
RBP: 99b67b224fc8   R8: 0001   R9: 
R10:   R11:   R12: 00025080
R13: a49fa1acbd00  R14: 0001  R15: 0200
ORIG_RAX: ff13  CS: 0010  SS: 0018
 #9 [a49fa1acbcf8] flush_tlb_mm_range at 91a7853c
#10 [a49fa1acbd90] free_pgtables at 91c4ac3b
#11 [a49fa1acbdc8] unmap_region at 91c54439
#12 [a49fa1acbe90] do_munmap at 91c56355
#13 [a49fa1acbee0] vm_munmap at 91c56587
#14 [a49fa1acbf20] __x64_sys_munmap at 91c565e2
#15 [a49fa1acbf38] do_syscall_64 at 91a04590
#16 [a49fa1acbf50] entry_SYSCALL_64_after_hwframe at 9240008d
RIP: 7f43e94de747  RSP: 7f43e91d7e28  RFLAGS: 0213
RAX: ffda  RBX: 011a6f30  RCX: 7f43e94de747
RDX: 0001  RSI: 0ade  RDI: 7f43ea47d000
RBP: 0005   R8: 7f43e8c0   R9: 7f43e91d7d00
R10: 011a53b0  R11: 0213  R12: 7f43ea47d000
R13: 0ade  R14: 7f43e91d89c0  R15: 0060
ORIG_RAX: 000b  CS: 0033  SS: 002b

This is waiting on CPU 16:
crash> bt
PID: 29299  TASK: 99b5dffd1f00  CPU: 16  COMMAND: "ag"
 #0 [fe2c8e38] crash_nmi_callback at 91a54202
 #1 [fe2c8e50] nmi_handle at 91a32ee2
 #2 [fe2c8ea0] default_do_nmi at 91a333ea
 #3 [fe2c8ec0] do_nmi at 91a33553
 #4 [fe2c8ef0] end_repeat_nmi at 924014e8
[exception RIP: native_queued_spin_lock_slowpath+33]
RIP: 91af2dc1  RSP: a49fa1a93948  RFLAGS: 0002
RAX: 0001  RBX: 99b67b763f40  RCX: 4f19a57a
RDX: 0001  RSI: 0001  RDI: 99b67b763f40
RBP: 0082   R8: 0001   R9: 
R10: a49fa1a938f8  R11: 91aca4a7  R12: 0015
R13: 99b67b764940  R14: a49fa1a93a60  R15: 0015
ORIG_RAX:   CS: 0010  SS: 
---  ---
 #5 [a49fa1a93948] native_queued_spin_lock_slowpath at 91af2dc1
 #6 [a49fa1a93948] do_raw_spin_lock at 91af48dd
 #7 [a49fa1a93958] _raw_spin_lock_irqsave at 923c1154
 #8 [a49fa1a93978] update_blocked_averages at 91aca4a7
 #9 [a49fa1a93a10] update_nohz_stats at 91acaa3d
#10 [a49fa1a93a20] find_busiest_group at 91ad2137
#11 [a49fa1a93bb8] load_balance at 91ad2be0
#12 [a49fa1a93cf0] pick_next_task_fair at 91ad41e6
#13 [a49fa1a93da0] mark_held_locks at 91aeebe4
#14 [a49fa1a93de8] schedule at 923b9ec2
#15 [a49fa1a93df8] rwsem_down_read_failed at 923be859
#16 [a49fa1a93e80] call_rwsem_down_read_failed at 923ae944
#17 [a49fa1a93ec8] down_read at 923bdf0b
#18 [a49fa1a93ee0] __do_page_fault at 91a71083
#19 [a49fa1a93f50] async_page_fault at 924010ee
RIP: 7f43e945f786  RSP: 7ffde2b50070  RFLAGS: 00010206
RAX: 00015f41  RBX: 7f43e97a1b20  RCX: 0111
RDX: 011affb0  RSI: 011b00c0  RDI: 
RBP: 0111   R8: 7f43e97a1bd8   R9: 
R10: 7f43e97a1b78  R11: 7f43e97a1b78  R12: 7f43e97a1b78
R13: 7f43e97a1b78  R14: 2710  R15: 7f43e97a1c78
ORIG_RAX:   CS: 0033  SS: 002b

Which is waiting on a lock held by CPU owned by 

[PATCH] iio: chemical: sps30: allow changing self cleaning period

2018-12-26 Thread Tomasz Duszynski
Sensor can periodically trigger self cleaning. Period can be changed by
writing a new value to a dedicated attribute. Upon attribute read
triplet representing respectively current, minimum and maximum period is
returned.

Signed-off-by: Tomasz Duszynski 
---
 Documentation/ABI/testing/sysfs-bus-iio-sps30 |  11 ++
 drivers/iio/chemical/sps30.c  | 134 +++---
 2 files changed, 127 insertions(+), 18 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-sps30 
b/Documentation/ABI/testing/sysfs-bus-iio-sps30
index e7ce2c57635e..d83d9192a3e0 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-sps30
+++ b/Documentation/ABI/testing/sysfs-bus-iio-sps30
@@ -6,3 +6,14 @@ Description:
Writing 1 starts sensor self cleaning. Internal fan accelerates
to its maximum speed and keeps spinning for about 10 seconds in
order to blow out accumulated dust.
+
+What:  /sys/bus/iio/devices/iio:deviceX/cleaning_interval
+Date:  December 2018
+KernelVersion: 4.22
+Contact:   linux-...@vger.kernel.org
+Description:
+   Sensor is capable of triggering self cleaning periodically.
+   Period can be changed by writing a new value here. Upon reading
+   three values are returned representing respectively current,
+   minimum and maximum period. All values are in seconds.
+   Writing 0 here disables periodical self cleaning entirely.
diff --git a/drivers/iio/chemical/sps30.c b/drivers/iio/chemical/sps30.c
index f3b4390c8f5c..c219fda08cba 100644
--- a/drivers/iio/chemical/sps30.c
+++ b/drivers/iio/chemical/sps30.c
@@ -5,9 +5,6 @@
  * Copyright (c) Tomasz Duszynski 
  *
  * I2C slave address: 0x69
- *
- * TODO:
- *  - support for reading/setting auto cleaning interval
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -21,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define SPS30_CRC8_POLYNOMIAL 0x31
@@ -28,6 +26,9 @@
 #define SPS30_MAX_READ_SIZE 48
 /* sensor measures reliably up to 3000 ug / m3 */
 #define SPS30_MAX_PM 3000
+/* minimum and maximum self cleaning intervals in seconds */
+#define SPS30_AUTO_CLEANING_INTERVAL_MIN 0
+#define SPS30_AUTO_CLEANING_INTERVAL_MAX 604800
 
 /* SPS30 commands */
 #define SPS30_START_MEAS 0x0010
@@ -37,6 +38,9 @@
 #define SPS30_READ_DATA 0x0300
 #define SPS30_READ_SERIAL 0xd033
 #define SPS30_START_FAN_CLEANING 0x5607
+#define SPS30_AUTO_CLEANING_INTERVAL 0x8004
+/* not a sensor command per se, used only to distinguish write from read */
+#define SPS30_READ_AUTO_CLEANING_INTERVAL 0x8005
 
 enum {
PM1,
@@ -45,6 +49,11 @@ enum {
PM10,
 };
 
+enum {
+   RESET,
+   MEASURING,
+};
+
 struct sps30_state {
struct i2c_client *client;
/*
@@ -52,6 +61,7 @@ struct sps30_state {
 * Must be held whenever sequence of commands is to be executed.
 */
struct mutex lock;
+   int state;
 };
 
 DECLARE_CRC8_TABLE(sps30_crc8_table);
@@ -107,6 +117,9 @@ static int sps30_do_cmd(struct sps30_state *state, u16 cmd, 
u8 *data, int size)
case SPS30_START_FAN_CLEANING:
ret = sps30_write_then_read(state, buf, 2, NULL, 0);
break;
+   case SPS30_READ_AUTO_CLEANING_INTERVAL:
+   buf[0] = SPS30_AUTO_CLEANING_INTERVAL >> 8;
+   buf[1] = (u8)SPS30_AUTO_CLEANING_INTERVAL;
case SPS30_READ_DATA_READY_FLAG:
case SPS30_READ_DATA:
case SPS30_READ_SERIAL:
@@ -114,6 +127,15 @@ static int sps30_do_cmd(struct sps30_state *state, u16 
cmd, u8 *data, int size)
size += size / 2;
ret = sps30_write_then_read(state, buf, 2, buf, size);
break;
+   case SPS30_AUTO_CLEANING_INTERVAL:
+   buf[2] = data[0];
+   buf[3] = data[1];
+   buf[4] = crc8(sps30_crc8_table, [2], 2, CRC8_INIT_VALUE);
+   buf[5] = data[2];
+   buf[6] = data[3];
+   buf[7] = crc8(sps30_crc8_table, [5], 2, CRC8_INIT_VALUE);
+   ret = sps30_write_then_read(state, buf, 8, NULL, 0);
+   break;
}
 
if (ret)
@@ -170,6 +192,14 @@ static int sps30_do_meas(struct sps30_state *state, s32 
*data, int size)
int i, ret, tries = 5;
u8 tmp[16];
 
+   if (state->state == RESET) {
+   ret = sps30_do_cmd(state, SPS30_START_MEAS, NULL, 0);
+   if (ret)
+   return ret;
+
+   state->state = MEASURING;
+   }
+
while (tries--) {
ret = sps30_do_cmd(state, SPS30_READ_DATA_READY_FLAG, tmp, 2);
if (ret)
@@ -276,6 +306,24 @@ static int sps30_read_raw(struct iio_dev *indio_dev,
return -EINVAL;
 }
 
+static int sps30_do_cmd_reset(struct sps30_state *state)
+{
+   int ret;
+
+   ret = sps30_do_cmd(state, SPS30_RESET, NULL, 0);
+   msleep(300);
+   /*
+* 

Re: [GIT PULL] asm-generic: syscall table script for arch/sh

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Fri, 21 Dec 2018 00:28:51 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git 
> tags/asm-generic-4.21

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/507413a5f88a2240b2c19cb4318166614e2349d9

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] arch/microblaze patches for 5.0-rc1

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Fri, 21 Dec 2018 11:13:09 +0100:

> git://git.monstr.eu/linux-2.6-microblaze.git tags/microblaze-v5.0-rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/30807ef2b76e01ea209fcad66a87e534ed1edb40

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT] Sparc

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Sat, 22 Dec 2018 15:46:26 -0800 (PST):

> git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next.git master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [git pull] m68k updates for 4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Thu, 20 Dec 2018 16:17:36 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git 
> tags/m68k-for-v4.21-tag1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e0783bb42448a4f2a6bd405c890010a3950feada

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] parisc architecture updates for kernel v4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Wed, 26 Dec 2018 17:49:42 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git 
> parisc-4.21-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a5f2bd479f58f171a16a9a4f3b4e748ab3057c0f

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] Main MIPS pull for 4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Sun, 23 Dec 2018 16:24:37 +:

> git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git tags/mips_4.21

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/89261c57021352045c4af24522c6854c9ee90139

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [PATCH] net: dsa: bcm_sf2: Propagate error value from mdio_write

2018-12-26 Thread Heiner Kallweit
On 26.12.2018 19:21, Kangjie Lu wrote:
> Both bcm_sf2_sw_indir_rw and mdiobus_write_nested could fail, so let's
> return their error codes upstream.
> 
> Signed-off-by: Kangjie Lu 
> ---
>  drivers/net/dsa/bcm_sf2.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
> index 2eb68769562c..236815700fba 100644
> --- a/drivers/net/dsa/bcm_sf2.c
> +++ b/drivers/net/dsa/bcm_sf2.c
> @@ -303,11 +303,10 @@ static int bcm_sf2_sw_mdio_write(struct mii_bus *bus, 
> int addr, int regnum,
>* send them to our master MDIO bus controller
>*/
>   if (addr == BRCM_PSEUDO_PHY_ADDR && priv->indir_phy_mask & BIT(addr))
> - bcm_sf2_sw_indir_rw(priv, 0, addr, regnum, val);
> + return bcm_sf2_sw_indir_rw(priv, 0, addr, regnum, val);
This is wrong. Please get familiar with what the function does.
And test changes before submitting them!

>   else
> - mdiobus_write_nested(priv->master_mii_bus, addr, regnum, val);
> -
> - return 0;
> + return mdiobus_write_nested(priv->master_mii_bus,
> + addr, regnum, val);
>  }
>  
>  static irqreturn_t bcm_sf2_switch_0_isr(int irq, void *dev_id)
> 



Re: [PATCH] mm: compaction.c: Propagate return value upstream

2018-12-26 Thread Matthew Wilcox
On Wed, Dec 26, 2018 at 01:07:49PM -0600, Aditya Pakki wrote:
>  {
> + return
>   proc_dointvec_minmax(table, write, buffer, length, ppos);
> -
> - return 0;

Don't do this.  If you're going to return something, it should be on the same
line as the return statement.

ie:

+   return proc_dointvec_minmax(table, write, buffer, length, ppos);



[PATCH] mm: compaction.c: Propagate return value upstream

2018-12-26 Thread Aditya Pakki
In sysctl_extfrag_handler(), proc_dointvec_minmax() can return an
error. The fix propagates the error upstream in case of failure.

Signed-off-by: Aditya Pakki 
---
 mm/compaction.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 7c607479de4a..5703b4051796 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1879,9 +1879,8 @@ int sysctl_compaction_handler(struct ctl_table *table, 
int write,
 int sysctl_extfrag_handler(struct ctl_table *table, int write,
void __user *buffer, size_t *length, loff_t *ppos)
 {
+   return
proc_dointvec_minmax(table, write, buffer, length, ppos);
-
-   return 0;
 }
 
 #if defined(CONFIG_SYSFS) && defined(CONFIG_NUMA)
-- 
2.17.1



Re: [PATCH v4 2/2] dt-bindings: spi: Document Renesas R-Car Gen3 RPC controller bindings

2018-12-26 Thread Marek Vasut
On 12/24/18 7:52 AM, Mason Yang wrote:
> Document the bindings used by the Renesas R-Car Gen3 RPC controller.
> 
> Signed-off-by: Mason Yang 
> ---
>  .../devicetree/bindings/spi/spi-renesas-rpc.txt| 37 
> ++
>  1 file changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
> 
> diff --git a/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt 
> b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
> new file mode 100644
> index 000..ba863d7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
> @@ -0,0 +1,37 @@
> +Renesas R-Car Gen3 RPC controller Device Tree Bindings
> +--
> +
> +Required properties:
> +- compatible: should be "renesas,r8a77995-rpc"
> +- #address-cells: should be 1
> +- #size-cells: should be 0
> +- reg: should contain 2 entries, one for the registers and one for the direct
> +   mapping area
> +- reg-names: should contain "regs" and "dirmap"
> +- clock-names: should contain "rpc"
> +- clocks: should contain 1 entries for the module's clock
> +- renesas,rpc-mode: should contain "spi" for rpc spi mode or
> +"hyperflash" for rpc hyerflash mode.

We do not need special property to identify that the controller is in HF
mode, just attach CFI NOR node or JEDEC SPI NOR underneath it.

-- 
Best regards,
Marek Vasut


Re: [PATCH v4 0/2] spi: Add Renesas R-Car Gen3 RPC SPI driver

2018-12-26 Thread Marek Vasut
On 12/24/18 7:52 AM, Mason Yang wrote:
> Hi Mark,
> 
> This Renesas R-Car Gen3 RPC SPI driver is based on Boris's new
> spi-mem direct mapping read/write mode [1][2].

Again, the RPC is NOT a SPI controller, it is dual SPI/HF controller.

[...]

-- 
Best regards,
Marek Vasut


Re: [PATCH] net: arcnet: Fix a possible concurrency use-after-free bug in arcnet_reply_tasklet()

2018-12-26 Thread kbuild test robot
Hi Jia-Ju,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on net-next/master]
[also build test ERROR on v4.20 next-20181224]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jia-Ju-Bai/net-arcnet-Fix-a-possible-concurrency-use-after-free-bug-in-arcnet_reply_tasklet/20181227-020417
config: x86_64-randconfig-x005-201851 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:9,
from include/linux/module.h:9,
from drivers/net/arcnet/arcnet.c:46:
   drivers/net/arcnet/arcnet.c: In function 'arcnet_reply_tasklet':
>> drivers/net/arcnet/arcnet.c:429:31: error: 'flags' undeclared (first use in 
>> this function); did you mean 'class'?
 spin_lock_irqsave(>lock, flags);
  ^
   include/linux/typecheck.h:11:9: note: in definition of macro 'typecheck'
 typeof(x) __dummy2; \
^
>> include/linux/spinlock.h:359:2: note: in expansion of macro 
>> 'raw_spin_lock_irqsave'
 raw_spin_lock_irqsave(spinlock_check(lock), flags); \
 ^
>> drivers/net/arcnet/arcnet.c:429:2: note: in expansion of macro 
>> 'spin_lock_irqsave'
 spin_lock_irqsave(>lock, flags);
 ^
   drivers/net/arcnet/arcnet.c:429:31: note: each undeclared identifier is 
reported only once for each function it appears in
 spin_lock_irqsave(>lock, flags);
  ^
   include/linux/typecheck.h:11:9: note: in definition of macro 'typecheck'
 typeof(x) __dummy2; \
^
>> include/linux/spinlock.h:359:2: note: in expansion of macro 
>> 'raw_spin_lock_irqsave'
 raw_spin_lock_irqsave(spinlock_check(lock), flags); \
 ^
>> drivers/net/arcnet/arcnet.c:429:2: note: in expansion of macro 
>> 'spin_lock_irqsave'
 spin_lock_irqsave(>lock, flags);
 ^
>> include/linux/typecheck.h:12:18: warning: comparison of distinct pointer 
>> types lacks a cast
 (void)(&__dummy == &__dummy2); \
 ^
>> include/linux/spinlock.h:240:3: note: in expansion of macro 'typecheck'
  typecheck(unsigned long, flags); \
  ^
>> include/linux/spinlock.h:359:2: note: in expansion of macro 
>> 'raw_spin_lock_irqsave'
 raw_spin_lock_irqsave(spinlock_check(lock), flags); \
 ^
>> drivers/net/arcnet/arcnet.c:429:2: note: in expansion of macro 
>> 'spin_lock_irqsave'
 spin_lock_irqsave(>lock, flags);
 ^
--
   In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:9,
from include/linux/module.h:9,
from drivers/net//arcnet/arcnet.c:46:
   drivers/net//arcnet/arcnet.c: In function 'arcnet_reply_tasklet':
   drivers/net//arcnet/arcnet.c:429:31: error: 'flags' undeclared (first use in 
this function); did you mean 'class'?
 spin_lock_irqsave(>lock, flags);
  ^
   include/linux/typecheck.h:11:9: note: in definition of macro 'typecheck'
 typeof(x) __dummy2; \
^
>> include/linux/spinlock.h:359:2: note: in expansion of macro 
>> 'raw_spin_lock_irqsave'
 raw_spin_lock_irqsave(spinlock_check(lock), flags); \
 ^
   drivers/net//arcnet/arcnet.c:429:2: note: in expansion of macro 
'spin_lock_irqsave'
 spin_lock_irqsave(>lock, flags);
 ^
   drivers/net//arcnet/arcnet.c:429:31: note: each undeclared identifier is 
reported only once for each function it appears in
 spin_lock_irqsave(>lock, flags);
  ^
   include/linux/typecheck.h:11:9: note: in definition of macro 'typecheck'
 typeof(x) __dummy2; \
^
>> include/linux/spinlock.h:359:2: note: in expansion of macro 
>> 'raw_spin_lock_irqsave'
 raw_spin_lock_irqsave(spinlock_check(lock), flags); \
 ^
   drivers/net//arcnet/arcnet.c:429:2: note: in expansion of macro 
'spin_lock_irqsave'
 spin_lock_irqsave(>lock, flags);
 ^
>> include/linux/typecheck.h:12:18: warning: comparison of distinct pointer 
>> types lacks a cast
 (void)(&__dummy == &__dummy2); \
 ^
>> include/linux/spinlock.h:240:3: note: in expansion of macro 'typecheck'
  typecheck(unsigned long, flags); \
  ^
>> include/linux/spinlock.h:359:2: note: in expansion of macro 
>> 'raw_spin_lock_irqsave'
 raw_spin_lock_irqsave(spinlock_check(lock), flags); \
 ^
   drivers/net//arcnet/arcnet.c:429:2: note: in expansion of macro 
'spin_lock_irqsave'
 spin_lock_irqsave(>lock, flags);
 

[GIT PULL] Modules updates for v4.21

2018-12-26 Thread Jessica Yu

Linus,

Please pull below to receive modules updates for the 4.21 merge window.
Details can be found in the signed tag.

Thanks,

Jessica

---

The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:

 Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)

are available in the Git repository at:

 ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git 
tags/modules-for-v4.21

for you to fetch changes up to 93d77e7f1410c366050d6035dcba1a5167c7cf0b:

 ARM: module: Fix function kallsyms on Thumb-2 (2018-12-14 20:27:29 +0100)


Modules updates for v4.21

Summary of modules changes for the 4.21 merge window:

- Some modules-related kallsyms cleanups and a kallsyms fix for ARM.

- Include keys from the secondary keyring in module signature
 verification.

Signed-off-by: Jessica Yu 


Jessica Yu (1):
 module: make it clearer when we're handling kallsyms symbols vs exported 
symbols

Ke Wu (1):
 modsign: use all trusted keys to verify module signature

Vincent Whitchurch (2):
 module: Overwrite st_size instead of st_info
 ARM: module: Fix function kallsyms on Thumb-2

arch/arm/include/asm/module.h |  11 
include/linux/module.h|   7 +++
kernel/module.c   | 123 --
kernel/module_signing.c   |   3 +-
4 files changed, 92 insertions(+), 52 deletions(-)



[PATCH] infiniband: bnxt_re: qplib: Check the return value of send_message

2018-12-26 Thread Aditya Pakki
In bnxt_qplib_map_tc2cos(), bnxt_qplib_rcfw_send_message() can return
an error value. The fix returns the error from the latter function
upstream.

Signed-off-by: Aditya Pakki 
---
 drivers/infiniband/hw/bnxt_re/qplib_sp.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/hw/bnxt_re/qplib_sp.c 
b/drivers/infiniband/hw/bnxt_re/qplib_sp.c
index 5216b5f844cc..adb8eae5193c 100644
--- a/drivers/infiniband/hw/bnxt_re/qplib_sp.c
+++ b/drivers/infiniband/hw/bnxt_re/qplib_sp.c
@@ -778,9 +778,8 @@ int bnxt_qplib_map_tc2cos(struct bnxt_qplib_res *res, u16 
*cids)
req.cos0 = cpu_to_le16(cids[0]);
req.cos1 = cpu_to_le16(cids[1]);
 
-   bnxt_qplib_rcfw_send_message(rcfw, (void *), (void *), NULL,
-0);
-   return 0;
+   return bnxt_qplib_rcfw_send_message(rcfw, (void *), (void *),
+   NULL, 0);
 }
 
 int bnxt_qplib_get_roce_stats(struct bnxt_qplib_rcfw *rcfw,
-- 
2.17.1



RE:

2018-12-26 Thread Alice Walton
I have a charity mission worth $ 100,000,000.00 from you


[PATCH v2] usb: chipidea: add a check for the availability of next child

2018-12-26 Thread Kangjie Lu
of_get_next_available_child returns NULL when no child nodes are found.
The fix checks its return value instead of assuming a child is found.

Signed-off-by: Kangjie Lu 
---
 drivers/usb/chipidea/ci_hdrc_msm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
b/drivers/usb/chipidea/ci_hdrc_msm.c
index 880009987460..b7f7acef72d4 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -250,6 +250,10 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
ulpi_node = of_get_child_by_name(pdev->dev.of_node, "ulpi");
if (ulpi_node) {
phy_node = of_get_next_available_child(ulpi_node, NULL);
+   if (!phy_node) {
+   dev_err(>dev, "no child nodes found\n");
+   return -ENODEV;
+   }
ci->hsic = of_device_is_compatible(phy_node, 
"qcom,usb-hsic-phy");
of_node_put(phy_node);
}
-- 
2.17.2 (Apple Git-113)



[PATCH] net: dsa: bcm_sf2: Propagate error value from mdio_write

2018-12-26 Thread Kangjie Lu
Both bcm_sf2_sw_indir_rw and mdiobus_write_nested could fail, so let's
return their error codes upstream.

Signed-off-by: Kangjie Lu 
---
 drivers/net/dsa/bcm_sf2.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 2eb68769562c..236815700fba 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -303,11 +303,10 @@ static int bcm_sf2_sw_mdio_write(struct mii_bus *bus, int 
addr, int regnum,
 * send them to our master MDIO bus controller
 */
if (addr == BRCM_PSEUDO_PHY_ADDR && priv->indir_phy_mask & BIT(addr))
-   bcm_sf2_sw_indir_rw(priv, 0, addr, regnum, val);
+   return bcm_sf2_sw_indir_rw(priv, 0, addr, regnum, val);
else
-   mdiobus_write_nested(priv->master_mii_bus, addr, regnum, val);
-
-   return 0;
+   return mdiobus_write_nested(priv->master_mii_bus,
+   addr, regnum, val);
 }
 
 static irqreturn_t bcm_sf2_switch_0_isr(int irq, void *dev_id)
-- 
2.17.2 (Apple Git-113)



Re: [PATCH] net: phy: phy: check return value of bus write

2018-12-26 Thread Heiner Kallweit
On 26.12.2018 19:04, Aditya Pakki wrote:
> phy_mii_ioctl() could fail when writing to the bus via
> mdiobus_write(). The fix adds a check and returns an error in case
> of failure.
> 
> Signed-off-by: Aditya Pakki 
> ---
>  drivers/net/phy/phy.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
This file belongs to phylib, not to a specific driver.
"net: phy: phy:" in the subject doesn't make sense, it should be
just "net: phy:". You can see this in the history of the file.

And as commented on another patch of yours:
net-next is closed currently.

Your efforts are appreciated, however you should start with
reading the following:
https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.txt

Heiner


[PATCH] hmm: Warn on devres_release failure

2018-12-26 Thread Aditya Pakki
devres_release can return -ENOENT if the device is not freed. The fix
throws a warning consistent with other invocations.

Signed-off-by: Aditya Pakki 
---
 mm/hmm.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/mm/hmm.c b/mm/hmm.c
index 90c34f3d1243..b06e3f092fbf 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -1183,8 +1183,12 @@ static int hmm_devmem_match(struct device *dev, void 
*data, void *match_data)
 
 static void hmm_devmem_pages_remove(struct hmm_devmem *devmem)
 {
-   devres_release(devmem->device, _devmem_release,
-  _devmem_match, devmem->resource);
+   int rc;
+
+   rc = devres_release(devmem->device, _devmem_release,
+   _devmem_match, devmem->resource);
+   if (rc)
+   WARN_ON(rc);
 }
 
 /*
-- 
2.17.1



Re: [PATCH v2] net: dsa: bcm_sf2: Propagate error value from mdio_write

2018-12-26 Thread Heiner Kallweit
On 26.12.2018 18:50, Kangjie Lu wrote:
> Both bcm_sf2_sw_indir_rw and mdiobus_write_nested could fail, so let's
> return their error codes upstream.
> 
> Signed-off-by: Kangjie Lu 
> ---
>  drivers/net/dsa/bcm_sf2.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
> index 2eb68769562c..73fbc16a1f86 100644
> --- a/drivers/net/dsa/bcm_sf2.c
> +++ b/drivers/net/dsa/bcm_sf2.c
> @@ -305,9 +305,8 @@ static int bcm_sf2_sw_mdio_write(struct mii_bus *bus, int 
> addr, int regnum,
>   if (addr == BRCM_PSEUDO_PHY_ADDR && priv->indir_phy_mask & BIT(addr))
>   bcm_sf2_sw_indir_rw(priv, 0, addr, regnum, val);
>   else
> - mdiobus_write_nested(priv->master_mii_bus, addr, regnum, val);
> -
> - return 0;
> + return mdiobus_write_nested(priv->master_mii_bus,
> + addr, regnum, val);
>  }
Did you try to compile this? The first branch of the if clause has no return
value any longer.


Re: [PATCH] ethernet: (niu) fix missing checks of niu_pci_eeprom_read

2018-12-26 Thread Shannon Nelson
On Mon, Dec 24, 2018 at 11:58 PM Kangjie Lu  wrote:
>
> niu_pci_eeprom_read() may fail, so we should check its return value
> before using the read data.
>
> Signed-off-by: Kangjie Lu 
> ---
>  drivers/net/ethernet/sun/niu.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
> index 9319d84bf49f..d84501441edd 100644
> --- a/drivers/net/ethernet/sun/niu.c
> +++ b/drivers/net/ethernet/sun/niu.c
> @@ -8100,6 +8100,8 @@ static int niu_pci_vpd_scan_props(struct niu *np, u32 
> start, u32 end)
> start += 3;
>
> prop_len = niu_pci_eeprom_read(np, start + 4);
> +   if (prop_len < 0)
> +   return prop_len;
> err = niu_pci_vpd_get_propname(np, start + 5, namebuf, 64);
> if (err < 0)
> return err;
> @@ -8144,8 +8146,12 @@ static int niu_pci_vpd_scan_props(struct niu *np, u32 
> start, u32 end)
> netif_printk(np, probe, KERN_DEBUG, np->dev,
>  "VPD_SCAN: Reading in property [%s] 
> len[%d]\n",
>  namebuf, prop_len);
> -   for (i = 0; i < prop_len; i++)
> -   *prop_buf++ = niu_pci_eeprom_read(np, off + 
> i);
> +   for (i = 0; i < prop_len; i++) {
> +   err = niu_pci_eeprom_read(np, off + i);
> +   if (err >= 0)
> +   *prop_buf = err;
> +   ++prop_buf;
> +   }
> }
>
> start += len;
> --
> 2.17.2 (Apple Git-113)
>

Acked-by: Shannon Nelson 

-- 
==
Mr. Shannon Nelson Parents can't afford to be squeamish.


[PATCH] net: phy: phy: check return value of bus write

2018-12-26 Thread Aditya Pakki
phy_mii_ioctl() could fail when writing to the bus via
mdiobus_write(). The fix adds a check and returns an error in case
of failure.

Signed-off-by: Aditya Pakki 
---
 drivers/net/phy/phy.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 1d73ac3309ce..1fbdaa96b36e 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -397,6 +397,7 @@ int phy_mii_ioctl(struct phy_device *phydev, struct ifreq 
*ifr, int cmd)
struct mii_ioctl_data *mii_data = if_mii(ifr);
u16 val = mii_data->val_in;
bool change_autoneg = false;
+   int rc;
 
switch (cmd) {
case SIOCGMIIPHY:
@@ -443,8 +444,10 @@ int phy_mii_ioctl(struct phy_device *phydev, struct ifreq 
*ifr, int cmd)
}
}
 
-   mdiobus_write(phydev->mdio.bus, mii_data->phy_id,
- mii_data->reg_num, val);
+   rc = mdiobus_write(phydev->mdio.bus, mii_data->phy_id,
+  mii_data->reg_num, val);
+   if (rc)
+   return rc;
 
if (mii_data->phy_id == phydev->mdio.addr &&
mii_data->reg_num == MII_BMCR &&
-- 
2.17.1



Re: [PATCH] sound: atom: fix a missing check of snd_pcm_lib_malloc_pages

2018-12-26 Thread Pierre-Louis Bossart



On 12/25/18 8:29 PM, Kangjie Lu wrote:

snd_pcm_lib_malloc_pages() may fail, so let's check its status and
return its error code upstream.


Acked-by: Pierre-Louis Bossart 




Signed-off-by: Kangjie Lu 
---
  sound/soc/intel/atom/sst-mfld-platform-pcm.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c 
b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
index afc559866095..91a2436ce952 100644
--- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
+++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
@@ -399,7 +399,13 @@ static int sst_media_hw_params(struct snd_pcm_substream 
*substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
  {
-   snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(params));
+   int ret;
+
+   ret =
+   snd_pcm_lib_malloc_pages(substream,
+   params_buffer_bytes(params));
+   if (ret)
+   return ret;
memset(substream->runtime->dma_area, 0, params_buffer_bytes(params));
return 0;
  }


Re: [PATCH 1/2] dt-bindings: Add Qualcomm USB Super-Speed PHY bindings

2018-12-26 Thread Jorge Ramirez

On 12/20/18 21:25, Stephen Boyd wrote:

Quoting Jorge Ramirez-Ortiz (2018-12-07 01:55:57)

+
+- qcom,vdd-voltage-level:
+Value type: 
+Definition: This is a list of three integer values  where
+each value corresponding to voltage corner in uV.


As far as I'm aware, this isn't how qcom's voltage corners are handled
or are going to be handled. Can't you hardcode it in the driver for now?




sure will do.

if there is any other driver in some tree/branch that I could be looking 
as a reference - to avoid having to hardcode the values in the driver- 
please let me know.


Re: [PATCH 2/2] phy: qualcomm: usb: Add Super-Speed PHY driver

2018-12-26 Thread Jorge Ramirez

On 12/20/18 21:29, Stephen Boyd wrote:

Quoting Jorge Ramirez-Ortiz (2018-12-07 01:55:58)

From: Shawn Guo 

Driver to control the Synopsys SS PHY 1.0.0 implemeneted in QCS404

Based on Sriharsha Allenki's  original code.

Signed-off-by: Jorge Ramirez-Ortiz 
Signed-off-by: Shawn Guo 


chain should be swapped?


ok.

Shawn asked me to remove him from the authors list so will remove.




Reviewed-by: Vinod Koul 


will remove the reviewed-by line as well.


---
diff --git a/drivers/phy/qualcomm/phy-qcom-usb-ss.c 
b/drivers/phy/qualcomm/phy-qcom-usb-ss.c
new file mode 100644
index 000..7b6a55e
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-usb-ss.c
+
+struct ssphy_priv {
+   void __iomem *base;
+   struct device *dev;
+   struct reset_control *reset_com;
+   struct reset_control *reset_phy;
+   struct clk *clk_ref;
+   struct clk *clk_phy;
+   struct clk *clk_pipe;


Use bulk clk APIs? And just get and enable all the clks?


yes.




+   struct regulator *vdda1p8;
+   struct regulator *vbus;
+   struct regulator *vdd;
+   unsigned int vdd_levels[LEVEL_NUM];
+};
+
+static inline void qcom_ssphy_updatel(void __iomem *addr, u32 mask, u32 val)
+{
+   writel((readl(addr) & ~mask) | val, addr);
+}
+
+static int qcom_ssphy_config_vdd(struct ssphy_priv *priv,
+enum phy_vdd_level level)
+{
+   return regulator_set_voltage(priv->vdd,
+priv->vdd_levels[level],
+priv->vdd_levels[LEVEL_MAX]);


regulator_set_voltage(reg, 0, max) is very suspicious. It's voltage
corners where the voltages are known?


sorry I dont understand the question

this regulator on the ss phy wold be
vreg_l3_1p05: l3 {
regulator-min-microvolt = <976000>;
regulator-max-microvolt = <116>;
};



+}
+
+static int qcom_ssphy_ldo_enable(struct ssphy_priv *priv)
+{
+   int ret;
+
+   ret = regulator_set_load(priv->vdda1p8, 23000);


Do you need to do this? Why can't the regulator be in high power mode
all the time and then go low power when it's disabled?


this regulator is shared with the usb hs phy and each (ss/hs) have 
different load requirements. why would it be wrong for the ss phy to 
announce its needs (which will differ from those of the hs phy)?





+   if (ret < 0) {
+   dev_err(priv->dev, "Failed to set regulator1p8 load\n");
+   return ret;
+   }
+
+   ret = regulator_set_voltage(priv->vdda1p8, 180, 180);


This looks unnecessary. The 1.8V regulator sounds like it better be 1.8V
so board constraints should enforce that. All that should be here is
enabling the regulator.


ok




+   if (ret) {
+   dev_err(priv->dev, "Failed to set regulator1p8 voltage\n");
+   goto put_vdda1p8_lpm;
+   }
+
+   ret = regulator_enable(priv->vdda1p8);
+   if (ret) {
+   dev_err(priv->dev, "Failed to enable regulator1p8\n");
+   goto unset_vdda1p8;
+   }
+
+   return ret;
+
+   /* rollback regulator changes */
+
+unset_vdda1p8:
+   regulator_set_voltage(priv->vdda1p8, 0, 180);
+
+put_vdda1p8_lpm:
+   regulator_set_load(priv->vdda1p8, 0);
+
+   return ret;
+}
+
+static void qcom_ssphy_ldo_disable(struct ssphy_priv *priv)
+{
+   regulator_disable(priv->vdda1p8);
+   regulator_set_voltage(priv->vdda1p8, 0, 180);


Urgh why?


since it is being shared with the hs phy I understand this is required 
to vote the transition to the lowest voltage state.



+   regulator_set_load(priv->vdda1p8, 0);
+}






[PATCH v2] net: dsa: bcm_sf2: Propagate error value from mdio_write

2018-12-26 Thread Kangjie Lu
Both bcm_sf2_sw_indir_rw and mdiobus_write_nested could fail, so let's
return their error codes upstream.

Signed-off-by: Kangjie Lu 
---
 drivers/net/dsa/bcm_sf2.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 2eb68769562c..73fbc16a1f86 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -305,9 +305,8 @@ static int bcm_sf2_sw_mdio_write(struct mii_bus *bus, int 
addr, int regnum,
if (addr == BRCM_PSEUDO_PHY_ADDR && priv->indir_phy_mask & BIT(addr))
bcm_sf2_sw_indir_rw(priv, 0, addr, regnum, val);
else
-   mdiobus_write_nested(priv->master_mii_bus, addr, regnum, val);
-
-   return 0;
+   return mdiobus_write_nested(priv->master_mii_bus,
+   addr, regnum, val);
 }
 
 static irqreturn_t bcm_sf2_switch_0_isr(int irq, void *dev_id)
-- 
2.17.2 (Apple Git-113)



Re: [PATCH] net:phy: Add a return value check on bus write

2018-12-26 Thread Heiner Kallweit
On 26.12.2018 18:37, Aditya Pakki wrote:
> xgmiitorgmii_read_status() could fail when writing to the bus via
> mdiobus_write(). The fix adds a check and returns an error in case
> of failure.
> 
> Signed-off-by: Aditya Pakki 
> ---

Two more things:
- subject should be: "net: phy: xgmiitorgmii: check bus write return value"
  See also git history of this file.
- patch needs to be properly annotated as "net" or "net-next".
  net-next is closed currently, please re-submit once it's open again in
  ~ 2-3 weeks.

Heiner


Re: [PATCH] sunrpc: remove redundant code

2018-12-26 Thread Chuck Lever



> On Dec 25, 2018, at 10:24 PM, Kangjie Lu  wrote:
> 
> If no bytes to decode, just use "xdr->p" instead of calling
> xdr_inline_decode to get it. The fix cleans up the code.
> 
> Signed-off-by: Kangjie Lu 
> ---
> net/sunrpc/xprtrdma/rpc_rdma.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c
> index 9f53e0240035..2ef86be49bd8 100644
> --- a/net/sunrpc/xprtrdma/rpc_rdma.c
> +++ b/net/sunrpc/xprtrdma/rpc_rdma.c
> @@ -1123,7 +1123,6 @@ rpcrdma_decode_msg(struct rpcrdma_xprt *r_xprt, struct 
> rpcrdma_rep *rep,
> {
>   struct xdr_stream *xdr = >rr_stream;
>   u32 writelist, replychunk, rpclen;
> - char *base;
> 
>   /* Decode the chunk lists */
>   if (decode_read_list(xdr))
> @@ -1138,10 +1137,9 @@ rpcrdma_decode_msg(struct rpcrdma_xprt *r_xprt, struct 
> rpcrdma_rep *rep,
>   return -EIO;
> 
>   /* Build the RPC reply's Payload stream in rqst->rq_rcv_buf */
> - base = (char *)xdr_inline_decode(xdr, 0);
>   rpclen = xdr_stream_remaining(xdr);
>   r_xprt->rx_stats.fixup_copy_count +=
> - rpcrdma_inline_fixup(rqst, base, rpclen, writelist & 3);
> + rpcrdma_inline_fixup(rqst, xdr->p, rpclen, writelist & 3);

I used xdr_inline_decode(xdr, 0) here because I didn't want to
embed specific knowledge about struct xdr_stream into
rpcrdma_decode_msg. IOW, adhere to the API contract.

Given the need for adding a type cast to this function call, as
reported by the kbuild robot, I don't see that this patch improves
things significantly.


>   r_xprt->rx_stats.total_rdma_reply += writelist;
>   return rpclen + xdr_align_size(writelist);
> -- 
> 2.17.2 (Apple Git-113)
> 

--
Chuck Lever





Re: [PATCH] net:phy: Add a return value check on bus write

2018-12-26 Thread Heiner Kallweit
On 26.12.2018 18:37, Aditya Pakki wrote:
> xgmiitorgmii_read_status() could fail when writing to the bus via
> mdiobus_write(). The fix adds a check and returns an error in case
> of failure.
> 
> Signed-off-by: Aditya Pakki 
> ---
>  drivers/net/phy/xilinx_gmii2rgmii.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/phy/xilinx_gmii2rgmii.c 
> b/drivers/net/phy/xilinx_gmii2rgmii.c
> index 74a8782313cf..926879d43373 100644
> --- a/drivers/net/phy/xilinx_gmii2rgmii.c
> +++ b/drivers/net/phy/xilinx_gmii2rgmii.c
> @@ -58,7 +58,9 @@ static int xgmiitorgmii_read_status(struct phy_device 
> *phydev)
>   else
>   val |= BMCR_SPEED10;
>  
> - mdiobus_write(bus, addr, XILINX_GMII2RGMII_REG, val);
> + err = mdiobus_write(bus, addr, XILINX_GMII2RGMII_REG, val);
> + if (err)
> + return err;
>  
>   return 0;
Why not simply:
return mdiobus_write(bus, addr, XILINX_GMII2RGMII_REG, val);

Heiner


Re: [PATCH] char: hw_random: Fix missing check during driver release

2018-12-26 Thread Michael S. Tsirkin
On Wed, Dec 26, 2018 at 11:23:31AM -0600, Aditya Pakki wrote:
> devres_release can return -ENOENT if the device is not freed. The fix
> throws a warning consistent with other invocations.
> 
> Signed-off-by: Aditya Pakki 

Well why not

Acked-by: Michael S. Tsirkin 


> ---
>  drivers/char/hw_random/core.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> index 95be7228f327..582d983fa93f 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -578,7 +578,11 @@ EXPORT_SYMBOL_GPL(devm_hwrng_register);
>  
>  void devm_hwrng_unregister(struct device *dev, struct hwrng *rng)
>  {
> - devres_release(dev, devm_hwrng_release, devm_hwrng_match, rng);
> + int rc;
> +
> + rc = devres_release(dev, devm_hwrng_release, devm_hwrng_match, rng);
> + if (rc)
> + WARN_ON(rc);
>  }
>  EXPORT_SYMBOL_GPL(devm_hwrng_unregister);
>  
> -- 
> 2.17.1


[PATCH] net:phy: Add a return value check on bus write

2018-12-26 Thread Aditya Pakki
xgmiitorgmii_read_status() could fail when writing to the bus via
mdiobus_write(). The fix adds a check and returns an error in case
of failure.

Signed-off-by: Aditya Pakki 
---
 drivers/net/phy/xilinx_gmii2rgmii.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/xilinx_gmii2rgmii.c 
b/drivers/net/phy/xilinx_gmii2rgmii.c
index 74a8782313cf..926879d43373 100644
--- a/drivers/net/phy/xilinx_gmii2rgmii.c
+++ b/drivers/net/phy/xilinx_gmii2rgmii.c
@@ -58,7 +58,9 @@ static int xgmiitorgmii_read_status(struct phy_device *phydev)
else
val |= BMCR_SPEED10;
 
-   mdiobus_write(bus, addr, XILINX_GMII2RGMII_REG, val);
+   err = mdiobus_write(bus, addr, XILINX_GMII2RGMII_REG, val);
+   if (err)
+   return err;
 
return 0;
 }
-- 
2.17.1



Re: [PATCH] sunrpc: fix a missing check of xdr_inline_decode

2018-12-26 Thread Chuck Lever



> On Dec 25, 2018, at 10:18 PM, Kangjie Lu  wrote:
> 
> xdr_inline_decode() could fail.

NAK: xdr_inline_decode cannot fail if its second argument is zero.


> When it fails, the return value is NULL
> and should not be dereferenced.
> The fix checks if xdr_inline_decode fails, and if so, returns.
> 
> Signed-off-by: Kangjie Lu 
> ---
> net/sunrpc/xprtrdma/backchannel.c | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/net/sunrpc/xprtrdma/backchannel.c 
> b/net/sunrpc/xprtrdma/backchannel.c
> index e5b367a3e517..bd9be5272ef4 100644
> --- a/net/sunrpc/xprtrdma/backchannel.c
> +++ b/net/sunrpc/xprtrdma/backchannel.c
> @@ -285,6 +285,8 @@ void rpcrdma_bc_receive_call(struct rpcrdma_xprt *r_xprt,
>   __be32 *p;
> 
>   p = xdr_inline_decode(>rr_stream, 0);
> + if (unlikely(!p))
> + goto out_overflow;
>   size = xdr_stream_remaining(>rr_stream);
> 
> #ifdef RPCRDMA_BACKCHANNEL_DEBUG
> -- 
> 2.17.2 (Apple Git-113)
> 

--
Chuck Lever





Re: [PATCH v3 08/11] ASoC: Intel: atom: Make PCI dependency explicit

2018-12-26 Thread Pierre-Louis Bossart



On 12/23/18 5:25 PM, Sinan Kaya wrote:

Code does unconditional select for IOSF_MBI. IOSF_MBI driver depends on
CONFIG_PCI set but this is not specified anywhere.


Can you please share the .config that exposes this problem? This hasn't 
changed in a long time and I wonder why this pops up now. You have 
similar cases elsewhere, e.g. arch/x86/Kconfig


config X86_INTEL_LPSS
    bool "Intel Low Power Subsystem Support"
    depends on X86 && ACPI
    select COMMON_CLK
    select PINCTRL
    select IOSF_MBI

or for the MMC.

config MMC_SDHCI_ACPI
    tristate "SDHCI support for ACPI enumerated SDHCI controllers"
    depends on MMC_SDHCI && ACPI
    select IOSF_MBI if X86

The use of IOSF_MBI is only for the Baytrail-CR detection and there are 
already in-flight patches to change the code and move it to a helper.


My understanding is that for compilation you only need CONFIG_x86 since 
there are fall-back routines available in iosf_mbi.h


Thanks!



Signed-off-by: Sinan Kaya 
---
  sound/soc/intel/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
index 2fd1b61e8331..b0764b2fe001 100644
--- a/sound/soc/intel/Kconfig
+++ b/sound/soc/intel/Kconfig
@@ -91,7 +91,7 @@ config SND_SST_ATOM_HIFI2_PLATFORM_PCI
  config SND_SST_ATOM_HIFI2_PLATFORM_ACPI
tristate "ACPI HiFi2 (Baytrail, Cherrytrail) Platforms"
default ACPI
-   depends on X86 && ACPI
+   depends on X86 && ACPI && PCI
select SND_SST_IPC_ACPI
select SND_SST_ATOM_HIFI2_PLATFORM
select SND_SOC_ACPI_INTEL_MATCH


<    1   2   3   4   5   6   >