On Wed, 18 Mar 2026 at 12:46, Shenwei Wang <[email protected]> wrote: > > > > > -----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. >
All arguments have already been presented to you, we are now going in circles. I am happy to look at a new revision of this work that complies with the comments Andrew, Arnaud and I provided. I will not engage with you or your work until that time comes. > @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 > > >
