On Mon, Jun 28, 2021 at 03:18:30PM +0800, Rocco Yue wrote:

On Thu, 2021-06-24 at 18:51 +0200, Greg KH wrote:
On Thu, Jun 24, 2021 at 11:55:02PM +0800, Rocco Yue wrote:

quoted

quoted

On Thu, 2021-06-24 at 14:23 +0200, Greg KH wrote:
On Thu, Jun 24, 2021 at 07:53:49PM +0800, Rocco Yue wrote:

quoted

not have exports that no one uses.  Please add the driver to this patch
series when you resend it.

I've just took a look at what the Linux staging tree is. It looks like
a good choice for the current ccmni driver.

honstly, If I simply upload the relevant driver code B that calls
A (e.g. ccmni_rx_push), there is still a lack of code to call B.
This seems to be a continuty problem, unless all drivers codes are
uploaded (e.g. power on modem, get hardware status, complete tx/rx flow).

Great, send it all!  Why is it different modules, it's only for one
chunk of hardware, no need to split it up into tiny pieces.  That way
only causes it to be more code overall.

quoted

Thanks~

Can I resend patch set as follows:
(1) supplement the details of pureip for patch 1/4;
(2) the document of ccmni.rst still live in the Documentation/...
(3) modify ccmni and move it into the drivers/staging/...

for drivers/staging/ the code needs to be "self contained" in that it
does not require adding anything outside of the directory for it.

If you still require this core networking change, that needs to be
accepted first by the networking developers and maintainers.

thanks,

greg k-h

Hi Greg,

I am grateful for your help.

Both ccmni change and networking changes are needed, because as far
as I know, usually a device type should have at least one device to
use it, and pureip is what the ccmni driver needs, so I uploaded the
networking change and ccmni driver together;

Since MTK’s modem driver has a large amount of code and strong code
coupling, it takes some time to clean up them. At this stage, it may
be difficult to upstream all the codes together.

Why?  Just dump the whole thing in a drivers/staging/mtk/ directory
structure and all should be fine.

During this period, even if ccmni is incomplete, can I put the ccmni
driver initial code in the driver/staging first ? After that, we will
gradually implement more functions of ccmni in the staging tree, and
we can also gradually sort out and clean up modem driver in the staging.

I do not know, let's see the code first.  But we can not add frameworks
with no in-kernel users, as that does not make any sense at all.

In addition, due to the requirements of GKI 2.0,

That is a Google requirement, not a kernel.org requirement.  Please work
with Google if you have questions/issues about that, there is NOTHING we
can do about that here in the community for obvious reasons.

if ccmni device
uses RAWIP or NONE, it will hit ipv6 issue; and if ccmni uses
a device type other than PUREIP/RAWIP/NONE, there will be tethering
ebpf offload or clat ebpf offload can not work problems.

I hope PUREIP and ccmni can be accepted by the Linux community.

As I stated before you need to have an in-kernel user for us to be able
to accept frameworks and functions into the tree.  Otherwise Linux would
quickly become unmanagable and unmaintainable.  Would you want to try to
maintain code with no in-tree users?  What would you do if you were in
our position?

But for networking flags like this that go into userspace, I do not know
what the maintainers of the networking stack require, so that really is
up to them, not me.

thanks,

greg k-h