diff mbox series

[net-next] r8152: add vendor/device ID pair for Microsoft Devkit

Message ID 20230111133228.190801-1-andre.przywara@arm.com
State New
Headers
Series [net-next] r8152: add vendor/device ID pair for Microsoft Devkit |

Commit Message

Andre Przywara Jan. 11, 2023, 1:32 p.m. UTC 
  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(+)

Comments

Jakub Kicinski Jan. 12, 2023, 5:31 a.m. UTC | #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.
Bjørn Mork Jan. 12, 2023, 8:33 a.m. UTC | #2 
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
Greg KH Jan. 12, 2023, 10 a.m. UTC | #3 
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
Andre Przywara Jan. 12, 2023, 10:51 a.m. UTC | #4 
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
Paolo Abeni Jan. 12, 2023, 11:39 a.m. UTC | #5 
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
Andre Przywara Jan. 12, 2023, 11:56 a.m. UTC | #6 
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
Paolo Abeni Jan. 12, 2023, 1:08 p.m. UTC | #7 
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
patchwork-bot+netdevbpf@kernel.org Jan. 12, 2023, 1:40 p.m. UTC | #8 
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 mbox series

Patch

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),