> -----Original Message----- > From: Mathieu Poirier <[email protected]> > Sent: Wednesday, March 18, 2026 11:03 AM > To: Andrew Lunn <[email protected]> > Cc: Arnaud POULIQUEN <[email protected]>; Shenwei Wang > <[email protected]>; Linus Walleij <[email protected]>; Bartosz > Golaszewski <[email protected]>; Jonathan Corbet <[email protected]>; Rob Herring > <[email protected]>; Krzysztof Kozlowski <[email protected]>; Conor Dooley > <[email protected]>; Bjorn Andersson <[email protected]>; Frank Li > <[email protected]>; Sascha Hauer <[email protected]>; Shuah Khan > <[email protected]>; [email protected]; linux- > [email protected]; [email protected]; Pengutronix Kernel Team > <[email protected]>; Fabio Estevam <[email protected]>; Peng Fan > <[email protected]>; [email protected]; linux- > [email protected]; [email protected]; linux-arm- > [email protected]; dl-linux-imx <[email protected]>; Bartosz > Golaszewski <[email protected]> > Subject: [EXT] Re: [PATCH v12 3/5] gpio: rpmsg: add generic rpmsg GPIO driver > On Tue, 17 Mar 2026 at 08:11, Andrew Lunn <[email protected]> wrote: > > > > > > +struct rpmsg_gpio_info { > > > > + struct rpmsg_device *rpdev; > > > > + struct rpmsg_gpio_packet *reply_msg; > > > > + struct completion cmd_complete; > > > > + struct mutex lock; > > > > + void **port_store; > > > > +}; > > > > > > Except if I missunderstood Mathieu and Bjorn's request: > > > "reuse all the design-work done in the gpio-virtio" > > > We should find similar structures here to those defined in > > > virtio_gpio.h. > > > struct rpmsg_gpio_config { > > > __le16 ngpio; > > > __u8 padding[2]; > > > __le32 gpio_names_size; > > > }; > > > > > > /* Virtio GPIO Request / Response */ struct virtio_gpio_request { > > > __le16 type; > > > __le16 gpio; > > > __le32 value; > > > }; > > > > The core of the issue is that Shenwei is stone walling any change > > which makes it hard to keep the legacy firmware. It is possible to use > > these structures, but it makes the extra code Shenwei needs to > > translate this protocol to the legacy protocol more difficult. It > > might need to keep state, etc. > > > > I agree with everything Andrew points out above. > > > Two points... > > > > The firmware implements more than GPIO. There is definitely I2C as > > well, the first version of the patch has bits of I2C code. Looking at: > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn. > > net%2Fml%2Fall%2F20250922200413.309707-3- > shenwei.wang%40nxp.com%2F&dat > > > a=05%7C02%7Cshenwei.wang%40nxp.com%7C4b8879a9c89a4a831cf508de850 > 7de18% > > > 7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C639094465992371367% > 7CUnkn > > > own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl > AiOiJX > > > aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=s8tl8n > m3eD > > 9l%2FetyyE%2FPWwJh4wQalaaHr4OEwzpQ7NY%3D&reserved=0 > > > > There is also RTC, and a few other things which don't directly map to > > Linux subsystems, but maybe do have Linux drivers? > > > > Give how much pushback there has been on the existing protocol for > > GPIO, it would be wise to assume that I2C, and RTC is going to get the > > same amount of pushback. If any of these three, GPIO, I2C, or RTC > > decide that only a new, clean protocol will be accepted, no legacy > > shims, the firmware has to change, breaking compatibility to legacy > > protocols, and the accepted shims become pointless Maintenance burden. > > > > I have made this point clear before: modeling legacy protocols in mainline > doesn't > scale. Mainline uses a single generic protocol, and yes, it means breaking > legacy > protocols. This is the cost of moving to a mainline kernel. If people want > to use > the legacy firmware, they must stick with a legacy kernel. > > > Point two is that the customers who are pushing for these drivers to > > be added to Mainline probably know that nearly nothing gets into > > Mainline without some changes. There is some short term pain to > > swapping to Mainline because of these changes, in this case, firmware > > upgrades. But in the long run, it is worth the pain to be able to use > > Mainline. And those customers who don't want to upgrade the firmware > > can keep with the out of tree drives. > > > > So, what are our choices? > > > > 1) We accept the code as it is now, with the shim? > > > > NAK > > > 2) We keep pushing for the virtio protocol, with the shim? > > > > NAK > > > 3) We keep pushing for the virtio protocol, no shim, firmware changes > > > > Nothing will get merged in the RPMSG subsystem that includes support for the > legacy protocol. Not today, not in a month, not in 5 years. >
@Mathieu, Your tone is unnecessary. If you believe this driver must comply with a specific virtio protocol, then please point to the exact specification instead of making blanket statements. If virtio is the direction you prefer, you are of course free to propose and implement such support yourself. My patches are contributed in good faith to improve the ecosystem, and this work clearly belongs to the GPIO subsystem. I don't understand why you are asserting authority here without providing any technical justification. @Linus Walleij, From a technical standpoint, this GPIO driver is no different from gpio-mxc, gpio-omap, or gpio-rda. If the concern is simply the use of the word “generic” in the name, I’m perfectly fine reverting it to an NXP‑specific driver. If maintaining a private GPIO driver is no longer acceptable going forward, that’s also fine — we can stop the discussion here. If you think there are still technical limitations in the driver itself, I’m more than willing to continue improving it. But the goal is not to create a driver for another protocol that someone claims perfect. Thanks, Shenwei > > 4) We pause GPIO where it is today, and restart all the arguments with > > the I2C driver. We can come back to the GPIO driver in a few months > > time once we have a better idea how I2C is going. And maybe we also > > need to see the watchdog driver, and argue about its protocol. > > > > I also understand ST has a generic I2C driver nearly ready, if that > > gets merged first, that probably kills the NXP I2C protocol, and maybe > > the NXP GPIO and RTC protocols. > > > > My vote is for 3. If not 3, then 4. > > > > Strong vote for 3. > > > Andrew > >
