[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210520135615.GB3962@sirena.org.uk>
Date: Thu, 20 May 2021 14:56:15 +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 net-next] net: dsa: sja1105: adapt to a SPI controller
with a limited max transfer size
On Thu, May 20, 2021 at 04:50:31PM +0300, Vladimir Oltean wrote:
> Only that certain SPI controllers, such as the spi-sc18is602 I2C-to-SPI
> bridge, cannot keep the chip select asserted for that long.
> The spi_max_transfer_size() and spi_max_message_size() functions are how
> the controller can impose its hardware limitations upon the SPI
> peripheral driver.
You should respect both, frankly I don't see any advantage to using
cs_change for something like this - just do a bunch of async SPI
transfers and you'll get the same effect in terms of being able to keep
the queue for the controller primed with more robust support since it's
not stressing edge cases. cs_change is more for doing things that are
just very non-standard.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists