From: Cristian Marussi <cristian.marussi@arm.com>
To: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Sudeep Holla <sudeep.holla@kernel.org>,
Cristian Marussi <cristian.marussi@arm.com>,
Marek Vasut <marek.vasut@mailbox.org>,
arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH 0/3] firmware: arm_scmi: Miscellaneous improvements
Date: Sun, 12 Apr 2026 19:44:58 +0100 [thread overview]
Message-ID: <advoKvOSGpOEN_qX@pluto> (raw)
In-Reply-To: <cover.1775205358.git.geert+renesas@glider.be>
On Fri, Apr 03, 2026 at 10:41:28AM +0200, Geert Uytterhoeven wrote:
> Hi all,
Hi Geert,
thanks for this, first of all.
I was a bit off the keyboard so the delay in my answer.
I will get back at this SCMI/Clocks/Quirks matters in the next few weeks
targeting next rc1-ish...
In a nutshell I was thinking to proceed roughly as follows:
- respinning a V3 of my original Clock Rates series WITH the addtion
of your previous fixes series on top (or merged into) BUT DROPPING
from my original series the patch that triggered a lot of FW panics
in the wild due to out of spec FWs. (Harden Clock protocol initialization)
- spinning another NEW series on top of this 'Miscellaneous improvement'
series of yours, since I want to add, on top of this rework of yours, the
capability for the Quirk framework to match the same quirk definition
(static key) against multiple vendors/subvendors/impl....since, as you may
have noticed :P, I broke a number of boards recently with just one fix
kernel side BUT all of these issues can be really quirked using some
common identical quirk snippet to match against all the needed vendors
(rockchip/nxp/renesas as of now)
...I have some ugly working hack with which I am experimenting on this
quirk matching evolution...
On top of all of this I would then reapply the FW-breaking fix AND all
the quirks we determine as needed (possibly N matching M vendoes) and
test as much as possible pushing into for-next...
Then we'll see what Sudeep thinks about all of this, of course.
Thoughts ? Any feedback welcome.
Thanks,
Cristian
prev parent reply other threads:[~2026-04-12 18:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-03 8:41 [PATCH 0/3] firmware: arm_scmi: Miscellaneous improvements Geert Uytterhoeven
2026-04-03 8:41 ` [PATCH 1/3] firmware: arm_scmi: quirk: Improve quirk range parsing Geert Uytterhoeven
2026-04-03 8:41 ` [PATCH 2/3] firmware: arm_scmi: quirk: Simplify quirk table iteration Geert Uytterhoeven
2026-04-03 8:41 ` [PATCH 3/3] firmware: arm_scmi: Convert to list_for_each_entry() Geert Uytterhoeven
2026-04-12 18:44 ` Cristian Marussi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=advoKvOSGpOEN_qX@pluto \
--to=cristian.marussi@arm.com \
--cc=arm-scmi@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=marek.vasut@mailbox.org \
--cc=sudeep.holla@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox