linux-kernel - Re: [PATCH 1/4] spi: Add parameter for clock to rx delay

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: <ZTvczyPdxKPd+lUG@finisterre.sirena.org.uk>
Date:   Fri, 27 Oct 2023 16:52:47 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Eberhard Stoll <estl@....net>
Cc:     linux-kernel@...r.kernel.org, linux-spi@...r.kernel.org,
        Eberhard Stoll <eberhard.stoll@...tron.de>,
        Frieder Schrempf <frieder.schrempf@...tron.de>,
        Amit Kumar Mahapatra <amit.kumar-mahapatra@....com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Krishna Yarlagadda <kyarlagadda@...dia.com>,
        Leonard Göhrs <l.goehrs@...gutronix.de>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Yang Yingliang <yangyingliang@...wei.com>
Subject: Re: [PATCH 1/4] spi: Add parameter for clock to rx delay

On Thu, Oct 26, 2023 at 05:23:02PM +0200, Eberhard Stoll wrote:
> From: Eberhard Stoll <eberhard.stoll@...tron.de>
> 
> For spi devices the master clock output defines the sampling point
> for receive data input stream (rising or falling edge). The receive
> data stream from the device is delayed in relation to the master
> clock output.
> 
> For some devices this delay is larger than one half clock period,
> which is normally the sampling point for receive data. In this case
> receive data is sampled too early and the device fails to operate.
> In consequence the spi clock has to be reduced to match the delay
> characteristics and this reduces performance and is therefore not
> recommended.
> 
> Some spi controllers implement a 'clock to receive data delay'
> compensation which shifts the receive sampling point. So we need
> a property to set this value for each spi device.
> 
> Add a parameter 'rx_sample_delay_ns' to enable setting the clock
> to rx data delay for each spi device separately.
> 
> The 'clock to receive data delay' value is often referenced as tCLQV
> in spi device data sheets.

This makes sense to me.  We should probably also have core support which
will constrain the clock rate such that we satisfy the timing constraint
if the controller can't control this, that'd need a flag to let the core
know that the controller has that ability.  Could you send an
incremental patch doing that please?

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