* [PATCH 1/2] dt-bindings: arm: aspeed: Add Meta Rainiera6 board
From: Neil Cheng @ 2026-05-18 8:13 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, joel, andrew, geert+renesas, magnus.damm
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-renesas-soc, Neil Cheng
In-Reply-To: <cover.1779088499.git.neilcheng0417@gmail.com>
Document the new compatibles used on Meta Rainiera6.
Signed-off-by: Neil Cheng <neilcheng0417@gmail.com>
---
Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index 8ec7a3e74a21..1a2252eb08f1 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -95,6 +95,7 @@ properties:
- facebook,greatlakes-bmc
- facebook,harma-bmc
- facebook,minerva-cmc
+ - facebook,rainiera6-bmc
- facebook,santabarbara-bmc
- facebook,yosemite4-bmc
- facebook,yosemite5-bmc
--
2.25.1
^ permalink raw reply related
* [PATCH 0/2] Add Meta Rainiera6 BMC support
From: Neil Cheng @ 2026-05-18 8:13 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, joel, andrew, geert+renesas, magnus.damm
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-renesas-soc, Neil Cheng
Add initial device tree support for the Meta Rainiera6 platform.
This series adds:
- Meta Rainiera6 compatible entry
- Rainiera6 BMC DTS
The DTS has been validated with:
- make dtbs
- make dt_binding_check
- make CHECK_DTBS=y
Neil Cheng (2):
dt-bindings: arm: aspeed: Add Meta Rainiera6 board
ARM: dts: aspeed: rainiera6: Add Meta Rainiera6 BMC
.../bindings/arm/aspeed/aspeed.yaml | 1 +
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../aspeed/aspeed-bmc-facebook-rainiera6.dts | 1012 +++++++++++++++++
3 files changed, 1014 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-rainiera6.dts
--
2.25.1
^ permalink raw reply
* Re: [PATCH 1/8] mm: Add ptep_try_install() for lockless empty-slot installs
From: David Hildenbrand (Arm) @ 2026-05-18 8:06 UTC (permalink / raw)
To: Tejun Heo, David Vernet, Andrea Righi, Changwoo Min,
Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann,
Martin KaFai Lau, Kumar Kartikeya Dwivedi
Cc: Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, Andrew Morton, Mike Rapoport,
Emil Tsalapatis, sched-ext, bpf, x86, linux-arm-kernel, linux-mm,
linux-kernel
In-Reply-To: <20260517211232.1670594-2-tj@kernel.org>
On 5/17/26 23:12, Tejun Heo wrote:
> Add ptep_try_install(ptep, new_pte): atomically set *ptep to new_pte
> iff it is currently pte_none(). Returns true on success, false if the
> slot was already populated or the arch has no implementation.
>
> The intended caller is the upcoming bpf_arena kernel-side fault
> recovery path. The install runs from a page fault and may have to
> contend with locks already held by the faulting kernel caller, so
> keeping it lock-free via cmpxchg is the safe choice.
>
> The generic version in <linux/pgtable.h> returns false. x86 and arm64
> override with try_cmpxchg-based implementations on the underlying
> pteval. Other architectures get the false stub - the callers there
> already fall through to oops.
>
> Suggested-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> Suggested-by: Alexei Starovoitov <ast@kernel.org>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> ---
[...]
>
> +#ifndef __HAVE_ARCH_PTEP_TRY_INSTALL
> +/**
> + * ptep_try_install - atomically install an empty PTE
> + * @ptep: page table entry
> + * @new_pte: value to install
> + *
> + * Atomically set *@ptep to @new_pte iff *@ptep is pte_none(). Return
> + * true on success. Architectures opt in by providing a cmpxchg-based
> + * override. The generic stub returns false.
> + */
> +static inline bool ptep_try_install(pte_t *ptep, pte_t new_pte)
> +{
> + return false;
> +}
> +#endif
Ehm, what?
This is a very, very, very bad generic idea/interface.
On which ptes is this supposed to be used? User ptes or kernel ptes?
Surely we don't want this on user ptes.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v3] i2c: davinci: fix division by zero on missing clock-frequency
From: Bartosz Golaszewski @ 2026-05-18 8:01 UTC (permalink / raw)
To: Chaitanya Sabnis
Cc: linux-arm-kernel, linux-i2c, linux-kernel, Sashiko, brgl,
andi.shyti
In-Reply-To: <20260515092520.9006-1-chaitanya.msabnis@gmail.com>
On Fri, 15 May 2026 11:25:20 +0200, Chaitanya Sabnis
<chaitanya.msabnis@gmail.com> said:
> When the 'clock-frequency' property is missing from the device tree,
> the driver falls back to DAVINCI_I2C_DEFAULT_BUS_FREQ. However, this
> macro was defined in kHz (100), whereas the device tree property is
> expected in Hz.
>
> The probe function divided the fallback value by 1000, causing
> integer truncation that resulted in dev->bus_freq = 0. This triggered
> a deterministic division-by-zero kernel panic when calculating clock
> dividers later in the probe sequence.
>
> Fix this by redefining DAVINCI_I2C_DEFAULT_BUS_FREQ in Hz (100000)
> to match the expected device tree property unit, allowing the existing
> division logic to work correctly for both cases.
>
> Fixes: b04ce6385979 ("i2c: davinci: kill platform data")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/all/20260514044726.57297C2BCB7@smtp.kernel.org/
> Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
> ---
Missing changelog.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> drivers/i2c/busses/i2c-davinci.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
> index a773ba082321..a264a480dc3c 100644
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -117,7 +117,7 @@
> /* timeout for pm runtime autosuspend */
> #define DAVINCI_I2C_PM_TIMEOUT 1000 /* ms */
>
> -#define DAVINCI_I2C_DEFAULT_BUS_FREQ 100
> +#define DAVINCI_I2C_DEFAULT_BUS_FREQ 100000
>
> struct davinci_i2c_dev {
> struct device *dev;
> @@ -761,9 +761,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
> r = device_property_read_u32(&pdev->dev, "clock-frequency", &prop);
> if (r)
> prop = DAVINCI_I2C_DEFAULT_BUS_FREQ;
> -
> dev->bus_freq = prop / 1000;
> -
These a ninja changes, at least mention them in the commit message.
Bart
> dev->has_pfunc = device_property_present(&pdev->dev, "ti,has-pfunc");
>
> dev->clk = devm_clk_get(&pdev->dev, NULL);
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH v2 07/16] ARM: Drop tautological ld.lld conditions from ARCH_MULTI_V4{,T}
From: Arnd Bergmann @ 2026-05-18 7:59 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Bill Wendling, Justin Stitt,
Nick Desaulniers
Cc: linux-kernel, llvm, linux-kbuild, Russell King, linux-arm-kernel
In-Reply-To: <20260517-bump-minimum-supported-llvm-version-to-17-v2-7-b3b8cda46bdd@kernel.org>
On Mon, May 18, 2026, at 01:05, Nathan Chancellor wrote:
> Now that the minimum supported version of LLVM for building the kernel
> has been raised to 17.0.1, the '!ld.lld || ld.lld >= 16' dependency of
> CONFIG_ARCH_MULTI_V4{,T} is always true, so tit can be removed from both
> symbols.
>
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-arm-kernel@lists.infradead.org
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH v1] Input: Use named initializers for arrays of i2c_device_data
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-18 7:56 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Geert Uytterhoeven, Dmitry Torokhov, Anshul Dalal,
Michael Hennerich, Yassine Oudjana, Linus Walleij, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Support Opensource, Nick Dyer,
Hans de Goede, Job Noorman, Mika Penttilä, Maxime Coquelin,
Alexandre Torgue, Kees Cook, bui duc phuc, Thorsten Blum,
Yauhen Kharuzhy, Sakari Ailus, Marco Crivellari, Minseong Kim,
Ingo Molnar, Thomas Gleixner, Oleh Kuzhylnyi, Marek Vasut,
Krzysztof Kozlowski, Geert Uytterhoeven, Josua Mayer,
Michael Tretter, Jeff LaBundy, Javier Carrasco, David Heidelberg,
Petr Hodina, Svyatoslav Ryhel, Johannes Kirchmair, Xichao Zhao,
linux-input, linux-kernel, linux-arm-kernel, platform-driver-x86,
linux-stm32
In-Reply-To: <agrAG3cLjEAPV90B@ashevche-desk.local>
[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]
On Mon, May 18, 2026 at 10:30:35AM +0300, Andy Shevchenko wrote:
> On Mon, May 18, 2026 at 09:24:35AM +0200, Geert Uytterhoeven wrote:
> > Hi Uwe,
> >
> > On Fri, 15 May 2026 at 18:48, Uwe Kleine-König (The Capable Hub)
> > <u.kleine-koenig@baylibre.com> wrote:
> > > My additional motivation for this effort is CHERI[1]. This is a hardware
> >
> > Nice!
> >
> > > extension that uses 128 bit pointers but unsigned long is still 64 bit.
> > > So with CHERI you cannot store pointers in unsigned long variables.
> >
> > Good luck fixing all implicit assumptions about this in the kernel!
> > Also, good luck convincing people to use uintptr_t instead ;-)
> >
> > https://lore.kernel.org/all/CAHk-=wj2OHy-5e+srG1fy+ZU00TmZ1NFp6kFLbVLMXHe7A1d-g@mail.gmail.com
>
> Yeah, I believe Linus will have a strong opinion about all this CHERI stuff :-)
> But let see, it might be surprising turn around.
Yeah, it's not yet the time to start that discussion, I want to have the
patch stack in a better state before that.
I think the strongest argument will be that
"unsigned long" [...] is an integer type large enough to hold a
pointer.
just isn't true for CHERI.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] memory: mtk-smi: Add a flag skip_rpm
From: Xueqi Zhang (张雪琦) @ 2026-05-18 7:41 UTC (permalink / raw)
To: robh@kernel.org, matthias.bgg@gmail.com,
Yong Wu (吴勇), AngeloGioacchino Del Regno,
krzk@kernel.org, conor+dt@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org,
Xueqi Zhang (张雪琦),
Project_Global_Chrome_Upstream_Group,
Wendy-ST Lin (林詩庭),
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev
In-Reply-To: <1571510c-e51c-40c6-a702-214bf77f9f4d@kernel.org>
hi Krzysztof
My apologies for the multiple emails! I've been having some technical
issues with my mail client's plain-text settings and thought my
previous attempts had failed.Thanks for the reminder!
thanks
xueqi
On Mon, 2026-05-18 at 09:18 +0200, Krzysztof Kozlowski wrote:
> On 18/05/2026 09:16, Xueqi Zhang (张雪琦) wrote:
> > Hi Angelo,
> >
> > First of all, please accept my apologies for the delayed response.
> > I
> > have been deeply occupied with MT8196 Aluminium pKVM SMMU and SMI
> > related tasks recently.
> >
>
>
> How may times are you going to send it? I counted FOUR already!
>
>
https://lore.kernel.org/all/?q=%22Re%3A+%5BPATCH+2%2F3%5D+memory%3A+mtk-smi%3A+Add+a+flag+skip_rpm%22
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH] usb: gadget: aspeed_udc: avoid past-the-end iterator in dequeue
From: Maoyi Xie @ 2026-05-18 7:34 UTC (permalink / raw)
To: Andrew Jeffery, Neal Liu
Cc: Greg Kroah-Hartman, Benjamin Herrenschmidt, Joel Stanley,
Andrew Jeffery, linux-aspeed, linux-arm-kernel, linux-usb,
linux-kernel
From: Maoyi Xie <maoyixie.tju@gmail.com>
ast_udc_ep_dequeue() declares the loop cursor `req` outside the
list_for_each_entry(). After the loop it tests `&req->req != _req`
to decide whether the request was found. If the queue holds no
match, `req` is past-the-end. It then aliases
container_of(&ep->queue, struct ast_udc_request, queue) via offset
cancellation. Whether that synthetic address equals `_req` depends
on heap layout. The function can return 0 without dequeueing
anything.
Use the cursor-vs-result idiom from the sibling aspeed-vhub driver,
ast_vhub_epn_dequeue() in drivers/usb/gadget/udc/aspeed-vhub/epn.c.
A separate `iter` walks the list. `req` is set only when a request
matches. After the loop, `req` is NULL if nothing matched.
The same idiom is used by the other UDC drivers in
drivers/usb/gadget/udc/ (at91_udc, atmel_usba_udc, dummy_hcd,
fsl_qe_udc, fsl_udc_core, goku_udc, gr_udc, lpc32xx_udc,
max3420_udc, net2280, omap_udc, pxa25x_udc, pxa27x_udc, udc-xilinx,
bcm63xx_udc).
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
---
drivers/usb/gadget/udc/aspeed_udc.c | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
--- a/drivers/usb/gadget/udc/aspeed_udc.c
+++ b/drivers/usb/gadget/udc/aspeed_udc.c
@@ -692,26 +692,30 @@
{
struct ast_udc_ep *ep = to_ast_ep(_ep);
struct ast_udc_dev *udc = ep->udc;
- struct ast_udc_request *req;
+ struct ast_udc_request *req = NULL, *iter;
unsigned long flags;
int rc = 0;
spin_lock_irqsave(&udc->lock, flags);
/* make sure it's actually queued on this endpoint */
- list_for_each_entry(req, &ep->queue, queue) {
- if (&req->req == _req) {
- list_del_init(&req->queue);
- ast_udc_done(ep, req, -ESHUTDOWN);
- _req->status = -ECONNRESET;
- break;
- }
+ list_for_each_entry(iter, &ep->queue, queue) {
+ if (&iter->req != _req)
+ continue;
+ req = iter;
+ break;
}
- /* dequeue request not found */
- if (&req->req != _req)
+ if (!req) {
rc = -EINVAL;
+ goto out;
+ }
+
+ list_del_init(&req->queue);
+ ast_udc_done(ep, req, -ESHUTDOWN);
+ _req->status = -ECONNRESET;
+out:
spin_unlock_irqrestore(&udc->lock, flags);
return rc;
--
2.34.1
^ permalink raw reply
* Re: [PATCH v1] Input: Use named initializers for arrays of i2c_device_data
From: Geert Uytterhoeven @ 2026-05-18 7:24 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Dmitry Torokhov, Anshul Dalal, Michael Hennerich, Yassine Oudjana,
Linus Walleij, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Support Opensource, Nick Dyer, Hans de Goede, Job Noorman,
Mika Penttilä, Maxime Coquelin, Alexandre Torgue, Kees Cook,
bui duc phuc, Thorsten Blum, Yauhen Kharuzhy, Sakari Ailus,
Marco Crivellari, Minseong Kim, Ingo Molnar, Thomas Gleixner,
Oleh Kuzhylnyi, Marek Vasut, Krzysztof Kozlowski,
Geert Uytterhoeven, Josua Mayer, Michael Tretter, Jeff LaBundy,
Javier Carrasco, David Heidelberg, Petr Hodina, Svyatoslav Ryhel,
Johannes Kirchmair, Andy Shevchenko, Xichao Zhao, linux-input,
linux-kernel, linux-arm-kernel, platform-driver-x86, linux-stm32
In-Reply-To: <20260515164848.497608-2-u.kleine-koenig@baylibre.com>
Hi Uwe,
On Fri, 15 May 2026 at 18:48, Uwe Kleine-König (The Capable Hub)
<u.kleine-koenig@baylibre.com> wrote:
> My additional motivation for this effort is CHERI[1]. This is a hardware
Nice!
> extension that uses 128 bit pointers but unsigned long is still 64 bit.
> So with CHERI you cannot store pointers in unsigned long variables.
Good luck fixing all implicit assumptions about this in the kernel!
Also, good luck convincing people to use uintptr_t instead ;-)
https://lore.kernel.org/all/CAHk-=wj2OHy-5e+srG1fy+ZU00TmZ1NFp6kFLbVLMXHe7A1d-g@mail.gmail.com
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v1] Input: Use named initializers for arrays of i2c_device_data
From: Andy Shevchenko @ 2026-05-18 7:30 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Uwe Kleine-König (The Capable Hub), Dmitry Torokhov,
Anshul Dalal, Michael Hennerich, Yassine Oudjana, Linus Walleij,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Support Opensource, Nick Dyer, Hans de Goede, Job Noorman,
Mika Penttilä, Maxime Coquelin, Alexandre Torgue, Kees Cook,
bui duc phuc, Thorsten Blum, Yauhen Kharuzhy, Sakari Ailus,
Marco Crivellari, Minseong Kim, Ingo Molnar, Thomas Gleixner,
Oleh Kuzhylnyi, Marek Vasut, Krzysztof Kozlowski,
Geert Uytterhoeven, Josua Mayer, Michael Tretter, Jeff LaBundy,
Javier Carrasco, David Heidelberg, Petr Hodina, Svyatoslav Ryhel,
Johannes Kirchmair, Xichao Zhao, linux-input, linux-kernel,
linux-arm-kernel, platform-driver-x86, linux-stm32
In-Reply-To: <CAMuHMdWGSBbQtKaoFej1Qm-SUgDenLMDF0psD9o07wyHKu8A+w@mail.gmail.com>
On Mon, May 18, 2026 at 09:24:35AM +0200, Geert Uytterhoeven wrote:
> Hi Uwe,
>
> On Fri, 15 May 2026 at 18:48, Uwe Kleine-König (The Capable Hub)
> <u.kleine-koenig@baylibre.com> wrote:
> > My additional motivation for this effort is CHERI[1]. This is a hardware
>
> Nice!
>
> > extension that uses 128 bit pointers but unsigned long is still 64 bit.
> > So with CHERI you cannot store pointers in unsigned long variables.
>
> Good luck fixing all implicit assumptions about this in the kernel!
> Also, good luck convincing people to use uintptr_t instead ;-)
>
> https://lore.kernel.org/all/CAHk-=wj2OHy-5e+srG1fy+ZU00TmZ1NFp6kFLbVLMXHe7A1d-g@mail.gmail.com
Yeah, I believe Linus will have a strong opinion about all this CHERI stuff :-)
But let see, it might be surprising turn around.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v6 4/5] ARM: dts: microchip: add I3C controller
From: Nicolas Ferre @ 2026-05-18 7:27 UTC (permalink / raw)
To: Manikandan M - I67131, Claudiu Beznea
Cc: alexandre.belloni@bootlin.com, Frank.Li@nxp.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, linux@armlinux.org.uk,
mturquette@baylibre.com, sboyd@kernel.org, tytso@mit.edu,
Aubin Constans - M51280, Ryan Wanner - C70674,
Romain Sioen - M70749, durai.manickamkr@microchip.com,
Cristian Birsan - M91496, adrian.hunter@intel.com,
jarkko.nikula@linux.intel.com, npitre@baylibre.com,
linux-i3c@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org
In-Reply-To: <515e89f3-fca9-477c-be4d-be9ed9428d5f@microchip.com>
On 18/05/2026 at 08:10, Manikandan M - I67131 wrote:
> Hi Claudiu,
>
> On 16/05/26 9:37 pm, Claudiu Beznea wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>> the content is safe
>>
>> Hi, Manikandan,
>>
>> On 5/7/26 11:48, Manikandan Muralidharan wrote:
>>> From: Durai Manickam KR <durai.manickamkr@microchip.com>
>>>
>>> Add I3C controller for sama7d65 SoC.
>>>
>>> Signed-off-by: Durai Manickam KR <durai.manickamkr@microchip.com>
>>> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
>>> ---
>>> Changes in v3:
>>> - Remove clock-names property as driver enables the clk in bulk
>>>
>>> arch/arm/boot/dts/microchip/sama7d65.dtsi | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi
>>> b/arch/arm/boot/dts/microchip/sama7d65.dtsi
>>> index 67253bbc08df..ec200848c153 100644
>>> --- a/arch/arm/boot/dts/microchip/sama7d65.dtsi
>>> +++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi
>>> @@ -1055,5 +1055,13 @@ gic: interrupt-controller@e8c11000 {
>>> #address-cells = <0>;
>>> interrupt-controller;
>>> };
>>> +
>>> + i3c: i3c@e9000000 {
>>> + compatible = "microchip,sama7d65-i3c-hci";
>>> + reg = <0xe9000000 0x300>;
>>
>> From manual at [1] I see the size of I3CC region is 0x1000. Unless that is
>> wrong I think we should use 0x1000 to properly describe de HW. Please
>> let me
>> know and I can do it while applying.
The memory map simply describes what is the next memory boundary
assigned (or void in this case), not the actual size of the IP user
interface.
So we took the opportunity to avoid mapping unused memory.
> According to Table 78.6 (Register Summary), the I3CC register space
> extends up to offset 0x258, Ideally the mapping should have been 0x400
The underlying memory mapping certainly does what is best, so I would
cling to being the closest to last register described. So your 0x300
value looks very good to me.
Best regards,
Nicolas
> (next power of 2 considering the memory region alignment), using 0x1000
> is also acceptable. Please advise which value is preferred.
>
>> Thank you,
>> Claudiu
>>
>> [1]
>> https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/DataSheets/SAMA7D6-Series-Data-Sheet-DS60001851.pdf
>>
>>> + interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
>>> + clocks = <&pmc PMC_TYPE_PERIPHERAL 105>, <&pmc
>>> PMC_TYPE_GCK 105>;
>>> + status = "disabled";
>>> + };
>>> };
>>> };
>>
>
^ permalink raw reply
* Re: [PATCH 0/8] iio: timestamp declaration cleanup
From: Andy Shevchenko @ 2026-05-18 7:26 UTC (permalink / raw)
To: David Lechner
Cc: Jyoti Bhayana, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Maxime Coquelin,
Alexandre Torgue, Benson Leung, Guenter Roeck, linux-iio,
linux-kernel, linux-arm-kernel, linux-stm32, chrome-platform
In-Reply-To: <20260517-iio-timestamp-cleanup-v1-0-61fb908c11c7@baylibre.com>
On Sun, May 17, 2026 at 01:17:17PM -0500, David Lechner wrote:
> While looking around the code, I noticed that there are a lot of places
> were we are manually filling all of the fields of an IIO timestamp.
>
> This is error-prone (as seen in the first patch) and more verbose than
> it needs to be.
>
> I went with the approach of using the existing IIO_CHAN_SOFT_TIMESTAMP()
> macro for doing a struct assignment. This does require a cast, which
> makes it a bit more verbose, but we were already doing that in to
> drivers, so I went with it anyway.
>
> If we want to consider alternatives, we could make a iio helper function
> or macro like the first and second patches did.
I like the series, just incorporate my patch, test and issue a v2, I will give
my tag.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2 2/2] PCI: imx6: Assert ref_clk_en after reference clock stabilizes on i.MX95
From: Richard Zhu @ 2026-05-18 7:27 UTC (permalink / raw)
To: frank.li, l.stach, lpieralisi, kwilczynski, mani, robh, bhelgaas,
s.hauer, kernel, festevam
Cc: linux-pci, linux-arm-kernel, imx, linux-kernel, Richard Zhu,
stable
In-Reply-To: <20260518072715.3166514-1-hongxing.zhu@nxp.com>
According to the PHY Databook Common Block Signals section, the
ref_clk_en signal must remain de-asserted until the reference clock is
running at the appropriate frequency. Once the clock is stable,
ref_clk_en can be asserted. For lower power states where the reference
clock to the PHY is disabled, ref_clk_en should also be de-asserted.
Move the ref_clk_en bit manipulation into imx95_pcie_enable_ref_clk()
to ensure the reference clock stabilizes before ref_clk_en is asserted
and before the PHY reset is de-asserted. This aligns with the timing
requirements specified in the PHY documentation.
Fixes: d8574ce57d76 ("PCI: imx6: Add external reference clock input mode support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
drivers/pci/controller/dwc/pci-imx6.c | 28 +++++++++++++++++++++------
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 66e760015c92..c4b079c93648 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -270,8 +270,6 @@ static int imx95_pcie_init_pre_reset(struct imx_pcie *imx_pcie)
static int imx95_pcie_init_phy(struct imx_pcie *imx_pcie)
{
- bool ext = imx_pcie->enable_ext_refclk;
-
/*
* ERR051624: The Controller Without Vaux Cannot Exit L23 Ready
* Through Beacon or PERST# De-assertion
@@ -290,10 +288,6 @@ static int imx95_pcie_init_phy(struct imx_pcie *imx_pcie)
IMX95_PCIE_PHY_CR_PARA_SEL,
IMX95_PCIE_PHY_CR_PARA_SEL);
- regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_SS_RW_REG_0,
- IMX95_PCIE_REF_CLKEN,
- ext ? 0 : IMX95_PCIE_REF_CLKEN);
-
return 0;
}
@@ -742,7 +736,29 @@ static void imx95_pcie_clkreq_override(struct imx_pcie *imx_pcie, bool enable)
static int imx95_pcie_enable_ref_clk(struct imx_pcie *imx_pcie, bool enable)
{
+ bool ext = imx_pcie->enable_ext_refclk;
+
imx95_pcie_clkreq_override(imx_pcie, enable);
+ /*
+ * The ref_clk_en signal must remain de-asserted until the
+ * reference clock is running at appropriate frequency, at which
+ * point this bit can be asserted. For lower power states where
+ * the reference clock to the PHY is disabled, it may also be
+ * de-asserted.
+ * +------------------- -+--------+----------------+
+ * | External clock mode | Enable | PCIE_REF_CLKEN |
+ * +---------------------+--------+----------------+
+ * | TRUE | X | 1b'0 |
+ * +---------------------+--------+----------------+
+ * | FALSE | TRUE | 1b'1 |
+ * +---------------------+--------+----------------+
+ * | FALSE | FALSE | 1b'0 |
+ * +---------------------+--------+----------------+
+ */
+ regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_SS_RW_REG_0,
+ IMX95_PCIE_REF_CLKEN,
+ ext || !enable ? 0 : IMX95_PCIE_REF_CLKEN);
+
return 0;
}
--
2.37.1
^ permalink raw reply related
* [PATCH v2 1/2] PCI: imx6: Configure REF_USE_PAD before PHY reset for i.MX95
From: Richard Zhu @ 2026-05-18 7:27 UTC (permalink / raw)
To: frank.li, l.stach, lpieralisi, kwilczynski, mani, robh, bhelgaas,
s.hauer, kernel, festevam
Cc: linux-pci, linux-arm-kernel, imx, linux-kernel, Richard Zhu,
stable, Frank Li
In-Reply-To: <20260518072715.3166514-1-hongxing.zhu@nxp.com>
According to the i.MX95 PCIe PHY Databook, the ref_use_pad signal in the
Common Block Signals section selects the reference clock source connected
to the PHY pads. Per the specification, any change to this input must be
followed by a PHY reset assertion to take effect.
Move the REF_USE_PAD configuration before the PHY reset toggle to comply
with the required initialization sequence.
Fixes: 47f54a902dcd ("PCI: imx6: Toggle the core reset for i.MX95 PCIe")
Cc: <stable@vger.kernel.org>
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
drivers/pci/controller/dwc/pci-imx6.c | 27 ++++++++++++++++++++++++---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 002e0a0d9382..66e760015c92 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -138,6 +138,7 @@ struct imx_pcie_drvdata {
const u32 mode_off[IMX_PCIE_MAX_INSTANCES];
const u32 mode_mask[IMX_PCIE_MAX_INSTANCES];
const struct pci_epc_features *epc_features;
+ int (*init_pre_reset)(struct imx_pcie *pcie);
int (*init_phy)(struct imx_pcie *pcie);
int (*enable_ref_clk)(struct imx_pcie *pcie, bool enable);
int (*core_reset)(struct imx_pcie *pcie, bool assert);
@@ -249,6 +250,24 @@ static unsigned int imx_pcie_grp_offset(const struct imx_pcie *imx_pcie)
return imx_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
}
+static int imx95_pcie_init_pre_reset(struct imx_pcie *imx_pcie)
+{
+ bool ext = imx_pcie->enable_ext_refclk;
+
+ /*
+ * Regarding the Signal Descriptions of i.MX95 PCIe PHY, ref_use_pad is
+ * used to select reference clock connected to a pair of pads.
+ *
+ * Any change in this input must be followed by phy_reset assertion.
+ */
+
+ regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_PHY_GEN_CTRL,
+ IMX95_PCIE_REF_USE_PAD,
+ ext ? IMX95_PCIE_REF_USE_PAD : 0);
+
+ return 0;
+}
+
static int imx95_pcie_init_phy(struct imx_pcie *imx_pcie)
{
bool ext = imx_pcie->enable_ext_refclk;
@@ -271,9 +290,6 @@ static int imx95_pcie_init_phy(struct imx_pcie *imx_pcie)
IMX95_PCIE_PHY_CR_PARA_SEL,
IMX95_PCIE_PHY_CR_PARA_SEL);
- regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_PHY_GEN_CTRL,
- IMX95_PCIE_REF_USE_PAD,
- ext ? IMX95_PCIE_REF_USE_PAD : 0);
regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_SS_RW_REG_0,
IMX95_PCIE_REF_CLKEN,
ext ? 0 : IMX95_PCIE_REF_CLKEN);
@@ -1348,6 +1364,9 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
pp->bridge->disable_device = imx_pcie_disable_device;
}
+ if (imx_pcie->drvdata->init_pre_reset)
+ imx_pcie->drvdata->init_pre_reset(imx_pcie);
+
imx_pcie_assert_core_reset(imx_pcie);
if (imx_pcie->drvdata->init_phy)
@@ -2047,6 +2066,7 @@ static const struct imx_pcie_drvdata drvdata[] = {
.mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
.core_reset = imx95_pcie_core_reset,
.init_phy = imx95_pcie_init_phy,
+ .init_pre_reset = imx95_pcie_init_pre_reset,
.wait_pll_lock = imx95_pcie_wait_for_phy_pll_lock,
.enable_ref_clk = imx95_pcie_enable_ref_clk,
.clr_clkreq_override = imx95_pcie_clr_clkreq_override,
@@ -2102,6 +2122,7 @@ static const struct imx_pcie_drvdata drvdata[] = {
.ltssm_mask = IMX95_PCIE_LTSSM_EN,
.mode_off[0] = IMX95_PE0_GEN_CTRL_1,
.mode_mask[0] = IMX95_PCIE_DEVICE_TYPE,
+ .init_pre_reset = imx95_pcie_init_pre_reset,
.init_phy = imx95_pcie_init_phy,
.core_reset = imx95_pcie_core_reset,
.wait_pll_lock = imx95_pcie_wait_for_phy_pll_lock,
base-commit: 40b7f61a1a4d7fd18188f3f87e15ff5a90ce1d31
--
2.37.1
^ permalink raw reply related
* [PATCH v2 0/2] PCI: imx6: Fix i.MX95 PCIe PHY initialization sequence
From: Richard Zhu @ 2026-05-18 7:27 UTC (permalink / raw)
To: frank.li, l.stach, lpieralisi, kwilczynski, mani, robh, bhelgaas,
s.hauer, kernel, festevam
Cc: linux-pci, linux-arm-kernel, imx, linux-kernel
This series addresses PHY initialization sequence issues for i.MX95 PCIe
that were identified through careful review of the i.MX95 PCIe PHY Databook.
The current implementation does not strictly follow the timing requirements
specified in the PHY documentation for reference clock configuration and
PHY reset sequencing. These violations can potentially lead to unreliable
PHY initialization.
Patch 1 ensures that the REF_USE_PAD configuration is applied before the
PHY reset is toggled, as required by the Common Block Signals specification.
Any change to ref_use_pad must be followed by a PHY reset assertion to take
effect properly.
Patch 2 corrects the ref_clk_en signal timing by moving its manipulation
into the reference clock enable function. This ensures the reference clock
is stable before ref_clk_en is asserted and before the PHY reset is
de-asserted, meeting the PHY's power sequencing requirements.
Together, these patches ensure proper PHY initialization sequence compliance
and improve the reliability of PCIe operation on i.MX95 platforms.
Changes in v2:
Correct the register when configure REF_USE_PAD bit.
Rebase to controller/dwc-imx6 branch of pci git repo.
Collect the Reviewed-by tag.
[PATCH v2 1/2] PCI: imx6: Configure REF_USE_PAD before PHY reset for
[PATCH v2 2/2] PCI: imx6: Assert ref_clk_en after reference clock
drivers/pci/controller/dwc/pci-imx6.c | 53 +++++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 45 insertions(+), 8 deletions(-)
^ permalink raw reply
* Re: [PATCH 0/8] iio: timestamp declaration cleanup
From: Andy Shevchenko @ 2026-05-18 7:23 UTC (permalink / raw)
To: David Lechner
Cc: Jyoti Bhayana, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Maxime Coquelin,
Alexandre Torgue, Benson Leung, Guenter Roeck, linux-iio,
linux-kernel, linux-arm-kernel, linux-stm32, chrome-platform
In-Reply-To: <83c11e2c-9688-4cc9-b7ee-6380de30fb58@baylibre.com>
On Sun, May 17, 2026 at 02:22:03PM -0500, David Lechner wrote:
> On 5/17/26 1:17 PM, David Lechner wrote:
> > While looking around the code, I noticed that there are a lot of places
> > were we are manually filling all of the fields of an IIO timestamp.
> >
> > This is error-prone (as seen in the first patch) and more verbose than
> > it needs to be.
> >
> > I went with the approach of using the existing IIO_CHAN_SOFT_TIMESTAMP()
> > macro for doing a struct assignment. This does require a cast, which
> > makes it a bit more verbose, but we were already doing that in to
> > drivers, so I went with it anyway.
> >
> > If we want to consider alternatives, we could make a iio helper function
> > or macro like the first and second patches did.
> >
> I should have looked harder for existing alternatives. Just found one
> more that avoids the cast via a local variable (in ad4170-4.c):
>
> /* Add timestamp channel */
> struct iio_chan_spec ts_chan = IIO_CHAN_SOFT_TIMESTAMP(chan_num);
>
> st->chans[chan_num] = ts_chan;
>
> And similar code is found in ad7192.c.
See my patch. The above with my patch applied can be simplified to the
inline use.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [RFC PATCH 1/2] KVM: arm64: Introduce S2 walker SKIP return options
From: Oliver Upton @ 2026-05-18 7:22 UTC (permalink / raw)
To: Leonardo Bras
Cc: Marc Zyngier, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Fuad Tabba, Raghavendra Rao Ananta,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <20260515195904.2466381-2-leo.bras@arm.com>
Hi Leo,
Thanks for having a look at this.
On Fri, May 15, 2026 at 08:59:02PM +0100, Leonardo Bras wrote:
> Introduce S2 walker return values:
> - SKIP_CHILDREN: skip walking the children of the current node
> - SKIP_SIBLINGS: skip waling the siblings of the current node
>
> Also, modify __kvm_pgtable_visit() to fulfil the hing on above return
> values. Current walkers should not be impacted
I'd rather see something based around new walk flags than introducing an
entirely new mechanic around return values.
e.g. you could split the LEAF flag into separate flags for blocks v.
pages:
KVM_PGTABLE_WALK_PAGE,
KVM_PGTABLE_WALK_BLOCK,
KVM_PGTABLE_WALK_LEAF = KVM_PGTABLE_WALK_PAGE |
KVM_PGTABLE_WALK_BLOCK,
and then let __kvm_pgtable_visit() decide how to steer the walk. You may
need some special handling to get the address arithmetic right when
skipping over a table of page descriptors.
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH 7/8] sched_ext: Sub-allocator over kernel-claimed BPF arena pages
From: Peter Zijlstra @ 2026-05-18 7:20 UTC (permalink / raw)
To: Tejun Heo
Cc: David Vernet, Andrea Righi, Changwoo Min, Alexei Starovoitov,
Andrii Nakryiko, Daniel Borkmann, Martin KaFai Lau,
Kumar Kartikeya Dwivedi, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Andrew Morton, David Hildenbrand, Mike Rapoport, Emil Tsalapatis,
sched-ext, bpf, x86, linux-arm-kernel, linux-mm, linux-kernel
In-Reply-To: <20260517211232.1670594-8-tj@kernel.org>
On Sun, May 17, 2026 at 11:12:31AM -1000, Tejun Heo wrote:
> Build a per-scheduler sub-allocator on top of pages claimed from the BPF
> arena registered in the previous patch. Subsequent kernel-managed
> arena-resident structures (e.g. per-CPU set_cmask cmask) carve their storage
> from this pool.
>
> scx_arena_pool_init() creates a gen_pool. scx_arena_alloc() returns the
> kernel VA. On exhaustion, the pool grows by claiming more pages via
> bpf_arena_alloc_pages_sleepable(). Chunks are added at the kernel-side
> mapping address; callers translate to the BPF-arena form themselves if
> needed.
>
> Allocations sleep (GFP_KERNEL) - they may grow the pool through vzalloc and
> arena page allocation. All current consumers run from the enable path (after
> ops.init() and the kernel-side arena auto-discovery, before validate_ops()),
> where sleeping is fine.
>
> scx_arena_pool_destroy() walks each chunk, returns outstanding ranges to the
> gen_pool with gen_pool_free() and then calls gen_pool_destroy(). The
> underlying arena pages are released when the arena map itself is torn down,
> so the pool destroy doesn't free them explicitly.
Should this really be part of scx rather than be part of the bpf-arena
thing proper?
^ permalink raw reply
* Re: [PATCH v2] tty: serial: atmel: Ignore chars when CREAD is cleared
From: Richard GENOUD @ 2026-05-18 7:20 UTC (permalink / raw)
To: Rakesh Alasyam, gregkh
Cc: richard.genoud, jirislaby, nicolas.ferre, alexandre.belloni,
claudiu.beznea, linux-serial, linux-kernel, linux-arm-kernel
In-Reply-To: <20260511165913.36467-1-alasyamrakesh77@gmail.com>
Hi Rakesh,
Le 11/05/2026 à 18:59, Rakesh Alasyam a écrit :
> Ignore received characters when CREAD is cleared by adding RXRDY
> to ignore_status_mask.
>
> This replaces an existing TODO in the driver.
>
> Tested on hardware.
Could you be more precise?
Which board(s) did you test with? (e.g. sama5d3_explained, custom...)
Which SoC? (sam9g35, sama5d2...)
With DMA, PDC or none?
Regards,
Richard
>
> Signed-off-by: Rakesh Alasyam <alasyamrakesh77@gmail.com>
>
> ---
>
> v2:
> - Add blank line before comment
> - Tested on hardware
> ---
> drivers/tty/serial/atmel_serial.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 5d8c1cfc1c60..5c756dc904b0 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -2184,7 +2184,8 @@ static void atmel_set_termios(struct uart_port *port,
> if (termios->c_iflag & IGNPAR)
> port->ignore_status_mask |= ATMEL_US_OVRE;
> }
> - /* TODO: Ignore all characters if CREAD is set.*/
> + if (!(termios->c_cflag & CREAD))
> + port->ignore_status_mask |= ATMEL_US_RXRDY;
>
> /* update the per-port timeout */
> uart_update_timeout(port, termios->c_cflag, baud);
^ permalink raw reply
* Re: [PATCH v4 2/2] ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC
From: Andrew Jeffery @ 2026-05-18 7:18 UTC (permalink / raw)
To: Kyle Hsieh, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20260424-ventura2_initial_dts-v4-2-806b00ea4314@gmail.com>
Hi Kyle,
Firstly, are you trying to represent multiple revisions of the hardware
design in this devicetree? I'm curious due to the 'legacy' labels
below.
On Fri, 2026-04-24 at 17:30 +0800, Kyle Hsieh wrote:
> Add linux device tree entry related to the Meta(Facebook) rmc-node.
> The system use an AT2600 BMC.
> This node is named "ventura2".
>
> Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
> ---
> arch/arm/boot/dts/aspeed/Makefile | 1 +
> .../dts/aspeed/aspeed-bmc-facebook-ventura2.dts | 2925 ++++++++++++++++++++
> 2 files changed, 2926 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
> index 9adf9278dc94..6b96997629d4 100644
> --- a/arch/arm/boot/dts/aspeed/Makefile
> +++ b/arch/arm/boot/dts/aspeed/Makefile
> @@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
> aspeed-bmc-facebook-minipack.dtb \
> aspeed-bmc-facebook-santabarbara.dtb \
> aspeed-bmc-facebook-tiogapass.dtb \
> + aspeed-bmc-facebook-ventura2.dtb \
> aspeed-bmc-facebook-wedge40.dtb \
> aspeed-bmc-facebook-wedge100.dtb \
> aspeed-bmc-facebook-wedge400-data64.dtb \
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts
> new file mode 100644
> index 000000000000..8d4ddb473862
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts
> @@ -0,0 +1,2925 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2023 Facebook Inc.
> +/dts-v1/;
> +
> +#include "aspeed-g6.dtsi"
> +#include <dt-bindings/i2c/i2c.h>
> +#include <dt-bindings/gpio/aspeed-gpio.h>
> +
> +/ {
> + model = "Facebook Ventura2 RMC";
> + compatible = "facebook,ventura2-rmc", "aspeed,ast2600";
> + aliases {
> + serial2 = &uart3;
> + serial4 = &uart5;
> +
> + /*
> + * i2c switch 0-0077, pca9548, 8 child channels assigned
> + * with bus number 16-23.
> + */
> + i2c16 = &i2c0mux0ch0;
> + i2c17 = &i2c0mux0ch1;
> + i2c18 = &i2c0mux0ch2;
> + i2c19 = &i2c0mux0ch3;
> + i2c20 = &i2c0mux0ch4;
> + i2c21 = &i2c0mux0ch5;
> + i2c22 = &i2c0mux0ch6;
> + i2c23 = &i2c0mux0ch7;
> +
> + /*
> + * i2c switch 1-0077, pca9548, 8 child channels assigned
> + * with bus number 24-31.
> + */
> + i2c24 = &i2c1mux0ch0;
> + i2c25 = &i2c1mux0ch1;
> + i2c26 = &i2c1mux0ch2;
> + i2c27 = &i2c1mux0ch3;
> + i2c28 = &i2c1mux0ch4;
> + i2c29 = &i2c1mux0ch5;
> + i2c30 = &i2c1mux0ch6;
> + i2c31 = &i2c1mux0ch7;
> +
> + /*
> + * i2c switch 4-0077, pca9548, 8 child channels assigned
> + * with bus number 32-39.
> + */
> + i2c32 = &i2c4mux0ch0;
> + i2c33 = &i2c4mux0ch1;
> + i2c34 = &i2c4mux0ch2;
> + i2c35 = &i2c4mux0ch3;
> + i2c36 = &i2c4mux0ch4;
> + i2c37 = &i2c4mux0ch5;
> + i2c38 = &i2c4mux0ch6;
> + i2c39 = &i2c4mux0ch7;
> +
> + /*
> + * i2c switch 5-0077, pca9548, 8 child channels assigned
> + * with bus number 40-47.
> + */
> + i2c40 = &i2c5mux0ch0;
> + i2c41 = &i2c5mux0ch1;
> + i2c42 = &i2c5mux0ch2;
> + i2c43 = &i2c5mux0ch3;
> + i2c44 = &i2c5mux0ch4;
> + i2c45 = &i2c5mux0ch5;
> + i2c46 = &i2c5mux0ch6;
> + i2c47 = &i2c5mux0ch7;
> +
> + /*
> + * i2c switch 8-0077, pca9548, 8 child channels assigned
> + * with bus number 48-55.
> + */
> + i2c48 = &i2c8mux0ch0;
> + i2c49 = &i2c8mux0ch1;
> + i2c50 = &i2c8mux0ch2;
> + i2c51 = &i2c8mux0ch3;
> + i2c52 = &i2c8mux0ch4;
> + i2c53 = &i2c8mux0ch5;
> + i2c54 = &i2c8mux0ch6;
> + i2c55 = &i2c8mux0ch7;
> +
> + /*
> + * i2c switch 11-0077, pca9548, 8 child channels assigned
> + * with bus number 56-63.
> + */
> + i2c56 = &i2c11mux0ch0;
> + i2c57 = &i2c11mux0ch1;
> + i2c58 = &i2c11mux0ch2;
> + i2c59 = &i2c11mux0ch3;
> + i2c60 = &i2c11mux0ch4;
> + i2c61 = &i2c11mux0ch5;
> + i2c62 = &i2c11mux0ch6;
> + i2c63 = &i2c11mux0ch7;
> +
> + /*
> + * i2c switch 13-0077, pca9548, 8 child channels assigned
> + * with bus number 64-71.
> + */
> + i2c64 = &i2c13mux0ch0;
> + i2c65 = &i2c13mux0ch1;
> + i2c66 = &i2c13mux0ch2;
> + i2c67 = &i2c13mux0ch3;
> + i2c68 = &i2c13mux0ch4;
> + i2c69 = &i2c13mux0ch5;
> + i2c70 = &i2c13mux0ch6;
> + i2c71 = &i2c13mux0ch7;
> +
> + /*
> + * i2c switch 15-0077, pca9548, 8 child channels assigned
> + * with bus number 72-79.
> + */
> + i2c72 = &i2c15mux0ch0;
> + i2c73 = &i2c15mux0ch1;
> + i2c74 = &i2c15mux0ch2;
> + i2c75 = &i2c15mux0ch3;
> + i2c76 = &i2c15mux0ch4;
> + i2c77 = &i2c15mux0ch5;
> + i2c78 = &i2c15mux0ch6;
> + i2c79 = &i2c15mux0ch7;
Can you please add comments justifying why all of these aliases are
necessary given a number of them are for busses with no devices
described under them?
> + };
> +
> + chosen {
> + stdout-path = "serial4:57600n8";
> + };
> +
> + fan_leds {
> + compatible = "gpio-leds";
> +
> + led-0 {
> + label = "fcb0fan0_ledd1_blue";
Given the labels are exposed to userspace and is something applications
likely consume, is the double 'd' in led intentional?
> + default-state = "off";
> + gpios = <&fan_io_expander0 0 GPIO_ACTIVE_LOW>;
> + };
> +
> + led-1 {
> + label = "fcb0fan1_ledd2_blue";
> + default-state = "off";
> + gpios = <&fan_io_expander0 1 GPIO_ACTIVE_LOW>;
> + };
> +
> + led-2 {
> + label = "fcb0fan2_ledd3_blue";
> + default-state = "off";
> + gpios = <&fan_io_expander1 0 GPIO_ACTIVE_LOW>;
> + };
> +
> + led-3 {
> + label = "fcb0fan3_ledd4_blue";
> + default-state = "off";
> + gpios = <&fan_io_expander1 1 GPIO_ACTIVE_LOW>;
> + };
> +
> + led-4 {
> + label = "fcb0fan0_ledd1_amber";
> + default-state = "off";
> + gpios = <&fan_io_expander0 4 GPIO_ACTIVE_LOW>;
> + };
> +
> + led-5 {
> + label = "fcb0fan1_ledd2_amber";
> + default-state = "off";
> + gpios = <&fan_io_expander0 5 GPIO_ACTIVE_LOW>;
> + };
> +
> + led-6 {
> + label = "fcb0fan2_ledd3_amber";
> + default-state = "off";
> + gpios = <&fan_io_expander1 4 GPIO_ACTIVE_LOW>;
> + };
> +
> + led-7 {
> + label = "fcb0fan3_ledd4_amber";
> + default-state = "off";
> + gpios = <&fan_io_expander1 5 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
...
> +
> +&fmc {
> + status = "okay";
> + flash@0 {
> + status = "okay";
> + m25p,fast-read;
> + label = "bmc";
> + spi-max-frequency = <50000000>;
> + #include "openbmc-flash-layout-128.dtsi"
> + };
> + flash@1 {
> + status = "okay";
> + m25p,fast-read;
> + label = "alt-bmc";
> + spi-max-frequency = <50000000>;
Perhaps include the alternate flash layout dtsi here?
> + };
> +};
> +
> +&peci0 {
Can you please order the nodes alphabetically. P is not between F and
G.
> + status = "okay";
> +};
> +
>
...
> +
> +&i2c10 {
> + status = "okay";
> +
> + legacy_prsnt_io_expander0: gpio@11 {
Why 'legacy'?
> + compatible = "nxp,pca9555";
> + reg = <0x11>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <&sgpiom0>;
> + interrupts = <40 IRQ_TYPE_LEVEL_LOW>;
> +
> + gpio-line-names =
> + "TRAY_PRSNT1_N_BUF_R", "TRAY_PRSNT2_N_BUF_R",
> + "TRAY_PRSNT3_N_BUF_R", "TRAY_PRSNT4_N_BUF_R",
> + "TRAY_PRSNT5_N_BUF_R", "TRAY_PRSNT6_N_BUF_R",
> + "TRAY_PRSNT7_N_BUF_R", "TRAY_PRSNT8_N_BUF_R",
> + "TRAY_PRSNT9_N_BUF_R", "TRAY_PRSNT10_N_BUF_R",
> + "TRAY_PRSNT11_N_BUF_R", "TRAY_PRSNT12_N_BUF_R",
> + "TRAY_PRSNT13_N_BUF_R", "TRAY_PRSNT14_N_BUF_R",
> + "TRAY_PRSNT15_N_BUF_R", "TRAY_PRSNT16_N_BUF_R";
> + };
> +
> + legacy_prsnt_io_expander1: gpio@12 {
> + compatible = "nxp,pca9555";
> + reg = <0x12>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <&sgpiom0>;
> + interrupts = <40 IRQ_TYPE_LEVEL_LOW>;
> +
> + gpio-line-names =
> + "TRAY_PRSNT17_N_BUF_R", "TRAY_PRSNT18_N_BUF_R",
> + "TRAY_PRSNT19_N_BUF_R", "TRAY_PRSNT20_N_BUF_R",
> + "TRAY_PRSNT21_N_BUF_R", "TRAY_PRSNT22_N_BUF_R",
> + "TRAY_PRSNT23_N_BUF_R", "TRAY_PRSNT24_N_BUF_R",
> + "TRAY_PRSNT25_N_BUF_R", "TRAY_PRSNT26_N_BUF_R",
> + "TRAY_PRSNT27_N_BUF_R", "TRAY_PRSNT28_N_BUF_R",
> + "TRAY_PRSNT29_N_BUF_R", "TRAY_PRSNT30_N_BUF_R",
> + "TRAY_PRSNT31_N_BUF_R", "TRAY_PRSNT32_N_BUF_R";
> + };
> +
> + legacy_prsnt_io_expander2: gpio@13 {
> + compatible = "nxp,pca9555";
> + reg = <0x13>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <&sgpiom0>;
> + interrupts = <40 IRQ_TYPE_LEVEL_LOW>;
> +
> + gpio-line-names =
> + "TRAY_PRSNT33_N_BUF_R", "TRAY_PRSNT34_N_BUF_R",
> + "TRAY_PRSNT35_N_BUF_R", "TRAY_PRSNT36_N_BUF_R",
> + "TRAY_PRSNT37_N_BUF_R", "TRAY_PRSNT38_N_BUF_R",
> + "TRAY_PRSNT39_N_BUF_R", "TRAY_PRSNT40_N_BUF_R",
> + "", "",
> + "", "",
> + "", "",
> + "", "";
> + };
> +
> + power-monitor@14 {
> + compatible = "infineon,xdp710";
> + reg = <0x14>;
> + };
> +
> + legacy_pwrgd_io_expander1: gpio@15 {
> + compatible = "nxp,pca9555";
> + reg = <0x15>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <&sgpiom0>;
> + interrupts = <42 IRQ_TYPE_LEVEL_LOW>;
> +
> + gpio-line-names =
> + "TRAY_PWRGD17_N_BUF_R", "TRAY_PWRGD18_N_BUF_R",
> + "TRAY_PWRGD19_N_BUF_R", "TRAY_PWRGD20_N_BUF_R",
> + "TRAY_PWRGD21_N_BUF_R", "TRAY_PWRGD22_N_BUF_R",
> + "TRAY_PWRGD23_N_BUF_R", "TRAY_PWRGD24_N_BUF_R",
> + "TRAY_PWRGD25_N_BUF_R", "TRAY_PWRGD26_N_BUF_R",
> + "TRAY_PWRGD27_N_BUF_R", "TRAY_PWRGD28_N_BUF_R",
> + "TRAY_PWRGD29_N_BUF_R", "TRAY_PWRGD30_N_BUF_R",
> + "TRAY_PWRGD31_N_BUF_R", "TRAY_PWRGD32_N_BUF_R";
> + };
> +
> + legacy_pwrgd_io_expander2: gpio@16 {
> + compatible = "nxp,pca9555";
> + reg = <0x16>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <&sgpiom0>;
> + interrupts = <42 IRQ_TYPE_LEVEL_LOW>;
> +
> + gpio-line-names =
> + "TRAY_PWRGD33_N_BUF_R", "TRAY_PWRGD34_N_BUF_R",
> + "TRAY_PWRGD35_N_BUF_R", "TRAY_PWRGD36_N_BUF_R",
> + "TRAY_PWRGD37_N_BUF_R", "TRAY_PWRGD38_N_BUF_R",
> + "TRAY_PWRGD39_N_BUF_R", "TRAY_PWRGD40_N_BUF_R",
> + "", "",
> + "", "",
> + "", "",
> + "", "";
> + };
> +
> + legacy_leak_io_expander0: gpio@17 {
> + compatible = "nxp,pca9555";
> + reg = <0x17>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <&sgpiom0>;
> + interrupts = <46 IRQ_TYPE_LEVEL_LOW>;
> +
> + gpio-line-names =
> + "TRAY_LEAK_DETECT1_N_BUF_R", "TRAY_LEAK_DETECT2_N_BUF_R",
> + "TRAY_LEAK_DETECT3_N_BUF_R", "TRAY_LEAK_DETECT4_N_BUF_R",
> + "TRAY_LEAK_DETECT5_N_BUF_R", "TRAY_LEAK_DETECT6_N_BUF_R",
> + "TRAY_LEAK_DETECT7_N_BUF_R", "TRAY_LEAK_DETECT8_N_BUF_R",
> + "TRAY_LEAK_DETECT9_N_BUF_R", "TRAY_LEAK_DETECT10_N_BUF_R",
> + "TRAY_LEAK_DETECT11_N_BUF_R", "TRAY_LEAK_DETECT12_N_BUF_R",
> + "TRAY_LEAK_DETECT13_N_BUF_R", "TRAY_LEAK_DETECT14_N_BUF_R",
> + "TRAY_LEAK_DETECT15_N_BUF_R", "TRAY_LEAK_DETECT16_N_BUF_R";
> + };
> +
> + legacy_leak_io_expander1: gpio@18 {
> + compatible = "nxp,pca9555";
> + reg = <0x18>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <&sgpiom0>;
> + interrupts = <46 IRQ_TYPE_LEVEL_LOW>;
> +
> + gpio-line-names =
> + "TRAY_LEAK_DETECT17_N_BUF_R", "TRAY_LEAK_DETECT18_N_BUF_R",
> + "TRAY_LEAK_DETECT19_N_BUF_R", "TRAY_LEAK_DETECT20_N_BUF_R",
> + "TRAY_LEAK_DETECT21_N_BUF_R", "TRAY_LEAK_DETECT22_N_BUF_R",
> + "TRAY_LEAK_DETECT23_N_BUF_R", "TRAY_LEAK_DETECT24_N_BUF_R",
> + "TRAY_LEAK_DETECT25_N_BUF_R", "TRAY_LEAK_DETECT26_N_BUF_R",
> + "TRAY_LEAK_DETECT27_N_BUF_R", "TRAY_LEAK_DETECT28_N_BUF_R",
> + "TRAY_LEAK_DETECT29_N_BUF_R", "TRAY_LEAK_DETECT30_N_BUF_R",
> + "TRAY_LEAK_DETECT31_N_BUF_R", "TRAY_LEAK_DETECT32_N_BUF_R";
> + };
> +
> + legacy_leak_io_expander2: gpio@19 {
> + compatible = "nxp,pca9555";
> + reg = <0x19>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <&sgpiom0>;
> + interrupts = <46 IRQ_TYPE_LEVEL_LOW>;
> +
> + gpio-line-names =
> + "TRAY_LEAK_DETECT33_N_BUF_R", "TRAY_LEAK_DETECT34_N_BUF_R",
> + "TRAY_LEAK_DETECT35_N_BUF_R", "TRAY_LEAK_DETECT36_N_BUF_R",
> + "TRAY_LEAK_DETECT37_N_BUF_R", "TRAY_LEAK_DETECT38_N_BUF_R",
> + "TRAY_LEAK_DETECT39_N_BUF_R", "TRAY_LEAK_DETECT40_N_BUF_R",
> + "", "",
> + "", "",
> + "", "",
> + "", "";
> + };
> +
> + legacy_small_leak_io_expander0: gpio@1a {
> + compatible = "nxp,pca9555";
> + reg = <0x1a>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <&sgpiom0>;
> + interrupts = <44 IRQ_TYPE_LEVEL_LOW>;
> +
> + gpio-line-names =
> + "TRAY_SMALL_LEAK1_N_BUF_R", "TRAY_SMALL_LEAK2_N_BUF_R",
> + "TRAY_SMALL_LEAK3_N_BUF_R", "TRAY_SMALL_LEAK4_N_BUF_R",
> + "TRAY_SMALL_LEAK5_N_BUF_R", "TRAY_SMALL_LEAK6_N_BUF_R",
> + "TRAY_SMALL_LEAK7_N_BUF_R", "TRAY_SMALL_LEAK8_N_BUF_R",
> + "TRAY_SMALL_LEAK9_N_BUF_R", "TRAY_SMALL_LEAK10_N_BUF_R",
> + "TRAY_SMALL_LEAK11_N_BUF_R", "TRAY_SMALL_LEAK12_N_BUF_R",
> + "TRAY_SMALL_LEAK13_N_BUF_R", "TRAY_SMALL_LEAK14_N_BUF_R",
> + "TRAY_SMALL_LEAK15_N_BUF_R", "TRAY_SMALL_LEAK16_N_BUF_R";
> + };
> +
> + legacy_small_leak_io_expander1: gpio@1b {
> + compatible = "nxp,pca9555";
> + reg = <0x1b>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <&sgpiom0>;
> + interrupts = <44 IRQ_TYPE_LEVEL_LOW>;
> +
> + gpio-line-names =
> + "TRAY_SMALL_LEAK17_N_BUF_R", "TRAY_SMALL_LEAK18_N_BUF_R",
> + "TRAY_SMALL_LEAK19_N_BUF_R", "TRAY_SMALL_LEAK20_N_BUF_R",
> + "TRAY_SMALL_LEAK21_N_BUF_R", "TRAY_SMALL_LEAK22_N_BUF_R",
> + "TRAY_SMALL_LEAK23_N_BUF_R", "TRAY_SMALL_LEAK24_N_BUF_R",
> + "TRAY_SMALL_LEAK25_N_BUF_R", "TRAY_SMALL_LEAK26_N_BUF_R",
> + "TRAY_SMALL_LEAK27_N_BUF_R", "TRAY_SMALL_LEAK28_N_BUF_R",
> + "TRAY_SMALL_LEAK29_N_BUF_R", "TRAY_SMALL_LEAK30_N_BUF_R",
> + "TRAY_SMALL_LEAK31_N_BUF_R", "TRAY_SMALL_LEAK32_N_BUF_R";
> + };
> +
> + legacy_small_leak_io_expander2: gpio@1c {
> + compatible = "nxp,pca9555";
> + reg = <0x1c>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <&sgpiom0>;
> + interrupts = <44 IRQ_TYPE_LEVEL_LOW>;
> +
> + gpio-line-names =
> + "TRAY_SMALL_LEAK33_N_BUF_R", "TRAY_SMALL_LEAK34_N_BUF_R",
> + "TRAY_SMALL_LEAK35_N_BUF_R", "TRAY_SMALL_LEAK36_N_BUF_R",
> + "TRAY_SMALL_LEAK37_N_BUF_R", "TRAY_SMALL_LEAK38_N_BUF_R",
> + "TRAY_SMALL_LEAK39_N_BUF_R", "TRAY_SMALL_LEAK40_N_BUF_R",
> + "", "",
> + "", "",
> + "", "",
> + "", "";
> + };
> +
> + legacy_pwrgd_io_expander0: gpio@28 {
> + compatible = "nxp,pca9555";
> + reg = <0x28>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <&sgpiom0>;
> + interrupts = <42 IRQ_TYPE_LEVEL_LOW>;
> +
> + gpio-line-names =
> + "TRAY_PWRGD1_N_BUF_R", "TRAY_PWRGD2_N_BUF_R",
> + "TRAY_PWRGD3_N_BUF_R", "TRAY_PWRGD4_N_BUF_R",
> + "TRAY_PWRGD5_N_BUF_R", "TRAY_PWRGD6_N_BUF_R",
> + "TRAY_PWRGD7_N_BUF_R", "TRAY_PWRGD8_N_BUF_R",
> + "TRAY_PWRGD9_N_BUF_R", "TRAY_PWRGD10_N_BUF_R",
> + "TRAY_PWRGD11_N_BUF_R", "TRAY_PWRGD12_N_BUF_R",
> + "TRAY_PWRGD13_N_BUF_R", "TRAY_PWRGD14_N_BUF_R",
> + "TRAY_PWRGD15_N_BUF_R", "TRAY_PWRGD16_N_BUF_R";
> + };
> +
...
> +
> +&mdio0 {
> + status = "okay";
> +};
> +
> +&peci0 {
> + status = "okay";
> +};
Ah, so the earlier peci node is redundant. Can you please remove it?
Andrew
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: r8a78000: Describe all reserved memory
From: Geert Uytterhoeven @ 2026-05-18 7:18 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260517163212.18016-1-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Sun, 17 May 2026 at 18:32, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Fully describe all available DRAM in the DT, and describe regions which
> are not accessible because they are used by firmware in reserved-memory
> node.
>
> Replace first memory bank memory@60600000 with memory@40000000 and a
> 518 MiB long reserved-memory no-map subnode. This memory region is used
> by other cores in the system.
>
> Reserve 32 kiB of memory at 0x8c100000 for parameters shared by IPL,
> SCP, TFA BL31 and TEE.
>
> Reserve 512 kiB of memory at 0x8c200000 for TFA BL31. The upcoming
> upstream TFA 2.15 BL31 uses memory from 0x8c200000..0x8c242fff, the
> round up to 512 kiB is slight future proofing.
>
> Reserve 32 MiB of memory at 0x8c400000 for OPTEE-OS, which is the
> entire OPTEE-OS TZ protected DRAM area.
>
> Neither the TFA BL31 nor OPTEE-OS do modify the DT passed to Linux in
> any way with any new reserved-memory {} node to reserve memory areas
> used by the TFA BL31 or OPTEE-OS to prevent the next stage from using
> those areas, which lets Linux use all of the available DRAM as it is
> described in the DT that was passed in by U-Boot, including the areas
> that are newly utilized by TFA BL31 or OPTEE-OS.
>
> In case of high DRAM utilization, unless the memory used by TFA BL31
> or OPTEE-OS is properly reserved, Linux may use and corrupt the memory
> used by TFA BL31 or OPTEE-OS, which would lead to the system becoming
> unresponsive.
>
> Fixes: ad142a4ef710 ("arm64: dts: renesas: r8a78000: Add initial Ironhide board support")
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
> @@ -20,10 +20,9 @@ chosen {
> stdout-path = "serial0:1843200n8";
> };
>
> - memory@60600000 {
> + memory@40000000 {
> device_type = "memory";
> - /* first 518MiB is reserved for other purposes. */
> - reg = <0x0 0x60600000 0x0 0x5fa00000>;
> + reg = <0x0 0x40000000 0x0 0x80000000>;
> };
>
> memory@1080000000 {
> @@ -65,6 +64,36 @@ memory@1e00000000 {
> device_type = "memory";
> reg = <0x1e 0x00000000 0x1 0x00000000>;
> };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* First 518 MiB is reserved for other purposes. */
> + firmware@40000000 {
> + reg = <0x0 0x40000000 0x0 0x20600000>;
> + no-map;
> + };
> +
> + /* Parameters set by IPL. */
> + parameters@8c100000 {
> + reg = <0x0 0x8c100000 0x0 0x00008000>;
> + no-map;
> + };
> +
> + /* TFA BL31. */
> + tfa-bl31@8c200000 {
> + reg = <0x0 0x8c200000 0x0 0x00080000>;
> + no-map;
> + };
> +
> + /* TEE TZ DRAM. */
> + tee@8c400000 {
> + reg = <0x0 0x8c400000 0x0 0x02000000>;
> + no-map;
> + };
> + };
Shouldn't these reservations be added by the bootloader stack, when
passing the DTB to Linux?
> };
>
> &extal_clk {
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/3] memory: mtk-smi: Add a flag skip_rpm
From: Krzysztof Kozlowski @ 2026-05-18 7:18 UTC (permalink / raw)
To: Xueqi Zhang (张雪琦), robh@kernel.org,
matthias.bgg@gmail.com, Yong Wu (吴勇),
AngeloGioacchino Del Regno, conor+dt@kernel.org
Cc: Wendy-ST Lin (林詩庭),
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
Project_Global_Chrome_Upstream_Group, devicetree@vger.kernel.org
In-Reply-To: <198865fb3184926d0b1b4e4855b5f863ad0d6a20.camel@mediatek.com>
On 18/05/2026 09:16, Xueqi Zhang (张雪琦) wrote:
> Hi Angelo,
>
> First of all, please accept my apologies for the delayed response. I
> have been deeply occupied with MT8196 Aluminium pKVM SMMU and SMI
> related tasks recently.
>
How may times are you going to send it? I counted FOUR already!
https://lore.kernel.org/all/?q=%22Re%3A+%5BPATCH+2%2F3%5D+memory%3A+mtk-smi%3A+Add+a+flag+skip_rpm%22
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Boris Brezillon @ 2026-05-18 7:16 UTC (permalink / raw)
To: Chia-I Wu
Cc: Liviu Dudau, Marcin Ślusarz, Ketil Johnsen, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Steven Price, Daniel Almeida, Alice Ryhl,
Matthias Brugger, AngeloGioacchino Del Regno, dri-devel,
linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek, Florent Tomasin, nd
In-Reply-To: <CAPaKu7QC7FdjL6m_OSb+E5aYKs6bmT-9DAHc5PC=XctCmRph2Q@mail.gmail.com>
On Wed, 13 May 2026 12:31:32 -0700
Chia-I Wu <olvaffe@gmail.com> wrote:
> On Tue, May 12, 2026 at 8:39 AM Liviu Dudau <liviu.dudau@arm.com> wrote:
> >
> > On Tue, May 12, 2026 at 04:11:11PM +0200, Boris Brezillon wrote:
> > > On Tue, 12 May 2026 14:47:27 +0100
> > > Liviu Dudau <liviu.dudau@arm.com> wrote:
> > >
> > > > On Thu, May 07, 2026 at 01:53:56PM +0200, Boris Brezillon wrote:
> > > > > On Thu, 7 May 2026 11:02:26 +0200
> > > > > Marcin Ślusarz <marcin.slusarz@arm.com> wrote:
> > > > >
> > > > > > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote:
> > > > > > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev)
> > > > > > > > return ret;
> > > > > > > > }
> > > > > > > >
> > > > > > > > + /* If a protected heap name is specified but not found, defer the probe until created */
> > > > > > > > + if (protected_heap_name && strlen(protected_heap_name)) {
> > > > > > >
> > > > > > > Do we really need this strlen() > 0? Won't dma_heap_find() fail is the
> > > > > > > name is "" already?
> > > > > >
> > > > > > If dma_heap_find() will fail, then the whole probe with fail too.
> > > > > > This check prevents that.
> > > > >
> > > > > Yeah, that's also a questionable design choice. I mean, we can
> > > > > currently probe and boot the FW even though we never setup the
> > > > > protected FW sections, so why should we defer the probe here? Can't we
> > > > > just retry the next time a group with the protected bit is created and
> > > > > fail if we can find a protected heap?
> > > >
> > > > The problem we have with the current firmware is that it does a number of setup steps at "boot"
> > > > time only. One of the steps is preparing its internal structures for when it enters protected
> > > > mode and it stores them in the buffer passed in at firmware loading. We cannot later run the
> > > > process when we have a group with protected mode set.
> > >
> > > No, but we can force a full/slow reset and have that thing
> > > re-initialized, can't we? I mean, that's basically what we do when a
> > > fast reset fails: we re-initialize all the sections and reset again, at
> > > which point the FW should start from a fresh state, and be able to
> > > properly initialize the protected-related stuff if protected sections
> > > are populated. Am I missing something?
> >
> > Right, we can do that. For some reason I keep associating the reset with the
> > error handling and not with "normal" operations.
> I kind of hope we end up with either
>
> - panthor knows the exact heap to use and fails with EPROBE_DEFER if
> the heap is missing, or
> - panthor gets a dma-buf from userspace and does the full reset
> - userspace also needs to provide a dma-buf for each protected
> group for the suspend buffer
>
> than something in-between. The latter is more ad-hoc and basically
> kicks the issue to the userspace.
Indeed, the second option is more ad-hoc, but when you think about it,
userspace has to have this knowledge, because it needs to know the
dma-heap to use for buffer allocation that cross a device boundary
anyway. Think about frames produced by a video decoder, and composited
by the GPU into a protected scanout buffer that's passed to the KMS
device. Why would the GPU driver be source of truth when it comes to
choosing the heap to use to allocate protected buffers for the video
decoder or those used for the display?
>
> For the former, expressing the relation in DT seems to be the best,
> but only if possible :-). Otherwise, a kconfig option (instead of
> module param) should be easier to work with.
>
> Looking at the userspace implementation, can we also have an panthor
> ioctl to return the heap to userspace?
Yes, it's something we can add, but again, I'm questioning the
usefulness of this: how can we ensure the heap used by panthor to
allocate its protected FW buffers is suitable for scanout buffers
(buffers that can be used by display drivers). There needs to be a glue
leaving in usersland and taking the decision, and I'm not too sure
trusting any of the component in the chain (vdec, gpu, display) is the
right thing to do.
^ permalink raw reply
* Re: [PATCH 2/3] memory: mtk-smi: Add a flag skip_rpm
From: Xueqi Zhang (张雪琦) @ 2026-05-18 7:16 UTC (permalink / raw)
To: robh@kernel.org, matthias.bgg@gmail.com,
Yong Wu (吴勇), AngeloGioacchino Del Regno,
krzk@kernel.org, conor+dt@kernel.org
Cc: Wendy-ST Lin (林詩庭),
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
Project_Global_Chrome_Upstream_Group, devicetree@vger.kernel.org
In-Reply-To: <46e0e1f1-e094-40f9-99f9-22678bb40d39@collabora.com>
Hi Angelo,
First of all, please accept my apologies for the delayed response. I
have been deeply occupied with MT8196 Aluminium pKVM SMMU and SMI
related tasks recently.
Regarding your question, my previous description in the patch was not
accurate enough and may have caused some confusion. In fact, not
all SMI commons have their backup/restore handled by the RTFF
hardware. The SMI commons are distributed across various subsystems
(e.g., mminfra, venc, display, cam, etc.). Currently, only the SMI
common under the mminfra subsystem is backed up and restored by
the RTFF hardware.
Therefore, I believe adding a specific 'skip_rpm' flag is more
appropriate here. If we were to differentiate this based on a new
MTK_SMI_GEN3 type, it would imply that all SMI common modules of
that generation would skip the RPM operations, which is not the
intended behavior.
To make this clearer, I plan to update the commit message in the
next version as follows:
Subject: memory: mtk-smi: Add skip_rpm flag for certain MT8196 SMI
commons
Body:
On MT8196, certain SMI commons are backed up and restored by the RTFF
hardware rather than by software.
For these specific SMI commons, software-controlled register backup
and restore in the runtime callback is no longer necessary. Therefore,
introduce a 'skip_rpm' flag to bypass these redundant RPMoperations
for these SMI commons.
What do you think about this approach?
Thanks,
Xueqi
On Thu, 2025-03-20 at 13:11 +0100, AngeloGioacchino Del Regno wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> Il 20/03/25 08:36, Xueqi Zhang ha scritto:
> > MT8196 SMI commons is backed up/restored by RTFF HW.
> > It doesn't need SW control the register backup/store
> > in the runtime callback.Therefore, add a flag skip_rpm
> > to help skip RPM operations for SMI commons.
> >
> > Signed-off-by: Xueqi Zhang <xueqi.zhang@mediatek.com>
>
> So the MT8196 SMI common doesn't require any clocks?
>
> That's fine for me, but this looks bloody similar to MT6989's SMI
> common, which
> is SMI GEN3 and not GEN2....
>
> ....so, are you sure that you need a `skip_rpm` flag and not new
> MTK_SMI_GEN3 and
> MTK_SMI_GEN3_SUB_COMM types? :-)
>
> Regards,
> Angelo
>
> > ---
> > drivers/memory/mtk-smi.c | 11 ++++++++---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> > index a8f5467d6b31..b9affa3c3185 100644
> > --- a/drivers/memory/mtk-smi.c
> > +++ b/drivers/memory/mtk-smi.c
> > @@ -123,6 +123,7 @@ static const char * const mtk_smi_common_clks[]
> > = {"apb", "smi", "gals0", "gals1
> > struct mtk_smi_common_plat {
> > enum mtk_smi_type type;
> > bool has_gals;
> > + bool skip_rpm;
> > u32 bus_sel; /* Balance some larbs to
> > enter mmu0 or mmu1 */
> >
> > const struct mtk_smi_reg_pair *init;
> > @@ -547,6 +548,9 @@ static int mtk_smi_dts_clk_init(struct device
> > *dev, struct mtk_smi *smi,
> > {
> > int i, ret;
> >
> > + if (smi->plat->skip_rpm)
> > + return 0;
> > +
> > for (i = 0; i < clk_nr_required; i++)
> > smi->clks[i].id = clks[i];
> > ret = devm_clk_bulk_get(dev, clk_nr_required, smi->clks);
> > @@ -783,7 +787,7 @@ static int mtk_smi_common_probe(struct
> > platform_device *pdev)
> > common->dev = dev;
> > common->plat = of_device_get_match_data(dev);
> >
> > - if (common->plat->has_gals) {
> > + if (!common->plat->skip_rpm && common->plat->has_gals) {
> > if (common->plat->type == MTK_SMI_GEN2)
> > clk_required = MTK_SMI_COM_GALS_REQ_CLK_NR;
> > else if (common->plat->type == MTK_SMI_GEN2_SUB_COMM)
> > @@ -814,13 +818,14 @@ static int mtk_smi_common_probe(struct
> > platform_device *pdev)
> > }
> >
> > /* link its smi-common if this is smi-sub-common */
> > - if (common->plat->type == MTK_SMI_GEN2_SUB_COMM) {
> > + if (common->plat->type == MTK_SMI_GEN2_SUB_COMM && !common-
> > >plat->skip_rpm) {
> > ret = mtk_smi_device_link_common(dev, &common-
> > >smi_common_dev);
> > if (ret < 0)
> > return ret;
> > }
> >
> > - pm_runtime_enable(dev);
> > + if (!common->plat->skip_rpm)
> > + pm_runtime_enable(dev);
> > platform_set_drvdata(pdev, common);
> > return 0;
> > }
>
>
^ permalink raw reply
* Re: [PATCH 0/8] iio: timestamp declaration cleanup
From: Andy Shevchenko @ 2026-05-18 7:14 UTC (permalink / raw)
To: David Lechner
Cc: Jyoti Bhayana, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Maxime Coquelin,
Alexandre Torgue, Benson Leung, Guenter Roeck, linux-iio,
linux-kernel, linux-arm-kernel, linux-stm32, chrome-platform
In-Reply-To: <agq7PPw0qupI_8Dh@ashevche-desk.local>
On Mon, May 18, 2026 at 10:09:48AM +0300, Andy Shevchenko wrote:
> On Sun, May 17, 2026 at 01:17:17PM -0500, David Lechner wrote:
> > While looking around the code, I noticed that there are a lot of places
> > were we are manually filling all of the fields of an IIO timestamp.
> >
> > This is error-prone (as seen in the first patch) and more verbose than
> > it needs to be.
> >
> > I went with the approach of using the existing IIO_CHAN_SOFT_TIMESTAMP()
> > macro for doing a struct assignment. This does require a cast, which
>
> No, it's *not* a cast. It's a compound literal. And instead of doing this in
> every driver, add it to the macro (in a separate patch). Oh, let me just cook
> it for you (I added that to several cases in the past).
20260518071349.469748-1-andriy.shevchenko@linux.intel.com
> > makes it a bit more verbose, but we were already doing that in to
> > drivers, so I went with it anyway.
>
> > If we want to consider alternatives, we could make a iio helper function
> > or macro like the first and second patches did.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox