linux-kernel - Re: [PATCH 5/7] spi: zynqmp-gqspi: Split the bus

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]

Message-ID: <1f7cb52d-31a4-458c-9b81-b46bf56fd8a8@linux.dev>
Date: Tue, 21 Jan 2025 10:53:53 -0500
From: Sean Anderson <sean.anderson@...ux.dev>
To: "Mahapatra, Amit Kumar" <amit.kumar-mahapatra@....com>,
 Mark Brown <broonie@...nel.org>, "Simek, Michal" <michal.simek@....com>,
 "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>
Cc: Jinjie Ruan <ruanjinjie@...wei.com>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 Miquel Raynal <miquel.raynal@...tlin.com>,
 "amitrkcian2002@...il.com" <amitrkcian2002@...il.com>,
 "git (AMD-Xilinx)" <git@....com>
Subject: Re: [PATCH 5/7] spi: zynqmp-gqspi: Split the bus

On 1/21/25 08:19, Mahapatra, Amit Kumar wrote:
> Hello Andreson,
> 
>> -----Original Message-----
>> From: Sean Anderson <sean.anderson@...ux.dev>
>> Sent: Friday, January 17, 2025 4:51 AM
>> To: Mark Brown <broonie@...nel.org>; Simek, Michal <michal.simek@....com>;
>> linux-spi@...r.kernel.org
>> Cc: Jinjie Ruan <ruanjinjie@...wei.com>; linux-arm-kernel@...ts.infradead.org;
>> Mahapatra, Amit Kumar <amit.kumar-mahapatra@....com>; linux-
>> kernel@...r.kernel.org; Miquel Raynal <miquel.raynal@...tlin.com>; Sean
>> Anderson <sean.anderson@...ux.dev>
>> Subject: [PATCH 5/7] spi: zynqmp-gqspi: Split the bus
>> 
>> This device supports two separate SPI busses: "lower" (SPI0) and "upper"
>> (SPI1). Each SPI bus has separate clock and data lines, as well as a hardware-
>> controlled chip select. The busses may be driven independently, with only one bus
>> active at a time, or in concert, with both busses active. If both busses are driven at
>> once, data may either be duplicated on each bus or striped (bitwise) across both
>> busses.
>> 
>> The current driver does not model this situation. It exposes one bus, where CS 0
>> uses the lower bus and the lower chip select, and CS 1 uses the upper bus and the
>> upper chip select. It is not possible to use the upper chip select with the lower bus
>> (or vice versa). GPIO chip selects are unsupported, and there would be no way to
>> specify which bus to use if they were.
>> 
>> To conserve pins, designers may wish to place multiple devices on a single SPI bus.
>> Add support for this by splitting the "merged" bus into an upper and lower bus. Each
>> bus uses a separate devicetree node and has a single native chipselect 0. If "lower"
> 
> IMHO, restricting users to fixed names is not ideal. A better approach would be to 
> introduce a Device Tree (DT) property for the bus number and select the bus 
> accordingly.

Why? It's not an artificial restriction; it reflects the hardware. And this is how
SPI busses are typically represented. If you have two SPI busses, there should be
two devicetree nodes.

--Sean