mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Julia Lawall <julia@diku.dk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Yinghai Lu <yinghai@kernel.org>, Ingo Molnar <mingo@elte.hu>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 06/12] genericirq: make irq_chip related function to take desc
Date: Sun, 21 Mar 2010 15:19:58 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.64.1003211515310.12371@ask.diku.dk> (raw)
In-Reply-To: <m1iq8p23af.fsf@fess.ebiederm.org>

On Sun, 21 Mar 2010, Eric W. Biederman wrote:

> Julia Lawall <julia@diku.dk> writes:
> 
> > I also worked on this, but only sent it to Thomas and Yinghai.  Onthe 
> > other hand, I mostly like your solution better, because it has the 
> > unintended side-effect of getting rid of some blank spaces after {s.
> 
> Wow I hadn't noticed that {s removal. That is an old coding style
> violation on alpha.  There was an intentional effect of not breaking
> up { }'s.  But I hadn't realized I was also fixing whitespace.

I think it is because you added a local declaration of irq and then 
removed it when it was not necessary.  So then coccinelle was motivated to 
remove the space after the {.

> > My rule was also more complicated in that it also searches for conditions 
> > in which it is not sure to be doing the right thing.  I will send those in 
> > another message.
> >
> >> @ DECL @
> >> struct irq_chip CHIP;
> >> identifier METHOD;
> >> identifier METHOD_NAME;
> >> @@
> >>  CHIP.METHOD_NAME = METHOD;
> >> 
> >> @ @
> >> identifier DECL.METHOD;
> >> identifier IRQ;
> >> @@
> >>  METHOD(
> >> -		unsigned int IRQ
> >> +		struct irq_desc *unused
> >>  , ...) {
> >>  }
> >
> > I didn't think of making a special rule for this.  It could consider any 
> > case where the body is ... when != IRQ
> 
> Nice addition.
> 
> >> @ @
> >> identifier DECL.METHOD;
> >> identifier IRQ;
> >> identifier DESC;
> >> @@
> >>  METHOD(
> >> -		unsigned int IRQ
> >> +		struct irq_desc *DESC
> >>  , ...) {
> >> +	unsigned int IRQ = DESC->irq;
> >>  	...
> >> -	struct irq_desc *DESC = irq_to_desc(IRQ);
> >> 	...
> >>  }
> >> 
> >> @ @
> >> identifier DECL.METHOD;
> >> identifier IRQ;
> >> identifier DESC;
> >> @@
> >>  METHOD(
> >> -		unsigned int IRQ
> >> +		struct irq_desc *DESC
> >>  , ...) {
> >> +	unsigned int IRQ = DESC->irq;
> >>  	...
> >> -	struct irq_desc *DESC;
> >> 	...
> >> -	DESC = irq_to_desc(IRQ);
> >> 	...
> >>  }
> >> 
> >> @ @
> >> identifier DECL.METHOD;
> >> identifier IRQ;
> >> @@
> >>  METHOD(
> >> -		unsigned int IRQ
> >> +		struct irq_desc *desc
> >>  , ...) {
> >> +	unsigned int IRQ = desc->irq;
> >>  ...
> >>  }
> >> 
> >> @ @
> >> identifier DECL.METHOD;
> >> identifier FUNC;
> >> identifier IRQ;
> >> @@
> >>  FUNC(...) {
> >>  <...
> >> 	METHOD(
> >> -		IRQ
> >> +		irq_to_desc(IRQ)
> >>  		, ... )
> >>  ...>
> >>  }
> >
> > I don't think FUNC(...) { <... and ...> } are needed here.  The goal is to 
> > make the change everywhere the call appears.
> 
> That is a reasonable simplification.
> 
> >> @ @
> >> identifier FUNC;
> >> identifier DESC;
> >> identifier IRQ;
> >> @@
> >>  FUNC(..., struct irq_desc *DESC, ...) {
> >>  ...
> >>  	unsigned int IRQ = DESC->irq;
> >>  <...
> >> -	irq_to_desc(IRQ)
> >> +	DESC
> >>  ...>
> >>  }
> >
> > This rule can be extended as follows:
> 
> Nice.  I had not picked up on the or operator.
> 
> > @ @
> > identifier FUNC;
> > identifier DESC;
> > identifier IRQ;
> > identifier FLD;
> > @@
> >  FUNC(..., struct irq_desc *DESC, ...) {
> >  ...
> >         unsigned int IRQ = DESC->irq;
> >  <...
> > (
> > -       irq_to_desc(IRQ)
> > +       DESC
> > |
> > -       irq_desc[IRQ].FLD
> > +       DESC->FLD
> > )
> >  ...>
> >  }
> >
> > Doing so gets rid of more references to IRQ.
> 
> Very reasonable, especially on arches like alpha where none of the
> sparse irq work has hit.
> 
> 
> > Another case that can be treated is method calls via a pointer:
> 
> I didn't actually find any cases where that rule hit on arch/x86
> so I did not include it, but it makes sense.
> 
> > @@
> > expression arg;
> > struct irq_desc *desc;
> > struct irq_chip *ic;
> > identifier fun;
> > @@
> >
> > (
> >   desc->chip->fun(
> > -   arg
> > +   desc
> >     ,...)
> > |
> >   ic->fun(
> > -   arg
> > +   irq_to_desc(arg)
> >     ,...)
> > )
> 
> 
> My paranoid sense says this rule should be:
> @ @
> expresion IRQ_EXPR;
> struct irq_desc *DESC;
> struct irq_chip *CHIP;
> identifier METHOD;
> @@
> (
>  	DESC->chip->METHOD(
> -			   IRQ_EXPR
> +			   irq_to_desc(IRQ_EXPR)
> 			   , ... )
> |
> 	CHIP->METHOD(
> -		     IRQ_EXPR
> +		     irq_to_desc(IRQ_EXPR)
> 		     , ... )

Agreed.  But then it would be nice to check whether DESC is already 
computed as irq_to_desc(IRQ_EXPR).

julia

> If this is before my irq_to_desc removal rule.  We should not
> see any new irq_to_desc calls popping up.
> 
> > julia
> >
> >> @ @
> >> identifier FUNC;
> >> identifier DESC;
> >> identifier IRQ;
> >> @@
> >>  FUNC(..., struct irq_desc *DESC, ...) {
> >>  ...
> >> -	unsigned int IRQ = DESC->irq;
> >>  ... when != IRQ
> >>  }
> 

  reply	other threads:[~2010-03-21 14:20 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-04 10:08 [PATCH 0/12] irq related: make function to take irq_desc pointer instead of irq Yinghai Lu
2010-03-04 10:08 ` [PATCH 01/12] x86: fix out of order of gsi - full Yinghai Lu
2010-03-04 10:08 ` [PATCH 02/12] x86: set nr_irqs_gsi only in probe_nr_irqs_gsi Yinghai Lu
2010-03-04 10:08 ` [PATCH 03/12] x86: kill smpboot_hooks.h Yinghai Lu
2010-03-04 10:08 ` [PATCH 04/12] x86: use vector_desc instead of vector_irq Yinghai Lu
2010-03-04 10:08 ` [PATCH 05/12] genericirq: make irq_chip to have member with irq_desc pointer Yinghai Lu
2010-03-04 10:08 ` [PATCH 06/12] genericirq: make irq_chip related function to take desc Yinghai Lu
2010-03-04 14:31   ` Thomas Gleixner
2010-03-04 18:56     ` Yinghai Lu
2010-03-04 19:08       ` Thomas Gleixner
2010-03-04 19:20         ` Yinghai Lu
2010-03-05  7:47       ` Julia Lawall
2010-03-21  4:18         ` Eric W. Biederman
2010-03-21 11:03           ` Julia Lawall
2010-03-21 13:11             ` [PATCH] irq: Start the transition of irq_chip methods taking a desc Eric W. Biederman
2010-03-21 14:43               ` Thomas Gleixner
2010-03-21 18:50                 ` Yinghai Lu
2010-03-22  0:32                 ` Eric W. Biederman
2010-03-21 13:49             ` [PATCH 06/12] genericirq: make irq_chip related function to take desc Eric W. Biederman
2010-03-21 14:19               ` Julia Lawall [this message]
2010-03-21 16:29               ` Julia Lawall
2010-03-21 11:08           ` Julia Lawall
2010-03-21 11:43             ` Eric W. Biederman
2010-03-21 19:16           ` Julia Lawall
2010-03-21 19:35           ` Julia Lawall
2010-03-21 19:36           ` Julia Lawall
2010-03-22  0:36             ` Eric W. Biederman
2010-03-04 19:18     ` Yinghai Lu
2010-03-04 10:08 ` [PATCH 07/12] genericirq: make hpet_msi/ht/msi/dmar_msi " Yinghai Lu
2010-03-04 10:08 ` [PATCH 08/12] x86: make irq_chip to use desc_mask instead of mask Yinghai Lu
2010-03-04 15:10   ` [PATCH 08/12] x86: make irq_chip to use desc_mask instead of maskn Thomas Gleixner
2010-03-04 10:08 ` [PATCH 09/12] x86: irq_chip to use desc_mask instead of mask part 2 Yinghai Lu
2010-03-04 10:08 ` [PATCH 10/12] genericirq: add set_irq_desc_chip/data Yinghai Lu
2010-03-04 10:08 ` [PATCH 11/12] x86/iommu/dmar: update iommu/inter_remapping to use desc Yinghai Lu
2010-03-04 10:08 ` [PATCH 12/12] x86: remove arch_probe_nr_irqs Yinghai Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.1003211515310.12371@ask.diku.dk \
    --to=julia@diku.dk \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®