linux-next boot error: WARNING in prepare_kswapd_sleep

2020-11-23 Thread syzbot
Hello,

syzbot found the following issue on:

HEAD commit:d9137320 Add linux-next specific files for 20201124
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17b1407950
kernel config:  https://syzkaller.appspot.com/x/.config?x=2ac6081150c8eac
dashboard link: https://syzkaller.appspot.com/bug?extid=ce635500093181f39c1c
compiler:   gcc (GCC) 10.1.0-syz 20200507

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ce635500093181f39...@syzkaller.appspotmail.com

[ cut here ]
WARNING: CPU: 1 PID: 2192 at include/linux/memcontrol.h:621 arch_static_branch 
arch/x86/include/asm/jump_label.h:25 [inline]
WARNING: CPU: 1 PID: 2192 at include/linux/memcontrol.h:621 mem_cgroup_disabled 
include/linux/memcontrol.h:504 [inline]
WARNING: CPU: 1 PID: 2192 at include/linux/memcontrol.h:621 mem_cgroup_lruvec 
include/linux/memcontrol.h:616 [inline]
WARNING: CPU: 1 PID: 2192 at include/linux/memcontrol.h:621 
clear_pgdat_congested mm/vmscan.c:3443 [inline]
WARNING: CPU: 1 PID: 2192 at include/linux/memcontrol.h:621 
prepare_kswapd_sleep mm/vmscan.c:3480 [inline]
WARNING: CPU: 1 PID: 2192 at include/linux/memcontrol.h:621 
prepare_kswapd_sleep+0xed/0x250 mm/vmscan.c:3456
Modules linked in:
CPU: 1 PID: 2192 Comm: kswapd0 Not tainted 5.10.0-rc5-next-20201124-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:mem_cgroup_lruvec include/linux/memcontrol.h:621 [inline]
RIP: 0010:clear_pgdat_congested mm/vmscan.c:3443 [inline]
RIP: 0010:prepare_kswapd_sleep mm/vmscan.c:3480 [inline]
RIP: 0010:prepare_kswapd_sleep+0xed/0x250 mm/vmscan.c:3456
Code: 89 ee 48 89 df e8 73 d3 ff ff 31 ff 41 89 c4 89 c6 e8 87 19 d7 ff 45 84 
e4 74 cc e8 6d 21 d7 ff 0f 1f 44 00 00 e8 63 21 d7 ff <0f> 0b 48 c7 c0 28 8d ee 
8c 48 ba 00 00 00 00 00 fc ff df 48 c1 e8
RSP: :c900085bfda0 EFLAGS: 00010293
RAX:  RBX: 88813fffb000 RCX: 81998e19
RDX: 8880168c1ac0 RSI: 81998e2d RDI: 0001
RBP:  R08: 0ab3 R09: 0f89
R10:  R11:  R12: 0001
R13: 0004 R14:  R15: 0003
FS:  () GS:8880b9f0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 0b08e000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 kswapd_try_to_sleep mm/vmscan.c:3784 [inline]
 kswapd+0x37d/0xdb0 mm/vmscan.c:3899
 kthread+0x3b1/0x4a0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 2192 Comm: kswapd0 Not tainted 5.10.0-rc5-next-20201124-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x107/0x163 lib/dump_stack.c:120
 panic+0x306/0x73d kernel/panic.c:231
 __warn.cold+0x35/0x44 kernel/panic.c:605
 report_bug+0x1bd/0x210 lib/bug.c:198
 handle_bug+0x3c/0x60 arch/x86/kernel/traps.c:239
 exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:259
 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:578
RIP: 0010:mem_cgroup_lruvec include/linux/memcontrol.h:621 [inline]
RIP: 0010:clear_pgdat_congested mm/vmscan.c:3443 [inline]
RIP: 0010:prepare_kswapd_sleep mm/vmscan.c:3480 [inline]
RIP: 0010:prepare_kswapd_sleep+0xed/0x250 mm/vmscan.c:3456
Code: 89 ee 48 89 df e8 73 d3 ff ff 31 ff 41 89 c4 89 c6 e8 87 19 d7 ff 45 84 
e4 74 cc e8 6d 21 d7 ff 0f 1f 44 00 00 e8 63 21 d7 ff <0f> 0b 48 c7 c0 28 8d ee 
8c 48 ba 00 00 00 00 00 fc ff df 48 c1 e8
RSP: :c900085bfda0 EFLAGS: 00010293
RAX:  RBX: 88813fffb000 RCX: 81998e19
RDX: 8880168c1ac0 RSI: 81998e2d RDI: 0001
RBP:  R08: 0ab3 R09: 0f89
R10:  R11:  R12: 0001
R13: 0004 R14:  R15: 0003
 kswapd_try_to_sleep mm/vmscan.c:3784 [inline]
 kswapd+0x37d/0xdb0 mm/vmscan.c:3899
 kthread+0x3b1/0x4a0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.


Re: [PATCH v3 00/10] Introduced new Cadence USBSSP DRD Driver.

2020-11-23 Thread Peter Chen
On 20-11-19 15:12:57, Pawel Laszczak wrote:
> This patch introduce new Cadence USBSS DRD driver to linux kernel.
> 
> The Cadence USBSS DRD Controller is a highly configurable IP Core which
> can be instantiated as Dual-Role Device (DRD), Peripheral Only and
> Host Only (XHCI)configurations.
> 
> The current driver has been validated with FPGA burned. We have support
> for PCIe bus, which is used on FPGA prototyping.
> 
> The host side of USBSS-DRD controller is compliance with XHCI
> specification, so it works with standard XHCI Linux driver.
> 
> The device side of USBSS DRD controller is compliant with XHCI.
> The architecture for device side is almost the same as for host side,
> and most of the XHCI specification can be used to understand how
> this controller operates.
> 
> This controller and driver support Full Speed, Hight Speed, Supper Speed
> and Supper Speed Plus USB protocol.
> 
> The prefix cdnsp used in driver has chosen by analogy to cdn3 driver.
> The last letter of this acronym means PLUS. The formal name of controller
> is USBSSP but it's to generic so I've decided to use CDNSP.
> 
> The patch 1: adds support for DRD CDNSP.
> The patch 2: separates common code that can be reusable by cdnsp driver.
> The patch 3: moves reusable code to separate module.
> The patch 4: changes prefixes in reusable code from cdns3 to common cdns.
> The patch 5: adopts gadget_dev pointer in cdns structure to make possible 
>  use it in both drivers.
> The patches 6-8: add the main part of driver and has been intentionally
>  split into 3 part. In my opinion such division should not
>  affect understanding and reviewing the driver, and cause that
>  main patch (7/8) is little smaller. Patch 6 introduces main
>  header file for driver, 7 is the main part that implements all
>  functionality of driver and 8 introduces tracepoints.
> The patch 9: Adds cdns3 prefixes to files related with USBSS driver.
> the patch 10: Adds USBSSP DRD IP driver entry to MAINTAINERS file.
> 
> Changlog from v2:
> - removed not used pdev parameter from cdnsp_read/wite_64 functions
> - fixed incorrect value assigned to CDNSP_ENDPOINTS_NUM (32 -> 31)
> - replaced some constant value with CDNSP_ENDPOINTS_NUM macro
> - replaced 'true' with '1' in bits description in cdnsp-gadget.h file
> - fixed some typos
> - some other less important changes suggested by Peter Chen

Hi Pawel,

I have updated my -next tree as the latest usb-next tree which v5.10-rc4
is included, would you please rebase my tree and send again, I could apply your
patches and test, if test could pass, I will apply it to my -next tree.
You don't need to rebase again since it is a huge patch set, will take some
efforts for rebase.

Peter
> 
> Changlog from v1:
> - updated common code to latest cdns3 driver
> - moved cdnsp driver files to cdns3 as sugested by Peter Chan
> - removed duplicate code from cdnsp_ep0_set_config function
> - added cdns3 prefixes to file related with USBSS driver
> - updated MAINTAINERS file
> - fixed issue with U1
> - fixed issue with L1
> - some less improtant changes sugested by Chunfeng Yun
> ---
> 
> Pawel Laszczak (10):
>   usb: cdns3: Add support for DRD CDNSP
>   usb: cdns3: Split core.c into cdns3-plat and core.c file
>   usb: cdns3: Moves reusable code to separate module
>   usb: cdns3: Refactoring names in reusable code
>   usb: cdns3: Changed type of gadget_dev in cdns structure
>   usb: cdnsp: Device side header file for CDNSP driver
>   usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver
>   usb: cdnsp: Add tracepoints for CDNSP driver
>   usb: cdns3: Change file names for cdns3 driver.
>   MAINTAINERS: add Cadence USBSSP DRD IP driver entry
> 
>  MAINTAINERS   |8 +
>  drivers/usb/Makefile  |2 +
>  drivers/usb/cdns3/Kconfig |   61 +-
>  drivers/usb/cdns3/Makefile|   30 +-
>  drivers/usb/cdns3/{debug.h => cdns3-debug.h}  |0
>  drivers/usb/cdns3/{ep0.c => cdns3-ep0.c}  |4 +-
>  .../usb/cdns3/{gadget.c => cdns3-gadget.c}|   28 +-
>  .../usb/cdns3/{gadget.h => cdns3-gadget.h}|0
>  drivers/usb/cdns3/cdns3-imx.c |2 +-
>  drivers/usb/cdns3/cdns3-plat.c|  315 +++
>  drivers/usb/cdns3/{trace.c => cdns3-trace.c}  |2 +-
>  drivers/usb/cdns3/{trace.h => cdns3-trace.h}  |6 +-
>  drivers/usb/cdns3/cdnsp-debug.h   |  583 
>  drivers/usb/cdns3/cdnsp-ep0.c |  495 
>  drivers/usb/cdns3/cdnsp-gadget.c  | 2017 ++
>  drivers/usb/cdns3/cdnsp-gadget.h  | 1600 +++
>  drivers/usb/cdns3/cdnsp-mem.c | 1325 +
>  drivers/usb/cdns3/cdnsp-pci.c |  255 ++
>  drivers/usb/cdns3/cdnsp-ring.c| 2439 +
>  drivers/usb/cdns3/cdnsp-trace.c   |   12 +
>  

[PATCH net-next v2 3/3] net: phy: mscc: use new PTP_MSGTYPE_* defines

2020-11-23 Thread Christian Eggers
Use recently introduced PTP_MSGTYPE_SYNC and PTP_MSGTYPE_DELAY_REQ
defines instead of a driver internal enumeration.

Signed-off-by: Christian Eggers 
Reviewed-by: Antoine Tenart 
Cc: Antoine Tenart 
---
 drivers/net/phy/mscc/mscc_ptp.c | 14 +++---
 drivers/net/phy/mscc/mscc_ptp.h |  5 -
 2 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/net/phy/mscc/mscc_ptp.c b/drivers/net/phy/mscc/mscc_ptp.c
