All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: Jakub Kicinski <kuba@kernel.org>, Andrew Lunn <andrew@lunn.ch>
Cc: "Bjørn Mork" <bjorn@mork.no>,
	"M Chetan Kumar" <m.chetan.kumar@intel.com>,
	netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
	johannes@sipsolutions.net, krishna.c.sudi@intel.com
Subject: Re: [PATCH 17/18] net: iosm: readme file
Date: Wed, 20 Jan 2021 19:34:48 -0600	[thread overview]
Message-ID: <82243bc066a12235099639928a271a8fe338668e.camel@redhat.com> (raw)
In-Reply-To: <20210120153255.4fcf7e32@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

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


  reply	other threads:[~2021-01-21  3:37 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-07 17:05 [PATCH 00/18] net: iosm: PCIe Driver for Intel M.2 Modem M Chetan Kumar
2021-01-07 17:05 ` [PATCH 01/18] net: iosm: entry point M Chetan Kumar
2021-01-07 17:05 ` [PATCH 02/18] net: iosm: irq handling M Chetan Kumar
2021-01-07 17:05 ` [PATCH 03/18] net: iosm: mmio scratchpad M Chetan Kumar
2021-01-07 17:05 ` [PATCH 04/18] net: iosm: shared memory IPC interface M Chetan Kumar
2021-01-07 17:05 ` [PATCH 05/18] net: iosm: shared memory I/O operations M Chetan Kumar
2021-01-07 17:05 ` [PATCH 06/18] net: iosm: channel configuration M Chetan Kumar
2021-01-07 17:05 ` [PATCH 07/18] net: iosm: char device for FW flash & coredump M Chetan Kumar
2021-01-07 19:35   ` Andrew Lunn
2021-01-07 17:05 ` [PATCH 08/18] net: iosm: MBIM control device M Chetan Kumar
2021-01-07 17:05 ` [PATCH 09/18] net: iosm: bottom half M Chetan Kumar
2021-01-07 17:05 ` [PATCH 10/18] net: iosm: multiplex IP sessions M Chetan Kumar
2021-01-07 17:05 ` [PATCH 11/18] net: iosm: encode or decode datagram M Chetan Kumar
2021-01-07 21:56   ` Andrew Lunn
2021-01-07 17:05 ` [PATCH 12/18] net: iosm: power management M Chetan Kumar
2021-01-07 17:05 ` [PATCH 13/18] net: iosm: shared memory protocol M Chetan Kumar
2021-01-07 17:05 ` [PATCH 14/18] net: iosm: protocol operations M Chetan Kumar
2021-01-07 17:05 ` [PATCH 15/18] net: iosm: uevent support M Chetan Kumar
2021-01-07 17:05 ` [PATCH 16/18] net: iosm: net driver M Chetan Kumar
2021-01-07 20:11   ` Andrew Lunn
2021-01-07 17:05 ` [PATCH 17/18] net: iosm: readme file M Chetan Kumar
2021-01-07 22:23   ` Andrew Lunn
2021-01-15  9:15     ` Johannes Berg
2021-01-17 17:26     ` Bjørn Mork
2021-01-20 19:34       ` Andrew Lunn
2021-01-20 23:32         ` Jakub Kicinski
2021-01-21  1:34           ` Dan Williams [this message]
2021-01-22 23:45             ` Andrew Lunn
2021-01-07 17:05 ` [PATCH 18/18] net: iosm: infrastructure M Chetan Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=82243bc066a12235099639928a271a8fe338668e.camel@redhat.com \
    --to=dcbw@redhat.com \
    --cc=andrew@lunn.ch \
    --cc=bjorn@mork.no \
    --cc=johannes@sipsolutions.net \
    --cc=krishna.c.sudi@intel.com \
    --cc=kuba@kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=m.chetan.kumar@intel.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.