linux-kernel - Re: [PATCH 2/3] spmi: add a spmi driver for Apple SoC

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: <CAMT+MTREFq2_ABXZF-WsAkw9qP6eXd7gQwgFGm7fw6nBntdbyQ@mail.gmail.com>
Date: Thu, 6 Mar 2025 09:25:21 +0100
From: Sasha Finkelstein <fnkl.kernel@...il.com>
To: Stephen Boyd <sboyd@...nel.org>
Cc: Alyssa Rosenzweig <alyssa@...enzweig.io>, Conor Dooley <conor+dt@...nel.org>, 
	Janne Grunau <j@...nau.net>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Rob Herring <robh@...nel.org>, 
	Sasha Finkelstein via B4 Relay <devnull+fnkl.kernel.gmail.com@...nel.org>, Sven Peter <sven@...npeter.dev>, 
	asahi@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, 
	Jean-Francois Bortolotti <jeff@...to.fr>
Subject: Re: [PATCH 2/3] spmi: add a spmi driver for Apple SoC

On Wed, 5 Mar 2025 at 23:11, Stephen Boyd <sboyd@...nel.org> wrote:
>
> Quoting Sasha Finkelstein via B4 Relay (2025-03-05 12:26:40)
> > +       while (len_to_read < bc) {
> > +               rsp = read_reg(spmi, SPMI_RSP_REG);
> > +               i = 0;
> > +               while ((len_to_read < bc) && (i < 4)) {
> > +                       __buf[len_to_read++] = ((0xff << (8 * i)) & rsp) >>
> > +                                              (8 * i);
> > +                       i += 1;
> > +               }
>
> Is this ioread32_rep()?
>
[...]
> > +       while (i < bc) {
> > +               j = 0;
> > +               spmi_cmd = 0;
> > +               while ((j < 4) & (i < bc))
> > +                       spmi_cmd |= __buf[i++] << (j++ * 8);
>
> Is this iowrite32_rep()? Perhaps unaligned sizes have to be dealt with,
> but otherwise I suspect it would be more efficient to use
> iowrite32_rep() until the number of bytes is less than 4 and then do the
> one extra pack.

I think it would be better to leave them open-coded, io{read,write}32_rep
casts the buffer to u32 and accesses it that way, probably resulting in
unaligned accesses, and we are on arm64.