Message ID | 20231106110654.31090-1-johan+linaro@kernel.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:8f47:0:b0:403:3b70:6f57 with SMTP id j7csp2579533vqu; Mon, 6 Nov 2023 03:07:50 -0800 (PST) X-Google-Smtp-Source: AGHT+IFMGV90Q3ry7J3UZtLjJgjtCd6iziEKeWym69ZLtDutBr6hv6gErVaSDZnW2xBnfYF5XOhl X-Received: by 2002:a05:6a21:a59b:b0:17b:7dda:c106 with SMTP id gd27-20020a056a21a59b00b0017b7ddac106mr30287223pzc.34.1699268869960; Mon, 06 Nov 2023 03:07:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699268869; cv=none; d=google.com; s=arc-20160816; b=dHls7AXqJy8bJB5qoFY2MeByPfuyEDcoO1C2eK8uVKK4DzIn21fsZvTJ0g23ojLMw9 Lx8F1orEjWn1YE5eenpOz2gspWjiZ3CBJwPJKbbmcn8eGubaTt8GoW3nUUkVaysjkigQ 7cELzwP1fh39gU3XYxUyIIN5naksy3K3q9RUawoA2gwbOpBuVgToTQox3EHl36/LwMtV 4vyKPNjch4E+hfAM1p/wuRNv2BPjqn0t838C9web0Kbh7QkQAD9RR3pWj0FL+oskNIDt 5gWkUpDNa3g2/5D0dGc8q3HpjTtCCV1bPbq103FOnbXhGidMr5D0ni6n9TRoveE3nOg5 zaUw== 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:dkim-signature; bh=J0isYWuS7AGfOCBjA1+9iBr6kSJnPRJXiklkJjVtHrk=; fh=usIcYeG3NIY35auTMv/raDZk1i0g7Ncau/NUR4dVPvU=; b=x7sTUeflw5IagwEF3lMUyBxXVg5nG1K0ytYbMMrU+B/rcclqkHX9ssfpdzWSyuQms7 M2JU3QUqDnVz8CwJmEaA2zjpdt8Gg/Xmd/D6aOmC+rauHYEmuJhlZepF0o9nXT2vFM3R /o4mR6/Fk11j/L2ApUp8S53Pci03U/mvu+vdipF+J/hgUPdiBi2kVpGu3x+27L+rtHBj n1KJUdkqqtaNQC7keEqCHvXW/6Vp92bl05oI+oYW6cKe8JIq2oJLgEvGfSejpz331Wvw 9V/vNQL1hIgJt53UWdFJnD4h6tOEK1jm/uwCHvGYWD43n4PtmC3IIplsLZdwTpjYuayh Yzng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="fBa/EuyJ"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id y76-20020a62ce4f000000b0068a6eb3b548si7256991pfg.401.2023.11.06.03.07.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 03:07:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="fBa/EuyJ"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id E11BB80401F3; Mon, 6 Nov 2023 03:07:30 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230308AbjKFLGw (ORCPT <rfc822;jaysivo@gmail.com> + 36 others); Mon, 6 Nov 2023 06:06:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60354 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230220AbjKFLGt (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 6 Nov 2023 06:06:49 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC1C4136 for <linux-kernel@vger.kernel.org>; Mon, 6 Nov 2023 03:06:46 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 35D51C433CB; Mon, 6 Nov 2023 11:06:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1699268806; bh=g3eDON8La9LZBGvGeH9tuvtlZ9gkW8hDKV2CMMchUE4=; h=From:To:Cc:Subject:Date:From; b=fBa/EuyJu1KjyLtU6I9czSHVWMGMexRmURy8to5xILif8oO7Yo0mGuoaqCYhuOgee ZiVGPee5/nkIaGBoUCvutRflUr4V2xi0k2wm539RlYLIYb2jdXMhCAERHajB3he6z4 JHRlIgbWM1H08AI3XpOsKrrnLBm7EV8x1nvF6SZ61EVh53N/ftYP3s9BbPc4Ht4kxj 5Bzc5dCtPcNFLIlhiCw7A6+SS/h+ivRDIIAXhbwMWyobSaI4RQtMMwGiPP0SIJnqc9 1o3MaBYLxTHEH4E77PTsbpzxZ022lJkuSjy0Yl0ciajvIL7RpwKAsrTpuF/CWTaDYV 8jKGgZ4L4lNrg== Received: from johan by xi.lan with local (Exim 4.96) (envelope-from <johan+linaro@kernel.org>) id 1qzxS7-00085p-1j; Mon, 06 Nov 2023 12:07:31 +0100 From: Johan Hovold <johan+linaro@kernel.org> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Vinod Koul <vkoul@kernel.org>, Kishon Vijay Abraham I <kishon@kernel.org>, Stanley Chang <stanley_chang@realtek.com>, linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org, linux-usb@vger.kernel.org, Johan Hovold <johan+linaro@kernel.org> Subject: [PATCH 0/3] Revert "usb: phy: add usb phy notify port status API" Date: Mon, 6 Nov 2023 12:06:51 +0100 Message-ID: <20231106110654.31090-1-johan+linaro@kernel.org> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Mon, 06 Nov 2023 03:07:31 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781812554740029167 X-GMAIL-MSGID: 1781812554740029167 |
Series |
Revert "usb: phy: add usb phy notify port status API"
|
|
Message
Johan Hovold
Nov. 6, 2023, 11:06 a.m. UTC
The recently added Realtek PHY drivers depend on the new port status notification mechanism which was built on the deprecated USB PHY implementation and devicetree binding. Specifically, using these PHYs would require describing the very same PHY using both the generic "phy" property and the deprecated "usb-phy" property which is clearly wrong. We should not be building new functionality on top of the legacy USB PHY implementation even if it is currently stuck in some kind of transitional limbo. Revert the new Realtek PHY drivers for now so that the port status notification interface can be reverted and replaced before we dig ourselves into an even deeper hole with this PHY mess. Note that there are no upstream users of these PHYs and the drivers were only included in 6.6 so there should still be time to undo this. Preferably these should go in through Greg's tree for 6.7-rc1. Johan Johan Hovold (3): Revert "phy: realtek: usb: Add driver for the Realtek SoC USB 3.0 PHY" Revert "phy: realtek: usb: Add driver for the Realtek SoC USB 2.0 PHY" Revert "usb: phy: add usb phy notify port status API" drivers/phy/Kconfig | 1 - drivers/phy/Makefile | 1 - drivers/phy/realtek/Kconfig | 32 - drivers/phy/realtek/Makefile | 3 - drivers/phy/realtek/phy-rtk-usb2.c | 1325 ---------------------------- drivers/phy/realtek/phy-rtk-usb3.c | 761 ---------------- drivers/usb/core/hub.c | 23 - include/linux/usb/phy.h | 13 - 8 files changed, 2159 deletions(-) delete mode 100644 drivers/phy/realtek/Kconfig delete mode 100644 drivers/phy/realtek/Makefile delete mode 100644 drivers/phy/realtek/phy-rtk-usb2.c delete mode 100644 drivers/phy/realtek/phy-rtk-usb3.c
Comments
On Mon, Nov 06, 2023 at 12:06:51PM +0100, Johan Hovold wrote: > The recently added Realtek PHY drivers depend on the new port status > notification mechanism which was built on the deprecated USB PHY > implementation and devicetree binding. > > Specifically, using these PHYs would require describing the very same > PHY using both the generic "phy" property and the deprecated "usb-phy" > property which is clearly wrong. > > We should not be building new functionality on top of the legacy USB PHY > implementation even if it is currently stuck in some kind of > transitional limbo. > > Revert the new Realtek PHY drivers for now so that the port status > notification interface can be reverted and replaced before we dig > ourselves into an even deeper hole with this PHY mess. > > Note that there are no upstream users of these PHYs and the drivers were > only included in 6.6 so there should still be time to undo this. No users of these phy drivers yet? Why were they added? > Preferably these should go in through Greg's tree for 6.7-rc1. I'll be glad to take this if I can get an ack for it. thanks, greg k-h
On 06-11-23, 12:15, Greg Kroah-Hartman wrote: > On Mon, Nov 06, 2023 at 12:06:51PM +0100, Johan Hovold wrote: > > The recently added Realtek PHY drivers depend on the new port status > > notification mechanism which was built on the deprecated USB PHY > > implementation and devicetree binding. > > > > Specifically, using these PHYs would require describing the very same > > PHY using both the generic "phy" property and the deprecated "usb-phy" > > property which is clearly wrong. > > > > We should not be building new functionality on top of the legacy USB PHY > > implementation even if it is currently stuck in some kind of > > transitional limbo. > > > > Revert the new Realtek PHY drivers for now so that the port status > > notification interface can be reverted and replaced before we dig > > ourselves into an even deeper hole with this PHY mess. > > > > Note that there are no upstream users of these PHYs and the drivers were > > only included in 6.6 so there should still be time to undo this. > > No users of these phy drivers yet? Why were they added? Not sure why, they didnt go thru phy ss! > > > Preferably these should go in through Greg's tree for 6.7-rc1. > > I'll be glad to take this if I can get an ack for it. Pls do drop this: Acked-by: Vinod Koul <vkoul@kernel.org>
On Mon, Nov 06, 2023 at 12:15:59PM +0100, Greg Kroah-Hartman wrote: > On Mon, Nov 06, 2023 at 12:06:51PM +0100, Johan Hovold wrote: > > The recently added Realtek PHY drivers depend on the new port status > > notification mechanism which was built on the deprecated USB PHY > > implementation and devicetree binding. > > > > Specifically, using these PHYs would require describing the very same > > PHY using both the generic "phy" property and the deprecated "usb-phy" > > property which is clearly wrong. > > > > We should not be building new functionality on top of the legacy USB PHY > > implementation even if it is currently stuck in some kind of > > transitional limbo. > > > > Revert the new Realtek PHY drivers for now so that the port status > > notification interface can be reverted and replaced before we dig > > ourselves into an even deeper hole with this PHY mess. > > > > Note that there are no upstream users of these PHYs and the drivers were > > only included in 6.6 so there should still be time to undo this. > > No users of these phy drivers yet? Why were they added? The devicetree bindings were also merged in 6.6 (and are left in place), but there are no devicetrees that actually use these new bindings in mainline yet. > > Preferably these should go in through Greg's tree for 6.7-rc1. > > I'll be glad to take this if I can get an ack for it. They went in through your tree, but note that you may now get a conflict with 7e909370a5cd ("phy: realtek: Replace of_device.h with explicit includes") in the phy tree. Johan
On Mon, Nov 06, 2023 at 04:54:45PM +0530, Vinod Koul wrote: > On 06-11-23, 12:15, Greg Kroah-Hartman wrote: > > On Mon, Nov 06, 2023 at 12:06:51PM +0100, Johan Hovold wrote: > > > The recently added Realtek PHY drivers depend on the new port status > > > notification mechanism which was built on the deprecated USB PHY > > > implementation and devicetree binding. > > > > > > Specifically, using these PHYs would require describing the very same > > > PHY using both the generic "phy" property and the deprecated "usb-phy" > > > property which is clearly wrong. > > > > > > We should not be building new functionality on top of the legacy USB PHY > > > implementation even if it is currently stuck in some kind of > > > transitional limbo. > > > > > > Revert the new Realtek PHY drivers for now so that the port status > > > notification interface can be reverted and replaced before we dig > > > ourselves into an even deeper hole with this PHY mess. > > > > > > Note that there are no upstream users of these PHYs and the drivers were > > > only included in 6.6 so there should still be time to undo this. > > > > No users of these phy drivers yet? Why were they added? > > Not sure why, they didnt go thru phy ss! > > > > > > Preferably these should go in through Greg's tree for 6.7-rc1. > > > > I'll be glad to take this if I can get an ack for it. > > Pls do drop this: > > Acked-by: Vinod Koul <vkoul@kernel.org> Thanks, now applied. greg k-h
On Mon, Nov 06, 2023 at 12:25:34PM +0100, Johan Hovold wrote: > On Mon, Nov 06, 2023 at 12:15:59PM +0100, Greg Kroah-Hartman wrote: > > On Mon, Nov 06, 2023 at 12:06:51PM +0100, Johan Hovold wrote: > > > The recently added Realtek PHY drivers depend on the new port status > > > notification mechanism which was built on the deprecated USB PHY > > > implementation and devicetree binding. > > > > > > Specifically, using these PHYs would require describing the very same > > > PHY using both the generic "phy" property and the deprecated "usb-phy" > > > property which is clearly wrong. > > > > > > We should not be building new functionality on top of the legacy USB PHY > > > implementation even if it is currently stuck in some kind of > > > transitional limbo. > > > > > > Revert the new Realtek PHY drivers for now so that the port status > > > notification interface can be reverted and replaced before we dig > > > ourselves into an even deeper hole with this PHY mess. > > > > > > Note that there are no upstream users of these PHYs and the drivers were > > > only included in 6.6 so there should still be time to undo this. > > > > No users of these phy drivers yet? Why were they added? > > The devicetree bindings were also merged in 6.6 (and are left in place), > but there are no devicetrees that actually use these new bindings in > mainline yet. > > > > Preferably these should go in through Greg's tree for 6.7-rc1. > > > > I'll be glad to take this if I can get an ack for it. > > They went in through your tree, but note that you may now get a conflict > with > > 7e909370a5cd ("phy: realtek: Replace of_device.h with explicit includes") > > in the phy tree. I fixed it up by hand, should be good now, thanks. greg k-h
Hi Johan and Vinod, I modified the Realtek phy to solve this issue and only use the generic PHY. And submitted these patches today as follows https://lore.kernel.org/linux-usb/20231107063518.27824-1-stanley_chang@realtek.com/ https://lore.kernel.org/linux-usb/20231107063518.27824-2-stanley_chang@realtek.com/ https://lore.kernel.org/linux-usb/20231107063518.27824-3-stanley_chang@realtek.com/ https://lore.kernel.org/linux-usb/20231107063518.27824-4-stanley_chang@realtek.com/ I don't think this patch is needed to revert a08799cf17c2 ("usb:phy: New usb phy notification port status API"). Thanks, Stanley > On 06-11-23, 12:15, Greg Kroah-Hartman wrote: > > On Mon, Nov 06, 2023 at 12:06:51PM +0100, Johan Hovold wrote: > > > The recently added Realtek PHY drivers depend on the new port status > > > notification mechanism which was built on the deprecated USB PHY > > > implementation and devicetree binding. > > > > > > Specifically, using these PHYs would require describing the very > > > same PHY using both the generic "phy" property and the deprecated > "usb-phy" > > > property which is clearly wrong. > > > > > > We should not be building new functionality on top of the legacy USB > > > PHY implementation even if it is currently stuck in some kind of > > > transitional limbo. > > > > > > Revert the new Realtek PHY drivers for now so that the port status > > > notification interface can be reverted and replaced before we dig > > > ourselves into an even deeper hole with this PHY mess. > > > > > > Note that there are no upstream users of these PHYs and the drivers > > > were only included in 6.6 so there should still be time to undo this. > > > > No users of these phy drivers yet? Why were they added? > > Not sure why, they didnt go thru phy ss! > > > > > > Preferably these should go in through Greg's tree for 6.7-rc1. > > > > I'll be glad to take this if I can get an ack for it. > > Pls do drop this: > > Acked-by: Vinod Koul <vkoul@kernel.org> > > -- > ~Vinod
On Tue, Nov 07, 2023 at 06:44:26AM +0000, Stanley Chang[昌育德] wrote: > Hi Johan and Vinod, > > I modified the Realtek phy to solve this issue and only use the generic PHY. > And submitted these patches today as follows > https://lore.kernel.org/linux-usb/20231107063518.27824-1-stanley_chang@realtek.com/ > https://lore.kernel.org/linux-usb/20231107063518.27824-2-stanley_chang@realtek.com/ > https://lore.kernel.org/linux-usb/20231107063518.27824-3-stanley_chang@realtek.com/ > https://lore.kernel.org/linux-usb/20231107063518.27824-4-stanley_chang@realtek.com/ > > I don't think this patch is needed to revert a08799cf17c2 ("usb:phy: New usb phy notification port status API"). I had already applied those reverts yesterday, but forgot to push them out (sorry about that, now fixed.) Let's start over here and you can rebase your new series on the 6.7-rc1. thanks, greg k-h
Hi Greg, > On Tue, Nov 07, 2023 at 06:44:26AM +0000, Stanley Chang[昌育德] wrote: > > Hi Johan and Vinod, > > > > I modified the Realtek phy to solve this issue and only use the generic PHY. > > And submitted these patches today as follows > > https://lore.kernel.org/linux-usb/20231107063518.27824-1-stanley_chang > > @realtek.com/ > > https://lore.kernel.org/linux-usb/20231107063518.27824-2-stanley_chang > > @realtek.com/ > > https://lore.kernel.org/linux-usb/20231107063518.27824-3-stanley_chang > > @realtek.com/ > > https://lore.kernel.org/linux-usb/20231107063518.27824-4-stanley_chang > > @realtek.com/ > > > > I don't think this patch is needed to revert a08799cf17c2 ("usb:phy: New usb > phy notification port status API"). > > I had already applied those reverts yesterday, but forgot to push them out > (sorry about that, now fixed.) Let's start over here and you can rebase your > new series on the 6.7-rc1. Okay, I will resubmit later. Thanks, Stanley > thanks, > > greg k-h