* Re: [PATCH 4/8] arm64: dts: qcom: kaanapali: Add qfprom node
From: Dmitry Baryshkov @ 2026-05-13 16:52 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sean Paul,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm,
freedreno, dri-devel, Jingyi Wang
In-Reply-To: <20260512-kaana-gpu-dt-v1-4-13e1c07c2050@oss.qualcomm.com>
On Tue, May 12, 2026 at 03:53:18AM +0530, Akhil P Oommen wrote:
> From: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>
> Add the qfprom node and gpu related subnodes on Kaanapali SoC.
QFPROM, GPU
With that fixed:
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kaanapali.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 5/8] arm64: dts: qcom: Add GPU support for Kaanapali
From: Dmitry Baryshkov @ 2026-05-13 16:53 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sean Paul,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm,
freedreno, dri-devel
In-Reply-To: <20260512-kaana-gpu-dt-v1-5-13e1c07c2050@oss.qualcomm.com>
On Tue, May 12, 2026 at 03:53:19AM +0530, Akhil P Oommen wrote:
> Adreno 840 present in Kaanapali SoC is the second generation GPU in
> A8x family. It is based on the new slice architecture with 3 slices,
> higher GMEM/caches etc.
>
> There is some re-arrangement in the reglist to properly cover maximum
> register region. Other than this, the DT description is mostly similar
> to the existing chipsets except the OPP tables.
>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kaanapali.dtsi | 232 ++++++++++++++++++++++++++++++++
> 1 file changed, 232 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub
From: Aneesh Kumar K.V @ 2026-05-13 16:53 UTC (permalink / raw)
To: Greg KH
Cc: Catalin Marinas, linux-kernel, linux-arm-kernel, Jeremy Linton,
Jonathan Cameron, Lorenzo Pieralisi, Mark Rutland, Sudeep Holla,
Will Deacon, Jonathan Cameron, Suzuki K Poulose
In-Reply-To: <2026051316-confidant-turtle-1e84@gregkh>
Greg KH <gregkh@linuxfoundation.org> writes:
> On Wed, May 13, 2026 at 02:23:01PM +0530, Aneesh Kumar K.V wrote:
>> Greg KH <gregkh@linuxfoundation.org> writes:
>>
>> > On Wed, May 13, 2026 at 12:28:12PM +0530, Aneesh Kumar K.V wrote:
>> >> Catalin Marinas <catalin.marinas@arm.com> writes:
>> >>
>> >> > + Suzuki again
>> >> >
>> >> > On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
>> >> >> The SMCCC firmware driver now creates the `arm-smccc` platform device
>> >> >> and also creates the CCA auxiliary devices once the RSI ABI is
>> >> >> discovered. This makes the arch-specific arm64_create_dummy_rsi_dev()
>> >> >> helper redundant. Remove the arm-cca-dev platform device registration
>> >> >> and let the SMCCC probe manage the RSI device.
>> >> >>
>> >> >> systemd match on platform:arm-cca-dev for confidential vm detection [1].
>> >> >> Losing the platform device registration can break that. Keeping this
>> >> >> removal in its own change makes it easy to revert if that regression
>> >> >> blocks the rollout.
>> >> >>
>> >> >> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>> >> >
>> >> > I wouldn't merge this now given that systemd checks this file. Could we
>> >> > have a symbolic link instead for some time until systemd eventually gets
>> >> > updated (years?).
>> >> >
>> >>
>> >> I’ll add this in the next revision.
>> >>
>> >> static int create_rsi_compat_link(struct device *target_dev)
>> >> {
>> >> struct kobject *platform_kobj;
>> >> /*
>> >> * target_dev is:
>> >> * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
>> >> * Create compat link /sys/devices/platform/arm-cca-dev
>> >> */
>> >> platform_kobj = target_dev->kobj.parent->parent;
>> >
>> > What? That is crazy, you don't know that is always going to be ok.
>> >
>> >> return sysfs_create_link(platform_kobj,
>> >> &target_dev->kobj,
>> >> "arm-cca-dev");
>> >
>> > No, don't do that, if a driver calls a sysfs* function, something is
>> > almost always wrong. Don't be making random sysfs symlinks please.
>> >
>>
>> Sure, but could you explain why this is wrong? Below is the full version
>> of the updated patch.
>>
>> coco: guest: arm64 Replace RSI platform device with compat symlink
>>
>> The SMCCC firmware driver now creates the arm-smccc platform device and
>> registers the RSI device as an auxiliary device once the RSI ABI has been
>> discovered. This makes the arch-specific arm64 arm-cca-dev platform device
>> redundant.
>>
>> Remove the arm64 platform device stub and let the SMCCC core manage RSI
>> device creation.
>>
>> This changes the real device location from the old platform device path to:
>>
>> /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
>>
>> Keep userspace compatibility by creating a sysfs symlink at the old path:
>>
>> /sys/devices/platform/arm-cca-dev
>>
>> A Debian Code Search check found systemd matching on the old
>> platform:arm-cca-dev device path for confidential VM detection. No other
>> userspace dependency on the old platform device path was found, but keeping
>> the compatibility symlink avoids breaking existing systemd-based detection
>> [1].
>>
>> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>
> Don't attempt to put symlinks between random devices in sysfs, that way
> lies madness and you will never get anything fixed.
>
> Just fix userspace, it shouldn't have hard-coded a device path in the
> first place, and you are thinking it would now use a different
> hard-coded device path? Please do this properly.
>
> Again, there should never be any hard-coded device paths, they are free
> to move around and be renamed at any time. Use the correct apis instead
> (walking all bus devices, looking at userspace attributes of classes,
> etc.)
>
> So your patch is ok, if you remove the symlink stuff.
>
How about adding /sys/firmware/cca/realm_guest? This would be similar to
/sys/firmware/uv/prot_virt_guest, which is provided on s390.
-aneesh
^ permalink raw reply
* Re: [PATCH v5 16/29] media: rockchip: rga: split flip and rotate into separate function
From: Nicolas Dufresne @ 2026-05-13 16:54 UTC (permalink / raw)
To: Sven Püschel, Jacob Chen, Ezequiel Garcia,
Mauro Carvalho Chehab, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil, Philipp Zabel
Cc: linux-media, linux-rockchip, linux-arm-kernel, linux-kernel,
devicetree, kernel, sebastian.reichel
In-Reply-To: <aeff9412-1c69-469d-bee3-7b9efa9b3947@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]
Le mercredi 13 mai 2026 à 16:29 +0200, Sven Püschel a écrit :
> Philipp Zabel just mentioned that a 90 degree rotation would just cause
> the RGA to scale it to the output format (deforming if it isn't
> quadratic). The existing code already considers the rotation to set the
> scaling factor accordingly (which I've also missed in this commit. But
> the commit is dropped anyways in v6 due to the various footguns).
>
> While I see that the V4L2_CID_ROTATE docs mention the need to set the
> format according to the chosen rotation, it feels like it's intended for
> non-scaling converters. So I don't see a problem to just allow the
> current state, as the user has to adjust the format anyways if he isn't
> interested in a deformed image (instead of blocking this potential rare
> use-case).
>
> But I'd add a check in my scaling commit to also check in the streaming
> state that we don't set a 90 degree rotation causing the scaling factor
> to be exceeded (e.g. 1x2 -> 1x32 scales by 16, whereas 90 degree
> rotation causes a scaling factor of 32).
Ok, didn't think it would just break aspect ratio to make it fit, but it means
its valid for this HW.
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Mathieu Poirier @ 2026-05-13 16:34 UTC (permalink / raw)
To: 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: <13140ca1-b4bc-4acc-9f7c-d23490e56dbb@amd.com>
On Tue, 12 May 2026 at 11:20, Shah, Tanmay <tanmays@amd.com> wrote:
>
>
>
> On 5/12/2026 10:41 AM, Mathieu Poirier wrote:
> > On Mon, May 11, 2026 at 04:35:46PM -0500, Shah, Tanmay wrote:
> >>
> >>
> >> 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 there are multiple GPIO controllers then yes, there will be more than one
> > endpoint. At this time I do now want to condiser other bus architectures (i2c,
> > spi, ...) to avoid muddying an already difficult conversation.
> >
> >>
> >> 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:
> >
> > I do not understand what you mean by "per device" - please be more specific.
> >
>
> "per device" I mean, per rpmsg device/channel. In our case that would be
> per gpio-controller.
>
> >>
> >> 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.
> >
> > There is no address space to consider since there is no GPIO controller memory
> > space to access. All that is done by the driver (remote processor) and
> > completely hidden from Linux by rpmsg-virtio-gpio.
> >
>
> So IMHO the dt-binding is the representation of the device hardware and
> is independent of how driver will access it. Any gpio-controller device
> node, we are just representing how gpio-controller hardware on the
> remote side looks like, and what is the corresponding view of the linux is.
>
> The rpmsg-gpio driver is different than the platform gpio controller
> driver mainly in two ways:
>
> 1) How the driver is probed: rpmsg-gpio driver will be probed when
> corresponding rpmsg channel/device name-service announcment will happen
> from the remote side.
>
I agree.
> 2) The GPIO Ops are not performed on the hardware directly, but it's
> done via rpmsg commands on the remote side.
>
I agree.
> However, the GPIO controller hardware remains the same. So bindings
> shoudln't change.
>
That is where I have a different point of view. There is no need to
have information in the bindings the kernel won't use. We are
advertizing virtio-gpio devices and as such should use virtio-gpio
bindings. The only thing that changes is the transport method, i.e,
encapsulated in RPMSG rather than directly over virtqueues.
> IMHO That means, if I want to move any existing GPIO-controller to the
> remote side, and want the rpmsg-gpio driver to handle it then, all I
> need to change is the compatible string of the current gpio-controller
> device node. The rest of the address space should remain the same, and
> leave ranges property empty. If the remote core has different view of
> the address space, then the device should contain remote's view and
> parent bus (rpmsg-io bus) should provide linux view via 'ranges' property.
>
> That is just the device hw representation in the device-tree as rpmsg
> device. Same for any other type of the controller: i2c, spi etc.
>
> Thanks,
> Tanmay
>
>
> >>
> >> 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
* [PATCH] arm64: mm: drop redundant remap of FDT first page
From: Sang-Heon Jeon @ 2026-05-13 17:01 UTC (permalink / raw)
To: catalin.marinas, will; +Cc: linux-arm-kernel, Sang-Heon Jeon
fixmap_remap_fdt() calls create_mapping_noalloc() to map the first
page of the FDT to read its magic and totalsize from the header. If
the FDT does not fit in a single page, it calls create_mapping_noalloc()
again to map the rest.
The second mapping redundantly covers the first page that was just
mapped by the first mapping.
Start the second mapping at dt_phys_base + PAGE_SIZE so it only covers
the pages that have not been mapped yet. No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
---
QEMU-based test results
$ qemu-system-aarch64 -M virt -singlestep -d nochain,exec ...
Count log lines from fixmap_remap_fdt() entry to return
- entry PC : address of the <fixmap_remap_fdt> symbol
- return PC : next address of each bl ... <fixmap_remap_fdt>
1) AS-IS
- 1st call (KERNEL) : 4935
- 2nd call (KERNEL_RO) : 14151
2) TO-BE
- 1st call : 4888
- 2nd call : 14104
---
Hello,
While looking into boot information, I found a minor cleanup point.
If I misunderstood anything, please feel free to let me know.
Thank you for taking valuable time to review this work.
Best Regards,
Sang-Heon Jeon
---
arch/arm64/mm/fixmap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
index c5c5425791da..f8aea5572f7c 100644
--- a/arch/arm64/mm/fixmap.c
+++ b/arch/arm64/mm/fixmap.c
@@ -167,8 +167,9 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
return NULL;
if (offset + *size > PAGE_SIZE) {
- create_mapping_noalloc(dt_phys_base, dt_virt_base,
- offset + *size, prot);
+ create_mapping_noalloc(dt_phys_base + PAGE_SIZE,
+ dt_virt_base + PAGE_SIZE,
+ offset + *size - PAGE_SIZE, prot);
}
return dt_virt;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA
From: Joonwon Kang @ 2026-05-13 17:03 UTC (permalink / raw)
To: jgg
Cc: Alexander.Grest, amhetre, baolu.lu, easwar.hariharan, iommu,
jacob.jun.pan, joonwonkang, joro, jpb, kees, kevin.tian,
linux-arm-kernel, linux-kernel, nicolinc, praan, robin.murphy,
smostafa, will
In-Reply-To: <20260512151133.GD7702@ziepe.ca>
> On Tue, May 12, 2026 at 02:51:38PM +0000, Joonwon Kang wrote:
>
> > Appreciate all your clarifications here. So, my understanding is that if
> > our system does not support ST64BV and ST64BV0 or if our device does not
> > distinguish between the posted write and the non-posted write regarding
> > PASID, then we can lift the use of the global PASID space. Can I say this?
>
> You should do what Robin said - just have your driver use a per-device
> PASID that it allocates and never use the global pasid allocator.
>
> To do this lightly re-organize the SVA code so the driver can supply
> its own PASID, and in this mode we wouldn't activate the ENQCMD
> features in the mm.
Ah, we could actively disallow EL0 to execute ENQCMD-like instructions
when the device driver explicitly shows the intention via a new API like
`iommu_sva_bind_device_pasid()` that Tian mentioned earlier. And the new
API only uses the per-device PASID space. It makes a lot of sense. It also
means that ENQCMD-like instructions are only allowed when the PASID is
allocated from the global PASID space.
If a process communicates with only one device with the PASID allocated
from the per-device PASID space, however, there should be no blocker for
the process to execute ENQCMD-like instructions, technically speaking. In
this case, should we allow the process to execute them? and later if the
process tries to allocate another PASID for another device, should we
disallow the instruction execution then? I guess this way may complicate
the implementation without much benefit, though.
To allocate a per-device PASID, I think we should do it using
`dev->iommu_group->pasid_array` instead of making the device driver
create its own PASID set since all the devices in the same `iommu_group`
are supposed to share the same PASID space.
Will create a new patch with the establishment so far.
Thanks,
Joonwon Kang
^ permalink raw reply
* Re: [PATCH RESEND v29 1/4] dt-bindings: i2c: Split AST2600 binding into a new YAML
From: Rob Herring (Arm) @ 2026-05-13 17:05 UTC (permalink / raw)
To: Ryan Chen
Cc: Joel Stanley, openbmc, Benjamin Herrenschmidt, Rayn Chen,
linux-i2c, Andrew Jeffery, Conor Dooley, devicetree, linux-aspeed,
linux-kernel, Krzysztof Kozlowski, Philipp Zabel, jk,
andriy.shevchenko, linux-arm-kernel, Andi Shyti
In-Reply-To: <20260513-upstream_i2c-v29-1-fe9926964d55@aspeedtech.com>
On Wed, 13 May 2026 13:32:00 +0800, Ryan Chen wrote:
> The AST2600 I2C controller introduces a completely new register layout
> with separate controller and target register blocks, unlike the mixed
> register layout used by AST2400/AST2500.
>
> Move AST2600 I2C binding from aspeed,i2c.yaml to a dedicated
> aspeed,ast2600-i2c.yaml schema.
>
> Besides the split, this also adjusts for AST2600-specific requirements.
> - require two reg regions (controller register block + buffer block)
> - use clock-frequency for bus speed description
> - interrupts are required on AST2600
> - use correct DTS coding style in example
>
> No compatible strings are changed.
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> ---
> Changes in v26:
> - commit message: include details of changes from original binding
> - fix example property ordering to follow DTS coding style
> - use consistent "AST2600" naming
> ---
> .../bindings/i2c/aspeed,ast2600-i2c.yaml | 62 ++++++++++++++++++++++
> .../devicetree/bindings/i2c/aspeed,i2c.yaml | 3 +-
> 2 files changed, 63 insertions(+), 2 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH RESEND v29 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs properties
From: Rob Herring (Arm) @ 2026-05-13 17:05 UTC (permalink / raw)
To: Ryan Chen
Cc: Joel Stanley, devicetree, Krzysztof Kozlowski,
Benjamin Herrenschmidt, jk, Andi Shyti, linux-i2c, Conor Dooley,
linux-arm-kernel, Andrew Jeffery, Rayn Chen, openbmc,
linux-kernel, Philipp Zabel, linux-aspeed, andriy.shevchenko
In-Reply-To: <20260513-upstream_i2c-v29-2-fe9926964d55@aspeedtech.com>
On Wed, 13 May 2026 13:32:01 +0800, Ryan Chen wrote:
> Add the aspeed,global-regs phandle to reference the AST2600 global
> registers syscon node, containing the SoC-common I2C register set.
>
> These properties apply only to the AST2600 binding. Legacy DTs remain
> unchanged.
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> ---
> Changes in v29:
> - remove aspeed,enable-dma properties.
>
> Changes in v28:
> - update commit message correspond with aspeed,enable-dma.
> - remove aspeed,transfer-mode and add aspeed,enable-dma property and
> description.
> - Fix aspeed,enable-dma description to reflect hardware capability rather
> than software behavior
>
> Changes in v27:
> - change aspeed,transfer-mode to aspeed,enable-dma.
> ---
> Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA
From: Jason Gunthorpe @ 2026-05-13 17:10 UTC (permalink / raw)
To: Joonwon Kang
Cc: Alexander.Grest, amhetre, baolu.lu, easwar.hariharan, iommu,
jacob.jun.pan, joro, jpb, kees, kevin.tian, linux-arm-kernel,
linux-kernel, nicolinc, praan, robin.murphy, smostafa, will
In-Reply-To: <20260513170333.1235601-1-joonwonkang@google.com>
On Wed, May 13, 2026 at 05:03:33PM +0000, Joonwon Kang wrote:
> > On Tue, May 12, 2026 at 02:51:38PM +0000, Joonwon Kang wrote:
> >
> > > Appreciate all your clarifications here. So, my understanding is that if
> > > our system does not support ST64BV and ST64BV0 or if our device does not
> > > distinguish between the posted write and the non-posted write regarding
> > > PASID, then we can lift the use of the global PASID space. Can I say this?
> >
> > You should do what Robin said - just have your driver use a per-device
> > PASID that it allocates and never use the global pasid allocator.
> >
> > To do this lightly re-organize the SVA code so the driver can supply
> > its own PASID, and in this mode we wouldn't activate the ENQCMD
> > features in the mm.
>
> Ah, we could actively disallow EL0 to execute ENQCMD-like instructions
> when the device driver explicitly shows the intention via a new API like
> `iommu_sva_bind_device_pasid()` that Tian mentioned earlier.
You shouldn't need to do anything like this.
All you need is to ensure that mm_get_enqcmd_pasid() returns
IOMMU_PASID_INVALID so long as a the normal iommu_sva_bind_device()
hasn't been called. Once it is called it is fine to allow the ENQCMD.
Your new iommu_sva_bind_device_pasid() needs to establish the SVA and
attach it without triggering mm_get_enqcmd_pasid().
The arch code is required to block the ENQCMD like instructions when
IOMMU_PASID_INVALID.
Devices that can mmap an ENQCMD sensitive BAR region must not do so
unless iommu_sva_bind_device() has been called.
> To allocate a per-device PASID, I think we should do it using
> `dev->iommu_group->pasid_array` instead of making the device driver
No, make the driver manage this, don't mess with the core code. PASID
isn't supported with multi-device groups already.
Jason
^ permalink raw reply
* Re: [PATCH] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS
From: Sudeep Holla @ 2026-05-13 17:15 UTC (permalink / raw)
To: Jamie Nguyen; +Cc: linux-arm-kernel, linux-kernel, Sudeep Holla
In-Reply-To: <20260513032800.68807-1-jamien@nvidia.com>
On Tue, May 12, 2026 at 08:28:00PM -0700, Jamie Nguyen wrote:
> __ffa_partition_info_get_regs() walks the response with a hardcoded
> 24-byte stride (regs += 3) even though the SPMC tells us the actual
> per-descriptor size via PARTITION_INFO_SZ in x2[63:48]. The size is
> read into buf_sz and then thrown away.
>
> That works while every SPMC returns the FF-A v1.1 layout, but it falls
> apart against a v1.3 SPMC returning the 48-byte descriptor. The loop
> strides over half a descriptor at a time and ends up parsing every
> other entry from a slice of two adjacent ones.
>
> The FF-A spec (v1.2, section 18.5) says that the producer should
> report the descriptor size, and the consumer is supposed to stride by
> that size and ignore any trailing fields it doesn't understand. The
> non-REGS path (__ffa_partition_info_get) does this already, and the
> REGS path should match.
>
> Use buf_sz for the stride, and bail out with -EPROTO if the SPMC
> reports something we can't safely walk.
>
Can you check if the issue is addressed in -next by:
Commit 3974ea193840 ("firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies")
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2 0/5] scmi: Log client subsystem entity counts
From: Alex Tran @ 2026-05-13 17:16 UTC (permalink / raw)
To: Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Sudeep Holla, Cristian Marussi, Linus Walleij,
Rafael J. Wysocki, Philipp Zabel, Viresh Kumar, Guenter Roeck
Cc: linux-iio, linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio,
linux-pm, linux-hwmon, Alex Tran
SCMI client drivers do not consistently log the number of supported
entities discovered from firmware. This information is useful during
debugging because it shows which domains or resources were exposed by
firmware during probe.
Add logging of the number of supported entities to the SCMI cpufreq,
pinctrl, reset, hwmon, and powercap client drivers after a successful
probe. This aligns these drivers with the existing logging in the SCMI
power and performance domain drivers.
Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
---
Changes in v2:
- Use dev_dbg instead of dev_info log level
- Link to v1: https://lore.kernel.org/r/20260513-scmi-client-probe-log-v1-0-00b47b1be009@oss.qualcomm.com
---
Alex Tran (5):
powercap: arm_scmi_powercap: Log number of powercap domains
cpufreq: scmi-cpufreq: Log number of perf domains
hwmon: scmi-hwmon: Log number of sensors
reset: reset-scmi: Log number of reset domains
pinctrl: pinctrl-scmi: Log number of pins, groups, functions
drivers/cpufreq/scmi-cpufreq.c | 5 ++++-
drivers/hwmon/scmi-hwmon.c | 1 +
drivers/pinctrl/pinctrl-scmi.c | 11 ++++++++++-
drivers/powercap/arm_scmi_powercap.c | 1 +
drivers/reset/reset-scmi.c | 8 +++++++-
5 files changed, 23 insertions(+), 3 deletions(-)
---
base-commit: 1bfaee9d3351b9b32a99766bbfb1f5baed60ddef
change-id: 20260509-scmi-client-probe-log-173cf85d5563
Best regards,
--
Alex Tran <alex.tran@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2 2/5] cpufreq: scmi-cpufreq: Log number of perf domains
From: Alex Tran @ 2026-05-13 17:16 UTC (permalink / raw)
To: Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Sudeep Holla, Cristian Marussi, Linus Walleij,
Rafael J. Wysocki, Philipp Zabel, Viresh Kumar, Guenter Roeck
Cc: linux-iio, linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio,
linux-pm, linux-hwmon, Alex Tran
In-Reply-To: <20260513-scmi-client-probe-log-v2-0-36607e9dd540@oss.qualcomm.com>
The SCMI cpufreq driver does not currently log the number of performance
domains discovered from firmware. This information is useful for
confirming the firmware exposed performance domains during debugging.
Log the domain count after a successful probe to align with the existing
SCMI client driver logging pattern.
Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
---
drivers/cpufreq/scmi-cpufreq.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 4edb4f7a8aa9..f4cf59d862c6 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -468,9 +468,12 @@ static int scmi_cpufreq_probe(struct scmi_device *sdev)
if (ret) {
dev_err(dev, "%s: registering cpufreq failed, err: %d\n",
__func__, ret);
+ return ret;
}
- return ret;
+ dev_dbg(dev, "Initialized %d performance domains\n",
+ perf_ops->num_domains_get(ph));
+ return 0;
}
static void scmi_cpufreq_remove(struct scmi_device *sdev)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/5] powercap: arm_scmi_powercap: Log number of powercap domains
From: Alex Tran @ 2026-05-13 17:16 UTC (permalink / raw)
To: Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Sudeep Holla, Cristian Marussi, Linus Walleij,
Rafael J. Wysocki, Philipp Zabel, Viresh Kumar, Guenter Roeck
Cc: linux-iio, linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio,
linux-pm, linux-hwmon, Alex Tran
In-Reply-To: <20260513-scmi-client-probe-log-v2-0-36607e9dd540@oss.qualcomm.com>
The SCMI powercap driver does not currently report how many powercap
domains were discovered from firmware during probe. This makes it harder
to confirm the firmware exposed powercap resources during debugging.
Log the powercap domain count after a successful probe, aligning the
driver with the existing SCMI client driver logging pattern.
Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
---
drivers/powercap/arm_scmi_powercap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/powercap/arm_scmi_powercap.c b/drivers/powercap/arm_scmi_powercap.c
index ab66e9a3b1e2..3efe3743cce0 100644
--- a/drivers/powercap/arm_scmi_powercap.c
+++ b/drivers/powercap/arm_scmi_powercap.c
@@ -496,6 +496,7 @@ static int scmi_powercap_probe(struct scmi_device *sdev)
return ret;
dev_set_drvdata(dev, pr);
+ dev_dbg(dev, "Initialized %d powercap domains\n", pr->num_zones);
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 4/5] reset: reset-scmi: Log number of reset domains
From: Alex Tran @ 2026-05-13 17:16 UTC (permalink / raw)
To: Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Sudeep Holla, Cristian Marussi, Linus Walleij,
Rafael J. Wysocki, Philipp Zabel, Viresh Kumar, Guenter Roeck
Cc: linux-iio, linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio,
linux-pm, linux-hwmon, Alex Tran
In-Reply-To: <20260513-scmi-client-probe-log-v2-0-36607e9dd540@oss.qualcomm.com>
The SCMI reset driver does not currently report how many reset domains
were discovered from firmware during probe. This makes it harder to
confirm the firmware reset resources during debugging.
Log the reset domain count after a successful probe, aligning the driver
with the existing SCMI client driver logging pattern.
Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
---
drivers/reset/reset-scmi.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/reset/reset-scmi.c b/drivers/reset/reset-scmi.c
index 4335811e0cfa..114470c12931 100644
--- a/drivers/reset/reset-scmi.c
+++ b/drivers/reset/reset-scmi.c
@@ -93,6 +93,7 @@ static int scmi_reset_probe(struct scmi_device *sdev)
struct device_node *np = dev->of_node;
const struct scmi_handle *handle = sdev->handle;
struct scmi_protocol_handle *ph;
+ int ret;
if (!handle)
return -ENODEV;
@@ -111,7 +112,12 @@ static int scmi_reset_probe(struct scmi_device *sdev)
data->rcdev.nr_resets = reset_ops->num_domains_get(ph);
data->ph = ph;
- return devm_reset_controller_register(dev, &data->rcdev);
+ ret = devm_reset_controller_register(dev, &data->rcdev);
+ if (ret)
+ return ret;
+
+ dev_dbg(dev, "Initialized %d reset domains\n", data->rcdev.nr_resets);
+ return 0;
}
static const struct scmi_device_id scmi_id_table[] = {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 5/5] pinctrl: pinctrl-scmi: Log number of pins, groups, functions
From: Alex Tran @ 2026-05-13 17:16 UTC (permalink / raw)
To: Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Sudeep Holla, Cristian Marussi, Linus Walleij,
Rafael J. Wysocki, Philipp Zabel, Viresh Kumar, Guenter Roeck
Cc: linux-iio, linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio,
linux-pm, linux-hwmon, Alex Tran
In-Reply-To: <20260513-scmi-client-probe-log-v2-0-36607e9dd540@oss.qualcomm.com>
The SCMI pinctrl driver does not currently log the number of pins,
groups, and functions discovered from firmware. This information is
useful for confirming the firmware exposed pinctrl resources during
debugging.
Log these counts after a successful probe to align with the existing
SCMI client driver logging pattern.
Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
---
drivers/pinctrl/pinctrl-scmi.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-scmi.c b/drivers/pinctrl/pinctrl-scmi.c
index f22be6b7b82a..999c2061ddc3 100644
--- a/drivers/pinctrl/pinctrl-scmi.c
+++ b/drivers/pinctrl/pinctrl-scmi.c
@@ -40,6 +40,7 @@ struct scmi_pinctrl {
struct pinctrl_desc pctl_desc;
struct pinfunction *functions;
unsigned int nr_functions;
+ unsigned int nr_groups;
};
static int pinctrl_scmi_get_groups_count(struct pinctrl_dev *pctldev)
@@ -578,7 +579,15 @@ static int scmi_pinctrl_probe(struct scmi_device *sdev)
if (!pmx->functions)
return -ENOMEM;
- return pinctrl_enable(pmx->pctldev);
+ pmx->nr_groups = pinctrl_scmi_get_groups_count(pmx->pctldev);
+
+ ret = pinctrl_enable(pmx->pctldev);
+ if (ret)
+ return ret;
+
+ dev_dbg(dev, "Initialized %d pins, %d groups, %d functions\n",
+ pmx->pctl_desc.npins, pmx->nr_groups, pmx->nr_functions);
+ return 0;
}
static const struct scmi_device_id scmi_id_table[] = {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/5] hwmon: scmi-hwmon: Log number of sensors
From: Alex Tran @ 2026-05-13 17:16 UTC (permalink / raw)
To: Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Sudeep Holla, Cristian Marussi, Linus Walleij,
Rafael J. Wysocki, Philipp Zabel, Viresh Kumar, Guenter Roeck
Cc: linux-iio, linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio,
linux-pm, linux-hwmon, Alex Tran
In-Reply-To: <20260513-scmi-client-probe-log-v2-0-36607e9dd540@oss.qualcomm.com>
The SCMI hwmon driver does not currently report how many sensors were
discovered from firmware during probe. This makes it harder to confirm
the firmware exposed sensor resources during debugging.
Log the sensor count after a successful probe, aligning the driver with
the existing SCMI client driver logging pattern.
Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
---
drivers/hwmon/scmi-hwmon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hwmon/scmi-hwmon.c b/drivers/hwmon/scmi-hwmon.c
index eec223d174c0..456ce11d050c 100644
--- a/drivers/hwmon/scmi-hwmon.c
+++ b/drivers/hwmon/scmi-hwmon.c
@@ -362,6 +362,7 @@ static int scmi_hwmon_probe(struct scmi_device *sdev)
}
}
+ dev_dbg(dev, "Initialized %d sensors\n", nr_sensors);
return 0;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 1/2] firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation
From: Sudeep Holla @ 2026-05-13 17:19 UTC (permalink / raw)
To: Mostafa Saleh
Cc: Sebastian Ene, catalin.marinas, Sudeep Holla, maz, oupton, will,
joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, suzuki.poulose,
vdonnefort, yuzenghui
In-Reply-To: <agR98uWCHQBHuGNg@google.com>
On Wed, May 13, 2026 at 01:34:42PM +0000, Mostafa Saleh wrote:
> On Tue, May 12, 2026 at 12:44:41PM +0000, Sebastian Ene wrote:
> > Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint
> > memory access array and to comply with the FF-A spec instead of defaulting
> > to `sizeof(struct ffa_mem_region)`.
> > This requires moving `ffa_mem_region_additional_setup()` earlier in the setup
> > flow.
> > Also, add sanity checks to ensure the calculated descriptor offsets do not
> > exceed `max_fragsize`.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > drivers/firmware/arm_ffa/driver.c | 14 ++++++++++----
> > include/linux/arm_ffa.h | 2 +-
> > 2 files changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> > index eb2782848283..56b166290b24 100644
> > --- a/drivers/firmware/arm_ffa/driver.c
> > +++ b/drivers/firmware/arm_ffa/driver.c
> > @@ -685,18 +685,25 @@ ffa_setup_and_transmit(u32 func_id, void *buffer, u32 max_fragsize,
> > struct ffa_composite_mem_region *composite;
> > struct ffa_mem_region_addr_range *constituents;
> > struct ffa_mem_region_attributes *ep_mem_access;
> > - u32 idx, frag_len, length, buf_sz = 0, num_entries = sg_nents(args->sg);
> > + u32 idx, frag_len, length, buf_sz = 0, num_entries = sg_nents(args->sg), ep_offset;
> >
> > mem_region->tag = args->tag;
> > mem_region->flags = args->flags;
> > mem_region->sender_id = drv_info->vm_id;
> > mem_region->attributes = ffa_memory_attributes_get(func_id);
> > +
> > + ffa_mem_region_additional_setup(drv_info->version, mem_region);
> > composite_offset = ffa_mem_desc_offset(buffer, args->nattrs,
> > drv_info->version);
> > + if (composite_offset > max_fragsize - sizeof(struct ffa_composite_mem_region))
> > + return -ENXIO;
>
> nit: This driver seems to use sizeof() with variable name rather than
> type (except for one place) so it may be good to keep that.
>
Agreed, +1.
> >
> > for (idx = 0; idx < args->nattrs; idx++) {
> > - ep_mem_access = buffer +
> > - ffa_mem_desc_offset(buffer, idx, drv_info->version);
> > + ep_offset = ffa_mem_desc_offset(buffer, idx, drv_info->version);
> > + if (ep_offset > max_fragsize - sizeof(struct ffa_mem_region_attributes))
> > + return -ENXIO;
> > +
> > + ep_mem_access = buffer + ep_offset;
> > ep_mem_access->receiver = args->attrs[idx].receiver;
> > ep_mem_access->attrs = args->attrs[idx].attrs;
> > ep_mem_access->composite_off = composite_offset;
> > @@ -708,7 +715,6 @@ ffa_setup_and_transmit(u32 func_id, void *buffer, u32 max_fragsize,
> > }
> > mem_region->handle = 0;
> > mem_region->ep_count = args->nattrs;
> > - ffa_mem_region_additional_setup(drv_info->version, mem_region);
> >
> > composite = buffer + composite_offset;
> > composite->total_pg_cnt = ffa_get_num_pages_sg(args->sg);
> > diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
> > index 81e603839c4a..62d67dae8b70 100644
> > --- a/include/linux/arm_ffa.h
> > +++ b/include/linux/arm_ffa.h
> > @@ -445,7 +445,7 @@ ffa_mem_desc_offset(struct ffa_mem_region *buf, int count, u32 ffa_version)
> > if (!FFA_MEM_REGION_HAS_EP_MEM_OFFSET(ffa_version))
> > offset += offsetof(struct ffa_mem_region, ep_mem_offset);
> > else
> > - offset += sizeof(struct ffa_mem_region);
> > + offset += buf->ep_mem_offset;
>
> Does it make sense to also set buf->ep_mem_offset for the other
> case in ffa_mem_region_additional_setup() and then add this
> unconditionally here?
>
I need to cross-check the spec, but if I vaguely recall as the name
FFA_MEM_REGION_HAS_EP_MEM_OFFSET suggests, older versions don't have that
field to use it.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v3 0/2] arm_ffa, KVM: Fix FF-A emad offset calculations
From: Sudeep Holla @ 2026-05-13 17:23 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, maz, oupton, Sudeep Holla, will, joey.gouly,
korneld, kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
mrigendra.chaubey, perlarsen, suzuki.poulose, vdonnefort,
yuzenghui
In-Reply-To: <20260512124442.1899107-1-sebastianene@google.com>
On Tue, May 12, 2026 at 12:44:40PM +0000, Sebastian Ene wrote:
> Hi all,
>
> This series fixes the Endpoint Memory Access Descriptor (EMAD) offset calculations
> and adds the necessary bounds checks for both the core FF-A driver and the pKVM
> hypervisor.
>
> Prior to FF-A version 1.1, the memory region header didn't specify an explicit offset
> for the EMADs, leading to the assumption that they immediately follow the header.
> However, from v1.1 onwards, the specification dictates using the `ep_mem_offset` field
> to determine the start of the memory access array.
>
> The patches in this series address this by:
> 1. Updating the core `arm_ffa` firmware driver to correctly calculate the descriptor
> offset using `ep_mem_offset` rather than defaulting to `sizeof(struct ffa_mem_region)`.
> It also introduces bounds checking against `max_fragsize`.
> 2. Enhancing the pKVM hypervisor validation logic to no longer strictly enforce that
> the descriptor strictly follows the header, aligning it with the driver behavior
> and the FF-A specification, while also ensuring the offset falls within the mailbox
> buffer bounds.
>
Looks good apart from the minor nits, but how do you plan to route these
changes as they are dependent for functionality but not for the build IIUC.
I don't think I have any conflicting change so far, so it can go along with
other pKVM changes. Let me know.
> Changelog
> #########
>
> v2 -> this:
> - Fixed typo in nvhe/ffa.c (missing sizeof)
>
> v1 -> v2:
> - For pKVM, removed the strict placement enforcement for `ep_mem_offset` as it is not
> compliant with the spec, and avoids making assumptions about the driver's memory
> layout.
>
> Link to:
> ########
>
> v2: https://lore.kernel.org/all/20260430160241.1934777-1-sebastianene@google.com/
> v1: https://lore.kernel.org/all/ae9KN9nkOgDYJcGP@google.com/T/#t
>
> Sebastian Ene (2):
> firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset
> calculation
> KVM: arm64: Validate the offset to the mem access descriptor
>
> arch/arm64/kvm/hyp/nvhe/ffa.c | 24 ++++++++++++++++++------
> drivers/firmware/arm_ffa/driver.c | 14 ++++++++++----
> include/linux/arm_ffa.h | 2 +-
> 3 files changed, 29 insertions(+), 11 deletions(-)
>
> --
> 2.54.0.563.g4f69b47b94-goog
>
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Jason Gunthorpe @ 2026-05-13 17:24 UTC (permalink / raw)
To: Mostafa Saleh
Cc: Aneesh Kumar K.V (Arm), iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev, linux-s390, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <agSKQrSIhizCXKwx@google.com>
On Wed, May 13, 2026 at 02:27:14PM +0000, Mostafa Saleh wrote:
> > + /*
> > + * if platform supports memory encryption,
> > + * restricted mem pool is decrypted by default
> > + */
> > + if (cc_platform_has(CC_ATTR_MEM_ENCRYPT)) {
> > + mem->unencrypted = true;
> > + set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
> > + rmem->size >> PAGE_SHIFT);
> > + } else {
> > + mem->unencrypted = false;
> > + }
>
> This breaks pKVM as it doesn’t set CC_ATTR_MEM_ENCRYPT, so all virtio
> traffic now fails.
How will pKVM signal what kind of memory the DMA needs then?
Does it use set_memory_decrypted()? How can it use
set_memory_decrypted() without offering CC_ATTR_MEM_ENCRYPT ?
> Also, by design, some drivers are clueless about bouncing, so
Oh? What does this mean? We take quite a dim view of drivers mis-using
the DMA API..
> I believe that the pool should have a way to control it’s property
> (encrypted or decrypted) and that takes priority over whatever
> attributes comes from allocation.
We should get here because dma_capable() fails, and then swiotlb needs
to return something that makes dma_capable() succeed. Yes, it should
return details about the thing it decided, but it shouldn't have been
pre-created with some idea how to make dma_capable() work.
If dma_capable() can fail, then swiotlb should know exactly what to do
to fix it.
If pkvm wants to use the hacky scheme where you force a swiotlb pool
configuration during arch init with force swiotlb that's a somewhat
different flow and, sure the forced pool should force do whatever it
is forced to.
But lets try to keep them seperated in the discussion..
> And that brings us to the same point whether it’s better to return
> the memory along with it’s state or we pass the requested state.
> I think for other cases it’s fine for the device/DMA-API to dictate
> the attrs, but not in restricted-dma case, the firmware just knows better.
The memory type must be returned back at some level so downstream
things can do the right transformation of the phys_addr_t.
One of the aspirational CC things that should work is a T=1 device
tries to DMA from a decrypted page, finds the address is above the dma
limit of the device, so it bounces it with SWIOTLB to an encrypted low
address page and then the DMA API internal flow switiches from working
with decrypted to encrypted phys_addr_t.
If we can make that work then maybe the flows are designed correctly.
Jason
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits
From: Pranjal Shrivastava @ 2026-05-13 17:38 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Will Deacon, Nicolin Chen, Robin Murphy, Joerg Roedel,
Jean-Philippe Brucker, Catalin Marinas, Mikołaj Lenczewski,
linux-arm-kernel, iommu, linux-kernel
In-Reply-To: <20260513143213.GA787748@nvidia.com>
On Wed, May 13, 2026 at 11:32:13AM -0300, Jason Gunthorpe wrote:
> On Wed, May 13, 2026 at 02:27:48PM +0000, Pranjal Shrivastava wrote:
>
> > Now, if we're work on an SVA page, with only SMMU supporting HTTU. A DMA
> > writes to the page and the process (CPU) calls fsync(). IIUC, it performs
> > a lookup in the Page Cache specifically for folios tagged as DIRTY.
> > Since, vmscan didn't run yet, this could potentally drop the writes..
>
> How does it work differently in the MM when the CPU has BBM support?
Hmm... I looked at fsync and I see that it eventually calls
folio_mkclean() (via writeback [1]), which performs an rmap_walk() [2]
to harvest dirty bits from PTEs into the respective struct folios.
Similarly, the vm_scan path does the same thing via try_to_unmap [3].
Since the MM subsystem actively scans the tables during writeback, it
doesn't matter if the dirty bits were flipped asynchronously by HW (w/o
kernel traps).
I guess that settles it, we don't need to gate this behind cpu_has_hw_af()
and we need not care about the CONFIG_ARM64_HW_AFDBM either.
Reviewed by: Pranjal Shrivastava <praan@google.com>
Thanks,
Praan
[1] https://elixir.bootlin.com/linux/v7.1-rc3/source/mm/page-writeback.c#L2905
[2] https://elixir.bootlin.com/linux/v7.1-rc3/source/mm/rmap.c#L1103
[3] https://elixir.bootlin.com/linux/v7.1-rc3/source/mm/rmap.c#L2164
^ permalink raw reply
* Re: [PATCH 6/8] arm64: dts: qcom: kaanapali: Add GPU cooling
From: Dmitry Baryshkov @ 2026-05-13 17:53 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sean Paul,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm,
freedreno, dri-devel, Gaurav Kohli
In-Reply-To: <20260512-kaana-gpu-dt-v1-6-13e1c07c2050@oss.qualcomm.com>
On Tue, May 12, 2026 at 03:53:20AM +0530, Akhil P Oommen wrote:
> From: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>
> Unlike the CPU, the GPU does not throttle its speed automatically when it
> reaches high temperatures.
>
> Set up GPU cooling by throttling the GPU speed
> when reaching 105°C.
>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kaanapali.dtsi | 165 ++++++++++++++++++++++++++------
> 1 file changed, 135 insertions(+), 30 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> index c57aea44218e..5089416ec32c 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> @@ -26,6 +26,7 @@
> #include <dt-bindings/soc/qcom,gpr.h>
> #include <dt-bindings/soc/qcom,rpmh-rsc.h>
> #include <dt-bindings/sound/qcom,q6dsp-lpass-ports.h>
> +#include <dt-bindings/thermal/thermal.h>
>
> #include "kaanapali-ipcc.h"
>
> @@ -7045,13 +7046,15 @@ nsphmx-3-critical {
> };
>
> gpuss-0-thermal {
> + polling-delay-passive = <200>;
Other DT files use 10 for GPU thermal zones polling interval.
> +
> thermal-sensors = <&tsens5 0>;
>
> trips {
> - gpuss-0-hot {
> - temperature = <120000>;
> + gpuss_0_alert0: gpuss-0-alert0 {
> + temperature = <105000>;
> hysteresis = <5000>;
> - type = "hot";
> + type = "passive";
> };
Why don't we keep both passive and hot trip points?
>
> gpuss-0-critical {
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 7/8] arm64: dts: qcom: kaanapali-mtp: Enable GPU
From: Dmitry Baryshkov @ 2026-05-13 17:54 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sean Paul,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm,
freedreno, dri-devel
In-Reply-To: <20260512-kaana-gpu-dt-v1-7-13e1c07c2050@oss.qualcomm.com>
On Tue, May 12, 2026 at 03:53:21AM +0530, Akhil P Oommen wrote:
> Add the secure firmware name property and enable GPU support on
> Kaanapali MTP device.
>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 8/8] arm64: dts: qcom: kaanapali-qrd: Enable GPU
From: Dmitry Baryshkov @ 2026-05-13 17:54 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sean Paul,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm,
freedreno, dri-devel
In-Reply-To: <20260512-kaana-gpu-dt-v1-8-13e1c07c2050@oss.qualcomm.com>
On Tue, May 12, 2026 at 03:53:22AM +0530, Akhil P Oommen wrote:
> Add the secure firmware name property and enable GPU support on
> Kaanapali QRD device.
>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 5/8] dt-bindings: arm: ras: Introduce bindings for ARM AEST
From: Rob Herring @ 2026-05-13 17:58 UTC (permalink / raw)
To: Umang Chheda
Cc: Ruidong Tian, Tony Luck, Borislav Petkov, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, catalin.marinas,
will, lpieralisi, rafael, mark.rutland, Sudeep Holla,
linux-arm-msm, linux-acpi, linux-arm-kernel, linux-edac,
linux-kernel, devicetree
In-Reply-To: <20260505-aest-devicetree-support-v1-5-d5d6ffacf0a5@oss.qualcomm.com>
On Tue, May 05, 2026 at 05:53:49PM +0530, Umang Chheda wrote:
> The Arm Error Source Table (AEST) specification describes how firmware
> exposes RAS error source topology to the operating system. On ACPI
> systems this information is provided via the AEST ACPI table.
>
> Introduce Device Tree bindings that provide an equivalent description
> of AEST error sources for DT-based platforms.
>
> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
> ---
> .../devicetree/bindings/arm/arm,aest.yaml | 406 +++++++++++++++++++++
> include/dt-bindings/arm/aest.h | 43 +++
> 2 files changed, 449 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/arm,aest.yaml b/Documentation/devicetree/bindings/arm/arm,aest.yaml
> new file mode 100644
> index 000000000000..7809a0d38270
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/arm,aest.yaml
> @@ -0,0 +1,406 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/arm,aest.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Arm Error Source Table (AEST)
> +
> +maintainers:
> + - Umang Chheda <umang.chheda@oss.qualcomm.com>
> +
> +description:
> + The Arm Error Source Table (AEST) describes RAS error sources and their
> + register interfaces. Each error source exposes one or more error records
> + through either system registers or a memory-mapped register window, and
> + may signal errors via interrupts. The top-level node acts as a container
> + for one or more child nodes, each describing a single AEST error source.
> + Refer to the Arm AEST specification (DEN0085 / DDI 0587B) for details.
> + Flag bit constants for use in DT source files are defined in
> + <dt-bindings/arm/aest.h>.
> +
> +properties:
> + compatible:
> + const: arm,aest
> +
> + "#address-cells":
> + const: 2
> +
> + "#size-cells":
> + const: 2
> +
> + ranges: true
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> +patternProperties:
> + "^aest-[a-z0-9-]+(@[0-9a-f]+)?$":
> + type: object
> + description:
> + An AEST error source node describing one error source defined by
> + the Arm AEST specification.
> +
> + properties:
> + compatible:
> + description:
> + Identifies the type of AEST error source. Each value corresponds to
> + a distinct error source class defined by the Arm AEST specification.
> + arm,aest-proxy represents a proxy error source that forwards errors
> + from another error source.
> + enum:
> + - arm,aest-processor
> + - arm,aest-memory
> + - arm,aest-smmu
> + - arm,aest-gic
> + - arm,aest-pcie
> + - arm,aest-vendor
> + - arm,aest-proxy
This is a fundamental difference how DT and ACPI get structured. ACPI
defines new table for some feature and puts everything in that table.
For DT, these all belong in the node for the corresponding h/w. For
example, if the GIC supports AEST, then that belongs in the GIC node.
> +
> + reg:
> + description:
> + Register ranges for the error source. Absence of reg implies
> + system-register access (interface type 0). A single range implies
> + memory-mapped access (interface type 1). Two ranges imply
> + single-record memory-mapped access (interface type 2).
> + minItems: 1
> + maxItems: 4
> +
> + reg-names:
> + description:
> + Names for the register ranges. The base error-record window is
> + unnamed (or first entry). Optional named ranges provide access to
> + the fault-injection, error-group, and interrupt-config register
> + windows defined by the AEST specification.
> + minItems: 1
> + maxItems: 4
> + items:
> + enum:
> + - fault-inject
> + - err-group
> + - irq-config
> +
> + interrupts:
> + description: Interrupts associated with the error source.
> + minItems: 1
> + maxItems: 2
> +
> + interrupt-names:
> + description: Names of the interrupts associated with the error source.
> + minItems: 1
> + maxItems: 2
> + items:
> + enum:
> + - fhi
> + - eri
> +
> + arm,fhi-flags:
> + description:
> + Bitmask of flags for the fault-handling interrupt (FHI), as defined
> + in the AEST node interrupt structure flags field. Constants are
> + defined in <dt-bindings/arm/aest.h> - AEST_IRQ_MODE_LEVEL (0),
> + AEST_IRQ_MODE_EDGE (1).
DT already has a way to define interrupt flags. Why invent something
new?
Rob
^ 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