* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Andrew Lunn @ 2026-05-11 18:18 UTC (permalink / raw)
To: Mathieu Poirier
Cc: tanmay.shah, Arnaud POULIQUEN, Beleswar Prasad Padhi,
Shenwei Wang, 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>
> 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.
How many of the participants here will be in Minneapolis next week for
the Embedded Linux Conference? There is even a talk about this:
https://osselcna2026.sched.com/event/2JQpx/building-virtual-drivers-with-rpmsg-key-design-principles-challenges-trade-offs-beleswar-prasad-padhi-texas-instruments?iframe=yes&w=100%&sidebar=yes&bg=no
Maybe we can get together and decide on the final design after the
session.
Andrew
^ permalink raw reply
* Re: [PATCH v2 14/15] dt-bindings: display/lvds-codec: add ti,sn65lvds93
From: Hugo Villeneuve @ 2026-05-11 15:44 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: krzk, robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong,
rfoss, Laurent.pinchart, jonas, jernej.skrabec, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, Frank.Li, s.hauer, kernel,
festevam, shawnguo, laurent.pinchart+renesas, antonin.godard,
devicetree, linux-kernel, dri-devel, imx, linux-arm-kernel,
Hugo Villeneuve, Krzysztof Kozlowski
In-Reply-To: <20260305180651.1827087-15-hugo@hugovil.com>
Hi,
On Thu, 5 Mar 2026 13:06:29 -0500
Hugo Villeneuve <hugo@hugovil.com> wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Add compatible string for TI SN65LVDS93. Similar to
> SN65LVDS83 but with an industrial temperature range.
>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Now that this series landed in linux-next/master, except for this
patch, we now have an error since it is required:
https://lore.kernel.org/oe-kbuild-all/202605071909.lXKPelNA-lkp@intel.com/
Hugo.
> ---
> Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> index 4f52e35d02537..f2cb74b86cc05 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> @@ -37,6 +37,7 @@ properties:
> - ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer
> - ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer
> - ti,sn75lvds83 # For the TI SN75LVDS83 FlatLink transmitter
> + - ti,sn75lvds93 # For the TI SN75LVDS93 FlatLink transmitter
> - const: lvds-encoder # Generic LVDS encoder compatible fallback
> - items:
> - enum:
> --
> 2.47.3
>
>
Hugo Villeneuve <hugo@hugovil.com>
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Mathieu Poirier @ 2026-05-11 17:58 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: <08c815f5-ccbe-404a-95a1-a549aac8a55d@amd.com>
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.
> 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] Documentation: KVM: Document guest-visible compatibility expectations
From: David Woodhouse @ 2026-05-11 17:53 UTC (permalink / raw)
To: Paolo Bonzini, Jonathan Corbet, Shuah Khan, kvm, linux-doc,
linux-kernel, Sean Christopherson, Jim Mattson, Marc Zyngier
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Raghavendra Rao Ananta, Eric Auger,
Kees Cook, Arnd Bergmann, Nathan Chancellor, linux-arm-kernel,
kvmarm, linux-kselftest
In-Reply-To: <baff82ca-6321-4b16-aa61-b2d6d60b6535@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]
On Mon, 2026-05-11 at 18:56 +0200, Paolo Bonzini wrote:
> On 5/11/26 18:38, David Woodhouse wrote:
> > Not *everything* is in CPUID; one recent exception that comes to mind
> > is the SUPPRESS_EOI_BROADCAST quirk. But on x86 we preserve the
> > existing behaviour of older kernels — even when that behaviour doesn't
> > make much sense, as with SUPPRESS_EOI_BROADCAST where older KVM would
> > *advertise* the feature, but not actually *implement* it. Nevertheless,
> > that remains the default behaviour of future kernels unless userspace
> > explicitly opts in to fully enable (or disable) the feature.
> >
> > But this documentation update isn't even asking for that compatible-by-
> > default behaviour, even though that is the right thing to do. It's only
> > asking that it be *possible* to reinstate the old behaviour, for
> > userspace that *knows* about the change and explicitly wants to go back
> > to the old way to remain compatible.
>
> Yep, these are the "quirks"---if it's too early for Arm to commit to
> that, I guess it's fine.
>
> However, independent of this patch which I (obviously) believe is a good
> idea, I'd like to understand how far it is, assuming 1) no quirks 2)
> same CPU host.
It generally works out on arm64, although it's obviously a lot more
work than x86 which makes an effort to get this stuff right.
When we upgrade the kernel we do a lot of in-guest testing to find the
stuff that "broke", like cache reporting:
https://lore.kernel.org/all/254ca48a67779ccf9b9f60e2bb5796a305c03f95.camel@infradead.org/
... and the GICD_IIDR thing which I reposted today:
https://lore.kernel.org/all/20260511113558.3325004-2-dwmw2@infradead.org/
Those are the ones I came up against recently because someone had just
*reverted* the offending commits local in a previous kernel upgrade,
and I'm trying to fix it *properly* this time around and not carry the
reverts forward for ever.
And fix the expectations too, of course. Being told that we shouldn't
*expect* to be able to upgrade and roll back the kernel while remaining
compatible is... not OK.
> By the way, you didn't Cc Marc...
Ah crap, I meant to. Thanks for spotting that!
I must have screwed up when I combined and dedeuplicated the
get_maintainer.pl output with the recipients of the IIDR patch series.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* [PATCH] thermal: imx: do not split quoted string across lines
From: Mayur Kumar @ 2026-05-11 17:42 UTC (permalink / raw)
To: rafael, daniel.lezcano, Frank.Li, s.hauer, rui.zhang, lukasz.luba,
festevam
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, kernel,
Mayur Kumar
The checkpatch tool warns against splitting quoted strings across
multiple lines. Join the dev_info message into a single line to
improve the ability to grep for the message in the source.
Signed-off-by: Mayur Kumar <kmayur809@gmail.com>
---
drivers/thermal/imx_thermal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 38c993d1bcb..5aaacbc5347 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -693,8 +693,8 @@ static int imx_thermal_probe(struct platform_device *pdev)
goto clk_disable;
}
- dev_info(dev, "%s CPU temperature grade - max:%dC"
- " critical:%dC passive:%dC\n", data->temp_grade,
+ dev_info(dev, "%s CPU temperature grade - max:%dC critical:%dC passive:%dC\n",
+ data->temp_grade,
data->temp_max / 1000, trips[IMX_TRIP_CRITICAL].temperature / 1000,
trips[IMX_TRIP_PASSIVE].temperature / 1000);
--
2.34.1
^ permalink raw reply related
* [PATCH v7 1/3] Revert "treewide: Fix probing of devices in DT overlays"
From: Herve Codina @ 2026-05-11 15:57 UTC (permalink / raw)
To: Andrew Lunn, Rob Herring, Saravana Kannan, Geert Uytterhoeven,
Kalle Niemi, Matti Vaittinen, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Wolfram Sang, Mark Brown,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Len Brown, Shawn Guo
Cc: Wolfram Sang, driver-core, linux-kernel, imx, linux-arm-kernel,
linux-i2c, devicetree, linux-spi, linux-acpi, Allan Nielsen,
Horatiu Vultur, Daniel Machon, Steen Hegelund, Luca Ceresoli,
Thomas Petazzoni, Saravana Kannan, Herve Codina
In-Reply-To: <20260511155755.34428-1-herve.codina@bootlin.com>
From: Saravana Kannan <saravanak@google.com>
This reverts commit 1a50d9403fb90cbe4dea0ec9fd0351d2ecbd8924.
While the commit fixed fw_devlink overlay handling for one case, it
broke it for another case. So revert it and redo the fix in a separate
patch.
Fixes: 1a50d9403fb9 ("treewide: Fix probing of devices in DT overlays")
Reported-by: Herve Codina <herve.codina@bootlin.com>
Closes: https://lore.kernel.org/lkml/CAMuHMdXEnSD4rRJ-o90x4OprUacN_rJgyo8x6=9F9rZ+-KzjOg@mail.gmail.com/
Closes: https://lore.kernel.org/all/20240221095137.616d2aaa@bootlin.com/
Closes: https://lore.kernel.org/lkml/20240312151835.29ef62a0@bootlin.com/
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/lkml/20240411235623.1260061-2-saravanak@google.com/
[Herve: Fix conflicts due to f72e77c33e4b ("device property: Make
modifications of fwnode "flags" thread safe")]
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
drivers/bus/imx-weim.c | 6 ------
drivers/i2c/i2c-core-of.c | 5 -----
drivers/of/dynamic.c | 1 -
drivers/of/platform.c | 5 -----
drivers/spi/spi.c | 5 -----
5 files changed, 22 deletions(-)
diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
index f735e0462c55..87070155b057 100644
--- a/drivers/bus/imx-weim.c
+++ b/drivers/bus/imx-weim.c
@@ -327,12 +327,6 @@ static int of_weim_notify(struct notifier_block *nb, unsigned long action,
"Failed to setup timing for '%pOF'\n", rd->dn);
if (!of_node_check_flag(rd->dn, OF_POPULATED)) {
- /*
- * Clear the flag before adding the device so that
- * fw_devlink doesn't skip adding consumers to this
- * device.
- */
- fwnode_clear_flag(&rd->dn->fwnode, FWNODE_FLAG_NOT_DEVICE);
if (!of_platform_device_create(rd->dn, NULL, &pdev->dev)) {
dev_err(&pdev->dev,
"Failed to create child device '%pOF'\n",
diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index 354a88d0599e..30b48a428c0b 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -176,11 +176,6 @@ static int of_i2c_notify(struct notifier_block *nb, unsigned long action,
return NOTIFY_OK;
}
- /*
- * Clear the flag before adding the device so that fw_devlink
- * doesn't skip adding consumers to this device.
- */
- fwnode_clear_flag(&rd->dn->fwnode, FWNODE_FLAG_NOT_DEVICE);
client = of_i2c_register_device(adap, rd->dn);
if (IS_ERR(client)) {
dev_err(&adap->dev, "failed to create client for '%pOF'\n",
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index ade288372101..aa450425ec1e 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -225,7 +225,6 @@ static void __of_attach_node(struct device_node *np)
np->sibling = np->parent->child;
np->parent->child = np;
of_node_clear_flag(np, OF_DETACHED);
- fwnode_set_flag(&np->fwnode, FWNODE_FLAG_NOT_DEVICE);
raw_spin_unlock_irqrestore(&devtree_lock, flags);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index a42224f9d1a8..53bca8c6f781 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -744,11 +744,6 @@ static int of_platform_notify(struct notifier_block *nb,
if (of_node_check_flag(rd->dn, OF_POPULATED))
return NOTIFY_OK;
- /*
- * Clear the flag before adding the device so that fw_devlink
- * doesn't skip adding consumers to this device.
- */
- fwnode_clear_flag(&rd->dn->fwnode, FWNODE_FLAG_NOT_DEVICE);
/* pdev_parent may be NULL when no bus platform device */
pdev_parent = of_find_device_by_node(parent);
pdev = of_platform_device_create(rd->dn, NULL,
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 104279858f56..889e1eecc757 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -5003,11 +5003,6 @@ static int of_spi_notify(struct notifier_block *nb, unsigned long action,
return NOTIFY_OK;
}
- /*
- * Clear the flag before adding the device so that fw_devlink
- * doesn't skip adding consumers to this device.
- */
- fwnode_clear_flag(&rd->dn->fwnode, FWNODE_FLAG_NOT_DEVICE);
spi = of_register_spi_device(ctlr, rd->dn);
put_device(&ctlr->dev);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
From: Catalin Marinas @ 2026-05-11 17:37 UTC (permalink / raw)
To: Jinjie Ruan
Cc: will, punit.agrawal, rafael.j.wysocki, fengchengwen, chenl311,
suzuki.poulose, maz, timothy.hayes, lpieralisi, mrigendra.chaubey,
arnd, sudeep.holla, yangyicong, jic23, pierre.gondois,
linux-arm-kernel, linux-kernel, james.morse
In-Reply-To: <20260427023507.1247418-1-ruanjinjie@huawei.com>
On Mon, Apr 27, 2026 at 10:35:07AM +0800, Jinjie Ruan wrote:
> On arm64, when booting with `maxcpus` greater than the number of present
> CPUs (e.g., QEMU -smp cpus=4,maxcpus=8), some CPUs are marked as 'present'
> but have not yet been registered via register_cpu(). Consequently,
> the per-cpu device objects for these CPUs are not yet initialized.
[...]
> Fix this by:
>
> 1. When booting with ACPI, checking the ACPI_MADT_ENABLED flag in the GICC
> entry before calling set_cpu_present() during SMP initialization.
>
> 2. Properly managing the present mask in acpi_map_cpu() and
> acpi_unmap_cpu() to support actual CPU hotplug events, This aligns with
> other architectures like x86 and LoongArch.
I had a chat with James earlier and IIUC the decision was to mark all
CPUs present and the GIC must be fully initialised. But digging through
the GICv3 code, I don't see it depending on cpu_present_mask but rather
on the "always on" MADT GICR description. So I think it should be safe
as long as we don't rely on the GICC gicr_base_address. But we should
update Documentation/arch/arm64/cpu-hotplug.rst to no longer state that
all online-capable vCPUs are marked as present by the kernel.
(or maybe I misunderstood all this)
--
Catalin
^ permalink raw reply
* Re: [PATCH v2] iio: adc: xilinx-ams: Replace spin_lock() and unlock() calls with guard(spinlock*)()
From: Jonathan Cameron @ 2026-05-11 17:21 UTC (permalink / raw)
To: Maxwell Doose
Cc: Sanjay Chitroda, salih.erim, conall.ogriofa, michal.simek,
David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel
In-Reply-To: <CAKqfh0Hmchpq5zvK6Fd=VCqWXN+1FKyWxNyF1O=3zsVEM7HJUw@mail.gmail.com>
On Fri, 8 May 2026 13:53:11 -0500
Maxwell Doose <m32285159@gmail.com> wrote:
> On Fri, May 8, 2026 at 1:50 PM Sanjay Chitroda
> <sanjayembeddedse@gmail.com> wrote:
> >
> > Hi Maxwell,
> >
> > Thanks for the resource cleanup change.
> >
> > Overall looks good.
> >
> > Also, there is opportunity for guard(mutex)().
> >
>
> Thanks, of course I'd also be happy to do the transition to
> guard(mutex)() but it seems like something for tomorrow evening since
> I've already submitted a lot to the mailing list.
Nice patch and well noted by Sanjay - I'd have just applied this
without checking for that :) I think sensible to do one patch that
deals with guard() for both mutex and spinlock.
Sometimes the Xilinx folk do review so I'll leave this a while longer
anyway in the hope they have time to take a look.
It's a safe change set but none the less nice to give time!
Thanks,
Jonathan
>
> best regards,
> max
>
>
>
>
> >
> > Thanks,
> > Sanjay Chitroda
> >
> >
^ permalink raw reply
* [PATCH 5/6] media: stm32-dcmipp: Return queued buffers on start_streaming() failure
From: Valery Borovsky @ 2026-05-11 17:12 UTC (permalink / raw)
To: linux-media
Cc: mchehab, hverkuil, hansg, hugues.fruchet, alain.volmat,
mcoquelin.stm32, alexandre.torgue, sakari.ailus, mripard, wens,
jernej.skrabec, samuel, linux-stm32, linux-arm-kernel,
linux-sunxi, linux-kernel, Valery Borovsky, stable
In-Reply-To: <cover.1778518085.git.vebohr@gmail.com>
The vb2 framework hands buffers to the driver via buf_queue() before
calling start_streaming(). If start_streaming() returns an error
without first returning those buffers via vb2_buffer_done(),
vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued
buffers leak.
dcmipp_bytecap_start_streaming() returned -EINVAL when the source
subdevice could not be resolved from the media graph, before
pm_runtime_resume_and_get() and media_pipeline_start() had been called.
The remaining error paths already converge on the err_buffer_done
label, which calls dcmipp_bytecap_all_buffers_done(...,
VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate
err_pm_put / err_media_pipeline_stop labels are skipped, which is
correct because nothing they would undo has happened yet.
This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure").
Fixes: 28e0f3772296 ("media: stm32-dcmipp: STM32 DCMIPP camera interface driver")
Cc: stable@vger.kernel.org
Signed-off-by: Valery Borovsky <vebohr@gmail.com>
---
.../media/platform/st/stm32/stm32-dcmipp/dcmipp-bytecap.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-bytecap.c b/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-bytecap.c
index a42f43d19f9e..f0e809458489 100644
--- a/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-bytecap.c
+++ b/drivers/media/platform/st/stm32/stm32-dcmipp/dcmipp-bytecap.c
@@ -401,8 +401,10 @@ static int dcmipp_bytecap_start_streaming(struct vb2_queue *vq,
*/
if (!vcap->s_subdev) {
pad = media_pad_remote_pad_first(&vcap->vdev.entity.pads[0]);
- if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
- return -EINVAL;
+ if (!pad || !is_media_entity_v4l2_subdev(pad->entity)) {
+ ret = -EINVAL;
+ goto err_buffer_done;
+ }
vcap->s_subdev = media_entity_to_v4l2_subdev(pad->entity);
vcap->s_subdev_pad_nb = pad->index;
}
--
2.51.0
^ permalink raw reply related
* [PATCH 6/6] media: sun4i-csi: Return queued buffers on start_streaming() failure
From: Valery Borovsky @ 2026-05-11 17:12 UTC (permalink / raw)
To: linux-media
Cc: mchehab, hverkuil, hansg, hugues.fruchet, alain.volmat,
mcoquelin.stm32, alexandre.torgue, sakari.ailus, mripard, wens,
jernej.skrabec, samuel, linux-stm32, linux-arm-kernel,
linux-sunxi, linux-kernel, Valery Borovsky, stable
In-Reply-To: <cover.1778518085.git.vebohr@gmail.com>
The vb2 framework hands buffers to the driver via buf_queue() before
calling start_streaming(). If start_streaming() returns an error
without first returning those buffers via vb2_buffer_done(),
vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued
buffers leak.
sun4i_csi_start_streaming() returned -EINVAL when no matching CSI
format could be found, before any setup (scratch buffer allocation,
pipeline start) had been performed. The remaining error paths already
converge on the err_clear_dma_queue label, which calls
return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump
to that label directly: the intermediate err_disable_device /
err_disable_pipeline / err_free_scratch_buffer labels are skipped,
which is correct because nothing they would undo has happened yet.
This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure").
Fixes: 577bbf23b758 ("media: sunxi: Add A10 CSI driver")
Cc: stable@vger.kernel.org
Signed-off-by: Valery Borovsky <vebohr@gmail.com>
---
drivers/media/platform/sunxi/sun4i-csi/sun4i_dma.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/sunxi/sun4i-csi/sun4i_dma.c b/drivers/media/platform/sunxi/sun4i-csi/sun4i_dma.c
index e911c7f7acc5..4781db21c205 100644
--- a/drivers/media/platform/sunxi/sun4i-csi/sun4i_dma.c
+++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_dma.c
@@ -234,8 +234,10 @@ static int sun4i_csi_start_streaming(struct vb2_queue *vq, unsigned int count)
int ret;
csi_fmt = sun4i_csi_find_format(&csi->fmt.pixelformat, NULL);
- if (!csi_fmt)
- return -EINVAL;
+ if (!csi_fmt) {
+ ret = -EINVAL;
+ goto err_clear_dma_queue;
+ }
dev_dbg(csi->dev, "Starting capture\n");
--
2.51.0
^ permalink raw reply related
* [PATCH 3/6] media: pwc: Return queued buffers on start_streaming() failure
From: Valery Borovsky @ 2026-05-11 17:12 UTC (permalink / raw)
To: linux-media
Cc: mchehab, hverkuil, hansg, hugues.fruchet, alain.volmat,
mcoquelin.stm32, alexandre.torgue, sakari.ailus, mripard, wens,
jernej.skrabec, samuel, linux-stm32, linux-arm-kernel,
linux-sunxi, linux-kernel, Valery Borovsky, stable
In-Reply-To: <cover.1778518085.git.vebohr@gmail.com>
The vb2 framework hands buffers to the driver via buf_queue() before
calling start_streaming(). If start_streaming() returns an error
without first returning those buffers via vb2_buffer_done(),
vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued
buffers leak.
pwc's start_streaming() had two early returns that hit this trap:
-ENODEV when the USB device was already disconnected, and -ERESTARTSYS
when mutex_lock_interruptible() was interrupted by a signal. Call the
existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED
before returning (matching the state already used by the
pwc_isoc_init() error path in the same function).
This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure").
Fixes: ceede9fa8939 ("[media] pwc: Fix locking")
Cc: stable@vger.kernel.org
Signed-off-by: Valery Borovsky <vebohr@gmail.com>
---
drivers/media/usb/pwc/pwc-if.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
index c416e2fc5754..59b99ac8fcb6 100644
--- a/drivers/media/usb/pwc/pwc-if.c
+++ b/drivers/media/usb/pwc/pwc-if.c
@@ -710,11 +710,15 @@ static int start_streaming(struct vb2_queue *vq, unsigned int count)
struct pwc_device *pdev = vb2_get_drv_priv(vq);
int r;
- if (!pdev->udev)
+ if (!pdev->udev) {
+ pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED);
return -ENODEV;
+ }
- if (mutex_lock_interruptible(&pdev->v4l2_lock))
+ if (mutex_lock_interruptible(&pdev->v4l2_lock)) {
+ pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED);
return -ERESTARTSYS;
+ }
/* Turn on camera and set LEDS on */
pwc_camera_power(pdev, 1);
pwc_set_leds(pdev, leds[0], leds[1]);
--
2.51.0
^ permalink raw reply related
* [PATCH 4/6] media: rtl2832_sdr: Return queued buffers on start_streaming() failure
From: Valery Borovsky @ 2026-05-11 17:12 UTC (permalink / raw)
To: linux-media
Cc: mchehab, hverkuil, hansg, hugues.fruchet, alain.volmat,
mcoquelin.stm32, alexandre.torgue, sakari.ailus, mripard, wens,
jernej.skrabec, samuel, linux-stm32, linux-arm-kernel,
linux-sunxi, linux-kernel, Valery Borovsky, stable
In-Reply-To: <cover.1778518085.git.vebohr@gmail.com>
The vb2 framework hands buffers to the driver via buf_queue() before
calling start_streaming(). If start_streaming() returns an error
without first returning those buffers via vb2_buffer_done(),
vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued
buffers leak.
rtl2832_sdr_start_streaming() had multiple error paths that hit this
trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six
`goto err` paths covering subdev s_power, tuner setup, ADC setup,
stream-buffer allocation, urb allocation, and urb submission failures.
None of them returned the queued buffers.
The original function had no distinct success exit and fell straight
through into the err label, which previously only did mutex_unlock and
"return ret". Adding queued-buffer cleanup at err must therefore be
paired with an explicit success return; otherwise every successful
start would also drain the buffer queue and kill streaming. Add that
success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err
label and before each early return.
The cleanup helper takes a vb2_buffer_state argument so that the
start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as
expected by userspace on start_streaming failure) while stop_streaming
keeps its existing VB2_BUF_STATE_ERROR semantics.
This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure").
The err label still does not roll back power_ctrl(), frontend_ctrl(),
the POWER_ON flag, or stream/URB allocations that may have happened
before the failing step. Those are pre-existing leaks of a different
class and are not addressed here.
Fixes: 771138920eaf ("[media] rtl2832_sdr: Realtek RTL2832 SDR driver module")
Cc: stable@vger.kernel.org
Signed-off-by: Valery Borovsky <vebohr@gmail.com>
---
drivers/media/dvb-frontends/rtl2832_sdr.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2832_sdr.c b/drivers/media/dvb-frontends/rtl2832_sdr.c
index 422d1a7b5456..c564485e3bbb 100644
--- a/drivers/media/dvb-frontends/rtl2832_sdr.c
+++ b/drivers/media/dvb-frontends/rtl2832_sdr.c
@@ -399,7 +399,8 @@ static int rtl2832_sdr_alloc_urbs(struct rtl2832_sdr_dev *dev)
}
/* Must be called with vb_queue_lock hold */
-static void rtl2832_sdr_cleanup_queued_bufs(struct rtl2832_sdr_dev *dev)
+static void rtl2832_sdr_cleanup_queued_bufs(struct rtl2832_sdr_dev *dev,
+ enum vb2_buffer_state state)
{
struct platform_device *pdev = dev->pdev;
unsigned long flags;
@@ -413,7 +414,7 @@ static void rtl2832_sdr_cleanup_queued_bufs(struct rtl2832_sdr_dev *dev)
buf = list_entry(dev->queued_bufs.next,
struct rtl2832_sdr_frame_buf, list);
list_del(&buf->list);
- vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_ERROR);
+ vb2_buffer_done(&buf->vb.vb2_buf, state);
}
spin_unlock_irqrestore(&dev->queued_bufs_lock, flags);
}
@@ -855,11 +856,15 @@ static int rtl2832_sdr_start_streaming(struct vb2_queue *vq, unsigned int count)
dev_dbg(&pdev->dev, "\n");
- if (!dev->udev)
+ if (!dev->udev) {
+ rtl2832_sdr_cleanup_queued_bufs(dev, VB2_BUF_STATE_QUEUED);
return -ENODEV;
+ }
- if (mutex_lock_interruptible(&dev->v4l2_lock))
+ if (mutex_lock_interruptible(&dev->v4l2_lock)) {
+ rtl2832_sdr_cleanup_queued_bufs(dev, VB2_BUF_STATE_QUEUED);
return -ERESTARTSYS;
+ }
if (d->props->power_ctrl)
d->props->power_ctrl(d, 1);
@@ -900,7 +905,11 @@ static int rtl2832_sdr_start_streaming(struct vb2_queue *vq, unsigned int count)
if (ret)
goto err;
+ mutex_unlock(&dev->v4l2_lock);
+ return 0;
+
err:
+ rtl2832_sdr_cleanup_queued_bufs(dev, VB2_BUF_STATE_QUEUED);
mutex_unlock(&dev->v4l2_lock);
return ret;
@@ -920,7 +929,7 @@ static void rtl2832_sdr_stop_streaming(struct vb2_queue *vq)
rtl2832_sdr_kill_urbs(dev);
rtl2832_sdr_free_urbs(dev);
rtl2832_sdr_free_stream_bufs(dev);
- rtl2832_sdr_cleanup_queued_bufs(dev);
+ rtl2832_sdr_cleanup_queued_bufs(dev, VB2_BUF_STATE_ERROR);
rtl2832_sdr_unset_adc(dev);
/* sleep tuner */
--
2.51.0
^ permalink raw reply related
* [PATCH 1/6] media: airspy: Return queued buffers on start_streaming() failure
From: Valery Borovsky @ 2026-05-11 17:12 UTC (permalink / raw)
To: linux-media
Cc: mchehab, hverkuil, hansg, hugues.fruchet, alain.volmat,
mcoquelin.stm32, alexandre.torgue, sakari.ailus, mripard, wens,
jernej.skrabec, samuel, linux-stm32, linux-arm-kernel,
linux-sunxi, linux-kernel, Valery Borovsky, stable
In-Reply-To: <cover.1778518085.git.vebohr@gmail.com>
The vb2 framework hands buffers to the driver via buf_queue() before
calling start_streaming(). If start_streaming() returns an error
without first returning those buffers via vb2_buffer_done(),
vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued
buffers leak.
airspy_start_streaming() returned -ENODEV early when the USB device had
been disconnected (s->udev == NULL) without returning any buffers that
buf_queue() had already accepted. Take v4l2_lock first and jump to the
existing err_clear_bit label, which already drains s->queued_bufs via
vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking.
This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure").
Fixes: 634fe5033951 ("[media] airspy: AirSpy SDR driver")
Cc: stable@vger.kernel.org
Signed-off-by: Valery Borovsky <vebohr@gmail.com>
---
drivers/media/usb/airspy/airspy.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/airspy/airspy.c b/drivers/media/usb/airspy/airspy.c
index 8f6b721ba107..57edb42463e8 100644
--- a/drivers/media/usb/airspy/airspy.c
+++ b/drivers/media/usb/airspy/airspy.c
@@ -522,11 +522,13 @@ static int airspy_start_streaming(struct vb2_queue *vq, unsigned int count)
dev_dbg(s->dev, "\n");
- if (!s->udev)
- return -ENODEV;
-
mutex_lock(&s->v4l2_lock);
+ if (!s->udev) {
+ ret = -ENODEV;
+ goto err_clear_bit;
+ }
+
s->sequence = 0;
set_bit(POWER_ON, &s->flags);
--
2.51.0
^ permalink raw reply related
* [PATCH 2/6] media: msi2500: Return queued buffers on start_streaming() failure
From: Valery Borovsky @ 2026-05-11 17:12 UTC (permalink / raw)
To: linux-media
Cc: mchehab, hverkuil, hansg, hugues.fruchet, alain.volmat,
mcoquelin.stm32, alexandre.torgue, sakari.ailus, mripard, wens,
jernej.skrabec, samuel, linux-stm32, linux-arm-kernel,
linux-sunxi, linux-kernel, Valery Borovsky, stable
In-Reply-To: <cover.1778518085.git.vebohr@gmail.com>
The vb2 framework hands buffers to the driver via buf_queue() before
calling start_streaming(). If start_streaming() returns an error
without first returning those buffers via vb2_buffer_done(),
vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued
buffers leak.
msi2500_start_streaming() had five error paths that all hit this trap
and were further tangled by ret-overwriting between calls:
- -ENODEV when the USB device was already disconnected
- -ERESTARTSYS when mutex_lock_interruptible() was interrupted
- msi2500_set_usb_adc() failure: ret was silently overwritten by
the next call (msi2500_isoc_init), so the error was lost entirely
- msi2500_isoc_init() failure: cleanup_queued_bufs was called, but
the function then fell through to msi2500_ctrl_msg() and again
masked the original error by overwriting ret
- msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all,
leaving isoc URBs submitted with no way for the driver to consume
them
Consolidate the error paths into a small goto chain. Every failure
now stops the function, drains the queued-buffer list, and returns
the real error code. The ctrl_msg failure path also rolls back the
preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before
unlocking and draining.
The cleanup helper takes a vb2_buffer_state argument so that the
start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as
expected by userspace on start_streaming failure) while stop_streaming
keeps its existing VB2_BUF_STATE_ERROR semantics.
This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure").
Fixes: 977e444f59ad ("[media] Mirics MSi3101 SDR Dongle driver")
Cc: stable@vger.kernel.org
Signed-off-by: Valery Borovsky <vebohr@gmail.com>
---
drivers/media/usb/msi2500/msi2500.c | 32 +++++++++++++++++++++--------
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/media/usb/msi2500/msi2500.c b/drivers/media/usb/msi2500/msi2500.c
index 1ff98956b680..0614087c3c3c 100644
--- a/drivers/media/usb/msi2500/msi2500.c
+++ b/drivers/media/usb/msi2500/msi2500.c
@@ -541,7 +541,8 @@ static int msi2500_isoc_init(struct msi2500_dev *dev)
}
/* Must be called with vb_queue_lock hold */
-static void msi2500_cleanup_queued_bufs(struct msi2500_dev *dev)
+static void msi2500_cleanup_queued_bufs(struct msi2500_dev *dev,
+ enum vb2_buffer_state state)
{
unsigned long flags;
@@ -554,7 +555,7 @@ static void msi2500_cleanup_queued_bufs(struct msi2500_dev *dev)
buf = list_entry(dev->queued_bufs.next,
struct msi2500_frame_buf, list);
list_del(&buf->list);
- vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_ERROR);
+ vb2_buffer_done(&buf->vb.vb2_buf, state);
}
spin_unlock_irqrestore(&dev->queued_bufs_lock, flags);
}
@@ -830,25 +831,40 @@ static int msi2500_start_streaming(struct vb2_queue *vq, unsigned int count)
dev_dbg(dev->dev, "\n");
- if (!dev->udev)
- return -ENODEV;
+ if (!dev->udev) {
+ ret = -ENODEV;
+ goto err_cleanup;
+ }
- if (mutex_lock_interruptible(&dev->v4l2_lock))
- return -ERESTARTSYS;
+ if (mutex_lock_interruptible(&dev->v4l2_lock)) {
+ ret = -ERESTARTSYS;
+ goto err_cleanup;
+ }
/* wake-up tuner */
v4l2_subdev_call(dev->v4l2_subdev, core, s_power, 1);
ret = msi2500_set_usb_adc(dev);
+ if (ret)
+ goto err_unlock_cleanup;
ret = msi2500_isoc_init(dev);
if (ret)
- msi2500_cleanup_queued_bufs(dev);
+ goto err_unlock_cleanup;
ret = msi2500_ctrl_msg(dev, CMD_START_STREAMING, 0);
+ if (ret)
+ goto err_isoc_cleanup;
mutex_unlock(&dev->v4l2_lock);
+ return 0;
+err_isoc_cleanup:
+ msi2500_isoc_cleanup(dev);
+err_unlock_cleanup:
+ mutex_unlock(&dev->v4l2_lock);
+err_cleanup:
+ msi2500_cleanup_queued_bufs(dev, VB2_BUF_STATE_QUEUED);
return ret;
}
@@ -863,7 +879,7 @@ static void msi2500_stop_streaming(struct vb2_queue *vq)
if (dev->udev)
msi2500_isoc_cleanup(dev);
- msi2500_cleanup_queued_bufs(dev);
+ msi2500_cleanup_queued_bufs(dev, VB2_BUF_STATE_ERROR);
/* according to tests, at least 700us delay is required */
msleep(20);
--
2.51.0
^ permalink raw reply related
* [PATCH 0/6] media: vb2: Return queued buffers from start_streaming() on error
From: Valery Borovsky @ 2026-05-11 17:12 UTC (permalink / raw)
To: linux-media
Cc: mchehab, hverkuil, hansg, hugues.fruchet, alain.volmat,
mcoquelin.stm32, alexandre.torgue, sakari.ailus, mripard, wens,
jernej.skrabec, samuel, linux-stm32, linux-arm-kernel,
linux-sunxi, linux-kernel, Valery Borovsky
The vb2 framework hands buffer ownership to the driver via buf_queue()
before calling start_streaming(). If start_streaming() returns an
error without first returning those buffers via vb2_buffer_done(),
vb2_start_streaming() fires WARN_ON(owned_by_drv_count != 0) and the
queued buffers leak.
This was previously fixed for uvcvideo in commit 4cf3b6fd54eb ("media:
uvcvideo: Return queued buffers on start_streaming() failure"). The
same pattern exists in six sibling drivers that still return an errno
early (USB disconnect, signal-interrupted mutex, or media-graph /
format lookup failure) without draining their internal queued-buffer
list. Each patch reuses or extends the helper / cleanup label that
the driver's other error paths already use.
airspy.c - moves mutex_lock above the !s->udev check and
jumps to the existing err_clear_bit label, which
already drains s->queued_bufs.
msi2500.c - rebuilds start_streaming into a goto chain that
drains the queue on every failure (including
previously-masked set_usb_adc / ctrl_msg paths);
parameterizes msi2500_cleanup_queued_bufs() with
vb2_buffer_state so the start_streaming path
passes _QUEUED. Rolls back isoc_init via
msi2500_isoc_cleanup() on ctrl_msg failure.
pwc-if.c - calls pwc_cleanup_queued_bufs(.., _QUEUED) before
each early return; state matches the existing
pwc_isoc_init() error-path in the same function.
rtl2832_sdr.c - calls rtl2832_sdr_cleanup_queued_bufs() before
each early return and at the err label. Adds an
explicit success return so the cleanup at err no
longer runs on the success path. Parameterizes
the helper with vb2_buffer_state.
dcmipp-bytecap.c - replaces the bare -EINVAL return for failed
subdev lookup with a goto err_buffer_done.
sun4i_dma.c - replaces the bare -EINVAL return for failed
csi-format lookup with a goto err_clear_dma_queue.
These sites were located by a Coccinelle pattern that matches
`return -ERRNO` inside a start_streaming(struct vb2_queue *, unsigned
int) callback without a preceding vb2_buffer_done() on the same path.
Build-tested with drivers/media/ allmodconfig. Not runtime-tested on
any of the six devices. Maintainers with hardware are kindly asked to
verify nothing regresses on their device.
Valery Borovsky (6):
media: airspy: Return queued buffers on start_streaming() failure
media: msi2500: Return queued buffers on start_streaming() failure
media: pwc: Return queued buffers on start_streaming() failure
media: rtl2832_sdr: Return queued buffers on start_streaming() failure
media: stm32-dcmipp: Return queued buffers on start_streaming()
failure
media: sun4i-csi: Return queued buffers on start_streaming() failure
drivers/media/dvb-frontends/rtl2832_sdr.c | 19 ++++++++---
.../st/stm32/stm32-dcmipp/dcmipp-bytecap.c | 6 ++--
.../platform/sunxi/sun4i-csi/sun4i_dma.c | 6 ++--
drivers/media/usb/airspy/airspy.c | 8 +++--
drivers/media/usb/msi2500/msi2500.c | 32 ++++++++++++++-----
drivers/media/usb/pwc/pwc-if.c | 8 +++--
6 files changed, 57 insertions(+), 22 deletions(-)
--
2.51.0
^ permalink raw reply
* Re: [PATCH v3 0/4] remoteproc: add Cortex-A Core remoteproc support on i.MX platforms
From: Mathieu Poirier @ 2026-05-11 17:10 UTC (permalink / raw)
To: Peng Fan
Cc: Jiafei Pan, andersson, peng.fan, Frank.Li, s.hauer, kernel,
festevam, imx, linux-arm-kernel, linux-kernel, Zhiqiang.Hou,
mingkai.hu, linux-remoteproc, devicetree
In-Reply-To: <agF+iYRfUIoBu35M@shlinux89>
On Mon, May 11, 2026 at 03:00:25PM +0800, Peng Fan wrote:
> Hi Jiafei,
>
> On Mon, May 11, 2026 at 10:39:24AM +0800, Jiafei Pan wrote:
> >This patch series is to add remoteproc support on Cortex-A Core of i.MX platforms:
> >1. Adding dts binding for Cortex-A Core remoteproc
> >2. Enable Cortex-A Core remoteproc support in remoteproc driver
> >3. Adding dts example on imx93 platforms.
>
> Normally, we only keep one patch or patch series from the same author that
> modifies the same file in the review queue at a time.
>
> You already have a patch for imx_rproc.c currently under review(got R-b, but
> need Mathieu to handle), so this patch series might be delayed to be reviewed.
>
> As I have replied in internal, to make multiple OS run on Cortex-A SMP without
> hypervsior, some GIC changes are required, without those GIC changes,
> this patchset is not testable using upstream tree.
>
If that is the case, please re-submit when the proper background work on GIC has
been merged.
Mathieu
> Thanks,
> Peng
>
> >
> >Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
> >
> >---
> >Changes in v3:
> >- Fixed dt_binding_check warnings
> >- Updated prefix of patch subject
> >
> >Changes in v2:
> >- Update arch/arm64/boot/dts/freescale/Makefile to add new dts
> >
> >---
> >Hou Zhiqiang (1):
> > remoteproc: imx_rproc: add autoboot support for A-core
> >
> >Jiafei Pan (3):
> > dt-bindings: remoteproc: add imx-rproc-psci
> > remoteproc: imx_rproc: add support for Cortex-A Core
> > arm64: dts: imx93: Cortex-A Core remoteproc device node
> >
> > .../remoteproc/fsl,imx-rproc-psci.yaml | 51 ++++++
> > arch/arm64/boot/dts/freescale/Makefile | 2 +
> > .../imx93-11x11-evk-multicore-rtos.dts | 39 +++++
> > .../imx93-14x14-evk-multicore-rtos.dts | 39 +++++
> > .../boot/dts/freescale/imx93-rproc-ca55.dtsi | 14 ++
> > drivers/remoteproc/imx_rproc.c | 150 ++++++++++++++++++
> > drivers/remoteproc/imx_rproc.h | 2 +
> > 7 files changed, 297 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.yaml
> > create mode 100644 arch/arm64/boot/dts/freescale/imx93-11x11-evk-multicore-rtos.dts
> > create mode 100644 arch/arm64/boot/dts/freescale/imx93-14x14-evk-multicore-rtos.dts
> > create mode 100644 arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi
> >
> >--
> >2.43.0
> >
^ permalink raw reply
* [PATCH v2] tty: serial: atmel: Ignore chars when CREAD is cleared
From: Rakesh Alasyam @ 2026-05-11 16:59 UTC (permalink / raw)
To: gregkh
Cc: richard.genoud, jirislaby, nicolas.ferre, alexandre.belloni,
claudiu.beznea, linux-serial, linux-kernel, linux-arm-kernel,
Rakesh Alasyam
In-Reply-To: <2026051106-obliged-dismount-d85f@gregkh>
Ignore received characters when CREAD is cleared by adding RXRDY
to ignore_status_mask.
This replaces an existing TODO in the driver.
Tested on hardware.
Signed-off-by: Rakesh Alasyam <alasyamrakesh77@gmail.com>
---
v2:
- Add blank line before comment
- Tested on hardware
---
drivers/tty/serial/atmel_serial.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 5d8c1cfc1c60..5c756dc904b0 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -2184,7 +2184,8 @@ static void atmel_set_termios(struct uart_port *port,
if (termios->c_iflag & IGNPAR)
port->ignore_status_mask |= ATMEL_US_OVRE;
}
- /* TODO: Ignore all characters if CREAD is set.*/
+ if (!(termios->c_cflag & CREAD))
+ port->ignore_status_mask |= ATMEL_US_RXRDY;
/* update the per-port timeout */
uart_update_timeout(port, termios->c_cflag, baud);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: Paolo Bonzini @ 2026-05-11 16:56 UTC (permalink / raw)
To: David Woodhouse, Jonathan Corbet, Shuah Khan, kvm, linux-doc,
linux-kernel, Sean Christopherson, Jim Mattson, Marc Zyngier
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Raghavendra Rao Ananta, Eric Auger,
Kees Cook, Arnd Bergmann, Nathan Chancellor, linux-arm-kernel,
kvmarm, linux-kselftest
In-Reply-To: <57bc082f4824d6114d3156744c25986effc29aca.camel@infradead.org>
On 5/11/26 18:38, David Woodhouse wrote:
> Not *everything* is in CPUID; one recent exception that comes to mind
> is the SUPPRESS_EOI_BROADCAST quirk. But on x86 we preserve the
> existing behaviour of older kernels — even when that behaviour doesn't
> make much sense, as with SUPPRESS_EOI_BROADCAST where older KVM would
> *advertise* the feature, but not actually *implement* it. Nevertheless,
> that remains the default behaviour of future kernels unless userspace
> explicitly opts in to fully enable (or disable) the feature.
>
> But this documentation update isn't even asking for that compatible-by-
> default behaviour, even though that is the right thing to do. It's only
> asking that it be *possible* to reinstate the old behaviour, for
> userspace that *knows* about the change and explicitly wants to go back
> to the old way to remain compatible.
Yep, these are the "quirks"---if it's too early for Arm to commit to
that, I guess it's fine.
However, independent of this patch which I (obviously) believe is a good
idea, I'd like to understand how far it is, assuming 1) no quirks 2)
same CPU host.
By the way, you didn't Cc Marc...
Paolo
^ permalink raw reply
* Re: [PATCH] tty: serial: atmel: Ignore chars when CREAD is cleared
From: Greg KH @ 2026-05-11 16:54 UTC (permalink / raw)
To: Rakesh Alasyam
Cc: richard.genoud, jirislaby, nicolas.ferre, alexandre.belloni,
claudiu.beznea, linux-serial, linux-kernel, linux-arm-kernel
In-Reply-To: <20260511155655.26435-1-alasyamrakesh77@gmail.com>
On Mon, May 11, 2026 at 09:26:55PM +0530, Rakesh Alasyam wrote:
> Ignore received characters when CREAD is cleared by adding RXRDY
> to ignore_status_mask.
>
> This replaces an existing TODO in the driver.
>
> Tested on hardware.
>
> Signed-off-by: Rakesh Alasyam <alasyamrakesh77@gmail.com>
>
> ---
>
> v2:
> - Add blank line before comment
> - Tested on hardware
> ---
> drivers/tty/serial/atmel_serial.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 5d8c1cfc1c60..5c756dc904b0 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -2184,7 +2184,8 @@ static void atmel_set_termios(struct uart_port *port,
> if (termios->c_iflag & IGNPAR)
> port->ignore_status_mask |= ATMEL_US_OVRE;
> }
> - /* TODO: Ignore all characters if CREAD is set.*/
> + if (!(termios->c_cflag & CREAD))
> + port->ignore_status_mask |= ATMEL_US_RXRDY;
>
> /* update the per-port timeout */
> uart_update_timeout(port, termios->c_cflag, baud);
> --
> 2.43.0
>
No v2 in the subject line :(
^ permalink raw reply
* Re: [PATCHv3] ARM: omap2: simplify allocation for omap_device
From: Kevin Hilman @ 2026-05-11 16:51 UTC (permalink / raw)
To: linux-omap, Rosen Penev
Cc: Aaro Koskinen, Andreas Kemnade, Roger Quadros, Tony Lindgren,
Russell King, Kees Cook, Gustavo A. R. Silva, linux-arm-kernel,
linux-kernel, linux-hardening
In-Reply-To: <20260330213528.18187-1-rosenp@gmail.com>
On Mon, 30 Mar 2026 14:35:28 -0700, Rosen Penev wrote:
> Use a flexible array member (FAM) to combine hwmods array allocation
> with the omap_device structure. This reduces the number of allocations
> from two separate calls (one for the device, one for the array) to a
> single allocation, improving efficiency and reducing memory fragmentation.
>
> The FAM approach also enables bounds checking through __counted_by(),
> which provides runtime verification that array accesses stay within
> the allocated size. This improves security and helps catch bugs during
> development.
>
> [...]
Applied, thanks!
[1/1] ARM: omap2: simplify allocation for omap_device
commit: 2a7a9e20b9e8b5dc4fdef777e67d390dcb3a8ea4
Best regards,
--
Kevin Hilman (TI) <khilman@baylibre.com>
^ permalink raw reply
* Re: [PATCH] pmdomain: ti_sci: add wakeup constraint to parent devices of wakeup source
From: Vitor Soares @ 2026-05-11 16:51 UTC (permalink / raw)
To: Kendall Willis, Nishanth Menon, Tero Kristo, Santosh Shilimkar,
Ulf Hansson, Kevin Hilman, Dhruva Gole
Cc: linux-arm-kernel, linux-pm, linux-kernel, stable, tomi.valkeinen,
sebin.francis, devarsht, vigneshr, vishalm, vitor.soares
In-Reply-To: <20260506-wkup-constraint-v1-1-0a4bce791b29@ti.com>
Hi Kendall,
On Wed, 2026-05-06 at 22:16 -0500, Kendall Willis wrote:
> Set wakeup constraint for any device in a wakeup path. All parent devices
> of a wakeup device should not be turned off during suspend. This ensures
> the wakeup device is kept on while the system is suspended.
>
Thanks for the patch.
I tested it on our Verdin AM62P. As expected, suspend now fails cleanly with "-
19" when an SDIO WiFi module is registered as a wakeup source, instead of
crashing on resume:
ti-sci 44043000.system-controller: PM: failed to suspend: error -19
I did not test the IO daisy chain wakeup path, since that is out of scope for
this patch.
Best regards,
Vitor Soares
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Shah, Tanmay @ 2026-05-11 16:47 UTC (permalink / raw)
To: Arnaud POULIQUEN, tanmay.shah, Beleswar Prasad Padhi,
Mathieu Poirier
Cc: 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: <da3b79b7-9dad-48cb-b552-cf6df445899f@amd.com>
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 ?
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.
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 v6 11/11] drm: of: forbid bridge-only calls to drm_of_find_panel_or_bridge()
From: Luca Ceresoli @ 2026-05-11 16:40 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Sumit Semwal, John Stultz, Tomi Valkeinen,
Michal Simek
Cc: Hui Pu, Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel,
linux-arm-msm, freedreno, linux-arm-kernel, Luca Ceresoli,
Dmitry Baryshkov, Laurent Pinchart
In-Reply-To: <20260511-drm-bridge-alloc-getput-panel_or_bridge-v6-0-f61c9e498b3f@bootlin.com>
Up to now drm_of_find_panel_or_bridge() can be called with a bridge pointer
only, a panel pointer only, or both a bridge and a panel pointers. The
logic to handle all the three cases is somewhat complex to read however.
Now all bridge-only callers have been converted to
of_drm_get_bridge_by_endpoint(), which is simpler and handles bridge
refcounting. So forbid new bridge-only users by mandating a non-NULL panel
pointer in the docs and in the sanity checks along with a warning.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
drivers/gpu/drm/drm_of.c | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index ef6b09316963..d03ada82eac9 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -225,15 +225,15 @@ EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint);
* @np: device tree node containing encoder output ports
* @port: port in the device tree node
* @endpoint: endpoint in the device tree node
- * @panel: pointer to hold returned drm_panel
+ * @panel: pointer to hold returned drm_panel, must not be NULL
* @bridge: pointer to hold returned drm_bridge
*
* Given a DT node's port and endpoint number, find the connected node and
- * return either the associated struct drm_panel or drm_bridge device. Either
- * @panel or @bridge must not be NULL.
+ * return either the associated struct drm_panel or drm_bridge device.
*
* This function is deprecated and should not be used in new drivers. Use
- * devm_drm_of_get_bridge() instead.
+ * of_drm_get_bridge_by_endpoint() instead when not looking for a panel, or
+ * devm_drm_of_get_bridge() otherwise.
*
* Returns zero if successful, or one of the standard error codes if it fails.
*/
@@ -245,10 +245,10 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
int ret = -EPROBE_DEFER;
struct device_node *remote;
- if (!panel && !bridge)
+ if (WARN_ON(!panel))
return -EINVAL;
- if (panel)
- *panel = NULL;
+
+ *panel = NULL;
/*
* of_graph_get_remote_node() produces a noisy error message if port
@@ -263,13 +263,11 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
if (!remote)
return -ENODEV;
- if (panel) {
- *panel = of_drm_find_panel(remote);
- if (!IS_ERR(*panel))
- ret = 0;
- else
- *panel = NULL;
- }
+ *panel = of_drm_find_panel(remote);
+ if (!IS_ERR(*panel))
+ ret = 0;
+ else
+ *panel = NULL;
if (bridge) {
if (ret) {
--
2.54.0
^ permalink raw reply related
* [PATCH v6 10/11] drm: zynqmp_dp: switch to of_drm_get_bridge_by_endpoint()
From: Luca Ceresoli @ 2026-05-11 16:40 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Sumit Semwal, John Stultz, Tomi Valkeinen,
Michal Simek
Cc: Hui Pu, Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel,
linux-arm-msm, freedreno, linux-arm-kernel, Luca Ceresoli,
Laurent Pinchart
In-Reply-To: <20260511-drm-bridge-alloc-getput-panel_or_bridge-v6-0-f61c9e498b3f@bootlin.com>
This driver calls drm_of_find_panel_or_bridge() with a NULL pointer in the
@panel parameter, thus using a reduced feature set of that function.
Replace this call with the simpler of_drm_get_bridge_by_endpoint().
Since of_drm_get_bridge_by_endpoint() increases the refcount of the
returned bridge, ensure it is put on removal. To achieve this, instead of
adding an explicit drm_bridge_put(), migrate to the bridge::next_bridge
pointer which is automatically put when the bridge is eventually freed.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v4:
- fix missing assignment
- simplify error management code flow
Changes in v3:
- fix ERR_PTR deref when -ENODEV is returned
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index 05bd31fe675b..7fb11b0a44f0 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -353,7 +353,6 @@ struct zynqmp_dp_train_set_priv {
* @lock: Mutex protecting this struct and register access (but not AUX)
* @irq: irq
* @bridge: DRM bridge for the DP encoder
- * @next_bridge: The downstream bridge
* @test: Configuration for test mode
* @config: IP core configuration from DTS
* @aux: aux channel
@@ -385,7 +384,6 @@ struct zynqmp_dp {
struct completion aux_done;
struct mutex lock;
- struct drm_bridge *next_bridge;
struct device *dev;
struct zynqmp_dpsub *dpsub;
void __iomem *iomem;
@@ -1494,8 +1492,8 @@ static int zynqmp_dp_bridge_attach(struct drm_bridge *bridge,
return ret;
}
- if (dp->next_bridge) {
- ret = drm_bridge_attach(encoder, dp->next_bridge,
+ if (dp->bridge.next_bridge) {
+ ret = drm_bridge_attach(encoder, dp->bridge.next_bridge,
bridge, flags);
if (ret < 0)
goto error;
@@ -2461,10 +2459,15 @@ int zynqmp_dp_probe(struct zynqmp_dpsub *dpsub)
* Acquire the next bridge in the chain. Ignore errors caused by port@5
* not being connected for backward-compatibility with older DTs.
*/
- ret = drm_of_find_panel_or_bridge(dp->dev->of_node, 5, 0, NULL,
- &dp->next_bridge);
- if (ret < 0 && ret != -ENODEV)
- goto err_reset;
+ dp->bridge.next_bridge = of_drm_get_bridge_by_endpoint(dp->dev->of_node, 5, 0);
+ if (IS_ERR(dp->bridge.next_bridge)) {
+ if (PTR_ERR(dp->bridge.next_bridge) != -ENODEV) {
+ ret = PTR_ERR(dp->bridge.next_bridge);
+ goto err_reset;
+ }
+
+ dp->bridge.next_bridge = NULL;
+ }
/* Initialize the hardware. */
dp->config.misc0 &= ~ZYNQMP_DP_MAIN_STREAM_MISC0_SYNC_LOCK;
--
2.54.0
^ permalink raw reply related
* [PATCH v6 09/11] drm/bridge: lt8713sx: switch to of_drm_get_bridge_by_endpoint()
From: Luca Ceresoli @ 2026-05-11 16:40 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Sumit Semwal, John Stultz, Tomi Valkeinen,
Michal Simek
Cc: Hui Pu, Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel,
linux-arm-msm, freedreno, linux-arm-kernel, Luca Ceresoli,
Dmitry Baryshkov
In-Reply-To: <20260511-drm-bridge-alloc-getput-panel_or_bridge-v6-0-f61c9e498b3f@bootlin.com>
This driver calls drm_of_find_panel_or_bridge() with a NULL pointer in the
@panel parameter, thus using a reduced feature set of that function.
Replace this call with the simpler of_drm_get_bridge_by_endpoint().
Since of_drm_get_bridge_by_endpoint() increases the refcount of the
returned bridge, ensure it is put on removal. To achieve this, instead of
adding an explicit drm_bridge_put(), migrate to the bridge::next_bridge
pointer which is automatically put when the bridge is eventually freed.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
drivers/gpu/drm/bridge/lontium-lt8713sx.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt8713sx.c b/drivers/gpu/drm/bridge/lontium-lt8713sx.c
index 18fac6a46db4..cee485adf5e5 100644
--- a/drivers/gpu/drm/bridge/lontium-lt8713sx.c
+++ b/drivers/gpu/drm/bridge/lontium-lt8713sx.c
@@ -32,7 +32,6 @@ DECLARE_CRC8_TABLE(lt8713sx_crc_table);
struct lt8713sx {
struct device *dev;
struct drm_bridge bridge;
- struct drm_bridge *next_bridge;
struct regmap *regmap;
/* Protects all accesses to registers by stopping the on-chip MCU */
@@ -458,7 +457,7 @@ static int lt8713sx_bridge_attach(struct drm_bridge *bridge,
struct lt8713sx *lt8713sx = container_of(bridge, struct lt8713sx, bridge);
return drm_bridge_attach(encoder,
- lt8713sx->next_bridge,
+ lt8713sx->bridge.next_bridge,
bridge, flags);
}
@@ -537,10 +536,9 @@ static int lt8713sx_probe(struct i2c_client *client)
if (IS_ERR(lt8713sx->regmap))
return dev_err_probe(dev, PTR_ERR(lt8713sx->regmap), "regmap i2c init failed\n");
- ret = drm_of_find_panel_or_bridge(lt8713sx->dev->of_node, 1, -1, NULL,
- <8713sx->next_bridge);
- if (ret < 0)
- return ret;
+ lt8713sx->bridge.next_bridge = of_drm_get_bridge_by_endpoint(lt8713sx->dev->of_node, 1, -1);
+ if (IS_ERR(lt8713sx->bridge.next_bridge))
+ return PTR_ERR(lt8713sx->bridge.next_bridge);
ret = lt8713sx_gpio_init(lt8713sx);
if (ret < 0)
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox