Re: [PATCH v2] scsi: hisi_sas: Fix NULL pointer dereference
On 10/20/18 12:28 AM, Martin K. Petersen wrote: > > Gustavo, > >> There is a NULL pointer dereference in case *slot* happens to >> be NULL at lines 1053 and 1878: >> >> struct hisi_sas_cq *cq = >> &hisi_hba->cq[slot->dlvry_queue]; >> >> Notice that *slot* is being NULL checked at lines 1057 and 1881: >> if (slot), which implies it may be NULL. >> >> Fix this by placing the declaration and definition of variable cq, >> which contains the pointer dereference slot->dlvry_queue, after >> slot has been properly NULL checked. > > Applied to 4.20/scsi-queue, thanks! > Glad to help. :) Thanks -- Gustavo
[PATCH v2] scsi/ata: Use unsigned int for cmd's type in ioctls in scsi_host_template
Clang warns several times in the scsi subsystem (trimmed for brevity):
drivers/scsi/hpsa.c:6209:7: warning: overflow converting case value to
switch condition type (2147762695 to 18446744071562347015) [-Wswitch]
case CCISS_GETBUSTYPES:
^
drivers/scsi/hpsa.c:6208:7: warning: overflow converting case value to
switch condition type (2147762694 to 18446744071562347014) [-Wswitch]
case CCISS_GETHEARTBEAT:
^
The root cause is that the _IOC macro can generate really large numbers,
which don't find into type 'int', which is used for the cmd paremeter in
the ioctls in scsi_host_template. My research into how GCC and Clang are
handling this at a low level didn't prove fruitful. However, looking at
the rest of the kernel tree, all ioctls use an 'unsigned int' for the
cmd parameter, which will fit all of the _IOC values in the scsi/ata
subsystems.
Make that change because none of the ioctls expect to take a negative
value, it brings the ioctls inline with the reset of the kernel, and it
removes ambiguity, which is never good when dealing with compilers.
Link: https://github.com/ClangBuiltLinux/linux/issues/85
Link: https://github.com/ClangBuiltLinux/linux/issues/154
Link: https://github.com/ClangBuiltLinux/linux/issues/157
Signed-off-by: Nathan Chancellor
---
v1 -> 2:
* Fix build breakage in cxlflash driver from forgetting to update
prototype (thanks to 0day for catching it).
drivers/ata/libata-scsi.c | 5 +++--
drivers/scsi/aacraid/aachba.c | 2 +-
drivers/scsi/aacraid/aacraid.h| 4 ++--
drivers/scsi/aacraid/commctrl.c | 2 +-
drivers/scsi/aacraid/linit.c | 6 --
drivers/scsi/cxlflash/common.h| 3 ++-
drivers/scsi/cxlflash/superpipe.c | 12 +---
drivers/scsi/esas2r/esas2r.h | 4 ++--
drivers/scsi/esas2r/esas2r_ioctl.c| 13 ++---
drivers/scsi/esas2r/esas2r_main.c | 2 +-
drivers/scsi/hpsa.c | 15 +--
drivers/scsi/ipr.c| 3 ++-
drivers/scsi/libsas/sas_scsi_host.c | 2 +-
drivers/scsi/scsi_debug.c | 3 ++-
drivers/scsi/smartpqi/smartpqi_init.c | 3 ++-
include/linux/libata.h| 5 +++--
include/scsi/libsas.h | 3 ++-
include/scsi/scsi_host.h | 6 --
18 files changed, 52 insertions(+), 41 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 3d4887d0e84a..6291f1dbf342 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -778,7 +778,7 @@ static int ata_ioc32(struct ata_port *ap)
}
int ata_sas_scsi_ioctl(struct ata_port *ap, struct scsi_device *scsidev,
-int cmd, void __user *arg)
+unsigned int cmd, void __user *arg)
{
unsigned long val;
int rc = -EINVAL;
@@ -829,7 +829,8 @@ int ata_sas_scsi_ioctl(struct ata_port *ap, struct
scsi_device *scsidev,
}
EXPORT_SYMBOL_GPL(ata_sas_scsi_ioctl);
-int ata_scsi_ioctl(struct scsi_device *scsidev, int cmd, void __user *arg)
+int ata_scsi_ioctl(struct scsi_device *scsidev, unsigned int cmd,
+ void __user *arg)
{
return ata_sas_scsi_ioctl(ata_shost_to_port(scsidev->host),
scsidev, cmd, arg);
diff --git a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c
index bd7f352c28f3..a6399fac 100644
--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -3452,7 +3452,7 @@ static int delete_disk(struct aac_dev *dev, void __user
*arg)
}
}
-int aac_dev_ioctl(struct aac_dev *dev, int cmd, void __user *arg)
+int aac_dev_ioctl(struct aac_dev *dev, unsigned int cmd, void __user *arg)
{
switch (cmd) {
case FSACTL_QUERY_DISK:
diff --git a/drivers/scsi/aacraid/aacraid.h b/drivers/scsi/aacraid/aacraid.h
index 39eb415987fc..1965072ab673 100644
--- a/drivers/scsi/aacraid/aacraid.h
+++ b/drivers/scsi/aacraid/aacraid.h
@@ -2705,12 +2705,12 @@ void aac_set_intx_mode(struct aac_dev *dev);
int aac_get_config_status(struct aac_dev *dev, int commit_flag);
int aac_get_containers(struct aac_dev *dev);
int aac_scsi_cmd(struct scsi_cmnd *cmd);
-int aac_dev_ioctl(struct aac_dev *dev, int cmd, void __user *arg);
+int aac_dev_ioctl(struct aac_dev *dev, unsigned int cmd, void __user *arg);
#ifndef shost_to_class
#define shost_to_class(shost) &shost->shost_dev
#endif
ssize_t aac_get_serial_number(struct device *dev, char *buf);
-int aac_do_ioctl(struct aac_dev * dev, int cmd, void __user *arg);
+int aac_do_ioctl(struct aac_dev *dev, unsigned int cmd, void __user *arg);
int aac_rx_init(struct aac_dev *dev);
int aac_rkt_init(struct aac_dev *dev);
int aac_nark_init(struct aac_dev *dev);
diff --git a/drivers/scsi/aacraid/commctrl.c b/drivers/scsi/aacraid/commctrl.c
index 25f6600d6c09..fd8a10871598 100644
--- a/drivers/scsi/aacraid/commctrl.c
+++ b/drivers/scsi/aacraid/commctrl.c
@@ -1061,7 +1061,7 @@ static int aac_s
Re: [PATCH] scsi/ata: Use unsigned int for cmd's type in ioctls in scsi_host_template
Hi Nathan, Thank you for the patch! Yet something to improve: [auto build test ERROR on scsi/for-next] [also build test ERROR on v4.19-rc8 next-20181019] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Nathan-Chancellor/scsi-ata-Use-unsigned-int-for-cmd-s-type-in-ioctls-in-scsi_host_template/20181020-120416 base: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next config: powerpc-allmodconfig (attached as .config) compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=powerpc All errors (new ones prefixed by >>): >> drivers/scsi//cxlflash/main.c:3170:11: error: initialization from >> incompatible pointer type [-Werror=incompatible-pointer-types] .ioctl = cxlflash_ioctl, ^~ drivers/scsi//cxlflash/main.c:3170:11: note: (near initialization for 'driver_template.ioctl') cc1: some warnings being treated as errors -- >> drivers/scsi//cxlflash/superpipe.c:2099:5: error: conflicting types for >> 'cxlflash_ioctl' int cxlflash_ioctl(struct scsi_device *sdev, unsigned int cmd, void __user *arg) ^~ In file included from drivers/scsi//cxlflash/superpipe.c:29:0: drivers/scsi//cxlflash/common.h:337:5: note: previous declaration of 'cxlflash_ioctl' was here int cxlflash_ioctl(struct scsi_device *sdev, int cmd, void __user *arg); ^~ vim +/cxlflash_ioctl +2099 drivers/scsi//cxlflash/superpipe.c 2082 2083 /** 2084 * cxlflash_ioctl() - IOCTL handler for driver 2085 * @sdev: SCSI device associated with LUN. 2086 * @cmd:IOCTL command. 2087 * @arg:Userspace ioctl data structure. 2088 * 2089 * A read/write semaphore is used to implement a 'drain' of currently 2090 * running ioctls. The read semaphore is taken at the beginning of each 2091 * ioctl thread and released upon concluding execution. Additionally the 2092 * semaphore should be released and then reacquired in any ioctl execution 2093 * path which will wait for an event to occur that is outside the scope of 2094 * the ioctl (i.e. an adapter reset). To drain the ioctls currently running, 2095 * a thread simply needs to acquire the write semaphore. 2096 * 2097 * Return: 0 on success, -errno on failure 2098 */ > 2099 int cxlflash_ioctl(struct scsi_device *sdev, unsigned int cmd, void > __user *arg) --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 1/3] scsi: myrs: Fix a logical vs bitwise bug
Dan, > The || was supposed to be |. The original code just sets ->result to 1. Applied to 4.20/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 2/3] scsi: myrs: Fix the processor absent message in processor_show()
Dan, > If both processors are absent then it's supposed to print that, but > instead we print that just the second processor is absent. Applied to 4.20/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 3/3] scsi: myrs: prevent negatives in disable_enclosure_messages_store()
Dan, > We only want the value to be zero or one. > > It's not a big deal, but say we passed set value to INT_MIN, then > disable_enclosure_messages_show() would return that 12 bytes of "buf" > are initialized but actually only 3 are. I think there are tools like > KASAN which will trigger an info leak warning when that happens. s/kstrtoint/kstrtouint/? -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v2] scsi: hisi_sas: Fix NULL pointer dereference
Gustavo, > There is a NULL pointer dereference in case *slot* happens to > be NULL at lines 1053 and 1878: > > struct hisi_sas_cq *cq = > &hisi_hba->cq[slot->dlvry_queue]; > > Notice that *slot* is being NULL checked at lines 1057 and 1881: > if (slot), which implies it may be NULL. > > Fix this by placing the declaration and definition of variable cq, > which contains the pointer dereference slot->dlvry_queue, after > slot has been properly NULL checked. Applied to 4.20/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCHv6 0/3] Deprecate DAC960 driver
Hannes, > No, I haven't, but I should probably do it. Should I fix up the patch > or send an additional one? Additional, please. >> Also, does MODULE_ALIAS do the right thing when a driver is split >> into two distinct modules? >> > Well, it does; half of the time :-) Is this a qualified guess or have you actually tried? > Personally, I don't think there'll be many users around so I've just > added if for completions sake. Yeah, I agree it's less critical than mpt[23]sas. However, I'm sure we'll break something for someone somewhere. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH RESEND] scsi: qla2xxx: I/Os timing out on surprise removal of
Bill, > When doing a surprise removal of an adapter, some in flight I/Os can > get stuck and take a while to complete (they actually timeout and are > retried). We are not handling an early error exit from > qla2xxx_eh_abort properly. This doesn't apply to 4.20/scsi-queue and the surrounding code has changed significantly. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: myrs: fix build failure on 32 bit
James, > For 32 bit versions we have to be careful about divisions of 64 bit > quantities so use do_div() instead of a direct division. This fixes a > warning about _uldivmod being undefined in certain configurations Applied to 4.20/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: 3w-{sas,9xxx}: Use unsigned char for cdb
On Thu, Oct 18, 2018 at 2:55 PM Nathan Chancellor
wrote:
>
> Clang warns a few times:
>
> drivers/scsi/3w-sas.c:386:11: warning: implicit conversion from 'int' to
> 'char' changes value from 128 to -128 [-Wconstant-conversion]
> cdb[4] = TW_ALLOCATION_LENGTH; /* allocation length */
>~ ^~~~
>
> Update cdb's type to unsigned char, which matches the type of the cdb
> member in struct TW_Command_Apache.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/158
> Signed-off-by: Nathan Chancellor
> ---
> drivers/scsi/3w-9xxx.c | 12
> drivers/scsi/3w-sas.c | 8 +---
> 2 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
> index 05293babb031..2d655a97b959 100644
> --- a/drivers/scsi/3w-9xxx.c
> +++ b/drivers/scsi/3w-9xxx.c
> @@ -143,7 +143,9 @@ static int twa_poll_status_gone(TW_Device_Extension
> *tw_dev, u32 flag, int secon
> static int twa_post_command_packet(TW_Device_Extension *tw_dev, int
> request_id, char internal);
> static int twa_reset_device_extension(TW_Device_Extension *tw_dev);
> static int twa_reset_sequence(TW_Device_Extension *tw_dev, int soft_reset);
> -static int twa_scsiop_execute_scsi(TW_Device_Extension *tw_dev, int
> request_id, char *cdb, int use_sg, TW_SG_Entry *sglistarg);
> +static int twa_scsiop_execute_scsi(TW_Device_Extension *tw_dev, int
> request_id,
> + unsigned char *cdb, int use_sg,
> + TW_SG_Entry *sglistarg);
> static void twa_scsiop_execute_scsi_complete(TW_Device_Extension *tw_dev,
> int request_id);
> static char *twa_string_lookup(twa_message_type *table, unsigned int
> aen_code);
>
> @@ -278,7 +280,7 @@ static int twa_aen_complete(TW_Device_Extension *tw_dev,
> int request_id)
> static int twa_aen_drain_queue(TW_Device_Extension *tw_dev, int
> no_check_reset)
> {
> int request_id = 0;
> - char cdb[TW_MAX_CDB_LEN];
> + unsigned char cdb[TW_MAX_CDB_LEN];
> TW_SG_Entry sglist[1];
> int finished = 0, count = 0;
> TW_Command_Full *full_command_packet;
> @@ -423,7 +425,7 @@ static void twa_aen_queue_event(TW_Device_Extension
> *tw_dev, TW_Command_Apache_H
> /* This function will read the aen queue from the isr */
> static int twa_aen_read_queue(TW_Device_Extension *tw_dev, int request_id)
> {
> - char cdb[TW_MAX_CDB_LEN];
> + unsigned char cdb[TW_MAX_CDB_LEN];
> TW_SG_Entry sglist[1];
> TW_Command_Full *full_command_packet;
> int retval = 1;
> @@ -1798,7 +1800,9 @@ static int twa_scsi_queue_lck(struct scsi_cmnd *SCpnt,
> void (*done)(struct scsi_
> static DEF_SCSI_QCMD(twa_scsi_queue)
>
> /* This function hands scsi cdb's to the firmware */
> -static int twa_scsiop_execute_scsi(TW_Device_Extension *tw_dev, int
> request_id, char *cdb, int use_sg, TW_SG_Entry *sglistarg)
> +static int twa_scsiop_execute_scsi(TW_Device_Extension *tw_dev, int
> request_id,
> + unsigned char *cdb, int use_sg,
> + TW_SG_Entry *sglistarg)
> {
> TW_Command_Full *full_command_packet;
> TW_Command_Apache *command_packet;
> diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
> index 266bdac75304..480cf82700e9 100644
> --- a/drivers/scsi/3w-sas.c
> +++ b/drivers/scsi/3w-sas.c
> @@ -287,7 +287,9 @@ static int twl_post_command_packet(TW_Device_Extension
> *tw_dev, int request_id)
> } /* End twl_post_command_packet() */
>
> /* This function hands scsi cdb's to the firmware */
> -static int twl_scsiop_execute_scsi(TW_Device_Extension *tw_dev, int
> request_id, char *cdb, int use_sg, TW_SG_Entry_ISO *sglistarg)
> +static int twl_scsiop_execute_scsi(TW_Device_Extension *tw_dev, int
> request_id,
> + unsigned char *cdb, int use_sg,
> + TW_SG_Entry_ISO *sglistarg)
> {
> TW_Command_Full *full_command_packet;
> TW_Command_Apache *command_packet;
> @@ -372,7 +374,7 @@ static int twl_scsiop_execute_scsi(TW_Device_Extension
> *tw_dev, int request_id,
> /* This function will read the aen queue from the isr */
> static int twl_aen_read_queue(TW_Device_Extension *tw_dev, int request_id)
> {
> - char cdb[TW_MAX_CDB_LEN];
> + unsigned char cdb[TW_MAX_CDB_LEN];
> TW_SG_Entry_ISO sglist[1];
> TW_Command_Full *full_command_packet;
> int retval = 1;
> @@ -554,7 +556,7 @@ static int twl_poll_response(TW_Device_Extension *tw_dev,
> int request_id, int se
> static int twl_aen_drain_queue(TW_Device_Extension *tw_dev, int
> no_check_reset)
> {
> int request_id = 0;
> - char cdb[TW_MAX_CDB_LEN];
> + unsigned char cdb[TW_MAX_CDB_LEN];
> TW_SG_Entry_ISO sglist[1];
> int finished = 0, count = 0;
> TW_Command_Full *full_command_packet;
> --
> 2.19.1
>
Looks ok.
Acked-by: Adam Rad
Re: [PATCH] scsi: 3w-{sas,9xxx}: Use unsigned char for cdb
On Thu, Oct 18, 2018 at 2:55 PM Nathan Chancellor
wrote:
>
> Clang warns a few times:
>
> drivers/scsi/3w-sas.c:386:11: warning: implicit conversion from 'int' to
> 'char' changes value from 128 to -128 [-Wconstant-conversion]
> cdb[4] = TW_ALLOCATION_LENGTH; /* allocation length */
>~ ^~~~
>
> Update cdb's type to unsigned char, which matches the type of the cdb
> member in struct TW_Command_Apache.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/158
> Signed-off-by: Nathan Chancellor
> ---
> drivers/scsi/3w-9xxx.c | 12
> drivers/scsi/3w-sas.c | 8 +---
> 2 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
> index 05293babb031..2d655a97b959 100644
> --- a/drivers/scsi/3w-9xxx.c
> +++ b/drivers/scsi/3w-9xxx.c
> @@ -143,7 +143,9 @@ static int twa_poll_status_gone(TW_Device_Extension
> *tw_dev, u32 flag, int secon
> static int twa_post_command_packet(TW_Device_Extension *tw_dev, int
> request_id, char internal);
> static int twa_reset_device_extension(TW_Device_Extension *tw_dev);
> static int twa_reset_sequence(TW_Device_Extension *tw_dev, int soft_reset);
> -static int twa_scsiop_execute_scsi(TW_Device_Extension *tw_dev, int
> request_id, char *cdb, int use_sg, TW_SG_Entry *sglistarg);
> +static int twa_scsiop_execute_scsi(TW_Device_Extension *tw_dev, int
> request_id,
> + unsigned char *cdb, int use_sg,
> + TW_SG_Entry *sglistarg);
> static void twa_scsiop_execute_scsi_complete(TW_Device_Extension *tw_dev,
> int request_id);
> static char *twa_string_lookup(twa_message_type *table, unsigned int
> aen_code);
>
> @@ -278,7 +280,7 @@ static int twa_aen_complete(TW_Device_Extension *tw_dev,
> int request_id)
> static int twa_aen_drain_queue(TW_Device_Extension *tw_dev, int
> no_check_reset)
> {
> int request_id = 0;
> - char cdb[TW_MAX_CDB_LEN];
> + unsigned char cdb[TW_MAX_CDB_LEN];
> TW_SG_Entry sglist[1];
> int finished = 0, count = 0;
> TW_Command_Full *full_command_packet;
> @@ -423,7 +425,7 @@ static void twa_aen_queue_event(TW_Device_Extension
> *tw_dev, TW_Command_Apache_H
> /* This function will read the aen queue from the isr */
> static int twa_aen_read_queue(TW_Device_Extension *tw_dev, int request_id)
> {
> - char cdb[TW_MAX_CDB_LEN];
> + unsigned char cdb[TW_MAX_CDB_LEN];
> TW_SG_Entry sglist[1];
> TW_Command_Full *full_command_packet;
> int retval = 1;
> @@ -1798,7 +1800,9 @@ static int twa_scsi_queue_lck(struct scsi_cmnd *SCpnt,
> void (*done)(struct scsi_
> static DEF_SCSI_QCMD(twa_scsi_queue)
>
> /* This function hands scsi cdb's to the firmware */
> -static int twa_scsiop_execute_scsi(TW_Device_Extension *tw_dev, int
> request_id, char *cdb, int use_sg, TW_SG_Entry *sglistarg)
> +static int twa_scsiop_execute_scsi(TW_Device_Extension *tw_dev, int
> request_id,
> + unsigned char *cdb, int use_sg,
> + TW_SG_Entry *sglistarg)
> {
> TW_Command_Full *full_command_packet;
> TW_Command_Apache *command_packet;
> diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
> index 266bdac75304..480cf82700e9 100644
> --- a/drivers/scsi/3w-sas.c
> +++ b/drivers/scsi/3w-sas.c
> @@ -287,7 +287,9 @@ static int twl_post_command_packet(TW_Device_Extension
> *tw_dev, int request_id)
> } /* End twl_post_command_packet() */
>
> /* This function hands scsi cdb's to the firmware */
> -static int twl_scsiop_execute_scsi(TW_Device_Extension *tw_dev, int
> request_id, char *cdb, int use_sg, TW_SG_Entry_ISO *sglistarg)
> +static int twl_scsiop_execute_scsi(TW_Device_Extension *tw_dev, int
> request_id,
> + unsigned char *cdb, int use_sg,
> + TW_SG_Entry_ISO *sglistarg)
> {
> TW_Command_Full *full_command_packet;
> TW_Command_Apache *command_packet;
> @@ -372,7 +374,7 @@ static int twl_scsiop_execute_scsi(TW_Device_Extension
> *tw_dev, int request_id,
> /* This function will read the aen queue from the isr */
> static int twl_aen_read_queue(TW_Device_Extension *tw_dev, int request_id)
> {
> - char cdb[TW_MAX_CDB_LEN];
> + unsigned char cdb[TW_MAX_CDB_LEN];
> TW_SG_Entry_ISO sglist[1];
> TW_Command_Full *full_command_packet;
> int retval = 1;
> @@ -554,7 +556,7 @@ static int twl_poll_response(TW_Device_Extension *tw_dev,
> int request_id, int se
> static int twl_aen_drain_queue(TW_Device_Extension *tw_dev, int
> no_check_reset)
> {
> int request_id = 0;
> - char cdb[TW_MAX_CDB_LEN];
> + unsigned char cdb[TW_MAX_CDB_LEN];
> TW_SG_Entry_ISO sglist[1];
> int finished = 0, count = 0;
> TW_Command_Full *full_command_packet;
> --
> 2.19.1
>
Looks ok.
Signed-off-by: Ada
Re: [PATCH 5/8] sg: add free list, rework locking
Hi linux-scsi-owner,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on mkp-scsi/for-next]
[also build test ERROR on v4.19-rc8 next-20181019]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/linux-scsi-owner-vger-kernel-org/sg-major-cleanup-remove-max_queue-limit/20181019-183809
base: https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
config: i386-randconfig-i1-201841 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/scsi/sg.o: In function `sg_rq_end_io_usercontext':
>> drivers/scsi/sg.c:1494: undefined reference to `sg_rq_state_str'
>> drivers/scsi/sg.c:1494: undefined reference to `sg_rq_state_str'
vim +1494 drivers/scsi/sg.c
1470
1471 /*
1472 * This user context function is needed to clean up a request that has
been
1473 * interrupted (e.g. by control-C at keyboard). That leads to a request
1474 * being an 'orphan' and will be cleared here unless the 'keep_orphan'
flag
1475 * has been set on the owning file descriptor. In that case the user is
1476 * expected to call read() or ioctl(SG_IORECEIVE) to receive the
response
1477 * and free resources held by the interrupted request.
1478 */
1479 static void
1480 sg_rq_end_io_usercontext(struct work_struct *work)
1481 {
1482 struct sg_request *srp = container_of(work, struct sg_request,
ew.work);
1483 struct sg_fd *sfp;
1484
1485 if (!srp) {
1486 WARN_ONCE("s: srp unexpectedly NULL\n", __func__);
1487 return;
1488 }
1489 sfp = srp->parentfp;
1490 if (!sfp) {
1491 WARN_ONCE(1, "%s: sfp unexpectedly NULL\n", __func__);
1492 return;
1493 }
> 1494 SG_LOG(3, sfp->parentdp, "%s: clean srp=0x%p, rq_state: %s\n",
1495 __func__, srp, sg_rq_state_str(srp->rq_state, true));
1496 sg_finish_scsi_blk_rq(srp);
1497 sg_remove_request(sfp, srp);
1498 kref_put(&sfp->f_ref, sg_remove_sfp);
1499 }
1500
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 5/8] sg: add free list, rework locking
On Fri, 2018-10-19 at 15:55 -0400, Douglas Gilbert wrote:
> On 2018-10-19 11:22 a.m., Bart Van Assche wrote:
> > On Fri, 2018-10-19 at 02:24 -0400, Douglas Gilbert wrote:
> > > static void
> > > -sg_fill_request_table(struct sg_fd *sfp, struct sg_req_info *rinfo)
> > > +sg_fill_request_table(struct sg_fd *sfp, struct sg_req_info *rinfo,
> > > + int max_num)
> > > {
> > > struct sg_request *srp;
> > > int val;
> > > - unsigned int ms;
> > >
> > > val = 0;
> > > - list_for_each_entry(srp, &sfp->rq_list, entry) {
> > > - if (val >= SG_MAX_QUEUE)
> > > - break;
> > > - rinfo[val].req_state = srp->done + 1;
> > > + list_for_each_entry(srp, &sfp->rq_list, rq_entry) {
> > > + if (val >= max_num)
> > > + return;
> >
> > What protects the sfp->rq_list against concurrent changes? It seems to me
> > like all other code that iterates over or modifies that list protects that
> > list with rq_list_lock?
>
> Bart,
> The function is called from sg_ioctl() case SG_GET_REQUEST_TABLE and at the
> call point the read_lock is held on rq_list_lock. Maybe I can add a comment
> above the function about the lock being held. [At least it is as the end
> of the patch series, and that is all I care about :-)]
Hi Doug,
Thanks for the clarification. How about adding a __must_hold() annotation?
Bart.
[bug report] scsi: myrb: Add Mylex RAID controller (block interface)
Hello Hannes Reinecke,
The patch 081ff398c56c: "scsi: myrb: Add Mylex RAID controller (block
interface)" from Oct 17, 2018, leads to the following static checker
warning:
drivers/scsi/myrb.c:1614 myrb_ldev_queuecommand()
warn: assigning signed to unsigned: 'mbox->type5.sg_count = nsge'
'(-12),0,2-s32max'
drivers/scsi/myrb.c
1579 if (scmd->sc_data_direction == DMA_NONE)
1580 goto submit;
1581 nsge = scsi_dma_map(scmd);
^
nsge can be -ENOMEM;
1582 if (nsge == 1) {
1583 sgl = scsi_sglist(scmd);
1584 if (scmd->sc_data_direction == DMA_FROM_DEVICE)
1585 mbox->type5.opcode = MYRB_CMD_READ;
1586 else
1587 mbox->type5.opcode = MYRB_CMD_WRITE;
1588
1589 mbox->type5.ld.xfer_len = block_cnt;
1590 mbox->type5.ld.ldev_num = sdev->id;
1591 mbox->type5.lba = lba;
1592 mbox->type5.addr = (u32)sg_dma_address(sgl);
1593 } else {
1594 struct myrb_sge *hw_sgl;
1595 dma_addr_t hw_sgl_addr;
1596 int i;
1597
1598 hw_sgl = dma_pool_alloc(cb->sg_pool, GFP_ATOMIC,
&hw_sgl_addr);
1599 if (!hw_sgl)
1600 return SCSI_MLQUEUE_HOST_BUSY;
1601
1602 cmd_blk->sgl = hw_sgl;
1603 cmd_blk->sgl_addr = hw_sgl_addr;
1604
1605 if (scmd->sc_data_direction == DMA_FROM_DEVICE)
1606 mbox->type5.opcode = MYRB_CMD_READ_SG;
1607 else
1608 mbox->type5.opcode = MYRB_CMD_WRITE_SG;
1609
1610 mbox->type5.ld.xfer_len = block_cnt;
1611 mbox->type5.ld.ldev_num = sdev->id;
1612 mbox->type5.lba = lba;
1613 mbox->type5.addr = hw_sgl_addr;
1614 mbox->type5.sg_count = nsge;
1615
1616 scsi_for_each_sg(scmd, sgl, nsge, i) {
1617 hw_sgl->sge_addr = (u32)sg_dma_address(sgl);
1618 hw_sgl->sge_count = (u32)sg_dma_len(sgl);
1619 hw_sgl++;
1620 }
1621 }
1622 submit:
1623 spin_lock_irqsave(&cb->queue_lock, flags);
regards,
dan carpenter
Re: dma related cleanups for wd719x
On Thursday 18 October 2018 15:01:14 Christoph Hellwig wrote:
> Hi Ondrej,
>
> can you look over this series, which cleans up a few dma-related
> bits in the wd719x driver?
>
This makes it work a bit (can detect drive and read partitions) but it hangs
completely after hdparm -t.
diff --git a/drivers/scsi/wd719x.c b/drivers/scsi/wd719x.c
index d47190f08ed6..55a7a542e653 100644
--- a/drivers/scsi/wd719x.c
+++ b/drivers/scsi/wd719x.c
@@ -183,7 +183,7 @@ static void wd719x_finish_cmd(struct wd719x_scb *scb, int
result)
list_del(&scb->list);
dma_unmap_single(&wd->pdev->dev, scb->phys,
- sizeof(struct wd719x_scb), DMA_TO_DEVICE);
+ sizeof(struct wd719x_scb), DMA_BIDIRECTIONAL);
scsi_dma_unmap(cmd);
dma_unmap_single(&wd->pdev->dev, cmd->SCp.dma_handle,
SCSI_SENSE_BUFFERSIZE, DMA_FROM_DEVICE);
@@ -236,6 +236,12 @@ static int wd719x_queuecommand(struct Scsi_Host *sh,
struct scsi_cmnd *cmd)
if (count_sg) {
struct scatterlist *sg;
+ scb->phys = dma_map_single(&wd->pdev->dev, scb, sizeof(*scb),
+ DMA_BIDIRECTIONAL);
+
+ if (dma_mapping_error(&wd->pdev->dev, scb->phys))
+ goto out_unmap_scsi_cmd;
+
scb->data_length = cpu_to_le32(count_sg *
sizeof(struct wd719x_sglist));
scb->data_p = cpu_to_le32(scb->phys +
@@ -246,11 +252,6 @@ static int wd719x_queuecommand(struct Scsi_Host *sh,
struct scsi_cmnd *cmd)
scb->sg_list[i].length = cpu_to_le32(sg_dma_len(sg));
}
scb->SCB_options |= WD719X_SCB_FLAGS_DO_SCATTER_GATHER;
-
- scb->phys = dma_map_single(&wd->pdev->dev, scb, sizeof(*scb),
- DMA_TO_DEVICE);
- if (dma_mapping_error(&wd->pdev->dev, scb->phys))
- goto out_unmap_scsi_cmd;
} else { /* zero length */
scb->data_length = 0;
scb->data_p = 0;
--
Ondrej Zary
Re: [PATCH 5/8] sg: add free list, rework locking
On 2018-10-19 11:22 a.m., Bart Van Assche wrote:
On Fri, 2018-10-19 at 02:24 -0400, Douglas Gilbert wrote:
static void
-sg_fill_request_table(struct sg_fd *sfp, struct sg_req_info *rinfo)
+sg_fill_request_table(struct sg_fd *sfp, struct sg_req_info *rinfo,
+ int max_num)
{
struct sg_request *srp;
int val;
- unsigned int ms;
val = 0;
- list_for_each_entry(srp, &sfp->rq_list, entry) {
- if (val >= SG_MAX_QUEUE)
- break;
- rinfo[val].req_state = srp->done + 1;
+ list_for_each_entry(srp, &sfp->rq_list, rq_entry) {
+ if (val >= max_num)
+ return;
What protects the sfp->rq_list against concurrent changes? It seems to me
like all other code that iterates over or modifies that list protects that
list with rq_list_lock?
Bart,
The function is called from sg_ioctl() case SG_GET_REQUEST_TABLE and at the
call point the read_lock is held on rq_list_lock. Maybe I can add a comment
above the function about the lock being held. [At least it is as the end
of the patch series, and that is all I care about :-)]
Doug Gilbert
P.S. Best to look at sg.c after each patch is applied, not the !@#$ing
stupid patches.
Re: [PATCH 3/8] sg: split header, expand and correct descriptions
On 2018-10-19 4:31 a.m., Johannes Thumshirn wrote:
On 19/10/18 08:24, Douglas Gilbert wrote:
+/* Alternate style type names, "..._t" variants preferred */
+typedef struct sg_io_hdr Sg_io_hdr;
+typedef struct sg_io_vec Sg_io_vec;
+typedef struct sg_scsi_id Sg_scsi_id;
+typedef struct sg_req_info Sg_req_info;
There are no _t variants for the above, or am I missing something?
I've expanded the comment to make it clearer I'm referring to the
definitions above in that header ***.
For example: Referring to
typedef struct sg_io_hdr {
... /* the definition of its fields */
} sg_io_hdr_t;
So the suggestion is to prefer sg_io_hdr_t to Sg_io_hdr and if you
are using C rather that C++ (in the user space) and you have very
backward looking conventions then prefer:
struct sg_io_hdr
Is that clearer?
Doug Gilbert
*** If the unified diff doesn't show that, then that is one of the
many weakness of using unified diffs for code reviews. One
of the things I'm trying to clean up is 15 years of
"laparoscopic" patches (and diff and patch are fighting back).
Re: [PATCH 1/5] ips: use lower_32_bits and upper_32_bits instead of reinventing them
On Thu, 2018-10-18 at 15:03 +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> ---
> drivers/scsi/ips.c | 6 +++---
> drivers/scsi/ips.h | 3 ---
> 2 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
> index ee8a1ecd58fd..679321e96a86 100644
> --- a/drivers/scsi/ips.c
> +++ b/drivers/scsi/ips.c
> @@ -1801,13 +1801,13 @@ ips_fill_scb_sg_single(ips_ha_t * ha, dma_addr_t
> busaddr,
> }
> if (IPS_USE_ENH_SGLIST(ha)) {
> scb->sg_list.enh_list[indx].address_lo =
> - cpu_to_le32(pci_dma_lo32(busaddr));
> + cpu_to_le32(lower_32_bits(busaddr));
> scb->sg_list.enh_list[indx].address_hi =
> - cpu_to_le32(pci_dma_hi32(busaddr));
> + cpu_to_le32(upper_32_bits(busaddr));
> scb->sg_list.enh_list[indx].length = cpu_to_le32(e_len);
> } else {
> scb->sg_list.std_list[indx].address =
> - cpu_to_le32(pci_dma_lo32(busaddr));
> + cpu_to_le32(lower_32_bits(busaddr));
> scb->sg_list.std_list[indx].length = cpu_to_le32(e_len);
> }
>
> diff --git a/drivers/scsi/ips.h b/drivers/scsi/ips.h
> index db546171e97f..42c180e3938b 100644
> --- a/drivers/scsi/ips.h
> +++ b/drivers/scsi/ips.h
> @@ -96,9 +96,6 @@
>#define __iomem
> #endif
>
> - #define pci_dma_hi32(a) ((a >> 16) >> 16)
> - #define pci_dma_lo32(a) (a & 0x)
> -
> #if (BITS_PER_LONG > 32) || defined(CONFIG_HIGHMEM64G)
>#define IPS_ENABLE_DMA64(1)
> #else
Reviewed-by: Bart Van Assche
Re: [PATCH 2/8] sg: introduce sg_log macro
On 2018-10-19 3:45 a.m., Johannes Thumshirn wrote:
On 19/10/18 08:24, Douglas Gilbert wrote:
[..]
+/*
+ * Kernel needs to be built with CONFIG_SCSI_LOGGING to see log messages.
+ * 'depth' is a number between 1 (most severe) and 7 (most noisy, most
+ * information). All messages are logged as informational (KERN_INFO). In
+ * the unexpected situation where sdp is NULL the macro reverts to a pr_info
+ * and ignores CONFIG_SCSI_LOGGING and always prints to the log.
+ */
+#define SG_LOG(depth, sdp, fmt, a...) \
+ do {\
+ if (IS_ERR_OR_NULL(sdp)) { \
+ pr_info("sg: sdp=NULL_or_ERR, " fmt, ##a);\
+ } else {\
+ SCSI_LOG_TIMEOUT(depth, sdev_prefix_printk( \
+KERN_INFO, (sdp)->device, \
+(sdp)->disk->disk_name, fmt, \
+##a)); \
+ } \
+ } while (0)
Hi Doug,
have you considered using the kernel's dynamic debug infrastructure instead?
Hi,
I'll follow what the scsi mid-level and the other ULDs do. IOW, no
change. The debug messages they produce are quite helpful (to me, I
use them a lot, and Tony B. has asked for more precision) and well-tuned
to the SCSI subsystem (e.g. telling us what sdp represents in useful
terms).
And they can be compiled out (but not my pr_info above, probably
should be a pr_warn).
Doug Gilbert
Re: [PATCH] scsi/ata: Use unsigned int for cmd's type in ioctls in scsi_host_template
On Fri, 2018-10-19 at 10:57 -0700, Nathan Chancellor wrote: > Clang warns several times in the scsi subsystem (trimmed for brevity): > > drivers/scsi/hpsa.c:6209:7: warning: overflow converting case value to > switch condition type (2147762695 to 18446744071562347015) [-Wswitch] > case CCISS_GETBUSTYPES: > ^ > drivers/scsi/hpsa.c:6208:7: warning: overflow converting case value to > switch condition type (2147762694 to 18446744071562347014) [-Wswitch] > case CCISS_GETHEARTBEAT: > ^ > > The root cause is that the _IOC macro can generate really large numbers, > which don't find into type 'int', which is used for the cmd paremeter in > the ioctls in scsi_host_template. My research into how GCC and Clang are > handling this at a low level didn't prove fruitful. However, looking at > the rest of the kernel tree, all ioctls use an 'unsigned int' for the > cmd parameter, which will fit all of the _IOC values in the scsi/ata > subsystems. > > Make that change because none of the ioctls expect to take a negative > value, it brings the ioctls inline with the reset of the kernel, and it > removes ambiguity, which is never good when dealing with compilers. Reviewed-by: Bart Van Assche
Re: [PATCH] scsi: myrs: fix build failure on 32 bit
On 10/18/18 4:50 PM, James Bottomley wrote:
> For 32 bit versions we have to be careful about divisions of 64 bit
> quantities so use do_div() instead of a direct division. This fixes a
> warning about _uldivmod being undefined in certain configurations
on i386 it was:
ERROR: "__udivdi3" [drivers/scsi/myrs.ko] undefined!
and this patch fixes that build error.
Tested-by: Randy Dunlap # build-tested
thanks.
>
> Fixes: 77266186397c ("scsi: myrs: Add Mylex RAID controller")
> Reported-by: kbuild test robot
> Signed-off-by: James Bottomley
> ---
> drivers/scsi/myrs.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/myrs.c b/drivers/scsi/myrs.c
> index b02ee0b0dd55..a9f9c77e889f 100644
> --- a/drivers/scsi/myrs.c
> +++ b/drivers/scsi/myrs.c
> @@ -1978,7 +1978,8 @@ myrs_get_resync(struct device *dev)
> struct scsi_device *sdev = to_scsi_device(dev);
> struct myrs_hba *cs = shost_priv(sdev->host);
> struct myrs_ldev_info *ldev_info = sdev->hostdata;
> - u8 percent_complete = 0, status;
> + u64 percent_complete = 0;
> + u8 status;
>
> if (sdev->channel < cs->ctlr_info->physchan_present || !ldev_info)
> return;
> @@ -1986,8 +1987,8 @@ myrs_get_resync(struct device *dev)
> unsigned short ldev_num = ldev_info->ldev_num;
>
> status = myrs_get_ldev_info(cs, ldev_num, ldev_info);
> - percent_complete = ldev_info->rbld_lba * 100 /
> - ldev_info->cfg_devsize;
> + percent_complete = ldev_info->rbld_lba * 100;
> + do_div(percent_complete, ldev_info->cfg_devsize);
> }
> raid_set_resync(myrs_raid_template, dev, percent_complete);
> }
>
--
~Randy
[PATCH] scsi: isci: Fix a missing-check bug
In isci_request_oprom(), a for loop is used to find the OEM table by scanning the signature, which has four bytes. In each iteration, the signature is copied from the IO memory region 'oprom + i' to 'oem_sig' through memcpy_fromio(). Then 'oem_sig' is checked to see whether it is ISCI_OEM_SIG. If yes, the OEM table is found. Next, the header of the rom, including the signature, is then copied to 'oem_hdr' through memcpy_fromio(). It is obvious that the signature is copied twice here. Given that the device also has the permission to access the IO memory region, it is possible that a malicious device controlled by an attacker can modify the signature between these two copies. By doing so, the attacker can supply unexpected signatures, which can cause undefined behavior of the kernel and introduce potential security risk. This patch rewrites the signature after the second copy, using the value obtained in the first copy, and thus avoids the above issue. Signed-off-by: Wenwen Wang --- drivers/scsi/isci/probe_roms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/isci/probe_roms.c b/drivers/scsi/isci/probe_roms.c index a2bbe46..bff54f2 100644 --- a/drivers/scsi/isci/probe_roms.c +++ b/drivers/scsi/isci/probe_roms.c @@ -68,6 +68,7 @@ struct isci_orom *isci_request_oprom(struct pci_dev *pdev) size_t copy_len; memcpy_fromio(&oem_hdr, oprom + i, sizeof(oem_hdr)); + memcpy(&oem_hdr.sig, oem_sig, ISCI_OEM_SIG_SIZE); copy_len = min(oem_hdr.len - sizeof(oem_hdr), sizeof(*rom)); -- 2.7.4
Re: [PATCH 6/9] PCI: consolidate PCI config entry in drivers/pci
On Fri, 19 Oct 2018 05:09:49 PDT (-0700), Christoph Hellwig wrote: There is no good reason to duplicate the PCI menu in every architecture. Instead provide a selectable HAVE_PCI symbol that indicates availability of PCI support and the handle the rest in drivers/pci. Note that for powerpc we now select HAVE_PCI globally instead of the convoluted mess of conditional or or non-conditional support per board, similar to what we do e.g. on x86. For alpha PCI is selected for the non-jensen configs as it was the default before, and a lot of code does not compile without PCI enabled. On other architectures with limited PCI support that wasn't as complicated I've left the selection as-is. Signed-off-by: Christoph Hellwig Acked-by: Max Filippov Acked-by: Thomas Gleixner Acked-by: Bjorn Helgaas ... diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index a344980287a5..071952cd4cae 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -39,8 +39,10 @@ config RISCV select SPARSE_IRQ select SYSCTL_EXCEPTION_TRACE select HAVE_ARCH_TRACEHOOK + select HAVE_PCI select MODULES_USE_ELF_RELA if MODULES select THREAD_INFO_IN_TASK + select PCI_MSI if PCI select RISCV_TIMER select GENERIC_IRQ_MULTI_HANDLER select ARCH_HAS_PTE_SPECIAL @@ -216,28 +218,12 @@ source "kernel/Kconfig.hz" endmenu -menu "Bus support" - -config PCI - bool "PCI support" - select PCI_MSI - help - This feature enables support for PCI bus system. If you say Y - here, the kernel will include drivers and infrastructure code - to support PCI bus devices. - - If you don't know what to do here, say Y. - config PCI_DOMAINS def_bool PCI config PCI_DOMAINS_GENERIC def_bool PCI -source "drivers/pci/Kconfig" - -endmenu - menu "Power management options" source kernel/power/Kconfig Reviewed-by: Palmer Dabbelt I'm assuming this will go in via PCI tree of some sort, so I'm not going to touch it any further. Thanks for cleaning this up!
[PATCH] scsi/ata: Use unsigned int for cmd's type in ioctls in scsi_host_template
Clang warns several times in the scsi subsystem (trimmed for brevity):
drivers/scsi/hpsa.c:6209:7: warning: overflow converting case value to
switch condition type (2147762695 to 18446744071562347015) [-Wswitch]
case CCISS_GETBUSTYPES:
^
drivers/scsi/hpsa.c:6208:7: warning: overflow converting case value to
switch condition type (2147762694 to 18446744071562347014) [-Wswitch]
case CCISS_GETHEARTBEAT:
^
The root cause is that the _IOC macro can generate really large numbers,
which don't find into type 'int', which is used for the cmd paremeter in
the ioctls in scsi_host_template. My research into how GCC and Clang are
handling this at a low level didn't prove fruitful. However, looking at
the rest of the kernel tree, all ioctls use an 'unsigned int' for the
cmd parameter, which will fit all of the _IOC values in the scsi/ata
subsystems.
Make that change because none of the ioctls expect to take a negative
value, it brings the ioctls inline with the reset of the kernel, and it
removes ambiguity, which is never good when dealing with compilers.
Link: https://github.com/ClangBuiltLinux/linux/issues/85
Link: https://github.com/ClangBuiltLinux/linux/issues/154
Link: https://github.com/ClangBuiltLinux/linux/issues/157
Signed-off-by: Nathan Chancellor
---
drivers/ata/libata-scsi.c | 5 +++--
drivers/scsi/aacraid/aachba.c | 2 +-
drivers/scsi/aacraid/aacraid.h| 4 ++--
drivers/scsi/aacraid/commctrl.c | 2 +-
drivers/scsi/aacraid/linit.c | 6 --
drivers/scsi/cxlflash/superpipe.c | 12 +---
drivers/scsi/esas2r/esas2r.h | 4 ++--
drivers/scsi/esas2r/esas2r_ioctl.c| 13 ++---
drivers/scsi/esas2r/esas2r_main.c | 2 +-
drivers/scsi/hpsa.c | 15 +--
drivers/scsi/ipr.c| 3 ++-
drivers/scsi/libsas/sas_scsi_host.c | 2 +-
drivers/scsi/scsi_debug.c | 3 ++-
drivers/scsi/smartpqi/smartpqi_init.c | 3 ++-
include/linux/libata.h| 5 +++--
include/scsi/libsas.h | 3 ++-
include/scsi/scsi_host.h | 6 --
17 files changed, 50 insertions(+), 40 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 3d4887d0e84a..6291f1dbf342 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -778,7 +778,7 @@ static int ata_ioc32(struct ata_port *ap)
}
int ata_sas_scsi_ioctl(struct ata_port *ap, struct scsi_device *scsidev,
-int cmd, void __user *arg)
+unsigned int cmd, void __user *arg)
{
unsigned long val;
int rc = -EINVAL;
@@ -829,7 +829,8 @@ int ata_sas_scsi_ioctl(struct ata_port *ap, struct
scsi_device *scsidev,
}
EXPORT_SYMBOL_GPL(ata_sas_scsi_ioctl);
-int ata_scsi_ioctl(struct scsi_device *scsidev, int cmd, void __user *arg)
+int ata_scsi_ioctl(struct scsi_device *scsidev, unsigned int cmd,
+ void __user *arg)
{
return ata_sas_scsi_ioctl(ata_shost_to_port(scsidev->host),
scsidev, cmd, arg);
diff --git a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c
index bd7f352c28f3..a6399fac 100644
--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -3452,7 +3452,7 @@ static int delete_disk(struct aac_dev *dev, void __user
*arg)
}
}
-int aac_dev_ioctl(struct aac_dev *dev, int cmd, void __user *arg)
+int aac_dev_ioctl(struct aac_dev *dev, unsigned int cmd, void __user *arg)
{
switch (cmd) {
case FSACTL_QUERY_DISK:
diff --git a/drivers/scsi/aacraid/aacraid.h b/drivers/scsi/aacraid/aacraid.h
index 39eb415987fc..1965072ab673 100644
--- a/drivers/scsi/aacraid/aacraid.h
+++ b/drivers/scsi/aacraid/aacraid.h
@@ -2705,12 +2705,12 @@ void aac_set_intx_mode(struct aac_dev *dev);
int aac_get_config_status(struct aac_dev *dev, int commit_flag);
int aac_get_containers(struct aac_dev *dev);
int aac_scsi_cmd(struct scsi_cmnd *cmd);
-int aac_dev_ioctl(struct aac_dev *dev, int cmd, void __user *arg);
+int aac_dev_ioctl(struct aac_dev *dev, unsigned int cmd, void __user *arg);
#ifndef shost_to_class
#define shost_to_class(shost) &shost->shost_dev
#endif
ssize_t aac_get_serial_number(struct device *dev, char *buf);
-int aac_do_ioctl(struct aac_dev * dev, int cmd, void __user *arg);
+int aac_do_ioctl(struct aac_dev *dev, unsigned int cmd, void __user *arg);
int aac_rx_init(struct aac_dev *dev);
int aac_rkt_init(struct aac_dev *dev);
int aac_nark_init(struct aac_dev *dev);
diff --git a/drivers/scsi/aacraid/commctrl.c b/drivers/scsi/aacraid/commctrl.c
index 25f6600d6c09..fd8a10871598 100644
--- a/drivers/scsi/aacraid/commctrl.c
+++ b/drivers/scsi/aacraid/commctrl.c
@@ -1061,7 +1061,7 @@ static int aac_send_reset_adapter(struct aac_dev *dev,
void __user *arg)
return retval;
}
-int aac_do_ioctl(struct aac_dev * dev, int cmd, void __user *arg)
+int aac_do_ioctl(s
Re: [PATCH -next] scsi: qedf: remove set but not used variable 'fcport'
On Fri, 2018-10-19 at 12:12 +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/scsi/qedf/qedf_main.c: In function 'qedf_eh_abort':
> drivers/scsi/qedf/qedf_main.c:619:21: warning:
> variable 'fcport' set but not used [-Wunused-but-set-variable]
> struct qedf_rport *fcport;
>
> It never used since introduction in
> commit 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE
> driver framework.")
>
> Signed-off-by: YueHaibing
> ---
> drivers/scsi/qedf/qedf_main.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/scsi/qedf/qedf_main.c
> b/drivers/scsi/qedf/qedf_main.c
> index d5a4f17..04f50a3 100644
> --- a/drivers/scsi/qedf/qedf_main.c
> +++ b/drivers/scsi/qedf/qedf_main.c
> @@ -615,8 +615,6 @@ static u32 qedf_get_login_failures(void *cookie)
> static int qedf_eh_abort(struct scsi_cmnd *sc_cmd)
> {
> struct fc_rport *rport =
> starget_to_rport(scsi_target(sc_cmd->device));
> - struct fc_rport_libfc_priv *rp = rport->dd_data;
> - struct qedf_rport *fcport;
> struct fc_lport *lport;
> struct qedf_ctx *qedf;
> struct qedf_ioreq *io_req;
> @@ -636,8 +634,6 @@ static int qedf_eh_abort(struct scsi_cmnd
> *sc_cmd)
> goto out;
> }
>
> - fcport = (struct qedf_rport *)&rp[1];
> -
> io_req = (struct qedf_ioreq *)sc_cmd->SCp.ptr;
> if (!io_req) {
> QEDF_ERR(&(qedf->dbg_ctx), "io_req is NULL.\n");
>
>
>
Yes, but qedf_eh_host_reset() checks if (fcport == NULL) and
returns FAILED and it's not clear that qedf_eh_abort() shouldn't
do the same thing, consider that qedf_process_cqe() checks
whether io_req->fcport == NULL so it does not seem clear that
the io_req->fcport from sc_cmd->SCp.ptr will always be valid later...
Can someone from Cavium (Chad) comment?
-Ewan
Re: [PATCH 6/8] sg: complete locking changes on ioctl+debug
Hi linux-scsi-owner, Thank you for the patch! Yet something to improve: [auto build test ERROR on mkp-scsi/for-next] [also build test ERROR on v4.19-rc8 next-20181019] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/linux-scsi-owner-vger-kernel-org/sg-major-cleanup-remove-max_queue-limit/20181019-183809 base: https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next config: arm-multi_v5_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=arm All errors (new ones prefixed by >>): >> ERROR: "sg_rq_state_str" [drivers/scsi/sg.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
RE: Looking for some help understanding error handling
> -Original Message- > From: linux-scsi-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of John Garry > Sent: Friday, October 19, 2018 2:19 AM > To: Chris Moore - C33997 ; h...@suse.de; > linux-scsi@vger.kernel.org; Jason Yan > Subject: Re: Looking for some help understanding error handling > > On 05/10/2018 16:51, chris.mo...@microchip.com wrote: > > Thanks Hannes, > > > > After some pointers from Shane Seymour I found that the FC and SRP > > transport layers have a devloss timer, so that when a device > > disappears they hold on to the target information for a time waiting > > to see if it comes back. The SAS transport layer doesn't have that feature. > > > > The options for me then would be to modify scsi_transport_sas.c to > > implement the devloss timeout, or to put that functionality into my LLDD. > > > > I'm willing to put the work into the SAS transport and libsas, but I > > suspect there's not a universal need for it. And since my LLDD is for > > internal use at our company and won't be upstreamed, I'll probably > > just do the work there. If anyone feels that this is a feature that more > people would want then I'll look into doing that. > > Hello, > > This feature sounds interesting for libsas. I however have a question on > feasibility of devloss here (note: I'm not familiar with the > concept/realization > for other standards): if a device is deattached and re-attached, how can we > confirm the same device? For SAS device it's ok as a disk has the WWN, but > what about SATA? > > Thanks, > John Would the serial number work? I haven't worked a lot with SATA drives, but ATA8-ACS says the IDENTIFY DEVICE response must contain a unique serial number. Chris > > > > > Thanks, > > Chris > > > >> -Original Message- > >> From: Hannes Reinecke [mailto:h...@suse.de] > >> Sent: Friday, October 5, 2018 8:01 AM > >> To: Chris Moore - C33997 ; linux- > >> s...@vger.kernel.org > >> Subject: Re: Looking for some help understanding error handling > >> > >> On 10/2/18 11:04 PM, chris.mo...@microchip.com wrote: > >>> I'm working on LLDD for a SAS/SATA host adapter, and trying to > >>> understand > >> how the system handles link loss and recovery. > >>> > >>> Say I have a device that gets recognized and attached as sd > >>> 12:0:4:0, at > >> /dev/sdb. > >>> The drive goes offline temporarily, then comes back online. > >>> When it does, it comes back as sd 12:0:5:0, and maybe /dev/sdb, > >>> maybe > >> /dev/sdc. > >>> > >>> I'm not sure how the Id gets assigned. Since this is the same > >>> drive, is there some way my driver can tell libsas and/or SCSI core > >>> that it's the > >> same drive coming back? > >>> Or is there no way to control that? > >>> > >> Not really. The target device is getting destroyed once the device > >> disconnects, and when it reconnects a new structure is allocated. But > >> as the target number is a simple counter it gets increased up each > allocation. > >> > >>> I looked into /dev/disk/by-id, but that also didn't quite do what I > >>> expected. If I open /dev/disk/by-id/some_identifier, that's a > >>> symlink to, > >> say, /dev/sdb. > >> > >> Yes. > >> > >>> /dev/sdb goes away, comes back as /dev/sdc, but my process doesn't > >>> know that, it still has /dev/disk/by-id/some_identifier opened and > >>> so it will > >> never recover without closing and reopening the file. > >>> > >> Simply don't keep hold of the symlink; once you have opened you'll > >> miss any updates to the symlink itself. > >> So better to open the symlink, check the device, do whatever needs to > >> be done, and _close the symlink_ again. > >> Then you can listen for udev events telling you when a device appears > >> or vanishes. > >> > >> Cheers, > >> > >> Hannes > >> -- > >> Dr. Hannes Reinecke Teamlead Storage & Networking > >> h...@suse.de +49 911 74053 688 > >> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg > >> GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB > >> 21284 (AG Nürnberg) >
Re: [PATCH] bsg: convert to use blk-mq
On Fri, Oct 19, 2018 at 09:50:53AM -0600, Jens Axboe wrote: > On 10/19/18 9:01 AM, Benjamin Block wrote: > > On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote: > >> On 10/17/18 9:55 AM, Benjamin Block wrote: > >>> On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: > Requires a few changes to the FC transport class as well. > > Cc: Johannes Thumshirn > Cc: Benjamin Block > Cc: linux-scsi@vger.kernel.org > Signed-off-by: Jens Axboe > --- > block/bsg-lib.c | 102 +-- > drivers/scsi/scsi_transport_fc.c | 61 ++ > 2 files changed, 91 insertions(+), 72 deletions(-) > > >>> > >>> Hey Jens, > >>> > >>> I haven't had time to look into this in any deep way - but I did plan to > >>> -, but just to see whether it starts and runs some I/O I tried giving it > >>> a spin and came up with nothing (see line 3 and 5): > >> > >> I'm an idiot, can you try this on top? > >> > >> > >> diff --git a/block/bsg-lib.c b/block/bsg-lib.c > >> index 1aa0ed3fc339..95e12b635225 100644 > >> --- a/block/bsg-lib.c > >> +++ b/block/bsg-lib.c > >> @@ -311,7 +311,7 @@ struct request_queue *bsg_setup_queue(struct device > >> *dev, const char *name, > >>int ret = -ENOMEM; > >> > >>set = kzalloc(sizeof(*set), GFP_KERNEL); > >> - if (set) > >> + if (!set) > >>return ERR_PTR(-ENOMEM); > >> > >>set->ops = &bsg_mq_ops; > >> > > > > Well, yes, that would be wrong. But it still doesn't fly (s390x stack > > trace): > > > > [ 36.271953] scsi host0: scsi_eh_0: sleeping > > [ 36.272571] scsi host0: zfcp > > [ 36.298065] WARNING: CPU: 7 PID: 856 at block/blk-settings.c:71 > > blk_queue_rq_timed_out+0x44/0x60 > > [ 36.298315] Modules linked in: zfcp scsi_transport_fc dm_multipath > > [ 36.299015] CPU: 7 PID: 856 Comm: systemd-udevd Tainted: GW > >4.19.0-rc8-bb-next+ #1 > > [ 36.299059] Hardware name: IBM 3906 M03 704 (LPAR) > > [ 36.299101] Krnl PSW : 0704e0018000 00ced494 > > (blk_queue_rq_timed_out+0x44/0x60) > > [ 36.299192]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 > > PM:0 RI:0 EA:3 > > [ 36.299259] Krnl GPRS: 015cee60 > > a0ce0180 0300 > > [ 36.299304]0300 00ced486 > > a5738000 03ff8069eba0 > > [ 36.299349]a11ec6a8 a0ce > > a11ec400 03ff805ee438 > > [ 36.299394]a0ce 03ff805f6b00 > > 00ced486 a28af0b0 > > [ 36.299460] Krnl Code: 00ced486: e310c182ltg > > %r1,384(%r12) > > 00ced48c: a7840004brc > > 8,ced494 > > #00ced490: a7f40001brc > > 15,ced492 > > >00ced494: 4120c150la > > %r2,336(%r12) > > 00ced498: c0e5ffc76290brasl > > %r14,5d99b8 > > 00ced49e: e3b0c1500024stg > > %r11,336(%r12) > > 00ced4a4: ebbff0a4lmg > > %r11,%r15,160(%r15) > > 00ced4aa: 07febcr > > 15,%r14 > > [ 36.299879] Call Trace: > > [ 36.299922] ([] 0xa11ec6a8) > > [ 36.299979] [<03ff805ee3fa>] fc_host_setup+0x622/0x660 > > [scsi_transport_fc] > > [ 36.300029] [<00f0baca>] transport_setup_classdev+0x62/0x70 > > [ 36.300075] [<00f0b592>] > > attribute_container_add_device+0x182/0x1d0 > > [ 36.300163] [<03ff80503cae>] scsi_sysfs_add_host+0x5e/0x100 > > [scsi_mod] > > [ 36.300245] [<03ff804e6d7c>] scsi_add_host_with_dma+0x2dc/0x468 > > [scsi_mod] > > [ 36.300310] [<03ff806835f2>] zfcp_scsi_adapter_register+0x222/0x260 > > [zfcp] > > [ 36.300373] [<03ff8066a49a>] zfcp_adapter_enqueue+0xae2/0xb20 > > [zfcp] > > [ 36.300435] [<03ff8066b436>] zfcp_ccw_set_online+0xb6/0x208 [zfcp] > > [ 36.300482] [<00f8ad14>] ccw_device_set_online+0x41c/0x878 > > [ 36.300527] [<00f8b374>] > > online_store_recog_and_online+0x204/0x230 > > [ 36.300572] [<00f8de20>] online_store+0x290/0x3e8 > > [ 36.300619] [<007842c0>] kernfs_fop_write+0x1b0/0x288 > > [ 36.300663] [<0064217e>] __vfs_write+0xee/0x398 > > [ 36.300705] [<006426b4>] vfs_write+0xec/0x238 > > [ 36.300754] [<00642abe>] ksys_write+0xd6/0x148 > > [ 36.300800] [<0137b668>] system_call+0x2b0/0x2d0 > > [ 36.300843] 5 locks held by systemd-udevd/856: > > [ 36.300882] #0: da3c74e2 (sb_writers#4){.+.+}, at: > > vfs_write+0xd6/0x238 > > [ 36.301053] #1: 2a1f461f (&of->mutex){+.+.}, at: > > kernfs_fop_write+0x258/0x288 > > [ 36.301202] #2: d
Re: [PATCH] bsg: convert to use blk-mq
On 10/19/18 9:01 AM, Benjamin Block wrote: > On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote: >> On 10/17/18 9:55 AM, Benjamin Block wrote: >>> On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: Requires a few changes to the FC transport class as well. Cc: Johannes Thumshirn Cc: Benjamin Block Cc: linux-scsi@vger.kernel.org Signed-off-by: Jens Axboe --- block/bsg-lib.c | 102 +-- drivers/scsi/scsi_transport_fc.c | 61 ++ 2 files changed, 91 insertions(+), 72 deletions(-) >>> >>> Hey Jens, >>> >>> I haven't had time to look into this in any deep way - but I did plan to >>> -, but just to see whether it starts and runs some I/O I tried giving it >>> a spin and came up with nothing (see line 3 and 5): >> >> I'm an idiot, can you try this on top? >> >> >> diff --git a/block/bsg-lib.c b/block/bsg-lib.c >> index 1aa0ed3fc339..95e12b635225 100644 >> --- a/block/bsg-lib.c >> +++ b/block/bsg-lib.c >> @@ -311,7 +311,7 @@ struct request_queue *bsg_setup_queue(struct device >> *dev, const char *name, >> int ret = -ENOMEM; >> >> set = kzalloc(sizeof(*set), GFP_KERNEL); >> -if (set) >> +if (!set) >> return ERR_PTR(-ENOMEM); >> >> set->ops = &bsg_mq_ops; >> > > Well, yes, that would be wrong. But it still doesn't fly (s390x stack > trace): > > [ 36.271953] scsi host0: scsi_eh_0: sleeping > [ 36.272571] scsi host0: zfcp > [ 36.298065] WARNING: CPU: 7 PID: 856 at block/blk-settings.c:71 > blk_queue_rq_timed_out+0x44/0x60 > [ 36.298315] Modules linked in: zfcp scsi_transport_fc dm_multipath > [ 36.299015] CPU: 7 PID: 856 Comm: systemd-udevd Tainted: GW > 4.19.0-rc8-bb-next+ #1 > [ 36.299059] Hardware name: IBM 3906 M03 704 (LPAR) > [ 36.299101] Krnl PSW : 0704e0018000 00ced494 > (blk_queue_rq_timed_out+0x44/0x60) > [ 36.299192]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 > RI:0 EA:3 > [ 36.299259] Krnl GPRS: 015cee60 a0ce0180 > 0300 > [ 36.299304]0300 00ced486 a5738000 > 03ff8069eba0 > [ 36.299349]a11ec6a8 a0ce a11ec400 > 03ff805ee438 > [ 36.299394]a0ce 03ff805f6b00 00ced486 > a28af0b0 > [ 36.299460] Krnl Code: 00ced486: e310c182ltg > %r1,384(%r12) > 00ced48c: a7840004brc > 8,ced494 > #00ced490: a7f40001brc > 15,ced492 > >00ced494: 4120c150la > %r2,336(%r12) > 00ced498: c0e5ffc76290brasl > %r14,5d99b8 > 00ced49e: e3b0c1500024stg > %r11,336(%r12) > 00ced4a4: ebbff0a4lmg > %r11,%r15,160(%r15) > 00ced4aa: 07febcr > 15,%r14 > [ 36.299879] Call Trace: > [ 36.299922] ([] 0xa11ec6a8) > [ 36.299979] [<03ff805ee3fa>] fc_host_setup+0x622/0x660 > [scsi_transport_fc] > [ 36.300029] [<00f0baca>] transport_setup_classdev+0x62/0x70 > [ 36.300075] [<00f0b592>] > attribute_container_add_device+0x182/0x1d0 > [ 36.300163] [<03ff80503cae>] scsi_sysfs_add_host+0x5e/0x100 > [scsi_mod] > [ 36.300245] [<03ff804e6d7c>] scsi_add_host_with_dma+0x2dc/0x468 > [scsi_mod] > [ 36.300310] [<03ff806835f2>] zfcp_scsi_adapter_register+0x222/0x260 > [zfcp] > [ 36.300373] [<03ff8066a49a>] zfcp_adapter_enqueue+0xae2/0xb20 [zfcp] > [ 36.300435] [<03ff8066b436>] zfcp_ccw_set_online+0xb6/0x208 [zfcp] > [ 36.300482] [<00f8ad14>] ccw_device_set_online+0x41c/0x878 > [ 36.300527] [<00f8b374>] > online_store_recog_and_online+0x204/0x230 > [ 36.300572] [<00f8de20>] online_store+0x290/0x3e8 > [ 36.300619] [<007842c0>] kernfs_fop_write+0x1b0/0x288 > [ 36.300663] [<0064217e>] __vfs_write+0xee/0x398 > [ 36.300705] [<006426b4>] vfs_write+0xec/0x238 > [ 36.300754] [<00642abe>] ksys_write+0xd6/0x148 > [ 36.300800] [<0137b668>] system_call+0x2b0/0x2d0 > [ 36.300843] 5 locks held by systemd-udevd/856: > [ 36.300882] #0: da3c74e2 (sb_writers#4){.+.+}, at: > vfs_write+0xd6/0x238 > [ 36.301053] #1: 2a1f461f (&of->mutex){+.+.}, at: > kernfs_fop_write+0x258/0x288 > [ 36.301202] #2: deb28615 (kn->count#52){.+.+}, at: > kernfs_fop_write+0x26e/0x288 > [ 36.301374] #3: 2ddb9663 (&dev->mutex){}, at: > online_store+0x19c/0x3e8 > [ 36.301523] #4: 982b5ed9 (attribute_container_mutex){+.+.}, at: > attribute_container_add_device+0x3
Re: [PATCH 5/8] sg: add free list, rework locking
On Fri, 2018-10-19 at 10:38 -0400, Tony Battersby wrote: > Incidentally, I have been using my own home-grown target-mode SCSI > system for the past 16 years, but now I am starting to look into > switching to SCST. I was just reading about their "SGV cache": > > http://scst.sourceforge.net/scst_pg.html > > It looks like it serves a similar purpose to what you are trying to > accomplish with recycling the indirect I/O buffers between different > requests. Perhaps you can borrow some inspiration from them (or even > some code). Although the current SCST SGV cache implementation is more complicated than necessary, I agree that it would be useful to have such a cache implementation in the Linux kernel. The NVMe target driver and the SCSI target core would also benefit from caching SGV allocations. Bart.
Re: [PATCH 5/8] sg: add free list, rework locking
On Fri, 2018-10-19 at 02:24 -0400, Douglas Gilbert wrote:
> static void
> -sg_fill_request_table(struct sg_fd *sfp, struct sg_req_info *rinfo)
> +sg_fill_request_table(struct sg_fd *sfp, struct sg_req_info *rinfo,
> + int max_num)
> {
> struct sg_request *srp;
> int val;
> - unsigned int ms;
>
> val = 0;
> - list_for_each_entry(srp, &sfp->rq_list, entry) {
> - if (val >= SG_MAX_QUEUE)
> - break;
> - rinfo[val].req_state = srp->done + 1;
> + list_for_each_entry(srp, &sfp->rq_list, rq_entry) {
> + if (val >= max_num)
> + return;
What protects the sfp->rq_list against concurrent changes? It seems to me
like all other code that iterates over or modifies that list protects that
list with rq_list_lock?
Thanks,
Bart.
Re: [PATCH 4/8] sg: expand request states
On Fri, 2018-10-19 at 02:24 -0400, Douglas Gilbert wrote: > +/* Following defines are states of sg_request::rq_state */ > +#define SG_RQ_INACTIVE 0/* request not in use (e.g. on fl) */ > +#define SG_RQ_INFLIGHT 1/* SCSI request issued, no response yet */ > +#define SG_RQ_AWAIT_READ 2 /* response received, awaiting read */ > +#define SG_RQ_DONE_READ 3 /* read is ongoing or done */ > +#define SG_RQ_BUSY 4/* example: reserve request changing size */ Please introduce an enumeration type instead of #defining these constants to allow the compiler to verify assignments to sg_request::rq_state. Thanks, Bart.
Re: [PATCH 5/9] powerpc: PCI_MSI needs PCI
On Fri, Oct 19, 2018 at 02:09:48PM +0200, Christoph Hellwig wrote: > Various powerpc boards select the PCI_MSI config option without selecting > PCI, resulting in potentially not compilable configurations if the by > default enabled PCI option is disabled. Explicitly select PCI to ensure > we always have valid configs. [...] > --- a/arch/powerpc/platforms/44x/Kconfig > +++ b/arch/powerpc/platforms/44x/Kconfig > @@ -24,6 +24,7 @@ config BLUESTONE > default n > select PPC44x_SIMPLE > select APM821xx > + select PCI > select PCI_MSI > select PPC4xx_MSI > select PPC4xx_PCI_EXPRESS > @@ -78,6 +79,7 @@ config KATMAI > select 440SPe > select PCI > select PPC4xx_PCI_EXPRESS > + select PCI > select PCI_MSI This case already had PCI selected a couple of lines above. > select PPC4xx_MSI > help > @@ -219,6 +221,7 @@ config AKEBONO > select SWIOTLB > select 476FPE > select PPC4xx_PCI_EXPRESS > + select PCI > select PCI_MSI > select PPC4xx_HSTA_MSI > select I2C > -- > 2.19.1 >
Re: [PATCH] bsg: convert to use blk-mq
On Wed, Oct 17, 2018 at 10:01:16AM -0600, Jens Axboe wrote: > On 10/17/18 9:55 AM, Benjamin Block wrote: > > On Tue, Oct 16, 2018 at 08:43:01AM -0600, Jens Axboe wrote: > >> Requires a few changes to the FC transport class as well. > >> > >> Cc: Johannes Thumshirn > >> Cc: Benjamin Block > >> Cc: linux-scsi@vger.kernel.org > >> Signed-off-by: Jens Axboe > >> --- > >> block/bsg-lib.c | 102 +-- > >> drivers/scsi/scsi_transport_fc.c | 61 ++ > >> 2 files changed, 91 insertions(+), 72 deletions(-) > >> > > > > Hey Jens, > > > > I haven't had time to look into this in any deep way - but I did plan to > > -, but just to see whether it starts and runs some I/O I tried giving it > > a spin and came up with nothing (see line 3 and 5): > > I'm an idiot, can you try this on top? > > > diff --git a/block/bsg-lib.c b/block/bsg-lib.c > index 1aa0ed3fc339..95e12b635225 100644 > --- a/block/bsg-lib.c > +++ b/block/bsg-lib.c > @@ -311,7 +311,7 @@ struct request_queue *bsg_setup_queue(struct device *dev, > const char *name, > int ret = -ENOMEM; > > set = kzalloc(sizeof(*set), GFP_KERNEL); > - if (set) > + if (!set) > return ERR_PTR(-ENOMEM); > > set->ops = &bsg_mq_ops; > Well, yes, that would be wrong. But it still doesn't fly (s390x stack trace): [ 36.271953] scsi host0: scsi_eh_0: sleeping [ 36.272571] scsi host0: zfcp [ 36.298065] WARNING: CPU: 7 PID: 856 at block/blk-settings.c:71 blk_queue_rq_timed_out+0x44/0x60 [ 36.298315] Modules linked in: zfcp scsi_transport_fc dm_multipath [ 36.299015] CPU: 7 PID: 856 Comm: systemd-udevd Tainted: GW 4.19.0-rc8-bb-next+ #1 [ 36.299059] Hardware name: IBM 3906 M03 704 (LPAR) [ 36.299101] Krnl PSW : 0704e0018000 00ced494 (blk_queue_rq_timed_out+0x44/0x60) [ 36.299192]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 [ 36.299259] Krnl GPRS: 015cee60 a0ce0180 0300 [ 36.299304]0300 00ced486 a5738000 03ff8069eba0 [ 36.299349]a11ec6a8 a0ce a11ec400 03ff805ee438 [ 36.299394]a0ce 03ff805f6b00 00ced486 a28af0b0 [ 36.299460] Krnl Code: 00ced486: e310c182ltg %r1,384(%r12) 00ced48c: a7840004brc 8,ced494 #00ced490: a7f40001brc 15,ced492 >00ced494: 4120c150la %r2,336(%r12) 00ced498: c0e5ffc76290brasl %r14,5d99b8 00ced49e: e3b0c1500024stg %r11,336(%r12) 00ced4a4: ebbff0a4lmg %r11,%r15,160(%r15) 00ced4aa: 07febcr 15,%r14 [ 36.299879] Call Trace: [ 36.299922] ([] 0xa11ec6a8) [ 36.299979] [<03ff805ee3fa>] fc_host_setup+0x622/0x660 [scsi_transport_fc] [ 36.300029] [<00f0baca>] transport_setup_classdev+0x62/0x70 [ 36.300075] [<00f0b592>] attribute_container_add_device+0x182/0x1d0 [ 36.300163] [<03ff80503cae>] scsi_sysfs_add_host+0x5e/0x100 [scsi_mod] [ 36.300245] [<03ff804e6d7c>] scsi_add_host_with_dma+0x2dc/0x468 [scsi_mod] [ 36.300310] [<03ff806835f2>] zfcp_scsi_adapter_register+0x222/0x260 [zfcp] [ 36.300373] [<03ff8066a49a>] zfcp_adapter_enqueue+0xae2/0xb20 [zfcp] [ 36.300435] [<03ff8066b436>] zfcp_ccw_set_online+0xb6/0x208 [zfcp] [ 36.300482] [<00f8ad14>] ccw_device_set_online+0x41c/0x878 [ 36.300527] [<00f8b374>] online_store_recog_and_online+0x204/0x230 [ 36.300572] [<00f8de20>] online_store+0x290/0x3e8 [ 36.300619] [<007842c0>] kernfs_fop_write+0x1b0/0x288 [ 36.300663] [<0064217e>] __vfs_write+0xee/0x398 [ 36.300705] [<006426b4>] vfs_write+0xec/0x238 [ 36.300754] [<00642abe>] ksys_write+0xd6/0x148 [ 36.300800] [<0137b668>] system_call+0x2b0/0x2d0 [ 36.300843] 5 locks held by systemd-udevd/856: [ 36.300882] #0: da3c74e2 (sb_writers#4){.+.+}, at: vfs_write+0xd6/0x238 [ 36.301053] #1: 2a1f461f (&of->mutex){+.+.}, at: kernfs_fop_write+0x258/0x288 [ 36.301202] #2: deb28615 (kn->count#52){.+.+}, at: kernfs_fop_write+0x26e/0x288 [ 36.301374] #3: 2ddb9663 (&dev->mutex){}, at: online_store+0x19c/0x3e8 [ 36.301523] #4: 982b5ed9 (attribute_container_mutex){+.+.}, at: attribute_container_add_device+0x3c/0x1d0 [ 36.301675] Last Breaking-Event-Address: [ 36.301717] [<00ced490>] blk_queue_rq_timed_out+0x40/0x60 [ 36.301758] irq event stamp: 9073 [ 36.301804] hardirqs last enabled at (9081):
Re: [PATCH 5/8] sg: add free list, rework locking
On 10/19/18 2:24 AM, Douglas Gilbert wrote:
> + if (sfp->tot_fd_thresh)
> + sfp->sum_fd_dlens += align_sz;
>
What lock protects sfp->sum_fd_dlens?
> /*
> @@ -2216,38 +2401,85 @@ sg_add_request(struct sg_fd *sfp)
> * data length exceeds rem_sgat_thresh then the data (or sgat) is
> * cleared and the request is appended to the tail of the free list.
> */
> -static int
> +static void
> sg_remove_request(struct sg_fd *sfp, struct sg_request *srp)
> {
> + bool reserve;
> unsigned long iflags;
> - int res = 0;
> + const char *cp = "head";
> + char b[64];
>
> - if (!sfp || !srp || list_empty(&sfp->rq_list))
> - return res;
> + if (WARN_ON(!sfp || !srp))
> + return;
> write_lock_irqsave(&sfp->rq_list_lock, iflags);
> - if (!list_empty(&srp->entry)) {
> - list_del(&srp->entry);
> - srp->parentfp = NULL;
> - res = 1;
> - }
> + spin_lock(&srp->rq_entry_lck);
> + /*
> + * N.B. sg_request object not de-allocated (freed). The contents of
> + * rq_list and rq_free_list lists are de-allocated (freed) when the
> + * owning file descriptor is closed. The free list acts as a LIFO.
> + * This can improve the chance of a cache hit when request is re-used.
> + */
> + reserve = (sfp->reserve_srp == srp);
> + if (reserve || srp->data.dlen <= sfp->rem_sgat_thresh) {
> + list_del(&srp->rq_entry);
> + if (srp->data.dlen > 0)
> + list_add(&srp->free_entry, &sfp->rq_free_list);
> + else {
> + list_add_tail(&srp->free_entry, &sfp->rq_free_list);
> + cp = "tail";
> + }
> + snprintf(b, sizeof(b), "%ssrp=0x%p move to fl %s",
> + (reserve ? "reserve " : ""), srp, cp);
> + } else {
> + srp->rq_state = SG_RQ_BUSY;
> + list_del(&srp->rq_entry);
> + spin_unlock(&srp->rq_entry_lck);
> + write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
> + if (sfp->sum_fd_dlens) {
> + u32 uv = srp->data.dlen;
> +
> + if (uv <= sfp->sum_fd_dlens)
> + sfp->sum_fd_dlens -= uv;
> + else {
> + SG_LOG(2, sfp->parentdp,
> +"%s: logic error this dlen > %s\n",
> +__func__, "sum_fd_dlens");
> + sfp->sum_fd_dlens = 0;
> + }
> + }
> + sg_remove_sgat(srp);
> + /* don't kfree(srp), move clear request to tail of fl */
> + write_lock_irqsave(&sfp->rq_list_lock, iflags);
> + spin_lock(&srp->rq_entry_lck);
> + list_add_tail(&srp->free_entry, &sfp->rq_free_list);
> + snprintf(b, sizeof(b), "clear sgat srp=0x%p move to fl tail",
> + srp);
> + }
>
>
Here again, no lock protecting sfp->sum_fd_dlens.
Incidentally, I have been using my own home-grown target-mode SCSI
system for the past 16 years, but now I am starting to look into
switching to SCST. I was just reading about their "SGV cache":
http://scst.sourceforge.net/scst_pg.html
It looks like it serves a similar purpose to what you are trying to
accomplish with recycling the indirect I/O buffers between different
requests. Perhaps you can borrow some inspiration from them (or even
some code).
Tony Battersby
Cybernetics
Re: -Wswitch Clang warnings in drivers/scsi
On 10/18/18 11:51 PM, Nathan Chancellor wrote: On Mon, Oct 08, 2018 at 11:47:09AM -0700, Bart Van Assche wrote: From the user space header : extern int ioctl (int __fd, unsigned long int __request, ...) __THROW; From the kernel header : long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); long (*compat_ioctl) (struct file *, unsigned int, unsigned long); Why has the second argument been declared as "unsigned long" in the glibc headers and as "unsigned int" in the kernel headers? That's not clear to me. Bart. Hi Bart, Sorry it took me so long to reply, somehow this email got lost in my inbox... Unfortuntely, I am unsure why there is that discrepency between the headers. I tried to do some research but I didn't come up with much. However, I did test changing the type of ioctl/compat_ioctl's cmd parameter to 'unsigned int' and came up with the following diff (rather large so sharing via a gist instead of pasting here): https://gist.github.com/nathanchance/8febc92735f4228574cb0464520f0f6f I'll obviously draft up a proper commit message before formally sending but I can address any major concerns before that happens. I checked every single ioctl for a negative value and there aren't any so I think this change makes sense to fix this warning. Hi Nathan, Since that change makes the SCSI code more consistent with the rest of the Linux kernel, I'm in favor of making that change. Bart.
Re: [PATCH 6/9] PCI: consolidate PCI config entry in drivers/pci
On Fri, Oct 19, 2018 at 9:23 PM Russell King - ARM Linux wrote: > > index a68b34183107..b185794549be 100644 > > --- a/arch/arm/mach-pxa/Kconfig > > +++ b/arch/arm/mach-pxa/Kconfig > > @@ -125,7 +125,7 @@ config MACH_ARMCORE > > bool "CompuLab CM-X255/CM-X270 modules" > > select ARCH_HAS_DMA_SET_COHERENT_MASK if PCI > > select IWMMXT > > - select MIGHT_HAVE_PCI > > + select HAVE_PCI > > select NEED_MACH_IO_H if PCI > > select PXA25x > > select PXA27x > > This is wrong. "MIGHT_HAVE_PCI" is _not_ the same as "HAVE_PCI" - we > have a bunch of platforms that mandatorily have PCI and these select > PCI directly. "MIGHT_HAVE_PCI" controls the _visibility_ of the PCI > menu option, but does not prevent it being selected. Your patch will > cause Kconfig to complain for those which mandatorily have PCI but > do not set HAVE_PCI. Good catch! But, adding a bunch of 'select HAVE_PCI' along with 'select PCI' is ugly. Do you have any suggestion? How about letting CONFIG_ARM to select HAVE_PCI ? -- Best Regards Masahiro Yamada
Re: [PATCH 2/9] arm: remove EISA kconfig option
On Fri, Oct 19, 2018 at 9:10 PM Christoph Hellwig wrote: > > No arm config enables EISA, and arm does not include drivers/eisa/Kconfig > which provides support for things like PCI to EISA bridges, so it is most > likely dead. > > If this is wrong we will be able to resurrect it easily by selecting > HAVE_EISA for the right arm configs after this series. What is your concern? This absolutely looks dead to me. > Suggested-by: Masahiro Yamada > Signed-off-by: Christoph Hellwig > --- > arch/arm/Kconfig | 15 --- > 1 file changed, 15 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index e8cd55a5b04c..e33735ce1c14 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -165,21 +165,6 @@ config HAVE_PROC_CPU > config NO_IOPORT_MAP > bool > > -config EISA > - bool There is no prompt for this symbol. Hence, there is no way for a user to enable this directly. 'select EISA' is the only way to enable it. git grep 'select EISA' gave no hit. So, we can say it is dead. > - ---help--- > - The Extended Industry Standard Architecture (EISA) bus was > - developed as an open alternative to the IBM MicroChannel bus. > - > - The EISA bus provided some of the features of the IBM MicroChannel > - bus while maintaining backward compatibility with cards made for > - the older ISA bus. The EISA bus saw limited use between 1988 and > - 1995 when it was made obsolete by the PCI bus. > - > - Say Y here if you are building a kernel for an EISA-based machine. > - > - Otherwise, say N. > - > config SBUS > bool I guess the situation is the same as powerpc. The difference between arm and powerpc is the presence of help. You fold the powerpc change in 9/9. -- Best Regards Masahiro Yamada
Re: [PATCH 6/9] PCI: consolidate PCI config entry in drivers/pci
On Fri, Oct 19, 2018 at 02:09:49PM +0200, Christoph Hellwig wrote: > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index e33735ce1c14..7495d0a0aa31 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -149,9 +149,6 @@ config ARM_DMA_IOMMU_ALIGNMENT > > endif > > -config MIGHT_HAVE_PCI > - bool > - > config SYS_SUPPORTS_APM_EMULATION > bool > > @@ -320,7 +317,7 @@ config ARCH_MULTIPLATFORM > select COMMON_CLK > select GENERIC_CLOCKEVENTS > select GENERIC_IRQ_MULTI_HANDLER > - select MIGHT_HAVE_PCI > + select HAVE_PCI > select PCI_DOMAINS if PCI > select SPARSE_IRQ > select USE_OF > @@ -436,7 +433,7 @@ config ARCH_IXP4XX > select DMABOUNCE if PCI > select GENERIC_CLOCKEVENTS > select GPIOLIB > - select MIGHT_HAVE_PCI > + select HAVE_PCI > select NEED_MACH_IO_H > select USB_EHCI_BIG_ENDIAN_DESC > select USB_EHCI_BIG_ENDIAN_MMIO > @@ -449,7 +446,7 @@ config ARCH_DOVE > select GENERIC_CLOCKEVENTS > select GENERIC_IRQ_MULTI_HANDLER > select GPIOLIB > - select MIGHT_HAVE_PCI > + select HAVE_PCI > select MVEBU_MBUS > select PINCTRL > select PINCTRL_DOVE > @@ -1216,14 +1213,6 @@ config ISA_DMA > config ISA_DMA_API > bool > > -config PCI > - bool "PCI support" if MIGHT_HAVE_PCI > - help > - Find out whether you have a PCI motherboard. PCI is the name of a > - bus system, i.e. the way the CPU talks to the other stuff inside > - your box. Other bus systems are ISA, EISA, MicroChannel (MCA) or > - VESA. If you have PCI, say Y, otherwise N. > - > config PCI_DOMAINS > bool "Support for multiple PCI domains" > depends on PCI > @@ -1252,8 +1241,6 @@ config PCI_HOST_ITE8152 > default y > select DMABOUNCE > > -source "drivers/pci/Kconfig" > - > source "drivers/pcmcia/Kconfig" > > endmenu > diff --git a/arch/arm/mach-ks8695/Kconfig b/arch/arm/mach-ks8695/Kconfig > index a545976bdbd6..b3185c05fffa 100644 > --- a/arch/arm/mach-ks8695/Kconfig > +++ b/arch/arm/mach-ks8695/Kconfig > @@ -4,7 +4,7 @@ menu "Kendin/Micrel KS8695 Implementations" > > config MACH_KS8695 > bool "KS8695 development board" > - select MIGHT_HAVE_PCI > + select HAVE_PCI > help > Say 'Y' here if you want your kernel to run on the original > Kendin-Micrel KS8695 development board. > @@ -52,7 +52,7 @@ config MACH_CM4002 > > config MACH_CM4008 > bool "OpenGear CM4008" > - select MIGHT_HAVE_PCI > + select HAVE_PCI > help > Say 'Y' here if you want your kernel to support the OpenGear > CM4008 Console Server. See http://www.opengear.com for more > @@ -60,7 +60,7 @@ config MACH_CM4008 > > config MACH_CM41xx > bool "OpenGear CM41xx" > - select MIGHT_HAVE_PCI > + select HAVE_PCI > help > Say 'Y' here if you want your kernel to support the OpenGear > CM4016 or CM4048 Console Servers. See http://www.opengear.com for > @@ -68,7 +68,7 @@ config MACH_CM41xx > > config MACH_IM4004 > bool "OpenGear IM4004" > - select MIGHT_HAVE_PCI > + select HAVE_PCI > help > Say 'Y' here if you want your kernel to support the OpenGear > IM4004 Secure Access Server. See http://www.opengear.com for > @@ -76,7 +76,7 @@ config MACH_IM4004 > > config MACH_IM42xx > bool "OpenGear IM42xx" > - select MIGHT_HAVE_PCI > + select HAVE_PCI > help > Say 'Y' here if you want your kernel to support the OpenGear > IM4216 or IM4248 Console Servers. See http://www.opengear.com for > diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig > index a68b34183107..b185794549be 100644 > --- a/arch/arm/mach-pxa/Kconfig > +++ b/arch/arm/mach-pxa/Kconfig > @@ -125,7 +125,7 @@ config MACH_ARMCORE > bool "CompuLab CM-X255/CM-X270 modules" > select ARCH_HAS_DMA_SET_COHERENT_MASK if PCI > select IWMMXT > - select MIGHT_HAVE_PCI > + select HAVE_PCI > select NEED_MACH_IO_H if PCI > select PXA25x > select PXA27x This is wrong. "MIGHT_HAVE_PCI" is _not_ the same as "HAVE_PCI" - we have a bunch of platforms that mandatorily have PCI and these select PCI directly. "MIGHT_HAVE_PCI" controls the _visibility_ of the PCI menu option, but does not prevent it being selected. Your patch will cause Kconfig to complain for those which mandatorily have PCI but do not set HAVE_PCI. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
[PATCH 3/9] powerpc: remove CONFIG_PCI_QSPAN
This option isn't actually used anywhere. Signed-off-by: Christoph Hellwig Acked-by: Benjamin Herrenschmidt --- arch/powerpc/Kconfig | 9 - 1 file changed, 9 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index a80669209155..e8c8970248bc 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -955,7 +955,6 @@ config PCI bool "PCI support" if PPC_PCI_CHOICE default y if !40x && !CPM2 && !PPC_8xx && !PPC_83xx \ && !PPC_85xx && !PPC_86xx && !GAMECUBE_COMMON - default PCI_QSPAN if PPC_8xx select GENERIC_PCI_IOMAP help Find out whether your system includes a PCI bus. PCI is the name of @@ -969,14 +968,6 @@ config PCI_DOMAINS config PCI_SYSCALL def_bool PCI -config PCI_QSPAN - bool "QSpan PCI" - depends on PPC_8xx - select PPC_I8259 - help - Say Y here if you have a system based on a Motorola 8xx-series - embedded processor with a QSPAN PCI interface, otherwise say N. - config PCI_8260 bool depends on PCI && 8260 -- 2.19.1
[PATCH 4/9] powerpc: remove CONFIG_MCA leftovers
Signed-off-by: Christoph Hellwig Acked-by: Thomas Gleixner --- arch/powerpc/Kconfig | 4 drivers/scsi/Kconfig | 6 +++--- 2 files changed, 3 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index e8c8970248bc..d4e97469a5f0 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -941,10 +941,6 @@ config FSL_GTM help Freescale General-purpose Timers support -# Yes MCA RS/6000s exist but Linux-PPC does not currently support any -config MCA - bool - # Platforms that what PCI turned unconditionally just do select PCI # in their config node. Platforms that want to choose at config # time should select PPC_PCI_CHOICE diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 7c097006c54d..d3734c54aec9 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -535,7 +535,7 @@ config SCSI_HPTIOP config SCSI_BUSLOGIC tristate "BusLogic SCSI support" - depends on (PCI || ISA || MCA) && SCSI && ISA_DMA_API && VIRT_TO_BUS + depends on (PCI || ISA) && SCSI && ISA_DMA_API && VIRT_TO_BUS ---help--- This is support for BusLogic MultiMaster and FlashPoint SCSI Host Adapters. Consult the SCSI-HOWTO, available from @@ -1142,12 +1142,12 @@ config SCSI_LPFC_DEBUG_FS config SCSI_SIM710 tristate "Simple 53c710 SCSI support (Compaq, NCR machines)" - depends on (EISA || MCA) && SCSI + depends on EISA && SCSI select SCSI_SPI_ATTRS ---help--- This driver is for NCR53c710 based SCSI host adapters. - It currently supports Compaq EISA cards and NCR MCA cards + It currently supports Compaq EISA cards. config SCSI_DC395x tristate "Tekram DC395(U/UW/F) and DC315(U) SCSI support" -- 2.19.1
[PATCH 8/9] rapidio: consolidate RAPIDIO config entry in drivers/rapidio
There is no good reason to duplicate the RAPIDIO menu in various architectures. Instead provide a selectable HAVE_RAPIDIO symbol that indicates native availability of RAPIDIO support and the handle the rest in drivers/pci. This also means we now provide support for PCI(e) to Rapidio bridges for every architecture instead of a limited subset. Signed-off-by: Christoph Hellwig Acked-by: Thomas Gleixner --- arch/mips/Kconfig | 15 +-- arch/powerpc/Kconfig| 15 +-- arch/powerpc/platforms/85xx/Kconfig | 8 arch/powerpc/platforms/86xx/Kconfig | 4 ++-- arch/x86/Kconfig| 10 -- drivers/Kconfig | 1 + drivers/rapidio/Kconfig | 11 +++ 7 files changed, 20 insertions(+), 44 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 18eeb66c6d99..96198f8375e1 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -894,7 +894,7 @@ config CAVIUM_OCTEON_SOC bool "Cavium Networks Octeon SoC based boards" select CEVT_R4K select ARCH_HAS_PHYS_TO_DMA - select HAS_RAPIDIO + select HAVE_RAPIDIO select PHYS_ADDR_T_64BIT select SYS_SUPPORTS_64BIT_KERNEL select SYS_SUPPORTS_BIG_ENDIAN @@ -3090,19 +3090,6 @@ config ZONE_DMA config ZONE_DMA32 bool -config HAS_RAPIDIO - bool - default n - -config RAPIDIO - tristate "RapidIO support" - depends on HAS_RAPIDIO || PCI - help - If you say Y here, the kernel will include drivers and - infrastructure code to support RapidIO interconnect devices. - -source "drivers/rapidio/Kconfig" - endmenu config TRAD_SIGNALS diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index ffd1695ad9b4..6b29c27770db 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -959,27 +959,14 @@ config PCI_8260 select PPC_INDIRECT_PCI default y -config HAS_RAPIDIO - bool - default n - -config RAPIDIO - tristate "RapidIO support" - depends on HAS_RAPIDIO || PCI - help - If you say Y here, the kernel will include drivers and - infrastructure code to support RapidIO interconnect devices. - config FSL_RIO bool "Freescale Embedded SRIO Controller support" - depends on RAPIDIO = y && HAS_RAPIDIO + depends on RAPIDIO = y && HAVE_RAPIDIO default "n" ---help--- Include support for RapidIO controller on Freescale embedded processors (MPC8548, MPC8641, etc). -source "drivers/rapidio/Kconfig" - endmenu config NONSTATIC_KERNEL diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index 20867a23f3f2..1c6bb9180d70 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -65,7 +65,7 @@ config MPC85xx_CDS bool "Freescale MPC85xx CDS" select DEFAULT_UIMAGE select PPC_I8259 - select HAS_RAPIDIO + select HAVE_RAPIDIO help This option enables support for the MPC85xx CDS board @@ -73,7 +73,7 @@ config MPC85xx_MDS bool "Freescale MPC85xx MDS" select DEFAULT_UIMAGE select PHYLIB if NETDEVICES - select HAS_RAPIDIO + select HAVE_RAPIDIO select SWIOTLB help This option enables support for the MPC85xx MDS board @@ -218,7 +218,7 @@ config PPA8548 help This option enables support for the Prodrive PPA8548 board. select DEFAULT_UIMAGE - select HAS_RAPIDIO + select HAVE_RAPIDIO config GE_IMP3A bool "GE Intelligent Platforms IMP3A" @@ -276,7 +276,7 @@ config CORENET_GENERIC select SWIOTLB select GPIOLIB select GPIO_MPC8XXX - select HAS_RAPIDIO + select HAVE_RAPIDIO select PPC_EPAPR_HV_PIC help This option enables support for the FSL CoreNet based boards. diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig index 87220554dd6f..badd9d6ba1ef 100644 --- a/arch/powerpc/platforms/86xx/Kconfig +++ b/arch/powerpc/platforms/86xx/Kconfig @@ -15,7 +15,7 @@ config MPC8641_HPCN select PPC_I8259 select DEFAULT_UIMAGE select FSL_ULI1575 if PCI - select HAS_RAPIDIO + select HAVE_RAPIDIO select SWIOTLB help This option enables support for the MPC8641 HPCN board. @@ -57,7 +57,7 @@ config GEF_SBC610 select MMIO_NVRAM select GPIOLIB select GE_FPGA - select HAS_RAPIDIO + select HAVE_RAPIDIO help This option enables support for the GE SBC610. diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index fda01408b596..6fe3740018f6 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2810,16 +2810,6 @@ config AMD_NB def_bool y depends on CPU_SUP_AMD && PCI -config RAPIDIO - tristate "RapidIO suppor
[PATCH 6/9] PCI: consolidate PCI config entry in drivers/pci
There is no good reason to duplicate the PCI menu in every architecture. Instead provide a selectable HAVE_PCI symbol that indicates availability of PCI support and the handle the rest in drivers/pci. Note that for powerpc we now select HAVE_PCI globally instead of the convoluted mess of conditional or or non-conditional support per board, similar to what we do e.g. on x86. For alpha PCI is selected for the non-jensen configs as it was the default before, and a lot of code does not compile without PCI enabled. On other architectures with limited PCI support that wasn't as complicated I've left the selection as-is. Signed-off-by: Christoph Hellwig Acked-by: Max Filippov Acked-by: Thomas Gleixner Acked-by: Bjorn Helgaas --- arch/alpha/Kconfig | 15 ++--- arch/arc/Kconfig | 20 arch/arc/plat-axs10x/Kconfig | 2 +- arch/arc/plat-hsdk/Kconfig | 2 +- arch/arm/Kconfig | 19 ++-- arch/arm/mach-ks8695/Kconfig | 10 +++--- arch/arm/mach-pxa/Kconfig | 2 +- arch/arm64/Kconfig | 10 +- arch/hexagon/Kconfig | 3 -- arch/ia64/Kconfig | 9 +- arch/m68k/Kconfig.bus | 11 --- arch/m68k/Kconfig.cpu | 1 + arch/microblaze/Kconfig| 6 +--- arch/mips/Kconfig | 43 +- arch/mips/alchemy/Kconfig | 6 ++-- arch/mips/ath25/Kconfig| 2 +- arch/mips/ath79/Kconfig| 8 ++--- arch/mips/bcm63xx/Kconfig | 14 - arch/mips/lantiq/Kconfig | 2 +- arch/mips/loongson64/Kconfig | 6 ++-- arch/mips/pmcs-msp71xx/Kconfig | 10 +++--- arch/mips/ralink/Kconfig | 8 ++--- arch/mips/sibyte/Kconfig | 10 +++--- arch/mips/txx9/Kconfig | 8 ++--- arch/mips/vr41xx/Kconfig | 8 ++--- arch/parisc/Kconfig| 1 + arch/powerpc/Kconfig | 25 --- arch/powerpc/platforms/44x/Kconfig | 1 - arch/powerpc/platforms/512x/Kconfig| 1 - arch/powerpc/platforms/52xx/Kconfig| 1 - arch/powerpc/platforms/83xx/Kconfig| 1 - arch/powerpc/platforms/85xx/Kconfig| 1 - arch/powerpc/platforms/86xx/Kconfig| 2 -- arch/powerpc/platforms/Kconfig | 1 - arch/powerpc/platforms/Kconfig.cputype | 2 -- arch/powerpc/platforms/ps3/Kconfig | 1 - arch/riscv/Kconfig | 18 ++- arch/s390/Kconfig | 23 +- arch/sh/Kconfig| 19 ++-- arch/sh/boards/Kconfig | 30 +- arch/sparc/Kconfig | 15 + arch/um/Kconfig| 3 -- arch/unicore32/Kconfig | 11 +-- arch/x86/Kconfig | 12 +-- arch/x86/configs/i386_defconfig| 1 + arch/x86/configs/x86_64_defconfig | 1 + arch/xtensa/Kconfig| 16 +- arch/xtensa/configs/common_defconfig | 1 + arch/xtensa/configs/iss_defconfig | 1 - drivers/Kconfig| 4 +++ drivers/parisc/Kconfig | 11 --- drivers/pci/Kconfig| 12 +++ drivers/pci/endpoint/Kconfig | 2 +- 53 files changed, 133 insertions(+), 319 deletions(-) diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 5b4f88363453..bb89924c0361 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -6,6 +6,8 @@ config ALPHA select ARCH_MIGHT_HAVE_PC_SERIO select ARCH_NO_PREEMPT select ARCH_USE_CMPXCHG_LOCKREF + select HAVE_PCI if !ALPHA_JENSEN + select PCI if !ALPHA_JENSEN select HAVE_AOUT select HAVE_IDE select HAVE_OPROFILE @@ -15,6 +17,7 @@ config ALPHA select NEED_SG_DMA_LENGTH select VIRT_TO_BUS select GENERIC_IRQ_PROBE + select GENERIC_PCI_IOMAP if PCI select AUTO_IRQ_AFFINITY if SMP select GENERIC_IRQ_SHOW select ARCH_WANT_IPC_PARSE_VERSION @@ -319,17 +322,6 @@ config ISA_DMA_API bool default y -config PCI - bool - depends on !ALPHA_JENSEN - select GENERIC_PCI_IOMAP - default y - help - Find out whether you have a PCI motherboard. PCI is the name of a - bus system, i.e. the way the CPU talks to the other stuff inside - your box. Other bus systems are ISA, EISA, MicroChannel (MCA) or - VESA. If you have PCI, say Y, otherwise N. - config PCI_DOMAINS bool default y @@ -681,7 +673,6 @@ config HZ default 1200 if HZ_1200 default 1024 -source "drivers/pci/Kconfig" source "drivers/eisa/Kconfig" source "drivers/pcmcia/Kconfig" diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
[PATCH 9/9] eisa: consolidate EISA Kconfig entry in drivers/eisa
Let architectures opt into EISA support by selecting HAS_EISA and handle everything else in drivers/eisa. Signed-off-by: Christoph Hellwig Acked-by: Thomas Gleixner --- arch/alpha/Kconfig | 15 --- arch/mips/Kconfig | 31 +-- arch/powerpc/Kconfig | 3 --- arch/x86/Kconfig | 19 +-- drivers/Kconfig| 1 + drivers/eisa/Kconfig | 21 - drivers/parisc/Kconfig | 11 +-- 7 files changed, 36 insertions(+), 65 deletions(-) diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 96f02268ea16..b723cd8ee6fb 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -128,11 +128,13 @@ choice config ALPHA_GENERIC bool "Generic" depends on TTY + select HAVE_EISA help A generic kernel will run on all supported Alpha hardware. config ALPHA_ALCOR bool "Alcor/Alpha-XLT" + select HAVE_EISA help For systems using the Digital ALCOR chipset: 5 chips (4, 64-bit data slices (Data Switch, DSW) - 208-pin PQFP and 1 control (Control, I/O @@ -206,6 +208,7 @@ config ALPHA_JENSEN bool "Jensen" depends on BROKEN select DMA_DIRECT_OPS + select HAVE_EISA help DEC PC 150 AXP (aka Jensen): This is a very old Digital system - one of the first-generation Alpha systems. A number of these systems @@ -222,6 +225,7 @@ config ALPHA_LX164 config ALPHA_LYNX bool "Lynx" + select HAVE_EISA help AlphaServer 2100A-based systems. @@ -232,6 +236,7 @@ config ALPHA_MARVEL config ALPHA_MIATA bool "Miata" + select HAVE_EISA help The Digital PersonalWorkStation (PWS 433a, 433au, 500a, 500au, 600a, or 600au). @@ -251,6 +256,7 @@ config ALPHA_NONAME_CH config ALPHA_NORITAKE bool "Noritake" + select HAVE_EISA help AlphaServer 1000A, AlphaServer 600A, and AlphaServer 800-based systems. @@ -263,6 +269,7 @@ config ALPHA_P2K config ALPHA_RAWHIDE bool "Rawhide" + select HAVE_EISA help AlphaServer 1200, AlphaServer 4000 and AlphaServer 4100 machines. See HOWTO at @@ -282,6 +289,7 @@ config ALPHA_SX164 config ALPHA_SABLE bool "Sable" + select HAVE_EISA help Digital AlphaServer 2000 and 2100-based systems. @@ -518,11 +526,6 @@ config ALPHA_SRM If unsure, say N. -config EISA - bool - depends on ALPHA_GENERIC || ALPHA_JENSEN || ALPHA_ALCOR || ALPHA_MIKASA || ALPHA_SABLE || ALPHA_LYNX || ALPHA_NORITAKE || ALPHA_RAWHIDE - default y - config ARCH_MAY_HAVE_PC_FDC def_bool y @@ -673,8 +676,6 @@ config HZ default 1200 if HZ_1200 default 1024 -source "drivers/eisa/Kconfig" - config SRM_ENV tristate "SRM environment through procfs" depends on PROC_FS diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 96198f8375e1..7cf58031a43e 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -23,6 +23,7 @@ config MIPS select GENERIC_CPU_AUTOPROBE select GENERIC_IRQ_PROBE select GENERIC_IRQ_SHOW + select GENERIC_ISA_DMA if EISA select GENERIC_LIB_ASHLDI3 select GENERIC_LIB_ASHRDI3 select GENERIC_LIB_CMPDI2 @@ -72,6 +73,7 @@ config MIPS select HAVE_SYSCALL_TRACEPOINTS select HAVE_VIRT_CPU_ACCOUNTING_GEN if 64BIT || !SMP select IRQ_FORCED_THREADING + select ISA if EISA select MODULES_USE_ELF_RELA if MODULES && 64BIT select MODULES_USE_ELF_REL if MODULES select PCI_DOMAINS if PCI @@ -634,7 +636,7 @@ config SGI_IP22 select CSRC_R4K select DEFAULT_SGI_PARTITION select DMA_NONCOHERENT - select HW_HAS_EISA + select HAVE_EISA select I8253 select I8259 select IP22_CPU_SCACHE @@ -699,7 +701,7 @@ config SGI_IP28 select DMA_NONCOHERENT select GENERIC_ISA_DMA_SUPPORT_BROKEN select IRQ_MIPS_CPU - select HW_HAS_EISA + select HAVE_EISA select I8253 select I8259 select SGI_HAS_I8042 @@ -842,8 +844,8 @@ config SNI_RM select DEFAULT_SGI_PARTITION if CPU_BIG_ENDIAN select DMA_NONCOHERENT select GENERIC_ISA_DMA + select HAVE_EISA select HAVE_PCSPKR_PLATFORM - select HW_HAS_EISA select HAVE_PCI select IRQ_MIPS_CPU select I8253 @@ -2991,9 +2993,6 @@ config MIPS_AUTO_PFN_OFFSET menu "Bus options (PCI, PCMCIA, EISA, ISA, TC)" -config HW_HAS_EISA - bool - config HT_PCI bool "Support for HT-linked PCI" default y @@ -3027,26 +3026,6 @@ config PCI_DRIVERS_LEGACY config ISA bool -config EISA - bool "EISA support" - depends on HW_HAS_EISA - select ISA - select GENERIC_ISA_DMA - ---help--- - The Extended In
[PATCH 5/9] powerpc: PCI_MSI needs PCI
Various powerpc boards select the PCI_MSI config option without selecting PCI, resulting in potentially not compilable configurations if the by default enabled PCI option is disabled. Explicitly select PCI to ensure we always have valid configs. Signed-off-by: Christoph Hellwig Acked-by: Thomas Gleixner --- arch/powerpc/platforms/40x/Kconfig | 1 + arch/powerpc/platforms/44x/Kconfig | 3 +++ 2 files changed, 4 insertions(+) diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig index 60254a321a91..d5361e63e0bb 100644 --- a/arch/powerpc/platforms/40x/Kconfig +++ b/arch/powerpc/platforms/40x/Kconfig @@ -33,6 +33,7 @@ config KILAUEA select 405EX select PPC40x_SIMPLE select PPC4xx_PCI_EXPRESS + select PCI select PCI_MSI select PPC4xx_MSI help diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig index a6011422b861..70856a213663 100644 --- a/arch/powerpc/platforms/44x/Kconfig +++ b/arch/powerpc/platforms/44x/Kconfig @@ -24,6 +24,7 @@ config BLUESTONE default n select PPC44x_SIMPLE select APM821xx + select PCI select PCI_MSI select PPC4xx_MSI select PPC4xx_PCI_EXPRESS @@ -78,6 +79,7 @@ config KATMAI select 440SPe select PCI select PPC4xx_PCI_EXPRESS + select PCI select PCI_MSI select PPC4xx_MSI help @@ -219,6 +221,7 @@ config AKEBONO select SWIOTLB select 476FPE select PPC4xx_PCI_EXPRESS + select PCI select PCI_MSI select PPC4xx_HSTA_MSI select I2C -- 2.19.1
[PATCH 7/9] pcmcia: allow PCMCIA support independent of the architecture
There is nothing architecture specific in the PCMCIA core, so allow building it everywhere. The actual host controllers will depend on ISA, PCI or a specific SOC. Signed-off-by: Christoph Hellwig Acked-by: Dominik Brodowski Acked-by: Thomas Gleixner --- arch/alpha/Kconfig | 2 -- arch/arm/Kconfig | 2 -- arch/ia64/Kconfig | 2 -- arch/m68k/Kconfig.bus | 2 -- arch/mips/Kconfig | 2 -- arch/powerpc/Kconfig | 2 -- arch/sh/Kconfig| 2 -- arch/sparc/Kconfig | 2 -- arch/unicore32/Kconfig | 6 -- arch/x86/Kconfig | 2 -- arch/xtensa/Kconfig| 2 -- drivers/Kconfig| 1 + drivers/parisc/Kconfig | 2 -- drivers/pcmcia/Kconfig | 1 + 14 files changed, 2 insertions(+), 28 deletions(-) diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index bb89924c0361..96f02268ea16 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -675,8 +675,6 @@ config HZ source "drivers/eisa/Kconfig" -source "drivers/pcmcia/Kconfig" - config SRM_ENV tristate "SRM environment through procfs" depends on PROC_FS diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 7495d0a0aa31..ec602deaab43 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1241,8 +1241,6 @@ config PCI_HOST_ITE8152 default y select DMABOUNCE -source "drivers/pcmcia/Kconfig" - endmenu menu "Kernel Features" diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 89da763d7c17..704ff5922ce0 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -553,8 +553,6 @@ config PCI_DOMAINS config PCI_SYSCALL def_bool PCI -source "drivers/pcmcia/Kconfig" - endmenu endif diff --git a/arch/m68k/Kconfig.bus b/arch/m68k/Kconfig.bus index 8cb0604b195b..9d0a3a23d50e 100644 --- a/arch/m68k/Kconfig.bus +++ b/arch/m68k/Kconfig.bus @@ -68,6 +68,4 @@ if !MMU config ISA_DMA_API def_bool !M5272 -source "drivers/pcmcia/Kconfig" - endif diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 09b93d5a55cb..18eeb66c6d99 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -3090,8 +3090,6 @@ config ZONE_DMA config ZONE_DMA32 bool -source "drivers/pcmcia/Kconfig" - config HAS_RAPIDIO bool default n diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 086d78c7c2c8..ffd1695ad9b4 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -959,8 +959,6 @@ config PCI_8260 select PPC_INDIRECT_PCI default y -source "drivers/pcmcia/Kconfig" - config HAS_RAPIDIO bool default n diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 2ff6855811a5..ce9487139155 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -861,8 +861,6 @@ config MAPLE config PCI_DOMAINS bool -source "drivers/pcmcia/Kconfig" - endmenu menu "Power management options (EXPERIMENTAL)" diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig index fc311b8dc46b..0198f96528fc 100644 --- a/arch/sparc/Kconfig +++ b/arch/sparc/Kconfig @@ -509,8 +509,6 @@ config SPARC_GRPCI2 help Say Y here to include the GRPCI2 Host Bridge Driver. -source "drivers/pcmcia/Kconfig" - config SUN_OPENPROMFS tristate "Openprom tree appears in /proc/openprom" help diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig index 601dcad2560e..d7750e7c7ccb 100644 --- a/arch/unicore32/Kconfig +++ b/arch/unicore32/Kconfig @@ -118,12 +118,6 @@ config UNICORE_FPU_F64 endmenu -menu "Bus support" - -source "drivers/pcmcia/Kconfig" - -endmenu - menu "Kernel Features" source "kernel/Kconfig.hz" diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5816e20a3ff9..fda01408b596 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2810,8 +2810,6 @@ config AMD_NB def_bool y depends on CPU_SUP_AMD && PCI -source "drivers/pcmcia/Kconfig" - config RAPIDIO tristate "RapidIO support" depends on PCI diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig index f057c16a48a5..c18ceaab7860 100644 --- a/arch/xtensa/Kconfig +++ b/arch/xtensa/Kconfig @@ -517,8 +517,6 @@ config FORCE_MAX_ZONEORDER This config option is actually maximum order plus one. For example, a value of 11 means that the largest free memory block is 2^10 pages. -source "drivers/pcmcia/Kconfig" - config PLATFORM_WANT_DEFAULT_MEM def_bool n diff --git a/drivers/Kconfig b/drivers/Kconfig index 059573823387..58ee88c36cf5 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -5,6 +5,7 @@ menu "Device Drivers" source "drivers/amba/Kconfig" source "drivers/pci/Kconfig" +source "drivers/pcmcia/Kconfig" source "drivers/base/Kconfig" diff --git a/drivers/parisc/Kconfig b/drivers/parisc/Kconfig index 5bbfea1a019c..1a55763d1245 100644 --- a/drivers/parisc/Kconfig +++ b/drivers/parisc/Kconfig @@ -92,8 +92,6 @@ config IOMMU_SBA depends on PCI_LBA default PCI_LBA -source "drivers/pcmcia/Kconfig" - endmenu menu "PA-RISC specific drivers" diff --git a/drivers/p
move bus (PCI, PCMCIA, EISA, rapdio) config to drivers/ v3
Hi all, currently every architecture that wants to provide on of the common periphal busses needs to add some boilerplate code and include the right Kconfig files. This series instead just selects the presence (when needed) and then handles everything in the bus-specific Kconfig file under drivers/. Changes since v2: - depend on HAVE_PCI for PCIe endpoint code - fix some commit message typos - remove CONFIG_PCI from xtensa iss defconfig - drop EISA support from arm - clean up EISA selection for alpha Changes since v1: - rename all HAS_* Kconfig symbols to HAVE_* - drop the CONFIG_PCI_QSPAN option entirely - drop duplicate select from powerpc - restore missing selection of PCI_MSI for riscv - update x86 and riscv defconfigs to include PCI - actually inclue drivers/eisa/Kconfig - adjust some captilizations
[PATCH 1/9] aha152x: rename the PCMCIA define
We plan to enable building the PCMCIA core and drivers, and the
non-prefixed PCMCIA name clashes with some arch headers.
Signed-off-by: Christoph Hellwig
Acked-by: Thomas Gleixner
---
drivers/scsi/aha152x.c | 14 +++---
drivers/scsi/pcmcia/aha152x_core.c | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/aha152x.c b/drivers/scsi/aha152x.c
index 4d7b0e0adbf7..301b3cad15f8 100644
--- a/drivers/scsi/aha152x.c
+++ b/drivers/scsi/aha152x.c
@@ -269,7 +269,7 @@ static LIST_HEAD(aha152x_host_list);
/* DEFINES */
/* For PCMCIA cards, always use AUTOCONF */
-#if defined(PCMCIA) || defined(MODULE)
+#if defined(AHA152X_PCMCIA) || defined(MODULE)
#if !defined(AUTOCONF)
#define AUTOCONF
#endif
@@ -297,7 +297,7 @@ CMD_INC_RESID(struct scsi_cmnd *cmd, int inc)
#define DELAY_DEFAULT 1000
-#if defined(PCMCIA)
+#if defined(AHA152X_PCMCIA)
#define IRQ_MIN 0
#define IRQ_MAX 16
#else
@@ -328,7 +328,7 @@ MODULE_AUTHOR("Jürgen Fischer");
MODULE_DESCRIPTION(AHA152X_REVID);
MODULE_LICENSE("GPL");
-#if !defined(PCMCIA)
+#if !defined(AHA152X_PCMCIA)
#if defined(MODULE)
static int io[] = {0, 0};
module_param_hw_array(io, int, ioport, NULL, 0);
@@ -391,7 +391,7 @@ static struct isapnp_device_id id_table[] = {
MODULE_DEVICE_TABLE(isapnp, id_table);
#endif /* ISAPNP */
-#endif /* !PCMCIA */
+#endif /* !AHA152X_PCMCIA */
static struct scsi_host_template aha152x_driver_template;
@@ -863,7 +863,7 @@ void aha152x_release(struct Scsi_Host *shpnt)
if (shpnt->irq)
free_irq(shpnt->irq, shpnt);
-#if !defined(PCMCIA)
+#if !defined(AHA152X_PCMCIA)
if (shpnt->io_port)
release_region(shpnt->io_port, IO_RANGE);
#endif
@@ -2924,7 +2924,7 @@ static struct scsi_host_template aha152x_driver_template
= {
.slave_alloc= aha152x_adjust_queue,
};
-#if !defined(PCMCIA)
+#if !defined(AHA152X_PCMCIA)
static int setup_count;
static struct aha152x_setup setup[2];
@@ -3392,4 +3392,4 @@ static int __init aha152x_setup(char *str)
__setup("aha152x=", aha152x_setup);
#endif
-#endif /* !PCMCIA */
+#endif /* !AHA152X_PCMCIA */
diff --git a/drivers/scsi/pcmcia/aha152x_core.c
b/drivers/scsi/pcmcia/aha152x_core.c
index dba3716511c5..24b89228b241 100644
--- a/drivers/scsi/pcmcia/aha152x_core.c
+++ b/drivers/scsi/pcmcia/aha152x_core.c
@@ -1,3 +1,3 @@
-#define PCMCIA 1
+#define AHA152X_PCMCIA 1
#define AHA152X_STAT 1
#include "aha152x.c"
--
2.19.1
[PATCH 2/9] arm: remove EISA kconfig option
No arm config enables EISA, and arm does not include drivers/eisa/Kconfig which provides support for things like PCI to EISA bridges, so it is most likely dead. If this is wrong we will be able to resurrect it easily by selecting HAVE_EISA for the right arm configs after this series. Suggested-by: Masahiro Yamada Signed-off-by: Christoph Hellwig --- arch/arm/Kconfig | 15 --- 1 file changed, 15 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e8cd55a5b04c..e33735ce1c14 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -165,21 +165,6 @@ config HAVE_PROC_CPU config NO_IOPORT_MAP bool -config EISA - bool - ---help--- - The Extended Industry Standard Architecture (EISA) bus was - developed as an open alternative to the IBM MicroChannel bus. - - The EISA bus provided some of the features of the IBM MicroChannel - bus while maintaining backward compatibility with cards made for - the older ISA bus. The EISA bus saw limited use between 1988 and - 1995 when it was made obsolete by the PCI bus. - - Say Y here if you are building a kernel for an EISA-based machine. - - Otherwise, say N. - config SBUS bool -- 2.19.1
[PATCH -next] scsi: qedf: remove set but not used variable 'fcport'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/scsi/qedf/qedf_main.c: In function 'qedf_eh_abort':
drivers/scsi/qedf/qedf_main.c:619:21: warning:
variable 'fcport' set but not used [-Wunused-but-set-variable]
struct qedf_rport *fcport;
It never used since introduction in
commit 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver
framework.")
Signed-off-by: YueHaibing
---
drivers/scsi/qedf/qedf_main.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c
index d5a4f17..04f50a3 100644
--- a/drivers/scsi/qedf/qedf_main.c
+++ b/drivers/scsi/qedf/qedf_main.c
@@ -615,8 +615,6 @@ static u32 qedf_get_login_failures(void *cookie)
static int qedf_eh_abort(struct scsi_cmnd *sc_cmd)
{
struct fc_rport *rport = starget_to_rport(scsi_target(sc_cmd->device));
- struct fc_rport_libfc_priv *rp = rport->dd_data;
- struct qedf_rport *fcport;
struct fc_lport *lport;
struct qedf_ctx *qedf;
struct qedf_ioreq *io_req;
@@ -636,8 +634,6 @@ static int qedf_eh_abort(struct scsi_cmnd *sc_cmd)
goto out;
}
- fcport = (struct qedf_rport *)&rp[1];
-
io_req = (struct qedf_ioreq *)sc_cmd->SCp.ptr;
if (!io_req) {
QEDF_ERR(&(qedf->dbg_ctx), "io_req is NULL.\n");
Re: move bus (PCI, PCMCIA, EISA, rapdio) config to drivers/ v2
On Fri, Oct 19, 2018 at 09:22:08AM +0200, Geert Uytterhoeven wrote: > Hi Christoph, > > On Fri, Oct 19, 2018 at 9:10 AM Christoph Hellwig wrote: > > On Fri, Oct 19, 2018 at 09:07:51AM +0200, Geert Uytterhoeven wrote: > > > Without this: > > > - It's hard to visually match your untagged cover letter with the > > > actual patches, > > > - Your individual patches lack the version info, so people cannot see > > > which > > > version review comments in an email reply apply to. > > > > All of that is trivially solved by mail threading. > > You forgot to answer this question: > > | Can you please clarify what exactly that would mess up? It makes the already limited space in the subject line even shorted (or harder to read depending on which way you go) for absolutely not good reason.
Re: [PATCH 5/8] sg: add free list, rework locking
Hi linux-scsi-owner, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on mkp-scsi/for-next] [also build test WARNING on v4.19-rc8 next-20181019] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/linux-scsi-owner-vger-kernel-org/sg-major-cleanup-remove-max_queue-limit/20181019-183809 base: https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next config: i386-randconfig-x078-201841 (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): >> drivers//scsi/sg.c:240:20: warning: 'sg_rq_state_str' used but never defined static const char *sg_rq_state_str(u8 rq_state, bool long_str); ^~~ drivers//scsi/sg.c:933:1: warning: 'sg_fill_request_table' defined but not used [-Wunused-function] sg_fill_request_table(struct sg_fd *sfp, struct sg_req_info *rinfo, ^ drivers//scsi/sg.c:19:12: warning: 'sg_version_num' defined but not used [-Wunused-variable] static int sg_version_num = 30901; /* 2 digits for each component */ ^~ vim +/sg_rq_state_str +240 drivers//scsi/sg.c 212 213 /* tasklet or soft irq callback */ 214 static void sg_rq_end_io(struct request *rq, blk_status_t status); 215 static int sg_start_req(struct sg_request *srp, u8 *cmd); 216 static void sg_finish_scsi_blk_rq(struct sg_request *srp); 217 static int sg_mk_sgat_dlen(struct sg_request *srp, struct sg_fd *sfp, 218 int dlen); 219 static ssize_t sg_new_read(struct sg_fd *sfp, char __user *buf, size_t count, 220 struct sg_request *srp); 221 static ssize_t sg_v3_write(struct sg_fd *sfp, struct file *file, 222 const char __user *buf, size_t count, 223 bool read_only, bool sync, 224 struct sg_request **o_srp); 225 static struct sg_request *sg_common_write(struct sg_fd *sfp, 226const struct sg_io_hdr *hp, 227struct sg_io_v4 *h4p, u8 *cmnd, 228bool sync, int timeout); 229 static int sg_read_oxfer(struct sg_request *srp, char __user *outp, 230 int num_xfer); 231 static void sg_remove_sgat(struct sg_request *srp); 232 static struct sg_fd *sg_add_sfp(struct sg_device *sdp); 233 static void sg_remove_sfp(struct kref *); 234 static struct sg_request *sg_get_rq_pack_id(struct sg_fd *sfp, int pack_id); 235 static struct sg_request *sg_add_request(struct sg_fd *sfp, int dxfr_len, 236 bool sync); 237 static void sg_remove_request(struct sg_fd *sfp, struct sg_request *srp); 238 static struct sg_device *sg_get_dev(int min_dev); 239 static void sg_device_destroy(struct kref *kref); > 240 static const char *sg_rq_state_str(u8 rq_state, bool long_str); 241 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH 3/3] scsi: myrs: prevent negatives in disable_enclosure_messages_store()
We only want the value to be zero or one.
It's not a big deal, but say we passed set value to INT_MIN, then
disable_enclosure_messages_show() would return that 12 bytes of "buf"
are initialized but actually only 3 are. I think there are tools like
KASAN which will trigger an info leak warning when that happens.
Fixes: 77266186397c ("scsi: myrs: Add Mylex RAID controller (SCSI interface)")
Signed-off-by: Dan Carpenter
---
drivers/scsi/myrs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/myrs.c b/drivers/scsi/myrs.c
index 07e5a3f54e31..55842ed54231 100644
--- a/drivers/scsi/myrs.c
+++ b/drivers/scsi/myrs.c
@@ -1501,7 +1501,7 @@ static ssize_t disable_enclosure_messages_store(struct
device *dev,
if (ret)
return ret;
- if (value > 2)
+ if (value < 0 || value > 2)
return -EINVAL;
cs->disable_enc_msg = value;
--
2.11.0
[PATCH 2/3] scsi: myrs: Fix the processor absent message in processor_show()
If both processors are absent then it's supposed to print that, but
instead we print that just the second processor is absent.
Fixes: 77266186397c ("scsi: myrs: Add Mylex RAID controller (SCSI interface)")
Signed-off-by: Dan Carpenter
---
drivers/scsi/myrs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/myrs.c b/drivers/scsi/myrs.c
index b02ee0b0dd55..07e5a3f54e31 100644
--- a/drivers/scsi/myrs.c
+++ b/drivers/scsi/myrs.c
@@ -1366,11 +1366,11 @@ static ssize_t processor_show(struct device *dev,
first_processor, info->cpu[0].cpu_count,
info->cpu[1].cpu_name,
second_processor, info->cpu[1].cpu_count);
- else if (!second_processor)
+ else if (first_processor && !second_processor)
ret = snprintf(buf, 64, "1: %s (%s, %d cpus)\n2: absent\n",
info->cpu[0].cpu_name,
first_processor, info->cpu[0].cpu_count);
- else if (!first_processor)
+ else if (!first_processor && second_processor)
ret = snprintf(buf, 64, "1: absent\n2: %s (%s, %d cpus)\n",
info->cpu[1].cpu_name,
second_processor, info->cpu[1].cpu_count);
--
2.11.0
Re: Looking for some help understanding error handling
On 05/10/2018 16:51, chris.mo...@microchip.com wrote: Thanks Hannes, After some pointers from Shane Seymour I found that the FC and SRP transport layers have a devloss timer, so that when a device disappears they hold on to the target information for a time waiting to see if it comes back. The SAS transport layer doesn't have that feature. The options for me then would be to modify scsi_transport_sas.c to implement the devloss timeout, or to put that functionality into my LLDD. I'm willing to put the work into the SAS transport and libsas, but I suspect there's not a universal need for it. And since my LLDD is for internal use at our company and won't be upstreamed, I'll probably just do the work there. If anyone feels that this is a feature that more people would want then I'll look into doing that. Hello, This feature sounds interesting for libsas. I however have a question on feasibility of devloss here (note: I'm not familiar with the concept/realization for other standards): if a device is deattached and re-attached, how can we confirm the same device? For SAS device it's ok as a disk has the WWN, but what about SATA? Thanks, John Thanks, Chris -Original Message- From: Hannes Reinecke [mailto:h...@suse.de] Sent: Friday, October 5, 2018 8:01 AM To: Chris Moore - C33997 ; linux- s...@vger.kernel.org Subject: Re: Looking for some help understanding error handling On 10/2/18 11:04 PM, chris.mo...@microchip.com wrote: I'm working on LLDD for a SAS/SATA host adapter, and trying to understand how the system handles link loss and recovery. Say I have a device that gets recognized and attached as sd 12:0:4:0, at /dev/sdb. The drive goes offline temporarily, then comes back online. When it does, it comes back as sd 12:0:5:0, and maybe /dev/sdb, maybe /dev/sdc. I'm not sure how the Id gets assigned. Since this is the same drive, is there some way my driver can tell libsas and/or SCSI core that it's the same drive coming back? Or is there no way to control that? Not really. The target device is getting destroyed once the device disconnects, and when it reconnects a new structure is allocated. But as the target number is a simple counter it gets increased up each allocation. I looked into /dev/disk/by-id, but that also didn't quite do what I expected. If I open /dev/disk/by-id/some_identifier, that's a symlink to, say, /dev/sdb. Yes. /dev/sdb goes away, comes back as /dev/sdc, but my process doesn't know that, it still has /dev/disk/by-id/some_identifier opened and so it will never recover without closing and reopening the file. Simply don't keep hold of the symlink; once you have opened you'll miss any updates to the symlink itself. So better to open the symlink, check the device, do whatever needs to be done, and _close the symlink_ again. Then you can listen for udev events telling you when a device appears or vanishes. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
[PATCH 1/3] scsi: myrs: Fix a logical vs bitwise bug
The || was supposed to be |. The original code just sets ->result to 1.
Fixes: 77266186397c ("scsi: myrs: Add Mylex RAID controller (SCSI interface)")
Signed-off-by: Dan Carpenter
---
drivers/scsi/myrs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/myrs.c b/drivers/scsi/myrs.c
index b02ee0b0dd55..17e691bde485 100644
--- a/drivers/scsi/myrs.c
+++ b/drivers/scsi/myrs.c
@@ -2085,7 +2085,7 @@ static void myrs_handle_scsi(struct myrs_hba *cs, struct
myrs_cmdblk *cmd_blk,
status == MYRS_STATUS_DEVICE_NON_RESPONSIVE2)
scmd->result = (DID_BAD_TARGET << 16);
else
- scmd->result = (DID_OK << 16) || status;
+ scmd->result = (DID_OK << 16) | status;
scmd->scsi_done(scmd);
}
--
2.11.0
Re: [PATCH 3/8] sg: split header, expand and correct descriptions
On 19/10/18 08:24, Douglas Gilbert wrote: > +/* Alternate style type names, "..._t" variants preferred */ > +typedef struct sg_io_hdr Sg_io_hdr; > +typedef struct sg_io_vec Sg_io_vec; > +typedef struct sg_scsi_id Sg_scsi_id; > +typedef struct sg_req_info Sg_req_info; There are no _t variants for the above, or am I missing something? -- Johannes ThumshirnSUSE Labs jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH 4/8] sg: expand request states
Looks good (but the ifdefs are creepy), Reviewed-by: Johannes Thumshirn -- Johannes ThumshirnSUSE Labs jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH] smartpqi: Fix timeout of smartpqi probe stage
Just Ping. This is a very serious issue. The OS boot from this raid controller couldn't find bock devices after installing OS. I think this patch should be merged asap. Feng Li 于2018年10月12日周五 上午11:13写道： > > I use 'HPE Smart Array E208i-a SR Gen10 Controller', and pass through > the SAS controller from ESXi 6.0U1 to VM, which is installed CentOS 7.4/7.5. > The disk is not found. > > The error log is "controller not ready after 30 seconds." > > Add some logs, and could check the probe stage needs nearly 36s to match the > status. > > Signed-off-by: Li Feng > --- > drivers/scsi/smartpqi/smartpqi_sis.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/smartpqi/smartpqi_sis.c > b/drivers/scsi/smartpqi/smartpqi_sis.c > index 5141bd4c9..bc7efdacb 100644 > --- a/drivers/scsi/smartpqi/smartpqi_sis.c > +++ b/drivers/scsi/smartpqi/smartpqi_sis.c > @@ -59,7 +59,7 @@ > > #define SIS_CTRL_KERNEL_UP 0x80 > #define SIS_CTRL_KERNEL_PANIC 0x100 > -#define SIS_CTRL_READY_TIMEOUT_SECS 30 > +#define SIS_CTRL_READY_TIMEOUT_SECS 90 > #define SIS_CTRL_READY_RESUME_TIMEOUT_SECS 90 > #define SIS_CTRL_READY_POLL_INTERVAL_MSECS 10 > > -- > 2.11.0 -- Thanks and Best Regards, Feng Li(Alex)
Re: [PATCH 2/8] sg: introduce sg_log macro
On 19/10/18 08:24, Douglas Gilbert wrote:
[..]
> +/*
> + * Kernel needs to be built with CONFIG_SCSI_LOGGING to see log messages.
> + * 'depth' is a number between 1 (most severe) and 7 (most noisy, most
> + * information). All messages are logged as informational (KERN_INFO). In
> + * the unexpected situation where sdp is NULL the macro reverts to a pr_info
> + * and ignores CONFIG_SCSI_LOGGING and always prints to the log.
> + */
> +#define SG_LOG(depth, sdp, fmt, a...)\
> + do {\
> + if (IS_ERR_OR_NULL(sdp)) { \
> + pr_info("sg: sdp=NULL_or_ERR, " fmt, ##a); \
> + } else {\
> + SCSI_LOG_TIMEOUT(depth, sdev_prefix_printk( \
> + KERN_INFO, (sdp)->device, \
> + (sdp)->disk->disk_name, fmt, \
> + ##a)); \
> + } \
> + } while (0)
Hi Doug,
have you considered using the kernel's dynamic debug infrastructure instead?
--
Johannes ThumshirnSUSE Labs
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH 1/8] sg: types and naming cleanup
On 19/10/18 08:24, Douglas Gilbert wrote: > Remove typedefs and use better type names like bool and u8 where > appropriate. Rename some variables and functions for clarity. > Adjust formatting (e.g. function definitions) to be more > consistent across the driver. Thanks a lot Doug, this is highly appreciated. I have one minor Nit if you need to resend the series, please remove the casts form void* (mostly filp->private_data). Otherwise: Reviewed-by: Johannes Thumshirn -- Johannes ThumshirnSUSE Labs jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: move bus (PCI, PCMCIA, EISA, rapdio) config to drivers/ v2
Hi Christoph,
On Fri, Oct 19, 2018 at 9:10 AM Christoph Hellwig wrote:
> On Fri, Oct 19, 2018 at 09:07:51AM +0200, Geert Uytterhoeven wrote:
> > Without this:
> > - It's hard to visually match your untagged cover letter with the
> > actual patches,
> > - Your individual patches lack the version info, so people cannot see
> > which
> > version review comments in an email reply apply to.
>
> All of that is trivially solved by mail threading.
You forgot to answer this question:
| Can you please clarify what exactly that would mess up?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: move bus (PCI, PCMCIA, EISA, rapdio) config to drivers/ v2
On Fri, Oct 19, 2018 at 09:07:51AM +0200, Geert Uytterhoeven wrote: > Without this: > - It's hard to visually match your untagged cover letter with the > actual patches, > - Your individual patches lack the version info, so people cannot see which > version review comments in an email reply apply to. All of that is trivially solved by mail threading.
Re: move bus (PCI, PCMCIA, EISA, rapdio) config to drivers/ v2
Hi Christoph,
On Fri, Oct 19, 2018 at 9:00 AM Christoph Hellwig wrote:
> On Wed, Oct 17, 2018 at 10:30:49AM +0200, Geert Uytterhoeven wrote:
> > Please use "git format-patch -v --cover" to prepare patch series
> > for sending with git-send-email.
> >
> > "-v" to prefix all patches with version number ,
> > "--cover" to have a "[PATCH 0/]" prefix in the cover letter.
>
> We had that discussion before and I strongly disagree with messing
> up the subject lines like that. The git-send-email defaults are
> perfectly fine.
Can you please clarify what exactly that would mess up?
Documentation/process/submitting-patches.rst even mentions the tags
to put in "[PATCH ]"?
Without this:
- It's hard to visually match your untagged cover letter with the
actual patches,
- Your individual patches lack the version info, so people cannot see which
version review comments in an email reply apply to.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 7/8] eisa: consolidate EISA Kconfig entry in drivers/eisa
On Fri, Oct 19, 2018 at 01:46:50PM +0900, Masahiro Yamada wrote: > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -59,6 +59,7 @@ config ARM > > select HAVE_ARCH_TRACEHOOK > > select HAVE_ARM_SMCCC if CPU_V7 > > select HAVE_EBPF_JIT if !CPU_ENDIAN_BE32 > > + select HAVE_EISA > > I doubt this. > > arch/arm/Kconfig previously did not include > driver/eisa/Kconfig. > > No ARM platform enabled CONFIG_EISA either. But it did offer the EISA option. I guess I can remove this in a separate commit and see if anyone screams.
Re: [PATCH] scsi: myrs: fix build failure on 32 bit
On 10/19/18 1:50 AM, James Bottomley wrote:
For 32 bit versions we have to be careful about divisions of 64 bit
quantities so use do_div() instead of a direct division. This fixes a
warning about _uldivmod being undefined in certain configurations
Fixes: 77266186397c ("scsi: myrs: Add Mylex RAID controller")
Reported-by: kbuild test robot
Signed-off-by: James Bottomley
---
drivers/scsi/myrs.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/myrs.c b/drivers/scsi/myrs.c
index b02ee0b0dd55..a9f9c77e889f 100644
--- a/drivers/scsi/myrs.c
+++ b/drivers/scsi/myrs.c
@@ -1978,7 +1978,8 @@ myrs_get_resync(struct device *dev)
struct scsi_device *sdev = to_scsi_device(dev);
struct myrs_hba *cs = shost_priv(sdev->host);
struct myrs_ldev_info *ldev_info = sdev->hostdata;
- u8 percent_complete = 0, status;
+ u64 percent_complete = 0;
+ u8 status;
if (sdev->channel < cs->ctlr_info->physchan_present || !ldev_info)
return;
@@ -1986,8 +1987,8 @@ myrs_get_resync(struct device *dev)
unsigned short ldev_num = ldev_info->ldev_num;
status = myrs_get_ldev_info(cs, ldev_num, ldev_info);
- percent_complete = ldev_info->rbld_lba * 100 /
- ldev_info->cfg_devsize;
+ percent_complete = ldev_info->rbld_lba * 100;
+ do_div(percent_complete, ldev_info->cfg_devsize);
}
raid_set_resync(myrs_raid_template, dev, percent_complete);
}
Thanks James.
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
Re: [PATCH 4/8] PCI: consolidate PCI config entry in drivers/pci
On Fri, Oct 19, 2018 at 02:07:04PM +0900, Masahiro Yamada wrote: > We could add 'depends on HAVE_PCI' or something > to guard it to avoid changing the logic. I guess that makes sense. > config PCI_ENDPOINT > bool "PCI Endpoint Support" > depends on HAVE_PCI # Is this correct ?? > depends on HAS_DMA > > > or better to have 'depends on PCI' ? It does not depend on the normal PCI support, so I don't think this is the right thing to do.
Re: move bus (PCI, PCMCIA, EISA, rapdio) config to drivers/ v2
On Wed, Oct 17, 2018 at 10:30:49AM +0200, Geert Uytterhoeven wrote: > Please use "git format-patch -v --cover" to prepare patch series > for sending with git-send-email. > > "-v" to prefix all patches with version number , > "--cover" to have a "[PATCH 0/]" prefix in the cover letter. We had that discussion before and I strongly disagree with messing up the subject lines like that. The git-send-email defaults are perfectly fine.
