Message ID | 20230111133228.190801-1-andre.przywara@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp3326703wrt; Wed, 11 Jan 2023 05:41:33 -0800 (PST) X-Google-Smtp-Source: AMrXdXtUwKnJ3DAIoLwvaQ64idek9X8Z2++FxUurnc23aMNJvhWMOw2UPaP/xj6mnWiOsZMH0YXA X-Received: by 2002:a17:90a:bc92:b0:226:fa8c:e50b with SMTP id x18-20020a17090abc9200b00226fa8ce50bmr13658636pjr.21.1673444493661; Wed, 11 Jan 2023 05:41:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673444493; cv=none; d=google.com; s=arc-20160816; b=FKt46Inga6lCHuC+/LsVK9rVyjVqBvx28Wu9+uv8idOfvCB3+9Qx7GjJCtBuwm2N1R mYcPmXLs8l64tgdJBbTDfL1gM8ehl2GY6el2cRCE5gQUXagFe/C0VysSmnNxzHEG5oC/ 0FhNDiLKLP4xqH9Y0+UXl7jSK0zpQyFO4a85FZG7aSS7Gtr4CyAhG7ON2h8tIcwso5x/ F92q9UW49C4Cawt88OMrnHdgwGbeBKS4pWyA1H08uJxNPiAjHQUU8RzolNDGy9O95o+8 mFT7OJUiOi651vRjuVkQPrhwmXeghSW0J63S1VF3zdTZDVgNYTQRwpUv+iqKL0kGruU6 H7BA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=IgGmCIwiO0RU7FAzOHD7G8Us0YfNyQ7whG+9OsT4cPE=; b=fremj+B1bstEtlw5IPbk3XcIjoC4xZcLLYIa2h/lpp0BE3/eBBcZrBAjwCGxtOXEjx yMTDwOiOHRP9KB5tqREIl8okprYfLxjoL2tShjWEWNiKXXUJV4u0HlO1HyzKkO7WVx8k LIis2z2CxrvOEn+fXNaNWVq9PtELDnfe5BjqYcNQ7xL+zKmurFU043nO9gmsUNmV8Kp0 zH/xz9JISf6V0k65sTDbGa7Gv/x0MkkOcgNGB0R70xb9mQGiLKbcrRedxcRtpaZAM3OH zgbLayTo4xUDEw6ewcOCEOBF8qTZ+7Ui1wFPpX7T9udh6vkHBk4ZuyFMp9bJ/mEWltmH Vjsg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id li9-20020a17090b48c900b00228efc59314si572902pjb.70.2023.01.11.05.41.19; Wed, 11 Jan 2023 05:41:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238853AbjAKNeY (ORCPT <rfc822;syz17693488234@gmail.com> + 99 others); Wed, 11 Jan 2023 08:34:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239294AbjAKNdE (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 11 Jan 2023 08:33:04 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5074D1B9C5; Wed, 11 Jan 2023 05:32:35 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 88342FEC; Wed, 11 Jan 2023 05:33:17 -0800 (PST) Received: from donnerap.cambridge.arm.com (donnerap.cambridge.arm.com [10.1.197.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 608883F71A; Wed, 11 Jan 2023 05:32:34 -0800 (PST) From: Andre Przywara <andre.przywara@arm.com> To: "David S . Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com> Cc: linux-usb@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH net-next] r8152: add vendor/device ID pair for Microsoft Devkit Date: Wed, 11 Jan 2023 13:32:28 +0000 Message-Id: <20230111133228.190801-1-andre.przywara@arm.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754733733091828043?= X-GMAIL-MSGID: =?utf-8?q?1754733733091828043?= |
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
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),