index d8a61456d1ce..924ed5b034a4 100644
--- a/drivers/net/phy/mscc/mscc_ptp.c
+++ b/drivers/net/phy/mscc/mscc_ptp.c
@@ -506,9 +506,9 @@ static int vsc85xx_ptp_cmp_init(struct phy_device *phydev, 
enum ts_blk blk)
 {
struct vsc8531_private *vsc8531 = phydev->priv;
bool base = phydev->mdio.addr == vsc8531->ts_base_addr;
-   enum vsc85xx_ptp_msg_type msgs[] = {
-   PTP_MSG_TYPE_SYNC,
-   PTP_MSG_TYPE_DELAY_REQ
+   u8 msgs[] = {
+   PTP_MSGTYPE_SYNC,
+   PTP_MSGTYPE_DELAY_REQ
};
u32 val;
u8 i;
@@ -847,9 +847,9 @@ static int vsc85xx_ts_ptp_action_flow(struct phy_device 
*phydev, enum ts_blk blk
 static int vsc85xx_ptp_conf(struct phy_device *phydev, enum ts_blk blk,
bool one_step, bool enable)
 {
-   enum vsc85xx_ptp_msg_type msgs[] = {
-   PTP_MSG_TYPE_SYNC,
-   PTP_MSG_TYPE_DELAY_REQ
+   u8 msgs[] = {
+   PTP_MSGTYPE_SYNC,
+   PTP_MSGTYPE_DELAY_REQ
};
u32 val;
u8 i;
@@ -858,7 +858,7 @@ static int vsc85xx_ptp_conf(struct phy_device *phydev, enum 
ts_blk blk,
if (blk == INGRESS)
vsc85xx_ts_ptp_action_flow(phydev, blk, msgs[i],
   PTP_WRITE_NS);
-   else if (msgs[i] == PTP_MSG_TYPE_SYNC && one_step)
+   else if (msgs[i] == PTP_MSGTYPE_SYNC && one_step)
/* no need to know Sync t when sending in one_step */
vsc85xx_ts_ptp_action_flow(phydev, blk, msgs[i],
   PTP_WRITE_1588);
diff --git a/drivers/net/phy/mscc/mscc_ptp.h b/drivers/net/phy/mscc/mscc_ptp.h
index 3ea163af0f4f..da3465360e90 100644
--- a/drivers/net/phy/mscc/mscc_ptp.h
+++ b/drivers/net/phy/mscc/mscc_ptp.h
@@ -436,11 +436,6 @@ enum ptp_cmd {
PTP_SAVE_IN_TS_FIFO = 11, /* invalid when writing in reg */
 };
 
-enum vsc85xx_ptp_msg_type {
-   PTP_MSG_TYPE_SYNC,
-   PTP_MSG_TYPE_DELAY_REQ,
-};
-
 struct vsc85xx_ptphdr {
u8 tsmt; /* transportSpecific | messageType */
u8 ver;  /* reserved0 | versionPTP */
-- 
Christian Eggers
Embedded software developer

Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: 
HRA 57918
Persoenlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: 
HRB 54477
Geschaeftsfuehrer: Dr. Michael Neuhaeuser; Stephan Schenk; Walter Trauninger; 
Markus Zeiler



[PATCH] i2c: cadence: Clear HOLD bit before xfer_size register rolls over

2020-11-23 Thread Raviteja Narayanam
On Xilinx zynq SOC if the delay between address register write and
control register write in cdns_mrecv function is more, the xfer size
register rolls over and controller is stuck. This is an IP bug and
is resolved in later versions of IP.

To avoid this scenario, disable the interrupts on the current processor
core between the two register writes and enable them later. This can
help achieve the timing constraint.

Signed-off-by: Raviteja Narayanam 
---
 drivers/i2c/busses/i2c-cadence.c | 48 ++--
 1 file changed, 41 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index e4b7f2a..81b7c45 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -578,6 +578,11 @@ static void cdns_i2c_mrecv(struct cdns_i2c *id)
 {
unsigned int ctrl_reg;
unsigned int isr_status;
+   unsigned long flags;
+   bool hold_clear = false;
+   bool irq_save = false;
+
+   u32 addr;
 
id->p_recv_buf = id->p_msg->buf;
id->recv_count = id->p_msg->len;
@@ -618,14 +623,43 @@ static void cdns_i2c_mrecv(struct cdns_i2c *id)
cdns_i2c_writereg(id->recv_count, CDNS_I2C_XFER_SIZE_OFFSET);
}
 
-   /* Set the slave address in address register - triggers operation */
-   cdns_i2c_writereg(id->p_msg->addr & CDNS_I2C_ADDR_MASK,
-   CDNS_I2C_ADDR_OFFSET);
-   /* Clear the bus hold flag if bytes to receive is less than FIFO size */
+   /* Determine hold_clear based on number of bytes to receive and hold 
flag */
if (!id->bus_hold_flag &&
-   ((id->p_msg->flags & I2C_M_RECV_LEN) != I2C_M_RECV_LEN) &&
-   (id->recv_count <= CDNS_I2C_FIFO_DEPTH))
-   cdns_i2c_clear_bus_hold(id);
+   ((id->p_msg->flags & I2C_M_RECV_LEN) != I2C_M_RECV_LEN) &&
+   (id->recv_count <= CDNS_I2C_FIFO_DEPTH)) {
+   if (cdns_i2c_readreg(CDNS_I2C_CR_OFFSET) & CDNS_I2C_CR_HOLD) {
+   hold_clear = true;
+   if (id->quirks & CDNS_I2C_BROKEN_HOLD_BIT)
+   irq_save = true;
+   }
+   }
+
+   addr = id->p_msg->addr;
+   addr &= CDNS_I2C_ADDR_MASK;
+
+   if (hold_clear) {
+   ctrl_reg = cdns_i2c_readreg(CDNS_I2C_CR_OFFSET) & 
~CDNS_I2C_CR_HOLD;
+   /*
+* In case of Xilinx Zynq SOC, clear the HOLD bit before 
transfer size
+* register reaches '0'. This is an IP bug which causes 
transfer size
+* register overflow to 0xFF. To satisfy this timing 
requirement,
+* disable the interrupts on current processor core between 
register
+* writes to slave address register and control register.
+*/
+   if (irq_save)
+   local_irq_save(flags);
+
+   cdns_i2c_writereg(addr, CDNS_I2C_ADDR_OFFSET);
+   cdns_i2c_writereg(ctrl_reg, CDNS_I2C_CR_OFFSET);
+   /* Read it back to avoid bufferring and make sure write happens 
*/
+   cdns_i2c_readreg(CDNS_I2C_CR_OFFSET);
+
+   if (irq_save)
+   local_irq_restore(flags);
+   } else {
+   cdns_i2c_writereg(addr, CDNS_I2C_ADDR_OFFSET);
+   }
+
cdns_i2c_writereg(CDNS_I2C_ENABLED_INTR_MASK, CDNS_I2C_IER_OFFSET);
 }
 
-- 
2.7.4



[PATCH net-next v2 2/3] mlxsw: spectrum_ptp: use PTP wide message type definitions

2020-11-23 Thread Christian Eggers
Use recently introduced PTP wide defines instead of a driver internal
enumeration.

Signed-off-by: Christian Eggers 
Reviewed-by: Ido Schimmel 
Cc: Petr Machata 
Cc: Jiri Pirko 
Cc: Ido Schimmel 
---
 drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c | 8 
 drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.h | 7 ---
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c 
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
index ca8090a28dec..d6e9ecb14681 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.c
@@ -828,10 +828,10 @@ struct mlxsw_sp_ptp_state *mlxsw_sp1_ptp_init(struct 
mlxsw_sp *mlxsw_sp)
goto err_hashtable_init;
 
/* Delive these message types as PTP0. */
-   message_type = BIT(MLXSW_SP_PTP_MESSAGE_TYPE_SYNC) |
-  BIT(MLXSW_SP_PTP_MESSAGE_TYPE_DELAY_REQ) |
-  BIT(MLXSW_SP_PTP_MESSAGE_TYPE_PDELAY_REQ) |
-  BIT(MLXSW_SP_PTP_MESSAGE_TYPE_PDELAY_RESP);
+   message_type = BIT(PTP_MSGTYPE_SYNC) |
+  BIT(PTP_MSGTYPE_DELAY_REQ) |
+  BIT(PTP_MSGTYPE_PDELAY_REQ) |
+  BIT(PTP_MSGTYPE_PDELAY_RESP);
err = mlxsw_sp_ptp_mtptpt_set(mlxsw_sp, MLXSW_REG_MTPTPT_TRAP_ID_PTP0,
  message_type);
if (err)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.h 
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.h
index 8c386571afce..1d43a3755285 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.h
@@ -11,13 +11,6 @@ struct mlxsw_sp;
 struct mlxsw_sp_port;
 struct mlxsw_sp_ptp_clock;
 
-enum {
-   MLXSW_SP_PTP_MESSAGE_TYPE_SYNC,
-   MLXSW_SP_PTP_MESSAGE_TYPE_DELAY_REQ,
-   MLXSW_SP_PTP_MESSAGE_TYPE_PDELAY_REQ,
-   MLXSW_SP_PTP_MESSAGE_TYPE_PDELAY_RESP,
-};
-
 static inline int mlxsw_sp_ptp_get_ts_info_noptp(struct ethtool_ts_info *info)
 {
info->so_timestamping = SOF_TIMESTAMPING_RX_SOFTWARE |
-- 
Christian Eggers
Embedded software developer

Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: 
HRA 57918
Persoenlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: 
HRB 54477
Geschaeftsfuehrer: Dr. Michael Neuhaeuser; Stephan Schenk; Walter Trauninger; 
Markus Zeiler



Re: [PATCH] ubifs: Fix error return code in ubifs_init_authentication()

2020-11-23 Thread Sascha Hauer
On Tue, Nov 24, 2020 at 02:33:20PM +0800, Wang ShaoBo wrote:
> Fix to return PTR_ERR() error code from the error handling case where
> ubifs_hash_get_desc() failed instead of 0 in ubifs_init_authentication(),
> as done elsewhere in this function.
> 
> Fixes: 49525e5eecca5 ("ubifs: Add helper functions for authentication 
> support")
> Signed-off-by: Wang ShaoBo 
> ---
>  fs/ubifs/auth.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Reviewed-by: Sascha Hauer 

Sascha

> 
> diff --git a/fs/ubifs/auth.c b/fs/ubifs/auth.c
> index b93b3cd10bfd..8c50de693e1d 100644
> --- a/fs/ubifs/auth.c
> +++ b/fs/ubifs/auth.c
> @@ -338,8 +338,10 @@ int ubifs_init_authentication(struct ubifs_info *c)
>   c->authenticated = true;
>  
>   c->log_hash = ubifs_hash_get_desc(c);
> - if (IS_ERR(c->log_hash))
> + if (IS_ERR(c->log_hash)) {
> + err = PTR_ERR(c->log_hash);
>   goto out_free_hmac;
> + }
>  
>   err = 0;
>  
> -- 
> 2.17.1
> 
> 

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


[PATCH net-next v2 1/3] net: phy: dp83640: use new PTP_MSGTYPE_SYNC define

2020-11-23 Thread Christian Eggers
Replace use of magic number with recently introduced define.

Signed-off-by: Christian Eggers 
Cc: Kurt Kanzenbach 
---
 drivers/net/phy/dp83640.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index f2caccaf4408..9757ca0d9633 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -964,15 +964,12 @@ static void decode_status_frame(struct dp83640_private 
*dp83640,
 static int is_sync(struct sk_buff *skb, int type)
 {
struct ptp_header *hdr;
-   u8 msgtype;
 
hdr = ptp_parse_header(skb, type);
if (!hdr)
return 0;
 
-   msgtype = ptp_get_msgtype(hdr, type);
-
-   return (msgtype & 0xf) == 0;
+   return ptp_get_msgtype(hdr, type) == PTP_MSGTYPE_SYNC;
 }
 
 static void dp83640_free_clocks(void)
-- 
Christian Eggers
Embedded software developer

Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: 
HRA 57918
Persoenlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: 
HRB 54477
Geschaeftsfuehrer: Dr. Michael Neuhaeuser; Stephan Schenk; Walter Trauninger; 
Markus Zeiler



Re: [PATCH v4] checkpatch: add fix and improve warning msg for Non-standard signature

2020-11-23 Thread Lukas Bulwahn
On Tue, Nov 24, 2020 at 8:26 AM Joe Perches  wrote:
>
> On Tue, 2020-11-24 at 07:54 +0100, Lukas Bulwahn wrote:
> > On Mon, Nov 23, 2020 at 6:33 PM Joe Perches  wrote:
> []
> > Maybe a patch reduced to the very obvious synonyms helps newcomers or
> > people with lousy memory to be reminded that it is called
> > "Co-developed-by:" not "Co-authored-by".
>
> I have no issue with proximity matching for nominally invalid uses.
> I think the method used wasn't great though.
> For trivial spelling defects, levenshtein might work well enough.
>

Yes, that is true. Aditya has actually created two patches, one using
some edit distance to find matches and one using a fixed match for
those cases (the one you see here). Both patches complement each
other. But he has only sent the second patch to you yet.

I guess when the other patch is sent out, it is a much clearer full
picture how this fix option will work.

Lukas


[PATCH net-next v2 0/3] net: ptp: use common defines for PTP message types in further drivers

2020-11-23 Thread Christian Eggers
Changes in v2:

- resend, as v1 was sent before the prerequisites were merged
- removed mismatch between From: and Signed-off-by:
- [2/3] Reviewed-by: Ido Schimmel 
- [3/3] Reviewed-by: Antoine Tenart 
- [3/3] removed dead email addresses from Cc:


This series replaces further driver internal enumeration / uses of magic
numbers with the newly introduced PTP_MSGTYPE_* defines.

On Friday, 20 November 2020, 23:39:10 CET, Vladimir Oltean wrote:
> On Fri, Nov 20, 2020 at 09:41:03AM +0100, Christian Eggers wrote:
> > This series introduces commen defines for PTP event messages. Driver
> > internal defines are removed and some uses of magic numbers are replaced
> > by the new defines.
> > [...]
> 
> I understand that you don't want to spend a lifetime on this, but I see
> that there are more drivers which you did not touch.
> 
> is_sync() in drivers/net/phy/dp83640.c can be made to
>   return ptp_get_msgtype(hdr, type) == PTP_MSGTYPE_SYNC;
> 
> this can be removed from drivers/net/ethernet/mellanox/mlxsw/spectrum_ptp.h:
> enum {
>   MLXSW_SP_PTP_MESSAGE_TYPE_SYNC,
>   MLXSW_SP_PTP_MESSAGE_TYPE_DELAY_REQ,
>   MLXSW_SP_PTP_MESSAGE_TYPE_PDELAY_REQ,
>   MLXSW_SP_PTP_MESSAGE_TYPE_PDELAY_RESP,
> };
I think that I have found an addtional one in the Microsemi VSC85xx PHY driver.






Re: [drm/fb] 6a1b34c0a3: WARNING:at_drivers/gpu/drm/drm_fb_helper.c:#drm_fb_helper_damage_work

2020-11-23 Thread Thomas Zimmermann

Hi

Am 24.11.20 um 02:58 schrieb Xing Zhengjun:



On 11/23/2020 4:04 PM, Thomas Zimmermann wrote:

Hi

Am 22.11.20 um 15:18 schrieb kernel test robot:


Greeting,

FYI, we noticed the following commit (built with gcc-9):

commit: 6a1b34c0a339fdc75d7932ad5702f2177c9d7a1c ("drm/fb-helper: 
Move damage blit code and its setup into separate routine")
url: 
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-fb-helper-Various-fixes-and-cleanups/20201120-182750 




in testcase: trinity
version: trinity-static-i386-x86_64-f93256fb_2019-08-28
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 
-m 8G


caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


That dmesg is full of messages like

[  696.323556] alloc_vmap_area: 24 callbacks suppressed
[  696.323562] vmap allocation for size 3149824 failed: use 
vmalloc= to increase size


I think the test system needs to be reconfigured first.



We have tried "vmalloc=256M" and "vmalloc=512M", the same warning still 
happened.


OK, then I don't know. Thanks for testing.

Best regards
Thomas





Best regards
Thomas




+---+++ 

|   
| 154f2d1afd | 6a1b34c0a3 |
+---+++ 

| 
WARNING:at_drivers/gpu/drm/drm_fb_helper.c:#drm_fb_helper_damage_work 
| 0  | 36 |

| EIP:drm_fb_helper_damage_work | 0  | 36 |
+---+++ 




If you fix the issue, kindly add following tag
Reported-by: kernel test robot 


[  106.616652] WARNING: CPU: 1 PID: 173 at 
drivers/gpu/drm/drm_fb_helper.c:434 
drm_fb_helper_damage_work+0x371/0x390

[  106.627732] Modules linked in:
[  106.632419] CPU: 1 PID: 173 Comm: kworker/1:2 Not tainted 
5.10.0-rc4-next-20201120-7-g6a1b34c0a339 #3
[  106.637806] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
BIOS 1.12.0-1 04/01/2014

[  106.642853] Workqueue: events drm_fb_helper_damage_work
[  106.647664] EIP: drm_fb_helper_damage_work+0x371/0x390
[  106.652305] Code: b1 17 c7 01 68 bd 5b 2d c5 53 50 68 55 21 2d c5 
83 15 44 b1 17 c7 00 e8 ae bc b1 01 83 05 48 b1 17 c7 01 83 15 4c b1 
17 c7 00 <0f> 0b 83 05 50 b1 17 c7 01 83 15 54 b1 17 c7 00 83 c4 10 
e9 78 fd

[  106.663517] EAX: 002d EBX: c8730520 ECX: 0847 EDX: 
[  106.668423] ESI: ca987000 EDI: cab274d8 EBP: f62f5f20 ESP: f62f5ee8
[  106.673214] DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068 EFLAGS: 
00010246

[  106.678295] CR0: 80050033 CR2:  CR3: 063a7000 CR4: 000406d0
[  106.683160] DR0:  DR1:  DR2:  DR3: 
[  106.687967] DR6: fffe0ff0 DR7: 0400
[  106.690763] Call Trace:
[  106.693394]  process_one_work+0x3ea/0xaa0
[  106.693501] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual 
Function Network Driver

[  106.695300]  worker_thread+0x330/0x900
[  106.697406] ixgbevf: Copyright (c) 2009 - 2018 Intel Corporation.
[  106.702963]  kthread+0x190/0x210
[  106.705709]  ? rescuer_thread+0x650/0x650
[  106.708379]  ? kthread_insert_work_sanity_check+0x120/0x120
[  106.711271]  ret_from_fork+0x1c/0x30
[  106.713973] ---[ end trace dd528799d3369ac1 ]---


To reproduce:

 # build kernel
cd linux
cp config-5.10.0-rc4-next-20201120-7-g6a1b34c0a339 .config
make HOSTCC=gcc-9 CC=gcc-9 ARCH=i386 olddefconfig prepare 
modules_prepare bzImage


 git clone https://github.com/intel/lkp-tests.git
 cd lkp-tests
 bin/lkp qemu -k  job-script # job-script is 
attached in this email




Thanks,
Oliver Sang




___
LKP mailing list -- l...@lists.01.org
To unsubscribe send an email to lkp-le...@lists.01.org





--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


OpenPGP_0x680DC11D530B7A23.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH] bdi: Fix error return code in alloc_wbufs()

2020-11-23 Thread Sascha Hauer
On Sun, Nov 15, 2020 at 04:23:43PM +0800, Wang ShaoBo wrote:
> Fix to return PTR_ERR() error code from the error handling case instead
> fo 0 in function alloc_wbufs(), as done elsewhere in this function.
> 
> Fixes: 6a98bc4614de ("ubifs: Add authentication nodes to journal")
> Signed-off-by: Wang ShaoBo 
> ---
>  fs/ubifs/super.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Prefix for this patch should be "ubifs:" rather than "bdi:". With this:

Reviewed-by: Sascha Hauer 

Sascha

> 
> diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
> index cb3acfb7dd1f..dacbb999ae34 100644
> --- a/fs/ubifs/super.c
> +++ b/fs/ubifs/super.c
> @@ -838,8 +838,10 @@ static int alloc_wbufs(struct ubifs_info *c)
>   c->jheads[i].wbuf.jhead = i;
>   c->jheads[i].grouped = 1;
>   c->jheads[i].log_hash = ubifs_hash_get_desc(c);
> - if (IS_ERR(c->jheads[i].log_hash))
> + if (IS_ERR(c->jheads[i].log_hash)) {
> + err = PTR_ERR(c->jheads[i].log_hash);
>   goto out;
> + }
>   }
>  
>   /*
> -- 
> 2.25.1
> 
> 

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


Re: [PATCH] media: ov8856: Remove 3280x2464 mode

2020-11-23 Thread Dongchun Zhu
Hi Robert,

Thanks for the patch.

On Mon, 2020-11-16 at 16:50 +0100, Robert Foss wrote:
> Remove the 3280x2464 mode as it can't be reproduced and yields
> an output resolution of 3264x2448 instead of the desired one.
> 
> Furthermore the 3264x2448 resolution is the highest resolution
> that the product brief lists.
> 
> Since 3280x2464 neither works correctly nor seems to be supported
> by the sensor, let's remove it.
> 

In fact, I was also confused about 3280x2464 setting at the beginning.
From datasheet, the OV8856 shall support an active array of 3264x2448
pixels (8-megapixel, the maximum) operating at 30fps.

> Signed-off-by: Robert Foss 
> ---
>  drivers/media/i2c/ov8856.c | 202 -
>  1 file changed, 202 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov8856.c b/drivers/media/i2c/ov8856.c
> index 2f4ceaa80593..3365d19a303d 100644
> --- a/drivers/media/i2c/ov8856.c
> +++ b/drivers/media/i2c/ov8856.c
> @@ -148,196 +148,6 @@ static const struct ov8856_reg mipi_data_rate_360mbps[] 
> = {
>   {0x031e, 0x0c},
>  };
>  
> -static const struct ov8856_reg mode_3280x2464_regs[] = {
> - {0x3000, 0x20},
> - {0x3003, 0x08},
> - {0x300e, 0x20},
> - {0x3010, 0x00},
> - {0x3015, 0x84},
> - {0x3018, 0x72},
> - {0x3021, 0x23},
> - {0x3033, 0x24},
> - {0x3500, 0x00},
> - {0x3501, 0x9a},
> - {0x3502, 0x20},
> - {0x3503, 0x08},
> - {0x3505, 0x83},
> - {0x3508, 0x01},
> - {0x3509, 0x80},
> - {0x350c, 0x00},
> - {0x350d, 0x80},
> - {0x350e, 0x04},
> - {0x350f, 0x00},
> - {0x3510, 0x00},
> - {0x3511, 0x02},
> - {0x3512, 0x00},
> - {0x3600, 0x72},
> - {0x3601, 0x40},
> - {0x3602, 0x30},
> - {0x3610, 0xc5},
> - {0x3611, 0x58},
> - {0x3612, 0x5c},
> - {0x3613, 0xca},
> - {0x3614, 0x20},
> - {0x3628, 0xff},
> - {0x3629, 0xff},
> - {0x362a, 0xff},
> - {0x3633, 0x10},
> - {0x3634, 0x10},
> - {0x3635, 0x10},
> - {0x3636, 0x10},
> - {0x3663, 0x08},
> - {0x3669, 0x34},
> - {0x366e, 0x10},
> - {0x3706, 0x86},
> - {0x370b, 0x7e},
> - {0x3714, 0x23},
> - {0x3730, 0x12},
> - {0x3733, 0x10},
> - {0x3764, 0x00},
> - {0x3765, 0x00},
> - {0x3769, 0x62},
> - {0x376a, 0x2a},
> - {0x376b, 0x30},
> - {0x3780, 0x00},
> - {0x3781, 0x24},
> - {0x3782, 0x00},
> - {0x3783, 0x23},
> - {0x3798, 0x2f},
> - {0x37a1, 0x60},
> - {0x37a8, 0x6a},
> - {0x37ab, 0x3f},
> - {0x37c2, 0x04},
> - {0x37c3, 0xf1},
> - {0x37c9, 0x80},
> - {0x37cb, 0x16},
> - {0x37cc, 0x16},
> - {0x37cd, 0x16},
> - {0x37ce, 0x16},
> - {0x3800, 0x00},
> - {0x3801, 0x00},
> - {0x3802, 0x00},
> - {0x3803, 0x06},
> - {0x3804, 0x0c},
> - {0x3805, 0xdf},
> - {0x3806, 0x09},
> - {0x3807, 0xa7},
> - {0x3808, 0x0c},
> - {0x3809, 0xd0},
> - {0x380a, 0x09},
> - {0x380b, 0xa0},
> - {0x380c, 0x07},
> - {0x380d, 0x88},
> - {0x380e, 0x09},
> - {0x380f, 0xb8},
> - {0x3810, 0x00},
> - {0x3811, 0x00},
> - {0x3812, 0x00},
> - {0x3813, 0x01},
> - {0x3814, 0x01},
> - {0x3815, 0x01},
> - {0x3816, 0x00},
> - {0x3817, 0x00},
> - {0x3818, 0x00},
> - {0x3819, 0x10},
> - {0x3820, 0x80},
> - {0x3821, 0x46},
> - {0x382a, 0x01},
> - {0x382b, 0x01},
> - {0x3830, 0x06},
> - {0x3836, 0x02},
> - {0x3862, 0x04},
> - {0x3863, 0x08},
> - {0x3cc0, 0x33},
> - {0x3d85, 0x17},
> - {0x3d8c, 0x73},
> - {0x3d8d, 0xde},
> - {0x4001, 0xe0},
> - {0x4003, 0x40},
> - {0x4008, 0x00},
> - {0x4009, 0x0b},
> - {0x400a, 0x00},
> - {0x400b, 0x84},
> - {0x400f, 0x80},
> - {0x4010, 0xf0},
> - {0x4011, 0xff},
> - {0x4012, 0x02},
> - {0x4013, 0x01},
> - {0x4014, 0x01},
> - {0x4015, 0x01},
> - {0x4042, 0x00},
> - {0x4043, 0x80},
> - {0x4044, 0x00},
> - {0x4045, 0x80},
> - {0x4046, 0x00},
> - {0x4047, 0x80},
> - {0x4048, 0x00},
> - {0x4049, 0x80},
> - {0x4041, 0x03},
> - {0x404c, 0x20},
> - {0x404d, 0x00},
> - {0x404e, 0x20},
> - {0x4203, 0x80},
> - {0x4307, 0x30},
> - {0x4317, 0x00},
> - {0x4503, 0x08},
> - {0x4601, 0x80},
> - {0x4800, 0x44},
> - {0x4816, 0x53},
> - {0x481b, 0x58},
> - {0x481f, 0x27},
> - {0x4837, 0x16},
> - {0x483c, 0x0f},
> - {0x484b, 0x05},
> - {0x5000, 0x57},
> - {0x5001, 0x0a},
> - {0x5004, 0x04},
> - {0x502e, 0x03},
> - {0x5030, 0x41},
> - {0x5780, 0x14},
> - {0x5781, 0x0f},
> - {0x5782, 0x44},
> - {0x5783, 0x02},
> - {0x5784, 0x01},
> - {0x5785, 0x01},
> - {0x5786, 0x00},
> - {0x5787, 0x04},
> - {0x5788, 0x02},
> - {0x5789, 0x0f},
> - {0x578a, 0xfd},
> - {0x578b, 0xf5},
> - {0x578c, 0xf5},
> - {0x578d, 0x03},
> - {0x578e, 0x08},
> - {0x578f, 

RE: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card controllers use fixed indices

2020-11-23 Thread Y.b. Lu
Hi Vladimir,

> -Original Message-
> From: Vladimir Oltean 
> Sent: Friday, November 20, 2020 5:30 PM
> To: Y.b. Lu 
> Cc: Shawn Guo ; Leo Li ; Rob
> Herring ; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; Adrian Hunter ; Ulf
> Hansson ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Ashish Kumar ;
> Michael Walle 
> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card
> controllers use fixed indices
> 
> On Fri, Nov 20, 2020 at 02:04:02AM +, Y.b. Lu wrote:
> > Hi Vladimir,
> >
> > I have already upstreamed a patch for all affected layerscape boards.
> >
> https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/commit/?
> h=imx/dt64=342ab37ecaf8c1b10dd3ca9a1271db29a6af0705
> >
> > Please check whether it works for you.
> 
> Thanks, one can tell that I haven't done my due diligence of checking
> Shawn's tree first. I'll cherry-pick that patch and carry on with my
> work.
> 
> However, the fact still remains that Michael has expressed his opinion
> regarding mmcblk0 vs mmcblk1. Do you think that we could make the
> aliases a per-board option instead of per-SoC? Consider that there might
> even be boards that only use SD card. It would be strange for the block
> device in that case to be called /dev/mmcblk1.

I don't think it's a problem in board dts to define board specific thing, like 
re-defining alias, and disabling any IP it not using.
Thanks.




Re: [PATCH] mm: memory_hotplug: put migration failure information under DEBUG_VM

2020-11-23 Thread Michal Hocko
On Mon 23-11-20 20:40:40, Charan Teja Kalla wrote:
> 
> Thanks Michal!
> On 11/23/2020 7:43 PM, Michal Hocko wrote:
> > On Mon 23-11-20 19:33:16, Charan Teja Reddy wrote:
> >> When the pages are failed to get isolate or migrate, the page owner
> >> information along with page info is dumped. If there are continuous
> >> failures in migration(say page is pinned) or isolation, the log buffer
> >> is simply getting flooded with the page owner information. As most of
> >> the times page info is sufficient to know the causes for failures of
> >> migration or isolation, place the page owner information under DEBUG_VM.
> > 
> > I do not see why this path is any different from others that call
> > dump_page. Page owner can add a very valuable information to debug
> > the underlying reasons for failures here. It is an opt-in debugging
> > feature which needs to be enabled explicitly. So I would argue users
> > are ready to accept a lot of data in the kernel log.
> 
> Just thinking how frequently failures can happen in those paths. In the
> memory hotplug path, we can flood the page owner logs just by making one
> page pinned.

If you are operating on a movable zone then pages shouldn't be pinned
for unbound amount of time. Yeah there are some ways to break this
fundamental assumption but this is a bigger problem that needs a
solution.

> Say If it is anonymous page, the page owner information
> shows is something like below, which is not really telling anything
> other than how the pinned page is allocated.

Well you can tell an anonymous page from __dump_page, all right, but
this is not true universally.

> page last allocated via order 0, migratetype Movable, gfp_mask
> 0x100dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO)
>   prep_new_page+0x7c/0x1a4
>   get_page_from_freelist+0x1ac/0x1c4
>   __alloc_pages_nodemask+0x12c/0x378
>   do_anonymous_page+0xac/0x3b4
>   handle_pte_fault+0x2a4/0x3bc
>   __handle_speculative_fault+0x208/0x3c0
>   do_page_fault+0x280/0x508
>   do_translation_fault+0x3c/0x54
>   do_mem_abort+0x64/0xf4
>   el0_da+0x1c/0x20
>  page last free stack trace:
>   free_pcp_prepare+0x320/0x454
>   free_unref_page_list+0x9c/0x2a4
>   release_pages+0x370/0x3c8
>   free_pages_and_swap_cache+0xdc/0x10c
>   tlb_flush_mmu+0x110/0x134
>   tlb_finish_mmu+0x48/0xc0
>   unmap_region+0x104/0x138
>   __do_munmap+0x2ec/0x3b4
>   __arm64_sys_munmap+0x80/0xd8
> 
> I see at some places in the kernel where they put the dump_page under
> DEBUG_VM, but in the end I agree that it is up to the users need. Then
> there are some users who don't care for these page owner logs.

Well, as I've said page_owner requires an explicit enabling and I would
expect that if somebody enables this tracking then it is expected to see
the information when we dump a page state.

> And an issue on Embedded systems with these continuous logs being
> printed to the console is the watchdog timeouts, because console logging
> happens by disabling the interrupts.

Are you enabling page_owner on those systems unconditionally?
-- 
Michal Hocko
SUSE Labs


Re: [RFC PATCH v1 2/4] KVM: arm64: GICv4.1: Try to save hw pending state in save_pending_tables

2020-11-23 Thread Shenming Lu
On 2020/11/23 17:18, Marc Zyngier wrote:
> On 2020-11-23 06:54, Shenming Lu wrote:
>> After pausing all vCPUs and devices capable of interrupting, in order
>     ^
> See my comment below about this.
> 
>> to save the information of all interrupts, besides flushing the pending
>> states in kvm’s vgic, we also try to flush the states of VLPIs in the
>> virtual pending tables into guest RAM, but we need to have GICv4.1 and
>> safely unmap the vPEs first.
>>
>> Signed-off-by: Shenming Lu 
>> ---
>>  arch/arm64/kvm/vgic/vgic-v3.c | 62 +++
>>  1 file changed, 56 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
>> index 9cdf39a94a63..e1b3aa4b2b12 100644
>> --- a/arch/arm64/kvm/vgic/vgic-v3.c
>> +++ b/arch/arm64/kvm/vgic/vgic-v3.c
>> @@ -1,6 +1,8 @@
>>  // SPDX-License-Identifier: GPL-2.0-only
>>
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -356,6 +358,39 @@ int vgic_v3_lpi_sync_pending_status(struct kvm
>> *kvm, struct vgic_irq *irq)
>>  return 0;
>>  }
>>
>> +/*
>> + * With GICv4.1, we can get the VLPI's pending state after unmapping
>> + * the vPE. The deactivation of the doorbell interrupt will trigger
>> + * the unmapping of the associated vPE.
>> + */
>> +static void get_vlpi_state_pre(struct vgic_dist *dist)
>> +{
>> +    struct irq_desc *desc;
>> +    int i;
>> +
>> +    if (!kvm_vgic_global_state.has_gicv4_1)
>> +    return;
>> +
>> +    for (i = 0; i < dist->its_vm.nr_vpes; i++) {
>> +    desc = irq_to_desc(dist->its_vm.vpes[i]->irq);
>> +    irq_domain_deactivate_irq(irq_desc_get_irq_data(desc));
>> +    }
>> +}
>> +
>> +static void get_vlpi_state_post(struct vgic_dist *dist)
> 
> nit: the naming feels a bit... odd. Pre/post what?

My understanding is that the unmapping is a preparation for get_vlpi_state...
Maybe just call it unmap/map_all_vpes?

> 
>> +{
>> +    struct irq_desc *desc;
>> +    int i;
>> +
>> +    if (!kvm_vgic_global_state.has_gicv4_1)
>> +    return;
>> +
>> +    for (i = 0; i < dist->its_vm.nr_vpes; i++) {
>> +    desc = irq_to_desc(dist->its_vm.vpes[i]->irq);
>> +    irq_domain_activate_irq(irq_desc_get_irq_data(desc), false);
>> +    }
>> +}
>> +
>>  /**
>>   * vgic_v3_save_pending_tables - Save the pending tables into guest RAM
>>   * kvm lock and all vcpu lock must be held
>> @@ -365,14 +400,17 @@ int vgic_v3_save_pending_tables(struct kvm *kvm)
>>  struct vgic_dist *dist = >arch.vgic;
>>  struct vgic_irq *irq;
>>  gpa_t last_ptr = ~(gpa_t)0;
>> -    int ret;
>> +    int ret = 0;
>>  u8 val;
>>
>> +    get_vlpi_state_pre(dist);
>> +
>>  list_for_each_entry(irq, >lpi_list_head, lpi_list) {
>>  int byte_offset, bit_nr;
>>  struct kvm_vcpu *vcpu;
>>  gpa_t pendbase, ptr;
>>  bool stored;
>> +    bool is_pending = irq->pending_latch;
>>
>>  vcpu = irq->target_vcpu;
>>  if (!vcpu)
>> @@ -387,24 +425,36 @@ int vgic_v3_save_pending_tables(struct kvm *kvm)
>>  if (ptr != last_ptr) {
>>  ret = kvm_read_guest_lock(kvm, ptr, , 1);
>>  if (ret)
>> -    return ret;
>> +    goto out;
>>  last_ptr = ptr;
>>  }
>>
>>  stored = val & (1U << bit_nr);
>> -    if (stored == irq->pending_latch)
>> +
>> +    /* also flush hw pending state */
> 
> This comment looks out of place, as we aren't flushing anything.

Ok, I will correct it.

> 
>> +    if (irq->hw) {
>> +    WARN_RATELIMIT(irq_get_irqchip_state(irq->host_irq,
>> +    IRQCHIP_STATE_PENDING, _pending),
>> +   "IRQ %d", irq->host_irq);
> 
> Isn't this going to warn like mad on a GICv4.0 system where this, by 
> definition,
> will generate an error?

As we have returned an error in save_its_tables if hw && !has_gicv4_1, we don't
have to warn this here?

> 
>> +    }
>> +
>> +    if (stored == is_pending)
>>  continue;
>>
>> -    if (irq->pending_latch)
>> +    if (is_pending)
>>  val |= 1 << bit_nr;
>>  else
>>  val &= ~(1 << bit_nr);
>>
>>  ret = kvm_write_guest_lock(kvm, ptr, , 1);
>>  if (ret)
>> -    return ret;
>> +    goto out;
>>  }
>> -    return 0;
>> +
>> +out:
>> +    get_vlpi_state_post(dist);
> 
> This bit worries me: you have unmapped the VPEs, so any interrupt that has 
> been
> generated during that phase is now forever lost (the GIC doesn't have 
> ownership
> of the pending tables).

In my opinion, during this phase, the devices capable of interrupting should 
have
already been paused (prevent from sending interrupts), such as VFIO migration 
protocol
has already realized it.

> 
> Do you really expect the VM to be restartable from that point? I don't see how
> this is possible.
> 

If the migration has encountered an error, the src VM 

Re: [RFC PATCH v1 1/4] irqchip/gic-v4.1: Plumb get_irqchip_state VLPI callback

2020-11-23 Thread Shenming Lu
On 2020/11/23 17:01, Marc Zyngier wrote:
> On 2020-11-23 06:54, Shenming Lu wrote:
>> From: Zenghui Yu 
>>
>> Up to now, the irq_get_irqchip_state() callback of its_irq_chip
>> leaves unimplemented since there is no architectural way to get
>> the VLPI's pending state before GICv4.1. Yeah, there has one in
>> v4.1 for VLPIs.
>>
>> With GICv4.1, after unmapping the vPE, which cleans and invalidates
>> any caching of the VPT, we can get the VLPI's pending state by
> 
> This is a crucial note: without this unmapping and invalidation,
> the pending bits are not generally accessible (they could be cached
> in a GIC private structure, cache or otherwise).
> 
>> peeking at the VPT. So we implement the irq_get_irqchip_state()
>> callback of its_irq_chip to do it.
>>
>> Signed-off-by: Zenghui Yu 
>> Signed-off-by: Shenming Lu 
>> ---
>>  drivers/irqchip/irq-gic-v3-its.c | 38 
>>  1 file changed, 38 insertions(+)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c 
>> b/drivers/irqchip/irq-gic-v3-its.c
>> index 0fec31931e11..287003cacac7 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -1695,6 +1695,43 @@ static void its_irq_compose_msi_msg(struct
>> irq_data *d, struct msi_msg *msg)
>>  iommu_dma_compose_msi_msg(irq_data_get_msi_desc(d), msg);
>>  }
>>
>> +static bool its_peek_vpt(struct its_vpe *vpe, irq_hw_number_t hwirq)
>> +{
>> +    int mask = hwirq % BITS_PER_BYTE;
> 
> nit: this isn't a mask, but a shift instead. BIT(hwirq % BPB) would give
> you a mask.

Ok, I will correct it.

> 
>> +    void *va;
>> +    u8 *pt;
>> +
>> +    va = page_address(vpe->vpt_page);
>> +    pt = va + hwirq / BITS_PER_BYTE;
>> +
>> +    return !!(*pt & (1U << mask));
>> +}
>> +
>> +static int its_irq_get_irqchip_state(struct irq_data *d,
>> + enum irqchip_irq_state which, bool *val)
>> +{
>> +    struct its_device *its_dev = irq_data_get_irq_chip_data(d);
>> +    struct its_vlpi_map *map = get_vlpi_map(d);
>> +
>> +    if (which != IRQCHIP_STATE_PENDING)
>> +    return -EINVAL;
>> +
>> +    /* not intended for physical LPI's pending state */
>> +    if (!map)
>> +    return -EINVAL;
>> +
>> +    /*
>> + * In GICv4.1, a VMAPP with {V,Alloc}=={0,1} cleans and invalidates
>> + * any caching of the VPT associated with the vPEID held in the GIC.
>> + */
>> +    if (!is_v4_1(its_dev->its) || atomic_read(>vpe->vmapp_count))
> 
> It isn't clear to me what prevents this from racing against a mapping of
> the VPE. Actually, since we only hold the LPI irqdesc lock, I'm pretty sure
> nothing prevents it.

Yes, should have the vmovp_lock held?
And is it necessary to also hold this lock in 
its_vpe_irq_domain_activate/deactivate?

> 
>> +    return -EACCES;
> 
> I can sort of buy EACCESS for a VPE that is currently mapped, but a non-4.1
> ITS should definitely return EINVAL.

Alright, EINVAL looks better.

> 
>> +
>> +    *val = its_peek_vpt(map->vpe, map->vintid);
>> +
>> +    return 0;
>> +}
>> +
>>  static int its_irq_set_irqchip_state(struct irq_data *d,
>>   enum irqchip_irq_state which,
>>   bool state)
>> @@ -1975,6 +2012,7 @@ static struct irq_chip its_irq_chip = {
>>  .irq_eoi    = irq_chip_eoi_parent,
>>  .irq_set_affinity    = its_set_affinity,
>>  .irq_compose_msi_msg    = its_irq_compose_msi_msg,
>> +    .irq_get_irqchip_state    = its_irq_get_irqchip_state,
> 
> My biggest issue with this is that it isn't a reliable interface.
> It happens to work in the context of KVM, because you make sure it
> is called at the right time, but that doesn't make it safe in general
> (anyone with the interrupt number is allowed to call this at any time).

We check the vmapp_count in it to ensure the unmapping of the vPE, and
let the caller do the unmapping (they should know whether it is the right
time). If the unmapping is not done, just return a failure.

> 
> Is there a problem with poking at the VPT page from the KVM side?
> The code should be exactly the same (maybe simpler even), and at least
> you'd be guaranteed to be in the correct context.

Yeah, that also seems a good choice.
If you prefer it, we can try to realize it in v2.

> 
>>  .irq_set_irqchip_state    = its_irq_set_irqchip_state,
>>  .irq_retrigger    = its_irq_retrigger,
>>  .irq_set_vcpu_affinity    = its_irq_set_vcpu_affinity,
> 
> Thanks,
> 
>     M.


[PATCH] ACPI: PM: Re-enable ACPI GPE if it's already enabled

2020-11-23 Thread Kai-Heng Feng
Dell Precision 5550 fails to detect Thunderbolt device hotplug events,
once the Thunderbolt device and its root port are runtime-suspended to
D3cold.

While putting the entire hierarchy to D3cold, the root port ACPI GPE is
enabled via acpi_pci_propagate_wakeup() when suspending Thunderbolt
bridges/switches. So when putting the root port to D3cold as last step,
ACPI GPE is untouched as it's already enabled.

However, platform may need PCI devices to be in D3hot or PME enabled
prior enabling GPE to make it work. So re-enable ACPI GPE to address
this.

Signed-off-by: Kai-Heng Feng 
---
 drivers/acpi/device_pm.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index 94d91c67aeae..dc25d9d204ae 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -757,11 +757,10 @@ static int __acpi_device_wakeup_enable(struct acpi_device 
*adev,
 
mutex_lock(_wakeup_lock);
 
-   if (wakeup->enable_count >= max_count)
-   goto out;
-
-   if (wakeup->enable_count > 0)
-   goto inc;
+   if (wakeup->enable_count > 0) {
+   acpi_disable_gpe(wakeup->gpe_device, wakeup->gpe_number);
+   acpi_disable_wakeup_device_power(adev);
+   }
 
error = acpi_enable_wakeup_device_power(adev, target_state);
if (error)
@@ -777,8 +776,8 @@ static int __acpi_device_wakeup_enable(struct acpi_device 
*adev,
acpi_handle_debug(adev->handle, "GPE%2X enabled for wakeup\n",
  (unsigned int)wakeup->gpe_number);
 
-inc:
-   wakeup->enable_count++;
+   if (wakeup->enable_count < max_count)
+   wakeup->enable_count++;
 
 out:
mutex_unlock(_wakeup_lock);
-- 
2.29.2



Re: [PATCH v7 2/5] dt-bindings: leds: Add LED_COLOR_ID_MOONLIGHT definitions

2020-11-23 Thread Gene Chen
Jacek Anaszewski  於 2020年11月24日 週二 上午4:52寫道:
>
> On 11/23/20 4:00 AM, Gene Chen wrote:
> > Jacek Anaszewski  於 2020年11月20日 週五 上午6:26寫道:
> >>
> >> On 11/19/20 10:57 PM, Pavel Machek wrote:
> >>> On Thu 2020-11-19 22:03:14, Jacek Anaszewski wrote:
>  Hi Pavel, Gene,
> 
>  On 11/18/20 10:37 PM, Pavel Machek wrote:
> > Hi!
> >
> >> From: Gene Chen 
> >>
> >> Add LED_COLOR_ID_MOONLIGHT definitions
> >
> > Why is moonlight a color? Camera flashes are usually white, no?
> >
> > At least it needs a comment...
> 
>  That's my fault, In fact I should have asked about adding
>  LED_FUNCTION_MOONLIGHT, it was evidently too late for me that evening...
> >>>
> >>> Aha, that makes more sense.
> >>>
> >>> But please let's call it "torch" if we do that, as that is already
> >>> used in kernel sources... and probably in the interface, too:
> >>
> >> I'd say that torch is something different that moonlight,
> >> but we would need more input from Gene to learn more about
> >> the nature of light emitted by ML LED on his device.
> >>
> >> Please note that torch is usually meant as the other mode of
> >> flash LED (sometimes it is called "movie mode"), which is already
> >> handled by brightness file of LED class flash device (i.e. its LED class
> >> subset), and which also maps to v4l2-flash TORCH mode.
> >>
> >
> > It's used to front camera fill light.
> > More brightness than screen backlight, and more soft light than flash.
> > I think LED_ID_COLOR_WHITE is okay.
>
> So why in v6 you assigned LED_COLOR_ID_AMBER to it?
>
> Regardless of that, now we're talking about LED function - you chose
> LED_FUNCTION_INDICATOR for it, but inferring from your above description
> - it certainly doesn't fit here.
>
> Also register names, containing part "ML" indicate that this LED's
> intended function is moonlinght, which your description somehow
> corroborates.
>
> Moonlight LEDs become ubiquitous nowadays so sooner or later we will
> need to add this function anyway [0].
>
> [0]
> https://landscapelightingoakville.com/what-is-moon-lighting-and-why-does-it-remain-so-popular/
>

We use term "Moonlight" as reference says
"When you are trying to imitate moonlight you need to use low voltage,
softer lighting. You don’t want something that’s too bright"
which is focus on brightness instead of color.

So we surpose Moonlight can be white or amber.

Should I add LED_FUNCTION_MOONLIGHT and set LED_COLOR_ID_WHITE?

> --
> Best regards,
> Jacek Anaszewski


[PATCH v2] soc: qcom: rpmh: Remove serialization of TCS commands

2020-11-23 Thread Maulik Shah
From: Lina Iyer 

Requests sent to RPMH can be sent as fire-n-forget or response required,
with the latter ensuring the command has been completed by the hardware
accelerator. Commands in a request with tcs_cmd::wait set, would ensure
that those select commands are sent as response required, even though
the actual TCS request may be fire-n-forget.

Also, commands with .wait flag were also guaranteed to be complete
before the following command in the TCS is sent. This means that the
next command of the same request blocked until the current request is
completed. This could mean waiting for a voltage to settle or series of
NOCs be configured before the next command is sent. But drivers using
this feature have never cared about the serialization aspect. By not
enforcing the serialization we can allow the hardware to run in parallel
improving the performance.

Let's clarify the usage of this member in the tcs_cmd structure to mean
only completion and not serialization. This should also improve the
performance of bus requests where changes could happen in parallel.
Also, CPU resume from deep idle may see benefits from certain wake
requests.

Signed-off-by: Lina Iyer 
Signed-off-by: Maulik Shah 
---
Changes in v2:
- Add SoB of self
- Fix typo in comment
- Update comment as Doug suggested
- Remove write to RSC_DRV_CMD_WAIT_FOR_CMPL in tcs_write() and tcs_invalidate()
---
 drivers/soc/qcom/rpmh-rsc.c | 25 ++---
 include/soc/qcom/tcs.h  |  3 ++-
 2 files changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
index 37969dc..9a06099 100644
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -231,10 +231,9 @@ static void tcs_invalidate(struct rsc_drv *drv, int type)
if (bitmap_empty(tcs->slots, MAX_TCS_SLOTS))
return;
 
-   for (m = tcs->offset; m < tcs->offset + tcs->num_tcs; m++) {
+   for (m = tcs->offset; m < tcs->offset + tcs->num_tcs; m++)
write_tcs_reg_sync(drv, RSC_DRV_CMD_ENABLE, m, 0);
-   write_tcs_reg_sync(drv, RSC_DRV_CMD_WAIT_FOR_CMPL, m, 0);
-   }
+
bitmap_zero(tcs->slots, MAX_TCS_SLOTS);
 }
 
@@ -423,8 +422,7 @@ static irqreturn_t tcs_tx_done(int irq, void *p)
cmd = >cmds[j];
sts = read_tcs_cmd(drv, RSC_DRV_CMD_STATUS, i, j);
if (!(sts & CMD_STATUS_ISSUED) ||
-  ((req->wait_for_compl || cmd->wait) &&
-  !(sts & CMD_STATUS_COMPL))) {
+  (cmd->wait && !(sts & CMD_STATUS_COMPL))) {
pr_err("Incomplete request: %s: addr=%#x 
data=%#x",
   drv->name, cmd->addr, cmd->data);
err = -EIO;
@@ -443,7 +441,6 @@ static irqreturn_t tcs_tx_done(int irq, void *p)
 skip:
/* Reclaim the TCS */
write_tcs_reg(drv, RSC_DRV_CMD_ENABLE, i, 0);
-   write_tcs_reg(drv, RSC_DRV_CMD_WAIT_FOR_CMPL, i, 0);
writel_relaxed(BIT(i), drv->tcs_base + RSC_DRV_IRQ_CLEAR);
spin_lock(>lock);
clear_bit(i, drv->tcs_in_use);
@@ -476,23 +473,23 @@ static irqreturn_t tcs_tx_done(int irq, void *p)
 static void __tcs_buffer_write(struct rsc_drv *drv, int tcs_id, int cmd_id,
   const struct tcs_request *msg)
 {
-   u32 msgid, cmd_msgid;
+   u32 msgid;
+   u32 cmd_msgid = CMD_MSGID_LEN | CMD_MSGID_WRITE;
u32 cmd_enable = 0;
-   u32 cmd_complete;
struct tcs_cmd *cmd;
int i, j;
 
-   cmd_msgid = CMD_MSGID_LEN;
+   /* Convert all commands to RR when the request has wait_for_compl set */
cmd_msgid |= msg->wait_for_compl ? CMD_MSGID_RESP_REQ : 0;
-   cmd_msgid |= CMD_MSGID_WRITE;
-
-   cmd_complete = read_tcs_reg(drv, RSC_DRV_CMD_WAIT_FOR_CMPL, tcs_id);
 
for (i = 0, j = cmd_id; i < msg->num_cmds; i++, j++) {
cmd = >cmds[i];
cmd_enable |= BIT(j);
-   cmd_complete |= cmd->wait << j;
msgid = cmd_msgid;
+   /*
+* Additionally, if the cmd->wait is set, make the command
+* response reqd even if the overall request was fire-n-forget.
+*/
msgid |= cmd->wait ? CMD_MSGID_RESP_REQ : 0;
 
write_tcs_cmd(drv, RSC_DRV_CMD_MSGID, tcs_id, j, msgid);
@@ -501,7 +498,6 @@ static void __tcs_buffer_write(struct rsc_drv *drv, int 
tcs_id, int cmd_id,
trace_rpmh_send_msg(drv, tcs_id, j, msgid, cmd);
}
 
-   write_tcs_reg(drv, RSC_DRV_CMD_WAIT_FOR_CMPL, tcs_id, cmd_complete);
cmd_enable |= read_tcs_reg(drv, RSC_DRV_CMD_ENABLE, tcs_id);
write_tcs_reg(drv, RSC_DRV_CMD_ENABLE, tcs_id, cmd_enable);
 }
@@ -652,7 +648,6 @@ int rpmh_rsc_send_data(struct rsc_drv *drv, const struct 
tcs_request 

[PATCH v2 2/2] scsi: ufs-qcom: Keep core_clk_unipro ON while link is active

2020-11-23 Thread Can Guo
If we want to disable clocks to save power but still keep the link active,
core_clk_unipro, as same as ref_clk, should not be the one being disabled.

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufs-qcom.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index f9d6ef3..70df357 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -977,6 +977,7 @@ static int ufs_qcom_init(struct ufs_hba *hba)
struct platform_device *pdev = to_platform_device(dev);
struct ufs_qcom_host *host;
struct resource *res;
+   struct ufs_clk_info *clki;
 
if (strlen(android_boot_dev) && strcmp(android_boot_dev, dev_name(dev)))
return -ENODEV;
@@ -1075,6 +1076,11 @@ static int ufs_qcom_init(struct ufs_hba *hba)
}
}
 
+   list_for_each_entry(clki, >clk_list_head, list) {
+   if (!strcmp(clki->name, "core_clk_unipro"))
+   clki->always_on_while_link_active = true;
+   }
+
err = ufs_qcom_init_lane_clks(host);
if (err)
goto out_variant_clear;
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.



RE: [EXTERNAL] Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken

2020-11-23 Thread Merger, Edgar [AUTOSOL/MAS/AUGS]
Module Version : PiccasoCpu 10 
AGESA Version   : PiccasoPI 100A

I did not try to enter the system in any other way (like via ssh) than via 
Desktop.

-Original Message-
From: Huang Rui  
Sent: Dienstag, 24. November 2020 07:43
To: Kuehling, Felix 
Cc: Will Deacon ; Deucher, Alexander 
; linux-kernel@vger.kernel.org; 
linux-...@vger.kernel.org; io...@lists.linux-foundation.org; Bjorn Helgaas 
; Merger, Edgar [AUTOSOL/MAS/AUGS] 
; Joerg Roedel ; Changfeng Zhu 

Subject: [EXTERNAL] Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken

On Tue, Nov 24, 2020 at 06:51:11AM +0800, Kuehling, Felix wrote:
> On 2020-11-23 5:33 p.m., Will Deacon wrote:
> > On Mon, Nov 23, 2020 at 09:04:14PM +, Deucher, Alexander wrote:
> >> [AMD Public Use]
> >>
> >>> -Original Message-
> >>> From: Will Deacon 
> >>> Sent: Monday, November 23, 2020 8:44 AM
> >>> To: linux-kernel@vger.kernel.org
> >>> Cc: linux-...@vger.kernel.org; io...@lists.linux-foundation.org; 
> >>> Will Deacon ; Bjorn Helgaas 
> >>> ; Deucher, Alexander 
> >>> ; Edgar Merger 
> >>> ; Joerg Roedel 
> >>> Subject: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken
> >>>
> >>> Edgar Merger reports that the AMD Raven GPU does not work reliably 
> >>> on his system when the IOMMU is enabled:
> >>>
> >>>| [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, 
> >>> signaled seq=1, emitted seq=3
> >>>| [...]
> >>>| amdgpu :0b:00.0: GPU reset begin!
> >>>| AMD-Vi: Completion-Wait loop timed out
> >>>| iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT
> >>> device=0b:00.0 address=0x38edc0970]
> >>>
> >>> This is indicative of a hardware/platform configuration issue so, 
> >>> since disabling ATS has been shown to resolve the problem, add a 
> >>> quirk to match this particular device while Edgar follows-up with AMD for 
> >>> more information.
> >>>
> >>> Cc: Bjorn Helgaas 
> >>> Cc: Alex Deucher 
> >>> Reported-by: Edgar Merger 
> >>> Suggested-by: Joerg Roedel 
> >>> Link:
> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lore=DwIDAw=jOURTkCZzT8tVB5xPEYIm3YJGoxoTaQsQPzPKJGaWbo=BJxhacqqa4K1PJGm6_-862rdSP13_P6LVp7j_9l1xmg=lNXu2xwvyxEZ3PzoVmXMBXXS55jsmfDicuQFJqkIOH4=_5VDNCRQdA7AhsvvZ3TJJtQZ2iBp9c9tFHIleTYT_ZM=
> >>>  .
> >>> kernel.org/linux-
> >>> iommu/MWHPR10MB1310F042A30661D4158520B589FC0@MWHPR10M
> >>> B1310.namprd10.prod.outlook.com
> >>> her%40amd.com%7C1a883fe14d0c408e7d9508d88fb5df4e%7C3dd8961fe488
> >>> 4e608e11a82d994e183d%7C0%7C0%7C637417358593629699%7CUnknown%7
> >>> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> >>> LCJXVCI6Mn0%3D%7C1000sdata=TMgKldWzsX8XZ0l7q3%2BszDWXQJJ
> >>> LOUfX5oGaoLN8n%2B8%3Dreserved=0
> >>> Signed-off-by: Will Deacon 
> >>> ---
> >>>
> >>> Hi all,
> >>>
> >>> Since Joerg is away at the moment, I'm posting this to try to make 
> >>> some progress with the thread in the Link: tag.
> >> + Felix
> >>
> >> What system is this?  Can you provide more details?  Does a sbios 
> >> update fix this?  Disabling ATS for all Ravens will break GPU 
> >> compute for a lot of people.  I'd prefer to just black list this 
> >> particular system (e.g., just SSIDs or revision) if possible.
> 
> +Ray
> 
> There are already many systems where the IOMMU is disabled in the 
> BIOS, or the CRAT table reporting the APU compute capabilities is 
> broken. Ray has been working on a fallback to make APUs behave like 
> dGPUs on such systems. That should also cover this case where ATS is 
> blacklisted. That said, it affects the programming model, because we 
> don't support the unified and coherent memory model on dGPUs like we 
> do on APUs with IOMMUv2. So it would be good to make the conditions 
> for this workaround as narrow as possible.

Yes, besides the comments from Alex and Felix, may we get your firmware version 
(SMC firmware which is from SBIOS) and device id?

> >>>| [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, 
> >>> signaled seq=1, emitted seq=3

It looks only gfx ib test passed, and fails to lanuch desktop, am I right?

We would like to see whether it is Raven, Raven kicker (new Raven), or Picasso. 
In our side, per the internal test result, we didn't see the similiar issue on 
Raven kicker and Picasso platform.

Thanks,
Ray

> 
> These are the relevant changes in KFD and Thunk for reference:
> 
> ### KFD ###
> 
> commit 914913ab04dfbcd0226ecb6bc99d276832ea2908
> Author: Huang Rui 
> Date:   Tue Aug 18 14:54:23 2020 +0800
> 
>      drm/amdkfd: implement the dGPU fallback path for apu (v6)
> 
>      We still have a few iommu issues which need to address, so force 
> raven
>      as "dgpu" path for the moment.
> 
>      This is to add the fallback path to bypass IOMMU if IOMMU v2 is 
> disabled
>      or ACPI CRAT table not correct.
> 
>      v2: Use ignore_crat parameter to decide whether it will go with 
> IOMMUv2.
>      v3: Align with existed thunk, don't change the way of raven, only 
> renoir
>      will use "dgpu" path by default.
>      

[PATCH v2 1/2] scsi: ufs: Refector ufshcd_setup_clocks() to remove skip_ref_clk

2020-11-23 Thread Can Guo
Remove the param skip_ref_clk from __ufshcd_setup_clocks(), but keep a flag
in struct ufs_clk_info to tell whether a clock can be disabled or not while
the link is active.

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufshcd-pltfrm.c |  2 ++
 drivers/scsi/ufs/ufshcd.c| 25 +
 drivers/scsi/ufs/ufshcd.h|  3 +++
 3 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index 3db0af6..39b1f9b 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -92,6 +92,8 @@ static int ufshcd_parse_clock_info(struct ufs_hba *hba)
clki->min_freq = clkfreq[i];
clki->max_freq = clkfreq[i+1];
clki->name = kstrdup(name, GFP_KERNEL);
+   if (!strcmp(name, "ref_clk"))
+   clki->always_on_while_link_active = true;
dev_dbg(dev, "%s: min %u max %u name %s\n", "freq-table-hz",
clki->min_freq, clki->max_freq, clki->name);
list_add_tail(>list, >clk_list_head);
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a7857f6..0802c10 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -221,8 +221,6 @@ static int ufshcd_eh_host_reset_handler(struct scsi_cmnd 
*cmd);
 static int ufshcd_clear_tm_cmd(struct ufs_hba *hba, int tag);
 static void ufshcd_hba_exit(struct ufs_hba *hba);
 static int ufshcd_probe_hba(struct ufs_hba *hba, bool async);
-static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
-bool skip_ref_clk);
 static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
 static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba);
 static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba);
@@ -1707,11 +1705,7 @@ static void ufshcd_gate_work(struct work_struct *work)
 
ufshcd_disable_irq(hba);
 
-   if (!ufshcd_is_link_active(hba))
-   ufshcd_setup_clocks(hba, false);
-   else
-   /* If link is active, device ref_clk can't be switched off */
-   __ufshcd_setup_clocks(hba, false, true);
+   ufshcd_setup_clocks(hba, false);
 
/*
 * In case you are here to cancel this work the gating state
@@ -7990,8 +7984,7 @@ static int ufshcd_init_hba_vreg(struct ufs_hba *hba)
return 0;
 }
 
-static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
-   bool skip_ref_clk)
+static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on)
 {
int ret = 0;
struct ufs_clk_info *clki;
@@ -8009,7 +8002,8 @@ static int __ufshcd_setup_clocks(struct ufs_hba *hba, 
bool on,
 
list_for_each_entry(clki, head, list) {
if (!IS_ERR_OR_NULL(clki->clk)) {
-   if (skip_ref_clk && !strcmp(clki->name, "ref_clk"))
+   if (ufshcd_is_link_active(hba) &&
+   clki->always_on_while_link_active)
continue;
 
clk_state_changed = on ^ clki->enabled;
@@ -8054,11 +8048,6 @@ static int __ufshcd_setup_clocks(struct ufs_hba *hba, 
bool on,
return ret;
 }
 
-static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on)
-{
-   return  __ufshcd_setup_clocks(hba, on, false);
-}
-
 static int ufshcd_init_clocks(struct ufs_hba *hba)
 {
int ret = 0;
@@ -8577,11 +8566,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
 */
ufshcd_disable_irq(hba);
 
-   if (!ufshcd_is_link_active(hba))
-   ufshcd_setup_clocks(hba, false);
-   else
-   /* If link is active, device ref_clk can't be switched off */
-   __ufshcd_setup_clocks(hba, false, true);
+   ufshcd_setup_clocks(hba, false);
 
if (ufshcd_is_clkgating_allowed(hba)) {
hba->clk_gating.state = CLKS_OFF;
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 66e5338..a06bdfb 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -229,6 +229,8 @@ struct ufs_dev_cmd {
  * @max_freq: maximum frequency supported by the clock
  * @min_freq: min frequency that can be used for clock scaling
  * @curr_freq: indicates the current frequency that it is set to
+ * @always_on_while_link_active: indicate that the clk should not be disabled 
if
+link is still active
  * @enabled: variable to check against multiple enable/disable
  */
 struct ufs_clk_info {
@@ -238,6 +240,7 @@ struct ufs_clk_info {
u32 max_freq;
u32 min_freq;
u32 curr_freq;
+   bool always_on_while_link_active;
bool enabled;
 };
 
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.



Re: [PATCH v4] checkpatch: add fix and improve warning msg for Non-standard signature

2020-11-23 Thread Joe Perches
On Tue, 2020-11-24 at 07:54 +0100, Lukas Bulwahn wrote:
> On Mon, Nov 23, 2020 at 6:33 PM Joe Perches  wrote:
[]
> Maybe a patch reduced to the very obvious synonyms helps newcomers or
> people with lousy memory to be reminded that it is called
> "Co-developed-by:" not "Co-authored-by".

I have no issue with proximity matching for nominally invalid uses.
I think the method used wasn't great though.
For trivial spelling defects, levenshtein might work well enough.





Re: [PATCH v9 1/2] kunit: Support for Parameterized Testing

2020-11-23 Thread David Gow
On Mon, Nov 23, 2020 at 9:08 PM Marco Elver  wrote:
>
> On Tue, 17 Nov 2020 at 08:21, David Gow  wrote:
> > On Mon, Nov 16, 2020 at 1:41 PM Arpitha Raghunandan <98.a...@gmail.com> 
> > wrote:
> > >
> > > Implementation of support for parameterized testing in KUnit. This
> > > approach requires the creation of a test case using the
> > > KUNIT_CASE_PARAM() macro that accepts a generator function as input.
> > >
> > > This generator function should return the next parameter given the
> > > previous parameter in parameterized tests. It also provides a macro to
> > > generate common-case generators based on arrays. Generators may also
> > > optionally provide a human-readable description of parameters, which is
> > > displayed where available.
> > >
> > > Note, currently the result of each parameter run is displayed in
> > > diagnostic lines, and only the overall test case output summarizes
> > > TAP-compliant success or failure of all parameter runs. In future, when
> > > supported by kunit-tool, these can be turned into subsubtest outputs.
> > >
> > > Signed-off-by: Arpitha Raghunandan <98.a...@gmail.com>
> > > Co-developed-by: Marco Elver 
> > > Signed-off-by: Marco Elver 
> > > ---
> > [Resending this because my email client re-defaulted to HTML! Aarrgh!]
> >
> > This looks good to me! I tested it in UML and x86-64 w/ KASAN, and
> > both worked fine.
> >
> > Reviewed-by: David Gow 
> > Tested-by: David Gow 
>
> Thank you!
>
> > Thanks for sticking with this!
>
> Will these patches be landing in 5.11 or 5.12?
>

I can't think of any reason not to have these in 5.11. We haven't
started staging things in the kselftest/kunit branch for 5.11 yet,
though.

Patch 2 will probably need to be acked by Ted for ext4 first.

Brendan, Shuah: can you make sure this doesn't get lost in patchwork?

Cheers,
-- David

> > -- David
>
> Thanks,
> -- Marco


Re: [PATCH v2] usb: musb: remove unused variable 'devctl'

2020-11-23 Thread Greg Kroah-Hartman
On Tue, Nov 24, 2020 at 02:36:13PM +0800, min@mediatek.com wrote:
> From: Min Guo 
> 
> Remove unused 'devctl' variable to fix compile warnings:
> 
> drivers/usb/musb/musbhsdma.c: In function 'dma_controller_irq':
> drivers/usb/musb/musbhsdma.c:324:8: warning: variable 'devctl' set
> but not used [-Wunused-but-set-variable]
> 
> Signed-off-by: Min Guo 
> ---
> changes in v2
> suggested by Alan Stern:
> Add void before musb_read to indicate that the register MUSB_DEVCTL
> was intended to be read and discarded.
> ---
>  drivers/usb/musb/musbhsdma.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
> index 0aacfc8be5a1..f59a009c533e 100644
> --- a/drivers/usb/musb/musbhsdma.c
> +++ b/drivers/usb/musb/musbhsdma.c
> @@ -321,8 +321,6 @@ irqreturn_t dma_controller_irq(int irq, void 
> *private_data)
>   musb_channel->channel.status =
>   MUSB_DMA_STATUS_BUS_ABORT;
>   } else {
> - u8 devctl;
> -
>   addr = musb_read_hsdma_addr(mbase,
>   bchannel);
>   channel->actual_len = addr
> @@ -336,7 +334,7 @@ irqreturn_t dma_controller_irq(int irq, void 
> *private_data)
>   < musb_channel->len) ?
>   "=> reconfig 0" : "=> complete");
>  
> - devctl = musb_readb(mbase, MUSB_DEVCTL);
> + (void)musb_readb(mbase, MUSB_DEVCTL);

Please put a comment here as to why the read is happening so that people
do not throw it away sometime in the future.

thanks,

greg k-h


Re: [PATCH 4.14 00/60] 4.14.209-rc1 review

2020-11-23 Thread Naresh Kamboju
On Mon, 23 Nov 2020 at 17:59, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.14.209 release.
> There are 60 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 25 Nov 2020 12:17:50 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.209-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 4.14.209-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: c3391de31d51a6a479f081994040a5fb99b29c9b
git describe: v4.14.208-61-gc3391de31d51
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.208-61-gc3391de31d51

No regressions (compared to build v4.14.208)

No fixes (compared to build v4.14.208)

Ran 41581 total tests in the following environments and test suites.

Environments
--
- arm
- arm64
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-kasan
- mips
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- sparc
- x15 - arm
- x86_64
- x86-kasan

Test Suites
---
* build
* igt-gpu-tools
* install-android-platform-tools-r2600
* linux-log-parser
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-dio-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* perf
* v4l2-compliance
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-mm-tests
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests

-- 
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH v3 0/5] Improve kernel section protections

2020-11-23 Thread Greentime Hu
Atish Patra  於 2020年11月5日 週四 上午8:05寫道:
>
> This series aims at improving kernel permissions by doing following things.
>
> 1. Protect kernel sections early instead of after /init.
> 2. Protect .init.text & .init.data sections with appropriate permissions.
> 3. Move dynamic relocation section to _init.
> 4. Moved .init sections after .text. This is what most of the other archs
>are also doing.
>
> After applying this patch, here are the linear mapped sections with non-uefi 
> boot.
>
> ---[ Linear mapping ]---
> 0xffe0-0xffe000800x8020 8M PMD
>  D A . . X . R V
> 0xffe00080-0xffe000c00x80a0 4M PMD
>  D A . . . W R V
> 0xffe000c0-0xffe001200x80e0 6M PMD
>  D A . . . . R V
> 0xffe00120-0xffe03fe00x8140  1004M PMD
>  D A . . . W R V
>
> Linear mapping with uefi boot.
>
> ---[ Linear mapping ]---
> 0xffe0-0xffe000800x8020 8M PTE
>  D A . . X . R V
> 0xffe00080-0xffe000c00x80a0 4M PTE
>  D A . . . W R V
> 0xffe000c0-0xffe001200x80e0 6M PTE
>  D A . . . . R V
> 0xffe00120-0xffe03e5340000x8140   1002704K PTE
>  D A . . . W R V
> 0xffe03e538000-0xffe03e5390000xbe738000 4K PTE
>  D A . . . W R V
> 0xffe03e53a000-0xffe03e53c0000xbe73a000 8K PTE
>  D A . . . W R V
> 0xffe03e54-0xffe03e5410000xbe74 4K PTE
>  D A . . . W R V
> 0xffe03e545000-0xffe03e5460000xbe745000 4K PTE
>  D A . . . W R V
> 0xffe03e549000-0xffe03e54a0000xbe749000 4K PTE
>  D A . . . W R V
> 0xffe03e54b000-0xffe03fd6d0000xbe74b000 24712K PTE
>  D A . . . W R V
> 0xffe03fd6e000-0xffe03fdee0000xbff6e000   512K PTE
>  D A . . . W R V
>
>
> Changes from v2->v3:
> 1. Added few extra comments to clarify rodata permissions.
> 2. Changed the name of the functions set_memory_default to set_memory_rw_nx.
> 3. Squashed patch 3&5 together as they depend on each other to allow
>bisectability.
> 4. Removed redundant arguments in protect_kernel_text_data.
>
> Changes from v1->v2:
> 1. .init.text section is aligned with SECTION_ALIGN.
> 2. .init.text is moved to below of .text so that .head.text & .text are in
>one section.
> 3. We don't need Guo's fix for static object issue.
> 4. Rebased on 5.10-rc1.
>
> Atish Patra (5):
> RISC-V: Move __start_kernel to .head.text
> RISC-V: Initialize SBI early
> RISC-V: Align the .init.text section
> RISC-V: Protect all kernel sections including init early
> RISC-V: Move dynamic relocation section under __init
>
> arch/riscv/include/asm/sections.h   |  2 +
> arch/riscv/include/asm/set_memory.h |  4 ++
> arch/riscv/kernel/head.S|  1 -
> arch/riscv/kernel/setup.c   | 19 +++--
> arch/riscv/kernel/vmlinux.lds.S | 63 +
> arch/riscv/mm/init.c| 21 +++---
> arch/riscv/mm/pageattr.c|  6 +++
> 7 files changed, 80 insertions(+), 36 deletions(-)
>

Test this series in v5.10-rc3 in Qemu and it works.
Tested-by: Greentime Hu 

Thank you. :)


Re: [PATCH net] ipv6: addrlabel: fix possible memory leak in ip6addrlbl_net_init

2020-11-23 Thread wanghai (M)



在 2020/11/24 9:22, Jakub Kicinski 写道:

On Sun, 22 Nov 2020 10:34:56 +0800 Wang Hai wrote:

kmemleak report a memory leak as follows:

unreferenced object 0x8880059c6a00 (size 64):
   comm "ip", pid 23696, jiffies 4296590183 (age 1755.384s)
   hex dump (first 32 bytes):
 20 01 00 10 00 00 00 00 00 00 00 00 00 00 00 00   ...
 1c 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00  
   backtrace:
 [] ip6addrlbl_add+0x90/0xbb0
 [<70b8d7f1>] ip6addrlbl_net_init+0x109/0x170
 [<6a9ca9d4>] ops_init+0xa8/0x3c0
 [<2da57bf2>] setup_net+0x2de/0x7e0
 [<4e52d573>] copy_net_ns+0x27d/0x530
 [] create_new_namespaces+0x382/0xa30
 [<3b76d36f>] unshare_nsproxy_namespaces+0xa1/0x1d0
 [<30653721>] ksys_unshare+0x3a4/0x780
 [<07e82e40>] __x64_sys_unshare+0x2d/0x40
 [<31a10c08>] do_syscall_64+0x33/0x40
 [<99df30e7>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

We should free all rules when we catch an error in ip6addrlbl_net_init().
otherwise a memory leak will occur.

Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address 
selection policy table.")
Reported-by: Hulk Robot 
Signed-off-by: Wang Hai 

We can simplify this function.


diff --git a/net/ipv6/addrlabel.c b/net/ipv6/addrlabel.c
index 642fc6ac13d2..637e323a0224 100644
--- a/net/ipv6/addrlabel.c
+++ b/net/ipv6/addrlabel.c
@@ -306,6 +306,8 @@ static int ip6addrlbl_del(struct net *net,
  /* add default label */
  static int __net_init ip6addrlbl_net_init(struct net *net)
  {
+   struct ip6addrlbl_entry *p = NULL;
+   struct hlist_node *n;
int err = 0;

err does not need init


int i;
  
@@ -320,9 +322,17 @@ static int __net_init ip6addrlbl_net_init(struct net *net)

instead of the temporary ret variable we can assign directly to err


 ip6addrlbl_init_table[i].prefixlen,
 0,
 ip6addrlbl_init_table[i].label, 0);
-   /* XXX: should we free all rules when we catch an error? */
-   if (ret && (!err || err != -ENOMEM))
+   if (ret && (!err || err != -ENOMEM)) {

this will become if (err)


err = ret;
+   goto err_ip6addrlbl_add;
+   }
+   }
+   return err;

return 0;


+err_ip6addrlbl_add:
+   hlist_for_each_entry_safe(p, n, >ipv6.ip6addrlbl_table.head, list) 
{
+   hlist_del_rcu(>list);
+   kfree_rcu(p, rcu);
}
return err;
  }


Thanks for advice. I just sent a v2

“[PATCH net v2] ipv6: addrlabel: fix possible memory leak in 
ip6addrlbl_net_init”



.



Re: [PATCH v2] brmcfmac: fix compile when DEBUG is defined

2020-11-23 Thread Kalle Valo
hby  writes:

> I am sorry for the HTML email, and I change the email client. The
> patch update.
>
> From b87d429158b4efc3f6835828f495a261e17d5af4 Mon Sep 17 00:00:00 2001
> From: hby 
> Date: Tue, 24 Nov 2020 09:16:24 +0800
> Subject: [PATCH] brmcfmac: fix compile when DEBUG is defined
>
> The steps:
> 1. add "#define DEBUG" in
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c line 61.
> 2. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=../Out_Linux
> bcm2835_defconfig
> 3. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=../Out_Linux/
> zImage modules dtbs -j8
>
> Then, it will fail, the compile log described below:

It doesn't work like this, the patch handling is very much automated and
you can't just reply with a new patch. I strongly recommend to use git
send-email and read the wiki page below.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


linux-next: Signed-off-by missing for commit in the qcom tree

2020-11-23 Thread Stephen Rothwell
Hi all,

Commit

  872b41c9a255 ("arm64: dts: qcom: sort sm8150 usb_2 node")

is missing a Signed-off-by from its author.

-- 
Cheers,
Stephen Rothwell


pgpVPDd2LEUBo.pgp
Description: OpenPGP digital signature


[PATCH net v2] ipv6: addrlabel: fix possible memory leak in ip6addrlbl_net_init

2020-11-23 Thread Wang Hai
kmemleak report a memory leak as follows:

unreferenced object 0x8880059c6a00 (size 64):
  comm "ip", pid 23696, jiffies 4296590183 (age 1755.384s)
  hex dump (first 32 bytes):
20 01 00 10 00 00 00 00 00 00 00 00 00 00 00 00   ...
1c 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00  
  backtrace:
[] ip6addrlbl_add+0x90/0xbb0
[<70b8d7f1>] ip6addrlbl_net_init+0x109/0x170
[<6a9ca9d4>] ops_init+0xa8/0x3c0
[<2da57bf2>] setup_net+0x2de/0x7e0
[<4e52d573>] copy_net_ns+0x27d/0x530
[] create_new_namespaces+0x382/0xa30
[<3b76d36f>] unshare_nsproxy_namespaces+0xa1/0x1d0
[<30653721>] ksys_unshare+0x3a4/0x780
[<07e82e40>] __x64_sys_unshare+0x2d/0x40
[<31a10c08>] do_syscall_64+0x33/0x40
[<99df30e7>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

We should free all rules when we catch an error in ip6addrlbl_net_init().
otherwise a memory leak will occur.

Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address 
selection policy table.")
Reported-by: Hulk Robot 
Signed-off-by: Wang Hai 
---
v1->v2: simplify this function
 net/ipv6/addrlabel.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/net/ipv6/addrlabel.c b/net/ipv6/addrlabel.c
index 642fc6ac13d2..8a22486cf270 100644
--- a/net/ipv6/addrlabel.c
+++ b/net/ipv6/addrlabel.c
@@ -306,7 +306,9 @@ static int ip6addrlbl_del(struct net *net,
 /* add default label */
 static int __net_init ip6addrlbl_net_init(struct net *net)
 {
-   int err = 0;
+   struct ip6addrlbl_entry *p = NULL;
+   struct hlist_node *n;
+   int err;
int i;
 
ADDRLABEL(KERN_DEBUG "%s\n", __func__);
@@ -315,14 +317,20 @@ static int __net_init ip6addrlbl_net_init(struct net *net)
INIT_HLIST_HEAD(>ipv6.ip6addrlbl_table.head);
 
for (i = 0; i < ARRAY_SIZE(ip6addrlbl_init_table); i++) {
-   int ret = ip6addrlbl_add(net,
-ip6addrlbl_init_table[i].prefix,
-ip6addrlbl_init_table[i].prefixlen,
-0,
-ip6addrlbl_init_table[i].label, 0);
-   /* XXX: should we free all rules when we catch an error? */
-   if (ret && (!err || err != -ENOMEM))
-   err = ret;
+   err = ip6addrlbl_add(net,
+ip6addrlbl_init_table[i].prefix,
+ip6addrlbl_init_table[i].prefixlen,
+0,
+ip6addrlbl_init_table[i].label, 0);
+   if (err)
+   goto err_ip6addrlbl_add;
+   }
+   return 0;
+
+err_ip6addrlbl_add:
+   hlist_for_each_entry_safe(p, n, >ipv6.ip6addrlbl_table.head, list) 
{
+   hlist_del_rcu(>list);
+   kfree_rcu(p, rcu);
}
return err;
 }
-- 
2.17.1



arch/powerpc/platforms/pseries/reconfig.c:394:30: error: 'ofdt_proc_ops' defined but not used

2020-11-23 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   d5beb3140f91b1c8a3d41b14d729aefa4dcc58bc
commit: 97a32539b9568bb653683349e5a76d02ff3c3e2c proc: convert everything to 
"struct proc_ops"
date:   10 months ago
config: powerpc-randconfig-r002-20201124 (attached as .config)
compiler: powerpc64le-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97a32539b9568bb653683349e5a76d02ff3c3e2c
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 97a32539b9568bb653683349e5a76d02ff3c3e2c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> arch/powerpc/platforms/pseries/reconfig.c:394:30: error: 'ofdt_proc_ops' 
>> defined but not used [-Werror=unused-const-variable=]
 394 | static const struct proc_ops ofdt_proc_ops = {
 |  ^
   cc1: all warnings being treated as errors
--
>> arch/powerpc/platforms/pseries/lparcfg.c:701:30: error: 'lparcfg_proc_ops' 
>> defined but not used [-Werror=unused-const-variable=]
 701 | static const struct proc_ops lparcfg_proc_ops = {
 |  ^~~~
   cc1: all warnings being treated as errors

vim +/ofdt_proc_ops +394 arch/powerpc/platforms/pseries/reconfig.c

   393  
 > 394  static const struct proc_ops ofdt_proc_ops = {
   395  .proc_write = ofdt_write,
   396  .proc_lseek = noop_llseek,
   397  };
   398  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip


linux-next: Tree for Nov 24

2020-11-23 Thread Stephen Rothwell
Hi all,

Changes since 20201123:

Linus' tree lost its build failure (or will shortly - fix in
powerpc-fixes).

The arm-soc tree gained a build failure so I used the version from
next-20201123.

The s390 tree gained a conflict against the asm-generic tree.

Non-merge commits (relative to Linus' tree): 7005
 6992 files changed, 593176 insertions(+), 117054 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 327 trees (counting Linus' and 85 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (418baf2c28f3 Linux 5.10-rc5)
Merging fixes/fixes (418baf2c28f3 Linux 5.10-rc5)
Merging kbuild-current/fixes (d1889589a4f5 builddeb: Fix rootless build in 
setuid/setgid directory)
Merging arc-current/for-curr (f737561c7096 ARC: stack unwinding: reorganize how 
initial register state setup)
Merging arm-current/fixes (9fa2e7af3d53 ARM: 9019/1: kprobes: Avoid 
fortify_panic() when copying optprobe template)
Merging arm64-fixes/for-next/fixes (774c4a3b5e5f ACPI/IORT: Fix doc warnings in 
iort.c)
Merging arm-soc-fixes/arm/fixes (4765df4d3a13 Merge tag 
'v5.10-rockchip-dtsfixes1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into 
arm/fixes)
Merging drivers-memory-fixes/fixes (3650b228f83a Linux 5.10-rc1)
Merging m68k-current/for-linus (50c5feeea0af ide/macide: Convert Mac IDE driver 
to platform driver)
Merging powerpc-fixes/fixes (b6b79dd53082 powerpc/64s: Fix allnoconfig build 
since uaccess flush)
Merging s390-fixes/fixes (1179f170b6f0 s390: fix fpu restore in entry.S)
Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro)
Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption 
not used on new files)
Merging net/master (f9b036532108 Merge branch 'ibmvnic-fixes-in-reset-path')
Merging bpf/master (178648916e73 xsk: Fix incorrect netdev reference count)
Merging ipsec/master (48f486e13ffd net: xfrm: fix memory leak in 
xfrm_user_policy())
Merging netfilter/master (986fbd9842ba netfilter: nf_tables: avoid 
false-postive lockdep splat)
Merging ipvs/master (986fbd9842ba netfilter: nf_tables: avoid false-postive 
lockdep splat)
Merging wireless-drivers/master (fe56d05ee6c8 iwlwifi: mvm: fix kernel panic in 
case of assert during CSA)
Merging mac80211/master (849920c70339 devlink: Add missing genlmsg_cancel() in 
devlink_nl_sb_port_pool_fill())
Merging rdma-fixes/for-rc (418baf2c28f3 Linux 5.10-rc5)
Merging sound-current/for-linus (92666d45adcf ALSA: hda/realtek - Fixed Dell 
AIO wrong sound tone)
Merging sound-asoc-fixes/for-linus (8f05568156ea Merge remote-tracking branch 
'asoc/for-5.10' into asoc-linus)
Merging regmap-fixes/for-linus (3650b228f83a Linux 5.10-rc1)
Merging regulator-fixes/for-linus (2ba546ebe0ce regulator: ti-abb: Fix array 
out of bound read access on the first transition)
Merging spi-fixes/for-linus (03cfdb8444c0 Merge remote-tracking branch 
'spi/for-5.10' into spi-linus)
Merging pci-current/for-linus (cce14622a703 PCI: Add function 1 DMA alias quirk 
for Marvell 9215 SATA controller)
Merging driver-core.current/driver-core-linus (f8394f232b1e Linux 5.10-rc3)
Merging tty.current/tty-linus (418baf2c28f3 Linux 5.10-rc5)
Merging usb.current/usb-linus (f3bc432aa8a7 USB: core: Change %pK for __user 
pointers to %px

Re: [PATCH 1/3] irqchip: qcom-pdc: Fix phantom irq when changing between rising/falling

2020-11-23 Thread Maulik Shah

Hi Doug,

Thanks for the patch. Looks good to me and tested.

Reviewed-by: Maulik Shah 
Tested-by: Maulik Shah 

Thanks,
Maulik

On 11/24/2020 5:31 AM, Douglas Anderson wrote:

We have a problem if we use gpio-keys and configure wakeups such that
we only want one edge to wake us up.  AKA:
   wakeup-event-action = ;
   wakeup-source;

Specifically we end up with a phantom interrupt that blocks suspend if
the line was already high and we want wakeups on rising edges (AKA we
want the GPIO to go low and then high again before we wake up).  The
opposite is also problematic.

Specifically, here's what's happening today:
1. Normally, gpio-keys configures to look for both edges.  Due to the
current workaround introduced in commit c3c0c2e18d94 ("pinctrl:
qcom: Handle broken/missing PDC dual edge IRQs on sc7180"), if the
line was high we'd configure for falling edges.
2. At suspend time, we change to look for rising edges.
3. After qcom_pdc_gic_set_type() runs, we get a phantom interrupt.

We can solve this by just clearing the phantom interrupt.

NOTE: it is possible that this could cause problems for a client with
very specific needs, but there's not much we can do with this
hardware.  As an example, let's say the interrupt signal is currently
high and the client is looking for falling edges.  The client now
changes to look for rising edges.  The client could possibly expect
that if the line has a short pulse low (and back high) that it would
always be detected.  Specifically no matter when the pulse happened,
it should either have tripped the (old) falling edge trigger or the
(new) rising edge trigger.  We will simply not trip it.  We could
narrow down the race a bit by polling our parent before changing
types, but no matter what we do there will still be a period of time
where we can't tell the difference between a real transition (or more
than one transition) and the phantom.

Signed-off-by: Douglas Anderson 
---

  drivers/irqchip/qcom-pdc.c | 19 ++-
  1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
index bd39e9de6ecf..7d097164aadc 100644
--- a/drivers/irqchip/qcom-pdc.c
+++ b/drivers/irqchip/qcom-pdc.c
@@ -159,6 +159,8 @@ static int qcom_pdc_gic_set_type(struct irq_data *d, 
unsigned int type)
  {
int pin_out = d->hwirq;
enum pdc_irq_config_bits pdc_type;
+   enum pdc_irq_config_bits old_pdc_type;
+   int ret;
  
  	if (pin_out == GPIO_NO_WAKE_IRQ)

return 0;
@@ -187,9 +189,24 @@ static int qcom_pdc_gic_set_type(struct irq_data *d, 
unsigned int type)
return -EINVAL;
}
  
+	old_pdc_type = pdc_reg_read(IRQ_i_CFG, pin_out);

pdc_reg_write(IRQ_i_CFG, pin_out, pdc_type);
  
-	return irq_chip_set_type_parent(d, type);

+   ret = irq_chip_set_type_parent(d, type);
+
+   /*
+* When we change types the PDC can give a phantom interrupt.
+* Clear it.  Specifically the phantom shows up if a line is already
+* high and we change to rising or if a line is already low and we
+* change to falling but let's be consistent and clear it always.
+*
+* Doing this works because we have IRQCHIP_SET_TYPE_MASKED so the
+* interrupt will be cleared before the rest of the system sees it.
+*/
+   if (old_pdc_type != pdc_type)
+   irq_chip_set_parent_state(d, IRQCHIP_STATE_PENDING, 0);
+
+   return ret;
  }
  
  static struct irq_chip qcom_pdc_gic_chip = {


--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



Re: [RFC PATCH v5] sched/fair: select idle cpu from idle cpumask for task wakeup

2020-11-23 Thread Li, Aubrey
Hi Vincent,

On 2020/11/23 17:27, Vincent Guittot wrote:
> Hi Aubrey,
> 
> On Thu, 19 Nov 2020 at 13:15, Aubrey Li  wrote:
>>
>> Add idle cpumask to track idle cpus in sched domain. When a CPU
>> enters idle, if the idle driver indicates to stop tick, this CPU
>> is set in the idle cpumask to be a wakeup target. And if the CPU
>> is not in idle, the CPU is cleared in idle cpumask during scheduler
>> tick to ratelimit idle cpumask update.
>>
>> When a task wakes up to select an idle cpu, scanning idle cpumask
>> has low cost than scanning all the cpus in last level cache domain,
>> especially when the system is heavily loaded.
>>
>> Benchmarks were tested on a x86 4 socket system with 24 cores per
>> socket and 2 hyperthreads per core, total 192 CPUs. Hackbench and
>> schbench have no notable change, uperf has:
>>
>> uperf throughput: netperf workload, tcp_nodelay, r/w size = 90
>>
>>   threads   baseline-avg%stdpatch-avg   %std
>>   961   0.831.233.27
>>   144   1   1.031.672.67
>>   192   1   0.691.813.59
>>   240   1   2.841.512.67
>>
>> v4->v5:
>> - add update_idle_cpumask for s2idle case
>> - keep the same ordering of tick_nohz_idle_stop_tick() and update_
>>   idle_cpumask() everywhere
>>
>> v3->v4:
>> - change setting idle cpumask from every idle entry to tickless idle
>>   if cpu driver is available.
> 
> Could you remind me why you did this change ? Clearing the cpumask is
> done during the tick to rate limit the number of updates of the
> cpumask but It's not clear for me why you have associated the set with
> the tick stop condition too.

I found the current implementation has better performance at a more 
suitable load range.

The two kinds of implementions(v4 and v5) have the same rate(scheduler
tick) to shrink idle cpumask when the system is busy, but

- Setting the idle mask everytime the cpu enters idle requires a much
heavier load level to preserve the idle cpumask(not call into idle),
otherwise the bits cleared in scheduler tick will be restored when the
cpu enters idle. That is, idle cpumask is almost equal to the domain
cpumask during task wakeup if the system load is not heavy enough.

- Associating with tick stop tolerates idle to preserve the idle cpumask
but only short idle, which causes tick retains. This is more fitable for
the real workload.

> 
> This change means that a cpu will not be part of the idle mask if the
> tick is not stopped. On some arm/arm64 platforms, the tick stops only
> if the idle duration is expected to be higher than 1-2ms which starts
> to be significantly long. Also, the cpuidle governor can easily
> mis-predict a short idle duration whereas it will be finally a long
> idle duration; In this case, the next tick will correct the situation
> and select a deeper state, but this can happen up to 4ms later on
> arm/arm64.

Yes this is intented. If the tick is not stopped, that indicates the
CPU is very busy, cpu idle governor selected the polling idle state, and/or 
the expected idle duration is shorter than the tick period length. For
example, uperf enters and exits 80 times between two ticks when utilizes
100% CPU, and the average idle residency < 50us.

If this CPU is added to idle cpumask, the wakeup task likely needs to 
wait in the runqueue as this CPU will run its current task very soon.

> 
> So I would prefer to keep trying to set the idle mask everytime the
> cpu enters idle. If a tick has not happened between 2 idle phases, the
> cpumask will not be updated and the overhead will be mostly testing if
> (rq->last_idle_state == idle_state).

Not sure if I addressed your concern, did you see any workloads any cases
v4 performs better than v5?

Thanks,
-Aubrey

> 
> 
>> - move clearing idle cpumask to scheduler_tick to decouple nohz mode.
>>
>> v2->v3:
>> - change setting idle cpumask to every idle entry, otherwise schbench
>>   has a regression of 99th percentile latency.
>> - change clearing idle cpumask to nohz_balancer_kick(), so updating
>>   idle cpumask is ratelimited in the idle exiting path.
>> - set SCHED_IDLE cpu in idle cpumask to allow it as a wakeup target.
>>
>> v1->v2:
>> - idle cpumask is updated in the nohz routines, by initializing idle
>>   cpumask with sched_domain_span(sd), nohz=off case remains the original
>>   behavior.
>>


[PATCH] drivers/pcmcia: Fix error return code in electra_cf_probe()

2020-11-23 Thread Wei Li
When it fails to call of_get_property(), it just jumps to 'fail1',
while the 'status' which will be returned is not updated.

Fixes: 2b571a066a2f ("pcmcia: CompactFlash driver for PA Semi Electra boards")
Signed-off-by: Wei Li 
---
 drivers/pcmcia/electra_cf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pcmcia/electra_cf.c b/drivers/pcmcia/electra_cf.c
index 35158cfd9c1a..0570758e3fa8 100644
--- a/drivers/pcmcia/electra_cf.c
+++ b/drivers/pcmcia/electra_cf.c
@@ -228,6 +228,7 @@ static int electra_cf_probe(struct platform_device *ofdev)
}
 
cf->socket.pci_irq = cf->irq;
+   status = -ENODEV;
 
prop = of_get_property(np, "card-detect-gpio", NULL);
if (!prop)
-- 
2.17.1



RE: [PATCH v2] uio/uio_pci_generic: remove unneeded pci_set_drvdata()

2020-11-23 Thread Ardelean, Alexandru



> -Original Message-
> From: Alexandru Ardelean 
> Sent: Monday, November 23, 2020 4:35 PM
> To: linux-kernel@vger.kernel.org; k...@vger.kernel.org
> Cc: m...@redhat.com; gre...@linuxfoundation.org; Ardelean, Alexandru
> 
> Subject: [PATCH v2] uio/uio_pci_generic: remove unneeded pci_set_drvdata()
> 
> The pci_get_drvdata() was moved during commit ef84928cff58
> ("uio/uio_pci_generic: use device-managed function equivalents").
> 
> Storing a private object with pci_set_drvdata() doesn't make sense since that
> change, since there is no more pci_get_drvdata() call in the driver to 
> retrieve the
> information.
> 
> This change removes it.
> 
> Fixes: ef84928cff58 ("io/uio_pci_generic: use device-managed function
> equivalents")
> Signed-off-by: Alexandru Ardelean 
> ---

Forgot the changelog
Apologies.

Changelog v1 -> v2:
* added Fixes tag
* updated commit comment a bit from V1

>  drivers/uio/uio_pci_generic.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/uio/uio_pci_generic.c b/drivers/uio/uio_pci_generic.c 
> index
> 1c6c09e1280d..b8e44d16279f 100644
> --- a/drivers/uio/uio_pci_generic.c
> +++ b/drivers/uio/uio_pci_generic.c
> @@ -101,13 +101,7 @@ static int probe(struct pci_dev *pdev,
>"no support for interrupts?\n");
>   }
> 
> - err = devm_uio_register_device(>dev, >info);
> - if (err)
> - return err;
> -
> - pci_set_drvdata(pdev, gdev);
> -
> - return 0;
> + return devm_uio_register_device(>dev, >info);
>  }
> 
>  static struct pci_driver uio_pci_driver = {
> --
> 2.17.1



Re: [PATCH v4] checkpatch: add fix and improve warning msg for Non-standard signature

2020-11-23 Thread Lukas Bulwahn
On Mon, Nov 23, 2020 at 6:33 PM Joe Perches  wrote:
>
> On Mon, 2020-11-23 at 22:54 +0530, Aditya Srivastava wrote:
> > Currently, checkpatch.pl warns for BAD_SIGN_OFF on non-standard signature
> > styles.
>
> I think this proposed change is unnecessary.
>
> > This warning occurs because of incorrect use of signature tags,
> > e.g. an evaluation on v4.13..v5.8 showed the use of following incorrect
> > signature tags, which may seem correct, but are not standard:
>
> Standards are useful, but standards are not constraints.
>

Agree, but we do try to create statistics and try to derive quality
statements from those tags (yes, empirical software engineering black
magic...).
Hence, I am in favor of suggesting to rewrite those tags that really
do not add anything at all. E.g., Suggestions-by: vs. Suggested-by, or
Coauthored-by vs. Co-developed-by.

Anyone can ignore checkpatch; so it is not a constraint unless
enforced by subsystem maintainers.

> > 1) Requested-by (count: 48) => Suggested-by
> > Rationale: In an open-source project, there are no 'requests', just
> > 'suggestions' to convince a maintainer to accept your patch
>
> There's nothing really wrong with some non-standard signatures.
> And I think leaving humor like brown-paper-bag-by: is useful.
>

I think we do not want to take the humor and fun away from patches.

So let us not suggest deleting the humorous and celebrating ones.

> Just telling people that they are using a non-standard signature
> I think is enough.
>

Maybe a patch reduced to the very obvious synonyms helps newcomers or
people with lousy memory to be reminded that it is called
"Co-developed-by:" not "Co-authored-by".

Lukas


Re: [PATCH 4.19 00/91] 4.19.160-rc1 review

2020-11-23 Thread Naresh Kamboju
On Mon, 23 Nov 2020 at 17:59, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.19.160 release.
> There are 91 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 25 Nov 2020 12:17:50 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.160-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 4.19.160-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: 6f94b70fe8f995a6d337b163e35735f9dc957ef7
git describe: v4.19.159-92-g6f94b70fe8f9
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.159-92-g6f94b70fe8f9

No regressions (compared to build v4.19.159)

No fixes (compared to build v4.19.159)


Ran 44060 total tests in the following environments and test suites.

Environments
--
- arm
- arm64
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- mips
- nxp-ls2088
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- s390
- sparc
- x15 - arm
- x86_64
- x86-kasan

Test Suites
---
* build
* igt-gpu-tools
* install-android-platform-tools-r2600
* libhugetlbfs
* linux-log-parser
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-io-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* perf
* v4l2-compliance
* ltp-commands-tests
* ltp-fs-tests
* ltp-hugetlb-tests
* ltp-math-tests
* ltp-mm-tests
* network-basic-tests
* kselftest
* ltp-cap_bounds-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-ipc-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH v2 00/19] Add generic vdso_base tracking

2020-11-23 Thread Christophe Leroy




Le 24/11/2020 à 01:29, Dmitry Safonov a écrit :

v2 Changes:
- Rename user_landing to vdso_base as it tracks vDSO VMA start address,
   rather than the explicit address to land (Andy)
- Reword and don't use "new-execed" and "new-born" task (Andy)
- Fix failures reported by build robot

Started from discussion [1], where was noted that currently a couple of
architectures support mremap() for vdso/sigpage, but not munmap().
If an application maps something on the ex-place of vdso/sigpage,
later after processing signal it will land there (good luck!)

Patches set is based on linux-next (next-20201123) and it depends on
changes in x86/cleanups (those reclaim TIF_IA32/TIF_X32) and also
on my changes in akpm (fixing several mremap() issues).


I have a series that cleans up VDSO init on powerpc and migrates powerpc to 
_install_special_mapping() (patch 10 of the series).


https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=204396=%2A=both

I'm wondering how we should coordinate with your series for merging.

I guess your series will also imply removal of arch_unmap() ? see 
https://elixir.bootlin.com/linux/v5.10-rc4/source/arch/powerpc/include/asm/mmu_context.h#L262




Logically, the patches set divides on:
- patch   1: a cleanup for patches in x86/cleanups
- patches  2-11: cleanups for arch_setup_additional_pages()
- patches 12-13: x86 signal changes for unmapped vdso
- patches 14-19: provide generic vdso_base in mm_struct

In the end, besides cleanups, it's now more predictable what happens for
applications with unmapped vdso on architectures those support .mremap()
for vdso/sigpage.

I'm aware of only one user that unmaps vdso - Valgrind [2].
(there possibly are more, but this one is "special", it unmaps vdso, but
  not vvar, which confuses CRIU [Checkpoint Restore In Userspace], that's
  why I'm aware of it)

Patches as a .git branch:
https://github.com/0x7f454c46/linux/tree/setup_additional_pages-v2

v1 Link:
https://lore.kernel.org/lkml/20201108051730.2042693-1-d...@arista.com/

[1]: 
https://lore.kernel.org/linux-arch/cajwjo6zanqykshbq+3b+fi_vt80mtrzev5yreqawx-l8j8x...@mail.gmail.com/
[2]: https://github.com/checkpoint-restore/criu/issues/488



Christophe


Re: Pinning ZONE_MOVABLE pages

2020-11-23 Thread John Hubbard

On 11/20/20 12:27 PM, Pavel Tatashin wrote:

Recently, I encountered a hang that is happening during memory hot
remove operation. It turns out that the hang is caused by pinned user
pages in ZONE_MOVABLE.

Kernel expects that all pages in ZONE_MOVABLE can be migrated, but
this is not the case if a user applications such as through dpdk
libraries pinned them via vfio dma map. Kernel keeps trying to
hot-remove them, but refcnt never gets to zero, so we are looping
until the hardware watchdog kicks in.

We cannot do dma unmaps before hot-remove, because hot-remove is a
slow operation, and we have thousands for network flows handled by
dpdk that we just cannot suspend for the duration of hot-remove
operation.

The solution is for dpdk to allocate pages from a zone below
ZONE_MOVAVLE, i.e. ZONE_NORMAL/ZONE_HIGHMEM, but this is not possible.
There is no user interface that we have that allows applications to
select what zone the memory should come from.

I've spoken with Stephen Hemminger, and he said that DPDK is moving in
the direction of using transparent huge pages instead of HugeTLBs,
which means that we need to allow at least anonymous, and anonymous
transparent huge pages to come from non-movable zones on demand.

Here is what I am proposing:
1. Add a new flag that is passed through pin_user_pages_* down to
fault handlers, and allow the fault handler to allocate from a
non-movable zone.



I like where the discussion so far (in the other threads) has taken
this. And the current plan also implies, I think, that you can probably
avoid any new flags at all: just check that both FOLL_LONGTERM and
FOLL_PIN are set, and if they are, then make your attempt to migrate
away from ZONE_MOVABLE.





Sample function stacks through which this info needs to be passed is this:

pin_user_pages_remote(gup_flags)
  __get_user_pages_remote(gup_flags)
   __gup_longterm_locked(gup_flags)
__get_user_pages_locked(gup_flags)
 __get_user_pages(gup_flags)
  faultin_page(gup_flags)
   Convert gup_flags into fault_flags
   handle_mm_fault(fault_flags)


I'm pleased that the gup_flags have pretty much been plumbed through all the
main places that they were missing, so there shouldn't be too much required
at this point.



 From handle_mm_fault(), the stack diverges into various faults,
examples include:

Transparent Huge Page
handle_mm_fault(fault_flags)
__handle_mm_fault(fault_flags)
Create: struct vm_fault vmf, use fault_flags to specify correct gfp_mask
create_huge_pmd(vmf);
do_huge_pmd_anonymous_page(vmf);
mm_get_huge_zero_page(vma->vm_mm); -> flag is lost, so flag from
vmf.gfp_mask should be passed as well.

There are several other similar paths in a transparent huge page, also
there is a named path where allocation is based on filesystems, and
the flag should be honored there as well, but it does not have to be
added at the same time.

Regular Pages
handle_mm_fault(fault_flags)
__handle_mm_fault(fault_flags)
Create: struct vm_fault vmf, use fault_flags to specify correct gfp_mask
handle_pte_fault(vmf)
do_anonymous_page(vmf);
page = alloc_zeroed_user_highpage_movable(vma, vmf->address); ->
replace change this call according to gfp_mask.

The above only take care of the case if user application faults on the
page during pinning time, but there are also cases where pages already
exist.

2. Add an internal move_pages_zone() similar to move_pages() syscall
but instead of migrating to a different NUMA node, migrate pages from
ZONE_MOVABLE to another zone.
Call move_pages_zone() on demand prior to pinning pages from
vfio_pin_map_dma() for instance.

3. Perhaps, it also makes sense to add madvise() flag, to allocate
pages from non-movable zone. When a user application knows that it
will do DMA mapping, and pin pages for a long time, the memory that it
allocates should never be migrated or hot-removed, so make sure that
it comes from the appropriate place.
The benefit of adding madvise() flag is that we won't have to deal
with slow page migration during pin time, but the disadvantage is that
we would need to change the user interface.

Before I start working on the above approaches, I would like to get an
opinion from the community on an appropriate path forward for this
problem. If what I described sounds reasonable, or if there are other
ideas on how to address the problem that I am seeing.



I'm also in favor with avoiding (3) for now and maybe forever, depending on
how it goes. Good luck... :)


thanks,
--
John Hubbard
NVIDIA


Re:[RFC PATCH] Add a new "Frozen" status to MAINTAINERS subsystem entries

2020-11-23 Thread Bernard

From: Joe Perches 
Date: 2020-11-24 06:24:07
To:  Sam Ravnborg ,Bernard Zhao 
Cc:  linux-kernel@vger.kernel.org,Andrew Morton 
,Linus Torvalds 
,kernel-janitors 
,Greg KH 
Subject: [RFC PATCH] Add a new "Frozen" status to MAINTAINERS subsystem 
entries>On Mon, 2020-11-23 at 22:42 +0100, Sam Ravnborg wrote:
>> For this old driver we should try to limit patches to bug fixing and
>> infrastructure updates.
>
>It might be useful to add a new "S:" entry type to these old drivers
>as supported/maintained/obsolete may not really be appropriate.
>
>How about something like "S: Frozen" and checkpatch could emit a
>message similar to the one for unnecessary changes to obsolete code?
>
>So using the below would emit:
>
>$ ./scripts/checkpatch.pl -f drivers/gpu/drm/via/via_dma.c
>WARNING: drivers/gpu/drm/via/via_dma.c is marked as 'frozen' in the 
>MAINTAINERS hierarchy.  No unnecessary modifications please.
>
>Maybe like the below (and fyi there's no additional git lookup overhead as
>the initial obsolete check already caches the git result).
>
>---
> MAINTAINERS   | 10 +-
> scripts/checkpatch.pl | 11 +++
> 2 files changed, 16 insertions(+), 5 deletions(-)
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index 5f10105cac6f..6374d29180b8 100644
>--- a/MAINTAINERS
>+++ b/MAINTAINERS
>@@ -88,7 +88,10 @@ Descriptions of section entries and preferred order
>  Supported:   Someone is actually paid to look after this.
>  Maintained:  Someone actually looks after it.
>  Odd Fixes:   It has a maintainer but they don't have time to do
>-  much other than throw the odd patch in. See below..
>+  much other than throw the odd patch in.
>+ Frozen:  Old code that should not be modified unless changes
>+  are to correct actual defects or API infrastructure.
>+  Cleanup/style changes are not generally accepted.
>  Orphan:  No current maintainer [but maybe you could take the
>   role as you write your new code].
>  Obsolete:Old code. Something tagged obsolete generally means
>@@ -5718,6 +5721,11 @@ S:  Supported
> T:git git://anongit.freedesktop.org/drm/drm-misc
> F:drivers/gpu/drm/udl/
> 
>+DRM DRIVER FOR VIA
>+L:dri-de...@lists.freedesktop.org
>+S:Frozen
>+F:drivers/gpu/drm/via/
>+
> DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS)
> M:Rodrigo Siqueira 
> M:Melissa Wen 
>diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
>index fdfd5ec09be6..79321cbfb761 100755
>--- a/scripts/checkpatch.pl
>+++ b/scripts/checkpatch.pl
>@@ -902,8 +902,8 @@ sub seed_camelcase_file {
> 
> our %maintained_status = ();
> 
>-sub is_maintained_obsolete {
>-  my ($filename) = @_;
>+sub is_maintained {
>+  my ($filename, $test) = @_;
> 
>   return 0 if (!$tree || !(-e "$root/scripts/get_maintainer.pl"));
> 
>@@ -911,7 +911,7 @@ sub is_maintained_obsolete {
>   $maintained_status{$filename} = `perl 
> $root/scripts/get_maintainer.pl --status --nom --nol --nogit --nogit-fallback 
> -f $filename 2>&1`;
>   }
> 
>-  return $maintained_status{$filename} =~ /obsolete/i;
>+  return $maintained_status{$filename} =~ /$test/i;
> }
> 
> sub is_SPDX_License_valid {
>@@ -2633,9 +2633,12 @@ sub process {
>   }
> 
>   if ($found_file) {
>-  if (is_maintained_obsolete($realfile)) {
>+  if (is_maintained($realfile, "obsolete")) {
>   WARN("OBSOLETE",
>"$realfile is marked as 'obsolete' in the 
> MAINTAINERS hierarchy.  No unnecessary modifications please.\n");
>+  } elsif (is_maintained($realfile, "frozen")) {
>+  WARN("FROZEN",
>+   "$realfile is marked as 'frozen' in the 
>MAINTAINERS hierarchy.  No unnecessary modifications please.\n");
>   }
>   if ($realfile =~ 
> m@^(?:drivers/net/|net/|drivers/staging/)@) {
>   $check = 1;

Hi:

For me, this seems to be a nice idea.
As a  newcomer to the community, maybe I am not sure which drivers are hot and 
which ones do not need too much attention.
With this patch script, it will give us a better guide.

BR//Bernard
>




[PATCH] fs/buffer.c: Revoke LRU when trying to drop buffers

2020-11-23 Thread Chris Goldsworthy
From: Laura Abbott 

When a buffer is added to the LRU list, a reference is taken which is
not dropped until the buffer is evicted from the LRU list. This is the
correct behavior, however this LRU reference will prevent the buffer
from being dropped. This means that the buffer can't actually be dropped
until it is selected for eviction. There's no bound on the time spent
on the LRU list, which means that the buffer may be undroppable for
very long periods of time. Given that migration involves dropping
buffers, the associated page is now unmigratible for long periods of
time as well. CMA relies on being able to migrate a specific range
of pages, so these types of failures make CMA significantly
less reliable, especially under high filesystem usage.

Rather than waiting for the LRU algorithm to eventually kick out
the buffer, explicitly remove the buffer from the LRU list when trying
to drop it. There is still the possibility that the buffer
could be added back on the list, but that indicates the buffer is
still in use and would probably have other 'in use' indicates to
prevent dropping.

Signed-off-by: Laura Abbott 
Signed-off-by: Chris Goldsworthy 
---
 fs/buffer.c | 47 +--
 1 file changed, 45 insertions(+), 2 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index 64564ac..1751f0b 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1471,12 +1471,48 @@ static bool has_bh_in_lru(int cpu, void *dummy)
return false;
 }
 
+static void __evict_bh_lru(void *arg)
+{
+   struct bh_lru *b = _cpu_var(bh_lrus);
+   struct buffer_head *bh = arg;
+   int i;
+
+   for (i = 0; i < BH_LRU_SIZE; i++) {
+   if (b->bhs[i] == bh) {
+   brelse(b->bhs[i]);
+   b->bhs[i] = NULL;
+   goto out;
+   }
+   }
+out:
+   put_cpu_var(bh_lrus);
+}
+
+static bool bh_exists_in_lru(int cpu, void *arg)
+{
+   struct bh_lru *b = per_cpu_ptr(_lrus, cpu);
+   struct buffer_head *bh = arg;
+   int i;
+
+   for (i = 0; i < BH_LRU_SIZE; i++) {
+   if (b->bhs[i] == bh)
+   return true;
+   }
+
+   return false;
+
+}
 void invalidate_bh_lrus(void)
 {
on_each_cpu_cond(has_bh_in_lru, invalidate_bh_lru, NULL, 1);
 }
 EXPORT_SYMBOL_GPL(invalidate_bh_lrus);
 
+static void evict_bh_lrus(struct buffer_head *bh)
+{
+   on_each_cpu_cond(bh_exists_in_lru, __evict_bh_lru, bh, 1);
+}
+
 void set_bh_page(struct buffer_head *bh,
struct page *page, unsigned long offset)
 {
@@ -3245,8 +3281,15 @@ drop_buffers(struct page *page, struct buffer_head 
**buffers_to_free)
 
bh = head;
do {
-   if (buffer_busy(bh))
-   goto failed;
+   if (buffer_busy(bh)) {
+   /*
+* Check if the busy failure was due to an
+* outstanding LRU reference
+*/
+   evict_bh_lrus(bh);
+   if (buffer_busy(bh))
+   goto failed;
+   }
bh = bh->b_this_page;
} while (bh != head);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH] Resolve LRU page-pinning issue for file-backed pages

2020-11-23 Thread Chris Goldsworthy
It is possible for file-backed pages to end up in a contiguous memory
area (CMA), such that the relevant page must be migrated using the
.migratepage() callback when its backing physical memory is selected
for use in an CMA allocation (through cma_alloc()).  However, if a set
of address space operations (AOPs) for a file-backed page lacks a
migratepage() page call-back, fallback_migrate_page() will be used
instead, which through try_to_release_page() calls
try_to_free_buffers() (which is called directly or through a
try_to_free_buffers() callback.  try_to_free_buffers() in turn calls
drop_buffers().

drop_buffers() itself can fail due to the buffer_head associated with
a page being busy. However, it is possible that the buffer_head is on
an LRU list for a CPU, such that we can try removing the buffer_head
from that list, in order to successfully release the page.  Do this.
For reference ext4_journalled_aops is a set of AOPs that lacks the
migratepage() callback.

Laura Abbott (1):
  fs/buffer.c: Revoke LRU when trying to drop buffers

 fs/buffer.c | 47 +--
 1 file changed, 45 insertions(+), 2 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



Re: [PATCH] usb: cdns3: fix NULL pointer dereference on no platform data

2020-11-23 Thread Peter Chen
On 20-11-23 12:49:31, Roger Quadros wrote:
> Some platforms (e.g. TI) will not have any platform data which will
> lead to NULL pointer dereference if we don't check for NULL pdata.
> 
> Fixes: a284b7fd1b8f ("usb: cdns3: add quirk for enable runtime pm by default")
> Reported-by: Nishanth Menon 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/cdns3/core.c | 2 +-
>  drivers/usb/cdns3/host.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
> index 54d841aa626f..0f08aebce86d 100644
> --- a/drivers/usb/cdns3/core.c
> +++ b/drivers/usb/cdns3/core.c
> @@ -559,7 +559,7 @@ static int cdns3_probe(struct platform_device *pdev)
>   device_set_wakeup_capable(dev, true);
>   pm_runtime_set_active(dev);
>   pm_runtime_enable(dev);
> - if (!(cdns->pdata->quirks & CDNS3_DEFAULT_PM_RUNTIME_ALLOW))
> + if (!(cdns->pdata && (cdns->pdata->quirks & 
> CDNS3_DEFAULT_PM_RUNTIME_ALLOW)))
>   pm_runtime_forbid(dev);
>  
>   /*
> diff --git a/drivers/usb/cdns3/host.c b/drivers/usb/cdns3/host.c
> index 08103785a17a..ec89f2e5430f 100644
> --- a/drivers/usb/cdns3/host.c
> +++ b/drivers/usb/cdns3/host.c
> @@ -59,7 +59,7 @@ static int __cdns3_host_init(struct cdns3 *cdns)
>   goto err1;
>   }
>  
> - if (cdns->pdata->quirks & CDNS3_DEFAULT_PM_RUNTIME_ALLOW)
> + if (cdns->pdata && (cdns->pdata->quirks & 
> CDNS3_DEFAULT_PM_RUNTIME_ALLOW))
>   cdns->xhci_plat_data->quirks |= XHCI_DEFAULT_PM_RUNTIME_ALLOW;
>  
>   ret = platform_device_add_data(xhci, cdns->xhci_plat_data,

Thanks for fixing it, already applied to -next tree.

-- 

Thanks,
Peter Chen

Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken

2020-11-23 Thread Huang Rui
On Tue, Nov 24, 2020 at 06:51:11AM +0800, Kuehling, Felix wrote:
> On 2020-11-23 5:33 p.m., Will Deacon wrote:
> > On Mon, Nov 23, 2020 at 09:04:14PM +, Deucher, Alexander wrote:
> >> [AMD Public Use]
> >>
> >>> -Original Message-
> >>> From: Will Deacon 
> >>> Sent: Monday, November 23, 2020 8:44 AM
> >>> To: linux-kernel@vger.kernel.org
> >>> Cc: linux-...@vger.kernel.org; io...@lists.linux-foundation.org; Will
> >>> Deacon ; Bjorn Helgaas ;
> >>> Deucher, Alexander ; Edgar Merger
> >>> ; Joerg Roedel 
> >>> Subject: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken
> >>>
> >>> Edgar Merger reports that the AMD Raven GPU does not work reliably on his
> >>> system when the IOMMU is enabled:
> >>>
> >>>| [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
> >>> signaled seq=1, emitted seq=3
> >>>| [...]
> >>>| amdgpu :0b:00.0: GPU reset begin!
> >>>| AMD-Vi: Completion-Wait loop timed out
> >>>| iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT
> >>> device=0b:00.0 address=0x38edc0970]
> >>>
> >>> This is indicative of a hardware/platform configuration issue so, since
> >>> disabling ATS has been shown to resolve the problem, add a quirk to match
> >>> this particular device while Edgar follows-up with AMD for more 
> >>> information.
> >>>
> >>> Cc: Bjorn Helgaas 
> >>> Cc: Alex Deucher 
> >>> Reported-by: Edgar Merger 
> >>> Suggested-by: Joerg Roedel 
> >>> Link:
> >>> https://lore.
> >>> kernel.org/linux-
> >>> iommu/MWHPR10MB1310F042A30661D4158520B589FC0@MWHPR10M
> >>> B1310.namprd10.prod.outlook.com
> >>> her%40amd.com%7C1a883fe14d0c408e7d9508d88fb5df4e%7C3dd8961fe488
> >>> 4e608e11a82d994e183d%7C0%7C0%7C637417358593629699%7CUnknown%7
> >>> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> >>> LCJXVCI6Mn0%3D%7C1000sdata=TMgKldWzsX8XZ0l7q3%2BszDWXQJJ
> >>> LOUfX5oGaoLN8n%2B8%3Dreserved=0
> >>> Signed-off-by: Will Deacon 
> >>> ---
> >>>
> >>> Hi all,
> >>>
> >>> Since Joerg is away at the moment, I'm posting this to try to make some
> >>> progress with the thread in the Link: tag.
> >> + Felix
> >>
> >> What system is this?  Can you provide more details?  Does a sbios update
> >> fix this?  Disabling ATS for all Ravens will break GPU compute for a lot
> >> of people.  I'd prefer to just black list this particular system (e.g.,
> >> just SSIDs or revision) if possible.
> 
> +Ray
> 
> There are already many systems where the IOMMU is disabled in the BIOS, 
> or the CRAT table reporting the APU compute capabilities is broken. Ray 
> has been working on a fallback to make APUs behave like dGPUs on such 
> systems. That should also cover this case where ATS is blacklisted. That 
> said, it affects the programming model, because we don't support the 
> unified and coherent memory model on dGPUs like we do on APUs with 
> IOMMUv2. So it would be good to make the conditions for this workaround 
> as narrow as possible.

Yes, besides the comments from Alex and Felix, may we get your firmware
version (SMC firmware which is from SBIOS) and device id?

> >>>| [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
> >>> signaled seq=1, emitted seq=3

It looks only gfx ib test passed, and fails to lanuch desktop, am I right?

We would like to see whether it is Raven, Raven kicker (new Raven), or
Picasso. In our side, per the internal test result, we didn't see the
similiar issue on Raven kicker and Picasso platform.

Thanks,
Ray

> 
> These are the relevant changes in KFD and Thunk for reference:
> 
> ### KFD ###
> 
> commit 914913ab04dfbcd0226ecb6bc99d276832ea2908
> Author: Huang Rui 
> Date:   Tue Aug 18 14:54:23 2020 +0800
> 
>      drm/amdkfd: implement the dGPU fallback path for apu (v6)
> 
>      We still have a few iommu issues which need to address, so force raven
>      as "dgpu" path for the moment.
> 
>      This is to add the fallback path to bypass IOMMU if IOMMU v2 is 
> disabled
>      or ACPI CRAT table not correct.
> 
>      v2: Use ignore_crat parameter to decide whether it will go with 
> IOMMUv2.
>      v3: Align with existed thunk, don't change the way of raven, only 
> renoir
>      will use "dgpu" path by default.
>      v4: don't update global ignore_crat in the driver, and revise fallback
>      function if CRAT is broken.
>      v5: refine acpi crat good but no iommu support case, and rename the
>      title.
>      v6: fix the issue of dGPU initialized firstly, just modify the report
>      value in the node_show().
> 
>      Signed-off-by: Huang Rui 
>      Reviewed-by: Felix Kuehling 
>      Signed-off-by: Alex Deucher 
> 
> ### Thunk ###
> 
> commit e32482fa4b9ca398c8bdc303920abfd672592764
> Author: Huang Rui 
> Date:   Tue Aug 18 18:54:05 2020 +0800
> 
>      libhsakmt: remove is_dgpu flag in the hsa_gfxip_table
> 
>      Whether use dgpu path will check the props which exposed from kernel.
>      We won't need hard code in the ASIC table.
> 
>      Signed-off-by: Huang Rui 
>      Change-Id: 

Re: [PATCH 00/12] Add the page size in the perf record (user tools)

2020-11-23 Thread Namhyung Kim
Hi,

On Wed, Nov 18, 2020 at 4:57 AM  wrote:
>
> From: Kan Liang 
>
> Current perf can report both virtual addresses and physical addresses,
> but not the page size. Without the page size information of the utilized
> page, users cannot decide whether to promote/demote large pages to
> optimize memory usage.
>
> The kernel patches have been merged into tip perf/core branch,
> commit 8d97e71811aa ("perf/core: Add PERF_SAMPLE_DATA_PAGE_SIZE")
> commit 76a5433f95f3 ("perf/x86/intel: Support PERF_SAMPLE_DATA_PAGE_SIZE")
> commit 4cb6a42e4c4b ("powerpc/perf: Support PERF_SAMPLE_DATA_PAGE_SIZE")
> commit 995f088efebe ("perf/core: Add support for PERF_SAMPLE_CODE_PAGE_SIZE")
> commit 51b646b2d9f8 ("perf,mm: Handle non-page-table-aligned hugetlbfs")
>
> and Peter's perf/core branch
> commit 524680ce47a1 ("mm/gup: Provide gup_get_pte() more generic")
> commit 44a35d6937d2 ("mm: Introduce pXX_leaf_size()")
> commit 2f1e2f091ad0 ("perf/core: Fix arch_perf_get_page_size()")
> commit 7649e44aacdd ("arm64/mm: Implement pXX_leaf_size() support")
> commit 1df1ae7e262c ("sparc64/mm: Implement pXX_leaf_size() support")
>
> This patch set is to enable the page size support in user tools.
>
> Kan Liang (8):
>   tools headers UAPI: Update tools's copy of linux/perf_event.h
>   perf record: Support new sample type for data page size
>   perf script: Support data page size
>   perf sort: Add sort option for data page size
>   perf mem: Factor out a function to generate sort order
>   perf mem: Clean up output format
>   perf mem: Support data page size
>   perf test: Add test case for PERF_SAMPLE_DATA_PAGE_SIZE
>
> Stephane Eranian (4):
>   perf tools: Add support for PERF_SAMPLE_CODE_PAGE_SIZE
>   perf script: Add support for PERF_SAMPLE_CODE_PAGE_SIZE
>   perf report: Add support for PERF_SAMPLE_CODE_PAGE_SIZE
>   perf test: Add test case for PERF_SAMPLE_CODE_PAGE_SIZE

For the patchset:

Acked-by: Namhyung Kim 

Thanks,
Namhyung

>
>  tools/include/uapi/linux/perf_event.h |   6 +-
>  tools/perf/Documentation/perf-mem.txt |   3 +
>  tools/perf/Documentation/perf-record.txt  |   6 +
>  tools/perf/Documentation/perf-report.txt  |   2 +
>  tools/perf/Documentation/perf-script.txt  |   5 +-
>  tools/perf/builtin-mem.c  | 150 --
>  tools/perf/builtin-record.c   |   4 +
>  tools/perf/builtin-script.c   |  26 +++-
>  tools/perf/tests/sample-parsing.c |  10 +-
>  tools/perf/util/event.h   |   5 +
>  tools/perf/util/evsel.c   |  18 +++
>  tools/perf/util/hist.c|   5 +
>  tools/perf/util/hist.h|   2 +
>  tools/perf/util/machine.c |   7 +-
>  tools/perf/util/map_symbol.h  |   1 +
>  tools/perf/util/perf_event_attr_fprintf.c |   2 +-
>  tools/perf/util/record.h  |   2 +
>  tools/perf/util/session.c |  26 
>  tools/perf/util/sort.c|  56 
>  tools/perf/util/sort.h|   3 +
>  tools/perf/util/synthetic-events.c|  16 +++
>  21 files changed, 278 insertions(+), 77 deletions(-)
>
> --
> 2.17.1
>


Re: [PATCH] Revert "usb: cdns3: core: quit if it uses role switch class"

2020-11-23 Thread Peter Chen
On 20-11-23 13:50:51, Roger Quadros wrote:
> This reverts commit 50642709f6590fe40afa6d22c32f23f5b842aed5.
> 
> This commit breaks hardware based role switching on TI platforms.
> cdns->role_sw is always going to be non-zero as it is a pointer
> to the usb_role_switch instance. Some other means needs to be used
> if hardware based role switching is not required by the platform.
> 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/cdns3/core.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
> index a0f73d4711ae..4c1445cf2ad0 100644
> --- a/drivers/usb/cdns3/core.c
> +++ b/drivers/usb/cdns3/core.c
> @@ -280,10 +280,6 @@ int cdns3_hw_role_switch(struct cdns3 *cdns)
>   enum usb_role real_role, current_role;
>   int ret = 0;
>  
> - /* Depends on role switch class */
> - if (cdns->role_sw)
> - return 0;
> -
>   pm_runtime_get_sync(cdns->dev);
>  
>   current_role = cdns->role;
> -- 

Hi Roger,

I am sorry about that. Do you use role switch /sys entry, if you have
used, I prefer using "usb-role-switch" property at dts to judge if
SoC OTG signals or external signals for role switch. If you have not
used it, I prefer only setting cdns->role_sw for role switch use cases.

-- 

Thanks,
Peter Chen

Re: [PATCH v2 4/4] iio: hid-sensors: Add hinge sensor driver

2020-11-23 Thread Ye, Xiang
On Sat, Nov 21, 2020 at 05:56:29PM +, Jonathan Cameron wrote:
> On Thu, 19 Nov 2020 18:03:31 +0800
> Ye Xiang  wrote:
> 
> > The Hinge sensor is a common custom sensor on laptops. It calculates
> > the angle between the lid (screen) and the base (keyboard). In addition,
> > it also exposes screen and the keyboard angels with respect to the
> > ground. Applications can easily get laptop's status in space through
> > this sensor, in order to display appropriate user interface.
> 
> I'm a little unclear on why the 3 axes aren't treated as a single sensor.
> You seem to always grab the 3 together or am I missing something?
> 
> That will greatly simplify things and get rid of the need to have
> a shared trigger with the problems that causes in the previous
> patch.
> 
> Thanks,
> 
> Jonathan
> 
> > 
> > Signed-off-by: Ye Xiang 
> > ---
> >  .../hid-sensors/hid-sensor-attributes.c   |   2 +
> >  drivers/iio/position/Kconfig  |  16 +
> >  drivers/iio/position/Makefile |   3 +
> >  .../iio/position/hid-sensor-custom-hinge.c| 412 ++
> 
> Given it's custom probably needs a more specific name.  I guess
> hid-sensor-custom-intel-hinge.c might be safe?
> 
> Same for other places we need names in here.
agree, will change the name to hid-sensor-custom-intel-hinge.c
> 
> >  4 files changed, 433 insertions(+)
> >  create mode 100644 drivers/iio/position/hid-sensor-custom-hinge.c
> > 
> > diff --git a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c 
> > b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > index 442ff787f7af..5b822a4298a0 100644
> > --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> > @@ -71,6 +71,8 @@ static struct {
> > {HID_USAGE_SENSOR_TEMPERATURE, HID_USAGE_SENSOR_UNITS_DEGREES, 1000, 0},
> >  
> > {HID_USAGE_SENSOR_HUMIDITY, 0, 1000, 0},
> > +   {HID_USAGE_SENSOR_HINGE, 0, 0, 17453293},
> > +   {HID_USAGE_SENSOR_HINGE, HID_USAGE_SENSOR_UNITS_DEGREES, 0, 17453293},
> >  };
> >  
> >  static void simple_div(int dividend, int divisor, int *whole,
> > diff --git a/drivers/iio/position/Kconfig b/drivers/iio/position/Kconfig
> > index eda67f008c5b..0346f6f2b422 100644
> > --- a/drivers/iio/position/Kconfig
> > +++ b/drivers/iio/position/Kconfig
> > @@ -16,4 +16,20 @@ config IQS624_POS
> >   To compile this driver as a module, choose M here: the module
> >   will be called iqs624-pos.
> >  
> > +config HID_SENSOR_CUSTOM_HINGE
> > +   depends on HID_SENSOR_HUB
> > +   select IIO_BUFFER
> > +   select IIO_TRIGGERED_BUFFER
> > +   select HID_SENSOR_IIO_COMMON
> > +   select HID_SENSOR_IIO_TRIGGER
> > +   tristate "HID Hinge"
> > +   help
> > + This sensor present three angles, hinge angel, screen angles
> > + and keyboard angle respect to horizon (ground).
> > + Say yes here to build support for the HID SENSOR CUSTOM
> > + HINGE.
> 
> Capitalization is a bit odd looking. I'd drop it.
ok, will use lowercase.
> 
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called hid-sensor-custom-hinge.
> > +
> >  endmenu
> > diff --git a/drivers/iio/position/Makefile b/drivers/iio/position/Makefile
> > index 3cbe7a734352..7a6225977a01 100644
> > --- a/drivers/iio/position/Makefile
> > +++ b/drivers/iio/position/Makefile
> > @@ -5,3 +5,6 @@
> >  # When adding new entries keep the list in alphabetical order
> >  
> >  obj-$(CONFIG_IQS624_POS)   += iqs624-pos.o
> > +
> > +obj-$(CONFIG_HID_SENSOR_CUSTOM_HINGE) += hid-sensor-custom-hinge.o
> 
> Alphabetical order preferred.
> 
> > +ccflags-y  += -I$(srctree)/drivers/iio/common/hid-sensors
> 
> Why?
hinge driver need to include #include "hid-sensor-trigger.h", if not using this 
cflag-y
it should be #include "../common/hid-sensors/hid-sensor-trigger.h"

> 
> > diff --git a/drivers/iio/position/hid-sensor-custom-hinge.c 
> > b/drivers/iio/position/hid-sensor-custom-hinge.c
> > new file mode 100644
> > index ..a91b333f36fa
> > --- /dev/null
> > +++ b/drivers/iio/position/hid-sensor-custom-hinge.c
> > @@ -0,0 +1,412 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * HID Sensors Driver
> > + * Copyright (c) 2020, Intel Corporation.
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "hid-sensor-trigger.h"
> > +
> > +/* Channel definitions */
> > +static const struct iio_chan_spec hinge_channels[] = {
> > +   { .type = IIO_ANGL,
> > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > + .info_mask_shared_by_type =
> > + BIT(IIO_CHAN_INFO_OFFSET) | BIT(IIO_CHAN_INFO_SCALE) |
> > + BIT(IIO_CHAN_INFO_SAMP_FREQ) | BIT(IIO_CHAN_INFO_HYSTERESIS),
> > + .scan_type.realbits = 16,
> > + .scan_type.storagebits = 32,
> 
> It a bit odd to see a single channel that is 16 bits inside a 32 bit with
> no shift or similar.  Why not just pack it into 16 bits?
As it's said in 

[PATCH v2] cpuidle: arm: qcom: fix Kconfig problems

2020-11-23 Thread Randy Dunlap
The Kconfig symbol ARM_QCOM_SPM_CPUIDLE wildly selects other
Kconfig symbols when it should not.
This causes kconfig warnings and subsequent build errors,
as listed below, so modify this symbol's Kconfig entry to
constrain and tame it.

WARNING: unmet direct dependencies detected for QCOM_SCM
  Depends on [n]: ARM [=y] && HAVE_ARM_SMCCC [=n] || ARM64
  Selected by [y]:
  - ARM_QCOM_SPM_CPUIDLE [=y] && CPU_IDLE [=y] && (ARM [=y] || ARM64) && 
(ARCH_QCOM [=n] || COMPILE_TEST [=y]) && !ARM64

WARNING: unmet direct dependencies detected for ARM_CPU_SUSPEND
  Depends on [n]: ARCH_SUSPEND_POSSIBLE [=n]
  Selected by [y]:
  - ARM_QCOM_SPM_CPUIDLE [=y] && CPU_IDLE [=y] && (ARM [=y] || ARM64) && 
(ARCH_QCOM [=n] || COMPILE_TEST [=y]) && !ARM64

and

arm-linux-gnueabi-ld: arch/arm/kernel/sleep.o: in function `__cpu_suspend':
(.text+0x68): undefined reference to `cpu_sa110_suspend_size'
arm-linux-gnueabi-ld: arch/arm/kernel/suspend.o: in function 
`__cpu_suspend_save':
suspend.c:(.text+0x138): undefined reference to `cpu_sa110_do_suspend'
arm-linux-gnueabi-ld: suspend.c:(.text+0x170): undefined reference to 
`cpu_sa110_do_resume'
arm-linux-gnueabi-ld: drivers/firmware/qcom_scm-smc.o: in function 
`__scm_smc_do_quirk':
qcom_scm-smc.c:(.text+0x54): undefined reference to `__arm_smccc_smc'
arm-linux-gnueabi-ld: drivers/firmware/qcom_scm-legacy.o: in function 
`scm_legacy_call':
qcom_scm-legacy.c:(.text+0x168): undefined reference to `__arm_smccc_smc'
arm-linux-gnueabi-ld: drivers/firmware/qcom_scm-legacy.o: in function 
`scm_legacy_call_atomic':
qcom_scm-legacy.c:(.text+0x2e0): undefined reference to `__arm_smccc_smc'

Fixes: a871be6b8eee ("cpuidle: Convert Qualcomm SPM driver to a generic CPUidle 
driver")
Signed-off-by: Randy Dunlap 
Reported-by: kernel test robot 
Cc: linux...@vger.kernel.org
Cc: Andy Gross 
Cc: Bjorn Andersson 
Cc: linux-arm-...@vger.kernel.org
Cc: "Rafael J. Wysocki" 
Cc: Daniel Lezcano 
Cc: Stephan Gerhold 
Cc: Lina Iyer 
Cc: Ulf Hansson 
Cc: Bjorn Andersson 
Cc: John Stultz 
---
v2: change to depends on QCOM_SCM (suggested by Bjorn)

 drivers/cpuidle/Kconfig.arm |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20201123.orig/drivers/cpuidle/Kconfig.arm
+++ linux-next-20201123/drivers/cpuidle/Kconfig.arm
@@ -108,10 +108,10 @@ config ARM_TEGRA_CPUIDLE
 config ARM_QCOM_SPM_CPUIDLE
bool "CPU Idle Driver for Qualcomm Subsystem Power Manager (SPM)"
depends on (ARCH_QCOM || COMPILE_TEST) && !ARM64
+   depends on QCOM_SCM
select ARM_CPU_SUSPEND
select CPU_IDLE_MULTIPLE_DRIVERS
select DT_IDLE_STATES
-   select QCOM_SCM
help
  Select this to enable cpuidle for Qualcomm processors.
  The Subsystem Power Manager (SPM) controls low power modes for the


Re: [PATCH 5.4 000/158] 5.4.80-rc1 review

2020-11-23 Thread Naresh Kamboju
On Mon, 23 Nov 2020 at 18:06, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 5.4.80 release.
> There are 158 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 25 Nov 2020 12:17:50 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.80-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 5.4.80-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: 0048695749b29788fab5e9fff442f5a5968290d3
git describe: v5.4.79-159-g0048695749b2
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.79-159-g0048695749b2

No regressions (compared to build v5.4.79)

No fixes (compared to build v5.4.79)


Ran 46177 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- nxp-ls2088
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan

Test Suites
---
* build
* igt-gpu-tools
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* linux-log-parser
* ltp-commands-tests
* ltp-controllers-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* ltp-tracing-tests
* perf
* v4l2-compliance
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-sched-tests
* ltp-syscalls-tests
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests

-- 
Linaro LKFT
https://lkft.linaro.org


[PATCH v2] usb: musb: remove unused variable 'devctl'

2020-11-23 Thread min.guo
From: Min Guo 

Remove unused 'devctl' variable to fix compile warnings:

drivers/usb/musb/musbhsdma.c: In function 'dma_controller_irq':
drivers/usb/musb/musbhsdma.c:324:8: warning: variable 'devctl' set
but not used [-Wunused-but-set-variable]

Signed-off-by: Min Guo 
---
changes in v2
suggested by Alan Stern:
Add void before musb_read to indicate that the register MUSB_DEVCTL
was intended to be read and discarded.
---
 drivers/usb/musb/musbhsdma.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index 0aacfc8be5a1..f59a009c533e 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -321,8 +321,6 @@ irqreturn_t dma_controller_irq(int irq, void *private_data)
musb_channel->channel.status =
MUSB_DMA_STATUS_BUS_ABORT;
} else {
-   u8 devctl;
-
addr = musb_read_hsdma_addr(mbase,
bchannel);
channel->actual_len = addr
@@ -336,7 +334,7 @@ irqreturn_t dma_controller_irq(int irq, void *private_data)
< musb_channel->len) ?
"=> reconfig 0" : "=> complete");
 
-   devctl = musb_readb(mbase, MUSB_DEVCTL);
+   (void)musb_readb(mbase, MUSB_DEVCTL);
 
channel->status = MUSB_DMA_STATUS_FREE;
 
-- 
2.18.0



Re: kernel BUG at fs/ext4/inode.c:LINE!

2020-11-23 Thread Hugh Dickins
On Mon, 23 Nov 2020, Linus Torvalds wrote:
> On Mon, Nov 23, 2020 at 8:07 PM Hugh Dickins  wrote:
> >
> > The problem is that PageWriteback is not accompanied by a page reference
> > (as the NOTE at the end of test_clear_page_writeback() acknowledges): as
> > soon as TestClearPageWriteback has been done, that page could be removed
> > from page cache, freed, and reused for something else by the time that
> > wake_up_page() is reached.
> 
> Ugh.
> 
> Would it be possible to instead just make PageWriteback take the ref?
> 
> I don't hate your patch per se, but looking at that long explanation,
> and looking at the gyrations end_page_writeback() does, I go "why
> don't we do that?"
> 
> IOW, why couldn't we just make the __test_set_page_writeback()
> increment the page count if the writeback flag wasn't already set, and
> then make the end_page_writeback() do a put_page() after it all?

Right, that should be a lot simpler, and will not require any of the
cleanup (much as I liked that).  If you're reasonably confident that
adding the extra get_page+put_page to every writeback (instead of
just to the waited case, which I presume significantly less common)
will get lost in the noise - I was not confident of that, nor
confident of devising realistic tests to decide it.

What I did look into before sending, was whether in the filesystems
there was a pattern of doing a put_page() after *set_page_writeback(),
when it would just be a matter of deleting that put_page() and doing
it instead at the end of end_page_writeback().  But no: there were a
few cases like that, but in general no such pattern.

Though, what I think I'll try is not quite what you suggest there,
but instead do both get_page() and put_page() in end_page_writeback().
The reason being, there are a number of places (in mm at least) where
we judge what to do by the expected refcount: places that know to add
1 on when PagePrivate is set (for buffers), but do not expect to add
1 on when PageWriteback is set.  Now, all of those places probably
have to have their own wait_on_page_writeback() too, but I'd rather
narrow the window when the refcount is raised, than work through
what if any change would be needed in those places.

> >
> > Then on crashing a second time, realized there's a stronger reason against
> > that approach.  If my testing just occasionally crashes on that check,
> > when the page is reused for part of a compound page, wouldn't it be much
> > more common for the page to get reused as an order-0 page before reaching
> > wake_up_page()?  And on rare occasions, might that reused page already be
> > marked PageWriteback by its new user, and already be waited upon?  What
> > would that look like?
> >
> > It would look like BUG_ON(PageWriteback) after wait_on_page_writeback()
> > in write_cache_pages() (though I have never seen that crash myself).
> 
> So looking more at the patch, I started looking at this part:
> 
> > +   writeback = TestClearPageWriteback(page);
> > +   /* No need for smp_mb__after_atomic() after TestClear */
> > +   waiters = PageWaiters(page);
> > +   if (waiters) {
> > +   /*
> > +* Writeback doesn't hold a page reference on its own, 
> > relying
> > +* on truncation to wait for the clearing of PG_writeback.
> > +* We could safely wake_up_page_bit(page, PG_writeback) 
> > here,
> > +* while holding i_pages lock: but that would be a poor 
> > choice
> > +* if the page is on a long hash chain; so instead choose to
> > +* get_page+put_page - though atomics will add some 
> > overhead.
> > +*/
> > +   get_page(page);
> > +   }
> 
> and thinking more about this, my first reaction was "but that has the
> same race, just a smaller window".
> 
> And then reading the comment more, I realize you relied on the i_pages
> lock, and that this odd ordering was to avoid the possible latency.

Yes.  I decided to send the get_page+put_page variant, rather than the
wake_up_page_bit while holding i_pages variant (also tested), in part
because it's easier to edit the get_page+put_page one to the other.

> 
> But what about the non-mapping case? I'm not sure how that happens,
> but this does seem very fragile.

I don't see how the non-mapping case would ever occur: I think it
probably comes from a general pattern of caution about NULL mapping
when akpm (I think) originally wrote these functions.

> 
> I'm wondering why you didn't want to just do the get_page()
> unconditionally and early. Is avoiding the refcount really such a big
> optimization?

I don't know: I trust your judgement more than mine.

Hugh


Re: [PATCH] cpuidle: arm: qcom: fix Kconfig problems

2020-11-23 Thread Randy Dunlap
On 11/23/20 8:51 PM, Bjorn Andersson wrote:
> On Mon 23 Nov 19:30 CST 2020, Randy Dunlap wrote:
> 
>> The Kconfig symbol ARM_QCOM_SPM_CPUIDLE wildly selects other
>> Kconfig symbols when it should not.
>> This causes kconfig warnings and subsequent build errors,
>> as listed below, so modify this symbol's Kconfig entry to
>> constrain and tame it.
>>
>> WARNING: unmet direct dependencies detected for QCOM_SCM
>>   Depends on [n]: ARM [=y] && HAVE_ARM_SMCCC [=n] || ARM64
>>   Selected by [y]:
>>   - ARM_QCOM_SPM_CPUIDLE [=y] && CPU_IDLE [=y] && (ARM [=y] || ARM64) && 
>> (ARCH_QCOM [=n] || COMPILE_TEST [=y]) && !ARM64
>>
>> WARNING: unmet direct dependencies detected for ARM_CPU_SUSPEND
>>   Depends on [n]: ARCH_SUSPEND_POSSIBLE [=n]
>>   Selected by [y]:
>>   - ARM_QCOM_SPM_CPUIDLE [=y] && CPU_IDLE [=y] && (ARM [=y] || ARM64) && 
>> (ARCH_QCOM [=n] || COMPILE_TEST [=y]) && !ARM64
>>
>> and
>>
>> arm-linux-gnueabi-ld: arch/arm/kernel/sleep.o: in function `__cpu_suspend':
>> (.text+0x68): undefined reference to `cpu_sa110_suspend_size'
>> arm-linux-gnueabi-ld: arch/arm/kernel/suspend.o: in function 
>> `__cpu_suspend_save':
>> suspend.c:(.text+0x138): undefined reference to `cpu_sa110_do_suspend'
>> arm-linux-gnueabi-ld: suspend.c:(.text+0x170): undefined reference to 
>> `cpu_sa110_do_resume'
>> arm-linux-gnueabi-ld: drivers/firmware/qcom_scm-smc.o: in function 
>> `__scm_smc_do_quirk':
>> qcom_scm-smc.c:(.text+0x54): undefined reference to `__arm_smccc_smc'
>> arm-linux-gnueabi-ld: drivers/firmware/qcom_scm-legacy.o: in function 
>> `scm_legacy_call':
>> qcom_scm-legacy.c:(.text+0x168): undefined reference to `__arm_smccc_smc'
>> arm-linux-gnueabi-ld: drivers/firmware/qcom_scm-legacy.o: in function 
>> `scm_legacy_call_atomic':
>> qcom_scm-legacy.c:(.text+0x2e0): undefined reference to `__arm_smccc_smc'
>>
>> Fixes: a871be6b8eee ("cpuidle: Convert Qualcomm SPM driver to a generic 
>> CPUidle driver")
>> Signed-off-by: Randy Dunlap 
>> Reported-by: kernel test robot 
>> Cc: linux...@vger.kernel.org
>> Cc: Andy Gross 
>> Cc: Bjorn Andersson 
>> Cc: linux-arm-...@vger.kernel.org
>> Cc: "Rafael J. Wysocki" 
>> Cc: Daniel Lezcano 
>> Cc: Stephan Gerhold 
>> Cc: Lina Iyer 
>> Cc: Ulf Hansson 
>> Cc: Bjorn Andersson 
>> ---
>>  drivers/cpuidle/Kconfig.arm |3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> --- linux-next-20201123.orig/drivers/cpuidle/Kconfig.arm
>> +++ linux-next-20201123/drivers/cpuidle/Kconfig.arm
>> @@ -108,10 +108,11 @@ config ARM_TEGRA_CPUIDLE
>>  config ARM_QCOM_SPM_CPUIDLE
>>  bool "CPU Idle Driver for Qualcomm Subsystem Power Manager (SPM)"
>>  depends on (ARCH_QCOM || COMPILE_TEST) && !ARM64
>> +depends on PM
>>  select ARM_CPU_SUSPEND
>>  select CPU_IDLE_MULTIPLE_DRIVERS
>>  select DT_IDLE_STATES
>> -select QCOM_SCM
>> +select QCOM_SCM if HAVE_ARM_SMCCC
> 
> I presume the trigger for this error is that 'd0511b5496c0 ("firmware:
> QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module")'
> made QCOM_SCM user selectable and described the dependency on
> HAVE_ARM_SMCCC..

I don't quite see that as contributing to the problem, but maybe
it's just too late at night for me to see it.

> So given that, and the fact that this driver doesn't do anything without
> QCOM_SCM, can we instead make it "depends on QCOM_SCM"? I believe it
> would inherit the dependency of HAVE_ARM_SMCCC in this case?

Sure, I'll respin it like that.

> Regards,
> Bjorn
> 
>>  help
>>Select this to enable cpuidle for Qualcomm processors.
>>The Subsystem Power Manager (SPM) controls low power modes for the


thanks.
-- 
~Randy



Re: [PATCH] dcookies: Make dcookies depend on CONFIG_OPROFILE

2020-11-23 Thread Viresh Kumar
On 20-10-20, 16:31, Viresh Kumar wrote:
> From: Arnd Bergmann 
> 
> The dcookies stuff is used only with OPROFILE and there is no need to
> build it if CONFIG_OPROFILE isn't enabled. Build it depending on
> CONFIG_OPROFILE instead of CONFIG_PROFILING.
> 
> Signed-off-by: Arnd Bergmann 
> [ Viresh: Update the name in #endif part ]
> Signed-off-by: Viresh Kumar 
> ---
>  fs/Makefile  | 2 +-
>  include/linux/dcookies.h | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)

Alexander,

Ping for picking up this patch for 5.11. Thanks.

-- 
viresh


[PATCH] ubifs: Fix error return code in ubifs_init_authentication()

2020-11-23 Thread Wang ShaoBo
Fix to return PTR_ERR() error code from the error handling case where
ubifs_hash_get_desc() failed instead of 0 in ubifs_init_authentication(),
as done elsewhere in this function.

Fixes: 49525e5eecca5 ("ubifs: Add helper functions for authentication support")
Signed-off-by: Wang ShaoBo 
---
 fs/ubifs/auth.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/ubifs/auth.c b/fs/ubifs/auth.c
index b93b3cd10bfd..8c50de693e1d 100644
--- a/fs/ubifs/auth.c
+++ b/fs/ubifs/auth.c
@@ -338,8 +338,10 @@ int ubifs_init_authentication(struct ubifs_info *c)
c->authenticated = true;
 
c->log_hash = ubifs_hash_get_desc(c);
-   if (IS_ERR(c->log_hash))
+   if (IS_ERR(c->log_hash)) {
+   err = PTR_ERR(c->log_hash);
goto out_free_hmac;
+   }
 
err = 0;
 
-- 
2.17.1



Re: [Regression]: Commit 74d905d2 breaks the touchpad and touchscreen of Google Chromebook "samus"

2020-11-23 Thread Wang, Jiada

Hi Andre

Thanks for the log,
Hmmm, from the log (also as you have observed)
Seems "data->use_retrigen_workaround" is true on your device
so workaround mxt_process_messages_until_invalid() is used.
which is as same as with the commit reverted,
I am not sure what caused IRQ get generated.

@dmitry
I would suggest to revert the commit until we find out the root cause

Thanks,
Jiada


On 2020/11/24 15:15, Andre Muller wrote:

On 24/11/2020 04.02, Wang, Jiada wrote:

Hello Andre

Thanks for the log,
can you add more debug information like following diff,
and get full log?


Hi Jiada,

I added the warnings, but none of them triggers.
I double-checked the generated object file, it includes the debug strings.
(Also tested that touchscreen/touchpad don't work, as expected.)

Please find the full log attached.

Thank you,
Andre




diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c

index 98f17fa3a892..60bccd5c42f6 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -1298,21 +1298,29 @@ static int mxt_check_retrigen(struct mxt_data 
*data)

 data->use_retrigen_workaround = false;

 irqd = irq_get_irq_data(data->irq);
-   if (!irqd)
+   if (!irqd) {
+   dev_warn(>dev, "unable to get IRQ data\n");
 return -EINVAL;
+   }

-   if (irqd_is_level_type(irqd))
+   if (irqd_is_level_type(irqd)) {
+   dev_warn(>dev, "IRQ is level type\n");
 return 0;
+   }

 if (data->T18_address) {
 error = __mxt_read_reg(client,
    data->T18_address + 
MXT_COMMS_CTRL,

    1, );
-   if (error)
+   if (error) {
+   dev_warn(>dev, "failed to read reg: 
MXT_COMMS_CTRL\n");

 return error;
+   }

-   if (val & MXT_COMMS_RETRIGEN)
+   if (val & MXT_COMMS_RETRIGEN) {
+   dev_warn(>dev, "RETRIGEN feature 
available\n");

 return 0;
+   }
 }

 dev_warn(>dev, "Enabling RETRIGEN workaround\n");


Thanks,
Jiada

On 2020/11/05 23:23, Andre Muller wrote:

On 05/11/2020 14.25, Wang, Jiada wrote:

Hi Andre

Thanks for your report,
could you also please post the log when with this commit reverted?

Thanks,
Jiada


Shure!
The full dmesg with the revert is attached.

The atmel_mxt bits are:

[    0.195879] atmel_mxt_ts i2c-ATML:01: Family: 164 Variant: 17 
Firmware V1.0.AA Objects: 32
[    0.211712] atmel_mxt_ts i2c-ATML:01: Direct firmware load for 
maxtouch.cfg failed with error -2

[    0.212986] atmel_mxt_ts i2c-ATML:01: Touchscreen size X960Y540
[    0.213025] input: Atmel maXTouch Touchpad as 
/devices/pci:00/INT3432:00/i2c-0/i2c-ATML:01/input/input4
[    0.219208] atmel_mxt_ts i2c-ATML0001:01: Family: 164 Variant: 13 
Firmware V1.0.AA Objects: 41
[    0.238825] atmel_mxt_ts i2c-ATML0001:01: Direct firmware load for 
maxtouch.cfg failed with error -2

[    0.238949] intel_rapl_common: Found RAPL domain package
[    0.238955] intel_rapl_common: Found RAPL domain core
[    0.238961] intel_rapl_common: Found RAPL domain uncore
[    0.238966] intel_rapl_common: Found RAPL domain dram
[    0.240121] atmel_mxt_ts i2c-ATML0001:01: Touchscreen size X2559Y1699
[    0.240157] input: Atmel maXTouch Touchscreen as 
/devices/pci:00/INT3433:00/i2c-1/i2c-ATML0001:01/input/input5


Regards,
Andre



On 2020/11/04 17:13, Andre wrote:

Hi,

commit 74d905d2: Input: atmel_mxt_ts - only read messages in
mxt_acquire_irq() when necessary

breaks the touchpad and touchscreen of the 2015 Chromebook Pixel 
"Samus".


Reverting the commit from the current git tree gets them to work 
again.


I am not at all shure what info to include, but I will happily provide
it on request.

The dmesgs of a boot with commit 74d905d2 show "Enabling RETRIGEN
workaround", but otherwise looks the same as a boot without.

Here is the relevant bit (with 74d905d2):

atmel_mxt_ts i2c-ATML:01: Family: 164 Variant: 17 Firmware V1.0.AA
Objects: 32
atmel_mxt_ts i2c-ATML:01: Enabling RETRIGEN workaround
atmel_mxt_ts i2c-ATML:01: Direct firmware load for maxtouch.cfg
failed with error -2
atmel_mxt_ts i2c-ATML:01: Touchscreen size X960Y540
input: Atmel maXTouch Touchpad as
/devices/pci:00/INT3432:00/i2c-0/i2c-ATML:01/input/input4
atmel_mxt_ts i2c-ATML0001:01: Family: 164 Variant: 13 Firmware V1.0.AA
Objects: 41
atmel_mxt_ts i2c-ATML0001:01: Enabling RETRIGEN workaround
atmel_mxt_ts i2c-ATML0001:01: Direct firmware load for maxtouch.cfg
failed with error -2

Thank you,
Andre Müller






[PATCH] EDAC, mv64x60: Fix error return code in mv64x60_pci_err_probe()

2020-11-23 Thread Wang ShaoBo
Fix to return -ENODEV error code when edac_pci_add_device() failed instaed
of 0 in mv64x60_pci_err_probe(), as done elsewhere in this function.

Fixes: 4f4aeeabc061 ("drivers-edac: add marvell mv64x60 driver")
Signed-off-by: Wang ShaoBo 
---
 drivers/edac/mv64x60_edac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
index 3c68bb525d5d..456b9ca1fe8d 100644
--- a/drivers/edac/mv64x60_edac.c
+++ b/drivers/edac/mv64x60_edac.c
@@ -168,6 +168,7 @@ static int mv64x60_pci_err_probe(struct platform_device 
*pdev)
 
if (edac_pci_add_device(pci, pdata->edac_idx) > 0) {
edac_dbg(3, "failed edac_pci_add_device()\n");
+   res = -ENODEV;
goto err;
}
 
-- 
2.17.1



[PATCH V4 0/3] cpufreq_cooling: Get effective CPU utilization from scheduler

2020-11-23 Thread Viresh Kumar
Hi,

This patchset makes the cpufreq_cooling driver reuse the CPU utilization
metric provided by the scheduler instead of depending on idle and busy
times of a CPU, which aren't that accurate to measure the busyness of a
CPU for the next cycle. More details can be seen in the commit log of
patch 2/2.

V3->V4:
- Broke the first patch into two parts and used effective_cpu_util() in
  schedutil (Rafael).

- Removed comment about idle-injection in last patch based on feedback
  from Lukasz and added hi Reviewed-by tag.

V2->V3:
- Put the scheduler helpers within ifdef CONFIG_SMP.
- Keep both SMP and !SMP implementations in the cpufreq_cooling driver.
- Improved commit log with testing related information.

--
Viresh

Viresh Kumar (3):
  sched/core: Move schedutil_cpu_util() to core.c
  sched/core: Rename schedutil_cpu_util() and allow rest of the kernel
to use it
  thermal: cpufreq_cooling: Reuse sched_cpu_util() for SMP platforms

 drivers/thermal/cpufreq_cooling.c |  68 ++
 include/linux/sched.h |  21 ++
 kernel/sched/core.c   | 115 ++
 kernel/sched/cpufreq_schedutil.c  | 108 +---
 kernel/sched/fair.c   |   6 +-
 kernel/sched/sched.h  |  31 +---
 6 files changed, 197 insertions(+), 152 deletions(-)


base-commit: 3650b228f83adda7e5ee532e2b90429c03f7b9ec
-- 
2.25.0.rc1.19.g042ed3e048af



[PATCH V4 3/3] thermal: cpufreq_cooling: Reuse sched_cpu_util() for SMP platforms

2020-11-23 Thread Viresh Kumar
Several parts of the kernel are already using the effective CPU
utilization (as seen by the scheduler) to get the current load on the
CPU, do the same here instead of depending on the idle time of the CPU,
which isn't that accurate comparatively.

This is also the right thing to do as it makes the cpufreq governor
(schedutil) align better with the cpufreq_cooling driver, as the power
requested by cpufreq_cooling governor will exactly match the next
frequency requested by the schedutil governor since they are both using
the same metric to calculate load.

This was tested on ARM Hikey6220 platform with hackbench, sysbench and
schbench. None of them showed any regression or significant
improvements. Schbench is the most important ones out of these as it
creates the scenario where the utilization numbers provide a better
estimate of the future.

Scenario 1: The CPUs were mostly idle in the previous polling window of
the IPA governor as the tasks were sleeping and here are the details
from traces (load is in %):

 Old: thermal_power_cpu_get_power: cpus=,00ff freq=120 
total_load=203 load={{0x35,0x1,0x0,0x31,0x0,0x0,0x64,0x0}} dynamic_power=1339
 New: thermal_power_cpu_get_power: cpus=,00ff freq=120 
total_load=600 load={{0x60,0x46,0x45,0x45,0x48,0x3b,0x61,0x44}} 
dynamic_power=3960

Here, the "Old" line gives the load and requested_power (dynamic_power
here) numbers calculated using the idle time based implementation, while
"New" is based on the CPU utilization from scheduler.

As can be clearly seen, the load and requested_power numbers are simply
incorrect in the idle time based approach and the numbers collected from
CPU's utilization are much closer to the reality.

Scenario 2: The CPUs were busy in the previous polling window of the IPA
governor:

 Old: thermal_power_cpu_get_power: cpus=,00ff freq=120 
total_load=800 load={{0x64,0x64,0x64,0x64,0x64,0x64,0x64,0x64}} 
dynamic_power=5280
 New: thermal_power_cpu_get_power: cpus=,00ff freq=120 
total_load=708 load={{0x4d,0x5c,0x5c,0x5b,0x5c,0x5c,0x51,0x5b}} 
dynamic_power=4672

As can be seen, the idle time based load is 100% for all the CPUs as it
took only the last window into account, but in reality the CPUs aren't
that loaded as shown by the utilization numbers.

Reviewed-by: Lukasz Luba 
Signed-off-by: Viresh Kumar 
---
 drivers/thermal/cpufreq_cooling.c | 68 ---
 1 file changed, 54 insertions(+), 14 deletions(-)

diff --git a/drivers/thermal/cpufreq_cooling.c 
b/drivers/thermal/cpufreq_cooling.c
index cc2959f22f01..5aff2ac4b77f 100644
--- a/drivers/thermal/cpufreq_cooling.c
+++ b/drivers/thermal/cpufreq_cooling.c
@@ -76,7 +76,9 @@ struct cpufreq_cooling_device {
struct em_perf_domain *em;
struct cpufreq_policy *policy;
struct list_head node;
+#ifndef CONFIG_SMP
struct time_in_idle *idle_time;
+#endif
struct freq_qos_request qos_req;
 };
 
@@ -132,14 +134,35 @@ static u32 cpu_power_to_freq(struct 
cpufreq_cooling_device *cpufreq_cdev,
 }
 
 /**
- * get_load() - get load for a cpu since last updated
- * @cpufreq_cdev:   cpufreq_cooling_device for this cpu
- * @cpu:   cpu number
- * @cpu_idx:   index of the cpu in time_in_idle*
+ * get_load() - get load for a cpu
+ * @cpufreq_cdev: struct cpufreq_cooling_device for the cpu
+ * @cpu: cpu number
+ * @cpu_idx: index of the cpu in time_in_idle array
  *
  * Return: The average load of cpu @cpu in percentage since this
  * function was last called.
  */
+#ifdef CONFIG_SMP
+static u32 get_load(struct cpufreq_cooling_device *cpufreq_cdev, int cpu,
+   int cpu_idx)
+{
+   unsigned long max = arch_scale_cpu_capacity(cpu);
+   unsigned long util;
+
+   util = sched_cpu_util(cpu, ENERGY_UTIL, max);
+   return (util * 100) / max;
+}
+
+static inline int allocate_idle_time(struct cpufreq_cooling_device 
*cpufreq_cdev)
+{
+   return 0;
+}
+
+static inline void free_idle_time(struct cpufreq_cooling_device *cpufreq_cdev)
+{
+}
+
+#else /* !CONFIG_SMP */
 static u32 get_load(struct cpufreq_cooling_device *cpufreq_cdev, int cpu,
int cpu_idx)
 {
@@ -162,6 +185,26 @@ static u32 get_load(struct cpufreq_cooling_device 
*cpufreq_cdev, int cpu,
return load;
 }
 
+static int allocate_idle_time(struct cpufreq_cooling_device *cpufreq_cdev)
+{
+   unsigned int num_cpus = 
cpumask_weight(cpufreq_cdev->policy->related_cpus);
+
+   cpufreq_cdev->idle_time = kcalloc(num_cpus,
+ sizeof(*cpufreq_cdev->idle_time),
+ GFP_KERNEL);
+   if (!cpufreq_cdev->idle_time)
+   return -ENOMEM;
+
+   return 0;
+}
+
+static void free_idle_time(struct cpufreq_cooling_device *cpufreq_cdev)
+{
+   kfree(cpufreq_cdev->idle_time);
+   cpufreq_cdev->idle_time = NULL;
+}
+#endif /* CONFIG_SMP */
+
 /**
  * get_dynamic_power() - calculate the 

[PATCH V4 2/3] sched/core: Rename schedutil_cpu_util() and allow rest of the kernel to use it

2020-11-23 Thread Viresh Kumar
There is nothing schedutil specific in schedutil_cpu_util(), rename it
to effective_cpu_util(). Also create and expose another wrapper
sched_cpu_util() which can be used by other parts of the kernel, like
thermal core (that will be done in a later commit).

Signed-off-by: Viresh Kumar 
---
 include/linux/sched.h| 21 +
 kernel/sched/core.c  | 11 +--
 kernel/sched/cpufreq_schedutil.c |  2 +-
 kernel/sched/fair.c  |  6 +++---
 kernel/sched/sched.h | 19 ++-
 5 files changed, 36 insertions(+), 23 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 063cd120b459..926b944dae5e 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1926,6 +1926,27 @@ extern long sched_getaffinity(pid_t pid, struct cpumask 
*mask);
 #define TASK_SIZE_OF(tsk)  TASK_SIZE
 #endif
 
+#ifdef CONFIG_SMP
+/**
+ * enum cpu_util_type - CPU utilization type
+ * @FREQUENCY_UTIL:Utilization used to select frequency
+ * @ENERGY_UTIL:   Utilization used during energy calculation
+ *
+ * The utilization signals of all scheduling classes (CFS/RT/DL) and IRQ time
+ * need to be aggregated differently depending on the usage made of them. This
+ * enum is used within sched_cpu_util() to differentiate the types of
+ * utilization expected by the callers, and adjust the aggregation accordingly.
+ */
+enum cpu_util_type {
+   FREQUENCY_UTIL,
+   ENERGY_UTIL,
+};
+
+/* Returns effective CPU utilization, as seen by the scheduler */
+unsigned long sched_cpu_util(int cpu, enum cpu_util_type type,
+unsigned long max);
+#endif /* CONFIG_SMP */
+
 #ifdef CONFIG_RSEQ
 
 /*
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b81265aec4a0..845c976ccd53 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5138,8 +5138,8 @@ struct task_struct *idle_task(int cpu)
  * based on the task model parameters and gives the minimal utilization
  * required to meet deadlines.
  */
-unsigned long schedutil_cpu_util(int cpu, unsigned long util_cfs,
-unsigned long max, enum schedutil_type type,
+unsigned long effective_cpu_util(int cpu, unsigned long util_cfs,
+unsigned long max, enum cpu_util_type type,
 struct task_struct *p)
 {
unsigned long dl_util, util, irq;
@@ -5223,6 +5223,13 @@ unsigned long schedutil_cpu_util(int cpu, unsigned long 
util_cfs,
 
return min(max, util);
 }
+
+unsigned long sched_cpu_util(int cpu, enum cpu_util_type type,
+unsigned long max)
+{
+   return effective_cpu_util(cpu, cpu_util_cfs(cpu_rq(cpu)), max, type,
+ NULL);
+}
 #endif /* CONFIG_SMP */
 
 /**
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 2d44befb322b..e71627a3792b 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -178,7 +178,7 @@ static unsigned long sugov_get_util(struct sugov_cpu 
*sg_cpu)
sg_cpu->max = max;
sg_cpu->bw_dl = cpu_bw_dl(rq);
 
-   return schedutil_cpu_util(sg_cpu->cpu, util, max, FREQUENCY_UTIL, NULL);
+   return effective_cpu_util(sg_cpu->cpu, util, max, FREQUENCY_UTIL, NULL);
 }
 
 /**
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 290f9e38378c..0e1c8eb7ad53 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6499,7 +6499,7 @@ compute_energy(struct task_struct *p, int dst_cpu, struct 
perf_domain *pd)
 * is already enough to scale the EM reported power
 * consumption at the (eventually clamped) cpu_capacity.
 */
-   sum_util += schedutil_cpu_util(cpu, util_cfs, cpu_cap,
+   sum_util += effective_cpu_util(cpu, util_cfs, cpu_cap,
   ENERGY_UTIL, NULL);
 
/*
@@ -6509,7 +6509,7 @@ compute_energy(struct task_struct *p, int dst_cpu, struct 
perf_domain *pd)
 * NOTE: in case RT tasks are running, by default the
 * FREQUENCY_UTIL's utilization can be max OPP.
 */
-   cpu_util = schedutil_cpu_util(cpu, util_cfs, cpu_cap,
+   cpu_util = effective_cpu_util(cpu, util_cfs, cpu_cap,
  FREQUENCY_UTIL, tsk);
max_util = max(max_util, cpu_util);
}
@@ -6607,7 +6607,7 @@ static int find_energy_efficient_cpu(struct task_struct 
*p, int prev_cpu)
 * IOW, placing the task there would make the CPU
 * overutilized. Take uclamp into account to see how
 * much capacity we can get out of the CPU; this is
-* aligned with schedutil_cpu_util().
+* aligned with sched_cpu_util().
 */
 

[PATCH V4 1/3] sched/core: Move schedutil_cpu_util() to core.c

2020-11-23 Thread Viresh Kumar
There is nothing schedutil specific in schedutil_cpu_util(), move it to
core.c and define it only for CONFIG_SMP.

Signed-off-by: Viresh Kumar 
---
 kernel/sched/core.c  | 108 +++
 kernel/sched/cpufreq_schedutil.c | 106 --
 kernel/sched/sched.h |  12 +---
 3 files changed, 109 insertions(+), 117 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d2003a7d5ab5..b81265aec4a0 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5117,6 +5117,114 @@ struct task_struct *idle_task(int cpu)
return cpu_rq(cpu)->idle;
 }
 
+#ifdef CONFIG_SMP
+/*
+ * This function computes an effective utilization for the given CPU, to be
+ * used for frequency selection given the linear relation: f = u * f_max.
+ *
+ * The scheduler tracks the following metrics:
+ *
+ *   cpu_util_{cfs,rt,dl,irq}()
+ *   cpu_bw_dl()
+ *
+ * Where the cfs,rt and dl util numbers are tracked with the same metric and
+ * synchronized windows and are thus directly comparable.
+ *
+ * The cfs,rt,dl utilization are the running times measured with rq->clock_task
+ * which excludes things like IRQ and steal-time. These latter are then accrued
+ * in the irq utilization.
+ *
+ * The DL bandwidth number otoh is not a measured metric but a value computed
+ * based on the task model parameters and gives the minimal utilization
+ * required to meet deadlines.
+ */
+unsigned long schedutil_cpu_util(int cpu, unsigned long util_cfs,
+unsigned long max, enum schedutil_type type,
+struct task_struct *p)
+{
+   unsigned long dl_util, util, irq;
+   struct rq *rq = cpu_rq(cpu);
+
+   if (!uclamp_is_used() &&
+   type == FREQUENCY_UTIL && rt_rq_is_runnable(>rt)) {
+   return max;
+   }
+
+   /*
+* Early check to see if IRQ/steal time saturates the CPU, can be
+* because of inaccuracies in how we track these -- see
+* update_irq_load_avg().
+*/
+   irq = cpu_util_irq(rq);
+   if (unlikely(irq >= max))
+   return max;
+
+   /*
+* Because the time spend on RT/DL tasks is visible as 'lost' time to
+* CFS tasks and we use the same metric to track the effective
+* utilization (PELT windows are synchronized) we can directly add them
+* to obtain the CPU's actual utilization.
+*
+* CFS and RT utilization can be boosted or capped, depending on
+* utilization clamp constraints requested by currently RUNNABLE
+* tasks.
+* When there are no CFS RUNNABLE tasks, clamps are released and
+* frequency will be gracefully reduced with the utilization decay.
+*/
+   util = util_cfs + cpu_util_rt(rq);
+   if (type == FREQUENCY_UTIL)
+   util = uclamp_rq_util_with(rq, util, p);
+
+   dl_util = cpu_util_dl(rq);
+
+   /*
+* For frequency selection we do not make cpu_util_dl() a permanent part
+* of this sum because we want to use cpu_bw_dl() later on, but we need
+* to check if the CFS+RT+DL sum is saturated (ie. no idle time) such
+* that we select f_max when there is no idle time.
+*
+* NOTE: numerical errors or stop class might cause us to not quite hit
+* saturation when we should -- something for later.
+*/
+   if (util + dl_util >= max)
+   return max;
+
+   /*
+* OTOH, for energy computation we need the estimated running time, so
+* include util_dl and ignore dl_bw.
+*/
+   if (type == ENERGY_UTIL)
+   util += dl_util;
+
+   /*
+* There is still idle time; further improve the number by using the
+* irq metric. Because IRQ/steal time is hidden from the task clock we
+* need to scale the task numbers:
+*
+*  max - irq
+*   U' = irq + - * U
+* max
+*/
+   util = scale_irq_capacity(util, irq, max);
+   util += irq;
+
+   /*
+* Bandwidth required by DEADLINE must always be granted while, for
+* FAIR and RT, we use blocked utilization of IDLE CPUs as a mechanism
+* to gracefully reduce the frequency when no tasks show up for longer
+* periods of time.
+*
+* Ideally we would like to set bw_dl as min/guaranteed freq and util +
+* bw_dl as requested freq. However, cpufreq is not yet ready for such
+* an interface. So, we only do the latter for now.
+*/
+   if (type == FREQUENCY_UTIL)
+   util += cpu_bw_dl(rq);
+
+   return min(max, util);
+}
+#endif /* CONFIG_SMP */
+
 /**
  * find_process_by_pid - find a process with a matching PID value.
  * @pid: the pid in question.
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 

Re: [PATCH v2 11/19] mm/mmap: Make vm_special_mapping::mremap return void

2020-11-23 Thread Christophe Leroy




Le 24/11/2020 à 01:29, Dmitry Safonov a écrit :

Previously .mremap() callback needed (int) return to provide way to
restrict resizing of a special mapping. Now it's restricted by
providing .may_split = special_mapping_split.

Removing (int) return simplifies further changes to
special_mapping_mremap() as it won't need save ret code from the
callback. Also, it removes needless `return 0` from callbacks.

Signed-off-by: Dmitry Safonov 
---
  arch/arm/kernel/process.c | 3 +--
  arch/arm64/kernel/vdso.c  | 4 +---
  arch/mips/vdso/genvdso.c  | 3 +--
  arch/x86/entry/vdso/vma.c | 4 +---
  include/linux/mm_types.h  | 2 +-
  mm/mmap.c | 2 +-
  6 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 65df8abd90bd..95a257927dae 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -780,7 +780,7 @@ struct vm_special_mapping {
struct vm_area_struct *vma,
struct vm_fault *vmf);
  
-	int (*mremap)(const struct vm_special_mapping *sm,

+   void (*mremap)(const struct vm_special_mapping *sm,
 struct vm_area_struct *new_vma);


Second line should be aligned to first line's parenthesis I think.


  };
  
diff --git a/mm/mmap.c b/mm/mmap.c

index d0d458632c1b..17fe59a9780b 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3433,7 +3433,7 @@ static int special_mapping_mremap(struct vm_area_struct 
*new_vma,
return -EFAULT;
  
  	if (sm->mremap)

-   return sm->mremap(sm, new_vma);
+   sm->mremap(sm, new_vma);
  
  	return 0;

  }



[PATCH] net: fs_enet: Fix incorrect IS_ERR_VALUE macro usages

2020-11-23 Thread Wei Li
IS_ERR_VALUE macro should be used only with unsigned long type.
Especially it works incorrectly with unsigned shorter types on
64bit machines.

Fixes: 976de6a8c304 ("fs_enet: Be an of_platform device when 
CONFIG_PPC_CPM_NEW_BINDING is set.")
Fixes: 4c35630ccda5 ("[POWERPC] Change rheap functions to use ulongs instead of 
pointers")
Signed-off-by: Wei Li 
---
 drivers/net/ethernet/freescale/fs_enet/mac-fcc.c | 2 +-
 drivers/net/ethernet/freescale/fs_enet/mac-scc.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fs_enet/mac-fcc.c 
b/drivers/net/ethernet/freescale/fs_enet/mac-fcc.c
index b47490be872c..e2117ad46130 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mac-fcc.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mac-fcc.c
@@ -107,7 +107,7 @@ static int do_pd_setup(struct fs_enet_private *fep)
 
fep->fcc.mem = (void __iomem *)cpm2_immr;
fpi->dpram_offset = cpm_dpalloc(128, 32);
-   if (IS_ERR_VALUE(fpi->dpram_offset)) {
+   if (IS_ERR_VALUE((unsigned long)(int)fpi->dpram_offset)) {
ret = fpi->dpram_offset;
goto out_fcccp;
}
diff --git a/drivers/net/ethernet/freescale/fs_enet/mac-scc.c 
b/drivers/net/ethernet/freescale/fs_enet/mac-scc.c
index 64300ac13e02..90f82df0b1bb 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mac-scc.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mac-scc.c
@@ -136,7 +136,7 @@ static int allocate_bd(struct net_device *dev)
 
fep->ring_mem_addr = cpm_dpalloc((fpi->tx_ring + fpi->rx_ring) *
 sizeof(cbd_t), 8);
-   if (IS_ERR_VALUE(fep->ring_mem_addr))
+   if (IS_ERR_VALUE((unsigned long)(int)fep->ring_mem_addr))
return -ENOMEM;
 
fep->ring_base = (void __iomem __force*)
-- 
2.17.1



Re: [PATCH v2 09/19] s390/vdso: Remove vdso_base pointer from mm->context

2020-11-23 Thread Christophe Leroy




Le 24/11/2020 à 01:29, Dmitry Safonov a écrit :

Not used any more.


Same, what about mremap(), why can it be removed ?



Cc: Christian Borntraeger 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: linux-s...@vger.kernel.org
Signed-off-by: Dmitry Safonov 
---
  arch/s390/include/asm/mmu.h |  1 -
  arch/s390/kernel/vdso.c | 10 --
  2 files changed, 11 deletions(-)

diff --git a/arch/s390/include/asm/mmu.h b/arch/s390/include/asm/mmu.h
index e12ff0f29d1a..095d0596f700 100644
--- a/arch/s390/include/asm/mmu.h
+++ b/arch/s390/include/asm/mmu.h
@@ -15,7 +15,6 @@ typedef struct {
unsigned long gmap_asce;
unsigned long asce;
unsigned long asce_limit;
-   unsigned long vdso_base;
/* The mmu context belongs to a secure guest. */
atomic_t is_protected;
/*
diff --git a/arch/s390/kernel/vdso.c b/arch/s390/kernel/vdso.c
index 810b72f8985c..3f07711a07c1 100644
--- a/arch/s390/kernel/vdso.c
+++ b/arch/s390/kernel/vdso.c
@@ -58,18 +58,9 @@ static vm_fault_t vdso_fault(const struct vm_special_mapping 
*sm,
return 0;
  }
  
-static int vdso_mremap(const struct vm_special_mapping *sm,

-  struct vm_area_struct *vma)
-{
-   current->mm->context.vdso_base = vma->vm_start;
-
-   return 0;
-}
-
  static const struct vm_special_mapping vdso_mapping = {
.name = "[vdso]",
.fault = vdso_fault,
-   .mremap = vdso_mremap,
  };
  
  static int __init vdso_setup(char *str)

@@ -204,7 +195,6 @@ int arch_setup_additional_pages(unsigned long *sysinfo_ehdr)
goto out_up;
}
  
-	current->mm->context.vdso_base = vdso_base;

*sysinfo_ehdr = vdso_base;
rc = 0;
  



Re: [PATCH 2/2] scsi: pm8001: Fix misindentation

2020-11-23 Thread Jinpu Wang
On Tue, Nov 24, 2020 at 5:36 AM Joe Perches  wrote:
>
> kernel robot reported a misindentation of a goto.
>
> Fix it.
>
> At the same time, use a temporary for a repeated entry in the same block
> to reduce visual noise.
>
> Reported-by: kernel test robot 
> Signed-off-by: Joe Perches 
Acked-by: Jack Wang 
> ---
>  drivers/scsi/pm8001/pm8001_init.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c 
> b/drivers/scsi/pm8001/pm8001_init.c
> index 38907f45c845..17b29163c13d 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -386,17 +386,17 @@ static int pm8001_alloc(struct pm8001_hba_info 
> *pm8001_ha,
> pm8001_ha->memoryMap.region[FORENSIC_MEM].element_size = 0x1;
> pm8001_ha->memoryMap.region[FORENSIC_MEM].alignment = 0x1;
> for (i = 0; i < pm8001_ha->max_memcnt; i++) {
> +   struct mpi_mem *region = _ha->memoryMap.region[i];
> +
> if (pm8001_mem_alloc(pm8001_ha->pdev,
> -   _ha->memoryMap.region[i].virt_ptr,
> -   _ha->memoryMap.region[i].phys_addr,
> -   _ha->memoryMap.region[i].phys_addr_hi,
> -   _ha->memoryMap.region[i].phys_addr_lo,
> -   pm8001_ha->memoryMap.region[i].total_len,
> -   pm8001_ha->memoryMap.region[i].alignment) != 0) {
> -   pm8001_dbg(pm8001_ha, FAIL,
> -  "Mem%d alloc failed\n",
> -  i);
> -   goto err_out;
> +>virt_ptr,
> +>phys_addr,
> +>phys_addr_hi,
> +>phys_addr_lo,
> +region->total_len,
> +region->alignment) != 0) {
> +   pm8001_dbg(pm8001_ha, FAIL, "Mem%d alloc failed\n", 
> i);
> +   goto err_out;
> }
> }
>
> --
> 2.26.0
>


Re: [PATCH 1/2] scsi: pm8001: Convert pm8001_printk to pm8001_info

2020-11-23 Thread Jinpu Wang
On Tue, Nov 24, 2020 at 5:36 AM Joe Perches  wrote:
>
> Use the more common logging style.
>
> Signed-off-by: Joe Perches 
Acked-by: Jack Wang 
Thanks!
> ---
>  drivers/scsi/pm8001/pm8001_init.c | 12 ++--
>  drivers/scsi/pm8001/pm8001_sas.c  |  4 ++--
>  drivers/scsi/pm8001/pm8001_sas.h  |  4 ++--
>  3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c 
> b/drivers/scsi/pm8001/pm8001_init.c
> index 13530d7fb8a6..38907f45c845 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -1293,8 +1293,8 @@ static int pm8001_pci_suspend(struct pci_dev *pdev, 
> pm_message_t state)
> tasklet_kill(_ha->tasklet[j]);
>  #endif
> device_state = pci_choose_state(pdev, state);
> -   pm8001_printk(pm8001_ha, "pdev=0x%p, slot=%s, entering operating 
> state [D%d]\n",
> - pdev, pm8001_ha->name, device_state);
> +   pm8001_info(pm8001_ha, "pdev=0x%p, slot=%s, entering operating state 
> [D%d]\n",
> +   pdev, pm8001_ha->name, device_state);
> pci_save_state(pdev);
> pci_disable_device(pdev);
> pci_set_power_state(pdev, device_state);
> @@ -1318,16 +1318,16 @@ static int pm8001_pci_resume(struct pci_dev *pdev)
> pm8001_ha = sha->lldd_ha;
> device_state = pdev->current_state;
>
> -   pm8001_printk(pm8001_ha, "pdev=0x%p, slot=%s, resuming from previous 
> operating state [D%d]\n",
> - pdev, pm8001_ha->name, device_state);
> +   pm8001_info(pm8001_ha, "pdev=0x%p, slot=%s, resuming from previous 
> operating state [D%d]\n",
> +   pdev, pm8001_ha->name, device_state);
>
> pci_set_power_state(pdev, PCI_D0);
> pci_enable_wake(pdev, PCI_D0, 0);
> pci_restore_state(pdev);
> rc = pci_enable_device(pdev);
> if (rc) {
> -   pm8001_printk(pm8001_ha, "slot=%s Enable device failed during 
> resume\n",
> - pm8001_ha->name);
> +   pm8001_info(pm8001_ha, "slot=%s Enable device failed during 
> resume\n",
> +   pm8001_ha->name);
> goto err_out_enable;
> }
>
> diff --git a/drivers/scsi/pm8001/pm8001_sas.c 
> b/drivers/scsi/pm8001/pm8001_sas.c
> index 4562b0a5062a..d1e9dba2ef19 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.c
> +++ b/drivers/scsi/pm8001/pm8001_sas.c
> @@ -1191,7 +1191,7 @@ int pm8001_abort_task(struct sas_task *task)
> phy_id = pm8001_dev->attached_phy;
> ret = pm8001_find_tag(task, );
> if (ret == 0) {
> -   pm8001_printk(pm8001_ha, "no tag for task:%p\n", task);
> +   pm8001_info(pm8001_ha, "no tag for task:%p\n", task);
> return TMF_RESP_FUNC_FAILED;
> }
> spin_lock_irqsave(>task_state_lock, flags);
> @@ -1313,7 +1313,7 @@ int pm8001_abort_task(struct sas_task *task)
> task->slow_task = NULL;
> spin_unlock_irqrestore(>task_state_lock, flags);
> if (rc != TMF_RESP_FUNC_COMPLETE)
> -   pm8001_printk(pm8001_ha, "rc= %d\n", rc);
> +   pm8001_info(pm8001_ha, "rc= %d\n", rc);
> return rc;
>  }
>
> diff --git a/drivers/scsi/pm8001/pm8001_sas.h 
> b/drivers/scsi/pm8001/pm8001_sas.h
> index 5266756a268b..f2c8cbad3853 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.h
> +++ b/drivers/scsi/pm8001/pm8001_sas.h
> @@ -70,14 +70,14 @@
>  #define PM8001_DEVIO_LOGGING   0x100 /* development io message logging */
>  #define PM8001_IOERR_LOGGING   0x200 /* development io err message logging */
>
> -#define pm8001_printk(HBA, fmt, ...)   \
> +#define pm8001_info(HBA, fmt, ...) \
> pr_info("%s:: %s  %d:" fmt, \
> (HBA)->name, __func__, __LINE__, ##__VA_ARGS__)
>
>  #define pm8001_dbg(HBA, level, fmt, ...)   \
>  do {   \
> if (unlikely((HBA)->logging_level & PM8001_##level##_LOGGING))  \
> -   pm8001_printk(HBA, fmt, ##__VA_ARGS__); \
> +   pm8001_info(HBA, fmt, ##__VA_ARGS__);   \
>  } while (0)
>
>  #define PM8001_USE_TASKLET
> --
> 2.26.0
>


[PATCH] net/ethernet/freescale: Fix incorrect IS_ERR_VALUE macro usages

2020-11-23 Thread Wei Li
IS_ERR_VALUE macro should be used only with unsigned long type.
Especially it works incorrectly with unsigned shorter types on
64bit machines.

Fixes: 4c35630ccda5 ("[POWERPC] Change rheap functions to use ulongs instead of 
pointers")
Signed-off-by: Wei Li 
---
 drivers/net/ethernet/freescale/ucc_geth.c | 30 +++
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ethernet/freescale/ucc_geth.c 
b/drivers/net/ethernet/freescale/ucc_geth.c
index 714b501be7d0..8656d9be256a 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -286,7 +286,7 @@ static int fill_init_enet_entries(struct ucc_geth_private 
*ugeth,
else {
init_enet_offset =
qe_muram_alloc(thread_size, thread_alignment);
-   if (IS_ERR_VALUE(init_enet_offset)) {
+   if (IS_ERR_VALUE((unsigned long)(int)init_enet_offset)) 
{
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM 
memory\n");
qe_put_snum((u8) snum);
@@ -2223,7 +2223,7 @@ static int ucc_geth_alloc_tx(struct ucc_geth_private 
*ugeth)
ugeth->tx_bd_ring_offset[j] =
qe_muram_alloc(length,
   UCC_GETH_TX_BD_RING_ALIGNMENT);
-   if (!IS_ERR_VALUE(ugeth->tx_bd_ring_offset[j]))
+   if (!IS_ERR_VALUE((unsigned 
long)(int)ugeth->tx_bd_ring_offset[j]))
ugeth->p_tx_bd_ring[j] =
(u8 __iomem *) qe_muram_addr(ugeth->
 tx_bd_ring_offset[j]);
@@ -2300,7 +2300,7 @@ static int ucc_geth_alloc_rx(struct ucc_geth_private 
*ugeth)
ugeth->rx_bd_ring_offset[j] =
qe_muram_alloc(length,
   UCC_GETH_RX_BD_RING_ALIGNMENT);
-   if (!IS_ERR_VALUE(ugeth->rx_bd_ring_offset[j]))
+   if (!IS_ERR_VALUE((unsigned 
long)(int)ugeth->rx_bd_ring_offset[j]))
ugeth->p_rx_bd_ring[j] =
(u8 __iomem *) qe_muram_addr(ugeth->
 rx_bd_ring_offset[j]);
@@ -2510,7 +2510,7 @@ static int ucc_geth_startup(struct ucc_geth_private 
*ugeth)
ugeth->tx_glbl_pram_offset =
qe_muram_alloc(sizeof(struct ucc_geth_tx_global_pram),
   UCC_GETH_TX_GLOBAL_PRAM_ALIGNMENT);
-   if (IS_ERR_VALUE(ugeth->tx_glbl_pram_offset)) {
+   if (IS_ERR_VALUE((unsigned long)(int)ugeth->tx_glbl_pram_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for 
p_tx_glbl_pram\n");
return -ENOMEM;
@@ -2530,7 +2530,7 @@ static int ucc_geth_startup(struct ucc_geth_private 
*ugeth)
   sizeof(struct ucc_geth_thread_data_tx) +
   32 * (numThreadsTxNumerical == 1),
   UCC_GETH_THREAD_DATA_ALIGNMENT);
-   if (IS_ERR_VALUE(ugeth->thread_dat_tx_offset)) {
+   if (IS_ERR_VALUE((unsigned long)(int)ugeth->thread_dat_tx_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for 
p_thread_data_tx\n");
return -ENOMEM;
@@ -2557,7 +2557,7 @@ static int ucc_geth_startup(struct ucc_geth_private 
*ugeth)
qe_muram_alloc(ug_info->numQueuesTx *
   sizeof(struct ucc_geth_send_queue_qd),
   UCC_GETH_SEND_QUEUE_QUEUE_DESCRIPTOR_ALIGNMENT);
-   if (IS_ERR_VALUE(ugeth->send_q_mem_reg_offset)) {
+   if (IS_ERR_VALUE((unsigned long)(int)ugeth->send_q_mem_reg_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for 
p_send_q_mem_reg\n");
return -ENOMEM;
@@ -2597,7 +2597,7 @@ static int ucc_geth_startup(struct ucc_geth_private 
*ugeth)
ugeth->scheduler_offset =
qe_muram_alloc(sizeof(struct ucc_geth_scheduler),
   UCC_GETH_SCHEDULER_ALIGNMENT);
-   if (IS_ERR_VALUE(ugeth->scheduler_offset)) {
+   if (IS_ERR_VALUE((unsigned long)(int)ugeth->scheduler_offset)) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for 
p_scheduler\n");
return -ENOMEM;
@@ -2644,7 +2644,7 @@ static int ucc_geth_startup(struct ucc_geth_private 
*ugeth)
qe_muram_alloc(sizeof
   (struct 
ucc_geth_tx_firmware_statistics_pram),
   

Re: [PATCH v2 08/19] arm/vdso: Remove vdso pointer from mm->context

2020-11-23 Thread Christophe Leroy




Le 24/11/2020 à 01:29, Dmitry Safonov a écrit :

Not used any more.


But what about mremap() ? Maybe you should explain why you can remove it ?



Signed-off-by: Dmitry Safonov 
---
  arch/arm/include/asm/mmu.h |  3 ---
  arch/arm/kernel/vdso.c | 12 
  2 files changed, 15 deletions(-)

diff --git a/arch/arm/include/asm/mmu.h b/arch/arm/include/asm/mmu.h
index 1592a4264488..2397b0a19f59 100644
--- a/arch/arm/include/asm/mmu.h
+++ b/arch/arm/include/asm/mmu.h
@@ -12,9 +12,6 @@ typedef struct {
  #endif
unsigned intvmalloc_seq;
unsigned long   sigpage;
-#ifdef CONFIG_VDSO
-   unsigned long   vdso;
-#endif
  #ifdef CONFIG_BINFMT_ELF_FDPIC
unsigned long   exec_fdpic_loadmap;
unsigned long   interp_fdpic_loadmap;
diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
index 710e5ca99a53..4b39c7d8f525 100644
--- a/arch/arm/kernel/vdso.c
+++ b/arch/arm/kernel/vdso.c
@@ -47,17 +47,8 @@ static const struct vm_special_mapping vdso_data_mapping = {
.pages = _data_page,
  };
  
-static int vdso_mremap(const struct vm_special_mapping *sm,

-   struct vm_area_struct *new_vma)
-{
-   current->mm->context.vdso = new_vma->vm_start;
-
-   return 0;
-}
-
  static struct vm_special_mapping vdso_text_mapping __ro_after_init = {
.name = "[vdso]",
-   .mremap = vdso_mremap,
  };
  
  struct elfinfo {

@@ -239,8 +230,6 @@ void arm_install_vdso(struct mm_struct *mm, unsigned long 
addr,
struct vm_area_struct *vma;
unsigned long len;
  
-	mm->context.vdso = 0;

-
if (vdso_text_pagelist == NULL)
return;
  
@@ -258,7 +247,6 @@ void arm_install_vdso(struct mm_struct *mm, unsigned long addr,

if (IS_ERR(vma))
return;
  
-	mm->context.vdso = addr;

*sysinfo_ehdr = addr;
  }
  



Re: [PATCH v2 06/19] elf/vdso: Reuse arch_setup_additional_pages() parameters

2020-11-23 Thread Christophe Leroy

"Reuse arch_setup_additional_pages() parameters"

Did you mean "remove" ? Or "Revise" ?

Maybe could be:

"Modify arch_setup_additional_pages() parameters"


Le 24/11/2020 à 01:29, Dmitry Safonov a écrit :

Both parameters of arch_setup_additional_pages() are currently unused.
commit fc5243d98ac2 ("[S390] arch_setup_additional_pages arguments")
tried to introduce useful arguments, but they still are not used.

Remove old parameters and introduce sysinfo_ehdr argument that will be
used to return vdso address to put as AT_SYSINFO_EHDR tag in auxiliary
vector. The reason to add this parameter is that many architecture
have vDSO pointer saved in their mm->context with the only purpose
to use it later in ARCH_DLINFO. That's the macro for elf loader
to setup sysinfo_ehdr tag.

Return sysinfo_ehdr address that will be later used by ARCH_DLINFO as
an argument. That will allow to drop vDSO pointer from mm->context
and any code responsible to track vDSO position on platforms that
don't use vDSO as a landing in userspace (arm/s390/sparc).

Cc: Albert Ou 
Cc: "David S. Miller" 
Cc: Palmer Dabbelt 
Cc: Paul Walmsley 
Cc: linux-fsde...@vger.kernel.org
Signed-off-by: Dmitry Safonov 
---
  arch/arm/include/asm/vdso.h|  6 --
  arch/arm/kernel/process.c  |  4 ++--
  arch/arm/kernel/vdso.c | 10 +++---
  arch/arm64/kernel/vdso.c   | 17 
  arch/csky/kernel/vdso.c|  3 ++-
  arch/hexagon/kernel/vdso.c |  3 ++-
  arch/mips/kernel/vdso.c|  3 ++-
  arch/nds32/kernel/vdso.c   |  3 ++-
  arch/nios2/mm/init.c   |  2 +-
  arch/powerpc/kernel/vdso.c |  3 ++-
  arch/riscv/kernel/vdso.c   | 11 +-
  arch/s390/kernel/vdso.c|  3 ++-
  arch/sh/kernel/vsyscall/vsyscall.c |  3 ++-
  arch/sparc/vdso/vma.c  | 15 +++---
  arch/x86/entry/vdso/vma.c  | 32 +-
  arch/x86/um/vdso/vma.c |  2 +-
  fs/binfmt_elf.c|  3 ++-
  fs/binfmt_elf_fdpic.c  |  3 ++-
  include/linux/elf.h| 17 +++-
  19 files changed, 85 insertions(+), 58 deletions(-)

diff --git a/arch/arm/include/asm/vdso.h b/arch/arm/include/asm/vdso.h
index 5b85889f82ee..6b2b3b1fe833 100644
--- a/arch/arm/include/asm/vdso.h
+++ b/arch/arm/include/asm/vdso.h
@@ -10,13 +10,15 @@ struct mm_struct;
  
  #ifdef CONFIG_VDSO
  
-void arm_install_vdso(struct mm_struct *mm, unsigned long addr);

+void arm_install_vdso(struct mm_struct *mm, unsigned long addr,
+ unsigned long *sysinfo_ehdr);
  
  extern unsigned int vdso_total_pages;
  
  #else /* CONFIG_VDSO */
  
-static inline void arm_install_vdso(struct mm_struct *mm, unsigned long addr)

+static inline void arm_install_vdso(struct mm_struct *mm, unsigned long addr,
+   unsigned long *sysinfo_ehdr)
  {
  }
  
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c

index d0220da1d1b1..0e90cba8ac7a 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -389,7 +389,7 @@ static const struct vm_special_mapping sigpage_mapping = {
.mremap = sigpage_mremap,
  };
  
-int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)

+int arch_setup_additional_pages(unsigned long *sysinfo_ehdr)
  {
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
@@ -430,7 +430,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
 * to be fatal to the process, so no error check needed
 * here.
 */
-   arm_install_vdso(mm, addr + PAGE_SIZE);
+   arm_install_vdso(mm, addr + PAGE_SIZE, sysinfo_ehdr);
  
   up_fail:

mmap_write_unlock(mm);
diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
index 3408269d19c7..710e5ca99a53 100644
--- a/arch/arm/kernel/vdso.c
+++ b/arch/arm/kernel/vdso.c
@@ -233,7 +233,8 @@ static int install_vvar(struct mm_struct *mm, unsigned long 
addr)
  }
  
  /* assumes mmap_lock is write-locked */

-void arm_install_vdso(struct mm_struct *mm, unsigned long addr)
+void arm_install_vdso(struct mm_struct *mm, unsigned long addr,
+ unsigned long *sysinfo_ehdr)
  {
struct vm_area_struct *vma;
unsigned long len;
@@ -254,7 +255,10 @@ void arm_install_vdso(struct mm_struct *mm, unsigned long 
addr)
VM_READ | VM_EXEC | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC,
_text_mapping);
  
-	if (!IS_ERR(vma))

-   mm->context.vdso = addr;
+   if (IS_ERR(vma))
+   return;
+
+   mm->context.vdso = addr;
+   *sysinfo_ehdr = addr;
  }
  
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c

index 1b710deb84d6..666338724a07 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -213,8 +213,7 @@ static vm_fault_t vvar_fault(const struct 
vm_special_mapping *sm,
  
  static int 

[PATCH v2 2/2] arm64: dts: qcom: sc7180: Add DDR/L3 votes for the pro variant

2020-11-23 Thread Sibi Sankar
Add DDR/L3 bandwidth votes for the pro variant of SC7180 SoC, as it support
frequencies upto 2.5 GHz.

Signed-off-by: Sibi Sankar 
---
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 625e922c273d..05bc10a4c84d 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -527,6 +527,11 @@
opp-hz = /bits/ 64 <24>;
opp-peak-kBps = <8532000 23347200>;
};
+
+   cpu6_opp16: opp-255360 {
+   opp-hz = /bits/ 64 <255360>;
+   opp-peak-kBps = <8532000 23347200>;
+   };
};
 
memory@8000 {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v2 1/2] arm64: dts: qcom: sc7180-lite: Tweak DDR/L3 scaling on SC7180-lite

2020-11-23 Thread Sibi Sankar
Tweak the DDR/L3 bandwidth votes on the lite variant of the SC7180 SoC
since the gold cores only support frequencies upto 2.1 GHz.

Signed-off-by: Sibi Sankar 
---

V2:
 * Updated the lite ddr/l3 cpufreq map to have better power numbers with
   similar perf.

 arch/arm64/boot/dts/qcom/sc7180-lite.dtsi | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-lite.dtsi

diff --git a/arch/arm64/boot/dts/qcom/sc7180-lite.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180-lite.dtsi
new file mode 100644
index ..d8ed1d7b4ec7
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sc7180-lite.dtsi
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * SC7180 lite device tree source
+ *
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+_opp10 {
+   opp-peak-kBps = <7216000 22425600>;
+};
+
+_opp11 {
+   opp-peak-kBps = <7216000 22425600>;
+};
+
+_opp12 {
+   opp-peak-kBps = <8532000 23347200>;
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH kernel v4 8/8] powerpc/pci: Remove LSI mappings on device teardown

2020-11-23 Thread Alexey Kardashevskiy
From: Oliver O'Halloran 

When a passthrough IO adapter is removed from a pseries machine using hash
MMU and the XIVE interrupt mode, the POWER hypervisor expects the guest OS
to clear all page table entries related to the adapter. If some are still
present, the RTAS call which isolates the PCI slot returns error 9001
"valid outstanding translations" and the removal of the IO adapter fails.
This is because when the PHBs are scanned, Linux maps automatically the
INTx interrupts in the Linux interrupt number space but these are never
removed.

This problem can be fixed by adding the corresponding unmap operation when
the device is removed. There's no pcibios_* hook for the remove case, but
the same effect can be achieved using a bus notifier.

Signed-off-by: Oliver O'Halloran 
Reviewed-by: Cédric Le Goater 
Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/kernel/pci-common.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index be108616a721..95f4e173368a 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -404,6 +404,27 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
return 0;
 }
 
+static int ppc_pci_unmap_irq_line(struct notifier_block *nb,
+  unsigned long action, void *data)
+{
+   struct pci_dev *pdev = to_pci_dev(data);
+
+   if (action == BUS_NOTIFY_DEL_DEVICE)
+   irq_dispose_mapping(pdev->irq);
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block ppc_pci_unmap_irq_notifier = {
+   .notifier_call = ppc_pci_unmap_irq_line,
+};
+
+static int ppc_pci_register_irq_notifier(void)
+{
+   return bus_register_notifier(_bus_type, 
_pci_unmap_irq_notifier);
+}
+arch_initcall(ppc_pci_register_irq_notifier);
+
 /*
  * Platform support for /proc/bus/pci/X/Y mmap()s.
  *  -- paulus.
-- 
2.17.1



[PATCH kernel v4 5/8] genirq: Add free_irq hook for IRQ descriptor and use for mapping disposal

2020-11-23 Thread Alexey Kardashevskiy
We want to make the irq_desc.kobj's release hook free associated resources
but we do not want to pollute the irqdesc code with domains.

This adds a free_irq hook which is called when the last reference to
the descriptor is dropped.

The first user is mapped irqs. This potentially can break the existing
users; however they seem to do the right thing and call dispose once
per mapping.

Signed-off-by: Alexey Kardashevskiy 
---
 include/linux/irqdesc.h|  1 +
 include/linux/irqdomain.h  |  2 --
 include/linux/irqhandler.h |  1 +
 kernel/irq/irqdesc.c   |  3 +++
 kernel/irq/irqdomain.c | 14 --
 5 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h
index 5745491303e0..6d44cb6a20ad 100644
--- a/include/linux/irqdesc.h
+++ b/include/linux/irqdesc.h
@@ -57,6 +57,7 @@ struct irq_desc {
struct irq_data irq_data;
unsigned int __percpu   *kstat_irqs;
irq_flow_handler_t  handle_irq;
+   irq_free_handler_t  free_irq;
struct irqaction*action;/* IRQ action list */
unsigned intstatus_use_accessors;
unsigned intcore_internal_state__do_not_mess_with_it;
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index a353b93ddf9e..ccca87cd3d15 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -381,8 +381,6 @@ extern int irq_domain_associate(struct irq_domain *domain, 
unsigned int irq,
 extern void irq_domain_associate_many(struct irq_domain *domain,
  unsigned int irq_base,
  irq_hw_number_t hwirq_base, int count);
-extern void irq_domain_disassociate(struct irq_domain *domain,
-   unsigned int irq);
 
 extern unsigned int irq_create_mapping(struct irq_domain *host,
   irq_hw_number_t hwirq);
diff --git a/include/linux/irqhandler.h b/include/linux/irqhandler.h
index c30f454a9518..3dbc2bb764f3 100644
--- a/include/linux/irqhandler.h
+++ b/include/linux/irqhandler.h
@@ -10,5 +10,6 @@
 struct irq_desc;
 struct irq_data;
 typedefvoid (*irq_flow_handler_t)(struct irq_desc *desc);
+typedefvoid (*irq_free_handler_t)(struct irq_desc *desc);
 
 #endif
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 75374b7944b5..071363da8688 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -427,6 +427,9 @@ static void irq_kobj_release(struct kobject *kobj)
struct irq_desc *desc = container_of(kobj, struct irq_desc, kobj);
unsigned int irq = desc->irq_data.irq;
 
+   if (desc->free_irq)
+   desc->free_irq(desc);
+
irq_remove_debugfs_entry(desc);
unregister_irq_proc(irq, desc);
 
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 805478f81d96..4779d912bb86 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -485,7 +485,7 @@ static void irq_domain_set_mapping(struct irq_domain 
*domain,
}
 }
 
-void irq_domain_disassociate(struct irq_domain *domain, unsigned int irq)
+static void irq_domain_disassociate(struct irq_domain *domain, unsigned int 
irq)
 {
struct irq_data *irq_data = irq_get_irq_data(irq);
irq_hw_number_t hwirq;
@@ -582,6 +582,13 @@ void irq_domain_associate_many(struct irq_domain *domain, 
unsigned int irq_base,
 }
 EXPORT_SYMBOL_GPL(irq_domain_associate_many);
 
+static void irq_mapped_free_desc(struct irq_desc *desc)
+{
+   unsigned int virq = desc->irq_data.irq;
+
+   irq_domain_disassociate(desc->irq_data.domain, virq);
+}
+
 /**
  * irq_create_direct_mapping() - Allocate an irq for direct mapping
  * @domain: domain to allocate the irq for or NULL for default domain
@@ -638,6 +645,7 @@ unsigned int irq_create_mapping(struct irq_domain *domain,
 {
struct device_node *of_node;
int virq;
+   struct irq_desc *desc;
 
pr_debug("irq_create_mapping(0x%p, 0x%lx)\n", domain, hwirq);
 
@@ -674,6 +682,9 @@ unsigned int irq_create_mapping(struct irq_domain *domain,
pr_debug("irq %lu on domain %s mapped to virtual irq %u\n",
hwirq, of_node_full_name(of_node), virq);
 
+   desc = irq_to_desc(virq);
+   desc->free_irq = irq_mapped_free_desc;
+
return virq;
 }
 EXPORT_SYMBOL_GPL(irq_create_mapping);
@@ -865,7 +876,6 @@ void irq_dispose_mapping(unsigned int virq)
if (irq_domain_is_hierarchy(domain)) {
irq_domain_free_irqs(virq, 1);
} else {
-   irq_domain_disassociate(domain, virq);
irq_free_desc(virq);
}
 }
-- 
2.17.1



[PATCH kernel v4 4/8] genirq: Free IRQ descriptor via embedded kobject

2020-11-23 Thread Alexey Kardashevskiy
At the moment the IRQ descriptor is freed via the free_desc() helper.
We want to add reference counting to IRQ descriptors and there is already
kobj embedded into irq_desc which we want to reuse.

This shuffles free_desc()/etc to make it simply call kobject_put() and
moves all the cleanup into the kobject_release hook.

As a bonus, we do not need irq_sysfs_del() as kobj removes itself from
sysfs if it knows that it was added.

This should cause no behavioral change.

Signed-off-by: Alexey Kardashevskiy 
---
 kernel/irq/irqdesc.c | 42 --
 1 file changed, 12 insertions(+), 30 deletions(-)

diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 1a7723604399..75374b7944b5 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -295,18 +295,6 @@ static void irq_sysfs_add(int irq, struct irq_desc *desc)
}
 }
 
-static void irq_sysfs_del(struct irq_desc *desc)
-{
-   /*
-* If irq_sysfs_init() has not yet been invoked (early boot), then
-* irq_kobj_base is NULL and the descriptor was never added.
-* kobject_del() complains about a object with no parent, so make
-* it conditional.
-*/
-   if (irq_kobj_base)
-   kobject_del(>kobj);
-}
-
 static int __init irq_sysfs_init(void)
 {
struct irq_desc *desc;
@@ -337,7 +325,6 @@ static struct kobj_type irq_kobj_type = {
 };
 
 static void irq_sysfs_add(int irq, struct irq_desc *desc) {}
-static void irq_sysfs_del(struct irq_desc *desc) {}
 
 #endif /* CONFIG_SYSFS */
 
@@ -419,39 +406,34 @@ static struct irq_desc *alloc_desc(int irq, int node, 
unsigned int flags,
return NULL;
 }
 
-static void irq_kobj_release(struct kobject *kobj)
-{
-   struct irq_desc *desc = container_of(kobj, struct irq_desc, kobj);
-
-   free_masks(desc);
-   free_percpu(desc->kstat_irqs);
-   kfree(desc);
-}
-
 static void delayed_free_desc(struct rcu_head *rhp)
 {
struct irq_desc *desc = container_of(rhp, struct irq_desc, rcu);
 
+   free_masks(desc);
+   free_percpu(desc->kstat_irqs);
+   kfree(desc);
+}
+
+static void free_desc(unsigned int irq)
+{
+   struct irq_desc *desc = irq_to_desc(irq);
+
kobject_put(>kobj);
 }
 
-static void free_desc(unsigned int irq)
+static void irq_kobj_release(struct kobject *kobj)
 {
-   struct irq_desc *desc = irq_to_desc(irq);
+   struct irq_desc *desc = container_of(kobj, struct irq_desc, kobj);
+   unsigned int irq = desc->irq_data.irq;
 
irq_remove_debugfs_entry(desc);
unregister_irq_proc(irq, desc);
 
/*
-* sparse_irq_lock protects also show_interrupts() and
-* kstat_irq_usr(). Once we deleted the descriptor from the
-* sparse tree we can free it. Access in proc will fail to
-* lookup the descriptor.
-*
 * The sysfs entry must be serialized against a concurrent
 * irq_sysfs_init() as well.
 */
-   irq_sysfs_del(desc);
delete_irq_desc(irq);
 
/*
-- 
2.17.1



RE: [EXTERNAL] Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken

2020-11-23 Thread Merger, Edgar [AUTOSOL/MAS/AUGS]
This is a board developed by my company.
Subsystem-ID is ea50:0c19 or ea50:cc10 (depending on which particular carrier 
board the compute module is attached to), however we haven´t managed yet to 
enter this Subsystem-ID to every PCI-Device in the system, because of missing 
means to do that by our UEFI-FW. This might will change if we update to latest 
AGESA version. 

-Original Message-
From: Will Deacon  
Sent: Montag, 23. November 2020 23:34
To: Deucher, Alexander 
Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; 
io...@lists.linux-foundation.org; Bjorn Helgaas ; Merger, 
Edgar [AUTOSOL/MAS/AUGS] ; Joerg Roedel 
; Kuehling, Felix 
Subject: [EXTERNAL] Re: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken

On Mon, Nov 23, 2020 at 09:04:14PM +, Deucher, Alexander wrote:
> [AMD Public Use]
> 
> > -Original Message-
> > From: Will Deacon 
> > Sent: Monday, November 23, 2020 8:44 AM
> > To: linux-kernel@vger.kernel.org
> > Cc: linux-...@vger.kernel.org; io...@lists.linux-foundation.org; 
> > Will Deacon ; Bjorn Helgaas ; 
> > Deucher, Alexander ; Edgar Merger 
> > ; Joerg Roedel 
> > Subject: [PATCH] PCI: Mark AMD Raven iGPU ATS as broken
> > 
> > Edgar Merger reports that the AMD Raven GPU does not work reliably 
> > on his system when the IOMMU is enabled:
> > 
> >   | [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, 
> > signaled seq=1, emitted seq=3
> >   | [...]
> >   | amdgpu :0b:00.0: GPU reset begin!
> >   | AMD-Vi: Completion-Wait loop timed out
> >   | iommu ivhd0: AMD-Vi: Event logged [IOTLB_INV_TIMEOUT
> > device=0b:00.0 address=0x38edc0970]
> > 
> > This is indicative of a hardware/platform configuration issue so, 
> > since disabling ATS has been shown to resolve the problem, add a 
> > quirk to match this particular device while Edgar follows-up with AMD for 
> > more information.
> > 
> > Cc: Bjorn Helgaas 
> > Cc: Alex Deucher 
> > Reported-by: Edgar Merger 
> > Suggested-by: Joerg Roedel 
> > Link:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__nam11.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Flore=DwIBAg=jOURTkCZzT8tVB5xPEYIm3YJGoxoTaQsQPzPKJGaWbo=BJxhacqqa4K1PJGm6_-862rdSP13_P6LVp7j_9l1xmg=WjiRGepDgI7voSyaAJcvnvZb6gsvZ1fvcnR2tm6bGXg=O1nU-RafBXMAS7Mao5Gtu6o1Xkuj8fg4oHQs74TssuA=
> >  .
> > kernel.org%2Flinux-
> > iommu%2FMWHPR10MB1310F042A30661D4158520B589FC0%40MWHPR10M
> > B1310.namprd10.prod.outlook.comdata=04%7C01%7Calexander.deuc
> > her%40amd.com%7C1a883fe14d0c408e7d9508d88fb5df4e%7C3dd8961fe488
> > 4e608e11a82d994e183d%7C0%7C0%7C637417358593629699%7CUnknown%7
> > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> > LCJXVCI6Mn0%3D%7C1000sdata=TMgKldWzsX8XZ0l7q3%2BszDWXQJJ
> > LOUfX5oGaoLN8n%2B8%3Dreserved=0
> > Signed-off-by: Will Deacon 
> > ---
> > 
> > Hi all,
> > 
> > Since Joerg is away at the moment, I'm posting this to try to make 
> > some progress with the thread in the Link: tag.
> 
> + Felix
> 
> What system is this?  Can you provide more details?  Does a sbios 
> update fix this?  Disabling ATS for all Ravens will break GPU compute 
> for a lot of people.  I'd prefer to just black list this particular 
> system (e.g., just SSIDs or revision) if possible.

Cheers, Alex. I'll have to defer to Edgar for the details, as my understanding 
from the original thread over at:

https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_linux-2Diommu_MWHPR10MB1310CDB6829DDCF5EA84A14689150-40MWHPR10MB1310.namprd10.prod.outlook.com_=DwIBAg=jOURTkCZzT8tVB5xPEYIm3YJGoxoTaQsQPzPKJGaWbo=BJxhacqqa4K1PJGm6_-862rdSP13_P6LVp7j_9l1xmg=WjiRGepDgI7voSyaAJcvnvZb6gsvZ1fvcnR2tm6bGXg=9qyuCqHeOGaY1sKjkzNN5A6ks6PNF7V2M2PPckHyFKk=
 

is that this is a board developed by his company.

Edgar -- please can you answer Alex's questions?

Will


[PATCH kernel v4 7/8] genirq/irqdomain: Reference irq_desc for already mapped irqs

2020-11-23 Thread Alexey Kardashevskiy
This references an irq_desc if already mapped interrupt requested to map
again. This happends for PCI legacy interrupts where 4 interrupts are
shared among all devices on the same PCI host bus adapter.

>From now on, the users shall call irq_dispose_mapping() for every
irq_create_fwspec_mapping(). Most (all?) users do not bother with
disposing though so it is not very likely to break many things.

Signed-off-by: Alexey Kardashevskiy 
---
 kernel/irq/irqdomain.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index a0a81cc6c524..07f4bde87de5 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -663,7 +663,9 @@ unsigned int irq_create_mapping(struct irq_domain *domain,
/* Check if mapping already exists */
virq = irq_find_mapping(domain, hwirq);
if (virq) {
+   desc = irq_to_desc(virq);
pr_debug("-> existing mapping on virq %d\n", virq);
+   kobject_get(>kobj);
return virq;
}
 
@@ -762,6 +764,7 @@ unsigned int irq_create_fwspec_mapping(struct irq_fwspec 
*fwspec)
irq_hw_number_t hwirq;
unsigned int type = IRQ_TYPE_NONE;
int virq;
+   struct irq_desc *desc;
 
if (fwspec->fwnode) {
domain = irq_find_matching_fwspec(fwspec, DOMAIN_BUS_WIRED);
@@ -798,8 +801,11 @@ unsigned int irq_create_fwspec_mapping(struct irq_fwspec 
*fwspec)
 * current trigger type then we are done so return the
 * interrupt number.
 */
-   if (type == IRQ_TYPE_NONE || type == irq_get_trigger_type(virq))
+   if (type == IRQ_TYPE_NONE || type == 
irq_get_trigger_type(virq)) {
+   desc = irq_to_desc(virq);
+   kobject_get(>kobj);
return virq;
+   }
 
/*
 * If the trigger type has not been set yet, then set
@@ -811,6 +817,8 @@ unsigned int irq_create_fwspec_mapping(struct irq_fwspec 
*fwspec)
return 0;
 
irqd_set_trigger_type(irq_data, type);
+   desc = irq_to_desc(virq);
+   kobject_get(>kobj);
return virq;
}
 
-- 
2.17.1



[PATCH kernel v4 1/8] genirq/ipi: Simplify irq_reserve_ipi

2020-11-23 Thread Alexey Kardashevskiy
__irq_domain_alloc_irqs() can already handle virq==-1 and free
descriptors if it failed allocating hardware interrupts so let's skip
this extra step.

Signed-off-by: Alexey Kardashevskiy 
---
 kernel/irq/ipi.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/kernel/irq/ipi.c b/kernel/irq/ipi.c
index 43e3d1be622c..1b2807318ea9 100644
--- a/kernel/irq/ipi.c
+++ b/kernel/irq/ipi.c
@@ -75,18 +75,12 @@ int irq_reserve_ipi(struct irq_domain *domain,
}
}
 
-   virq = irq_domain_alloc_descs(-1, nr_irqs, 0, NUMA_NO_NODE, NULL);
-   if (virq <= 0) {
-   pr_warn("Can't reserve IPI, failed to alloc descs\n");
-   return -ENOMEM;
-   }
-
-   virq = __irq_domain_alloc_irqs(domain, virq, nr_irqs, NUMA_NO_NODE,
-  (void *) dest, true, NULL);
+   virq = __irq_domain_alloc_irqs(domain, -1, nr_irqs, NUMA_NO_NODE,
+  (void *) dest, false, NULL);
 
if (virq <= 0) {
pr_warn("Can't reserve IPI, failed to alloc hw irqs\n");
-   goto free_descs;
+   return -EBUSY;
}
 
for (i = 0; i < nr_irqs; i++) {
@@ -96,10 +90,6 @@ int irq_reserve_ipi(struct irq_domain *domain,
irq_set_status_flags(virq + i, IRQ_NO_BALANCING);
}
return virq;
-
-free_descs:
-   irq_free_descs(virq, nr_irqs);
-   return -EBUSY;
 }
 
 /**
-- 
2.17.1



[PATCH kernel v4 6/8] genirq/irqdomain: Move hierarchical IRQ cleanup to kobject_release

2020-11-23 Thread Alexey Kardashevskiy
This moves hierarchical domain's irqs cleanup into the kobject release
hook to make irq_domain_free_irqs() as simple as kobject_put.

Signed-off-by: Alexey Kardashevskiy 
---
 kernel/irq/irqdomain.c | 43 +-
 1 file changed, 22 insertions(+), 21 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 4779d912bb86..a0a81cc6c524 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -863,21 +863,9 @@ EXPORT_SYMBOL_GPL(irq_create_of_mapping);
  */
 void irq_dispose_mapping(unsigned int virq)
 {
-   struct irq_data *irq_data = irq_get_irq_data(virq);
-   struct irq_domain *domain;
+   struct irq_desc *desc = irq_to_desc(virq);
 
-   if (!virq || !irq_data)
-   return;
-
-   domain = irq_data->domain;
-   if (WARN_ON(domain == NULL))
-   return;
-
-   if (irq_domain_is_hierarchy(domain)) {
-   irq_domain_free_irqs(virq, 1);
-   } else {
-   irq_free_desc(virq);
-   }
+   kobject_put(>kobj);
 }
 EXPORT_SYMBOL_GPL(irq_dispose_mapping);
 
@@ -1396,6 +1384,19 @@ int irq_domain_alloc_irqs_hierarchy(struct irq_domain 
*domain,
return domain->ops->alloc(domain, irq_base, nr_irqs, arg);
 }
 
+static void irq_domain_hierarchy_free_desc(struct irq_desc *desc)
+{
+   unsigned int virq = desc->irq_data.irq;
+   struct irq_data *data = irq_get_irq_data(virq);
+
+   mutex_lock(_domain_mutex);
+   irq_domain_remove_irq(virq);
+   irq_domain_free_irqs_hierarchy(data->domain, virq, 1);
+   mutex_unlock(_domain_mutex);
+
+   irq_domain_free_irq_data(virq, 1);
+}
+
 int __irq_domain_alloc_irqs_data(struct irq_domain *domain, int virq,
 unsigned int nr_irqs, int node, void *arg,
 const struct irq_affinity_desc *affinity)
@@ -1430,7 +1431,10 @@ int __irq_domain_alloc_irqs_data(struct irq_domain 
*domain, int virq,
}
 
for (i = 0; i < nr_irqs; i++) {
+   struct irq_desc *desc = irq_to_desc(virq + i);
+
irq_domain_insert_irq(virq + i);
+   desc->free_irq = irq_domain_hierarchy_free_desc;
}
mutex_unlock(_domain_mutex);
 
@@ -1675,14 +1679,11 @@ void irq_domain_free_irqs(unsigned int virq, unsigned 
int nr_irqs)
 "NULL pointer, cannot free irq\n"))
return;
 
-   mutex_lock(_domain_mutex);
-   for (i = 0; i < nr_irqs; i++)
-   irq_domain_remove_irq(virq + i);
-   irq_domain_free_irqs_hierarchy(data->domain, virq, nr_irqs);
-   mutex_unlock(_domain_mutex);
+   for (i = 0; i < nr_irqs; i++) {
+   struct irq_desc *desc = irq_to_desc(virq + i);
 
-   irq_domain_free_irq_data(virq, nr_irqs);
-   irq_free_descs(virq, nr_irqs);
+   kobject_put(>kobj);
+   }
 }
 
 /**
-- 
2.17.1



[PATCH kernel v4 0/8] genirq/irqdomain: Add reference counting to IRQs

2020-11-23 Thread Alexey Kardashevskiy
This is another attempt to add reference counting to IRQ
descriptors; or - more to the point - reuse already existing
kobj from irq_desc. This allows the same IRQ to be used several
times (such as legacy PCI INTx) and when disposing those, only
the last reference drop clears the hardware mappings.
Domains do not add references to irq_desc as the whole point of
this exercise is to move actual cleanup in hardware to
the last reference drop. This only changes sparse interrupts
(no idea about the other case yet).

No changelog as it is all completely rewritten. I am still running
tests but I hope this demonstrates the idea.

Some context from Cedric:
The background context for such a need is that the POWER9 and POWER10
processors have a new XIVE interrupt controller which uses MMIO pages
for interrupt management. Each interrupt has a pair of pages which are
required to be unmapped in some environment, like PHB removal. And so,
all interrupts need to be unmmaped.

1/8 .. 3/8 are removing confusing "realloc" which not strictly required
but I was touching this anyway and legacy interrupts should probably use
the new counting anyway;

4/8 .. 6/8 is reordering irq_desc disposal;

7/8 adds extra references (probably missed other places);

8/8 is the fix for the original XIVE bug; it is here for demonstration.

I am cc'ing ppc list so people can pull the patches from that patchworks.

This is based on sha1
418baf2c28f3 Linus Torvalds "Linux 5.10-rc5".

and pushed out to
https://github.com/aik/linux/commits/irqs
sha1 3955f97c448242f6a

Please comment. Thanks.


Alexey Kardashevskiy (7):
  genirq/ipi:  Simplify irq_reserve_ipi
  genirq/irqdomain: Clean legacy IRQ allocation
  genirq/irqdomain: Drop unused realloc parameter from
__irq_domain_alloc_irqs
  genirq: Free IRQ descriptor via embedded kobject
  genirq: Add free_irq hook for IRQ descriptor and use for mapping
disposal
  genirq/irqdomain: Move hierarchical IRQ cleanup to kobject_release
  genirq/irqdomain: Reference irq_desc for already mapped irqs

Oliver O'Halloran (1):
  powerpc/pci: Remove LSI mappings on device teardown

 include/linux/irqdesc.h |   1 +
 include/linux/irqdomain.h   |   9 +-
 include/linux/irqhandler.h  |   1 +
 arch/powerpc/kernel/pci-common.c|  21 
 arch/x86/kernel/apic/io_apic.c  |  13 ++-
 drivers/gpio/gpiolib.c  |   1 -
 drivers/irqchip/irq-armada-370-xp.c |   2 +-
 drivers/irqchip/irq-bcm2836.c   |   3 +-
 drivers/irqchip/irq-gic-v3.c|   3 +-
 drivers/irqchip/irq-gic-v4.c|   6 +-
 drivers/irqchip/irq-gic.c   |   3 +-
 drivers/irqchip/irq-ixp4xx.c|   1 -
 kernel/irq/ipi.c|  16 +--
 kernel/irq/irqdesc.c|  45 +++-
 kernel/irq/irqdomain.c  | 160 +---
 kernel/irq/msi.c|   2 +-
 16 files changed, 158 insertions(+), 129 deletions(-)

-- 
2.17.1



[PATCH kernel v4 2/8] genirq/irqdomain: Clean legacy IRQ allocation

2020-11-23 Thread Alexey Kardashevskiy
There are 10 users of __irq_domain_alloc_irqs() and only one - IOAPIC -
passes realloc==true. There is no obvious reason for handling this
specific case in the generic code.

This splits out __irq_domain_alloc_irqs_data() to make it clear what
IOAPIC does and makes __irq_domain_alloc_irqs() cleaner.

This should cause no behavioral change.

Signed-off-by: Alexey Kardashevskiy 
---
 include/linux/irqdomain.h  |  3 ++
 arch/x86/kernel/apic/io_apic.c | 13 +++--
 kernel/irq/irqdomain.c | 89 --
 3 files changed, 65 insertions(+), 40 deletions(-)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 71535e87109f..6cc37bba9951 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -470,6 +470,9 @@ static inline struct irq_domain 
*irq_domain_add_hierarchy(struct irq_domain *par
   ops, host_data);
 }
 
+extern int __irq_domain_alloc_irqs_data(struct irq_domain *domain, int virq,
+   unsigned int nr_irqs, int node, void 
*arg,
+   const struct irq_affinity_desc 
*affinity);
 extern int __irq_domain_alloc_irqs(struct irq_domain *domain, int irq_base,
   unsigned int nr_irqs, int node, void *arg,
   bool realloc,
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 7b3c7e0d4a09..df9c0ab3a119 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -970,9 +970,14 @@ static int alloc_irq_from_domain(struct irq_domain 
*domain, int ioapic, u32 gsi,
return -1;
}
 
-   return __irq_domain_alloc_irqs(domain, irq, 1,
-  ioapic_alloc_attr_node(info),
-  info, legacy, NULL);
+   if (irq == -1 || !legacy)
+   return __irq_domain_alloc_irqs(domain, irq, 1,
+  ioapic_alloc_attr_node(info),
+  info, false, NULL);
+
+   return __irq_domain_alloc_irqs_data(domain, irq, 1,
+   ioapic_alloc_attr_node(info),
+   info, NULL);
 }
 
 /*
@@ -1006,7 +1011,7 @@ static int alloc_isa_irq_from_domain(struct irq_domain 
*domain,
return -ENOMEM;
} else {
info->flags |= X86_IRQ_ALLOC_LEGACY;
-   irq = __irq_domain_alloc_irqs(domain, irq, 1, node, info, true,
+   irq = __irq_domain_alloc_irqs_data(domain, irq, 1, node, info,
  NULL);
if (irq >= 0) {
irq_data = irq_domain_get_irq_data(domain, irq);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index cf8b374b892d..ca5c78366c85 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1386,6 +1386,51 @@ int irq_domain_alloc_irqs_hierarchy(struct irq_domain 
*domain,
return domain->ops->alloc(domain, irq_base, nr_irqs, arg);
 }
 
+int __irq_domain_alloc_irqs_data(struct irq_domain *domain, int virq,
+unsigned int nr_irqs, int node, void *arg,
+const struct irq_affinity_desc *affinity)
+{
+   int i, ret;
+
+   if (domain == NULL) {
+   domain = irq_default_domain;
+   if (WARN(!domain, "domain is NULL; cannot allocate IRQ\n"))
+   return -EINVAL;
+   }
+
+   if (irq_domain_alloc_irq_data(domain, virq, nr_irqs)) {
+   pr_debug("cannot allocate memory for IRQ%d\n", virq);
+   ret = -ENOMEM;
+   goto out_free_irq_data;
+   }
+
+   mutex_lock(_domain_mutex);
+   ret = irq_domain_alloc_irqs_hierarchy(domain, virq, nr_irqs, arg);
+   if (ret < 0) {
+   mutex_unlock(_domain_mutex);
+   goto out_free_irq_data;
+   }
+
+   for (i = 0; i < nr_irqs; i++) {
+   ret = irq_domain_trim_hierarchy(virq + i);
+   if (ret) {
+   mutex_unlock(_domain_mutex);
+   goto out_free_irq_data;
+   }
+   }
+
+   for (i = 0; i < nr_irqs; i++) {
+   irq_domain_insert_irq(virq + i);
+   }
+   mutex_unlock(_domain_mutex);
+
+   return virq;
+
+out_free_irq_data:
+   irq_domain_free_irq_data(virq, nr_irqs);
+   return ret;
+}
+
 /**
  * __irq_domain_alloc_irqs - Allocate IRQs from domain
  * @domain:domain to allocate from
@@ -1412,7 +1457,7 @@ int __irq_domain_alloc_irqs(struct irq_domain *domain, 
int irq_base,
unsigned int nr_irqs, int node, void *arg,
bool realloc, const struct irq_affinity_desc 
*affinity)
 {
-   int i, ret, virq;
+   int ret, virq;
 
if 

[PATCH kernel v4 3/8] genirq/irqdomain: Drop unused realloc parameter from __irq_domain_alloc_irqs

2020-11-23 Thread Alexey Kardashevskiy
The two previous patches made @realloc obsolete. This finishes removing it.

Signed-off-by: Alexey Kardashevskiy 
---
 include/linux/irqdomain.h   | 4 +---
 arch/x86/kernel/apic/io_apic.c  | 2 +-
 drivers/gpio/gpiolib.c  | 1 -
 drivers/irqchip/irq-armada-370-xp.c | 2 +-
 drivers/irqchip/irq-bcm2836.c   | 3 +--
 drivers/irqchip/irq-gic-v3.c| 3 +--
 drivers/irqchip/irq-gic-v4.c| 6 ++
 drivers/irqchip/irq-gic.c   | 3 +--
 drivers/irqchip/irq-ixp4xx.c| 1 -
 kernel/irq/ipi.c| 2 +-
 kernel/irq/irqdomain.c  | 4 +---
 kernel/irq/msi.c| 2 +-
 12 files changed, 11 insertions(+), 22 deletions(-)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 6cc37bba9951..a353b93ddf9e 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -475,7 +475,6 @@ extern int __irq_domain_alloc_irqs_data(struct irq_domain 
*domain, int virq,
const struct irq_affinity_desc 
*affinity);
 extern int __irq_domain_alloc_irqs(struct irq_domain *domain, int irq_base,
   unsigned int nr_irqs, int node, void *arg,
-  bool realloc,
   const struct irq_affinity_desc *affinity);
 extern void irq_domain_free_irqs(unsigned int virq, unsigned int nr_irqs);
 extern int irq_domain_activate_irq(struct irq_data *irq_data, bool early);
@@ -484,8 +483,7 @@ extern void irq_domain_deactivate_irq(struct irq_data 
*irq_data);
 static inline int irq_domain_alloc_irqs(struct irq_domain *domain,
unsigned int nr_irqs, int node, void *arg)
 {
-   return __irq_domain_alloc_irqs(domain, -1, nr_irqs, node, arg, false,
-  NULL);
+   return __irq_domain_alloc_irqs(domain, -1, nr_irqs, node, arg, NULL);
 }
 
 extern int irq_domain_alloc_irqs_hierarchy(struct irq_domain *domain,
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index df9c0ab3a119..5b45f0874571 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -973,7 +973,7 @@ static int alloc_irq_from_domain(struct irq_domain *domain, 
int ioapic, u32 gsi,
if (irq == -1 || !legacy)
return __irq_domain_alloc_irqs(domain, irq, 1,
   ioapic_alloc_attr_node(info),
-  info, false, NULL);
+  info, NULL);
 
return __irq_domain_alloc_irqs_data(domain, irq, 1,
ioapic_alloc_attr_node(info),
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 089ddcaa9bc6..b7cfecb5c701 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1059,7 +1059,6 @@ static void gpiochip_set_hierarchical_irqchip(struct 
gpio_chip *gc,
  1,
  NUMA_NO_NODE,
  ,
- false,
  NULL);
if (ret < 0) {
chip_err(gc,
diff --git a/drivers/irqchip/irq-armada-370-xp.c 
b/drivers/irqchip/irq-armada-370-xp.c
index d7eb2e93db8f..bf17eb312669 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -431,7 +431,7 @@ static __init void armada_xp_ipi_init(struct device_node 
*node)
 
irq_domain_update_bus_token(ipi_domain, DOMAIN_BUS_IPI);
base_ipi = __irq_domain_alloc_irqs(ipi_domain, -1, IPI_DOORBELL_END,
-  NUMA_NO_NODE, NULL, false, NULL);
+  NUMA_NO_NODE, NULL, NULL);
if (WARN_ON(!base_ipi))
return;
 
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index cbc7c740e4dc..fe9ff90940d3 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -269,8 +269,7 @@ static void __init bcm2836_arm_irqchip_smp_init(void)
irq_domain_update_bus_token(ipi_domain, DOMAIN_BUS_IPI);
 
base_ipi = __irq_domain_alloc_irqs(ipi_domain, -1, BITS_PER_MBOX,
-  NUMA_NO_NODE, NULL,
-  false, NULL);
+  NUMA_NO_NODE, NULL, NULL);
 
if (WARN_ON(!base_ipi))
return;
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 16fecc0febe8..ff20fd54921f 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -1163,8 +1163,7 @@ static void __init gic_smp_init(void)
 
/* Register all 8 non-secure SGIs */
base_sgi = 

Re: [PATCH] scsi: ufs: Don't disable core_clk_unipro if the link is active

2020-11-23 Thread Can Guo

Hi Stanley,

On 2020-11-24 13:20, Stanley Chu wrote:

Hi Can,

On Mon, 2020-11-23 at 21:05 -0800, Can Guo wrote:
If we want to disable clocks but still keep the link active, both 
ref_clk

and core_clk_unipro should be skipped.



"core_clk_unipro" seems used by ufs-qcom only and not defined in the 
UFS

platform binding document: ufshcd_pltfrm.txt.


Agree.



Could you please add the definition first and then it would be
reasonable to be used in common driver?

Or, how about add a flag in struct ufs_clk_info indicating if this 
clock

needs be ON to keep the link active? The flag could be set properly by
vendor initialization functions. In this way, we can also remove the
hard-coded "ref_clk" in __ufshcd_setup_clocks().


This seems better, I will upload next version to incorporate the idea
after it is tested.

Thanks,

Can Guo.



Thanks.
Stanley Chu


Signed-off-by: Can Guo 

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a7857f6..69c2e91 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -222,7 +222,7 @@ static int ufshcd_clear_tm_cmd(struct ufs_hba 
*hba, int tag);

 static void ufshcd_hba_exit(struct ufs_hba *hba);
 static int ufshcd_probe_hba(struct ufs_hba *hba, bool async);
 static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
-bool skip_ref_clk);
+bool keep_link_active);
 static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
 static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba);
 static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba 
*hba);
@@ -1710,7 +1710,6 @@ static void ufshcd_gate_work(struct work_struct 
*work)

if (!ufshcd_is_link_active(hba))
ufshcd_setup_clocks(hba, false);
else
-   /* If link is active, device ref_clk can't be switched off */
__ufshcd_setup_clocks(hba, false, true);

/*
@@ -7991,7 +7990,7 @@ static int ufshcd_init_hba_vreg(struct ufs_hba 
*hba)

 }

 static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
-   bool skip_ref_clk)
+   bool keep_link_active)
 {
int ret = 0;
struct ufs_clk_info *clki;
@@ -8009,7 +8008,13 @@ static int __ufshcd_setup_clocks(struct ufs_hba 
*hba, bool on,


list_for_each_entry(clki, head, list) {
if (!IS_ERR_OR_NULL(clki->clk)) {
-   if (skip_ref_clk && !strcmp(clki->name, "ref_clk"))
+   /*
+* To keep link active, ref_clk and core_clk_unipro
+* should be kept ON.
+*/
+   if (keep_link_active &&
+   (!strcmp(clki->name, "ref_clk") ||
+!strcmp(clki->name, "core_clk_unipro")))
continue;

clk_state_changed = on ^ clki->enabled;
@@ -8580,7 +8585,6 @@ static int ufshcd_suspend(struct ufs_hba *hba, 
enum ufs_pm_op pm_op)

if (!ufshcd_is_link_active(hba))
ufshcd_setup_clocks(hba, false);
else
-   /* If link is active, device ref_clk can't be switched off */
__ufshcd_setup_clocks(hba, false, true);

if (ufshcd_is_clkgating_allowed(hba)) {


Re: [Regression]: Commit 74d905d2 breaks the touchpad and touchscreen of Google Chromebook "samus"

2020-11-23 Thread Andre Muller

On 24/11/2020 04.02, Wang, Jiada wrote:

Hello Andre

Thanks for the log,
can you add more debug information like following diff,
and get full log?


Hi Jiada,

I added the warnings, but none of them triggers.
I double-checked the generated object file, it includes the debug strings.
(Also tested that touchscreen/touchpad don't work, as expected.)

Please find the full log attached.

Thank you,
Andre




diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 98f17fa3a892..60bccd5c42f6 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -1298,21 +1298,29 @@ static int mxt_check_retrigen(struct mxt_data *data)
     data->use_retrigen_workaround = false;

     irqd = irq_get_irq_data(data->irq);
-   if (!irqd)
+   if (!irqd) {
+   dev_warn(>dev, "unable to get IRQ data\n");
     return -EINVAL;
+   }

-   if (irqd_is_level_type(irqd))
+   if (irqd_is_level_type(irqd)) {
+   dev_warn(>dev, "IRQ is level type\n");
     return 0;
+   }

     if (data->T18_address) {
     error = __mxt_read_reg(client,
    data->T18_address + MXT_COMMS_CTRL,
    1, );
-   if (error)
+   if (error) {
+   dev_warn(>dev, "failed to read reg: 
MXT_COMMS_CTRL\n");
     return error;
+   }

-   if (val & MXT_COMMS_RETRIGEN)
+   if (val & MXT_COMMS_RETRIGEN) {
+   dev_warn(>dev, "RETRIGEN feature available\n");
     return 0;
+   }
     }

     dev_warn(>dev, "Enabling RETRIGEN workaround\n");


Thanks,
Jiada

On 2020/11/05 23:23, Andre Muller wrote:

On 05/11/2020 14.25, Wang, Jiada wrote:

Hi Andre

Thanks for your report,
could you also please post the log when with this commit reverted?

Thanks,
Jiada


Shure!
The full dmesg with the revert is attached.

The atmel_mxt bits are:

[    0.195879] atmel_mxt_ts i2c-ATML:01: Family: 164 Variant: 17 Firmware 
V1.0.AA Objects: 32
[    0.211712] atmel_mxt_ts i2c-ATML:01: Direct firmware load for 
maxtouch.cfg failed with error -2
[    0.212986] atmel_mxt_ts i2c-ATML:01: Touchscreen size X960Y540
[    0.213025] input: Atmel maXTouch Touchpad as 
/devices/pci:00/INT3432:00/i2c-0/i2c-ATML:01/input/input4
[    0.219208] atmel_mxt_ts i2c-ATML0001:01: Family: 164 Variant: 13 Firmware 
V1.0.AA Objects: 41
[    0.238825] atmel_mxt_ts i2c-ATML0001:01: Direct firmware load for 
maxtouch.cfg failed with error -2
[    0.238949] intel_rapl_common: Found RAPL domain package
[    0.238955] intel_rapl_common: Found RAPL domain core
[    0.238961] intel_rapl_common: Found RAPL domain uncore
[    0.238966] intel_rapl_common: Found RAPL domain dram
[    0.240121] atmel_mxt_ts i2c-ATML0001:01: Touchscreen size X2559Y1699
[    0.240157] input: Atmel maXTouch Touchscreen as 
/devices/pci:00/INT3433:00/i2c-1/i2c-ATML0001:01/input/input5

Regards,
Andre



On 2020/11/04 17:13, Andre wrote:

Hi,

commit 74d905d2: Input: atmel_mxt_ts - only read messages in
mxt_acquire_irq() when necessary

breaks the touchpad and touchscreen of the 2015 Chromebook Pixel "Samus".

Reverting the commit from the current git tree gets them to work again.

I am not at all shure what info to include, but I will happily provide
it on request.

The dmesgs of a boot with commit 74d905d2 show "Enabling RETRIGEN
workaround", but otherwise looks the same as a boot without.

Here is the relevant bit (with 74d905d2):

atmel_mxt_ts i2c-ATML:01: Family: 164 Variant: 17 Firmware V1.0.AA
Objects: 32
atmel_mxt_ts i2c-ATML:01: Enabling RETRIGEN workaround
atmel_mxt_ts i2c-ATML:01: Direct firmware load for maxtouch.cfg
failed with error -2
atmel_mxt_ts i2c-ATML:01: Touchscreen size X960Y540
input: Atmel maXTouch Touchpad as
/devices/pci:00/INT3432:00/i2c-0/i2c-ATML:01/input/input4
atmel_mxt_ts i2c-ATML0001:01: Family: 164 Variant: 13 Firmware V1.0.AA
Objects: 41
atmel_mxt_ts i2c-ATML0001:01: Enabling RETRIGEN workaround
atmel_mxt_ts i2c-ATML0001:01: Direct firmware load for maxtouch.cfg
failed with error -2

Thank you,
Andre Müller




[0.00] microcode: microcode updated early to revision 0x2f, date = 
2019-11-12
[0.00] Linux version 5.9.3+ (kernelbob@monty) (gcc (Gentoo 9.3.0-r1 p3) 
9.3.0, GNU ld (Gentoo 2.34 p6) 2.34.0) #23 SMP Tue Nov 24 06:54:25 CET 2020
[0.00] Command line: BOOT_IMAGE=known_good root=802
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, 

Re: [PATCH v2 02/19] elf: Move arch_setup_additional_pages() to generic elf.h

2020-11-23 Thread Christophe Leroy




Le 24/11/2020 à 01:29, Dmitry Safonov a écrit :

Ifdef the function in the header, not in the code.
Following kernel style, move it to Kconfig.
All it makes it easier to follow when the option is enabled/disabled.
Remove re-definition from compat_binfmt_elf, as it's always defined
under compat_arch_setup_additional_pages (to be reworked).

Signed-off-by: Dmitry Safonov 
---
  arch/arm/Kconfig|  1 +
  arch/arm/include/asm/elf.h  |  5 -
  arch/arm64/Kconfig  |  1 +
  arch/arm64/include/asm/elf.h|  6 +-
  arch/csky/Kconfig   |  1 +
  arch/csky/include/asm/elf.h |  4 
  arch/hexagon/Kconfig|  1 +
  arch/hexagon/include/asm/elf.h  |  6 --
  arch/mips/Kconfig   |  1 +
  arch/mips/include/asm/elf.h |  5 -
  arch/nds32/Kconfig  |  1 +
  arch/nds32/include/asm/elf.h|  3 ---
  arch/nios2/Kconfig  |  1 +
  arch/nios2/include/asm/elf.h|  4 
  arch/powerpc/Kconfig|  1 +
  arch/powerpc/include/asm/elf.h  |  5 -
  arch/riscv/Kconfig  |  1 +
  arch/riscv/include/asm/elf.h|  4 
  arch/s390/Kconfig   |  1 +
  arch/s390/include/asm/elf.h |  5 -
  arch/sh/Kconfig |  1 +
  arch/sh/include/asm/elf.h   |  6 --
  arch/sparc/Kconfig  |  1 +
  arch/sparc/include/asm/elf_64.h |  6 --
  arch/x86/Kconfig|  1 +
  arch/x86/include/asm/elf.h  |  4 
  arch/x86/um/asm/elf.h   |  5 -
  fs/Kconfig.binfmt   |  3 +++
  fs/binfmt_elf.c |  2 --
  fs/binfmt_elf_fdpic.c   |  3 +--
  fs/compat_binfmt_elf.c  |  2 --
  include/linux/elf.h | 12 
  32 files changed, 30 insertions(+), 73 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 6fd7d38a60c8..4221f171d1a9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -134,6 +134,7 @@ config PPC
select ARCH_HAS_PTE_SPECIAL
select ARCH_HAS_MEMBARRIER_CALLBACKS
select ARCH_HAS_MEMBARRIER_SYNC_CORE
+   select ARCH_HAS_SETUP_ADDITIONAL_PAGES


We try to keep alphabetic order on powerpc, should go after 
ARCH_HAS_SCALED_CPUTIME


select ARCH_HAS_SCALED_CPUTIME  if VIRT_CPU_ACCOUNTING_NATIVE 
&& PPC_BOOK3S_64
select ARCH_HAS_STRICT_KERNEL_RWX   if (PPC32 && !HIBERNATION)
select ARCH_HAS_TICK_BROADCAST  if GENERIC_CLOCKEVENTS_BROADCAST
diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index 53ed2ca40151..ba0e1e331088 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -111,11 +111,6 @@ extern int dcache_bsize;
  extern int icache_bsize;
  extern int ucache_bsize;
  
-/* vDSO has arch_setup_additional_pages */

-#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
-struct linux_binprm;
-extern int arch_setup_additional_pages(struct linux_binprm *bprm,
-  int uses_interp);
  #define VDSO_AUX_ENT(a,b) NEW_AUX_ENT(a,b)
  
  /* 1GB for 64bit, 8MB for 32bit */


Christophe


Re: [PATCH v2 05/19] elf: Remove compat_arch_setup_additional_pages()

2020-11-23 Thread Christophe Leroy




Le 24/11/2020 à 01:29, Dmitry Safonov a écrit :

Now that all users rely on detecting bitness of new-born task checking
personality, remove compat_arch_setup_additional_pages() macro,
simplifying the code.


I understand from cover that you wanted to reword "new-born" ?



Signed-off-by: Dmitry Safonov 
---
  fs/compat_binfmt_elf.c | 5 -
  1 file changed, 5 deletions(-)

diff --git a/fs/compat_binfmt_elf.c b/fs/compat_binfmt_elf.c
index 3606dd3a32f5..da8ee4d6e451 100644
--- a/fs/compat_binfmt_elf.c
+++ b/fs/compat_binfmt_elf.c
@@ -115,11 +115,6 @@
  #define START_THREAD  COMPAT_START_THREAD
  #endif
  
-#ifdef	compat_arch_setup_additional_pages

-#undef arch_setup_additional_pages
-#definearch_setup_additional_pages compat_arch_setup_additional_pages
-#endif
-
  #ifdefcompat_elf_read_implies_exec
  #undefelf_read_implies_exec
  #define   elf_read_implies_exec compat_elf_read_implies_exec



Re: [PATCH 5.9 000/252] 5.9.11-rc1 review

2020-11-23 Thread Naresh Kamboju
On Mon, 23 Nov 2020 at 18:14, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 5.9.11 release.
> There are 252 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 25 Nov 2020 12:17:50 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.11-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 5.9.11-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.9.y
git commit: 7939279fca79f52c48861829cef3fe5d15529c42
git describe: v5.9.10-253-g7939279fca79
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.9.y/build/v5.9.10-253-g7939279fca79

No regressions (compared to build v5.9.10)

No fixes (compared to build v5.9.10)


Ran 47415 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- nxp-ls2088
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-i386-clang
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan

Test Suites
---
* build
* install-android-platform-tools-r2600
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-tracing-tests
* perf
* v4l2-compliance
* ltp-controllers-tests
* ltp-syscalls-tests
* network-basic-tests
* ltp-cve-tests
* ltp-fs-tests
* ltp-hugetlb-tests
* ltp-mm-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kunit
* kselftest

-- 
Linaro LKFT
https://lkft.linaro.org


[PATCH] phram: Allow the user to set the erase page size.

2020-11-23 Thread Guohua Zhong
Permit the user to specify the erase page size as a parameter.
This solves two problems:

- phram can access images made by mkfs.jffs2.  mkfs.jffs2 won't
create images with erase sizes less than 8KiB; many architectures
define PAGE_SIZE as 4KiB.

- Allows more effective use of small capacity devices.  JFFS2
needs somewhere between 2 and 5 empty pages for garbage collection;
and for an NVRAM part with only 32KiB of space, a smaller erase page
allows much better utilization in applications where garbage collection
is important.

Signed-off-by: Patrick O'Grady 
Reviewed-by: Joern Engel 
Link: 
https://lore.kernel.org/lkml/CAJ7m5OqYv_=JB9NhHsqBsa8YU0DFRoP7C+W10PY22wonAGJK=a...@mail.gmail.com/
[Guohua Zhong: fix token array index out of bounds and update patch for kernel 
master branch]
Signed-off-by: Guohua Zhong 
---
 drivers/mtd/devices/phram.c | 51 +
 1 file changed, 33 insertions(+), 18 deletions(-)

diff --git a/drivers/mtd/devices/phram.c b/drivers/mtd/devices/phram.c
index 087b5e86d1bf..3ac766b65bf2 100644
--- a/drivers/mtd/devices/phram.c
+++ b/drivers/mtd/devices/phram.c
@@ -6,14 +6,14 @@
  * Usage:
  *
  * one commend line parameter per device, each in the form:
- *   phram=,,
+ *   phram=,,[,]
  *  may be up to 63 characters.
- *  and  can be octal, decimal or hexadecimal.  If followed
+ * , , and  can be octal, decimal or hexadecimal.  If 
followed
  * by "ki", "Mi" or "Gi", the numbers will be interpreted as kilo, mega or
- * gigabytes.
+ * gigabytes.  is optional and defaults to PAGE_SIZE.
  *
  * Example:
- * phram=swap,64Mi,128Mi phram=test,900Mi,1Mi
+ * phram=swap,64Mi,128Mi phram=test,900Mi,1Mi,64Ki
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -88,7 +88,7 @@ static void unregister_devices(void)
}
 }
 
-static int register_device(char *name, phys_addr_t start, size_t len)
+static int register_device(char *name, phys_addr_t start, size_t len, uint32_t 
erasesize)
 {
struct phram_mtd_list *new;
int ret = -ENOMEM;
@@ -115,7 +115,7 @@ static int register_device(char *name, phys_addr_t start, 
size_t len)
new->mtd._write = phram_write;
new->mtd.owner = THIS_MODULE;
new->mtd.type = MTD_RAM;
-   new->mtd.erasesize = PAGE_SIZE;
+   new->mtd.erasesize = erasesize;
new->mtd.writesize = 1;
 
ret = -EAGAIN;
@@ -204,22 +204,23 @@ static inline void kill_final_newline(char *str)
 static int phram_init_called;
 /*
  * This shall contain the module parameter if any. It is of the form:
- * - phram=,, for module case
- * - phram.phram=,, for built-in case
- * We leave 64 bytes for the device name, 20 for the address and 20 for the
- * size.
- * Example: phram.phram=rootfs,0xa000,512Mi
+ * - phram=,,[,] for module case
+ * - phram.phram=,,[,] for built-in case
+ * We leave 64 bytes for the device name, 20 for the address , 20 for the
+ * size and 20 for the erasesize.
+ * Example: phram.phram=rootfs,0xa000,512Mi,65536
  */
-static char phram_paramline[64 + 20 + 20];
+static char phram_paramline[64 + 20 + 20 + 20];
 #endif
 
 static int phram_setup(const char *val)
 {
-   char buf[64 + 20 + 20], *str = buf;
-   char *token[3];
+   char buf[64 + 20 + 20 + 20], *str = buf;
+   char *token[4];
char *name;
uint64_t start;
uint64_t len;
+   uint64_t erasesize = PAGE_SIZE;
int i, ret;
 
if (strnlen(val, sizeof(buf)) >= sizeof(buf))
@@ -228,7 +229,7 @@ static int phram_setup(const char *val)
strcpy(str, val);
kill_final_newline(str);
 
-   for (i = 0; i < 3; i++)
+   for (i = 0; i < 4; i++)
token[i] = strsep(, ",");
 
if (str)
@@ -253,11 +254,25 @@ static int phram_setup(const char *val)
goto error;
}
 
-   ret = register_device(name, start, len);
+   if (token[3]) {
+   ret = parse_num64(, token[3]);
+   if (ret) {
+   parse_err("illegal erasesize\n");
+   goto error;
+   }
+   }
+
+   if (len == 0 || erasesize == 0 || erasesize > len
+   || erasesize > UINT_MAX || len % erasesize != 0) {
+   parse_err("illegal erasesize or len\n");
+   goto error;
+   }
+
+   ret = register_device(name, start, len, (uint32_t)erasesize);
if (ret)
goto error;
 
-   pr_info("%s device: %#llx at %#llx\n", name, len, start);
+   pr_info("%s device: %#llx at %#llx for erasesize %#llx\n", name, len, 
start, erasesize);
return 0;
 
 error:
@@ -298,7 +313,7 @@ static int phram_param_call(const char *val, const struct 
kernel_param *kp)
 }
 
 module_param_call(phram, phram_param_call, NULL, NULL, 0200);
-MODULE_PARM_DESC(phram, "Memory region to map. 
\"phram=,,\"");
+MODULE_PARM_DESC(phram, "Memory region to map. 
\"phram=,,[,]\"");
 
 
 static int __init init_phram(void)
-- 
2.12.3



[PATCH 11/17] fs/reiserfs: Use memcpy_from_page()

2020-11-23 Thread ira . weiny
From: Ira Weiny 

Remove the open coding of kmap/memcpy/kunmap and use the new
memcpy_from_page() function.

Signed-off-by: Ira Weiny 
---
 fs/reiserfs/journal.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/fs/reiserfs/journal.c b/fs/reiserfs/journal.c
index e98f99338f8f..e288bbbe80ff 100644
--- a/fs/reiserfs/journal.c
+++ b/fs/reiserfs/journal.c
@@ -4184,7 +4184,6 @@ static int do_journal_end(struct 
reiserfs_transaction_handle *th, int flags)
/* copy all the real blocks into log area.  dirty log blocks */
if (buffer_journaled(cn->bh)) {
struct buffer_head *tmp_bh;
-   char *addr;
struct page *page;
tmp_bh =
journal_getblk(sb,
@@ -4194,11 +4193,9 @@ static int do_journal_end(struct 
reiserfs_transaction_handle *th, int flags)
SB_ONDISK_JOURNAL_SIZE(sb)));
set_buffer_uptodate(tmp_bh);
page = cn->bh->b_page;
-   addr = kmap(page);
-   memcpy(tmp_bh->b_data,
-  addr + offset_in_page(cn->bh->b_data),
-  cn->bh->b_size);
-   kunmap(page);
+   memcpy_from_page(tmp_bh->b_data, page,
+offset_in_page(cn->bh->b_data),
+cn->bh->b_size);
mark_buffer_dirty(tmp_bh);
jindex++;
set_buffer_journal_dirty(cn->bh);
-- 
2.28.0.rc0.12.gb6a658bd00c9



[PATCH 04/17] fs/afs: Convert to memzero_page()

2020-11-23 Thread ira . weiny
From: Ira Weiny 

Convert the kmap()/memcpy()/kunmap() pattern to memzero_page().

Cc: David Howells 
Signed-off-by: Ira Weiny 
---
 fs/afs/write.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/fs/afs/write.c b/fs/afs/write.c
index 50371207f327..ed7419de0178 100644
--- a/fs/afs/write.c
+++ b/fs/afs/write.c
@@ -30,7 +30,6 @@ static int afs_fill_page(struct afs_vnode *vnode, struct key 
*key,
 {
struct afs_read *req;
size_t p;
-   void *data;
int ret;
 
_enter(",,%llu", (unsigned long long)pos);
@@ -38,9 +37,7 @@ static int afs_fill_page(struct afs_vnode *vnode, struct key 
*key,
if (pos >= vnode->vfs_inode.i_size) {
p = pos & ~PAGE_MASK;
ASSERTCMP(p + len, <=, PAGE_SIZE);
-   data = kmap(page);
-   memset(data + p, 0, len);
-   kunmap(page);
+   memzero_page(page, p, len);
return 0;
}
 
-- 
2.28.0.rc0.12.gb6a658bd00c9



[PATCH 05/17] fs/btrfs: Convert to memzero_page()

2020-11-23 Thread ira . weiny
From: Ira Weiny 

Remove the kmap/memset()/kunmap pattern and use the new memzero_page()
call where possible.

Cc: Chris Mason 
Cc: Josef Bacik 
Cc: David Sterba 
Signed-off-by: Ira Weiny 
---
 fs/btrfs/inode.c | 21 +
 1 file changed, 5 insertions(+), 16 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index da58c58ef9aa..b0bcf9493236 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -590,17 +590,12 @@ static noinline int compress_file_range(struct 
async_chunk *async_chunk)
if (!ret) {
unsigned long offset = offset_in_page(total_compressed);
struct page *page = pages[nr_pages - 1];
-   char *kaddr;
 
/* zero the tail end of the last page, we might be
 * sending it down to disk
 */
-   if (offset) {
-   kaddr = kmap_atomic(page);
-   memset(kaddr + offset, 0,
-  PAGE_SIZE - offset);
-   kunmap_atomic(kaddr);
-   }
+   if (offset)
+   memzero_page(page, offset, PAGE_SIZE - offset);
will_compress = 1;
}
}
@@ -6485,11 +6480,8 @@ static noinline int uncompress_inline(struct btrfs_path 
*path,
 * cover that region here.
 */
 
-   if (max_size + pg_offset < PAGE_SIZE) {
-   char *map = kmap(page);
-   memset(map + pg_offset + max_size, 0, PAGE_SIZE - max_size - 
pg_offset);
-   kunmap(page);
-   }
+   if (max_size + pg_offset < PAGE_SIZE)
+   memzero_page(page, pg_offset + max_size, PAGE_SIZE - max_size - 
pg_offset);
kfree(tmp);
return ret;
 }
@@ -8245,7 +8237,6 @@ vm_fault_t btrfs_page_mkwrite(struct vm_fault *vmf)
struct btrfs_ordered_extent *ordered;
struct extent_state *cached_state = NULL;
struct extent_changeset *data_reserved = NULL;
-   char *kaddr;
unsigned long zero_start;
loff_t size;
vm_fault_t ret;
@@ -8352,10 +8343,8 @@ vm_fault_t btrfs_page_mkwrite(struct vm_fault *vmf)
zero_start = PAGE_SIZE;
 
if (zero_start != PAGE_SIZE) {
-   kaddr = kmap(page);
-   memset(kaddr + zero_start, 0, PAGE_SIZE - zero_start);
+   memzero_page(page, zero_start, PAGE_SIZE - zero_start);
flush_dcache_page(page);
-   kunmap(page);
}
ClearPageChecked(page);
set_page_dirty(page);
-- 
2.28.0.rc0.12.gb6a658bd00c9



[PATCH 06/17] fs/hfs: Convert to mem*_page() interface

2020-11-23 Thread ira . weiny
From: Ira Weiny 

Where possible remove kmap/mem*/kunmap in favor of the new mem*_page()
calls.

Signed-off-by: Ira Weiny 
---
 fs/hfs/bnode.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/fs/hfs/bnode.c b/fs/hfs/bnode.c
index b63a4df7327b..56037ae5ba69 100644
--- a/fs/hfs/bnode.c
+++ b/fs/hfs/bnode.c
@@ -23,8 +23,7 @@ void hfs_bnode_read(struct hfs_bnode *node, void *buf,
off += node->page_offset;
page = node->page[0];
 
-   memcpy(buf, kmap(page) + off, len);
-   kunmap(page);
+   memcpy_from_page(buf, page, off, len);
 }
 
 u16 hfs_bnode_read_u16(struct hfs_bnode *node, int off)
@@ -65,8 +64,7 @@ void hfs_bnode_write(struct hfs_bnode *node, void *buf, int 
off, int len)
off += node->page_offset;
page = node->page[0];
 
-   memcpy(kmap(page) + off, buf, len);
-   kunmap(page);
+   memcpy_to_page(page, off, buf, len);
set_page_dirty(page);
 }
 
@@ -90,8 +88,7 @@ void hfs_bnode_clear(struct hfs_bnode *node, int off, int len)
off += node->page_offset;
page = node->page[0];
 
-   memset(kmap(page) + off, 0, len);
-   kunmap(page);
+   memzero_page(page, off, len);
set_page_dirty(page);
 }
 
@@ -108,9 +105,7 @@ void hfs_bnode_copy(struct hfs_bnode *dst_node, int dst,
src_page = src_node->page[0];
dst_page = dst_node->page[0];
 
-   memcpy(kmap(dst_page) + dst, kmap(src_page) + src, len);
-   kunmap(src_page);
-   kunmap(dst_page);
+   memcpy_page(dst_page, dst, src_page, src, len);
set_page_dirty(dst_page);
 }
 
-- 
2.28.0.rc0.12.gb6a658bd00c9



[PATCH V3.1] entry: Pass irqentry_state_t by reference

2020-11-23 Thread ira . weiny
From: Ira Weiny 

Currently struct irqentry_state_t only contains a single bool value
which makes passing it by value is reasonable.  However, future patches
add information to this struct.  This includes the PKRS thread state,
included in this series, as well as information to store kmap reference
tracking and PKS global state outside this series.  In total, we
anticipate 2 new 32 bit fields and an integer field to be added to the
struct beyond the existing bool value.

Adding information to irqentry_state_t makes passing by value less
efficient.  Therefore, change the entry/exit calls to pass irq_state by
reference in preparation for the changes which follow.

While at it, make the code easier to follow by changing all the usage
sites to consistently use the variable name 'irq_state'.

Signed-off-by: Ira Weiny 

---
Changes from V3
Clarify commit message regarding the need for this patch

Changes from V1
From Thomas: Update commit message
Further clean up Kernel doc and comments
Missed some 'return' comments which are no longer valid

Changes from RFC V3
Clean up @irq_state comments
Standardize on 'irq_state' for the state variable name
Refactor based on new patch from Thomas Gleixner
Also addresses Peter Zijlstra's comment
---
 arch/x86/entry/common.c |  8 
 arch/x86/include/asm/idtentry.h | 25 ++--
 arch/x86/kernel/cpu/mce/core.c  |  4 ++--
 arch/x86/kernel/kvm.c   |  6 +++---
 arch/x86/kernel/nmi.c   |  4 ++--
 arch/x86/kernel/traps.c | 21 
 arch/x86/mm/fault.c |  6 +++---
 include/linux/entry-common.h| 18 +
 kernel/entry/common.c   | 34 +
 9 files changed, 65 insertions(+), 61 deletions(-)

diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index 18d8f17f755c..87dea56a15d2 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -259,9 +259,9 @@ __visible noinstr void xen_pv_evtchn_do_upcall(struct 
pt_regs *regs)
 {
struct pt_regs *old_regs;
bool inhcall;
-   irqentry_state_t state;
+   irqentry_state_t irq_state;
 
-   state = irqentry_enter(regs);
+   irqentry_enter(regs, _state);
old_regs = set_irq_regs(regs);
 
instrumentation_begin();
@@ -271,13 +271,13 @@ __visible noinstr void xen_pv_evtchn_do_upcall(struct 
pt_regs *regs)
set_irq_regs(old_regs);
 
inhcall = get_and_clear_inhcall();
-   if (inhcall && !WARN_ON_ONCE(state.exit_rcu)) {
+   if (inhcall && !WARN_ON_ONCE(irq_state.exit_rcu)) {
instrumentation_begin();
irqentry_exit_cond_resched();
instrumentation_end();
restore_inhcall(inhcall);
} else {
-   irqentry_exit(regs, state);
+   irqentry_exit(regs, _state);
}
 }
 #endif /* CONFIG_XEN_PV */
diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
index 247a60a47331..282d2413b6a1 100644
--- a/arch/x86/include/asm/idtentry.h
+++ b/arch/x86/include/asm/idtentry.h
@@ -49,12 +49,13 @@ static __always_inline void __##func(struct pt_regs *regs); 
\
\
 __visible noinstr void func(struct pt_regs *regs)  \
 {  \
-   irqentry_state_t state = irqentry_enter(regs);  \
+   irqentry_state_t irq_state; 
\
\
+   irqentry_enter(regs, _state);   
\
instrumentation_begin();\
__##func (regs);\
instrumentation_end();  \
-   irqentry_exit(regs, state); \
+   irqentry_exit(regs, _state);
\
 }  \
\
 static __always_inline void __##func(struct pt_regs *regs)
@@ -96,12 +97,13 @@ static __always_inline void __##func(struct pt_regs *regs,  
\
 __visible noinstr void func(struct pt_regs *regs,  \
unsigned long error_code)   \
 {  \
-   irqentry_state_t state = irqentry_enter(regs);  \
+   irqentry_state_t irq_state; 
\
\
+   irqentry_enter(regs, _state); 

Re: [PATCH v7 1/5] leds: flash: Add flash registration with undefined CONFIG_LEDS_CLASS_FLASH

2020-11-23 Thread Gene Chen
Jacek Anaszewski  於 2020年11月24日 週二 上午5:07寫道:
>
> On 11/23/20 4:20 AM, Gene Chen wrote:
> > Jacek Anaszewski  於 2020年11月20日 週五 上午6:29寫道:
> >>
> >> Hi Gene,
> >>
> >> On 11/18/20 11:47 AM, Gene Chen wrote:
> >>> From: Gene Chen 
> >>>
> >>> Add flash registration with undefined CONFIG_LEDS_CLASS_FLASH
> >>>
> >>> Signed-off-by: Gene Chen 
> >>> ---
> >>>include/linux/led-class-flash.h | 36 
> >>> 
> >>>1 file changed, 36 insertions(+)
> >>>
> >>> diff --git a/include/linux/led-class-flash.h 
> >>> b/include/linux/led-class-flash.h
> >>> index 21a3358..4f56c28 100644
> >>> --- a/include/linux/led-class-flash.h
> >>> +++ b/include/linux/led-class-flash.h
> >>> @@ -85,6 +85,7 @@ static inline struct led_classdev_flash 
> >>> *lcdev_to_flcdev(
> >>>return container_of(lcdev, struct led_classdev_flash, led_cdev);
> >>>}
> >>>
> >>> +#if IS_ENABLED(CONFIG_LEDS_CLASS_FLASH)
> >>>/**
> >>> * led_classdev_flash_register_ext - register a new object of LED 
> >>> class with
> >>> *   init data and with support for flash 
> >>> LEDs
> >>> @@ -127,6 +128,41 @@ static inline int 
> >>> devm_led_classdev_flash_register(struct device *parent,
> >>>void devm_led_classdev_flash_unregister(struct device *parent,
> >>>struct led_classdev_flash 
> >>> *fled_cdev);
> >>>
> >>> +#else
> >>> +
> >>> +static inline int led_classdev_flash_register_ext(struct device *parent,
> >>> + struct led_classdev_flash *fled_cdev,
> >>> + struct led_init_data *init_data)
> >>> +{
> >>> + return -EINVAL;
> >>
> >> s/-EINVAL/0/
> >>
> >> The goal here is to assure that client will not fail when using no-op.
> >>
> >>> +}
> >>> +
> >>> +static inline int led_classdev_flash_register(struct device *parent,
> >>> +struct led_classdev_flash 
> >>> *fled_cdev)
> >>> +{
> >>> + return led_classdev_flash_register_ext(parent, fled_cdev, NULL);
> >>> +}
> >>
> >> This function should be placed after #ifdef block because its
> >> shape is the same for both cases.
> >>
> >>> +static inline void led_classdev_flash_unregister(struct 
> >>> led_classdev_flash *fled_cdev) {};
> >>> +static inline int devm_led_classdev_flash_register_ext(struct device 
> >>> *parent,
> >>> +  struct led_classdev_flash *fled_cdev,
> >>> +  struct led_init_data *init_data)
> >>> +{
> >>> + return -EINVAL;
> >>
> >> /-EINVAL/0/
> >>
> >> Please do the same fix in all no-ops in the led-class-multicolor.h,
> >> as we've discussed.
> >>
> >
> > I think return -EINVAL is correct, because I should register flash
> > light device if I define FLED in DTS node.
>
> I don't quite follow your logic here.
>
> No-op function's purpose is to simplify the code on the caller's side.
> Therefore it should report success.
>
> Please return 0 from it.
>

Just like those functions in led-class-multicolor.h, caller may use
return value to check whether FLED is registered successfully or not.
For this case, is returning 0 a little bit misleading?

> --
> Best regards,
> Jacek Anaszewski


[PATCH 10/17] fs/freevxfs: Use memcpy_to_page()

2020-11-23 Thread ira . weiny
From: Ira Weiny 

Remove kmap/memcpy/kunmap pattern in favor of the new memcpy_to_page()

Cc: Christoph Hellwig 
Signed-off-by: Ira Weiny 
---
 fs/freevxfs/vxfs_immed.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/fs/freevxfs/vxfs_immed.c b/fs/freevxfs/vxfs_immed.c
index bfc780c682fb..d185fa67b82f 100644
--- a/fs/freevxfs/vxfs_immed.c
+++ b/fs/freevxfs/vxfs_immed.c
@@ -67,12 +67,8 @@ vxfs_immed_readpage(struct file *fp, struct page *pp)
 {
struct vxfs_inode_info  *vip = VXFS_INO(pp->mapping->host);
u_int64_t   offset = (u_int64_t)pp->index << PAGE_SHIFT;
-   caddr_t kaddr;
 
-   kaddr = kmap(pp);
-   memcpy(kaddr, vip->vii_immed.vi_immed + offset, PAGE_SIZE);
-   kunmap(pp);
-   
+   memcpy_to_page(pp, 0, vip->vii_immed.vi_immed + offset, PAGE_SIZE);
flush_dcache_page(pp);
SetPageUptodate(pp);
 unlock_page(pp);
-- 
2.28.0.rc0.12.gb6a658bd00c9



[PATCH 16/17] lib: Use mempcy_to/from_page()

2020-11-23 Thread ira . weiny
From: Ira Weiny 

Remove kmap/mem*()/kunmap pattern and use memcpy_to/from_page()

Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: "Jérôme Glisse" 
Signed-off-by: Ira Weiny 
---
 lib/test_bpf.c | 11 ++-
 lib/test_hmm.c | 10 ++
 2 files changed, 4 insertions(+), 17 deletions(-)

diff --git a/lib/test_bpf.c b/lib/test_bpf.c
index ca7d635bccd9..def048bc1c48 100644
--- a/lib/test_bpf.c
+++ b/lib/test_bpf.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -6499,25 +6500,17 @@ static void *generate_test_data(struct bpf_test *test, 
int sub)
 * single fragment to the skb, filled with
 * test->frag_data.
 */
-   void *ptr;
-
page = alloc_page(GFP_KERNEL);
 
if (!page)
goto err_kfree_skb;
 
-   ptr = kmap(page);
-   if (!ptr)
-   goto err_free_page;
-   memcpy(ptr, test->frag_data, MAX_DATA);
-   kunmap(page);
+   memcpy_to_page(page, 0, test->frag_data, MAX_DATA);
skb_add_rx_frag(skb, 0, page, 0, MAX_DATA, MAX_DATA);
}
 
return skb;
 
-err_free_page:
-   __free_page(page);
 err_kfree_skb:
kfree_skb(skb);
return NULL;
diff --git a/lib/test_hmm.c b/lib/test_hmm.c
index 80a78877bd93..6a5fe7c4088b 100644
--- a/lib/test_hmm.c
+++ b/lib/test_hmm.c
@@ -321,16 +321,13 @@ static int dmirror_do_read(struct dmirror *dmirror, 
unsigned long start,
for (pfn = start >> PAGE_SHIFT; pfn < (end >> PAGE_SHIFT); pfn++) {
void *entry;
struct page *page;
-   void *tmp;
 
entry = xa_load(>pt, pfn);
page = xa_untag_pointer(entry);
if (!page)
return -ENOENT;
 
-   tmp = kmap(page);
-   memcpy(ptr, tmp, PAGE_SIZE);
-   kunmap(page);
+   memcpy_from_page(ptr, page, 0, PAGE_SIZE);
 
ptr += PAGE_SIZE;
bounce->cpages++;
@@ -390,16 +387,13 @@ static int dmirror_do_write(struct dmirror *dmirror, 
unsigned long start,
for (pfn = start >> PAGE_SHIFT; pfn < (end >> PAGE_SHIFT); pfn++) {
void *entry;
struct page *page;
-   void *tmp;
 
entry = xa_load(>pt, pfn);
page = xa_untag_pointer(entry);
if (!page || xa_pointer_tag(entry) != DPT_XA_TAG_WRITE)
return -ENOENT;
 
-   tmp = kmap(page);
-   memcpy(tmp, ptr, PAGE_SIZE);
-   kunmap(page);
+   memcpy_to_page(page, 0, ptr, PAGE_SIZE);
 
ptr += PAGE_SIZE;
bounce->cpages++;
-- 
2.28.0.rc0.12.gb6a658bd00c9



[PATCH 14/17] drivers/scsi: Use memcpy_to_page()

2020-11-23 Thread ira . weiny
From: Ira Weiny 

Remove kmap/mem*()/kunmap pattern and use memcpy_to_page()

Cc: Brian King 
Signed-off-by: Ira Weiny 
---
 drivers/scsi/ipr.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index b0aa58d117cc..3cdd8db24270 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -3912,7 +3912,6 @@ static int ipr_copy_ucode_buffer(struct ipr_sglist 
*sglist,
 {
int bsize_elem, i, result = 0;
struct scatterlist *sg;
-   void *kaddr;
 
/* Determine the actual number of bytes per element */
bsize_elem = PAGE_SIZE * (1 << sglist->order);
@@ -3923,10 +3922,7 @@ static int ipr_copy_ucode_buffer(struct ipr_sglist 
*sglist,
buffer += bsize_elem) {
struct page *page = sg_page(sg);
 
-   kaddr = kmap(page);
-   memcpy(kaddr, buffer, bsize_elem);
-   kunmap(page);
-
+   memcpy_to_page(page, 0, buffer, bsize_elem);
sg->length = bsize_elem;
 
if (result != 0) {
@@ -3938,10 +3934,7 @@ static int ipr_copy_ucode_buffer(struct ipr_sglist 
*sglist,
if (len % bsize_elem) {
struct page *page = sg_page(sg);
 
-   kaddr = kmap(page);
-   memcpy(kaddr, buffer, len % bsize_elem);
-   kunmap(page);
-
+   memcpy_to_page(page, 0, buffer, len % bsize_elem);
sg->length = len % bsize_elem;
}
 
-- 
2.28.0.rc0.12.gb6a658bd00c9



[PATCH 15/17] drivers/staging: Use memcpy_to/from_page()

2020-11-23 Thread ira . weiny
From: Ira Weiny 

Remove kmap/mem*()/kunmap pattern and use memcpy_to/from_page()

Cc: Greg Kroah-Hartman 
Signed-off-by: Ira Weiny 
---
 drivers/staging/rts5208/rtsx_transport.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c 
b/drivers/staging/rts5208/rtsx_transport.c
index 909a3e663ef6..e0e52bae953e 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -92,13 +92,13 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char 
*buffer,
while (sglen > 0) {
unsigned int plen = min(sglen, (unsigned int)
PAGE_SIZE - poff);
-   unsigned char *ptr = kmap(page);
 
if (dir == TO_XFER_BUF)
-   memcpy(ptr + poff, buffer + cnt, plen);
+   memcpy_to_page(page, poff,
+  buffer + cnt, plen);
else
-   memcpy(buffer + cnt, ptr + poff, plen);
-   kunmap(page);
+   memcpy_from_page(buffer + cnt, page,
+poff, plen);
 
/* Start at the beginning of the next page */
poff = 0;
-- 
2.28.0.rc0.12.gb6a658bd00c9



[PATCH 17/17] samples: Use memcpy_to/from_page()

2020-11-23 Thread ira . weiny
From: Ira Weiny 

Remove kmap/mem*()/kunmap pattern and use memcpy_to/from_page()

Cc: Kirti Wankhede 
Signed-off-by: Ira Weiny 
---
 samples/vfio-mdev/mbochs.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index e03068917273..54fe04f63c66 100644
--- a/samples/vfio-mdev/mbochs.c
+++ b/samples/vfio-mdev/mbochs.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -442,7 +443,6 @@ static ssize_t mdev_access(struct mdev_device *mdev, char 
*buf, size_t count,
struct device *dev = mdev_dev(mdev);
struct page *pg;
loff_t poff;
-   char *map;
int ret = 0;
 
mutex_lock(_state->ops_lock);
@@ -479,12 +479,10 @@ static ssize_t mdev_access(struct mdev_device *mdev, char 
*buf, size_t count,
pos -= MBOCHS_MMIO_BAR_OFFSET;
poff = pos & ~PAGE_MASK;
pg = __mbochs_get_page(mdev_state, pos >> PAGE_SHIFT);
-   map = kmap(pg);
if (is_write)
-   memcpy(map + poff, buf, count);
+   memcpy_to_page(pg, poff, buf, count);
else
-   memcpy(buf, map + poff, count);
-   kunmap(pg);
+   memcpy_from_page(buf, pg, poff, count);
put_page(pg);
 
} else {
-- 
2.28.0.rc0.12.gb6a658bd00c9



[PATCH 13/17] drivers/target: Convert to mem*_page()

2020-11-23 Thread ira . weiny
From: Ira Weiny 

Remove the kmap/mem*()/kunmap patter and use the new mem*_page()
functions.

Cc: "Martin K. Petersen" 
Signed-off-by: Ira Weiny 
---
 drivers/target/target_core_rd.c|  6 ++
 drivers/target/target_core_transport.c | 10 +++---
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/target/target_core_rd.c b/drivers/target/target_core_rd.c
index bf936bbeccfe..30bf0fcae519 100644
--- a/drivers/target/target_core_rd.c
+++ b/drivers/target/target_core_rd.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -117,7 +118,6 @@ static int rd_allocate_sgl_table(struct rd_dev *rd_dev, 
struct rd_dev_sg_table *
sizeof(struct scatterlist));
struct page *pg;
struct scatterlist *sg;
-   unsigned char *p;
 
while (total_sg_needed) {
unsigned int chain_entry = 0;
@@ -159,9 +159,7 @@ static int rd_allocate_sgl_table(struct rd_dev *rd_dev, 
struct rd_dev_sg_table *
sg_assign_page([j], pg);
sg[j].length = PAGE_SIZE;
 
-   p = kmap(pg);
-   memset(p, init_payload, PAGE_SIZE);
-   kunmap(pg);
+   memset_page(pg, init_payload, 0, PAGE_SIZE);
}
 
page_offset += sg_per_table;
diff --git a/drivers/target/target_core_transport.c 
b/drivers/target/target_core_transport.c
index ff26ab0a5f60..4fec5c728344 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1689,15 +1690,10 @@ int target_submit_cmd_map_sgls(struct se_cmd *se_cmd, 
struct se_session *se_sess
 */
if (!(se_cmd->se_cmd_flags & SCF_SCSI_DATA_CDB) &&
 se_cmd->data_direction == DMA_FROM_DEVICE) {
-   unsigned char *buf = NULL;
 
if (sgl)
-   buf = kmap(sg_page(sgl)) + sgl->offset;
-
-   if (buf) {
-   memset(buf, 0, sgl->length);
-   kunmap(sg_page(sgl));
-   }
+   memzero_page(sg_page(sgl), sgl->offset,
+sgl->length);
}
 
rc = transport_generic_map_mem_to_cmd(se_cmd, sgl, sgl_count,
-- 
2.28.0.rc0.12.gb6a658bd00c9



  1   2   3   4   5   6   7   8   9   10   >