RE: [PATCH] aacraid 2.6: Fix aacraid probe breakage inscsi-block-2.6.git

RE: [PATCH] aacraid 2.6: Fix aacraid probe breakage inscsi-block-2.6.git

[Salyzyn, Mark]

The code does not 'damage' the scsi-misc tree version, so why not apply
it to the scsi-misc tree as well at least to make sure it does not
(extending the test coverage)? What is the scsi-block timetable for
downstream?

I have almost religiously applied all patches that touch the driver to
the Adaptec branch here. The net result is I have caught some gaffs
early on because we always have some test or Q/A program ready to give
it coverage.

Sincerely -- Mark Salyzyn

-----Original Message-----
From: James Bottomley [mailto:James.Bottomley@SteelEye.com] 
Sent: Monday, August 15, 2005 1:01 PM
To: Mark Haverkamp
Cc: linux-scsi; Salyzyn, Mark
Subject: Re: [PATCH] aacraid 2.6: Fix aacraid probe breakage
inscsi-block-2.6.git

On Mon, 2005-08-15 at 09:53 -0700, Mark Haverkamp wrote:
> This patch fixes the bad assumption of the aacraid driver with use_sg.
> I used the 3w-xxxx driver fix as a guide for this.

Yes, that looks about right

> The patch applies to the scsi-block-2.6 git tree. Is that the right
> place for the patch?  Should it be applied to the scsi-misc or the
scsi-
> rc-fixes tree instead?

That's correct.  The problems are only caused by the scsi-block-2.6 tree
(I don't think too many people send INQUIRY or MODE_SENSE via SG_IO, so
no-one's reported the breakage in the main tree yet).

James

RE: [PATCH] aacraid 2.6: Fix aacraid probe breakage inscsi-block-2.6.git

[James Bottomley]

On Mon, 2005-08-15 at 13:06 -0400, Salyzyn, Mark wrote:
> The code does not 'damage' the scsi-misc tree version, so why not apply
> it to the scsi-misc tree as well at least to make sure it does not
> (extending the test coverage)? What is the scsi-block timetable for
> downstream?

OK, that's true ... there's no reason not to.

> I have almost religiously applied all patches that touch the driver to
> the Adaptec branch here. The net result is I have caught some gaffs
> early on because we always have some test or Q/A program ready to give
> it coverage.

Yes, early and often ... just in case the scsi-block merge gets delayed
again.

James