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://lwn.net/ml/all/[email protected]/ > > 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. > 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 >
