public inbox for arm-scmi@vger.kernel.org
 help / color / mirror / Atom feed
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


      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