> On Tue, 2013-05-07 at 17:25 +0300, Dan Carpenter wrote:
>> Hello Dolev Raviv,
>>
>> This is a semi-automatic email about new static checker warnings.
>>
>> The patch 3aee47c623a3: "[SCSI] ufs: add support for query requests"
>> from May 2, 2013, leads to the following Smatch complaint:
>>
>> dri
Thanks for fix.
Lindar.
-Original Message-
From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
Sent: Wednesday, May 08, 2013 5:44 AM
To: linux-scsi
Cc: Lukasz Dorau; Maciej Patelczyk; Dave Jiang; xjtu...@gmail.com;
lindar_...@usish.com; Xiangliang Yu
Subject: [PATCH] sas
On Tue, 2013-05-07 at 13:26 -0700, Kamaljit Singh wrote:
> > I wouldn't do it that way. Since everything has to form a command IU
> > anyway by copying, I'd just make sas_ssp->cdb a pointer to the actual
> > command instead of an array of the command; if it points to the
> I'd prefer that too, spe
On Tue, 2013-05-07 at 17:25 +0300, Dan Carpenter wrote:
> Hello Dolev Raviv,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch 3aee47c623a3: "[SCSI] ufs: add support for query requests"
> from May 2, 2013, leads to the following Smatch complaint:
>
> drivers/scs
These enums have been separate since the dawn of SAS, mainly because the
latter is a procotol only enum and the former includes additional state
for libsas. The dichotomy causes endless confusion about which one you
should use where and leads to pointless warnings like this:
drivers/scsi/mvsas/mv
On Tue, 2013-05-07 at 12:57 -0400, Kyle McMartin wrote:
> device_type is a sas_device_type, not a sas_dev_type.
Heh, months ago, someone who submitted the same trivial but insufficient
fix was asked to go and see if they could unify sas_device_type and
sas_dev_type, which is the correct fix. They
> I wouldn't do it that way. Since everything has to form a command IU
> anyway by copying, I'd just make sas_ssp->cdb a pointer to the actual
> command instead of an array of the command; if it points to the
I'd prefer that too, specially since scsi_cmnd->cmnd is already a pointer. I
considered
On Tue, 2013-05-07 at 12:46 -0700, Kamaljit Singh wrote:
> James, Jack,
>
> Thanks for your responses.
>
> > I don't understand the question ... it should just work; is it
> broken?
> sas_create_task() only copies 16 bytes to the sas_ssp_task struct’s
> cdb field, which itself is a 16 byte wide
James, Jack,
Thanks for your responses.
> I don't understand the question ... it should just work; is it broken?
sas_create_task() only copies 16 bytes to the sas_ssp_task struct’s cdb field,
which itself is a 16 byte wide array. So it looks like sas_queuecommand()
doesn’t support a 32-byte c
device_type is a sas_device_type, not a sas_dev_type.
1 drivers/scsi/mvsas/mv_sas.c: In function 'mvs_update_phyinfo':
2 drivers/scsi/mvsas/mv_sas.c:1162:34: warning: comparison between
'enum sas_device_type' and 'en
In include/uapi/linux/capability.h, next to CAP_SYS_ADMIN, one will find
the notice
/* Allow enabling/disabling tagged queuing on SCSI controllers and sending
arbitrary SCSI commands */
#define CAP_SYS_ADMIN 21
To the best of my knowledge, arbitrary commands can be issued with
the SG_IO io
On 5/7/2013 2:57 PM, Seungwon Jeon wrote:
> On Monday, May 06, 2013, Sujit Reddy Thumma wrote:
>> As part of device initialization sequence, sending NOP OUT UPIU and
>> waiting for NOP IN UPIU response is mandatory. This confirms that the
>> device UFS Transport (UTP) layer is functional and the ho
Hello Dolev Raviv,
This is a semi-automatic email about new static checker warnings.
The patch 3aee47c623a3: "[SCSI] ufs: add support for query requests"
from May 2, 2013, leads to the following Smatch complaint:
drivers/scsi/ufs/ufshcd.c:723 ufshcd_query_request()
error: we previously
From: Wei Yongjun
Fix to return -ENOMEM in the ecardm_iomap() error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/scsi/arm/acornscsi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/arm/acornscsi.c b/
Hi James,
Got it. Will be more careful next time.
Regards
Anand
-Original Message-
From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
Sent: Tuesday, May 07, 2013 11:37 AM
To: Anand Kumar Santhanam
Cc: linux-scsi@vger.kernel.org; sakthivel...@hcl.com; Sangeetha
Gnanasek
On Monday, May 06, 2013, Sujit Reddy Thumma wrote:
> As part of device initialization sequence, sending NOP OUT UPIU and
> waiting for NOP IN UPIU response is mandatory. This confirms that the
> device UFS Transport (UTP) layer is functional and the host can configure
> the device with further comm
16 matches
Mail list logo
