On Wed, 2021-01-20 at 15:32 -0800, Jakub Kicinski wrote: > On Wed, 20 Jan 2021 20:34:51 +0100 Andrew Lunn wrote: > > On Sun, Jan 17, 2021 at 06:26:54PM +0100, Bjørn Mork wrote: > > > I was young and stupid. Now I'm not that young anymore ;-) > > > > We all make mistakes, when we don't have the knowledge there are > > other > > ways. That is partially what code review is about. > > > > > Never ever imagined that this would be replicated in another > > > driver, > > > though. That doesn't really make much sense. We have learned by > > > now, > > > haven't we? This subject has been discussed a few times in the > > > past, > > > and Johannes summary is my understanding as well: > > > "I don't think anyone likes that" > > > > So there seems to be agreement there. But what is not clear, is > > anybody willing to do the work to fix this, and is there enough > > ROI. > > > > Do we expect more devices like this? Will 6G, 7G modems look very > > different? > > Didn't Intel sell its 5G stuff off to Apple? Yes, but they kept the ability to continue with 3G/4G hardware and other stuff. > > Be real network devices and not need any of this odd stuff? > > Or will they be just be incrementally better but mostly the same? > > > > I went into the review thinking it was an Ethernet driver, and kept > > having WTF moments. Now i know it is not an Ethernet driver, i can > > say > > it is not my domain, i don't know the field well enough to say if > > all > > these hacks are acceptable or not. > > > > It probably needs David and Jakub to set the direction to be > > followed. > > AFAIU all those cellar modems are relatively slow and FW-heavy, so > the > ideal solution IMO is not even a common kernel interface but actually > a common device interface, like NVMe (or virtio for lack of better > examples). That was supposed to be MBIM, but unfortunately those involved didn't iterate and MBIM got stuck. I don't think we'll see a standard as long as some vendors are dominant and see no need for it. Dan
