linux-kernel - RE: [PATCH v3 2/2] irqchip/aspeed-intc: Add support for AST27XX INTC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <PSAPR06MB49496CC4F25425753EA4252C89452@PSAPR06MB4949.apcprd06.prod.outlook.com>
Date: Tue, 15 Oct 2024 10:19:49 +0000
From: Kevin Chen <kevin_chen@...eedtech.com>
To: Markus Elfring <Markus.Elfring@....de>, "linux-aspeed@...ts.ozlabs.org"
	<linux-aspeed@...ts.ozlabs.org>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>
CC: Andrew Jeffery <andrew@...econstruct.com.au>, Conor Dooley
	<conor+dt@...nel.org>, Joel Stanley <joel@....id.au>, Krzysztof Kozlowski
	<krzk+dt@...nel.org>, Rob Herring <robh@...nel.org>, Thomas Gleixner
	<tglx@...utronix.de>, "kernel-janitors@...r.kernel.org"
	<kernel-janitors@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
	BMC-SW <BMC-SW@...eedtech.com>
Subject: RE: [PATCH v3 2/2] irqchip/aspeed-intc: Add support for AST27XX INTC

> 
> > > 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