[PATCH v2 17/24] scsi: be2iscsi: be_iscsi: Fix API/documentation slip

2020-07-13 Thread Lee Jones
And add descriptions for a couple of missing function parameters.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/be2iscsi/be_iscsi.c:38: warning: Function parameter or member 
'ep' not described in 'beiscsi_session_create'
 drivers/scsi/be2iscsi/be_iscsi.c:173: warning: Function parameter or member 
'is_leading' not described in 'beiscsi_conn_bind'
 drivers/scsi/be2iscsi/be_iscsi.c:998: warning: Function parameter or member 
'beiscsi_ep' not described in 'beiscsi_free_ep'
 drivers/scsi/be2iscsi/be_iscsi.c:998: warning: Excess function parameter 'ep' 
description in 'beiscsi_free_ep'
 drivers/scsi/be2iscsi/be_iscsi.c:1039: warning: Function parameter or member 
'non_blocking' not described in 'beiscsi_open_conn'
 drivers/scsi/be2iscsi/be_iscsi.c:1135: warning: Function parameter or member 
'shost' not described in 'beiscsi_ep_connect'
 drivers/scsi/be2iscsi/be_iscsi.c:1135: warning: Excess function parameter 
'scsi_host' description in 'beiscsi_ep_connect'
 drivers/scsi/be2iscsi/be_iscsi.c:1236: warning: Function parameter or member 
'beiscsi_ep' not described in 'beiscsi_conn_close'
 drivers/scsi/be2iscsi/be_iscsi.c:1236: warning: Excess function parameter 'ep' 
description in 'beiscsi_conn_close'

Cc: Subbu Seetharaman 
Cc: Ketan Mukadam 
Cc: Jitendra Bhivare 
Cc: linux-driv...@broadcom.com
Signed-off-by: Lee Jones 
---
 drivers/scsi/be2iscsi/be_iscsi.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c
index 2058d50d62e12..fe10575bce7f0 100644
--- a/drivers/scsi/be2iscsi/be_iscsi.c
+++ b/drivers/scsi/be2iscsi/be_iscsi.c
@@ -27,6 +27,7 @@ extern struct iscsi_transport beiscsi_iscsi_transport;
 
 /**
  * beiscsi_session_create - creates a new iscsi session
+ * @ep: pointer to iscsi ep
  * @cmds_max: max commands supported
  * @qdepth: max queue depth supported
  * @initial_cmdsn: initial iscsi CMDSN
@@ -164,6 +165,7 @@ beiscsi_conn_create(struct iscsi_cls_session *cls_session, 
u32 cid)
  * @cls_session: pointer to iscsi cls session
  * @cls_conn: pointer to iscsi cls conn
  * @transport_fd: EP handle(64 bit)
+ * @is_leading: indicate if this is the session leading connection (MCS)
  *
  * This function binds the TCP Conn with iSCSI Connection and Session.
  */
@@ -992,7 +994,7 @@ static void beiscsi_put_cid(struct beiscsi_hba *phba, 
unsigned short cid)
 
 /**
  * beiscsi_free_ep - free endpoint
- * @ep:pointer to iscsi endpoint structure
+ * @beiscsi_ep: pointer to device endpoint struct
  */
 static void beiscsi_free_ep(struct beiscsi_endpoint *beiscsi_ep)
 {
@@ -1027,9 +1029,10 @@ static void beiscsi_free_ep(struct beiscsi_endpoint 
*beiscsi_ep)
 
 /**
  * beiscsi_open_conn - Ask FW to open a TCP connection
- * @ep:endpoint to be used
+ * @beiscsi_ep: pointer to device endpoint struct
  * @src_addr: The source IP address
  * @dst_addr: The Destination  IP address
+ * @non_blocking: blocking or non-blocking call
  *
  * Asks the FW to open a TCP connection
  */
@@ -1123,7 +1126,7 @@ static int beiscsi_open_conn(struct iscsi_endpoint *ep,
 
 /**
  * beiscsi_ep_connect - Ask chip to create TCP Conn
- * @scsi_host: Pointer to scsi_host structure
+ * @shost: Pointer to scsi_host structure
  * @dst_addr: The IP address of Target
  * @non_blocking: blocking or non-blocking call
  *
@@ -1228,7 +1231,7 @@ static void beiscsi_flush_cq(struct beiscsi_hba *phba)
 
 /**
  * beiscsi_conn_close - Invalidate and upload connection
- * @ep: The iscsi endpoint
+ * @beiscsi_ep: pointer to device endpoint struct
  *
  * Returns 0 on success,  -1 on failure.
  */
-- 
2.25.1



[PATCH v2 24/24] scsi: aic7xxx: aic79xx_osm: Remove set but unused variabes 'saved_scsiid' and 'saved_modes'

2020-07-13 Thread Lee Jones
Haven't been used since 2006.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/aic7xxx/aic79xx_osm.c: In function ‘ahd_linux_queue_abort_cmd’:
 drivers/scsi/aic7xxx/aic79xx_osm.c:2155:17: warning: variable ‘saved_modes’ 
set but not used [-Wunused-but-set-variable]
 drivers/scsi/aic7xxx/aic79xx_osm.c:2148:9: warning: variable ‘saved_scsiid’ 
set but not used [-Wunused-but-set-variable]

Cc: Hannes Reinecke 
Signed-off-by: Lee Jones 
---
 drivers/scsi/aic7xxx/aic79xx_osm.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/scsi/aic7xxx/aic79xx_osm.c 
b/drivers/scsi/aic7xxx/aic79xx_osm.c
index 3782a20d58885..140c4e74ddd7e 100644
--- a/drivers/scsi/aic7xxx/aic79xx_osm.c
+++ b/drivers/scsi/aic7xxx/aic79xx_osm.c
@@ -2141,14 +2141,12 @@ ahd_linux_queue_abort_cmd(struct scsi_cmnd *cmd)
u_int  saved_scbptr;
u_int  active_scbptr;
u_int  last_phase;
-   u_int  saved_scsiid;
u_int  cdb_byte;
intretval;
intwas_paused;
intpaused;
intwait;
intdisconnected;
-   ahd_mode_state saved_modes;
unsigned long flags;
 
pending_scb = NULL;
@@ -2239,7 +2237,6 @@ ahd_linux_queue_abort_cmd(struct scsi_cmnd *cmd)
goto done;
}
 
-   saved_modes = ahd_save_modes(ahd);
ahd_set_modes(ahd, AHD_MODE_SCSI, AHD_MODE_SCSI);
last_phase = ahd_inb(ahd, LASTPHASE);
saved_scbptr = ahd_get_scbptr(ahd);
@@ -2257,7 +2254,6 @@ ahd_linux_queue_abort_cmd(struct scsi_cmnd *cmd)
 * passed in command.  That command is currently active on the
 * bus or is in the disconnected state.
 */
-   saved_scsiid = ahd_inb(ahd, SAVED_SCSIID);
if (last_phase != P_BUSFREE
&& SCB_GET_TAG(pending_scb) == active_scbptr) {
 
-- 
2.25.1



[PATCH v2 01/24] scsi: aacraid: aachba: Repair two kerneldoc headers

2020-07-13 Thread Lee Jones
The function headers for aac_get_config_status() and aac_get_containers()
have suffered bitrot where the documentation hasn't kept up with the API.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/aacraid/aachba.c:358: warning: Function parameter or member 'dev' 
not described in 'aac_get_config_status'
 drivers/scsi/aacraid/aachba.c:358: warning: Function parameter or member 
'commit_flag' not described in 'aac_get_config_status'
 drivers/scsi/aacraid/aachba.c:358: warning: Excess function parameter 'common' 
description in 'aac_get_config_status'
 drivers/scsi/aacraid/aachba.c:450: warning: Function parameter or member 'dev' 
not described in 'aac_get_containers'
 drivers/scsi/aacraid/aachba.c:450: warning: Excess function parameter 'common' 
description in 'aac_get_containers'

Cc: Adaptec OEM Raid Solutions 
Cc: "PMC-Sierra, Inc" 
Signed-off-by: Lee Jones 
---
 drivers/scsi/aacraid/aachba.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c
index 7ae1e545a255c..769af4ca9ca97 100644
--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -350,7 +350,8 @@ static inline int aac_valid_context(struct scsi_cmnd 
*scsicmd,
 
 /**
  * aac_get_config_status   -   check the adapter configuration
- * @common: adapter to query
+ * @dev: aac driver data
+ * @commit_flag: force sending CT_COMMIT_CONFIG
  *
  * Query config status, and commit the configuration if needed.
  */
@@ -442,7 +443,7 @@ static void aac_expose_phy_device(struct scsi_cmnd *scsicmd)
 
 /**
  * aac_get_containers  -   list containers
- * @common: adapter to probe
+ * @dev: aac driver data
  *
  * Make a list of all containers on this controller
  */
-- 
2.25.1



[PATCH v2 07/24] scsi: aacraid: commsup: Fix a bunch of function header issues

2020-07-13 Thread Lee Jones
Some parameters not documented.  Others misspelled.

Also, functions must follow directly after the header that documents them.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/aacraid/commsup.c:223: warning: Function parameter or member 
'scmd' not described in 'aac_fib_alloc_tag'
 drivers/scsi/aacraid/commsup.c:421: warning: Function parameter or member 
'qid' not described in 'aac_queue_get'
 drivers/scsi/aacraid/commsup.c:421: warning: Function parameter or member 
'hw_fib' not described in 'aac_queue_get'
 drivers/scsi/aacraid/commsup.c:421: warning: Excess function parameter 
'priority' description in 'aac_queue_get'
 drivers/scsi/aacraid/commsup.c:421: warning: Excess function parameter 'fib' 
description in 'aac_queue_get'
 drivers/scsi/aacraid/commsup.c:943: warning: Function parameter or member 
'fibptr' not described in 'aac_fib_complete'
 drivers/scsi/aacraid/commsup.c:943: warning: Excess function parameter 'fib' 
description in 'aac_fib_complete'
 drivers/scsi/aacraid/commsup.c:1061: warning: Excess function parameter 'dev' 
description in 'AIF_SNIFF_TIMEOUT'
 drivers/scsi/aacraid/commsup.c:1061: warning: Excess function parameter 
'fibptr' description in 'AIF_SNIFF_TIMEOUT'
 drivers/scsi/aacraid/commsup.c:2428: warning: Function parameter or member 
'data' not described in 'aac_command_thread'
 drivers/scsi/aacraid/commsup.c:2428: warning: Excess function parameter 'dev' 
description in 'aac_command_thread'

Cc: Adaptec OEM Raid Solutions 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: "PMC-Sierra, Inc" 
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/scsi/aacraid/commsup.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/aacraid/commsup.c b/drivers/scsi/aacraid/commsup.c
index 8ee4e1abe568d..adbdc3b7c7a70 100644
--- a/drivers/scsi/aacraid/commsup.c
+++ b/drivers/scsi/aacraid/commsup.c
@@ -214,6 +214,7 @@ int aac_fib_setup(struct aac_dev * dev)
 /**
  * aac_fib_alloc_tag-allocate a fib using tags
  * @dev: Adapter to allocate the fib for
+ * @scmd: SCSI command
  *
  * Allocate a fib from the adapter fib pool using tags
  * from the blk layer.
@@ -405,8 +406,8 @@ static int aac_get_entry (struct aac_dev * dev, u32 qid, 
struct aac_entry **entr
  * aac_queue_get   -   get the next free QE
  * @dev: Adapter
  * @index: Returned index
- * @priority: Priority of fib
- * @fib: Fib to associate with the queue entry
+ * @qid: Queue number
+ * @hw_fib: Fib to associate with the queue entry
  * @wait: Wait if queue full
  * @fibptr: Driver fib object to go with fib
  * @nonotify: Don't notify the adapter
@@ -934,7 +935,7 @@ int aac_fib_adapter_complete(struct fib *fibptr, unsigned 
short size)
 
 /**
  * aac_fib_complete-   fib completion handler
- * @fib: FIB to complete
+ * @fibptr: FIB to complete
  *
  * Will do all necessary work to complete a FIB.
  */
@@ -1049,6 +1050,7 @@ static void aac_handle_aif_bu(struct aac_dev *dev, struct 
aac_aifcmd *aifcmd)
}
 }
 
+#define AIF_SNIFF_TIMEOUT  (500*HZ)
 /**
  * aac_handle_aif  -   Handle a message from the firmware
  * @dev: Which adapter this fib is from
@@ -1057,8 +1059,6 @@ static void aac_handle_aif_bu(struct aac_dev *dev, struct 
aac_aifcmd *aifcmd)
  * This routine handles a driver notify fib from the adapter and
  * dispatches it to the appropriate routine for handling.
  */
-
-#define AIF_SNIFF_TIMEOUT  (500*HZ)
 static void aac_handle_aif(struct aac_dev * dev, struct fib * fibptr)
 {
struct hw_fib * hw_fib = fibptr->hw_fib_va;
@@ -2416,7 +2416,7 @@ static int aac_send_hosttime(struct aac_dev *dev, struct 
timespec64 *now)
 
 /**
  * aac_command_thread  -   command processing thread
- * @dev: Adapter to monitor
+ * @data: Adapter to monitor
  *
  * Waits on the commandready event in it's queue. When the event gets set
  * it will pull FIBs off it's queue. It will continue to pull FIBs off
-- 
2.25.1



[PATCH v2 22/24] scsi: aic7xxx: aic79xx_osm: Remove unused variables 'wait' and 'paused'

2020-07-13 Thread Lee Jones
It looks like they have never actually been used.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/aic7xxx/aic79xx_osm.c: In function ‘ahd_linux_dev_reset’:
 drivers/scsi/aic7xxx/aic79xx_osm.c:782:9: warning: variable ‘wait’ set but not 
used [-Wunused-but-set-variable]
 drivers/scsi/aic7xxx/aic79xx_osm.c:781:9: warning: variable ‘paused’ set but 
not used [-Wunused-but-set-variable]

Cc: Hannes Reinecke 
Signed-off-by: Lee Jones 
---
 drivers/scsi/aic7xxx/aic79xx_osm.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/scsi/aic7xxx/aic79xx_osm.c 
b/drivers/scsi/aic7xxx/aic79xx_osm.c
index 9235b6283c0b3..8e43ff86e0a60 100644
--- a/drivers/scsi/aic7xxx/aic79xx_osm.c
+++ b/drivers/scsi/aic7xxx/aic79xx_osm.c
@@ -775,16 +775,13 @@ ahd_linux_dev_reset(struct scsi_cmnd *cmd)
struct scb *reset_scb;
u_int  cdb_byte;
intretval = SUCCESS;
-   intpaused;
-   intwait;
struct  ahd_initiator_tinfo *tinfo;
struct  ahd_tmode_tstate *tstate;
unsigned long flags;
DECLARE_COMPLETION_ONSTACK(done);
 
reset_scb = NULL;
-   paused = FALSE;
-   wait = FALSE;
+
ahd = *(struct ahd_softc **)cmd->device->host->hostdata;
 
scmd_printk(KERN_INFO, cmd,
-- 
2.25.1



[PATCH v2 23/24] scsi: aic7xxx: aic79xx_osm: Fix 'amount_xferred' set but not used issue

2020-07-13 Thread Lee Jones
'amount_xferred' is used, but only in certain circumstances.  Place
the same stipulations on the defining/allocating of 'amount_xferred'
as is placed when using it.

We've been careful not to change any of the ordering semantics here.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/aic7xxx/aic79xx_osm.c: In function ‘ahd_done’:
 drivers/scsi/aic7xxx/aic79xx_osm.c:1796:12: warning: variable ‘amount_xferred’ 
set but not used [-Wunused-but-set-variable]

Cc: Hannes Reinecke 
Signed-off-by: Lee Jones 
---
 drivers/scsi/aic7xxx/aic79xx_osm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/aic7xxx/aic79xx_osm.c 
b/drivers/scsi/aic7xxx/aic79xx_osm.c
index 8e43ff86e0a60..3782a20d58885 100644
--- a/drivers/scsi/aic7xxx/aic79xx_osm.c
+++ b/drivers/scsi/aic7xxx/aic79xx_osm.c
@@ -1787,10 +1787,12 @@ ahd_done(struct ahd_softc *ahd, struct scb *scb)
 */
cmd->sense_buffer[0] = 0;
if (ahd_get_transaction_status(scb) == CAM_REQ_INPROG) {
+#ifdef AHD_REPORT_UNDERFLOWS
uint32_t amount_xferred;
 
amount_xferred =
ahd_get_transfer_length(scb) - ahd_get_residual(scb);
+#endif
if ((scb->flags & SCB_TRANSMISSION_ERROR) != 0) {
 #ifdef AHD_DEBUG
if ((ahd_debug & AHD_SHOW_MISC) != 0) {
-- 
2.25.1



[PATCH v2 13/24] scsi: ipr: Remove a bunch of set but checked variables

2020-07-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

In file included from  drivers/scsi/ipr.c:73:
 drivers/scsi/ipr.c: In function ‘ipr_mask_and_clear_interrupts’:
 drivers/scsi/ipr.c:740:15: warning: variable ‘int_reg’ set but not used 
[-Wunused-but-set-variable]
 drivers/scsi/ipr.c: In function ‘ipr_cancel_op’:
 drivers/scsi/ipr.c:5497:13: warning: variable ‘int_reg’ set but not used 
[-Wunused-but-set-variable]
 drivers/scsi/ipr.c: In function ‘ipr_iopoll’:
 drivers/scsi/ipr.c:5765:22: warning: variable ‘ioa_cfg’ set but not used 
[-Wunused-but-set-variable]
 drivers/scsi/ipr.c: In function ‘ipr_reset_restore_cfg_space’:
 drivers/scsi/ipr.c:8662:6: warning: variable ‘int_reg’ set but not used 
[-Wunused-but-set-variable]
 drivers/scsi/ipr.c: In function ‘ipr_test_msi’:

Cc: Brian King 
Signed-off-by: Lee Jones 
---
 drivers/scsi/ipr.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index f85020904099e..b0aa58d117cc9 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -738,7 +738,6 @@ struct ipr_cmnd *ipr_get_free_ipr_cmnd(struct ipr_ioa_cfg 
*ioa_cfg)
 static void ipr_mask_and_clear_interrupts(struct ipr_ioa_cfg *ioa_cfg,
  u32 clr_ints)
 {
-   volatile u32 int_reg;
int i;
 
/* Stop new interrupts */
@@ -758,7 +757,7 @@ static void ipr_mask_and_clear_interrupts(struct 
ipr_ioa_cfg *ioa_cfg,
if (ioa_cfg->sis64)
writel(~0, ioa_cfg->regs.clr_interrupt_reg);
writel(clr_ints, ioa_cfg->regs.clr_interrupt_reg32);
-   int_reg = readl(ioa_cfg->regs.sense_interrupt_reg);
+   readl(ioa_cfg->regs.sense_interrupt_reg);
 }
 
 /**
@@ -5510,7 +5509,7 @@ static int ipr_cancel_op(struct scsi_cmnd *scsi_cmd)
struct ipr_ioa_cfg *ioa_cfg;
struct ipr_resource_entry *res;
struct ipr_cmd_pkt *cmd_pkt;
-   u32 ioasc, int_reg;
+   u32 ioasc;
int i, op_found = 0;
struct ipr_hrr_queue *hrrq;
 
@@ -5533,7 +5532,7 @@ static int ipr_cancel_op(struct scsi_cmnd *scsi_cmd)
 * by a still not detected EEH error. In such cases, reading a register 
will
 * trigger the EEH recovery infrastructure.
 */
-   int_reg = readl(ioa_cfg->regs.sense_interrupt_reg);
+   readl(ioa_cfg->regs.sense_interrupt_reg);
 
if (!ipr_is_gscsi(res))
return FAILED;
@@ -5780,7 +5779,6 @@ static int ipr_process_hrrq(struct ipr_hrr_queue 
*hrr_queue, int budget,
 
 static int ipr_iopoll(struct irq_poll *iop, int budget)
 {
-   struct ipr_ioa_cfg *ioa_cfg;
struct ipr_hrr_queue *hrrq;
struct ipr_cmnd *ipr_cmd, *temp;
unsigned long hrrq_flags;
@@ -5788,7 +5786,6 @@ static int ipr_iopoll(struct irq_poll *iop, int budget)
LIST_HEAD(doneq);
 
hrrq = container_of(iop, struct ipr_hrr_queue, iopoll);
-   ioa_cfg = hrrq->ioa_cfg;
 
spin_lock_irqsave(hrrq->lock, hrrq_flags);
completed_ops = ipr_process_hrrq(hrrq, budget, );
@@ -8681,7 +8678,6 @@ static int ipr_dump_mailbox_wait(struct ipr_cmnd *ipr_cmd)
 static int ipr_reset_restore_cfg_space(struct ipr_cmnd *ipr_cmd)
 {
struct ipr_ioa_cfg *ioa_cfg = ipr_cmd->ioa_cfg;
-   u32 int_reg;
 
ENTER;
ioa_cfg->pdev->state_saved = true;
@@ -8697,7 +8693,7 @@ static int ipr_reset_restore_cfg_space(struct ipr_cmnd 
*ipr_cmd)
if (ioa_cfg->sis64) {
/* Set the adapter to the correct endian mode. */
writel(IPR_ENDIAN_SWAP_KEY, ioa_cfg->regs.endian_swap_reg);
-   int_reg = readl(ioa_cfg->regs.endian_swap_reg);
+   readl(ioa_cfg->regs.endian_swap_reg);
}
 
if (ioa_cfg->ioa_unit_checked) {
@@ -10120,7 +10116,6 @@ static irqreturn_t ipr_test_intr(int irq, void *devp)
 static int ipr_test_msi(struct ipr_ioa_cfg *ioa_cfg, struct pci_dev *pdev)
 {
int rc;
-   volatile u32 int_reg;
unsigned long lock_flags = 0;
int irq = pci_irq_vector(pdev, 0);
 
@@ -10131,7 +10126,7 @@ static int ipr_test_msi(struct ipr_ioa_cfg *ioa_cfg, 
struct pci_dev *pdev)
ioa_cfg->msi_received = 0;
ipr_mask_and_clear_interrupts(ioa_cfg, ~IPR_PCII_IOA_TRANS_TO_OPER);
writel(IPR_PCII_IO_DEBUG_ACKNOWLEDGE, 
ioa_cfg->regs.clr_interrupt_mask_reg32);
-   int_reg = readl(ioa_cfg->regs.sense_interrupt_mask_reg);
+   readl(ioa_cfg->regs.sense_interrupt_mask_reg);
spin_unlock_irqrestore(ioa_cfg->host->host_lock, lock_flags);
 
rc = request_irq(irq, ipr_test_intr, 0, IPR_NAME, ioa_cfg);
@@ -10142,7 +10137,7 @@ static int ipr_test_msi(struct ipr_ioa_cfg *ioa_cfg, 
struct pci_dev *pdev)
dev_info(>dev, "IRQ assigned: %d\n", irq);
 
writel(IPR_PCII_IO_DEBUG_ACKNOWLEDGE, 
ioa_cfg->regs.sense_interrupt_reg32);
-   int_reg = readl(ioa_cfg->regs.sense_interrupt_reg);
+   readl(ioa_cfg->regs.sense_interrupt_reg);

[PATCH v2 20/24] scsi: lpfc: lpfc_nvme: Correct some pretty obvious misdocumentation

2020-07-13 Thread Lee Jones
Either due to API slippage before the driver was mainlined or copy/paste errors.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/lpfc/lpfc_nvme.c:254: warning: Function parameter or member 
'pnvme_lport' not described in 'lpfc_nvme_create_queue'
 drivers/scsi/lpfc/lpfc_nvme.c:254: warning: Function parameter or member 
'qsize' not described in 'lpfc_nvme_create_queue'
 drivers/scsi/lpfc/lpfc_nvme.c:254: warning: Excess function parameter 
'lpfc_pnvme' description in 'lpfc_nvme_create_queue'
 drivers/scsi/lpfc/lpfc_nvme.c:311: warning: Function parameter or member 
'pnvme_lport' not described in 'lpfc_nvme_delete_queue'
 drivers/scsi/lpfc/lpfc_nvme.c:311: warning: Excess function parameter 
'lpfc_pnvme' description in 'lpfc_nvme_delete_queue'
 drivers/scsi/lpfc/lpfc_nvme.c:689: warning: Function parameter or member 
'gen_req_cmp' not described in '__lpfc_nvme_ls_req'
 drivers/scsi/lpfc/lpfc_nvme.c:801: warning: Function parameter or member 
'pnvme_lport' not described in 'lpfc_nvme_ls_req'
 drivers/scsi/lpfc/lpfc_nvme.c:801: warning: Function parameter or member 
'pnvme_rport' not described in 'lpfc_nvme_ls_req'
 drivers/scsi/lpfc/lpfc_nvme.c:801: warning: Function parameter or member 
'pnvme_lsreq' not described in 'lpfc_nvme_ls_req'
 drivers/scsi/lpfc/lpfc_nvme.c:801: warning: Excess function parameter 
'lpfc_nvme_lport' description in 'lpfc_nvme_ls_req'
 drivers/scsi/lpfc/lpfc_nvme.c:801: warning: Excess function parameter 
'lpfc_nvme_rport' description in 'lpfc_nvme_ls_req'
 drivers/scsi/lpfc/lpfc_nvme.c:937: warning: Function parameter or member 
'pnvme_lport' not described in 'lpfc_nvme_ls_abort'
 drivers/scsi/lpfc/lpfc_nvme.c:937: warning: Function parameter or member 
'pnvme_rport' not described in 'lpfc_nvme_ls_abort'
 drivers/scsi/lpfc/lpfc_nvme.c:937: warning: Function parameter or member 
'pnvme_lsreq' not described in 'lpfc_nvme_ls_abort'
 drivers/scsi/lpfc/lpfc_nvme.c:937: warning: Excess function parameter 
'lpfc_nvme_lport' description in 'lpfc_nvme_ls_abort'
 drivers/scsi/lpfc/lpfc_nvme.c:937: warning: Excess function parameter 
'lpfc_nvme_rport' description in 'lpfc_nvme_ls_abort'
 drivers/scsi/lpfc/lpfc_nvme.c:1075: warning: Function parameter or member 
'phba' not described in 'lpfc_nvme_io_cmd_wqe_cmpl'
 drivers/scsi/lpfc/lpfc_nvme.c:1075: warning: Function parameter or member 
'pwqeIn' not described in 'lpfc_nvme_io_cmd_wqe_cmpl'
 drivers/scsi/lpfc/lpfc_nvme.c:1075: warning: Function parameter or member 
'wcqe' not described in 'lpfc_nvme_io_cmd_wqe_cmpl'
 drivers/scsi/lpfc/lpfc_nvme.c:1075: warning: Excess function parameter 
'lpfc_pnvme' description in 'lpfc_nvme_io_cmd_wqe_cmpl'
 drivers/scsi/lpfc/lpfc_nvme.c:1075: warning: Excess function parameter 
'lpfc_nvme_lport' description in 'lpfc_nvme_io_cmd_wqe_cmpl'
 drivers/scsi/lpfc/lpfc_nvme.c:1075: warning: Excess function parameter 
'lpfc_nvme_rport' description in 'lpfc_nvme_io_cmd_wqe_cmpl'
 drivers/scsi/lpfc/lpfc_nvme.c:1313: warning: Function parameter or member 
'vport' not described in 'lpfc_nvme_prep_io_cmd'
 drivers/scsi/lpfc/lpfc_nvme.c:1313: warning: Function parameter or member 
'lpfc_ncmd' not described in 'lpfc_nvme_prep_io_cmd'
 drivers/scsi/lpfc/lpfc_nvme.c:1313: warning: Function parameter or member 
'pnode' not described in 'lpfc_nvme_prep_io_cmd'
 drivers/scsi/lpfc/lpfc_nvme.c:1313: warning: Function parameter or member 
'cstat' not described in 'lpfc_nvme_prep_io_cmd'
 drivers/scsi/lpfc/lpfc_nvme.c:1313: warning: Excess function parameter 
'lpfc_pnvme' description in 'lpfc_nvme_prep_io_cmd'
 drivers/scsi/lpfc/lpfc_nvme.c:1313: warning: Excess function parameter 
'lpfc_nvme_lport' description in 'lpfc_nvme_prep_io_cmd'
 drivers/scsi/lpfc/lpfc_nvme.c:1313: warning: Excess function parameter 
'lpfc_nvme_rport' description in 'lpfc_nvme_prep_io_cmd'
 drivers/scsi/lpfc/lpfc_nvme.c:1313: warning: Excess function parameter 
'lpfc_nvme_fcreq' description in 'lpfc_nvme_prep_io_cmd'
 drivers/scsi/lpfc/lpfc_nvme.c:1313: warning: Excess function parameter 
'hw_queue_handle' description in 'lpfc_nvme_prep_io_cmd'
 drivers/scsi/lpfc/lpfc_nvme.c:1420: warning: Function parameter or member 
'vport' not described in 'lpfc_nvme_prep_io_dma'
 drivers/scsi/lpfc/lpfc_nvme.c:1420: warning: Function parameter or member 
'lpfc_ncmd' not described in 'lpfc_nvme_prep_io_dma'
 drivers/scsi/lpfc/lpfc_nvme.c:1420: warning: Excess function parameter 
'lpfc_pnvme' description in 'lpfc_nvme_prep_io_dma'
 drivers/scsi/lpfc/lpfc_nvme.c:1420: warning: Excess function parameter 
'lpfc_nvme_lport' description in 'lpfc_nvme_prep_io_dma'
 drivers/scsi/lpfc/lpfc_nvme.c:1420: warning: Excess function parameter 
'lpfc_nvme_rport' description in 'lpfc_nvme_prep_io_dma'
 drivers/scsi/lpfc/lpfc_nvme.c:1420: warning: Excess function parameter 
'lpfc_nvme_fcreq' description in 'lpfc_nvme_prep_io_dma'
 drivers/scsi/lpfc/lpfc_nvme.c:1420: warning: Excess function parameter 
'hw_queue_handle' description in 'lpfc_nvme_prep_io_dma'
 

[PATCH v2 05/24] scsi: aacraid: dpcsup: Demote partially documented function header

2020-07-13 Thread Lee Jones
This should be populated by someone who knows the meaning of all the params.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/aacraid/dpcsup.c:272: warning: Function parameter or member 
'isAif' not described in 'aac_intr_normal'
 drivers/scsi/aacraid/dpcsup.c:272: warning: Function parameter or member 
'isFastResponse' not described in 'aac_intr_normal'
 drivers/scsi/aacraid/dpcsup.c:272: warning: Function parameter or member 
'aif_fib' not described in 'aac_intr_normal'

Cc: Adaptec OEM Raid Solutions 
Cc: "PMC-Sierra, Inc" 
Signed-off-by: Lee Jones 
---
 drivers/scsi/aacraid/dpcsup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/aacraid/dpcsup.c b/drivers/scsi/aacraid/dpcsup.c
index 749f8e740ece1..fbe334c59f376 100644
--- a/drivers/scsi/aacraid/dpcsup.c
+++ b/drivers/scsi/aacraid/dpcsup.c
@@ -258,7 +258,7 @@ static void aac_aif_callback(void *context, struct fib * 
fibptr)
 }
 
 
-/**
+/*
  * aac_intr_normal -   Handle command replies
  * @dev: Device
  * @index: completion reference
-- 
2.25.1



[PATCH v2 06/24] scsi: aic94xx: aic94xx_seq: Document 'lseq' and repair asd_update_port_links() header

2020-07-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/scsi/aic94xx/aic94xx_seq.c:587: warning: Function parameter or member 
'lseq' not described in 'asd_init_lseq_mip'
 drivers/scsi/aic94xx/aic94xx_seq.c:674: warning: Function parameter or member 
'lseq' not described in 'asd_init_lseq_mdp'
 drivers/scsi/aic94xx/aic94xx_seq.c:958: warning: Function parameter or member 
'lseq' not described in 'asd_init_lseq_cio'
 drivers/scsi/aic94xx/aic94xx_seq.c:1364: warning: Function parameter or member 
'asd_ha' not described in 'asd_update_port_links'
 drivers/scsi/aic94xx/aic94xx_seq.c:1364: warning: Function parameter or member 
'phy' not described in 'asd_update_port_links'
 drivers/scsi/aic94xx/aic94xx_seq.c:1364: warning: Excess function parameter 
'sas_phy' description in 'asd_update_port_links'

Cc: Luben Tuikov 
Signed-off-by: Lee Jones 
---
 drivers/scsi/aic94xx/aic94xx_seq.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/aic94xx/aic94xx_seq.c 
b/drivers/scsi/aic94xx/aic94xx_seq.c
index 11853ec29d87a..c0f685c86851b 100644
--- a/drivers/scsi/aic94xx/aic94xx_seq.c
+++ b/drivers/scsi/aic94xx/aic94xx_seq.c
@@ -582,6 +582,7 @@ static void asd_init_cseq_scratch(struct asd_ha_struct 
*asd_ha)
 /**
  * asd_init_lseq_mip -- initialize LSEQ Mode independent pages 0-3
  * @asd_ha: pointer to host adapter structure
+ * @lseq:  link sequencer
  */
 static void asd_init_lseq_mip(struct asd_ha_struct *asd_ha, u8 lseq)
 {
@@ -669,6 +670,7 @@ static void asd_init_lseq_mip(struct asd_ha_struct *asd_ha, 
u8 lseq)
 /**
  * asd_init_lseq_mdp -- initialize LSEQ mode dependent pages.
  * @asd_ha: pointer to host adapter structure
+ * @lseq:  link sequencer
  */
 static void asd_init_lseq_mdp(struct asd_ha_struct *asd_ha,  int lseq)
 {
@@ -953,6 +955,7 @@ static void asd_init_cseq_cio(struct asd_ha_struct *asd_ha)
 /**
  * asd_init_lseq_cio -- initialize LmSEQ CIO registers
  * @asd_ha: pointer to host adapter structure
+ * @lseq:  link sequencer
  */
 static void asd_init_lseq_cio(struct asd_ha_struct *asd_ha, int lseq)
 {
@@ -1345,7 +1348,8 @@ int asd_start_seqs(struct asd_ha_struct *asd_ha)
 
 /**
  * asd_update_port_links -- update port_map_by_links and phy_is_up
- * @sas_phy: pointer to the phy which has been added to a port
+ * @asd_ha: pointer to host adapter structure
+ * @phy: pointer to the phy which has been added to a port
  *
  * 1) When a link reset has completed and we got BYTES DMAED with a
  * valid frame we call this function for that phy, to indicate that
-- 
2.25.1



[PATCH v2 08/24] scsi: aic94xx: aic94xx_scb: Fix a couple of formatting and bitrot issues

2020-07-13 Thread Lee Jones
Kerneldoc format should be '@.*: ', else the checker gets confused.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/aic94xx/aic94xx_scb.c:137: warning: Function parameter or member 
'phy' not described in 'asd_get_attached_sas_addr'
 drivers/scsi/aic94xx/aic94xx_scb.c:137: warning: Function parameter or member 
'sas_addr' not described in 'asd_get_attached_sas_addr'
 drivers/scsi/aic94xx/aic94xx_scb.c:860: warning: Function parameter or member 
't' not described in 'asd_ascb_timedout'
 drivers/scsi/aic94xx/aic94xx_scb.c:860: warning: Excess function parameter 
'data' description in 'asd_ascb_timedout'

Cc: Luben Tuikov 
Signed-off-by: Lee Jones 
---
 drivers/scsi/aic94xx/aic94xx_scb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/aic94xx/aic94xx_scb.c 
b/drivers/scsi/aic94xx/aic94xx_scb.c
index 4a80ec08f0c96..c264b4b56970b 100644
--- a/drivers/scsi/aic94xx/aic94xx_scb.c
+++ b/drivers/scsi/aic94xx/aic94xx_scb.c
@@ -123,8 +123,8 @@ static unsigned ord_phy(struct asd_ha_struct *asd_ha, 
struct asd_phy *phy)
 
 /**
  * asd_get_attached_sas_addr -- extract/generate attached SAS address
- * phy: pointer to asd_phy
- * sas_addr: pointer to buffer where the SAS address is to be written
+ * @phy: pointer to asd_phy
+ * @sas_addr: pointer to buffer where the SAS address is to be written
  *
  * This function extracts the SAS address from an IDENTIFY frame
  * received.  If OOB is SATA, then a SAS address is generated from the
@@ -847,7 +847,7 @@ void asd_build_initiate_link_adm_task(struct asd_ascb 
*ascb, int phy_id,
 
 /**
  * asd_ascb_timedout -- called when a pending SCB's timer has expired
- * @data: unsigned long, a pointer to the ascb in question
+ * @t: Timer context used to fetch the SCB
  *
  * This is the default timeout function which does the most necessary.
  * Upper layers can implement their own timeout function, say to free
-- 
2.25.1



[PATCH v2 18/24] scsi: be2iscsi: be_main: Fix misdocumentation of 'pcontext'

2020-07-13 Thread Lee Jones
Also demote unintentional kerneldoc header.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/be2iscsi/be_main.c:986: warning: Function parameter or member 
'pcontext' not described in 'alloc_wrb_handle'
 drivers/scsi/be2iscsi/be_main.c:986: warning: Excess function parameter 
'pwrb_context' description in 'alloc_wrb_handle'
 drivers/scsi/be2iscsi/be_main.c:1409: warning: Function parameter or member 
'beiscsi_conn' not described in 'beiscsi_complete_pdu'
 drivers/scsi/be2iscsi/be_main.c:1409: warning: Function parameter or member 
'phdr' not described in 'beiscsi_complete_pdu'
 drivers/scsi/be2iscsi/be_main.c:1409: warning: Function parameter or member 
'pdata' not described in 'beiscsi_complete_pdu'
 drivers/scsi/be2iscsi/be_main.c:1409: warning: Function parameter or member 
'dlen' not described in 'beiscsi_complete_pdu'

Cc: Subbu Seetharaman 
Cc: Ketan Mukadam 
Cc: Jitendra Bhivare 
Cc: linux-driv...@broadcom.com
Signed-off-by: Lee Jones 
---
 drivers/scsi/be2iscsi/be_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 9b81cfbbc5c53..8dc2e0824ad78 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -977,7 +977,7 @@ beiscsi_get_wrb_handle(struct hwi_wrb_context *pwrb_context,
  * alloc_wrb_handle - To allocate a wrb handle
  * @phba: The hba pointer
  * @cid: The cid to use for allocation
- * @pwrb_context: ptr to ptr to wrb context
+ * @pcontext: ptr to ptr to wrb context
  *
  * This happens under session_lock until submission to chip
  */
@@ -1394,7 +1394,7 @@ static void hwi_complete_cmd(struct beiscsi_conn 
*beiscsi_conn,
spin_unlock_bh(>back_lock);
 }
 
-/**
+/*
  * ASYNC PDUs include
  * a. Unsolicited NOP-In (target initiated NOP-In)
  * b. ASYNC Messages
-- 
2.25.1



[PATCH v2 15/24] scsi: myrs: Demote obvious misuse of kerneldoc to standard comment blocks

2020-07-13 Thread Lee Jones
No attempt has been made to document any of the demoted functions here.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/myrs.c:94: warning: Function parameter or member 'cmd_blk' not 
described in 'myrs_reset_cmd'
 drivers/scsi/myrs.c:105: warning: Function parameter or member 'cs' not 
described in 'myrs_qcmd'
 drivers/scsi/myrs.c:105: warning: Function parameter or member 'cmd_blk' not 
described in 'myrs_qcmd'
 drivers/scsi/myrs.c:130: warning: Function parameter or member 'cs' not 
described in 'myrs_exec_cmd'
 drivers/scsi/myrs.c:130: warning: Function parameter or member 'cmd_blk' not 
described in 'myrs_exec_cmd'
 drivers/scsi/myrs.c:149: warning: Function parameter or member 'cs' not 
described in 'myrs_report_progress'
 drivers/scsi/myrs.c:149: warning: Function parameter or member 'ldev_num' not 
described in 'myrs_report_progress'
 drivers/scsi/myrs.c:149: warning: Function parameter or member 'msg' not 
described in 'myrs_report_progress'
 drivers/scsi/myrs.c:149: warning: Function parameter or member 'blocks' not 
described in 'myrs_report_progress'
 drivers/scsi/myrs.c:149: warning: Function parameter or member 'size' not 
described in 'myrs_report_progress'
 drivers/scsi/myrs.c:160: warning: Function parameter or member 'cs' not 
described in 'myrs_get_ctlr_info'
 drivers/scsi/myrs.c:222: warning: Function parameter or member 'cs' not 
described in 'myrs_get_ldev_info'
 drivers/scsi/myrs.c:222: warning: Function parameter or member 'ldev_num' not 
described in 'myrs_get_ldev_info'
 drivers/scsi/myrs.c:222: warning: Function parameter or member 'ldev_info' not 
described in 'myrs_get_ldev_info'
 drivers/scsi/myrs.c:310: warning: Function parameter or member 'cs' not 
described in 'myrs_get_pdev_info'
 drivers/scsi/myrs.c:310: warning: Function parameter or member 'channel' not 
described in 'myrs_get_pdev_info'
 drivers/scsi/myrs.c:310: warning: Function parameter or member 'target' not 
described in 'myrs_get_pdev_info'
 drivers/scsi/myrs.c:310: warning: Function parameter or member 'lun' not 
described in 'myrs_get_pdev_info'
 drivers/scsi/myrs.c:310: warning: Function parameter or member 'pdev_info' not 
described in 'myrs_get_pdev_info'
 drivers/scsi/myrs.c:353: warning: Function parameter or member 'cs' not 
described in 'myrs_dev_op'
 drivers/scsi/myrs.c:353: warning: Function parameter or member 'opcode' not 
described in 'myrs_dev_op'
 drivers/scsi/myrs.c:353: warning: Function parameter or member 'opdev' not 
described in 'myrs_dev_op'
 drivers/scsi/myrs.c:379: warning: Function parameter or member 'cs' not 
described in 'myrs_translate_pdev'
 drivers/scsi/myrs.c:379: warning: Function parameter or member 'channel' not 
described in 'myrs_translate_pdev'
 drivers/scsi/myrs.c:379: warning: Function parameter or member 'target' not 
described in 'myrs_translate_pdev'
 drivers/scsi/myrs.c:379: warning: Function parameter or member 'lun' not 
described in 'myrs_translate_pdev'
 drivers/scsi/myrs.c:379: warning: Function parameter or member 'devmap' not 
described in 'myrs_translate_pdev'
 drivers/scsi/myrs.c:422: warning: Function parameter or member 'cs' not 
described in 'myrs_get_event'
 drivers/scsi/myrs.c:422: warning: Function parameter or member 'event_num' not 
described in 'myrs_get_event'
 drivers/scsi/myrs.c:422: warning: Function parameter or member 'event_buf' not 
described in 'myrs_get_event'
 drivers/scsi/myrs.c:484: warning: Function parameter or member 'cs' not 
described in 'myrs_enable_mmio_mbox'
 drivers/scsi/myrs.c:484: warning: Function parameter or member 
'enable_mbox_fn' not described in 'myrs_enable_mmio_mbox'
 drivers/scsi/myrs.c:584: warning: Function parameter or member 'cs' not 
described in 'myrs_get_config'
 drivers/scsi/myrs.c:688: warning: cannot understand function prototype: 
'struct '
 drivers/scsi/myrs.c:1967: warning: Function parameter or member 'dev' not 
described in 'myrs_is_raid'
 drivers/scsi/myrs.c:1980: warning: Function parameter or member 'dev' not 
described in 'myrs_get_resync'
 drivers/scsi/myrs.c:2005: warning: Function parameter or member 'dev' not 
described in 'myrs_get_state'
 drivers/scsi/myrs.c:2343: warning: bad line:   the Error Status Register when 
the driver performs the BIOS handshaking.
 drivers/scsi/myrs.c:2344: warning: bad line:   It returns true for fatal 
errors and false otherwise.
 drivers/scsi/myrs.c:2349: warning: Function parameter or member 'cs' not 
described in 'myrs_err_status'
 drivers/scsi/myrs.c:2349: warning: Function parameter or member 'status' not 
described in 'myrs_err_status'
 drivers/scsi/myrs.c:2349: warning: Function parameter or member 'parm0' not 
described in 'myrs_err_status'
 drivers/scsi/myrs.c:2349: warning: Function parameter or member 'parm1' not 
described in 'myrs_err_status'

Cc: Hannes Reinecke 
Cc: Linux GmbH 
Cc: "Leonard N. Zubkoff" 
Signed-off-by: Lee Jones 
---
 drivers/scsi/myrs.c | 34 +-
 1 file changed, 17 insertions(+), 17 

[PATCH v2 19/24] scsi: be2iscsi: be_mgmt: Add missing function parameter description

2020-07-13 Thread Lee Jones
Also promote fully documented function header to kerneldoc.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/be2iscsi/be_mgmt.c:112: warning: Function parameter or member 
'phba' not described in 'mgmt_open_connection'

Cc: Subbu Seetharaman 
Cc: Ketan Mukadam 
Cc: Jitendra Bhivare 
Cc: linux-driv...@broadcom.com
Signed-off-by: Lee Jones 
---
 drivers/scsi/be2iscsi/be_mgmt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/be2iscsi/be_mgmt.c b/drivers/scsi/be2iscsi/be_mgmt.c
index a2d69b287c7bb..96d6e384b2b25 100644
--- a/drivers/scsi/be2iscsi/be_mgmt.c
+++ b/drivers/scsi/be2iscsi/be_mgmt.c
@@ -97,6 +97,7 @@ unsigned int mgmt_vendor_specific_fw_cmd(struct be_ctrl_info 
*ctrl,
 
 /**
  * mgmt_open_connection()- Establish a TCP CXN
+ * @phba: driver priv structure
  * @dst_addr: Destination Address
  * @beiscsi_ep: ptr to device endpoint struct
  * @nonemb_cmd: ptr to memory allocated for command
@@ -209,7 +210,7 @@ int mgmt_open_connection(struct beiscsi_hba *phba,
return tag;
 }
 
-/*
+/**
  * beiscsi_exec_nemb_cmd()- execute non-embedded MBX cmd
  * @phba: driver priv structure
  * @nonemb_cmd: DMA address of the MBX command to be issued
-- 
2.25.1



[PATCH v2 09/24] scsi: aacraid: rx: Fill in the very parameter descriptions for rx_sync_cmd()

2020-07-13 Thread Lee Jones
... and document aac_rx_ioremap() 'dev' param.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/aacraid/rx.c:156: warning: Function parameter or member 'p2' not 
described in 'rx_sync_cmd'
 drivers/scsi/aacraid/rx.c:156: warning: Function parameter or member 'p3' not 
described in 'rx_sync_cmd'
 drivers/scsi/aacraid/rx.c:156: warning: Function parameter or member 'p4' not 
described in 'rx_sync_cmd'
 drivers/scsi/aacraid/rx.c:156: warning: Function parameter or member 'p5' not 
described in 'rx_sync_cmd'
 drivers/scsi/aacraid/rx.c:156: warning: Function parameter or member 'p6' not 
described in 'rx_sync_cmd'
 drivers/scsi/aacraid/rx.c:156: warning: Function parameter or member 'status' 
not described in 'rx_sync_cmd'
 drivers/scsi/aacraid/rx.c:156: warning: Function parameter or member 'r1' not 
described in 'rx_sync_cmd'
 drivers/scsi/aacraid/rx.c:156: warning: Function parameter or member 'r2' not 
described in 'rx_sync_cmd'
 drivers/scsi/aacraid/rx.c:156: warning: Function parameter or member 'r3' not 
described in 'rx_sync_cmd'
 drivers/scsi/aacraid/rx.c:156: warning: Function parameter or member 'r4' not 
described in 'rx_sync_cmd'
 drivers/scsi/aacraid/rx.c:156: warning: Excess function parameter 'ret' 
description in 'rx_sync_cmd'
 drivers/scsi/aacraid/rx.c:450: warning: Function parameter or member 'dev' not 
described in 'aac_rx_ioremap'

Cc: Adaptec OEM Raid Solutions 
Cc: "PMC-Sierra, Inc" 
Signed-off-by: Lee Jones 
---
 drivers/scsi/aacraid/rx.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/aacraid/rx.c b/drivers/scsi/aacraid/rx.c
index 3dea348bd25d2..cdccf9abcdc40 100644
--- a/drivers/scsi/aacraid/rx.c
+++ b/drivers/scsi/aacraid/rx.c
@@ -144,7 +144,16 @@ static void aac_rx_enable_interrupt_message(struct aac_dev 
*dev)
  * @dev: Adapter
  * @command: Command to execute
  * @p1: first parameter
- * @ret: adapter status
+ * @p2: second parameter
+ * @p3: third parameter
+ * @p4: forth parameter
+ * @p5: fifth parameter
+ * @p6: sixth parameter
+ * @status: adapter status
+ * @r1: first return value
+ * @r2: second return value
+ * @r3: third return value
+ * @r4: forth return value
  *
  * This routine will send a synchronous command to the adapter and wait 
  * for its completion.
@@ -443,6 +452,7 @@ static int aac_rx_deliver_message(struct fib * fib)
 
 /**
  * aac_rx_ioremap
+ * @dev: adapter
  * @size: mapping resize request
  *
  */
-- 
2.25.1



Re: [PATCH v4 4/4] PCI/ACS: Enable PCI_ACS_TB for untrusted/external-facing devices

2020-07-13 Thread Joerg Roedel
On Sat, Jul 11, 2020 at 09:58:38PM -0500, Bjorn Helgaas wrote:
> If BIOS handed off with ATS enabled and we somehow relied on it being
> already enabled, something might break if we start disabling ATS.
> Just a theoretical possibility, doesn't seem likely to me.

I don't think this will be a problem. When the BIOS enables ATS for a
device it also needs to enable the IOMMU already, an we are not handling
an already enabled IOMMU (outside of kdump kernels) very well.


Regards,

Joerg


[PATCH v2 11/24] scsi: ipr: Fix a mountain of kerneldoc misdemeanours

2020-07-13 Thread Lee Jones
Mainly misspellings and/or missing function parameter descriptions.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/ipr.c:10100:15: warning: variable ‘int_reg’ set but not used 
[-Wunused-but-set-variable]
 drivers/scsi/ipr.c:679: warning: Function parameter or member 'fast_done' not 
described in 'ipr_init_ipr_cmnd'
 drivers/scsi/ipr.c:697: warning: Function parameter or member 'hrrq' not 
described in '__ipr_get_free_ipr_cmnd'
 drivers/scsi/ipr.c:697: warning: Excess function parameter 'ioa_cfg' 
description in '__ipr_get_free_ipr_cmnd'
 drivers/scsi/ipr.c:1297: warning: Function parameter or member 'buffer' not 
described in '__ipr_format_res_path'
 drivers/scsi/ipr.c:1297: warning: Excess function parameter 'buf' description 
in '__ipr_format_res_path'
 drivers/scsi/ipr.c:1321: warning: Function parameter or member 'buffer' not 
described in 'ipr_format_res_path'
 drivers/scsi/ipr.c:1321: warning: Excess function parameter 'buf' description 
in 'ipr_format_res_path'
 drivers/scsi/ipr.c:1400: warning: Excess function parameter 'cfgtew' 
description in 'ipr_clear_res_target'
 drivers/scsi/ipr.c:2679: warning: Function parameter or member 't' not 
described in 'ipr_timeout'
 drivers/scsi/ipr.c:2679: warning: Excess function parameter 'ipr_cmd' 
description in 'ipr_timeout'
 drivers/scsi/ipr.c:2712: warning: Function parameter or member 't' not 
described in 'ipr_oper_timeout'
 drivers/scsi/ipr.c:2712: warning: Excess function parameter 'ipr_cmd' 
description in 'ipr_oper_timeout'
 drivers/scsi/ipr.c:3494: warning: Function parameter or member 'attr' not 
described in 'ipr_show_fw_version'
 drivers/scsi/ipr.c:3528: warning: Function parameter or member 'attr' not 
described in 'ipr_show_log_level'
 drivers/scsi/ipr.c:3551: warning: Function parameter or member 'attr' not 
described in 'ipr_store_log_level'
 drivers/scsi/ipr.c:3551: warning: Function parameter or member 'count' not 
described in 'ipr_store_log_level'
 drivers/scsi/ipr.c:3586: warning: Function parameter or member 'attr' not 
described in 'ipr_store_diagnostics'
 drivers/scsi/ipr.c:3642: warning: Function parameter or member 'dev' not 
described in 'ipr_show_adapter_state'
 drivers/scsi/ipr.c:3642: warning: Function parameter or member 'attr' not 
described in 'ipr_show_adapter_state'
 drivers/scsi/ipr.c:3642: warning: Excess function parameter 'class_dev' 
description in 'ipr_show_adapter_state'
 drivers/scsi/ipr.c:3671: warning: Function parameter or member 'attr' not 
described in 'ipr_store_adapter_state'
 drivers/scsi/ipr.c:3722: warning: Function parameter or member 'attr' not 
described in 'ipr_store_reset_adapter'
 drivers/scsi/ipr.c:3783: warning: Function parameter or member 'attr' not 
described in 'ipr_store_iopoll_weight'
 drivers/scsi/ipr.c:3783: warning: Function parameter or member 'count' not 
described in 'ipr_store_iopoll_weight'
 drivers/scsi/ipr.c:3883: warning: Function parameter or member 'sglist' not 
described in 'ipr_free_ucode_buffer'
 drivers/scsi/ipr.c:3883: warning: Excess function parameter 'p_dnld' 
description in 'ipr_free_ucode_buffer'
 drivers/scsi/ipr.c:4074: warning: Function parameter or member 'dev' not 
described in 'ipr_store_update_fw'
 drivers/scsi/ipr.c:4074: warning: Function parameter or member 'attr' not 
described in 'ipr_store_update_fw'
 drivers/scsi/ipr.c:4074: warning: Excess function parameter 'class_dev' 
description in 'ipr_store_update_fw'
 drivers/scsi/ipr.c:4149: warning: Function parameter or member 'attr' not 
described in 'ipr_show_fw_type'
 drivers/scsi/ipr.c:4489: warning: Excess function parameter 'reason' 
description in 'ipr_change_queue_depth'
 drivers/scsi/ipr.c:4660: warning: Function parameter or member 'attr' not 
described in 'ipr_show_raw_mode'
 drivers/scsi/ipr.c:4688: warning: Function parameter or member 'attr' not 
described in 'ipr_store_raw_mode'
 drivers/scsi/ipr.c:4688: warning: Function parameter or member 'count' not 
described in 'ipr_store_raw_mode'
 drivers/scsi/ipr.c:5069: warning: Function parameter or member 'ipr_cmd' not 
described in 'ipr_cmnd_is_free'
 drivers/scsi/ipr.c:5108: warning: Function parameter or member 'ioa_cfg' not 
described in 'ipr_wait_for_ops'
 drivers/scsi/ipr.c:5108: warning: Excess function parameter 'ipr_cmd' 
description in 'ipr_wait_for_ops'
 drivers/scsi/ipr.c:5272: warning: Function parameter or member 'deadline' not 
described in 'ipr_sata_reset'
 drivers/scsi/ipr.c:5453: warning: Function parameter or member 't' not 
described in 'ipr_abort_timeout'
 drivers/scsi/ipr.c:5453: warning: Excess function parameter 'ipr_cmd' 
description in 'ipr_abort_timeout'
 drivers/scsi/ipr.c:5578: warning: Function parameter or member 'shost' not 
described in 'ipr_scan_finished'
 drivers/scsi/ipr.c:5578: warning: Function parameter or member 'elapsed_time' 
not described in 'ipr_scan_finished'
 drivers/scsi/ipr.c:5578: warning: Excess function parameter 'scsi_cmd' 
description in 'ipr_scan_finished'
 

[PATCH v2 03/24] scsi: aacraid: dpcsup: Fix logical bug when !DBG

2020-07-13 Thread Lee Jones
When DBG is not enabled FIB_COUNTER_INCREMENT() results in an
empty statement, leaving the contents of if() and else() empty.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/aacraid/dpcsup.c: In function ‘aac_response_normal’:
 drivers/scsi/aacraid/dpcsup.c:105:50: warning: suggest braces around empty 
body in an ‘else’ statement [-Wempty-body]
 105 | FIB_COUNTER_INCREMENT(aac_config.AsyncRecved);
 | ^
 drivers/scsi/aacraid/dpcsup.c: In function ‘aac_intr_normal’:
 drivers/scsi/aacraid/dpcsup.c:411:30: warning: suggest braces around empty 
body in an ‘else’ statement [-Wempty-body]
 411 | aac_config.AsyncRecved);
 | ^

Cc: Adaptec OEM Raid Solutions 
Cc: "PMC-Sierra, Inc" 
Signed-off-by: Lee Jones 
---
 drivers/scsi/aacraid/dpcsup.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/aacraid/dpcsup.c b/drivers/scsi/aacraid/dpcsup.c
index a557aa629827e..25ebb94368f2c 100644
--- a/drivers/scsi/aacraid/dpcsup.c
+++ b/drivers/scsi/aacraid/dpcsup.c
@@ -99,10 +99,11 @@ unsigned int aac_response_normal(struct aac_queue * q)
}
if (hwfib->header.XferState & cpu_to_le32(NoResponseExpected | 
Async)) 
{
-   if (hwfib->header.XferState & 
cpu_to_le32(NoResponseExpected))
+   if (hwfib->header.XferState & 
cpu_to_le32(NoResponseExpected)) {

FIB_COUNTER_INCREMENT(aac_config.NoResponseRecved);
-   else 
+   } else {
FIB_COUNTER_INCREMENT(aac_config.AsyncRecved);
+   }
/*
 *  NOTE:  we cannot touch the fib after this
 *  call, because it may have been deallocated.
@@ -403,12 +404,13 @@ unsigned int aac_intr_normal(struct aac_dev *dev, u32 
index, int isAif,
if (hwfib->header.XferState &
cpu_to_le32(NoResponseExpected | Async)) {
if (hwfib->header.XferState & cpu_to_le32(
-   NoResponseExpected))
+   NoResponseExpected)) {
FIB_COUNTER_INCREMENT(
aac_config.NoResponseRecved);
-   else
+   } else {
FIB_COUNTER_INCREMENT(
aac_config.AsyncRecved);
+   }
start_callback = 1;
} else {
unsigned long flagv;
-- 
2.25.1



[PATCH v2 04/24] scsi: aacraid: dpcsup: Remove unused variable 'status'

2020-07-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/scsi/aacraid/dpcsup.c: In function ‘aac_aif_callback’:
 drivers/scsi/aacraid/dpcsup.c:232:6: warning: variable ‘status’ set but not 
used [-Wunused-but-set-variable]
 232 | int status;
 | ^~

Cc: Adaptec OEM Raid Solutions 
Cc: "PMC-Sierra, Inc" 
Signed-off-by: Lee Jones 
---
 drivers/scsi/aacraid/dpcsup.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/aacraid/dpcsup.c b/drivers/scsi/aacraid/dpcsup.c
index 25ebb94368f2c..749f8e740ece1 100644
--- a/drivers/scsi/aacraid/dpcsup.c
+++ b/drivers/scsi/aacraid/dpcsup.c
@@ -230,7 +230,6 @@ static void aac_aif_callback(void *context, struct fib * 
fibptr)
struct fib *fibctx;
struct aac_dev *dev;
struct aac_aifcmd *cmd;
-   int status;
 
fibctx = (struct fib *)context;
BUG_ON(fibptr == NULL);
@@ -250,7 +249,7 @@ static void aac_aif_callback(void *context, struct fib * 
fibptr)
cmd = (struct aac_aifcmd *) fib_data(fibctx);
cmd->command = cpu_to_le32(AifReqEvent);
 
-   status = aac_fib_send(AifRequest,
+   aac_fib_send(AifRequest,
fibctx,
sizeof(struct hw_fib)-sizeof(struct aac_fibhdr),
FsaNormal,
-- 
2.25.1



[PATCH v2 10/24] scsi: pm8001: pm8001_ctl: Provide descriptions for the many undocumented 'attr's

2020-07-13 Thread Lee Jones
... even if they are completely unused.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/pm8001/pm8001_ctl.c:56: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_mpi_interface_rev_show'
 drivers/scsi/pm8001/pm8001_ctl.c:81: warning: Function parameter or member 
'attr' not described in 'controller_fatal_error_show'
 drivers/scsi/pm8001/pm8001_ctl.c:100: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_fw_version_show'
 drivers/scsi/pm8001/pm8001_ctl.c:130: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_ila_version_show'
 drivers/scsi/pm8001/pm8001_ctl.c:155: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_inactive_fw_version_show'
 drivers/scsi/pm8001/pm8001_ctl.c:181: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_max_out_io_show'
 drivers/scsi/pm8001/pm8001_ctl.c:204: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_max_devices_show'
 drivers/scsi/pm8001/pm8001_ctl.c:230: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_max_sg_list_show'
 drivers/scsi/pm8001/pm8001_ctl.c:274: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_sas_spec_support_show'
 drivers/scsi/pm8001/pm8001_ctl.c:303: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_host_sas_address_show'
 drivers/scsi/pm8001/pm8001_ctl.c:322: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_logging_level_show'
 drivers/scsi/pm8001/pm8001_ctl.c:355: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_aap_log_show'
 drivers/scsi/pm8001/pm8001_ctl.c:390: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_ib_queue_log_show'
 drivers/scsi/pm8001/pm8001_ctl.c:423: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_ob_queue_log_show'
 drivers/scsi/pm8001/pm8001_ctl.c:454: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_bios_version_show'
 drivers/scsi/pm8001/pm8001_ctl.c:492: warning: Function parameter or member 
'attr' not described in 'event_log_size_show'
 drivers/scsi/pm8001/pm8001_ctl.c:510: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_iop_log_show'
 drivers/scsi/pm8001/pm8001_ctl.c:548: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_fatal_log_show'
 drivers/scsi/pm8001/pm8001_ctl.c:566: warning: Function parameter or member 
'attr' not described in 'non_fatal_log_show'
 drivers/scsi/pm8001/pm8001_ctl.c:609: warning: Function parameter or member 
'attr' not described in 'pm8001_ctl_gsm_log_show'

Cc: Jack Wang 
Signed-off-by: Lee Jones 
---
 drivers/scsi/pm8001/pm8001_ctl.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/scsi/pm8001/pm8001_ctl.c b/drivers/scsi/pm8001/pm8001_ctl.c
index 3c9f42779dd02..a5f3c702ada9f 100644
--- a/drivers/scsi/pm8001/pm8001_ctl.c
+++ b/drivers/scsi/pm8001/pm8001_ctl.c
@@ -47,6 +47,7 @@
 /**
  * pm8001_ctl_mpi_interface_rev_show - MPI interface revision number
  * @cdev: pointer to embedded class device
+ * @attr: device attribute (unused)
  * @buf: the buffer returned
  *
  * A sysfs 'read-only' shost attribute.
@@ -72,6 +73,7 @@ DEVICE_ATTR(interface_rev, S_IRUGO, 
pm8001_ctl_mpi_interface_rev_show, NULL);
 /**
  * controller_fatal_error_show - check controller is under fatal err
  * @cdev: pointer to embedded class device
+ * @attr: device attribute (unused)
  * @buf: the buffer returned
  *
  * A sysfs 'read only' shost attribute.
@@ -121,6 +123,7 @@ static DEVICE_ATTR(fw_version, S_IRUGO, 
pm8001_ctl_fw_version_show, NULL);
 /**
  * pm8001_ctl_ila_version_show - ila version
  * @cdev: pointer to embedded class device
+ * @attr: device attribute (unused)
  * @buf: the buffer returned
  *
  * A sysfs 'read-only' shost attribute.
@@ -146,6 +149,7 @@ static DEVICE_ATTR(ila_version, 0444, 
pm8001_ctl_ila_version_show, NULL);
 /**
  * pm8001_ctl_inactive_fw_version_show - Inacative firmware version number
  * @cdev: pointer to embedded class device
+ * @attr: device attribute (unused)
  * @buf: the buffer returned
  *
  * A sysfs 'read-only' shost attribute.
@@ -172,6 +176,7 @@ DEVICE_ATTR(inc_fw_ver, 0444, 
pm8001_ctl_inactive_fw_version_show, NULL);
 /**
  * pm8001_ctl_max_out_io_show - max outstanding io supported
  * @cdev: pointer to embedded class device
+ * @attr: device attribute (unused)
  * @buf: the buffer returned
  *
  * A sysfs 'read-only' shost attribute.
@@ -195,6 +200,7 @@ static DEVICE_ATTR(max_out_io, S_IRUGO, 
pm8001_ctl_max_out_io_show, NULL);
 /**
  * pm8001_ctl_max_devices_show - max devices support
  * @cdev: pointer to embedded class device
+ * @attr: device attribute (unused)
  * @buf: the buffer returned
  *
  * A sysfs 'read-only' shost attribute.
@@ -221,6 +227,7 @@ static DEVICE_ATTR(max_devices, S_IRUGO, 
pm8001_ctl_max_devices_show, 

[PATCH v2 21/24] scsi: aic7xxx: aic79xx_osm: Remove unused variable 'ahd'

2020-07-13 Thread Lee Jones
Hasn't been used since 2005.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/aic7xxx/aic79xx_osm.c: In function ‘ahd_linux_slave_configure’:
 drivers/scsi/aic7xxx/aic79xx_osm.c:703:20: warning: variable ‘ahd’ set but not 
used [-Wunused-but-set-variable]

Cc: Hannes Reinecke 
Signed-off-by: Lee Jones 
---
 drivers/scsi/aic7xxx/aic79xx_osm.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/scsi/aic7xxx/aic79xx_osm.c 
b/drivers/scsi/aic7xxx/aic79xx_osm.c
index dc4fe334efd01..9235b6283c0b3 100644
--- a/drivers/scsi/aic7xxx/aic79xx_osm.c
+++ b/drivers/scsi/aic7xxx/aic79xx_osm.c
@@ -700,9 +700,6 @@ ahd_linux_slave_alloc(struct scsi_device *sdev)
 static int
 ahd_linux_slave_configure(struct scsi_device *sdev)
 {
-   struct  ahd_softc *ahd;
-
-   ahd = *((struct ahd_softc **)sdev->host->hostdata);
if (bootverbose)
sdev_printk(KERN_INFO, sdev, "Slave Configure\n");
 
-- 
2.25.1



[PATCH v2 02/24] scsi: aacraid: commctrl: Fix a few kerneldoc issues

2020-07-13 Thread Lee Jones
Functions must follow imediately after the header documenting them and
all parameters must be present.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/aacraid/commctrl.c:43: warning: Excess function parameter 'dev' 
description in 'AAC_DEBUG_PREAMBLE'
 drivers/scsi/aacraid/commctrl.c:43: warning: Excess function parameter 'arg' 
description in 'AAC_DEBUG_PREAMBLE'
 drivers/scsi/aacraid/commctrl.c:167: warning: Function parameter or member 
'dev' not described in 'open_getadapter_fib'
 drivers/scsi/aacraid/commctrl.c:167: warning: Function parameter or member 
'arg' not described in 'open_getadapter_fib'
 drivers/scsi/aacraid/commctrl.c:458: warning: Cannot understand  *
 on line 458 - I thought it was a doc line

Cc: Adaptec OEM Raid Solutions 
Cc: "PMC-Sierra, Inc" 
Signed-off-by: Lee Jones 
---
 drivers/scsi/aacraid/commctrl.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/aacraid/commctrl.c b/drivers/scsi/aacraid/commctrl.c
index 34e65dea992e4..59e82a832042f 100644
--- a/drivers/scsi/aacraid/commctrl.c
+++ b/drivers/scsi/aacraid/commctrl.c
@@ -32,6 +32,8 @@
 
 #include "aacraid.h"
 
+# define AAC_DEBUG_PREAMBLEKERN_INFO
+# define AAC_DEBUG_POSTAMBLE
 /**
  * ioctl_send_fib  -   send a FIB from userspace
  * @dev:   adapter is being processed
@@ -40,9 +42,6 @@
  * This routine sends a fib to the adapter on behalf of a user level
  * program.
  */
-# define AAC_DEBUG_PREAMBLEKERN_INFO
-# define AAC_DEBUG_POSTAMBLE
-
 static int ioctl_send_fib(struct aac_dev * dev, void __user *arg)
 {
struct hw_fib * kfib;
@@ -158,11 +157,12 @@ static int ioctl_send_fib(struct aac_dev * dev, void 
__user *arg)
 
 /**
  * open_getadapter_fib -   Get the next fib
+ * @dev:   adapter is being processed
+ * @arg:   arguments to the open call
  *
  * This routine will get the next Fib, if available, from the 
AdapterFibContext
  * passed in from the user.
  */
-
 static int open_getadapter_fib(struct aac_dev * dev, void __user *arg)
 {
struct aac_fib_context * fibctx;
@@ -234,7 +234,6 @@ static int open_getadapter_fib(struct aac_dev * dev, void 
__user *arg)
  * This routine will get the next Fib, if available, from the 
AdapterFibContext
  * passed in from the user.
  */
-
 static int next_getadapter_fib(struct aac_dev * dev, void __user *arg)
 {
struct fib_ioctl f;
@@ -455,11 +454,10 @@ static int check_revision(struct aac_dev *dev, void 
__user *arg)
 
 
 /**
- *
  * aac_send_raw_scb
- *
+ * @dev:   adapter is being processed
+ * @arg:   arguments to the send call
  */
-
 static int aac_send_raw_srb(struct aac_dev* dev, void __user * arg)
 {
struct fib* srbfib;
-- 
2.25.1



[PATCH] EDAC: i5400_edac: Replace HTTP links with HTTPS ones

2020-07-13 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 drivers/edac/i5400_edac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/edac/i5400_edac.c b/drivers/edac/i5400_edac.c
index f131c05ade9f..92d63eb533ae 100644
--- a/drivers/edac/i5400_edac.c
+++ b/drivers/edac/i5400_edac.c
@@ -8,7 +8,7 @@
  *  Ben Woodard 
  *  Mauro Carvalho Chehab
  *
- * Red Hat Inc. http://www.redhat.com
+ * Red Hat Inc. https://www.redhat.com
  *
  * Forked and adapted from the i5000_edac driver which was
  * written by Douglas Thompson Linux Networx 
@@ -1460,7 +1460,7 @@ module_exit(i5400_exit);
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Ben Woodard ");
 MODULE_AUTHOR("Mauro Carvalho Chehab");
-MODULE_AUTHOR("Red Hat Inc. (http://www.redhat.com)");
+MODULE_AUTHOR("Red Hat Inc. (https://www.redhat.com)");
 MODULE_DESCRIPTION("MC Driver for Intel I5400 memory controllers - "
   I5400_REVISION);
 
-- 
2.27.0



[PATCH v2 12/24] scsi: virtio_scsi: Demote seemingly unintentional kerneldoc header

2020-07-13 Thread Lee Jones
This is the only use of kerneldoc in the sourcefile and no
descriptions are provided.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/virtio_scsi.c:109: warning: Function parameter or member 'vscsi' 
not described in 'virtscsi_complete_cmd'
 drivers/scsi/virtio_scsi.c:109: warning: Function parameter or member 'buf' 
not described in 'virtscsi_complete_cmd'

Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Cc: Stefan Hajnoczi 
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Lee Jones 
Acked-by: Paolo Bonzini 
---
 drivers/scsi/virtio_scsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 0e0910c5b9424..56875467e4984 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -100,7 +100,7 @@ static void virtscsi_compute_resid(struct scsi_cmnd *sc, 
u32 resid)
scsi_set_resid(sc, resid);
 }
 
-/**
+/*
  * virtscsi_complete_cmd - finish a scsi_cmd and invoke scsi_done
  *
  * Called with vq_lock held.
-- 
2.25.1



[PATCH v2 14/24] scsi: ipr: Fix struct packed-not-aligned issues

2020-07-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/scsi/ipr.h:1687:1: warning: alignment 1 of ‘struct 
ipr_dump_location_entry’ is less than 4 [-Wpacked-not-aligned]
 1687 | }__attribute__((packed));
 | ^
 drivers/scsi/ipr.h:1711:1: warning: alignment 1 of ‘struct ipr_driver_dump’ is 
less than 4 [-Wpacked-not-aligned]
 1711 | }__attribute__((packed));
 | ^

Cc: Brian King 
Cc: Alan Cox 
Signed-off-by: Lee Jones 
---
 drivers/scsi/ipr.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ipr.h b/drivers/scsi/ipr.h
index 9a0d3d7293206..783ee03ad9ea2 100644
--- a/drivers/scsi/ipr.h
+++ b/drivers/scsi/ipr.h
@@ -1684,7 +1684,7 @@ struct ipr_dump_entry_header {
 struct ipr_dump_location_entry {
struct ipr_dump_entry_header hdr;
u8 location[20];
-}__attribute__((packed));
+}__attribute__((packed, aligned (4)));
 
 struct ipr_dump_trace_entry {
struct ipr_dump_entry_header hdr;
@@ -1708,7 +1708,7 @@ struct ipr_driver_dump {
struct ipr_dump_location_entry location_entry;
struct ipr_dump_ioa_type_entry ioa_type_entry;
struct ipr_dump_trace_entry trace_entry;
-}__attribute__((packed));
+}__attribute__((packed, aligned (4)));
 
 struct ipr_ioa_dump {
struct ipr_dump_entry_header hdr;
-- 
2.25.1



[PATCH v2 00/24] Set 3: Fix another set of SCSI related W=1 warnings

2020-07-13 Thread Lee Jones
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.

Slowly working through the SCSI related ones.  There are many.

This brings the total of W=1 SCSI wanings from 1690 in v5.8-rc1 to 1109.

Changelog:

v1 => v2
 - Collected *-bys
 - Removed inert function-calls when removing unused variables
   - As suggested by James Bottomley
 
Lee Jones (24):
  scsi: aacraid: aachba: Repair two kerneldoc headers
  scsi: aacraid: commctrl: Fix a few kerneldoc issues
  scsi: aacraid: dpcsup: Fix logical bug when !DBG
  scsi: aacraid: dpcsup: Remove unused variable 'status'
  scsi: aacraid: dpcsup: Demote partially documented function header
  scsi: aic94xx: aic94xx_seq: Document 'lseq' and repair
asd_update_port_links() header
  scsi: aacraid: commsup: Fix a bunch of function header issues
  scsi: aic94xx: aic94xx_scb: Fix a couple of formatting and bitrot
issues
  scsi: aacraid: rx: Fill in the very parameter descriptions for
rx_sync_cmd()
  scsi: pm8001: pm8001_ctl: Provide descriptions for the many
undocumented 'attr's
  scsi: ipr: Fix a mountain of kerneldoc misdemeanours
  scsi: virtio_scsi: Demote seemingly unintentional kerneldoc header
  scsi: ipr: Remove a bunch of set but checked variables
  scsi: ipr: Fix struct packed-not-aligned issues
  scsi: myrs: Demote obvious misuse of kerneldoc to standard comment
blocks
  scsi: megaraid: Fix a whole bunch of function header formatting issues
  scsi: be2iscsi: be_iscsi: Fix API/documentation slip
  scsi: be2iscsi: be_main: Fix misdocumentation of 'pcontext'
  scsi: be2iscsi: be_mgmt: Add missing function parameter description
  scsi: lpfc: lpfc_nvme: Correct some pretty obvious misdocumentation
  scsi: aic7xxx: aic79xx_osm: Remove unused variable 'ahd'
  scsi: aic7xxx: aic79xx_osm: Remove unused variables 'wait' and
'paused'
  scsi: aic7xxx: aic79xx_osm: Fix 'amount_xferred' set but not used
issue
  scsi: aic7xxx: aic79xx_osm: Remove set but unused variabes
'saved_scsiid' and 'saved_modes'

 drivers/scsi/aacraid/aachba.c  |   5 +-
 drivers/scsi/aacraid/commctrl.c|  14 +-
 drivers/scsi/aacraid/commsup.c |  12 +-
 drivers/scsi/aacraid/dpcsup.c  |  15 +-
 drivers/scsi/aacraid/rx.c  |  12 +-
 drivers/scsi/aic7xxx/aic79xx_osm.c |  14 +-
 drivers/scsi/aic94xx/aic94xx_scb.c |   6 +-
 drivers/scsi/aic94xx/aic94xx_seq.c |   6 +-
 drivers/scsi/be2iscsi/be_iscsi.c   |  11 +-
 drivers/scsi/be2iscsi/be_main.c|   4 +-
 drivers/scsi/be2iscsi/be_mgmt.c|   3 +-
 drivers/scsi/ipr.c |  90 +++-
 drivers/scsi/ipr.h |   4 +-
 drivers/scsi/lpfc/lpfc_nvme.c  |  38 +++--
 drivers/scsi/megaraid.c| 218 ++---
 drivers/scsi/myrs.c|  34 ++---
 drivers/scsi/pm8001/pm8001_ctl.c   |  14 ++
 drivers/scsi/virtio_scsi.c |   2 +-
 18 files changed, 273 insertions(+), 229 deletions(-)

-- 
2.25.1



Re: [PATCH] fuse_writepages_fill() optimization to avoid WARN_ON in tree_insert

2020-07-13 Thread Vasily Averin
On 7/11/20 7:01 AM, Miklos Szeredi wrote:
> On Thu, Jun 25, 2020 at 11:02 AM Vasily Averin  wrote:
>>
>> In current implementation fuse_writepages_fill() tries to share the code:
>> for new wpa it calls tree_insert() with num_pages = 0
>> then switches to common code used non-modified num_pages
>> and increments it at the very end.
>>
>> Though it triggers WARN_ON(!wpa->ia.ap.num_pages) in tree_insert()
>>  WARNING: CPU: 1 PID: 17211 at fs/fuse/file.c:1728 tree_insert+0xab/0xc0 
>> [fuse]
>>  RIP: 0010:tree_insert+0xab/0xc0 [fuse]
>>  Call Trace:
>>   fuse_writepages_fill+0x5da/0x6a0 [fuse]
>>   write_cache_pages+0x171/0x470
>>   fuse_writepages+0x8a/0x100 [fuse]
>>   do_writepages+0x43/0xe0
>>
>> This patch re-works fuse_writepages_fill() to call tree_insert()
>> with num_pages = 1 and avoids its subsequent increment and
>> an extra spin_lock(>lock) for newly added wpa.
> 
> Looks good.  However, I don't like the way fuse_writepage_in_flight()
> is silently changed to insert page into the rb_tree.  Also the
> insertion can be merged with the search for in-flight and be done
> unconditionally to simplify the logic.  See attached patch.

Your patch looks correct for me except 2 things:
1) you have lost "data->wpa = NULL;" when fuse_writepage_add() returns false.
2) in the same case old code did not set data->orig_pages[ap->num_pages] = page;

I've lightly updated your patch to fix noticed problems, please see attached 
patch.

Thank you,
Vasily Averin
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index e573b0cd2737..57721570c005 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -1674,7 +1674,8 @@ __acquires(fi->lock)
 	}
 }
 
-static void tree_insert(struct rb_root *root, struct fuse_writepage_args *wpa)
+static struct fuse_writepage_args *fuse_insert_writeback(struct rb_root *root,
+		struct fuse_writepage_args *wpa)
 {
 	pgoff_t idx_from = wpa->ia.write.in.offset >> PAGE_SHIFT;
 	pgoff_t idx_to = idx_from + wpa->ia.ap.num_pages - 1;
@@ -1697,11 +1698,17 @@ static void tree_insert(struct rb_root *root, struct fuse_writepage_args *wpa)
 		else if (idx_to < curr_index)
 			p = &(*p)->rb_left;
 		else
-			return (void) WARN_ON(true);
+			return curr;
 	}
 
 	rb_link_node(>writepages_entry, parent, p);
 	rb_insert_color(>writepages_entry, root);
+	return NULL;
+}
+
+static void tree_insert(struct rb_root *root, struct fuse_writepage_args *wpa)
+{
+	WARN_ON(fuse_insert_writeback(root, wpa));
 }
 
 static void fuse_writepage_end(struct fuse_conn *fc, struct fuse_args *args,
@@ -1952,14 +1959,14 @@ static void fuse_writepages_send(struct fuse_fill_wb_data *data)
 }
 
 /*
- * First recheck under fi->lock if the offending offset is still under
- * writeback.  If yes, then iterate auxiliary write requests, to see if there's
+ * Check under fi->lock if the page is under writeback, and insert it onto the
+ * rb_tree if not. Otherwise iterate auxiliary write requests, to see if there's
  * one already added for a page at this offset.  If there's none, then insert
  * this new request onto the auxiliary list, otherwise reuse the existing one by
- * copying the new page contents over to the old temporary page.
+ * swapping the new temp page with the old one.
  */
-static bool fuse_writepage_in_flight(struct fuse_writepage_args *new_wpa,
- struct page *page)
+static bool fuse_writepage_add(struct fuse_writepage_args *new_wpa,
+			   struct page *page)
 {
 	struct fuse_inode *fi = get_fuse_inode(new_wpa->inode);
 	struct fuse_writepage_args *tmp;
@@ -1967,17 +1974,15 @@ static bool fuse_writepage_in_flight(struct fuse_writepage_args *new_wpa,
 	struct fuse_args_pages *new_ap = _wpa->ia.ap;
 
 	WARN_ON(new_ap->num_pages != 0);
+	new_ap->num_pages = 1;
 
 	spin_lock(>lock);
-	rb_erase(_wpa->writepages_entry, >writepages);
-	old_wpa = fuse_find_writeback(fi, page->index, page->index);
+	old_wpa = fuse_insert_writeback(>writepages, new_wpa);
 	if (!old_wpa) {
-		tree_insert(>writepages, new_wpa);
 		spin_unlock(>lock);
-		return false;
+		return true;
 	}
 
-	new_ap->num_pages = 1;
 	for (tmp = old_wpa->next; tmp; tmp = tmp->next) {
 		pgoff_t curr_index;
 
@@ -2006,7 +2011,7 @@ static bool fuse_writepage_in_flight(struct fuse_writepage_args *new_wpa,
 		fuse_writepage_free(new_wpa);
 	}
 
-	return true;
+	return false;
 }
 
 static int fuse_writepages_fill(struct page *page,
@@ -2085,12 +2090,6 @@ static int fuse_writepages_fill(struct page *page,
 		ap->args.end = fuse_writepage_end;
 		ap->num_pages = 0;
 		wpa->inode = inode;
-
-		spin_lock(>lock);
-		tree_insert(>writepages, wpa);
-		spin_unlock(>lock);
-
-		data->wpa = wpa;
 	}
 	set_page_writeback(page);
 
@@ -2103,20 +2102,22 @@ static int fuse_writepages_fill(struct page *page,
 	inc_node_page_state(tmp_page, NR_WRITEBACK_TEMP);
 
 	err = 0;
-	if (is_writeback && fuse_writepage_in_flight(wpa, page)) {
+	if (data->wpa) {
+		/*
+		 * Protected by fi->lock against concurrent access by
+		 * fuse_page_is_writeback().
+		 */
+		spin_lock(>lock);
+	

Re: [5.8RC4][bugreport]WARNING: CPU: 28 PID: 211236 at fs/fuse/file.c:1684 tree_insert+0xaf/0xc0 [fuse]

2020-07-13 Thread Mikhail Gavrilov
On Mon, 13 Jul 2020 at 12:11, Mikhail Gavrilov
 wrote:
>
> On Mon, 13 Jul 2020 at 03:28, Mikhail Gavrilov
>  wrote:
> >
> > Hi folks.
> > While testing 5.8 RCs I founded that kernel log flooded by the message
> > "WARNING: CPU: 28 PID: 211236 at fs/fuse/file.c:1684 tree
> > insert+0xaf/0xc0 [fuse]" when I start podman container.
> > In kernel 5.7 not has such a problem.
>
> Maxim, I suppose you leave `WARN_ON(!wpa->ia.ap.num_pages);` for debug 
> purpose?
> Now this line is often called when I start the container.
>

That odd, but I can't send an email to the author of the commit.
mpatlasov wasn't found at virtuozzo.com.

--
Best Regards,
Mike Gavrilov.


Re: [Ksummit-discuss] [PATCH v3] CodingStyle: Inclusive Terminology

2020-07-13 Thread Takashi Iwai
On Wed, 08 Jul 2020 20:14:27 +0200,
Dan Williams wrote:
> 
> +Recommended replacements for 'blacklist/whitelist' are:
> +'denylist / allowlist'
> +'blocklist / passlist'

I started looking through the tree now and noticed there are lots of
patterns like "whitelisted" or "blacklisted".  How can the words fit
for those?  Actually, there are two cases like:

- Foo is blacklisted
- Allow to load the non-whitelisted cards

Currently I'm replacing the former with "Foo is in denylist", but not
sure about the latter case.  I thought Kees mentioned about this, but
don't remember the proposal...

In anyway, I'm for the action:
  Acked-by: Takashi Iwai 


thanks,

Takashi


[PATCH] fbdev: sm712fb: handle ioremap() errors in probe

2020-07-13 Thread Evgeny Novikov
smtcfb_pci_probe() does not handle ioremap() errors for case 0x720. The
patch fixes that exactly like for case 0x710/2.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Evgeny Novikov 
---
 drivers/video/fbdev/sm712fb.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c
index 6a1b4a853d9e..0171b23fa211 100644
--- a/drivers/video/fbdev/sm712fb.c
+++ b/drivers/video/fbdev/sm712fb.c
@@ -1602,6 +1602,14 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
sfb->fb->fix.mmio_start = mmio_base;
sfb->fb->fix.mmio_len = 0x0020;
sfb->dp_regs = ioremap(mmio_base, 0x0020 + smem_size);
+   if (!sfb->dp_regs) {
+   dev_err(>dev,
+   "%s: unable to map memory mapped IO!\n",
+   sfb->fb->fix.id);
+   err = -ENOMEM;
+   goto failed_fb;
+   }
+
sfb->lfb = sfb->dp_regs + 0x0020;
sfb->mmio = (smtc_regbaseaddress =
sfb->dp_regs + 0x000c);
-- 
2.16.4



Re: WARNING: suspicious RCU usage in tipc_l2_send_msg

2020-07-13 Thread syzbot
syzbot has found a reproducer for the following crash on:

HEAD commit:4437dd6e Merge tag 'io_uring-5.8-2020-07-12' of git://git...
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17b7869f10
kernel config:  https://syzkaller.appspot.com/x/.config?x=66ad203c2bb6d8b
dashboard link: https://syzkaller.appspot.com/bug?extid=47bbc6b678d317cccbe0
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=10c005af10

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

=
WARNING: suspicious RCU usage
5.8.0-rc4-syzkaller #0 Not tainted
-
net/tipc/bearer.c:466 suspicious rcu_dereference_check() usage!

other info that might help us debug this:


rcu_scheduler_active = 2, debug_locks = 1
2 locks held by kworker/0:1/12:
 #0: 88821adc9538 ((wq_completion)cryptd){+.+.}-{0:0}, at: 
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
 #0: 88821adc9538 ((wq_completion)cryptd){+.+.}-{0:0}, at: atomic64_set 
include/asm-generic/atomic-instrumented.h:856 [inline]
 #0: 88821adc9538 ((wq_completion)cryptd){+.+.}-{0:0}, at: atomic_long_set 
include/asm-generic/atomic-long.h:41 [inline]
 #0: 88821adc9538 ((wq_completion)cryptd){+.+.}-{0:0}, at: set_work_data 
kernel/workqueue.c:616 [inline]
 #0: 88821adc9538 ((wq_completion)cryptd){+.+.}-{0:0}, at: 
set_work_pool_and_clear_pending kernel/workqueue.c:643 [inline]
 #0: 88821adc9538 ((wq_completion)cryptd){+.+.}-{0:0}, at: 
process_one_work+0x82b/0x1670 kernel/workqueue.c:2240
 #1: c9d2fda8 ((work_completion)(_queue->work)){+.+.}-{0:0}, at: 
process_one_work+0x85f/0x1670 kernel/workqueue.c:2244

stack backtrace:
CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.8.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Workqueue: cryptd cryptd_queue_worker
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x18f/0x20d lib/dump_stack.c:118
 tipc_l2_send_msg+0x354/0x420 net/tipc/bearer.c:466
 tipc_aead_encrypt_done+0x204/0x3a0 net/tipc/crypto.c:761
 cryptd_aead_crypt+0xe8/0x1d0 crypto/cryptd.c:739
 cryptd_queue_worker+0x118/0x1b0 crypto/cryptd.c:181
 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
 kthread+0x3b5/0x4a0 kernel/kthread.c:291
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293



Re: [PATCH RFC 2/3] io_uring: add IOURING_REGISTER_RESTRICTIONS opcode

2020-07-13 Thread Stefano Garzarella
On Fri, Jul 10, 2020 at 11:52:48AM -0600, Jens Axboe wrote:
> On 7/10/20 8:19 AM, Stefano Garzarella wrote:
> > The new io_uring_register(2) IOURING_REGISTER_RESTRICTIONS opcode
> > permanently installs a feature whitelist on an io_ring_ctx.
> > The io_ring_ctx can then be passed to untrusted code with the
> > knowledge that only operations present in the whitelist can be
> > executed.
> > 
> > The whitelist approach ensures that new features added to io_uring
> > do not accidentally become available when an existing application
> > is launched on a newer kernel version.
> 
> Keeping with the trend of the times, you should probably use 'allowlist'
> here instead of 'whitelist'.

Sure, it is better!

> > 
> > Currently is it possible to restrict sqe opcodes and register
> > opcodes. It is also possible to allow only fixed files.
> > 
> > IOURING_REGISTER_RESTRICTIONS can only be made once. Afterwards
> > it is not possible to change restrictions anymore.
> > This prevents untrusted code from removing restrictions.
> 
> A few comments below.
> 
> > @@ -337,6 +344,7 @@ struct io_ring_ctx {
> > struct llist_head   file_put_llist;
> >  
> > struct work_struct  exit_work;
> > +   struct io_restriction   restrictions;
> >  };
> >  
> >  /*
> 
> Since very few will use this feature, was going to suggest that we make
> it dynamically allocated. But it's just 32 bytes, currently, so probably
> not worth the effort...
> 

Yeah, I'm not sure it will grow in the future, so I'm tempted to leave it
as it is, but I can easily change it if you prefer.

> > @@ -5491,6 +5499,11 @@ static int io_req_set_file(struct io_submit_state 
> > *state, struct io_kiocb *req,
> > if (unlikely(!fixed && io_async_submit(req->ctx)))
> > return -EBADF;
> >  
> > +   if (unlikely(!fixed && req->ctx->restrictions.enabled &&
> > +test_bit(IORING_RESTRICTION_FIXED_FILES_ONLY,
> > + req->ctx->restrictions.restriction_op)))
> > +   return -EACCES;
> > +
> > return io_file_get(state, req, fd, >file, fixed);
> >  }
> 
> This one hurts, though. I don't want any extra overhead from the
> feature, and you're digging deep in ctx here to figure out of we need to
> check.
> 
> Generally, all the checking needs to be out-of-line, and it needs to
> base the decision on whether to check something or not on a cache hot
> piece of data. So I'd suggest to turn all of these into some flag.
> ctx->flags generally mirrors setup flags, so probably just add a:
> 
>   unsigned int restrictions : 1;
> 
> after eventfd_async : 1 in io_ring_ctx. That's free, plenty of room
> there and that cacheline is already pulled in for reading.
> 

Thanks for the clear explanation!

I left a TODO comment near the 'enabled' field to look for something better,
and what you're suggesting is what I was looking for :-)

I'll change it!

Thanks,
Stefano



RE: [PATCH v3 1/3] xen/privcmd: Corrected error handling path

2020-07-13 Thread Paul Durrant
> -Original Message-
> From: Souptick Joarder 
> Sent: 12 July 2020 04:40
> To: boris.ostrov...@oracle.com; jgr...@suse.com; sstabell...@kernel.org
> Cc: xen-de...@lists.xenproject.org; linux-kernel@vger.kernel.org; Souptick 
> Joarder
> ; John Hubbard ; Paul Durrant 
> 
> Subject: [PATCH v3 1/3] xen/privcmd: Corrected error handling path
> 
> Previously, if lock_pages() end up partially mapping pages, it used
> to return -ERRNO due to which unlock_pages() have to go through
> each pages[i] till *nr_pages* to validate them. This can be avoided
> by passing correct number of partially mapped pages & -ERRNO separately,
> while returning from lock_pages() due to error.
> 
> With this fix unlock_pages() doesn't need to validate pages[i] till
> *nr_pages* for error scenario and few condition checks can be ignored.
> 
> Signed-off-by: Souptick Joarder 
> Reviewed-by: Juergen Gross 
> Cc: John Hubbard 
> Cc: Boris Ostrovsky 
> Cc: Paul Durrant 

Reviewed-by: Paul Durrant 

> ---
>  drivers/xen/privcmd.c | 31 +++
>  1 file changed, 15 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 5dfc59f..b001673 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -579,13 +579,13 @@ static long privcmd_ioctl_mmap_batch(
> 
>  static int lock_pages(
>   struct privcmd_dm_op_buf kbufs[], unsigned int num,
> - struct page *pages[], unsigned int nr_pages)
> + struct page *pages[], unsigned int nr_pages, unsigned int *pinned)
>  {
>   unsigned int i;
> 
>   for (i = 0; i < num; i++) {
>   unsigned int requested;
> - int pinned;
> + int page_count;
> 
>   requested = DIV_ROUND_UP(
>   offset_in_page(kbufs[i].uptr) + kbufs[i].size,
> @@ -593,14 +593,15 @@ static int lock_pages(
>   if (requested > nr_pages)
>   return -ENOSPC;
> 
> - pinned = get_user_pages_fast(
> + page_count = get_user_pages_fast(
>   (unsigned long) kbufs[i].uptr,
>   requested, FOLL_WRITE, pages);
> - if (pinned < 0)
> - return pinned;
> + if (page_count < 0)
> + return page_count;
> 
> - nr_pages -= pinned;
> - pages += pinned;
> + *pinned += page_count;
> + nr_pages -= page_count;
> + pages += page_count;
>   }
> 
>   return 0;
> @@ -610,13 +611,8 @@ static void unlock_pages(struct page *pages[], unsigned 
> int nr_pages)
>  {
>   unsigned int i;
> 
> - if (!pages)
> - return;
> -
> - for (i = 0; i < nr_pages; i++) {
> - if (pages[i])
> - put_page(pages[i]);
> - }
> + for (i = 0; i < nr_pages; i++)
> + put_page(pages[i]);
>  }
> 
>  static long privcmd_ioctl_dm_op(struct file *file, void __user *udata)
> @@ -629,6 +625,7 @@ static long privcmd_ioctl_dm_op(struct file *file, void 
> __user *udata)
>   struct xen_dm_op_buf *xbufs = NULL;
>   unsigned int i;
>   long rc;
> + unsigned int pinned = 0;
> 
>   if (copy_from_user(, udata, sizeof(kdata)))
>   return -EFAULT;
> @@ -682,9 +679,11 @@ static long privcmd_ioctl_dm_op(struct file *file, void 
> __user *udata)
>   goto out;
>   }
> 
> - rc = lock_pages(kbufs, kdata.num, pages, nr_pages);
> - if (rc)
> + rc = lock_pages(kbufs, kdata.num, pages, nr_pages, );
> + if (rc < 0) {
> + nr_pages = pinned;
>   goto out;
> + }
> 
>   for (i = 0; i < kdata.num; i++) {
>   set_xen_guest_handle(xbufs[i].h, kbufs[i].uptr);
> --
> 1.9.1




[PATCH 2/2] scsi: hisi_sas: Remove one kerneldoc comment

2020-07-13 Thread John Garry
The comment for interrupt_init_v2_hw() should not be a kerneldoc comment,
so remove it.

Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 4151b2c04923..ce84f2ba7f68 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -3302,7 +3302,7 @@ static irq_handler_t 
fatal_interrupts[HISI_SAS_FATAL_INT_NR] = {
fatal_axi_int_v2_hw
 };
 
-/**
+/*
  * There is a limitation in the hip06 chipset that we need
  * to map in all mbigen interrupts, even if they are not used.
  */
-- 
2.26.2



[PATCH 1/2] scsi: hisi_sas: Directly trigger SCSI error handling for completion errors

2020-07-13 Thread John Garry
From: Luo Jiaxing 

We used timeout mechanism of SCSI mid-layer to trigger some IO's error
handle, this type of abnormal IO require driver to enter error handle to
clear the residue in the hardware.

But timeout mechanism caught error handle time to be longer, some threads
need to wait for tens of seconds until block layer detect timeout and wake
up SCSI error handle thread. So we try to trigger error handling directly
for some specific IOs to save time.

Signed-off-by: Luo Jiaxing 
Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 4 +++-
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 4 +++-
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 4 +++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
index 2e1718f9ade2..53e1f517efe9 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
@@ -1258,8 +1258,10 @@ static void slot_complete_v1_hw(struct hisi_hba 
*hisi_hba,
!(cmplt_hdr_data & CMPLT_HDR_RSPNS_XFRD_MSK)) {
 
slot_err_v1_hw(hisi_hba, task, slot);
-   if (unlikely(slot->abort))
+   if (unlikely(slot->abort)) {
+   sas_task_abort(task);
return;
+   }
goto out;
}
 
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index e7e7849a4c14..4151b2c04923 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -2404,8 +2404,10 @@ static void slot_complete_v2_hw(struct hisi_hba 
*hisi_hba,
 error_info[0], error_info[1],
 error_info[2], error_info[3]);
 
-   if (unlikely(slot->abort))
+   if (unlikely(slot->abort)) {
+   sas_task_abort(task);
return;
+   }
goto out;
}
 
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index 3e6b78a1f993..d2488d27ff8f 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
@@ -2235,8 +2235,10 @@ static void slot_complete_v3_hw(struct hisi_hba 
*hisi_hba,
 dw0, dw1, complete_hdr->act, dw3,
 error_info[0], error_info[1],
 error_info[2], error_info[3]);
-   if (unlikely(slot->abort))
+   if (unlikely(slot->abort)) {
+   sas_task_abort(task);
return;
+   }
goto out;
}
 
-- 
2.26.2



[PATCH 0/2] hisi_sas: A couple of misc patches

2020-07-13 Thread John Garry
Includes a patch to speed up error handling and a kerneldoc clean-up.

John Garry (1):
  scsi: hisi_sas: Remove one kerneldoc comment

Luo Jiaxing (1):
  scsi: hisi_sas: Directly trigger SCSI error handling for completion
errors

 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 4 +++-
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 6 --
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 4 +++-
 3 files changed, 10 insertions(+), 4 deletions(-)

-- 
2.26.2



RE: [PATCH v3 2/3] xen/privcmd: Mark pages as dirty

2020-07-13 Thread Paul Durrant
> -Original Message-
> From: Souptick Joarder 
> Sent: 12 July 2020 04:40
> To: boris.ostrov...@oracle.com; jgr...@suse.com; sstabell...@kernel.org
> Cc: xen-de...@lists.xenproject.org; linux-kernel@vger.kernel.org; Souptick 
> Joarder
> ; John Hubbard ; Paul Durrant 
> 
> Subject: [PATCH v3 2/3] xen/privcmd: Mark pages as dirty
> 
> pages need to be marked as dirty before unpinned it in
> unlock_pages() which was oversight. This is fixed now.
> 
> Signed-off-by: Souptick Joarder 
> Suggested-by: John Hubbard 
> Reviewed-by: Juergen Gross 
> Cc: John Hubbard 
> Cc: Boris Ostrovsky 
> Cc: Paul Durrant 

Reviewed-by: Paul Durrant 

> ---
>  drivers/xen/privcmd.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index b001673..079d35b 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -611,8 +611,11 @@ static void unlock_pages(struct page *pages[], unsigned 
> int nr_pages)
>  {
>   unsigned int i;
> 
> - for (i = 0; i < nr_pages; i++)
> + for (i = 0; i < nr_pages; i++) {
> + if (!PageDirty(pages[i]))
> + set_page_dirty_lock(pages[i]);
>   put_page(pages[i]);
> + }
>  }
> 
>  static long privcmd_ioctl_dm_op(struct file *file, void __user *udata)
> --
> 1.9.1




RE: [PATCH v3] scsi: ufs: Cleanup completed request without interrupt notification

2020-07-13 Thread Avri Altman
> 
> Hi Bart and Avri,
> 
> On Sun, 2020-07-12 at 18:39 -0700, Bart Van Assche wrote:
> > On 2020-07-06 06:21, Stanley Chu wrote:
> > > If somehow no interrupt notification is raised for a completed request
> > > and its doorbell bit is cleared by host, UFS driver needs to cleanup
> > > its outstanding bit in ufshcd_abort().
> >
> > How is it possible that no interrupt notification is raised for a completed
> > request? Is this the result of a hardware shortcoming or rather the result
> > of how the UFS driver works? In the latter case, is this patch perhaps a
> > workaround? If so, has it been considered to fix the root cause instead of
> > implementing a workaround?
> 
> Actually this fail is triggered by "error injection" to produce a
> command timeout event for checking if anything can be improved or fixed.
> 
> I agree that "no interrupt notification" may be something wrong in
> hardware and the root cause shall be fixed in the highest priority.
> However from this injection, we found ufshcd_abort() indeed has a defect
> flow for a corner case, so we are looking for the solution to fix the
> "hole".
> 
> What would you think if Linux driver shall consider this case? If this
> is not necessary, I would drop this patch : )
Artificially injecting errors is a very common validation mechanism,
Provided that you are not breaking anything of the upper-layers,
Which I don't think you are doing.

Can you refer please to my last comment?

> 
> Thanks a lot,
> Stanley Chu
> 
> >
> > In section 7.2.3 of the UFS specification I found the following about how
> > to process request completions: "Software determines if new TRs have
> > completed since step #2, by repeating one of the two methods described in
> > step #2. If new TRs have completed, software repeats the sequence from
> step
> > #3." Is such a loop perhaps missing from the Linux UFS driver?
Could not find that citation.
What version of the spec are you using?

Thanks,
Avri
> >
> > Thanks,
> >
> > Bart.



RE: [PATCH v3 3/3] xen/privcmd: Convert get_user_pages*() to pin_user_pages*()

2020-07-13 Thread Paul Durrant
> -Original Message-
> From: Souptick Joarder 
> Sent: 12 July 2020 04:40
> To: boris.ostrov...@oracle.com; jgr...@suse.com; sstabell...@kernel.org
> Cc: xen-de...@lists.xenproject.org; linux-kernel@vger.kernel.org; Souptick 
> Joarder
> ; John Hubbard ; Paul Durrant 
> 
> Subject: [PATCH v3 3/3] xen/privcmd: Convert get_user_pages*() to 
> pin_user_pages*()
> 
> In 2019, we introduced pin_user_pages*() and now we are converting
> get_user_pages*() to the new API as appropriate. [1] & [2] could
> be referred for more information. This is case 5 as per document [1].
> 
> [1] Documentation/core-api/pin_user_pages.rst
> 
> [2] "Explicit pinning of user-space pages":
> https://lwn.net/Articles/807108/
> 
> Signed-off-by: Souptick Joarder 
> Reviewed-by: Juergen Gross 
> Cc: John Hubbard 
> Cc: Boris Ostrovsky 
> Cc: Paul Durrant 

Reviewed-by: Paul Durrant 

> ---
>  drivers/xen/privcmd.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 079d35b..63abe6c 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -593,7 +593,7 @@ static int lock_pages(
>   if (requested > nr_pages)
>   return -ENOSPC;
> 
> - page_count = get_user_pages_fast(
> + page_count = pin_user_pages_fast(
>   (unsigned long) kbufs[i].uptr,
>   requested, FOLL_WRITE, pages);
>   if (page_count < 0)
> @@ -609,13 +609,7 @@ static int lock_pages(
> 
>  static void unlock_pages(struct page *pages[], unsigned int nr_pages)
>  {
> - unsigned int i;
> -
> - for (i = 0; i < nr_pages; i++) {
> - if (!PageDirty(pages[i]))
> - set_page_dirty_lock(pages[i]);
> - put_page(pages[i]);
> - }
> + unpin_user_pages_dirty_lock(pages, nr_pages, true);
>  }
> 
>  static long privcmd_ioctl_dm_op(struct file *file, void __user *udata)
> --
> 1.9.1




[PATCH] f2fs: gc: fix the variable used in PTR_ERR()

2020-07-13 Thread Xu Wang
PTR_ERR should access the value just tested by IS_ERR, so fix
the variable used in PTR_ERR().

Signed-off-by: Xu Wang 
---
 drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c 
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 924bc01ef526..d2587e46afe9 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1349,7 +1349,7 @@ static int live_timeslice_nopreempt(void *arg)
 
ce = intel_context_create(engine);
if (IS_ERR(ce)) {
-   err = PTR_ERR(rq);
+   err = PTR_ERR(ce);
goto out_spin;
}
 
-- 
2.17.1



[PATCH] EDAC/ie31200: Replace HTTP links with HTTPS ones

2020-07-13 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 drivers/edac/ie31200_edac.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/edac/ie31200_edac.c b/drivers/edac/ie31200_edac.c
index d68346a8e141..b52175e7c6d2 100644
--- a/drivers/edac/ie31200_edac.c
+++ b/drivers/edac/ie31200_edac.c
@@ -9,7 +9,7 @@
  * Since the DRAM controller is on the cpu chip, we can use its PCI device
  * id to identify these processors.
  *
- * PCI DRAM controller device ids (Taken from The PCI ID Repository - 
http://pci-ids.ucw.cz/)
+ * PCI DRAM controller device ids (Taken from The PCI ID Repository - 
https://pci-ids.ucw.cz/)
  *
  * 0108: Xeon E3-1200 Processor Family DRAM Controller
  * 010c: Xeon E3-1200/2nd Generation Core Processor Family DRAM Controller
@@ -23,9 +23,9 @@
  * 3e..: 8th/9th Gen Core Processor Host Bridge/DRAM Registers
  *
  * Based on Intel specification:
- * 
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e3-1200v3-vol-2-datasheet.pdf
+ * 
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e3-1200v3-vol-2-datasheet.pdf
  * 
http://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200-family-vol-2-datasheet.html
- * 
http://www.intel.com/content/www/us/en/processors/core/7th-gen-core-family-mobile-h-processor-lines-datasheet-vol-2.html
+ * 
https://www.intel.com/content/www/us/en/processors/core/7th-gen-core-family-mobile-h-processor-lines-datasheet-vol-2.html
  * 
https://www.intel.com/content/www/us/en/products/docs/processors/core/8th-gen-core-family-datasheet-vol-2.html
  *
  * According to the above datasheet (p.16):
-- 
2.27.0



[PATCH] v4l2-ctrl: Add VP9 codec levels

2020-07-13 Thread Stanimir Varbanov
Add menu control for VP9 codec levels. A total of 14 levels are
defined for Profile 0 (8bit) and Profile 2 (10bit). Each level
is a set of constrained bitstreams coded with targeted resolutions,
frame rates, and bitrates.

The definition has been taken from webm project.

Signed-off-by: Stanimir Varbanov 
---
 .../media/v4l/ext-ctrls-codec.rst | 42 +++
 drivers/media/v4l2-core/v4l2-ctrls.c  | 21 ++
 include/uapi/linux/v4l2-controls.h| 17 
 3 files changed, 80 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst 
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index d0d506a444b1..d49bdafa768a 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -3316,6 +3316,48 @@ enum v4l2_mpeg_video_vp9_profile -
 * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_3``
   - Profile 3
 
+.. _v4l2-mpeg-video-vp9-level:
+
+``V4L2_CID_MPEG_VIDEO_VP9_LEVEL (enum)``
+
+enum v4l2_mpeg_video_vp9_level -
+This control allows selecting the level for VP9 encoder.
+This is also used to enumerate supported levels by VP9 encoder or decoder.
+Possible values are:
+
+.. flat-table::
+:header-rows:  0
+:stub-columns: 0
+
+* - ``V4L2_MPEG_VIDEO_VP9_LEVEL_1_0``
+  - Level 1
+* - ``V4L2_MPEG_VIDEO_VP9_LEVEL_1_1``
+  - Level 1.1
+* - ``V4L2_MPEG_VIDEO_VP9_LEVEL_2_0``
+  - Level 2
+* - ``V4L2_MPEG_VIDEO_VP9_LEVEL_2_1``
+  - Level 2.1
+* - ``V4L2_MPEG_VIDEO_VP9_LEVEL_3_0``
+  - Level 3
+* - ``V4L2_MPEG_VIDEO_VP9_LEVEL_3_1``
+  - Level 3.1
+* - ``V4L2_MPEG_VIDEO_VP9_LEVEL_4_0``
+  - Level 4
+* - ``V4L2_MPEG_VIDEO_VP9_LEVEL_4_1``
+  - Level 4.1
+* - ``V4L2_MPEG_VIDEO_VP9_LEVEL_5_0``
+  - Level 5
+* - ``V4L2_MPEG_VIDEO_VP9_LEVEL_5_1``
+  - Level 5.1
+* - ``V4L2_MPEG_VIDEO_VP9_LEVEL_5_2``
+  - Level 5.2
+* - ``V4L2_MPEG_VIDEO_VP9_LEVEL_6_0``
+  - Level 6
+* - ``V4L2_MPEG_VIDEO_VP9_LEVEL_6_1``
+  - Level 6.1
+* - ``V4L2_MPEG_VIDEO_VP9_LEVEL_6_2``
+  - Level 6.2
+
 
 High Efficiency Video Coding (HEVC/H.265) Control Reference
 ===
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 3f3fbcd60cc6..359dc737053d 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -474,6 +474,23 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"3",
NULL,
};
+   static const char * const vp9_level[] = {
+   "1",
+   "1.1",
+   "2",
+   "2.1",
+   "3",
+   "3.1",
+   "4",
+   "4.1",
+   "5",
+   "5.1",
+   "5.2",
+   "6",
+   "6.1",
+   "6.2",
+   NULL,
+   };
 
static const char * const flash_led_mode[] = {
"Off",
@@ -685,6 +702,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return vp8_profile;
case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
return vp9_profile;
+   case V4L2_CID_MPEG_VIDEO_VP9_LEVEL:
+   return vp9_level;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
case V4L2_CID_DV_TX_MODE:
@@ -938,6 +957,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:return "VPX 
P-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:   return "VP8 
Profile";
case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:   return "VP9 
Profile";
+   case V4L2_CID_MPEG_VIDEO_VP9_LEVEL: return "VP9 
Level";
case V4L2_CID_MPEG_VIDEO_VP8_FRAME_HEADER:  return "VP8 
Frame Header";
 
/* HEVC controls */
@@ -1294,6 +1314,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
+   case V4L2_CID_MPEG_VIDEO_VP9_LEVEL:
case V4L2_CID_DETECT_MD_MODE:
case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 62271418c1be..1b0bc79c1bc3 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -650,6 +650,23 @@ enum v4l2_mpeg_video_vp9_profile {
V4L2_MPEG_VIDEO_VP9_PROFILE_2   = 2,
V4L2_MPEG_VIDEO_VP9_PROFILE_3   = 3,
 };
+#define V4L2_CID_MPEG_VIDEO_VP9_LEVEL  (V4L2_CID_MPEG_BASE+513)
+enum v4l2_mpeg_video_vp9_level {
+   

Re: [PATCH v10 04/15] perf evlist: introduce control file descriptors

2020-07-13 Thread Alexey Budankov


On 13.07.2020 6:13, Namhyung Kim wrote:
> Hello,
> 
> On Wed, Jul 8, 2020 at 4:47 PM Alexey Budankov
>  wrote:
>>
>>
>> Define and initialize control file descriptors.
>>
>> Signed-off-by: Alexey Budankov 
>> ---
>>  tools/perf/util/evlist.c | 3 +++
>>  tools/perf/util/evlist.h | 5 +
>>  2 files changed, 8 insertions(+)
>>
>> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
>> index bcbe0cb8482e..36eb50aba1f5 100644
>> --- a/tools/perf/util/evlist.c
>> +++ b/tools/perf/util/evlist.c
>> @@ -63,6 +63,9 @@ void evlist__init(struct evlist *evlist, struct 
>> perf_cpu_map *cpus,
>> perf_evlist__set_maps(>core, cpus, threads);
>> evlist->workload.pid = -1;
>> evlist->bkw_mmap_state = BKW_MMAP_NOTREADY;
>> +   evlist->ctl_fd.fd = -1;
>> +   evlist->ctl_fd.ack = -1;
>> +   evlist->ctl_fd.pos = -1;
>>  }
>>
>>  struct evlist *evlist__new(void)
>> diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
>> index 38901c0d1599..2caf19fb87a8 100644
>> --- a/tools/perf/util/evlist.h
>> +++ b/tools/perf/util/evlist.h
>> @@ -74,6 +74,11 @@ struct evlist {
>> pthread_t   th;
>> volatile intdone;
>> } thread;
>> +   struct {
>> +   int fd;
>> +   int ack;
>> +   int pos;
>> +   } ctl_fd;
> 
> Could you please add brief descriptions for each field
> in the comment?  It's not obvious to me other than fd.

Ok. In v11.

Alexei


RE: [PATCH v3] scsi: ufs-mediatek: Add inline encryption support

2020-07-13 Thread Avri Altman
 
> 
> Add inline encryption support to ufs-mediatek.
> 
> The standards-compliant parts, such as querying the crypto capabilities
> and enabling crypto for individual UFS requests, are already handled by
> ufshcd-crypto.c, which itself is wired into the blk-crypto framework.
> 
> However MediaTek UFS host requires a vendor-specific hce_enable operation
> to allow crypto-related registers being accessed normally in kernel.
> After this step, MediaTek UFS host can work as standard-compliant host
> for inline-encryption related functions.
> 
> Signed-off-by: Stanley Chu 
Reviewed-by: Avri Altman 

> ---
>  drivers/scsi/ufs/ufs-mediatek.c | 22 ++
>  drivers/scsi/ufs/ufs-mediatek.h |  1 +
>  2 files changed, 23 insertions(+)
> 
> diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
> index ad929235c193..31af8b3d2b53 100644
> --- a/drivers/scsi/ufs/ufs-mediatek.c
> +++ b/drivers/scsi/ufs/ufs-mediatek.c
> @@ -16,6 +16,7 @@
>  #include 
> 
>  #include "ufshcd.h"
> +#include "ufshcd-crypto.h"
>  #include "ufshcd-pltfrm.h"
>  #include "ufs_quirks.h"
>  #include "unipro.h"
> @@ -25,6 +26,9 @@
> arm_smccc_smc(MTK_SIP_UFS_CONTROL, \
>   cmd, val, 0, 0, 0, 0, 0, &(res))
> 
> +#define ufs_mtk_crypto_ctrl(res, enable) \
> +   ufs_mtk_smc(UFS_MTK_SIP_CRYPTO_CTRL, enable, res)
> +
>  #define ufs_mtk_ref_clk_notify(on, res) \
> ufs_mtk_smc(UFS_MTK_SIP_REF_CLK_NOTIFICATION, on, res)
> 
> @@ -73,6 +77,18 @@ static void ufs_mtk_cfg_unipro_cg(struct ufs_hba *hba,
> bool enable)
> }
>  }
> 
> +static void ufs_mtk_crypto_enable(struct ufs_hba *hba)
> +{
> +   struct arm_smccc_res res;
> +
> +   ufs_mtk_crypto_ctrl(res, 1);
> +   if (res.a0) {
> +   dev_info(hba->dev, "%s: crypto enable failed, err: %lu\n",
> +__func__, res.a0);
> +   hba->caps &= ~UFSHCD_CAP_CRYPTO;
> +   }
> +}
> +
>  static int ufs_mtk_hce_enable_notify(struct ufs_hba *hba,
>  enum ufs_notify_change_status status)
>  {
> @@ -83,6 +99,9 @@ static int ufs_mtk_hce_enable_notify(struct ufs_hba
> *hba,
> hba->vps->hba_enable_delay_us = 0;
> else
> hba->vps->hba_enable_delay_us = 600;
> +
> +   if (hba->caps & UFSHCD_CAP_CRYPTO)
> +   ufs_mtk_crypto_enable(hba);
> }
> 
> return 0;
> @@ -317,6 +336,9 @@ static int ufs_mtk_init(struct ufs_hba *hba)
> /* Enable clock-gating */
> hba->caps |= UFSHCD_CAP_CLK_GATING;
> 
> +   /* Enable inline encryption */
> +   hba->caps |= UFSHCD_CAP_CRYPTO;
> +
> /* Enable WriteBooster */
> hba->caps |= UFSHCD_CAP_WB_EN;
> hba->vps->wb_flush_threshold = UFS_WB_BUF_REMAIN_PERCENT(80);
> diff --git a/drivers/scsi/ufs/ufs-mediatek.h b/drivers/scsi/ufs/ufs-mediatek.h
> index 6052ec105aba..8ed24d5fcff9 100644
> --- a/drivers/scsi/ufs/ufs-mediatek.h
> +++ b/drivers/scsi/ufs/ufs-mediatek.h
> @@ -70,6 +70,7 @@ enum {
>   */
>  #define MTK_SIP_UFS_CONTROL   MTK_SIP_SMC_CMD(0x276)
>  #define UFS_MTK_SIP_DEVICE_RESET  BIT(1)
> +#define UFS_MTK_SIP_CRYPTO_CTRL   BIT(2)
>  #define UFS_MTK_SIP_REF_CLK_NOTIFICATION  BIT(3)
> 
>  /*
> --
> 2.18.0


Re: [PATCH v3] arm64: dts: zii-ultra: update MDIO speed and preamble

2020-07-13 Thread Shawn Guo
On Tue, Jul 07, 2020 at 06:00:05PM -0700, Chris Healy wrote:
> Update MDIO configuration with zii-ultra device to fully utilize
> MDIO endpoint capabilities.  Device supports 12.5MHz clock and
> doesn't require MDIO preamble.
> 
> Signed-off-by: Chris Healy 

Applied, thanks.


Re: [PATCH v2 10/24] scsi: pm8001: pm8001_ctl: Provide descriptions for the many undocumented 'attr's

2020-07-13 Thread Jinpu Wang
On Mon, Jul 13, 2020 at 10:00 AM Lee Jones  wrote:
>
> ... even if they are completely unused.
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/scsi/pm8001/pm8001_ctl.c:56: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_mpi_interface_rev_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:81: warning: Function parameter or member 
> 'attr' not described in 'controller_fatal_error_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:100: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_fw_version_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:130: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_ila_version_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:155: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_inactive_fw_version_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:181: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_max_out_io_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:204: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_max_devices_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:230: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_max_sg_list_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:274: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_sas_spec_support_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:303: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_host_sas_address_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:322: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_logging_level_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:355: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_aap_log_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:390: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_ib_queue_log_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:423: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_ob_queue_log_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:454: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_bios_version_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:492: warning: Function parameter or member 
> 'attr' not described in 'event_log_size_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:510: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_iop_log_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:548: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_fatal_log_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:566: warning: Function parameter or member 
> 'attr' not described in 'non_fatal_log_show'
>  drivers/scsi/pm8001/pm8001_ctl.c:609: warning: Function parameter or member 
> 'attr' not described in 'pm8001_ctl_gsm_log_show'
>
> Cc: Jack Wang 
> Signed-off-by: Lee Jones 
good to have kernel doc warning clean.
Thanks!
Acked-by: Jack Wang 


[PATCH v2 0/2] PM / devfreq: Add governor flags

2020-07-13 Thread Chanwoo Choi
Devfreq provides the multiple governors and sysfs interface for user.
But, some sysfs attributes are useful or not useful. Prior to that
the user can access all sysfs attributes regardless of availability.

So, clarify the access permission of sysfs attributes according to governor.
Provide the governor flag to specify what is necessary or not.
When adding the devfreq governor, governor can specify the available
attributes with DEVFREQ_GOV_ATTR_ATTR_* defintion as following.

[Definition for sysfs attributes]
- DEVFREQ_GOV_ATTR_GOVERNOR
- DEVFREQ_GOV_ATTR_AVAIL_GOVERNORS
- DEVFREQ_GOV_ATTR_AVAIL_FREQUENCIES
- DEVFREQ_GOV_ATTR_CUR_FREQ
- DEVFREQ_GOV_ATTR_TARGET_FREQ
- DEVFREQ_GOV_ATTR_MIN_FREQ
- DEVFREQ_GOV_ATTR_MAX_FREQ
- DEVFREQ_GOV_ATTR_TRANS_STAT
- DEVFREQ_GOV_ATTR_POLLING_INTERVAL
- DEVFREQ_GOV_ATTR_TIMER

Also, the devfreq governor is able to have the specific flag as follows
in order to implement the specific feature with DEVFREQ_GOV_FLA_*.
For exmaple, the devfreq deivce using passive governor cannot change
their own governor because passive governor requires the 'immutable'
feature with DEVFREQ_GOV_FLAG_IMMUTABLE.

[Definition for governor flag]
- DEVFREQ_GOV_FLAG_IMMUTABLE
: If immutable flag is set, governor is never changeable to other governors.
- DEVFREQ_GOV_FLAG_IRQ_DRIVEN
: Devfreq core won't schedule polling work for this governor if value is set.


Changes from v1:
- Rebase it on latest devfreq-next branch
- Fix typo issue of tegra30-devfreq.c and test it with COMPILE_TEST

Chanwoo Choi (2):
  PM / devfreq: Clean up the devfreq instance name in sysfs attr
  PM / devfreq: Add governor flags to clarify the features

 drivers/devfreq/devfreq.c | 186 +-
 drivers/devfreq/governor.h|  44 -
 drivers/devfreq/governor_passive.c|   3 +-
 drivers/devfreq/governor_performance.c|   1 +
 drivers/devfreq/governor_powersave.c  |   1 +
 drivers/devfreq/governor_simpleondemand.c |   3 +
 drivers/devfreq/governor_userspace.c  |   1 +
 drivers/devfreq/tegra30-devfreq.c |   6 +-
 8 files changed, 192 insertions(+), 53 deletions(-)

-- 
2.17.1



[PATCH v2 2/2] PM / devfreq: Add governor flags to clarify the features

2020-07-13 Thread Chanwoo Choi
DEVFREQ supports the default governors like performance, powersave and also
allows the devfreq driver to add their own governor like tegra30-devfreq.c
according to their requirement. In result, some sysfs attributes are
useful or not useful. Prior to that the user can access all sysfs attributes
regardless of availability.

So, clarify the access permission of sysfs attributes according to governor.
When adding the devfreq governor, can specify the available attribute
information by using DEVFREQ_GOV_ATTR_* constant variable. The user can
read or write the sysfs attributes in accordance to the specified attributes.

/* Devfreq governor flags for attributes and features */
[Definition for sysfs attributes]
- DEVFREQ_GOV_ATTR_GOVERNOR
- DEVFREQ_GOV_ATTR_AVAIL_GOVERNORS
- DEVFREQ_GOV_ATTR_AVAIL_FREQUENCIES
- DEVFREQ_GOV_ATTR_CUR_FREQ
- DEVFREQ_GOV_ATTR_TARGET_FREQ
- DEVFREQ_GOV_ATTR_MIN_FREQ
- DEVFREQ_GOV_ATTR_MAX_FREQ
- DEVFREQ_GOV_ATTR_TRANS_STAT
- DEVFREQ_GOV_ATTR_POLLING_INTERVAL
- DEVFREQ_GOV_ATTR_TIMER

Also, the devfreq governor is able to have the specific flag as follows
in order to implement the specific feature. For example, Devfreq allows
user to change the governors on runtime via sysfs interface.
But, if devfreq device uses 'passive' governor, don't allow user to change
the governor. For this case, define the DEVFREQ_GOV_FLAT_IMMUTABLE
and set it to flag of passive governor.

[Definition for governor flag]
- DEVFREQ_GOV_FLAG_IMMUTABLE
: If immutable flag is set, governor is never changeable to other governors.
- DEVFREQ_GOV_FLAG_IRQ_DRIVEN
: Devfreq core won't schedule polling work for this governor if value is set.

[Table of governor flag for devfreq governors]
--
  | simple| perfor | power | user | passive | tegra30
  | ondemand  | mance  | save  | space| |
--
governor  | O | O  | O | O| O   | O
available_governors   | O | O  | O | O| O   | O
available_frequencies | O | O  | O | O| O   | O
cur_freq  | O | O  | O | O| O   | O
target_freq   | O | O  | O | O| O   | O
min_freq  | O | O  | O | O| O   | O
max_freq  | O | O  | O | O| O   | O
trans_stat| O | O  | O | O| O   | O
  
polling_interval  | O | X  | X | X| X   | O
timer | O | X  | X | X| X   | X
--
immutable | X | X  | X | X| O   | O
interrupt_driven  | X(polling)| X  | X | X| X   | O (irq)
--

Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/devfreq.c | 106 ++
 drivers/devfreq/governor.h|  44 +++--
 drivers/devfreq/governor_passive.c|   3 +-
 drivers/devfreq/governor_performance.c|   1 +
 drivers/devfreq/governor_powersave.c  |   1 +
 drivers/devfreq/governor_simpleondemand.c |   3 +
 drivers/devfreq/governor_userspace.c  |   1 +
 drivers/devfreq/tegra30-devfreq.c |   6 +-
 8 files changed, 139 insertions(+), 26 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 286957f760f1..ce82bdb5fa5c 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -456,7 +456,7 @@ static void devfreq_monitor(struct work_struct *work)
  */
 void devfreq_monitor_start(struct devfreq *devfreq)
 {
-   if (devfreq->governor->interrupt_driven)
+   if (DEVFREQ_GOV_FLAG_IRQ_DRIVEN & devfreq->governor->flag)
return;
 
switch (devfreq->profile->timer) {
@@ -486,7 +486,7 @@ EXPORT_SYMBOL(devfreq_monitor_start);
  */
 void devfreq_monitor_stop(struct devfreq *devfreq)
 {
-   if (devfreq->governor->interrupt_driven)
+   if (DEVFREQ_GOV_FLAG_IRQ_DRIVEN & devfreq->governor->flag)
return;
 
cancel_delayed_work_sync(>work);
@@ -517,7 +517,7 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
devfreq->stop_polling = true;
mutex_unlock(>lock);
 
-   if (devfreq->governor->interrupt_driven)
+   if (DEVFREQ_GOV_FLAG_IRQ_DRIVEN & devfreq->governor->flag)
return;
 
cancel_delayed_work_sync(>work);
@@ -537,12 +537,13 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
unsigned long freq;
 
mutex_lock(>lock);
-   if (!devfreq->stop_polling)
-   goto out;
 
-   if 

[PATCH v2 1/2] PM / devfreq: Clean up the devfreq instance name in sysfs attr

2020-07-13 Thread Chanwoo Choi
The sysfs attr interface used eithere 'df' or 'devfreq' for devfreq instance
name. In order to keep the consistency and to improve the readabilty,
unify the instance name as 'df'. Add add the missing conditional statement
to prevent the fault.

Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/devfreq.c | 94 +--
 1 file changed, 60 insertions(+), 34 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 5320c3b37f35..286957f760f1 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -1280,18 +1280,20 @@ EXPORT_SYMBOL(devfreq_remove_governor);
 static ssize_t name_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
-   struct devfreq *devfreq = to_devfreq(dev);
-   return sprintf(buf, "%s\n", dev_name(devfreq->dev.parent));
+   struct devfreq *df = to_devfreq(dev);
+   return sprintf(buf, "%s\n", dev_name(df->dev.parent));
 }
 static DEVICE_ATTR_RO(name);
 
 static ssize_t governor_show(struct device *dev,
 struct device_attribute *attr, char *buf)
 {
-   if (!to_devfreq(dev)->governor)
+   struct devfreq *df = to_devfreq(dev);
+
+   if (!df->governor)
return -EINVAL;
 
-   return sprintf(buf, "%s\n", to_devfreq(dev)->governor->name);
+   return sprintf(buf, "%s\n", df->governor->name);
 }
 
 static ssize_t governor_store(struct device *dev, struct device_attribute 
*attr,
@@ -1302,6 +1304,9 @@ static ssize_t governor_store(struct device *dev, struct 
device_attribute *attr,
char str_governor[DEVFREQ_NAME_LEN + 1];
const struct devfreq_governor *governor, *prev_governor;
 
+   if (!df->governor)
+   return -EINVAL;
+
ret = sscanf(buf, "%" __stringify(DEVFREQ_NAME_LEN) "s", str_governor);
if (ret != 1)
return -EINVAL;
@@ -1315,20 +1320,18 @@ static ssize_t governor_store(struct device *dev, 
struct device_attribute *attr,
if (df->governor == governor) {
ret = 0;
goto out;
-   } else if ((df->governor && df->governor->immutable) ||
-   governor->immutable) {
+   } else if (df->governor->immutable || governor->immutable) {
ret = -EINVAL;
goto out;
}
 
-   if (df->governor) {
-   ret = df->governor->event_handler(df, DEVFREQ_GOV_STOP, NULL);
-   if (ret) {
-   dev_warn(dev, "%s: Governor %s not stopped(%d)\n",
-__func__, df->governor->name, ret);
-   goto out;
-   }
+   ret = df->governor->event_handler(df, DEVFREQ_GOV_STOP, NULL);
+   if (ret) {
+   dev_warn(dev, "%s: Governor %s not stopped(%d)\n",
+__func__, df->governor->name, ret);
+   goto out;
}
+
prev_governor = df->governor;
df->governor = governor;
strncpy(df->governor_name, governor->name, DEVFREQ_NAME_LEN);
@@ -1363,13 +1366,16 @@ static ssize_t available_governors_show(struct device 
*d,
struct devfreq *df = to_devfreq(d);
ssize_t count = 0;
 
+   if (!df->governor)
+   return -EINVAL;
+
mutex_lock(_list_lock);
 
/*
 * The devfreq with immutable governor (e.g., passive) shows
 * only own governor.
 */
-   if (df->governor && df->governor->immutable) {
+   if (df->governor->immutable) {
count = scnprintf([count], DEVFREQ_NAME_LEN,
  "%s ", df->governor_name);
/*
@@ -1403,27 +1409,37 @@ static ssize_t cur_freq_show(struct device *dev, struct 
device_attribute *attr,
 char *buf)
 {
unsigned long freq;
-   struct devfreq *devfreq = to_devfreq(dev);
+   struct devfreq *df = to_devfreq(dev);
 
-   if (devfreq->profile->get_cur_freq &&
-   !devfreq->profile->get_cur_freq(devfreq->dev.parent, ))
+   if (!df->profile)
+   return -EINVAL;
+
+   if (df->profile->get_cur_freq &&
+   !df->profile->get_cur_freq(df->dev.parent, ))
return sprintf(buf, "%lu\n", freq);
 
-   return sprintf(buf, "%lu\n", devfreq->previous_freq);
+   return sprintf(buf, "%lu\n", df->previous_freq);
 }
 static DEVICE_ATTR_RO(cur_freq);
 
 static ssize_t target_freq_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
-   return sprintf(buf, "%lu\n", to_devfreq(dev)->previous_freq);
+   struct devfreq *df = to_devfreq(dev);
+
+   return sprintf(buf, "%lu\n", df->previous_freq);
 }
 static DEVICE_ATTR_RO(target_freq);
 
 static ssize_t polling_interval_show(struct device *dev,
 struct device_attribute *attr, char *buf)
 {
-   return sprintf(buf, "%d\n", 

Re: [PATCH 1/3] dt-bindings: usb: ci-hdrc-usb2: add property disable-runtime-pm

2020-07-13 Thread Philippe Schenker
On Fri, 2020-07-10 at 12:56 -0300, Fabio Estevam wrote:
> Hi Philippe,
> 
> On Fri, Jul 10, 2020 at 12:51 PM Philippe Schenker
>  wrote:
> > Chipidea depends on some hardware signals to be there in order
> 
> I think this description is too vague.
> 
> Could you please provide more details so that a user can know if their
> hardware falls into this category?
> 
> It is not clear from seeing this series what is the hardware details
> that would require this property to be used.

Hi Fabio, Peter,

I tried to keep the description for this patch somewhat general. But as
Peter suggested I will add Toradex's use-case for this.

The problem with Colibri iMX6ULL is that we are stuck with a legacy
module standard that does only include one USB host/device switching
signal. Plus on that specific module we have no 5V available hence left
the connection of VBUS signal away.
This works normally pretty well but for our "dual-role OTG" port I could
not make it work with runtime-pm running and proper extcon
configuration. The problem was, when plugging in something in device or
host mode gets not enumerated and detected.

That are the reasons why I believe the PHY or something else in Chipidea
needs a signal that it does not have on that module that would wake the
whole thing from runtime-suspend.

I will think about a better description and send a v2

Thanks
Philippe


linux-next: manual merge of the akpm-current tree with the net-next tree

2020-07-13 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/cma.h

between commit:

  a2b992c828f7 ("debugfs: make sure we can remove u32_array files cleanly")

from the net-next tree and commit:

  bc7212aceef6 ("mm: cma: fix the name of CMA areas")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/cma.h
index 6698fa63279b,27d3f0e9f68f..
--- a/mm/cma.h
+++ b/mm/cma.h
@@@ -2,8 -2,8 +2,10 @@@
  #ifndef __MM_CMA_H__
  #define __MM_CMA_H__
  
 +#include 
 +
+ #define CMA_MAX_NAME 64
+ 
  struct cma {
unsigned long   base_pfn;
unsigned long   count;
@@@ -13,9 -13,8 +15,9 @@@
  #ifdef CONFIG_CMA_DEBUGFS
struct hlist_head mem_head;
spinlock_t mem_head_lock;
 +  struct debugfs_u32_array dfs_bitmap;
  #endif
-   const char *name;
+   char name[CMA_MAX_NAME];
  };
  
  extern struct cma cma_areas[MAX_CMA_AREAS];


pgpS9IctLvIY2.pgp
Description: OpenPGP digital signature


Re: [PATCH v3] arm: dts: ZII: update MDIO speed and preamble

2020-07-13 Thread Shawn Guo
On Tue, Jul 07, 2020 at 06:16:27PM -0700, Chris Healy wrote:
> Update MDIO configuration with ZII devices to fully utilize
> MDIO endpoint capabilities.  All devices support 12.5MHz clock and
> don't require MDIO preable.
> 
> Signed-off-by: Chris Healy 
> Reviewed-by: Fabio Estevam 

We use prefix 'ARM: ...' for arm dts.  Fixed it up and applied the
patch.

Shawn


[PATCH] HID: mcp2221: Replace HTTP links with HTTPS ones

2020-07-13 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 drivers/hid/hid-mcp2221.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index e1b93ce32e01..0d27ccb55dd9 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -4,7 +4,7 @@
  *
  * Copyright (c) 2020, Rishi Gupta 
  *
- * Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20005565B.pdf
+ * Datasheet: https://ww1.microchip.com/downloads/en/DeviceDoc/20005565B.pdf
  */
 
 #include 
-- 
2.27.0



Re: [PATCH v2] ARM: dts: vf610-zii-dev-rev-c: Configure fiber port to 1000BaseX

2020-07-13 Thread Shawn Guo
On Wed, Jul 08, 2020 at 04:25:01PM -0700, Chris Healy wrote:
> The SFF soldered onto the board expects the port to use 1000BaseX.  It
> makes no sense to have the port set to SGMII, since it doesn't even
> support that mode.
> 
> Signed-off-by: Chris Healy 

Applied, thanks.


Re: [PATCH v10 05/15] perf evlist: implement control command handling functions

2020-07-13 Thread Alexey Budankov


On 13.07.2020 6:20, Namhyung Kim wrote:
> On Wed, Jul 8, 2020 at 4:50 PM Alexey Budankov
>  wrote:
>>
>>
>> Implement functions of initialization, finalization and processing
>> of control command messages coming from control file descriptors.
>> Allocate control file descriptor as descriptor at struct pollfd
>> object of evsel_list for atomic poll() operation.
>>
>> Signed-off-by: Alexey Budankov 
>> ---
> [SNIP]
>> +static int evlist__ctlfd_recv(struct evlist *evlist, enum evlist_ctl_cmd 
>> *cmd,
>> + char *cmd_data, size_t data_size)
>> +{
>> +   int err;
>> +   char c;
>> +   size_t bytes_read = 0;
>> +
>> +   memset(cmd_data, 0, data_size--);
> 
> I overlooked the '--' at the end and thought there might be
> buffer overflow..  Care to add a comment?

If it wants to be more explicit then it could possibly be implemented
like this:

memset(cmd_data, 0, data_size);
data_size--;

> 
>> +
>> +   do {
>> +   err = read(evlist->ctl_fd.fd, , 1);
> 
> Maybe I missed earlier discussion, but do we really want
> this 1 byte read in a loop?

That was the explicit request to support commands of variable
length so it implements it like that.

Alexei

> 
> Thanks
> Namhyung
> 
> 
>> +   if (err > 0) {
>> +   if (c == '\n' || c == '\0')
>> +   break;
>> +   cmd_data[bytes_read++] = c;
>> +   if (bytes_read == data_size)
>> +   break;
>> +   } else {
>> +   if (err == -1)
>> +   pr_err("Failed to read from ctlfd %d: %m\n", 
>> evlist->ctl_fd.fd);
>> +   break;
>> +   }
>> +   } while (1);
>> +
>> +   pr_debug("Message from ctl_fd: \"%s%s\"\n", cmd_data,
>> +bytes_read == data_size ? "" : c == '\n' ? "\\n" : "\\0");
>> +
>> +   if (err > 0) {
>> +   if (!strncmp(cmd_data, EVLIST_CTL_CMD_ENABLE_TAG,
>> +(sizeof(EVLIST_CTL_CMD_ENABLE_TAG)-1))) {
>> +   *cmd = EVLIST_CTL_CMD_ENABLE;
>> +   } else if (!strncmp(cmd_data, EVLIST_CTL_CMD_DISABLE_TAG,
>> +   (sizeof(EVLIST_CTL_CMD_DISABLE_TAG)-1))) 
>> {
>> +   *cmd = EVLIST_CTL_CMD_DISABLE;
>> +   }
>> +   }
>> +
>> +   return err;
>> +}


Re: [PATCH v2] arm: dts: vf610-zii-scu4-aib: Configure fibre ports to 1000BaseX

2020-07-13 Thread Shawn Guo
On Wed, Jul 08, 2020 at 05:11:54PM -0700, Chris Healy wrote:
> From: Andrew Lunn 
> 
> The SFF soldered onto the board expect the ports to use 1000BaseX.  It
> makes no sense to have the ports set to SGMII, since they don't even
> support that mode.
> 
> Signed-off-by: Andrew Lunn 
> Signed-off-by: Chris Healy 

s/arm/ARM in subject prefix, and applied.


Re: [PATCH v3] PCI: aardvark: Don't touch PCIe registers if no card connected

2020-07-13 Thread Pali Rohár
On Friday 10 July 2020 10:18:00 Lorenzo Pieralisi wrote:
> On Thu, Jul 09, 2020 at 05:09:59PM +0200, Pali Rohár wrote:
> > > I understand that but the bridge bus resource can be trimmed to just
> > > contain the root bus because that's the only one where there is a
> > > chance you can enumerate a device.
> > 
> > It is possible to register only root bridge without endpoint?
> 
> It is possible to register the root bridge with a trimmed IORESOURCE_BUS
> so that you don't enumerate anything other than the root port.

Hello Lorenzo! I really do not know how to achieve it. From code it
looks like that pci/probe.c scans child buses unconditionally.

pci-aardvark.c calls pci_host_probe() which calls functions
pci_scan_root_bus_bridge() which calls pci_scan_child_bus() which calls
pci_scan_child_bus_extend() which calls pci_scan_bridge_extend() (bridge
needs to be reconfigured) which then try to probe child bus via
pci_scan_child_bus_extend() because bridge is not card bus.

In function pci_scan_bridge_extend() I do not see a way how to skip
probing for child buses which would avoid enumerating aardvark root
bridge when PCIe device is not connected.

dmesg output contains:

  advk-pcie d007.pcie: link never came up
  advk-pcie d007.pcie: PCI host bridge to bus :00
  pci_bus :00: root bus resource [bus 00-ff]
  pci_bus :00: root bus resource [mem 0xe800-0xe8ff]
  pci_bus :00: root bus resource [io  0x-0x] (bus address 
[0xe900-0xe900])
  pci_bus :00: scanning bus
  pci :00:00.0: [1b4b:0100] type 01 class 0x060400
  pci :00:00.0: reg 0x38: [mem 0x-0x07ff pref]
  pci_bus :00: fixups for bus
  pci :00:00.0: scanning [bus 00-00] behind bridge, pass 0
  pci :00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
  pci :00:00.0: scanning [bus 00-00] behind bridge, pass 1
  pci_bus :01: scanning bus
  advk-pcie d007.pcie: advk_pcie_valid_device


Re: [PATCH v2 2/2] soc: mediatek: add mtk-devapc driver

2020-07-13 Thread Neal Liu
Hi Chun-Kuang,

Thanks for your review.

On Fri, 2020-07-10 at 22:21 +0800, Chun-Kuang Hu wrote:
> Hi, Neal:
> 
> Neal Liu  於 2020年7月10日 週五 上午11:23寫道:
> >
> > Hi Chun-Kuang,
> >
> > Thanks for your review.
> >
> > On Thu, 2020-07-09 at 21:01 +0800, Chun-Kuang Hu wrote:
> > > Hi, Neal:
> > >
> > > Neal Liu  於 2020年7月9日 週四 下午5:13寫道:
> > > >
> > > > MediaTek bus fabric provides TrustZone security support and data
> > > > protection to prevent slaves from being accessed by unexpected
> > > > masters.
> > > > The security violation is logged and sent to the processor for
> > > > further analysis or countermeasures.
> > > >
> > > > Any occurrence of security violation would raise an interrupt, and
> > > > it will be handled by mtk-devapc driver. The violation
> > > > information is printed in order to find the murderer.
> > > >
> > > > Signed-off-by: Neal Liu 
> > >
> > > [snip]
> > >
> > > > +
> > > > +static u32 get_shift_group(struct mtk_devapc_context *devapc_ctx,
> > > > +  int slave_type, int vio_idx)
> > >
> > > vio_idx  is useless, so remove it.
> > >
> >
> > yes, my mistake. I'll remove it on next patch.
> >
> > > > +{
> > > > +   u32 vio_shift_sta;
> > > > +   void __iomem *reg;
> > > > +   int bit;
> > > > +
> > > > +   reg = mtk_devapc_pd_get(devapc_ctx, slave_type, VIO_SHIFT_STA, 
> > > > 0);
> > > > +   vio_shift_sta = readl(reg);
> > > > +
> > > > +   for (bit = 0; bit < 32; bit++) {
> > > > +   if ((vio_shift_sta >> bit) & 0x1)
> > > > +   break;
> > > > +   }
> > > > +
> > > > +   return bit;
> > > > +}
> > > > +
> > >
> > > [snip]
> > >
> > > > +
> > > > +/*
> > > > + * devapc_violation_irq - the devapc Interrupt Service Routine (ISR) 
> > > > will dump
> > > > + *   violation information including which master 
> > > > violates
> > > > + *   access slave.
> > > > + */
> > > > +static irqreturn_t devapc_violation_irq(int irq_number,
> > > > +   struct mtk_devapc_context 
> > > > *devapc_ctx)
> > > > +{
> > > > +   const struct mtk_device_info **device_info;
> > > > +   int slave_type_num;
> > > > +   int vio_idx = -1;
> > > > +   int slave_type;
> > > > +
> > > > +   slave_type_num = devapc_ctx->slave_type_num;
> > > > +   device_info = devapc_ctx->device_info;
> > > > +
> > > > +   for (slave_type = 0; slave_type < slave_type_num; slave_type++) 
> > > > {
> > >
> > > If slave_type_num is 1, I think the code should be simpler.
> >
> > slave_type_num is depends on DT data, it's not always 1.
> 
> Please change commit title to "add mt6779 mtk-devapc driver". This
> patch is just for mt6779. If slave_type_num = 1 in mt6779, there is
> only one slave and we don't need a slave_type variable. Add
> slave_type_num in the patch of adding one SoC which has multiple
> slaves.

If slave_type_num value is passed from DT data, could we still assume
its value? Does it make sense to have this strong assumption?

I'm going to remove mtk_device_info struct array, and pass all SoC
specific data from DT.
Is it okay to keep slave_type_num as a variance?

> 
> >
> > >
> > > > +   if (!mtk_devapc_dump_vio_dbg(devapc_ctx, slave_type, 
> > > > _idx))
> > > > +   continue;
> > > > +
> > > > +   /* Ensure that violation info are written before
> > > > +* further operations
> > > > +*/
> > > > +   smp_mb();
> > > > +
> > > > +   mask_module_irq(devapc_ctx, slave_type, vio_idx, true);
> > >
> > > Why do you mask irq?
> >
> > It has to mask slave's irq before clear violation status.
> > It's one of hardware design.
> 
> If don't do this before clear_vio_status, what would happen? The clear
> would fail?

If we don't mask slave's irq before clear vio status, It might trigger
another interrupt before current ISR finished. The nested interrupt will
have unexpected behavior and hardware state machine goes wrong.

> 
> >
> > >
> > > > +
> > > > +   clear_vio_status(devapc_ctx, slave_type, vio_idx);
> > > > +
> > > > +   mask_module_irq(devapc_ctx, slave_type, vio_idx, false);
> > > > +   }
> > > > +
> > > > +   return IRQ_HANDLED;
> > > > +}
> > > > +
> > > > +/*
> > > > + * start_devapc - initialize devapc status and start receiving 
> > > > interrupt
> > > > + *   while devapc violation is triggered.
> > > > + */
> > >
> > > [snip]
> > >
> > > > +
> > > > +struct mtk_device_info {
> > > > +   int sys_index;
> > >
> > > Useless, so remove it.
> >
> > We need to print it as our debug information.
> > But I did not apply it on this patch, I'll add it on next patch.
> 
> I think vio address is enough to find out the murder, so remove it in
> this patch. If it provide another information, add it in another patch
> and describe clear about what is this and how to use this information.
> 

Okay, it 

[PATCH] KVM: nVMX: properly pad struct kvm_vmx_nested_state_hdr

2020-07-13 Thread Vitaly Kuznetsov
Holes in structs which are userspace ABI are undesireable.

Fixes: 83d31e5271ac ("KVM: nVMX: fixes for preemption timer migration")
Signed-off-by: Vitaly Kuznetsov 
---
 Documentation/virt/kvm/api.rst  | 2 +-
 arch/x86/include/uapi/asm/kvm.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 320788f81a05..7beccda11978 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -4345,7 +4345,7 @@ Errors:
struct {
__u16 flags;
} smm;
-
+   __u16 pad;
__u32 flags;
__u64 preemption_timer_deadline;
   };
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 0780f97c1850..aae3df1cbd01 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -414,7 +414,7 @@ struct kvm_vmx_nested_state_hdr {
struct {
__u16 flags;
} smm;
-
+   __u16 pad;
__u32 flags;
__u64 preemption_timer_deadline;
 };
-- 
2.25.4



[PATCH] IB/iser: Replace HTTP links with HTTPS ones

2020-07-13 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 drivers/infiniband/ulp/iser/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/ulp/iser/Kconfig 
b/drivers/infiniband/ulp/iser/Kconfig
index 3016a0c9a9f0..6ba73ae1291b 100644
--- a/drivers/infiniband/ulp/iser/Kconfig
+++ b/drivers/infiniband/ulp/iser/Kconfig
@@ -9,5 +9,5 @@ config INFINIBAND_ISER
  that speak iSCSI over iSER over InfiniBand.
 
  The iSER protocol is defined by IETF.
- See 
+ See 
  and 
-- 
2.27.0



[PATCH 1/2] riscv: Fix building error in entry.S when CONFIG_RISCV_M_MODE is enabled

2020-07-13 Thread Greentime Hu
arch/riscv/kernel/entry.S: Assembler messages:
arch/riscv/kernel/entry.S:106: Error: illegal operands `andi a0,s1,0x1800'

This building error is because of the SR_MPP value is too large to be used
as an immediate value for andi. To fix this issue I use li to set the
immediate value to t0, then it can use t0 and s1 to do and operation.

Reported-by: kernel test robot 
Signed-off-by: Greentime Hu 
---
 arch/riscv/kernel/entry.S | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index 6ed579fc1073..000984695cd6 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -99,7 +99,8 @@ _save_context:
 
 #ifdef CONFIG_CONTEXT_TRACKING
/* If previous state is in user mode, call context_tracking_user_exit. 
*/
-   andi a0, s1, SR_SPP
+   li t0, SR_PP
+   and a0, s1, t0
bnez a0, skip_context_tracking
call context_tracking_user_exit
 
-- 
2.27.0



[PATCH 2/2] riscv: Simplify the checking for SR_PP

2020-07-13 Thread Greentime Hu
This patch simplifies the checking for SR_MPP and SR_SPP. It uses SR_PP in the
code flow for both m-mode and s-mode then we can remove the ifdef here.

Signed-off-by: Greentime Hu 
---
 arch/riscv/kernel/entry.S | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index 000984695cd6..597beae0d238 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -210,13 +210,8 @@ ret_from_syscall_rejected:
 ret_from_exception:
REG_L s0, PT_STATUS(sp)
csrc CSR_STATUS, SR_IE
-#ifdef CONFIG_RISCV_M_MODE
-   /* the MPP value is too large to be used as an immediate arg for addi */
-   li t0, SR_MPP
+   li t0, SR_PP
and s0, s0, t0
-#else
-   andi s0, s0, SR_SPP
-#endif
bnez s0, resume_kernel
 
 resume_userspace:
-- 
2.27.0



RE: [PATCH v11 1/2] ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records

2020-07-13 Thread Shiju Jose
Hi Rafael, Hi James,

Can you help to merge this patch because I added and tested all the suggestions 
from James.

Thanks,
Shiju

>-Original Message-
>From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
>ow...@vger.kernel.org] On Behalf Of Shiju Jose
>Sent: 22 June 2020 13:05
>To: linux-a...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>ker...@vger.kernel.org; r...@rjwysocki.net; helg...@kernel.org;
>b...@alien8.de; james.mo...@arm.com; l...@kernel.org;
>tony.l...@intel.com; dan.carpen...@oracle.com;
>zhangligu...@linux.alibaba.com; andriy.shevche...@linux.intel.com;
>Wangkefeng (OS Kernel Lab) ;
>jroe...@suse.de
>Cc: Linuxarm ; yangyicong
>; Jonathan Cameron
>; tanxiaofei 
>Subject: [PATCH v11 1/2] ACPI / APEI: Add a notifier chain for unknown
>(vendor) CPER records
>
>CPER records describing a firmware-first error are identified by GUID.
>The ghes driver currently logs, but ignores any unknown CPER records.
>This prevents describing errors that can't be represented by a standard entry,
>that would otherwise allow a driver to recover from an error.
>The UEFI spec calls these 'Non-standard Section Body' (N.2.3 of version 2.8).
>
>Add a notifier chain for these non-standard/vendor-records. Callers must
>identify their type of records by GUID.
>
>Record data is copied to memory from the ghes_estatus_pool to allow us to
>keep it until after the notifier has run.
>
>Signed-off-by: Shiju Jose  [ Removed kfifo and
>ghes_gdata_pool. Expanded commit message ]
>Signed-off-by: James Morse 
>---
> drivers/acpi/apei/ghes.c | 63
>
> include/acpi/ghes.h  | 27 +
> 2 files changed, 90 insertions(+)
>
>diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index
>81bf71b10d44..99df00f64306 100644
>--- a/drivers/acpi/apei/ghes.c
>+++ b/drivers/acpi/apei/ghes.c
>@@ -79,6 +79,12 @@
>   ((struct acpi_hest_generic_status *)\
>((struct ghes_estatus_node *)(estatus_node) + 1))
>
>+#define GHES_VENDOR_ENTRY_LEN(gdata_len)   \
>+  (sizeof(struct ghes_vendor_record_entry) + (gdata_len))
>+#define GHES_GDATA_FROM_VENDOR_ENTRY(vendor_entry) \
>+  ((struct acpi_hest_generic_data *)  \
>+  ((struct ghes_vendor_record_entry *)(vendor_entry) + 1))
>+
> /*
>  *  NMI-like notifications vary by architecture, before the compiler can prune
>  *  unused static functions it needs a value for these enums.
>@@ -123,6 +129,12 @@ static DEFINE_MUTEX(ghes_list_mutex);
>  */
> static DEFINE_SPINLOCK(ghes_notify_lock_irq);
>
>+struct ghes_vendor_record_entry {
>+  struct work_struct work;
>+  int error_severity;
>+  char vendor_record[];
>+};
>+
> static struct gen_pool *ghes_estatus_pool;  static unsigned long
>ghes_estatus_pool_size_request;
>
>@@ -511,6 +523,56 @@ static void ghes_handle_aer(struct
>acpi_hest_generic_data *gdata)  #endif  }
>
>+static BLOCKING_NOTIFIER_HEAD(vendor_record_notify_list);
>+
>+int ghes_register_vendor_record_notifier(struct notifier_block *nb) {
>+  return blocking_notifier_chain_register(_record_notify_list,
>+nb); } EXPORT_SYMBOL_GPL(ghes_register_vendor_record_notifier);
>+
>+void ghes_unregister_vendor_record_notifier(struct notifier_block *nb)
>+{
>+  blocking_notifier_chain_unregister(_record_notify_list, nb);
>}
>+EXPORT_SYMBOL_GPL(ghes_unregister_vendor_record_notifier);
>+
>+static void ghes_vendor_record_work_func(struct work_struct *work) {
>+  struct ghes_vendor_record_entry *entry;
>+  struct acpi_hest_generic_data *gdata;
>+  u32 len;
>+
>+  entry = container_of(work, struct ghes_vendor_record_entry, work);
>+  gdata = GHES_GDATA_FROM_VENDOR_ENTRY(entry);
>+
>+  blocking_notifier_call_chain(_record_notify_list,
>+   entry->error_severity, gdata);
>+
>+  len = GHES_VENDOR_ENTRY_LEN(acpi_hest_get_record_size(gdata));
>+  gen_pool_free(ghes_estatus_pool, (unsigned long)entry, len); }
>+
>+static void ghes_defer_non_standard_event(struct acpi_hest_generic_data
>*gdata,
>+int sev)
>+{
>+  struct acpi_hest_generic_data *copied_gdata;
>+  struct ghes_vendor_record_entry *entry;
>+  u32 len;
>+
>+  len = GHES_VENDOR_ENTRY_LEN(acpi_hest_get_record_size(gdata));
>+  entry = (void *)gen_pool_alloc(ghes_estatus_pool, len);
>+  if (!entry)
>+  return;
>+
>+  copied_gdata = GHES_GDATA_FROM_VENDOR_ENTRY(entry);
>+  memcpy(copied_gdata, gdata, acpi_hest_get_record_size(gdata));
>+  entry->error_severity = sev;
>+
>+  INIT_WORK(>work, ghes_vendor_record_work_func);
>+  schedule_work(>work);
>+}
>+
> static bool ghes_do_proc(struct ghes *ghes,
>const struct acpi_hest_generic_status *estatus)  {
>@@ -549,6 +611,7 @@ static bool ghes_do_proc(struct ghes *ghes,
>   } else {
>   

Re: [PATCH] debugfs: add a proxy stub for ->read_iter

2020-07-13 Thread Greg KH
On Mon, Jul 13, 2020 at 09:37:29AM +0200, Christoph Hellwig wrote:
> debugfs registrations typically go through a set of proxy ops to deal
> with refcounting, which need to support every method that can be
> supported.  Add ->read_iter to the proxy ops to prepare for seq_file to
> be switch to ->read_iter.
> 
> Reported-by: Jon Hunter 
> Signed-off-by: Christoph Hellwig 

Acked-by: Greg Kroah-Hartman 


Re: allow ->read_iter on debugfs

2020-07-13 Thread Greg KH
On Mon, Jul 13, 2020 at 09:37:28AM +0200, Christoph Hellwig wrote:
> Hi Greg,
> 
> in my filesystem set_fs removel series I convert the seq_file interface
> to be iov_iter based.  It turns out debugfs needs this little patch
> to proxy read_iter as well.  Let me know if you are ok with me queueing
> this up with the rest of the series.
> 
> 

No objection from me, please do so!

thanks,

greg k-h


BE MY PARTNER IN THIS BUSINESS

2020-07-13 Thread Mr Suleman Bello
Hello Dear Friend,

I am Mr.Suleman Bello from Burkina faso in West Africa, I have an
important business discussion I wish to share with you which I believe
will interest you, and you are going to benefit from it. We shall go
over the details once i receive your urgent response. let me know you
receive my email, so i can explain more.

Regards,
Mr.Suleman Bello.


Re: [PATCH v2 1/5] power: supply: core: add quick charge type property

2020-07-13 Thread Greg KH
On Mon, Jul 13, 2020 at 12:03:36PM +0800, Qiwu Huang wrote:
> From: Qiwu Huang 
> 
> Reports the kind of quick charge type based on
> different adapter power. UI will show different
> animation effect for different quick charge type.
> 
> Signed-off-by: Qiwu Huang 
> ---
>  Documentation/ABI/testing/sysfs-class-power | 10 ++
>  drivers/power/supply/power_supply_sysfs.c   |  1 +
>  include/linux/power_supply.h|  1 +
>  3 files changed, 12 insertions(+)

What changed from v1 of this patch?  SHouldn't that always be below the
--- line?


> 
> diff --git a/Documentation/ABI/testing/sysfs-class-power 
> b/Documentation/ABI/testing/sysfs-class-power
> index 216d61a22f1e..d3169d47e359 100644
> --- a/Documentation/ABI/testing/sysfs-class-power
> +++ b/Documentation/ABI/testing/sysfs-class-power
> @@ -708,3 +708,13 @@ Description:
>  
>   Access: Read
>   Valid values: 1-31
> +
> +What:/sys/class/power_supply//quick_charge_type
> +Date:Jul 2020
> +Contact: Fei Jiang 
> + Description:
> + Reports the kind of quick charge type based on different 
> adapter power.

What are the allowed types here?  Shouldn't that also be an enumerated
type with a predefined string?

thanks,

greg k-h


Re: [PATCH v4 2/2] Add Intel LGM soc DMA support.

2020-07-13 Thread Reddy, MallikarjunaX

Thanks for the review Andy. My comments inline.

On 7/9/2020 7:09 PM, Andy Shevchenko wrote:

On Thu, Jul 09, 2020 at 02:01:06PM +0800, Amireddy Mallikarjuna reddy wrote:

Add DMA controller driver for Lightning Mountain(LGM) family of SoCs.

The main function of the DMA controller is the transfer of data from/to any
DPlus compliant peripheral to/from the memory. A memory to memory copy
capability can also be configured.

This ldma driver is used for configure the device and channnels for data
and control paths.
+#include "../virt-dma.h"

I didn't find any evidence this driver utilizes virt-dma API in full.
For example, there is a virt_dma_desc structure and descriptor management 
around it.
Why don't you use it?

Lgm dma soc has its own hardware descriptor.
and each dma channel is associated with a peripheral, it is one to one 
mapping between channel and associated peripheral.




Re: [PATCH v2 2/5] power: supply: core: add wireless charger adapter type property

2020-07-13 Thread Greg KH
On Mon, Jul 13, 2020 at 12:03:37PM +0800, Qiwu Huang wrote:
> From: Qiwu Huang 
> 
> Reports what type of wireless adapter connection is
> currently active forthe supply.
> for example it can show if ADAPTER_PD capable source is attached.
> 
> Signed-off-by: Qiwu Huang 
> ---
>  Documentation/ABI/testing/sysfs-class-power | 11 +++
>  drivers/power/supply/power_supply_sysfs.c   |  1 +
>  include/linux/power_supply.h|  1 +
>  3 files changed, 13 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-power 
> b/Documentation/ABI/testing/sysfs-class-power
> index d3169d47e359..cd07d3f4e8b1 100644
> --- a/Documentation/ABI/testing/sysfs-class-power
> +++ b/Documentation/ABI/testing/sysfs-class-power
> @@ -718,3 +718,14 @@ Contact: Fei Jiang 
>   Access: Read-Only
>   Valid values: Reported as integer
>  
> += Wireless Charger Properties =
> +What:/sys/class/power_supply//tx_adapter
> +Date:Jul 2020
> +Contact: Fei Jiang 
> +Description:
> + Reports what type of wireless adapter connection is currently 
> active for
> + the supply, for example it can show if ADAPTER_PD capable source
> + is attached.

Same question as before, what are the allowed types here?

> +
> + Access: Read-Only
> + Valid values: Reported as integer

What integer maps to what values?

thanks,

greg k-h


[PATCH] LICENSES: Replace HTTP links with HTTPS ones

2020-07-13 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 LICENSES/dual/Apache-2.0 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/LICENSES/dual/Apache-2.0 b/LICENSES/dual/Apache-2.0
index 6e89ddeab187..fd71308fd2c3 100644
--- a/LICENSES/dual/Apache-2.0
+++ b/LICENSES/dual/Apache-2.0
@@ -15,7 +15,7 @@ Apache License
 
 Version 2.0, January 2004
 
-http://www.apache.org/licenses/
+https://www.apache.org/licenses/
 
 TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
 
-- 
2.27.0



Re: [PATCH V2] soc: imx: select ARM_GIC_V3 for i.MX8M

2020-07-13 Thread Shawn Guo
On Fri, Jul 10, 2020 at 09:43:53AM +0800, peng@nxp.com wrote:
> From: Peng Fan 
> 
> Select ARM_GIC_V3, then it is able to use gic v3 driver in aarch32
> mode linux on aarch64 hardware. For aarch64 mode, it not hurts
> to select ARM_GIC_V3.
> 
> Acked-by: Arnd Bergmann 
> Signed-off-by: Peng Fan 

Applied, thanks.


[PATCH v18 00/14] Introduce Data Access MONitor (DAMON)

2020-07-13 Thread SeongJae Park
From: SeongJae Park 

Changes from Previous Version
=

- Reorganize the doc and remove png blobs (Mike Rapoport)
- Wordsmith mechnisms doc and commit messages
- tools/wss: Set default working set access frequency threshold
- Avoid race in damon deamon start

Introduction


DAMON is a data access monitoring framework subsystem for the Linux kernel.
The core mechanisms of DAMON called 'region based sampling' and 'adaptive
regions adjustment' (refer to 'mechanisms.rst' in the 11th patch of this
patchset for the detail) make it

 - accurate (The monitored information is useful for DRAM level memory
   management. It might not appropriate for Cache-level accuracy, though.),
 - light-weight (The monitoring overhead is low enough to be applied online
   while making no impact on the performance of the target workloads.), and
 - scalable (the upper-bound of the instrumentation overhead is controllable
   regardless of the size of target workloads.).

Using this framework, therefore, the kernel's core memory management mechanisms
such as reclamation and THP can be optimized for better memory management.  The
experimental memory management optimization works that incurring high
instrumentation overhead will be able to have another try.  In user space,
meanwhile, users who have some special workloads will be able to write
personalized tools or applications for deeper understanding and specialized
optimizations of their systems.

Evaluations
===

We evaluated DAMON's overhead, monitoring quality and usefulness using 25
realistic workloads on my QEMU/KVM based virtual machine running a kernel that
v16 DAMON patchset is applied.

DAMON is lightweight. It increases system memory usage by only -0.25% and
consumes less than 1% CPU time in most case. It slows target workloads down by
only 0.94%.

DAMON is accurate and useful for memory management optimizations. An
experimental DAMON-based operation scheme for THP, 'ethp', removes 31.29% of
THP memory overheads while preserving 60.64% of THP speedup. Another
experimental DAMON-based 'proactive reclamation' implementation, 'prcl',
reduces 87.95% of residential sets and 29.52% of system memory footprint while
incurring only 2.15% runtime overhead in the best case (parsec3/freqmine).

NOTE that the experimentail THP optimization and proactive reclamation are not
for production, just only for proof of concepts.

Please refer to the official document[1] or "Documentation/admin-guide/mm: Add
a document for DAMON" patch in this patchset for detailed evaluation setup and
results.

[1] 
https://damonitor.github.io/doc/html/latest-damon/admin-guide/mm/damon/eval.html

More Information


We prepared a showcase web site[1] that you can get more information.  There
are

- the official documentations[2],
- the heatmap format dynamic access pattern of various realistic workloads for
  heap area[3], mmap()-ed area[4], and stack[5] area,
- the dynamic working set size distribution[6] and chronological working set
  size changes[7], and
- the latest performance test results[8].

[1] https://damonitor.github.io/_index
[2] https://damonitor.github.io/doc/html/latest-damon
[3] https://damonitor.github.io/test/result/visual/latest/rec.heatmap.0.png.html
[4] https://damonitor.github.io/test/result/visual/latest/rec.heatmap.1.png.html
[5] https://damonitor.github.io/test/result/visual/latest/rec.heatmap.2.png.html
[6] https://damonitor.github.io/test/result/visual/latest/rec.wss_sz.png.html
[7] https://damonitor.github.io/test/result/visual/latest/rec.wss_time.png.html
[8] https://damonitor.github.io/test/result/perf/latest/html/index.html

Baseline and Complete Git Trees
===

The patches are based on the v5.7.  You can also clone the complete git
tree:

$ git clone git://github.com/sjp38/linux -b damon/patches/v18

The web is also available:
https://github.com/sjp38/linux/releases/tag/damon/patches/v18

There are a couple of trees for entire DAMON patchset series.  It includes
future features.  The first one[1] contains the changes for latest release,
while the other one[2] contains the changes for next release.

[1] https://github.com/sjp38/linux/tree/damon/master
[2] https://github.com/sjp38/linux/tree/damon/next

Sequence Of Patches
===

The 1st patch exports 'lookup_page_ext()' to GPL modules so that it can be used
by DAMON even though it is built as a loadable module.

Next four patches implement the target address space independent core logics of
DAMON and it's programming interface.  The 2nd patch introduces DAMON module,
it's data structures, and data structure related common functions.  Following
three patches (3rd to 5th) implements the core mechanisms of DAMON, namely
regions based sampling (patch 3), adaptive regions adjustment (patch 4), and
dynamic memory mapping chage adoption (patch 5).

The following one (patch 6) implements the virtual memory address space
specific 

Re: [Ksummit-discuss] [PATCH v3] CodingStyle: Inclusive Terminology

2020-07-13 Thread Julia Lawall



On Mon, 13 Jul 2020, Takashi Iwai wrote:

> On Wed, 08 Jul 2020 20:14:27 +0200,
> Dan Williams wrote:
> >
> > +Recommended replacements for 'blacklist/whitelist' are:
> > +'denylist / allowlist'
> > +'blocklist / passlist'
>
> I started looking through the tree now and noticed there are lots of
> patterns like "whitelisted" or "blacklisted".  How can the words fit
> for those?  Actually, there are two cases like:
>
> - Foo is blacklisted
> - Allow to load the non-whitelisted cards
>
> Currently I'm replacing the former with "Foo is in denylist", but not

In the denylist?

julia


> sure about the latter case.  I thought Kees mentioned about this, but
> don't remember the proposal...
>
> In anyway, I'm for the action:
>   Acked-by: Takashi Iwai 
>
>
> thanks,
>
> Takashi
> ___
> Ksummit-discuss mailing list
> ksummit-disc...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>


[PATCH v18 02/14] mm: Introduce Data Access MONitor (DAMON)

2020-07-13 Thread SeongJae Park
From: SeongJae Park 

DAMON is a data access monitoring framework subsystem for the Linux
kernel.  The core mechanisms of DAMON make it

 - accurate (the monitoring output is useful enough for DRAM level
   memory management; It might not appropriate for CPU Cache levels,
   though),
 - light-weight (the monitoring overhead is low enough to be applied
   online), and
 - scalable (the upper-bound of the overhead is in constant range
   regardless of the size of target workloads).

Using this framework, therefore, the kernel's memory management
mechanisms can make advanced decisions.  Experimental memory management
optimization works that incurring high data accesses monitoring overhead
could implemented again.  In user space, meanwhile, users who have some
special workloads can write personalized applications for better
understanding and optimizations of their workloads and systems.

This commit is implementing only the stub for the module load/unload,
basic data structures, and simple manipulation functions of the
structures to keep the size of commit small.  The core mechanisms of
DAMON will be implemented one by one by following commits.

Signed-off-by: SeongJae Park 
Reviewed-by: Leonard Foerster 
Reviewed-by: Varad Gautam 
---
 include/linux/damon.h |  63 ++
 mm/Kconfig|  12 +++
 mm/Makefile   |   1 +
 mm/damon.c| 188 ++
 4 files changed, 264 insertions(+)
 create mode 100644 include/linux/damon.h
 create mode 100644 mm/damon.c

diff --git a/include/linux/damon.h b/include/linux/damon.h
new file mode 100644
index ..c8f8c1c41a45
--- /dev/null
+++ b/include/linux/damon.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * DAMON api
+ *
+ * Copyright 2019-2020 Amazon.com, Inc. or its affiliates.
+ *
+ * Author: SeongJae Park 
+ */
+
+#ifndef _DAMON_H_
+#define _DAMON_H_
+
+#include 
+#include 
+
+/**
+ * struct damon_addr_range - Represents an address region of [@start, @end).
+ * @start: Start address of the region (inclusive).
+ * @end:   End address of the region (exclusive).
+ */
+struct damon_addr_range {
+   unsigned long start;
+   unsigned long end;
+};
+
+/**
+ * struct damon_region - Represents a monitoring target region.
+ * @ar:The address range of the region.
+ * @sampling_addr: Address of the sample for the next access check.
+ * @nr_accesses:   Access frequency of this region.
+ * @list:  List head for siblings.
+ */
+struct damon_region {
+   struct damon_addr_range ar;
+   unsigned long sampling_addr;
+   unsigned int nr_accesses;
+   struct list_head list;
+};
+
+/**
+ * struct damon_task - Represents a monitoring target task.
+ * @pid:   Process id of the task.
+ * @regions_list:  Head of the monitoring target regions of this task.
+ * @list:  List head for siblings.
+ *
+ * If the monitoring target address space is task independent (e.g., physical
+ * memory address space monitoring), @pid should be '-1'.
+ */
+struct damon_task {
+   int pid;
+   struct list_head regions_list;
+   struct list_head list;
+};
+
+/**
+ * struct damon_ctx - Represents a context for each monitoring.
+ * @tasks_list:Head of monitoring target tasks (_task) 
list.
+ */
+struct damon_ctx {
+   struct list_head tasks_list;/* 'damon_task' objects */
+};
+
+#endif
diff --git a/mm/Kconfig b/mm/Kconfig
index c1acc34c1c35..464e9594dcec 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -867,4 +867,16 @@ config ARCH_HAS_HUGEPD
 config MAPPING_DIRTY_HELPERS
 bool
 
+config DAMON
+   tristate "Data Access Monitor"
+   depends on MMU
+   help
+ This feature allows to monitor access frequency of each memory
+ region. The information can be useful for performance-centric DRAM
+ level memory management.
+
+ See https://damonitor.github.io/doc/html/latest-damon/index.html for
+ more information.
+ If unsure, say N.
+
 endmenu
diff --git a/mm/Makefile b/mm/Makefile
index fccd3756b25f..230e545b6e07 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -112,3 +112,4 @@ obj-$(CONFIG_MEMFD_CREATE) += memfd.o
 obj-$(CONFIG_MAPPING_DIRTY_HELPERS) += mapping_dirty_helpers.o
 obj-$(CONFIG_PTDUMP_CORE) += ptdump.o
 obj-$(CONFIG_PAGE_REPORTING) += page_reporting.o
+obj-$(CONFIG_DAMON) += damon.o
diff --git a/mm/damon.c b/mm/damon.c
new file mode 100644
index ..5ab13b1c15cf
--- /dev/null
+++ b/mm/damon.c
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Data Access Monitor
+ *
+ * Copyright 2019-2020 Amazon.com, Inc. or its affiliates.
+ *
+ * Author: SeongJae Park 
+ *
+ * This file is constructed in below parts.
+ *
+ * - Functions and macros for DAMON data structures
+ * - Functions for the module loading/unloading
+ *
+ * The core parts are not implemented yet.
+ */
+
+#define pr_fmt(fmt) "damon: " fmt
+

[PATCH v18 04/14] mm/damon: Adaptively adjust regions

2020-07-13 Thread SeongJae Park
From: SeongJae Park 

Even somehow the initial monitoring target regions are well constructed
to fulfill the assumption (pages in same region have similar access
frequencies), the data access pattern can be dynamically changed.  This
will result in low monitoring quality.  To keep the assumption as much
as possible, DAMON adaptively merges and splits each region based on
their access frequency.

For each ``aggregation interval``, it compares the access frequencies of
adjacent regions and merges those if the frequency difference is small.
Then, after it reports and clears the aggregated access frequency of
each region, it splits each region into two or three regions if the
total number of regions will not exceed the user-specified maximum
number of regions after the split.

In this way, DAMON provides its best-effort quality and minimal overhead
while keeping the upper-bound overhead that users set.

Signed-off-by: SeongJae Park 
Reviewed-by: Leonard Foerster 
---
 include/linux/damon.h |  11 ++-
 mm/damon.c| 191 --
 2 files changed, 189 insertions(+), 13 deletions(-)

diff --git a/include/linux/damon.h b/include/linux/damon.h
index 7adc7b6b3507..97ddc74e207f 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -61,7 +61,8 @@ struct damon_task {
  *
  * @sample_interval:   The time between access samplings.
  * @aggr_interval: The time between monitor results aggregations.
- * @nr_regions:The number of monitoring regions.
+ * @min_nr_regions:The minimum number of monitoring regions.
+ * @max_nr_regions:The maximum number of monitoring regions.
  *
  * For each @sample_interval, DAMON checks whether each region is accessed or
  * not.  It aggregates and keeps the access information (number of accesses to
@@ -114,7 +115,8 @@ struct damon_task {
 struct damon_ctx {
unsigned long sample_interval;
unsigned long aggr_interval;
-   unsigned long nr_regions;
+   unsigned long min_nr_regions;
+   unsigned long max_nr_regions;
 
struct timespec64 last_aggregation;
 
@@ -133,8 +135,9 @@ struct damon_ctx {
 };
 
 int damon_set_pids(struct damon_ctx *ctx, int *pids, ssize_t nr_pids);
-int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int,
-   unsigned long aggr_int, unsigned long min_nr_reg);
+int damon_set_attrs(struct damon_ctx *ctx,
+   unsigned long sample_int, unsigned long aggr_int,
+   unsigned long min_nr_reg, unsigned long max_nr_reg);
 int damon_start(struct damon_ctx *ctx);
 int damon_stop(struct damon_ctx *ctx);
 
diff --git a/mm/damon.c b/mm/damon.c
index 29d82c2d65be..02bc7542a76f 100644
--- a/mm/damon.c
+++ b/mm/damon.c
@@ -176,6 +176,26 @@ static unsigned int nr_damon_regions(struct damon_task *t)
return nr_regions;
 }
 
+/* Returns the size upper limit for each monitoring region */
+static unsigned long damon_region_sz_limit(struct damon_ctx *ctx)
+{
+   struct damon_task *t;
+   struct damon_region *r;
+   unsigned long sz = 0;
+
+   damon_for_each_task(t, ctx) {
+   damon_for_each_region(r, t)
+   sz += r->ar.end - r->ar.start;
+   }
+
+   if (ctx->min_nr_regions)
+   sz /= ctx->min_nr_regions;
+   if (sz < MIN_REGION)
+   sz = MIN_REGION;
+
+   return sz;
+}
+
 /*
  * Functions for DAMON core logics and features
  */
@@ -226,6 +246,145 @@ static void kdamond_reset_aggregated(struct damon_ctx *c)
}
 }
 
+#define sz_damon_region(r) (r->ar.end - r->ar.start)
+
+/*
+ * Merge two adjacent regions into one region
+ */
+static void damon_merge_two_regions(struct damon_region *l,
+   struct damon_region *r)
+{
+   l->nr_accesses = (l->nr_accesses * sz_damon_region(l) +
+   r->nr_accesses * sz_damon_region(r)) /
+   (sz_damon_region(l) + sz_damon_region(r));
+   l->ar.end = r->ar.end;
+   damon_destroy_region(r);
+}
+
+#define diff_of(a, b) (a > b ? a - b : b - a)
+
+/*
+ * Merge adjacent regions having similar access frequencies
+ *
+ * t   task affected by merge operation
+ * thres   '->nr_accesses' diff threshold for the merge
+ * sz_limitsize upper limit of each region
+ */
+static void damon_merge_regions_of(struct damon_task *t, unsigned int thres,
+  unsigned long sz_limit)
+{
+   struct damon_region *r, *prev = NULL, *next;
+
+   damon_for_each_region_safe(r, next, t) {
+   if (prev && prev->ar.end == r->ar.start &&
+   diff_of(prev->nr_accesses, r->nr_accesses) <= thres &&
+   sz_damon_region(prev) + sz_damon_region(r) <= sz_limit)
+   damon_merge_two_regions(prev, r);
+   else
+   prev = r;
+   }
+}
+
+/*
+ * Merge adjacent regions having similar 

[PATCH v18 03/14] mm/damon: Implement region based sampling

2020-07-13 Thread SeongJae Park
From: SeongJae Park 

DAMON separates its monitoring target address space independent high
level logics from the target space dependent low level primitives for
flexible support of various address spaces.

This commit implements DAMON's target address space independent high
level logics for basic access check and region based sampling.  Hence,
without the target address space specific parts implementations, this
doesn't work alone.  A reference implementation of those will be
provided by a later commit.

Basic Access Check
==

The output of DAMON says what pages are how frequently accessed for a
given duration.  The resolution of the access frequency is controlled by
setting ``sampling interval`` and ``aggregation interval``.  In detail,
DAMON checks access to each page per ``sampling interval`` and
aggregates the results.  In other words, counts the number of the
accesses to each page.  After each ``aggregation interval`` passes,
DAMON calls callback functions that previously registered by users so
that users can read the aggregated results and then clears the results.
This can be described in below simple pseudo-code::

while monitoring_on:
for page in monitoring_target:
if accessed(page):
nr_accesses[page] += 1
if time() % aggregation_interval == 0:
for callback in user_registered_callbacks:
callback(monitoring_target, nr_accesses)
for page in monitoring_target:
nr_accesses[page] = 0
sleep(sampling interval)

The monitoring overhead of this mechanism will arbitrarily increase as
the size of the target workload grows.

Region Based Sampling
=

To avoid the unbounded increase of the overhead, DAMON groups adjacent
pages that assumed to have the same access frequencies into a region.
As long as the assumption (pages in a region have the same access
frequencies) is kept, only one page in the region is required to be
checked.  Thus, for each ``sampling interval``, DAMON randomly picks one
page in each region, waits for one ``sampling interval``, checks whether
the page is accessed meanwhile, and increases the access frequency of
the region if so.  Therefore, the monitoring overhead is controllable by
setting the number of regions.  DAMON allows users to set the minimum
and the maximum number of regions for the trade-off.

This scheme, however, cannot preserve the quality of the output if the
assumption is not guaranteed.  Next commit will address this problem.

Signed-off-by: SeongJae Park 
Reviewed-by: Leonard Foerster 
---
 include/linux/damon.h |  80 -
 mm/damon.c| 260 +-
 2 files changed, 337 insertions(+), 3 deletions(-)

diff --git a/include/linux/damon.h b/include/linux/damon.h
index c8f8c1c41a45..7adc7b6b3507 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -11,6 +11,8 @@
 #define _DAMON_H_
 
 #include 
+#include 
+#include 
 #include 
 
 /**
@@ -53,11 +55,87 @@ struct damon_task {
 };
 
 /**
- * struct damon_ctx - Represents a context for each monitoring.
+ * struct damon_ctx - Represents a context for each monitoring.  This is the
+ * main interface that allows users to set the attributes and get the results
+ * of the monitoring.
+ *
+ * @sample_interval:   The time between access samplings.
+ * @aggr_interval: The time between monitor results aggregations.
+ * @nr_regions:The number of monitoring regions.
+ *
+ * For each @sample_interval, DAMON checks whether each region is accessed or
+ * not.  It aggregates and keeps the access information (number of accesses to
+ * each region) for @aggr_interval time.  All time intervals are in
+ * micro-seconds.
+ *
+ * @kdamond:   Kernel thread who does the monitoring.
+ * @kdamond_stop:  Notifies whether kdamond should stop.
+ * @kdamond_lock:  Mutex for the synchronizations with @kdamond.
+ *
+ * For each monitoring request (damon_start()), a kernel thread for the
+ * monitoring is created.  The pointer to the thread is stored in @kdamond.
+ *
+ * The monitoring thread sets @kdamond to NULL when it terminates.  Therefore,
+ * users can know whether the monitoring is ongoing or terminated by reading
+ * @kdamond.  Also, users can ask @kdamond to be terminated by writing non-zero
+ * to @kdamond_stop.  Reads and writes to @kdamond and @kdamond_stop from
+ * outside of the monitoring thread must be protected by @kdamond_lock.
+ *
+ * Note that the monitoring thread protects only @kdamond and @kdamond_stop via
+ * @kdamond_lock.  Accesses to other fields must be protected by themselves.
+ *
  * @tasks_list:Head of monitoring target tasks (_task) 
list.
+ *
+ * @init_target_regions:   Constructs initial monitoring target regions.
+ * @prepare_access_checks: Prepares next access check of target regions.
+ * @check_accesses:Checks the access 

[PATCH v18 01/14] mm/page_ext: Export lookup_page_ext() to GPL modules

2020-07-13 Thread SeongJae Park
From: SeongJae Park 

This commit exports 'lookup_page_ext()' to GPL modules.  It will be used
by DAMON in following commit for the implementation of the region based
sampling.

Signed-off-by: SeongJae Park 
Reviewed-by: Leonard Foerster 
Reviewed-by: Varad Gautam 
---
 mm/page_ext.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/page_ext.c b/mm/page_ext.c
index a3616f7a0e9e..9d802d01fcb5 100644
--- a/mm/page_ext.c
+++ b/mm/page_ext.c
@@ -131,6 +131,7 @@ struct page_ext *lookup_page_ext(const struct page *page)
MAX_ORDER_NR_PAGES);
return get_entry(base, index);
 }
+EXPORT_SYMBOL_GPL(lookup_page_ext);
 
 static int __init alloc_node_page_ext(int nid)
 {
-- 
2.17.1



Re: [PATCH] ARM: imx_v6_v7_defconfig: Support i.MX8MM

2020-07-13 Thread Shawn Guo
On Fri, Jul 10, 2020 at 10:10:53AM +0800, peng@nxp.com wrote:
> From: Peng Fan 
> 
> i.MX8MM is built with AArch64 hardware, this is to support
> it could run in Aarch32 mode with clock and pinctrl driver enabled.
> 
> Signed-off-by: Peng Fan 

Applied, thanks.


[PATCH v18 07/14] mm/damon: Implement access pattern recording

2020-07-13 Thread SeongJae Park
From: SeongJae Park 

This commit implements the recording feature of DAMON.  If this feature
is enabled, DAMON writes the monitored access patterns in its binary
format into a file which specified by the user.  This is already able to
be implemented by each user using the callbacks.  However, as the
recording is expected to be widely used, this commit implements the
feature in the DAMON, for more convenience.

Signed-off-by: SeongJae Park 
Reviewed-by: Leonard Foerster 
---
 include/linux/damon.h |  15 +
 mm/damon.c| 141 +-
 2 files changed, 153 insertions(+), 3 deletions(-)

diff --git a/include/linux/damon.h b/include/linux/damon.h
index 310d36d123b3..b0e7e31a22b3 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -72,6 +72,14 @@ struct damon_task {
  * in case of virtual memory monitoring) and applies the changes for each
  * @regions_update_interval.  All time intervals are in micro-seconds.
  *
+ * @rbuf: In-memory buffer for monitoring result recording.
+ * @rbuf_len: The length of @rbuf.
+ * @rbuf_offset: The offset for next write to @rbuf.
+ * @rfile_path: Record file path.
+ *
+ * If @rbuf, @rbuf_len, and @rfile_path are set, the monitored results are
+ * automatically stored in @rfile_path file.
+ *
  * @kdamond:   Kernel thread who does the monitoring.
  * @kdamond_stop:  Notifies whether kdamond should stop.
  * @kdamond_lock:  Mutex for the synchronizations with @kdamond.
@@ -129,6 +137,11 @@ struct damon_ctx {
struct timespec64 last_aggregation;
struct timespec64 last_regions_update;
 
+   unsigned char *rbuf;
+   unsigned int rbuf_len;
+   unsigned int rbuf_offset;
+   char *rfile_path;
+
struct task_struct *kdamond;
bool kdamond_stop;
struct mutex kdamond_lock;
@@ -154,6 +167,8 @@ int damon_set_pids(struct damon_ctx *ctx, int *pids, 
ssize_t nr_pids);
 int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int,
unsigned long aggr_int, unsigned long regions_update_int,
unsigned long min_nr_reg, unsigned long max_nr_reg);
+int damon_set_recording(struct damon_ctx *ctx,
+   unsigned int rbuf_len, char *rfile_path);
 int damon_start(struct damon_ctx *ctx);
 int damon_stop(struct damon_ctx *ctx);
 
diff --git a/mm/damon.c b/mm/damon.c
index 386780739007..55ecfab64220 100644
--- a/mm/damon.c
+++ b/mm/damon.c
@@ -58,6 +58,10 @@
 #define damon_for_each_task_safe(t, next, ctx) \
list_for_each_entry_safe(t, next, &(ctx)->tasks_list, list)
 
+#define MIN_RECORD_BUFFER_LEN  1024
+#define MAX_RECORD_BUFFER_LEN  (4 * 1024 * 1024)
+#define MAX_RFILE_PATH_LEN 256
+
 /* Get a random number in [l, r) */
 #define damon_rand(l, r) (l + prandom_u32() % (r - l))
 
@@ -707,16 +711,88 @@ static bool kdamond_aggregate_interval_passed(struct 
damon_ctx *ctx)
 }
 
 /*
- * Reset the aggregated monitoring results
+ * Flush the content in the result buffer to the result file
+ */
+static void damon_flush_rbuffer(struct damon_ctx *ctx)
+{
+   ssize_t sz;
+   loff_t pos = 0;
+   struct file *rfile;
+
+   if (!ctx->rbuf_offset)
+   return;
+
+   rfile = filp_open(ctx->rfile_path, O_CREAT | O_RDWR | O_APPEND, 0644);
+   if (IS_ERR(rfile)) {
+   pr_err("Cannot open the result file %s\n",
+   ctx->rfile_path);
+   return;
+   }
+
+   while (ctx->rbuf_offset) {
+   sz = kernel_write(rfile, ctx->rbuf, ctx->rbuf_offset, );
+   if (sz < 0)
+   break;
+   ctx->rbuf_offset -= sz;
+   }
+   filp_close(rfile, NULL);
+}
+
+/*
+ * Write a data into the result buffer
+ */
+static void damon_write_rbuf(struct damon_ctx *ctx, void *data, ssize_t size)
+{
+   if (!ctx->rbuf_len || !ctx->rbuf || !ctx->rfile_path)
+   return;
+   if (ctx->rbuf_offset + size > ctx->rbuf_len)
+   damon_flush_rbuffer(ctx);
+   if (ctx->rbuf_offset + size > ctx->rbuf_len) {
+   pr_warn("%s: flush failed, or wrong size given(%u, %zu)\n",
+   __func__, ctx->rbuf_offset, size);
+   return;
+   }
+
+   memcpy(>rbuf[ctx->rbuf_offset], data, size);
+   ctx->rbuf_offset += size;
+}
+
+/*
+ * Flush the aggregated monitoring results to the result buffer
+ *
+ * Stores current tracking results to the result buffer and reset 'nr_accesses'
+ * of each region.  The format for the result buffer is as below:
+ *
+ * 
+ *
+ *   task info:   
+ *   region info:   
  */
 static void kdamond_reset_aggregated(struct damon_ctx *c)
 {
struct damon_task *t;
-   struct damon_region *r;
+   struct timespec64 now;
+   unsigned int nr;
+
+   ktime_get_coarse_ts64();
+
+   damon_write_rbuf(c, , sizeof(now));
+   nr = nr_damon_tasks(c);
+   damon_write_rbuf(c, , sizeof(nr));

Re: [PATCH] EDAC-TI: Replace HTTP links with HTTPS ones

2020-07-13 Thread Tero Kristo

On 09/07/2020 20:47, Alexander A. Klimov wrote:

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
   If not .svg:
 For each line:
   If doesn't contain `\bxmlns\b`:
 For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
 If both the HTTP and HTTPS versions
 return 200 OK and serve the same content:
   Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 


Looks fine to me.

Acked-by: Tero Kristo 


---
  Continuing my work started at 93431e0607e5.
  See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
  (Actually letting a shell for loop submit all this stuff for me.)

  If there are any URLs to be removed completely or at least not HTTPSified:
  Just clearly say so and I'll *undo my change*.
  See also: https://lkml.org/lkml/2020/6/27/64

  If there are any valid, but yet not changed URLs:
  See: https://lkml.org/lkml/2020/6/26/837

  If you apply the patch, please let me know.


  drivers/edac/ti_edac.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/edac/ti_edac.c b/drivers/edac/ti_edac.c
index 8be3e89a510e..6e52796a0b41 100644
--- a/drivers/edac/ti_edac.c
+++ b/drivers/edac/ti_edac.c
@@ -1,6 +1,6 @@
  // SPDX-License-Identifier: GPL-2.0
  /*
- * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2017 Texas Instruments Incorporated - https://www.ti.com/
   *
   * Texas Instruments DDR3 ECC error correction and detection driver
   *



--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


[PATCH v18 05/14] mm/damon: Track dynamic monitoring target regions update

2020-07-13 Thread SeongJae Park
From: SeongJae Park 

The monitoring target address range can be dynamically changed.  For
example, virtual memory could be dynamically mapped and unmapped.
Physical memory could be hot-plugged.

As the changes could be quite frequent in some cases, DAMON checks the
dynamic memory mapping changes and applies it to the abstracted target
area only for each of a user-specified time interval, ``regions update
interval``.

Signed-off-by: SeongJae Park 
Reviewed-by: Leonard Foerster 
---
 include/linux/damon.h | 20 +++-
 mm/damon.c| 23 +--
 2 files changed, 36 insertions(+), 7 deletions(-)

diff --git a/include/linux/damon.h b/include/linux/damon.h
index 97ddc74e207f..3c0b92a679e8 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -61,13 +61,16 @@ struct damon_task {
  *
  * @sample_interval:   The time between access samplings.
  * @aggr_interval: The time between monitor results aggregations.
+ * @regions_update_interval:   The time between monitor regions updates.
  * @min_nr_regions:The minimum number of monitoring regions.
  * @max_nr_regions:The maximum number of monitoring regions.
  *
  * For each @sample_interval, DAMON checks whether each region is accessed or
  * not.  It aggregates and keeps the access information (number of accesses to
- * each region) for @aggr_interval time.  All time intervals are in
- * micro-seconds.
+ * each region) for @aggr_interval time.  DAMON also checks whether the target
+ * memory regions need update (e.g., by ``mmap()`` calls from the application,
+ * in case of virtual memory monitoring) and applies the changes for each
+ * @regions_update_interval.  All time intervals are in micro-seconds.
  *
  * @kdamond:   Kernel thread who does the monitoring.
  * @kdamond_stop:  Notifies whether kdamond should stop.
@@ -88,6 +91,7 @@ struct damon_task {
  * @tasks_list:Head of monitoring target tasks (_task) 
list.
  *
  * @init_target_regions:   Constructs initial monitoring target regions.
+ * @update_target_regions: Updates monitoring target regions.
  * @prepare_access_checks: Prepares next access check of target regions.
  * @check_accesses:Checks the access of target regions.
  * @sample_cb: Called for each sampling interval.
@@ -96,11 +100,14 @@ struct damon_task {
  * DAMON can be extended for various address spaces by users.  For this, users
  * can register the target address space dependent low level functions for
  * their usecases via the callback pointers of the context.  The monitoring
- * thread calls @init_target_regions before starting the monitoring, and
+ * thread calls @init_target_regions before starting the monitoring,
+ * @update_target_regions for each @regions_update_interval, and
  * @prepare_access_checks and @check_accesses for each @sample_interval.
  *
  * @init_target_regions should construct proper monitoring target regions and
  * link those to the DAMON context struct.
+ * @update_target_regions should update the monitoring target regions for
+ * current status.
  * @prepare_access_checks should manipulate the monitoring regions to be
  * prepare for the next access check.
  * @check_accesses should check the accesses to each region that made after the
@@ -115,10 +122,12 @@ struct damon_task {
 struct damon_ctx {
unsigned long sample_interval;
unsigned long aggr_interval;
+   unsigned long regions_update_interval;
unsigned long min_nr_regions;
unsigned long max_nr_regions;
 
struct timespec64 last_aggregation;
+   struct timespec64 last_regions_update;
 
struct task_struct *kdamond;
bool kdamond_stop;
@@ -128,6 +137,7 @@ struct damon_ctx {
 
/* callbacks */
void (*init_target_regions)(struct damon_ctx *context);
+   void (*update_target_regions)(struct damon_ctx *context);
void (*prepare_access_checks)(struct damon_ctx *context);
unsigned int (*check_accesses)(struct damon_ctx *context);
void (*sample_cb)(struct damon_ctx *context);
@@ -135,8 +145,8 @@ struct damon_ctx {
 };
 
 int damon_set_pids(struct damon_ctx *ctx, int *pids, ssize_t nr_pids);
-int damon_set_attrs(struct damon_ctx *ctx,
-   unsigned long sample_int, unsigned long aggr_int,
+int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int,
+   unsigned long aggr_int, unsigned long regions_update_int,
unsigned long min_nr_reg, unsigned long max_nr_reg);
 int damon_start(struct damon_ctx *ctx);
 int damon_stop(struct damon_ctx *ctx);
diff --git a/mm/damon.c b/mm/damon.c
index 02bc7542a76f..b844924b9fdb 100644
--- a/mm/damon.c
+++ b/mm/damon.c
@@ -385,6 +385,17 @@ static void kdamond_split_regions(struct damon_ctx *ctx)
last_nr_regions = nr_regions;
 }
 
+/*
+ * Check whether it is time to check and apply the target monitoring regions
+ *
+ * 

[PATCH v18 08/14] mm/damon: Add a tracepoint

2020-07-13 Thread SeongJae Park
From: SeongJae Park 

This commit adds a tracepoint for DAMON.  It traces the monitoring
results of each region for each aggregation interval.  Using this, DAMON
can easily integrated with tracepoints supporting tools such as perf.

Signed-off-by: SeongJae Park 
Reviewed-by: Leonard Foerster 
---
 include/trace/events/damon.h | 43 
 mm/damon.c   |  4 
 2 files changed, 47 insertions(+)
 create mode 100644 include/trace/events/damon.h

diff --git a/include/trace/events/damon.h b/include/trace/events/damon.h
new file mode 100644
index ..40b249a28b30
--- /dev/null
+++ b/include/trace/events/damon.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM damon
+
+#if !defined(_TRACE_DAMON_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_DAMON_H
+
+#include 
+#include 
+#include 
+
+TRACE_EVENT(damon_aggregated,
+
+   TP_PROTO(struct damon_task *t, struct damon_region *r,
+   unsigned int nr_regions),
+
+   TP_ARGS(t, r, nr_regions),
+
+   TP_STRUCT__entry(
+   __field(int, pid)
+   __field(unsigned int, nr_regions)
+   __field(unsigned long, start)
+   __field(unsigned long, end)
+   __field(unsigned int, nr_accesses)
+   ),
+
+   TP_fast_assign(
+   __entry->pid = t->pid;
+   __entry->nr_regions = nr_regions;
+   __entry->start = r->ar.start;
+   __entry->end = r->ar.end;
+   __entry->nr_accesses = r->nr_accesses;
+   ),
+
+   TP_printk("pid=%d nr_regions=%u %lu-%lu: %u", __entry->pid,
+   __entry->nr_regions, __entry->start,
+   __entry->end, __entry->nr_accesses)
+);
+
+#endif /* _TRACE_DAMON_H */
+
+/* This part must be outside protection */
+#include 
diff --git a/mm/damon.c b/mm/damon.c
index 55ecfab64220..00df1a4c3d5c 100644
--- a/mm/damon.c
+++ b/mm/damon.c
@@ -19,6 +19,8 @@
 
 #define pr_fmt(fmt) "damon: " fmt
 
+#define CREATE_TRACE_POINTS
+
 #include 
 #include 
 #include 
@@ -29,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Minimal region size.  Every damon_region is aligned by this. */
 #define MIN_REGION PAGE_SIZE
@@ -791,6 +794,7 @@ static void kdamond_reset_aggregated(struct damon_ctx *c)
damon_write_rbuf(c, >ar.end, sizeof(r->ar.end));
damon_write_rbuf(c, >nr_accesses,
sizeof(r->nr_accesses));
+   trace_damon_aggregated(t, r, nr);
r->nr_accesses = 0;
}
}
-- 
2.17.1



Re: [PATCH v2 5/5] power: supply: core: supply battery soc with decimal form

2020-07-13 Thread Greg KH
On Mon, Jul 13, 2020 at 12:03:40PM +0800, Qiwu Huang wrote:
> From: Qiwu Huang 
> 
> Broadcast battery soc with decimal form.
> soc_decimal is the decimal part of battery soc.
> soc_decimal_rate is update frequency of decimal
> part of battery soc.
> We want to report such as 0.01 to 99.99% to
> user space to improve user experience
> when do very quick charging.
> 
> Signed-off-by: Qiwu Huang 
> ---
>  Documentation/ABI/testing/sysfs-class-power | 20 
>  drivers/power/supply/power_supply_sysfs.c   |  2 ++
>  include/linux/power_supply.h|  2 ++
>  3 files changed, 24 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-power 
> b/Documentation/ABI/testing/sysfs-class-power
> index f4234ba1684a..bcc8ccad8163 100644
> --- a/Documentation/ABI/testing/sysfs-class-power
> +++ b/Documentation/ABI/testing/sysfs-class-power
> @@ -349,6 +349,26 @@ Description:
>   Access: Read
>   Valid values: Represented in microvolts
>  
> +What:/sys/class/power_supply//soc_decimal,
> +Date:Jul 2020
> +Contact: jiangf...@xiaomi.com
> +Description:
> + Broadcast battery soc with decimal form.
> + soc_decimal is the start decimal part of battery soc.
> +
> + Access: Read
> + Valid values: 0 - 100

How can "100" be a valid decimal form here if this is a percent?


> +
> +What:/sys/class/power_supply//soc_decimal_rate,
> +Date:Jul 2020
> +Contact: jiangf...@xiaomi.com
> +Description:
> + Broadcast battery soc with decimal form.
> + soc_decimal_rate is the decimal part of battery soc update 
> freqency.
> +
> + Access: Read
> + Valid values: 0 - 100

I think you need to document this a lot better as I still don't really
understand what this is for or how to use it or report it.

And what does "soc" mean here?

thanks,

greg k-h


[PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces

2020-07-13 Thread SeongJae Park
From: SeongJae Park 

This commit introduces a reference implementation of the address space
specific low level primitives for the virtual address space, so that
users of DAMON can easily monitor the data accesses on virtual address
spaces of specific processes by simply configuring the implementation to
be used by DAMON.

The low level primitives for the fundamental access monitoring are
defined in two parts:
1. Identification of the monitoring target address range for the address
space.
2. Access check of specific address range in the target space.

The reference implementation for the virtual address space provided by
this commit is designed as below.

PTE Accessed-bit Based Access Check
---

The implementation uses PTE Accessed-bit for basic access checks.  That
is, it clears the bit for next sampling target page and checks whether
it set again after one sampling period.  To avoid disturbing other
Accessed bit users such as the reclamation logic, the implementation
adjusts the ``PG_Idle`` and ``PG_Young`` appropriately, as same to the
'Idle Page Tracking'.

VMA-based Target Address Range Construction
---

Only small parts in the super-huge virtual address space of the
processes are mapped to physical memory and accessed.  Thus, tracking
the unmapped address regions is just wasteful.  However, because DAMON
can deal with some level of noise using the adaptive regions adjustment
mechanism, tracking every mapping is not strictly required but could
even incur a high overhead in some cases.  That said, too huge unmapped
areas inside the monitoring target should be removed to not take the
time for the adaptive mechanism.

For the reason, this implementation converts the complex mappings to
three distinct regions that cover every mapped area of the address
space.  Also, the two gaps between the three regions are the two biggest
unmapped areas in the given address space.  The two biggest unmapped
areas would be the gap between the heap and the uppermost mmap()-ed
region, and the gap between the lowermost mmap()-ed region and the stack
in most of the cases.  Because these gaps are exceptionally huge in
usual address spacees, excluding these will be sufficient to make a
reasonable trade-off.  Below shows this in detail::




(small mmap()-ed regions and munmap()-ed regions)




Signed-off-by: SeongJae Park 
Reviewed-by: Leonard Foerster 
---
 include/linux/damon.h |   6 +
 mm/damon.c| 474 ++
 2 files changed, 480 insertions(+)

diff --git a/include/linux/damon.h b/include/linux/damon.h
index 3c0b92a679e8..310d36d123b3 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -144,6 +144,12 @@ struct damon_ctx {
void (*aggregate_cb)(struct damon_ctx *context);
 };
 
+/* Reference callback implementations for virtual memory */
+void kdamond_init_vm_regions(struct damon_ctx *ctx);
+void kdamond_update_vm_regions(struct damon_ctx *ctx);
+void kdamond_prepare_vm_access_checks(struct damon_ctx *ctx);
+unsigned int kdamond_check_vm_accesses(struct damon_ctx *ctx);
+
 int damon_set_pids(struct damon_ctx *ctx, int *pids, ssize_t nr_pids);
 int damon_set_attrs(struct damon_ctx *ctx, unsigned long sample_int,
unsigned long aggr_int, unsigned long regions_update_int,
diff --git a/mm/damon.c b/mm/damon.c
index b844924b9fdb..386780739007 100644
--- a/mm/damon.c
+++ b/mm/damon.c
@@ -9,6 +9,9 @@
  * This file is constructed in below parts.
  *
  * - Functions and macros for DAMON data structures
+ * - Functions for the initial monitoring target regions construction
+ * - Functions for the dynamic monitoring target regions update
+ * - Functions for the access checking of the regions
  * - Functions for DAMON core logics and features
  * - Functions for the DAMON programming interface
  * - Functions for the module loading/unloading
@@ -196,6 +199,477 @@ static unsigned long damon_region_sz_limit(struct 
damon_ctx *ctx)
return sz;
 }
 
+/*
+ * Get the mm_struct of the given task
+ *
+ * Caller _must_ put the mm_struct after use, unless it is NULL.
+ *
+ * Returns the mm_struct of the task on success, NULL on failure
+ */
+static struct mm_struct *damon_get_mm(struct damon_task *t)
+{
+   struct task_struct *task;
+   struct mm_struct *mm;
+
+   task = damon_get_task_struct(t);
+   if (!task)
+   return NULL;
+
+   mm = get_task_mm(task);
+   put_task_struct(task);
+   return mm;
+}
+
+/*
+ * Functions for the initial monitoring target regions construction
+ */
+
+/*
+ * Size-evenly split a region into 'nr_pieces' small regions
+ *
+ * Returns 0 on success, or negative error code otherwise.
+ */
+static int damon_split_region_evenly(struct damon_ctx *ctx,
+   struct damon_region *r, unsigned int nr_pieces)
+{
+   unsigned long sz_orig, sz_piece, orig_end;
+   struct damon_region *n 

[PATCH v18 10/14] tools: Introduce a minimal user-space tool for DAMON

2020-07-13 Thread SeongJae Park
From: SeongJae Park 

This commit imtroduces a shallow wrapper python script,
``/tools/damon/damo`` that provides more convenient interface.  Note
that it is only aimed to be used for minimal reference of the DAMON's
debugfs interfaces and for debugging of the DAMON itself.

Signed-off-by: SeongJae Park 
---
 tools/damon/.gitignore|   1 +
 tools/damon/_damon.py | 129 ++
 tools/damon/_dist.py  |  36 
 tools/damon/_recfile.py   |  23 +++
 tools/damon/bin2txt.py|  67 +++
 tools/damon/damo  |  37 
 tools/damon/heats.py  | 362 ++
 tools/damon/nr_regions.py |  91 ++
 tools/damon/record.py | 106 +++
 tools/damon/report.py |  45 +
 tools/damon/wss.py| 100 +++
 11 files changed, 997 insertions(+)
 create mode 100644 tools/damon/.gitignore
 create mode 100644 tools/damon/_damon.py
 create mode 100644 tools/damon/_dist.py
 create mode 100644 tools/damon/_recfile.py
 create mode 100644 tools/damon/bin2txt.py
 create mode 100755 tools/damon/damo
 create mode 100644 tools/damon/heats.py
 create mode 100644 tools/damon/nr_regions.py
 create mode 100644 tools/damon/record.py
 create mode 100644 tools/damon/report.py
 create mode 100644 tools/damon/wss.py

diff --git a/tools/damon/.gitignore b/tools/damon/.gitignore
new file mode 100644
index ..96403d36ff93
--- /dev/null
+++ b/tools/damon/.gitignore
@@ -0,0 +1 @@
+__pycache__/*
diff --git a/tools/damon/_damon.py b/tools/damon/_damon.py
new file mode 100644
index ..2a08468ad27e
--- /dev/null
+++ b/tools/damon/_damon.py
@@ -0,0 +1,129 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0
+
+"""
+Contains core functions for DAMON debugfs control.
+"""
+
+import os
+import subprocess
+
+debugfs_attrs = None
+debugfs_record = None
+debugfs_pids = None
+debugfs_monitor_on = None
+
+def set_target_pid(pid):
+return subprocess.call('echo %s > %s' % (pid, debugfs_pids), shell=True,
+executable='/bin/bash')
+
+def turn_damon(on_off):
+return subprocess.call("echo %s > %s" % (on_off, debugfs_monitor_on),
+shell=True, executable="/bin/bash")
+
+def is_damon_running():
+with open(debugfs_monitor_on, 'r') as f:
+return f.read().strip() == 'on'
+
+class Attrs:
+sample_interval = None
+aggr_interval = None
+regions_update_interval = None
+min_nr_regions = None
+max_nr_regions = None
+rbuf_len = None
+rfile_path = None
+
+def __init__(self, s, a, r, n, x, l, f):
+self.sample_interval = s
+self.aggr_interval = a
+self.regions_update_interval = r
+self.min_nr_regions = n
+self.max_nr_regions = x
+self.rbuf_len = l
+self.rfile_path = f
+
+def __str__(self):
+return "%s %s %s %s %s %s %s" % (self.sample_interval,
+self.aggr_interval, self.regions_update_interval,
+self.min_nr_regions, self.max_nr_regions, self.rbuf_len,
+self.rfile_path)
+
+def attr_str(self):
+return "%s %s %s %s %s " % (self.sample_interval, self.aggr_interval,
+self.regions_update_interval, self.min_nr_regions,
+self.max_nr_regions)
+
+def record_str(self):
+return '%s %s ' % (self.rbuf_len, self.rfile_path)
+
+def apply(self):
+ret = subprocess.call('echo %s > %s' % (self.attr_str(), 
debugfs_attrs),
+shell=True, executable='/bin/bash')
+if ret:
+return ret
+ret = subprocess.call('echo %s > %s' % (self.record_str(),
+debugfs_record), shell=True, executable='/bin/bash')
+if ret:
+return ret
+
+def current_attrs():
+with open(debugfs_attrs, 'r') as f:
+attrs = f.read().split()
+attrs = [int(x) for x in attrs]
+
+with open(debugfs_record, 'r') as f:
+rattrs = f.read().split()
+attrs.append(int(rattrs[0]))
+attrs.append(rattrs[1])
+
+return Attrs(*attrs)
+
+def chk_update_debugfs(debugfs):
+global debugfs_attrs
+global debugfs_record
+global debugfs_pids
+global debugfs_monitor_on
+
+debugfs_damon = os.path.join(debugfs, 'damon')
+debugfs_attrs = os.path.join(debugfs_damon, 'attrs')
+debugfs_record = os.path.join(debugfs_damon, 'record')
+debugfs_pids = os.path.join(debugfs_damon, 'pids')
+debugfs_monitor_on = os.path.join(debugfs_damon, 'monitor_on')
+
+if not os.path.isdir(debugfs_damon):
+print("damon debugfs dir (%s) not found", debugfs_damon)
+exit(1)
+
+for f in [debugfs_attrs, debugfs_record, debugfs_pids, debugfs_monitor_on]:
+if not os.path.isfile(f):
+print("damon debugfs file (%s) not found" % f)
+exit(1)
+
+def cmd_args_to_attrs(args):
+"Generate attributes with specified arguments"
+sample_interval = args.sample
+aggr_interval = args.aggr
+regions_update_interval = args.updr
+ 

RE: [PATCH] Replace HTTP links with HTTPS ones: Dialog Semiconductor drivers

2020-07-13 Thread Adam Thomson
On 05 July 2020 08:56, Alexander A. Klimov wrote:

> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
>   If both the HTTP and HTTPS versions
>   return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 

Acked-by: Adam Thomson 

> ---
>  Continuing my work started at 93431e0607e5.
> 
>  If there are any URLs to be removed completely or at least not HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See https://lkml.org/lkml/2020/6/26/837
> 
>  Documentation/devicetree/bindings/mfd/da9062.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt
> b/Documentation/devicetree/bindings/mfd/da9062.txt
> index 857af982c88f..bab0d0e66cb3 100644
> --- a/Documentation/devicetree/bindings/mfd/da9062.txt
> +++ b/Documentation/devicetree/bindings/mfd/da9062.txt
> @@ -1,8 +1,8 @@
>  * Dialog DA9062 Power Management Integrated Circuit (PMIC)
> 
>  Product information for the DA9062 and DA9061 devices can be found here:
> -- http://www.dialog-semiconductor.com/products/da9062
> -- http://www.dialog-semiconductor.com/products/da9061
> +- https://www.dialog-semiconductor.com/products/da9062
> +- https://www.dialog-semiconductor.com/products/da9061
> 
>  The DA9062 PMIC consists of:
> 
> --
> 2.27.0



[PATCH v18 09/14] mm/damon: Implement a debugfs interface

2020-07-13 Thread SeongJae Park
From: SeongJae Park 

This commit implements a debugfs interface for DAMON.  It works for the
virtual address spaces monitoring.

DAMON exports four files, ``attrs``, ``pids``, ``record``, and
``monitor_on`` under its debugfs directory, ``/damon/``.

Attributes
--

Users can read and write the ``sampling interval``, ``aggregation
interval``, ``regions update interval``, and min/max number of
monitoring target regions by reading from and writing to the ``attrs``
file.  For example, below commands set those values to 5 ms, 100 ms,
1,000 ms, 10, 1000 and check it again::

# cd /damon
# echo 5000 10 100 10 1000 > attrs
# cat attrs
5000 10 100 10 1000

Target PIDs
---

Users can read and write the pids of current monitoring target processes
by reading from and writing to the ``pids`` file.  For example, below
commands set processes having pids 42 and 4242 as the processes to be
monitored and check it again::

# cd /damon
# echo 42 4242 > pids
# cat pids
42 4242

Note that setting the pids doesn't start the monitoring.

Record
--

DAMON supports direct monitoring result record feature.  The recorded
results are first written to a buffer and flushed to a file in batch.
Users can set the size of the buffer and the path to the result file by
reading from and writing to the ``record`` file.  For example, below
commands set the buffer to be 4 KiB and the result to be saved in
'/damon.data'.

# cd /damon
# echo 4096 /damon.data > pids
# cat record
4096 /damon.data

Turning On/Off
--

You can check current status, start and stop the monitoring by reading
from and writing to the ``monitor_on`` file.  Writing ``on`` to the file
starts DAMON to monitor the target processes with the attributes.
Writing ``off`` to the file stops DAMON.  DAMON also stops if every
target processes is terminated.  Below example commands turn on, off,
and check status of DAMON::

# cd /damon
# echo on > monitor_on
# echo off > monitor_on
# cat monitor_on
off

Please note that you cannot write to the ``attrs`` and ``pids`` files
while the monitoring is turned on.  If you write to the files while
DAMON is running, ``-EINVAL`` will be returned.

Signed-off-by: SeongJae Park 
Reviewed-by: Leonard Foerster 
---
 mm/damon.c | 381 -
 1 file changed, 380 insertions(+), 1 deletion(-)

diff --git a/mm/damon.c b/mm/damon.c
index 00df1a4c3d5c..df05bd821ff8 100644
--- a/mm/damon.c
+++ b/mm/damon.c
@@ -14,6 +14,7 @@
  * - Functions for the access checking of the regions
  * - Functions for DAMON core logics and features
  * - Functions for the DAMON programming interface
+ * - Functions for the DAMON debugfs interface
  * - Functions for the module loading/unloading
  */
 
@@ -22,6 +23,7 @@
 #define CREATE_TRACE_POINTS
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -68,6 +70,20 @@
 /* Get a random number in [l, r) */
 #define damon_rand(l, r) (l + prandom_u32() % (r - l))
 
+/* A monitoring context for debugfs interface users. */
+static struct damon_ctx damon_user_ctx = {
+   .sample_interval = 5 * 1000,
+   .aggr_interval = 100 * 1000,
+   .regions_update_interval = 1000 * 1000,
+   .min_nr_regions = 10,
+   .max_nr_regions = 1000,
+
+   .init_target_regions = kdamond_init_vm_regions,
+   .update_target_regions = kdamond_update_vm_regions,
+   .prepare_access_checks = kdamond_prepare_vm_access_checks,
+   .check_accesses = kdamond_check_vm_accesses,
+};
+
 /*
  * Construct a damon_region struct
  *
@@ -1228,17 +1244,380 @@ int damon_set_attrs(struct damon_ctx *ctx, unsigned 
long sample_int,
return 0;
 }
 
+/*
+ * Functions for the DAMON debugfs interface
+ */
+
+static ssize_t debugfs_monitor_on_read(struct file *file,
+   char __user *buf, size_t count, loff_t *ppos)
+{
+   struct damon_ctx *ctx = _user_ctx;
+   char monitor_on_buf[5];
+   bool monitor_on;
+   int len;
+
+   monitor_on = damon_kdamond_running(ctx);
+   len = snprintf(monitor_on_buf, 5, monitor_on ? "on\n" : "off\n");
+
+   return simple_read_from_buffer(buf, count, ppos, monitor_on_buf, len);
+}
+
+/*
+ * Returns non-empty string on success, negarive error code otherwise.
+ */
+static char *user_input_str(const char __user *buf, size_t count, loff_t *ppos)
+{
+   char *kbuf;
+   ssize_t ret;
+
+   /* We do not accept continuous write */
+   if (*ppos)
+   return ERR_PTR(-EINVAL);
+
+   kbuf = kmalloc(count + 1, GFP_KERNEL);
+   if (!kbuf)
+   return ERR_PTR(-ENOMEM);
+
+   ret = simple_write_to_buffer(kbuf, count + 1, ppos, buf, count);
+   if (ret != count) {
+   kfree(kbuf);
+   return ERR_PTR(-EIO);
+   }
+   kbuf[ret] = '\0';
+
+   return kbuf;
+}
+
+static ssize_t debugfs_monitor_on_write(struct file *file,
+   const 

[PATCH v18 13/14] mm/damon: Add user space selftests

2020-07-13 Thread SeongJae Park
From: SeongJae Park 

This commit adds a simple user space tests for DAMON.  The tests are
using kselftest framework.

Signed-off-by: SeongJae Park 
---
 tools/testing/selftests/damon/Makefile|   7 +
 .../selftests/damon/_chk_dependency.sh|  28 
 tools/testing/selftests/damon/_chk_record.py  | 108 ++
 .../testing/selftests/damon/debugfs_attrs.sh  | 139 ++
 .../testing/selftests/damon/debugfs_record.sh |  50 +++
 5 files changed, 332 insertions(+)
 create mode 100644 tools/testing/selftests/damon/Makefile
 create mode 100644 tools/testing/selftests/damon/_chk_dependency.sh
 create mode 100644 tools/testing/selftests/damon/_chk_record.py
 create mode 100755 tools/testing/selftests/damon/debugfs_attrs.sh
 create mode 100755 tools/testing/selftests/damon/debugfs_record.sh

diff --git a/tools/testing/selftests/damon/Makefile 
b/tools/testing/selftests/damon/Makefile
new file mode 100644
index ..cfd5393a4639
--- /dev/null
+++ b/tools/testing/selftests/damon/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+# Makefile for damon selftests
+
+TEST_FILES = _chk_dependency.sh _chk_record_file.py
+TEST_PROGS = debugfs_attrs.sh debugfs_record.sh
+
+include ../lib.mk
diff --git a/tools/testing/selftests/damon/_chk_dependency.sh 
b/tools/testing/selftests/damon/_chk_dependency.sh
new file mode 100644
index ..814dcadd5e96
--- /dev/null
+++ b/tools/testing/selftests/damon/_chk_dependency.sh
@@ -0,0 +1,28 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# Kselftest framework requirement - SKIP code is 4.
+ksft_skip=4
+
+DBGFS=/sys/kernel/debug/damon
+
+if [ $EUID -ne 0 ];
+then
+   echo "Run as root"
+   exit $ksft_skip
+fi
+
+if [ ! -d $DBGFS ]
+then
+   echo "$DBGFS not found"
+   exit $ksft_skip
+fi
+
+for f in attrs record pids monitor_on
+do
+   if [ ! -f "$DBGFS/$f" ]
+   then
+   echo "$f not found"
+   exit 1
+   fi
+done
diff --git a/tools/testing/selftests/damon/_chk_record.py 
b/tools/testing/selftests/damon/_chk_record.py
new file mode 100644
index ..5cfcf4161404
--- /dev/null
+++ b/tools/testing/selftests/damon/_chk_record.py
@@ -0,0 +1,108 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0
+
+"Check whether the DAMON record file is valid"
+
+import argparse
+import struct
+import sys
+
+fmt_version = 0
+
+def set_fmt_version(f):
+global fmt_version
+
+mark = f.read(16)
+if mark == b'damon_recfmt_ver':
+fmt_version = struct.unpack('i', f.read(4))[0]
+else:
+fmt_version = 0
+f.seek(0)
+return fmt_version
+
+def read_pid(f):
+if fmt_version == 0:
+pid = struct.unpack('L', f.read(8))[0]
+else:
+pid = struct.unpack('i', f.read(4))[0]
+def err_percent(val, expected):
+return abs(val - expected) / expected * 100
+
+def chk_task_info(f):
+pid = read_pid(f)
+nr_regions = struct.unpack('I', f.read(4))[0]
+
+if nr_regions > max_nr_regions:
+print('too many regions: %d > %d' % (nr_regions, max_nr_regions))
+exit(1)
+
+nr_gaps = 0
+eaddr = 0
+for r in range(nr_regions):
+saddr = struct.unpack('L', f.read(8))[0]
+if eaddr and saddr != eaddr:
+nr_gaps += 1
+eaddr = struct.unpack('L', f.read(8))[0]
+nr_accesses = struct.unpack('I', f.read(4))[0]
+
+if saddr >= eaddr:
+print('wrong region [%d,%d)' % (saddr, eaddr))
+exit(1)
+
+max_nr_accesses = aint / sint
+if nr_accesses > max_nr_accesses:
+if err_percent(nr_accesses, max_nr_accesses) > 15:
+print('too high nr_access: expected %d but %d' %
+(max_nr_accesses, nr_accesses))
+exit(1)
+if nr_gaps != 2:
+print('number of gaps are not two but %d' % nr_gaps)
+exit(1)
+
+def parse_time_us(bindat):
+sec = struct.unpack('l', bindat[0:8])[0]
+nsec = struct.unpack('l', bindat[8:16])[0]
+return (sec * 10 + nsec) / 1000
+
+def main():
+global sint
+global aint
+global min_nr
+global max_nr_regions
+
+parser = argparse.ArgumentParser()
+parser.add_argument('file', metavar='',
+help='path to the record file')
+parser.add_argument('--attrs', metavar='',
+default='5000 10 100 10 1000',
+help='content of debugfs attrs file')
+args = parser.parse_args()
+file_path = args.file
+attrs = [int(x) for x in args.attrs.split()]
+sint, aint, rint, min_nr, max_nr_regions = attrs
+
+with open(file_path, 'rb') as f:
+set_fmt_version(f)
+last_aggr_time = None
+while True:
+timebin = f.read(16)
+if len(timebin) != 16:
+break
+
+now = parse_time_us(timebin)
+if not last_aggr_time:
+last_aggr_time = now
+else:
+error 

[PATCH v18 12/14] mm/damon: Add kunit tests

2020-07-13 Thread SeongJae Park
From: SeongJae Park 

This commit adds kunit based unit tests for DAMON.

Signed-off-by: SeongJae Park 
Reviewed-by: Brendan Higgins 
---
 mm/Kconfig  |  11 +
 mm/damon-test.h | 661 
 mm/damon.c  |   6 +
 3 files changed, 678 insertions(+)
 create mode 100644 mm/damon-test.h

diff --git a/mm/Kconfig b/mm/Kconfig
index 464e9594dcec..e32761985611 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -879,4 +879,15 @@ config DAMON
  more information.
  If unsure, say N.
 
+config DAMON_KUNIT_TEST
+   bool "Test for damon"
+   depends on DAMON=y && KUNIT
+   help
+ This builds the DAMON Kunit test suite.
+
+ For more information on KUnit and unit tests in general, please refer
+ to the KUnit documentation.
+
+ If unsure, say N.
+
 endmenu
diff --git a/mm/damon-test.h b/mm/damon-test.h
new file mode 100644
index ..b31c7fe913ca
--- /dev/null
+++ b/mm/damon-test.h
@@ -0,0 +1,661 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Data Access Monitor Unit Tests
+ *
+ * Copyright 2019 Amazon.com, Inc. or its affiliates.  All rights reserved.
+ *
+ * Author: SeongJae Park 
+ */
+
+#ifdef CONFIG_DAMON_KUNIT_TEST
+
+#ifndef _DAMON_TEST_H
+#define _DAMON_TEST_H
+
+#include 
+
+static void damon_test_str_to_pids(struct kunit *test)
+{
+   char *question;
+   int *answers;
+   int expected[] = {12, 35, 46};
+   ssize_t nr_integers = 0, i;
+
+   question = "123";
+   answers = str_to_pids(question, strnlen(question, 128), _integers);
+   KUNIT_EXPECT_EQ(test, (ssize_t)1, nr_integers);
+   KUNIT_EXPECT_EQ(test, 123, answers[0]);
+   kfree(answers);
+
+   question = "123abc";
+   answers = str_to_pids(question, strnlen(question, 128), _integers);
+   KUNIT_EXPECT_EQ(test, (ssize_t)1, nr_integers);
+   KUNIT_EXPECT_EQ(test, 123, answers[0]);
+   kfree(answers);
+
+   question = "a123";
+   answers = str_to_pids(question, strnlen(question, 128), _integers);
+   KUNIT_EXPECT_EQ(test, (ssize_t)0, nr_integers);
+   KUNIT_EXPECT_PTR_EQ(test, answers, (int *)NULL);
+
+   question = "12 35";
+   answers = str_to_pids(question, strnlen(question, 128), _integers);
+   KUNIT_EXPECT_EQ(test, (ssize_t)2, nr_integers);
+   for (i = 0; i < nr_integers; i++)
+   KUNIT_EXPECT_EQ(test, expected[i], answers[i]);
+   kfree(answers);
+
+   question = "12 35 46";
+   answers = str_to_pids(question, strnlen(question, 128), _integers);
+   KUNIT_EXPECT_EQ(test, (ssize_t)3, nr_integers);
+   for (i = 0; i < nr_integers; i++)
+   KUNIT_EXPECT_EQ(test, expected[i], answers[i]);
+   kfree(answers);
+
+   question = "12 35 abc 46";
+   answers = str_to_pids(question, strnlen(question, 128), _integers);
+   KUNIT_EXPECT_EQ(test, (ssize_t)2, nr_integers);
+   for (i = 0; i < 2; i++)
+   KUNIT_EXPECT_EQ(test, expected[i], answers[i]);
+   kfree(answers);
+
+   question = "";
+   answers = str_to_pids(question, strnlen(question, 128), _integers);
+   KUNIT_EXPECT_EQ(test, (ssize_t)0, nr_integers);
+   KUNIT_EXPECT_PTR_EQ(test, (int *)NULL, answers);
+   kfree(answers);
+
+   question = "\n";
+   answers = str_to_pids(question, strnlen(question, 128), _integers);
+   KUNIT_EXPECT_EQ(test, (ssize_t)0, nr_integers);
+   KUNIT_EXPECT_PTR_EQ(test, (int *)NULL, answers);
+   kfree(answers);
+}
+
+static void damon_test_regions(struct kunit *test)
+{
+   struct damon_region *r;
+   struct damon_task *t;
+
+   r = damon_new_region(1, 2);
+   KUNIT_EXPECT_EQ(test, 1ul, r->ar.start);
+   KUNIT_EXPECT_EQ(test, 2ul, r->ar.end);
+   KUNIT_EXPECT_EQ(test, 0u, r->nr_accesses);
+
+   t = damon_new_task(42);
+   KUNIT_EXPECT_EQ(test, 0u, nr_damon_regions(t));
+
+   damon_add_region(r, t);
+   KUNIT_EXPECT_EQ(test, 1u, nr_damon_regions(t));
+
+   damon_del_region(r);
+   KUNIT_EXPECT_EQ(test, 0u, nr_damon_regions(t));
+
+   damon_free_task(t);
+}
+
+static void damon_test_tasks(struct kunit *test)
+{
+   struct damon_ctx *c = _user_ctx;
+   struct damon_task *t;
+
+   t = damon_new_task(42);
+   KUNIT_EXPECT_EQ(test, 42, t->pid);
+   KUNIT_EXPECT_EQ(test, 0u, nr_damon_tasks(c));
+
+   damon_add_task(_user_ctx, t);
+   KUNIT_EXPECT_EQ(test, 1u, nr_damon_tasks(c));
+
+   damon_destroy_task(t);
+   KUNIT_EXPECT_EQ(test, 0u, nr_damon_tasks(c));
+}
+
+static void damon_test_set_pids(struct kunit *test)
+{
+   struct damon_ctx *ctx = _user_ctx;
+   int pids[] = {1, 2, 3};
+   char buf[64];
+
+   damon_set_pids(ctx, pids, 3);
+   damon_sprint_pids(ctx, buf, 64);
+   KUNIT_EXPECT_STREQ(test, (char *)buf, "1 2 3\n");
+
+   damon_set_pids(ctx, NULL, 0);
+   damon_sprint_pids(ctx, buf, 64);
+   KUNIT_EXPECT_STREQ(test, (char *)buf, "\n");
+
+  

[PATCH v18 11/14] Documentation: Add documents for DAMON

2020-07-13 Thread SeongJae Park
From: SeongJae Park 

This commit adds documents for DAMON under
`Documentation/admin-guide/mm/damon/` and `Documentation/vm/damon/`.

Signed-off-by: SeongJae Park 
---
 Documentation/admin-guide/mm/damon/guide.rst | 157 ++
 Documentation/admin-guide/mm/damon/index.rst |  15 +
 Documentation/admin-guide/mm/damon/plans.rst |  29 ++
 Documentation/admin-guide/mm/damon/start.rst |  98 ++
 Documentation/admin-guide/mm/damon/usage.rst | 298 +++
 Documentation/admin-guide/mm/index.rst   |   1 +
 Documentation/vm/damon/api.rst   |  20 ++
 Documentation/vm/damon/eval.rst  | 222 ++
 Documentation/vm/damon/faq.rst   |  59 
 Documentation/vm/damon/index.rst |  32 ++
 Documentation/vm/damon/mechanisms.rst| 165 ++
 Documentation/vm/index.rst   |   1 +
 12 files changed, 1097 insertions(+)
 create mode 100644 Documentation/admin-guide/mm/damon/guide.rst
 create mode 100644 Documentation/admin-guide/mm/damon/index.rst
 create mode 100644 Documentation/admin-guide/mm/damon/plans.rst
 create mode 100644 Documentation/admin-guide/mm/damon/start.rst
 create mode 100644 Documentation/admin-guide/mm/damon/usage.rst
 create mode 100644 Documentation/vm/damon/api.rst
 create mode 100644 Documentation/vm/damon/eval.rst
 create mode 100644 Documentation/vm/damon/faq.rst
 create mode 100644 Documentation/vm/damon/index.rst
 create mode 100644 Documentation/vm/damon/mechanisms.rst

diff --git a/Documentation/admin-guide/mm/damon/guide.rst 
b/Documentation/admin-guide/mm/damon/guide.rst
new file mode 100644
index ..c51fb843efaa
--- /dev/null
+++ b/Documentation/admin-guide/mm/damon/guide.rst
@@ -0,0 +1,157 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+Optimization Guide
+==
+
+This document helps you estimating the amount of benefit that you could get
+from DAMON-based optimizations, and describes how you could achieve it.  You
+are assumed to already read :doc:`start`.
+
+
+Check The Signs
+===
+
+No optimization can provide same extent of benefit to every case.  Therefore
+you should first guess how much improvements you could get using DAMON.  If
+some of below conditions match your situation, you could consider using DAMON.
+
+- *Low IPC and High Cache Miss Ratios.*  Low IPC means most of the CPU time is
+  spent waiting for the completion of time-consuming operations such as memory
+  access, while high cache miss ratios mean the caches don't help it well.
+  DAMON is not for cache level optimization, but DRAM level.  However,
+  improving DRAM management will also help this case by reducing the memory
+  operation latency.
+- *Memory Over-commitment and Unknown Users.*  If you are doing memory
+  overcommitment and you cannot control every user of your system, a memory
+  bank run could happen at any time.  You can estimate when it will happen
+  based on DAMON's monitoring results and act earlier to avoid or deal better
+  with the crisis.
+- *Frequent Memory Pressure.*  Frequent memory pressure means your system has
+  wrong configurations or memory hogs.  DAMON will help you find the right
+  configuration and/or the criminals.
+- *Heterogeneous Memory System.*  If your system is utilizing memory devices
+  that placed between DRAM and traditional hard disks, such as non-volatile
+  memory or fast SSDs, DAMON could help you utilizing the devices more
+  efficiently.
+
+
+Profile
+===
+
+If you found some positive signals, you could start by profiling your workloads
+using DAMON.  Find major workloads on your systems and analyze their data
+access pattern to find something wrong or can be improved.  The DAMON user
+space tool (``damo``) will be useful for this.
+
+We recommend you to start from working set size distribution check using ``damo
+report wss``.  If the distribution is ununiform or quite different from what
+you estimated, you could consider `Memory Configuration`_ optimization.
+
+Then, review the overall access pattern in heatmap form using ``damo report
+heats``.  If it shows a simple pattern consists of a small number of memory
+regions having high contrast of access temperature, you could consider manual
+`Program Modification`_.
+
+If you still want to absorb more benefits, you should develop `Personalized
+DAMON Application`_ for your special case.
+
+You don't need to take only one approach among the above plans, but you could
+use multiple of the above approaches to maximize the benefit.
+
+
+Optimize
+
+
+If the profiling result also says it's worth trying some optimization, you
+could consider below approaches.  Note that some of the below approaches assume
+that your systems are configured with swap devices or other types of auxiliary
+memory so that you don't strictly required to accommodate the whole working set
+in the main memory.  Most of the detailed optimization should be made on your
+concrete 

[PATCH v18 14/14] MAINTAINERS: Update for DAMON

2020-07-13 Thread SeongJae Park
From: SeongJae Park 

This commit updates MAINTAINERS file for DAMON related files.

Signed-off-by: SeongJae Park 
---
 MAINTAINERS | 13 +
 1 file changed, 13 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 50659d76976b..23348005f5bd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4686,6 +4686,19 @@ F:   net/ax25/ax25_out.c
 F: net/ax25/ax25_timer.c
 F: net/ax25/sysctl_net_ax25.c
 
+DATA ACCESS MONITOR
+M: SeongJae Park 
+L: linux...@kvack.org
+S: Maintained
+F: Documentation/admin-guide/mm/damon/*
+F: Documentation/vm/damon/*
+F: include/linux/damon.h
+F: include/trace/events/damon.h
+F: mm/damon-test.h
+F: mm/damon.c
+F: tools/damon/*
+F: tools/testing/selftests/damon/*
+
 DAVICOM FAST ETHERNET (DMFE) NETWORK DRIVER
 L: net...@vger.kernel.org
 S: Orphan
-- 
2.17.1



Re: [PATCH v5 07/13] pwm: add support for sl28cpld PWM controller

2020-07-13 Thread Uwe Kleine-König
Hello Michael,

On Sat, Jul 11, 2020 at 07:28:05PM +0200, Michael Walle wrote:
> Am 2020-07-09 10:50, schrieb Uwe Kleine-König:
> > On Mon, Jul 06, 2020 at 07:53:47PM +0200, Michael Walle wrote:
> > > diff --git a/drivers/pwm/pwm-sl28cpld.c b/drivers/pwm/pwm-sl28cpld.c
> > > new file mode 100644
> > > index ..8ee286b605bf
> > > --- /dev/null
> > > +++ b/drivers/pwm/pwm-sl28cpld.c
> > > @@ -0,0 +1,187 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * sl28cpld PWM driver
> > > + *
> > > + * Copyright 2020 Kontron Europe GmbH
> > > + */
> > 
> > Is there publically available documenation available? If so please add a
> > link here.
> 
> Unfortunately not. But it should be easy enough and I'll describe it
> briefly in the header.

That's fine.

> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +/*
> > > + * PWM timer block registers.
> > > + */
> > > +#define PWM_CTRL 0x00
> > > +#define   PWM_ENABLE BIT(7)
> > > +#define   PWM_MODE_250HZ 0
> > > +#define   PWM_MODE_500HZ 1
> > > +#define   PWM_MODE_1KHZ  2
> > > +#define   PWM_MODE_2KHZ  3
> > > +#define   PWM_MODE_MASK  GENMASK(1, 0)
> > > +#define PWM_CYCLE0x01
> > > +#define   PWM_CYCLE_MAX  0x7f
> > 
> > Please use a less generic prefix for your defines. Also I like having
> > the defines for field names include register name. Something like:
> > 
> > #define PWM_SL28CPLD_CTRL   0x00
> > #define PWM_SL28CPLD_CTRL_ENABLEBIT(7)
> > #define PWM_SL28CPLD_CTRL_MODE_MASK GENMASK(1, 0)
> 
> Ok.
> 
> > #define
> > PWM_SL28CPLD_CTRL_MODE_250HZ
> > FIELD_PREP(PWM_SL28CPLD_CTRL_MODE_MASK,
> > 0)
> 
> Shouldn't we just "#define ..MODE_250HZ 1" use FIELD_PREP inside the code,
> so you can actually use the normalized enumeration values, too?

yeah, looks sane.

> Actually, I'll rename the PWM_MODE to PWM_PRESCALER, because that is
> more accurate.

Whatever suits you and is consistent is fine for me.

> > > +struct sl28cpld_pwm {
> > > + struct pwm_chip pwm_chip;
> > > + struct regmap *regmap;
> > > + u32 offset;
> > > +};
> > > +
> > > +struct sl28cpld_pwm_periods {
> > > + u8 ctrl;
> > > + unsigned long duty_cycle;
> > > +};
> > > +
> > > +struct sl28cpld_pwm_config {
> > > + unsigned long period_ns;
> > > + u8 max_duty_cycle;
> > > +};
> > > +
> > > +static struct sl28cpld_pwm_config sl28cpld_pwm_config[] = {
> > 
> > const ? (Or drop as the values can be easily computed, see below.)
> > 
> > > + [PWM_MODE_250HZ] = { .period_ns = 400, .max_duty_cycle = 0x80 },
> > > + [PWM_MODE_500HZ] = { .period_ns = 200, .max_duty_cycle = 0x40 },
> > > + [PWM_MODE_1KHZ]  = { .period_ns = 100, .max_duty_cycle = 0x20 },
> > > + [PWM_MODE_2KHZ]  = { .period_ns =  50, .max_duty_cycle = 0x10 },
> > > +};
> > > +
> > > +static void sl28cpld_pwm_get_state(struct pwm_chip *chip,
> > > +struct pwm_device *pwm,
> > > +struct pwm_state *state)
> > > +{
> > > + struct sl28cpld_pwm *priv = dev_get_drvdata(chip->dev);
> > > + static struct sl28cpld_pwm_config *config;
> > > + unsigned int reg;
> > > + unsigned int mode;
> > > +
> > > + regmap_read(priv->regmap, priv->offset + PWM_CTRL, );
> > > +
> > > + state->enabled = reg & PWM_ENABLE;
> > 
> > Would it be more consisted to use FIELD_GET here, too?
> 
> I had used FIELD_GET only for bit-fields with more than one bit,
> i.e. no flags. But that is just a matter of taste, I guess. I'd
> prefer to keep the simple "reg & PWM_ENABLE". If you insist on
> the FIELD_GET() I'll change it ;)

I think using FIELD_GET is more consistent, but I won't insist.

> > > + mode = FIELD_GET(PWM_MODE_MASK, reg);
> > > + config = _pwm_config[mode];
> > > + state->period = config->period_ns;
> > 
> > I wonder if this could be done more effectively without the above table.
> > Something like:
> > 
> > state->period = 400 >> mode.
> 
> The reason I introduced a lookup table here was that I need a
> list of the supported modes; I wasn't aware of the rounding.

List of supported modes = [0, 1, 2, 3], isn't it?

> See also below.
> 
> > (with a #define for 400 of course).
> > 
> > > + regmap_read(priv->regmap, priv->offset + PWM_CYCLE, );
> > > + pwm_set_relative_duty_cycle(state, reg, config->max_duty_cycle);
> > 
> > Oh, what a creative idea to use pwm_set_relative_duty_cycle here.
> 
> What is that helper for then? The former versions did the same
> calculations (i.e. DIV_ROUND_CLOSEST_ULL()) just open coded. But
> I guess then it was also rounding the wrong way.

Yes. In my book pwm_set_relative_duty_cycle is for consumers. And if
DIV_ROUND_CLOSEST_ULL is the right thing for them depends on their use
case.

> > Unfortunately it's using the wrong rounding strategy. Please enable
> > PWM_DEBUG which should diagnose these problems 

Re: [fs] 936e92b615: unixbench.score 32.3% improvement

2020-07-13 Thread Shaokun Zhang
Hi maintainers,

This issue is debugged on Huawei Kunpeng 920 which is an ARM64 platform and we 
also do more tests
on x86 platform.
Since Rong has also reported the improvement on x86,it seems necessary for us 
to do it.
Any comments on it?

Thanks,
Shaokun

在 2020/7/8 15:23, kernel test robot 写道:
> Greeting,
> 
> FYI, we noticed a 32.3% improvement of unixbench.score due to commit:
> 
> 
> commit: 936e92b615e212d08eb74951324bef25ba564c34 ("[PATCH RESEND] fs: Move 
> @f_count to different cacheline with @f_mode")
> url: 
> https://github.com/0day-ci/linux/commits/Shaokun-Zhang/fs-Move-f_count-to-different-cacheline-with-f_mode/20200624-163511
> base: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git 
> 5e857ce6eae7ca21b2055cca4885545e29228fe2
> 
> in testcase: unixbench
> on test machine: 192 threads Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz 
> with 192G memory
> with following parameters:
> 
>   runtime: 300s
>   nr_task: 30%
>   test: syscall
>   cpufreq_governor: performance
>   ucode: 0x5002f01
> 
> test-description: UnixBench is the original BYTE UNIX benchmark suite aims to 
> test performance of Unix-like system.
> test-url: https://github.com/kdlucas/byte-unixbench
> 
> 
> 
> 
> 
> Details are as below:
> -->
> 
> 
> To reproduce:
> 
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml  # job file is attached in this email
> bin/lkp run job.yaml
> 
> =
> compiler/cpufreq_governor/kconfig/nr_task/rootfs/runtime/tbox_group/test/testcase/ucode:
>   
> gcc-9/performance/x86_64-rhel-7.6/30%/debian-x86_64-20191114.cgz/300s/lkp-csl-2ap3/syscall/unixbench/0x5002f01
> 
> commit: 
>   5e857ce6ea ("Merge branch 'hch' (maccess patches from Christoph Hellwig)")
>   936e92b615 ("fs: Move @f_count to different cacheline with @f_mode")
> 
> 5e857ce6eae7ca21 936e92b615e212d08eb74951324 
>  --- 
>  %stddev %change %stddev
>  \  |\  
>   2297 ±  2% +32.3%   3038unixbench.score
> 171.74   +34.8% 231.55unixbench.time.user_time
>  1.366e+09   +32.6%  1.812e+09unixbench.workload
>  26472 ±  6%   +1270.0% 362665 ±158%  cpuidle.C1.usage
>   0.25 ±  2%  +0.10.33mpstat.cpu.all.usr%
>   8.32 ± 43%+129.7%  19.12 ± 63%  sched_debug.cpu.clock.stddev
>   8.32 ± 43%+129.7%  19.12 ± 63%  
> sched_debug.cpu.clock_task.stddev
>   2100 ±  2% -15.6%   1772 ±  9%  sched_debug.cpu.nr_switches.min
> 373.34 ±  3% +12.4% 419.48 ±  6%  
> sched_debug.cpu.ttwu_local.stddev
>   2740 ± 12% -72.3% 757.75 ±105%  
> numa-vmstat.node0.nr_inactive_anon
>   3139 ±  8% -69.9% 946.25 ± 97%  numa-vmstat.node0.nr_shmem
>   2740 ± 12% -72.3% 757.75 ±105%  
> numa-vmstat.node0.nr_zone_inactive_anon
> 373.75 ± 51%+443.3%   2030 ± 26%  
> numa-vmstat.node2.nr_inactive_anon
> 496.00 ± 19%+366.1%   2311 ± 29%  numa-vmstat.node2.nr_shmem
> 373.75 ± 51%+443.3%   2030 ± 26%  
> numa-vmstat.node2.nr_zone_inactive_anon
>  13728 ± 13%+148.1%  34056 ± 46%  numa-vmstat.node3.nr_active_anon
>  78558   +11.3%  87431 ±  6%  numa-vmstat.node3.nr_file_pages
>   9939 ±  8% +19.7%  11902 ± 13%  numa-vmstat.node3.nr_shmem
>  13728 ± 13%+148.1%  34056 ± 46%  
> numa-vmstat.node3.nr_zone_active_anon
>  11103 ± 13% -71.2%   3201 ± 99%  numa-meminfo.node0.Inactive
>  10962 ± 12% -72.3%   3032 ±105%  
> numa-meminfo.node0.Inactive(anon)
>   8551 ± 31% -29.4%   6034 ± 18%  numa-meminfo.node0.Mapped
>  12560 ±  8% -69.9%   3786 ± 97%  numa-meminfo.node0.Shmem
>   1596 ± 51%+415.6%   8230 ± 24%  numa-meminfo.node2.Inactive
>   1496 ± 51%+442.8%   8122 ± 26%  
> numa-meminfo.node2.Inactive(anon)
>   1984 ± 19%+366.1%   9248 ± 29%  numa-meminfo.node2.Shmem
>  54929 ± 13%+148.0% 136212 ± 46%  numa-meminfo.node3.Active
>  54929 ± 13%+148.0% 136206 ± 46%  numa-meminfo.node3.Active(anon)
> 314216   +11.3% 349697 ±  6%  numa-meminfo.node3.FilePages
> 747907 ±  2% +15.2% 861672 ±  9%  numa-meminfo.node3.MemUsed
>  39744 ±  8% +19.7%  47580 ± 13%  numa-meminfo.node3.Shmem
>  13.94 ±  6% -13.90.00
> perf-profile.calltrace.cycles-pp.dnotify_flush.filp_close.__x64_sys_close.do_syscall_64.entry_SYSCALL_64_after_hwframe
>   0.00+0.70.66 ±  8%  
> perf-profile.calltrace.cycles-pp.__x64_sys_umask.do_syscall_64.entry_SYSCALL_64_after_hwframe
>  31.64 ±  8%   

Re: [PATCH net-next v1 5/5] net: phy: micrel: ksz886x/ksz8081: add cabletest support

2020-07-13 Thread Oleksij Rempel
On Mon, Jul 13, 2020 at 06:11:30AM +0200, Oleksij Rempel wrote:
> On Sat, Jul 11, 2020 at 08:29:12PM +0200, Andrew Lunn wrote:
> > On Fri, Jul 10, 2020 at 02:08:51PM +0200, Oleksij Rempel wrote:
> > > This patch support for cable test for the ksz886x switches and the
> > > ksz8081 PHY.
> > > 
> > > The patch was tested on a KSZ8873RLL switch with following results:
> > > 
> > > - port 1:
> > >   - cannot detect any distance
> > >   - provides inverted values
> > > (Errata: DS8830A: "LinkMD does not work on Port 1",
> > >  
> > > http://ww1.microchip.com/downloads/en/DeviceDoc/KSZ8873-Errata-DS8830A.pdf)
> > > - Reports "short" on open or ok.
> > > - Reports "ok" on short.
> > > 
> > > - port 2:
> > >   - can detect distance
> > >   - can detect open on each wire of pair A (wire 1 and 2)
> > >   - can detect open only on one wire of pair B (only wire 3)
> > >   - can detect short between wires of a pair (wires 1 + 2 or 3 + 6)
> > >   - short between pairs is detected as open.
> > > For example short between wires 2 + 3 is detected as open.
> > > 
> > > In order to work around the errata for port 1, the ksz8795 switch driver
> > > should be extended to provide proper device tree support for the related
> > > PHY nodes. So we can set a DT property to mark the port 1 as affected by
> > > the errata.
> 
> Hi Andrew,
>  
> > Hi Oleksij
> > 
> > Do the PHY register read/writes pass through the DSA driver for the
> > 8873?  I was wondering if the switch could intercept reads/writes on
> > port1 for KSZ8081_LMD and return EOPNOTSUPP? That would be a more
> > robust solution than DT properties, which are going to get forgotten.
> 
> Yes, it was my first idea as well. But this switch allows direct MDIO
> access to the PHYs and this PHY driver could be used without DSA driver.
> Not sure if we should support both variants?
> 
> Beside, the Port 1 need at least one more quirk. The pause souport is
> announced but is not working. Should we some how clear Puase bit in the PHY 
> and
> tell PHY framework to not use it? What is the best way to do it?

On other hand, if adding this quirks in to switch driver is acceptable
way, i'll be happy with this as well.

Regards,
Oleksij
-- 
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] selftests/livepatch: adopt to newer sysctl error format

2020-07-13 Thread Kamalesh Babulal
On 11/07/20 12:01 am, Joe Lawrence wrote:
> On Fri, Jul 10, 2020 at 05:27:35PM +0200, Petr Mladek wrote:
>> On Fri 2020-07-10 10:40:43, Kamalesh Babulal wrote:
>>> With procfs v3.3.16, the sysctl command doesn't prints the set key and
>>> value on error.  This change breaks livepatch selftest test-ftrace.sh,
>>> that tests the interaction of sysctl ftrace_enabled:
>>>
> 
> Good catch, it looks like it was this procps commit that modified that
> behavior:
> 
>   commit da82fe49b1476d227874905068adb69577e11d96
>   Author: Patrick Steinhardt 
>   Date:   Tue May 29 13:29:03 2018 +0200
>   
>   sysctl: do not report set key in case `close_stream` fails
>   
>   As we're using buffered I/O when writing kernel parameters, write errors
>   may get delayed until we close the `FILE` stream. As we are currently
>   outputting the key that is to be set disregarding the return value of
>   `close_stream`, we may end up in a situation where we report error and
>   success:
>   
>   $ sysctl kernel.printk_ratelimit=100
>   sysctl: setting key "kernel.printk_ratelimit": error code 22
>   kernel.printk_ratelimit = 100
>   
>   Fix the issue by only outputting the updated value in case
>   `close_stream` does not report an error.
>   
>   Signed-off-by: Patrick Steinhardt 
> 
> And I'd agree that echoing the failed new value was confusing to see
> from a user's perspective.
> 
>>>  # selftests: livepatch: test-ftrace.sh
>>>  # TEST: livepatch interaction with ftrace_enabled sysctl ... not ok
>>>  #
>>>  # --- expected
>>>  # +++ result
>>>  # @@ -16,7 +16,7 @@ livepatch: 'test_klp_livepatch': initial
>>>  #  livepatch: 'test_klp_livepatch': starting patching transition
>>>  #  livepatch: 'test_klp_livepatch': completing patching transition
>>>  #  livepatch: 'test_klp_livepatch': patching complete
>>>  # -livepatch: sysctl: setting key "kernel.ftrace_enabled": Device or
>>> resource busy kernel.ftrace_enabled = 0
>>>  # +livepatch: sysctl: setting key "kernel.ftrace_enabled": Device or
>>> resource busy
>>>  #  % echo 0 > /sys/kernel/livepatch/test_klp_livepatch/enabled
>>>  #  livepatch: 'test_klp_livepatch': initializing unpatching transition
>>>  #  livepatch: 'test_klp_livepatch': starting unpatching transition
>>>  #
>>>  # ERROR: livepatch kselftest(s) failed
>>>
>>> on setting sysctl kernel.ftrace_enabled={0,1} value successfully, the
>>> set key and value is displayed.
>>>
>>> This patch fixes it by limiting the output from both the cases to eight
>>> words, that includes the error message or set key and value on failure
>>> and success. The upper bound of eight words is enough to display the
>>> only tracked error message. Also, adjust the check_result string in
>>> test-ftrace.sh to match the expected output.
>>
>> This looks really tricky.
>>
>> I wonder if we could use "sysctl -q" to refuse printing the value
>> even with older versions. The following patch works here with
>> sysctl 3.3.15:

Agree, "sysctl -q" is more robust, I tested it with sysctl v3.3.16 and the test
passes.  Can you please send the patch?

>>
> 
> FWIW, --quiet was added to procps way back in 2004, so it should be safe
> to use... and there's already a bunch of net selftests using it.

a couple of tests is using the "-q" options to set the sysctl values.

> 
>> diff --git a/tools/testing/selftests/livepatch/functions.sh 
>> b/tools/testing/selftests/livepatch/functions.sh
>> index 2aab9791791d..47aa4c762bb4 100644
>> --- a/tools/testing/selftests/livepatch/functions.sh
>> +++ b/tools/testing/selftests/livepatch/functions.sh
>> @@ -64,7 +64,8 @@ function set_dynamic_debug() {
>>  }
>>  
>>  function set_ftrace_enabled() {
>> -result=$(sysctl kernel.ftrace_enabled="$1" 2>&1 | paste --serial 
>> --delimiters=' ')
>> +result=$(sysctl -q kernel.ftrace_enabled="$1" 2>&1 && \
>> + sysctl kernel.ftrace_enabled 2>&1)
>>  echo "livepatch: $result" > /dev/kmsg
>>  }
>>  
>> diff --git a/tools/testing/selftests/livepatch/test-ftrace.sh 
>> b/tools/testing/selftests/livepatch/test-ftrace.sh
>> index e2a76887f40a..aa967c5d0558 100755
>> --- a/tools/testing/selftests/livepatch/test-ftrace.sh
>> +++ b/tools/testing/selftests/livepatch/test-ftrace.sh
>> @@ -53,7 +53,7 @@ livepatch: '$MOD_LIVEPATCH': initializing patching 
>> transition
>>  livepatch: '$MOD_LIVEPATCH': starting patching transition
>>  livepatch: '$MOD_LIVEPATCH': completing patching transition
>>  livepatch: '$MOD_LIVEPATCH': patching complete
>> -livepatch: sysctl: setting key \"kernel.ftrace_enabled\": Device or 
>> resource busy kernel.ftrace_enabled = 0
>> +livepatch: sysctl: setting key \"kernel.ftrace_enabled\": Device or 
>> resource busy
>>  % echo 0 > /sys/kernel/livepatch/$MOD_LIVEPATCH/enabled
>>  livepatch: '$MOD_LIVEPATCH': initializing unpatching transition
>>  livepatch: '$MOD_LIVEPATCH': starting unpatching transition
>>
>>
> 
> I think this 

[PATCH] MIPS: Replace HTTP links with HTTPS ones

2020-07-13 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not just HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 arch/mips/Kconfig   | 4 ++--
 arch/mips/include/asm/war.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 6fee1a133e9d..bdd073a0a67e 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2393,7 +2393,7 @@ config MIPS_MT_SMP
  on cores with the MT ASE and uses the available VPEs to implement
  virtual processors which supports SMP. This is equivalent to the
  Intel Hyperthreading feature. For further information go to
- .
+ .
 
 config MIPS_MT
bool
@@ -2825,7 +2825,7 @@ config SMP
  Y to "Enhanced Real Time Clock Support", below.
 
  See also the SMP-HOWTO available at
- .
+ .
 
  If you don't know what to do here, say N.
 
diff --git a/arch/mips/include/asm/war.h b/arch/mips/include/asm/war.h
index 1eedd596a064..e43f800e662d 100644
--- a/arch/mips/include/asm/war.h
+++ b/arch/mips/include/asm/war.h
@@ -121,7 +121,7 @@
  * operate correctly if the internal data cache refill buffer is empty.
 These
  * CACHE instructions should be separated from any potential data cache miss
  * by a load instruction to an uncached address to empty the response buffer."
- * (Revision 2.0 device errata from IDT available on http://www.idt.com/
+ * (Revision 2.0 device errata from IDT available on https://www.idt.com/
  * in .pdf format.)
  */
 #ifndef R4600_V2_HIT_CACHEOP_WAR
-- 
2.27.0



Re: [RFC PATCH 0/2] PM / devfreq: Add delayed timer for polling

2020-07-13 Thread Lukasz Luba

Hi Willy

On 7/10/20 4:12 PM, Willy Wolff wrote:

Hi Lukasz,

On 2020-07-08-15-25-03, Lukasz Luba wrote:

Hi Willy,

On 7/3/20 1:33 PM, Willy Wolff wrote:

Hi Chanwoo,

I think it doesn't help on the benchmark I suggested that is doing only memory
accesses. With both timer, I have the same timing.

To test the benchmark with these new patches about timer:

git clone https://github.com/wwilly/benchmark.git \
&& cd benchmark \
&& source env.sh \
&& ./bench_build.sh \
&& bash source/scripts/test_dvfs_mem_patched.sh

The benchmark is set by default to run for 1s, but you can increase this by
tweaking the script as:

taskset 8 ./bench_install/bin/microbe_cache 33554431 0 972  
${little_freq}


Also, as I reported the issue, would it be possible to add a
Reported-by: Willy Wolff  ?
Many thanks in advance.


Thank you for your good work and the benchmark. I hope you will continue
to use it and report some issues. I am going to send a follow up patches
for the DMC and I will add your 'Reported-by'. In the tests I can see
the improvements, but it's worth to consult with you if I understand
the new results correctly.



Thanks for that. I will follow on the other patch thread discussion.


I think there is still some area for improvements in the devfreq and you
could find the interesting bits to contribute.


In fact, this benchmark is motivated about part of my PhD research that has just
been accepted at LCTES2020: "Performance Optimization on big.LITTLE 
Architectures:
A Memory-latency Aware Approach" at 
https://dl.acm.org/doi/10.1145/3372799.3394370



Congrats and thank you for the link (I will read it).


Basically, it's about snooping latency with "bad" CPU DVFS choice on big.LITTLE
systems or more generally SMP/AMP architecture. I'm cleaning up my code and will
propose patches as an RFC later. It introduces a new CPU DVFS governor to limit
snooping latency.


This is interesting, please add me on CC in the patch set.

Regards,
Lukasz


Re: [PATCH] regulator: cros-ec: Constify cros_ec_regulator_voltage_ops

2020-07-13 Thread Pi-Hsun Shih
Acked-by: Pi-Hsun Shih 

On Sat, Jul 11, 2020 at 7:44 PM Rikard Falkeborn
 wrote:
>
> It is never modified, so make it const to allow the compiler to put it
> in read-only memory.
>
> Signed-off-by: Rikard Falkeborn 
> ---
>  drivers/regulator/cros-ec-regulator.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/regulator/cros-ec-regulator.c 
> b/drivers/regulator/cros-ec-regulator.c
> index 35f97246bc48..eeed5aac3f32 100644
> --- a/drivers/regulator/cros-ec-regulator.c
> +++ b/drivers/regulator/cros-ec-regulator.c
> @@ -142,7 +142,7 @@ static int cros_ec_regulator_set_voltage(struct 
> regulator_dev *dev, int min_uV,
>sizeof(cmd), NULL, 0);
>  }
>
> -static struct regulator_ops cros_ec_regulator_voltage_ops = {
> +static const struct regulator_ops cros_ec_regulator_voltage_ops = {
> .enable = cros_ec_regulator_enable,
> .disable = cros_ec_regulator_disable,
> .is_enabled = cros_ec_regulator_is_enabled,
> --
> 2.27.0
>


Re: [PATCH] arm64: dts: lx2160a: Increase configuration space size

2020-07-13 Thread Shawn Guo
On Fri, Jul 10, 2020 at 03:21:44PM +0530, Wasim Khan wrote:
> From: Wasim Khan 
> 
> lx2160a rev2 requires 4KB space for type0 and 4KB
> space for type1 iATU window. Increase configuration
> space size to 8KB to have sufficient space for type0
> and type1 window.
> 
> Signed-off-by: Wasim Khan 
> Reviewed-by: Li Yang 
> Acked-by: Hou Zhiqiang 

Applied, thanks.


[PATCH v5 1/2] dt-bindings: phy: Add USB PHY support for Intel LGM SoC

2020-07-13 Thread Ramuthevar,Vadivel MuruganX
From: Ramuthevar Vadivel Murugan 

Add the dt-schema to support USB PHY on Intel LGM SoC

Signed-off-by: Ramuthevar Vadivel Murugan 

Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/phy/intel,lgm-usb-phy.yaml | 53 ++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml 
b/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml
new file mode 100644
index ..0fc76cd23774
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/intel,lgm-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM USB PHY Device Tree Bindings
+
+maintainers:
+  - Vadivel Murugan Ramuthevar 
+
+properties:
+  compatible:
+const: intel,lgm-usb-phy
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  resets:
+items:
+  - description: USB PHY and Host controller reset
+  - description: APB BUS reset
+  - description: General Hardware reset
+
+  reset-names:
+items:
+  - const: phy
+  - const: apb
+  - const: phy31
+
+required:
+  - compatible
+  - clocks
+  - reg
+  - resets
+  - reset-names
+
+additionalProperties: false
+
+examples:
+  - |
+usb_phy: usb_phy@e7e0 {
+compatible = "intel,lgm-usb-phy";
+reg = <0xe7e0 0x1>;
+clocks = < 153>;
+resets = < 0x70 0x24>,
+ < 0x70 0x26>,
+ < 0x70 0x28>;
+reset-names = "phy", "apb", "phy31";
+};
-- 
2.11.0



  1   2   3   4   5   6   7   8   9   10   >