[patch 14/25] SCSI: use irq_handler_t where appropriate

[patch 14/25] SCSI: use irq_handler_t where appropriate

[akpm]

From: Jeff Garzik <jeff@garzik.org>

Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 drivers/scsi/aacraid/aacraid.h |    2 +-
 drivers/scsi/qla2xxx/qla_isr.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff -puN drivers/scsi/aacraid/aacraid.h~scsi-use-irq_handler_t-where-appropriate drivers/scsi/aacraid/aacraid.h
--- a/drivers/scsi/aacraid/aacraid.h~scsi-use-irq_handler_t-where-appropriate
+++ a/drivers/scsi/aacraid/aacraid.h
@@ -464,7 +464,7 @@ struct adapter_ops
 	int  (*adapter_restart)(struct aac_dev *dev, int bled);
 	/* Transport operations */
 	int  (*adapter_ioremap)(struct aac_dev * dev, u32 size);
-	irqreturn_t (*adapter_intr)(int irq, void *dev_id);
+	irq_handler_t adapter_intr;
 	/* Packet operations */
 	int  (*adapter_deliver)(struct fib * fib);
 	int  (*adapter_bounds)(struct aac_dev * dev, struct scsi_cmnd * cmd, u64 lba);
diff -puN drivers/scsi/qla2xxx/qla_isr.c~scsi-use-irq_handler_t-where-appropriate drivers/scsi/qla2xxx/qla_isr.c
--- a/drivers/scsi/qla2xxx/qla_isr.c~scsi-use-irq_handler_t-where-appropriate
+++ a/drivers/scsi/qla2xxx/qla_isr.c
@@ -1633,7 +1633,7 @@ struct qla_init_msix_entry {
 	uint16_t entry;
 	uint16_t index;
 	const char *name;
-	irqreturn_t (*handler)(int, void *);
+	irq_handler_t handler;
 };
 
 static struct qla_init_msix_entry imsix_entries[QLA_MSIX_ENTRIES] = {
_

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

[Jeff Garzik]

akpm@linux-foundation.org wrote:
> From: Jeff Garzik <jeff@garzik.org>
> 
> Signed-off-by: Jeff Garzik <jeff@garzik.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  drivers/scsi/aacraid/aacraid.h |    2 +-
>  drivers/scsi/qla2xxx/qla_isr.c |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

hrm.  This appears to have been sent to linux-scsi at least three times.

If it doesn't stick, I'll go ahead and send it up myself.

	Jeff

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

[Andrew Morton]

On Wed, 23 May 2007 18:07:35 -0400
Jeff Garzik <jeff@garzik.org> wrote:

> akpm@linux-foundation.org wrote:
> > From: Jeff Garzik <jeff@garzik.org>
> > 
> > Signed-off-by: Jeff Garzik <jeff@garzik.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > ---
> > 
> >  drivers/scsi/aacraid/aacraid.h |    2 +-
> >  drivers/scsi/qla2xxx/qla_isr.c |    2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> hrm.  This appears to have been sent to linux-scsi at least three times.

One of these patches is appearing on linux-scsi for the fifteenth time.

> If it doesn't stick, I'll go ahead and send it up myself.

Well I've had it.  If nothing happens this time I shall re-review the
ancient and neglected patches and I will merge them up myself.

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

[James Bottomley]

On Wed, 2007-05-23 at 18:07 -0400, Jeff Garzik wrote:
> akpm@linux-foundation.org wrote:
> > From: Jeff Garzik <jeff@garzik.org>
> > 
> > Signed-off-by: Jeff Garzik <jeff@garzik.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > ---
> > 
> >  drivers/scsi/aacraid/aacraid.h |    2 +-
> >  drivers/scsi/qla2xxx/qla_isr.c |    2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> hrm.  This appears to have been sent to linux-scsi at least three times.
> 
> If it doesn't stick, I'll go ahead and send it up myself.

It's not a bug fix or even an enhancement.  Historically, it is quite
difficult to get maintainers to ack these ... particularly if you don't
cc them.

James

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

[David Miller]

From: Jeff Garzik <jeff@garzik.org>
Date: Wed, 23 May 2007 18:07:35 -0400

> hrm.  This appears to have been sent to linux-scsi at least three times.
> 
> If it doesn't stick, I'll go ahead and send it up myself.

The latency on linux-scsi review and integration of patches is not so
hot lately, or perhaps I've only been paying attention recently
and this is how things always have been.

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

[Jeff Garzik]

James Bottomley wrote:
> It's not a bug fix or even an enhancement.  Historically, it is quite
> difficult to get maintainers to ack these ... particularly if you don't
> cc them.

If neither you nor the maintainers are reading and responding to patches 
sent to linux-scsi, I don't think the problem is sitting in my chair.

If others have SCSI patches that have been sitting in limbo for weeks or 
months, send them to me, and I'll queue them in misc-2.6.git#scsi.

	Jeff

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

[Andrew Vasquez]

On Wed, 23 May 2007, akpm@linux-foundation.org wrote:

> Subject: [patch 14/25] SCSI: use irq_handler_t where appropriate
> Message-Id: <200705232141.l4NLfjq9001203@shell0.pdx.osdl.net>
> 
> From: Jeff Garzik <jeff@garzik.org>
> 
> Signed-off-by: Jeff Garzik <jeff@garzik.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  drivers/scsi/aacraid/aacraid.h |    2 +-
>  drivers/scsi/qla2xxx/qla_isr.c |    2 +-

ACK -- the qla2xxx changes.

RE: [patch 14/25] SCSI: use irq_handler_t where appropriate

[Salyzyn, Mark]

I ACK the portion that resides in aacraid.h, and will track and push it
in the future if it does not stick ;->

I will comment for any dpt_i2o, ips or aacraid patches posted to the
SCSI list from submissions from folks not working at Adaptec once unit
tested, accepted into the Adaptec upstreamed source or code inspected;
as a matter of form. There will be no *requirement* to cc my maintainer
address.

Sincerely -- Mark Salyzyn

> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@SteelEye.com] 
> Sent: Wednesday, May 23, 2007 6:55 PM
> To: Jeff Garzik
> Cc: akpm@linux-foundation.org; linux-scsi@vger.kernel.org; 
> Salyzyn, Mark; Andrew Vasquez
> Subject: Re: [patch 14/25] SCSI: use irq_handler_t where appropriate
> 
> 
> On Wed, 2007-05-23 at 18:07 -0400, Jeff Garzik wrote:
> > akpm@linux-foundation.org wrote:
> > > From: Jeff Garzik <jeff@garzik.org>
> > > 
> > > Signed-off-by: Jeff Garzik <jeff@garzik.org>
> > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > > ---
> > > 
> > >  drivers/scsi/aacraid/aacraid.h |    2 +-
> > >  drivers/scsi/qla2xxx/qla_isr.c |    2 +-
> > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > hrm.  This appears to have been sent to linux-scsi at least 
> three times.
> > 
> > If it doesn't stick, I'll go ahead and send it up myself.
> 
> It's not a bug fix or even an enhancement.  Historically, it is quite
> difficult to get maintainers to ack these ... particularly if 
> you don't
> cc them.
> 
> James
> 
> 
> 

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

[James Bottomley]

On Thu, 2007-05-24 at 01:51 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > It's not a bug fix or even an enhancement.  Historically, it is quite
> > difficult to get maintainers to ack these ... particularly if you don't
> > cc them.
> 
> If neither you nor the maintainers are reading and responding to patches 
> sent to linux-scsi, I don't think the problem is sitting in my chair.

Oh come off it ... You've been around long enough to know that
maintainers are not always watching everything ... it would be nice if
they were, but to give a patch the best shot at review, you try to
attract their attention.  Specifically, in this case, you should cc the
maintainers and you should have a subject line explaining that you are
modifying their driver.  It is very easy to ignore a patch that's simply
waved at the SCSI list with a generic subject line.

> If others have SCSI patches that have been sitting in limbo for weeks or 
> months, send them to me, and I'll queue them in misc-2.6.git#scsi.

James

RE: [patch 14/25] SCSI: use irq_handler_t where appropriate

[Salyzyn, Mark]

Not being defensive.

This is not just a maintainer's issue. We see the silent ACK treatment
all the time from all avenues of inspection whether they be maintainers,
illuminati, interested parties or JAFO. There is a little bit of a
volunteer in every one of us.

Requiring the maintainer to be cc'd is a burden on the submitter, I do
not want to spank someone that comes up with a useful patch that fails
some bureaucratic litmus test. It is still a good idea, but lets try a
different tactic?

