[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkda2yQefuUMn6Ot8Ns6nNgfC25i9nwmzwxOy5fUg=A44hQ@mail.gmail.com>
Date: Fri, 9 Jun 2023 10:42:04 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Alexander Stein <alexander.stein@...tq-group.com>
Cc: Matthias Schiffer <matthias.schiffer@...tq-group.com>,
linux-arm-kernel@...ts.infradead.org,
Mark Brown <broonie@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, linux-spi@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux@...tq-group.com
Subject: Re: [PATCH 1/2] spi: dt-bindings: introduce linux,use-rt-queue flag
On Fri, Jun 9, 2023 at 10:15 AM Alexander Stein
<alexander.stein@...tq-group.com> wrote:
> > A agree with Mark that a command line option isn't that bad. It's something
> > that pertains to just the Linux kernel after all? And you can put that
> > command line option in the default device tree, in chosen, if you want.
>
> I don't like the idea of a command line enabling realtime scheduling for all
> instances of the SPI controller driver or even all SPI controllers. Actually
> this might be worse if a non-rt SPI bus is considered for RT scheduling.
> IMHO this should be configurable per SPI controller,
OK that's a fair point.
I don't think command line arguments are necessarily global by
nature, AFAIK it's fine to invent something like pl022.4.rt_sched=1
where 4 is the instance number. Parsing it is just code.
> e.g. a sysfs attribute.
But it needs to be set before userspace is up :/
I fully sympathize with this problem, because I have faced
similar problems myself.
My fallback solution for this driver would be to keep using the
old DT property (which was merged when reviewing was
not as strict) if that works, or use undocumented DT properties,
it's not the end of the world but does leave the bad taste of
a work not finished.
Yours,
Linus Walleij
Powered by blists - more mailing lists