[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZTvbFc+kFMotVUkh@finisterre.sirena.org.uk>
Date: Fri, 27 Oct 2023 16:45:25 +0100
From: Mark Brown <broonie@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: "Stoll, Eberhard" <eberhard.stoll@...tron.de>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Eberhard Stoll <estl@....net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
"Schrempf, Frieder" <frieder.schrempf@...tron.de>,
Amit Kumar Mahapatra <amit.kumar-mahapatra@....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>,
Yang Yingliang <yangyingliang@...wei.com>
Subject: Re: AW: [PATCH 1/4] spi: Add parameter for clock to rx delay
On Fri, Oct 27, 2023 at 02:46:42PM +0300, Andy Shevchenko wrote:
> So, to me sounds like device tree source issue. I.e. you need to provide
> different DT(b)s depending on the platform (and how it should be).
> The cleanest solution (as I see not the first time people I trying quirks like
> this to be part of the subsystems / drivers) is to make DT core (OF) to have
> conditionals or boot-time modifications allowed.
> This, what you are doing, does not scale and smells like an ugly hack.
No, this seems like an entirely reasonable thing to have - it's just a
property of the device, we don't need to add a DT property for it, and
the maximum speed that the device can run at is going to vary depending
on the ability of the controller to control the sampling point.
As people have been saying there's a particularly clear case for this
with SPI flash which is probed at runtime and is readily substituted at
the hardware level.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists