All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rocco Yue <rocco.yue@mediatek.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	David Ahern <dsahern@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Felix Fietkau <nbd@nbd.name>, John Crispin <john@phrozen.org>,
	Sean Wang <sean.wang@mediatek.com>,
	Mark Lee <Mark-MC.Lee@mediatek.com>, <netdev@vger.kernel.org>,
	<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>, <bpf@vger.kernel.org>,
	<wsd_upstream@mediatek.com>, <chao.song@mediatek.com>,
	<kuohong.wang@mediatek.com>, Rocco Yue <rocco.yue@mediatek.com>
Subject: Re: [PATCH 4/4] drivers: net: mediatek: initial implementation of ccmni
Date: Mon, 28 Jun 2021 15:18:30 +0800	[thread overview]
Message-ID: <20210628071829.14925-1-rocco.yue@mediatek.com> (raw)
In-Reply-To: <YNS4GzYHpxMWIH+1@kroah.com>

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

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.

In addition, due to the requirements of GKI 2.0, 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.

Thanks,
Rocco


WARNING: multiple messages have this Message-ID (diff)
From: Rocco Yue <rocco.yue@mediatek.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	David Ahern <dsahern@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Felix Fietkau <nbd@nbd.name>, John Crispin <john@phrozen.org>,
	Sean Wang <sean.wang@mediatek.com>,
	Mark Lee <Mark-MC.Lee@mediatek.com>, <netdev@vger.kernel.org>,
	<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,  <bpf@vger.kernel.org>,
	<wsd_upstream@mediatek.com>, <chao.song@mediatek.com>,
	 <kuohong.wang@mediatek.com>, Rocco Yue <rocco.yue@mediatek.com>
Subject: Re: [PATCH 4/4] drivers: net: mediatek: initial implementation of ccmni
Date: Mon, 28 Jun 2021 15:18:30 +0800	[thread overview]
Message-ID: <20210628071829.14925-1-rocco.yue@mediatek.com> (raw)
In-Reply-To: <YNS4GzYHpxMWIH+1@kroah.com>

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

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.

In addition, due to the requirements of GKI 2.0, 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.

Thanks,
Rocco
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Rocco Yue <rocco.yue@mediatek.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	David Ahern <dsahern@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Felix Fietkau <nbd@nbd.name>, John Crispin <john@phrozen.org>,
	Sean Wang <sean.wang@mediatek.com>,
	Mark Lee <Mark-MC.Lee@mediatek.com>, <netdev@vger.kernel.org>,
	<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,  <bpf@vger.kernel.org>,
	<wsd_upstream@mediatek.com>, <chao.song@mediatek.com>,
	 <kuohong.wang@mediatek.com>, Rocco Yue <rocco.yue@mediatek.com>
Subject: Re: [PATCH 4/4] drivers: net: mediatek: initial implementation of ccmni
Date: Mon, 28 Jun 2021 15:18:30 +0800	[thread overview]
Message-ID: <20210628071829.14925-1-rocco.yue@mediatek.com> (raw)
In-Reply-To: <YNS4GzYHpxMWIH+1@kroah.com>

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

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.

In addition, due to the requirements of GKI 2.0, 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.

Thanks,
Rocco
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-06-28  7:34 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-23 11:34 [PATCH 1/4] net: if_arp: add ARPHRD_PUREIP type Rocco Yue
2021-06-23 11:34 ` Rocco Yue
2021-06-23 11:34 ` Rocco Yue
2021-06-23 11:34 ` [PATCH 2/4] net: ipv6: don't generate link local address on PUREIP device Rocco Yue
2021-06-23 11:34   ` Rocco Yue
2021-06-23 11:34   ` Rocco Yue
2021-06-23 11:34 ` [PATCH 3/4] net: dev_is_mac_header_xmit() return false for ARPHRD_PUREIP Rocco Yue
2021-06-23 11:34   ` Rocco Yue
2021-06-23 11:34   ` Rocco Yue
2021-06-23 11:34 ` [PATCH 4/4] drivers: net: mediatek: initial implementation of ccmni Rocco Yue
2021-06-23 11:34   ` Rocco Yue
2021-06-23 11:34   ` Rocco Yue
2021-06-23 17:25   ` Greg KH
2021-06-23 17:25     ` Greg KH
2021-06-23 17:25     ` Greg KH
2021-06-23 17:26   ` kernel test robot
2021-06-23 17:31   ` Greg KH
2021-06-23 17:31     ` Greg KH
2021-06-23 17:31     ` Greg KH
2021-06-24 11:53     ` [PATCH 1/4] net: if_arp: add ARPHRD_PUREIP type Rocco Yue
2021-06-24 11:53       ` Rocco Yue
2021-06-24 11:53       ` Rocco Yue
2021-06-24 12:23       ` Greg KH
2021-06-24 12:23         ` Greg KH
2021-06-24 12:23         ` Greg KH
2021-06-24 15:55         ` [PATCH 4/4] drivers: net: mediatek: initial implementation of ccmni Rocco Yue
2021-06-24 15:55           ` Rocco Yue
2021-06-24 15:55           ` Rocco Yue
2021-06-24 16:51           ` Greg KH
2021-06-24 16:51             ` Greg KH
2021-06-24 16:51             ` Greg KH
2021-06-28  7:18             ` Rocco Yue [this message]
2021-06-28  7:18               ` Rocco Yue
2021-06-28  7:18               ` Rocco Yue
2021-06-28  9:30               ` Greg KH
2021-06-28  9:30                 ` Greg KH
2021-06-28  9:30                 ` Greg KH
2021-06-23 17:19 ` [PATCH 1/4] net: if_arp: add ARPHRD_PUREIP type Greg KH
2021-06-23 17:19   ` Greg KH
2021-06-23 17:19   ` Greg KH
2021-06-24  3:33   ` Rocco Yue
2021-06-24  3:33     ` Rocco Yue
2021-06-24  3:33     ` Rocco Yue
2021-06-24  5:15     ` David Ahern
2021-06-24  5:15       ` David Ahern
2021-06-24  5:15       ` David Ahern
2021-06-24  5:31       ` Rocco Yue
2021-06-24  5:31         ` Rocco Yue
2021-06-24  5:31         ` Rocco Yue
2021-06-24  5:29     ` Greg KH
2021-06-24  5:29       ` Greg KH
2021-06-24  5:29       ` Greg KH
2021-06-24  6:13       ` Rocco Yue
2021-06-24  6:13         ` Rocco Yue
2021-06-24  6:13         ` Rocco Yue
2021-06-24  9:04         ` Greg KH
2021-06-24  9:04           ` Greg KH
2021-06-24  9:04           ` Greg KH
2021-06-24 12:24           ` Rocco Yue
2021-06-24 12:24             ` Rocco Yue
2021-06-24 12:24             ` Rocco Yue
2021-06-24 13:06             ` Greg KH
2021-06-24 13:06               ` Greg KH
2021-06-24 13:06               ` Greg KH
2021-06-25  6:01               ` Rocco Yue
2021-06-25  6:01                 ` Rocco Yue
2021-06-25  6:01                 ` Rocco Yue
2021-06-24 16:14         ` Dan Williams
2021-06-24 16:14           ` Dan Williams
2021-06-24 16:14           ` Dan Williams
2021-06-25  6:04           ` Rocco Yue
2021-06-25  6:04             ` Rocco Yue
2021-06-25  6:04             ` Rocco Yue

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=20210628071829.14925-1-rocco.yue@mediatek.com \
    --to=rocco.yue@mediatek.com \
    --cc=Mark-MC.Lee@mediatek.com \
    --cc=bpf@vger.kernel.org \
    --cc=chao.song@mediatek.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=john@phrozen.org \
    --cc=kuba@kernel.org \
    --cc=kuohong.wang@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=sean.wang@mediatek.com \
    --cc=wsd_upstream@mediatek.com \
    --cc=yoshfuji@linux-ipv6.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.