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

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

[Andre Przywara]

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(+)

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

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

[Jakub Kicinski]

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.

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

[Bjørn Mork]

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

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

[Greg KH]

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

[PATCH net-next] r8152; preserve device list format

[Bjørn Mork]

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 <bjorn@mork.no>
---
The patch in
https://lore.kernel.org/lkml/20230111133228.190801-1-andre.przywara@arm.com/
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

Re: [PATCH net-next] r8152; preserve device list format

[Greg KH]

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 <bjorn@mork.no>
> ---
> The patch in
> https://lore.kernel.org/lkml/20230111133228.190801-1-andre.przywara@arm.com/
> 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

Re: [PATCH net-next] r8152; preserve device list format

[Bjørn Mork]

Greg KH <greg@kroah.com> 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 <bjorn@mork.no>
>> ---
>> The patch in
>> https://lore.kernel.org/lkml/20230111133228.190801-1-andre.przywara@arm.com/
>> 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

Re: [PATCH net-next] r8152; preserve device list format

[Greg KH]

On Thu, Jan 12, 2023 at 11:18:59AM +0100, Bjørn Mork wrote:
> Greg KH <greg@kroah.com> 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 <bjorn@mork.no>
> >> ---
> >> The patch in
> >> https://lore.kernel.org/lkml/20230111133228.190801-1-andre.przywara@arm.com/
> >> 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

Re: [PATCH net-next] r8152; preserve device list format

[Bjørn Mork]

Bjørn Mork <bjorn@mork.no> writes:
> Greg KH <greg@kroah.com> 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

Re: [PATCH net-next] r8152; preserve device list format

[Greg KH]

On Thu, Jan 12, 2023 at 11:29:40AM +0100, Bjørn Mork wrote:
> Bjørn Mork <bjorn@mork.no> writes:
> > Greg KH <greg@kroah.com> 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

Re: [PATCH net-next] r8152; preserve device list format

[Bjørn Mork]

Greg KH <greg@kroah.com> writes:
> On Thu, Jan 12, 2023 at 11:29:40AM +0100, Bjørn Mork wrote:
>> Bjørn Mork <bjorn@mork.no> writes:
>> > Greg KH <greg@kroah.com> 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

Re: [PATCH net-next] r8152; preserve device list format

[Jakub Kicinski]

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.

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

[Andre Przywara]

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

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

[Paolo Abeni]

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

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

[Andre Przywara]

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

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

[Paolo Abeni]

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

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

[patchwork-bot+netdevbpf]

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!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html