Re: [PATCH v1] spi: designware: add support for bits-per-word DT binding

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]

On Tue, Mar 03, 2026 at 08:37:21AM -0600, Tom Rini wrote:
> On Tue, Mar 03, 2026 at 03:59:35PM +0800, Ng, Boon Khai wrote:
> > Hi Tom,
> > 
> > > I don't see this binding in v7.0-rc1, did I miss it? Thanks.
> > > 
> > 
> > This binding was not introduce in Linux. This is a per-requisite commit
> > to support the Agilex Smart NIC 60xx board https://www.silicom-usa.com/wp-content/uploads/2024/02/FPGA-SmartNIC-N6010-AgileX-Based.pdf
> > 
> > During the initialization stage, this board require a spi communication to
> > configure the chip's PLL and also to check the chip's status.
> > 
> > and it require the specific spi bits-per-word=16 setting.
> > 
> > Can i add the binding at U-Boot?
> > https://github.com/u-boot/u-boot/blob/master/doc/device-tree-bindings/spi/snps%2Cdw-apb-ssi.txt
> 
> Why would this be inappropraite for the Linux kernel, once the system is

Did you mean "inappropraite", or actually appropriate? Guess it
doesn't really matter to me, since the former would be asking "why would
linux not want this" and the latter would be "why would linux want
this". And I guess, as U-Boot maintainer the former is more important so
inappropriate is actually what you meant. I, of course, always approach
things with the latter mindset ;)

> fully supported in Linux is the first question to answer. Thanks.

The property doesn't make sense to me in a linux context. bits_per_word
as explained here is a device setting should be set in the device driver,
and is almost always per-compatible so doesn't even need to come from dt
at all. What a controller can support is also effectively always
determinable from the compatible of the controller, and is often a range.

Looking at the linux driver, all dw spi controllers appear to be able to
support 4-16 bits per word with select devices also supporting 32. The
check is done at runtime, it has no need for a property at all. The
device driver effectively decides what is done for the transfer, within
the range of supported values by the controller, based on what it sets
in its spi_device struct. I don't know if u-boot has similar
functionality in its code, but looking at dm_spi_slave_plat which I
think is your version of spi_device, that information is not there.

Were this submitted to linux with the current explanation, the feedback
would be to set bits_per_word in the driver for whatever this "chip"
that's being talked about is, presumably that means setting it in some
sort of clock driver given that it controls a PLL?

Cheers,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]