Hi Andi, On Tue, 26 Sep 2023 23:27:20 +0200, Andi Shyti wrote: > On Tue, Sep 26, 2023 at 01:37:25PM +0200, Jean Delvare wrote: > > The i2c-amd756-s4882 and i2c-nforce2-s4985 muxing pseudo-drivers were > > written at a time when the i2c core did not support muxing. They are > > essentially board-specific hacks. If we had to add support for these > > boards today, we would implement it in a completely different way. > > > > These Tyan server boards are 18 years old by now, so I very much doubt > > any of these is still running today. So let's just drop this clumsy > > code. If anyone really still needs this support and complains, I'll > > rewrite it in a proper way on top of i2c-mux. > > do you have such devices? I don't. If I did, I would have written proper muxing code for them long ago. > I'm somewhat conflicted, on one hand I like the cleanup. But on > the other I think that they don't do any harm if they stay where > they are. Every piece of code which lives in the kernel tree has a maintenance cost. As a matter of fact, these 2 "drivers" were affected by 6 tree-wide or subsystem-wide changes over the last 14 years. No actual driver-specific change was applied during that period of time. Currently these "drivers" also cause build-time warnings (with W=1), which Nick understandably wanted to clear, and this is even the reason why I looked into that and wrote this removal patch. > There are lots of drivers that look outdated and need > maintenance, we can't just remove them... right? Actually we can, and should, if we suspect there are no users left. There's absolutely no reason to spend time maintaining and building old drivers which have no users left. Unused drivers also take disk space and network bandwidth world-wide, and represent an additional attack surface from a security perspective. -- Jean Delvare SUSE L3 Support
