[PATCH v3 2/2] irqchip/aspeed-intc: Add support for AST27XX INTC
Kevin Chen
kevin_chen at aspeedtech.com
Tue Oct 15 21:19:49 AEDT 2024
>
> > > I propose to move selected variable definitions into corresponding
> > > compound statements (by using extra curly brackets).
> > > https://refactoring.com/catalog/reduceScopeOfVariable.html
> > OK. I moved these two local variables into scoped_guard.
>
> Will development interests grow for further refactorings?
Do you have any example for this refactorings?
>
>
> > +static void aspeed_intc_ic_irq_handler(struct irq_desc *desc) {
> > + struct aspeed_intc_ic *intc_ic =
> > +irq_desc_get_handler_data(desc);
>
> Another update candidate (for scope reduction)?
Variable of intc_ic used in "scoped_guard(raw_spinlock, &intc_ic->gic_lock) {".
Or, how can I reduce the scope of intc_ic?
>
>
> > +
> > + guard(chained_irq)(desc);
>
> Using another macro call “scoped_guard(…) { … }”?
Is it necessary to use scoped_guard(...) {...}?
In the end of aspeed_intc_ic_irq_handler, chained_irq_exit would be called as destructor.
Only one reason I thought is that the chained_irq_exit is needed to be called in the middle of aspeed_intc_ic_irq_handler.
>
>
> > + scoped_guard(raw_spinlock, &intc_ic->gic_lock) {
>
> Would you like to reconsider the proposed macro mixture once more?
Could I check the reason for once more?
>
>
> > + unsigned long bit, status;
> …
>
> …
> > +++ b/include/linux/irqchip/chained_irq.h
> > @@ -38,4 +38,6 @@ static inline void chained_irq_exit(struct irq_chip *chip,
> > chip->irq_unmask(&desc->irq_data);
> > }
> >
> > +DEFINE_GUARD(chained_irq, struct irq_desc *,
> chained_irq_exit((_T->irq_data.chip), (_T)),
> > + chained_irq_enter((_T->irq_data.chip), (_T)))
>
> Would you like to add a #include directive in this header file accordingly?
Can you give me an example?
>
> Regards,
> Markus
More information about the Linux-aspeed
mailing list