* 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
* Re: [PATCH 2/3] memory: mtk-smi: Add a flag skip_rpm
From: Xueqi Zhang (张雪琦) @ 2026-05-18 7:13 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?
For reference, here is the link to the patch series on Patchwork:
https://patchwork.kernel.org/project/linux-mediatek/list/?series=945811&archive=both
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:09 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
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).
> 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
* Re: [PATCH v14 04/44] arm64: RMI: Add SMC definitions for calling the RMM
From: Gavin Shan @ 2026-05-18 7:08 UTC (permalink / raw)
To: Steven Price, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <20260513131757.116630-5-steven.price@arm.com>
Hi Steven,
On 5/13/26 11:17 PM, Steven Price wrote:
> The RMM (Realm Management Monitor) provides functionality that can be
> accessed by SMC calls from the host.
>
> The SMC definitions are based on DEN0137[1] version 2.0-bet1
>
> [1] https://developer.arm.com/documentation/den0137/2-0bet1/
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Changes since v13:
> * Updated to RMM spec v2.0-bet1
> Changes since v12:
> * Updated to RMM spec v2.0-bet0
> Changes since v9:
> * Corrected size of 'ripas_value' in struct rec_exit. The spec states
> this is an 8-bit type with padding afterwards (rather than a u64).
> Changes since v8:
> * Added RMI_PERMITTED_GICV3_HCR_BITS to define which bits the RMM
> permits to be modified.
> Changes since v6:
> * Renamed REC_ENTER_xxx defines to include 'FLAG' to make it obvious
> these are flag values.
> Changes since v5:
> * Sorted the SMC #defines by value.
> * Renamed SMI_RxI_CALL to SMI_RMI_CALL since the macro is only used for
> RMI calls.
> * Renamed REC_GIC_NUM_LRS to REC_MAX_GIC_NUM_LRS since the actual
> number of available list registers could be lower.
> * Provided a define for the reserved fields of FeatureRegister0.
> * Fix inconsistent names for padding fields.
> Changes since v4:
> * Update to point to final released RMM spec.
> * Minor rearrangements.
> Changes since v3:
> * Update to match RMM spec v1.0-rel0-rc1.
> Changes since v2:
> * Fix specification link.
> * Rename rec_entry->rec_enter to match spec.
> * Fix size of pmu_ovf_status to match spec.
> ---
> arch/arm64/include/asm/rmi_smc.h | 448 +++++++++++++++++++++++++++++++
> 1 file changed, 448 insertions(+)
> create mode 100644 arch/arm64/include/asm/rmi_smc.h
>
> diff --git a/arch/arm64/include/asm/rmi_smc.h b/arch/arm64/include/asm/rmi_smc.h
> new file mode 100644
> index 000000000000..a09b7a631fef
> --- /dev/null
> +++ b/arch/arm64/include/asm/rmi_smc.h
> @@ -0,0 +1,448 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2023-2026 ARM Ltd.
> + *
> + * The values and structures in this file are from the Realm Management Monitor
> + * specification (DEN0137) version 2.0-bet1:
> + * https://developer.arm.com/documentation/den0137/2-0bet1/
> + */
> +
> +#ifndef __ASM_RMI_SMC_H
> +#define __ASM_RMI_SMC_H
> +
> +#include <linux/arm-smccc.h>
> +
> +#define SMC_RMI_CALL(func) \
> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> + ARM_SMCCC_SMC_64, \
> + ARM_SMCCC_OWNER_STANDARD, \
> + (func))
> +
> +#define SMC_RMI_VERSION SMC_RMI_CALL(0x0150)
> +
> +#define SMC_RMI_RTT_DATA_MAP_INIT SMC_RMI_CALL(0x0153)
> +
> +#define SMC_RMI_REALM_ACTIVATE SMC_RMI_CALL(0x0157)
> +#define SMC_RMI_REALM_CREATE SMC_RMI_CALL(0x0158)
> +#define SMC_RMI_REALM_DESTROY SMC_RMI_CALL(0x0159)
> +#define SMC_RMI_REC_CREATE SMC_RMI_CALL(0x015a)
> +#define SMC_RMI_REC_DESTROY SMC_RMI_CALL(0x015b)
> +#define SMC_RMI_REC_ENTER SMC_RMI_CALL(0x015c)
> +#define SMC_RMI_RTT_CREATE SMC_RMI_CALL(0x015d)
> +#define SMC_RMI_RTT_DESTROY SMC_RMI_CALL(0x015e)
> +
> +#define SMC_RMI_RTT_READ_ENTRY SMC_RMI_CALL(0x0161)
> +
> +#define SMC_RMI_RTT_DEV_VALIDATE SMC_RMI_CALL(0x0163)
> +#define SMC_RMI_PSCI_COMPLETE SMC_RMI_CALL(0x0164)
> +#define SMC_RMI_FEATURES SMC_RMI_CALL(0x0165)
> +#define SMC_RMI_RTT_FOLD SMC_RMI_CALL(0x0166)
> +
> +#define SMC_RMI_RTT_INIT_RIPAS SMC_RMI_CALL(0x0168)
> +#define SMC_RMI_RTT_SET_RIPAS SMC_RMI_CALL(0x0169)
> +#define SMC_RMI_VSMMU_CREATE SMC_RMI_CALL(0x016a)
> +#define SMC_RMI_VSMMU_DESTROY SMC_RMI_CALL(0x016b)
> +#define SMC_RMI_RMM_CONFIG_SET SMC_RMI_CALL(0x016e)
> +#define SMC_RMI_PSMMU_IRQ_NOTIFY SMC_RMI_CALL(0x016f)
> +
> +#define SMC_RMI_PDEV_ABORT SMC_RMI_CALL(0x0174)
> +#define SMC_RMI_PDEV_COMMUNICATE SMC_RMI_CALL(0x0175)
> +#define SMC_RMI_PDEV_CREATE SMC_RMI_CALL(0x0176)
> +#define SMC_RMI_PDEV_DESTROY SMC_RMI_CALL(0x0177)
> +#define SMC_RMI_PDEV_GET_STATE SMC_RMI_CALL(0x0178)
> +
> +#define SMC_RMI_PDEV_STREAM_KEY_REFRESH SMC_RMI_CALL(0x017a)
> +#define SMC_RMI_PDEV_SET_PUBKEY SMC_RMI_CALL(0x017b)
> +#define SMC_RMI_PDEV_STOP SMC_RMI_CALL(0x017c)
> +#define SMC_RMI_RTT_AUX_CREATE SMC_RMI_CALL(0x017d)
> +#define SMC_RMI_RTT_AUX_DESTROY SMC_RMI_CALL(0x017e)
> +#define SMC_RMI_RTT_AUX_FOLD SMC_RMI_CALL(0x017f)
> +
> +#define SMC_RMI_VDEV_ABORT SMC_RMI_CALL(0x0185)
> +#define SMC_RMI_VDEV_COMMUNICATE SMC_RMI_CALL(0x0186)
> +#define SMC_RMI_VDEV_CREATE SMC_RMI_CALL(0x0187)
> +#define SMC_RMI_VDEV_DESTROY SMC_RMI_CALL(0x0188)
> +#define SMC_RMI_VDEV_GET_STATE SMC_RMI_CALL(0x0189)
> +#define SMC_RMI_VDEV_UNLOCK SMC_RMI_CALL(0x018a)
> +#define SMC_RMI_RTT_SET_S2AP SMC_RMI_CALL(0x018b)
> +#define SMC_RMI_VDEV_COMPLETE SMC_RMI_CALL(0x018e)
> +
> +#define SMC_RMI_VDEV_GET_INTERFACE_REPORT SMC_RMI_CALL(0x01d0)
> +#define SMC_RMI_VDEV_GET_MEASUREMENTS SMC_RMI_CALL(0x01d1)
> +#define SMC_RMI_VDEV_LOCK SMC_RMI_CALL(0x01d2)
> +#define SMC_RMI_VDEV_START SMC_RMI_CALL(0x01d3)
> +
> +#define SMC_RMI_VSMMU_EVENT_NOTIFY SMC_RMI_CALL(0x01d6)
> +#define SMC_RMI_PSMMU_ACTIVATE SMC_RMI_CALL(0x01d7)
> +#define SMC_RMI_PSMMU_DEACTIVATE SMC_RMI_CALL(0x01d8)
> +
> +#define SMC_RMI_PSMMU_ST_L2_CREATE SMC_RMI_CALL(0x01db)
> +#define SMC_RMI_PSMMU_ST_L2_DESTROY SMC_RMI_CALL(0x01dc)
> +#define SMC_RMI_DPT_L0_CREATE SMC_RMI_CALL(0x01dd)
> +#define SMC_RMI_DPT_L0_DESTROY SMC_RMI_CALL(0x01de)
> +#define SMC_RMI_DPT_L1_CREATE SMC_RMI_CALL(0x01df)
> +#define SMC_RMI_DPT_L1_DESTROY SMC_RMI_CALL(0x01e0)
> +#define SMC_RMI_GRANULE_TRACKING_GET SMC_RMI_CALL(0x01e1)
> +
> +#define SMC_RMI_GRANULE_TRACKING_SET SMC_RMI_CALL(0x01e3)
> +
> +#define SMC_RMI_RMM_CONFIG_GET SMC_RMI_CALL(0x01ec)
> +
> +#define SMC_RMI_RMM_STATE_GET SMC_RMI_CALL(0x01ee)
> +
> +#define SMC_RMI_PSMMU_EVENT_CONSUME SMC_RMI_CALL(0x01f0)
> +#define SMC_RMI_GRANULE_RANGE_DELEGATE SMC_RMI_CALL(0x01f1)
> +#define SMC_RMI_GRANULE_RANGE_UNDELEGATE SMC_RMI_CALL(0x01f2)
> +#define SMC_RMI_GPT_L1_CREATE SMC_RMI_CALL(0x01f3)
> +#define SMC_RMI_GPT_L1_DESTROY SMC_RMI_CALL(0x01f4)
> +#define SMC_RMI_RTT_DATA_MAP SMC_RMI_CALL(0x01f5)
> +#define SMC_RMI_RTT_DATA_UNMAP SMC_RMI_CALL(0x01f6)
> +#define SMC_RMI_RTT_DEV_MAP SMC_RMI_CALL(0x01f7)
> +#define SMC_RMI_RTT_DEV_UNMAP SMC_RMI_CALL(0x01f8)
> +#define SMC_RMI_RTT_ARCH_DEV_MAP SMC_RMI_CALL(0x01f9)
> +#define SMC_RMI_RTT_ARCH_DEV_UNMAP SMC_RMI_CALL(0x01fa)
> +#define SMC_RMI_RTT_UNPROT_MAP SMC_RMI_CALL(0x01fb)
> +#define SMC_RMI_RTT_UNPROT_UNMAP SMC_RMI_CALL(0x01fc)
> +#define SMC_RMI_RTT_AUX_PROT_MAP SMC_RMI_CALL(0x01fd)
> +#define SMC_RMI_RTT_AUX_PROT_UNMAP SMC_RMI_CALL(0x01fe)
> +#define SMC_RMI_RTT_AUX_UNPROT_MAP SMC_RMI_CALL(0x01ff)
> +#define SMC_RMI_RTT_AUX_UNPROT_UNMAP SMC_RMI_CALL(0x0200)
> +#define SMC_RMI_REALM_TERMINATE SMC_RMI_CALL(0x0201)
> +#define SMC_RMI_RMM_ACTIVATE SMC_RMI_CALL(0x0202)
> +#define SMC_RMI_OP_CONTINUE SMC_RMI_CALL(0x0203)
> +#define SMC_RMI_PDEV_STREAM_CONNECT SMC_RMI_CALL(0x0204)
> +#define SMC_RMI_PDEV_STREAM_DISCONNECT SMC_RMI_CALL(0x0205)
> +#define SMC_RMI_PDEV_STREAM_COMPLETE SMC_RMI_CALL(0x0206)
> +#define SMC_RMI_PDEV_STREAM_KEY_PURGE SMC_RMI_CALL(0x0207)
> +#define SMC_RMI_OP_MEM_DONATE SMC_RMI_CALL(0x0208)
> +#define SMC_RMI_OP_MEM_RECLAIM SMC_RMI_CALL(0x0209)
> +#define SMC_RMI_OP_CANCEL SMC_RMI_CALL(0x020a)
> +#define SMC_RMI_VSMMU_FEATURES SMC_RMI_CALL(0x020b)
> +#define SMC_RMI_VSMMU_CMD_GET SMC_RMI_CALL(0x020c)
> +#define SMC_RMI_VSMMU_CMD_COMPLETE SMC_RMI_CALL(0x020d)
> +#define SMC_RMI_PSMMU_INFO SMC_RMI_CALL(0x020e)
> +
> +#define RMI_ABI_MAJOR_VERSION 2
> +#define RMI_ABI_MINOR_VERSION 0
> +
> +#define RMI_ABI_VERSION_GET_MAJOR(version) ((version) >> 16)
> +#define RMI_ABI_VERSION_GET_MINOR(version) ((version) & 0xFFFF)
> +#define RMI_ABI_VERSION(major, minor) (((major) << 16) | (minor))
> +
> +#define RMI_UNASSIGNED 0
> +#define RMI_ASSIGNED 1
> +#define RMI_TABLE 2
> +
Those definations are inconsistent to those defined in tf-rmm/lib/smc/include/smc-rmi.h
where their size are 64-bits. Also, other two definations are missed here and perhaps
worthy to be added here.
#define RMI_ASSIGNED_DEV UL(3)
#define RMI_AUX_DESTROYED UL(5)
> +#define RMI_RETURN_STATUS(ret) ((ret) & 0xFF)
> +#define RMI_RETURN_INDEX(ret) (((ret) >> 8) & 0xFF)
> +#define RMI_RETURN_MEMREQ(ret) (((ret) >> 8) & 0x3)
> +#define RMI_RETURN_CAN_CANCEL(ret) (((ret) >> 10) & 0x1)
> +
> +#define RMI_SUCCESS 0
> +#define RMI_ERROR_INPUT 1
> +#define RMI_ERROR_REALM 2
> +#define RMI_ERROR_REC 3
> +#define RMI_ERROR_RTT 4
> +#define RMI_ERROR_NOT_SUPPORTED 5
> +#define RMI_ERROR_DEVICE 6
> +#define RMI_ERROR_RTT_AUX 7
> +#define RMI_ERROR_PSMMU_ST 8
> +#define RMI_ERROR_DPT 9
> +#define RMI_BUSY 10
> +#define RMI_ERROR_GLOBAL 11
> +#define RMI_ERROR_TRACKING 12
> +#define RMI_INCOMPLETE 13
> +#define RMI_BLOCKED 14
> +#define RMI_ERROR_GPT 15
> +#define RMI_ERROR_GRANULE 16
> +
> +#define RMI_OP_MEM_REQ_NONE 0
> +#define RMI_OP_MEM_REQ_DONATE 1
> +#define RMI_OP_MEM_REQ_RECLAIM 2
> +
The size of those definations are 32-bits, different to that of them defined
in tf-rmm/lib/smc/include/smc-rmi.h
#define RMI_OP_MEM_REQ_NONE (0UL)
#define RMI_OP_MEM_REQ_DONATE (1UL)
#define RMI_OP_MEM_REQ_RECLAIM (2UL)
> +#define RMI_DONATE_SIZE(req) ((req) & 0x3)
> +#define RMI_DONATE_COUNT_MASK GENMASK(15, 2)
> +#define RMI_DONATE_COUNT(req) (((req) & RMI_DONATE_COUNT_MASK) >> 2)
> +#define RMI_DONATE_CONTIG(req) (!!((req) & BIT(16)))
> +#define RMI_DONATE_STATE(req) (!!((req) & BIT(17)))
> +
> +#define RMI_OP_MEM_DELEGATED 0
> +#define RMI_OP_MEM_UNDELEGATED 1
> +
As above, inconsistent size to those definations in tf-rmm/lib/smc/include/smc-rmi.h
> +#define RMI_ADDR_TYPE_NONE 0
> +#define RMI_ADDR_TYPE_SINGLE 1
> +#define RMI_ADDR_TYPE_LIST 2
> +
As above, inconsistent size to those definations in tf-rmm/lib/smc/include/smc-rmi.h
> +#define RMI_ADDR_RANGE_SIZE_MASK GENMASK(1, 0)
> +#define RMI_ADDR_RANGE_COUNT_MASK GENMASK(PAGE_SHIFT - 1, 2)
> +#define RMI_ADDR_RANGE_ADDR_MASK (PAGE_MASK & GENMASK(51, 0))
> +#define RMI_ADDR_RANGE_STATE_MASK BIT(63)
> +
> +#define RMI_ADDR_RANGE_SIZE(ar) (FIELD_GET(RMI_ADDR_RANGE_SIZE_MASK, \
> + (ar)))
> +#define RMI_ADDR_RANGE_COUNT(ar) (FIELD_GET(RMI_ADDR_RANGE_COUNT_MASK, \
> + (ar)))
> +#define RMI_ADDR_RANGE_ADDR(ar) ((ar) & RMI_ADDR_RANGE_ADDR_MASK)
> +#define RMI_ADDR_RANGE_STATE(ar) (FIELD_GET(RMI_ADDR_RANGE_STATE_MASK, \
> + (ar)))
> +
> +enum rmi_ripas {
> + RMI_EMPTY = 0,
> + RMI_RAM = 1,
> + RMI_DESTROYED = 2,
> + RMI_DEV = 3,
> +};
> +
> +#define RMI_NO_MEASURE_CONTENT 0
> +#define RMI_MEASURE_CONTENT 1
> +
> +#define RMI_FEATURE_REGISTER_0_S2SZ GENMASK(7, 0)
> +#define RMI_FEATURE_REGISTER_0_LPA2 BIT(8)
> +#define RMI_FEATURE_REGISTER_0_SVE BIT(9)
> +#define RMI_FEATURE_REGISTER_0_SVE_VL GENMASK(13, 10)
> +#define RMI_FEATURE_REGISTER_0_NUM_BPS GENMASK(19, 14)
> +#define RMI_FEATURE_REGISTER_0_NUM_WPS GENMASK(25, 20)
> +#define RMI_FEATURE_REGISTER_0_PMU BIT(26)
> +#define RMI_FEATURE_REGISTER_0_PMU_NUM_CTRS GENMASK(31, 27)
> +
> +#define RMI_FEATURE_REGISTER_1_RMI_GRAN_SZ_4KB BIT(0)
> +#define RMI_FEATURE_REGISTER_1_RMI_GRAN_SZ_16KB BIT(1)
> +#define RMI_FEATURE_REGISTER_1_RMI_GRAN_SZ_64KB BIT(2)
> +#define RMI_FEATURE_REGISTER_1_HASH_SHA_256 BIT(3)
> +#define RMI_FEATURE_REGISTER_1_HASH_SHA_384 BIT(4)
> +#define RMI_FEATURE_REGISTER_1_HASH_SHA_512 BIT(5)
> +#define RMI_FEATURE_REGISTER_1_MAX_RECS_ORDER GENMASK(9, 6)
> +#define RMI_FEATURE_REGISTER_1_L0GPTSZ GENMASK(13, 10)
> +#define RMI_FEATURE_REGISTER_1_PPS GENMASK(16, 14)
> +
> +#define RMI_FEATURE_REGISTER_2_DA BIT(0)
> +#define RMI_FEATURE_REGISTER_2_DA_COH BIT(1)
> +#define RMI_FEATURE_REGISTER_2_VSMMU BIT(2)
> +#define RMI_FEATURE_REGISTER_2_ATS BIT(3)
> +#define RMI_FEATURE_REGISTER_2_MAX_VDEVS_ORDER GENMASK(7, 4)
> +#define RMI_FEATURE_REGISTER_2_VDEV_KROU BIT(8)
> +#define RMI_FEATURE_REGISTER_2_NON_TEE_STREAM BIT(9)
> +
> +#define RMI_FEATURE_REGISTER_3_MAX_NUM_AUX_PLANES GENMASK(3, 0)
> +#define RMI_FEATURE_REGISTER_3_RTT_PLAN GENMASK(5, 4)
> +#define RMI_FEATURE_REGISTER_3_RTT_S2AP_INDIRECT BIT(6)
> +
> +#define RMI_FEATURE_REGISTER_4_MEC_COUNT GENMASK(63, 0)
> +
> +#define RMI_MEM_CATEGORY_CONVENTIONAL 0
> +#define RMI_MEM_CATEGORY_DEV_NCOH 1
> +#define RMI_MEM_CATEGORY_DEV_COH 2
> +
> +#define RMI_TRACKING_RESERVED 0
> +#define RMI_TRACKING_NONE 1
> +#define RMI_TRACKING_FINE 2
> +#define RMI_TRACKING_COARSE 3
> +
> +#define RMI_GRANULE_SIZE_4KB 0
> +#define RMI_GRANULE_SIZE_16KB 1
> +#define RMI_GRANULE_SIZE_64KB 2
> +
> +/*
> + * Note many of these fields are smaller than u64 but all fields have u64
> + * alignment, so use u64 to ensure correct alignment.
> + */
> +struct rmm_config {
> + union { /* 0x0 */
> + struct {
> + u64 tracking_region_size;
> + u64 rmi_granule_size;
> + };
> + u8 sizer[0x1000];
> + };
> +};
> +
> +#define RMI_REALM_PARAM_FLAG_LPA2 BIT(0)
> +#define RMI_REALM_PARAM_FLAG_SVE BIT(1)
> +#define RMI_REALM_PARAM_FLAG_PMU BIT(2)
> +
> +struct realm_params {
> + union { /* 0x0 */
> + struct {
> + u64 flags;
> + u64 s2sz;
> + u64 sve_vl;
> + u64 num_bps;
> + u64 num_wps;
> + u64 pmu_num_ctrs;
> + u64 hash_algo;
> + u64 num_aux_planes;
> + };
> + u8 padding0[0x400];
> + };
> + union { /* 0x400 */
> + struct {
> + u8 rpv[64];
> + u64 ats_plane;
> + };
> + u8 padding1[0x400];
> + };
> + union { /* 0x800 */
> + struct {
> + u64 padding;
> + u64 rtt_base;
> + s64 rtt_level_start;
> + u64 rtt_num_start;
> + u64 flags1;
> + u64 aux_rtt_base[3];
> + };
> + u8 padding2[0x800];
> + };
> +};
> +
> +/*
> + * The number of GPRs (starting from X0) that are
> + * configured by the host when a REC is created.
> + */
> +#define REC_CREATE_NR_GPRS 8
> +
> +#define REC_PARAMS_FLAG_RUNNABLE BIT_ULL(0)
> +
> +struct rec_params {
> + union { /* 0x0 */
> + u64 flags;
> + u8 padding0[0x100];
> + };
> + union { /* 0x100 */
> + u64 mpidr;
> + u8 padding1[0x100];
> + };
> + union { /* 0x200 */
> + u64 pc;
> + u8 padding2[0x100];
> + };
> + union { /* 0x300 */
> + u64 gprs[REC_CREATE_NR_GPRS];
> + u8 padding3[0xd00];
> + };
> +};
> +
> +#define REC_ENTER_FLAG_EMULATED_MMIO BIT(0)
> +#define REC_ENTER_FLAG_INJECT_SEA BIT(1)
> +#define REC_ENTER_FLAG_TRAP_WFI BIT(2)
> +#define REC_ENTER_FLAG_TRAP_WFE BIT(3)
> +#define REC_ENTER_FLAG_RIPAS_RESPONSE BIT(4)
> +#define REC_ENTER_FLAG_S2AP_RESPONSE BIT(5)
> +#define REC_ENTER_FLAG_DEV_MEM_RESPONSE BIT(6)
> +#define REC_ENTER_FLAG_FORCE_P0 BIT(7)
> +
> +#define REC_RUN_GPRS 31
> +#define REC_MAX_GIC_NUM_LRS 16
> +
> +#define RMI_PERMITTED_GICV3_HCR_BITS (ICH_HCR_EL2_UIE | \
> + ICH_HCR_EL2_LRENPIE | \
> + ICH_HCR_EL2_NPIE | \
> + ICH_HCR_EL2_VGrp0EIE | \
> + ICH_HCR_EL2_VGrp0DIE | \
> + ICH_HCR_EL2_VGrp1EIE | \
> + ICH_HCR_EL2_VGrp1DIE | \
> + ICH_HCR_EL2_TDIR)
> +
> +struct rec_enter {
> + union { /* 0x000 */
> + u64 flags;
> + u8 padding0[0x200];
> + };
> + union { /* 0x200 */
> + u64 gprs[REC_RUN_GPRS];
> + u8 padding1[0x100];
> + };
> + u8 padding3[0x500];
> +};
> +
> +#define RMI_EXIT_SYNC 0x00
> +#define RMI_EXIT_IRQ 0x01
> +#define RMI_EXIT_FIQ 0x02
> +#define RMI_EXIT_PSCI 0x03
> +#define RMI_EXIT_RIPAS_CHANGE 0x04
> +#define RMI_EXIT_HOST_CALL 0x05
> +#define RMI_EXIT_SERROR 0x06
> +#define RMI_EXIT_S2AP_CHANGE 0x07
> +#define RMI_EXIT_VDEV_REQUEST 0x08
> +#define RMI_EXIT_VDEV_VALIDATE_MAPPING 0x09
> +#define RMI_EXIT_VSMMU_COMMAND 0x0a
> +
> +struct rec_exit {
> + union { /* 0x000 */
> + u8 exit_reason;
> + u8 padding0[0x100];
> + };
> + union { /* 0x100 */
> + struct {
> + u64 esr;
> + u64 far;
> + u64 hpfar;
> + u64 rtt_tree;
> + };
> + u8 padding1[0x100];
> + };
> + union { /* 0x200 */
> + u64 gprs[REC_RUN_GPRS];
> + u8 padding2[0x100];
> + };
> + union { /* 0x300 */
> + u8 padding3[0x100];
> + };
> + union { /* 0x400 */
> + struct {
> + u64 cntp_ctl;
> + u64 cntp_cval;
> + u64 cntv_ctl;
> + u64 cntv_cval;
> + };
> + u8 padding4[0x100];
> + };
> + union { /* 0x500 */
> + struct {
> + u64 ripas_base;
> + u64 ripas_top;
> + u8 ripas_value;
> + u8 padding8[15];
> + u64 s2ap_base;
> + u64 s2ap_top;
> + u64 vdev_id_1;
> + u64 vdev_id_2;
> + u64 dev_mem_base;
> + u64 dev_mem_top;
> + u64 dev_mem_pa;
> + };
> + u8 padding5[0x100];
> + };
> + union { /* 0x600 */
> + struct {
> + u16 imm;
> + u16 padding9;
> + u64 plane;
> + };
> + u8 padding6[0x100];
> + };
> + union { /* 0x700 */
> + struct {
> + u8 pmu_ovf_status;
> + u8 padding10[15];
> + u64 vsmmu;
> + };
> + u8 padding7[0x100];
> + };
> +};
> +
> +struct rec_run {
> + struct rec_enter enter;
> + struct rec_exit exit;
> +};
> +
> +/* RMI_RTT_UNPROT_MAP_FLAGS definitions */
> +#define RMI_RTT_UNPROT_MAP_FLAGS_OADDR_TYPE GENMASK(1, 0)
> +#define RMI_RTT_UNPROT_MAP_FLAGS_LIST_COUNT GENMASK(15, 2)
> +#define RMI_RTT_UNPROT_MAP_FLAGS_MEMATTR GENMASK(18, 16)
> +#define RMI_RTT_UNPROT_MAP_FLAGS_S2AP GENMASK(22, 19)
> +
> +/* S2AP Direct Encodings, used in RMI_RTT_UNPROT_MAP_FLAGS_S2AP */
> +#define RMI_S2AP_DIRECT_WRITE BIT(0)
> +#define RMI_S2AP_DIRECT_READ BIT(1)
> +
> +#endif /* __ASM_RMI_SMC_H */
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding
From: Krzysztof Kozlowski @ 2026-05-18 7:07 UTC (permalink / raw)
To: Chancel Liu
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, festevam@gmail.com,
mturquette@baylibre.com, sboyd@kernel.org, kernel@pengutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-clk@vger.kernel.org
In-Reply-To: <AM9PR04MB8353FE81D06852D45514E460E3032@AM9PR04MB8353.eurprd04.prod.outlook.com>
On 18/05/2026 06:18, Chancel Liu wrote:
>>> +description:
>>> + The NXP I/O connector represents a physically present I/O connector
>>> +on the
>>> + base board. It acts as a nexus that exposes a constrained set of
>>> +I/O
>>> + resources, such as GPIOs, clocks, PWMs and interrupts, through
>>> +fixed
>>> + electrical wiring. All actual hardware providers reside on the base board.
>>> + The connector node only defines index-based mappings to those
>> providers.
>>> +
>>> +properties:
>>> + compatible:
>>> + const: fsl,io-connector
>>
>> Everything is IO. Everything is connector, so your compatible does not match
>> requirements from writing bindings.
>>
>
> Yes, this compatible is too generic. I will rename the compatible to
> fsl,aud-io-connector.
aud is not much better. Which boards have it? What's the pinout? What's
standard? Is it described anywhere? If so, provide reference to spec/docs.
>
>>> +
>>> + gpio-controller: true
>>> +
>>> + '#gpio-cells':
>>> + const: 2
>>> +
>>> + gpio-map:
>>> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
>>
>> You do not need to redefine the types. You need constraints, though.
>>
>
> OK. I will add proper constraints.
>
>>> +
>>> + gpio-map-mask:
>>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>>> +
>>> + gpio-map-pass-thru:
>>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>>> +
>>> + '#clock-cells':
>>> + const: 1
>>> +
>>> + clock-map:
>>> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
>>> +
>>> + clock-map-mask:
>>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>>> +
>>> + clock-map-pass-thru:
>>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>>
>> I do not see these defined anywhere. I also checked cover letter for
>> references for pulls to dtschema.
>>
>
> Nexus nodes are already in the device-tree specification：
> https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping
> For reference, current kernel has supported it:
> * Nexus OF support:
> commit bd6f2fd5a1d5 ("of: Support parsing phandle argument lists through a nexus node")
> * GPIO adoption:
> commit c11e6f0f04db ("gpio: Support gpio nexus dt bindings")
> * PWM adoption:
> commit e71e46a6f19c ("pwm: Add support for pwm nexus dt bindings")
> Clock adoption is ongoing:
> https://lore.kernel.org/all/20260327-schneider-v7-0-rc1-crypto-v1-10-5e6ff7853994@bootlin.com/
DT spec only mentions nexuses, but it is only a spec. Each property from
the spec must be defined in dtschema or kernel bindings.
I do not see any dependency mentioned in the cover letter, so how do you
think we can figure out where is this definition of clock nexus?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: usb: add CIX Sky1 Cadence USB3 controller
From: Krzysztof Kozlowski @ 2026-05-18 7:04 UTC (permalink / raw)
To: Peter Chen
Cc: robh, krzk+dt, conor+dt, gregkh, pawell, rogerq, devicetree,
linux-kernel, linux-usb, cix-kernel-upstream, linux-arm-kernel,
arnd
In-Reply-To: <agq5eZSAZYRAuCH6@nchen-desktop>
On 18/05/2026 09:02, Peter Chen wrote:
> On 26-05-15 13:18:53, Krzysztof Kozlowski wrote:
>> EXTERNAL EMAIL
>>
>> On 15/05/2026 12:25, Peter Chen wrote:
>>> On 26-05-15 09:54:10, Krzysztof Kozlowski wrote:
>>>> EXTERNAL EMAIL
>>>>
>>>> On Mon, May 11, 2026 at 10:42:43AM +0800, Peter Chen wrote:
>>>>> Add a binding for the CIX Sky1 integration of the Cadence USBSSP DRD
>>>>> controller. The schema documents the glue register window, clocks,
>>>>> resets, interrupts and S5 system controller phandle.
>>>>>
>>>>> Signed-off-by: Peter Chen <peter.chen@cixtech.com>
>>>>> ---
>>>>> .../bindings/usb/cix,sky1-cdns3.yaml | 151 ++++++++++++++++++
>>>>
>>>> Why are you mixing USB patches with DTS in one patchset? Don't.
>>>
>>> In this series, the 1st patch is the IP core driver changes (export APIs for glue layer
>>> use), and the second glue layer patch is the user for new adding APIs.
>>
>>
>> Not really answer to my question. Why is DTS here? It has nothing to do
>> with 1st patch, second patch or this one.
>>
>
> Per submitting-patches.rst I.7, the DTS was placed at the end of the
> series so either maintainer can apply their portion. That said, if
> you prefer I can split it into a separate series, I have no strong
> option.
Don't mix DTS with USB patchset.
Best regards,
Krzysztof
^ 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