linux-kernel - Re: AW: [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]

Date:   Mon, 30 Oct 2023 10:48:08 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Mark Brown <broonie@...nel.org>, Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.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 04:45:25PM +0100, Mark Brown wrote:
> 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.

So, then the question is what does DT _actually_ describes?
If we have an autoprobe of something that doesn't work on platform A and works
on platform B, shouldn't these platforms have to have distinguishable DTs?

-- 
With Best Regards,
Andy Shevchenko