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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).