linux-kernel - Re: [PATCH v2 10/10] soc: aspeed: lpc-snoop: Lift channel config to const structs

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: <24c957d3e63bf6dcd58b0807df79350d4b111926.camel@codeconstruct.com.au>
Date: Tue, 08 Jul 2025 11:37:33 +0930
From: Andrew Jeffery <andrew@...econstruct.com.au>
To: Jean Delvare <jdelvare@...e.de>
Cc: linux-aspeed@...ts.ozlabs.org, Joel Stanley <joel@....id.au>, Henry
 Martin <bsdhenrymartin@...il.com>, Patrick Rudolph
 <patrick.rudolph@...ements.com>,  Andrew Geissler <geissonator@...oo.com>,
 Ninad Palsule <ninad@...ux.ibm.com>, Patrick Venture <venture@...gle.com>, 
 Robert Lippert <roblip@...il.com>, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 10/10] soc: aspeed: lpc-snoop: Lift channel config to
 const structs

Hi Jean,

On Fri, 2025-07-04 at 18:23 +0200, Jean Delvare wrote:
> 
> > @@ -189,28 +215,27 @@ static int aspeed_lpc_snoop_config_irq(struct aspeed_lpc_snoop *lpc_snoop,
> >  }
> >  
> >  __attribute__((nonnull))
> > -static int aspeed_lpc_enable_snoop(struct aspeed_lpc_snoop *lpc_snoop,
> > -                                  struct device *dev,
> > -                                  enum aspeed_lpc_snoop_index index, u16 lpc_port)
> > +static int aspeed_lpc_enable_snoop(struct device *dev,
> > +                                   struct aspeed_lpc_snoop *lpc_snoop,
> > +                                   struct aspeed_lpc_snoop_channel *channel,
> > +                                   const struct aspeed_lpc_snoop_channel_cfg *cfg,
> > +                                   u16 lpc_port)
> >  {
> 
> I'm confused by this new calling convention. With lpc_snoop and index,
> you could already retrieve the aspeed_lpc_snoop_channel struct and the
> aspeed_lpc_snoop_channel_cfg struct. I can't see the benefit of the
> change. 
> 

My motivation for this choice was to isolate the association between
indexes into the arrays to the call-site of aspeed_lpc_enable_snoop(),
rather than have that information spread through the implementation.

I considered the approaches you outline next before posting v2, so
while they have their merits as well, I'm going to chalk this one up to
personal preference on my part.

> It even forces you to add an index field to struct
> aspeed_lpc_snoop_channel_cfg, which would otherwise not be needed.
> 
> If you prefer to pass cfg instead of index as a parameter, that does
> not imply passing channel too. You can get the index from the cfg (if
> you decide to keep it in that struct), and then the channel from index.
> 
> Or you could even pass only the channel (to be consistent with
> aspeed_lpc_disable_snoop), if you set channel->cfg before calling this
> function. Again this implies keeping index in struct
> aspeed_lpc_snoop_channel_cfg.

*snip*

> 
> > -
> > -       /* Enable LPC snoop channel at requested port */
> > -       regmap_update_bits(lpc_snoop->regmap, HICR5, hicr5_en, hicr5_en);
> > -       regmap_update_bits(lpc_snoop->regmap, SNPWADR, snpwadr_mask,
> > -                          lpc_port << snpwadr_shift);
> > +       regmap_set_bits(lpc_snoop->regmap, HICR5, cfg->hicr5_en);
> > +       regmap_update_bits(lpc_snoop->regmap, SNPWADR, cfg->snpwadr_mask,
> > +               lpc_port << cfg->snpwadr_shift);
> 
> It is a good practice to align the second line on the opening
> parenthesis of the first line (as was done originally).

Thanks, I've fixed this up.

*snip*

> >  
> >  static int aspeed_lpc_snoop_probe(struct platform_device *pdev)
> > @@ -339,6 +326,8 @@ static int aspeed_lpc_snoop_probe(struct platform_device *pdev)
> >         if (rc)
> >                 return rc;
> >  
> > +       static_assert(ARRAY_SIZE(channel_cfgs) == ARRAY_SIZE(lpc_snoop->chan),
> > +               "Broken implementation assumption regarding cfg count");
> 
> Both also need to be equal to ASPEED_LPC_SNOOP_INDEX_MAX + 1, right?
> Otherwise the loop below would break. But it turns out that both arrays
> are now declared that way, so it just has to be true. This makes me
> believe that this static assert is no longer needed.

My intent was to convey that we require the arrays to be the same
length, as opposed to being declared such that they happen to have the
same length. It's a property of the design rather than the
implementation. All static_assert()s should be obviously true; IMO
their purpose is to communicate requirements and constrain change.

With the view to getting these patches applied I intend to keep it.

Thanks,

Andrew