Re: [PATCH 17/18] net: iosm: readme file

[Andrew Lunn <andrew@lunn.ch>]

On Wed, Jan 20, 2021 at 07:34:48PM -0600, Dan Williams wrote:
> 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.

But we can expect 6G in what, 2030? And 7G in 2040? Are they going to
look different? Or is it going to be more of the same, meaningless
ethernet headers, VLANs where VLANs make little sense?

> > > 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.

We the kernel community need to decide, we are happy for this broken
architecture to live on, and we should give suggest how to make this
submission better. Or we need to push back and say for the long term
good, this driver is not going to be accepted, use a more sensible
architecture.

	Andrew