| Message ID | 20230111133228.190801-1-andre.przywara@arm.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | be53771c87f4e322a9835d3faa9cd73a4ecdec5b |
| Headers | show |
| Series | [net-next] r8152: add vendor/device ID pair for Microsoft Devkit | expand |
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 <kuba@kernel.org> 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 <kuba@kernel.org> 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
On Wed, 11 Jan 2023 21:31:43 -0800 Jakub Kicinski <kuba@kernel.org> 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: <stable@vger.kernel.org> # 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, 2023-01-12 at 10:51 +0000, Andre Przywara wrote: > On Wed, 11 Jan 2023 21:31:43 -0800 Jakub Kicinski <kuba@kernel.org> 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: <stable@vger.kernel.org> # 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
On Thu, 12 Jan 2023 12:39:01 +0100 Paolo Abeni <pabeni@redhat.com> 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 <kuba@kernel.org> 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: <stable@vger.kernel.org> # 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 11:56 +0000, Andre Przywara wrote: > On Thu, 12 Jan 2023 12:39:01 +0100 > Paolo Abeni <pabeni@redhat.com> 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 <kuba@kernel.org> 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: <stable@vger.kernel.org> # 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
Hello: This patch was applied to netdev/net.git (master) by Paolo Abeni <pabeni@redhat.com>: 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!
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),
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 <andre.przywara@arm.com> --- drivers/net/usb/r8152.c | 1 + 1 file changed, 1 insertion(+)