linux-kernel - Re: [PATCH 3/5] gpio: aspeed-sgpio: Create llops to handle hardware access

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] [day] [month] [year] [list]

Message-ID:
 <OSQPR06MB72528801E014FB1CAFB410F28B88A@OSQPR06MB7252.apcprd06.prod.outlook.com>
Date: Mon, 19 Jan 2026 03:37:09 +0000
From: Billy Tsai <billy_tsai@...eedtech.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Linus Walleij <linusw@...nel.org>, Bartosz Golaszewski <brgl@...nel.org>,
	Joel Stanley <joel@....id.au>, Andrew Jeffery <andrew@...econstruct.com.au>,
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, "linux-gpio@...r.kernel.org"
	<linux-gpio@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-aspeed@...ts.ozlabs.org"
	<linux-aspeed@...ts.ozlabs.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Andrew Jeffery <andrew@...id.au>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, BMC-SW
	<BMC-SW@...eedtech.com>
Subject: Re: [PATCH 3/5] gpio: aspeed-sgpio: Create llops to handle hardware
 access




> > > @@ -318,30 +278,25 @@ static int aspeed_sgpio_set_type(struct irq_data *d, unsigned int type)
> > >       u32 type0 = 0;
> > >       u32 type1 = 0;
> > >       u32 type2 = 0;
> > > -     u32 bit, reg;
> > > -     const struct aspeed_sgpio_bank *bank;
> > >       irq_flow_handler_t handler;
> > > -     struct aspeed_sgpio *gpio;
> > > -     void __iomem *addr;
> > > -     int offset;
> > > -
> > > -     irqd_to_aspeed_sgpio_data(d, &gpio, &bank, &bit, &offset);
> > > +     struct aspeed_sgpio *gpio = irq_data_get_irq_chip_data(d);
> > > +     int offset = irqd_to_hwirq(d);
> > >
> > >       switch (type & IRQ_TYPE_SENSE_MASK) {
> > >       case IRQ_TYPE_EDGE_BOTH:
> > > -             type2 |= bit;
> > > +             type2 = 1;
> > >               fallthrough;
> > >       case IRQ_TYPE_EDGE_RISING:
> > > -             type0 |= bit;
> > > +             type0 = 1;
> > >               fallthrough;
> > >       case IRQ_TYPE_EDGE_FALLING:
> > >               handler = handle_edge_irq;
> > >               break;
> > >       case IRQ_TYPE_LEVEL_HIGH:
> > > -             type0 |= bit;
> > > +             type0 = 1;
> > >               fallthrough;
> > >       case IRQ_TYPE_LEVEL_LOW:
> > > -             type1 |= bit;
> > > +             type1 = 1;
> > >               handler = handle_level_irq;
> > >               break;

> > This change is not obviously correct to me. It is not about
> > abstracting register accesses, what you actually write to the
> > registers appears to of changed. Maybe you could add a refactoring
> > patch first which does this change, with a commit message explaining
> > it, and then insert the register abstraction?

> You’re right — viewed together, this change is not obviously correct and makes
> the refactoring harder to review.
> 
> While the llops interface is designed to handle bit positioning internally
> (changing the semantics from passing a bitmask to passing a value), combining
> this semantic change with the abstraction refactoring increases review
> complexity.
> 
> To address this, I will respin the series and split it into:
>                 1.            a preparatory refactoring patch that introduces the llops helpers without
> changing behavior, and
>                 2.            a follow-up patch that switches callers to the new value-based interface,
> with a commit message explicitly explaining the semantic change.

Follow-up clarification

I’d like to clarify this part after double-checking the logic.

You’re right that, when viewed in isolation, this change is not obviously correct.

In the llops-based design, the semantics intentionally change from passing a
bitmask to passing an offset plus a value. The llops helpers are responsible for
deriving the correct bit position internally. The same model is used on the
other side as well, so functionally this does not change the behavior.

Thanks again for pointing this out.

Billy Tsai