linux-kernel - Re: [PATCH 1/2] spi: ar934x: fix transfer size

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]

Date:   Wed, 22 Dec 2021 14:59:30 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Oskari Lemmelä <oskari@...mela.net>
Cc:     linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] spi: ar934x: fix transfer size

On Wed, Dec 22, 2021 at 04:27:36PM +0200, Oskari Lemmelä wrote:
> On 22.12.2021 14.32, Mark Brown wrote:

> > Does this actually materially affect what the hardware does?  How much
> > data is transferred in an internal loop in the driver is completely
> > immaterial, bits per word only matters for formatting of the transferred
> > data.

> I don't have logic analyzator to verify what hardware actual does.
> I tested this with transferring 32bits to ATSAMD20J15 slave.
> Running loop in 8bits or 16bits, transfer is done correctly without
> any errors. When running loop in 24bits or 32bits directly I got
> error from spi_sync_transfer.

This doesn't inspire confidence TBH.  Given the lack of any change in
the interaction with the hardware it doesn't seem likely that the word
length is being changed at any point.  Possibly there's a bug somewhere
that needs fixing but it's been misdiagnosed.

Note also that the commit log is not good here, now I look at the code
the driver only supports 8 bits per word at the minute and the change
adds support for higher word lengths.  If you are seeing an issue that
might point towards what it is.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)