* RE: [PATCH 3/3] perf/arm_cspmu: nvidia: fix BDF calculation examples in PCIE PMU docs
From: Besar Wicaksono @ 2026-05-11 21:48 UTC (permalink / raw)
To: Saurav Sachidanand, Will Deacon
Cc: Mark Rutland, Ilkka Koskinen, Jon Hunter,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
aghayev@amazon.com, juew@amazon.com
In-Reply-To: <20260511210905.91917-2-sauravsc@amazon.com>
> -----Original Message-----
> From: Saurav Sachidanand <sauravsc@amazon.com>
> Sent: Monday, May 11, 2026 4:09 PM
> To: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>; Besar Wicaksono
> <bwicaksono@nvidia.com>; Ilkka Koskinen
> <ilkka@os.amperecomputing.com>; Jon Hunter <jonathanh@nvidia.com>;
> linux-arm-kernel@lists.infradead.org; linux-perf-users@vger.kernel.org; linux-
> kernel@vger.kernel.org; aghayev@amazon.com; juew@amazon.com; Saurav
> Sachidanand <sauravsc@amazon.com>
> Subject: [PATCH 3/3] perf/arm_cspmu: nvidia: fix BDF calculation examples in
> PCIE PMU docs
>
> External email: Use caution opening links or attachments
>
>
> The BDF hex values in the documentation examples are inconsistent with
> the stated formula (bus << 8) + (device << 3) + (function):
>
> - BDF 27:01.1: documented as 0x2781, correct value is 0x2709
> (0x27 << 8) + (0x01 << 3) + 0x1 = 0x2709
> - BDF 01:01.0: documented as 0x0180, correct value is 0x0108
> (0x01 << 8) + (0x01 << 3) + 0x0 = 0x0108
>
> It appears (device << 7) was used instead of (device << 3) when
> computing the example values.
>
> Fixes: bf585ba14726 ("perf/arm_cspmu: nvidia: Add Tegra410 PCIE PMU")
> Signed-off-by: Saurav Sachidanand <sauravsc@amazon.com>
Thanks for the fix.
Reviewed-by: Besar Wicaksono <bwicaksono@nvidia.com>
> ---
> Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
> b/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
> index 0656223b61d47..24f0e801d7b80 100644
> --- a/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
> +++ b/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
> @@ -170,7 +170,7 @@ The list of event filters:
> devices in root port 0 to 3.
> * src_bdf: the BDF that will be monitored. This is a 16-bit value that
> follows formula: (bus << 8) + (device << 3) + (function). For example, the
> - value of BDF 27:01.1 is 0x2781.
> + value of BDF 27:01.1 is 0x2709.
> * src_bdf_en: enable the BDF filter. If this is set, the BDF filter value in
> "src_bdf" is used to filter the traffic.
>
> @@ -215,7 +215,7 @@ Example usage:
> * Count event id 0x4 from BDF 01:01.0 of PCIE RC-4 on socket 0 targeting all
> destinations::
>
> - perf stat -a -e
> nvidia_pcie_pmu_0_rc_4/event=0x4,src_bdf=0x0180,src_bdf_en=0x1/
> + perf stat -a -e
> nvidia_pcie_pmu_0_rc_4/event=0x4,src_bdf=0x0108,src_bdf_en=0x1/
>
> .. _NVIDIA_T410_PCIE_PMU_RC_Mapping_Section:
>
> --
> 2.47.3
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Shah, Tanmay @ 2026-05-11 21:35 UTC (permalink / raw)
To: Mathieu Poirier, tanmay.shah
Cc: Arnaud POULIQUEN, Beleswar Prasad Padhi, Shenwei Wang,
Andrew Lunn, Linus Walleij, Bartosz Golaszewski, Jonathan Corbet,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Frank Li, Sascha Hauer, Shuah Khan, linux-gpio@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan,
devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
dl-linux-imx, Bartosz Golaszewski
In-Reply-To: <CANLsYkz8HpM_8eS7DjN_jmYs4T7P9xY0jYmdiAx5WO=_1zvFpQ@mail.gmail.com>
On 5/11/2026 12:58 PM, Mathieu Poirier wrote:
> On Mon, 11 May 2026 at 10:47, Shah, Tanmay <tanmays@amd.com> wrote:
>>
>>
>>
>> On 5/5/2026 10:52 AM, Shah, Tanmay wrote:
>>>
>>>
>>> On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
>>>> Hi Tanmay,
>>>>
>>>> On 5/4/26 21:19, Shah, Tanmay wrote:
>>>>>
>>>>> Hello all,
>>>>>
>>>>> I have started reviewing this work as well.
>>>>> Thanks Shenwei for this work.
>>>>>
>>>>> I have gone through only the current revision, and would like to provide
>>>>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
>>>>> Also, have some bindings related question.
>>>>>
>>>>> Please see below:
>>>>>
>>>>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>>>>>
>>>>>>
>>>>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>>>>>> Hello Arnaud,
>>>>>>>
>>>>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Mathieu,
>>>>>>>>>>
>>>>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
>>>>>>>>>>>>> padhi@ti.com>; Linus
>>>>>>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
>>>>>>>>>>>>> <brgl@kernel.org>; Jonathan
>>>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
>>>>>>>>>>>>> Andersson
>>>>>>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-
>>>>>>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
>>>>>>>>>>>>> kernel@vger.kernel.org;
>>>>>>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
>>>>>>>>>>>>> linux-imx <linux-
>>>>>>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>>>> rpmsg GPIO driver
>>>>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
>>>>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>>>>>>> Krzysztof
>>>>>>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>>>>>>>>>>>>>>> <conor+dt@kernel.org>;
>>>>>>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>;
>>>>>>>>>>>>>>> Sascha
>>>>>>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>>>>>> rpmsg
>>>>>>>>>>>>>>> GPIO driver
>>>>>>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>>>>>> __u8 status;
>>>>>>>>>>>>>>>>> __u8 value;
>>>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>>> It is the same message format. Please see the message
>>>>>>>>>>>>>>>> definition
>>>>>>>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>>>>>> + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>>>>>>>> + | 1 | 2 |port |line | err | dir|
>>>>>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
>>>>>>>>>>>>>>> message format.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
>>>>>>>>>>>>>> requests and
>>>>>>>>>>>>> replies, and a second one for events.
>>>>>>>>>>>>>> In contrast, rpmsg provides only a single communication
>>>>>>>>>>>>>> channel, so a
>>>>>>>>>>>>>> type field is required to distinguish between different kinds
>>>>>>>>>>>>>> of messages.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Since rpmsg replies and events share the same message format,
>>>>>>>>>>>>>> an additional
>>>>>>>>>>>>> line is introduced to handle both cases.
>>>>>>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
>>>>>>>>>>>>>> field is added to
>>>>>>>>>>>>> uniquely identify the target controller.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have commented on this before - RPMSG is already providing
>>>>>>>>>>>>> multiplexing
>>>>>>>>>>>>> capability by way of endpoints. There is no need for a port
>>>>>>>>>>>>> field. One endpoint,
>>>>>>>>>>>>> one GPIO controller.
>>>>>>>>>>>>>
>>>>>>>>>>>> You still need a way to let the remote side know which port the
>>>>>>>>>>>> endpoint maps to, either
>>>>>>>>>>>> by embedding the port information in the message (the current
>>>>>>>>>>>> way), or by sending it
>>>>>>>>>>>> separately.
>>>>>>>>>>>>
>>>>>>>>>>> An endpoint is created with every namespace request. There
>>>>>>>>>>> should be
>>>>>>>>>>> one namespace request for every GPIO controller, which yields a
>>>>>>>>>>> unique
>>>>>>>>>>> endpoint for each controller and eliminates the need for an extra
>>>>>>>>>>> field to identify them.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Right, but this can still be done by just having one namespace
>>>>>>>>>> request.
>>>>>>>>>> We can create new endpoints bound to an existing namespace/
>>>>>>>>>> channel by
>>>>>>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>>>>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
>>>>>>>>>> b73d-228295daaeec@ti.com/
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I will look at your suggestion (i.e link above) later this week or
>>>>>>>>> next week.
>>>>>>>>>
>>>>>>>>>> My mental model looks like this for the complete picture:
>>>>>>>>>>
>>>>>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>>>>>> a. ept1 -> gpio-controller@1
>>>>>>>>>> b. ept2 -> gpio-controller@2
>>>>>>>>>>
>>>>>
>>>>> If my understanding of what gpio-controller is right, than this won't
>>>>> work. We need one rpmsg channel per gpio-controller, and in most cases
>>>>> there will be only one GPIO-controller on the remote side. If there are
>>>>> multiple or multiple instances of same controller, than we need separate
>>>>> channel name for that controller just like we would have separate device
>>>>> on the Linux.
>>>>
>>>> As done in ehe rpmsg_tty driver it could be instantiated several times with
>>>> the same channel/service name. This would imply a specific rpmsg to
>>>> retreive
>>>> the gpio controller index from the remote side.
>>>>>
>>>>>>>>>
>>>>>>>>> I've asked for one endpoint per GPIO controller since the very
>>>>>>>>> beginning. I don't yet have a strong opinion on whether to use one
>>>>>>>>> namespace request per GPIO controller or a single request that spins
>>>>>>>>> off multiple endpoints. I'll have to look at your link and
>>>>>>>>> reflect on
>>>>>>>>> that. Regardless of how we proceed on that front, multiplexing needs
>>>>>>>>> to happen at the endpoint level rather than the packet level.
>>>>>>>>> This is
>>>>>>>>> the only way this work can move forward.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
>>>>>>>> created with every namespace request.”
>>>>>>>>
>>>>>>>> If the endpoint is created only on the Linux side, how do we match
>>>>>>>> the Linux endpoint address with the local port field on the remote
>>>>>>>> side?
>>>>>>>
>>>>>>>
>>>>>>> Simply by sending a message to the remote containing the newly created
>>>>>>> endpoint and the port idx. Note that is this done just one time, after
>>>>>>> this
>>>>>>> Linux need not have the port field in the message everytime its sending
>>>>>>> a message.
>>>>>>>
>>>>>>>>
>>>>>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>>>>>> [addr], where [addr] corresponds to the GPIO controller address in
>>>>>>>> the DT. This would:
>>>>>>>
>>>>>>>
>>>>>>> You will face the same problem in this case also that you asked above:
>>>>>>> "how do we match the Linux endpoint address with the local port field
>>>>>>> on the remote side?"
>>>>>>
>>>>>> Sorry I probably introduced confusion here
>>>>>> my sentence should be;
>>>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>>>> [port],
>>>>>> where [port] corresponds to the GPIO controller port in the DT.
>>>>>>
>>>>>>
>>>>>> For instance:
>>>>>>
>>>>>> rpmsg {
>>>>>> rpmsg-io {
>>>>>> #address-cells = <1>;
>>>>>> #size-cells = <0>;
>>>>>>
>>>>>> gpio@25 {
>>>>>> compatible = "rpmsg-gpio";
>>>>>> reg = <25>;
>>>>>> gpio-controller;
>>>>>> #gpio-cells = <2>;
>>>>>> #interrupt-cells = <2>;
>>>>>> interrupt-controller;
>>>>>> };
>>>>>>
>>>>>> gpio@32 {
>>>>>> compatible = "rpmsg-gpio";
>>>>>> reg = <32>;
>>>>>> gpio-controller;
>>>>>> #gpio-cells = <2>;
>>>>>> #interrupt-cells = <2>;
>>>>>> interrupt-controller;
>>>>>> };
>>>>>> };
>>>>>> };
>>>>>>
>>>>>> rpmsg-io-25 would match with gpio@25
>>>>>> rpmsg-io-32 would match with gpio@32
>>>>>>
>>>>>
>>>>> The problem with this approach is, we will endup creating way too many
>>>>> RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
>>>>> many GPIOs can be handled by remote from memory perspective. At
>>>>> somepoint we might just run-out of number ept & channels created by the
>>>>> remote. As of now, open-amp library supports 128 epts I think.
>>>>
>>>> Right, I proposed a solution in my previous answer to Beleswar who has
>>>> the same concern.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Because the endpoint that is created on a namespace request is also
>>>>>>> dynamic in nature. How will the remote know which endpoint addr
>>>>>>> Linux allocated for a namespace that it announced?
>>>>>>>
>>>>>>> As an example/PoC, I created a firmware example which announces
>>>>>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>>>>>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>>>>>>> see it created 2 different addresses (0x400 and 0x401) for each of
>>>>>>> the name service request from the same firmware:
>>>>>>>
>>>>>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>>>>>>> [ 9.290275] virtio_rpmsg_bus virtio0: creating channel
>>>>>>> ti.ipc4.ping-pong addr 0xd
>>>>>>> [ 9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
>>>>>>> addr 0xe
>>>>>>> [ 9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
>>>>>>> formed from src = 0x400 to dst = 0xe
>>>>>>> [ 9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
>>>>>>> new channel: 0x401 -> 0xd!
>>>>>>>
>>>>>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>>>>>>> Back to same problem. Simple solution is to reply to remote with the
>>>>>>> created ept addr and the index.
>>>>>>
>>>>>> That why I would like to suggest to use the name service field to
>>>>>> identify the port/controller, instead of the endpoint address.
>>>>>>>
>>>>>>>>
>>>>>>>> - match the RPMsg probe with the DT,
>>>>>>>
>>>>>>>
>>>>>>> We can probe from all controllers with a single name service
>>>>>>> announcement too.
>>>>>>>
>>>>>>>> - provide a simple mapping between the port and the endpoint on both
>>>>>>>> sides,
>>>>>>>
>>>>>>>
>>>>>>> We are trying to get rid of this mapping from Linux side to adapt
>>>>>>> the gpio-virtio design.
>>>>>>>
>>>>>>>> - allow multiple endpoints on the remote side,
>>>>>>>
>>>>>>>
>>>>>>> We can support this as well with single nameservice model.
>>>>>>> There is no limitation. Remote has to send a message with
>>>>>>> its newly created ept that's all.
>>>>>>>
>>>>>>>> - provide a simple discovery mechanism for remote capabilities.
>>>>>>>
>>>>>>>
>>>>>>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>>>>>>
>>>>>>> Feel free to let me know if you have concerns with any of the
>>>>>>> suggestions!
>>>>>>
>>>>>> My only concern, whatever the solution, is that we find a smart
>>>>>> solution to associate the correct endpoint with the correct GPIO
>>>>>> port/controller defined in the DT.
>>>>>>
>>>>>> I may have misunderstood your solution. Could you please help me
>>>>>> understand your proposal by explaining how you would handle three
>>>>>> GPIO ports defined in the DT, considering that the endpoint
>>>>>> addresses on the Linux side can be random?
>>>>>> If I assume there is a unique endpoint on the remote side,
>>>>>> I do not understand how you can match, on the firmware side,
>>>>>> the Linux endpoint address to the GPIO port.
>>>>>>
>>>>>> Thanks and Regards,Arnaud
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Beleswar
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Arnaud
>>>>>>>>
>>>>>>>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>>>>>>>> a. ept1 -> i2c@1
>>>>>>>>>> b. ept2 -> i2c@2
>>>>>>>>>> c. ept3 -> i2c@3
>>>>>>>>>>
>>>>>>>>>> etc...
>>>>>>>>>>
>>>>>
>>>>> Just want to clear-up few terms before I jump to the solution:
>>>>>
>>>>> **RPMsg channel/device**:
>>>>> - These are devices announced by the remote processor, and created by
>>>>> linux. They are created at: /sys/bus/rpmsg/devices
>>>>> - The channel format: <name>.<src ept>.<dst ept>
>>>>>
>>>>> **RPMsg endpoint**:
>>>>> - Endpoint is differnt than channel. Single channel can have multiple
>>>>> endpoints, and represented in the linux with: /dev/rpmsg? devices.
>>>>>
>>>>> To create endpoint device, we have rpmsg_create_ept API, which takes
>>>>> channel information as input, which has src-ept, dst-ept.
>>>>>
>>>>> Following is proposed solution:
>>>>>
>>>>> 1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
>>>>> pin/port).
>>>>> - In our case that would be, single rpmsg-io node. (That makes me
>>>>> question if bindings are correct or not).
>>>>>
>>>>> 2) Assign GPIO number as src ept.
>>>>>
>>>>> i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
>>>>> endpoint.
>>>>>
>>>>> Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
>>>>> add 1024 offset to the GPIO number:
>>>>>
>>>>> so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
>>>>> (GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)
>>>>>
>>>>> Now on the remote side, there is single channel and only single-endpoint
>>>>> is needed that is mapped to the rpmsg-io channel callback.
>>>>>
>>>>> That callback will receive all the payloads from the Linux, which will
>>>>> have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).
>>>>
>>>>
>>>> Interesting approach. I also tried to find a similar solution.
>>>>
>>>> The question here is: how can we guarantee continuous addresses? Given
>>>> the static and dynamic allocation of endpoint addresses that are
>>>> implemented, my conclusion was that it is not reliable enough.
>>>>
>>>> but perhaps I missed something...
>>>>
>>>>>
>>>>> It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
>>>>> on platform specific logic.
>>>>>
>>>>> This doesn't need PORT information at all. Also it makes sure that
>>>>> remote is using only single-endpoint so not much memory is used.
>>>>>
>>>>> *Example*:
>>>>> If only rpmsg-gpio channel is created by the remote side, than following
>>>>> is the representation of the devices when GPIO 25, 26, 27 is assigned to
>>>>> the rpmsg-io controller:
>>>>>
>>>>> Linux Remote
>>>>>
>>>>> rpmsg-channel: rpmsg-gpio.0x400.0x400
>>>>>
>>>>> /dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
>>>>> |
>>>>> /dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
>>>>> |
>>>>> /dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-| 0x400 ept callback.
>>>>>
>>>>>
>>>>> *On remote side*:
>>>>>
>>>>> ept_0x400_callback(..., int src_ept, ...,)
>>>>> {
>>>>> int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
>>>>> // platform specific logic to convert gpio num to proper pin,
>>>>> // just like you would convert gpio num to pin on a linux gpio
>>>>> controller.
>>>>> }
>>>>>
>>>>> My question on the binding:
>>>>>
>>>>> Why each GPIO is represented with the separate node? I think rpmsg-gpio
>>>>> can be represented just any other GPIO controller? Please let me know if
>>>>> I am missing something. So rpmsg channel/rpmsg device is not created per
>>>>> GPIO, but per controller. GPIO number multiplexing should be done with
>>>>> rpmsg src ept, that removes the need of having each GPIO as a separate
>>>>> node.
>>>>>
>>>>>
>>>>> rpmsg_gpio: rpmsg-gpio@0 {
>>>>> compatible = "rpmsg-gpio";
>>>>> reg = <0>;
>>>>> gpio-controller;
>>>>> #gpio-cells = <2>;
>>>>> #interrupt-cells = <2>;
>>>>> interrupt-controller;
>>>>> };
>>>>>
>>>>> Then in DT, use like regular GPIO, but with the rpmsg-gpio controller:
>>>>>
>>>>> rpmsg-gpios = <&rpmsg_gpio (GPIO NUM) (flags)>;
>>>>>
>>>>> If the intent to create separate gpio nodes was only for the channel
>>>>> creation, then it's not really needed.
>>>>>
>>>>> [1]
>>>>> https://github.com/torvalds/linux/
>>>>> blob/6d35786de28116ecf78797a62b84e6bf3c45aa5a/drivers/rpmsg/
>>>>> virtio_rpmsg_bus.c#L136
>>>>>
>>>>
>>>> It is already the case. bindings declare GPIO controllers, not directly
>>>> GPIOs in:
>>>>
>>>> [PATCH v13 2/4] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode
>>>> support
>>>>
>>>> The discussion is around having an unique RPmsg endpoint for all
>>>> GPIO controller or one RPmsg endpoint per GPIO controller.
>>>>
>>>
>>> Endpoint where remote side or linux side?
>>>
>>> If unique endpoint on remote side per gpio controller then it makes sense.
>>>
>>> Unique endpoint on linux side doesn't make sense. Instead, unique
>>> channel per gpio controller makes sense, and each channel will have
>>> multiple endpoints on linux side. As I replied to Beleswar on the other
>>> email, I will copy past my answer here too:
>>>
>>>
>>> To be more specific:
>>>
>>> Linux: remote:
>>>
>>> ch1: rpmsg-gpio.-1.1024 -> gpio-controller@1024
>>> - gpio-line ept1
>>> - gpio-line ept2 -> They all map to same callback_ept_1024.
>>> - gpio-line ept3
>>>
>>> ch2: rpmsg-gpio.-1.1025 -> gpio-controller@1025
>>> - gpio-line ept1
>>> - gpio-line ept2 -> They all map to same callback_ept_1025.
>>> - gpio-line ept3
>>>
>>
>>
>> Hi Mathieu,
>>
>> So upon more brain storming in this approach I found limitation:
>>
>> This approach won't work if host OS is any other OS but Linux. For
>> example, if the remote OS is zephyr/baremetal using open-amp, then Only
>> Linux <-> zephyr combination will work, and we won't be able to re-use
>> this approach for zephyr <-> zephyr use case. The concept of rpmsg
>> channel/device exist only in the linux kernel implementation. This
>> brings another question: Should the protocol we decide work on other use
>> cases as well? Or Linux must be the Host OS for this protocol ?
>>
>
> Linux and Zephyr are very distinct OS, each with their own subsystems
> and characteristics. The design we choose here involves RPMSG and,
> inherently, Linux. We can't make decisions based on what may
> potentially happen in Zephyr.
>
>>
>> I think your & Arnaud's proposed approach of single endpoint per
>> gpio-controller on both side makes more sense, as it will work
>> regardless of any OS on host or remote side.
>>
>
> Arnaud, Beleswar, Andrew and I are all advocating for one endpoint per
> GPIO controller. The remaining issue it about the best way to work
> out source and destination addresses between Linux and the remote
> processor. I'm running out of time for today but I'll return to this
> thread with a final analysis by the end of the week.
>
Okay. Then that means multiple endpoints on Linux side can be considered.
If we decide to go single-endpoint per device on both side, then for
that here is the proposal to represent src ept and dst ept:
When we represent any device under rpmsg bus node, I think it should be
considered remote's view of the adddress space. So ideally we can
convert it to Linux view of the address space, via 'ranges' property.
So bindings should include 'ranges' property in the parent node. Then
linux view of the start address becomes src ept, and remote view of the
start address becomes dest ept. The remote view of the start address is
expected to be the static src endpoint on the remote side.
Following representation of the rpmsg devices (gpio, i2c, spi or any other):
rpmsg {
#address-cells = <1>;
#size-cells = <1>;
rpmsg-io {
compatible = "rpmsg-io-bus";
ranges = <remote_view_addr(dst ept) linux_view_addr(src ept) size>;
#address-cells = <1>;
#size-cells = <1>;
gpio@remote_view_addr(or dst ept) {
compatible = "rpmsg-io";
reg = <remote_view_addr addr_space_size>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
...
};
};
Example device-tree:
rpmsg {
#address-cells = <1>;
#size-cells = <1>;
rpmsg-io {
compatible = "rpmsg-io-bus";
ranges = <0x10000 0x50000 0x1000>,
<0x20000 0x60000 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
gpio@10000 {
compatible = "rpmsg-io";
reg = <0x10000 0x1000>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
gpio@20000 {
compatible = "rpmsg-io";
reg = <0x20000 0x1000>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
};
};
Thanks,
Tanmay
>> To be more specific this will look like following:
>>
>> Host (Linux) Remote (baremetal/RTOS)
>>
>> rpmsg ch/device 1:
>> - rpmsg ept 1 <------> rpmsg ept 1 gpio-controller 0
>>
>> rpmsg ch/device 2:
>> - rpmsg ept 2 <------> rpmsg ept 2 gpio-controller 1
>>
>>
>> The question is, how to decide src ept, and dest ept on both sides?
>> I still think it should be static endpoints.
>>
>> I will get back with more reasoning on that.
>>
>>> On the remote side, we have to hardcode Which rpmsg controller is mapped
>>> to which endpoint.
>>>
>>>> Or did I misunderstand your questions?
>>>>
>>>> Thanks,
>>>> Arnaud
>>>>
>>>
>>>
>>> I gave this patch more time yesterday, and I think the 'reg' property
>>> should represent remote endpoint, instead of the gpio-controller index.
>>>
>>> So in this approach remote implementation is expected to provide
>>> hard-coded (static) endpoints for each gpio-controller instance, and
>>> that same number should be represented with the 'reg' property.
>>>
>>> On remote side:
>>>
>>> #define RPMSG_GPIO_0_CONTROLLER_EPT (RPMSG_RESERVED_ADDRESSES + 1) // 1024
>>>
>>> ept_1024_callback() {
>>>
>>> // handle appropriate gpio port ()
>>>
>>> }
>>>
>>> On linux side:
>>>
>>> So new representation of controller:
>>>
>>> rpmsg_gpio_0: gpio@1024 {
>>> compatible = "rpmsg-gpio";
>>> reg = <1024>;
>>> gpio-controller;
>>> #gpio-cells = <2>;
>>> #interrupt-cells = <2>;
>>> interrupt-controller;
>>> };
>>>
>>> rpmsg_gpio_1: gpio@1025 {
>>> compatible = "rpmsg-gpio";
>>> reg = <1025>;
>>> gpio-controller;
>>> #gpio-cells = <2>;
>>> #interrupt-cells = <2>;
>>> interrupt-controller;
>>> };
>>>
>>> gpios = <&rpmsg_gpio_0 (GPIO NUM or PIN) flags>,
>>> <&rpmsg_gpio_1 (GPIO NUM or PIN) flags>;
>>>
>>> Now in the linux driver:
>>>
>>> You can easily retrieve destination endpoint when we want to send the
>>> command to the gpio controller via device's "reg" property.
>>>
>>> This approach also provides built-in security as well. Because now
>>> gpio-controller instance is hardcoded with the endpoint callback, it
>>> can't be modified/addressed without changing the 'reg' property.
>>>
>>> Just like you wouldn't change device address for the instance of the
>>> gpio-controller right?
>>>
>>> This approach can be easily adapted to all the other rpmsg controllers
>>> as well.
>>>
>>> So, dynamic endpoint allocation doesn't make sense in this case. Dynamic
>>> endpoint allocation makes more sense for user-space apps which don't
>>> really care about endpoints and only payloads.
>>>
>>> But, here we are multiplexing device-addresses with endpoints, and so it
>>> has to be fixed, and presented via 'reg' property. So, firmware can't
>>> change device-address without Linux knowing it.
>>>
>>> Thanks,
>>> Tanmay
>>>
>>>
>>>>
>>>>>>>>>> This way device groups are isolated with each channel/namespace, and
>>>>>>>>>> instances within each device groups are also respected with specific
>>>>>>>>>> endpoints.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Beleswar
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
^ permalink raw reply
* Re: [PATCH RFC v2 1/4] dt-bindings: clk: zte: Add zx297520v3 clock and reset bindings.
From: Stefan Dösinger @ 2026-05-11 21:33 UTC (permalink / raw)
To: Conor Dooley
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260511-backstage-crewman-e44947ab6cfc@spud>
[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]
Hi Conor,
Thanks for your reply!
> Am 11.05.2026 um 19:07 schrieb Conor Dooley <conor@kernel.org>:
>
> How come the "matrixclk" has no constraints on clock properties?
Because I am not sure what the correct/preferred way to express the interface between top and matrix is - see the first question raised in my cover letter.
In short, matrix potentially consumes all clocks available on the top controller. There is no obvious interface between them, like there is between matrix and LSP. So I see two ways to handle this in the bindings:
1) List the top clk inputs, top clk PLL outputs and PLL fractionals as matrix input
2) Be quiet about it
It'd be about 20 clocks or so that I know are consumed. The bigger issue than the number of clocks is that my knowledge of the board is from reverse engineering, not proper datasheets, so I might find out that a clock is missing or wrong.
> Although, these two devices seem too different to be in the same
> dt-binding. Do they have anyhting in common other than the SoC they are
> part of?
No, they don't have anything in common, other than that their concerns are poorly separated in hardware.
I take it from your question that the preferred way is to have separate bindings for them in this case - I guess separate headers as well as separate yaml files. Is this correct?
The third clock controller - LSP - is nicely separated from the other two. I would not be surprised to see this subsystem of the board show up on a different ZTE board. If top and matrix should have different bindings, LSP certainly should as well.
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 4/4] remoteproc: switch drivers to optional resource-table helper
From: Ben Levinsky @ 2026-05-11 21:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, linux-remoteproc
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Patrice Chotard, Maxime Coquelin,
Alexandre Torgue, imx, linux-arm-kernel, linux-kernel,
linux-renesas-soc, linux-stm32, tanmay.shah
In-Reply-To: <20260511211841.284809-1-ben.levinsky@amd.com>
Use the shared optional resource-table helper in the remoteproc
drivers that currently ignore a missing table. This keeps the missing
resource-table case non-fatal while letting other parsing failures
propagate to the caller.
Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
---
drivers/remoteproc/imx_dsp_rproc.c | 10 +--------
drivers/remoteproc/imx_rproc.c | 13 +----------
drivers/remoteproc/rcar_rproc.c | 13 +----------
drivers/remoteproc/stm32_rproc.c | 10 +--------
drivers/remoteproc/xlnx_r5_remoteproc.c | 29 +------------------------
5 files changed, 5 insertions(+), 70 deletions(-)
diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
index 2d9f14fbef1d..3e96e7978cd2 100644
--- a/drivers/remoteproc/imx_dsp_rproc.c
+++ b/drivers/remoteproc/imx_dsp_rproc.c
@@ -954,14 +954,6 @@ static int imx_dsp_rproc_elf_load_segments(struct rproc *rproc, const struct fir
return ret;
}
-static int imx_dsp_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
-{
- if (rproc_elf_load_rsc_table(rproc, fw))
- dev_warn(&rproc->dev, "no resource table found for this firmware\n");
-
- return 0;
-}
-
static int imx_dsp_rproc_load(struct rproc *rproc, const struct firmware *fw)
{
struct imx_dsp_rproc *priv = rproc->priv;
@@ -997,7 +989,7 @@ static const struct rproc_ops imx_dsp_rproc_ops = {
.stop = imx_dsp_rproc_stop,
.kick = imx_dsp_rproc_kick,
.load = imx_dsp_rproc_load,
- .parse_fw = imx_dsp_rproc_parse_fw,
+ .parse_fw = rproc_elf_load_rsc_table_optional,
.handle_rsc = imx_dsp_rproc_handle_rsc,
.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
.sanity_check = rproc_elf_sanity_check,
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 6249815b54d8..5509048f7e19 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -680,17 +680,6 @@ static int imx_rproc_prepare(struct rproc *rproc)
return 0;
}
-static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
-{
- int ret;
-
- ret = rproc_elf_load_rsc_table(rproc, fw);
- if (ret)
- dev_info(&rproc->dev, "No resource table in elf\n");
-
- return 0;
-}
-
static void imx_rproc_kick(struct rproc *rproc, int vqid)
{
struct imx_rproc *priv = rproc->priv;
@@ -777,7 +766,7 @@ static const struct rproc_ops imx_rproc_ops = {
.kick = imx_rproc_kick,
.da_to_va = imx_rproc_da_to_va,
.load = rproc_elf_load_segments,
- .parse_fw = imx_rproc_parse_fw,
+ .parse_fw = rproc_elf_load_rsc_table_optional,
.find_loaded_rsc_table = imx_rproc_elf_find_loaded_rsc_table,
.get_loaded_rsc_table = imx_rproc_get_loaded_rsc_table,
.sanity_check = rproc_elf_sanity_check,
diff --git a/drivers/remoteproc/rcar_rproc.c b/drivers/remoteproc/rcar_rproc.c
index e3121fadd292..7adaa6d37b82 100644
--- a/drivers/remoteproc/rcar_rproc.c
+++ b/drivers/remoteproc/rcar_rproc.c
@@ -55,17 +55,6 @@ static int rcar_rproc_prepare(struct rproc *rproc)
}
}
-static int rcar_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
-{
- int ret;
-
- ret = rproc_elf_load_rsc_table(rproc, fw);
- if (ret)
- dev_info(&rproc->dev, "No resource table in elf\n");
-
- return 0;
-}
-
static int rcar_rproc_start(struct rproc *rproc)
{
struct rcar_rproc *priv = rproc->priv;
@@ -104,7 +93,7 @@ static struct rproc_ops rcar_rproc_ops = {
.start = rcar_rproc_start,
.stop = rcar_rproc_stop,
.load = rproc_elf_load_segments,
- .parse_fw = rcar_rproc_parse_fw,
+ .parse_fw = rproc_elf_load_rsc_table_optional,
.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
.sanity_check = rproc_elf_sanity_check,
.get_boot_addr = rproc_elf_get_boot_addr,
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 7ac8265b60ac..007175dcd7af 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -232,14 +232,6 @@ static int stm32_rproc_prepare(struct rproc *rproc)
}
}
-static int stm32_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
-{
- if (rproc_elf_load_rsc_table(rproc, fw))
- dev_warn(&rproc->dev, "no resource table found for this firmware\n");
-
- return 0;
-}
-
static irqreturn_t stm32_rproc_wdg(int irq, void *data)
{
struct platform_device *pdev = data;
@@ -631,7 +623,7 @@ static const struct rproc_ops st_rproc_ops = {
.detach = stm32_rproc_detach,
.kick = stm32_rproc_kick,
.load = rproc_elf_load_segments,
- .parse_fw = stm32_rproc_parse_fw,
+ .parse_fw = rproc_elf_load_rsc_table_optional,
.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
.get_loaded_rsc_table = stm32_rproc_get_loaded_rsc_table,
.sanity_check = rproc_elf_sanity_check,
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
index e5d1903c9636..92c1f8972551 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -664,33 +664,6 @@ static int add_tcm_banks(struct rproc *rproc)
return ret;
}
-/*
- * zynqmp_r5_parse_fw()
- * @rproc: single R5 core's corresponding rproc instance
- * @fw: ptr to firmware to be loaded onto r5 core
- *
- * get resource table if available
- *
- * return 0 on success, otherwise non-zero value on failure
- */
-static int zynqmp_r5_parse_fw(struct rproc *rproc, const struct firmware *fw)
-{
- int ret;
-
- ret = rproc_elf_load_rsc_table(rproc, fw);
- if (ret == -EINVAL) {
- /*
- * resource table only required for IPC.
- * if not present, this is not necessarily an error;
- * for example, loading r5 hello world application
- * so simply inform user and keep going.
- */
- dev_info(&rproc->dev, "no resource table found.\n");
- ret = 0;
- }
- return ret;
-}
-
/**
* zynqmp_r5_rproc_prepare() - prepare core to boot/attach
* adds carveouts for TCM bank and reserved memory regions
@@ -849,7 +822,7 @@ static const struct rproc_ops zynqmp_r5_rproc_ops = {
.start = zynqmp_r5_rproc_start,
.stop = zynqmp_r5_rproc_stop,
.load = rproc_elf_load_segments,
- .parse_fw = zynqmp_r5_parse_fw,
+ .parse_fw = rproc_elf_load_rsc_table_optional,
.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
.sanity_check = rproc_elf_sanity_check,
.get_boot_addr = rproc_elf_get_boot_addr,
--
2.34.1
^ permalink raw reply related
* [PATCH 3/4] remoteproc: add helper for optional ELF resource tables
From: Ben Levinsky @ 2026-05-11 21:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, linux-remoteproc
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Patrice Chotard, Maxime Coquelin,
Alexandre Torgue, imx, linux-arm-kernel, linux-kernel,
linux-renesas-soc, linux-stm32, tanmay.shah
In-Reply-To: <20260511211841.284809-1-ben.levinsky@amd.com>
Add a small helper around rproc_elf_load_rsc_table() for remoteproc
drivers that treat a missing ELF resource table as optional. The helper
returns success on -EINVAL and propagates other failures unchanged.
Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
---
drivers/remoteproc/remoteproc_internal.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
index 3724a47a9748..dff87e468837 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -146,6 +146,18 @@ static inline int rproc_mem_entry_iounmap(struct rproc *rproc,
return 0;
}
+static inline int rproc_elf_load_rsc_table_optional(struct rproc *rproc,
+ const struct firmware *fw)
+{
+ int ret;
+
+ ret = rproc_elf_load_rsc_table(rproc, fw);
+ if (ret == -EINVAL)
+ dev_dbg(&rproc->dev, "no resource table found\n");
+
+ return ret == -EINVAL ? 0 : ret;
+}
+
static inline int rproc_prepare_device(struct rproc *rproc)
{
if (rproc->ops->prepare)
--
2.34.1
^ permalink raw reply related
* [PATCH 2/4] remoteproc: switch exact-match drivers to wc-ioremap callbacks
From: Ben Levinsky @ 2026-05-11 21:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, linux-remoteproc
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Patrice Chotard, Maxime Coquelin,
Alexandre Torgue, imx, linux-arm-kernel, linux-kernel,
linux-renesas-soc, linux-stm32, tanmay.shah
In-Reply-To: <20260511211841.284809-1-ben.levinsky@amd.com>
Replace the exact-match carveout map and unmap callbacks in the
existing remoteproc drivers with the common wc-ioremap helpers. Leave
the zynqmp R5 TCM callbacks alone because they also clear the mapped
memory and are not exact matches.
Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
---
drivers/remoteproc/imx_dsp_rproc.c | 36 ++++---------------
drivers/remoteproc/imx_rproc.c | 32 ++---------------
drivers/remoteproc/rcar_rproc.c | 33 ++---------------
drivers/remoteproc/st_remoteproc.c | 31 ++--------------
drivers/remoteproc/stm32_rproc.c | 34 ++----------------
drivers/remoteproc/xlnx_r5_remoteproc.c | 47 +++----------------------
6 files changed, 18 insertions(+), 195 deletions(-)
diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
index 008741af9f11..2d9f14fbef1d 100644
--- a/drivers/remoteproc/imx_dsp_rproc.c
+++ b/drivers/remoteproc/imx_dsp_rproc.c
@@ -644,32 +644,6 @@ static void imx_dsp_rproc_free_mbox(struct imx_dsp_rproc *priv)
mbox_free_channel(priv->rxdb_ch);
}
-static int imx_dsp_rproc_mem_alloc(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- struct device *dev = rproc->dev.parent;
- void *va;
-
- va = ioremap_wc(mem->dma, mem->len);
- if (!va) {
- dev_err(dev, "Unable to map memory region: %pa+%zx\n",
- &mem->dma, mem->len);
- return -ENOMEM;
- }
-
- mem->va = va;
-
- return 0;
-}
-
-static int imx_dsp_rproc_mem_release(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- iounmap(mem->va);
-
- return 0;
-}
-
/**
* imx_dsp_rproc_add_carveout() - request mailbox channels
* @priv: private data pointer
@@ -700,8 +674,10 @@ static int imx_dsp_rproc_add_carveout(struct imx_dsp_rproc *priv)
/* Register memory region */
mem = rproc_mem_entry_init(dev, NULL, (dma_addr_t)att->sa,
- att->size, da, imx_dsp_rproc_mem_alloc,
- imx_dsp_rproc_mem_release, "dsp_mem");
+ att->size, da,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
+ "dsp_mem");
if (mem)
rproc_coredump_add_segment(rproc, da, att->size);
@@ -732,8 +708,8 @@ static int imx_dsp_rproc_add_carveout(struct imx_dsp_rproc *priv)
/* Register memory region */
mem = rproc_mem_entry_init(dev, NULL, (dma_addr_t)res.start,
resource_size(&res), da,
- imx_dsp_rproc_mem_alloc,
- imx_dsp_rproc_mem_release,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
"%.*s", strchrnul(res.name, '@') - res.name, res.name);
if (!mem)
return -ENOMEM;
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 7f54322244ac..6249815b54d8 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -600,35 +600,6 @@ static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *i
return va;
}
-static int imx_rproc_mem_alloc(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- struct device *dev = rproc->dev.parent;
- void *va;
-
- dev_dbg(dev, "map memory: %p+%zx\n", &mem->dma, mem->len);
- va = ioremap_wc(mem->dma, mem->len);
- if (IS_ERR_OR_NULL(va)) {
- dev_err(dev, "Unable to map memory region: %p+%zx\n",
- &mem->dma, mem->len);
- return -ENOMEM;
- }
-
- /* Update memory entry va */
- mem->va = va;
-
- return 0;
-}
-
-static int imx_rproc_mem_release(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- dev_dbg(rproc->dev.parent, "unmap memory: %pa\n", &mem->dma);
- iounmap(mem->va);
-
- return 0;
-}
-
static int imx_rproc_sm_lmm_prepare(struct rproc *rproc)
{
struct imx_rproc *priv = rproc->priv;
@@ -692,7 +663,8 @@ static int imx_rproc_prepare(struct rproc *rproc)
/* Register memory region */
mem = rproc_mem_entry_init(priv->dev, NULL, (dma_addr_t)res.start,
resource_size(&res), da,
- imx_rproc_mem_alloc, imx_rproc_mem_release,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
"%.*s", strchrnul(res.name, '@') - res.name,
res.name);
if (!mem)
diff --git a/drivers/remoteproc/rcar_rproc.c b/drivers/remoteproc/rcar_rproc.c
index 3c25625f966d..e3121fadd292 100644
--- a/drivers/remoteproc/rcar_rproc.c
+++ b/drivers/remoteproc/rcar_rproc.c
@@ -19,35 +19,6 @@ struct rcar_rproc {
struct reset_control *rst;
};
-static int rcar_rproc_mem_alloc(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- struct device *dev = &rproc->dev;
- void *va;
-
- dev_dbg(dev, "map memory: %pa+%zx\n", &mem->dma, mem->len);
- va = ioremap_wc(mem->dma, mem->len);
- if (!va) {
- dev_err(dev, "Unable to map memory region: %pa+%zx\n",
- &mem->dma, mem->len);
- return -ENOMEM;
- }
-
- /* Update memory entry va */
- mem->va = va;
-
- return 0;
-}
-
-static int rcar_rproc_mem_release(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- dev_dbg(&rproc->dev, "unmap memory: %pa\n", &mem->dma);
- iounmap(mem->va);
-
- return 0;
-}
-
static int rcar_rproc_prepare(struct rproc *rproc)
{
struct device *dev = rproc->dev.parent;
@@ -73,8 +44,8 @@ static int rcar_rproc_prepare(struct rproc *rproc)
mem = rproc_mem_entry_init(dev, NULL,
res.start,
resource_size(&res), da,
- rcar_rproc_mem_alloc,
- rcar_rproc_mem_release,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
res.name);
if (!mem)
diff --git a/drivers/remoteproc/st_remoteproc.c b/drivers/remoteproc/st_remoteproc.c
index a07edf7217d2..486180cdccb4 100644
--- a/drivers/remoteproc/st_remoteproc.c
+++ b/drivers/remoteproc/st_remoteproc.c
@@ -88,33 +88,6 @@ static void st_rproc_kick(struct rproc *rproc, int vqid)
dev_err(dev, "failed to send message via mbox: %d\n", ret);
}
-static int st_rproc_mem_alloc(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- struct device *dev = rproc->dev.parent;
- void *va;
-
- va = ioremap_wc(mem->dma, mem->len);
- if (!va) {
- dev_err(dev, "Unable to map memory region: %pa+%zx\n",
- &mem->dma, mem->len);
- return -ENOMEM;
- }
-
- /* Update memory entry va */
- mem->va = va;
-
- return 0;
-}
-
-static int st_rproc_mem_release(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- iounmap(mem->va);
-
- return 0;
-}
-
static int st_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
{
struct device *dev = rproc->dev.parent;
@@ -138,8 +111,8 @@ static int st_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
mem = rproc_mem_entry_init(dev, NULL,
(dma_addr_t)res.start,
resource_size(&res), res.start,
- st_rproc_mem_alloc,
- st_rproc_mem_release,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
"%.*s",
strchrnul(res.name, '@') - res.name,
res.name);
diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 632614013dc6..7ac8265b60ac 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -113,35 +113,6 @@ static int stm32_rproc_pa_to_da(struct rproc *rproc, phys_addr_t pa, u64 *da)
return -EINVAL;
}
-static int stm32_rproc_mem_alloc(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- struct device *dev = rproc->dev.parent;
- void *va;
-
- dev_dbg(dev, "map memory: %pad+%zx\n", &mem->dma, mem->len);
- va = (__force void *)ioremap_wc(mem->dma, mem->len);
- if (IS_ERR_OR_NULL(va)) {
- dev_err(dev, "Unable to map memory region: %pad+0x%zx\n",
- &mem->dma, mem->len);
- return -ENOMEM;
- }
-
- /* Update memory entry va */
- mem->va = va;
-
- return 0;
-}
-
-static int stm32_rproc_mem_release(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- dev_dbg(rproc->dev.parent, "unmap memory: %pa\n", &mem->dma);
- iounmap((__force __iomem void *)mem->va);
-
- return 0;
-}
-
static int stm32_rproc_of_memory_translations(struct platform_device *pdev,
struct stm32_rproc *ddata)
{
@@ -237,8 +208,8 @@ static int stm32_rproc_prepare(struct rproc *rproc)
mem = rproc_mem_entry_init(dev, NULL,
(dma_addr_t)res.start,
resource_size(&res), da,
- stm32_rproc_mem_alloc,
- stm32_rproc_mem_release,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
"%.*s", strchrnul(res.name, '@') - res.name,
res.name);
if (mem)
@@ -957,4 +928,3 @@ MODULE_DESCRIPTION("STM32 Remote Processor Control Driver");
MODULE_AUTHOR("Ludovic Barre <ludovic.barre@st.com>");
MODULE_AUTHOR("Fabien Dessenne <fabien.dessenne@st.com>");
MODULE_LICENSE("GPL v2");
-
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 45a62cb98072..e5d1903c9636 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -447,45 +447,6 @@ static int zynqmp_r5_rproc_stop(struct rproc *rproc)
return ret;
}
-/*
- * zynqmp_r5_mem_region_map()
- * @rproc: single R5 core's corresponding rproc instance
- * @mem: mem descriptor to map reserved memory-regions
- *
- * Callback to map va for memory-region's carveout.
- *
- * return 0 on success, otherwise non-zero value on failure
- */
-static int zynqmp_r5_mem_region_map(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- void __iomem *va;
-
- va = ioremap_wc(mem->dma, mem->len);
- if (IS_ERR_OR_NULL(va))
- return -ENOMEM;
-
- mem->va = (void *)va;
-
- return 0;
-}
-
-/*
- * zynqmp_r5_rproc_mem_unmap
- * @rproc: single R5 core's corresponding rproc instance
- * @mem: mem entry to unmap
- *
- * Unmap memory-region carveout
- *
- * return: always returns 0
- */
-static int zynqmp_r5_mem_region_unmap(struct rproc *rproc,
- struct rproc_mem_entry *mem)
-{
- iounmap((void __iomem *)mem->va);
- return 0;
-}
-
/*
* add_mem_regions_carveout()
* @rproc: single R5 core's corresponding rproc instance
@@ -522,8 +483,8 @@ static int add_mem_regions_carveout(struct rproc *rproc)
rproc_mem = rproc_mem_entry_init(&rproc->dev, NULL,
(dma_addr_t)res.start,
resource_size(&res), res.start,
- zynqmp_r5_mem_region_map,
- zynqmp_r5_mem_region_unmap,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
"%.*s",
strchrnul(res.name, '@') - res.name,
res.name);
@@ -560,8 +521,8 @@ static int add_sram_carveouts(struct rproc *rproc)
rproc_mem = rproc_mem_entry_init(&rproc->dev, NULL,
dma_addr,
len, da,
- zynqmp_r5_mem_region_map,
- zynqmp_r5_mem_region_unmap,
+ rproc_mem_entry_ioremap_wc,
+ rproc_mem_entry_iounmap,
sram->sram_res.name);
if (!rproc_mem) {
dev_err(&rproc->dev, "failed to add sram %s da=0x%x, size=0x%lx",
--
2.34.1
^ permalink raw reply related
* [PATCH 1/4] remoteproc: add common wc-ioremap carveout callbacks
From: Ben Levinsky @ 2026-05-11 21:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, linux-remoteproc
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Patrice Chotard, Maxime Coquelin,
Alexandre Torgue, imx, linux-arm-kernel, linux-kernel,
linux-renesas-soc, linux-stm32, tanmay.shah
In-Reply-To: <20260511211841.284809-1-ben.levinsky@amd.com>
Several remoteproc drivers open-code the same ioremap_wc() and
iounmap() callbacks for carveout mappings. Add subsystem-private
helpers in remoteproc_internal.h so those drivers can share the same
implementation.
Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
---
drivers/remoteproc/remoteproc_internal.h | 26 +++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
index 0a5e15744b1d..3724a47a9748 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -12,8 +12,9 @@
#ifndef REMOTEPROC_INTERNAL_H
#define REMOTEPROC_INTERNAL_H
-#include <linux/irqreturn.h>
#include <linux/firmware.h>
+#include <linux/io.h>
+#include <linux/irqreturn.h>
struct rproc;
@@ -122,6 +123,29 @@ rproc_find_carveout_by_name(struct rproc *rproc, const char *name, ...);
void rproc_add_rvdev(struct rproc *rproc, struct rproc_vdev *rvdev);
void rproc_remove_rvdev(struct rproc_vdev *rvdev);
+static inline int rproc_mem_entry_ioremap_wc(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ void __iomem *va;
+
+ va = ioremap_wc(mem->dma, mem->len);
+ if (!va)
+ return -ENOMEM;
+
+ mem->va = (__force void *)va;
+ mem->is_iomem = true;
+
+ return 0;
+}
+
+static inline int rproc_mem_entry_iounmap(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ iounmap((__force __iomem void *)mem->va);
+
+ return 0;
+}
+
static inline int rproc_prepare_device(struct rproc *rproc)
{
if (rproc->ops->prepare)
--
2.34.1
^ permalink raw reply related
* [PATCH 0/4] remoteproc: cleanup shared carveout and resource-table helpers
From: Ben Levinsky @ 2026-05-11 21:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, linux-remoteproc
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Patrice Chotard, Maxime Coquelin,
Alexandre Torgue, imx, linux-arm-kernel, linux-kernel,
linux-renesas-soc, linux-stm32, tanmay.shah
This series is a preparatory remoteproc cleanup split out from review of
the AMD BRAM-based remoteproc series.
During review, there was a request to move the duplicated plain
ioremap_wc()/iounmap() carveout callbacks into common code and to
factor the "missing resource table is OK" ELF parsing path into a
common helper as well. There was also a request to send that cleanup as
its own patchset first, with the AMD BRAM series respun afterwards on
top once this cleanup is merged.
This series does that in four patches:
1. add common subsystem-private callbacks for the exact-match
wc-ioremap carveout case
2. switch the in-tree exact-match users over to those callbacks
3. add a common helper for drivers that treat a missing ELF resource
table as optional, returning success on -EINVAL and propagating
other errors unchanged
4. switch the matching in-tree drivers over to that helper
For the carveout map/unmap cleanup, this series covers the exact-match
users called out in review: xlnx_r5_remoteproc, rcar_rproc,
st_remoteproc, stm32_rproc, imx_rproc, and imx_dsp_rproc. The zynqmp R5
TCM mapping path is left alone because it also clears the mapped memory
and is not an exact match.
For the optional resource-table handling, this series converts
xlnx_r5_remoteproc, rcar_rproc, stm32_rproc, imx_rproc, and
imx_dsp_rproc. st_remoteproc is intentionally left unchanged because its
parse_fw() callback also builds carveouts and is therefore not a direct
match for the helper introduced here.
Ben Levinsky (4):
remoteproc: add common wc-ioremap carveout callbacks
remoteproc: switch exact-match drivers to wc-ioremap callbacks
remoteproc: add helper for optional ELF resource tables
remoteproc: switch drivers to optional resource-table helper
drivers/remoteproc/imx_dsp_rproc.c | 46 +++-----------
drivers/remoteproc/imx_rproc.c | 45 +-------------
drivers/remoteproc/rcar_rproc.c | 46 +-------------
drivers/remoteproc/remoteproc_internal.h | 38 +++++++++++-
drivers/remoteproc/st_remoteproc.c | 31 +---------
drivers/remoteproc/stm32_rproc.c | 44 +-------------
drivers/remoteproc/xlnx_r5_remoteproc.c | 76 ++----------------------
7 files changed, 60 insertions(+), 266 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH 3/3] perf/arm_cspmu: nvidia: fix BDF calculation examples in PCIE PMU docs
From: Saurav Sachidanand @ 2026-05-11 21:09 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Besar Wicaksono, Ilkka Koskinen, Jonathan Hunter,
linux-arm-kernel, linux-perf-users, linux-kernel, aghayev, juew,
Saurav Sachidanand
In-Reply-To: <20260511210905.91917-1-sauravsc@amazon.com>
The BDF hex values in the documentation examples are inconsistent with
the stated formula (bus << 8) + (device << 3) + (function):
- BDF 27:01.1: documented as 0x2781, correct value is 0x2709
(0x27 << 8) + (0x01 << 3) + 0x1 = 0x2709
- BDF 01:01.0: documented as 0x0180, correct value is 0x0108
(0x01 << 8) + (0x01 << 3) + 0x0 = 0x0108
It appears (device << 7) was used instead of (device << 3) when
computing the example values.
Fixes: bf585ba14726 ("perf/arm_cspmu: nvidia: Add Tegra410 PCIE PMU")
Signed-off-by: Saurav Sachidanand <sauravsc@amazon.com>
---
Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst b/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
index 0656223b61d47..24f0e801d7b80 100644
--- a/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
+++ b/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst
@@ -170,7 +170,7 @@ The list of event filters:
devices in root port 0 to 3.
* src_bdf: the BDF that will be monitored. This is a 16-bit value that
follows formula: (bus << 8) + (device << 3) + (function). For example, the
- value of BDF 27:01.1 is 0x2781.
+ value of BDF 27:01.1 is 0x2709.
* src_bdf_en: enable the BDF filter. If this is set, the BDF filter value in
"src_bdf" is used to filter the traffic.
@@ -215,7 +215,7 @@ Example usage:
* Count event id 0x4 from BDF 01:01.0 of PCIE RC-4 on socket 0 targeting all
destinations::
- perf stat -a -e nvidia_pcie_pmu_0_rc_4/event=0x4,src_bdf=0x0180,src_bdf_en=0x1/
+ perf stat -a -e nvidia_pcie_pmu_0_rc_4/event=0x4,src_bdf=0x0108,src_bdf_en=0x1/
.. _NVIDIA_T410_PCIE_PMU_RC_Mapping_Section:
--
2.47.3
^ permalink raw reply related
* [PATCH 2/3] perf/arm_cspmu: nvidia: handle empty resource list in PCIE-TGT init
From: Saurav Sachidanand @ 2026-05-11 21:09 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Besar Wicaksono, Ilkka Koskinen, Jonathan Hunter,
linux-arm-kernel, linux-perf-users, linux-kernel, aghayev, juew,
Saurav Sachidanand
When acpi_dev_get_memory_resources() returns success but the resource
list is empty (rentry is NULL), addr_filter_reg remains NULL from
devm_kzalloc. Since IS_ERR(NULL) is false, the function proceeds
without error and later dereferences the NULL pointer in
pcie_tgt_pmu_config_addr_filter().
Set addr_filter_reg to ERR_PTR(-ENODEV) when the resource list is
empty so the existing IS_ERR check catches it.
Fixes: 3dd73022306b ("perf/arm_cspmu: nvidia: Add Tegra410 PCIE-TGT PMU")
Signed-off-by: Saurav Sachidanand <sauravsc@amazon.com>
---
drivers/perf/arm_cspmu/nvidia_cspmu.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/perf/arm_cspmu/nvidia_cspmu.c b/drivers/perf/arm_cspmu/nvidia_cspmu.c
index bac83e424d6dc..bae722e263e91 100644
--- a/drivers/perf/arm_cspmu/nvidia_cspmu.c
+++ b/drivers/perf/arm_cspmu/nvidia_cspmu.c
@@ -555,14 +555,16 @@ static int pcie_tgt_init_data(struct arm_cspmu *cspmu)
rentry = list_first_entry_or_null(
&resource_list, struct resource_entry, node);
- if (rentry) {
+ if (rentry)
data->addr_filter_reg = devm_ioremap_resource(dev, rentry->res);
- ret = 0;
- }
+ else
+ data->addr_filter_reg = ERR_PTR(-ENODEV);
if (IS_ERR(data->addr_filter_reg)) {
dev_err(dev, "failed to get address filter resource\n");
ret = PTR_ERR(data->addr_filter_reg);
+ } else {
+ ret = 0;
}
acpi_dev_free_resource_list(&resource_list);
--
2.47.3
^ permalink raw reply related
* [PATCH 1/3] perf vendor events arm64: fix swapped MetricGroup for Tegra410 L1 prefetcher metrics
From: Saurav Sachidanand @ 2026-05-11 21:08 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Will Deacon, Besar Wicaksono, Ian Rogers, Namhyung Kim, Leo Yan,
linux-perf-users, linux-arm-kernel, linux-kernel, aghayev, juew,
Saurav Sachidanand
The L1D prefetcher metrics (l1d_cache_rw_miss_ratio, l1d_demand_accesses,
etc.) were incorrectly assigned to MetricGroup "L1I_Prefetcher_Effectiveness"
and vice versa. This causes 'perf stat --metric-group L1D_Prefetcher_Effectiveness'
to display L1I metrics, which is misleading.
Swap the MetricGroup assignments so L1D metrics are in the L1D group and
L1I metrics are in the L1I group.
Fixes: 86ff690f45cc ("perf vendor events arm64: Add Tegra410 Olympus PMU events")
Signed-off-by: Saurav Sachidanand <sauravsc@amazon.com>
---
.../arch/arm64/nvidia/t410/metrics.json | 28 +++++++++----------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/tools/perf/pmu-events/arch/arm64/nvidia/t410/metrics.json b/tools/perf/pmu-events/arch/arm64/nvidia/t410/metrics.json
index b825ede03f544..59474ccb7417f 100644
--- a/tools/perf/pmu-events/arch/arm64/nvidia/t410/metrics.json
+++ b/tools/perf/pmu-events/arch/arm64/nvidia/t410/metrics.json
@@ -346,42 +346,42 @@
"MetricExpr": "l1d_demand_misses / l1d_demand_accesses",
"BriefDescription": "This metric measures the ratio of L1 D-cache Read accesses missed to the total number of L1 D-cache accesses. This gives an indication of the effectiveness of the L1 D-cache for demand Load or Store traffic.",
"ScaleUnit": "1per cache access",
- "MetricGroup": "L1I_Prefetcher_Effectiveness"
+ "MetricGroup": "L1D_Prefetcher_Effectiveness"
},
{
"MetricName": "l1d_demand_accesses",
"MetricExpr": "L1D_CACHE_RW",
"BriefDescription": "This metric measures the count of L1 D-cache accesses incurred on Load or Store by the instruction stream of the program.",
"ScaleUnit": "1count",
- "MetricGroup": "L1I_Prefetcher_Effectiveness"
+ "MetricGroup": "L1D_Prefetcher_Effectiveness"
},
{
"MetricName": "l1d_demand_misses",
"MetricExpr": "L1D_CACHE_REFILL_RW",
"BriefDescription": "This metric measures the count of L1 D-cache misses incurred on a Load or Store by the instruction stream of the program.",
"ScaleUnit": "1count",
- "MetricGroup": "L1I_Prefetcher_Effectiveness"
+ "MetricGroup": "L1D_Prefetcher_Effectiveness"
},
{
"MetricName": "l1d_prf_accuracy",
"MetricExpr": "100 * (l1d_useful_prf / l1d_refilled_prf)",
"BriefDescription": "This metric measures the fraction of prefetched memory addresses that are used by the instruction stream.",
"ScaleUnit": "1percent of prefetch",
- "MetricGroup": "L1I_Prefetcher_Effectiveness"
+ "MetricGroup": "L1D_Prefetcher_Effectiveness"
},
{
"MetricName": "l1d_prf_coverage",
"MetricExpr": "100 * (l1d_useful_prf / (l1d_demand_misses + l1d_refilled_prf))",
"BriefDescription": "This metric measures the baseline demand cache misses which the prefetcher brings into the cache.",
"ScaleUnit": "1percent of cache access",
- "MetricGroup": "L1I_Prefetcher_Effectiveness"
+ "MetricGroup": "L1D_Prefetcher_Effectiveness"
},
{
"MetricName": "l1d_refilled_prf",
"MetricExpr": "L1D_CACHE_REFILL_HWPRF + L1D_CACHE_REFILL_PRFM + L1D_LFB_HIT_RW_FHWPRF + L1D_LFB_HIT_RW_FPRFM",
"BriefDescription": "This metric measures the count of cache lines refilled by L1 data prefetcher (hardware prefetches or software preload) into L1 D-cache.",
"ScaleUnit": "1count",
- "MetricGroup": "L1I_Prefetcher_Effectiveness"
+ "MetricGroup": "L1D_Prefetcher_Effectiveness"
},
{
"MetricName": "l1d_tlb_miss_ratio",
@@ -402,7 +402,7 @@
"MetricExpr": "L1D_CACHE_HIT_RW_FPRF + L1D_LFB_HIT_RW_FHWPRF + L1D_LFB_HIT_RW_FPRFM",
"BriefDescription": "This metric measures the count of cache lines refilled by L1 data prefetcher (hardware prefetches or software preload) into L1 D-cache which are further used by Load or Store from the instruction stream of the program.",
"ScaleUnit": "1count",
- "MetricGroup": "L1I_Prefetcher_Effectiveness"
+ "MetricGroup": "L1D_Prefetcher_Effectiveness"
},
{
"MetricName": "l1i_cache_miss_ratio",
@@ -423,42 +423,42 @@
"MetricExpr": "l1i_demand_misses / l1i_demand_accesses",
"BriefDescription": "This metric measures the ratio of L1 I-cache Read accesses missed to the total number of L1 I-cache accesses. This gives an indication of the effectiveness of the L1 I-cache for demand instruction fetch traffic. Note that cache accesses in this cache are demand instruction fetch.",
"ScaleUnit": "1per cache access",
- "MetricGroup": "L1D_Prefetcher_Effectiveness"
+ "MetricGroup": "L1I_Prefetcher_Effectiveness"
},
{
"MetricName": "l1i_demand_accesses",
"MetricExpr": "L1I_CACHE_RD",
"BriefDescription": "This metric measures the count of L1 I-cache accesses caused by an instruction fetch by the instruction stream of the program.",
"ScaleUnit": "1count",
- "MetricGroup": "L1D_Prefetcher_Effectiveness"
+ "MetricGroup": "L1I_Prefetcher_Effectiveness"
},
{
"MetricName": "l1i_demand_misses",
"MetricExpr": "L1I_CACHE_REFILL_RD",
"BriefDescription": "This metric measures the count of L1 I-cache misses caused by an instruction fetch by the instruction stream of the program.",
"ScaleUnit": "1count",
- "MetricGroup": "L1D_Prefetcher_Effectiveness"
+ "MetricGroup": "L1I_Prefetcher_Effectiveness"
},
{
"MetricName": "l1i_prf_accuracy",
"MetricExpr": "100 * (l1i_useful_prf / l1i_refilled_prf)",
"BriefDescription": "This metric measures the fraction of prefetched memory addresses that are used by the instruction stream.",
"ScaleUnit": "1percent of prefetch",
- "MetricGroup": "L1D_Prefetcher_Effectiveness"
+ "MetricGroup": "L1I_Prefetcher_Effectiveness"
},
{
"MetricName": "l1i_prf_coverage",
"MetricExpr": "100 * (l1i_useful_prf / (l1i_demand_misses + l1i_refilled_prf))",
"BriefDescription": "This metric measures the baseline demand cache misses which the prefetcher brings into the cache.",
"ScaleUnit": "1percent of cache access",
- "MetricGroup": "L1D_Prefetcher_Effectiveness"
+ "MetricGroup": "L1I_Prefetcher_Effectiveness"
},
{
"MetricName": "l1i_refilled_prf",
"MetricExpr": "L1I_CACHE_REFILL_HWPRF + L1I_CACHE_REFILL_PRFM",
"BriefDescription": "This metric measures the count of cache lines refilled by L1 instruction prefetcher (hardware prefetches or software preload) into L1 I-cache.",
"ScaleUnit": "1count",
- "MetricGroup": "L1D_Prefetcher_Effectiveness"
+ "MetricGroup": "L1I_Prefetcher_Effectiveness"
},
{
"MetricName": "l1i_tlb_miss_ratio",
@@ -479,7 +479,7 @@
"MetricExpr": "L1I_CACHE_HIT_RD_FPRF",
"BriefDescription": "This metric measures the count of cache lines refilled by L1 instruction prefetcher (hardware prefetches or software preload) into L1 I-cache which are further used by instruction stream of the program.",
"ScaleUnit": "1count",
- "MetricGroup": "L1D_Prefetcher_Effectiveness"
+ "MetricGroup": "L1I_Prefetcher_Effectiveness"
},
{
"MetricName": "l2_cache_miss_ratio",
--
2.47.3
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: imx53-ppd: add '#phy-cells' for usb-nop-xceiv
From: Frank Li @ 2026-05-11 21:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260511-b4-imx25_dts_simple_warning-v1-0-01b855a5ce25@nxp.com>
Add '#phy-cells' for usb-nop-xceiv to fix below check_dtbs warnings:
usbphy-2 (usb-nop-xceiv): '#phy-cells' is a required property
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx53-ppd.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-ppd.dts b/arch/arm/boot/dts/nxp/imx/imx53-ppd.dts
index e45a97d3f449de9a82ecd9171bcedb0f5f41346b..f0fb88c14171919ccdd68a90c453a5d2dbaa126d 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-ppd.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-ppd.dts
@@ -258,6 +258,7 @@ usbphy2: usbphy-2 {
clock-names = "main_clk";
clock-frequency = <24000000>;
clocks = <&clks IMX5_CLK_CKO2>;
+ #phy-cells = <0>;
assigned-clocks = <&clks IMX5_CLK_CKO2_SEL>, <&clks IMX5_CLK_OSC>;
assigned-clock-parents = <&clks IMX5_CLK_OSC>;
};
@@ -270,6 +271,7 @@ usbphy3: usbphy-3 {
clock-frequency = <24000000>;
clocks = <&clks IMX5_CLK_CKO2>;
+ #phy-cells = <0>;
assigned-clocks = <&clks IMX5_CLK_CKO2_SEL>, <&clks IMX5_CLK_OSC>;
assigned-clock-parents = <&clks IMX5_CLK_OSC>;
};
--
2.43.0
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: imx53-qsb: add dvdd and avdd supply for panel sii,43wvf1g
From: Frank Li @ 2026-05-11 21:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260511-b4-imx25_dts_simple_warning-v1-0-01b855a5ce25@nxp.com>
Add dvdd and avdd supply and regulators for panel sii,43wvf1g to fix below
check_dtbs warnings:
panel (sii,43wvf1g): 'dvdd-supply' is a required property
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi b/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi
index 1869ad86baf202098c6062c0f511358eeffb5c5a..d3b27dc3c2c7d2ab868a8a070a164af994ed30a9 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi
@@ -91,6 +91,8 @@ panel_dpi: panel {
pinctrl-0 = <&pinctrl_display_power>;
backlight = <&backlight_parallel>;
enable-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>;
+ dvdd-supply = <®_3p2v>;
+ avdd-supply = <®_5v>;
port {
panel_in: endpoint {
@@ -107,6 +109,14 @@ reg_3p2v: regulator-3p2v {
regulator-always-on;
};
+ reg_5v: regulator-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
reg_usb_vbus: regulator-usb-vbus {
compatible = "regulator-fixed";
regulator-name = "usb_vbus";
--
2.43.0
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: imx: add ti,deskew = <0> for ti,tfp410
From: Frank Li @ 2026-05-11 21:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260511-b4-imx25_dts_simple_warning-v1-0-01b855a5ce25@nxp.com>
Add required proprety ti,deskew for ti,tfp410, which have not defined
default value in yaml. 0 is default value according to
drivers/gpu/drm/bridge/ti-tfp410.c.
Fix below check_dtbs warning:
dvi-encoder (ti,tfp410): 'ti,deskew' is a required property
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx51-babbage.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts b/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts
index b17264e06e6916057c426179e4207c4a28acf1ab..a02e9cd0b3fa04efc4df49f8ad990515d5e81671 100644
--- a/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx51-babbage.dts
@@ -126,6 +126,7 @@ dvi_connector_in: endpoint {
dvi-encoder {
compatible = "ti,tfp410";
+ ti,deskew = <0>;
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts b/arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts
index 0814f5665a59c3a64c6023714a3b58230ac80dda..02be8b6da69619a5d33a7b1e964e951addefa676 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts
@@ -60,6 +60,7 @@ dvi_connector_in: endpoint {
dvi-converter {
compatible = "ti,tfp410";
+ ti,deskew = <0>;
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts b/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts
index c78f101c3cc122f418b708b1c274ca11b586b65c..6a6ef4a25d8dca7363a527aeea4ddcd81acd58bc 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts
@@ -61,6 +61,7 @@ aliases {
encoder {
compatible = "ti,tfp410";
+ ti,deskew = <0>;
ports {
#address-cells = <1>;
--
2.43.0
^ permalink raw reply related
* [PATCH 1/4] ARM: dts: imx6qdl-sabrelite: add mdio phy address 0
From: Frank Li @ 2026-05-11 21:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260511-b4-imx25_dts_simple_warning-v1-0-01b855a5ce25@nxp.com>
According to IEEE 802.3 Clause 22.2.4.5.5 PHYAD (PHY Address), A PHY that
is connected to the station management entity via the mechanical interface
defined in 22.6 shall always respond to transactions addressed to PHY
Address zero <00000>.
Use address 0 is safe because only one MDIO phy under mdio bus.
Fix below CHECK_DTBS warnings:
arm/boot/dts/nxp/imx/imx6dl-sabrelite.dtb: ethernet@2188000 (fsl,imx6q-fec): mdio: Unevaluated properties are not allowed ('ethernet-phy' was unexpected)
from schema $id: http://devicetree.org/schemas/net/fsl,fec.yaml
/home/lizhi/source/linux-upstream-pci/arch/arm/boot/dts/nxp/imx/imx6dl-sabrelite.dtb: ethernet-phy (ethernet-phy-ieee802.3-c22): 'reg' is a required property
from schema $id: http://devicetree.org/schemas/net/ethernet-phy.yaml
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi
index 3b7d01065e87b2587a87f97438eea205be3222f8..d936732db46f07806ca07de4353ff47fe26e23b6 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi
@@ -291,8 +291,9 @@ mdio {
#address-cells = <1>;
#size-cells = <0>;
- ethphy: ethernet-phy {
+ ethphy: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
txen-skew-ps = <0>;
txc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
--
2.43.0
^ permalink raw reply related
* [PATCH 0/4] ARM: dts: DTB_CHECK warning cleanup
From: Frank Li @ 2026-05-11 21:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Frank Li (4):
ARM: dts: imx6qdl-sabrelite: add mdio phy address 0
ARM: dts: imx: add ti,deskew = <0> for ti,tfp410
ARM: dts: imx53-qsb: add dvdd and avdd supply for panel sii,43wvf1g
ARM: dts: imx53-ppd: add '#phy-cells' for usb-nop-xceiv
arch/arm/boot/dts/nxp/imx/imx51-babbage.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx53-ppd.dts | 2 ++
arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi | 10 ++++++++++
arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx6qdl-sabrelite.dtsi | 3 ++-
6 files changed, 17 insertions(+), 1 deletion(-)
---
base-commit: 6920bef1402681e36b9c09e9aff8a860b0b54ccd
change-id: 20260511-b4-imx25_dts_simple_warning-e29b7a077b31
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH] clk: rockchip: Use flexible array for clock table
From: Brian Masney @ 2026-05-11 20:41 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Michael Turquette, Stephen Boyd, Heiko Stuebner,
moderated list:ARM/Rockchip SoC support,
open list:ARM/Rockchip SoC support, open list,
Gustavo A. R. Silva
In-Reply-To: <CAKxU2N-nEx-=KFh9djQRGZVTR_HJTSrJYzAa8NR+4QcNvbkxqw@mail.gmail.com>
+ Gustavo
On Mon, May 11, 2026 at 12:08:56PM -0700, Rosen Penev wrote:
> On Mon, May 11, 2026 at 9:06 AM Brian Masney <bmasney@redhat.com> wrote:
> >
> > Hi Rosen,
> >
> > On Sun, May 10, 2026 at 08:22:52PM -0700, Rosen Penev wrote:
> > > Store the clock lookup table in the Rockchip clock provider
> > > allocation instead of allocating it separately.
> > >
> > > This ties the table lifetime directly to the provider and removes a
> > > separate allocation failure path while preserving the clk_onecell_data
> > > lookup interface.
> > >
> > > Assisted-by: Codex:GPT-5.5
> > > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > > ---
> > > drivers/clk/rockchip/clk.c | 17 ++++-------------
> > > drivers/clk/rockchip/clk.h | 2 ++
> > > 2 files changed, 6 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
> > > index ee8c79b938d3..dbb4b6f33abb 100644
> > > --- a/drivers/clk/rockchip/clk.c
> > > +++ b/drivers/clk/rockchip/clk.c
> > > @@ -359,26 +359,21 @@ static struct rockchip_clk_provider *rockchip_clk_init_base(
> > > unsigned long nr_clks, bool has_late_clocks)
> > > {
> > > struct rockchip_clk_provider *ctx;
> > > - struct clk **clk_table;
> > > struct clk *default_clk_val;
> > > int i;
> > >
> > > default_clk_val = ERR_PTR(has_late_clocks ? -EPROBE_DEFER : -ENOENT);
> > >
> > > - ctx = kzalloc_obj(struct rockchip_clk_provider);
> > > + ctx = kzalloc_flex(*ctx, clk_table, nr_clks);
> > > if (!ctx)
> > > return ERR_PTR(-ENOMEM);
> > >
> > > - clk_table = kzalloc_objs(struct clk *, nr_clks);
> > > - if (!clk_table)
> > > - goto err_free;
> > > -
> > > for (i = 0; i < nr_clks; ++i)
> > > - clk_table[i] = default_clk_val;
> > > + ctx->clk_table[i] = default_clk_val;
> > >
> > > - ctx->reg_base = base;
> > > - ctx->clk_data.clks = clk_table;
> > > ctx->clk_data.clk_num = nr_clks;
> > > + ctx->clk_data.clks = ctx->clk_table;
> >
> > Where's the __counted_by? Also struct clk_onecell_data is embedded
> > inside struct rockchip_clk_provider, and I'm not sure offhand how
> > that'll work.
> Not present. __counted_by does not work with embedded struct members.
> No need to add one IMO.
I'll be honest that I'm not sure what's correct here. I added Gustavo
since I saw comments from him before about these types of changes.
Brian
^ permalink raw reply
* Re: [PATCH v6 0/7] pinctrl: Add generic pinctrl for board-level mux chips
From: Linus Walleij @ 2026-05-11 20:34 UTC (permalink / raw)
To: Frank Li
Cc: Peter Rosin, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-kernel, linux-gpio, devicetree, imx,
linux-arm-kernel, Haibo Chen, Conor Dooley, Ahmad Fatoum
In-Reply-To: <agIwOYrKXlnKbpII@lizhi-Precision-Tower-5810>
On Mon, May 11, 2026 at 9:38 PM Frank Li <Frank.li@nxp.com> wrote:
> I fixed a build warning by missing doc 'np',
> https://lore.kernel.org/imx/20260507152117.240612-1-Frank.Li@nxp.com/
>
> Anything need me to do futher?
Sorry was busy!
Applied this fixup on top of the branch and merged it into my
devel branch for v7.2!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 0/2] pinctrl: add support amlogic a9
From: Linus Walleij @ 2026-05-11 20:26 UTC (permalink / raw)
To: xianwei.zhao
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, linux-amlogic,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260507-a9-pinctrl-v2-0-49774feff2ef@amlogic.com>
On Thu, May 7, 2026 at 10:21 AM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
> Add pinctrl bindings and driver about for amlogic a9.
>
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Patches applied!
Yours,
Linus Walleij
^ permalink raw reply
* [soc:soc/dt] BUILD SUCCESS b133e22edd5c4d43398b0656063457e7ccf32778
From: kernel test robot @ 2026-05-11 20:24 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/dt
branch HEAD: b133e22edd5c4d43398b0656063457e7ccf32778 ARM: dts: ixp4xx: use phandle-based GPIOs in mi424wr
elapsed time: 726m
configs tested: 267
configs skipped: 134
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260511 gcc-10.5.0
arc randconfig-002-20260511 gcc-10.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260511 gcc-10.5.0
arm randconfig-002-20260511 gcc-10.5.0
arm randconfig-003-20260511 gcc-10.5.0
arm randconfig-004-20260511 gcc-10.5.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260511 clang-17
arm64 randconfig-001-20260511 clang-23
arm64 randconfig-001-20260512 gcc-14.3.0
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260511 clang-17
arm64 randconfig-002-20260511 clang-23
arm64 randconfig-002-20260512 gcc-14.3.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260511 clang-17
arm64 randconfig-003-20260511 clang-23
arm64 randconfig-003-20260512 gcc-14.3.0
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260511 clang-17
arm64 randconfig-004-20260511 clang-23
arm64 randconfig-004-20260512 gcc-14.3.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001 clang-23
csky randconfig-001-20260511 clang-17
csky randconfig-001-20260511 clang-23
csky randconfig-001-20260512 gcc-14.3.0
csky randconfig-002 clang-23
csky randconfig-002-20260511 clang-17
csky randconfig-002-20260511 clang-23
csky randconfig-002-20260512 gcc-14.3.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260511 gcc-8.5.0
hexagon randconfig-001-20260512 gcc-10.5.0
hexagon randconfig-002-20260511 gcc-8.5.0
hexagon randconfig-002-20260512 gcc-10.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260511 gcc-14
i386 buildonly-randconfig-002-20260511 gcc-14
i386 buildonly-randconfig-003-20260511 gcc-14
i386 buildonly-randconfig-004-20260511 gcc-14
i386 buildonly-randconfig-005-20260511 gcc-14
i386 buildonly-randconfig-006-20260511 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260511 gcc-12
i386 randconfig-002-20260511 gcc-12
i386 randconfig-003-20260511 gcc-12
i386 randconfig-004-20260511 gcc-12
i386 randconfig-005-20260511 gcc-12
i386 randconfig-006-20260511 gcc-12
i386 randconfig-007-20260511 gcc-12
i386 randconfig-011 clang-20
i386 randconfig-011-20260511 clang-20
i386 randconfig-011-20260512 clang-20
i386 randconfig-012 clang-20
i386 randconfig-012-20260511 clang-20
i386 randconfig-012-20260512 clang-20
i386 randconfig-013 clang-20
i386 randconfig-013-20260511 clang-20
i386 randconfig-013-20260512 clang-20
i386 randconfig-014 clang-20
i386 randconfig-014-20260511 clang-20
i386 randconfig-014-20260512 clang-20
i386 randconfig-015 clang-20
i386 randconfig-015-20260511 clang-20
i386 randconfig-015-20260512 clang-20
i386 randconfig-016 clang-20
i386 randconfig-016-20260511 clang-20
i386 randconfig-016-20260512 clang-20
i386 randconfig-017 clang-20
i386 randconfig-017-20260511 clang-20
i386 randconfig-017-20260512 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260511 gcc-8.5.0
loongarch randconfig-001-20260512 gcc-10.5.0
loongarch randconfig-002-20260511 gcc-8.5.0
loongarch randconfig-002-20260512 gcc-10.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips jazz_defconfig clang-17
mips maltaup_xpa_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260511 gcc-8.5.0
nios2 randconfig-001-20260512 gcc-10.5.0
nios2 randconfig-002-20260511 gcc-8.5.0
nios2 randconfig-002-20260512 gcc-10.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001 clang-20
parisc randconfig-001-20260511 clang-20
parisc randconfig-002 clang-20
parisc randconfig-002-20260511 clang-20
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc arches_defconfig gcc-15.2.0
powerpc randconfig-001 clang-20
powerpc randconfig-001-20260511 clang-20
powerpc randconfig-002 clang-20
powerpc randconfig-002-20260511 clang-20
powerpc64 randconfig-001 clang-20
powerpc64 randconfig-001-20260511 clang-20
powerpc64 randconfig-002 clang-20
powerpc64 randconfig-002-20260511 clang-20
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001 gcc-12.5.0
riscv randconfig-001-20260511 gcc-12.5.0
riscv randconfig-001-20260512 gcc-15.2.0
riscv randconfig-002 gcc-12.5.0
riscv randconfig-002-20260511 gcc-12.5.0
riscv randconfig-002-20260512 gcc-15.2.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001 gcc-12.5.0
s390 randconfig-001-20260511 gcc-12.5.0
s390 randconfig-001-20260512 gcc-15.2.0
s390 randconfig-002 gcc-12.5.0
s390 randconfig-002-20260511 gcc-12.5.0
s390 randconfig-002-20260512 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001 gcc-12.5.0
sh randconfig-001-20260511 gcc-12.5.0
sh randconfig-001-20260512 gcc-15.2.0
sh randconfig-002 gcc-12.5.0
sh randconfig-002-20260511 gcc-12.5.0
sh randconfig-002-20260512 gcc-15.2.0
sh se7751_defconfig gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001 gcc-8.5.0
sparc randconfig-001-20260511 gcc-8.5.0
sparc randconfig-002 gcc-8.5.0
sparc randconfig-002-20260511 gcc-8.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-8.5.0
sparc64 randconfig-001-20260511 gcc-8.5.0
sparc64 randconfig-002 gcc-8.5.0
sparc64 randconfig-002-20260511 gcc-8.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 gcc-8.5.0
um randconfig-001-20260511 gcc-8.5.0
um randconfig-002 gcc-8.5.0
um randconfig-002-20260511 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001 gcc-14
x86_64 buildonly-randconfig-001-20260511 gcc-14
x86_64 buildonly-randconfig-001-20260512 gcc-14
x86_64 buildonly-randconfig-002 gcc-14
x86_64 buildonly-randconfig-002-20260511 gcc-14
x86_64 buildonly-randconfig-002-20260512 gcc-14
x86_64 buildonly-randconfig-003 gcc-14
x86_64 buildonly-randconfig-003-20260511 gcc-14
x86_64 buildonly-randconfig-003-20260512 gcc-14
x86_64 buildonly-randconfig-004 gcc-14
x86_64 buildonly-randconfig-004-20260511 gcc-14
x86_64 buildonly-randconfig-004-20260512 gcc-14
x86_64 buildonly-randconfig-005 gcc-14
x86_64 buildonly-randconfig-005-20260511 gcc-14
x86_64 buildonly-randconfig-005-20260512 gcc-14
x86_64 buildonly-randconfig-006 gcc-14
x86_64 buildonly-randconfig-006-20260511 gcc-14
x86_64 buildonly-randconfig-006-20260512 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001 clang-20
x86_64 randconfig-001-20260511 clang-20
x86_64 randconfig-001-20260512 gcc-14
x86_64 randconfig-002 clang-20
x86_64 randconfig-002-20260511 clang-20
x86_64 randconfig-002-20260512 gcc-14
x86_64 randconfig-003 clang-20
x86_64 randconfig-003-20260511 clang-20
x86_64 randconfig-003-20260512 gcc-14
x86_64 randconfig-004 clang-20
x86_64 randconfig-004-20260511 clang-20
x86_64 randconfig-004-20260512 gcc-14
x86_64 randconfig-005 clang-20
x86_64 randconfig-005-20260511 clang-20
x86_64 randconfig-005-20260512 gcc-14
x86_64 randconfig-006 clang-20
x86_64 randconfig-006-20260511 clang-20
x86_64 randconfig-006-20260512 gcc-14
x86_64 randconfig-011 clang-20
x86_64 randconfig-011-20260511 clang-20
x86_64 randconfig-012 clang-20
x86_64 randconfig-012-20260511 clang-20
x86_64 randconfig-013 clang-20
x86_64 randconfig-013-20260511 clang-20
x86_64 randconfig-014 clang-20
x86_64 randconfig-014-20260511 clang-20
x86_64 randconfig-015 clang-20
x86_64 randconfig-015-20260511 clang-20
x86_64 randconfig-016 clang-20
x86_64 randconfig-016-20260511 clang-20
x86_64 randconfig-071-20260511 clang-20
x86_64 randconfig-072-20260511 clang-20
x86_64 randconfig-073-20260511 clang-20
x86_64 randconfig-074-20260511 clang-20
x86_64 randconfig-075-20260511 clang-20
x86_64 randconfig-076-20260511 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa iss_defconfig gcc-15.2.0
xtensa randconfig-001 gcc-8.5.0
xtensa randconfig-001-20260511 gcc-8.5.0
xtensa randconfig-002 gcc-8.5.0
xtensa randconfig-002-20260511 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] arm64: Implement _THIS_IP_ using inline asm
From: Marco Elver @ 2026-05-11 20:16 UTC (permalink / raw)
To: elver, Catalin Marinas, Will Deacon
Cc: Thomas Huth, Nathan Chancellor, Kees Cook, Vlastimil Babka,
Harry Yoo, linux-arm-kernel, linux-kernel, kasan-dev
Both GCC [1] and Clang [2] consider the generic version of _THIS_IP_ to
be broken:
#define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; })
In particular, the address of a label is only expected to be used with a
computed goto.
While the generic version more or less works today, it is known to be
brittle and may break with current and future optimizations. For
example, Clang -O2 always returns 1 when this function is inlined:
static inline unsigned long get_ip(void)
{ return ({ __label__ __here; __here: (unsigned long)&&__here; }); }
Fix it by overriding _THIS_IP_ in <asm/linkage.h> (which is included by
<linux/instruction_pointer.h>) using an architecture-specific inline asm
version. Additionally, avoiding taking the address of a label prevents
compilers from emitting spurious indirect branch targets (e.g. ENDBR or
BTI) under control-flow integrity schemes.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120071 [1]
Link: https://github.com/llvm/llvm-project/issues/138272 [2]
Signed-off-by: Marco Elver <elver@google.com>
---
arch/arm64/include/asm/linkage.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/linkage.h b/arch/arm64/include/asm/linkage.h
index 40bd17add539..73eabc82a6bb 100644
--- a/arch/arm64/include/asm/linkage.h
+++ b/arch/arm64/include/asm/linkage.h
@@ -43,4 +43,6 @@
SYM_TYPED_START(name, SYM_L_GLOBAL, SYM_A_ALIGN) \
bti c ;
+#define _THIS_IP_ ({ unsigned long __ip; asm volatile("adr %0, ." : "=r" (__ip)); __ip; })
+
#endif
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* Re: [PATCH v5 4/9] dt-bindings: pinctrl: mediatek,mt65xx: Add MT6392 pinctrl
From: Linus Walleij @ 2026-05-11 20:12 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, AngeloGioacchino Del Regno, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Liam Girdwood, Mark Brown, Louis-Alexis Eyraud, Gary Bisson,
Val Packett, Julien Massot, Fabien Parent, Akari Tsuyukusa,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260420213529.1645560-5-l.scorcia@gmail.com>
On Mon, Apr 20, 2026 at 11:37 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
> Add a compatible for the pinctrl device of the MT6392 PMIC, a variant of
> the already supported MT6397.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
This patch 4/9 applied to the pinctrl tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctrl: mediatek: mt8188: allow gpio hogs
From: Linus Walleij @ 2026-05-11 20:10 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Hui Liu, linux-gpio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260504072748.2580172-1-zhengxingda@iscas.ac.cn>
On Mon, May 4, 2026 at 9:28 AM Icenowy Zheng <zhengxingda@iscas.ac.cn> wrote:
> Add gpio hogs subnode rules to the MT8188 pinctrl binding.
>
> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
This patch 1/2 applied to the pinctrl tree.
Please funnel patch 2/2 through the SoC tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v9 0/3] pinctrl: aspeed: Add AST2700 SoC0 support
From: Linus Walleij @ 2026-05-11 20:05 UTC (permalink / raw)
To: Billy Tsai
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Bartosz Golaszewski, Ryan Chen,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, openbmc, linux-gpio, linux-clk
In-Reply-To: <20260506-upstream_pinctrl-v9-0-0636e22343ad@aspeedtech.com>
On Wed, May 6, 2026 at 10:12 AM Billy Tsai <billy_tsai@aspeedtech.com> wrote:
> AST2700 is composed of two interconnected SoC instances, each providing
> its own pin control hardware. This series introduces bindings describing
> the AST2700 pinctrl architecture and adds pinctrl driver support for the
> SoC0 instance.
>
> The bindings document the AST2700 dual-SoC design and follow common
> pinctrl conventions, while the SoC0 driver implementation builds upon
> the existing ASPEED pinctrl infrastructure.
Patch applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v9 2/3] dt-bindings: mfd: aspeed,ast2x00-scu: Describe AST2700 SCU0
From: Linus Walleij @ 2026-05-11 20:04 UTC (permalink / raw)
To: Billy Tsai
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Bartosz Golaszewski, Ryan Chen,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, openbmc, linux-gpio, linux-clk
In-Reply-To: <20260506-upstream_pinctrl-v9-2-0636e22343ad@aspeedtech.com>
On Wed, May 6, 2026 at 10:07 AM Billy Tsai <billy_tsai@aspeedtech.com> wrote:
> AST2700 consists of two interconnected SoC instances, each with its own
> System Control Unit (SCU). The SCU0 provides pin control, interrupt
> controllers, clocks, resets, and address-space mappings for the
> Secondary and Tertiary Service Processors (SSP and TSP).
>
> Describe the SSP/TSP address mappings using the standard
> memory-region and memory-region-names properties.
>
> Disallow legacy child nodes that are not present on AST2700, including
> p2a-control and smp-memram. The latter is unnecessary as software can
> access the scratch registers via the SCU syscon.
>
> Also allow the AST2700 SoC0 pin controller to be described as a child
> node of the SCU0, and add an example illustrating the SCU0 layout,
> including reserved-memory, interrupt controllers, and pinctrl.
>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
This is an MFD patch in the middle of a pinctrl series, I think Lee
should apply this.
FWIW:
Acked-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox