The Microsoft Devkit 2023 is a an ARM64 based machine featuring a
Realtek 8153 USB3.0-to-GBit Ethernet adapter. As in their other
machines, Microsoft uses a custom USB device ID.
Add the respective ID values to the driver. This makes Ethernet work on
the MS Devkit device. The chip has been visually confirmed to be a
RTL8153.
Signed-off-by: Andre Przywara <[email protected]>
---
drivers/net/usb/r8152.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index a481a1d831e2f..23da1d9dafd1f 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -9836,6 +9836,7 @@ static const struct usb_device_id rtl8152_table[] = {
REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07ab),
REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07c6),
REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x0927),
+ REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x0c5e),
REALTEK_USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101),
REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x304f),
REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x3054),
--
2.25.1
On Wed, 11 Jan 2023 13:32:28 +0000 Andre Przywara wrote:
> The Microsoft Devkit 2023 is a an ARM64 based machine featuring a
> Realtek 8153 USB3.0-to-GBit Ethernet adapter. As in their other
> machines, Microsoft uses a custom USB device ID.
>
> Add the respective ID values to the driver. This makes Ethernet work on
> the MS Devkit device. The chip has been visually confirmed to be a
> RTL8153.
Hm, we have a patch in net-next which reformats the entries:
ec51fbd1b8a2bca2948dede99c14ec63dc57ff6b
Would you like this ID to be also added in stable? We could just
apply it to net, and deal with the conflict locally. But if you
don't care about older kernels then better if you rebase.
Jakub Kicinski <[email protected]> writes:
> On Wed, 11 Jan 2023 13:32:28 +0000 Andre Przywara wrote:
>> The Microsoft Devkit 2023 is a an ARM64 based machine featuring a
>> Realtek 8153 USB3.0-to-GBit Ethernet adapter. As in their other
>> machines, Microsoft uses a custom USB device ID.
>>
>> Add the respective ID values to the driver. This makes Ethernet work on
>> the MS Devkit device. The chip has been visually confirmed to be a
>> RTL8153.
>
> Hm, we have a patch in net-next which reformats the entries:
> ec51fbd1b8a2bca2948dede99c14ec63dc57ff6b
>
> Would you like this ID to be also added in stable? We could just
> apply it to net, and deal with the conflict locally. But if you
> don't care about older kernels then better if you rebase.
And now I started worrying about consequences of that reformatting...
Maybe I didn't give this enough thought?
Please let me know if you prefer to have the old macro name back. We
can avoid reformatting the list.
Bjørn
On Thu, Jan 12, 2023 at 09:33:08AM +0100, Bj?rn Mork wrote:
> Jakub Kicinski <[email protected]> writes:
> > On Wed, 11 Jan 2023 13:32:28 +0000 Andre Przywara wrote:
> >> The Microsoft Devkit 2023 is a an ARM64 based machine featuring a
> >> Realtek 8153 USB3.0-to-GBit Ethernet adapter. As in their other
> >> machines, Microsoft uses a custom USB device ID.
> >>
> >> Add the respective ID values to the driver. This makes Ethernet work on
> >> the MS Devkit device. The chip has been visually confirmed to be a
> >> RTL8153.
> >
> > Hm, we have a patch in net-next which reformats the entries:
> > ec51fbd1b8a2bca2948dede99c14ec63dc57ff6b
> >
> > Would you like this ID to be also added in stable? We could just
> > apply it to net, and deal with the conflict locally. But if you
> > don't care about older kernels then better if you rebase.
>
> And now I started worrying about consequences of that reformatting...
> Maybe I didn't give this enough thought?
Just send a reformatting patch for stable as well. I've taken patches
like that many times for other drivers/subsystems to make backports
trivial.
thanks,
greg k-h
This is a partial revert of commit ec51fbd1b8a2 ("r8152:
add USB device driver for config selection")
Keep a simplified version of the REALTEK_USB_DEVICE macro
to avoid unnecessary reformatting of the device list. This
makes new device ID additions apply cleanly across driver
versions.
Fixes: ec51fbd1b8a2 ("r8152: add USB device driver for config selection")
Signed-off-by: Bjørn Mork <[email protected]>
---
The patch in
https://lore.kernel.org/lkml/[email protected]/
will apply cleanly on top of this.
This fix will also prevent a lot of stable backporting hassle.
Sorry for not thinking the change completely through before
submitting. I should never have touched the rtl8152_table.
Bjørn
drivers/net/usb/r8152.c | 48 +++++++++++++++++++++--------------------
1 file changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 66e70b5f8417..3d4631dae00f 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -9817,34 +9817,36 @@ static void rtl8152_disconnect(struct usb_interface *intf)
}
}
+#define REALTEK_USB_DEVICE(vend, prod) { USB_DEVICE(vend, prod) }
+
/* table of devices that work with this driver */
static const struct usb_device_id rtl8152_table[] = {
/* Realtek */
- { USB_DEVICE(VENDOR_ID_REALTEK, 0x8050) },
- { USB_DEVICE(VENDOR_ID_REALTEK, 0x8053) },
- { USB_DEVICE(VENDOR_ID_REALTEK, 0x8152) },
- { USB_DEVICE(VENDOR_ID_REALTEK, 0x8153) },
- { USB_DEVICE(VENDOR_ID_REALTEK, 0x8155) },
- { USB_DEVICE(VENDOR_ID_REALTEK, 0x8156) },
+ REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8050),
+ REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8053),
+ REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8152),
+ REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8153),
+ REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8155),
+ REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8156),
/* Microsoft */
- { USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07ab) },
- { USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07c6) },
- { USB_DEVICE(VENDOR_ID_MICROSOFT, 0x0927) },
- { USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101) },
- { USB_DEVICE(VENDOR_ID_LENOVO, 0x304f) },
- { USB_DEVICE(VENDOR_ID_LENOVO, 0x3054) },
- { USB_DEVICE(VENDOR_ID_LENOVO, 0x3062) },
- { USB_DEVICE(VENDOR_ID_LENOVO, 0x3069) },
- { USB_DEVICE(VENDOR_ID_LENOVO, 0x3082) },
- { USB_DEVICE(VENDOR_ID_LENOVO, 0x7205) },
- { USB_DEVICE(VENDOR_ID_LENOVO, 0x720c) },
- { USB_DEVICE(VENDOR_ID_LENOVO, 0x7214) },
- { USB_DEVICE(VENDOR_ID_LENOVO, 0x721e) },
- { USB_DEVICE(VENDOR_ID_LENOVO, 0xa387) },
- { USB_DEVICE(VENDOR_ID_LINKSYS, 0x0041) },
- { USB_DEVICE(VENDOR_ID_NVIDIA, 0x09ff) },
- { USB_DEVICE(VENDOR_ID_TPLINK, 0x0601) },
+ REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07ab),
+ REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07c6),
+ REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x0927),
+ REALTEK_USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101),
+ REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x304f),
+ REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x3054),
+ REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x3062),
+ REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x3069),
+ REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x3082),
+ REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x7205),
+ REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x720c),
+ REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x7214),
+ REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x721e),
+ REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0xa387),
+ REALTEK_USB_DEVICE(VENDOR_ID_LINKSYS, 0x0041),
+ REALTEK_USB_DEVICE(VENDOR_ID_NVIDIA, 0x09ff),
+ REALTEK_USB_DEVICE(VENDOR_ID_TPLINK, 0x0601),
{}
};
--
2.30.2
On Thu, Jan 12, 2023 at 11:01:00AM +0100, Bj?rn Mork wrote:
> This is a partial revert of commit ec51fbd1b8a2 ("r8152:
> add USB device driver for config selection")
>
> Keep a simplified version of the REALTEK_USB_DEVICE macro
> to avoid unnecessary reformatting of the device list. This
> makes new device ID additions apply cleanly across driver
> versions.
>
> Fixes: ec51fbd1b8a2 ("r8152: add USB device driver for config selection")
> Signed-off-by: Bj?rn Mork <[email protected]>
> ---
> The patch in
> https://lore.kernel.org/lkml/[email protected]/
> will apply cleanly on top of this.
>
> This fix will also prevent a lot of stable backporting hassle.
No need for this, just backport the original change to older kernels and
all will be fine.
Don't live with stuff you don't want to because of stable kernels,
that's not how this whole process works at all :)
thanks,
greg k-h
Bjørn Mork <[email protected]> writes:
> Greg KH <[email protected]> writes:
>
>> No need for this, just backport the original change to older kernels and
>> all will be fine.
>>
>> Don't live with stuff you don't want to because of stable kernels,
>> that's not how this whole process works at all :)
>
> OK, thanks. Will prepare a patch for stable instead then.
>
> But I guess the original patch is unacceptable for stable as-is? It
> changes how Linux react to these devces, and includes a completely new
> USB device driver (i.e not interface driver).
Doh! I gotta start thinking before I send email. Will start right
after sending this one ;-)
We cannot backport the device-id table change to stable without taking
the rest of the patch. The strategy used by the old driver needs two
entries per device ID, which is why the macro was there.
So the question is: Can commit ec51fbd1b8a2 ("r8152: add USB device
driver for config selection") be accepted in stable?
( Direct link for convenience since it's not yet in mainline:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/drivers/net/usb/r8152.c?id=ec51fbd1b8a2bca2948dede99c14ec63dc57ff6b
)
This is not within the rules as I read them, but it's your call...
Bjørn
On Thu, Jan 12, 2023 at 11:18:59AM +0100, Bj?rn Mork wrote:
> Greg KH <[email protected]> writes:
> > On Thu, Jan 12, 2023 at 11:01:00AM +0100, Bj?rn Mork wrote:
> >> This is a partial revert of commit ec51fbd1b8a2 ("r8152:
> >> add USB device driver for config selection")
> >>
> >> Keep a simplified version of the REALTEK_USB_DEVICE macro
> >> to avoid unnecessary reformatting of the device list. This
> >> makes new device ID additions apply cleanly across driver
> >> versions.
> >>
> >> Fixes: ec51fbd1b8a2 ("r8152: add USB device driver for config selection")
> >> Signed-off-by: Bj?rn Mork <[email protected]>
> >> ---
> >> The patch in
> >> https://lore.kernel.org/lkml/[email protected]/
> >> will apply cleanly on top of this.
> >>
> >> This fix will also prevent a lot of stable backporting hassle.
> >
> > No need for this, just backport the original change to older kernels and
> > all will be fine.
> >
> > Don't live with stuff you don't want to because of stable kernels,
> > that's not how this whole process works at all :)
>
> OK, thanks. Will prepare a patch for stable instead then.
>
> But I guess the original patch is unacceptable for stable as-is? It
> changes how Linux react to these devces, and includes a completely new
> USB device driver (i.e not interface driver).
That's up to you all. We don't add new support for new hardware to
older kernels _UNLESS_ it's just a new device id. Otherwise it's just
better to tell people to upgrade to the newer kernel.
If you split things up and added a whole new driver, then just leave it
alone, no need to backport anything, sorry, I didn't realize that.
greg k-h
Greg KH <[email protected]> writes:
> On Thu, Jan 12, 2023 at 11:01:00AM +0100, Bjørn Mork wrote:
>> This is a partial revert of commit ec51fbd1b8a2 ("r8152:
>> add USB device driver for config selection")
>>
>> Keep a simplified version of the REALTEK_USB_DEVICE macro
>> to avoid unnecessary reformatting of the device list. This
>> makes new device ID additions apply cleanly across driver
>> versions.
>>
>> Fixes: ec51fbd1b8a2 ("r8152: add USB device driver for config selection")
>> Signed-off-by: Bjørn Mork <[email protected]>
>> ---
>> The patch in
>> https://lore.kernel.org/lkml/[email protected]/
>> will apply cleanly on top of this.
>>
>> This fix will also prevent a lot of stable backporting hassle.
>
> No need for this, just backport the original change to older kernels and
> all will be fine.
>
> Don't live with stuff you don't want to because of stable kernels,
> that's not how this whole process works at all :)
OK, thanks. Will prepare a patch for stable instead then.
But I guess the original patch is unacceptable for stable as-is? It
changes how Linux react to these devces, and includes a completely new
USB device driver (i.e not interface driver).
Bjørn
On Thu, Jan 12, 2023 at 11:29:40AM +0100, Bj?rn Mork wrote:
> Bj?rn Mork <[email protected]> writes:
> > Greg KH <[email protected]> writes:
> >
> >> No need for this, just backport the original change to older kernels and
> >> all will be fine.
> >>
> >> Don't live with stuff you don't want to because of stable kernels,
> >> that's not how this whole process works at all :)
> >
> > OK, thanks. Will prepare a patch for stable instead then.
> >
> > But I guess the original patch is unacceptable for stable as-is? It
> > changes how Linux react to these devces, and includes a completely new
> > USB device driver (i.e not interface driver).
>
> Doh! I gotta start thinking before I send email. Will start right
> after sending this one ;-)
>
> We cannot backport the device-id table change to stable without taking
> the rest of the patch. The strategy used by the old driver needs two
> entries per device ID, which is why the macro was there.
>
> So the question is: Can commit ec51fbd1b8a2 ("r8152: add USB device
> driver for config selection") be accepted in stable?
>
> ( Direct link for convenience since it's not yet in mainline:
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/drivers/net/usb/r8152.c?id=ec51fbd1b8a2bca2948dede99c14ec63dc57ff6b
> )
>
> This is not within the rules as I read them, but it's your call...
Ah, yeah, that's simple enough, I'd take it if you send it to me :)
greg k-h
On Wed, 11 Jan 2023 21:31:43 -0800
Jakub Kicinski <[email protected]> wrote:
Hi,
> On Wed, 11 Jan 2023 13:32:28 +0000 Andre Przywara wrote:
> > The Microsoft Devkit 2023 is a an ARM64 based machine featuring a
> > Realtek 8153 USB3.0-to-GBit Ethernet adapter. As in their other
> > machines, Microsoft uses a custom USB device ID.
> >
> > Add the respective ID values to the driver. This makes Ethernet work on
> > the MS Devkit device. The chip has been visually confirmed to be a
> > RTL8153.
>
> Hm, we have a patch in net-next which reformats the entries:
> ec51fbd1b8a2bca2948dede99c14ec63dc57ff6b
>
> Would you like this ID to be also added in stable? We could just
> apply it to net, and deal with the conflict locally. But if you
> don't care about older kernels then better if you rebase.
Stable would be nice, but only to v6.1. I think I don't care
about older kernels.
So what about if I resend this one here, based on top of the reformat
patch, with a:
Cc: <[email protected]> # 6.1.x
line in there, and then reply to the email that the automatic backport
failed, with a tailored patch for v6.1?
Alternatively I can send an explicit stable backport email once this one
is merged.
Cheers,
Andre
On Thu, 12 Jan 2023 12:39:01 +0100
Paolo Abeni <[email protected]> wrote:
Hi,
> On Thu, 2023-01-12 at 10:51 +0000, Andre Przywara wrote:
> > On Wed, 11 Jan 2023 21:31:43 -0800 Jakub Kicinski <[email protected]> wrote:
> > > Hm, we have a patch in net-next which reformats the entries:
> > > ec51fbd1b8a2bca2948dede99c14ec63dc57ff6b
> > >
> > > Would you like this ID to be also added in stable? We could just
> > > apply it to net, and deal with the conflict locally. But if you
> > > don't care about older kernels then better if you rebase.
> >
> > Stable would be nice, but only to v6.1. I think I don't care
> > about older kernels.
> > So what about if I resend this one here, based on top of the reformat
> > patch, with a:
> > Cc: <[email protected]> # 6.1.x
> > line in there, and then reply to the email that the automatic backport
> > failed, with a tailored patch for v6.1?
> > Alternatively I can send an explicit stable backport email once this one
> > is merged.
>
> Note that we can merge this kind of changes via the -net tree. No
> repost will be needed. We can merge it as is on -net and you can follow
> the option 2 from the stable kernel rules doc, with no repost nor
> additional mangling for stable will be needed.
>
> If you are ok with the above let me know.
That sounds good to me, but that will then trigger a merge conflict when
net-next (with the reformat patch) is merged? I guess it's easy enough to
solve, but that would be extra work on your side. If you are fine with
that, it's OK for me.
Thanks,
Andre
On Thu, 2023-01-12 at 10:51 +0000, Andre Przywara wrote:
> On Wed, 11 Jan 2023 21:31:43 -0800 Jakub Kicinski <[email protected]> wrote:
> > Hm, we have a patch in net-next which reformats the entries:
> > ec51fbd1b8a2bca2948dede99c14ec63dc57ff6b
> >
> > Would you like this ID to be also added in stable? We could just
> > apply it to net, and deal with the conflict locally. But if you
> > don't care about older kernels then better if you rebase.
>
> Stable would be nice, but only to v6.1. I think I don't care
> about older kernels.
> So what about if I resend this one here, based on top of the reformat
> patch, with a:
> Cc: <[email protected]> # 6.1.x
> line in there, and then reply to the email that the automatic backport
> failed, with a tailored patch for v6.1?
> Alternatively I can send an explicit stable backport email once this one
> is merged.
Note that we can merge this kind of changes via the -net tree. No
repost will be needed. We can merge it as is on -net and you can follow
the option 2 from the stable kernel rules doc, with no repost nor
additional mangling for stable will be needed.
If you are ok with the above let me know.
Thanks,
Paolo
Hello:
This patch was applied to netdev/net.git (master)
by Paolo Abeni <[email protected]>:
On Wed, 11 Jan 2023 13:32:28 +0000 you wrote:
> The Microsoft Devkit 2023 is a an ARM64 based machine featuring a
> Realtek 8153 USB3.0-to-GBit Ethernet adapter. As in their other
> machines, Microsoft uses a custom USB device ID.
>
> Add the respective ID values to the driver. This makes Ethernet work on
> the MS Devkit device. The chip has been visually confirmed to be a
> RTL8153.
>
> [...]
Here is the summary with links:
- [net-next] r8152: add vendor/device ID pair for Microsoft Devkit
https://git.kernel.org/netdev/net/c/be53771c87f4
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
On Thu, 2023-01-12 at 11:56 +0000, Andre Przywara wrote:
> On Thu, 12 Jan 2023 12:39:01 +0100
> Paolo Abeni <[email protected]> wrote:
>
> Hi,
>
> > On Thu, 2023-01-12 at 10:51 +0000, Andre Przywara wrote:
> > > On Wed, 11 Jan 2023 21:31:43 -0800 Jakub Kicinski <[email protected]> wrote:
> > > > Hm, we have a patch in net-next which reformats the entries:
> > > > ec51fbd1b8a2bca2948dede99c14ec63dc57ff6b
> > > >
> > > > Would you like this ID to be also added in stable? We could just
> > > > apply it to net, and deal with the conflict locally. But if you
> > > > don't care about older kernels then better if you rebase.
> > >
> > > Stable would be nice, but only to v6.1. I think I don't care
> > > about older kernels.
> > > So what about if I resend this one here, based on top of the reformat
> > > patch, with a:
> > > Cc: <[email protected]> # 6.1.x
> > > line in there, and then reply to the email that the automatic backport
> > > failed, with a tailored patch for v6.1?
> > > Alternatively I can send an explicit stable backport email once this one
> > > is merged.
> >
> > Note that we can merge this kind of changes via the -net tree. No
> > repost will be needed. We can merge it as is on -net and you can follow
> > the option 2 from the stable kernel rules doc, with no repost nor
> > additional mangling for stable will be needed.
> >
> > If you are ok with the above let me know.
>
> That sounds good to me, but that will then trigger a merge conflict when
> net-next (with the reformat patch) is merged? I guess it's easy enough to
> solve, but that would be extra work on your side. If you are fine with
> that, it's OK for me.
Fine by us (well, probably poor Jakub will end-up handling the
conflict, but AFAIK he is ok with this specific case).
I'll merge the patch on net.
Cheers,
Paolo
Greg KH <[email protected]> writes:
> On Thu, Jan 12, 2023 at 11:29:40AM +0100, Bjørn Mork wrote:
>> Bjørn Mork <[email protected]> writes:
>> > Greg KH <[email protected]> writes:
>> >
>> >> No need for this, just backport the original change to older kernels and
>> >> all will be fine.
>> >>
>> >> Don't live with stuff you don't want to because of stable kernels,
>> >> that's not how this whole process works at all :)
>> >
>> > OK, thanks. Will prepare a patch for stable instead then.
>> >
>> > But I guess the original patch is unacceptable for stable as-is? It
>> > changes how Linux react to these devces, and includes a completely new
>> > USB device driver (i.e not interface driver).
>>
>> Doh! I gotta start thinking before I send email. Will start right
>> after sending this one ;-)
>>
>> We cannot backport the device-id table change to stable without taking
>> the rest of the patch. The strategy used by the old driver needs two
>> entries per device ID, which is why the macro was there.
>>
>> So the question is: Can commit ec51fbd1b8a2 ("r8152: add USB device
>> driver for config selection") be accepted in stable?
>>
>> ( Direct link for convenience since it's not yet in mainline:
>> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/drivers/net/usb/r8152.c?id=ec51fbd1b8a2bca2948dede99c14ec63dc57ff6b
>> )
>>
>> This is not within the rules as I read them, but it's your call...
>
> Ah, yeah, that's simple enough, I'd take it if you send it to me :)
Great!
There is no point backporting to anything older than v5.15 since the
patch depend on significant driver changes between v5.10 and v5.15. The
good news is that those changes also modified the macro in question so
any device ID patch for v5.10 or older will have to be fixed up in any
case. So we don't lose anything by ignoring the older longterm kernels
here.
IIUC the special netdev stable rules are gone. But if this is going to
stable, then I believe it still has to go to "net" first.
David/Jakub - Would you please pick
ec51fbd1b8a2 ("r8152: add USB device driver for config selection")
69649ef84053 ("cdc_ether: no need to blacklist any r8152 devices")
from net-next to net? With a "CC: stable" preferably. Or do you prefer
some other solution?
Bjørn
On Fri, 13 Jan 2023 11:16:47 +0100 Bjørn Mork wrote:
> There is no point backporting to anything older than v5.15 since the
> patch depend on significant driver changes between v5.10 and v5.15. The
> good news is that those changes also modified the macro in question so
> any device ID patch for v5.10 or older will have to be fixed up in any
> case. So we don't lose anything by ignoring the older longterm kernels
> here.
>
> IIUC the special netdev stable rules are gone. But if this is going to
> stable, then I believe it still has to go to "net" first.
>
> David/Jakub - Would you please pick
>
> ec51fbd1b8a2 ("r8152: add USB device driver for config selection")
> 69649ef84053 ("cdc_ether: no need to blacklist any r8152 devices")
>
> from net-next to net? With a "CC: stable" preferably. Or do you prefer
> some other solution?
Well.. we already shipped the patch from this thread as is to Linus.
Greg will be able to take be53771c87f4 into stable directly, with
no dependencies.
And now the refactoring won't cherry-pick cleanly :(
Maybe let's leave it be?
I'll keep in mind that Greg is okay with taking this sort of
refactoring in in the future. I made an unnecessary commotion here.