* Re: [PATCH 1/2] dt-bindings: remoteproc: xlnx: add auto boot feature
From: Krzysztof Kozlowski @ 2026-04-23 17:26 UTC (permalink / raw)
To: tanmay.shah
Cc: andersson, mathieu.poirier, robh, krzk+dt, conor+dt, michal.simek,
ben.levinsky, linux-remoteproc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <2351c698-cf08-4037-9777-0820448a14d8@amd.com>
On 23/04/2026 17:14, Shah, Tanmay wrote:
> Hello,
>
> Thanks for reviews. Please see my comments below.
>
> On 4/23/2026 4:09 AM, Krzysztof Kozlowski wrote:
>> On Wed, Apr 22, 2026 at 01:25:57PM -0700, Tanmay Shah wrote:
>>> Add auto-boot property to notify that remote processor is setup and
>>> ready to boot. Linux can attempt to boot or attach to already running
>>> remote processor. "firmware-name" property is used to mention default
>>> firmware to boot when linux starts the remote processor.
>>>
>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>> ---
>>> .../devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>> index ee63c03949c9..0d27260e3baa 100644
>>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>> @@ -135,6 +135,14 @@ patternProperties:
>>> - description: vring1
>>> additionalItems: true
>>>
>>> + auto-boot:
>>
>> Last months, I have been asking AMD to follow writing-bindings doc or
>> other DT guidelines way too many times.
>>
>> Or you just sent us downstream... Do you see anywhere such property?
>> What properties do you see? How are they named?
>>
>
> I should have put note about this. Current auto-boot properties are
> named like st,auto-boot fsl,auto-boot etc. but nothing vendor specific
> there. Can we have a common auto-boot property? Similar to
> firmware-name? If we agree to it then what's the correct location? New
> file remoteproc.yaml is okay?
Common properties go to dtschema, so it would need to go there, but the
point is that it's way too generic - every component with FW could be
called "auto-boot". This should stay vendor property, IMO.
>
>>> + type: boolean
>>> + description: remote core is either already running or ready to boot
>>
>> And why is this property of a board?
>>
>
> Not sure what indicates it is? The property is under remoteproc child
> device that is SOC level property. Remote core is on same SOC wher linux
> core is running.
So it is implied by SoC compatible? Please provide some arguments why it
cannot be implied by the SoC compatible. I gave you one way out, but if
you disagree then no problem.
>
>>> +
>>> + firmware-name:
>>> + maxItems: 1
>>> + description: default firmware to load
>>
>> Can you load non-default firmware later? IOW, why adding description
>> here, what is special?
>>
>
> The rootfs contains other firmware demos, and it is possible to stop the
> default firmware, load other fw elf and re-run the remote core.
> I don't have strong preference on the description part, I will remove it
> if redundant.
No, it's fine, I wanted to be sure that such use case makes sense.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Chris Kennelly @ 2026-04-23 17:38 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Mathias Stearn, Peter Zijlstra, Mathieu Desnoyers,
Catalin Marinas, Will Deacon, Boqun Feng, Paul E. McKenney,
Dmitry Vyukov, regressions, linux-kernel, linux-arm-kernel,
Ingo Molnar, Mark Rutland, Jinjie Ruan, Blake Oler,
Linus Torvalds
In-Reply-To: <87cxzp1tn6.ffs@tglx>
On Thu, Apr 23, 2026 at 1:19 PM Thomas Gleixner <tglx@kernel.org> wrote:
>
> On Thu, Apr 23 2026 at 14:11, Mathias Stearn wrote:
>
> Cc+ Linus
>
> > Of course, even if we make that change, it will only apply to _future_
> > binaries. That's why we prefer a kernel fix so that users will be able
> > to run our existing releases (or any containers that use them) on a
> > modern kernel.
>
> I understand that and as everyone else I would be happy to do that, but
> the price everyone pays for proliferating the tcmalloc insanity is not
> cheap either.
>
> So let me recap the whole situation and how we got there:
>
> 1) The original RSEQ implementation updates the rseq::cpu_id_start
> field in user space more or less unconditionally on every exit to
> user, whether the CPU/MMCID have been changed or not.
>
> That went unnoticed for years because nothing used rseq aside of
> google and tcmalloc. Once glibc registered rseq, this resulted in a
> up to 15% performance penalty for syscall heavy workloads.
>
> 2) The rseq::cpu_id_start field is documented as read only for user
> space in the ABI contract and guaranteed to be updated by the
> kernel when a task is migrated to a different CPU.
>
> 3) The RO for userspace property has been enforced by RSEQ debugging
> mode since day one. If such a debug enabled kernel detects user
> space changing the field it kills the task/application.
The optimization in TCMalloc that you're describing has been available
since September 2023:
https://github.com/google/tcmalloc/commit/aaa4fbf6fcdce1b7f86fcadd659874645c75ddb9
I thought the RSEQ debug checks were added in December 2024:
https://github.com/torvalds/linux/commit/7d5265ffcd8b41da5e09066360540d6e0716e9cd,
but perhaps I misidentified the ones in question.
>
> 4) tcmalloc abused the suboptimal implementation (see #1) and
> scribbled over rseq::cpu_id_start for their own nefarious purposes.
>
> 5) As a consequence of #4 tcmalloc cannot be used on a RSEQ debug
> enabled kernel. Which means a developer cannot validate his RSEQ
> code against a debug kernel when tcmalloc is in use on the system
> as that would crash the tcmalloc dependent applications due to #3.
>
> 6) As a consequence of #4 tcmalloc cannot be used together with any
> other facility/library which wants to utilize the ABI guaranteed
> properties of rseq::cpu_id_start in the same application.
>
> 7) tcmalloc violates the ABI from day one and has since refused to
> address the problem despite being offered a kernel side rseq
> extension to solve it many years ago.
I know there was some discussion around a preemption notification
scheme, rseq_sched_state; but I thought the discussion moved in favor
of the timeslice extension interface that recently landed. Timeslice
extension solves some use cases, but I'm not sure it addresses this
one.
>
> 8) When addressing the performance issues of RSEQ the unconditional
> update stopped to exist under the valid assumption that the kernel
> has only to satisfy the guaranteed ABI properties, especially when
> they are enforcable by RSEQ debug.
>
> As a consequence this exposed the tcmalloc ABI violation because
> the unconditional pointless overwriting of something which did not
> change stopped to happen.
>
> Due to #4 everyone is in a hard place and up a creek without a paddle.
>
> Here are the possible solutions:
>
> A) Mathias suggested to force overwrite rseq:cpu_id_start everytime
> the rseq::rseq_cs field is cleared by the kernel under the not yet
> validated theoretical assumption that this cures the problem for
> tcmalloc.
>
> If that's sufficient that would be harmless performance wise
> because the write would be inside the already existing STAC/CLAC
> section and just add some more noise to the rseq critical section
> operations.
>
> That would allow existing tcmalloc usage to continue, but
> obviously would neither solve #5 and #6 above nor provide an
> incentive for tcmalloc to actually fix their crap.
>
> B) If that's not sufficient then keeping tcmalloc alive would require
> to go back to the previous state and let everyone else pay the
> price in terms of performance overhead.
>
> C) Declare that this is not a regression because the ABI guarantee is
> not violated and the RO property has been enforcable by RSEQ
> debugging since day one.
>
> In my opinion #C is the right thing to do, but I can see a case being
> made for the lightweight fix Mathias suggested (#A) _if_ and only _if_
> that is sufficient. Picking #A would also mean that user space people
> have to take up the fight against tcmalloc when they want to use the
> RSEQ guaranteed ABI along with tcmalloc in the same application or use a
> RSEQ debug kernel to validate their own code.
>
> Going back to the full unconditional nightmare (#B) is not an option at
> all as anybody else has to take the massive performance hit.
>
> Oh well...
>
> Thanks,
>
> tglx
^ permalink raw reply
* [PATCH v2 0/2] spi: sun6i: Fix chip select handling around autosuspend
From: Kevin Mehall @ 2026-04-23 17:39 UTC (permalink / raw)
To: Mark Brown, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Mirko Vogt, Ralf Schlatterbeck, linux-spi, linux-arm-kernel,
linux-sunxi, linux-kernel
Move the initialization of the SUN6I_TFR_CTL_REG bits out of
sun6i_spi_transfer_one() into earlier callbacks to fix two bugs:
- With a native chip select, the setup_delay is not correctly applied to
the first transfer after autosuspend.
- With a GPIO chip select, the CS is asserted before SCK is driven to the
correct initial level per the SPI mode. When the mode is set, it can
cause an extra SCK transition with CS low and corrupt the transfer.
Changes since the previous single patch:
- Move the line that sets `SUN6I_TFR_CTL_CS_MANUAL` into
`sun6i_spi_set_cs()` rather than into `sun6i_spi_prepare_message()`.
This change is now a separate commit.
Kevin Mehall (2):
spi: sun6i: Honor CS setup delay on the first transfer with native CS
spi: sun6i: Set SPI mode in prepare_message
drivers/spi/spi-sun6i.c | 74 +++++++++++++++++++++++++----------------
1 file changed, 45 insertions(+), 29 deletions(-)
base-commit: 028ef9c96e96197026887c0f092424679298aae8
--
2.53.0
^ permalink raw reply
* [PATCH v2 1/2] spi: sun6i: Honor CS setup delay on the first transfer with native CS
From: Kevin Mehall @ 2026-04-23 17:40 UTC (permalink / raw)
To: Mark Brown, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Mirko Vogt, Ralf Schlatterbeck, linux-spi, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260423174001.2797797-1-km@kevinmehall.net>
Move SUN6I_TFR_CTL_CS_MANUAL to sun6i_spi_set_cs.
The CS_MANUAL bit is required for CS_LEVEL to affect the CS pin state.
Set it in the same place as other CS bits to ensure that set_cs takes
effect immediately, and to make it easier to reason about CS behavior.
Previously, this bit was not set until the first transfer's
sun6i_spi_transfer_one. That meant that on the first transfer, set_cs
would have no immediate effect, and the CS falling edge was deferred
until the bit is set in transfer_one. As any configured cs_setup delay
happens between those two steps, the configured delay would have
effectively been ignored on the very first transfer. This change makes
the first transfer work like subsequent ones.
Link: https://lore.kernel.org/linux-spi/d199f72a-093b-41bb-b33e-b6685563f704@app.fastmail.com/
Fixes: 3558fe900e8a ("spi: sunxi: Add Allwinner A31 SPI controller driver")
Signed-off-by: Kevin Mehall <km@kevinmehall.net>
---
drivers/spi/spi-sun6i.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 240e46f84f7b..fc228574ed38 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -185,6 +185,10 @@ static void sun6i_spi_set_cs(struct spi_device *spi, bool enable)
u32 reg;
reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
+
+ /* SUN6I_TFR_CTL_CS_LEVEL sets CS rather than the controller doing it automatically */
+ reg |= SUN6I_TFR_CTL_CS_MANUAL;
+
reg &= ~SUN6I_TFR_CTL_CS_MASK;
reg |= SUN6I_TFR_CTL_CS(spi_get_chipselect(spi, 0));
@@ -364,9 +368,6 @@ static int sun6i_spi_transfer_one(struct spi_controller *host,
reg |= SUN6I_TFR_CTL_DHB;
}
- /* We want to control the chip select manually */
- reg |= SUN6I_TFR_CTL_CS_MANUAL;
-
sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
if (sspi->cfg->has_clk_ctl) {
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/2] spi: sun6i: Set SPI mode in prepare_message
From: Kevin Mehall @ 2026-04-23 17:40 UTC (permalink / raw)
To: Mark Brown, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Mirko Vogt, Ralf Schlatterbeck, linux-spi, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260423174001.2797797-1-km@kevinmehall.net>
With a GPIO chip select, CS is asserted before entering transfer_one.
The spi-sun6i driver previously configured the SPI mode (including clock
polarity) and enabled the bus in transfer_one, which can cause an
extraneous SCK transition with CS asserted, corrupting the transferred
data.
This patch moves the SPI mode configuration and bus enable to the
spi_prepare_message callback, ensuring that SCK is driven to the correct
level prior to asserting CS.
A previous fix for a related issue (0d7993b234c9f) was incomplete in
that it only delayed enabling the SCK output drive to prevent it from
being driven at the wrong level when resuming from autosuspend, but
didn't help if switching CPOL modes between chip selects while active,
or if SCK floats to the opposite level when suspended.
Fixes: 0d7993b234c9 ("spi: spi-sun6i: Fix chipselect/clock bug")
Signed-off-by: Kevin Mehall <km@kevinmehall.net>
---
drivers/spi/spi-sun6i.c | 67 +++++++++++++++++++++++++----------------
1 file changed, 41 insertions(+), 26 deletions(-)
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index fc228574ed38..983e791e3396 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -205,6 +205,44 @@ static size_t sun6i_spi_max_transfer_size(struct spi_device *spi)
return SUN6I_MAX_XFER_SIZE - 1;
}
+static int sun6i_spi_prepare_message(struct spi_controller *ctlr,
+ struct spi_message *msg)
+{
+ struct sun6i_spi *sspi = spi_controller_get_devdata(ctlr);
+ struct spi_device *spi = msg->spi;
+ u32 reg;
+
+ /* Set the mode bits in the transfer control register */
+ reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
+
+ if (spi->mode & SPI_CPOL)
+ reg |= SUN6I_TFR_CTL_CPOL;
+ else
+ reg &= ~SUN6I_TFR_CTL_CPOL;
+
+ if (spi->mode & SPI_CPHA)
+ reg |= SUN6I_TFR_CTL_CPHA;
+ else
+ reg &= ~SUN6I_TFR_CTL_CPHA;
+
+ if (spi->mode & SPI_LSB_FIRST)
+ reg |= SUN6I_TFR_CTL_FBS;
+ else
+ reg &= ~SUN6I_TFR_CTL_FBS;
+
+ sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
+
+ /*
+ * Now that the clock polarity is configured, enable the bus if the
+ * controller was previously suspended.
+ */
+ reg = sun6i_spi_read(sspi, SUN6I_GBL_CTL_REG);
+ reg |= SUN6I_GBL_CTL_BUS_ENABLE;
+ sun6i_spi_write(sspi, SUN6I_GBL_CTL_REG, reg);
+
+ return 0;
+}
+
static void sun6i_spi_dma_rx_cb(void *param)
{
struct sun6i_spi *sspi = param;
@@ -336,31 +374,12 @@ static int sun6i_spi_transfer_one(struct spi_controller *host,
sun6i_spi_write(sspi, SUN6I_FIFO_CTL_REG, reg);
- /*
- * Setup the transfer control register: Chip Select,
- * polarities, etc.
- */
- reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
-
- if (spi->mode & SPI_CPOL)
- reg |= SUN6I_TFR_CTL_CPOL;
- else
- reg &= ~SUN6I_TFR_CTL_CPOL;
-
- if (spi->mode & SPI_CPHA)
- reg |= SUN6I_TFR_CTL_CPHA;
- else
- reg &= ~SUN6I_TFR_CTL_CPHA;
-
- if (spi->mode & SPI_LSB_FIRST)
- reg |= SUN6I_TFR_CTL_FBS;
- else
- reg &= ~SUN6I_TFR_CTL_FBS;
-
/*
* If it's a TX only transfer, we don't want to fill the RX
* FIFO with bogus data
*/
+ reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
+
if (sspi->rx_buf) {
reg &= ~SUN6I_TFR_CTL_DHB;
rx_len = tfr->len;
@@ -429,11 +448,6 @@ static int sun6i_spi_transfer_one(struct spi_controller *host,
sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
}
- /* Finally enable the bus - doing so before might raise SCK to HIGH */
- reg = sun6i_spi_read(sspi, SUN6I_GBL_CTL_REG);
- reg |= SUN6I_GBL_CTL_BUS_ENABLE;
- sun6i_spi_write(sspi, SUN6I_GBL_CTL_REG, reg);
-
/* Setup the transfer now... */
if (sspi->tx_buf) {
tx_len = tfr->len;
@@ -668,6 +682,7 @@ static int sun6i_spi_probe(struct platform_device *pdev)
host->max_speed_hz = 100 * 1000 * 1000;
host->min_speed_hz = 3 * 1000;
host->use_gpio_descriptors = true;
+ host->prepare_message = sun6i_spi_prepare_message;
host->set_cs = sun6i_spi_set_cs;
host->transfer_one = sun6i_spi_transfer_one;
host->num_chipselect = 4;
--
2.53.0
^ permalink raw reply related
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Linus Torvalds @ 2026-04-23 17:41 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Mathias Stearn, Peter Zijlstra, Mathieu Desnoyers,
Catalin Marinas, Will Deacon, Boqun Feng, Paul E. McKenney,
Chris Kennelly, Dmitry Vyukov, regressions, linux-kernel,
linux-arm-kernel, Ingo Molnar, Mark Rutland, Jinjie Ruan,
Blake Oler
In-Reply-To: <87cxzp1tn6.ffs@tglx>
On Thu, 23 Apr 2026 at 10:19, Thomas Gleixner <tglx@kernel.org> wrote:
>
> C) Declare that this is not a regression because the ABI guarantee is
> not violated and the RO property has been enforcable by RSEQ
> debugging since day one.
No, if this actually hits real users, that is not an option. If real
users never used RSEQ debugging options, those options are simply
irrelevant.
Regression rules have never been about "it wouldn't have worked in
some other configuration". That's like saying "that code would never
have worked on another architecture". It may be true, but it's
irrelevant for the people whose binaries no longer work.
We will have to fix this.
This is not some kind of gray area. It clearly violates our regression rules.
The only "ABI guarantee" is what people actually see and use, not some
debug option that wasn't enabled.
And I just checked - it's not enabled in at least the Fedora distro
kernels. Presumably other distros don't enable it either. So no actual
non-kernel developer would *ever* have hit it, and claiming it is
relevant is just garbage.
IOW, that debug option was always a complete no-op except for kernel developers.
In fact, that debug option is actively *hidden* - you have to enable
EXPERT to even see it. Soi it really is not a real option for normal
people AT ALL.
Christ, even *I* don't enable EXPERT except for build testing. It's
literally something that only embedded people doing odd things should
do.
If that rule was actually an important part of the ABI, it shouldn't
have been a debug thing.
So:
(a) the debug code in question needs to just be removed, since it's
now actively detrimental, and means that any kernel developer who
*does* enable it can't actually test this case any more. It's checking
for something that has been shown to not be true.
(b) we need to fix this (revert if it can't be fixed otherwise)
I see some patches flying around, but am not clear on whether there
was an actual patch that make this work again?
Linus
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
From: Conor Dooley @ 2026-04-23 17:44 UTC (permalink / raw)
To: Billy Tsai
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Linus Walleij, Bartosz Golaszewski,
Ryan Chen, Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <OSQPR06MB7252BD7967D2567AD6DA7A1D8B2F2@OSQPR06MB7252.apcprd06.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]
On Mon, Apr 20, 2026 at 07:22:57AM +0000, Billy Tsai wrote:
> In particular, I'll split the constraints as follows:
>
> - For pinmux, the presence of `function` will require `groups`, and
> `pins` will not be allowed. This reflects the hardware design, where
> the groups are defined by the pins affected by a given mux expression
>
> - For pin configuration, exactly one of `groups` or `pins` will be
> required (using oneOf), so that configuration is applied either at
> group level or per-pin, but not both.
>
>
> - if:
> required:
> - function
> then:
> required:
> - groups
> not:
> required:
> - pins
> else:
I think this is a separate section under an allOf, rather than an else.
You can also simplify the condition above to just be
- if:
required:
- function
then:
required:
- groups
since the node will then always be tested against what you have below
> oneOf:
> - required:
> - groups
> not:
> required:
> - pins
> - required:
> - pins
> not:
> required:
> - groups
I think this here simplifies to
oneOf:
- required:
- groups
- required:
- pins
You'd also need to note that pin level config settings should take
precedence over group level ones.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] spi: sun6i: Set SPI mode in prepare_message
From: Kevin Mehall @ 2026-04-23 17:46 UTC (permalink / raw)
To: Mark Brown
Cc: Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Mirko Vogt,
Ralf Schlatterbeck, linux-spi, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <f93e1bc6-608b-4c75-8b1a-80f701ff37ce@sirena.org.uk>
I tested with `spi-cs-setup-delay-ns = <1000000>;` and a hardware CS in the
device tree, and confirmed the suspected second bug: without this patch, the
first transfer after autosuspend ignores the setup delay.
> I do see that the driver uses a reset controller over suspend, are you
> sure that setup() will be called again on resume?
SUN6I_TFR_CTL_REG is indeed being reset after autosuspend because the above bug
reoccurs after a few seconds of inactivity. I am not sure if setup() is running on
resume because the datasheet reset value of SUN6I_TFR_CTL_CS_LEVEL is the same
as what would be written. Either way, it's moot if we set all CS-related bits in
the same register write.
I've moved the line that sets SUN6I_TFR_CTL_CS_MANUAL into sun6i_spi_set_cs()
rather than into sun6i_spi_prepare_message() as a separated commit in a new patch
series:
https://lore.kernel.org/linux-spi/20260423174001.2797797-1-km@kevinmehall.net/
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Mathieu Desnoyers @ 2026-04-23 17:47 UTC (permalink / raw)
To: Chris Kennelly, Thomas Gleixner
Cc: Mathias Stearn, Peter Zijlstra, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Dmitry Vyukov, regressions,
linux-kernel, linux-arm-kernel, Ingo Molnar, Mark Rutland,
Jinjie Ruan, Blake Oler, Linus Torvalds
In-Reply-To: <CAEE+yb=rZFxxOhCw+6wsUt5PE6=ebbKjEggQ_j_G3qSkMQZsfg@mail.gmail.com>
On 2026-04-23 13:38, Chris Kennelly wrote:
> On Thu, Apr 23, 2026 at 1:19 PM Thomas Gleixner <tglx@kernel.org> wrote:
[...]
>>
>> 3) The RO for userspace property has been enforced by RSEQ debugging
>> mode since day one. If such a debug enabled kernel detects user
>> space changing the field it kills the task/application.
>
> The optimization in TCMalloc that you're describing has been available
> since September 2023:
> https://github.com/google/tcmalloc/commit/aaa4fbf6fcdce1b7f86fcadd659874645c75ddb9
>
> I thought the RSEQ debug checks were added in December 2024:
> https://github.com/torvalds/linux/commit/7d5265ffcd8b41da5e09066360540d6e0716e9cd,
> but perhaps I misidentified the ones in question.
You are correct, I added the RSEQ field corruption validation under
debug config in Nov. 2024 when I noticed the world of pain we were
heading towards with incompatible tcmalloc vs glibc (and general) use
due to tcmalloc not respecting the ABI contract. RSEQ has been
upstreamed in 2018. So that's not exactly a day one enforcement.
The ABI contract was clear about this being an invalid use from
day one though.
[...]
>> 7) tcmalloc violates the ABI from day one and has since refused to
>> address the problem despite being offered a kernel side rseq
>> extension to solve it many years ago.
>
> I know there was some discussion around a preemption notification
> scheme, rseq_sched_state; but I thought the discussion moved in favor
> of the timeslice extension interface that recently landed. Timeslice
> extension solves some use cases, but I'm not sure it addresses this
> one.
I have actively engaged with the tcmalloc developers to
understand their needs and figure out a proper solution for the
past ~3-4 years, without success.
I have done a POC branch extending rseq with a "reset a linked list of
userspace areas on preemption" back in 2024 which would have solved
tcmalloc's issues cleanly. I never posted it publicly because the
tcmalloc devs told me they could not justify spending time even trying
this out to their managers.
I still have that feature branch gathering dust somewhere.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: remoteproc: xlnx: add auto boot feature
From: Shah, Tanmay @ 2026-04-23 17:59 UTC (permalink / raw)
To: Krzysztof Kozlowski, tanmay.shah
Cc: andersson, mathieu.poirier, robh, krzk+dt, conor+dt, michal.simek,
ben.levinsky, linux-remoteproc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <eac0f387-c38a-44eb-aed4-6c4022f01777@kernel.org>
On 4/23/2026 12:26 PM, Krzysztof Kozlowski wrote:
> On 23/04/2026 17:14, Shah, Tanmay wrote:
>> Hello,
>>
>> Thanks for reviews. Please see my comments below.
>>
>> On 4/23/2026 4:09 AM, Krzysztof Kozlowski wrote:
>>> On Wed, Apr 22, 2026 at 01:25:57PM -0700, Tanmay Shah wrote:
>>>> Add auto-boot property to notify that remote processor is setup and
>>>> ready to boot. Linux can attempt to boot or attach to already running
>>>> remote processor. "firmware-name" property is used to mention default
>>>> firmware to boot when linux starts the remote processor.
>>>>
>>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>>> ---
>>>> .../devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 8 ++++++++
>>>> 1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> index ee63c03949c9..0d27260e3baa 100644
>>>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> @@ -135,6 +135,14 @@ patternProperties:
>>>> - description: vring1
>>>> additionalItems: true
>>>>
>>>> + auto-boot:
>>>
>>> Last months, I have been asking AMD to follow writing-bindings doc or
>>> other DT guidelines way too many times.
>>>
>>> Or you just sent us downstream... Do you see anywhere such property?
>>> What properties do you see? How are they named?
>>>
>>
>> I should have put note about this. Current auto-boot properties are
>> named like st,auto-boot fsl,auto-boot etc. but nothing vendor specific
>> there. Can we have a common auto-boot property? Similar to
>> firmware-name? If we agree to it then what's the correct location? New
>> file remoteproc.yaml is okay?
>
> Common properties go to dtschema, so it would need to go there, but the
> point is that it's way too generic - every component with FW could be
> called "auto-boot". This should stay vendor property, IMO.
>
Ack, I will rename it to xlnx,auto-boot.
>>
>>>> + type: boolean
>>>> + description: remote core is either already running or ready to boot
>>>
>>> And why is this property of a board?
>>>
>>
>> Not sure what indicates it is? The property is under remoteproc child
>> device that is SOC level property. Remote core is on same SOC wher linux
>> core is running.
>
> So it is implied by SoC compatible? Please provide some arguments why it
> cannot be implied by the SoC compatible. I gave you one way out, but if
> you disagree then no problem.
>
So on some SoC, the bootloader supports loading and starting of the
remote processor. But it is totally user's choice. User can choose to
load & start one core of a cluster via bootloader and leave another core
powered-off.
That is why it is not possible to decide based on SoC compatible.
If we don't want to make it a device-tree property then I can implement
in a different way. New way will detect if the remote is running or not
via EMMI/SCMI call to the firmware, and take a decision based on that.
If this new way works, then I don't think we need auto-boot property at all.
Let me know your thoughts.
>>
>>>> +
>>>> + firmware-name:
>>>> + maxItems: 1
>>>> + description: default firmware to load
>>>
>>> Can you load non-default firmware later? IOW, why adding description
>>> here, what is special?
>>>
>>
>> The rootfs contains other firmware demos, and it is possible to stop the
>> default firmware, load other fw elf and re-run the remote core.
>> I don't have strong preference on the description part, I will remove it
>> if redundant.
>
> No, it's fine, I wanted to be sure that such use case makes sense.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Mimi Zohar @ 2026-04-23 18:01 UTC (permalink / raw)
To: Yeoreum Yun, Jonathan McDowell
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, roberto.sassu,
dmitry.kasatkin, eric.snowberg, jarkko, jgg, sudeep.holla, maz,
oupton, joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
will, noodles, sebastianene
In-Reply-To: <aeotq8nPVu4wvEx5@e129823.arm.com>
On Thu, 2026-04-23 at 15:33 +0100, Yeoreum Yun wrote:
> Hi Jonathan,
>
> > * # Be careful, this email looks suspicious; * Out of Character: The sender is exhibiting a significant deviation from their usual behavior, this may indicate that their account has been compromised. Be extra cautious before opening links or attachments. *
> > On Thu, Apr 23, 2026 at 02:55:14PM +0100, Yeoreum Yun wrote:
> > > > On Thu, 2026-04-23 at 13:53 +0100, Jonathan McDowell wrote:
> > > > > On Thu, Apr 23, 2026 at 01:34:13PM +0100, Yeoreum Yun wrote:
> > > > > > > > On Thu, 2026-04-23 at 06:55 +0100, Yeoreum Yun wrote:
> > > > > > > > > > On Wed, 2026-04-22 at 20:41 +0100, Yeoreum Yun wrote:
> > > > > > > > > > > > Hi Mimi,
> > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, 2026-04-22 at 17:24 +0100, Yeoreum Yun wrote:
> > > > > > > > > > > > > > To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
> > > > > > > > > > > > > > the TPM driver must be built as built-in and
> > > > > > > > > > > > > > must be probed before the IMA subsystem is initialized.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > However, when the TPM device operates over the FF-A protocol using
> > > > > > > > > > > > > > the CRB interface, probing fails and returns -EPROBE_DEFER if
> > > > > > > > > > > > > > the tpm_crb_ffa device — an FF-A device that provides the communication
> > > > > > > > > > > > > > interface to the tpm_crb driver — has not yet been probed.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To ensure the TPM device operating over the FF-A protocol with
> > > > > > > > > > > > > > the CRB interface is probed before IMA initialization,
> > > > > > > > > > > > > > the following conditions must be met:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 1. The corresponding ffa_device must be registered,
> > > > > > > > > > > > > > which is done via ffa_init().
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 2. The tpm_crb_driver must successfully probe this device via
> > > > > > > > > > > > > > tpm_crb_ffa_init().
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 3. The tpm_crb driver using CRB over FF-A can then
> > > > > > > > > > > > > > be probed successfully. (See crb_acpi_add() and
> > > > > > > > > > > > > > tpm_crb_ffa_init() for reference.)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > > > > > > > > > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > > > > > > > > > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > When this occurs, probing the TPM device is deferred.
> > > > > > > > > > > > > > However, the deferred probe can happen after the IMA subsystem
> > > > > > > > > > > > > > has already been initialized, since IMA initialization is performed
> > > > > > > > > > > > > > during late_initcall, and deferred_probe_initcall() is performed
> > > > > > > > > > > > > > at the same level.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > To resolve this, call ima_init() again at late_inicall_sync level
> > > > > > > > > > > > > > so that let IMA not miss TPM PCR value when generating boot_aggregate
> > > > > > > > > > > > > > log though TPM device presents in the system.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > > > > > > > > > >
> > > > > > > > > > > > > A lot of change for just detecting whether ima_init() is being called on
> > > > > > > > > > > > > late_initcall or late_initcall_sync(), without any explanation for all the other
> > > > > > > > > > > > > changes (e.g. ima_init_core).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Please just limit the change to just calling ima_init() twice.
> > > > > > > > > > > >
> > > > > > > > > > > > My concern is that ima_update_policy_flags() will be called
> > > > > > > > > > > > when ima_init() is deferred -- not initialised anything.
> > > > > > > > > > > > though functionally, it might be okay however,
> > > > > > > > > > > > I think ima_update_policy_flags() and notifier should work after ima_init()
> > > > > > > > > > > > works logically.
> > > > > > > > > > > >
> > > > > > > > > > > > This change I think not much quite a lot. just wrapper ima_init() with
> > > > > > > > > > > > ima_init_core() with some error handling.
> > > > > > > > > > > >
> > > > > > > > > > > > Am I missing something?
> > > > > > > > > > >
> > > > > > > > > > > Also, if we handle in ima_init() only, but it failed with other reason,
> > > > > > > > > > > we shouldn't call again ima_init() in the late_initcall_sync.
> > > > > > > > > > >
> > > > > > > > > > > To handle this, It wouldn't do in the ima_init() but we need to handle
> > > > > > > > > > > it by caller of ima_init().
> > > > > > > > > >
> > > > > > > > > > Only tpm_default_chip() is being called to set the ima_tpm_chip. On failure,
> > > > > > > > > > instead of going into TPM-bypass mode, return immediately. There are no calls
> > > > > > > > > > to anything else. Just call ima_init() a second time.
> > > > > > > > >
> > > > > > > > > I’m not fully convinced this is sufficient.
> > > > > > > > >
> > > > > > > > > What I meant is the case where ima_init() fails due to other
> > > > > > > > > initialisation steps, not only tpm_default_chip() (e.g. ima_fs_init()).
> > > > > > > >
> > > > > > > > The purpose of THIS patch is to add late_initcall_sync, when the TPM is not
> > > > > > > > available at late_initcall. This would be classified as a bug fix and would be
> > > > > > > > backported. No other changes should be included in this patch.
> > > > > > >
> > > > > > > Okay.
> > > > > > >
> > > > > > > > >
> > > > > > > > > I’d also like to ask again whether it is fine to call
> > > > > > > > > ima_update_policy_flags() and keep the notifier registered in the
> > > > > > > > > deferred TPM case. While this may be functionally acceptable, it seems
> > > > > > > > > logically questionable to do so when ima_init() has not completed.
> > > > > > > >
> > > > > > > > Other than extending the TPM, IMA should behave exactly the same whether there
> > > > > > > > is a TPM or goes into TPM-bypass mode.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > There is also a possibility that a deferred case ultimately fails (e.g.
> > > > > > > > > deferred at late_initcall, but then failing at late_initcall_sync
> > > > > > > > > for another reason, even while entering TPM bypass mode). In that case,
> > > > > > > > > it seems more appropriate to handle this state in the caller of
> > > > > > > > > ima_init(), rather than inside ima_init() itself.
> > > > > > > >
> > > > > > > > If the TPM isn't found at late_initcall_sync(), then IMA should go into TPM-
> > > > > > > > bypass mode. Please don't make any other changes to the existing IMA behavior
> > > > > > > > and hide it here behind the late_initcall_sync change.
> > > > > > >
> > > > > > > Okay. you're talking called ima_update_policy_flags() at late_initcall
> > > > > > > wouldn't be not a problem even in case of late_initcall_sync's ima_init()
> > > > > > > get failed with "TPM-bypass mode".
> > > > > > >
> > > > > > > I see then, I'll make a patch simpler then.
> > > > > >
> > > > > > But I think in case of below situation:
> > > > > > - late_initcall's first ima_init() is deferred.
> > > > > > - late_initcall_sync try again but failed and try again with
> > > > > > CONFIG_IMA_DEFAULT_HASH.
> > > > > >
> > > > > > I would like to sustain init_ima_core to reduce the same code repeat
> > > > > > in late_initcall_sync.
> > > > >
> > > > > I think what Mimi's proposing is:
> > > > >
> > > > > If we're in late_initcall, and the TPM isn't available, return
> > > > > immediately with an error (the EPROBE_DEFER?), don't do any init.
> > > > >
> > > > > If we're in late_initcall_sync, either we're already initialised, so do
> > > > > return and nothing, or run through the entire flow, even if the TPM
> > > > > isn't unavailable.
> > > > >
> > > > > So ima_init() just needs to know a) if it's in the sync or non-sync mode
> > > > > and b) for the sync mode, if we've already done the init at
> > > > > non-sync.
> > > >
> > > > Thanks, Jonathan. That is exactly what I'm suggesting. Any other changes
> > > > should not be included in this patch. Since Yeoreum is not hearing me, feel
> > > > free to post a patch.
> > >
> > > I see. so what you need to is this only
> > > If it looks good to you. I'll send it at v3.
> >
> > FWIW, I pulled the tpm_default_chip check out a level to account for the
> > extra init you mentioned, and have the following (completely untested or
> > compiled, but gives the approach):
> >
> > diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> > index d48bf0ad26f4..88fe105b7f00 100644
> > --- a/include/linux/lsm_hooks.h
> > +++ b/include/linux/lsm_hooks.h
> > @@ -166,6 +166,7 @@ enum lsm_order {
> > * @initcall_fs: LSM callback for fs_initcall setup, optional
> > * @initcall_device: LSM callback for device_initcall() setup, optional
> > * @initcall_late: LSM callback for late_initcall() setup, optional
> > + * @initcall_late_sync: LSM callback for late_initcall_sync() setup, optional
> > */
> > struct lsm_info {
> > const struct lsm_id *id;
> > @@ -181,6 +182,7 @@ struct lsm_info {
> > int (*initcall_fs)(void);
> > int (*initcall_device)(void);
> > int (*initcall_late)(void);
> > + int (*initcall_late_sync)(void);
> > };
> > #define DEFINE_LSM(lsm) \
> > diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c
> > index a2f34f2d8ad7..a60dfb8316d8 100644
> > --- a/security/integrity/ima/ima_init.c
> > +++ b/security/integrity/ima/ima_init.c
> > @@ -119,10 +119,6 @@ int __init ima_init(void)
> > {
> > int rc;
> > - ima_tpm_chip = tpm_default_chip();
> > - if (!ima_tpm_chip)
> > - pr_info("No TPM chip found, activating TPM-bypass!\n");
> > -
> > rc = integrity_init_keyring(INTEGRITY_KEYRING_IMA);
> > if (rc)
> > return rc;
> > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> > index 1d6229b156fb..b60a85fa803a 100644
> > --- a/security/integrity/ima/ima_main.c
> > +++ b/security/integrity/ima/ima_main.c
> > @@ -1237,7 +1237,7 @@ static int ima_kernel_module_request(char *kmod_name)
> > #endif /* CONFIG_INTEGRITY_ASYMMETRIC_KEYS */
> > -static int __init init_ima(void)
> > +static int __init init_ima(bool sync)
> > {
> > int error;
> > @@ -1247,6 +1247,19 @@ static int __init init_ima(void)
> > return 0;
> > }
> > + /* If we found the TPM during our first attempt, nothing further to do */
> > + if (sync && ima_tpm_chip)
> > + return 0;
> > +
> > + ima_tpm_chip = tpm_default_chip();
> > + if (!ima_tpm_chip && !sync) {
> > + pr_debug("TPM not available, will try later\n");
> > + return -EPROBE_DEFER;
> > + }
> > +
> > + if (!ima_tpm_chip)
> > + pr_info("No TPM chip found, activating TPM-bypass!\n");
> > +
> > ima_appraise_parse_cmdline();
> > ima_init_template_list();
> > hash_setup(CONFIG_IMA_DEFAULT_HASH);
> > @@ -1274,6 +1287,16 @@ static int __init init_ima(void)
> > return error;
> > }
> > +static int __init init_ima_late(void)
> > +{
> > + return init_ima(false);
> > +}
> > +
> > +static int __init init_ima_late_sync(void)
> > +{
> > + return init_ima(true);
> > +}
> > +
> > static struct security_hook_list ima_hooks[] __ro_after_init = {
> > LSM_HOOK_INIT(bprm_check_security, ima_bprm_check),
> > LSM_HOOK_INIT(bprm_creds_for_exec, ima_bprm_creds_for_exec),
> > @@ -1319,6 +1342,7 @@ DEFINE_LSM(ima) = {
> > .init = init_ima_lsm,
> > .order = LSM_ORDER_LAST,
> > .blobs = &ima_blob_sizes,
> > - /* Start IMA after the TPM is available */
> > - .initcall_late = init_ima,
> > + /* Ensure we start IMA after the TPM is available */
> > + .initcall_late = init_ima_late,
> > + .initcall_late_sync = init_ima_late_sync,
> > };
> > diff --git a/security/lsm_init.c b/security/lsm_init.c
> > index 573e2a7250c4..4e5c59beb82a 100644
> > --- a/security/lsm_init.c
> > +++ b/security/lsm_init.c
> > @@ -547,13 +547,22 @@ device_initcall(security_initcall_device);
> > * security_initcall_late - Run the LSM late initcalls
> > */
> > static int __init security_initcall_late(void)
> > +{
> > + return lsm_initcall(late);
> > +}
> > +late_initcall(security_initcall_late);
> > +
> > +/**
> > + * security_initcall_late_sync - Run the LSM late initcalls sync
> > + */
> > +static int __init security_initcall_late_sync(void)
> > {
> > int rc;
> > - rc = lsm_initcall(late);
> > + rc = lsm_initcall(late_sync);
> > lsm_pr_dbg("all enabled LSMs fully activated\n");
> > call_blocking_lsm_notifier(LSM_STARTED_ALL, NULL);
> > return rc;
> > }
> > -late_initcall(security_initcall_late);
> > +late_initcall_sync(security_initcall_late_sync);
>
> I'm fine this. but are we talking about "ima_init()" not "init_ima()"?
Having two functions named ima_init() and init_ima() is really confusing. At
least with this patch, init_ima() will be replaced with init_ima_late() and
init_ima_sync().
> Because of this, I've fixuated and make a long stupid speaking myself.
The commit 0e0546eabcd6 ("firmware: arm_ffa: Change initcall level of ffa_init()
to rootfs_initcall") patch description was really well written. I'm really sad
that it needs to be reverted.
The TPM not being initialized before IMA, has been an issue for a really long
time. Hopefully this patch will safely fix it, not only for you, but for others
as well.
>
> If this seems good to Mimi, I don't care who send it.
> But If you're going to send this, could you includes 2 and 3 too?
Once this patch is ready, we can create a topic branch to coordinate upstreaming
the remaining patches.
thanks!
Mimi
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Yeoreum Yun @ 2026-04-23 18:13 UTC (permalink / raw)
To: Mimi Zohar
Cc: Jonathan McDowell, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm, paul, jmorris, serge,
roberto.sassu, dmitry.kasatkin, eric.snowberg, jarkko, jgg,
sudeep.holla, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, noodles, sebastianene
In-Reply-To: <e4e242ae5533d5762a3647186a178764881bf9ff.camel@linux.ibm.com>
> On Thu, 2026-04-23 at 15:33 +0100, Yeoreum Yun wrote:
> > Hi Jonathan,
> >
> > > * # Be careful, this email looks suspicious; * Out of Character: The sender is exhibiting a significant deviation from their usual behavior, this may indicate that their account has been compromised. Be extra cautious before opening links or attachments. *
> > > On Thu, Apr 23, 2026 at 02:55:14PM +0100, Yeoreum Yun wrote:
> > > > > On Thu, 2026-04-23 at 13:53 +0100, Jonathan McDowell wrote:
> > > > > > On Thu, Apr 23, 2026 at 01:34:13PM +0100, Yeoreum Yun wrote:
> > > > > > > > > On Thu, 2026-04-23 at 06:55 +0100, Yeoreum Yun wrote:
> > > > > > > > > > > On Wed, 2026-04-22 at 20:41 +0100, Yeoreum Yun wrote:
> > > > > > > > > > > > > Hi Mimi,
> > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, 2026-04-22 at 17:24 +0100, Yeoreum Yun wrote:
> > > > > > > > > > > > > > > To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
> > > > > > > > > > > > > > > the TPM driver must be built as built-in and
> > > > > > > > > > > > > > > must be probed before the IMA subsystem is initialized.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > However, when the TPM device operates over the FF-A protocol using
> > > > > > > > > > > > > > > the CRB interface, probing fails and returns -EPROBE_DEFER if
> > > > > > > > > > > > > > > the tpm_crb_ffa device — an FF-A device that provides the communication
> > > > > > > > > > > > > > > interface to the tpm_crb driver — has not yet been probed.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To ensure the TPM device operating over the FF-A protocol with
> > > > > > > > > > > > > > > the CRB interface is probed before IMA initialization,
> > > > > > > > > > > > > > > the following conditions must be met:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 1. The corresponding ffa_device must be registered,
> > > > > > > > > > > > > > > which is done via ffa_init().
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 2. The tpm_crb_driver must successfully probe this device via
> > > > > > > > > > > > > > > tpm_crb_ffa_init().
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 3. The tpm_crb driver using CRB over FF-A can then
> > > > > > > > > > > > > > > be probed successfully. (See crb_acpi_add() and
> > > > > > > > > > > > > > > tpm_crb_ffa_init() for reference.)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > > > > > > > > > > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > > > > > > > > > > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > When this occurs, probing the TPM device is deferred.
> > > > > > > > > > > > > > > However, the deferred probe can happen after the IMA subsystem
> > > > > > > > > > > > > > > has already been initialized, since IMA initialization is performed
> > > > > > > > > > > > > > > during late_initcall, and deferred_probe_initcall() is performed
> > > > > > > > > > > > > > > at the same level.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > To resolve this, call ima_init() again at late_inicall_sync level
> > > > > > > > > > > > > > > so that let IMA not miss TPM PCR value when generating boot_aggregate
> > > > > > > > > > > > > > > log though TPM device presents in the system.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > A lot of change for just detecting whether ima_init() is being called on
> > > > > > > > > > > > > > late_initcall or late_initcall_sync(), without any explanation for all the other
> > > > > > > > > > > > > > changes (e.g. ima_init_core).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Please just limit the change to just calling ima_init() twice.
> > > > > > > > > > > > >
> > > > > > > > > > > > > My concern is that ima_update_policy_flags() will be called
> > > > > > > > > > > > > when ima_init() is deferred -- not initialised anything.
> > > > > > > > > > > > > though functionally, it might be okay however,
> > > > > > > > > > > > > I think ima_update_policy_flags() and notifier should work after ima_init()
> > > > > > > > > > > > > works logically.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This change I think not much quite a lot. just wrapper ima_init() with
> > > > > > > > > > > > > ima_init_core() with some error handling.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Am I missing something?
> > > > > > > > > > > >
> > > > > > > > > > > > Also, if we handle in ima_init() only, but it failed with other reason,
> > > > > > > > > > > > we shouldn't call again ima_init() in the late_initcall_sync.
> > > > > > > > > > > >
> > > > > > > > > > > > To handle this, It wouldn't do in the ima_init() but we need to handle
> > > > > > > > > > > > it by caller of ima_init().
> > > > > > > > > > >
> > > > > > > > > > > Only tpm_default_chip() is being called to set the ima_tpm_chip. On failure,
> > > > > > > > > > > instead of going into TPM-bypass mode, return immediately. There are no calls
> > > > > > > > > > > to anything else. Just call ima_init() a second time.
> > > > > > > > > >
> > > > > > > > > > I’m not fully convinced this is sufficient.
> > > > > > > > > >
> > > > > > > > > > What I meant is the case where ima_init() fails due to other
> > > > > > > > > > initialisation steps, not only tpm_default_chip() (e.g. ima_fs_init()).
> > > > > > > > >
> > > > > > > > > The purpose of THIS patch is to add late_initcall_sync, when the TPM is not
> > > > > > > > > available at late_initcall. This would be classified as a bug fix and would be
> > > > > > > > > backported. No other changes should be included in this patch.
> > > > > > > >
> > > > > > > > Okay.
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I’d also like to ask again whether it is fine to call
> > > > > > > > > > ima_update_policy_flags() and keep the notifier registered in the
> > > > > > > > > > deferred TPM case. While this may be functionally acceptable, it seems
> > > > > > > > > > logically questionable to do so when ima_init() has not completed.
> > > > > > > > >
> > > > > > > > > Other than extending the TPM, IMA should behave exactly the same whether there
> > > > > > > > > is a TPM or goes into TPM-bypass mode.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > There is also a possibility that a deferred case ultimately fails (e.g.
> > > > > > > > > > deferred at late_initcall, but then failing at late_initcall_sync
> > > > > > > > > > for another reason, even while entering TPM bypass mode). In that case,
> > > > > > > > > > it seems more appropriate to handle this state in the caller of
> > > > > > > > > > ima_init(), rather than inside ima_init() itself.
> > > > > > > > >
> > > > > > > > > If the TPM isn't found at late_initcall_sync(), then IMA should go into TPM-
> > > > > > > > > bypass mode. Please don't make any other changes to the existing IMA behavior
> > > > > > > > > and hide it here behind the late_initcall_sync change.
> > > > > > > >
> > > > > > > > Okay. you're talking called ima_update_policy_flags() at late_initcall
> > > > > > > > wouldn't be not a problem even in case of late_initcall_sync's ima_init()
> > > > > > > > get failed with "TPM-bypass mode".
> > > > > > > >
> > > > > > > > I see then, I'll make a patch simpler then.
> > > > > > >
> > > > > > > But I think in case of below situation:
> > > > > > > - late_initcall's first ima_init() is deferred.
> > > > > > > - late_initcall_sync try again but failed and try again with
> > > > > > > CONFIG_IMA_DEFAULT_HASH.
> > > > > > >
> > > > > > > I would like to sustain init_ima_core to reduce the same code repeat
> > > > > > > in late_initcall_sync.
> > > > > >
> > > > > > I think what Mimi's proposing is:
> > > > > >
> > > > > > If we're in late_initcall, and the TPM isn't available, return
> > > > > > immediately with an error (the EPROBE_DEFER?), don't do any init.
> > > > > >
> > > > > > If we're in late_initcall_sync, either we're already initialised, so do
> > > > > > return and nothing, or run through the entire flow, even if the TPM
> > > > > > isn't unavailable.
> > > > > >
> > > > > > So ima_init() just needs to know a) if it's in the sync or non-sync mode
> > > > > > and b) for the sync mode, if we've already done the init at
> > > > > > non-sync.
> > > > >
> > > > > Thanks, Jonathan. That is exactly what I'm suggesting. Any other changes
> > > > > should not be included in this patch. Since Yeoreum is not hearing me, feel
> > > > > free to post a patch.
> > > >
> > > > I see. so what you need to is this only
> > > > If it looks good to you. I'll send it at v3.
> > >
> > > FWIW, I pulled the tpm_default_chip check out a level to account for the
> > > extra init you mentioned, and have the following (completely untested or
> > > compiled, but gives the approach):
> > >
> > > diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> > > index d48bf0ad26f4..88fe105b7f00 100644
> > > --- a/include/linux/lsm_hooks.h
> > > +++ b/include/linux/lsm_hooks.h
> > > @@ -166,6 +166,7 @@ enum lsm_order {
> > > * @initcall_fs: LSM callback for fs_initcall setup, optional
> > > * @initcall_device: LSM callback for device_initcall() setup, optional
> > > * @initcall_late: LSM callback for late_initcall() setup, optional
> > > + * @initcall_late_sync: LSM callback for late_initcall_sync() setup, optional
> > > */
> > > struct lsm_info {
> > > const struct lsm_id *id;
> > > @@ -181,6 +182,7 @@ struct lsm_info {
> > > int (*initcall_fs)(void);
> > > int (*initcall_device)(void);
> > > int (*initcall_late)(void);
> > > + int (*initcall_late_sync)(void);
> > > };
> > > #define DEFINE_LSM(lsm) \
> > > diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c
> > > index a2f34f2d8ad7..a60dfb8316d8 100644
> > > --- a/security/integrity/ima/ima_init.c
> > > +++ b/security/integrity/ima/ima_init.c
> > > @@ -119,10 +119,6 @@ int __init ima_init(void)
> > > {
> > > int rc;
> > > - ima_tpm_chip = tpm_default_chip();
> > > - if (!ima_tpm_chip)
> > > - pr_info("No TPM chip found, activating TPM-bypass!\n");
> > > -
> > > rc = integrity_init_keyring(INTEGRITY_KEYRING_IMA);
> > > if (rc)
> > > return rc;
> > > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> > > index 1d6229b156fb..b60a85fa803a 100644
> > > --- a/security/integrity/ima/ima_main.c
> > > +++ b/security/integrity/ima/ima_main.c
> > > @@ -1237,7 +1237,7 @@ static int ima_kernel_module_request(char *kmod_name)
> > > #endif /* CONFIG_INTEGRITY_ASYMMETRIC_KEYS */
> > > -static int __init init_ima(void)
> > > +static int __init init_ima(bool sync)
> > > {
> > > int error;
> > > @@ -1247,6 +1247,19 @@ static int __init init_ima(void)
> > > return 0;
> > > }
> > > + /* If we found the TPM during our first attempt, nothing further to do */
> > > + if (sync && ima_tpm_chip)
> > > + return 0;
> > > +
> > > + ima_tpm_chip = tpm_default_chip();
> > > + if (!ima_tpm_chip && !sync) {
> > > + pr_debug("TPM not available, will try later\n");
> > > + return -EPROBE_DEFER;
> > > + }
> > > +
> > > + if (!ima_tpm_chip)
> > > + pr_info("No TPM chip found, activating TPM-bypass!\n");
> > > +
> > > ima_appraise_parse_cmdline();
> > > ima_init_template_list();
> > > hash_setup(CONFIG_IMA_DEFAULT_HASH);
> > > @@ -1274,6 +1287,16 @@ static int __init init_ima(void)
> > > return error;
> > > }
> > > +static int __init init_ima_late(void)
> > > +{
> > > + return init_ima(false);
> > > +}
> > > +
> > > +static int __init init_ima_late_sync(void)
> > > +{
> > > + return init_ima(true);
> > > +}
> > > +
> > > static struct security_hook_list ima_hooks[] __ro_after_init = {
> > > LSM_HOOK_INIT(bprm_check_security, ima_bprm_check),
> > > LSM_HOOK_INIT(bprm_creds_for_exec, ima_bprm_creds_for_exec),
> > > @@ -1319,6 +1342,7 @@ DEFINE_LSM(ima) = {
> > > .init = init_ima_lsm,
> > > .order = LSM_ORDER_LAST,
> > > .blobs = &ima_blob_sizes,
> > > - /* Start IMA after the TPM is available */
> > > - .initcall_late = init_ima,
> > > + /* Ensure we start IMA after the TPM is available */
> > > + .initcall_late = init_ima_late,
> > > + .initcall_late_sync = init_ima_late_sync,
> > > };
> > > diff --git a/security/lsm_init.c b/security/lsm_init.c
> > > index 573e2a7250c4..4e5c59beb82a 100644
> > > --- a/security/lsm_init.c
> > > +++ b/security/lsm_init.c
> > > @@ -547,13 +547,22 @@ device_initcall(security_initcall_device);
> > > * security_initcall_late - Run the LSM late initcalls
> > > */
> > > static int __init security_initcall_late(void)
> > > +{
> > > + return lsm_initcall(late);
> > > +}
> > > +late_initcall(security_initcall_late);
> > > +
> > > +/**
> > > + * security_initcall_late_sync - Run the LSM late initcalls sync
> > > + */
> > > +static int __init security_initcall_late_sync(void)
> > > {
> > > int rc;
> > > - rc = lsm_initcall(late);
> > > + rc = lsm_initcall(late_sync);
> > > lsm_pr_dbg("all enabled LSMs fully activated\n");
> > > call_blocking_lsm_notifier(LSM_STARTED_ALL, NULL);
> > > return rc;
> > > }
> > > -late_initcall(security_initcall_late);
> > > +late_initcall_sync(security_initcall_late_sync);
> >
> > I'm fine this. but are we talking about "ima_init()" not "init_ima()"?
>
> Having two functions named ima_init() and init_ima() is really confusing. At
> least with this patch, init_ima() will be replaced with init_ima_late() and
> init_ima_sync().
>
> > Because of this, I've fixuated and make a long stupid speaking myself.
>
> The commit 0e0546eabcd6 ("firmware: arm_ffa: Change initcall level of ffa_init()
> to rootfs_initcall") patch description was really well written. I'm really sad
> that it needs to be reverted.
>
> The TPM not being initialized before IMA, has been an issue for a really long
> time. Hopefully this patch will safely fix it, not only for you, but for others
> as well.
>
> >
> > If this seems good to Mimi, I don't care who send it.
> > But If you're going to send this, could you includes 2 and 3 too?
>
> Once this patch is ready, we can create a topic branch to coordinate upstreaming
> the remaining patches.
Sounds good. Once the patch is posted, I’ll review it as well.
Sorry again for the noise, and thanks for your patience ;)
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* [PATCH] iio: fix header includes across multiple drivers
From: Caio Morais @ 2026-04-23 18:33 UTC (permalink / raw)
To: jic23, dlechner, nuno.sa, andy, michal.simek
Cc: Caio Morais, linux-iio, linux-arm-kernel
From: Caio Morais <caiomorais@usp.br>
Remove unnecessary includes and add missing ones as reported by the
include-what-you-use (IWYU) tool.
Files changed:
- drivers/iio/adc/xilinx-xadc-events.c
- drivers/iio/buffer/industrialio-triggered-buffer.c
- drivers/iio/common/st_sensors/st_sensors_i2c.c
- drivers/iio/common/st_sensors/st_sensors_spi.c
Signed-off-by: Caio Morais <caiomorais@usp.br>
---
drivers/iio/adc/xilinx-xadc-events.c | 4 ++--
drivers/iio/buffer/industrialio-triggered-buffer.c | 8 ++++----
drivers/iio/common/st_sensors/st_sensors_i2c.c | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/iio/adc/xilinx-xadc-events.c b/drivers/iio/adc/xilinx-xadc-events.c
index d16e61953..20b796ec7 100644
--- a/drivers/iio/adc/xilinx-xadc-events.c
+++ b/drivers/iio/adc/xilinx-xadc-events.c
@@ -7,11 +7,11 @@
*/
#include <linux/bitmap.h>
-#include <linux/types.h>
#include <linux/errno.h>
-#include <linux/mutex.h>
#include <linux/iio/events.h>
#include <linux/iio/iio.h>
+#include <linux/mutex.h>
+#include <linux/types.h>
#include "xilinx-xadc.h"
diff --git a/drivers/iio/buffer/industrialio-triggered-buffer.c b/drivers/iio/buffer/industrialio-triggered-buffer.c
index 601a26398..5796c9da7 100644
--- a/drivers/iio/buffer/industrialio-triggered-buffer.c
+++ b/drivers/iio/buffer/industrialio-triggered-buffer.c
@@ -5,15 +5,15 @@
*/
#include <linux/errno.h>
-#include <linux/linkage.h>
-#include <linux/module.h>
-#include <linux/stddef.h>
-#include <linux/iio/iio.h>
#include <linux/iio/buffer.h>
#include <linux/iio/buffer_impl.h>
+#include <linux/iio/iio.h>
#include <linux/iio/kfifo_buf.h>
#include <linux/iio/triggered_buffer.h>
#include <linux/iio/trigger_consumer.h>
+#include <linux/linkage.h>
+#include <linux/module.h>
+#include <linux/stddef.h>
/**
* iio_triggered_buffer_setup_ext() - Setup triggered buffer and pollfunc
diff --git a/drivers/iio/common/st_sensors/st_sensors_i2c.c b/drivers/iio/common/st_sensors/st_sensors_i2c.c
index 6ab143498..974e349ae 100644
--- a/drivers/iio/common/st_sensors/st_sensors_i2c.c
+++ b/drivers/iio/common/st_sensors/st_sensors_i2c.c
@@ -10,10 +10,10 @@
#include <linux/device.h>
#include <linux/err.h>
#include <linux/i2c.h>
+#include <linux/iio/iio.h>
#include <linux/linkage.h>
#include <linux/module.h>
#include <linux/regmap.h>
-#include <linux/iio/iio.h>
#include <linux/iio/common/st_sensors_i2c.h>
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 00/19] KVM: selftests: Use kernel-style integer and g[vp]a_t types
From: Sean Christopherson @ 2026-04-23 18:34 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini, Marc Zyngier, Oliver Upton,
Tianrui Zhao, Bibo Mao, Huacai Chen, Anup Patel, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Christian Borntraeger, Janosch Frank,
Claudio Imbrenda
Cc: kvm, linux-arm-kernel, kvmarm, loongarch, kvm-riscv, linux-riscv,
linux-kernel, David Matlack
In-Reply-To: <20260420212004.3938325-1-seanjc@google.com>
On Mon, 20 Apr 2026 14:19:45 -0700, Sean Christopherson wrote:
> David's series to renames types across all KVM selftests. I'm going to apply
> this ~now in order to get it into -next ASAP. Unless someone screams in the
> next few days, I'm going to send a pull request on Thursday, with the goal of
> getting this into -rc1 so that all architectures (and developers) can use the
> new types straightaway.
>
> Fully tested on x86, and I verified a handful of tests generate identical
> code. I tried to do the same for other architectures, but gcc at least doesn't
> seem to provide reproducible builds for other architectures. E.g. on arm64 and
> LoongArch, a completely benign vaddr_t => gva_t rename would sometimes result
> in different offsets in the generated code. But based on manual diffs from
> objdump, I'm fairly confident in the result.
>
> [...]
Applied to kvm-x86 selftests_kernel_types (a few days ago, spaced on sending
"thanks").
[01/19] KVM: selftests: Use gva_t instead of vm_vaddr_t
https://github.com/kvm-x86/linux/commit/5567fc9dcd7e
[02/19] KVM: selftests: Use gpa_t instead of vm_paddr_t
https://github.com/kvm-x86/linux/commit/97dcda3fdce5
[03/19] KVM: selftests: Use gpa_t for GPAs in Hyper-V selftests
https://github.com/kvm-x86/linux/commit/6d3494255ac0
[04/19] KVM: selftests: Use u64 instead of uint64_t
https://github.com/kvm-x86/linux/commit/26f8453288d4
[05/19] KVM: selftests: Use s64 instead of int64_t
https://github.com/kvm-x86/linux/commit/286e8903aed1
[06/19] KVM: selftests: Use u32 instead of uint32_t
https://github.com/kvm-x86/linux/commit/0c3a8774692a
[07/19] KVM: selftests: Use s32 instead of int32_t
https://github.com/kvm-x86/linux/commit/7b609187684d
[08/19] KVM: selftests: Use u16 instead of uint16_t
https://github.com/kvm-x86/linux/commit/19d091492004
[09/19] KVM: selftests: Use s16 instead of int16_t
https://github.com/kvm-x86/linux/commit/2540ebd60349
[10/19] KVM: selftests: Use u8 instead of uint8_t
https://github.com/kvm-x86/linux/commit/6ec982b5a2c7
[11/19] KVM: selftests: Drop "vaddr_" from APIs that allocate memory for a given VM
https://github.com/kvm-x86/linux/commit/85819fa0e3b9
[12/19] KVM: selftests: Rename vm_vaddr_unused_gap() => vm_unused_gva_gap()
https://github.com/kvm-x86/linux/commit/48321f609a73
[13/19] KVM: selftests: Rename vm_vaddr_populate_bitmap() => vm_populate_gva_bitmap()
https://github.com/kvm-x86/linux/commit/3fd995905b71
[14/19] KVM: selftests: Rename translate_to_host_paddr() => translate_hva_to_hpa()
https://github.com/kvm-x86/linux/commit/4babae4ca10a
[15/19] KVM: selftests: Clarify that arm64's inject_uer() takes a host PA, not a guest PA
https://github.com/kvm-x86/linux/commit/a662c4e03853
[16/19] KVM: selftests: Replace "vaddr" with "gva" throughout
https://github.com/kvm-x86/linux/commit/014dfb7b9bf3
[17/19] KVM: selftests: Replace "u64 gpa" with "gpa_t" throughout
https://github.com/kvm-x86/linux/commit/df079910f981
[18/19] KVM: selftests: Replace "u64 nested_paddr" with "gpa_t l2_gpa"
https://github.com/kvm-x86/linux/commit/abc374191dc2
[19/19] KVM: selftests: Replace "paddr" with "gpa" throughout
https://github.com/kvm-x86/linux/commit/dfd2a8b07c6c
--
https://github.com/kvm-x86/linux/tree/next
^ permalink raw reply
* Re: [PATCH v10 14/30] KVM: arm64: Implement SME vector length configuration
From: Mark Brown @ 2026-04-23 18:34 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: Marc Zyngier, Joey Gouly, Catalin Marinas, Suzuki K Poulose,
Will Deacon, Paolo Bonzini, Jonathan Corbet, Shuah Khan,
Oliver Upton, Dave Martin, Fuad Tabba, Mark Rutland, Ben Horgan,
linux-arm-kernel, kvmarm, linux-kernel, kvm, linux-doc,
linux-kselftest, Peter Maydell, Eric Auger
In-Reply-To: <20260318175317.GL2390801@myrica>
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
On Wed, Mar 18, 2026 at 05:53:17PM +0000, Jean-Philippe Brucker wrote:
> On Fri, Mar 06, 2026 at 05:01:06PM +0000, Mark Brown wrote:
> > +/* Current for the hypervisor */
> Not sure what this means, isn't it also current for the guest?
If it has multiple VLs available then the guest may select between them,
including choosing one smaller than what is configured in the hypervisor
- for example a guest running at EL1 can set a lower VL in ZCR_EL1 or
SMCR_EL1 than is configured in the corresponding EL2 register. This has
been something that has frequently needed clarification.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Mathias Stearn @ 2026-04-23 18:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Gleixner, Peter Zijlstra, Mathieu Desnoyers,
Catalin Marinas, Will Deacon, Boqun Feng, Paul E. McKenney,
Chris Kennelly, Dmitry Vyukov, regressions, linux-kernel,
linux-arm-kernel, Ingo Molnar, Mark Rutland, Jinjie Ruan,
Blake Oler
In-Reply-To: <CAHk-=wjsEqWJxXArS-P5+ksSY2Apaox8u6FtUrtyWSBEOL4Q2Q@mail.gmail.com>
On Thu, Apr 23, 2026 at 7:48 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> I see some patches flying around, but am not clear on whether there
> was an actual patch that make this work again?
Thomas's patch from upthread appears in initial testing to address the
arm64 preemption breakage. Thanks! I'm currently building with the
following patch on top of that and will test it once it is ready.
---
diff --git a/include/linux/rseq_entry.h b/include/linux/rseq_entry.h
index a36b472627de..e26bf249bbd8 100644
--- a/include/linux/rseq_entry.h
+++ b/include/linux/rseq_entry.h
@@ -300,12 +300,15 @@ rseq_update_user_cs(struct task_struct *t,
struct pt_regs *regs, unsigned long c
/* Invalidate the critical section */
unsafe_put_user(0ULL, &t->rseq.usrptr->rseq_cs, efault);
+ /* TCMalloc kludge - it relies on cpu_id_start being overwritten */
+ unsafe_put_user((u32)task_cpu(t),
&t->rseq.usrptr->cpu_id_start, efault);
/* Update the instruction pointer */
instruction_pointer_set(regs, (unsigned long)abort_ip);
rseq_stat_inc(rseq_stats.fixup);
break;
clear:
unsafe_put_user(0ULL, &t->rseq.usrptr->rseq_cs, efault);
+ unsafe_put_user((u32)task_cpu(t),
&t->rseq.usrptr->cpu_id_start, efault);
rseq_stat_inc(rseq_stats.clear);
abort_ip = 0ULL;
}
^ permalink raw reply related
* Re: [PATCH v2 1/2] spi: sun6i: Honor CS setup delay on the first transfer with native CS
From: Kevin Mehall @ 2026-04-23 18:40 UTC (permalink / raw)
To: Mark Brown, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Mirko Vogt, Ralf Schlatterbeck, linux-spi, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260423174001.2797797-2-km@kevinmehall.net>
I realized this is incorrect. With a GPIO chip select, sun6i_spi_set_cs() is not called,
thus CS_MANUAL would not be set, and the hardware would then automatically
assert native CS 0 during the transfer. My testing was with native CS 1 and a second GPIO chip select,
so I didn't see this because native CS 0 is not used on the Orange Pi Zero 3.
Therefore, I think the best place to set CS_MANUAL is in sun6i_spi_prepare_message
as I had in my original patch [1], unless you think it should be duplicated in both places
or have a better suggestion of where to set it. sun6i_spi_prepare_message() is still called
before set_cs(), so it still fixes the skipped delay.
[1]: https://lore.kernel.org/linux-spi/20260420164755.1131645-1-km@kevinmehall.net/
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3: Allow disabling Stage 1 translation
From: Samiullah Khawaja @ 2026-04-23 18:43 UTC (permalink / raw)
To: Will Deacon
Cc: Jason Gunthorpe, Evangelos Petrongonas, Robin Murphy,
Joerg Roedel, Nicolin Chen, Pranjal Shrivastava, Lu Baolu,
linux-arm-kernel, iommu, linux-kernel, nh-open-source,
Zeev Zilberman, dmatlack, pasha.tatashin
In-Reply-To: <aepRy7Gp7Ng85Zr7@willie-the-truck>
On Thu, Apr 23, 2026 at 06:07:23PM +0100, Will Deacon wrote:
>On Thu, Apr 23, 2026 at 11:23:26AM -0300, Jason Gunthorpe wrote:
>> On Thu, Apr 23, 2026 at 10:47:49AM +0100, Will Deacon wrote:
>> > > Does iommu-pages provide a mechanism to map the memory as non-cacheable
>> > > if the SMMU isn't coherent?
>>
>> No, it has to use CMOs today.
>>
>> It looks like all the stuff dma_alloc_coherent does to make a
>> non-cached mapping are pretty arch specific. I don't know if there is
>> a way we could make more general code get a struct page into an
>> uncached KVA and meet all the arch rules?
>>
>> I also think dma_alloc_coherent is far to complex, with pools and
>> more, to support KHO.
Agreed. dma_alloc_* is too complex with pools, CMAs and what not to
support fully in KHO.
>
>I wonder if there's scope for supporting just some subset of it?
We have been experimenting with something like this. We have a usecase
where memory needs to be preserved but we want to avoid invasive changes
in the driver.
If it's not a crazy idea, maybe we can start with a very limited scope
of providing preservation for a subset of allocations done through the
DMA API? I can send out my proof of concept as an RFC after I'm done
with the next revision of my IOMMU persistence series. WDYT?
Sami
^ permalink raw reply
* Re: [PATCH] iio: fix header includes across multiple drivers
From: David Lechner @ 2026-04-23 18:45 UTC (permalink / raw)
To: Caio Morais, jic23, nuno.sa, andy, michal.simek
Cc: linux-iio, linux-arm-kernel
In-Reply-To: <20260423183349.636757-1-caiomorais@usp.br>
On 4/23/26 1:33 PM, Caio Morais wrote:
> From: Caio Morais <caiomorais@usp.br>
>
> Remove unnecessary includes and add missing ones as reported by the
> include-what-you-use (IWYU) tool.
>
> Files changed:
> - drivers/iio/adc/xilinx-xadc-events.c
> - drivers/iio/buffer/industrialio-triggered-buffer.c
> - drivers/iio/common/st_sensors/st_sensors_i2c.c
> - drivers/iio/common/st_sensors/st_sensors_spi.c
We'll want to split these up, one patch per file in case they every
need to be backported as a dependency to a fix.
>
> Signed-off-by: Caio Morais <caiomorais@usp.br>
> ---
> drivers/iio/adc/xilinx-xadc-events.c | 4 ++--
> drivers/iio/buffer/industrialio-triggered-buffer.c | 8 ++++----
> drivers/iio/common/st_sensors/st_sensors_i2c.c | 2 +-
> 3 files changed, 7 insertions(+), 7 deletions(-)
This looks like sorting alphabetically, not actually adding or removing
any headers as seen by the equal number of insertions and deletions.
Usually we don't bother with sorting unless we are making other
changes on top of that.
>
> diff --git a/drivers/iio/adc/xilinx-xadc-events.c b/drivers/iio/adc/xilinx-xadc-events.c
> index d16e61953..20b796ec7 100644
> --- a/drivers/iio/adc/xilinx-xadc-events.c
> +++ b/drivers/iio/adc/xilinx-xadc-events.c
> @@ -7,11 +7,11 @@
> */
>
> #include <linux/bitmap.h>
> -#include <linux/types.h>
> #include <linux/errno.h>
> -#include <linux/mutex.h>
> #include <linux/iio/events.h>
> #include <linux/iio/iio.h>
> +#include <linux/mutex.h>
> +#include <linux/types.h>
>
> #include "xilinx-xadc.h"
>
> diff --git a/drivers/iio/buffer/industrialio-triggered-buffer.c b/drivers/iio/buffer/industrialio-triggered-buffer.c
> index 601a26398..5796c9da7 100644
> --- a/drivers/iio/buffer/industrialio-triggered-buffer.c
> +++ b/drivers/iio/buffer/industrialio-triggered-buffer.c
> @@ -5,15 +5,15 @@
> */
>
> #include <linux/errno.h>
> -#include <linux/linkage.h>
> -#include <linux/module.h>
> -#include <linux/stddef.h>
> -#include <linux/iio/iio.h>
> #include <linux/iio/buffer.h>
> #include <linux/iio/buffer_impl.h>
> +#include <linux/iio/iio.h>
> #include <linux/iio/kfifo_buf.h>
> #include <linux/iio/triggered_buffer.h>
> #include <linux/iio/trigger_consumer.h>
> +#include <linux/linkage.h>
> +#include <linux/module.h>
> +#include <linux/stddef.h>
>
> /**
> * iio_triggered_buffer_setup_ext() - Setup triggered buffer and pollfunc
> diff --git a/drivers/iio/common/st_sensors/st_sensors_i2c.c b/drivers/iio/common/st_sensors/st_sensors_i2c.c
> index 6ab143498..974e349ae 100644
> --- a/drivers/iio/common/st_sensors/st_sensors_i2c.c
> +++ b/drivers/iio/common/st_sensors/st_sensors_i2c.c
> @@ -10,10 +10,10 @@
> #include <linux/device.h>
> #include <linux/err.h>
> #include <linux/i2c.h>
> +#include <linux/iio/iio.h>
> #include <linux/linkage.h>
> #include <linux/module.h>
> #include <linux/regmap.h>
> -#include <linux/iio/iio.h>
On this one, it would be more logical to move the iio header
down one line to group it with the one below.
>
> #include <linux/iio/common/st_sensors_i2c.h>
>
^ permalink raw reply
* Re: [PATCH v2 1/2] spi: sun6i: Honor CS setup delay on the first transfer with native CS
From: Mark Brown @ 2026-04-23 18:50 UTC (permalink / raw)
To: Kevin Mehall
Cc: Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Mirko Vogt,
Ralf Schlatterbeck, linux-spi, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <53c2d366-2d76-4a6d-a72b-99544026ee27@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]
On Thu, Apr 23, 2026 at 12:40:34PM -0600, Kevin Mehall wrote:
> I realized this is incorrect. With a GPIO chip select, sun6i_spi_set_cs() is not called,
> thus CS_MANUAL would not be set, and the hardware would then automatically
> assert native CS 0 during the transfer. My testing was with native CS 1 and a second GPIO chip select,
> so I didn't see this because native CS 0 is not used on the Orange Pi Zero 3.
> Therefore, I think the best place to set CS_MANUAL is in sun6i_spi_prepare_message
> as I had in my original patch [1], unless you think it should be duplicated in both places
> or have a better suggestion of where to set it. sun6i_spi_prepare_message() is still called
> before set_cs(), so it still fixes the skipped delay.
That sounds about right, the other option would be
SPI_CONTROLLER_GPIO_SS but I don't think this controller needs it.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Mark Rutland @ 2026-04-23 18:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Gleixner, Mathias Stearn, Peter Zijlstra,
Mathieu Desnoyers, Catalin Marinas, Will Deacon, Boqun Feng,
Paul E. McKenney, Chris Kennelly, Dmitry Vyukov, regressions,
linux-kernel, linux-arm-kernel, Ingo Molnar, Jinjie Ruan,
Blake Oler
In-Reply-To: <CAHk-=wjsEqWJxXArS-P5+ksSY2Apaox8u6FtUrtyWSBEOL4Q2Q@mail.gmail.com>
On Thu, Apr 23, 2026 at 10:41:02AM -0700, Linus Torvalds wrote:
> On Thu, 23 Apr 2026 at 10:19, Thomas Gleixner <tglx@kernel.org> wrote:
> I see some patches flying around, but am not clear on whether there
> was an actual patch that make this work again?
There's not a patch yet.
The diffs sent so far were options for fixing the arm64-specific issue
(missing aborts on preemption), NOT the generic issue (missing
clobbering of cpu_id_start that tcmalloc was depending upon).
For the arm64 issue, I think we can have a fix tomorrow (as it's end of
day here in the UK). Now that I've pored the entry code and the rseq
code, I think a variant of one of Thomas's proposed fixes will work, but
I'd like to make the naming/layering crystal clear so that it's harder
to break this by accident in future.
For the generic issue, hopefully the option Mathias proposed (clearing
cpu_id_start when rseq_cs is cleared) is sufficient. I'll work with
Mathias and Thomas for that.
I've also poked folk to make sure that CI systems run the rseq selftests
(which they evidently weren't), so that we catch this sort of thing
earlier.
Mark.
^ permalink raw reply
* [PATCH v14 01/28] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
From: Nicolas Frattaroli @ 2026-04-23 19:03 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Werner Sembach, Andri Yngvason
In-Reply-To: <20260423-color-format-v14-0-449a419ccbd4@collabora.com>
From: Werner Sembach <wse@tuxedocomputers.com>
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.
Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
there is no reason to use RGB when the display
reports drm_mode_is_420_only() even on a non HDMI connection.
This patch also moves both checks in the same if-case. This eliminates an
extra else-if-case.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Andri Yngvason <andri@yngvason.is>
Tested-by: Andri Yngvason <andri@yngvason.is>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e96a12ff2d31..5b9fcfb45fd2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6785,12 +6785,9 @@ static void fill_stream_properties_from_drm_display_mode(
timing_out->v_border_top = 0;
timing_out->v_border_bottom = 0;
/* TODO: un-hardcode */
- if (drm_mode_is_420_only(info, mode_in)
- && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
- timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
- else if (drm_mode_is_420_also(info, mode_in)
- && aconnector
- && aconnector->force_yuv420_output)
+ if (drm_mode_is_420_only(info, mode_in) ||
+ (aconnector && aconnector->force_yuv420_output &&
+ drm_mode_is_420_also(info, mode_in)))
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
else if ((connector->display_info.color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422))
&& aconnector
--
2.53.0
^ permalink raw reply related
* [PATCH v14 02/28] drm/display: hdmi-state-helper: Use default case for unsupported formats
From: Nicolas Frattaroli @ 2026-04-23 19:03 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Cristian Ciocaltea
In-Reply-To: <20260423-color-format-v14-0-449a419ccbd4@collabora.com>
Switch statements that do not handle all possible values of an
enumeration will generate a warning during compilation. In preparation
for adding a COUNT value to the end of the enum, this needs to be dealt
with.
Add a default case to sink_supports_format_bpc's DRM_OUTPUT_COLOR_FORMAT
switch statement, and move the log-and-return unknown pixel format
handling into it.
No functional change.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
index 9f3b696aceeb..a0d88701d236 100644
--- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
@@ -541,10 +541,11 @@ sink_supports_format_bpc(const struct drm_connector *connector,
drm_dbg_kms(dev, "YUV444 format supported in that configuration.\n");
return true;
- }
- drm_dbg_kms(dev, "Unsupported pixel format.\n");
- return false;
+ default:
+ drm_dbg_kms(dev, "Unsupported pixel format.\n");
+ return false;
+ }
}
static enum drm_mode_status
--
2.53.0
^ permalink raw reply related
* [PATCH v14 03/28] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-04-23 19:03 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <20260423-color-format-v14-0-449a419ccbd4@collabora.com>
Add a new general DRM property named "color format" which can be used by
userspace to request the display driver to output a particular color
format.
Possible string values for the new enum property are:
- "AUTO" (setup by default, driver internally picks the color format)
- "RGB"
- "YUV 4:4:4"
- "YUV 4:2:2"
- "YUV 4:2:0"
Drivers should advertise from this list the formats they support in an
optimistic best-case scenario. EDID data from the sink can then be used
in the kernel's atomic check phase to restrict this set of formats, as
well as by userspace to make a correct choice in the first place.
Co-developed-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Co-developed-by: Andri Yngvason <andri@yngvason.is>
Signed-off-by: Andri Yngvason <andri@yngvason.is>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Documentation/gpu/drm-kms.rst | 6 ++
drivers/gpu/drm/drm_atomic_helper.c | 5 ++
drivers/gpu/drm/drm_atomic_uapi.c | 11 +++
drivers/gpu/drm/drm_connector.c | 155 ++++++++++++++++++++++++++++++++++++
include/drm/drm_connector.h | 108 +++++++++++++++++++++++++
5 files changed, 285 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 2292e65f044c..da5133b672d3 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -599,6 +599,12 @@ Color Management Properties
.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
:doc: overview
+Color Format Property
+---------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+ :doc: Color format
+
Tile Group Property
-------------------
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index a768398a1884..446857a4945d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -737,6 +737,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->max_requested_bpc !=
new_connector_state->max_requested_bpc)
new_crtc_state->connectors_changed = true;
+
+ if (old_connector_state->color_format !=
+ new_connector_state->color_format)
+ new_crtc_state->connectors_changed = true;
+
}
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 5bd5bf6661df..dee510c85e59 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -935,6 +935,15 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
state->privacy_screen_sw_state = val;
} else if (property == connector->broadcast_rgb_property) {
state->hdmi.broadcast_rgb = val;
+ } else if (property == connector->color_format_property) {
+ if (val > INT_MAX || !drm_connector_color_format_valid(val)) {
+ drm_dbg_atomic(connector->dev,
+ "[CONNECTOR:%d:%s] unknown color format %llu\n",
+ connector->base.id, connector->name, val);
+ return -EINVAL;
+ }
+
+ state->color_format = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1020,6 +1029,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
*val = state->privacy_screen_sw_state;
} else if (property == connector->broadcast_rgb_property) {
*val = state->hdmi.broadcast_rgb;
+ } else if (property == connector->color_format_property) {
+ *val = state->color_format;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 3fa4d2082cd7..a0fca522f18f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1388,6 +1388,18 @@ static const u32 hdmi_colorspaces =
BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
+static const u32 hdmi_colorformats =
+ BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
+
+static const u32 dp_colorformats =
+ BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
+
/*
* As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
* Format Table 2-120
@@ -2935,6 +2947,149 @@ int drm_connector_attach_colorspace_property(struct drm_connector *connector)
}
EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
+/**
+ * DOC: Color format
+ *
+ * The connector "color format" property allows userspace to request a specific
+ * color model on the output of the connector. Not all values listed by the
+ * property are guaranteed to work for every sink; rather, it is an optimistic
+ * listing of color formats that the source could output depending on
+ * circumstances.
+ *
+ * Whether it actually can output a certain color format is determined during
+ * the atomic check phase. Consequently, a userspace application that sets the
+ * color format to a value other than "AUTO" should check whether its atomic
+ * commit succeeded.
+ *
+ * Possible values for "color format":
+ *
+ * "AUTO":
+ * The driver or display protocol helpers should pick a suitable color
+ * format. All implementations of a specific display protocol will behave
+ * the same way with "AUTO", but different display protocols do not
+ * necessarily have the same "AUTO" semantics.
+ *
+ * For HDMI connectors, "AUTO" picks RGB, but falls back to YUV 4:2:0 if
+ * the bandwidth required for full-scale RGB is not available, or the mode
+ * is YUV 4:2:0-only, as long as the mode, source, and sink all support
+ * YUV 4:2:0.
+ * "RGB":
+ * RGB output format. The quantization range (limited/full) depends on the
+ * value of the "Broadcast RGB" property if it is present on the connector.
+ * "YUV 4:4:4":
+ * YUV 4:4:4 (a.k.a. YCbCr 4:4:4) output format. Chroma is not subsampled.
+ * The quantization range defaults to limited.
+ * "YUV 4:2:2":
+ * YUV 4:2:2 (a.k.a. YCbCr 4:2:2) output format. Chroma has half the
+ * horizontal resolution of Luma. The quantization range defaults to
+ * limited.
+ * "YUV 4:2:0":
+ * YUV 4:2:0 (a.k.a. YCbCr 4:2:0) output format. Chroma has half the
+ * horizontal and vertical resolution of Luma. The quantization range
+ * defaults to limited.
+ *
+ * A sink may only support some color formats in specific modes and at specific
+ * bit depths. The atomic modesetting API should be used to set a working
+ * configuration in one go, as an unsupported combination of parameters is
+ * rejected.
+ */
+
+/**
+ * drm_connector_attach_color_format_property - create and attach color format property
+ * @connector: connector to create the color format property on
+ * @supported_color_formats: bitmask of bit-shifted &enum drm_output_color_format
+ * values the connector supports
+ *
+ * Called by a driver to create a color format property. The property is
+ * attached to the connector automatically on success.
+ *
+ * @supported_color_formats should only include color formats the connector
+ * type can actually support.
+ *
+ * Returns:
+ * 0 on success, negative errno on error
+ */
+int drm_connector_attach_color_format_property(struct drm_connector *connector,
+ unsigned long supported_color_formats)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_prop_enum_list enum_list[DRM_CONNECTOR_COLOR_FORMAT_COUNT];
+ unsigned int i = 0;
+ unsigned long fmt;
+
+ if (connector->color_format_property)
+ return 0;
+
+ if (!supported_color_formats) {
+ drm_err(dev, "No supported color formats provided on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
+ if (supported_color_formats & ~GENMASK(DRM_OUTPUT_COLOR_FORMAT_COUNT - 1, 0)) {
+ drm_err(dev, "Unknown color formats provided on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
+ switch (connector->connector_type) {
+ case DRM_MODE_CONNECTOR_HDMIA:
+ case DRM_MODE_CONNECTOR_HDMIB:
+ if (supported_color_formats & ~hdmi_colorformats) {
+ drm_err(dev, "Color formats not allowed for HDMI on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+ break;
+ case DRM_MODE_CONNECTOR_DisplayPort:
+ case DRM_MODE_CONNECTOR_eDP:
+ if (supported_color_formats & ~dp_colorformats) {
+ drm_err(dev, "Color formats not allowed for DP on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+ break;
+ }
+
+ enum_list[0].name = "AUTO";
+ enum_list[0].type = DRM_CONNECTOR_COLOR_FORMAT_AUTO;
+
+ for_each_set_bit(fmt, &supported_color_formats, DRM_OUTPUT_COLOR_FORMAT_COUNT) {
+ switch (fmt) {
+ case DRM_OUTPUT_COLOR_FORMAT_RGB444:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
+ break;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
+ break;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
+ break;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
+ break;
+ default:
+ drm_warn(dev, "Unknown supported format %ld on [CONNECTOR:%d:%s]\n",
+ fmt, connector->base.id, connector->name);
+ continue;
+ }
+ enum_list[i].name = drm_hdmi_connector_get_output_format_name(fmt);
+ }
+
+ connector->color_format_property =
+ drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "color format",
+ enum_list, i + 1);
+
+ if (!connector->color_format_property)
+ return -ENOMEM;
+
+ drm_object_attach_property(&connector->base, connector->color_format_property,
+ DRM_CONNECTOR_COLOR_FORMAT_AUTO);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_color_format_property);
+
/**
* drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
* @old_state: old connector state to compare
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 3e422a4f2e72..3f7b94e4d83d 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -571,14 +571,106 @@ enum drm_colorspace {
* YCbCr 4:2:2 output format (ie. with horizontal subsampling)
* @DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
* YCbCr 4:2:0 output format (ie. with horizontal and vertical subsampling)
+ * @DRM_OUTPUT_COLOR_FORMAT_COUNT:
+ * Number of valid output color format values in this enum
*/
enum drm_output_color_format {
DRM_OUTPUT_COLOR_FORMAT_RGB444 = 0,
DRM_OUTPUT_COLOR_FORMAT_YCBCR444,
DRM_OUTPUT_COLOR_FORMAT_YCBCR422,
DRM_OUTPUT_COLOR_FORMAT_YCBCR420,
+ DRM_OUTPUT_COLOR_FORMAT_COUNT,
};
+/**
+ * enum drm_connector_color_format - Connector Color Format Request
+ *
+ * This enum, unlike &enum drm_output_color_format, is used to specify requests
+ * for a specific color format on a connector through the DRM "color format"
+ * property. The difference is that it has an "AUTO" value to specify that
+ * no specific choice has been made.
+ */
+enum drm_connector_color_format {
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
+ * helpers should pick a suitable color format. All implementations of a
+ * specific display protocol must behave the same way with "AUTO", but
+ * different display protocols do not necessarily have the same "AUTO"
+ * semantics.
+ *
+ * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
+ * bandwidth required for full-scale RGB is not available, or the mode
+ * is YCbCr 4:2:0-only, as long as the mode and output both support
+ * YCbCr 4:2:0.
+ *
+ * For display protocols other than HDMI, the recursive bridge chain
+ * format selection picks the first chain of bridge formats that works,
+ * as has already been the case before the introduction of the "color
+ * format" property. Non-HDMI bridges should therefore either sort their
+ * bus output formats by preference, or agree on a unified auto format
+ * selection logic that's implemented in a common state helper (like
+ * how HDMI does it).
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format. The
+ * quantization range depends on the value of the "Broadcast RGB"
+ * property if it is present on the connector.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_RGB444,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
+ * not subsampled). Quantization range is "Limited" by default.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
+ * with horizontal subsampling). Quantization range is "Limited" by
+ * default.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
+ * with horizontal and vertical subsampling). Quantization range is
+ * "Limited" by default.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_COUNT: Number of valid connector color
+ * format values in this enum
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_COUNT,
+};
+
+/**
+ * drm_connector_color_format_valid - Validate drm_connector_color_format value
+ * @fmt: value to check against all values of &enum drm_connector_color_format
+ *
+ * Checks whether the passed in value of @fmt is one of the allowable values in
+ * &enum drm_connector_color_format.
+ *
+ * Returns: %true if it's a valid value for the enum, %false otherwise.
+ */
+static inline bool __pure
+drm_connector_color_format_valid(enum drm_connector_color_format fmt)
+{
+ switch (fmt) {
+ case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
+ case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
+ case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
+ case DRM_CONNECTOR_COLOR_FORMAT_YCBCR422:
+ case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
+ return true;
+ default:
+ return false;
+ }
+}
+
const char *
drm_hdmi_connector_get_output_format_name(enum drm_output_color_format fmt);
@@ -1167,6 +1259,13 @@ struct drm_connector_state {
*/
enum drm_colorspace colorspace;
+ /**
+ * @color_format: State variable for Connector property to request
+ * color format change on Sink. This is most commonly used to switch
+ * between RGB to YUV and vice-versa.
+ */
+ enum drm_connector_color_format color_format;
+
/**
* @writeback_job: Writeback job for writeback connectors
*
@@ -2165,6 +2264,12 @@ struct drm_connector {
*/
struct drm_property *colorspace_property;
+ /**
+ * @color_format_property: Connector property to set the suitable
+ * color format supported by the sink.
+ */
+ struct drm_property *color_format_property;
+
/**
* @path_blob_ptr:
*
@@ -2648,6 +2753,9 @@ bool drm_connector_has_possible_encoder(struct drm_connector *connector,
struct drm_encoder *encoder);
const char *drm_get_colorspace_name(enum drm_colorspace colorspace);
+int drm_connector_attach_color_format_property(struct drm_connector *connector,
+ unsigned long supported_color_formats);
+
/**
* drm_for_each_connector_iter - connector_list iterator macro
* @connector: &struct drm_connector pointer used as cursor
--
2.53.0
^ permalink raw reply related
* [PATCH v14 04/28] drm/connector: Let connectors have a say in their color format
From: Nicolas Frattaroli @ 2026-04-23 19:03 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli
In-Reply-To: <20260423-color-format-v14-0-449a419ccbd4@collabora.com>
Add a function to get the connector color format from a connector state,
and a new function pointer in drm_connector_funcs to allow connectors to
override what connector color format it returns.
This is useful for the bridge chain recursive bus format selection code,
which does not wish to implement connector implementation specific
checks like whether it involves HDMI.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/drm_connector.c | 16 ++++++++++++++++
include/drm/drm_connector.h | 12 ++++++++++++
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a0fca522f18f..41a5ab1e563e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -3685,6 +3685,22 @@ void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
}
EXPORT_SYMBOL(drm_connector_oob_hotplug_event);
+/**
+ * drm_connector_get_color_format - Return connector color format of @conn_state
+ * @conn_state: pointer to the &struct drm_connector_state to go check
+ *
+ */
+enum drm_connector_color_format
+drm_connector_get_color_format(const struct drm_connector_state *conn_state)
+{
+ struct drm_connector *connector = conn_state->connector;
+
+ if (connector->funcs->color_format)
+ return connector->funcs->color_format(conn_state);
+
+ return conn_state->color_format;
+}
+EXPORT_SYMBOL(drm_connector_get_color_format);
/**
* DOC: Tile group
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 3f7b94e4d83d..0178941bc0d1 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1811,6 +1811,16 @@ struct drm_connector_funcs {
* Allows connectors to create connector-specific debugfs files.
*/
void (*debugfs_init)(struct drm_connector *connector, struct dentry *root);
+
+ /**
+ * @color_format:
+ *
+ * Allows connectors to return a connector color format other than
+ * @conn_state.color_format for purposes of e.g. display protocol
+ * specific helper logic having already mapped it to an output format.
+ */
+ enum drm_connector_color_format (*color_format)(
+ const struct drm_connector_state *conn_state);
};
/**
@@ -2627,6 +2637,8 @@ drm_connector_is_unregistered(struct drm_connector *connector)
void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
enum drm_connector_status status);
+enum drm_connector_color_format
+drm_connector_get_color_format(const struct drm_connector_state *conn_state);
const char *drm_get_connector_type_name(unsigned int connector_type);
const char *drm_get_connector_status_name(enum drm_connector_status status);
const char *drm_get_subpixel_order_name(enum subpixel_order order);
--
2.53.0
^ permalink raw reply related
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