James, you are a volunteer, so I can not require an increase in your
burden. But it would be 'nice' if you had a git tree that reported
pending approval (so that makes three persistent trees if I am correct,
scsi-misc-2.6, scsi-rc-fixes-2.6 and scsi-pending-2.6?). This way we can
tell that you saw it, and as a maintainer we can see a change even if we
missed the patch email. It does make it hard for the maintainer to
report *which* patch to approve, but he could do a blanket approval of
what he sees in the pending tree? AndrewM can tell that he no longer
needs to track the patch, as it is now the SCSI list's responsibility
once it is in the pending tree.

Sincerely -- Mark Salyzyn

> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@SteelEye.com] 
> Sent: Thursday, May 24, 2007 10:04 AM
> To: Jeff Garzik
> Cc: akpm@linux-foundation.org; linux-scsi@vger.kernel.org; 
> Salyzyn, Mark; Andrew Vasquez
> Subject: Re: [patch 14/25] SCSI: use irq_handler_t where appropriate
> 
> 
> On Thu, 2007-05-24 at 01:51 -0400, Jeff Garzik wrote:
> > James Bottomley wrote:
> > > It's not a bug fix or even an enhancement.  Historically, 
> it is quite
> > > difficult to get maintainers to ack these ... 
> particularly if you don't
> > > cc them.
> > 
> > If neither you nor the maintainers are reading and 
> responding to patches 
> > sent to linux-scsi, I don't think the problem is sitting in 
> my chair.
> 
> Oh come off it ... You've been around long enough to know that
> maintainers are not always watching everything ... it would be nice if
> they were, but to give a patch the best shot at review, you try to
> attract their attention.  Specifically, in this case, you 
> should cc the
> maintainers and you should have a subject line explaining that you are
> modifying their driver.  It is very easy to ignore a patch 
> that's simply
> waved at the SCSI list with a generic subject line.
> 
> > If others have SCSI patches that have been sitting in limbo 
> for weeks or 
> > months, send them to me, and I'll queue them in misc-2.6.git#scsi.
> 
> James
> 
> 
> 

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

[Randy Dunlap]

On Thu, 24 May 2007 09:04:06 -0500 James Bottomley wrote:

> On Thu, 2007-05-24 at 01:51 -0400, Jeff Garzik wrote:
> > James Bottomley wrote:
> > > It's not a bug fix or even an enhancement.  Historically, it is quite
> > > difficult to get maintainers to ack these ... particularly if you don't
> > > cc them.
> > 
> > If neither you nor the maintainers are reading and responding to patches 
> > sent to linux-scsi, I don't think the problem is sitting in my chair.
> 
> Oh come off it ... You've been around long enough to know that
> maintainers are not always watching everything ... it would be nice if
> they were, but to give a patch the best shot at review, you try to
> attract their attention.  Specifically, in this case, you should cc the
> maintainers and you should have a subject line explaining that you are
> modifying their driver.  It is very easy to ignore a patch that's simply
> waved at the SCSI list with a generic subject line.

I can understand subsystem maintainers ignoring lkml, but ignoring
the subsystem mailing list makes no sense to me, especially if the
subject contains "[PATCH]".

> > If others have SCSI patches that have been sitting in limbo for weeks or 
> > months, send them to me, and I'll queue them in misc-2.6.git#scsi.


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

RE: [patch 14/25] SCSI: use irq_handler_t where appropriate

[James Bottomley]

On Thu, 2007-05-24 at 10:28 -0400, Salyzyn, Mark wrote:
> This is not just a maintainer's issue. We see the silent ACK treatment
> all the time from all avenues of inspection whether they be maintainers,
> illuminati, interested parties or JAFO. There is a little bit of a
> volunteer in every one of us.
> 
> Requiring the maintainer to be cc'd is a burden on the submitter, I do
> not want to spank someone that comes up with a useful patch that fails
> some bureaucratic litmus test. It is still a good idea, but lets try a
> different tactic?
> 
> James, you are a volunteer, so I can not require an increase in your
> burden. But it would be 'nice' if you had a git tree that reported
> pending approval (so that makes three persistent trees if I am correct,
> scsi-misc-2.6, scsi-rc-fixes-2.6 and scsi-pending-2.6?). This way we can
> tell that you saw it, and as a maintainer we can see a change even if we
> missed the patch email. It does make it hard for the maintainer to
> report *which* patch to approve, but he could do a blanket approval of
> what he sees in the pending tree? AndrewM can tell that he no longer
> needs to track the patch, as it is now the SCSI list's responsibility
> once it is in the pending tree.

We can certainly try that approach.  Please note that scsi-pending-2.6
will essentially be a quilt like tree (i.e. constantly rebasing) so it
will be impossible to pull incrementally from it ... but you will be
able to fetch from it and just check it out to give the patches an
inspection/try out.

James

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

[James Bottomley]

On Thu, 2007-05-24 at 08:17 -0700, Randy Dunlap wrote:
> On Thu, 24 May 2007 09:04:06 -0500 James Bottomley wrote:
> 
> > On Thu, 2007-05-24 at 01:51 -0400, Jeff Garzik wrote:
> > > James Bottomley wrote:
> > > > It's not a bug fix or even an enhancement.  Historically, it is quite
> > > > difficult to get maintainers to ack these ... particularly if you don't
> > > > cc them.
> > > 
> > > If neither you nor the maintainers are reading and responding to patches 
> > > sent to linux-scsi, I don't think the problem is sitting in my chair.
> > 
> > Oh come off it ... You've been around long enough to know that
> > maintainers are not always watching everything ... it would be nice if
> > they were, but to give a patch the best shot at review, you try to
> > attract their attention.  Specifically, in this case, you should cc the
> > maintainers and you should have a subject line explaining that you are
> > modifying their driver.  It is very easy to ignore a patch that's simply
> > waved at the SCSI list with a generic subject line.
> 
> I can understand subsystem maintainers ignoring lkml, but ignoring
> the subsystem mailing list makes no sense to me, especially if the
> subject contains "[PATCH]".

SCSI is a slightly different subsystem from almost any other in the
kernel.  It has something like 15 active driver maintainers plus at
least another 15-25 periodically active ones.  Most (but not all) driver
maintainers are employed by the company who produces the board/chip and
tend to be overloaded with a lot of non-linux work.  Requiring acks for
maintained drivers is a courtesy to make sure we don't get maintainers
spending time trying to resolve conflicts.  I'm not mandating any
particular method of getting acks, just noting that cc'ing maintainers
and having specific subject lines mentioning the driver is a reasonable
way of getting them to notice.

James

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

[Jeff Garzik]

James Bottomley wrote:
> SCSI is a slightly different subsystem from almost any other in the
> kernel.  It has something like 15 active driver maintainers plus at
> least another 15-25 periodically active ones.  Most (but not all) driver
> maintainers are employed by the company who produces the board/chip and
> tend to be overloaded with a lot of non-linux work.  Requiring acks for
> maintained drivers is a courtesy to make sure we don't get maintainers
> spending time trying to resolve conflicts.  I'm not mandating any
> particular method of getting acks, just noting that cc'ing maintainers
> and having specific subject lines mentioning the driver is a reasonable
> way of getting them to notice.


Linux has never worked that way.  We always have a stream of patches 
that are multi-subsystem cleanups and the like.  Blocking these patches 
for months at a time because individual driver maintainers are off doing 
non-Linux work is just not realistic.

The system is broken, from where I sit.  In pretty much every other 
subsystem in the kernel, the subsystem maintainer makes sure patches 
don't get stuck in limbo for months.

	Jeff

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

[Jeff Garzik]

James Bottomley wrote:
> On Thu, 2007-05-24 at 01:51 -0400, Jeff Garzik wrote:
>> James Bottomley wrote:
>>> It's not a bug fix or even an enhancement.  Historically, it is quite
>>> difficult to get maintainers to ack these ... particularly if you don't
>>> cc them.
>> If neither you nor the maintainers are reading and responding to patches 
>> sent to linux-scsi, I don't think the problem is sitting in my chair.
> 
> Oh come off it ... You've been around long enough to know that
> maintainers are not always watching everything ... it would be nice if
> they were, but to give a patch the best shot at review, you try to
> attract their attention.  Specifically, in this case, you should cc the
> maintainers and you should have a subject line explaining that you are
> modifying their driver.  It is very easy to ignore a patch that's simply
> waved at the SCSI list with a generic subject line.

If individual driver maintainers are not paying attention to what is 
going on in their subsystem, and in the kernel as a whole, then the 
problem does not lie with the external patch author.

	Jeff

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

[Stefan Richter]

Randy Dunlap wrote:
> On Thu, 24 May 2007 09:04:06 -0500 James Bottomley wrote:
>> maintainers are not always watching everything ... it would be nice if
>> they were, but to give a patch the best shot at review, you try to
>> attract their attention.  Specifically, in this case, you should cc the
>> maintainers and you should have a subject line explaining that you are
>> modifying their driver.  It is very easy to ignore a patch that's simply
>> waved at the SCSI list with a generic subject line.
> 
> I can understand subsystem maintainers ignoring lkml, but ignoring
> the subsystem mailing list makes no sense to me, especially if the
> subject contains "[PATCH]".

I mostly agree.  It becomes difficult with cross-subsystem patches
though.  The difficulty with such patches is that the subsystem
mailinglist which was chosen as adressee doesn't tell the whole picture,
and the subject, even if chosen carefully, often cannot explicitly tell
which places it touches.

On the other hand, submitters of nontrivial cross-subsystem patches can
be expected to put some extra care in their submission, i.e. to add
respective personal addresses.  (And of course to include a diffstat!)

The patch "SCSI: use irq_handler_t where appropriate" is of course not a
patch of this kind.  Also, it is of the sort which IMO doesn't need a
driver maintainer's ACK in the first place.  Sure, it wouldn't have hurt
a lot to call it for example "SCSI: use irq_handler_t in aacraid and
qla2xxx", even though that information will be redundant /after/ it went
into a git tree.
-- 
Stefan Richter
-=====-=-=== -=-= ==--=
http://arcgraph.de/sr/

Re: [patch 14/25] SCSI: use irq_handler_t where appropriate

[Stefan Richter]

Jeff Garzik wrote:
> James Bottomley wrote:
>> SCSI is a slightly different subsystem from almost any other in the
>> kernel.  It has something like 15 active driver maintainers plus at
>> least another 15-25 periodically active ones.  Most (but not all) driver
>> maintainers are employed by the company who produces the board/chip and
>> tend to be overloaded with a lot of non-linux work.

(People who do maintenance on a volunteer basis in spare time tend to be
overloaded with a lot of non-Linux work too.)

>> Requiring acks for
>> maintained drivers is a courtesy to make sure we don't get maintainers
>> spending time trying to resolve conflicts.  I'm not mandating any
>> particular method of getting acks, just noting that cc'ing maintainers
>> and having specific subject lines mentioning the driver is a reasonable
>> way of getting them to notice.
> 
> Linux has never worked that way.  We always have a stream of patches 
> that are multi-subsystem cleanups and the like.  Blocking these patches 
> for months at a time because individual driver maintainers are off doing 
> non-Linux work is just not realistic.

I agree.  Merge conflicts and similar issues with such cleanup patches
or API conversions and the like are issues which driver maintainers and
even subsystem maintainers just have to cope with.  Of course it's a
different matter with patches which change functionality.

The time spent to resolve conflicts
   - can pay off if overall time to handle patch flow is reduced,
   - can be minimized by trying to react quickly on simpler patches.
-- 
Stefan Richter
-=====-=-=== -=-= ==--=
http://arcgraph.de/sr/

RE: [patch 14/25] SCSI: use irq_handler_t where appropriate

[James Bottomley]

On Thu, 2007-05-24 at 10:21 -0500, James Bottomley wrote:
> On Thu, 2007-05-24 at 10:28 -0400, Salyzyn, Mark wrote:
> > This is not just a maintainer's issue. We see the silent ACK treatment
> > all the time from all avenues of inspection whether they be maintainers,
> > illuminati, interested parties or JAFO. There is a little bit of a
> > volunteer in every one of us.
> > 
> > Requiring the maintainer to be cc'd is a burden on the submitter, I do
> > not want to spank someone that comes up with a useful patch that fails
> > some bureaucratic litmus test. It is still a good idea, but lets try a
> > different tactic?
> > 
> > James, you are a volunteer, so I can not require an increase in your
> > burden. But it would be 'nice' if you had a git tree that reported
> > pending approval (so that makes three persistent trees if I am correct,
> > scsi-misc-2.6, scsi-rc-fixes-2.6 and scsi-pending-2.6?). This way we can
> > tell that you saw it, and as a maintainer we can see a change even if we
> > missed the patch email. It does make it hard for the maintainer to
> > report *which* patch to approve, but he could do a blanket approval of
> > what he sees in the pending tree? AndrewM can tell that he no longer
> > needs to track the patch, as it is now the SCSI list's responsibility
> > once it is in the pending tree.
> 
> We can certainly try that approach.  Please note that scsi-pending-2.6
> will essentially be a quilt like tree (i.e. constantly rebasing) so it
> will be impossible to pull incrementally from it ... but you will be
> able to fetch from it and just check it out to give the patches an
> inspection/try out.

OK, this is basically done.  I've set up the pending tree here:

http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-pending-2.6.git;a=summary

Since it's wet out today, I also coded up a git update hook that emails
people who get patches into this tree and the maintainers nagging about
needed acks.

James