Hi,
On Thu, 2019-03-21 at 01:45 +, YueHaibing wrote:
> Remove .owner field if calls are used which set it automatically
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
>
> Signed-off-by: YueHaibing
> ---
> drivers/scsi/ufs/ufs-mediatek.c | 1 -
> 1 file changed, 1 deletio
When I use dd test a SCSI device which use blk-mq in the following steps:
1.echo "blocked" >/sys/block/sda/device/state
2.dd if=/dev/sda of=/mnt/t.log bs=1M count=10
3.echo "running" >/sys/block/sda/device/state
dd should finish this work after step 3, unfortunately, still hung.
After step2, the k
On 3/20/19 8:21 PM, zhengbin wrote:
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 6a9040f..ce60408 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -770,7 +770,20 @@ store_state_field(struct device *dev, struct
device_attribute *attr,
Hi Ming
On 3/21/19 11:55 AM, Ming Lei wrote:
> On Thu, Mar 21, 2019 at 11:21:20AM +0800, zhengbin wrote:
>> When I use dd test a SCSI device which use blk-mq in the following steps:
>> 1.echo "blocked" >/sys/block/sda/device/state
>> 2.dd if=/dev/sda of=/mnt/t.log bs=1M count=10
>> 3.echo "running
On Thu, Mar 21, 2019 at 11:21:20AM +0800, zhengbin wrote:
> When I use dd test a SCSI device which use blk-mq in the following steps:
> 1.echo "blocked" >/sys/block/sda/device/state
> 2.dd if=/dev/sda of=/mnt/t.log bs=1M count=10
> 3.echo "running" >/sys/block/sda/device/state
> dd should finish th
When I use dd test a SCSI device which use blk-mq in the following steps:
1.echo "blocked" >/sys/block/sda/device/state
2.dd if=/dev/sda of=/mnt/t.log bs=1M count=10
3.echo "running" >/sys/block/sda/device/state
dd should finish this work after step 3, unfortunately, still hung.
After step2, the k
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: YueHaibing
---
drivers/scsi/ufs/ufs-mediatek.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/uf
Bart,
> You are right of course. The reason I would like to inline that
> function is because it was essential in the past to have that code as
> a separate function but after patch 1/2 inlining that function makes
> sd_probe() easier to read. Martin, do you want me to resubmit this
> patch ser
James,
> Declaring interrupt clear routines as inline is bogus as they are used
> as an indirect pointer.
>
> Remove the inline references
Applied this and James' fix to 5.2/scsi-queue. Thanks.
--
Martin K. Petersen Oracle Linux Engineering
On Wed, 2019-03-20 at 13:28 -0700, Bart Van Assche wrote:
> On Wed, 2019-03-20 at 11:11 -0400, Laurence Oberman wrote:
> > On Wed, 2019-03-20 at 09:45 -0400, Laurence Oberman wrote:
> > > Hello Bart, I hope all is well with you.
> > >
> > > Quick question
> > > preparing to test v5.1-rc2 SRP, my u
On Wed, 2019-03-20 at 11:11 -0400, Laurence Oberman wrote:
> On Wed, 2019-03-20 at 09:45 -0400, Laurence Oberman wrote:
> > Hello Bart, I hope all is well with you.
> >
> > Quick question
> > preparing to test v5.1-rc2 SRP, my usual method is first validate the
> > prior kernel I had in place.
> >
On Wed, 2019-03-20 at 21:14 +0100, Greg Kroah-Hartman wrote:
> On Wed, Mar 20, 2019 at 01:09:20PM -0700, Bart Van Assche wrote:
> > This patch does not change any functionality.
>
> Then why do it?
>
> You need to say _why_ a patch is needed in order for people to want to
> take it...
Hi Greg,
On Wed, Mar 20, 2019 at 01:09:20PM -0700, Bart Van Assche wrote:
> This patch does not change any functionality.
Then why do it?
You need to say _why_ a patch is needed in order for people to want to
take it...
thanks,
greg k-h
Hi Martin,
Now that patch the patch series that includes "driver core: Probe devices
asynchronously instead of the driver" is upstream I'm resubmitting the patch
series that makes the sd driver rely on the driver core for asynchronous
probing. Please consider this patch series for kernel v5.2.
Th
This patch does not change any functionality.
Cc: Lee Duncan
Cc: Hannes Reinecke
Cc: Luis Chamberlain
Cc: Johannes Thumshirn
Cc: Christoph Hellwig
Cc: Greg Kroah-Hartman
Signed-off-by: Bart Van Assche
---
drivers/scsi/sd.c | 101 --
1 file change
As explained during the 2018 LSF/MM session about increasing SCSI
disk probing concurrency, the problems with the current probing
approach are as follows:
- The driver core is unaware of asynchronous SCSI LUN probing.
wait_for_device_probe() waits for all asynchronous probes except
asynchronous
On Wed, Mar 13, 2019 at 10:43 PM Sreekanth Reddy
wrote:
>
> On Tue, Mar 12, 2019 at 3:46 PM Sreekanth Reddy
> wrote:
> >
> > On Tue, Mar 12, 2019 at 3:17 PM Michal Soltys wrote:
> > >
> > > On 3/11/19 10:17 AM, Sreekanth Reddy wrote:
> > > > On Fri, Mar 8, 2019 at 6:52 PM Christoph Hellwig
> >
On 3/20/2019 8:21 AM, Martin K. Petersen wrote:
James,
So there are a couple of other instances you can fix at your leisure:
they're not causing immediate linux-next problems because the body of
they're only apparently used within one file so the body is available,
but if the use expands we'll
Declaring interrupt clear routines as inline is bogus as they are used as an
indirect pointer.
Remove the inline references
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
drivers/scsi/lpfc/lpfc_sli.c | 4 ++--
drivers/scsi/lpfc/lpfc_sli4.h | 4 ++--
2 files changed, 4 insertions(
On 3/19/19, 11:26 PM, "Nathan Chancellor" wrote:
External Email
--
On Tue, Mar 12, 2019 at 11:08:18AM -0700, Himanshu Madhani wrote:
> From: Joe Carnuccio
>
> This patch made following changes to
James,
> So there are a couple of other instances you can fix at your leisure:
> they're not causing immediate linux-next problems because the body of
> they're only apparently used within one file so the body is available,
> but if the use expands we'll get the same problem:
>
> lpfc_sli4.h:inl
On Tue, 2019-03-19 at 20:35 -0700, James Smart wrote:
> > On Mar 19, 2019, at 6:02 PM, James Bottomley > nPartnership.com> wrote:
> >
> > On Tue, 2019-03-12 at 16:30 -0700, James Smart wrote:
> > > Currently the driver maintains a sideband structure which has a
> > > pointer for each queue elemen
On Wed, 2019-03-20 at 09:45 -0400, Laurence Oberman wrote:
> Hello Bart, I hope all is well with you.
>
> Quick question
> preparing to test v5.1-rc2 SRP, my usual method is first validate the
> prior kernel I had in place.
> This had passed tests previously (5.0.0-rc2) but I had not run the
> tar
Hello Bart, I hope all is well with you.
Quick question
preparing to test v5.1-rc2 SRP, my usual method is first validate the
prior kernel I had in place.
This had passed tests previously (5.0.0-rc2) but I had not run the
target server reboot test, just the disconnect tests.
Today with mapped SRP
Hi all,
here's a fix for a long-standing issue in the 'ch' driver where we would
crash if one of the referenced devices was removed from underneath us.
As usual, comments and reviews are welcome.
Hannes Reinecke (2):
ch: add missing mutex_lock()/mutex_unlock() in ch_release()
ch: fixup refco
The SCSI device is required to be present during 'ch_probe'
and ch_open(), but as we cannot known whether ch_release()
or ch_remove() will be called first we should blank out the
pointer to the SCSI device in ch_destroy(), not in ch_release().
Signed-off-by: Hannes Reinecke
---
drivers/scsi/ch.c
The 'ch_mutex" is meant to guard against modifications of
file->private_data, so we need to take in in ch_release() as
well as in ch_open().
Signed-off-by: Hannes Reinecke
---
drivers/scsi/ch.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/ch.c b/drivers/scsi/ch.c
index 1c50
27 matches
Mail list logo
