netdev - Re: [PATCH v3 net-next 1/2] net: dsa: sja1105: send multiple spi_messages instead of using cs

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: <20210607175611.GD10625@sirena.org.uk>
Date:   Mon, 7 Jun 2021 18:56:11 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        linux-spi@...r.kernel.org, Guenter Roeck <linux@...ck-us.net>,
        Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH v3 net-next 1/2] net: dsa: sja1105: send multiple
 spi_messages instead of using cs_change

On Mon, May 24, 2021 at 04:02:12PM +0300, Vladimir Oltean wrote:
> On Mon, May 24, 2021 at 09:35:29AM +0100, Mark Brown wrote:

> > This is not the case, spi_message_max_size() is a limit on the size of a
> > spi_message.

> That is true, although it doesn't mean much, since in the presence of
> cs_change, a spi_message has no correspondent in the physical world
> (i.e. you can't look at a logic analyzer dump and say "this spi_message
> was from this to this point"), and that is the problem really.

It may affect how things are implemented by the driver, for example if
the driver can send a command stream to the hardware the limit might be
due to that command stream.  There is no need or expectation for drivers
to pattern match what the're being asked to do and parse out something
that should be a string of messages from the spi_message they get, it is
expected that client drivers should split things up naturally.

> Describing the controller's inability to send more than N SPI words with
> continuous chip select using spi_message_max_size() is what seems flawed
> to me, but it's what we have, and what I've adapted to.

I can't entirely parse that but the limit here isn't to do with how long
chip select is asserted for.

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