linux-kernel - Re: [RFC PATCH v2 09/12] spi: cadence-quadspi: add PHY tuning infrastructure

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: <012a44f3-973f-4f34-be69-286cf924a6c6@ti.com>
Date: Sat, 7 Feb 2026 00:55:49 +0530
From: Santhosh Kumar K <s-k6@...com>
To: Miquel Raynal <miquel.raynal@...tlin.com>
CC: <broonie@...nel.org>, <robh@...nel.org>, <krzk+dt@...nel.org>,
	<conor+dt@...nel.org>, <richard@....at>, <vigneshr@...com>,
	<tudor.ambarus@...aro.org>, <pratyush@...nel.org>, <mwalle@...nel.org>,
	<linux-spi@...r.kernel.org>, <devicetree@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-mtd@...ts.infradead.org>,
	<praneeth@...com>, <u-kumar1@...com>, <p-mantena@...com>, <a-dutta@...com>,
	<s-k6@...com>
Subject: Re: [RFC PATCH v2 09/12] spi: cadence-quadspi: add PHY tuning
 infrastructure



On 05/02/26 23:09, Miquel Raynal wrote:
> On 13/01/2026 at 19:46:14 +0530, Santhosh Kumar K <s-k6@...com> wrote:
> 
>> Implement the spi_controller_mem_ops execute_tuning callback to enable
>> PHY tuning support for the Cadence controller. PHY tuning optimizes data
>> capture timing at high frequencies by calibrating the read data capture
>> delay through the controller's PHY interface.
>>
>> Tuning algorithm functions (cqspi_phy_tuning_ddr/sdr and
>> cqspi_phy_pre/post_config) are placeholders to be implemented
>> in subsequent commits.
>>
>> Signed-off-by: Santhosh Kumar K <s-k6@...com>
>> ---
>>   drivers/spi/spi-cadence-quadspi.c | 241 ++++++++++++++++++++++++++++++
>>   1 file changed, 241 insertions(+)
>>
>> diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
>> index 0df286d24256..b8b0e85f4f68 100644
>> --- a/drivers/spi/spi-cadence-quadspi.c
>> +++ b/drivers/spi/spi-cadence-quadspi.c
>> @@ -32,6 +32,7 @@
>>   
>>   #define CQSPI_NAME			"cadence-qspi"
>>   #define CQSPI_MAX_CHIPSELECT		4
>> +#define CQSPI_AM654_NON_PHY_CLK_RATE	25000000
>>   
>>   static_assert(CQSPI_MAX_CHIPSELECT <= SPI_DEVICE_CS_CNT_MAX);
>>   
>> @@ -65,6 +66,7 @@ struct cqspi_st;
>>   struct cqspi_flash_pdata {
>>   	struct cqspi_st	*cqspi;
>>   	u32		clk_rate;
>> +	u32		non_phy_clk_rate;
> 
> This is the second (and last) main issue I have with the series as it is
> right now. We cannot set this type of frequency in the driver IMO, it is
> too board specific.
> 
> We currently have a DT property for the SPI maximum supported
> frequency. I believe this is no longer enough. Why not making this
> frequency property an array? First frequency would be the default,
> non tuned maximum frequency. The second would be the maximum frequency
> reachable when tuning the PHY.

If the concern is only about where this is set, we could introduce a DT
property such as "non-phy-max-freq" to carry this information. This
would allow us to avoid any changes to the existing "spi-max-frequency"
handling. Let me know your thoughts on this.

I'll also test the approach you suggested and share my inputs based on
the results. By the way, where are you insisting to adjust/switch to
the maximum frequency - within the controller driver or in the
spi-core?

Regards,
Santhosh.

> 
> The rest of the patch LGTM otherwise, but there is this frequency
> information which I think should be handled with more care.
> 
> Thanks,
> Miquèl