[PATCH 2/2] scsi: ufs: add Exynos-specific driver

This driver is to use UFS devices on Exynos SoC and has been already used for many years for commercial products. Signed-off-by: Kiwoong Kim --- drivers/scsi/ufs/Kconfig | 10 + drivers/scsi/ufs/Makefile | 1 + drivers/scsi/ufs/ufs-exynos.c | 962

[PATCH 1/2] scsi: ufs: add some definition included in UFS HCI specifications

These would be used in the future in some specific drivers. Signed-off-by: Kiwoong Kim --- drivers/scsi/ufs/ufshci.h | 16 1 file changed, 16 insertions(+) diff --git a/drivers/scsi/ufs/ufshci.h b/drivers/scsi/ufs/ufshci.h index

[PATCH] libsas: flush pending destruct work in sas_unregister_domain_devices()

We saw dozens of the following kernel waring: WARNING: CPU: 0 PID: 705 at fs/sysfs/group.c:224 sysfs_remove_group+0x54/0x88() sysfs group 81ab7670 not found for kobject '6:0:3:0' Modules linked in: cpufreq_ondemand x86_pkg_temp_thermal coretemp kvm_intel kvm microcode raid0 iTCO_wdt

Re: [PATCH] Ensure that the SCSI error handler gets woken up

On Mon, 2017-11-27 at 15:53 -0600, Stuart Hayes wrote: > Could you modify this patch to make scsi_dec_host_busy() get the spin lock > right before checking host_failed instead of right after, like Pavel's patch, > to protect against this? Hello Stuart, Thanks for the feedback. I will look into

[PATCH] scsi: scsi_devinfo: handle non-terminated strings

devinfo->vendor and devinfo->model aren't necessarily zero-terminated. Fixes: b8018b973c7c "scsi_devinfo: fixup string compare" Signed-off-by: Martin Wilck --- drivers/scsi/scsi_devinfo.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

[PATCH] scsi_devinfo: cleanly zero-pad devinfo strings

Cleanly fill memory for "vendor" and "model" with 0-bytes for the "compatible" case rather than adding only a single 0 byte. This simplifies the devinfo code a a bit, and avoids mistakes in other places of the code (not in current upstream, but we had one such mistake in the SUSE kernel).

Re: [PATCH] Ensure that the SCSI error handler gets woken up

For what it's worth, this does not fix the problem that both Pavel's original patch (https://patchwork.kernel.org/patch/9938919/) and the patch I submitted (https://patchwork.kernel.org/patch/10067059/) would fix. I verified that this patch still fails on my system. The only problem I am able

Re: [PATCH] Ensure that the SCSI error handler gets woken up

On Thu, 2017-11-23 at 09:18 +0100, Christoph Hellwig wrote: > > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c > > index 5e89049e9b4e..f7f014c755d7 100644 > > --- a/drivers/scsi/scsi_error.c > > +++ b/drivers/scsi/scsi_error.c > > @@ -61,9 +61,10 @@ static int

Re: News UBSAN warnings in aacraid

On Mon, Nov 27, 2017 at 8:17 PM, Meelis Roos wrote: > Tried 4.15-rc1 on an old 32-bit HP Netserver with aacraid card. Compared > to 4.14, there are new UBSAN warnings with timer related backtraces, so > the timespec64 change seems suspicious: > [ 12.228155] UBSAN: Undefined

Re: UFS utilities

On Mon, 2017-11-27 at 11:25 +, Bean Huo (beanhuo) wrote: > Is there someone knows if exists one utilis dedicated to UFS device, > rather than SCSI utils? I have tried sg3-utils, but it is not convenient > for the embedded ARM-based system. Hello Bean, Please be more specific. What is

News UBSAN warnings in aacraid

Tried 4.15-rc1 on an old 32-bit HP Netserver with aacraid card. Compared to 4.14, there are new UBSAN warnings with timer related backtraces, so the timespec64 change seems suspicious: [ 12.228058] [

Re: 4.13.12: frequent AACraid crash with a drive

On Mon, Nov 27, 2017 at 07:21:47AM -0800, Marc MERLIN wrote: > Crash log: I should add that sometimes the reset works ok: aacraid: Host adapter abort request. aacraid: Outstanding commands on (10,1,0,0): aacraid: Host adapter reset request. SCSI hang ? aacraid :02:00.0: outstanding cmd:

4.13.12: frequent AACraid crash with a drive

Howdy, https://www.kernel.org/doc/Documentation/scsi/aacraid.txt mentions that I should Email here. This is not a new problem with a new kernel, I just switched to an adaptec 16 port SATA card, and one of the drives (apparently always the same) is causing the card to crash apparently due to not

[PATCH] scsi: lpfc: Fix potential NULL pointer dereference in lpfc_nvme_fcp_io_submit

pnvme_lport is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by null checking pnvme_lport before it is dereferenced. Addresses-Coverity-ID: 1423709 ("Dereference before null check") Fixes: b7672ae681f8 ("scsi: lpfc: Fix crash in

Re: [PATCH] scsi: debug: remove jiffies_to_timespec

On 2017-11-27 12:36 PM, Arnd Bergmann wrote: There is no need to go through an intermediate timespec to convert to ktime_t when we just want a simple multiplication. This gets rid of one of the few users of jiffies_to_timespec, which I hope to remove as part of the y2038 cleanup. Signed-off-by:

Re: [PATCH] scsi: debug: remove jiffies_to_timespec

Looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham

Re: UFS utilities

On Mon, Nov 27, 2017 at 11:25:47AM +, Bean Huo (beanhuo) wrote: > Hi, all > Is there someone knows if exists one utilis dedicated to UFS device, rather > than SCSI utils? > I have tried sg3-utils, but it is not convenient for the embedded ARM-based > system. > And also it doesn't support

[PATCH] scsi: debug: remove jiffies_to_timespec

There is no need to go through an intermediate timespec to convert to ktime_t when we just want a simple multiplication. This gets rid of one of the few users of jiffies_to_timespec, which I hope to remove as part of the y2038 cleanup. Signed-off-by: Arnd Bergmann ---

UFS utilities

Hi, all Is there someone knows if exists one utilis dedicated to UFS device, rather than SCSI utils? I have tried sg3-utils, but it is not convenient for the embedded ARM-based system. And also it doesn't support several UFS special command. If we don't have this kind of tool for UFS, is it

Re: [PATCH] scsi: libfc: fix ELS request handling

Thanks Martin, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard,