Patch looks fine to me. But I don't think you can submit a net and usb
serial patch in a series. These are two different subsystems.
There's no dependency between the patches so you can just submit
them as standalone patches. I.e. no series.
Feel free to include
Acked-by: Bjørn Mork <bjorn@mork.no>
Patch looks fine to me. But I don't think you can submit a net and usb
serial patch in a series. These are two different subsystems.
There's no dependency between the patches so you can just submit
them as standalone patches. I.e. no series.
Actually, there is, and I just noticed, that patches are in wrong order.
Without patch 2/2 for 'option' driver, there is possibility for that
driver to steal
interface 3 from qmi_wwan, as currently it will match interface 3 as
ff/ff/ff.
With that in mind I'm not really sure how to proceed.
What comes to my mind, is either submit this as series again, with
ordering swapped,
or submit 2/2 first, wait for it to become merged, and then submit 1/2.
Feel free to include
Acked-by: Bjørn Mork<bjorn@mork.no>
Patch looks fine to me. But I don't think you can submit a net and usb
serial patch in a series. These are two different subsystems.
There's no dependency between the patches so you can just submit
them as standalone patches. I.e. no series.
Actually, there is, and I just noticed, that patches are in wrong order.
Without patch 2/2 for 'option' driver, there is possibility for that
driver to steal
interface 3 from qmi_wwan, as currently it will match interface 3 as
ff/ff/ff.
With that in mind I'm not really sure how to proceed.
What comes to my mind, is either submit this as series again, with
ordering swapped,
or submit 2/2 first, wait for it to become merged, and then submit 1/2.
Send patch 2, wait for it to hit net, send 1 seems like the safest
option. If we're lucky Johan can still send patch 2 for 5.11, otherwise
we'll wait until the merge window - we're at rc7 already, it won't take
too long.
Patch looks fine to me. But I don't think you can submit a net and usb
serial patch in a series. These are two different subsystems.
There's no dependency between the patches so you can just submit
them as standalone patches. I.e. no series.
Actually, there is, and I just noticed, that patches are in wrong order.
Without patch 2/2 for 'option' driver, there is possibility for that
driver to steal
interface 3 from qmi_wwan, as currently it will match interface 3 as
ff/ff/ff.
With that in mind I'm not really sure how to proceed.
What comes to my mind, is either submit this as series again, with
ordering swapped,
or submit 2/2 first, wait for it to become merged, and then submit 1/2.
Send patch 2, wait for it to hit net, send 1 seems like the safest
option. If we're lucky Johan can still send patch 2 for 5.11, otherwise
we'll wait until the merge window - we're at rc7 already, it won't take
too long.
I usually don't send on new device-ids this late in the release cycle,
so I'll queue the USB-serial one up for 5.12-rc1 and you can take this
one through net-next.
Johan
From: Jakub Kicinski <kuba@kernel.org> Date: 2021-02-08 17:55:41
On Mon, 8 Feb 2021 10:35:24 +0100 Johan Hovold wrote:
quoted
Send patch 2, wait for it to hit net, send 1 seems like the safest
option. If we're lucky Johan can still send patch 2 for 5.11, otherwise
we'll wait until the merge window - we're at rc7 already, it won't take
too long.
I usually don't send on new device-ids this late in the release cycle,
so I'll queue the USB-serial one up for 5.12-rc1 and you can take this
one through net-next.
From: Johan Hovold <johan@kernel.org> Date: 2021-02-09 12:11:02
On Mon, Feb 08, 2021 at 09:52:52AM -0800, Jakub Kicinski wrote:
On Mon, 8 Feb 2021 10:35:24 +0100 Johan Hovold wrote:
quoted
quoted
Send patch 2, wait for it to hit net, send 1 seems like the safest
option. If we're lucky Johan can still send patch 2 for 5.11, otherwise
we'll wait until the merge window - we're at rc7 already, it won't take
too long.
I usually don't send on new device-ids this late in the release cycle,
so I'll queue the USB-serial one up for 5.12-rc1 and you can take this
one through net-next.
s/net-next/net/ Sound like a plan, thanks!
I did mean net-next so that both would end up in -rc1 and allowing you
to apply it straight away, but either works. :)
While there is a dependency of sort here, it's not the end of the world
if the networking one goes in before the USB-serial one; the serial
driver might just continue to claim those ports a while longer in some
setups (depending on probe order).
Johan
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Tue, 23 Feb 2021 19:34:56 +0100 you wrote:
Now that interface 3 in "option" driver is no longer mapped, add device
ID matching it to qmi_wwan.
The modem is used inside ZTE MF283+ router and carriers identify it as
such.
Interface mapping is:
0: QCDM, 1: AT (PCUI), 2: AT (Modem), 3: QMI, 4: ADB
[...]
On 2021-02-24 at 19:10, patchwork-bot+netdevbpf@kernel.org wrote:
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Tue, 23 Feb 2021 19:34:56 +0100 you wrote:
quoted
Now that interface 3 in "option" driver is no longer mapped, add device
ID matching it to qmi_wwan.
The modem is used inside ZTE MF283+ router and carriers identify it as
such.
Interface mapping is:
0: QCDM, 1: AT (PCUI), 2: AT (Modem), 3: QMI, 4: ADB
[...]
From: Jakub Kicinski <kuba@kernel.org> Date: 2021-03-03 06:14:50
On Mon, 1 Mar 2021 22:13:08 +0100 Lech Perczak wrote:
On 2021-02-24 at 19:10, patchwork-bot+netdevbpf@kernel.org wrote:
quoted
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Tue, 23 Feb 2021 19:34:56 +0100 you wrote:
quoted
Now that interface 3 in "option" driver is no longer mapped, add device
ID matching it to qmi_wwan.
The modem is used inside ZTE MF283+ router and carriers identify it as
such.
Interface mapping is:
0: QCDM, 1: AT (PCUI), 2: AT (Modem), 3: QMI, 4: ADB
[...]