Re: [Ksummit-2013-discuss] [ATTEND] scsi-mq prototype discussion
On Tue, 2013-07-16 at 15:15 -0600, Jens Axboe wrote: > On Tue, Jul 16 2013, Nicholas A. Bellinger wrote: > > On Sat, 2013-07-13 at 06:53 +, James Bottomley wrote: > > > On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote: > > > > On 07/12/2013 03:33 AM, Nicholas A. Bellinger wrote: > > > > > On Thu, 2013-07-11 at 18:02 -0700, Greg KH wrote: > > > > >> On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger > > > > >> wrote: > > > > >>> Drilling down the work items ahead of a real mainline push is high > > > > >>> on > > > > >>> priority list for discussion. > > > > >>> > > > > >>> The parties to be included in such a discussion are: > > > > >>> > > > > >>> - Jens Axboe (blk-mq author) > > > > >>> - James Bottomley (scsi maintainer) > > > > >>> - Christoph Hellwig (scsi) > > > > >>> - Martin Petersen (scsi) > > > > >>> - Tejun Heo (block + libata) > > > > >>> - Hannes Reinecke (scsi error recovery) > > > > >>> - Kent Overstreet (block, per-cpu ida) > > > > >>> - Stephen Cameron (scsi-over-pcie driver) > > > > >>> - Andrew Vasquez (qla2xxx LLD) > > > > >>> - James Smart (lpfc LLD) > > > > >> > > > > >> Isn't this something that should have been discussed at the storage > > > > >> mini-summit a few months ago? > > > > > > > > > > The scsi-mq prototype, along with blk-mq (in it's current form) did > > > > > not > > > > > exist a few short months ago. ;) > > > > > > > > > >> It seems very specific to one subsystem to be a kernel summit topic, > > > > >> don't you think? > > > > > > > > > > It's no more subsystem specific than half of the other proposals so > > > > > far, > > > > > and given it's reach across multiple subsystems (block, scsi, target), > > > > > and the amount of off-list interest on the topic, I think it would > > > > > make > > > > > a good candidate for discussion. > > > > > > > > > And it'll open up new approaches which previously were dismissed, > > > > like re-implementing multipathing on top of scsi-mq, giving us the > > > > single scsi device like other UNIX systems. > > > > > > > > Also I do think there's quite some synergy to be had, as with blk-mq > > > > we could nail each queue to a processor, which would eliminate the > > > > need for locking. > > > > Which could be useful for other subsystems, too. > > > > > > Lets start with discussing this on the list, please, and then see where > > > we go from there ... > > > > > > > Yes, the discussion is beginning to make it's way to the list. I've > > mostly been waiting for blk-mq to get a wider review before taking the > > early scsi-mq prototype driver to a larger public audience. > > > > Primarily, I'm now reaching out to the people most effected by existing > > scsi_request_fn() based performance limitations. Most of them have > > abandoned existing scsi_request_fn() based logic in favor of raw block > > make_request() based drivers, and are now estimating the amount of > > effort to move to an scsi-mq based approach. > > > > Regardless, as the prototype progresses over the next months, having a > > face-to-face discussion with the key parties in the room would be very > > helpful given the large amount of effort involved to actually make this > > type of generational shift in SCSI actually happen. > > There's a certain amount of overlap with the aio/O_DIRECT work as well. > But if it's not a general session, could always be a BOF or something. > > I'll second the argument that most technical topics probably DO belong > in a topic related workshop. But that leaves us with basically only > process related topics at KS, I don't think it hurts to have a bit of > tech meat on the bone too. At least I personally miss that part of KS > from years gone by. Heh well, given that most of the block mq discussions at LSF have been you saying you really should get around to cleaning up and posting the code, you'll understand my wanting to see that happen first ... I suppose we could try to run a storage workshop within KS, but I think most of the mini summit slots have already gone. There's also plumbers if all slots are gone (I would say that, being biased and on the programme committee) Ric is running the storage and Filesystems MC http://www.linuxplumbersconf.org/2013/ocw/events/LPC2013/tracks/159 James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] arcmsr: Fix bug of updating ARECA Raid adapter firmware through ioctl(ARCHTTP) interface
From: chingching2...@areca.com.tw Fix bug of updating ARECA Raid adapter firmware through ioctl(ARCHTTP) interface Signed-off-by: chingching2...@areca.com.tw --- patch3 Description: Binary data
[PATCH 2/3] arcmsr: Fix command throttling for ARC188x series adapters
From: chingching2...@areca.com.tw Fix command throttling for ARC188x series adapters. Signed-off-by: chingching2...@areca.com.tw --- patch2 Description: Binary data
[PATCH] scsi/isci/port_config: Fix a infinite loop.
It seems the "phy_index++;" have been placed in wrong place, without it the while circle up will do a infinite loop. Signed-off-by: Xinghai Yu --- drivers/scsi/isci/port_config.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/isci/port_config.c b/drivers/scsi/isci/port_config.c index cd962da..85c77f6 100644 --- a/drivers/scsi/isci/port_config.c +++ b/drivers/scsi/isci/port_config.c @@ -311,9 +311,9 @@ sci_mpc_agent_validate_phy_configuration(struct isci_host *ihost, &ihost->phys[phy_index]); assigned_phy_mask |= (1 << phy_index); + phy_index++; } - phy_index++; } return sci_port_configuration_agent_validate_ports(ihost, port_agent); -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] arcmsr: Modify maxium outstanding command
From: Ching Modify maximum outstanding command number, notify command complete with auto request sense, reassign ARC12x4 series to SATA type adapter Signed-off-by: chingching2...@areca.com.tw --- patch1 Description: Binary data
Re: [Ksummit-2013-discuss] [ATTEND] scsi-mq prototype discussion
On Tue, Jul 16, 2013 at 02:07:29PM -0700, Nicholas A. Bellinger wrote: > On Sat, 2013-07-13 at 06:53 +, James Bottomley wrote: > > On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote: > > > On 07/12/2013 03:33 AM, Nicholas A. Bellinger wrote: > > > > On Thu, 2013-07-11 at 18:02 -0700, Greg KH wrote: > > > >> On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote: > > > >>> Drilling down the work items ahead of a real mainline push is high on > > > >>> priority list for discussion. > > > >>> > > > >>> The parties to be included in such a discussion are: > > > >>> > > > >>> - Jens Axboe (blk-mq author) > > > >>> - James Bottomley (scsi maintainer) > > > >>> - Christoph Hellwig (scsi) > > > >>> - Martin Petersen (scsi) > > > >>> - Tejun Heo (block + libata) > > > >>> - Hannes Reinecke (scsi error recovery) > > > >>> - Kent Overstreet (block, per-cpu ida) > > > >>> - Stephen Cameron (scsi-over-pcie driver) > > > >>> - Andrew Vasquez (qla2xxx LLD) > > > >>> - James Smart (lpfc LLD) > > > >> > > > >> Isn't this something that should have been discussed at the storage > > > >> mini-summit a few months ago? > > > > > > > > The scsi-mq prototype, along with blk-mq (in it's current form) did not > > > > exist a few short months ago. ;) > > > > > > > >> It seems very specific to one subsystem to be a kernel summit topic, > > > >> don't you think? > > > > > > > > It's no more subsystem specific than half of the other proposals so far, > > > > and given it's reach across multiple subsystems (block, scsi, target), > > > > and the amount of off-list interest on the topic, I think it would make > > > > a good candidate for discussion. > > > > > > > And it'll open up new approaches which previously were dismissed, > > > like re-implementing multipathing on top of scsi-mq, giving us the > > > single scsi device like other UNIX systems. > > > > > > Also I do think there's quite some synergy to be had, as with blk-mq > > > we could nail each queue to a processor, which would eliminate the > > > need for locking. > > > Which could be useful for other subsystems, too. > > > > Lets start with discussing this on the list, please, and then see where > > we go from there ... > > > > Yes, the discussion is beginning to make it's way to the list. I've > mostly been waiting for blk-mq to get a wider review before taking the > early scsi-mq prototype driver to a larger public audience. > > Primarily, I'm now reaching out to the people most effected by existing > scsi_request_fn() based performance limitations. Most of them have > abandoned existing scsi_request_fn() based logic in favor of raw block > make_request() based drivers, and are now estimating the amount of > effort to move to an scsi-mq based approach. > > Regardless, as the prototype progresses over the next months, having a > face-to-face discussion with the key parties in the room would be very > helpful given the large amount of effort involved to actually make this > type of generational shift in SCSI actually happen. I'd be very interested in attending this, if invited. -- steve -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
if/when will the RC2 GIT pull occur?
Hey James, Will there a git pull occur for 3.11 RC2, and if so when? Looking to get the latest patch for isci, it just happened to miss the RC1 pull thanks! Pat -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 0/1] AHCI: Optimize interrupt processing
On Tue, 2013-07-16 at 20:32 +0200, Alexander Gordeev wrote:
> On Fri, Jul 12, 2013 at 10:20:12PM -0700, Nicholas A. Bellinger wrote:
> > On Fri, 2013-07-12 at 09:46 +0200, Alexander Gordeev wrote:
> > > > > diff --git a/drivers/scsi/scsi-mq.c b/drivers/scsi/scsi-mq.c
> > > > > index ca6ff67..d8cc7a4 100644
> > > > > --- a/drivers/scsi/scsi-mq.c
> > > > > +++ b/drivers/scsi/scsi-mq.c
> > > > > @@ -155,6 +155,7 @@ void scsi_mq_done(struct scsi_cmnd *sc)
> > > > > static struct blk_mq_ops scsi_mq_ops = {
> > > > > .queue_rq = scsi_mq_queue_rq,
> > > > > .map_queue = blk_mq_map_queue,
> > > > > + .timeout= scsi_times_out,
> > > > > .alloc_hctx = blk_mq_alloc_single_hw_queue,
> > > > > .free_hctx = blk_mq_free_single_hw_queue,
> > > > > };
> >
> > So your actually triggering a blk-mq timeout with ata_piix..?
>
> No.
> That is to avoid a NULL-pointer assignment from ->timeout elsewhere.
> In fact I return -ENODEV for sr_probe() to not hit it.
>
> > That is why scsi-mq still uses blk_execute_rq() for this reason, and
> > this will need be addressed in order to safely use blk_mq_execute_rq()
> > in the above context.
>
> Got it.
>
> > Do you have an OOPs backtrace handy to post w/o the last two changes in
> > place..?
>
> Attaching the output. No oops actually (due to aforementioned .timeout).
>
Hi Alexander,
Thanks for the logs. I'm In-lining some of the output here for
reference:
[7.927596] Calling blk_mq_init_queue: scsi_mq_ops: 81ca13e0,
queue_depth: 64, cmd_size: 296 SCSI cmd_size: 0
Just FYI, a SCSI cmd_size of zero here means that scsi-mq will not be
providing pre-allocated LLD descriptors (located at scsi_cmnd->SCp.ptr)
for use by libata driver code.
That is fine for initial testing, but libata will eventually want to
take advantage of scsi_host_template->cmd_size = sizeof(ata_queued_cmd)
in order to remove (all) memory allocations from the I/O fast-path.
[7.927639] blk-mq: CPU -> queue map
[7.927640] CPU 0 -> Queue 0
[7.927640] CPU 1 -> Queue 0
[7.927640] CPU 2 -> Queue 0
[7.927641] CPU 3 -> Queue 0
[7.927641] CPU 4 -> Queue 0
[7.927642] CPU 5 -> Queue 0
[7.927642] CPU 6 -> Queue 0
[7.927643] CPU 7 -> Queue 0
[7.927643] CPU 8 -> Queue 0
[7.927643] CPU 9 -> Queue 0
[7.927644] CPU10 -> Queue 0
[7.927644] CPU11 -> Queue 0
[7.927645] CPU12 -> Queue 0
[7.927645] CPU13 -> Queue 0
[7.927646] CPU14 -> Queue 0
[7.927646] CPU15 -> Queue 0
[7.927673] Performing sc map setup on q: 88046243 hctx:
880462a14200 i: 0
[7.927780] scsi_mq_alloc_queue() complete !! >>>
[7.927784] Entering scsi_execute with q->mq_ops: 81ca13e0
[7.927785] Allocated blk-mq req: 88046244ad40, req->tag: 63
[7.927790] Calling blk_mq_insert_request from blk_execute_rq_nowait
[7.927803] scsi_execute(): Calling blk_mq_free_request >>>
[7.927815] Entering scsi_execute with q->mq_ops: 81ca13e0
[7.927816] Allocated blk-mq req: 88046244ad40, req->tag: 63
[7.927817] Calling blk_mq_insert_request from blk_execute_rq_nowait
[7.927818] scsi_execute(): Calling blk_mq_free_request >>>
[7.927826] scsi 0:0:0:0: Direct-Access ATA ST9500530NS CC03
PQ: 0 ANSI: 5
OK, so INQUIRY response payload is looking as expected here.
[7.927944] Entering scsi_execute with q->mq_ops: 81ca13e0
[7.927946] Allocated blk-mq req: 88046244a7c0, req->tag: 61
[7.927946] Calling blk_mq_insert_request from blk_execute_rq_nowait
[7.927949] scsi_execute(): Calling blk_mq_free_request >>>
[7.927951] Entering scsi_execute with q->mq_ops: 81ca13e0
[7.927952] Allocated blk-mq req: 88046244a7c0, req->tag: 61
[7.927955] Calling blk_mq_insert_request from blk_execute_rq_nowait
[7.927958] scsi_execute(): Calling blk_mq_free_request >>>
[7.927960] sd 0:0:0:0: [sda] Sector size 0 reported, assuming 512.
[7.927964] sd 0:0:0:0: [sda] 1 512-byte logical blocks: (512 B/512 B)
[7.927965] sd 0:0:0:0: [sda] 0-byte physical blocks
Strange.. READ_CAPACITY appears to be returning a payload as zeros..?
[7.927966] Entering scsi_execute with q->mq_ops: 81ca13e0
[7.927967] Allocated blk-mq req: 88046244a7c0, req->tag: 61
[7.927968] Calling blk_mq_insert_request from blk_execute_rq_nowait
[7.927970] scsi_execute(): Calling blk_mq_free_request >>>
[7.927970] Entering scsi_execute with q->mq_ops: 81ca13e0
[7.927971] Allocated blk-mq req: 88046244a7c0, req->tag: 61
[7.927972] Calling blk_mq_insert_request from blk_execute_rq_nowait
[7.927973] scsi_execute(): Calling blk_mq_free_request >>>
[7.927975] Entering scsi_execute with q->mq_ops: 81ca13e0
[7.927976] Allocated blk
Re: [Ksummit-2013-discuss] [ATTEND] scsi-mq prototype discussion
On Tue, Jul 16 2013, Nicholas A. Bellinger wrote: > On Sat, 2013-07-13 at 06:53 +, James Bottomley wrote: > > On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote: > > > On 07/12/2013 03:33 AM, Nicholas A. Bellinger wrote: > > > > On Thu, 2013-07-11 at 18:02 -0700, Greg KH wrote: > > > >> On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote: > > > >>> Drilling down the work items ahead of a real mainline push is high on > > > >>> priority list for discussion. > > > >>> > > > >>> The parties to be included in such a discussion are: > > > >>> > > > >>> - Jens Axboe (blk-mq author) > > > >>> - James Bottomley (scsi maintainer) > > > >>> - Christoph Hellwig (scsi) > > > >>> - Martin Petersen (scsi) > > > >>> - Tejun Heo (block + libata) > > > >>> - Hannes Reinecke (scsi error recovery) > > > >>> - Kent Overstreet (block, per-cpu ida) > > > >>> - Stephen Cameron (scsi-over-pcie driver) > > > >>> - Andrew Vasquez (qla2xxx LLD) > > > >>> - James Smart (lpfc LLD) > > > >> > > > >> Isn't this something that should have been discussed at the storage > > > >> mini-summit a few months ago? > > > > > > > > The scsi-mq prototype, along with blk-mq (in it's current form) did not > > > > exist a few short months ago. ;) > > > > > > > >> It seems very specific to one subsystem to be a kernel summit topic, > > > >> don't you think? > > > > > > > > It's no more subsystem specific than half of the other proposals so far, > > > > and given it's reach across multiple subsystems (block, scsi, target), > > > > and the amount of off-list interest on the topic, I think it would make > > > > a good candidate for discussion. > > > > > > > And it'll open up new approaches which previously were dismissed, > > > like re-implementing multipathing on top of scsi-mq, giving us the > > > single scsi device like other UNIX systems. > > > > > > Also I do think there's quite some synergy to be had, as with blk-mq > > > we could nail each queue to a processor, which would eliminate the > > > need for locking. > > > Which could be useful for other subsystems, too. > > > > Lets start with discussing this on the list, please, and then see where > > we go from there ... > > > > Yes, the discussion is beginning to make it's way to the list. I've > mostly been waiting for blk-mq to get a wider review before taking the > early scsi-mq prototype driver to a larger public audience. > > Primarily, I'm now reaching out to the people most effected by existing > scsi_request_fn() based performance limitations. Most of them have > abandoned existing scsi_request_fn() based logic in favor of raw block > make_request() based drivers, and are now estimating the amount of > effort to move to an scsi-mq based approach. > > Regardless, as the prototype progresses over the next months, having a > face-to-face discussion with the key parties in the room would be very > helpful given the large amount of effort involved to actually make this > type of generational shift in SCSI actually happen. There's a certain amount of overlap with the aio/O_DIRECT work as well. But if it's not a general session, could always be a BOF or something. I'll second the argument that most technical topics probably DO belong in a topic related workshop. But that leaves us with basically only process related topics at KS, I don't think it hurts to have a bit of tech meat on the bone too. At least I personally miss that part of KS from years gone by. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2013-discuss] [ATTEND] scsi-mq prototype discussion
On Sat, 2013-07-13 at 06:53 +, James Bottomley wrote: > On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote: > > On 07/12/2013 03:33 AM, Nicholas A. Bellinger wrote: > > > On Thu, 2013-07-11 at 18:02 -0700, Greg KH wrote: > > >> On Thu, Jul 11, 2013 at 05:23:32PM -0700, Nicholas A. Bellinger wrote: > > >>> Drilling down the work items ahead of a real mainline push is high on > > >>> priority list for discussion. > > >>> > > >>> The parties to be included in such a discussion are: > > >>> > > >>> - Jens Axboe (blk-mq author) > > >>> - James Bottomley (scsi maintainer) > > >>> - Christoph Hellwig (scsi) > > >>> - Martin Petersen (scsi) > > >>> - Tejun Heo (block + libata) > > >>> - Hannes Reinecke (scsi error recovery) > > >>> - Kent Overstreet (block, per-cpu ida) > > >>> - Stephen Cameron (scsi-over-pcie driver) > > >>> - Andrew Vasquez (qla2xxx LLD) > > >>> - James Smart (lpfc LLD) > > >> > > >> Isn't this something that should have been discussed at the storage > > >> mini-summit a few months ago? > > > > > > The scsi-mq prototype, along with blk-mq (in it's current form) did not > > > exist a few short months ago. ;) > > > > > >> It seems very specific to one subsystem to be a kernel summit topic, > > >> don't you think? > > > > > > It's no more subsystem specific than half of the other proposals so far, > > > and given it's reach across multiple subsystems (block, scsi, target), > > > and the amount of off-list interest on the topic, I think it would make > > > a good candidate for discussion. > > > > > And it'll open up new approaches which previously were dismissed, > > like re-implementing multipathing on top of scsi-mq, giving us the > > single scsi device like other UNIX systems. > > > > Also I do think there's quite some synergy to be had, as with blk-mq > > we could nail each queue to a processor, which would eliminate the > > need for locking. > > Which could be useful for other subsystems, too. > > Lets start with discussing this on the list, please, and then see where > we go from there ... > Yes, the discussion is beginning to make it's way to the list. I've mostly been waiting for blk-mq to get a wider review before taking the early scsi-mq prototype driver to a larger public audience. Primarily, I'm now reaching out to the people most effected by existing scsi_request_fn() based performance limitations. Most of them have abandoned existing scsi_request_fn() based logic in favor of raw block make_request() based drivers, and are now estimating the amount of effort to move to an scsi-mq based approach. Regardless, as the prototype progresses over the next months, having a face-to-face discussion with the key parties in the room would be very helpful given the large amount of effort involved to actually make this type of generational shift in SCSI actually happen. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions about your scsi-mq prototype
On Mon, 2013-07-15 at 16:41 -0500, scame...@beardog.cce.hp.com wrote: > Hi, > > I have some questions about your scsi-mq prototype. I have > CC'ed Chayan Biswas from Sandisk who is the other guy working > with me on the scsi-over-pcie driver. BTW, if you would prefer > I CC linux-kernel or linux-scsi or other people with such > questions (or refrain from bothering you at all) just let me know. > Thanks for asking. Adding CC's to linux-scsi + Jens now.. > I wonder if you can provide a summary of how you envision > a scsi LLD is expected to interact with the scsi-mq code. I > gather that: > > 1. scsi_mq in scsi_host_template should be set to true. Correct. > 2. scsi LLD should provide queuecommand_mq function >(in addition to normal queuecommand? or instead of? > virtio_scsi.c seems to provide both.) In addition to for the moment, correct. > 3. LLD should tell scsi mid layer size of its commands via >scsi_host_template cmd_size field. >I guess midlayer will pre-allocate per queue to avoid >the midlayer threads contending to allocate commands maybe? >and hands this space to LLD to use via sc->SCp.ptr (sc is struct scsi_cmnd) >(right? or am I off in the weeds here?) This is all exactly correct. The one extra point here wrt ->queuecommand_mq() is that it's using the same parameters for the moment, but once nr_hw_queues > 1 is implemented, we will expect to pass down the associated blk_mq_hw_ctx in order for the LLD to determine which hardware context the struct scsi_cmnd is being dispatched upon. > 4. Wondering about how the multiple queue thing will work. >I see this: > >#warning FIXME: Need to pass nr_hw_queues into scsi-mq > >and I don't see any code setting sdev_mq_reg.nr_hw_queues to >anything other than 1. > >So maybe I'm just looking too early and that part isn't done yet? > Correct, not done yet.. However, so far with a single SCSI LUN with nr_hw_queues=1, 4k blocksize randrw performance is on the order of 1M, vs. ~250K using legacy scsi_request_fn(). > In any case, since we switched away from a scsi driver for the scsi-over-pcie > driver to a block driver, the original scsi version of the driver has lain > fallow, and the first thing we would need to do before we could begin to try > to use your code is to update that driver to work with our current hardware, > and > take advantage of other code improvements made in the block driver. > Understood. I'm happy to help on the scsi-mq conversion side, but as you've noticed from the virtio-scsi conversion patch, enabling scsi-mq it it's current form for I/O benchmarking is straight forward. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fnic: BUG: sleeping function called from invalid context during probe
I hit this during driver probe with the latest fnic updates (this trace
is from a backport into a distro kernel, but the issue is the same).
> BUG: sleeping function called from invalid context at mm/slab.c:3113
> in_atomic(): 0, irqs_disabled(): 1, pid: 610, name: work_for_cpu
> INFO: lockdep is turned off.
> irq event stamp: 0
> hardirqs last enabled at (0): [<(null)>] (null)
> hardirqs last disabled at (0): []
> copy_process+0x5e5/0x1670
> softirqs last enabled at (0): []
> copy_process+0x5e5/0x1670
> softirqs last disabled at (0): [<(null)>] (null)
> Pid: 610, comm: work_for_cpu Not tainted
> Call Trace:
> [] ? print_irqtrace_events+0xd0/0xe0
> [] ? __might_sleep+0xf7/0x130
> [] ? kmem_cache_alloc_trace+0x20b/0x2d0
> [] ? __create_workqueue_key+0x3e/0x1d0
> [] ? __create_workqueue_key+0x3e/0x1d0
> [] ? fnic_probe+0x977/0x11aa [fnic]
> [] ? fnic_probe+0x9a3/0x11aa [fnic]
> [] ? do_work_for_cpu+0x0/0x30
> [] ? local_pci_probe+0x17/0x20
> [] ? do_work_for_cpu+0x18/0x30
> [] ? kthread+0x96/0xa0
> [] ? child_rip+0xa/0x20
> [] ? _spin_unlock_irq+0x30/0x40
> [] ? restore_args+0x0/0x30
> [] ? kthread+0x0/0xa0
> [] ? child_rip+0x0/0x20
The problem is in this hunk of "FIP VLAN Discovery Feature Support"
(d3c995f1dcf938f1084388d92b8fb97bec366566)
create_singlethreaded_workqueue cannot be called with irqs disabled
@@ -620,7 +634,29 @@ static int __devinit fnic_probe(struct pci_dev
*pdev,
vnic_dev_packet_filter(fnic->vdev, 1, 1, 0, 0, 0);
vnic_dev_add_addr(fnic->vdev, FIP_ALL_ENODE_MACS);
vnic_dev_add_addr(fnic->vdev, fnic->ctlr.ctl_src_addr);
+ fnic->set_vlan = fnic_set_vlan;
fcoe_ctlr_init(&fnic->ctlr, FIP_MODE_AUTO);
+ setup_timer(&fnic->fip_timer, fnic_fip_notify_timer,
+ (unsigned long)fnic);
+ spin_lock_init(&fnic->vlans_lock);
+ INIT_WORK(&fnic->fip_frame_work, fnic_handle_fip_frame);
+ INIT_WORK(&fnic->event_work, fnic_handle_event);
+ skb_queue_head_init(&fnic->fip_frame_queue);
+ spin_lock_irqsave(&fnic_list_lock, flags);
+ if (!fnic_fip_queue) {
+ fnic_fip_queue =
+ create_singlethread_workqueue("fnic_fip_q");
+ if (!fnic_fip_queue) {
+ spin_unlock_irqrestore(&fnic_list_lock, flags);
+ printk(KERN_ERR PFX "fnic FIP work queue "
+"create failed\n");
+ err = -ENOMEM;
+ goto err_out_free_max_pool;
+ }
+ }
+ spin_unlock_irqrestore(&fnic_list_lock, flags);
+ INIT_LIST_HEAD(&fnic->evlist);
+ INIT_LIST_HEAD(&fnic->vlans);
} else {
shost_printk(KERN_INFO, fnic->lport->host,
"firmware uses non-FIP mode\n");
The attempts to make fnic_fip_queue a single instance for the driver
while it's being created in probe look awkward anyway, why is this not
created in fnic_init_module like the event workqueue?
Built and loaded, tested all-right through probe without triggering the
same issue. Not tested by me for functionality, as the fnic hardware I
had access to isn't actually attached to an FCoE SAN.
Signed-off-by: Chris Leech
---
drivers/scsi/fnic/fnic_main.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/fnic/fnic_main.c b/drivers/scsi/fnic/fnic_main.c
index 5f09d18..42e15ee 100644
--- a/drivers/scsi/fnic/fnic_main.c
+++ b/drivers/scsi/fnic/fnic_main.c
@@ -642,19 +642,6 @@ static int fnic_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
INIT_WORK(&fnic->fip_frame_work, fnic_handle_fip_frame);
INIT_WORK(&fnic->event_work, fnic_handle_event);
skb_queue_head_init(&fnic->fip_frame_queue);
- spin_lock_irqsave(&fnic_list_lock, flags);
- if (!fnic_fip_queue) {
- fnic_fip_queue =
- create_singlethread_workqueue("fnic_fip_q");
- if (!fnic_fip_queue) {
- spin_unlock_irqrestore(&fnic_list_lock, flags);
- printk(KERN_ERR PFX "fnic FIP work queue "
-"create failed\n");
- err = -ENOMEM;
- goto err_out_free_max_pool;
- }
- }
- spin_unlock_irqrestore(&fnic_list_lock, flags);
INIT_LIST_HEAD(&fnic->evlist);
INIT_LIST_HEAD(&fnic->vlans);
} else {
@@ -960,6 +947,13 @@ static int __init fnic_init_module(void)
spin_lock_init(&fnic_list_lock);
INIT_LIST_HEAD(&fnic_list);
+ fnic_fip_queue = create_singlethread_workqueue("fnic_fip_q");
+ if (!fnic_fip_queue) {
+ printk(KERN_ERR PFX "fnic FIP work queue create failed\n");
+ err = -ENOMEM;
+ goto err_create_fip_workq;
+ }
+
fnic_fc_transp
Re: [PATCH v2] [SCSI] scsi_debug: silence GCC warning
2013/7/17 Paul Bolle :
> On Wed, 2013-07-17 at 00:21 +0900, Akinobu Mita wrote:
>> This one looks good to me.
>
> Thanks.
>
>> It would be much better if this commit
>> log had a reference to the commit that introduced this warning as
>> you described after '---' in v1 patch.
>
> Do you mean that I should submit a v3, with a commit explanation that
> also has one or two lines that mention commit beb40ea42b ("[SCSI]
> scsi_debug: reduce duplication between prot_verify_read and
> prot_verify_write")?
Yes. I think it will help someone to understand the background of this patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [SCSI] scsi_debug: silence GCC warning
On Wed, 2013-07-17 at 00:21 +0900, Akinobu Mita wrote:
> This one looks good to me.
Thanks.
> It would be much better if this commit
> log had a reference to the commit that introduced this warning as
> you described after '---' in v1 patch.
Do you mean that I should submit a v3, with a commit explanation that
also has one or two lines that mention commit beb40ea42b ("[SCSI]
scsi_debug: reduce duplication between prot_verify_read and
prot_verify_write")?
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mpt2sas,mpt3sas watchdog device removal
On Tue, 16 Jul 2013 16:03:38 +0400 James Bottomley wrote: > On Tue, 2013-07-16 at 17:30 +0530, Reddy, Sreekanth wrote: > > James, > > > > This patch seem to be fine. Please consider this patch. > > Where's the new version? The one that has all of this fixed: > > > Off list, Sreekanth from LSI tested and noticed a few issues with this > > patch: > > > > - mpt2sas_base_stop_watchdog is called twice: The call from > >mpt2sas_base_detach is safe, but now unnecessary (as a call was > >added earlier up in the PCI driver callbacks to ensure that the > >watchdog was out of the way.) This second invocation can be > > removed. > > > > - If the watchdog detects a bad IOC, the watchdog remains running: > >The watchdog workqueue isn't cleaned up until > >mpt2sas_base_stop_watchdog is called, so in the case that the > >watchdog removes the device from SCSI topo, the workqueue will > >remain unused until PCI .remove/.shutdown cleans it up. Perhaps a > >single watchdog that iterates over all adapters would be simpler? > > > > Finally, if SCSI topo detachment is all that is interesting here, > > would > > it make more sense to move the watchdog into the MPT "scsi" code? I > > haven't looked at the code yet, but this might make an MPT fusion > > patch > > easier (due to dependencies between its "scsi" and "base" modules). This patch fizzled out in May as other work took priority. If LSI is still interested in these changes, I can dust off my notes and test/rebase for the 3.11 series. A few of the issues quoted above are easily fixed, however I remember having an outstanding question of how to best clean up the driver's per device watchdog workqueue: The way the MPT drivers are working right now is that the watchdog workqueue function _base_fault_reset_work() initiates a PCI device removal via kthread. The PCI callback kthread context then tears down the device and cancel/flush/destroys the watchdog workqueue. This patch eliminated the kthread and its call into PCI API, simply detaching from the SCSI midlayer. In my opinion, the kthread complicated device removal and introduced potential races if the watchdog tried removing the device at the same time an ordinary device removal request occurred. At the time, the best solution I had was to leave the unused workqueue around until its PCI device was removed. Regards, -- Joe -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [SCSI] scsi_debug: silence GCC warning
2013/7/16 Paul Bolle :
> Building scsi_debug.o triggers a GCC warning:
> drivers/scsi/scsi_debug.c: In function ‘dif_verify’:
> drivers/scsi/scsi_debug.c:1755:3: warning: ‘csum’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>
> This is a false positive. But if we transform the switch statement in
> dif_compute_csum() to a straightforward if/else statement we supply GCC
> with enough information to determine that csum will not be used
> uninitialized.
>
> Signed-off-by: Paul Bolle
> ---
> 0) v2 because I started to worry whether v1 would change an interface
> (ie, the way the "guard" module parameter behaves). This patch is much
> simpler, and doesn't change any behavior.
>
> 1) Still only compile tested.
This one looks good to me. It would be much better if this commit
log had a reference to the commit that introduced this warning as
you described after '---' in v1 patch.
> drivers/scsi/scsi_debug.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
> index cb4fefa..7565ec5 100644
> --- a/drivers/scsi/scsi_debug.c
> +++ b/drivers/scsi/scsi_debug.c
> @@ -1735,14 +1735,11 @@ static u16 dif_compute_csum(const void *buf, int len)
> {
> u16 csum;
>
> - switch (scsi_debug_guard) {
> - case 1:
> + if (scsi_debug_guard == 1)
> csum = ip_compute_csum(buf, len);
> - break;
> - case 0:
> + else
> csum = cpu_to_be16(crc_t10dif(buf, len));
> - break;
> - }
> +
> return csum;
> }
>
> --
> 1.8.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ATTO esas2r - Scsi_Host_template max_lun setting
[please keep linux-scsi in the cc otherwise I'll lose the email] On Tue, 2013-07-16 at 10:05 -0400, Bradley Grove wrote: > James, > > When we sent the first version of our driver code for comments, you > suggested that we set max_lun in the host template and use that to > enforce the lun limit. However, the Scsi_Host_Template struct doesn't > doesn't contain mux_lun. Let me know if I misunderstood what you were > asking for. You set it in the detection routine just after you've obtained struct scsi_host. shost->max_lun. James > I think we addressed your remaining issues as well as some issues that > we found. That said, it's tough to be sure that we haven't > reimplemented primitives that already exist in the kernel tree. > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/10] [RFC] SCSI: esas2r: Add Makefile, Kconfig, and MAINTAINERS files
Signed-off-by: Bradley Grove --- MAINTAINERS | 7 +++ drivers/scsi/Kconfig | 1 + drivers/scsi/Makefile| 1 + drivers/scsi/esas2r/Kconfig | 6 ++ drivers/scsi/esas2r/Makefile | 5 + 5 files changed, 20 insertions(+) create mode 100644 drivers/scsi/esas2r/Kconfig create mode 100644 drivers/scsi/esas2r/Makefile diff --git a/MAINTAINERS b/MAINTAINERS index 50105f9..5f121dd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1540,6 +1540,13 @@ W: http://atmelwlandriver.sourceforge.net/ S: Maintained F: drivers/net/wireless/atmel* +ATTO EXPRESSSAS SAS/SATA RAID SCSI DRIVER +M:Bradley Grove +L:linux-scsi@vger.kernel.org +W:http://www.attotech.com +S:Supported +F:drivers/scsi/esas2r + AUDIT SUBSYSTEM M: Al Viro M: Eric Paris diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 48b2918..c298b76 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -601,6 +601,7 @@ config SCSI_ARCMSR To compile this driver as a module, choose M here: the module will be called arcmsr (modprobe arcmsr). +source "drivers/scsi/esas2r/Kconfig" source "drivers/scsi/megaraid/Kconfig.megaraid" source "drivers/scsi/mpt2sas/Kconfig" source "drivers/scsi/mpt3sas/Kconfig" diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile index b607ba4..149bb6b 100644 --- a/drivers/scsi/Makefile +++ b/drivers/scsi/Makefile @@ -141,6 +141,7 @@ obj-$(CONFIG_SCSI_CXGB3_ISCSI) += libiscsi.o libiscsi_tcp.o cxgbi/ obj-$(CONFIG_SCSI_CXGB4_ISCSI) += libiscsi.o libiscsi_tcp.o cxgbi/ obj-$(CONFIG_SCSI_BNX2_ISCSI) += libiscsi.o bnx2i/ obj-$(CONFIG_BE2ISCSI) += libiscsi.o be2iscsi/ +obj-$(CONFIG_SCSI_ESAS2R) += esas2r/ obj-$(CONFIG_SCSI_PMCRAID) += pmcraid.o obj-$(CONFIG_SCSI_VIRTIO) += virtio_scsi.o obj-$(CONFIG_VMWARE_PVSCSI)+= vmw_pvscsi.o diff --git a/drivers/scsi/esas2r/Kconfig b/drivers/scsi/esas2r/Kconfig new file mode 100644 index 000..758ec48 --- /dev/null +++ b/drivers/scsi/esas2r/Kconfig @@ -0,0 +1,5 @@ +config SCSI_ESAS2R + tristate "ATTO Technology's ExpressSAS RAID adapter driver" + depends on PCI && SCSI && NET + ---help--- + This driver supports the ATTO ExpressSAS R6xx SAS/SATA RAID controllers. diff --git a/drivers/scsi/esas2r/Makefile b/drivers/scsi/esas2r/Makefile new file mode 100644 index 000..c77160b --- /dev/null +++ b/drivers/scsi/esas2r/Makefile @@ -0,0 +1,5 @@ +obj-$(CONFIG_SCSI_ESAS2R) += esas2r.o + +esas2r-objs := esas2r_log.o esas2r_disc.o esas2r_flash.o esas2r_init.o \ +esas2r_int.o esas2r_io.o esas2r_ioctl.o esas2r_targdb.o \ +esas2r_vda.o esas2r_main.o -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/10] [RFC] SCSI: esas2r: Add initialization functions
Signed-off-by: Bradley Grove
---
drivers/scsi/esas2r/esas2r_init.c | 1775 +
1 file changed, 1775 insertions(+)
create mode 100644 drivers/scsi/esas2r/esas2r_init.c
diff --git a/drivers/scsi/esas2r/esas2r_init.c
b/drivers/scsi/esas2r/esas2r_init.c
new file mode 100644
index 000..757d14d
--- /dev/null
+++ b/drivers/scsi/esas2r/esas2r_init.c
@@ -0,0 +1,1775 @@
+/*
+ * linux/drivers/scsi/esas2r/esas2r_init.c
+ * For use with ATTO ExpressSAS R6xx SAS/SATA RAID controllers
+ *
+ * Copyright (c) 2001-2013 ATTO Technology, Inc.
+ * (mailto:linuxdriv...@attotech.com)mpt3sas/mpt3sas_trigger_diag.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * NO WARRANTY
+ * THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR
+ * CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT
+ * LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT,
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is
+ * solely responsible for determining the appropriateness of using and
+ * distributing the Program and assumes all risks associated with its
+ * exercise of rights under this Agreement, including but not limited to
+ * the risks and costs of program errors, damage to or loss of data,
+ * programs or equipment, and unavailability or interruption of operations.
+ *
+ * DISCLAIMER OF LIABILITY
+ * NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+ * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED
+ * HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
+ * USA.
+ */
+
+#include "esas2r.h"
+
+static bool esas2r_initmem_alloc(struct esas2r_adapter *a,
+struct esas2r_mem_desc *mem_desc,
+u32 align)
+{
+ mem_desc->esas2r_param = mem_desc->size + align;
+ mem_desc->virt_addr = NULL;
+ mem_desc->phys_addr = 0;
+ mem_desc->esas2r_data = dma_alloc_coherent(&a->pcid->dev,
+ (size_t)mem_desc->
+ esas2r_param,
+ (dma_addr_t *)&mem_desc->
+ phys_addr,
+ GFP_KERNEL);
+
+ if (mem_desc->esas2r_data == NULL) {
+ esas2r_log(ESAS2R_LOG_CRIT,
+ "failed to allocate %lu bytes of consistent memory!",
+ (long
+ unsigned
+ int)mem_desc->esas2r_param);
+ return false;
+ }
+
+ mem_desc->virt_addr = PTR_ALIGN(mem_desc->esas2r_data, align);
+ mem_desc->phys_addr = ALIGN(mem_desc->phys_addr, align);
+ memset(mem_desc->virt_addr, 0, mem_desc->size);
+ return true;
+}
+
+static void esas2r_initmem_free(struct esas2r_adapter *a,
+ struct esas2r_mem_desc *mem_desc)
+{
+ if (mem_desc->virt_addr == NULL)
+ return;
+
+ /*
+* Careful! phys_addr and virt_addr may have been adjusted from the
+* original allocation in order to return the desired alignment. That
+* means we have to use the original address (in esas2r_data) and size
+* (esas2r_param) and calculate the original physical address based on
+* the difference between the requested and actual allocation size.
+*/
+ if (mem_desc->phys_addr) {
+ int unalign = ((u8 *)mem_desc->virt_addr) -
+ ((u8 *)mem_desc->esas2r_data);
+
+ dma_free_coherent(&a->pcid->dev,
+ (size_t)mem_desc->esas2r_param,
+ mem_desc->esas2r_data,
+ (dma_addr_t)(mem_desc->phys_addr - unalign));
+ } else {
+ kfree(mem_desc->esas2r_data);
+ }
+
+
[PATCH v2 00/10] [RFC] SCSI: esas2r: ATTO Technology ExpressSAS 6G SAS/SATA RAID Adapter Driver
This is a new driver for ATTO Technology's ExpressSAS series of hardware RAID adapters. It supports the following adapters: - ExpressSAS R60F - ExpressSAS R680 - ExpressSAS R608 - ExpressSAS R644 This patch is split into ten parts, all of which need to be applied to build the driver. Changes since V1: - We now use the kernel's list structs and alignment macros rather than our own implementations - Fix to PCIe address size declaration when compiling on 32-bit architectures - Use memcpy() instead opf memmove() where appropriate - Fixes for big-endian architectures - Removed unneeded MSI configuration code - Simplified memory allocation during init - Code formatting cleanup Bradley Grove (10): [RFC] SCSI: esas2r: Add main header file [RFC] SCSI: esas2r: Add main file [RFC] SCSI: esas2r: Add initialization functions [RFC] SCSI: esas2r: Add device discovery and logging functions [RFC] SCSI: esas2r: Add interrupt and IO functions [RFC] SCSI: esas2r: Add flash and target database functions [RFC] SCSI: esas2r: Add IOCTL header file [RFC] SCSI: esas2r: Add IOCTL functions [RFC] SCSI: esas2r: Add ATTO VDA Firmware API headers and functions. This API is used to control and manage the RAID adapter. [RFC] SCSI: esas2r: Add Makefile, Kconfig, and MAINTAINERS files MAINTAINERS |7 + drivers/scsi/Kconfig|1 + drivers/scsi/Makefile |1 + drivers/scsi/esas2r/Kconfig |6 + drivers/scsi/esas2r/Makefile|5 + drivers/scsi/esas2r/atioctl.h | 1254 drivers/scsi/esas2r/atvda.h | 1320 + drivers/scsi/esas2r/esas2r.h| 1442 +++ drivers/scsi/esas2r/esas2r_disc.c | 1190 +++ drivers/scsi/esas2r/esas2r_flash.c | 1516 drivers/scsi/esas2r/esas2r_init.c | 1775 drivers/scsi/esas2r/esas2r_int.c| 940 +++ drivers/scsi/esas2r/esas2r_io.c | 883 ++ drivers/scsi/esas2r/esas2r_ioctl.c | 2108 ++ drivers/scsi/esas2r/esas2r_log.c| 255 drivers/scsi/esas2r/esas2r_log.h| 118 ++ drivers/scsi/esas2r/esas2r_main.c | 2169 +++ drivers/scsi/esas2r/esas2r_targdb.c | 306 + drivers/scsi/esas2r/esas2r_vda.c| 523 + 19 files changed, 15819 insertions(+) create mode 100644 drivers/scsi/esas2r/Kconfig create mode 100644 drivers/scsi/esas2r/Makefile create mode 100644 drivers/scsi/esas2r/atioctl.h create mode 100644 drivers/scsi/esas2r/atvda.h create mode 100644 drivers/scsi/esas2r/esas2r.h create mode 100644 drivers/scsi/esas2r/esas2r_disc.c create mode 100644 drivers/scsi/esas2r/esas2r_flash.c create mode 100644 drivers/scsi/esas2r/esas2r_init.c create mode 100644 drivers/scsi/esas2r/esas2r_int.c create mode 100644 drivers/scsi/esas2r/esas2r_io.c create mode 100644 drivers/scsi/esas2r/esas2r_ioctl.c create mode 100644 drivers/scsi/esas2r/esas2r_log.c create mode 100644 drivers/scsi/esas2r/esas2r_log.h create mode 100644 drivers/scsi/esas2r/esas2r_main.c create mode 100644 drivers/scsi/esas2r/esas2r_targdb.c create mode 100644 drivers/scsi/esas2r/esas2r_vda.c -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/10] [RFC] SCSI: esas2r: Add IOCTL header file
Signed-off-by: Bradley Grove
---
drivers/scsi/esas2r/atioctl.h | 1254 +
1 file changed, 1254 insertions(+)
create mode 100644 drivers/scsi/esas2r/atioctl.h
diff --git a/drivers/scsi/esas2r/atioctl.h b/drivers/scsi/esas2r/atioctl.h
new file mode 100644
index 000..4aca3d5
--- /dev/null
+++ b/drivers/scsi/esas2r/atioctl.h
@@ -0,0 +1,1254 @@
+/* linux/drivers/scsi/esas2r/atioctl.h
+ * ATTO IOCTL Handling
+ *
+ * Copyright (c) 2001-2013 ATTO Technology, Inc.
+ * (mailto:linuxdriv...@attotech.com)
+ */
+/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * NO WARRANTY
+ * THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR
+ * CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT
+ * LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT,
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is
+ * solely responsible for determining the appropriateness of using and
+ * distributing the Program and assumes all risks associated with its
+ * exercise of rights under this Agreement, including but not limited to
+ * the risks and costs of program errors, damage to or loss of data,
+ * programs or equipment, and unavailability or interruption of operations.
+ *
+ * DISCLAIMER OF LIABILITY
+ * NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+ * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED
+ * HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
+
+#include "atvda.h"
+
+#ifndef ATIOCTL_H
+#define ATIOCTL_H
+
+#define EXPRESS_IOCTL_SIGNATURE"Express"
+#define EXPRESS_IOCTL_SIGNATURE_SIZE 8
+
+/* structure definitions for IOCTls */
+
+struct __packed atto_express_ioctl_header {
+ u8 signature[EXPRESS_IOCTL_SIGNATURE_SIZE];
+ u8 return_code;
+
+#define IOCTL_SUCCESS 0
+#define IOCTL_ERR_INVCMD 101
+#define IOCTL_INIT_FAILED 102
+#define IOCTL_NOT_IMPLEMENTED 103
+#define IOCTL_BAD_CHANNEL 104
+#define IOCTL_TARGET_OVERRUN 105
+#define IOCTL_TARGET_NOT_ENABLED 106
+#define IOCTL_BAD_FLASH_IMGTYPE 107
+#define IOCTL_OUT_OF_RESOURCES108
+#define IOCTL_GENERAL_ERROR 109
+#define IOCTL_INVALID_PARAM 110
+
+ u8 channel;
+ u8 retries;
+ u8 pad[5];
+};
+
+/*
+ * NOTE - if channel == 0xFF, the request is
+ * handled on the adapter it came in on.
+ */
+#define MAX_NODE_NAMES 256
+
+struct __packed atto_firmware_rw_request {
+ u8 function;
+ #define FUNC_FW_DOWNLOAD0x09
+ #define FUNC_FW_UPLOAD 0x12
+
+ u8 img_type;
+ #define FW_IMG_FW 0x01
+ #define FW_IMG_BIOS 0x02
+ #define FW_IMG_NVR 0x03
+ #define FW_IMG_RAW 0x04
+ #define FW_IMG_FM_API 0x05
+ #define FW_IMG_FS_API 0x06
+
+ u8 pad[2];
+ u32 img_offset;
+ u32 img_size;
+ u8 image[0x8];
+};
+
+struct __packed atto_param_rw_request {
+ u16 code;
+ char data_buffer[512];
+};
+
+#define MAX_CHANNEL 256
+
+struct __packed atto_channel_list {
+ u32 num_channels;
+ u8 channel[MAX_CHANNEL];
+};
+
+struct __packed atto_channel_info {
+ u8 major_rev;
+ u8 minor_rev;
+ u8 IRQ;
+ u8 revision_id;
+ u8 pci_bus;
+ u8 pci_dev_func;
+ u8 core_rev;
+ u8 host_no;
+ u16 device_id;
+ u16 vendor_id;
+ u16 ven_dev_id;
+ u8 pad[3];
+ u32 hbaapi_rev;
+};
+
+/*
+ * CSMI control codes
+ * class independent
+ */
+#define CSMI_CC_GET_DRVR_INFO1
+#define CSMI_CC_GET_CNTLR_CFG2
+#define CSMI_CC_GET_CNTLR_STS3
+#define CSMI_CC_FW_DOWNLOAD 4
+
+/* RAID class */
+#define CSMI_CC_GET_RAID_INFO10
+#define CSMI_CC_GET
[PATCH v2 02/10] [RFC] SCSI: esas2r: Add main file
Signed-off-by: Bradley Grove
---
drivers/scsi/esas2r/esas2r_main.c | 2169 +
1 file changed, 2169 insertions(+)
create mode 100644 drivers/scsi/esas2r/esas2r_main.c
diff --git a/drivers/scsi/esas2r/esas2r_main.c
b/drivers/scsi/esas2r/esas2r_main.c
new file mode 100644
index 000..4f24aac
--- /dev/null
+++ b/drivers/scsi/esas2r/esas2r_main.c
@@ -0,0 +1,2169 @@
+/*
+ * linux/drivers/scsi/esas2r/esas2r_main.c
+ * For use with ATTO ExpressSAS R6xx SAS/SATA RAID controllers
+ *
+ * Copyright (c) 2001-2013 ATTO Technology, Inc.
+ * (mailto:linuxdriv...@attotech.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * NO WARRANTY
+ * THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR
+ * CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT
+ * LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT,
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is
+ * solely responsible for determining the appropriateness of using and
+ * distributing the Program and assumes all risks associated with its
+ * exercise of rights under this Agreement, including but not limited to
+ * the risks and costs of program errors, damage to or loss of data,
+ * programs or equipment, and unavailability or interruption of operations.
+ *
+ * DISCLAIMER OF LIABILITY
+ * NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+ * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED
+ * HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
+ * USA.
+ */
+
+#include "esas2r.h"
+
+MODULE_DESCRIPTION(ESAS2R_DRVR_NAME ": " ESAS2R_LONGNAME " driver");
+MODULE_AUTHOR("ATTO Technology, Inc.");
+MODULE_LICENSE("GPL");
+MODULE_VERSION(ESAS2R_VERSION_STR);
+
+/* global definitions */
+
+static int found_adapters;
+struct esas2r_adapter *esas2r_adapters[MAX_ADAPTERS];
+
+#define ESAS2R_VDA_EVENT_PORT1 54414
+#define ESAS2R_VDA_EVENT_PORT2 54415
+#define ESAS2R_VDA_EVENT_SOCK_COUNT 2
+
+static struct socket *event_socket[ESAS2R_VDA_EVENT_SOCK_COUNT];
+
+static struct esas2r_adapter *esas2r_adapter_from_kobj(struct kobject *kobj)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct Scsi_Host *host = class_to_shost(dev);
+
+ return (struct esas2r_adapter *)host->hostdata;
+}
+
+static ssize_t read_fw(struct file *file, struct kobject *kobj,
+ struct bin_attribute *attr,
+ char *buf, loff_t off, size_t count)
+{
+ struct esas2r_adapter *a = esas2r_adapter_from_kobj(kobj);
+
+ return esas2r_read_fw(a, buf, off, count);
+}
+
+static ssize_t write_fw(struct file *file, struct kobject *kobj,
+ struct bin_attribute *attr,
+ char *buf, loff_t off, size_t count)
+{
+ struct esas2r_adapter *a = esas2r_adapter_from_kobj(kobj);
+
+ return esas2r_write_fw(a, buf, off, count);
+}
+
+static ssize_t read_fs(struct file *file, struct kobject *kobj,
+ struct bin_attribute *attr,
+ char *buf, loff_t off, size_t count)
+{
+ struct esas2r_adapter *a = esas2r_adapter_from_kobj(kobj);
+
+ return esas2r_read_fs(a, buf, off, count);
+}
+
+static ssize_t write_fs(struct file *file, struct kobject *kobj,
+ struct bin_attribute *attr,
+ char *buf, loff_t off, size_t count)
+{
+ struct esas2r_adapter *a = esas2r_adapter_from_kobj(kobj);
+ int length = min(sizeof(struct esas2r_ioctl_fs), count);
+ int result = 0;
+
+ result = esas2r_write_fs(a, buf, off, count);
+
+ if (result < 0)
+ result = 0;
+
+ return length;
+}
+
+static ssize_t read_vda(struct file *file, struct kobject *kobj,
+ struct bin_attribute *attr,
+ char *buf, loff_t off, size_t count)
+{
+ struct esas2r_adapter *a = esas2r_adapter_from_ko
[PATCH v2 04/10] [RFC] SCSI: esas2r: Add device discovery and logging functions
Signed-off-by: Bradley Grove --- drivers/scsi/esas2r/esas2r_disc.c | 1190 + drivers/scsi/esas2r/esas2r_log.c | 255 drivers/scsi/esas2r/esas2r_log.h | 118 3 files changed, 1563 insertions(+) create mode 100644 drivers/scsi/esas2r/esas2r_disc.c create mode 100644 drivers/scsi/esas2r/esas2r_log.c create mode 100644 drivers/scsi/esas2r/esas2r_log.h diff --git a/drivers/scsi/esas2r/esas2r_disc.c b/drivers/scsi/esas2r/esas2r_disc.c new file mode 100644 index 000..319ba9a --- /dev/null +++ b/drivers/scsi/esas2r/esas2r_disc.c @@ -0,0 +1,1189 @@ +/* + * linux/drivers/scsi/esas2r/esas2r_disc.c + * esas2r device discovery routines + * + * Copyright (c) 2001-2013 ATTO Technology, Inc. + * (mailto:linuxdriv...@attotech.com) + */ +/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/ +/* + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * NO WARRANTY + * THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR + * CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT + * LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is + * solely responsible for determining the appropriateness of using and + * distributing the Program and assumes all risks associated with its + * exercise of rights under this Agreement, including but not limited to + * the risks and costs of program errors, damage to or loss of data, + * programs or equipment, and unavailability or interruption of operations. + * + * DISCLAIMER OF LIABILITY + * NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR + * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE + * USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED + * HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/ + +#include "esas2r.h" + +/* Miscellaneous internal discovery routines */ +static void esas2r_disc_abort(struct esas2r_adapter *a, + struct esas2r_request *rq); +static bool esas2r_disc_continue(struct esas2r_adapter *a, +struct esas2r_request *rq); +static void esas2r_disc_fix_curr_requests(struct esas2r_adapter *a); +static u32 esas2r_disc_get_phys_addr(struct esas2r_sg_context *sgc, u64 *addr); +static bool esas2r_disc_start_request(struct esas2r_adapter *a, + struct esas2r_request *rq); + +/* Internal discovery routines that process the states */ +static bool esas2r_disc_block_dev_scan(struct esas2r_adapter *a, + struct esas2r_request *rq); +static void esas2r_disc_block_dev_scan_cb(struct esas2r_adapter *a, + struct esas2r_request *rq); +static bool esas2r_disc_dev_add(struct esas2r_adapter *a, + struct esas2r_request *rq); +static bool esas2r_disc_dev_remove(struct esas2r_adapter *a, + struct esas2r_request *rq); +static bool esas2r_disc_part_info(struct esas2r_adapter *a, + struct esas2r_request *rq); +static void esas2r_disc_part_info_cb(struct esas2r_adapter *a, +struct esas2r_request *rq); +static bool esas2r_disc_passthru_dev_info(struct esas2r_adapter *a, + struct esas2r_request *rq); +static void esas2r_disc_passthru_dev_info_cb(struct esas2r_adapter *a, +struct esas2r_request *rq); +static bool esas2r_disc_passthru_dev_addr(struct esas2r_adapter *a, + struct esas2r_request *rq); +static void esas2r_disc_passthru_dev_addr_cb(struct esas2r_adapter *a, +struct esas2r_request *rq); +static bool esas2r_disc_raid_grp_info(struct esas2r_adapter *a, + struct
[PATCH v2 09/10] [RFC] SCSI: esas2r: Add ATTO VDA Firmware API headers and functions. This API is used to control and manage the RAID adapter.
Signed-off-by: Bradley Grove
---
drivers/scsi/esas2r/atvda.h | 1320 ++
drivers/scsi/esas2r/esas2r_vda.c | 523 +++
2 files changed, 1843 insertions(+)
create mode 100644 drivers/scsi/esas2r/atvda.h
create mode 100644 drivers/scsi/esas2r/esas2r_vda.c
diff --git a/drivers/scsi/esas2r/atvda.h b/drivers/scsi/esas2r/atvda.h
new file mode 100644
index 000..0f70c31
--- /dev/null
+++ b/drivers/scsi/esas2r/atvda.h
@@ -0,0 +1,1319 @@
+/* linux/drivers/scsi/esas2r/atvda.h
+ * ATTO VDA interface definitions
+ *
+ * Copyright (c) 2001-2013 ATTO Technology, Inc.
+ * (mailto:linuxdriv...@attotech.com)
+ */
+/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * NO WARRANTY
+ * THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR
+ * CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT
+ * LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT,
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is
+ * solely responsible for determining the appropriateness of using and
+ * distributing the Program and assumes all risks associated with its
+ * exercise of rights under this Agreement, including but not limited to
+ * the risks and costs of program errors, damage to or loss of data,
+ * programs or equipment, and unavailability or interruption of operations.
+ *
+ * DISCLAIMER OF LIABILITY
+ * NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+ * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED
+ * HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
+
+
+#ifndef ATVDA_H
+#define ATVDA_H
+
+struct __packed atto_dev_addr {
+ u64 dev_port;
+ u64 hba_port;
+ u8 lun;
+ u8 flags;
+ #define VDA_DEVADDRF_SATA 0x01
+ #define VDA_DEVADDRF_SSD0x02
+ u8 link_speed; /* VDALINKSPEED_xxx */
+ u8 pad[1];
+};
+
+/* dev_addr2 was added for 64-bit alignment */
+
+struct __packed atto_dev_addr2 {
+ u64 dev_port;
+ u64 hba_port;
+ u8 lun;
+ u8 flags;
+ u8 link_speed;
+ u8 pad[5];
+};
+
+struct __packed atto_vda_sge {
+ u32 length;
+ u64 address;
+};
+
+
+/* VDA request function codes */
+
+#define VDA_FUNC_SCSI 0x00
+#define VDA_FUNC_FLASH0x01
+#define VDA_FUNC_DIAG 0x02
+#define VDA_FUNC_AE 0x03
+#define VDA_FUNC_CLI 0x04
+#define VDA_FUNC_IOCTL0x05
+#define VDA_FUNC_CFG 0x06
+#define VDA_FUNC_MGT 0x07
+#define VDA_FUNC_GSV 0x08
+
+
+/* VDA request status values. for host driver considerations, values for
+ * SCSI requests start at zero. other requests may use these values as well.
*/
+
+#define RS_SUCCESS 0x00/*! successful completion*/
+#define RS_INV_FUNC 0x01/*! invalid command function */
+#define RS_BUSY 0x02/*! insufficient resources */
+#define RS_SEL 0x03/*! no target at target_id */
+#define RS_NO_LUN 0x04/*! invalid LUN */
+#define RS_TIMEOUT 0x05/*! request timeout */
+#define RS_OVERRUN 0x06/*! data overrun */
+#define RS_UNDERRUN 0x07/*! data underrun*/
+#define RS_SCSI_ERROR 0x08/*! SCSI error occurred */
+#define RS_ABORTED 0x0A/*! command aborted */
+#define RS_RESID_MISM 0x0B/*! residual length incorrect*/
+#define RS_TM_FAILED0x0C/*! task management failed */
+#define RS_RESET0x0D/*! aborted due to bus reset */
+#define RS_ERR_DMA_SG 0x0E/*! error reading SG list*/
+#def
[PATCH v2 08/10] [RFC] SCSI: esas2r: Add IOCTL functions
Signed-off-by: Bradley Grove
---
drivers/scsi/esas2r/esas2r_ioctl.c | 2108
1 file changed, 2108 insertions(+)
create mode 100644 drivers/scsi/esas2r/esas2r_ioctl.c
diff --git a/drivers/scsi/esas2r/esas2r_ioctl.c
b/drivers/scsi/esas2r/esas2r_ioctl.c
new file mode 100644
index 000..34278ac
--- /dev/null
+++ b/drivers/scsi/esas2r/esas2r_ioctl.c
@@ -0,0 +1,2108 @@
+/*
+ * linux/drivers/scsi/esas2r/esas2r_ioctl.c
+ * For use with ATTO ExpressSAS R6xx SAS/SATA RAID controllers
+ *
+ * Copyright (c) 2001-2013 ATTO Technology, Inc.
+ * (mailto:linuxdriv...@attotech.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * NO WARRANTY
+ * THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR
+ * CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT
+ * LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT,
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is
+ * solely responsible for determining the appropriateness of using and
+ * distributing the Program and assumes all risks associated with its
+ * exercise of rights under this Agreement, including but not limited to
+ * the risks and costs of program errors, damage to or loss of data,
+ * programs or equipment, and unavailability or interruption of operations.
+ *
+ * DISCLAIMER OF LIABILITY
+ * NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+ * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED
+ * HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
+ * USA.
+ */
+
+#include "esas2r.h"
+
+/*
+ * Buffered ioctl handlers. A buffered ioctl is one which requires that we
+ * allocate a DMA-able memory area to communicate with the firmware. In
+ * order to prevent continually allocating and freeing consistent memory,
+ * we will allocate a global buffer the first time we need it and re-use
+ * it for subsequent ioctl calls that require it.
+ */
+
+u8 *esas2r_buffered_ioctl;
+dma_addr_t esas2r_buffered_ioctl_addr;
+u32 esas2r_buffered_ioctl_size;
+struct pci_dev *esas2r_buffered_ioctl_pcid;
+
+static DEFINE_SEMAPHORE(buffered_ioctl_semaphore);
+typedef int (*BUFFERED_IOCTL_CALLBACK)(struct esas2r_adapter *,
+ struct esas2r_request *,
+ struct esas2r_sg_context *,
+ void *);
+typedef void (*BUFFERED_IOCTL_DONE_CALLBACK)(struct esas2r_adapter *,
+struct esas2r_request *, void *);
+
+struct esas2r_buffered_ioctl {
+ struct esas2r_adapter *a;
+ void *ioctl;
+ u32 length;
+ u32 control_code;
+ u32 offset;
+ BUFFERED_IOCTL_CALLBACK
+ callback;
+ void *context;
+ BUFFERED_IOCTL_DONE_CALLBACK
+ done_callback;
+ void *done_context;
+
+};
+
+static void complete_fm_api_req(struct esas2r_adapter *a,
+ struct esas2r_request *rq)
+{
+ a->fm_api_command_done = 1;
+ wake_up_interruptible(&a->fm_api_waiter);
+}
+
+/* Callbacks for building scatter/gather lists for FM API requests */
+static u32 get_physaddr_fm_api(struct esas2r_sg_context *sgc, u64 *addr)
+{
+ struct esas2r_adapter *a = (struct esas2r_adapter *)sgc->adapter;
+ int offset = sgc->cur_offset - a->save_offset;
+
+ (*addr) = a->firmware.phys + offset;
+ return a->firmware.orig_len - offset;
+}
+
+static u32 get_physaddr_fm_api_header(struct esas2r_sg_context *sgc, u64 *addr)
+{
+ struct esas2r_adapter *a = (struct esas2r_adapter *)sgc->adapter;
+ int offset = sgc->cur_offset - a->save_offset;
+
+ (*addr) = a->firmware.header_buff_phys + offset;
+ return sizeof(struct esas2r_flash_img) - offset;
+}
+
+/* Handle EXPRESS_IOCTL_RW_FIRMWARE ioctl with img_type = FW_IMG_FM_API. */
+static void do_fm_api(struct esas2r_adapter *a, struct esas2r_flash_img *fi)
+{
+
[PATCH v2 01/10] [RFC] SCSI: esas2r: Add main header file
Signed-off-by: Bradley Grove --- drivers/scsi/esas2r/esas2r.h | 1442 ++ 1 file changed, 1442 insertions(+) create mode 100644 drivers/scsi/esas2r/esas2r.h diff --git a/drivers/scsi/esas2r/esas2r.h b/drivers/scsi/esas2r/esas2r.h new file mode 100644 index 000..b271822 --- /dev/null +++ b/drivers/scsi/esas2r/esas2r.h @@ -0,0 +1,1442 @@ +/* + * linux/drivers/scsi/esas2r/esas2r.h + * For use with ATTO ExpressSAS R6xx SAS/SATA RAID controllers + * + * Copyright (c) 2001-2013 ATTO Technology, Inc. + * (mailto:linuxdriv...@attotech.com) + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * NO WARRANTY + * THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR + * CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT + * LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is + * solely responsible for determining the appropriateness of using and + * distributing the Program and assumes all risks associated with its + * exercise of rights under this Agreement, including but not limited to + * the risks and costs of program errors, damage to or loss of data, + * programs or equipment, and unavailability or interruption of operations. + * + * DISCLAIMER OF LIABILITY + * NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR + * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE + * USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED + * HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, + * USA. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "esas2r_log.h" +#include "atioctl.h" +#include "atvda.h" + +#ifndef ESAS2R_H +#define ESAS2R_H + +/* Global Variables */ +extern struct esas2r_adapter *esas2r_adapters[]; +extern u8 *esas2r_buffered_ioctl; +extern dma_addr_t esas2r_buffered_ioctl_addr; +extern u32 esas2r_buffered_ioctl_size; +extern struct pci_dev *esas2r_buffered_ioctl_pcid; +#define SGL_PG_SZ_MIN 64 +#define SGL_PG_SZ_MAX 1024 +extern int sgl_page_size; +#define NUM_SGL_MIN 8 +#define NUM_SGL_MAX 2048 +extern int num_sg_lists; +#define NUM_REQ_MIN 4 +#define NUM_REQ_MAX 256 +extern int num_requests; +#define NUM_AE_MIN 2 +#define NUM_AE_MAX 8 +extern int num_ae_requests; +extern int cmd_per_lun; +extern int can_queue; +extern int esas2r_max_sectors; +extern int sg_tablesize; +extern int interrupt_mode; +extern int num_io_requests; + +/* Macro defintions */ +#define ESAS2R_MAX_ID255 +#define MAX_ADAPTERS 32 +#define ESAS2R_DRVR_NAME "esas2r" +#define ESAS2R_LONGNAME "ATTO ExpressSAS 6GB RAID Adapter" +#define ESAS2R_MAX_DEVICES 32 +#define ATTONODE_NAME "ATTONode" +#define ESAS2R_MAJOR_REV 1 +#define ESAS2R_MINOR_REV 00 +#define ESAS2R_VERSION_STR DEFINED_NUM_TO_STR(ESAS2R_MAJOR_REV) "." \ + DEFINED_NUM_TO_STR(ESAS2R_MINOR_REV) +#define ESAS2R_COPYRIGHT_YEARS "2001-2013" +#define ESAS2R_DEFAULT_SGL_PAGE_SIZE 384 +#define ESAS2R_DEFAULT_CMD_PER_LUN 64 +#define ESAS2R_DEFAULT_NUM_SG_LISTS 1024 +#define DEFINED_NUM_TO_STR(num) NUM_TO_STR(num) +#define NUM_TO_STR(num) #num + +#define ESAS2R_SGL_ALIGN16 +#define ESAS2R_LIST_ALIGN 16 +#define ESAS2R_LIST_EXTRA ESAS2R_NUM_EXTRA +#define ESAS2R_DATA_BUF_LEN 256 +#define ESAS2R_DEFAULT_TMO 5000 +#define ESAS2R_DISC_BUF_LEN 512 +#define ESAS2R_FWCOREDUMP_SZ0x8 +#define ESAS2R_NUM_PHYS 8 +#define ESAS2R_TARG_ID_INV 0x +#define ESAS2R_INT_STS_MASK MU_INTSTAT_MASK +#define ESAS2R_INT_ENB_MASK MU_INTSTAT_MASK +#define ESAS2R_INT_DIS_MASK 0 +#define ESAS2R_MAX_TARGETS 256 +#define ESAS2R_KOBJ_NAME_LEN20 + +/* u16 (WORD) component macros */ +#define LOBYTE(w) ((u8)(u16)(w)) +#define HIBYTE(w) ((u8)(((u16)(w)) >> 8)) +#
[PATCH v2 06/10] [RFC] SCSI: esas2r: Add flash and target database functions
Signed-off-by: Bradley Grove
---
drivers/scsi/esas2r/esas2r_flash.c | 1516 +++
drivers/scsi/esas2r/esas2r_targdb.c | 306 +++
2 files changed, 1822 insertions(+)
create mode 100644 drivers/scsi/esas2r/esas2r_flash.c
create mode 100644 drivers/scsi/esas2r/esas2r_targdb.c
diff --git a/drivers/scsi/esas2r/esas2r_flash.c
b/drivers/scsi/esas2r/esas2r_flash.c
new file mode 100644
index 000..61ef449
--- /dev/null
+++ b/drivers/scsi/esas2r/esas2r_flash.c
@@ -0,0 +1,1514 @@
+
+/*
+ * linux/drivers/scsi/esas2r/esas2r_flash.c
+ * For use with ATTO ExpressSAS R6xx SAS/SATA RAID controllers
+ *
+ * Copyright (c) 2001-2013 ATTO Technology, Inc.
+ * (mailto:linuxdriv...@attotech.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * NO WARRANTY
+ * THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR
+ * CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT
+ * LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT,
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is
+ * solely responsible for determining the appropriateness of using and
+ * distributing the Program and assumes all risks associated with its
+ * exercise of rights under this Agreement, including but not limited to
+ * the risks and costs of program errors, damage to or loss of data,
+ * programs or equipment, and unavailability or interruption of operations.
+ *
+ * DISCLAIMER OF LIABILITY
+ * NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+ * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED
+ * HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
+ * USA.
+ */
+
+#include "esas2r.h"
+
+/* local macro defs */
+#define esas2r_nvramcalc_cksum(n) \
+ (esas2r_calc_byte_cksum((u8 *)(n), sizeof(struct esas2r_sas_nvram), \
+ SASNVR_CKSUM_SEED))
+#define esas2r_nvramcalc_xor_cksum(n) \
+ (esas2r_calc_byte_xor_cksum((u8 *)(n), \
+ sizeof(struct esas2r_sas_nvram), 0))
+
+#define ESAS2R_FS_DRVR_VER 2
+
+static struct esas2r_sas_nvram default_sas_nvram = {
+ { 'E', 'S', 'A', 'S' }, /* signature */
+ SASNVR_VERSION, /* version*/
+ 0, /* checksum */
+ 31, /* max_lun_for_target */
+ SASNVR_PCILAT_MAX, /* pci_latency*/
+ SASNVR1_BOOT_DRVR, /* options1 */
+ SASNVR2_HEARTBEAT | SASNVR2_SINGLE_BUS /* options2 */
+ | SASNVR2_SW_MUX_CTRL,
+ SASNVR_COAL_DIS, /* int_coalescing */
+ SASNVR_CMDTHR_NONE, /* cmd_throttle */
+ 3, /* dev_wait_time */
+ 1, /* dev_wait_count */
+ 0, /* spin_up_delay */
+ 0, /* ssp_align_rate */
+ { 0x50, 0x01, 0x08, 0x60,/* sas_addr */
+ 0x00, 0x00, 0x00, 0x00 },
+ { SASNVR_SPEED_AUTO }, /* phy_speed */
+ { SASNVR_MUX_DISABLED }, /* SAS multiplexing */
+ { 0 }, /* phy_flags */
+ SASNVR_SORT_SAS_ADDR,/* sort_type */
+ 3, /* dpm_reqcmd_lmt */
+ 3, /* dpm_stndby_time*/
+ 0, /* dpm_active_time*/
+ { 0 }, /* phy_target_id */
+ SASNVR_VSMH_DISABLED,
[PATCH v2 05/10] [RFC] SCSI: esas2r: Add interrupt and IO functions
Signed-off-by: Bradley Grove
---
drivers/scsi/esas2r/esas2r_int.c | 940 +++
drivers/scsi/esas2r/esas2r_io.c | 883
2 files changed, 1823 insertions(+)
create mode 100644 drivers/scsi/esas2r/esas2r_int.c
create mode 100644 drivers/scsi/esas2r/esas2r_io.c
diff --git a/drivers/scsi/esas2r/esas2r_int.c b/drivers/scsi/esas2r/esas2r_int.c
new file mode 100644
index 000..f2c2a46
--- /dev/null
+++ b/drivers/scsi/esas2r/esas2r_int.c
@@ -0,0 +1,940 @@
+/*
+ * linux/drivers/scsi/esas2r/esas2r_int.c
+ * esas2r interrupt handling
+ *
+ * Copyright (c) 2001-2013 ATTO Technology, Inc.
+ * (mailto:linuxdriv...@attotech.com)
+ */
+/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * NO WARRANTY
+ * THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR
+ * CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT
+ * LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT,
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is
+ * solely responsible for determining the appropriateness of using and
+ * distributing the Program and assumes all risks associated with its
+ * exercise of rights under this Agreement, including but not limited to
+ * the risks and costs of program errors, damage to or loss of data,
+ * programs or equipment, and unavailability or interruption of operations.
+ *
+ * DISCLAIMER OF LIABILITY
+ * NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+ * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED
+ * HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
+
+#include "esas2r.h"
+
+/* Local function prototypes */
+static void esas2r_doorbell_interrupt(struct esas2r_adapter *a, u32 doorbell);
+static void esas2r_get_outbound_responses(struct esas2r_adapter *a);
+static void esas2r_process_bus_reset(struct esas2r_adapter *a);
+
+/*
+ * Poll the adapter for interrupts and service them.
+ * This function handles both legacy interrupts and MSI.
+ */
+void esas2r_polled_interrupt(struct esas2r_adapter *a)
+{
+ u32 intstat;
+ u32 doorbell;
+
+ esas2r_disable_chip_interrupts(a);
+
+ intstat = esas2r_read_register_dword(a, MU_INT_STATUS_OUT);
+
+ if (intstat & MU_INTSTAT_POST_OUT) {
+ /* clear the interrupt */
+
+ esas2r_write_register_dword(a, MU_OUT_LIST_INT_STAT,
+ MU_OLIS_INT);
+ esas2r_flush_register_dword(a, MU_OUT_LIST_INT_STAT);
+
+ esas2r_get_outbound_responses(a);
+ }
+
+ if (intstat & MU_INTSTAT_DRBL) {
+ doorbell = esas2r_read_register_dword(a, MU_DOORBELL_OUT);
+ if (doorbell != 0)
+ esas2r_doorbell_interrupt(a, doorbell);
+ }
+
+ esas2r_enable_chip_interrupts(a);
+
+ if (atomic_read(&a->disable_cnt) == 0)
+ esas2r_do_deferred_processes(a);
+}
+
+/*
+ * Legacy and MSI interrupt handlers. Note that the legacy interrupt handler
+ * schedules a TASKLET to process events, whereas the MSI handler just
+ * processes interrupt events directly.
+ */
+irqreturn_t esas2r_interrupt(int irq, void *dev_id)
+{
+ struct esas2r_adapter *a = (struct esas2r_adapter *)dev_id;
+
+ if (!esas2r_adapter_interrupt_pending(a))
+ return IRQ_NONE;
+
+ esas2r_lock_set_flags(&a->flags2, AF2_INT_PENDING);
+ esas2r_schedule_tasklet(a);
+
+ return IRQ_HANDLED;
+}
+
+void esas2r_adapter_interrupt(struct esas2r_adapter *a)
+{
+ u32 doorbell;
+
+ if (likely(a->int_stat & MU_INTSTAT_POST_OUT)) {
+ /* clear the interrupt */
+ esas2r_write_register_dword(a, MU_OUT_LIST_INT_STAT,
+ MU_OLIS_INT
Re: mpt2sas,mpt3sas watchdog device removal
On Tue, 2013-07-16 at 17:30 +0530, Reddy, Sreekanth wrote: > James, > > This patch seem to be fine. Please consider this patch. Where's the new version? The one that has all of this fixed: > Off list, Sreekanth from LSI tested and noticed a few issues with this > patch: > > - mpt2sas_base_stop_watchdog is called twice: The call from >mpt2sas_base_detach is safe, but now unnecessary (as a call was >added earlier up in the PCI driver callbacks to ensure that the >watchdog was out of the way.) This second invocation can be > removed. > > - If the watchdog detects a bad IOC, the watchdog remains running: >The watchdog workqueue isn't cleaned up until >mpt2sas_base_stop_watchdog is called, so in the case that the >watchdog removes the device from SCSI topo, the workqueue will >remain unused until PCI .remove/.shutdown cleans it up. Perhaps a >single watchdog that iterates over all adapters would be simpler? > > Finally, if SCSI topo detachment is all that is interesting here, > would > it make more sense to move the watchdog into the MPT "scsi" code? I > haven't looked at the code yet, but this might make an MPT fusion > patch > easier (due to dependencies between its "scsi" and "base" modules). ? James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: mpt2sas,mpt3sas watchdog device removal
James,
This patch seem to be fine. Please consider this patch.
Regards,
Sreekanth.
-Original Message-
From: Joe Lawrence [mailto:joe.lawre...@stratus.com]
Sent: Wednesday, May 15, 2013 11:00 PM
To: linux-scsi@vger.kernel.org
Cc: James E.J. Bottomley; Reddy, Sreekanth; Desai, Kashyap; Nandigama,
Nagalakshmi; Bjorn Helgaas
Subject: Re: mpt2sas,mpt3sas watchdog device removal
>From 84ac7a35ebd61e84d4254eae78bb967de17254c2 Mon Sep 17 00:00:00 2001
From: Joe Lawrence
Date: Wed, 15 May 2013 12:52:31 -0400
Subject: [PATCH] mpt2sas,mpt3sas: make watchdog instantiated device removal
safe
Calling pci_stop_and_remove_bus_device from a SCSI LLD may introduce device
removal races with PCI callback functions.
Simplify the mpt2sas watchdog mechanism by separating PCI device removal from
SCSI midlayer detachment. When the watchdog wishes to remove a SCSI device from
the topology, detach from the SCSI midlayer, leaving the PCI device alone.
Adjust various pci_driver callbacks to account for a potentially SCSI detached
PCI device.
Signed-off-by: Joe Lawrence
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 43 +---
drivers/scsi/mpt2sas/mpt2sas_base.h | 2 +
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 97 +---
drivers/scsi/mpt3sas/mpt3sas_base.c | 43 +---
drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 65 +++-
6 files changed, 105 insertions(+), 147 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index bcb23d2..cc1bf28 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -57,7 +57,6 @@
#include
#include
#include
-#include
#include
#include "mpt2sas_base.h"
@@ -115,29 +114,6 @@ module_param_call(mpt2sas_fwfault_debug,
_scsih_set_fwfault_debug,
param_get_int, &mpt2sas_fwfault_debug, 0644);
/**
- * mpt2sas_remove_dead_ioc_func - kthread context to remove dead ioc
- * @arg: input argument, used to derive ioc
- *
- * Return 0 if controller is removed from pci subsystem.
- * Return -1 for other case.
- */
-static int mpt2sas_remove_dead_ioc_func(void *arg) -{
- struct MPT2SAS_ADAPTER *ioc = (struct MPT2SAS_ADAPTER *)arg;
- struct pci_dev *pdev;
-
- if ((ioc == NULL))
- return -1;
-
- pdev = ioc->pdev;
- if ((pdev == NULL))
- return -1;
- pci_stop_and_remove_bus_device(pdev);
- return 0;
-}
-
-
-/**
* _base_fault_reset_work - workq handling ioc fault conditions
* @work: input argument, used to derive ioc
* Context: sleep.
@@ -152,7 +128,6 @@ _base_fault_reset_work(struct work_struct *work)
unsigned longflags;
u32 doorbell;
int rc;
- struct task_struct *p;
spin_lock_irqsave(&ioc->ioc_reset_in_progress_lock, flags);
if (ioc->shost_recovery || ioc->pci_error_recovery) @@ -186,23 +161,7
@@ _base_fault_reset_work(struct work_struct *work)
* command back from HW.
*/
ioc->schedule_dead_ioc_flush_running_cmds(ioc);
- /*
-* Set remove_host flag early since kernel thread will
-* take some time to execute.
-*/
- ioc->remove_host = 1;
- /*Remove the Dead Host */
- p = kthread_run(mpt2sas_remove_dead_ioc_func, ioc,
- "mpt2sas_dead_ioc_%d", ioc->id);
- if (IS_ERR(p)) {
- printk(MPT2SAS_ERR_FMT
- "%s: Running mpt2sas_dead_ioc thread failed \n",
- ioc->name, __func__);
- } else {
- printk(MPT2SAS_ERR_FMT
- "%s: Running mpt2sas_dead_ioc thread success \n",
- ioc->name, __func__);
- }
+ mpt2sas_scsih_detach(ioc);
return; /* don't rearm timer */
}
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.h
b/drivers/scsi/mpt2sas/mpt2sas_base.h
index 4caaac1..94d0e98 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.h
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.h
@@ -817,6 +817,7 @@ struct MPT2SAS_ADAPTER {
u8 broadcast_aen_busy;
u16 broadcast_aen_pending;
u8 shost_recovery;
+ u8 shost_attached;
struct mutexreset_in_progress_mutex;
spinlock_t ioc_reset_in_progress_lock;
@@ -1078,6 +1079,7 @@ struct _sas_device
*mpt2sas_scsih_sas_device_find_by_sas_address(
void mpt2sas_port_enable_complete(struct MPT2SAS_ADAPTER *ioc);
void mpt2sas_scsih_reset_handler(struct MPT2SAS_ADAPTER *ioc, int reset_phase);
+void mpt2sas_scsih_detach(struct MPT2SAS_ADAPTER *ioc);
/* config shared API */
u8 mpt2sas_config_done(struct MPT2SAS_ADAPTER *ioc, u16
Re: [PATCH 1/3] arcmsr: Modify maximum outstanding command
On Tue, 2013-07-16 at 18:22 +0800, 黃清隆 wrote: > From: Ching > > Modify maximum outstanding command value, notify auto request sense, reassign > ARC12x4 series to SATA adapter. > Signed-off-by:Ching > --- This patch needs to make it to the SCSI mailing list and it didn't. You can easily check this yourself by either subscribing to the reflector or looking at some of the archivers like marc: http://marc.info/?l=linux-scsi The reason it got dropped is probably because you have a text/html attachment. vger accepts text/plain only. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
