Swap the I/O memory read value back to cpu endianness before storing it
in a data structures which are defined in the MPI headers where
u8 components are not defined in the endianness order.
In this area from day one mpt3sas driver is using le32_to_cpu() &
cpu_to_le32() APIs. But in the patch
In mpt3sas_base_clear_st() function smid value is reseted in wrong line,
i.e. driver should reset smid value to zero after decrementing chain_offset
counter in chain_lookup table but in current code, driver is resetting smid
value before decrementing the chain_offset counter. which we are
Hi Martin,
> On Jul 30, 2018, at 7:29 PM, Martin K. Petersen
> wrote:
>
> External Email
>
> Himanshu,
>
>> This patch series addresses issue with N2N connection for FCP and
>> FC-NVMe by moving login to state machine and handle various state
>> change.
>>
>> Please apply this series to
Arjun,
> + switch (density) {
> + case 0x14: /* 1MB */
> + size = 1 << 20;
> + break;
It seems a bit silly to have a switch statement for this. Why not just
do:
size = 1 << density;
?
> + case 0x15: /* 2MB
Mike,
> The first patch fixes a locking bug in the command setup path. The
> rest of the patches fix several bugs and cleanup the setup and
> configuration code paths.
Applied to 4.19/scsi-queue. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
Bart,
> The two patches in this series suppress one gcc 8 compiler warning and
> one sparse warning. Please consider these for kernel v4.19.
Applied to 4.19/scsi-queue, thanks!
--
Martin K. Petersen Oracle Linux Engineering
Bart,
> Tell snprintf() to store at most 255 characters in the output buffer
> instead of 256. This patch avoids that smatch reports the following
> warning:
Applied to 4.18/scsi-fixes. Thank you!
--
Martin K. Petersen Oracle Linux Engineering
Himanshu,
> This patch series addresses issue with N2N connection for FCP and
> FC-NVMe by moving login to state machine and handle various state
> change.
>
> Please apply this series to 4.19/scsi-queue at your earliest.
Does not apply, patch #2 fails. Please resubmit, thanks!
--
Martin K.
Himanshu,
> In the case of IOCB QFull, Initiator code can leave behind a stale
> pointer to an SRB structure on the outstanding command array.
Applied to 4.18/scsi-fixes. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
This patch avoids that building with W=1 causes the compiler to
complain about fall-through.
Signed-off-by: Bart Van Assche
Cc: Lee Duncan
Cc: Chris Leech
---
drivers/scsi/libiscsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index
This patch avoids that sparse reports the following:
drivers/scsi/libiscsi.c:1844:23: warning: context imbalance in
'iscsi_exec_task_mgmt_fn' - unexpected unlock
Signed-off-by: Bart Van Assche
Signed-off-by: Lee Duncan
Signed-off-by: Chris Leech
---
drivers/scsi/libiscsi.c | 1 +
1 file
Hello Martin,
The two patches in this series suppress one gcc 8 compiler warning and one
sparse warning. Please consider these for kernel v4.19.
Note: these patches had been posted for the first time a while ago but I had
not yet had the time to send these to you. See also
On 2018-07-30 02:13 PM, Hannes Reinecke wrote:
On 07/30/2018 08:01 PM, Bart Van Assche wrote:
On Sun, 2018-07-29 at 16:33 +0300, Avri Altman wrote:
Here is a proposal to use the scsi transport subsystem to manage
ufs devices.
scsi transport is a framework that allow to send scsi commands to
a
A long time ago the unfortunate decision was taken to add a self-
deletion attribute to the sysfs SCSI device directory. That decision
was unfortunate because self-deletion is really tricky. We can't drop
that attribute because widely used user space software depends on it,
namely the
Hello Martin,
This patch series avoids that SCSI device removal through sysfs triggers a
deadlock. Please consider this patch series for the v4.19 kernel.
Thanks,
Bart.
Bart Van Assche (2):
sysfs: Introduce sysfs_{un,}break_active_protection()
Avoid that SCSI device removal through sysfs
Introduce these two functions and export them such that the next patch
can add calls to these functions from the SCSI core.
Signed-off-by: Bart Van Assche
Cc: Greg Kroah-Hartman
Cc: Tejun Heo
Cc:
---
fs/sysfs/file.c | 44 +++
On 07/30/2018 08:01 PM, Bart Van Assche wrote:
On Sun, 2018-07-29 at 16:33 +0300, Avri Altman wrote:
Here is a proposal to use the scsi transport subsystem to manage
ufs devices.
scsi transport is a framework that allow to send scsi commands to
a non-scsi devices. Still, it is flexible enough
On Sun, 2018-07-29 at 16:33 +0300, Avri Altman wrote:
> Here is a proposal to use the scsi transport subsystem to manage
> ufs devices.
>
> scsi transport is a framework that allow to send scsi commands to
> a non-scsi devices. Still, it is flexible enough to allow
> sending non-scsi commands as
Hello,
On Mon, Jul 30, 2018 at 05:50:02PM +, Bart Van Assche wrote:
> On Mon, 2018-07-30 at 10:31 -0700, t...@kernel.org wrote:
> > On Mon, Jul 30, 2018 at 05:28:11PM +, Bart Van Assche wrote:
> > > It's not clear to me how the sysfs_break_active_protection() should obtain
> > > the
On Mon, 2018-07-30 at 10:31 -0700, t...@kernel.org wrote:
> On Mon, Jul 30, 2018 at 05:28:11PM +, Bart Van Assche wrote:
> > It's not clear to me how the sysfs_break_active_protection() should obtain
> > the struct kernfs_node pointer to the attribute. Calling that function
> > before
> >
Hello, Bart.
On Mon, Jul 30, 2018 at 05:28:11PM +, Bart Van Assche wrote:
> It's not clear to me how the sysfs_break_active_protection() should obtain
> the struct kernfs_node pointer to the attribute. Calling that function before
> device_remove_file_self() causes a double call to
>
On Mon, 2018-07-30 at 07:13 -0700, t...@kernel.org wrote:
> Also, wouldn't it be better to just expose sysfs_break/unbreak and
> then do sth like the following from scsi?
>
> kobject_get();
> sysfs_break_active_protection();
> do normal sysfs removal;
>
Good day
I am contacting you regarding a project i wish to execute with you,i
will send you a comprehensive report once i get your response with
your name and phone number to my mail.
Regards,
Mr.James Robertson
On Sun, Jul 29, 2018 at 04:03:41AM +, Bart Van Assche wrote:
> On Thu, 2018-07-26 at 06:35 -0700, Tejun Heo wrote:
> > Making removal asynchronous this way sometimes causes issues because
> > whether the user sees the device released or not is racy.
>
> Hello Tejun,
>
> How could this change
Hello, Bart.
On Thu, Jul 26, 2018 at 09:57:40PM +, Bart Van Assche wrote:
...
> @@ -440,11 +445,21 @@ bool sysfs_remove_file_self(struct kobject *kobj, const
> struct attribute *attr)
> return false;
>
> ret = kernfs_remove_self(kn);
> + if (ret && cb) {
> +
25 matches
Mail list logo
