* Re: [PATCH] iommu/arm-smmu-qcom: Fix fastrpc compatible string in ACTLR client match table
From: Dmitry Baryshkov @ 2026-04-09 1:48 UTC (permalink / raw)
To: bibek.patro
Cc: Rob Clark, Will Deacon, Robin Murphy, Joerg Roedel,
Dmitry Baryshkov, iommu, linux-arm-msm, linux-arm-kernel,
linux-kernel, srinivas.kandagatla
In-Reply-To: <20260408130825.3268733-1-bibek.patro@oss.qualcomm.com>
On Wed, Apr 08, 2026 at 06:38:25PM +0530, bibek.patro@oss.qualcomm.com wrote:
> From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>
> The qcom_smmu_actlr_client_of_match table contained "qcom,fastrpc" as
> the compatible string for applying ACTLR prefetch settings to FastRPC
> devices. However, "qcom,fastrpc" is the compatible string for the parent
> rpmsg channel node, which is not an IOMMU client — it carries no
> "iommus" property in the device tree and is never attached to an SMMU
> context bank.
>
> The actual IOMMU clients are the compute context bank (CB) child nodes,
> which use the compatible string "qcom,fastrpc-compute-cb". These nodes
> carry the "iommus" property and are probed by fastrpc_cb_driver via
> fastrpc_cb_probe(), which sets up the DMA mask and IOMMU mappings for
> each FastRPC session. The device tree structure is:
>
> fastrpc {
> compatible = "qcom,fastrpc"; /* rpmsg channel, no iommus */
> ...
> compute-cb@3 {
> compatible = "qcom,fastrpc-compute-cb";
> iommus = <&apps_smmu 0x1823 0x0>; /* actual IOMMU client */
> };
> };
>
> Since qcom_smmu_set_actlr_dev() calls of_match_device() against the
> device being attached to the SMMU context bank, the "qcom,fastrpc"
> entry was never matching any device. As a result, the ACTLR prefetch
> settings (PREFETCH_DEEP | CPRE | CMTLB) were silently never applied
> for FastRPC compute context banks.
>
> Fix this by replacing "qcom,fastrpc" with "qcom,fastrpc-compute-cb"
> in the match table so that the ACTLR settings are correctly applied
> to the compute CB devices that are the true IOMMU clients.
>
> Assisted-by: Anthropic:claude-4-6-sonnet
> Fixes: 3e35c3e725de ("iommu/arm-smmu: Add ACTLR data and support for qcom_smmu_500")
> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
> ---
>
> While there is an ongoing discussion [1] on how to differentiate ACTLR
> prefetch settings between compute DSP and audio DSP fastrpc devices, it
> is necessary to first fix the compatible string to "qcom,fastrpc-compute-cb".
> Both compute DSP and audio DSP fastrpc nodes use this compatible string,
> so both will receive the ACTLR settings after this fix. However, for
> audio DSP devices the effect remains the same as the current
> state since they do not actively use prefetch — the write is effectively
> a NOP for them. The fix is meaningful for compute DSP devices, which
> actively use prefetch and were previously being silently skipped.
>
> [1]: https://lore.kernel.org/all/9b4c895a-c822-40e6-bb92-8fdcd09c82d3@oss.qualcomm.com/
>
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
From: Brian Norris @ 2026-04-09 1:58 UTC (permalink / raw)
To: Hongxing Zhu
Cc: manivannan.sadhasivam@oss.qualcomm.com, Bjorn Helgaas,
Mahesh J Salgaonkar, Oliver O'Halloran, Will Deacon,
Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Heiko Stuebner, Philipp Zabel,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, linux-rockchip@lists.infradead.org,
Niklas Cassel, Wilfred Mallawa, Krishna Chaitanya Chundru,
Lukas Wunner, Wilson Ding, Miles Chen
In-Reply-To: <AS8PR04MB883389FD2A016F9E02756B048C49A@AS8PR04MB8833.eurprd04.prod.outlook.com>
Hi Richard and Mani,
For the record, I've been using a form of an earlier version of this
patchset in my environment for some time now, and I've run across
problems that *might* relate to what Richard is reporting, but I'm not
quite sure at the moment. Details below.
On Wed, Mar 25, 2026 at 07:06:49AM +0000, Hongxing Zhu wrote:
> Hi Mani:
> I've accidentally encountered a new issue based on the reset root port patch-set.
> After performing a few hot-reset operations, the PCIe link enters a continuous up/down cycling pattern.
>
> I found that calling pci_reset_secondary_bus() first in pcibios_reset_secondary_bus() appears to resolve this issue.
> Have you experienced a similar problem?
>
> "
> ...
> [ 141.897701] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
> [ 142.086341] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
> [ 142.092038] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000c00) link down detected
> ...
> "
>
> Platform: i.MX95 EVK board plus local Root Ports reset supports based on the #1 and #2 patches of v7 patch-set.
> Notes of the logs:
> - One Gen3 NVME device is connected.
> - "./memtool 4c341058=0;./memtool 4c341058=1;" is used to toggle the LTSSM_EN bit to trigger the link down.
> - Toggle BIT6 of Bridge Control Register to trigger hot reset by "./memtool 4c30003c=004001ff; ./memtool 4c30003c=000001ff;"
> - The Root Port reset patches works correctly at first.
> However, after several hot-reset triggers, the link enters a repeated down/up cycling state.
>
> Logs:
> [ 3.553188] imx6q-pcie 4c300000.pcie: host bridge /soc/pcie@4c300000 ranges:
> [ 3.560308] imx6q-pcie 4c300000.pcie: IO 0x006ff00000..0x006fffffff -> 0x0000000000
> [ 3.568525] imx6q-pcie 4c300000.pcie: MEM 0x0910000000..0x091fffffff -> 0x0010000000
> [ 3.577314] imx6q-pcie 4c300000.pcie: config reg[1] 0x60100000 == cpu 0x60100000
> [ 3.796029] imx6q-pcie 4c300000.pcie: iATU: unroll T, 128 ob, 128 ib, align 4K, limit 1024G
> [ 4.003746] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
> [ 4.009553] imx6q-pcie 4c300000.pcie: PCI host bridge to bus 0000:00
> root@imx95evk:~#
> root@imx95evk:~#
> root@imx95evk:~# ./memtool 4c341058=0;./memtool 4c341058=1; Writing 32-bit value 0x0 to address 0x4C341058
> Writing 32-bit v
> [ 87.265348] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000d01) link down detected
> alue 0x1 to adder
> [ 87.273106] imx6q-pcie 4c300000.pcie: Stop root bus and handle link down
> ss 0x4C341058
> [ 87.281264] pcieport 0000:00:00.0: Recovering Root Port due to Link Down
> [ 87.289245] pci 0000:01:00.0: AER: can't recover (no error_detected callback)
> root@imx95evk:~# [ 87.514216] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
> [ 87.702968] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
> [ 87.834983] pcieport 0000:00:00.0: Root Port has been reset
> [ 87.840714] pcieport 0000:00:00.0: AER: device recovery failed
> [ 87.846592] imx6q-pcie 4c300000.pcie: Rescan bus after link up is detected
> [ 87.855947] pcieport 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
I've seen this same line ("bridge configuration invalid") before, and I
believe that's because the saved state (pci_save_state(); more about
this below) is invalid -- it contains 0 values in places where they
should be non-zero. So when those values are restored
(pci_restore_state()), we get confused.
I believe we've pinned down one reason this invalid state occurs -- it's
because of an automatic (mis)feature in the DesignWare PCIe hardware.
Specifically, it's because of what the controller does during a surprise
link-down error.
From the Designware docs:
"[...] during normal operation, the link might fail and go down. After
this link-down event, the controller requests the DWC_pcie_clkrst.v
module to hot-reset the controller. There is no difference in the
handling of a link-down reset or a hot reset; the controller asserts
the link_req_rst_not output requesting the DWC_pcie_clkrst.v module to
reset the controller."
In some of the adjacent documentation (and confirmed in local testing),
it suggests that this automatic reset will also reset various DBI (i.e.,
PCIe config space) registers. It also seems as if there's not really a
good way to completely stop this automatic reset -- the docs mention
some SW methods prevent the reset, but they all seem racy or incomplete.
Anyway, I think this implies that patch 1 is somewhat wrong [1]. It
includes some code like this:
pci_save_state(dev);
ret = host->reset_root_port(host, dev);
if (ret)
pci_err(dev, "Failed to reset Root Port: %d\n", ret);
else
/* Now restore it on success */
pci_restore_state(dev);
That first line (pci_save_state()) is prone to saving invalid state,
depending on whether the link-down event has finished flushing and
resetting the controller yet or not. The resulting impact is a bit hard
to judge, depending on what (mis)configuration you end up with.
I also noticed commit a2f1e22390ac ("PCI/ERR: Ensure error
recoverability at all times") was merged recently. With that change, I
believe it is now safe to perform pci_restore_state() even without
pci_save_state() here.
So ... can we remove pci_save_state() from
pcibios_reset_secondary_bus()? Might that help? It sounds like my above
observations *may* match Richard's reports, but I'm not sure. And
anyway, the documented hardware behavior is racy, so it's hard to
propose a foolproof solution.
Brian
[1] At least, for DesignWare controllers.
> [ 87.864423] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
>
> root@imx95evk:~#
> root@imx95evk:~# cat /proc/interrupts | grep lnk;
> 273: 2 0 0 0 0 0 GICv3 342 Level PCIe PME, lnk_notify
> root@imx95evk:~#
> root@imx95evk:~#
> root@imx95evk:~# ./memtool 4c30003c=004001ff; ./memtool 4c30003c=000001ff; Writing 32-bit va
> [ 107.028086] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000d00) link down detected lue 0x4001FF to a
> [ 107.037018] imx6q-pcie 4c300000.pcie: Stop root bus and handle link down ddress 0x4C30003C
> [ 107.045137] pcieport 0000:00:00.0: Recovering Root Port due to Link Down
>
> Writing 32-bit
> [ 107.053332] pci 0000:01:00.0: AER: can't recover (no error_detected callback) value 0x1FF to address 0x4C30003C root@imx95evk:~#
> [ 107.282146] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
> [ 107.470801] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
> [ 107.602823] pcieport 0000:00:00.0: Root Port has been reset
> [ 107.608601] pcieport 0000:00:00.0: AER: device recovery failed
> [ 107.614497] imx6q-pcie 4c300000.pcie: Rescan bus after link up is detected
> [ 107.623805] pcieport 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> [ 107.632281] pci_bus 0000:01: busn_res: [bus 01] end is updated to 01
>
> root@imx95evk:~#
> root@imx95evk:~# cat /proc/interrupts | grep lnk;
> 273: 4 0 0 0 0 0 GICv3 342 Level PCIe PME, lnk_notify
> root@imx95evk:~#
> root@imx95evk:~# ./memtool 4c30003c=004001ff; ./memtool 4c30003c=000001ff; Writing 32-bit va
> [ 133.424041] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000d00) link down detected lue 0x4001FF to a
> [ 133.432954] imx6q-pcie 4c300000.pcie: Stop root bus and handle link down ddress 0x4C30003C
> [ 133.441106] pcieport 0000:00:00.0: Recovering Root Port due to Link Down
>
> Writing 32-bit
> [ 133.449309] pci 0000:01:00.0: AER: can't recover (no error_detected callback) value 0x1FF to address 0x4C30003C root@imx95evk:~#
> [ 133.677824] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
> [ 133.870414] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
> [ 134.002534] pcieport 0000:00:00.0: Root Port has been reset
> [ 134.008307] pcieport 0000:00:00.0: AER: device recovery failed
> [ 134.014193] imx6q-pcie 4c300000.pcie: Rescan bus after link up is detected
> [ 134.023418] pcieport 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
> [ 134.031881] pci_bus 0000:01: busn_res: [bus 01] end is updated to 01
>
> root@imx95evk:~# ./memtool 4c30003c=004001ff; ./memtool 4c30003c=000001ff; Writing 32-bit va
> [ 140.149713] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000d00) link down detected lue 0x4001FF to a
> [ 140.158614] imx6q-pcie 4c300000.pcie: Stop root bus and handle link down ddress 0x4C30003C
> [ 140.166779] pcieport 0000:00:00.0: Recovering Root Port due to Link Down
> [ 140.174981] pci 0000:01:00.0: AER: can't recover (no error_detected callback) Writing 32-bit value 0x1FF to address 0x4C30003C root@imx95evk:~#
> [ 140.401605] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
> [ 140.590491] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
> [ 140.596206] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000c00) link down detected
>
> root@imx95evk:~#
> [ 141.630311] pcieport 0000:00:00.0: Data Link Layer Link Active not set in 100 msec
> [ 141.637950] pcieport 0000:00:00.0: Failed to reset Root Port: -25
> [ 141.644095] pcieport 0000:00:00.0: AER: subordinate device reset failed
> [ 141.650883] pcieport 0000:00:00.0: AER: device recovery failed
> [ 141.656784] imx6q-pcie 4c300000.pcie: Stop root bus and handle link down
> [ 141.663520] pcieport 0000:00:00.0: Recovering Root Port due to Link Down
> [ 141.670271] pci 0000:01:00.0: AER: can't recover (no error_detected callback)
> [ 141.897701] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
> [ 142.086341] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
> [ 142.092038] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000c00) link down detected
> [ 143.126273] pcieport 0000:00:00.0: Data Link Layer Link Active not set in 100 msec
> [ 143.133919] pcieport 0000:00:00.0: Failed to reset Root Port: -25
> [ 143.140052] pcieport 0000:00:00.0: AER: subordinate device reset failed
> [ 143.146747] pcieport 0000:00:00.0: AER: device recovery failed
> [ 143.152604] imx6q-pcie 4c300000.pcie: Stop root bus and handle link down
> [ 143.159314] pcieport 0000:00:00.0: Recovering Root Port due to Link Down
> [ 143.166022] pci 0000:01:00.0: AER: can't recover (no error_detected callback)
> [ 143.389723] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
> [ 143.582294] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
> [ 143.587996] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000c00) link down detected
>
>
> Thanks.
> Best Regards
> Richard Zhu
^ permalink raw reply
* RE: Status of thermal support for i.MX93
From: Jacky Bai @ 2026-04-09 1:59 UTC (permalink / raw)
To: Stefan Wahren, Alice Guo, Frank Li
Cc: Fabio Estevam, imx@lists.linux.dev, Linux ARM,
open list:GENERIC PM DOMAINS, Daniel Lezcano, Sascha Hauer
In-Reply-To: <1ad05dc4-9eaa-4fc2-a665-e17521fd333c@gmx.net>
Hi Stefan,
> Subject: Status of thermal support for i.MX93
>
> Hi,
>
> AFAIK the thermal support for i.MX93 hasn't been mainlined yet. The last
> version I can find is here [1].
>
> Are there any plans to finish this work?
>
I thought Frank answered the comments and no further action to do from my side, So it slipped
From my memory.
I just rechecked the comments history, it seems still have some comments need to be resolved.
I will handle them and send out a new version.
Thx for point this out.
BR
> Thanks
>
^ permalink raw reply
* Re: [RFC V1 00/16] arm64/mm: Enable 128 bit page table entries
From: Anshuman Khandual @ 2026-04-09 2:08 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, Mark Rutland,
Lorenzo Stoakes, Andrew Morton, Mike Rapoport, Linu Cherian,
linux-kernel, linux-mm
In-Reply-To: <c664368c-fe2c-42d8-b488-e9e30b342491@kernel.org>
On 08/04/26 5:43 PM, David Hildenbrand (Arm) wrote:
> On 4/8/26 12:53, Anshuman Khandual wrote:
>> On 07/04/26 8:14 PM, David Hildenbrand (Arm) wrote:
>>> On 2/24/26 06:11, Anshuman Khandual wrote:
>>>> FEAT_D128 is a new arm architecture feature adding support for VMSAv9-128
>>>> translation system. FEAT_D128 is an optional feature from ARMV9.3 onwards.
>>>> So with this feature arm64 platforms could have two different translation
>>>> systems, VMSAv8-64 and VMSAv9-128 could selectively be enabled.
>>>>
>>>> FEAT_D128 adds 128 bit page table entries, thus supporting larger physical
>>>> and virtual address range while also expanding available room for more MMU
>>>> management feature bits both for HW and SW.
>>>>
>>>> This series has been split into two parts. Generic MM changes followed by
>>>> arm64 platform changes, finally enabling D128 with a new config ARM64_D128.
>>>>
>>>> READ_ONCE() on page table entries get routed via level specific pxdp_get()
>>>> helpers which platforms could then override when required. These accessors
>>>> on arm64 platform help in ensuring page table accesses are performed in an
>>>> atomic manner while reading 128 bit page table entries.
>>>>
>>>> All ARM64_VA_BITS and ARM64_PA_BITS combinations for all page sizes are now
>>>> supported both on D64 and D128 translation regimes. Although new 56 bits VA
>>>> space is not yet supported. Similarly FEAT_D128 skip level is not supported
>>>> currently.
>>>>
>>>> Basic page table geometry has been changed with D128 as there are now fewer
>>>> entries per level. Please refer to the following table for leaf entry sizes
>>>>
>>>> D64 D128
>>>> ------------------------------------------------
>>>> | PAGE_SIZE | PMD | PUD | PMD | PUD |
>>>> -----------------------------|-----------------|
>>>> | 4K | 2M | 1G | 1M | 256M |
>>>> | 16K | 32M | 64G | 16M | 16G |
>>>> | 64K | 512M | 4T | 256M | 1T |
>>>> ------------------------------------------------
>>>>
>>>
>>> Interesting. That means user space will have it even harder to optimize
>>> for THP sizes.
>>>
>>> What's the effect on cont-pte? Do they still span the same number of
>>> entries and there is effectively no change?
>>
>> The numbers are the same for 4K base page size but will need
>> some changes for 16K and 64K base page sizes. Something that
>> git missed in this series, will fix it.
>
> Oh, and it would be great to also clearly spell out the effect on
> hugetlb as well. I assume the available hugetlb sizes will change as well.
Sure will update the required information in the commit message as well as in
file arch/arm64/mm/hugetlb.c, where HugeTLB sizes support matrix is enlisted.
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx93-9x9-qsb: Add tianma,tm050rdh03 panel
From: Liu Ying @ 2026-04-09 2:19 UTC (permalink / raw)
To: Frank Li
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <adYy9xesCKsYWNBg@lizhi-Precision-Tower-5810>
On Wed, Apr 08, 2026 at 06:50:31AM -0400, Frank Li wrote:
> On Wed, Apr 08, 2026 at 04:40:37PM +0800, Liu Ying wrote:
>> On Wed, Apr 08, 2026 at 04:28:40AM -0400, Frank Li wrote:
> ...
>>>>>>>
>>>>>>> Is it possible to appply this overlay file and kd50g21-40nt-a1 overlay file
>>>>>>>
>>>>>>> to imx93-9x9-qsb.dtb, so needn't create dtsi.
>>>>>>
>>>>>> I'm sorry, I don't get your question here.
>>>>>> Anyway, the DT overlays are needed, because the 40-pin EXP/PRI interface on
>>>>>> the i.MX93 9x9 QSB board can not only connect to a DPI panel adapter board
>>>>>> but also to an audio hat[2], and maybe more. The newly introduced .dtsi
>>>>>> file just aims to avoid duplicated code.
>>>>>
>>>>> My means apply two overlay files to dtb
>>>>>
>>>>> imx93-9x9-qsb-tianma-tm050rdh03-dtbs += imx93-9x9-qsb.dtb imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo imx93-9x9-qsb-tianma-tm050rdh03.dtbo
>>
>> This ...
>>
>>>>>
>>>>> In imx93-9x9-qsb-tianma-tm050rdh03.dtbo, only include
>>>>> &{/} {
>>>>> panel {
>>>>> compatible = "tianma,tm050rdh03";
>>>>> enable-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>;
>>>>> };
>>>>> };
>>>>
>>>> If an user wants to use imx93-9x9-qsb.dtb and the DT overlay blob
>>>> imx93-9x9-qsb-tianma-tm050rdh03.dtbo to enable the tianma,tm050rdh03
>>>> DPI panel, then it won't work unless the user also apply
>>>> imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo, right?
>>>>
>>>>>
>>>
>>> Yes, imx93-9x9-qsb-tianma-tm050rdh03.dtb already created, which already
>>> applied both overlay file.
>>
>> .... indicates that imx93-9x9-qsb-tianma-tm050rdh03.dtb is generated by
>> applying both imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo and
>> imx93-9x9-qsb-tianma-tm050rdh03.dtbo to imx93-9x9-qsb.dtb.
>> While, imx93-9x9-qsb-tianma-tm050rdh03.dtbo(a DT overlay blob) just contains
>> the panel node, which means that an user __cannot_ enable the tianma,tm050rdh03
>> DPI panel by only applying it to imx93-9x9-qsb.dtb, unless the user also
>> applies imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo. That's why the .dtsi
>> file is needed.
>
> what's problem if we require user do that? Makefile already create finial
> imx93-9x9-qsb-tianma-tm050rdh03.dtb.
The problem is that the user would apply imx93-9x9-qsb-tianma-tm050rdh03.dtbo
to imx93-9x9-qsb.dtb to enable the tianma,tm050rdh03 DPI panel, say in the
U-boot stage with the 'fdt' command, which is fairly a typical usecase, just
like the user would apply imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo to
imx93-9x9-qsb.dtb to enable the ontat,kd50g21-40nt-a1 DPI panel. We cannot
ask the user to additionally apply imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtbo
to enable the tianma,tm050rdh03 DPI panel, because that's very confusing.
Note that imx93-9x9-qsb-tianma-tm050rdh03.dtb certainly can be used to
enable the tianma,tm050rdh03 DPI panel, but in addition to that,
imx93-9x9-qsb.dtb + imx93-9x9-qsb-tianma-tm050rdh03.dtbo can also be
used to enable the panel.
>
> Any user really apply dtso manaully without use kernel's Makefile?
That's not relevant.
The point is that imx93-9x9-qsb-tianma-tm050rdh03.dtbo would be generated
and applied by the user to imx93-9x9-qsb.dtb to enable the tianma,tm050rdh03
DPI panel.
>
>>
>>>
>>> can the same board be use for imx91 or other evk boards?
>>
>> Yes, both tianma,tm050rdh03 and ontat,kd50g21-40nt-a1 DPI panels can be
>> connected to i.MX91/93 11x11 EVK and 9x9 QSB boards.
>
> Is it possible to use one overlay files for all imx91/imx93 boards?
No, that's impossible, because they use GPIO backlight or PWM backlight,
different GPIOs to enable DPI panels and different GPIO hogs.
>
> Frank
>>
>>>
>>> Frank
>>>
>>>>> Frank
>>>>>>
>>>>>> [2] https://www.nxp.com/design/design-center/development-boards-and-designs/mx93aud-hat-audio-board:MX93AUD-HAT
>>>>>>
>>>>>>>
>>>>>>> Frank
>>>>>>>>
>>>>>>>> ---
>>>>>>>> base-commit: 816f193dd0d95246f208590924dd962b192def78
>>>>>>>> change-id: 20260407-tianma-tm050rdh03-imx93-9x9-qsb-6e4bbbde3d08
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> --
>>>>>>>> Liu Ying <victor.liu@nxp.com>
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Liu Ying
>>>>
>>>> --
>>>> Regards,
>>>> Liu Ying
>>
>> --
>> Regards,
>> Liu Ying
--
Regards,
Liu Ying
^ permalink raw reply
* RE: [PATCH V11 04/12] PCI: imx6: Add support for parsing the reset property in new Root Port binding
From: Sherry Sun @ 2026-04-09 2:40 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <t5x45nyn6lw7cofzj2rec5j6z2ml6kve2hvzeeastdrv4hilsu@ujhkmltpp5ky>
> Subject: Re: [PATCH V11 04/12] PCI: imx6: Add support for parsing the reset
> property in new Root Port binding
>
> On Wed, Apr 08, 2026 at 08:34:03AM +0000, Sherry Sun wrote:
> > > On Tue, Apr 07, 2026 at 06:41:46PM +0800, Sherry Sun wrote:
> > > > The current DT binding for pci-imx6 specifies the 'reset-gpios'
> > > > property in the host bridge node. However, the PERST# signal
> > > > logically belongs to individual Root Ports rather than the host bridge
> itself.
> > > > This becomes important when supporting PCIe KeyE connector and PCI
> > > > power control framework for pci-imx6 driver, which requires
> > > > properties to be specified in Root Port nodes.
> > > >
> > > > Add support for parsing 'reset-gpios' from Root Port child nodes
> > > > using the common helper pci_host_common_parse_ports(), and update
> > > > the reset GPIO handling to use the parsed port list from
> > > > bridge->ports. To maintain DT backwards compatibility, fallback to
> > > > the legacy method of parsing the host bridge node if the reset
> > > > property is not present in the Root Port node.
> > > >
> > > > Since now the reset GPIO is obtained with GPIOD_ASIS flag, it may
> > > > be in input mode, using gpiod_direction_output() instead of
> > > > gpiod_set_value_cansleep() to ensure the reset GPIO is properly
> > > > configured as output before setting its value.
> > > >
> > > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > > ---
> > > > drivers/pci/controller/dwc/pci-imx6.c | 75
> > > > +++++++++++++++++++++------
> > > > 1 file changed, 60 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > > index d99da7e42590..dd8f9c0fcec4 100644
> > > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > > @@ -34,6 +34,7 @@
> > > > #include <linux/pm_runtime.h>
> > > >
> > > > #include "../../pci.h"
> > > > +#include "../pci-host-common.h"
> > > > #include "pcie-designware.h"
> > > >
> > > > #define IMX8MQ_GPR_PCIE_REF_USE_PAD BIT(9)
> > > > @@ -152,7 +153,6 @@ struct imx_lut_data {
> > > >
> > > > struct imx_pcie {
> > > > struct dw_pcie *pci;
> > > > - struct gpio_desc *reset_gpiod;
> > > > struct clk_bulk_data *clks;
> > > > int num_clks;
> > > > bool supports_clkreq;
> > > > @@ -1224,6 +1224,32 @@ static void imx_pcie_disable_device(struct
> > > pci_host_bridge *bridge,
> > > > imx_pcie_remove_lut(imx_pcie, pci_dev_id(pdev)); }
> > > >
> > > > +static int imx_pcie_parse_legacy_binding(struct imx_pcie *pcie) {
> > > > + struct device *dev = pcie->pci->dev;
> > > > + struct pci_host_bridge *bridge = pcie->pci->pp.bridge;
> > > > + struct pci_host_port *port;
> > > > + struct gpio_desc *reset;
> > > > +
> > > > + reset = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
> > > > + if (IS_ERR(reset))
> > > > + return PTR_ERR(reset);
> > > > +
> > > > + if (!reset)
> > > > + return 0;
> > > > +
> > > > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > > > + if (!port)
> > > > + return -ENOMEM;
> > > > +
> > > > + port->reset = reset;
> > > > + INIT_LIST_HEAD(&port->list);
> > > > + list_add_tail(&port->list, &bridge->ports);
> > > > +
> > > > + return devm_add_action_or_reset(dev,
> > > pci_host_common_delete_ports,
> > > > + &bridge->ports);
> > > > +}
> > > > +
> > > > static void imx_pcie_vpcie_aux_disable(void *data) {
> > > > struct regulator *vpcie_aux = data; @@ -1233,13 +1259,22 @@
> > > > static void imx_pcie_vpcie_aux_disable(void
> > > > *data)
> > > >
> > > > static void imx_pcie_assert_perst(struct imx_pcie *imx_pcie, bool
> > > > assert) {
> > > > - if (assert) {
> > > > - gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 1);
> > > > - } else {
> > > > - if (imx_pcie->reset_gpiod) {
> > > > - msleep(PCIE_T_PVPERL_MS);
> > > > - gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 0);
> > > > - msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > > > + struct dw_pcie *pci = imx_pcie->pci;
> > > > + struct pci_host_bridge *bridge = pci->pp.bridge;
> > > > + struct pci_host_port *port;
> > > > +
> > > > + if (!bridge)
> > > > + return;
> > > > +
> > > > + list_for_each_entry(port, &bridge->ports, list) {
> > > > + if (assert) {
> > > > + gpiod_direction_output(port->reset, 1);
> > > > + } else {
> > > > + if (port->reset) {
> > > > + msleep(PCIE_T_PVPERL_MS);
> > > > + gpiod_direction_output(port->reset, 0);
> > > > + msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > > > + }
> > >
> > > Sashiko flagged this loop:
> > >
> > > ```
> > > Does this loop multiply the initialization delays?
> > > If a controller has multiple Root Ports, the msleep calls will run
> > > sequentially for each port, linearly increasing the delay. Could we
> > > optimize this by asserting all reset GPIOs, waiting the pre-delay
> > > once, de-asserting all GPIOs, and waiting the post-delay once for the entire
> bus?
> > > ```
> > >
> > > Maybe you should do:
> > >
> > > if (!list_empty(&bridge->ports) && !assert)
> > > msleep(PCIE_T_PVPERL_MS);
> > >
> > > list_for_each_entry(port, &bridge->ports, list) {
> > > ...
> > > gpiod_direction_output(port->reset, 0);
> > > ...
> > > }
> > >
> > > if (!list_empty(&bridge->ports) && !assert)
> > > msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > >
> >
> > Hi Mani, I think the code below looks clearer, is that ok for you?
> >
> > if (assert) {
> > list_for_each_entry(port, &bridge->ports, list)
> > gpiod_direction_output(port->reset, 1);
> > } else {
> > if (list_empty(&bridge->ports))
> > return;
> >
>
> This check should be moved out of the if() condition. Other than this, the
> change looks good.
Ok, will do.
>
> > msleep(PCIE_T_PVPERL_MS);
> > list_for_each_entry(port, &bridge->ports, list)
> > gpiod_direction_output(port->reset, 0);
> > msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > }
> >
> > > And then this:
> > >
> > > ```
> > > Also, since this function is called from imx_pcie_resume_noirq,
> > > which executes with hardware interrupts disabled, does the use of
> > > msleep here trigger a 'sleeping while atomic' bug?
> > > ```
> > >
> > > This is a valid concern. You should use mdelay(). But I'd recommend
> > > switching to IRQ enabled callback, resume() instead. There is no
> > > complelling reason to use resume_noirq() in this driver and adding
> > > delays in noirq() callbacks is not recommended as it may increase the
> overall system resume time.
> > >
> > > I will submit a separate series to convert dw_pcie_resume_noirq()
> > > and its callers to IRQ enabled callbacks since this
> > > dw_pcie_resume_noirq() could potentially cause delay up to 1sec.
> >
> > Yes, this is not a new bug introduced by this patch. I agree we should
> > covert the convert dw_pcie_resume_noirq() and the caller to IRQ
> > enabled callbacks to fix this in a separate patch series.
> > For now, should I leave it as is, or switch to mdelay in this patch?
> >
>
> Just use mdelay() in your patch for now.
Ok, thanks!
Best Regards
Sherry
^ permalink raw reply
* [PATCH] drm/bridge: stm_lvds: Do not fail atomic_check on disabled connector
From: Marek Vasut @ 2026-04-09 2:48 UTC (permalink / raw)
To: dri-devel
Cc: Marek Vasut, Alexandre Torgue, David Airlie, Maarten Lankhorst,
Maxime Coquelin, Maxime Ripard, Philippe Cornu,
Raphael Gallais-Pou, Simona Vetter, Thomas Zimmermann,
Yannick Fertre, linux-arm-kernel, linux-kernel, linux-stm32
If the connector is disabled, the new connector state has .crtc field
set to NULL and there is nothing more to validate after that point.
The .crtc field being NULL is not an error. Test for .crtc being NULL,
and if it is NULL, exit early with return 0.
This fixes a failure in suspend/resume path, where the connector is
already disabled, but .atomic_check is called, fails, returns -EINVAL
and blocks the suspend entry.
Fixes: aca1cbc1c986 ("drm/stm: lvds: add new STM32 LVDS Display Interface Transmitter driver")
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: David Airlie <airlied@gmail.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Philippe Cornu <philippe.cornu@foss.st.com>
Cc: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Yannick Fertre <yannick.fertre@foss.st.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
---
drivers/gpu/drm/stm/lvds.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/stm/lvds.c b/drivers/gpu/drm/stm/lvds.c
index fe38c0984b2b5..25e2ba98f36ae 100644
--- a/drivers/gpu/drm/stm/lvds.c
+++ b/drivers/gpu/drm/stm/lvds.c
@@ -897,14 +897,14 @@ static int lvds_connector_atomic_check(struct drm_connector *connector,
if (!conn_state)
return -EINVAL;
+ if (!conn_state->crtc)
+ return 0;
+
if (list_empty(&connector->modes)) {
drm_dbg(connector->dev, "connector: empty modes list\n");
return -EINVAL;
}
- if (!conn_state->crtc)
- return -EINVAL;
-
panel_mode = list_first_entry(&connector->modes,
struct drm_display_mode, head);
--
2.53.0
^ permalink raw reply related
* RE: [PATCH V11 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Sherry Sun @ 2026-04-09 2:58 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <yijf6mwclpx6n7giucgykxvrm73baicy2urhzns34sxgloli3z@ygose2qrgvuz>
> On Wed, Apr 08, 2026 at 06:34:02AM +0000, Sherry Sun wrote:
>
> [...]
>
> > > > +/**
> > > > + * pci_host_common_parse_port - Parse a single Root Port node
> > > > + * @dev: Device pointer
> > > > + * @bridge: PCI host bridge
> > > > + * @node: Device tree node of the Root Port
> > > > + *
> > > > + * Returns: 0 on success, negative error code on failure */
> > > > +static int pci_host_common_parse_port(struct device *dev,
> > > > + struct pci_host_bridge *bridge,
> > > > + struct device_node *node) {
> > > > + struct pci_host_port *port;
> > > > + struct gpio_desc *reset;
> > > > +
> > > > + reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(node),
> > > > + "reset", GPIOD_ASIS, "PERST#");
> > >
> > > Sorry, I missed this earlier.
> > >
> > > Since PERST# is optional, you cannot reliably detect whether the
> > > Root Port binding intentionally skipped the PERST# GPIO or legacy
> > > binding is used, just by checking for PERST# in Root Port node.
> > >
> > > So this helper should do 3 things:
> > >
> > > 1. If PERST# is found in Root Port node, use it.
> > > 2. If not, check the RC node and if present, return -ENOENT to
> > > fallback to the legacy binding.
> > > 3. If not found in both nodes, assume that the PERST# is not present
> > > in the design, and proceed with parsing Root Port binding further.
> >
> > Hi Mani, understand, does the following code looks ok for above three
> cases?
> >
> > /* Check if PERST# is present in Root Port node */
> > reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(node),
> > "reset", GPIOD_ASIS, "PERST#");
> > if (IS_ERR(reset)) {
> > /* If error is not -ENOENT, it's a real error */
> > if (PTR_ERR(reset) != -ENOENT)
> > return PTR_ERR(reset);
> >
> > /* PERST# not found in Root Port node, check RC node */
> > rc_has_reset = of_property_read_bool(dev->of_node, "reset-gpios") ||
> > of_property_read_bool(dev->of_node, "reset-gpio");
>
> Just:
> if (of_property_read_bool(dev->of_node, "reset-gpios") ||
> of_property_read_bool(dev->of_node, "reset-gpio")) {
> return -ENOENT;
> }
Ok, will do.
>
> > if (rc_has_reset)
> > return -ENOENT;
> >
> > /* No PERST# in either node, assume not present in design */
> > reset = NULL;
> > }
> >
> > port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > if (!port)
> > return -ENOMEM;
> > ...
> >
> > >
> > > But there is one more important limitation here. Right now, this API
> > > only handles PERST#. But if another vendor tries to use it and if
> > > they need other properties such as PHY, clocks etc... those
> > > resources should be fetched optionally only by this helper. But if
> > > the controller has a hard dependency on those resources, the driver will
> fail to operate.
> > >
> > > I don't think we can fix this limitation though and those platforms
> > > should ensure that the resource dependency is correctly modeled in
> > > DT binding and the DTS is validated properly. It'd be good to
> > > mention this in the kernel doc of this API.
> >
> > Ok, I will add a NOTE for this in this API description.
> >
> > >
> > > > + if (IS_ERR(reset))
> > > > + return PTR_ERR(reset);
> > > > +
> > > > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > > > + if (!port)
> > > > + return -ENOMEM;
> > > > +
> > > > + port->reset = reset;
> > > > + INIT_LIST_HEAD(&port->list);
> > > > + list_add_tail(&port->list, &bridge->ports);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +/**
> > > > + * pci_host_common_parse_ports - Parse Root Port nodes from
> > > > +device tree
> > > > + * @dev: Device pointer
> > > > + * @bridge: PCI host bridge
> > > > + *
> > > > + * This function iterates through child nodes of the host bridge
> > > > +and parses
> > > > + * Root Port properties (currently only reset GPIO).
> > > > + *
> > > > + * Returns: 0 on success, -ENOENT if no ports found, other
> > > > +negative error codes
> > > > + * on failure
> > > > + */
> > > > +int pci_host_common_parse_ports(struct device *dev, struct
> > > > +pci_host_bridge *bridge) {
> > > > + int ret = -ENOENT;
> > > > +
> > > > + for_each_available_child_of_node_scoped(dev->of_node, of_port) {
> > > > + if (!of_node_is_type(of_port, "pci"))
> > > > + continue;
> > > > + ret = pci_host_common_parse_port(dev, bridge, of_port);
> > > > + if (ret)
> > > > + return ret;
> > >
> > > As Sashiko flagged, you need to make sure that
> > > devm_add_action_or_reset() is added even during the error path:
> >
> > Yes, it needs to be fixed. We can handle it with the following two methods, I
> am not sure which method is better or more preferable?
> >
> > #1: register cleanup action after first successful port parse and use
> cleanup_registered flag to avoid duplicate register.
> > int ret = -ENOENT;
> > bool cleanup_registered = false;
> >
> > for_each_available_child_of_node_scoped(dev->of_node, of_port) {
> > if (!of_node_is_type(of_port, "pci"))
> > continue;
> > ret = pci_host_common_parse_port(dev, bridge, of_port);
> > if (ret)
> > return ret;
> >
> > /* Register cleanup action after first successful port parse */
> > if (!cleanup_registered) {
> > ret = devm_add_action_or_reset(dev,
> > pci_host_common_delete_ports,
> > &bridge->ports);
>
> Even if you register devm_add_action_or_reset(), it won't be called when
> pci_host_common_parse_port() fails since the legacy fallback will be used.
>
> So you need to manually call pci_host_common_delete_ports() in the error
> path.
Get your point, so seems I should just add the err_cleanup handle path like this, right?
for_each_available_child_of_node_scoped(dev->of_node, of_port) {
if (!of_node_is_type(of_port, "pci"))
continue;
ret = pci_host_common_parse_port(dev, bridge, of_port);
if (ret)
goto err_cleanup;
}
if (ret)
return ret;
return devm_add_action_or_reset(dev, pci_host_common_delete_ports,
&bridge->ports);
err_cleanup:
pci_host_common_delete_ports(&bridge->ports);
return ret;
Best Regards
Sherry
^ permalink raw reply
* Re: [PATCH v1 1/3] dt-bindings: arm: fsl: add Variscite VAR-SOM-MX91 Boards
From: Peng Fan @ 2026-04-09 3:05 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Shawn Guo, Dario Binacchi, Markus Niebel, Maud Spierings,
Alexander Stein, Ernest Van Hoecke, Josua Mayer,
Francesco Dolcini, Primoz Fiser
In-Reply-To: <86635091cd5db0ecb7f07c5ad9d6f735ec349485.1775669847.git.stefano.r@variscite.com>
On Wed, Apr 08, 2026 at 07:39:44PM +0200, Stefano Radaelli wrote:
>From: Stefano Radaelli <stefano.r@variscite.com>
>
>Add DT compatible strings for Variscite VAR-SOM-MX91 SoM and Symphony
>development carrier Board.
>
>Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* Re: [PATCH] ACPI: APEI: Handle repeated SEA error interrupts storm scenarios
From: hejunhao @ 2026-04-09 3:10 UTC (permalink / raw)
To: Shuai Xue, Rafael J. Wysocki, Luck, Tony, linmiaohe@huawei.com
Cc: bp, guohanjun, mchehab, jarkko, yazen.ghannam, jane.chu, lenb,
Jonathan.Cameron, linux-acpi, linux-arm-kernel, linux-kernel,
linux-edac, shiju.jose, tanxiaofei, Linuxarm
In-Reply-To: <08c7aee3-b3a6-4696-b54f-0c7bc70a2929@linux.alibaba.com>
On 2026/4/7 10:23, Shuai Xue wrote:
>
>
> On 3/26/26 9:26 PM, hejunhao wrote:
>>
>> On 2026/3/25 20:40, Shuai Xue wrote:
>>>
>>>
>>> On 3/25/26 5:24 PM, hejunhao wrote:
>>>>
>>>>
>>>> On 2026/3/25 10:12, Shuai Xue wrote:
>>>>> Hi, junhao
>>>>>
>>>>> On 3/24/26 6:04 PM, hejunhao wrote:
>>>>>> Hi shuai xue,
>>>>>>
>>>>>>
>>>>>> On 2026/3/3 22:42, Shuai Xue wrote:
>>>>>>> Hi, junhao,
>>>>>>>
>>>>>>> On 2/27/26 8:12 PM, hejunhao wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2025/11/4 9:32, Shuai Xue wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 在 2025/11/4 00:19, Rafael J. Wysocki 写道:
>>>>>>>>>> On Thu, Oct 30, 2025 at 8:13 AM Junhao He <hejunhao3@h-partners.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> The do_sea() function defaults to using firmware-first mode, if supported.
>>>>>>>>>>> It invoke acpi/apei/ghes ghes_notify_sea() to report and handling the SEA
>>>>>>>>>>> error, The GHES uses a buffer to cache the most recent 4 kinds of SEA
>>>>>>>>>>> errors. If the same kind SEA error continues to occur, GHES will skip to
>>>>>>>>>>> reporting this SEA error and will not add it to the "ghes_estatus_llist"
>>>>>>>>>>> list until the cache times out after 10 seconds, at which point the SEA
>>>>>>>>>>> error will be reprocessed.
>>>>>>>>>>>
>>>>>>>>>>> The GHES invoke ghes_proc_in_irq() to handle the SEA error, which
>>>>>>>>>>> ultimately executes memory_failure() to process the page with hardware
>>>>>>>>>>> memory corruption. If the same SEA error appears multiple times
>>>>>>>>>>> consecutively, it indicates that the previous handling was incomplete or
>>>>>>>>>>> unable to resolve the fault. In such cases, it is more appropriate to
>>>>>>>>>>> return a failure when encountering the same error again, and then proceed
>>>>>>>>>>> to arm64_do_kernel_sea for further processing.
>>>>>>>
>>>>>>> There is no such function in the arm64 tree. If apei_claim_sea() returns
>>>>>>
>>>>>> Sorry for the mistake in the commit message. The function arm64_do_kernel_sea() should
>>>>>> be arm64_notify_die().
>>>>>>
>>>>>>> an error, the actual fallback path in do_sea() is arm64_notify_die(),
>>>>>>> which sends SIGBUS?
>>>>>>>
>>>>>>
>>>>>> If apei_claim_sea() returns an error, arm64_notify_die() will call arm64_force_sig_fault(inf->sig /* SIGBUS */, , , ),
>>>>>> followed by force_sig_fault(SIGBUS, , ) to force the process to receive the SIGBUS signal.
>>>>>
>>>>> So the process is expected to killed by SIGBUS?
>>>>
>>>> Yes. The devmem process is expected to terminate upon receiving a SIGBUS signal, you can
>>>> see this at the last line of the test log after the patch is applied.
>>>> For other processes whether it terminates depends on whether it catches the signal; the kernel is
>>>> responsible for sending it immediately.
>>>>
>>>>>
>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> When hardware memory corruption occurs, a memory error interrupt is
>>>>>>>>>>> triggered. If the kernel accesses this erroneous data, it will trigger
>>>>>>>>>>> the SEA error exception handler. All such handlers will call
>>>>>>>>>>> memory_failure() to handle the faulty page.
>>>>>>>>>>>
>>>>>>>>>>> If a memory error interrupt occurs first, followed by an SEA error
>>>>>>>>>>> interrupt, the faulty page is first marked as poisoned by the memory error
>>>>>>>>>>> interrupt process, and then the SEA error interrupt handling process will
>>>>>>>>>>> send a SIGBUS signal to the process accessing the poisoned page.
>>>>>>>>>>>
>>>>>>>>>>> However, if the SEA interrupt is reported first, the following exceptional
>>>>>>>>>>> scenario occurs:
>>>>>>>>>>>
>>>>>>>>>>> When a user process directly requests and accesses a page with hardware
>>>>>>>>>>> memory corruption via mmap (such as with devmem), the page containing this
>>>>>>>>>>> address may still be in a free buddy state in the kernel. At this point,
>>>>>>>>>>> the page is marked as "poisoned" during the SEA claim memory_failure().
>>>>>>>>>>> However, since the process does not request the page through the kernel's
>>>>>>>>>>> MMU, the kernel cannot send SIGBUS signal to the processes. And the memory
>>>>>>>>>>> error interrupt handling process not support send SIGBUS signal. As a
>>>>>>>>>>> result, these processes continues to access the faulty page, causing
>>>>>>>>>>> repeated entries into the SEA exception handler. At this time, it lead to
>>>>>>>>>>> an SEA error interrupt storm.
>>>>>>>
>>>>>>> In such case, the user process which accessing the poisoned page will be killed
>>>>>>> by memory_fauilre?
>>>>>>>
>>>>>>> // memory_failure():
>>>>>>>
>>>>>>> if (TestSetPageHWPoison(p)) {
>>>>>>> res = -EHWPOISON;
>>>>>>> if (flags & MF_ACTION_REQUIRED)
>>>>>>> res = kill_accessing_process(current, pfn, flags);
>>>>>>> if (flags & MF_COUNT_INCREASED)
>>>>>>> put_page(p);
>>>>>>> action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED);
>>>>>>> goto unlock_mutex;
>>>>>>> }
>>>>>>>
>>>>>>> I think this problem has already been fixed by commit 2e6053fea379 ("mm/memory-failure:
>>>>>>> fix infinite UCE for VM_PFNMAP pfn").
>>>>>>>
>>>>>>> The root cause is that walk_page_range() skips VM_PFNMAP vmas by default when
>>>>>>> no .test_walk callback is set, so kill_accessing_process() returns 0 for a
>>>>>>> devmem-style mapping (remap_pfn_range, VM_PFNMAP), making the caller believe
>>>>>>> the UCE was handled properly while the process was never actually killed.
>>>>>>>
>>>>>>> Did you try the lastest kernel version?
>>>>>>>
>>>>>>
>>>>>> I retested this issue on the kernel v7.0.0-rc4 with the following debug patch and was still able to reproduce it.
>>>>>>
>>>>>>
>>>>>> @@ -1365,8 +1365,11 @@ static int ghes_in_nmi_queue_one_entry(struct ghes *ghes,
>>>>>> ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
>>>>>>
>>>>>> /* This error has been reported before, don't process it again. */
>>>>>> - if (ghes_estatus_cached(estatus))
>>>>>> + if (ghes_estatus_cached(estatus)) {
>>>>>> + pr_info("This error has been reported before, don't process it again.\n");
>>>>>> goto no_work;
>>>>>> + }
>>>>>>
>>>>>> the test log Only some debug logs are retained here.
>>>>>>
>>>>>> [2026/3/24 14:51:58.199] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32 0
>>>>>> [2026/3/24 14:51:58.369] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32
>>>>>> [2026/3/24 14:51:58.458] [ 130.558038][ C40] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
>>>>>> [2026/3/24 14:51:58.459] [ 130.572517][ C40] {1}[Hardware Error]: event severity: recoverable
>>>>>> [2026/3/24 14:51:58.459] [ 130.578861][ C40] {1}[Hardware Error]: Error 0, type: recoverable
>>>>>> [2026/3/24 14:51:58.459] [ 130.585203][ C40] {1}[Hardware Error]: section_type: ARM processor error
>>>>>> [2026/3/24 14:51:58.459] [ 130.592238][ C40] {1}[Hardware Error]: MIDR: 0x0000000000000000
>>>>>> [2026/3/24 14:51:58.459] [ 130.598492][ C40] {1}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081010400
>>>>>> [2026/3/24 14:51:58.459] [ 130.607871][ C40] {1}[Hardware Error]: error affinity level: 0
>>>>>> [2026/3/24 14:51:58.459] [ 130.614038][ C40] {1}[Hardware Error]: running state: 0x1
>>>>>> [2026/3/24 14:51:58.459] [ 130.619770][ C40] {1}[Hardware Error]: Power State Coordination Interface state: 0
>>>>>> [2026/3/24 14:51:58.459] [ 130.627673][ C40] {1}[Hardware Error]: Error info structure 0:
>>>>>> [2026/3/24 14:51:58.459] [ 130.633839][ C40] {1}[Hardware Error]: num errors: 1
>>>>>> [2026/3/24 14:51:58.459] [ 130.639137][ C40] {1}[Hardware Error]: error_type: 0, cache error
>>>>>> [2026/3/24 14:51:58.459] [ 130.645652][ C40] {1}[Hardware Error]: error_info: 0x0000000020400014
>>>>>> [2026/3/24 14:51:58.459] [ 130.652514][ C40] {1}[Hardware Error]: cache level: 1
>>>>>> [2026/3/24 14:51:58.551] [ 130.658073][ C40] {1}[Hardware Error]: the error has not been corrected
>>>>>> [2026/3/24 14:51:58.551] [ 130.665194][ C40] {1}[Hardware Error]: physical fault address: 0x0000001351811800
>>>>>> [2026/3/24 14:51:58.551] [ 130.673097][ C40] {1}[Hardware Error]: Vendor specific error info has 48 bytes:
>>>>>> [2026/3/24 14:51:58.551] [ 130.680744][ C40] {1}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
>>>>>> [2026/3/24 14:51:58.551] [ 130.690471][ C40] {1}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
>>>>>> [2026/3/24 14:51:58.552] [ 130.700198][ C40] {1}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
>>>>>> [2026/3/24 14:51:58.552] [ 130.710083][ T9767] Memory failure: 0x1351811: recovery action for free buddy page: Recovered
>>>>>> [2026/3/24 14:51:58.638] [ 130.790952][ C40] This error has been reported before, don't process it again.
>>>>>> [2026/3/24 14:51:58.903] [ 131.046994][ C40] This error has been reported before, don't process it again.
>>>>>> [2026/3/24 14:51:58.991] [ 131.132360][ C40] This error has been reported before, don't process it again.
>>>>>> [2026/3/24 14:51:59.969] [ 132.071431][ C40] This error has been reported before, don't process it again.
>>>>>> [2026/3/24 14:52:00.860] [ 133.010255][ C40] This error has been reported before, don't process it again.
>>>>>> [2026/3/24 14:52:01.927] [ 134.034746][ C40] This error has been reported before, don't process it again.
>>>>>> [2026/3/24 14:52:02.906] [ 135.058973][ C40] This error has been reported before, don't process it again.
>>>>>> [2026/3/24 14:52:03.971] [ 136.083213][ C40] This error has been reported before, don't process it again.
>>>>>> [2026/3/24 14:52:04.860] [ 137.021956][ C40] This error has been reported before, don't process it again.
>>>>>> [2026/3/24 14:52:06.018] [ 138.131460][ C40] This error has been reported before, don't process it again.
>>>>>> [2026/3/24 14:52:06.905] [ 139.070280][ C40] This error has been reported before, don't process it again.
>>>>>> [2026/3/24 14:52:07.886] [ 140.009147][ C40] This error has been reported before, don't process it again.
>>>>>> [2026/3/24 14:52:08.596] [ 140.777368][ C40] {2}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
>>>>>> [2026/3/24 14:52:08.683] [ 140.791921][ C40] {2}[Hardware Error]: event severity: recoverable
>>>>>> [2026/3/24 14:52:08.683] [ 140.798263][ C40] {2}[Hardware Error]: Error 0, type: recoverable
>>>>>> [2026/3/24 14:52:08.683] [ 140.804606][ C40] {2}[Hardware Error]: section_type: ARM processor error
>>>>>> [2026/3/24 14:52:08.683] [ 140.811641][ C40] {2}[Hardware Error]: MIDR: 0x0000000000000000
>>>>>> [2026/3/24 14:52:08.684] [ 140.817895][ C40] {2}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081010400
>>>>>> [2026/3/24 14:52:08.684] [ 140.827274][ C40] {2}[Hardware Error]: error affinity level: 0
>>>>>> [2026/3/24 14:52:08.684] [ 140.833440][ C40] {2}[Hardware Error]: running state: 0x1
>>>>>> [2026/3/24 14:52:08.684] [ 140.839173][ C40] {2}[Hardware Error]: Power State Coordination Interface state: 0
>>>>>> [2026/3/24 14:52:08.684] [ 140.847076][ C40] {2}[Hardware Error]: Error info structure 0:
>>>>>> [2026/3/24 14:52:08.684] [ 140.853241][ C40] {2}[Hardware Error]: num errors: 1
>>>>>> [2026/3/24 14:52:08.684] [ 140.858540][ C40] {2}[Hardware Error]: error_type: 0, cache error
>>>>>> [2026/3/24 14:52:08.684] [ 140.865055][ C40] {2}[Hardware Error]: error_info: 0x0000000020400014
>>>>>> [2026/3/24 14:52:08.684] [ 140.871917][ C40] {2}[Hardware Error]: cache level: 1
>>>>>> [2026/3/24 14:52:08.684] [ 140.877475][ C40] {2}[Hardware Error]: the error has not been corrected
>>>>>> [2026/3/24 14:52:08.764] [ 140.884596][ C40] {2}[Hardware Error]: physical fault address: 0x0000001351811800
>>>>>> [2026/3/24 14:52:08.764] [ 140.892499][ C40] {2}[Hardware Error]: Vendor specific error info has 48 bytes:
>>>>>> [2026/3/24 14:52:08.766] [ 140.900145][ C40] {2}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
>>>>>> [2026/3/24 14:52:08.767] [ 140.909872][ C40] {2}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
>>>>>> [2026/3/24 14:52:08.767] [ 140.919598][ C40] {2}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
>>>>>> [2026/3/24 14:52:08.768] [ 140.929346][ T9767] Memory failure: 0x1351811: already hardware poisoned
>>>>>> [2026/3/24 14:52:08.768] [ 140.936072][ T9767] Memory failure: 0x1351811: Sending SIGBUS to busybox:9767 due to hardware memory corruption
>>>>>
>>>>> Did you cut off some logs here?
>>>>
>>>> I just removed some duplicate debug logs: "This error has already been...", these were added by myself.
>>
>> Hi, Shuai
>
> Hi, Junhao,
>
> Sorry for late reply.
>
>>
>> Compared to the original commit message and the logs reproducing this issue
>> on kernel v7.0.0-rc4, perhaps you are asking whether the current log is missing
>> information such as 'NOTICE: SEA Handle'?
>> These miss logs are from the firmware. To reduce serial output, the firmware has
>> hidden these debug prints. However, using my own custom debug logs, I can
>> still see that the kernel's do_sea() process is continuously running during the
>> 10-second cache timeout. Although only one debug log is retained per second.
>> This confirms that the issue is still present on the latest kernel v7.0.0-rc4.
>>
>>>>> The error log also indicates that the SIGBUS is delivered as expected.
>>>>
>>>> An SError occurs at kernel time 130.558038. Then, after 10 seconds, the kernel
>>>> can re-enter the SEA processing flow and send the SIGBUS signal to the process.
>>>> This 10-second delay corresponds to the cache timeout threshold of the
>>>> ghes_estatus_cached() feature.
>>>> Therefore, the purpose of this patch is to send the SIGBUS signal to the process
>>>> immediately, rather than waiting for the timeout to expire.
>>>
>>> Hi, hejun,
>>>
>>> Sorry, but I am still not convinced by the log you provided.
>>>
>>> As I understand your commit message, there are two different cases being discussed:
>>>
>>> Case 1: memory error interrupt first, then SEA
>>>
>>> When hardware memory corruption occurs, a memory error interrupt is
>>> triggered first. If the kernel later accesses the corrupted data, it may
>>> then enter the SEA handler. In this case, the faulty page would already
>>> have been marked poisoned by the memory error interrupt path, and the SEA
>>> handling path would eventually send SIGBUS to the task accessing that page.
>>>
>>> Case 2: SEA first, then memory error interrupt
>>>
>>> Your commit message describes this as the problematic scenario:
>>>
>>> A user process directly accesses hardware-corrupted memory through a
>>> PFNMAP-style mapping such as devmem. The page may still be in the free
>>> buddy state when SEA is handled first. In that case, memory_failure()
>>> poisons the page during SEA handling, but the process is not killed
>>> immediately. Since the task continues accessing the same corrupted
>>> location, it keeps re-entering the SEA handler, leading to an SEA storm.
>>> Later, the memory error interrupt path also cannot kill the task, so the
>>> system remains stuck in this repeated SEA loop.
>> Yes.
>>>
>>> My concern is that your recent explanation and log seem to demonstrate
>>> something different from what the commit message claims to fix.
>>>
>>> From the log, what I can see is:
>>>
>>> the first SEA occurs,
>>> the page is marked poisoned as a free buddy page,
>>> repeated SEAs are suppressed by ghes_estatus_cached(),
>>> after the cache timeout expires, the SEA path runs again,
>>> then memory_failure() reports "already hardware poisoned" and SIGBUS is
>>> sent to the busybox devmem process.
>>> This seems to show a delayed SIGBUS delivery caused by the GHES cache
>>> timeout, rather than clearly demonstrating the SEA storm problem described
>>> in the commit message.
>>>
>>> So I think there is still a mismatch here:
>>>
>>> If the patch is intended to fix the SEA storm described in case 2,
>>> then I would expect evidence that the storm still exists on the latest
>>> kernel and that this patch is what actually breaks that loop.
>>> If instead the patch is intended to avoid the 10-second delay before
>>> SIGBUS delivery, then that should be stated explicitly, because that is
>>> a different problem statement from what the current commit message says.
>>> Also, regarding the devmem/PFNMAP case: I previously pointed to commit
>>> 2e6053fea379 ("mm/memory-failure: fix infinite UCE for VM_PFNMAP pfn"),
>>> which was meant to address the failure to kill tasks accessing poisoned
>>> VM_PFNMAP mappings.
>>>
>>
>> This patch was already merged prior to kernel v7.0.0-rc4, therefore, it cannot fix this issue.
>>
>> I reverted the patch on kernel v7.0.0-rc4 to reproduce the issue.
>> The debug logs show that the message 'This error has already been...' persists
>> for more than 10 seconds, and the printing cannot be stopped. so it fixes other issue.
>
> Thanks for confirm.
>
>>
>>> So my main question is:
>>>
>>> Does the SEA storm issue still exist on the latest kernel version, or is
>>> the remaining issue only that SIGBUS is delayed by the GHES estatus cache
>>> timeout?
>>
>> We should not treat them separately.
>
> Agreed. Please update the commit message to explain the causal chain explicitly:
Sure, Will fix in next version.
>
> - The first SEA poisons the free buddy page but does not kill the
> accessing task, because memory_failure() takes the free-buddy recovery
> path and never reaches kill_accessing_process().
>
> - The task re-enters the SEA handler repeatedly, but
> ghes_estatus_cached() suppresses all subsequent entries during the
> 10-second window, preventing ghes_do_proc() from being called and
> blocking the MF_ACTION_REQUIRED-based SIGBUS delivery.
>
> - This suppression is what sustains the SEA storm.
>
>>
>> In case 2, First SEA can only poisons the page, and then re-enter the SEA processing flow.
>> Due to the reporting throttle of the ghes_estatus_cached(), SEA cannot timely invoke
>> memory_failure() to kill the task, the task will continues accessing the same corrupted
>> location, then re-enter the SEA processing flow loop, so causing the SEA storm...
>> Perhaps I never clearly explained why the SEA storm occurred.
>
> +cc Lin Miaohe for the memory_failure() discussion.
>
> Regarding the memory_failure() path: since SEA is a synchronous
> notification, is_hest_syncnotify() returns true, ghesdo_proc() sets sync
> = true, and MF_ACTION_REQUIRED is passed into ghes_do_memory_failure().
> This means that on the second and subsequent SEAs (after cache expiry),
> memory_failure() would reach the already-poisoned branch and call
> kill_accessing_process() to terminate the task:
>
>
> if (TestSetPageHWPoison(p)) {
> res = -EHWPOISON;
> if (flags & MF_ACTION_REQUIRED)
> res = kill_accessing_process(current, pfn, flags);
> if (flags & MF_COUNT_INCREASED)
> put_page(p);
> action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED);
> goto unlock_mutex;
> }
>
> The patch short-circuits this by terminating the task earlier, via
> arm64_notify_die(), on every cache-suppressed SEA. I have no objection
> to killing the process early in this way.
>
> +cc Tony Luck for the ghes_notify_nmi path.
>
> One concern is the impact on ghes_notify_nmi().
>
> ghes_in_nmi_queue_one_entry() is shared between two callers:
>
> ghes_notify_sea() → ghes_in_nmi_spool_from_list(&ghes_sea, ...)
> ghes_notify_nmi() → ghes_in_nmi_spool_from_list(&ghes_nmi, ...)
Can we use fixmap_idx to distinguish between SEA and NMI? The basis for
differentiation is that the parameters passed to ghes_in_nmi_spool_from_list()
differ when these two exceptions are handled.
ghes_in_nmi_spool_from_list(&ghes_sea, FIX_APEI_GHES_SEA)
ghes_in_nmi_spool_from_list(&ghes_nmi, FIX_APEI_GHES_NMI)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 8acd2742bb27..5c0a7ecad7db 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -1365,8 +1365,11 @@ static int ghes_in_nmi_queue_one_entry(struct ghes *ghes,
ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
/* This error has been reported before, don't process it again. */
- if (ghes_estatus_cached(estatus))
+ if (ghes_estatus_cached(estatus)) {
+ if (fixmap_idx == FIX_APEI_GHES_SEA)
+ rc = -ECANCELED;
goto no_work;
+ }
llist_add(&estatus_node->llnode, &ghes_estatus_llist);
Best regards,
Junhao.
>
> For the NMI path, if ghes_estatuscached() hits and
> ghesin_nmi_queue_one_entry() now returns -ECANCELED instead of 0,
> ghesinnmi_spool_from_list() will not set ret = 0, and ghes_notify_nmi()
> will return NMI_DONE instead of NMI_HANDLED. This tells the NMI handler
> chain that no handler claimed the interrupt, which is semantically
> incorrect — an active hardware error was observed, but deliberately
> suppressed by the cache. NMI errors are asynchronous (sync = false,
> MF_ACTION_REQUIRED not set), so there is no practical impact on the kill
> path. However, returning NMI_DONE for a cache-suppressed NMI could cause
> spurious warnings from the NMI dispatcher on some platforms. To avoid
> this, I suggest scoping the -ECANCELED return to the synchronous (SEA)
> case only. One approach is to pass a bool sync parameter down through
> ghes_in_nmi_spool_from_list() and ghes_innmiqueue_one_entry(), returning
> -ECANCELED on cache-hit only when sync is true. Alternatively, this
> logic can be handled at the ghes_notify_sea() call site directly.
>
> Shuai
> Thanks.
> Shuai
> .
>
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX91
From: Frank Li @ 2026-04-09 3:30 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Dario Binacchi, Markus Niebel, Maud Spierings, Alexander Stein,
Ernest Van Hoecke, Josua Mayer, Francesco Dolcini, Primoz Fiser
In-Reply-To: <1ed7e2100e3feb74c9f0006d5b88e1bba1ad4339.1775669847.git.stefano.r@variscite.com>
On Wed, Apr 08, 2026 at 07:39:45PM +0200, Stefano Radaelli wrote:
> From: Stefano Radaelli <stefano.r@variscite.com>
>
> Add device tree support for the Variscite VAR-SOM-MX91 system on module.
> This SOM is designed to be used with various carrier boards.
>
> The module includes:
> - NXP i.MX91 MPU processor
> - Up to 2GB of LPDDR4 memory
> - Up to 128GB of eMMC storage memory
> - Integrated 10/100/1000 Mbps Ethernet Transceiver
> - Codec audio WM8904
> - WIFI6 dual-band 802.11ax/ac/a/b/g/n with optional 802.15.4 and Bluetooth
>
> Only SOM-specific peripherals are enabled by default. Carrier board
> specific interfaces are left disabled to be enabled in the respective
> carrier board device trees.
>
> Link: https://variscite.com/system-on-module-som/i-mx-9/i-mx-91/var-som-mx91/
> Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
> ---
> .../boot/dts/freescale/imx91-var-som.dtsi | 456 ++++++++++++++++++
what' difference with imx93-var-som ? Can you reuse it?
Frank
>
^ permalink raw reply
* Re: [PATCH v2] interconnect: imx: fix use-after-free in imx_icc_node_init_qos()
From: Frank Li @ 2026-04-09 3:34 UTC (permalink / raw)
To: Wentao Liang
Cc: Georgi Djakov, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-pm, imx, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <20260408153022.401123-1-vulab@iscas.ac.cn>
On Wed, Apr 08, 2026 at 03:30:22PM +0000, Wentao Liang wrote:
> The function imx_icc_node_init_qos() manually manages the reference count
> of struct device_node *dn using of_node_put(). However, some error paths
> use dn after the put, leading to use-after-free. Convert to automatic
> cleanup using __free(device_node) to ensure the reference is always
> released when dn goes out of scope.
>
> Fixes: f0d8048525d7 ("interconnect: Add imx core driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> Changes in v2:
> - Use auto cheanup to fix the problem.
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/interconnect/imx/imx.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/interconnect/imx/imx.c b/drivers/interconnect/imx/imx.c
> index 9511f80cf041..e5fcdcb88cfb 100644
> --- a/drivers/interconnect/imx/imx.c
> +++ b/drivers/interconnect/imx/imx.c
> @@ -120,7 +120,8 @@ static int imx_icc_node_init_qos(struct icc_provider *provider,
> struct imx_icc_node *node_data = node->data;
> const struct imx_icc_node_adj_desc *adj = node_data->desc->adj;
> struct device *dev = provider->dev;
> - struct device_node *dn = NULL;
> + struct device_node *__free(device_nod) dn = of_parse_phandle(dev->of_node,
> + adj->phandle_name, 0);
> struct platform_device *pdev;
>
> if (adj->main_noc) {
> @@ -128,7 +129,6 @@ static int imx_icc_node_init_qos(struct icc_provider *provider,
> dev_dbg(dev, "icc node %s[%d] is main noc itself\n",
> node->name, node->id);
> } else {
> - dn = of_parse_phandle(dev->of_node, adj->phandle_name, 0);
> if (!dn) {
> dev_warn(dev, "Failed to parse %s\n",
> adj->phandle_name);
> @@ -138,12 +138,10 @@ static int imx_icc_node_init_qos(struct icc_provider *provider,
> if (!of_device_is_available(dn)) {
> dev_warn(dev, "Missing property %s, skip scaling %s\n",
> adj->phandle_name, node->name);
> - of_node_put(dn);
> return 0;
> }
>
> pdev = of_find_device_by_node(dn);
> - of_node_put(dn);
> if (!pdev) {
> dev_warn(dev, "node %s[%d] missing device for %pOF\n",
> node->name, node->id, dn);
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH v1] phy: rockchip-snps-pcie3:phy: Configure clkreq_n and PowerDown for all lanes
From: Anand Moon @ 2026-04-09 4:49 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner,
open list:GENERIC PHY FRAMEWORK,
moderated list:ARM/Rockchip SoC support,
open list:ARM/Rockchip SoC support, open list
Cc: Anand Moon, Niklas Cassel
During the rk3588_p3phy_init sequence, the driver now explicitly
configures each lane's CON0 register to ensure
- PIPE 4.3 Compliance: clkreq_n (bit 6) is forced low (asserted) to meet
sideband signal requirements.
- Active Power State: PowerDown[3:0] (bits 11:8) is set to P0
(Normal Operational State) to ensure the PHY is fully powered and ready
for link training.
These changes ensure that all lanes are consistently transitioned from
reset into a known-good operational state, preventing undefined behavior
and ensuring the PHY is ready for high-speed data transmission.
Cc: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
.../phy/rockchip/phy-rockchip-snps-pcie3.c | 28 +++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
index 4e8ffd173096..f46e13e79a0e 100644
--- a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
+++ b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
@@ -7,6 +7,7 @@
#include <linux/clk.h>
#include <linux/delay.h>
+#include <linux/hw_bitfield.h>
#include <linux/io.h>
#include <linux/iopoll.h>
#include <linux/kernel.h>
@@ -35,10 +36,14 @@
#define RK3588_PCIE3PHY_GRF_CMN_CON0 0x0
#define RK3588_PCIE3PHY_GRF_PHY0_STATUS1 0x904
#define RK3588_PCIE3PHY_GRF_PHY1_STATUS1 0xa04
+#define RK3588_PCIE3PHY_GRF_PHY0_LN0_CON0 0x1000
#define RK3588_PCIE3PHY_GRF_PHY0_LN0_CON1 0x1004
#define RK3588_PCIE3PHY_GRF_PHY0_LN1_CON1 0x1104
+#define RK3588_PCIE3PHY_GRF_PHY0_LN1_CON0 0x1100
+#define RK3588_PCIE3PHY_GRF_PHY1_LN0_CON0 0x2000
#define RK3588_PCIE3PHY_GRF_PHY1_LN0_CON1 0x2004
#define RK3588_PCIE3PHY_GRF_PHY1_LN1_CON1 0x2104
+#define RK3588_PCIE3PHY_GRF_PHY1_LN1_CON0 0x2100
#define RK3588_SRAM_INIT_DONE(reg) (reg & BIT(0))
#define RK3588_BIFURCATION_LANE_0_1 BIT(0)
@@ -49,6 +54,13 @@
#define RK3588_PCIE1LN_SEL_EN (GENMASK(1, 0) << 16)
#define RK3588_PCIE30_PHY_MODE_EN (GENMASK(2, 0) << 16)
+static const u32 rk3588_lane_con0[] = {
+ RK3588_PCIE3PHY_GRF_PHY0_LN0_CON0,
+ RK3588_PCIE3PHY_GRF_PHY0_LN1_CON0,
+ RK3588_PCIE3PHY_GRF_PHY1_LN0_CON0,
+ RK3588_PCIE3PHY_GRF_PHY1_LN1_CON0,
+};
+
struct rockchip_p3phy_ops;
struct rockchip_p3phy_priv {
@@ -142,7 +154,7 @@ static int rockchip_p3phy_rk3588_init(struct rockchip_p3phy_priv *priv)
{
u32 reg = 0;
u8 mode = RK3588_LANE_AGGREGATION; /* default */
- int ret;
+ int ret, i;
regmap_write(priv->phy_grf, RK3588_PCIE3PHY_GRF_PHY0_LN0_CON1,
priv->rx_cmn_refclk_mode[0] ? RK3588_RX_CMN_REFCLK_MODE_EN :
@@ -161,7 +173,7 @@ static int rockchip_p3phy_rk3588_init(struct rockchip_p3phy_priv *priv)
regmap_write(priv->phy_grf, RK3588_PCIE3PHY_GRF_CMN_CON0, BIT(8) | BIT(24));
/* Set bifurcation if needed */
- for (int i = 0; i < priv->num_lanes; i++) {
+ for (i = 0; i < priv->num_lanes; i++) {
if (priv->lanes[i] > 1)
mode &= ~RK3588_LANE_AGGREGATION;
if (priv->lanes[i] == 3)
@@ -174,6 +186,18 @@ static int rockchip_p3phy_rk3588_init(struct rockchip_p3phy_priv *priv)
regmap_write(priv->phy_grf, RK3588_PCIE3PHY_GRF_CMN_CON0,
RK3588_PCIE30_PHY_MODE_EN | reg);
+ for (i = 0; i < priv->num_lanes && i < ARRAY_SIZE(rk3588_lane_con0); i++) {
+ u32 base = rk3588_lane_con0[i];
+
+ /* clkreq_n = 0 (asserted low for PIPE 4.3) */
+ regmap_write(priv->phy_grf, base,
+ FIELD_PREP_WM16(BIT(6), 0));
+
+ /* PowerDown = P0 (0x0, fully active) */
+ regmap_write(priv->phy_grf, base,
+ FIELD_PREP_WM16(GENMASK(11, 8), 0x0));
+ }
+
/* Set pcie1ln_sel in PHP_GRF_PCIESEL_CON */
if (!IS_ERR(priv->pipe_grf)) {
reg = mode & (RK3588_BIFURCATION_LANE_0_1 | RK3588_BIFURCATION_LANE_2_3);
base-commit: 7f87a5ea75f011d2c9bc8ac0167e5e2d1adb1594
--
2.50.1
^ permalink raw reply related
* [PATCH] arm: artpec: Remove unnecessary semicolons in artpec6_init_machine()
From: Nobuhiro Iwamatsu @ 2026-04-09 5:01 UTC (permalink / raw)
To: jesper.nilsson, lars.persson
Cc: linux-arm-kernel, linux-arm-kernel, linux-kernel,
Nobuhiro Iwamatsu
Remove unnecessary semicolons in artpec6_init_machine().
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.x90@mail.toshiba>
---
arch/arm/mach-artpec/board-artpec6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-artpec/board-artpec6.c b/arch/arm/mach-artpec/board-artpec6.c
index d3cf3e8603e81..c27e7bbcd7bc2 100644
--- a/arch/arm/mach-artpec/board-artpec6.c
+++ b/arch/arm/mach-artpec/board-artpec6.c
@@ -39,7 +39,7 @@ static void __init artpec6_init_machine(void)
*/
regmap_write(regmap, ARTPEC6_DMACFG_REGNUM,
ARTPEC6_DMACFG_UARTS_BURST);
- };
+ }
}
static void artpec6_l2c310_write_sec(unsigned long val, unsigned reg)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] arm64: dts: qcom: sm8750-mtp: Set sufficient voltage for panel nt37801
From: Ayushi Makhija @ 2026-04-09 5:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: konrad.dybcio, robh+dt, krzysztof.kozlowski+dt, conor+dt,
dmitry.baryshkov, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, quic_rajeevny, quic_vproddut
In-Reply-To: <acVWseivbxLQ_uDM@baldur>
On 3/26/2026 9:28 PM, Bjorn Andersson wrote:
> On Thu, Mar 26, 2026 at 03:06:52PM +0530, Ayushi Makhija wrote:
>> On 3/24/2026 7:34 AM, Bjorn Andersson wrote:
>>> On Mon, Mar 23, 2026 at 03:52:29PM +0530, Ayushi Makhija wrote:
>>>> The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
>>>> VDDI=1.65V~1.95V, so set sufficient voltage for panel nt37801.
>>>>
>>>
>>> Please add Fixes: tag.
>>>
>>
>> Hi Bjorn,
>>
>> Sure, will add in new patchset.
>>
>>>> Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com>
>>>
>>> Please start using your oss.qualcomm.com address.
>>>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
>>>> index 3837f6785320..6ba4e69bf377 100644
>>>> --- a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
>>>> +++ b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
>>>> @@ -462,7 +462,7 @@ vreg_l11b_1p0: ldo11 {
>>>>
>>>> vreg_l12b_1p8: ldo12 {
>>>> regulator-name = "vreg_l12b_1p8";
>>>> - regulator-min-microvolt = <1200000>;
>>>> + regulator-min-microvolt = <1650000>;
>>>
>>> Are you sure it's not supposed to be 1.8V, given the name of the rail?
>>>
>>> Regards,
>>> Bjorn
>>
>> There was already discussion regarding the minimum voltage for this regulator on sm8550 target
>> on other upstream patch.
>>
>> Link: https://lore.kernel.org/all/aQQdQoCLeKhYtY7W@yuanjiey.ap.qualcomm.com/
>>
>> This values is according to the NT37801 panel sec
>> "The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
>> VDDI=1.65V~1.95V."
>>
>
> Yes, so the panel requires 1.65V, so regulator-min-microvolt needs to be
> at least that. But regulator-min-microvolt should account for all the
> consumers of the rail, are there any others?
>
> Which leads me to my question, the people designing the board named the
> rail VREG_L12B_1P8 in the schematics, why didn't they name it
> VREG_L12B_1P65?
>
> Please check all the consumers and make the regulator-min-microvolt work
> for all of them - if that's 1.65V, then your change is good.
>
> Regards,
> Bjorn
Hi Bjorn,
There is only one consumer of VREG_L12B_1P8 rail, i.e. NT37801 panel.
So regulator-min-microvolt as 1.65V should be fine for VREG_L12B_1P8 rail.
Thanks,
Ayushi
^ permalink raw reply
* Re: [PATCH v2] nvme-apple: drop invalid put of admin queue reference count
From: Christoph Hellwig @ 2026-04-09 6:09 UTC (permalink / raw)
To: Fedor Pchelkin
Cc: Keith Busch, Christoph Hellwig, Jens Axboe, Sven Peter,
Janne Grunau, Neal Gompa, Sagi Grimberg, Hannes Reinecke,
Ming Lei, Chaitanya Kulkarni, Heyne, Maximilian, asahi,
linux-arm-kernel, linux-nvme, linux-kernel, lvc-project, stable
In-Reply-To: <20260408141815.375695-1-pchelkin@ispras.ru>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v2 0/5] Migrate soc, drm-mediatek, mdp3 to new CMDQ APIs (series 2/4)
From: Jason-JH Lin (林睿祥) @ 2026-04-09 6:10 UTC (permalink / raw)
To: jassisinghbrar@gmail.com, mchehab@kernel.org,
chunkuang.hu@kernel.org, AngeloGioacchino Del Regno,
nicolas@ndufresne.ca
Cc: matthias.bgg@gmail.com, Singo Chang (張興國),
linux-media@vger.kernel.org, Project_Global_Chrome_Upstream_Group,
dri-devel@lists.freedesktop.org,
Nancy Lin (林欣螢),
linux-kernel@vger.kernel.org,
Paul-pl Chen (陳柏霖),
Sirius Wang (王皓昱), wenst@chromium.org,
Xiandong Wang (王先冬),
linux-mediatek@lists.infradead.org,
Moudy Ho (何宗原),
linux-arm-kernel@lists.infradead.org
In-Reply-To: <cd1de04076917d65ccd7dd91d9392af7977a4906.camel@ndufresne.ca>
Hi Nicolas,
> > media: platform: mtk-mdp3: Refactor CMDQ writes for CMDQ API
> > change
Since this patch is already applied:
soc: mediatek: mtk-cmdq: Extend cmdq_pkt_write API for SoCs without
subsys ID
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=40dc5bbad63b5f60dd2e69a32def1a2673cba09e
You can apply this mdp3 patch to media tree now.
---
> > media: platform: mtk-mdp3: Change cmdq_pkt_jump_rel() to
> > cmdq_pkt_jump_rel_temp()
This mdp3 patch need to be applied with this soc patch in this series:
[v2,2/5] soc: mediatek: mtk-cmdq: Add cmdq_pkt_jump_rel_temp() for
removing shift_pa
You need to wait for the soc: patched landed.
Thanks
Jason-JH Lin
> Can the two last be applied to the media tree alone without breaking
> anything ?
> Otherwise I will need to wait for the soc: patches to have landed.
>
> Nicolas
>
^ permalink raw reply
* Re: [PATCH v14 00/10] arm64: entry: Convert to Generic Entry
From: Jinjie Ruan @ 2026-04-09 6:29 UTC (permalink / raw)
To: catalin.marinas, will, oleg, tglx, peterz, luto, kees, wad,
linusw, kevin.brodsky, yeoreum.yun, ldv, song, thuth,
ryan.roberts, mark.rutland, ada.coupriediaz, anshuman.khandual,
broonie, liqiang01, pengcan, mathieu.desnoyers, mingo, edumazet,
arnd, linux-arm-kernel, linux-kernel
In-Reply-To: <20260320102620.1336796-1-ruanjinjie@huawei.com>
On 2026/3/20 18:26, Jinjie Ruan wrote:
> Currently, x86, Riscv, Loongarch use the Generic Entry which makes
> maintainers' work easier and codes more elegant. arm64 has already
> successfully switched to the Generic IRQ Entry in commit
> b3cf07851b6c ("arm64: entry: Switch to generic IRQ entry"), it is
> time to completely convert arm64 to Generic Entry.
>
> The goal is to bring arm64 in line with other architectures that already
> use the generic entry infrastructure, reducing duplicated code and
> making it easier to share future changes in entry/exit paths, such as
> "Syscall User Dispatch" and RSEQ optimizations.
Hi,
Just a quick ping to see if this series is good to go. Do I need to
provide a new version rebased on the latest arm64 for-next/generic-entry
branches, or is the current version acceptable?
>
> This patch set is rebased on arm64 for-next/core. This series contains
> foundational updates for arm64. As suggested by Linus Walleij, these 10
> patches are being submitted separately for inclusion in the arm64 tree.
>
> And the performance benchmarks results on qemu-kvm are below:
>
> perf bench syscall usec/op (-ve is improvement)
>
> | Syscall | Base | Generic Entry | change % |
> | ------- | ----------- | ------------- | -------- |
> | basic | 0.123997 | 0.120872 | -2.57 |
> | execve | 512.1173 | 504.9966 | -1.52 |
> | fork | 114.1144 | 113.2301 | -1.06 |
> | getpgid | 0.120182 | 0.121245 | +0.9 |
>
> perf bench syscall ops/sec (+ve is improvement)
>
> | Syscall | Base | Generic Entry| change % |
> | ------- | -------- | ------------ | -------- |
> | basic | 8064712 | 8273212 | +2.48 |
> | execve | 1952 | 1980 | +1.52 |
> | fork | 8763 | 8832 | +1.06 |
> | getpgid | 8320704 | 8247810 | -0.9 |
>
> Therefore, the syscall performance variation ranges from a 1% regression
> to a 2.5% improvement.
>
> It was tested ok with following test cases on QEMU virt platform:
> - Stress-ng CPU stress test.
> - Hackbench stress test.
> - "sud" selftest testcase.
> - get_set_sud, get_syscall_info, set_syscall_info, peeksiginfo
> in tools/testing/selftests/ptrace.
> - breakpoint_test_arm64 in selftests/breakpoints.
> - syscall-abi and ptrace in tools/testing/selftests/arm64/abi
> - fp-ptrace, sve-ptrace, za-ptrace in selftests/arm64/fp.
> - vdso_test_getrandom in tools/testing/selftests/vDSO
> - Strace tests.
> - slice_test for rseq optimizations.
>
> The test QEMU configuration is as follows:
>
> qemu-system-aarch64 \
> -M virt \
> -enable-kvm \
> -cpu host \
> -kernel Image \
> -smp 8 \
> -m 512m \
> -nographic \
> -no-reboot \
> -device virtio-rng-pci \
> -append "root=/dev/vda rw console=ttyAMA0 kgdboc=ttyAMA0,115200 \
> earlycon preempt=voluntary irqchip.gicv3_pseudo_nmi=1 audit=1" \
> -drive if=none,file=images/rootfs.ext4,format=raw,id=hd0 \
> -device virtio-blk-device,drive=hd0 \
>
> Changes in v14:
> - Initialize ret = 0 in syscall_trace_enter().
> - Split into two patch sets as Linus Walleij suggested, so this patch set
> can be applied separately to the arm64 tree.
> - Rebased on arm64 for-next/core branch.
> - Collect Reviewed-by and Acked-by.
> - Link to v13 resend: https://lore.kernel.org/all/20260317082020.737779-15-ruanjinjie@huawei.com/
>
> Changes in v13 resend:
> - Fix exit_to_user_mode_prepare_legacy() issues.
> - Also move TIF_SINGLESTEP to generic TIF infrastructure for loongarch.
> - Use generic TIF bits for arm64 and moving TIF_SINGLESTEP to
> generic TIF for related architectures separately.
> - Refactor syscall_trace_enter/exit() to accept flags and Use
> syscall_get_nr() helper separately.
> - Tested with slice_test for rseq optimizations.
> - Add acked-by.
> - Link to v13: https://lore.kernel.org/all/20260313094738.3985794-1-ruanjinjie@huawei.com/
>
> Changes in v13:
> - Rebased on v7.0-rc3, so drop the firt applied arm64 patch.
> - Use generic TIF bits to enables RSEQ optimization.
> - Update most of the commit message to make it more clear.
> - Link to v12: https://lore.kernel.org/all/20260203133728.848283-1-ruanjinjie@huawei.com/
>
> Changes in v12:
> - Rebased on "sched/core", so remove the four generic entry patches.
> - Move "Expand secure_computing() in place" and
> "Use syscall_get_arguments() helper" patch forward, which will group all
> non-functional cleanups at the front.
> - Adjust the explanation for moving rseq_syscall() before
> audit_syscall_exit().
> - Link to v11: https://lore.kernel.org/all/20260128031934.3906955-1-ruanjinjie@huawei.com/
>
> Changes in v11:
> - Remove unused syscall in syscall_trace_enter().
> - Update and provide a detailed explanation of the differences after
> moving rseq_syscall() before audit_syscall_exit().
> - Rebased on arm64 (for-next/entry), and remove the first applied 3 patchs.
> - syscall_exit_to_user_mode_work() for arch reuse instead of adding
> new syscall_exit_to_user_mode_work_prepare() helper.
> - Link to v10: https://lore.kernel.org/all/20251222114737.1334364-1-ruanjinjie@huawei.com/
>
> Changes in v10:
> - Rebased on v6.19-rc1, rename syscall_exit_to_user_mode_prepare() to
> syscall_exit_to_user_mode_work_prepare() to avoid conflict.
> - Also inline syscall_trace_enter().
> - Support aarch64 for sud_benchmark.
> - Update and correct the commit message.
> - Add Reviewed-by.
> - Link to v9: https://lore.kernel.org/all/20251204082123.2792067-1-ruanjinjie@huawei.com/
>
> Changes in v9:
> - Move "Return early for ptrace_report_syscall_entry() error" patch ahead
> to make it not introduce a regression.
> - Not check _TIF_SECCOMP/SYSCALL_EMU for syscall_exit_work() in
> a separate patch.
> - Do not report_syscall_exit() for PTRACE_SYSEMU_SINGLESTEP in a separate
> patch.
> - Add two performance patch to improve the arm64 performance.
> - Add Reviewed-by.
> - Link to v8: https://lore.kernel.org/all/20251126071446.3234218-1-ruanjinjie@huawei.com/
>
> Changes in v8:
> - Rename "report_syscall_enter()" to "report_syscall_entry()".
> - Add ptrace_save_reg() to avoid duplication.
> - Remove unused _TIF_WORK_MASK in a standalone patch.
> - Align syscall_trace_enter() return value with the generic version.
> - Use "scno" instead of regs->syscallno in el0_svc_common().
> - Move rseq_syscall() ahead in a standalone patch to clarify it clearly.
> - Rename "syscall_trace_exit()" to "syscall_exit_work()".
> - Keep the goto in el0_svc_common().
> - No argument was passed to __secure_computing() and check -1 not -1L.
> - Remove "Add has_syscall_work() helper" patch.
> - Move "Add syscall_exit_to_user_mode_prepare() helper" patch later.
> - Add miss header for asm/entry-common.h.
> - Update the implementation of arch_syscall_is_vdso_sigreturn().
> - Add "ARCH_SYSCALL_WORK_EXIT" to be defined as "SECCOMP | SYSCALL_EMU"
> to keep the behaviour unchanged.
> - Add more testcases test.
> - Add Reviewed-by.
> - Update the commit message.
> - Link to v7: https://lore.kernel.org/all/20251117133048.53182-1-ruanjinjie@huawei.com/
>
> Jinjie Ruan (10):
> arm64/ptrace: Refactor syscall_trace_enter/exit() to accept flags
> parameter
> arm64/ptrace: Use syscall_get_nr() helper for syscall_trace_enter()
> arm64/ptrace: Expand secure_computing() in place
> arm64/ptrace: Use syscall_get_arguments() helper for audit
> arm64: ptrace: Move rseq_syscall() before audit_syscall_exit()
> arm64: syscall: Introduce syscall_exit_to_user_mode_work()
> arm64/ptrace: Define and use _TIF_SYSCALL_EXIT_WORK
> arm64/ptrace: Skip syscall exit reporting for PTRACE_SYSEMU_SINGLESTEP
> arm64: entry: Convert to generic entry
> arm64: Inline el0_svc_common()
>
> arch/arm64/Kconfig | 2 +-
> arch/arm64/include/asm/entry-common.h | 76 +++++++++++++++++
> arch/arm64/include/asm/syscall.h | 19 ++++-
> arch/arm64/include/asm/thread_info.h | 16 +---
> arch/arm64/kernel/debug-monitors.c | 7 ++
> arch/arm64/kernel/entry-common.c | 25 ++++--
> arch/arm64/kernel/ptrace.c | 115 --------------------------
> arch/arm64/kernel/signal.c | 2 +-
> arch/arm64/kernel/syscall.c | 29 ++-----
> include/linux/irq-entry-common.h | 8 --
> include/linux/rseq_entry.h | 18 ----
> 11 files changed, 130 insertions(+), 187 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v5 23/27] clk: mediatek: Add MT8196 disp-ao clock support
From: Jason-JH Lin (林睿祥) @ 2026-04-09 6:30 UTC (permalink / raw)
To: aford173@gmail.com
Cc: Guangjie Song (宋光杰), robh@kernel.org,
kernel@collabora.com, Sirius Wang (王皓昱),
Nancy Lin (林欣螢), AngeloGioacchino Del Regno,
linux-mediatek@lists.infradead.org, conor+dt@kernel.org,
mturquette@baylibre.com, richardcochran@gmail.com,
Project_Global_Chrome_Upstream_Group, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, krzk+dt@kernel.org, Laura Nao,
Nicolas Prado, p.zabel@pengutronix.de,
Singo Chang (張興國),
Paul-pl Chen (陳柏霖), wenst@chromium.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
linux-clk@vger.kernel.org, matthias.bgg@gmail.com,
sboyd@kernel.org
In-Reply-To: <CAHCN7x+K25H-QWLDA6SoGSzxv9koO0wFOrjfWNePc+0AfjCVZg@mail.gmail.com>
>
[snip]
> > > > > +static const struct of_device_id
> > > > > of_match_clk_mt8196_vdisp_ao[]
> > > > > = {
> > > > > + { .compatible = "mediatek,mt8196-vdisp-ao", .data =
> > > > > &mm_v_mcd },
> > > >
> > > > Hi Laura,
> > > >
> > > > We are going to send mtk-mmsys driver for MT8196 recently, but
> > > > we
> > > > found
> > > > the compatible name is used here.
> > > >
> > > > As your commit message, vdisp-ao is integrated with the mtk-
> > > > mmsys
> > > > driver, which registers the vdisp-ao clock driver via
> > > > platform_device_register_data().
> > > >
> > > > Shouldn't this compatible name belong to mmsys driver for
> > > > MT8196?
> > > >
> > >
> > > That's right, my fault for missing that! Thanks for the heads up.
> > >
> > > I'm aware Angelo is currently restructuring mediatek-drm
> > > (including
> > > mmsys and mutex), and that might affect the way vdisp-ao is
> > > loaded
> > > too.
> > > So I'm not sure whether it makes sense to send a patch to fix
> > > this
> > > right away.
> >
> > OK, we'll try to contact Angelo from other places.
> > Thanks for your confirmation!
> >
>
>
> If anyone wants me to test anything, I have a Chromebook with the
> mt8196 that I can test code, so feel free to CC me on anything that
> you want tested. I'd love to see this stuff pushed upstream.
>
> thanks
>
> adam
Hi Adam,
However, we still need some more time to discuss and refactor this.
We'll send the new patch if necessary.
Thank you for your help!
Regards,
Jason-JH Lin
> >
> > Regards,
> > Jason-JH.Lin
> >
> > >
> > > Best,
> > >
> > > Laura
> > >
> >
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX91
From: Peng Fan @ 2026-04-09 6:33 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Shawn Guo, Dario Binacchi, Markus Niebel, Maud Spierings,
Alexander Stein, Ernest Van Hoecke, Josua Mayer,
Francesco Dolcini, Primoz Fiser
In-Reply-To: <1ed7e2100e3feb74c9f0006d5b88e1bba1ad4339.1775669847.git.stefano.r@variscite.com>
On Wed, Apr 08, 2026 at 07:39:45PM +0200, Stefano Radaelli wrote:
>From: Stefano Radaelli <stefano.r@variscite.com>
>
>Add device tree support for the Variscite VAR-SOM-MX91 system on module.
>This SOM is designed to be used with various carrier boards.
>
>The module includes:
>- NXP i.MX91 MPU processor
>- Up to 2GB of LPDDR4 memory
>- Up to 128GB of eMMC storage memory
>- Integrated 10/100/1000 Mbps Ethernet Transceiver
>- Codec audio WM8904
>- WIFI6 dual-band 802.11ax/ac/a/b/g/n with optional 802.15.4 and Bluetooth
>
>Only SOM-specific peripherals are enabled by default. Carrier board
>specific interfaces are left disabled to be enabled in the respective
>carrier board device trees.
>
>Link: https://variscite.com/system-on-module-som/i-mx-9/i-mx-91/var-som-mx91/
>Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* Re: [PATCH] clk: clk-imx8mm: Initialize clocks in arch_initcall
From: Peng Fan @ 2026-04-09 6:51 UTC (permalink / raw)
To: Paul Geurts
Cc: abelvesa, peng.fan, mturquette, sboyd, Frank.Li, s.hauer, kernel,
festevam, shawnguo, linux-clk, imx, linux-arm-kernel,
linux-kernel, martijn.de.gouw
In-Reply-To: <20260408101313.2082125-1-paul.geurts@prodrive-technologies.com>
On Wed, Apr 08, 2026 at 12:13:13PM +0200, Paul Geurts wrote:
>The i.MX8MM clock driver is implemented as module_platform_driver();,
>which makes it initialize in device_initcall(). This means that all
>drivers referencing the clock driver nodes in the device tree are
>deferred by fw_devlink, which are most of the i.MX8M platform drivers.
>
>Explicitly initialize the clock driver in arch_initcall(), to make sure
>the clock driver is ready when the rest of the drivers are probed.
Let's keep as it is, changing to arch_initcall() is not allowed.
Thanks,
Peng
^ permalink raw reply
* [PATCH v13 03/17] drm/exynos: exynos_dp: Remove &exynos_dp_device.ptn_bridge
From: Damon Ding @ 2026-04-09 6:52 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, victor.liu, Frank.Li, shawnguo,
s.hauer, inki.dae, sw0312.kim, kyungmin.park, krzk, jingoohan1,
p.zabel, hjc, heiko, andy.yan
Cc: Laurent.pinchart, jonas, jernej.skrabec, kernel, festevam,
alim.akhtar, dmitry.baryshkov, luca.ceresoli, nicolas.frattaroli,
dianders, m.szyprowski, linux-kernel, dri-devel, imx,
linux-arm-kernel, linux-samsung-soc, linux-rockchip, Damon Ding
In-Reply-To: <20260409065301.446670-1-damon.ding@rock-chips.com>
Use &analogix_dp_plat_data.bridge instead of &exynos_dp_device.ptn_bridge
directly.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588
---
Changes in v3:
- Fix the typographical error for &dp->plat_data.bridge.
Changes in v4:
- Rename the &analogix_dp_plat_data.bridge to
&analogix_dp_plat_data.next_bridge.
Changes in v9:
- Add Reviewed-by and Tested-by tags.
Changes in v13:
- Modify '(on rk3588)' to '# rk3588' for Tested-by tag.
---
drivers/gpu/drm/exynos/exynos_dp.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c
index 5bcf41e0bd04..f469ac5b3c2a 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -36,7 +36,6 @@
struct exynos_dp_device {
struct drm_encoder encoder;
struct drm_connector *connector;
- struct drm_bridge *ptn_bridge;
struct drm_device *drm_dev;
struct device *dev;
@@ -106,8 +105,8 @@ static int exynos_dp_bridge_attach(struct analogix_dp_plat_data *plat_data,
dp->connector = connector;
/* Pre-empt DP connector creation if there's a bridge */
- if (dp->ptn_bridge) {
- ret = drm_bridge_attach(&dp->encoder, dp->ptn_bridge, bridge,
+ if (plat_data->next_bridge) {
+ ret = drm_bridge_attach(&dp->encoder, plat_data->next_bridge, bridge,
0);
if (ret)
return ret;
@@ -155,7 +154,7 @@ static int exynos_dp_bind(struct device *dev, struct device *master, void *data)
dp->drm_dev = drm_dev;
- if (!dp->plat_data.panel && !dp->ptn_bridge) {
+ if (!dp->plat_data.panel && !dp->plat_data.next_bridge) {
ret = exynos_dp_dt_parse_panel(dp);
if (ret)
return ret;
@@ -232,6 +231,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
/* The remote port can be either a panel or a bridge */
dp->plat_data.panel = panel;
+ dp->plat_data.next_bridge = bridge;
dp->plat_data.dev_type = EXYNOS_DP;
dp->plat_data.power_on = exynos_dp_poweron;
dp->plat_data.power_off = exynos_dp_poweroff;
@@ -239,8 +239,6 @@ static int exynos_dp_probe(struct platform_device *pdev)
dp->plat_data.get_modes = exynos_dp_get_modes;
dp->plat_data.skip_connector = !!bridge;
- dp->ptn_bridge = bridge;
-
out:
dp->adp = analogix_dp_probe(dev, &dp->plat_data);
if (IS_ERR(dp->adp))
--
2.34.1
^ permalink raw reply related
* [PATCH v13 05/17] drm/exynos: exynos_dp: Apply of-display-mode-bridge to parse the display-timings node
From: Damon Ding @ 2026-04-09 6:52 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, victor.liu, Frank.Li, shawnguo,
s.hauer, inki.dae, sw0312.kim, kyungmin.park, krzk, jingoohan1,
p.zabel, hjc, heiko, andy.yan
Cc: Laurent.pinchart, jonas, jernej.skrabec, kernel, festevam,
alim.akhtar, dmitry.baryshkov, luca.ceresoli, nicolas.frattaroli,
dianders, m.szyprowski, linux-kernel, dri-devel, imx,
linux-arm-kernel, linux-samsung-soc, linux-rockchip, Damon Ding
In-Reply-To: <20260409065301.446670-1-damon.ding@rock-chips.com>
If there is neither a panel nor a bridge, the display timing can be
parsed from the display-timings node under the dp node.
In order to get rid of &analogix_dp_plat_data.get_modes() and make
the codes more consistent, apply DRM of-display-mode-bridge to parse
display timings.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588
---
Changes in v6:
- Apply DRM legacy bridge to parse display timings instead of
implementing the same codes only for Exynos DP.
Changes in v7:
- Use temporary flag &exynos_dp_device.has_of_bridge, which will be
removed in the following patch, instead of applying API
drm_bridge_is_legacy().
- Remove exynos_dp_legacy_bridge_init() and inline API
devm_drm_of_display_mode_bridge().
Changes in v9:
- Add Tested-by tag.
Changes in v10:
- Add Reviewed-by tag.
Changes in v13:
- Modify '(on rk3588)' to '# rk3588' for Tested-by tag.
---
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_dp.c | 66 ++++++++----------------------
2 files changed, 17 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 0d13828e7d9e..380d9a8ce259 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -72,6 +72,7 @@ config DRM_EXYNOS_DP
select DRM_ANALOGIX_DP
select DRM_DISPLAY_DP_HELPER
default DRM_EXYNOS
+ select DRM_OF_DISPLAY_MODE_BRIDGE
select DRM_PANEL
help
This enables support for DP device.
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c
index e20513164032..ac16138a22fe 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -19,6 +19,7 @@
#include <video/videomode.h>
#include <drm/bridge/analogix_dp.h>
+#include <drm/bridge/of-display-mode-bridge.h>
#include <drm/drm_atomic_helper.h>
#include <drm/drm_bridge.h>
#include <drm/drm_crtc.h>
@@ -38,9 +39,10 @@ struct exynos_dp_device {
struct drm_device *drm_dev;
struct device *dev;
- struct videomode vm;
struct analogix_dp_device *adp;
struct analogix_dp_plat_data plat_data;
+
+ bool has_of_bridge;
};
static int exynos_dp_crtc_clock_enable(struct analogix_dp_plat_data *plat_data,
@@ -67,44 +69,20 @@ static int exynos_dp_poweroff(struct analogix_dp_plat_data *plat_data)
return exynos_dp_crtc_clock_enable(plat_data, false);
}
-static int exynos_dp_get_modes(struct analogix_dp_plat_data *plat_data,
- struct drm_connector *connector)
-{
- struct exynos_dp_device *dp = to_dp(plat_data);
- struct drm_display_mode *mode;
-
- if (dp->plat_data.panel)
- return 0;
-
- mode = drm_mode_create(connector->dev);
- if (!mode) {
- DRM_DEV_ERROR(dp->dev,
- "failed to create a new display mode.\n");
- return 0;
- }
-
- drm_display_mode_from_videomode(&dp->vm, mode);
- connector->display_info.width_mm = mode->width_mm;
- connector->display_info.height_mm = mode->height_mm;
-
- mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
- drm_mode_set_name(mode);
- drm_mode_probed_add(connector, mode);
-
- return 1;
-}
-
static int exynos_dp_bridge_attach(struct analogix_dp_plat_data *plat_data,
struct drm_bridge *bridge,
struct drm_connector *connector)
{
struct exynos_dp_device *dp = to_dp(plat_data);
+ enum drm_bridge_attach_flags flags = 0;
int ret;
/* Pre-empt DP connector creation if there's a bridge */
if (plat_data->next_bridge) {
- ret = drm_bridge_attach(&dp->encoder, plat_data->next_bridge, bridge,
- 0);
+ if (dp->has_of_bridge)
+ flags = DRM_BRIDGE_ATTACH_NO_CONNECTOR;
+
+ ret = drm_bridge_attach(&dp->encoder, plat_data->next_bridge, bridge, flags);
if (ret)
return ret;
}
@@ -129,19 +107,6 @@ static const struct drm_encoder_helper_funcs exynos_dp_encoder_helper_funcs = {
.disable = exynos_dp_nop,
};
-static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
-{
- int ret;
-
- ret = of_get_videomode(dp->dev->of_node, &dp->vm, OF_USE_NATIVE_MODE);
- if (ret) {
- DRM_DEV_ERROR(dp->dev,
- "failed: of_get_videomode() : %d\n", ret);
- return ret;
- }
- return 0;
-}
-
static int exynos_dp_bind(struct device *dev, struct device *master, void *data)
{
struct exynos_dp_device *dp = dev_get_drvdata(dev);
@@ -151,12 +116,6 @@ static int exynos_dp_bind(struct device *dev, struct device *master, void *data)
dp->drm_dev = drm_dev;
- if (!dp->plat_data.panel && !dp->plat_data.next_bridge) {
- ret = exynos_dp_dt_parse_panel(dp);
- if (ret)
- return ret;
- }
-
drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_TMDS);
drm_encoder_helper_add(encoder, &exynos_dp_encoder_helper_funcs);
@@ -223,6 +182,14 @@ static int exynos_dp_probe(struct platform_device *pdev)
}
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0, &panel, &bridge);
+ if (ret == -ENODEV) {
+ dp->plat_data.next_bridge = devm_drm_of_display_mode_bridge(dp->dev,
+ dp->dev->of_node,
+ DRM_MODE_CONNECTOR_eDP);
+ ret = IS_ERR(dp->plat_data.next_bridge) ? PTR_ERR(dp->plat_data.next_bridge) : 0;
+ if (!ret)
+ dp->has_of_bridge = true;
+ }
if (ret)
return ret;
@@ -233,7 +200,6 @@ static int exynos_dp_probe(struct platform_device *pdev)
dp->plat_data.power_on = exynos_dp_poweron;
dp->plat_data.power_off = exynos_dp_poweroff;
dp->plat_data.attach = exynos_dp_bridge_attach;
- dp->plat_data.get_modes = exynos_dp_get_modes;
dp->plat_data.skip_connector = !!bridge;
out:
--
2.34.1
^ permalink raw reply related
* [PATCH v13 04/17] drm/exynos: exynos_dp: Remove unused &exynos_dp_device.connector
From: Damon Ding @ 2026-04-09 6:52 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, victor.liu, Frank.Li, shawnguo,
s.hauer, inki.dae, sw0312.kim, kyungmin.park, krzk, jingoohan1,
p.zabel, hjc, heiko, andy.yan
Cc: Laurent.pinchart, jonas, jernej.skrabec, kernel, festevam,
alim.akhtar, dmitry.baryshkov, luca.ceresoli, nicolas.frattaroli,
dianders, m.szyprowski, linux-kernel, dri-devel, imx,
linux-arm-kernel, linux-samsung-soc, linux-rockchip, Damon Ding
In-Reply-To: <20260409065301.446670-1-damon.ding@rock-chips.com>
The &exynos_dp_device.connector is assigned in exynos_dp_bridge_attach()
but never used. It should make sense to remove it.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588
---
Changes in v5:
- Fix the 'drm/bridge' to 'drm/exynos' in commit message.
Changes in v9:
- Add Reviewed-by and Tested-by tags.
Changes in v13:
- Modify '(on rk3588)' to '# rk3588' for Tested-by tag.
---
drivers/gpu/drm/exynos/exynos_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c
index f469ac5b3c2a..e20513164032 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -35,7 +35,6 @@
struct exynos_dp_device {
struct drm_encoder encoder;
- struct drm_connector *connector;
struct drm_device *drm_dev;
struct device *dev;
@@ -102,8 +101,6 @@ static int exynos_dp_bridge_attach(struct analogix_dp_plat_data *plat_data,
struct exynos_dp_device *dp = to_dp(plat_data);
int ret;
- dp->connector = connector;
-
/* Pre-empt DP connector creation if there's a bridge */
if (plat_data->next_bridge) {
ret = drm_bridge_attach(&dp->encoder, plat_data->next_bridge, bridge,
--
2.34.1
^ permalink raw reply related
* [PATCH v13 01/17] drm/bridge: analogix_dp: Add &analogix_dp_plat_data.next_bridge
From: Damon Ding @ 2026-04-09 6:52 UTC (permalink / raw)
To: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, victor.liu, Frank.Li, shawnguo,
s.hauer, inki.dae, sw0312.kim, kyungmin.park, krzk, jingoohan1,
p.zabel, hjc, heiko, andy.yan
Cc: Laurent.pinchart, jonas, jernej.skrabec, kernel, festevam,
alim.akhtar, dmitry.baryshkov, luca.ceresoli, nicolas.frattaroli,
dianders, m.szyprowski, linux-kernel, dri-devel, imx,
linux-arm-kernel, linux-samsung-soc, linux-rockchip, Damon Ding
In-Reply-To: <20260409065301.446670-1-damon.ding@rock-chips.com>
In order to move the panel/bridge parsing and attachmenet to the
Analogix side, add component struct drm_bridge *next_bridge to
platform data struct analogix_dp_plat_data.
The movement makes sense because the panel/bridge should logically
be positioned behind the Analogix bridge in the display pipeline.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588
---
Changes in v4:
- Rename the &analogix_dp_plat_data.bridge to
&analogix_dp_plat_data.next_bridge
Changes in v9:
- Add Reviewed-by and Tested-by tags.
Changes in v13:
- Modify '(on rk3588)' to '# rk3588' for Tested-by tag.
---
include/drm/bridge/analogix_dp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index cf17646c1310..582357c20640 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -27,6 +27,7 @@ static inline bool is_rockchip(enum analogix_dp_devtype type)
struct analogix_dp_plat_data {
enum analogix_dp_devtype dev_type;
struct drm_panel *panel;
+ struct drm_bridge *next_bridge;
struct drm_encoder *encoder;
struct drm_connector *connector;
bool skip_connector;
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox