* [GIT PULL] Mailbox changes for v7.1
From: Jassi Brar @ 2026-04-26 22:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-arm-kernel, Linux Kernel Mailing List
Hi Linus,
The following changes since commit 11439c4635edd669ae435eec308f4ab8a0804808:
Linux 7.0-rc2 (2026-03-01 15:39:31 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox.git
tags/mailbox-v7.1
for you to fetch changes up to 6e937f4e769e60947909e3525965f0137b9039e8:
mailbox: mailbox-test: make data_ready a per-instance variable
(2026-04-18 13:10:14 -0500)
----------------------------------------------------------------
mailbox: updates for v7.1
- core: fix NULL message handling and add API to query TX queue slots
- test: resolve concurrency bugs, dangling IRQs, and memory leaks
- dt-bindings: qcom: add Eliza IPCC
- mtk: fix address calculation and pointer handling bugs
- cix: resolve SCMI suspend timeouts
- misc memory allocation optimizations and cleanups
----------------------------------------------------------------
Abel Vesa (1):
dt-bindings: mailbox: qcom-ipcc: Document the Eliza
Inter-Processor Communication Controller
Dylan Wu (1):
mailbox: cix: Add IRQF_NO_SUSPEND to mailbox interrupt
Felix Gu (1):
mailbox: mtk-vcp-mailbox: Fix the return value in mtk_vcp_mbox_xlate()
Jason-JH Lin (1):
mailbox: mtk-cmdq: Fix CURR and END addr for task insert case
Jassi Brar (2):
mailbox: add API to query available TX queue slots
mailbox: Fix NULL message support in mbox_send_message()
Rosen Penev (2):
mailbox: rockchip: kzalloc + kcalloc to kzalloc
mailbox: hi6220: kzalloc + kcalloc to kzalloc
Wolfram Sang (12):
mailbox: exynos: drop superfluous mbox setting per channel
mailbox: test: really ignore optional memory resources
mailbox: correct kdoc title for mbox_bind_client
mailbox: remove superfluous internal header
mailbox: prefix new constants with MBOX_
mailbox: mailbox-test: free channels on probe error
mailbox: add sanity check for channel array
mailbox: update kdoc for struct mbox_controller
mailbox: mailbox-test: handle channel errors consistently
mailbox: mailbox-test: don't free the reused channel
mailbox: mailbox-test: initialize struct earlier
mailbox: mailbox-test: make data_ready a per-instance variable
.../devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 +
drivers/mailbox/cix-mailbox.c | 6 +-
drivers/mailbox/exynos-mailbox.c | 4 --
drivers/mailbox/hi3660-mailbox.c | 2 -
drivers/mailbox/hi6220-mailbox.c | 14 ++--
drivers/mailbox/imx-mailbox.c | 4 +-
drivers/mailbox/mailbox-sti.c | 2 -
drivers/mailbox/mailbox-test.c | 80 +++++++++++++---------
drivers/mailbox/mailbox.c | 67 +++++++++++-------
drivers/mailbox/mailbox.h | 12 ----
drivers/mailbox/mtk-cmdq-mailbox.c | 10 +--
drivers/mailbox/mtk-vcp-mailbox.c | 2 +-
drivers/mailbox/omap-mailbox.c | 4 +-
drivers/mailbox/pcc.c | 2 -
drivers/mailbox/rockchip-mailbox.c | 9 +--
drivers/mailbox/tegra-hsp.c | 6 +-
include/linux/mailbox_client.h | 1 +
include/linux/mailbox_controller.h | 17 +++--
18 files changed, 124 insertions(+), 119 deletions(-)
delete mode 100644 drivers/mailbox/mailbox.h
^ permalink raw reply
* Re: [PATCH/RFC 05/14] firmware: arm_scmi: Add scmi_get_base_info()
From: Cristian Marussi @ 2026-04-26 23:03 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Cristian Marussi, Sudeep Holla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto, arm-scmi, linux-arm-kernel, linux-renesas-soc,
linux-clk, devicetree, linux-pm, linux-kernel
In-Reply-To: <CAMuHMdWJvMH+a1RqozbaCxxH_8M569JcruTFa8PW+87FysnjHw@mail.gmail.com>
On Fri, Apr 24, 2026 at 02:08:55PM +0200, Geert Uytterhoeven wrote:
> Hi Cristian,
Hi Geert,
>
> On Wed, 22 Apr 2026 at 20:45, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > On Tue, Apr 21, 2026 at 08:11:38PM +0200, Geert Uytterhoeven wrote:
> > > Currently non-SCMI drivers cannot find out what the specific versions of
> > > each SCMI provider implementation on the running system are.
> >
> > Thanks for your patches....this is not a proper full review of the series,
> > BUT this patch catched my eye..
> >
> > Indeed, yes, it is deliberate that the SCMI version information is NOT
> > exposed out of the SCMI world, since being the SCMI an attempt to
> > standardize a common FW interface (as in [1] of course), you should not
> > know what runs inside the black-box, it should be irrelevant...
> >
> > ...indeed the versioning is used inside the SCMI stack to deal properly
> > with different protocol versions implemented by the server OR to apply
> > proper quirks when needed, but all the rest should be standard....
> >
> > ...you should NOT really behave differently based on the underneath
> > protocol or firmare implementation version...it is the SCMI stack that
> > should behave properly, transparently...
>
> Oh well...
>
> > Having said that...I understand that at least it could be useful to be able
> > to query the SCMI stack to know, even from non-SCMI drivers, WHICH quirks
> > have been applied/activated at run time...but anything more than that it
>
> I see no need for that, but we can discover which quirks have been
> applied from the kernel log ;-)
Ok so I may have misunderstood...it seemed to me, glancing through the
series that you wanted sort of reconfigure other non-SCMI drivers based
on the SCMI FW version assuming that some quirks were applied BUT also
that some sort of corrective workaround was needed additionally...so
what I was saying was that: is not more straightforward to be possibly
able to check if a quirk has been applied instead of querying the
version from outside ?
>
> > seems to me dangerous and prone to a number of abuses of the SCMI stack
> > itself...
> >
> > (Also...exposing the versions itself means also tracking that bit of info
> > in more than one place: the quirk framework and your drivers.)
>
> I'll see if I can get everything handled as quirks instead...
>
> > > However, different versions may use different ABIs (e.g. different clock
> > > IDs), or behave different, requiring remapping or workarounds in other
> > > drivers.
> >
> > ...abuse like this indeed :P ... the SCMI server is supposed to be that
> > one entity remapping the IDs in the background if the same IDs happen to
> > be representing different physical resources across a number of distinct
> > platforms all supported by the same firmware blob...so as to present
> > a consistent set of contiguos IDs...
>
> In our case it is just a single platform, with different ID number
> spaces for different firmware versions.
Yes understood.
>
> > Also because this should be one of the selling point of the SCMI stack
> > in a virtualized environment: you can ship the same kernel drivers with
> > the same DT and you know that ID=<N> will always identify the specific
> > resource that is needed by your driver without worrying about the fact
> > that in reality in the backstage the effectively managed physical resource
> > could be different across different platforms, because that does not matter
>
> This sounds strange to me, do I understand it correctly?
> So the ID should (1) be tied to the use-case, and not to the underlying
> hardware, and (2) be the same for different platforms?
>
> For (1): Then we must not put these IDs in DT at all, as DT is supposed
> to describe the hardware (and firmware IDs in DT were IMHO already
> a stretch before).
> For (2): How can there be a contiguous list of IDs, as not all platforms
> may have the same underlying hardware?
>
I would NOT say that an SCMI FW must behave like this regarding IDs, but it
is a possible SCMI deployed setup that can be useful in virtualized setups
I mean, the DT describes the hardware of course BUT when you refer to
some of this hardware DT bits from some other subsystem by referencing a
phandle, even in the non-SCMI world, you are in fact selecting a specific
resource that fit you use case, right ? Can we say this ?
I mean you needed that specific clock or regulator that you described
previously so as to be able to enable some other piece of HW...
Now, the SCMI provides an abstraction on top of this, since you really
discover domain IDs of a specific class (clocks/regulators etc) you are
in fact describing an HW abstraction that you then refer with the usual
phandle...also because there is NOT so much SCMI hardware to describe,
given that the HW is handled transparently (opaquely really :P) by the
driver on the FW side...
...you basically obtain such domain ID, usable as phandles through dynamic
SCMI enumeration so that you can use it all over your DT to make use of such
resources...
...on top of this, consider that the SCMI server CAN provide to its agents
a per-agent-view of the world, IOW it can (and should) expose to a specific
agent ONLY the resources needed by that agent, i.e. it can expose the set
of resources 1-N to two distinct agents and that does NOT mean that the
underlying physical resource mapped by ID=3 in both agents has to be
effectively the same piece of hardware: it could be the case, and this
would be useful to exposed and managed properly a shared resource, or
it could also be that the same ID=3 could refer to completely distinct
pieces of the same class of hardware...(same protocol same class of
resource...)
In fact the SCMI server provides an abstraction, sometime a mere illusion
to the agents...
So in a virtualized ennvironment you could expose the same ID to a pair
of distinct agents on distinct VMs, so that you can use the same driver
and same DT despite the fact that maybe the underlying resources are
distinct pieces of hardware ...
...OR on the other side you could decide to share the same resource with
different agents (say a clock) and take care, as a server, of armonizing
conflicting requests from different agents (e.g. by refcounting enable/disable
across all agents), WITHOUT necessarily need to expose that same resource
with the same ID to both agents...
...and you can easily draw a parallel from this virtualization dynamic
scenario to a more static usecase where you have a FW shipped on
multiple boards and so capable of serving, in fact, multiple distinct
agents, but this time, just NOT all together like the VM, but one at time
depending on which board configuration is booted...
....all of this madness of course has a chance to work ONLY if the SCMI
server takes care to remap such resources properly at build-time or
run-time as a contiguos set of IDs, based on the expected agents that
it has to serve
I am, of course, disillusioned enough NOT to believe that many FW were
shipped around trying to fit this ideal SCMI deployment scenario BUT at
least we try, kernel side, NOT to ease these kind of design that goes
pretty much against the SCMI ideas of a system (and the spec to some
extent if you punch holes in the IDs sets), and even more we try NOT
to legalize/normalize out-of-spec FW behaviours by fixing the driver,
where required, and deploying needed quirks to let existing boards survive
(..and that becomes quickly much more a pain in the ass for us then for the
FW guys :P)
> > if the SCMI platform server had properly remapped (at build time/run-time ?)
> > the resources to your expected ID...alternatively of course you can ship
> > with different DTs to describe different hardware...BUT remmapping stuff
>
> That is a different issue: as SCMI covers the full platform, not just
> the SoC, the IDs can be board-specific, and thus should be specified
> in the board .dts, not in the SoC .dtsi?
> Then the SoC .dtsi should describe the hardware, and we end up with
> things like arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts?
>
> > in the drivers themselves guessing on the vendor/subvendor/impl_vers
> > seems a dangerous abuse...
>
> There is no guessing.
>
> > I watched a bit of the LPC discussions around this (from Marek I think)
> > but sincerely most of those problems had one (not necessarily simple)
> > solution: fix your firmwares AND/OR apply quirks in the meantime...
>
> Unfortunately (at this point) we have to work with the firmware that exists.
>
> From that LPC discussion, we learned that we are actually the lucky
> guys: some other vendors tend to change the IDs and/or behavior without
> bumping the version, so Linux cannot even act upon that...
>
Oh I know that :P ... the whole SCMI quirk framework has been introduced
to cope with FW issue from one vendor that afterwards fixed their FW
issue BUT did NOT take care to update properly their FW versions upon
each release...so their quirks will be like diamonds, forever !
... no matter how many fixed-FW they will deploy :P
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v2 08/13] firmware: arm_scmi: Harden clock protocol initialization
From: Cristian Marussi @ 2026-04-26 23:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Cristian Marussi, Nicolas Frattaroli, linux-kernel,
linux-arm-kernel, arm-scmi, linux-clk, linux-renesas-soc,
sudeep.holla, philip.radford, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek,
dan.carpenter, geert+renesas, kuninori.morimoto.gx,
marek.vasut+renesas
In-Reply-To: <CAMuHMdXYGRzq2j3z1io=kHj_QsWtJBirPhbZPa5bFBD7U9e0sw@mail.gmail.com>
On Fri, Apr 24, 2026 at 03:55:08PM +0200, Geert Uytterhoeven wrote:
> Hi Cristian,
Hi,
>
> On Fri, 24 Apr 2026 at 15:32, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > On Fri, Apr 24, 2026 at 02:07:59PM +0200, Nicolas Frattaroli wrote:
> > > On Tuesday, 10 March 2026 19:40:25 Central European Summer Time Cristian Marussi wrote:
> > > > Add proper error handling on failure to enumerate clocks features or
> > > > rates.
>
> > > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > > > ---
> > > > drivers/firmware/arm_scmi/clock.c | 22 ++++++++++++++++------
> > > > 1 file changed, 16 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
> > > > index c9b62edce4fd..bf956305a8fe 100644
> > > > --- a/drivers/firmware/arm_scmi/clock.c
> > > > +++ b/drivers/firmware/arm_scmi/clock.c
> > > > @@ -402,10 +402,16 @@ static int scmi_clock_attributes_get(const struct scmi_protocol_handle *ph,
> > > > SUPPORTS_RATE_CHANGE_REQUESTED_NOTIF(attributes))
> > > > clk->rate_change_requested_notifications = true;
> > > > if (PROTOCOL_REV_MAJOR(ph->version) >= 0x3) {
> > > > - if (SUPPORTS_PARENT_CLOCK(attributes))
> > > > - scmi_clock_possible_parents(ph, clk_id, cinfo);
> > > > - if (SUPPORTS_GET_PERMISSIONS(attributes))
> > > > - scmi_clock_get_permissions(ph, clk_id, clk);
> > > > + if (SUPPORTS_PARENT_CLOCK(attributes)) {
> > > > + ret = scmi_clock_possible_parents(ph, clk_id, cinfo);
> > > > + if (ret)
> > > > + return ret;
> > > > + }
> > > > + if (SUPPORTS_GET_PERMISSIONS(attributes)) {
> > > > + ret = scmi_clock_get_permissions(ph, clk_id, clk);
> > > > + if (ret)
> > > > + return ret;
> > > > + }
> > > > if (SUPPORTS_EXTENDED_CONFIG(attributes))
> > > > clk->extended_config = true;
> > > > }
> > > > @@ -1143,8 +1149,12 @@ static int scmi_clock_protocol_init(const struct scmi_protocol_handle *ph)
> > > > for (clkid = 0; clkid < cinfo->num_clocks; clkid++) {
> > > > cinfo->clkds[clkid].id = clkid;
> > > > ret = scmi_clock_attributes_get(ph, clkid, cinfo);
> > > > - if (!ret)
> > > > - scmi_clock_describe_rates_get(ph, clkid, cinfo);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + ret = scmi_clock_describe_rates_get(ph, clkid, cinfo);
> > > > + if (ret)
> > > > + return ret;
> > > > }
> > > >
> > > > if (PROTOCOL_REV_MAJOR(ph->version) >= 0x3) {
> > > >
> > >
> > > I see that a quirk is being added for this, but I thought I should chime
> > > in with my opinion for future approaches in this direction.
> > >
> > > I don't see how this hardens anything. All this does is break platforms
> > > that were previously working by returning early. At most, this should
> >
> > Certainly the naming in the subject was chosen badly (by me!)...indeed it
> > should be more something like "Enforce strict protocol compliance",
> > because at the end all of the broken platforms really run a slighly odd
> > out of spec SCMI firmware that does NOT implement one or more of the SCMI
> > mandatory command...
> >
> > > be a warning (as in not WARN but pr_warn/dev_warn/...). If firmware
> > > returns nonsense, a clock driver should imho try its best to work
> > > around the nonsense in a safe way, because the alternative is that
> > > a major part of the system (and thus likely the entire system) no
> >
> > ..well yes we definitely dont want to break deployed platforms BUT also
> > we dont want to legalize this kind of out of spec behaviour in future
> > firmwares...hence (a number ?) of quirks an FW_BUG warns probably to
> > let already broken deployed platforms survive while discouraging such
> > implementation in future fw implementations...
> >
> > These firmware most certainly wont pass the SCMI compliance test suite [1],
> > which indeed we do not mandate, but the reason these bugs happened is
> > exactly because the kernel SCMI stack was buggy and left that door open...
> >
> > More specifically these kind of out-of-spec behaviours are not really just
> > a matter being 'picky', the problem is that any resource set in any
> > SCMI protocol is defined by the spec such as to be described by a
> > contiguos set of IDs and the drivers are designed anyway under that
> > assumption from the allocation point of view, so allowing a clock ID to
> > just fail one of the mandatory commands and skip a domain would jeopardize
> > all of this and, even if clearly is NOT a problem here, seems a fragile
> > assumption.
>
> How can you have all of:
> 1. a contiguous list of IDs,
> 2. implement all mandatory commands,
> 2. restrict the use of some clocks to a subset of the agents in the system?
> Use a different list of IDs for each agent?
Yes, the SCMI server can provide a per-agent view of the world to each
agent, and ideally it should not even expose resources that are not
needed at all to an agent...and by that I mean that the server SHOULD
not enumerate that resources when queried, by dropping them from the
list of resources that return to that agent WHILE maintaining the set of
IDs contigous...
...the SCMI server provides an illusion ideally where the agent is in
control and can access whatever it wants, while the reality is that the
agent can only issue commands that are deemed safe and sensible by the server,
which is the ultimate arbiter on the system, to the extent that can hide
resources or simply silently ignore requests...
> What if a mistake was made, and a clock was exposed to an agent by
> accident?
Quirk !
More detail on all of this in my babbling on the other thread...sorry
for the flood of words :P
Thanks,
Cristian
^ permalink raw reply
* Re: (subset) [PATCH 0/3] Mediatek Genio 1200-EVK: MT6315/MT6360 PMIC regulator supply cleanup
From: Mark Brown @ 2026-04-26 22:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Liam Girdwood, Gene Chen,
Louis-Alexis Eyraud
Cc: kernel, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260414-mtk-g1200-pmic-cleanup-v1-0-2a7193ed4e93@collabora.com>
On Tue, 14 Apr 2026 13:44:09 +0200, Louis-Alexis Eyraud wrote:
> Mediatek Genio 1200-EVK: MT6315/MT6360 PMIC regulator supply cleanup
>
> This series goal is to cleanup the power supplies of MT6315 and MT6360
> PMIC regulators, that are either missing or incorrect in the Mediatek
> Genio 1200-EVK board devicetree.
>
> Patch 1 completes the MT6360 dt-bindings by adding the missing power
> supply descriptions for its buck regulators, that already handled by
> the mt6360 regulator driver.
> Patch 2 adds for the board the MT6315 regulator supply properties, that
> were added in the dt-bindings by [1].
> Patch 3 adds for the board the MT6360 regulator supply properties and
> fixes the existing one.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-7.2
Thanks!
[1/3] regulator: dt-bindings: mt6360: add buck regulator supplies
https://git.kernel.org/broonie/regulator/c/a8fccc792f42
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] ASoC: mchp-spdifrx: Replace manual bitfield manipulations with macros and typo correction
From: Mark Brown @ 2026-04-26 21:51 UTC (permalink / raw)
To: claudiu.beznea, andrei.simion, lgirdwood, perex, tiwai,
nicolas.ferre, alexandre.belloni, Joao Marinho joao.bcc@usp.br
Cc: Micael Vinicius, linux-sound, linux-arm-kernel
In-Reply-To: <20260420203218.15060-1-joao.bcc@usp.br>
On Mon, 20 Apr 2026 17:32:03 -0300, Joao Marinho joao.bcc@usp.br wrote:
> ASoC: mchp-spdifrx: Replace manual bitfield manipulations with macros and typo correction
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[1/1] ASoC: mchp-spdifrx: Replace manual bitfield manipulations with macros and typo correction
https://git.kernel.org/broonie/asoc/c/0241d6192a11
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] Change manual bitfield manipulation to use FIELD_PREP()
From: Mark Brown @ 2026-04-26 21:53 UTC (permalink / raw)
To: claudiu.beznea, andrei.simion, lgirdwood, perex, tiwai,
nicolas.ferre, alexandre.belloni, Gabriel Jacob Perin
Cc: carlos.albmr, linux-sound, linux-arm-kernel
In-Reply-To: <20260421193113.1060213-1-gabrieljp@usp.br>
On Tue, 21 Apr 2026 16:31:13 -0300, Gabriel Jacob Perin wrote:
> Change manual bitfield manipulation to use FIELD_PREP()
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[1/1] Change manual bitfield manipulation to use FIELD_PREP()
https://git.kernel.org/broonie/sound/c/ae93afff9818
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: (subset) [PATCH 0/3] spi: rockchip: ISR fix and minor cleanups
From: Mark Brown @ 2026-04-26 21:57 UTC (permalink / raw)
To: heiko, John Madieu
Cc: jon.lin, linux-spi, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260425092936.2590132-1-john.madieu@gmail.com>
On Sat, 25 Apr 2026 09:29:33 +0000, John Madieu wrote:
> spi: rockchip: ISR fix and minor cleanups
>
> Hi all,
>
> This series fixes one real bug in the Rockchip SPI driver and tidies up
> two unrelated cosmetic issues spotted while looking at the same area.
> The patches are independent and could be applied in any order; they are
> ordered here by decreasing severity.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.1
Thanks!
[1/3] spi: rockchip: Read ISR, not IMR, to detect cs-inactive IRQ
https://git.kernel.org/broonie/spi/c/b4683a239a40
[2/3] spi: rockchip: Drop unused and broken CR0 macros
https://git.kernel.org/broonie/spi/c/7643978722aa
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* [PATCH] Documentation: ABI: sysfs-class-reboot-mode-reboot_modes: fix doc warnings
From: Randy Dunlap @ 2026-04-26 23:27 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, linux-pm, linux-arm-kernel, Bartosz Golaszewski,
Sebastian Reichel, Shivendra Pratap, linux-doc
Repair the docs build warnings in this file by unindenting the description,
adding blank lines, and using `` to quote *arg.
WARNING: Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:36: abi_sys_class_reboot_mode_driver_reboot_modes doesn't have a description
Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils]
Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils]
Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: WARNING: Inline emphasis start-string without end-string. [docutils]
Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils]
Fixes: d3da03025e6d ("Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: linux-pm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Bartosz Golaszewski <brgl@kernel.org>
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
Cc: linux-doc@vger.kernel.org
Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes | 13 ++++++----
1 file changed, 8 insertions(+), 5 deletions(-)
--- linux-next-20260424.orig/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
+++ linux-next-20260424/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
@@ -2,33 +2,36 @@ What: /sys/class/reboot-mode/<driver>/r
Date: March 2026(TBD)
KernelVersion: TBD
Contact: linux-pm@vger.kernel.org
- Description:
+Description:
This interface exposes the reboot-mode arguments
registered with the reboot-mode framework. It is
a read-only interface and provides a space
separated list of reboot-mode arguments supported
on the current platform.
Example:
+
recovery fastboot bootloader
The exact sysfs path may vary depending on the
name of the driver that registers the arguments.
- Example:
+ Example::
+
/sys/class/reboot-mode/nvmem-reboot-mode/reboot_modes
/sys/class/reboot-mode/syscon-reboot-mode/reboot_modes
/sys/class/reboot-mode/qcom-pon/reboot_modes
The supported arguments can be used by userspace to
invoke device reset using the standard reboot() system
- call interface, with the "argument" as string to "*arg"
- parameter along with LINUX_REBOOT_CMD_RESTART2.
+ call interface, with the "argument" as string to ``*arg``
+ parameter along with ``LINUX_REBOOT_CMD_RESTART2``.
A driver can expose the supported arguments by
registering them with the reboot-mode framework
using the property names that follow the
mode-<argument> format.
Example:
- mode-bootloader, mode-recovery.
+
+ mode-bootloader, mode-recovery
This attribute is useful for scripts or initramfs
logic that need to programmatically determine
^ permalink raw reply
* New Order- REQUEST FOR QUOTATION-URGENT
From: Andriana Agathocleous @ 2026-04-24 8:52 UTC (permalink / raw)
To: linux-arm-kernel
Dear Sir/Madam,
Good day.
I am Andriana Agathocleous , Due to our recent project, we want
to make inquiries about your products and we wish to establish a
potential business cooperation with your Company. I will send
requirements for your perusal and quote upon receiving your
feedback.
Please kindly send your current catalogue, price list, payment
terms.
Kindly acknowledge this communication and send me feedback upon
receipt so we can place the order without any further delays.
Best Regards,
Andriana Agathocleous
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: dt-bindings: drop redundant wakeup-source definitions
From: Bui Duc Phuc @ 2026-04-26 23:40 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Mark Brown, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Joseph Chen,
Chris Zhong, Zhang Qing, David Rau, Animesh Agarwal, devicetree,
linux-sound, linux-rockchip, linux-arm-kernel, linux-kernel
In-Reply-To: <20260423-ingenious-psychedelic-jaybird-40bb4d@quoll>
Hi,
> > The 'wakeup-source' property already has its type defined in the core
> TYPES. It is plural.
Thank you for pointing that out. That was a mistake in my wording.
Regarding the two data types, I’m already aware of this and have
discussed it in a previous patch.
https://lore.kernel.org/all/CAABR9nH3hr+Y5ksD0cn3Gd9XUvmb07X7zJw0b4k_yVbnAuz9=w@mail.gmail.com/
> > - wakeup-source:
> > - type: boolean
> > - description:
> > - Flag to indicate this device can wake system (suspend/resume).
> > + wakeup-source: true
>
> That's wrong. Commit msg is making here false statements that it is
> redundant. I checked (and you should too!) and driver does clearly
> device_property_read_bool() thus the property CANNOT be the second type.
I think Device Tree bindings should describe the hardware capability.
If the hardware supports wakeup functionality,
referencing the core schema is sufficient. Hardware description should
not be constrained by the current driver implementation
( e.g. the use of device_property_read_bool() ).
Bindings should remain stable and generic, while drivers can evolve over time.
Re-defining the type locally duplicates the core definition. If the
core schema evolves,
this approach would require touching many bindings instead of updating
one central place.
This follows the recent cleanups suggested by Rob
https://lore.kernel.org/all/177628888260.592110.11727813820499601669.robh@kernel.org/
https://lore.kernel.org/all/177679687272.1458365.1328485324673928433.robh@kernel.org/
Best regards,
Phuc
^ permalink raw reply
* Re: [PATCH 1/1] Revert "scsi: ufs: Use pre-calculated offsets in ufshcd_init_lrb()"
From: Ed Tsai (蔡宗軒) @ 2026-04-26 23:41 UTC (permalink / raw)
To: avri.altman@sandisk.com, matthias.bgg@gmail.com,
AngeloGioacchino Del Regno, bvanassche@acm.org,
alim.akhtar@samsung.com, martin.petersen@oracle.com,
James.Bottomley@HansenPartnership.com
Cc: Alice Chao (趙珮均), linux-scsi@vger.kernel.org,
wsd_upstream, linux-kernel@vger.kernel.org,
Chun-Hung Wu (巫駿宏),
linux-arm-kernel@lists.infradead.org,
Naomi Chu (朱詠田),
linux-mediatek@lists.infradead.org,
Peter Wang (王信友)
In-Reply-To: <a496a84b-66c8-452e-99b6-622550afeae5@acm.org>
On Fri, 2026-04-24 at 15:55 -0700, Bart Van Assche wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> On 4/23/26 11:35 PM, ed.tsai@mediatek.com wrote:
> > Note that these DMA addresses are only used in ufshcd_print_tr()
> > for
> > error logging, so the impact is limited to misleading error logs.
>
> Instead of fixing these offsets, please remove the ucd_rsp_dma_addr
> and
> ucd_prdt_dma_addr members from struct ufshcd_lrb.
>
> Thanks,
>
> Bart.
Sounds good, I will send a new patch. Thanks.
^ permalink raw reply
* Re: [PATCH] dt-bindings: Remove the redundant 'type: boolean'
From: Bui Duc Phuc @ 2026-04-27 0:19 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh, krzk+dt, conor+dt, nick, dmitry.torokhov, nicolas.ferre,
alexandre.belloni, claudiu.beznea, lee, heiko, gregkh, linusw,
zyw, zhangqing, gene_chen, linux-input, devicetree,
linux-arm-kernel, linux-usb
In-Reply-To: <a145db93-a8ad-4bee-8404-21f356d7d4ab@kernel.org>
Hi Krzysztof,
> Why did you change one file and ignore the rest?
I'm processing the remaining files with caution. Files without
significant descriptions or context will be updated in the upcoming
patches.
Those with specific descriptions require deeper review and will be
handled in separate patch series later.
> Why did you not mention previous feedback I gave you on your patches
> (some time ago), that there are TWO TYPES defined for wakeup-source.
Thanks for mentioning this.
In v2 of the patch, I reviewed the previous discussion between you and
Connor regarding the two types for wakeup-source.
https://lore.kernel.org/all/20260316034606.11304-1-phucduc.bui@gmail.com/
When moving to v3, I followed Rob’s suggestion to use true. I also
sent a follow-up email to confirm this approach,
and since I did not receive further comments, I assumed this direction
was acceptable.
https://lore.kernel.org/all/CAABR9nH3hr+Y5ksD0cn3Gd9XUvmb07X7zJw0b4k_yVbnAuz9=w@mail.gmail.com/
Best Regards,
Phuc
^ permalink raw reply
* [PATCH] soc: imx8m: Fix match data lookup for soc device
From: Peng Fan (OSS) @ 2026-04-27 1:01 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Greg Kroah-Hartman, Rob Herring (Arm), Bartosz Golaszewski
Cc: imx, linux-arm-kernel, linux-kernel, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
The i.MX8M soc device is registered via platform_device_register_simple(),
so it is not associated with a Device Tree node and the imx8m_soc_driver
has no of_match_table.
As a result, device_get_match_data() always returns NULL when probing
the soc device.
Retrieve the match data directly from the machine compatible using
of_machine_get_match_data(imx8_soc_match), which provides the correct SoC
data.
Fixes: 2524b293a59e5 ("soc: imx8m: don't access of_root directly")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/soc/imx/soc-imx8m.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/imx/soc-imx8m.c b/drivers/soc/imx/soc-imx8m.c
index 77763a107edbd11302017e3f61ecb4369fda1ab0..fc080e56f50d423b88a673181a6bc986eb4c1691 100644
--- a/drivers/soc/imx/soc-imx8m.c
+++ b/drivers/soc/imx/soc-imx8m.c
@@ -247,7 +247,7 @@ static int imx8m_soc_probe(struct platform_device *pdev)
if (ret)
return ret;
- data = device_get_match_data(dev);
+ data = of_machine_get_match_data(imx8_soc_match);
if (data) {
soc_dev_attr->soc_id = data->name;
ret = imx8m_soc_prepare(pdev, data->ocotp_compatible);
---
base-commit: 70c8a7ec6715b5fb14e501731b5b9210a16684f7
change-id: 20260424-soc-imx8m-fix-90d7ce2397f5
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ permalink raw reply related
* Re: [PATCH v2 3/4] ARM: dts: renesas: r8a7740: Add ZT/ZTR trace clock on R-Mobile A1
From: Marek Vasut @ 2026-04-27 0:32 UTC (permalink / raw)
To: Krzysztof Kozlowski, Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <d246edd2-5f9d-4e95-850d-abff175088a6@kernel.org>
On 4/23/26 4:00 PM, Krzysztof Kozlowski wrote:
Hello Krzysztof,
>>>> "
>>>> WARNING: DT binding docs and includes should be a separate patch. See:
>>>> Documentation/devicetree/bindings/submitting-patches.rst
>>>
>>> So you did not implement it... Include goes with the binding. Always.
>>> Look at other commits.
>> The warning says the exact opposite thing , does it not ?
>>
>> Maybe the warning text needs to be updated ?
>
> The warning is shown for patches mixing stuff, like DTSI+header, so for
> this context the AND means binding doc plus header are separate FROM
> this patch. Not separate from each other.
Oh, thank you for the clarification.
> To me it is clear, so I don't feel like finding different text. If you
> find it unclear or confusing, you should propose something better.
How about this:
"
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 0d18771f1b013..715a98ccc69f7 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2957,7 +2957,7 @@ sub process {
if (($last_binding_patch != -1) &&
($last_binding_patch ^
$is_binding_patch)) {
WARN("DT_SPLIT_BINDING_PATCH",
- "DT binding docs and
includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.rst\n");
+ "DT binding docs and
includes should be a single patch, but separate from this patch. See:
Documentation/devicetree/bindings/submitting-patches.rst\n");
}
}
"
^ permalink raw reply related
* Re: [PATCH v5 3/6] pwm: Add rockchip PWMv4 driver
From: Damon Ding @ 2026-04-27 1:20 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Nicolas Frattaroli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Lee Jones, William Breathitt Gray,
kernel, Jonas Karlman, Alexey Charkov, linux-rockchip, linux-pwm,
devicetree, linux-arm-kernel, linux-kernel, linux-iio
In-Reply-To: <ae4MCRE_hGJ-VcBQ@monoceros>
Hi Uwe,
On 4/26/2026 9:06 PM, Uwe Kleine-König wrote:
> Hello,
>
> first of all thanks for your extensive testing, very appreciated.
>
> On Sun, Apr 26, 2026 at 05:44:46PM +0800, Damon Ding wrote:
>> On 4/20/2026 9:52 PM, Nicolas Frattaroli wrote:
>>> The Rockchip RK3576 brings with it a new PWM IP, in downstream code
>>> referred to as "v4". This new IP is different enough from the previous
>>> Rockchip IP that I felt it necessary to add a new driver for it, instead
>>> of shoehorning it in the old one.
>>>
>>> Add this new driver, based on the PWM core's waveform APIs. Its platform
>>> device is registered by the parent mfpwm driver, from which it also
>>> receives a little platform data struct, so that mfpwm can guarantee that
>>> all the platform device drivers spread across different subsystems for
>>> this specific hardware IP do not interfere with each other.
>>>
>>> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>> Tested-by: Damon Ding <damon.ding@rock-chips.com>
>>
>> The continuous mode of all PWM channels has been preliminarily tested
>> and verified working on the RK3576 IoT board.
>>
>> I have tested with several typical period and duty cycle configurations.
>>
>> Following Uwe's suggestion [0], I also tested with libpwm using commands
>> similar to the following:
>>
>> ./pwmset -c 0 -p 0 -P 1000000 -D 500000 -s 5000
>
> This one is good if you have an oscilloscope (or something similar) to
> verify the output. Without that (or additionally) pwmtestperf creates a
> series of requests that in combination with PWM_DEBUG should uncover
> rounding errors in the .tohw and .fromhw callbacks.
Aha, this is my oversight. I did not elaborate on my verification
methods. ;-)
I have adopted three ways to complete the test:
1. Measure the output waveform of each channel with a simple logic
analyzer, Kinst LA2016.
2. Read relevant registers to verify that the configured period and duty
values match expectations.
3. Connect the PWM continuous output pins to capture input pins
directly, to confirm the capture measurement results.
>
> A good set of calls then is:
>
> pwmtestperf -p ... -c ... -P 50000 -S1
> pwmtestperf -p ... -c ... -P 50000 -S1 -I
>
> pwmtestperf -p ... -c ... -P 50000 -S-1
> pwmtestperf -p ... -c ... -P 50000 -S-1 -I
>
> (Assuming that 50000 is a sensible period for the device under test.)
>
Okay, I will look into this tool and run these commands to conduct more
in-depth verification.
> And yes, I know, I need to document that using something more permanent
> than a mailing list post.
>
Best regards,
Damon
^ permalink raw reply
* Re: [PATCH v8 1/4] coresight: cti: Convert trigger usage fields to dynamic bitmaps and arrays
From: Jie Gan @ 2026-04-27 1:48 UTC (permalink / raw)
To: Yingchao Deng, Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin
Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
quic_yingdeng, Jinlong Mao, Tingwei Zhang
In-Reply-To: <20260426-extended-cti-v8-1-23b900a4902f@oss.qualcomm.com>
On 4/26/2026 5:44 PM, Yingchao Deng wrote:
> Replace the fixed-size u32 fields in the cti_config and cti_trig_grp
> structure with dynamically allocated bitmaps and arrays. This allows
> memory to be allocated based on the actual number of triggers during probe
> time, reducing memory footprint and improving scalability for platforms
> with varying trigger counts.
>
> Signed-off-by: Yingchao Deng <yingchao.deng@oss.qualcomm.com>
> ---
> drivers/hwtracing/coresight/coresight-cti-core.c | 59 +++++++++++++++++-----
> .../hwtracing/coresight/coresight-cti-platform.c | 26 +++++++---
> drivers/hwtracing/coresight/coresight-cti-sysfs.c | 14 ++---
> drivers/hwtracing/coresight/coresight-cti.h | 12 ++---
> 4 files changed, 76 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c
> index 2f4c9362709a..4e7d12bd2d3e 100644
> --- a/drivers/hwtracing/coresight/coresight-cti-core.c
> +++ b/drivers/hwtracing/coresight/coresight-cti-core.c
> @@ -161,8 +161,8 @@ void cti_write_intack(struct device *dev, u32 ackval)
> /* DEVID[19:16] - number of CTM channels */
> #define CTI_DEVID_CTMCHANNELS(devid_val) ((int) BMVAL(devid_val, 16, 19))
>
> -static void cti_set_default_config(struct device *dev,
> - struct cti_drvdata *drvdata)
> +static int cti_set_default_config(struct device *dev,
> + struct cti_drvdata *drvdata)
> {
> struct cti_config *config = &drvdata->config;
> u32 devid;
> @@ -181,6 +181,26 @@ static void cti_set_default_config(struct device *dev,
> config->nr_trig_max = CTIINOUTEN_MAX;
> }
>
> + config->trig_in_use = devm_bitmap_zalloc(dev, config->nr_trig_max, GFP_KERNEL);
> + if (!config->trig_in_use)
> + return -ENOMEM;
> +
> + config->trig_out_use = devm_bitmap_zalloc(dev, config->nr_trig_max, GFP_KERNEL);
> + if (!config->trig_out_use)
> + return -ENOMEM;
> +
> + config->trig_out_filter = devm_bitmap_zalloc(dev, config->nr_trig_max, GFP_KERNEL);
> + if (!config->trig_out_filter)
> + return -ENOMEM;
> +
> + config->ctiinen = devm_kcalloc(dev, config->nr_trig_max, sizeof(u32), GFP_KERNEL);
> + if (!config->ctiinen)
> + return -ENOMEM;
> +
> + config->ctiouten = devm_kcalloc(dev, config->nr_trig_max, sizeof(u32), GFP_KERNEL);
> + if (!config->ctiouten)
> + return -ENOMEM;
> +
> config->nr_ctm_channels = CTI_DEVID_CTMCHANNELS(devid);
>
> /* Most regs default to 0 as zalloc'ed except...*/
> @@ -189,6 +209,7 @@ static void cti_set_default_config(struct device *dev,
> config->enable_req_count = 0;
>
> config->asicctl_impl = !!FIELD_GET(GENMASK(4, 0), devid);
> + return 0;
> }
>
> /*
> @@ -219,8 +240,10 @@ int cti_add_connection_entry(struct device *dev, struct cti_drvdata *drvdata,
> cti_dev->nr_trig_con++;
>
> /* add connection usage bit info to overall info */
> - drvdata->config.trig_in_use |= tc->con_in->used_mask;
> - drvdata->config.trig_out_use |= tc->con_out->used_mask;
> + bitmap_or(drvdata->config.trig_in_use, drvdata->config.trig_in_use,
> + tc->con_in->used_mask, drvdata->config.nr_trig_max);
> + bitmap_or(drvdata->config.trig_out_use, drvdata->config.trig_out_use,
> + tc->con_out->used_mask, drvdata->config.nr_trig_max);
>
> return 0;
> }
> @@ -231,6 +254,8 @@ struct cti_trig_con *cti_allocate_trig_con(struct device *dev, int in_sigs,
> {
> struct cti_trig_con *tc = NULL;
> struct cti_trig_grp *in = NULL, *out = NULL;
> + struct cti_drvdata *drvdata = dev_get_drvdata(dev);
> + int n_trigs = drvdata->config.nr_trig_max;
>
> tc = devm_kzalloc(dev, sizeof(struct cti_trig_con), GFP_KERNEL);
> if (!tc)
> @@ -242,12 +267,20 @@ struct cti_trig_con *cti_allocate_trig_con(struct device *dev, int in_sigs,
> if (!in)
> return NULL;
>
> + in->used_mask = devm_bitmap_zalloc(dev, n_trigs, GFP_KERNEL);
> + if (!in->used_mask)
> + return NULL;
> +
> out = devm_kzalloc(dev,
> offsetof(struct cti_trig_grp, sig_types[out_sigs]),
> GFP_KERNEL);
> if (!out)
> return NULL;
>
> + out->used_mask = devm_bitmap_zalloc(dev, n_trigs, GFP_KERNEL);
> + if (!out->used_mask)
> + return NULL;
> +
> tc->con_in = in;
> tc->con_out = out;
> tc->con_in->nr_sigs = in_sigs;
> @@ -263,7 +296,6 @@ int cti_add_default_connection(struct device *dev, struct cti_drvdata *drvdata)
> {
> int ret = 0;
> int n_trigs = drvdata->config.nr_trig_max;
> - u32 n_trig_mask = GENMASK(n_trigs - 1, 0);
> struct cti_trig_con *tc = NULL;
>
> /*
> @@ -274,8 +306,8 @@ int cti_add_default_connection(struct device *dev, struct cti_drvdata *drvdata)
> if (!tc)
> return -ENOMEM;
>
> - tc->con_in->used_mask = n_trig_mask;
> - tc->con_out->used_mask = n_trig_mask;
> + bitmap_fill(tc->con_in->used_mask, n_trigs);
> + bitmap_fill(tc->con_out->used_mask, n_trigs);
> ret = cti_add_connection_entry(dev, drvdata, tc, NULL, "default");
> return ret;
> }
> @@ -288,7 +320,6 @@ int cti_channel_trig_op(struct device *dev, enum cti_chan_op op,
> {
> struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct cti_config *config = &drvdata->config;
> - u32 trig_bitmask;
> u32 chan_bitmask;
> u32 reg_value;
> int reg_offset;
> @@ -298,18 +329,16 @@ int cti_channel_trig_op(struct device *dev, enum cti_chan_op op,
> (trigger_idx >= config->nr_trig_max))
> return -EINVAL;
>
> - trig_bitmask = BIT(trigger_idx);
> -
> /* ensure registered triggers and not out filtered */
> if (direction == CTI_TRIG_IN) {
> - if (!(trig_bitmask & config->trig_in_use))
> + if (!(test_bit(trigger_idx, config->trig_in_use)))
> return -EINVAL;
> } else {
> - if (!(trig_bitmask & config->trig_out_use))
> + if (!(test_bit(trigger_idx, config->trig_out_use)))
> return -EINVAL;
>
> if ((config->trig_filter_enable) &&
> - (config->trig_out_filter & trig_bitmask))
> + test_bit(trigger_idx, config->trig_out_filter))
> return -EINVAL;
> }
>
> @@ -687,7 +716,9 @@ static int cti_probe(struct amba_device *adev, const struct amba_id *id)
> raw_spin_lock_init(&drvdata->spinlock);
>
> /* initialise CTI driver config values */
> - cti_set_default_config(dev, drvdata);
> + ret = cti_set_default_config(dev, drvdata);
> + if (ret)
> + return ret;
>
> pdata = coresight_cti_get_platform_data(dev);
> if (IS_ERR(pdata)) {
> diff --git a/drivers/hwtracing/coresight/coresight-cti-platform.c b/drivers/hwtracing/coresight/coresight-cti-platform.c
> index 4eff96f48594..557debbc8ca4 100644
> --- a/drivers/hwtracing/coresight/coresight-cti-platform.c
> +++ b/drivers/hwtracing/coresight/coresight-cti-platform.c
> @@ -136,8 +136,8 @@ static int cti_plat_create_v8_etm_connection(struct device *dev,
> goto create_v8_etm_out;
>
> /* build connection data */
> - tc->con_in->used_mask = 0xF0; /* sigs <4,5,6,7> */
> - tc->con_out->used_mask = 0xF0; /* sigs <4,5,6,7> */
> + bitmap_set(tc->con_in->used_mask, 4, 4); /* sigs <4,5,6,7> */
> + bitmap_set(tc->con_out->used_mask, 4, 4); /* sigs <4,5,6,7> */
>
> /*
> * The EXTOUT type signals from the ETM are connected to a set of input
> @@ -194,10 +194,10 @@ static int cti_plat_create_v8_connections(struct device *dev,
> goto of_create_v8_out;
>
> /* Set the v8 PE CTI connection data */
> - tc->con_in->used_mask = 0x3; /* sigs <0 1> */
> + bitmap_set(tc->con_in->used_mask, 0, 2); /* sigs <0 1> */
> tc->con_in->sig_types[0] = PE_DBGTRIGGER;
> tc->con_in->sig_types[1] = PE_PMUIRQ;
> - tc->con_out->used_mask = 0x7; /* sigs <0 1 2 > */
> + bitmap_set(tc->con_out->used_mask, 0, 3); /* sigs <0 1 2 > */
> tc->con_out->sig_types[0] = PE_EDBGREQ;
> tc->con_out->sig_types[1] = PE_DBGRESTART;
> tc->con_out->sig_types[2] = PE_CTIIRQ;
> @@ -213,7 +213,7 @@ static int cti_plat_create_v8_connections(struct device *dev,
> goto of_create_v8_out;
>
> /* filter pe_edbgreq - PE trigout sig <0> */
> - drvdata->config.trig_out_filter |= 0x1;
> + set_bit(0, drvdata->config.trig_out_filter);
>
> of_create_v8_out:
> return ret;
> @@ -257,7 +257,7 @@ static int cti_plat_read_trig_group(struct cti_trig_grp *tgrp,
> if (!err) {
> /* set the signal usage mask */
> for (idx = 0; idx < tgrp->nr_sigs; idx++)
> - tgrp->used_mask |= BIT(values[idx]);
> + set_bit(values[idx], tgrp->used_mask);
> }
>
> kfree(values);
> @@ -316,23 +316,33 @@ static int cti_plat_process_filter_sigs(struct cti_drvdata *drvdata,
> {
> struct cti_trig_grp *tg = NULL;
> int err = 0, nr_filter_sigs;
> + int nr_trigs = drvdata->config.nr_trig_max;
>
> nr_filter_sigs = cti_plat_count_sig_elements(fwnode,
> CTI_DT_FILTER_OUT_SIGS);
> if (nr_filter_sigs == 0)
> return 0;
>
> - if (nr_filter_sigs > drvdata->config.nr_trig_max)
> + if (nr_filter_sigs > nr_trigs)
> return -EINVAL;
>
> tg = kzalloc_obj(*tg);
> if (!tg)
> return -ENOMEM;
>
> + tg->used_mask = bitmap_zalloc(nr_trigs, GFP_KERNEL);
> + if (!tg->used_mask) {
> + kfree(tg);
> + return -ENOMEM;
> + }
> +
> err = cti_plat_read_trig_group(tg, fwnode, CTI_DT_FILTER_OUT_SIGS);
> if (!err)
> - drvdata->config.trig_out_filter |= tg->used_mask;
> + bitmap_or(drvdata->config.trig_out_filter,
> + drvdata->config.trig_out_filter,
> + tg->used_mask, nr_trigs);
The error may be silently ignored when a memory allocation error
occured. I think it's better to add a log print to tell user what happened.
Thanks,
Jie
>
> + bitmap_free(tg->used_mask);
> kfree(tg);
> return err;
> }
> diff --git a/drivers/hwtracing/coresight/coresight-cti-sysfs.c b/drivers/hwtracing/coresight/coresight-cti-sysfs.c
> index 3fe2c916d228..2bbfa405cb6b 100644
> --- a/drivers/hwtracing/coresight/coresight-cti-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-cti-sysfs.c
> @@ -719,12 +719,12 @@ static ssize_t trigout_filtered_show(struct device *dev,
> struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct cti_config *cfg = &drvdata->config;
> int nr_trig_max = cfg->nr_trig_max;
> - unsigned long mask = cfg->trig_out_filter;
> + unsigned long *mask = cfg->trig_out_filter;
>
> - if (mask == 0)
> + if (bitmap_empty(mask, nr_trig_max))
> return 0;
>
> - return sysfs_emit(buf, "%*pbl\n", nr_trig_max, &mask);
> + return sysfs_emit(buf, "%*pbl\n", nr_trig_max, mask);
> }
> static DEVICE_ATTR_RO(trigout_filtered);
>
> @@ -931,9 +931,9 @@ static ssize_t trigin_sig_show(struct device *dev,
> struct cti_trig_con *con = (struct cti_trig_con *)ext_attr->var;
> struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct cti_config *cfg = &drvdata->config;
> - unsigned long mask = con->con_in->used_mask;
> + unsigned long *mask = con->con_in->used_mask;
>
> - return sysfs_emit(buf, "%*pbl\n", cfg->nr_trig_max, &mask);
> + return sysfs_emit(buf, "%*pbl\n", cfg->nr_trig_max, mask);
> }
>
> static ssize_t trigout_sig_show(struct device *dev,
> @@ -945,9 +945,9 @@ static ssize_t trigout_sig_show(struct device *dev,
> struct cti_trig_con *con = (struct cti_trig_con *)ext_attr->var;
> struct cti_drvdata *drvdata = dev_get_drvdata(dev->parent);
> struct cti_config *cfg = &drvdata->config;
> - unsigned long mask = con->con_out->used_mask;
> + unsigned long *mask = con->con_out->used_mask;
>
> - return sysfs_emit(buf, "%*pbl\n", cfg->nr_trig_max, &mask);
> + return sysfs_emit(buf, "%*pbl\n", cfg->nr_trig_max, mask);
> }
>
> /* convert a sig type id to a name */
> diff --git a/drivers/hwtracing/coresight/coresight-cti.h b/drivers/hwtracing/coresight/coresight-cti.h
> index c5f9e79fabc6..ef079fc18b72 100644
> --- a/drivers/hwtracing/coresight/coresight-cti.h
> +++ b/drivers/hwtracing/coresight/coresight-cti.h
> @@ -68,7 +68,7 @@ struct fwnode_handle;
> */
> struct cti_trig_grp {
> int nr_sigs;
> - u32 used_mask;
> + unsigned long *used_mask;
> int sig_types[];
> };
>
> @@ -145,17 +145,17 @@ struct cti_config {
> int enable_req_count;
>
> /* registered triggers and filtering */
> - u32 trig_in_use;
> - u32 trig_out_use;
> - u32 trig_out_filter;
> + unsigned long *trig_in_use;
> + unsigned long *trig_out_use;
> + unsigned long *trig_out_filter;
> bool trig_filter_enable;
> u8 xtrig_rchan_sel;
>
> /* cti cross trig programmable regs */
> u32 ctiappset;
> u8 ctiinout_sel;
> - u32 ctiinen[CTIINOUTEN_MAX];
> - u32 ctiouten[CTIINOUTEN_MAX];
> + u32 *ctiinen;
> + u32 *ctiouten;
> u32 ctigate;
> u32 asicctl;
> };
>
^ permalink raw reply
* [PATCH] pinctrl: mediatek: paris: Directly modify registers to set GPIO direction
From: Chen-Yu Tsai @ 2026-04-27 2:10 UTC (permalink / raw)
To: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Linus Walleij
Cc: Chen-Yu Tsai, linux-mediatek, linux-gpio, linux-arm-kernel,
linux-kernel
pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take
the pinctrl mutex. This causes a gpiochip operations to need to sleep.
Worse yet, the .can_sleep field in the gpiochip is not set. This causes
the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check
whether it can use a spinlock or needs a mutex. In this case, it ends
up taking a spinlock, then calls pinctrl_gpio_direction_output(), which
takes a mutex. This causes a huge warning.
While this class of Mediatek hardware does not have separate clear/set
registers, the pinctrl context has a spinlock that is taken whenever
a register read-modify-write is done.
Switch to directly setting the GPIO direction register bits to avoid
the mutex.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/pinctrl/mediatek/pinctrl-paris.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c b/drivers/pinctrl/mediatek/pinctrl-paris.c
index 6bf37d8085fa..e4c0bc27d984 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -886,19 +886,24 @@ static int mtk_gpio_set(struct gpio_chip *chip, unsigned int gpio, int value)
static int mtk_gpio_direction_input(struct gpio_chip *chip, unsigned int gpio)
{
- return pinctrl_gpio_direction_input(chip, gpio);
+ struct mtk_pinctrl *hw = gpiochip_get_data(chip);
+ const struct mtk_pin_desc *desc = &hw->soc->pins[gpio];
+
+ return mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DIR, 0);
}
static int mtk_gpio_direction_output(struct gpio_chip *chip, unsigned int gpio,
int value)
{
+ struct mtk_pinctrl *hw = gpiochip_get_data(chip);
+ const struct mtk_pin_desc *desc = &hw->soc->pins[gpio];
int ret;
ret = mtk_gpio_set(chip, gpio, value);
if (ret)
return ret;
- return pinctrl_gpio_direction_output(chip, gpio);
+ return mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DIR, 1);
}
static int mtk_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
--
2.54.0.rc2.544.gc7ae2d5bb8-goog
^ permalink raw reply related
* [PATCH] pinctrl: mediatek: eint: Drop base from mtk_eint_chip_write_mask()
From: Chen-Yu Tsai @ 2026-04-27 2:11 UTC (permalink / raw)
To: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Linus Walleij
Cc: Chen-Yu Tsai, linux-mediatek, linux-gpio, linux-arm-kernel,
linux-kernel, Hao Chang, Qingliang Li
When support for multiple EINT base addresses was added in commit
3ef9f710efcb ("pinctrl: mediatek: Add EINT support for multiple
addresses"), mtk_eint_chip_write_mask() was changed to write interrupt
masks for all base addresses in one call. However the "base" parameter
was left around and now causes sparse warnings:
mtk-eint.c:428:44: warning: incorrect type in argument 2 (different address spaces)
mtk-eint.c:428:44: expected void [noderef] __iomem *base
mtk-eint.c:428:44: got void [noderef] __iomem **base
mtk-eint.c:436:44: warning: incorrect type in argument 2 (different address spaces)
mtk-eint.c:436:44: expected void [noderef] __iomem *base
mtk-eint.c:436:44: got void [noderef] __iomem **base
Since the "base" parameter is no longer needed, just drop it.
Fixes: 3ef9f710efcb ("pinctrl: mediatek: Add EINT support for multiple addresses")
Cc: Hao Chang <ot_chhao.chang@mediatek.com>
Cc: Qingliang Li <qingliang.li@mediatek.com>
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Only compile tested.
---
drivers/pinctrl/mediatek/mtk-eint.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/mediatek/mtk-eint.c b/drivers/pinctrl/mediatek/mtk-eint.c
index 2a3c04eedc5f..47ac92ea98c2 100644
--- a/drivers/pinctrl/mediatek/mtk-eint.c
+++ b/drivers/pinctrl/mediatek/mtk-eint.c
@@ -246,7 +246,7 @@ static int mtk_eint_irq_set_wake(struct irq_data *d, unsigned int on)
}
static void mtk_eint_chip_write_mask(const struct mtk_eint *eint,
- void __iomem *base, unsigned int **buf)
+ unsigned int **buf)
{
int inst, port, port_num;
void __iomem *reg;
@@ -425,7 +425,7 @@ static void mtk_eint_irq_handler(struct irq_desc *desc)
int mtk_eint_do_suspend(struct mtk_eint *eint)
{
- mtk_eint_chip_write_mask(eint, eint->base, eint->wake_mask);
+ mtk_eint_chip_write_mask(eint, eint->wake_mask);
return 0;
}
@@ -433,7 +433,7 @@ EXPORT_SYMBOL_GPL(mtk_eint_do_suspend);
int mtk_eint_do_resume(struct mtk_eint *eint)
{
- mtk_eint_chip_write_mask(eint, eint->base, eint->cur_mask);
+ mtk_eint_chip_write_mask(eint, eint->cur_mask);
return 0;
}
--
2.54.0.rc2.544.gc7ae2d5bb8-goog
^ permalink raw reply related
* Re: [PATCH v8 2/4] coresight: cti: encode trigger register index in register offsets
From: Jie Gan @ 2026-04-27 2:22 UTC (permalink / raw)
To: Yingchao Deng, Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin
Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
quic_yingdeng, Jinlong Mao, Tingwei Zhang
In-Reply-To: <20260426-extended-cti-v8-2-23b900a4902f@oss.qualcomm.com>
On 4/26/2026 5:44 PM, Yingchao Deng wrote:
> Introduce a small encoding to carry the register index together with the
> base offset in a single u32, and use a common helper to compute the final
> MMIO address. This refactors register access to be based on the encoded
> (reg, nr) pair, reducing duplicated arithmetic and making it easier to
> support variants that bank or relocate trigger-indexed registers.
>
> Signed-off-by: Yingchao Deng <yingchao.deng@oss.qualcomm.com>
> ---
> drivers/hwtracing/coresight/coresight-cti-core.c | 31 +++++++++++++++--------
> drivers/hwtracing/coresight/coresight-cti-sysfs.c | 4 +--
> drivers/hwtracing/coresight/coresight-cti.h | 16 ++++++++++--
> 3 files changed, 36 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c
> index 4e7d12bd2d3e..c4cbeb64365b 100644
> --- a/drivers/hwtracing/coresight/coresight-cti-core.c
> +++ b/drivers/hwtracing/coresight/coresight-cti-core.c
> @@ -42,6 +42,14 @@ static DEFINE_MUTEX(ect_mutex);
> #define csdev_to_cti_drvdata(csdev) \
> dev_get_drvdata(csdev->dev.parent)
>
> +static void __iomem *cti_reg_addr(struct cti_drvdata *drvdata, int reg)
u32 reg would be better.
> +{
> + u32 offset = CTI_REG_CLR_NR(reg);
No functional error but a little bit tricky here.
CTI_REG_CLR_NR(reg) will produce a offset for the bits[0:23], but in the
comment, you mentioned the base register offset ranges from [0:11].
With my understanding, all CTI register offsets fall within the range b
0 to 0XFAC, that's why we have bits[0:11]?
Thanks,
Jie
> + u32 nr = CTI_REG_GET_NR(reg);
> +
> + return drvdata->base + offset + sizeof(u32) * nr;
> +}
> +
> /* write set of regs to hardware - call with spinlock claimed */
> void cti_write_all_hw_regs(struct cti_drvdata *drvdata)
> {
> @@ -55,16 +63,17 @@ void cti_write_all_hw_regs(struct cti_drvdata *drvdata)
>
> /* write the CTI trigger registers */
> for (i = 0; i < config->nr_trig_max; i++) {
> - writel_relaxed(config->ctiinen[i], drvdata->base + CTIINEN(i));
> + writel_relaxed(config->ctiinen[i],
> + cti_reg_addr(drvdata, CTI_REG_SET_NR(CTIINEN, i)));
> writel_relaxed(config->ctiouten[i],
> - drvdata->base + CTIOUTEN(i));
> + cti_reg_addr(drvdata, CTI_REG_SET_NR(CTIOUTEN, i)));
> }
>
> /* other regs */
> - writel_relaxed(config->ctigate, drvdata->base + CTIGATE);
> + writel_relaxed(config->ctigate, cti_reg_addr(drvdata, CTIGATE));
> if (config->asicctl_impl)
> - writel_relaxed(config->asicctl, drvdata->base + ASICCTL);
> - writel_relaxed(config->ctiappset, drvdata->base + CTIAPPSET);
> + writel_relaxed(config->asicctl, cti_reg_addr(drvdata, ASICCTL));
> + writel_relaxed(config->ctiappset, cti_reg_addr(drvdata, CTIAPPSET));
>
> /* re-enable CTI */
> writel_relaxed(1, drvdata->base + CTICONTROL);
> @@ -127,7 +136,7 @@ u32 cti_read_single_reg(struct cti_drvdata *drvdata, int offset)
> int val;
>
> CS_UNLOCK(drvdata->base);
> - val = readl_relaxed(drvdata->base + offset);
> + val = readl_relaxed(cti_reg_addr(drvdata, offset));
> CS_LOCK(drvdata->base);
>
> return val;
> @@ -136,7 +145,7 @@ u32 cti_read_single_reg(struct cti_drvdata *drvdata, int offset)
> void cti_write_single_reg(struct cti_drvdata *drvdata, int offset, u32 value)
> {
> CS_UNLOCK(drvdata->base);
> - writel_relaxed(value, drvdata->base + offset);
> + writel_relaxed(value, cti_reg_addr(drvdata, offset));
> CS_LOCK(drvdata->base);
> }
>
> @@ -344,8 +353,7 @@ int cti_channel_trig_op(struct device *dev, enum cti_chan_op op,
>
> /* update the local register values */
> chan_bitmask = BIT(channel_idx);
> - reg_offset = (direction == CTI_TRIG_IN ? CTIINEN(trigger_idx) :
> - CTIOUTEN(trigger_idx));
> + reg_offset = (direction == CTI_TRIG_IN ? CTIINEN : CTIOUTEN);
>
> guard(raw_spinlock_irqsave)(&drvdata->spinlock);
>
> @@ -365,8 +373,9 @@ int cti_channel_trig_op(struct device *dev, enum cti_chan_op op,
>
> /* write through if enabled */
> if (cti_is_active(config))
> - cti_write_single_reg(drvdata, reg_offset, reg_value);
> -
> + cti_write_single_reg(drvdata,
> + CTI_REG_SET_NR(reg_offset, trigger_idx),
> + reg_value);
> return 0;
> }
>
> diff --git a/drivers/hwtracing/coresight/coresight-cti-sysfs.c b/drivers/hwtracing/coresight/coresight-cti-sysfs.c
> index 2bbfa405cb6b..8b70e7e38ea3 100644
> --- a/drivers/hwtracing/coresight/coresight-cti-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-cti-sysfs.c
> @@ -386,7 +386,7 @@ static ssize_t inen_store(struct device *dev,
>
> /* write through if enabled */
> if (cti_is_active(config))
> - cti_write_single_reg(drvdata, CTIINEN(index), val);
> + cti_write_single_reg(drvdata, CTI_REG_SET_NR(CTIINEN, index), val);
>
> return size;
> }
> @@ -427,7 +427,7 @@ static ssize_t outen_store(struct device *dev,
>
> /* write through if enabled */
> if (cti_is_active(config))
> - cti_write_single_reg(drvdata, CTIOUTEN(index), val);
> + cti_write_single_reg(drvdata, CTI_REG_SET_NR(CTIOUTEN, index), val);
>
> return size;
> }
> diff --git a/drivers/hwtracing/coresight/coresight-cti.h b/drivers/hwtracing/coresight/coresight-cti.h
> index ef079fc18b72..dd1ba44518c4 100644
> --- a/drivers/hwtracing/coresight/coresight-cti.h
> +++ b/drivers/hwtracing/coresight/coresight-cti.h
> @@ -7,6 +7,7 @@
> #ifndef _CORESIGHT_CORESIGHT_CTI_H
> #define _CORESIGHT_CORESIGHT_CTI_H
>
> +#include <linux/bitfield.h>
> #include <linux/coresight.h>
> #include <linux/device.h>
> #include <linux/list.h>
> @@ -30,8 +31,8 @@ struct fwnode_handle;
> #define CTIAPPSET 0x014
> #define CTIAPPCLEAR 0x018
> #define CTIAPPPULSE 0x01C
> -#define CTIINEN(n) (0x020 + (4 * n))
> -#define CTIOUTEN(n) (0x0A0 + (4 * n))
> +#define CTIINEN 0x020
> +#define CTIOUTEN 0x0A0
> #define CTITRIGINSTATUS 0x130
> #define CTITRIGOUTSTATUS 0x134
> #define CTICHINSTATUS 0x138
> @@ -59,6 +60,17 @@ struct fwnode_handle;
> */
> #define CTIINOUTEN_MAX 32
>
> +/*
> + * Encode CTI register offset and register index in one u32:
> + * - bits[0:11] : base register offset (0x000 to 0xFFF)
> + * - bits[24:31] : register index (nr)
> + */
> +#define CTI_REG_NR_MASK GENMASK(31, 24)
> +#define CTI_REG_GET_NR(reg) FIELD_GET(CTI_REG_NR_MASK, (reg))
> +#define CTI_REG_SET_NR_CONST(reg, nr) ((reg) | FIELD_PREP_CONST(CTI_REG_NR_MASK, (nr)))
> +#define CTI_REG_SET_NR(reg, nr) ((reg) | FIELD_PREP(CTI_REG_NR_MASK, (nr)))
> +#define CTI_REG_CLR_NR(reg) ((reg) & (~CTI_REG_NR_MASK))
> +
> /**
> * Group of related trigger signals
> *
>
^ permalink raw reply
* [PATCH v2] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
From: Jinjie Ruan @ 2026-04-27 2:35 UTC (permalink / raw)
To: catalin.marinas, will, punit.agrawal, rafael.j.wysocki,
fengchengwen, chenl311, suzuki.poulose, maz, timothy.hayes,
lpieralisi, mrigendra.chaubey, arnd, sudeep.holla, yangyicong,
jic23, pierre.gondois, linux-arm-kernel, linux-kernel,
james.morse
Cc: ruanjinjie
On arm64, when booting with `maxcpus` greater than the number of present
CPUs (e.g., QEMU -smp cpus=4,maxcpus=8), some CPUs are marked as 'present'
but have not yet been registered via register_cpu(). Consequently,
the per-cpu device objects for these CPUs are not yet initialized.
In cpuhp_smt_enable(), the code iterates over all present CPUs. Calling
_cpu_up() for these unregistered CPUs eventually leads to
sysfs_create_group() being called with a NULL kobject (or a kobject
without a directory), triggering the following warning in
fs/sysfs/group.c:
if (WARN_ON(!kobj || (!update && !kobj->sd)))
return -EINVAL;
When booting with ACPI, arm64 smp_prepare_cpus() currently sets all
enumerated CPUs as "present" regardless of their status in the MADT. This
causes issues with SMT hotplug control. For instance, with QEMU's
"-smp 4,maxcpus=8" configuration, the MADT GICC entries are populated as
follows: the first four CPUs are marked Enabled while the remaining four
are marked Online Capable to support potential hot-plugging.
Fix this by:
1. When booting with ACPI, checking the ACPI_MADT_ENABLED flag in the GICC
entry before calling set_cpu_present() during SMP initialization.
2. Properly managing the present mask in acpi_map_cpu() and
acpi_unmap_cpu() to support actual CPU hotplug events, This aligns with
other architectures like x86 and LoongArch.
This ensures that only physically available or explicitly enabled CPUs
are in the present mask, keeping the SMT control logic consistent with
the actual hardware state.
How to reproduce:
1. echo off > /sys/devices/system/cpu/smt/control
psci: CPU1 killed (polled 0 ms)
psci: CPU3 killed (polled 0 ms)
2. echo 2 > /sys/devices/system/cpu/smt/control
Detected PIPT I-cache on CPU1
GICv3: CPU1: found redistributor 1 region 0:0x00000000080c0000
CPU1: Booted secondary processor 0x0000000001 [0x410fd082]
Detected PIPT I-cache on CPU3
GICv3: CPU3: found redistributor 3 region 0:0x0000000008100000
CPU3: Booted secondary processor 0x0000000003 [0x410fd082]
------------[ cut here ]------------
WARNING: fs/sysfs/group.c:137 at internal_create_group+0x41c/0x4bc, CPU#2: sh/181
Modules linked in:
CPU: 2 UID: 0 PID: 181 Comm: sh Not tainted 7.0.0-rc1-00010-g8d13386c7624 #142 PREEMPT
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : internal_create_group+0x41c/0x4bc
lr : sysfs_create_group+0x18/0x24
sp : ffff80008078ba40
x29: ffff80008078ba40 x28: ffff296c980ad000 x27: ffff00007fb94128
x26: 0000000000000054 x25: ffffd693e845f3f0 x24: 0000000000000001
x23: 0000000000000001 x22: 0000000000000004 x21: 0000000000000000
x20: ffffd693e845fc10 x19: 0000000000000004 x18: 00000000ffffffff
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000358 x13: 0000000000000007 x12: 0000000000000350
x11: 0000000000000008 x10: 0000000000000407 x9 : 0000000000000400
x8 : ffff00007fbf3b60 x7 : 0000000000000000 x6 : ffffd693e845f3f0
x5 : ffff00007fb94128 x4 : 0000000000000000 x3 : ffff000000f4eac0
x2 : ffffd693e7095a08 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
internal_create_group+0x41c/0x4bc (P)
sysfs_create_group+0x18/0x24
topology_add_dev+0x1c/0x28
cpuhp_invoke_callback+0x104/0x20c
__cpuhp_invoke_callback_range+0x94/0x11c
_cpu_up+0x200/0x37c
cpuhp_smt_enable+0xbc/0x114
control_store+0xe8/0x1d4
dev_attr_store+0x18/0x2c
sysfs_kf_write+0x7c/0x94
kernfs_fop_write_iter+0x128/0x1b8
vfs_write+0x2b0/0x354
ksys_write+0x68/0xfc
__arm64_sys_write+0x1c/0x28
invoke_syscall+0x48/0x10c
el0_svc_common.constprop.0+0x40/0xe8
do_el0_svc+0x20/0x2c
el0_svc+0x34/0x124
el0t_64_sync_handler+0xa0/0xe4
el0t_64_sync+0x198/0x19c
---[ end trace 0000000000000000 ]---
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Yicong Yang <yangyicong@hisilicon.com>
Cc: stable@vger.kernel.org
Link: https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#gic-cpu-interface-gicc-structure
Fixes: eed4583bcf9a6 ("arm64: Kconfig: Enable HOTPLUG_SMT")
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/arm64/kernel/acpi.c | 2 ++
arch/arm64/kernel/smp.c | 12 +++++++++++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 5891f92c2035..681aa2bbc399 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -448,12 +448,14 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, u32 apci_id,
return *pcpu;
}
+ set_cpu_present(*pcpu, true);
return 0;
}
EXPORT_SYMBOL(acpi_map_cpu);
int acpi_unmap_cpu(int cpu)
{
+ set_cpu_present(cpu, false);
return 0;
}
EXPORT_SYMBOL(acpi_unmap_cpu);
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 1aa324104afb..5932e5b30b71 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -566,6 +566,11 @@ struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu)
}
EXPORT_SYMBOL_GPL(acpi_cpu_get_madt_gicc);
+static bool acpi_cpu_is_present(int cpu)
+{
+ return acpi_cpu_get_madt_gicc(cpu)->flags & ACPI_MADT_ENABLED;
+}
+
/*
* acpi_map_gic_cpu_interface - parse processor MADT entry
*
@@ -670,6 +675,10 @@ static void __init acpi_parse_and_init_cpus(void)
early_map_cpu_to_node(i, acpi_numa_get_nid(i));
}
#else
+static bool acpi_cpu_is_present(int cpu)
+{
+ return false;
+}
#define acpi_parse_and_init_cpus(...) do { } while (0)
#endif
@@ -808,7 +817,8 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
if (err)
continue;
- set_cpu_present(cpu, true);
+ if (acpi_disabled || acpi_cpu_is_present(cpu))
+ set_cpu_present(cpu, true);
numa_store_cpu_info(cpu);
}
}
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/3] Add i.MX94 remoteproc support and reset vector handling improvements
From: Peng Fan (OSS) @ 2026-04-27 2:41 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
Peng Fan
This series adds remoteproc support for the i.MX94 family, including the
CM70, CM71, and CM33S cores, and derive the hardware reset vector for
Cortex‑M processors whose ELF entry point does not directly correspond to
the actual reset address.
Background:
Cortex‑M processors fetch their initial SP and PC from a fixed reset vector
table. While ELF images embed the entry point (e_entry), this value is
not always aligned to the hardware reset address. On platforms such as
i.MX94 CM33S, masking is required to compute the correct reset vector
address before programming the SoC reset registers.
Similarly, on i.MX95, the existing implementation always programs a reset
vector of 0x0, which only works when executing entirely from TCM. When
firmware is loaded into DDR, the driver must pass the correct reset vector
to the SM CPU/LMM interfaces.
Summary of patches:
[1]dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask
Adds a new DT property allowing SoCs to specify a mask for deriving the
hardware reset vector from the ELF entry point.
[2]remoteproc: imx_rproc: Program non-zero SM CPU/LMM reset vector
Ensures the correct reset vector is passed to SM APIs by introducing a
helper (imx_rproc_sm_get_reset_vector()) that applies the reset‑vector
mask.
[3]remoteproc: imx_rproc: Add support for i.MX94 remoteproc
Adds address translation tables and configuration data for CM70, CM71,
and CM33S, enabling full remoteproc operation on i.MX94.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Changes in v4:
- Daniel raised the M33S secure region was not included, but since I not
have image to test secure region, so drop the Secure alias region for
all. Updated DDR region. R-b kept since this is a minor change.
- Add R-b for patch 2
- Link to v3: https://lore.kernel.org/r/20260415-imx943-rproc-v3-0-9fa7528db8ca@nxp.com
Changes in v3:
- Patch 2:
Drop R-b because of changes in V3
Following suggestion from Mathieu that apply reset vector in
scmi_imx_[cpu,lmm]_reset_vector_set(), not change the meaning of
rproc->bootaddr, add helper imx_rproc_sm_get_reset_vector() to get reset
vector and use the hlper in scmi_imx_[cpu,lmm]_reset_vector_set().
Add reset-vector-mask for i.MX95 CM7 to avoid breaking i.MX95 CM7
boot.
- Link to v2: https://lore.kernel.org/r/20260327-imx943-rproc-v2-0-a547a3588730@nxp.com
Changes in v2:
- Drop fsl,reset-vector-mask by using fixed value in driver for per device
- Add R-b for i.MX94 dt-binding
- Update commit log to include dev addr and sys addr
- Link to v1: https://lore.kernel.org/r/20260312-imx943-rproc-v1-0-3e66596592a8@nxp.com
---
Peng Fan (3):
dt-bindings: remoteproc: imx-rproc: Support i.MX94
remoteproc: imx_rproc: Program non-zero SM CPU/LMM reset vector
remoteproc: imx_rproc: Add support for i.MX94
.../bindings/remoteproc/fsl,imx-rproc.yaml | 3 +
drivers/remoteproc/imx_rproc.c | 92 +++++++++++++++++++++-
drivers/remoteproc/imx_rproc.h | 2 +
3 files changed, 95 insertions(+), 2 deletions(-)
---
base-commit: 724699d8d0523909da51fda8d1e10c1ff867b280
change-id: 20260311-imx943-rproc-2050e00b65f7
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* [PATCH v4 1/3] dt-bindings: remoteproc: imx-rproc: Support i.MX94
From: Peng Fan (OSS) @ 2026-04-27 2:41 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
Peng Fan
In-Reply-To: <20260427-imx943-rproc-v4-0-68d7c7253acd@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add compatible string for:
Cortex-M7 core[0,1] in i.MX94
Cortex-M33 Sync core in i.MX94
To i.MX94, Cortex-M7 core0 and core1 have different memory view from
Cortex-A55 core, so different compatible string is used.
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index ce8ec0119469c8fc0979a192b6e3d3a03108d7d2..c18f71b648890da9c25a2f3309d8dbec5bb8d226 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -28,6 +28,9 @@ properties:
- fsl,imx8qxp-cm4
- fsl,imx8ulp-cm33
- fsl,imx93-cm33
+ - fsl,imx94-cm33s
+ - fsl,imx94-cm70
+ - fsl,imx94-cm71
- fsl,imx95-cm7
clocks:
--
2.37.1
^ permalink raw reply related
* [PATCH v4 2/3] remoteproc: imx_rproc: Program non-zero SM CPU/LMM reset vector
From: Peng Fan (OSS) @ 2026-04-27 2:41 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
Peng Fan
In-Reply-To: <20260427-imx943-rproc-v4-0-68d7c7253acd@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Cortex-M[7,33] processors use a fixed reset vector table format:
0x00 Initial SP value
0x04 Reset vector
0x08 NMI
0x0C ...
...
IRQ[n]
In ELF images, the corresponding layout is:
reset_vectors: --> hardware reset address
.word __stack_end__
.word Reset_Handler
.word NMI_Handler
.word HardFault_Handler
...
.word UART_IRQHandler
.word SPI_IRQHandler
...
Reset_Handler: --> ELF entry point address
...
The hardware fetches the first two words from reset_vectors and populates
SP with __stack_end__ and PC with Reset_Handler. Execution proceeds from
Reset_Handler.
However, the ELF entry point does not always match the hardware reset
address. For example, on i.MX94 CM33S:
ELF entry point: 0x0ffc211d
hardware reset base: 0x0ffc0000 (default reset value, sw programmable)
Current driver always programs the reset vector as 0. But i.MX94 CM33S's
default reset base is 0x0ffc0000, so the correct reset vector must be
passed to the SM API; otherwise the M33 Sync core cannot boot successfully.
rproc_elf_get_boot_addr() returns the ELF entry point, which is not the
hardware reset vector address. Fix the issue by deriving the hardware reset
vector locally using a SoC-specific mask:
reset_vector = rproc->bootaddr & reset_vector_mask
The ELF entry point semantics remain unchanged. The masking is applied only
at the point where the SM reset vector is programmed.
Add reset_vector_mask = GENMASK_U32(31, 16) to the i.MX95 M7 configuration
so the hardware reset vector is derived correctly. Without this mask, the
SM reset vector would be programmed with an unaligned ELF entry point and
the M7 core would fail to boot.
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 27 +++++++++++++++++++++++++--
drivers/remoteproc/imx_rproc.h | 2 ++
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 0dd80e688b0ea3df4c66e5726884dc86c8a5a881..c21782be4bb69d830479f538a091bda48b740ca4 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -339,13 +339,32 @@ static int imx_rproc_scu_api_start(struct rproc *rproc)
return imx_sc_pm_cpu_start(priv->ipc_handle, priv->rsrc_id, true, priv->entry);
}
+static u64 imx_rproc_sm_get_reset_vector(struct rproc *rproc)
+{
+ struct imx_rproc *priv = rproc->priv;
+ u32 reset_vector_mask = priv->dcfg->reset_vector_mask ?: GENMASK(31, 0);
+
+ /*
+ * The hardware fetches the first two words from reset_vectors
+ * (hardware reset address) and populates SP and PC using the first
+ * two words. Execution proceeds from PC. The ELF entry point does
+ * not always match the hardware reset address.
+ * To derive the correct hardware reset address, the lower address
+ * bits must be masked off before programming the reset vector.
+ */
+ return rproc->bootaddr & reset_vector_mask;
+}
+
static int imx_rproc_sm_cpu_start(struct rproc *rproc)
{
struct imx_rproc *priv = rproc->priv;
const struct imx_rproc_dcfg *dcfg = priv->dcfg;
+ u64 reset_vector;
int ret;
- ret = scmi_imx_cpu_reset_vector_set(dcfg->cpuid, 0, true, false, false);
+ reset_vector = imx_rproc_sm_get_reset_vector(rproc);
+
+ ret = scmi_imx_cpu_reset_vector_set(dcfg->cpuid, reset_vector, true, false, false);
if (ret) {
dev_err(priv->dev, "Failed to set reset vector cpuid(%u): %d\n", dcfg->cpuid, ret);
return ret;
@@ -359,13 +378,16 @@ static int imx_rproc_sm_lmm_start(struct rproc *rproc)
struct imx_rproc *priv = rproc->priv;
const struct imx_rproc_dcfg *dcfg = priv->dcfg;
struct device *dev = priv->dev;
+ u64 reset_vector;
int ret;
+ reset_vector = imx_rproc_sm_get_reset_vector(rproc);
+
/*
* If the remoteproc core can't start the M7, it will already be
* handled in imx_rproc_sm_lmm_prepare().
*/
- ret = scmi_imx_lmm_reset_vector_set(dcfg->lmid, dcfg->cpuid, 0, 0);
+ ret = scmi_imx_lmm_reset_vector_set(dcfg->lmid, dcfg->cpuid, 0, reset_vector);
if (ret) {
dev_err(dev, "Failed to set reset vector lmid(%u), cpuid(%u): %d\n",
dcfg->lmid, dcfg->cpuid, ret);
@@ -1462,6 +1484,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx95_m7 = {
/* Must align with System Manager Firmware */
.cpuid = 1, /* Use 1 as cpu id for M7 core */
.lmid = 1, /* Use 1 as Logical Machine ID where M7 resides */
+ .reset_vector_mask = GENMASK_U32(31, 16),
};
static const struct of_device_id imx_rproc_of_match[] = {
diff --git a/drivers/remoteproc/imx_rproc.h b/drivers/remoteproc/imx_rproc.h
index d37e6f90548cec727b4aeb874680b42af85bdbb4..0d7d48352a1091ad24e8e083172ce6da6d26ae10 100644
--- a/drivers/remoteproc/imx_rproc.h
+++ b/drivers/remoteproc/imx_rproc.h
@@ -41,6 +41,8 @@ struct imx_rproc_dcfg {
/* For System Manager(SM) based SoCs */
u32 cpuid; /* ID of the remote core */
u32 lmid; /* ID of the Logcial Machine */
+ /* reset_vector = elf_entry_addr & reset_vector_mask */
+ u32 reset_vector_mask;
};
#endif /* _IMX_RPROC_H */
--
2.37.1
^ permalink raw reply related
* [PATCH v4 3/3] remoteproc: imx_rproc: Add support for i.MX94
From: Peng Fan (OSS) @ 2026-04-27 2:41 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta
Cc: linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel,
Peng Fan
In-Reply-To: <20260427-imx943-rproc-v4-0-68d7c7253acd@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add basic remoteproc support for the i.MX94 M-core processors, including
address translation tables(dev addr is from view of remote processor,
sys addr is from view of main processor) and device configuration data for
the CM70, CM71, and CM33S cores.
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 65 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 65 insertions(+)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index c21782be4bb69d830479f538a091bda48b740ca4..7f54322244acacb32d8fe17f5e62b6aba21b3084 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -145,6 +145,41 @@ static const struct imx_rproc_att imx_rproc_att_imx95_m7[] = {
{ 0x80000000, 0x80000000, 0x50000000, 0 },
};
+static const struct imx_rproc_att imx_rproc_att_imx94_m70[] = {
+ /* dev addr , sys addr , size , flags */
+ /* TCM CODE NON-SECURE */
+ { 0x00000000, 0x203C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+ /* TCM SYS NON-SECURE*/
+ { 0x20000000, 0x20400000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+ /* DDR */
+ { 0x80000000, 0x80000000, 0x10000000, 0 },
+};
+
+static const struct imx_rproc_att imx_rproc_att_imx94_m71[] = {
+ /* dev addr , sys addr , size , flags */
+ /* TCM CODE NON-SECURE */
+ { 0x00000000, 0x202C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+ /* TCM SYS NON-SECURE*/
+ { 0x20000000, 0x20300000, 0x00040000, ATT_OWN | ATT_IOMEM },
+
+ /* DDR */
+ { 0x80000000, 0x80000000, 0x10000000, 0 },
+};
+
+static const struct imx_rproc_att imx_rproc_att_imx94_m33s[] = {
+ /* dev addr , sys addr , size , flags */
+ /* TCM CODE NON-SECURE */
+ { 0x0FFC0000, 0x209C0000, 0x00040000, ATT_OWN | ATT_IOMEM },
+ /* TCM SYS NON-SECURE */
+ { 0x20000000, 0x20A00000, 0x00040000, ATT_OWN | ATT_IOMEM },
+ /* M33S OCRAM NON-SECURE */
+ { 0x20800000, 0x20800000, 0x180000, ATT_OWN | ATT_IOMEM },
+
+ /* DDR */
+ { 0x80000000, 0x80000000, 0x10000000, 0 },
+};
+
static const struct imx_rproc_att imx_rproc_att_imx93[] = {
/* dev addr , sys addr , size , flags */
/* TCM CODE NON-SECURE */
@@ -1477,6 +1512,33 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx93 = {
.flags = IMX_RPROC_NEED_CLKS,
};
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m70 = {
+ .att = imx_rproc_att_imx94_m70,
+ .att_size = ARRAY_SIZE(imx_rproc_att_imx94_m70),
+ .ops = &imx_rproc_ops_sm_lmm,
+ .cpuid = 1,
+ .lmid = 2,
+ .reset_vector_mask = GENMASK_U32(31, 16),
+};
+
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m71 = {
+ .att = imx_rproc_att_imx94_m71,
+ .att_size = ARRAY_SIZE(imx_rproc_att_imx94_m71),
+ .ops = &imx_rproc_ops_sm_lmm,
+ .cpuid = 7,
+ .lmid = 3,
+ .reset_vector_mask = GENMASK_U32(31, 16),
+};
+
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx94_m33s = {
+ .att = imx_rproc_att_imx94_m33s,
+ .att_size = ARRAY_SIZE(imx_rproc_att_imx94_m33s),
+ .ops = &imx_rproc_ops_sm_lmm,
+ .cpuid = 8,
+ .lmid = 1,
+ .reset_vector_mask = GENMASK_U32(31, 16),
+};
+
static const struct imx_rproc_dcfg imx_rproc_cfg_imx95_m7 = {
.att = imx_rproc_att_imx95_m7,
.att_size = ARRAY_SIZE(imx_rproc_att_imx95_m7),
@@ -1501,6 +1563,9 @@ static const struct of_device_id imx_rproc_of_match[] = {
{ .compatible = "fsl,imx8qm-cm4", .data = &imx_rproc_cfg_imx8qm },
{ .compatible = "fsl,imx8ulp-cm33", .data = &imx_rproc_cfg_imx8ulp },
{ .compatible = "fsl,imx93-cm33", .data = &imx_rproc_cfg_imx93 },
+ { .compatible = "fsl,imx94-cm70", .data = &imx_rproc_cfg_imx94_m70 },
+ { .compatible = "fsl,imx94-cm71", .data = &imx_rproc_cfg_imx94_m71 },
+ { .compatible = "fsl,imx94-cm33s", .data = &imx_rproc_cfg_imx94_m33s },
{ .compatible = "fsl,imx95-cm7", .data = &imx_rproc_cfg_imx95_m7 },
{},
};
--
2.37.1
^ permalink raw reply related
* [PATCH v4 0/4] Enable sysfs module symlink for more built-in drivers
From: Shashank Balaji @ 2026-04-27 2:41 UTC (permalink / raw)
To: Suzuki K Poulose, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Richard Cochran, Jonathan Corbet,
Shuah Khan, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Mike Leach, Leo Yan, Mike Leach
Cc: Rahul Bukte, Shashank Balaji, linux-kernel, coresight,
linux-arm-kernel, driver-core, rust-for-linux, linux-doc,
Daniel Palmer, Tim Bird, linux-modules
In-Reply-To: <20260422-acpi_mod_name-v3-0-a184eff9ff6f@sony.com>
struct device_driver's mod_name is not set by a number of bus' driver registration
functions. Without that, built-in drivers don't have the module symlink in sysfs.
We want this to go from unbound driver name -> module name -> kernel config name.
This is useful on embedded platforms to minimize kernel config, reduce kernel size,
and reduce boot time.
In order to achieve this, mod_name has to be set to KBUILD_MODNAME, and this has
to be done for all buses which don't yet do this.
Here are some treewide stats:
- 110 registration functions across all bus types
- 20 of them set mod_name
- Remaining 90 do not set mod_name:
1. 36 functions under pattern 1:
They have a __register function + register macro. KBUILD_MODNAME needs to
be passed and the function needs to take mod_name as input.
2. 42 functions under pattern 2:
These have no macro wrapper. They need a double-underscore rename + macro
wrapper to make them similar to pattern 1.
3. Remaining 12 do not have such a clean registration interface. More analysis
is required.
We plan to start with pattern 1, since it's the easiest category of changes.
Within that, for now we're only sending the platform patch. If we get the go-ahead
on that, we'll send the remaining ones.
Patch 3 depends on patches 1 and 2.
Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
---
Changes in v4:
- Initialize module_kset in do_basic_setup() before do_initcalls() (Gary)
- Add commit body to the documentation patch (Greg)
- Link to v3: https://patch.msgid.link/20260422-acpi_mod_name-v3-0-a184eff9ff6f@sony.com
Changes in v3:
- Initialize module_kset on-demand (Greg)
- Make coresight driver registration happen through a macro (Greg)
- Split up the patch adding mod_name to platform driver registrations (Greg)
- Link to v2: https://patch.msgid.link/20260421-acpi_mod_name-v2-0-e73f9310dad3@sony.com
Changes in v2:
- Drop acpi patch, send platform instead (Rafael)
- Link to v1: https://patch.msgid.link/20260416-acpi_mod_name-v1-0-1a4d96fd86c9@sony.com
To: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Mike Leach <mike.leach@linaro.org>
To: James Clark <james.clark@linaro.org>
To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
To: Maxime Coquelin <mcoquelin.stm32@gmail.com>
To: Alexandre Torgue <alexandre.torgue@foss.st.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
To: Danilo Krummrich <dakr@kernel.org>
To: Miguel Ojeda <ojeda@kernel.org>
To: Boqun Feng <boqun@kernel.org>
To: Gary Guo <gary@garyguo.net>
To: Björn Roy Baron <bjorn3_gh@protonmail.com>
To: Benno Lossin <lossin@kernel.org>
To: Andreas Hindborg <a.hindborg@kernel.org>
To: Alice Ryhl <aliceryhl@google.com>
To: Trevor Gross <tmgross@umich.edu>
To: Richard Cochran <richardcochran@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Shuah Khan <skhan@linuxfoundation.org>
To: Luis Chamberlain <mcgrof@kernel.org>
To: Petr Pavlu <petr.pavlu@suse.com>
To: Daniel Gomez <da.gomez@kernel.org>
To: Sami Tolvanen <samitolvanen@google.com>
To: Aaron Tomlin <atomlin@atomlin.com>
To: Mike Leach <mike.leach@arm.com>
To: Leo Yan <leo.yan@arm.com>
Cc: linux-kernel@vger.kernel.org
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: driver-core@lists.linux.dev
Cc: rust-for-linux@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: Shashank Balaji <shashank.mahadasyam@sony.com>
Cc: Rahul Bukte <rahul.bukte@sony.com>
Cc: Daniel Palmer <daniel.palmer@sony.com>
Cc: Tim Bird <tim.bird@sony.com>
Cc: linux-modules@vger.kernel.org
---
Shashank Balaji (4):
kernel: param: initialize module_kset before do_initcalls()
coresight: pass THIS_MODULE implicitly through a macro
driver core: platform: set mod_name in driver registration
docs: driver-api: add mod_name argument to __platform_register_drivers()
Documentation/driver-api/driver-model/platform.rst | 3 ++-
drivers/base/platform.c | 21 ++++++++++++++-------
drivers/hwtracing/coresight/coresight-catu.c | 2 +-
drivers/hwtracing/coresight/coresight-core.c | 9 +++++----
drivers/hwtracing/coresight/coresight-cpu-debug.c | 3 +--
drivers/hwtracing/coresight/coresight-funnel.c | 3 +--
drivers/hwtracing/coresight/coresight-replicator.c | 3 +--
drivers/hwtracing/coresight/coresight-stm.c | 2 +-
drivers/hwtracing/coresight/coresight-tmc-core.c | 2 +-
drivers/hwtracing/coresight/coresight-tnoc.c | 2 +-
drivers/hwtracing/coresight/coresight-tpdm.c | 3 +--
drivers/hwtracing/coresight/coresight-tpiu.c | 2 +-
include/linux/coresight.h | 7 +++++--
include/linux/module.h | 4 ++++
include/linux/platform_device.h | 17 +++++++++--------
init/main.c | 1 +
kernel/params.c | 21 +++++++++------------
rust/kernel/platform.rs | 4 +++-
18 files changed, 61 insertions(+), 48 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260416-acpi_mod_name-f645a76e337b
Best regards,
--
Shashank Balaji <shashank.mahadasyam@sony.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox