Message ID | 20231208210458.912776-2-CFSworks@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp5719460vqy; Fri, 8 Dec 2023 13:05:31 -0800 (PST) X-Google-Smtp-Source: AGHT+IHir2VCYXjBUuhhh1jjbhg6EuMpdL6TbtATzgjHLjjtfVYwcGYCbkUTUgvRHKInaOJBchB5 X-Received: by 2002:a17:90a:6c02:b0:286:6cc1:2cd8 with SMTP id x2-20020a17090a6c0200b002866cc12cd8mr587912pjj.98.1702069531369; Fri, 08 Dec 2023 13:05:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702069531; cv=none; d=google.com; s=arc-20160816; b=ioxwmqKjMOLDYJP1lAQSr1e/+6J4A5Is49FwxoAglwFfEYVbGYUUOOx4+acZD7uWzq VyfKHusEL4Vi/XGeCX1hLGtPZLw7NkPzeLCItyibfhbjjbbeSDe3GCB2/4L+TPfhXI3N XmCeUB8/WZQ4nIauQPCR9QOhiHfPB1QuBs+qaQ0pgn0kTV/m3GHlWWnFV87BYNsbDj5E IRczWE+kkg/7OZOp0NJSwGsHPQEZcioFd6CobsdHL0KtA4SVipRMtGYrZpCdJ0sIqPNe F/eRWPHbFMTC3FYvnprDILypdEDKP0tLIdtrGjIIyejBUoClzTt+A+HAWIdJtqGJbVE0 KGXw== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=X7JrVD5PKv0frUWLpY5zIGIkfAkbUXW6B5RnmTRZ8nk=; fh=d9TSyadBXPDybutOgGlYLsH9jqXf9pJuF0lO8Gj/Fg4=; b=Z8E2ZV7Eryjf78xSpL8eMIf1IxSWSgAbNGsW2U+SNn8U4/sCrmw5iakVYwcABG4hz7 4//YK/BQ6hP707w1XoL12PJp3f042WrJgA9KKLzPxHB00jXSjSnKaEDCbWGgdQlwyvDI B+Gor8i17/9btVHb6gywdlGQnokukEoN1T5IN/awuQNBd8EeJ4sGfRy5ndlPSjIz0Gk3 unBfxg8XcOZQA5x67IYkHfPBu8YOQZ8tLiZkLlKOW3uawdq2DJAES/jAwGzOIMCw5JWl EwHtF5Zc7RKa7cQlISDQWwyY9arefa5KkUIC7oI7xJfGWclTaphwhA77kMvySuhNjnXU Dwyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=e2xgLwD9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from pete.vger.email (pete.vger.email. [23.128.96.36]) by mx.google.com with ESMTPS id pm17-20020a17090b3c5100b002869aab8f55si2212859pjb.52.2023.12.08.13.05.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Dec 2023 13:05:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=e2xgLwD9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 3ABCB8359395; Fri, 8 Dec 2023 13:05:26 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234293AbjLHVFM (ORCPT <rfc822;makky5685@gmail.com> + 99 others); Fri, 8 Dec 2023 16:05:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43976 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1574766AbjLHVFJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 8 Dec 2023 16:05:09 -0500 Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6C0601738; Fri, 8 Dec 2023 13:05:14 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id e9e14a558f8ab-35d718382b7so9075705ab.1; Fri, 08 Dec 2023 13:05:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702069513; x=1702674313; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=X7JrVD5PKv0frUWLpY5zIGIkfAkbUXW6B5RnmTRZ8nk=; b=e2xgLwD9psUc+MsvWqMkW0QrVy1p0uKRYDewy97dmO5ey/Rys1z/H0JNaItbtnh7xK /HliAnS4ZAUKIjS5Dwu72S7MQRWXpnmkRgAfVIZHXO2zilbmZIhRdE2JgQIvYrYnquJb 766YkWrtr7l8W4jT18oIBywEk4lkvuu5QccI8HZrgqHkUg1AL589delH3zltxMVfMQdP XiE1PfRzTdZ1jQlvLl24y+Cg19sMSpAUF4bveL2oGrb4gZVL+penr1J57P9Ee7bzbXox AlCcUYt3SQKzUtq2EAQpcLQFmiJRx/QfPWbmpiqmcyqWsZBFtyvPpXaK5IdJviTKUukI 8AnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702069513; x=1702674313; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=X7JrVD5PKv0frUWLpY5zIGIkfAkbUXW6B5RnmTRZ8nk=; b=l7NRnQPxLN1x1QXx+4mYAWJ6if9+KR764tJj4fQzEtwR2LcE6dXUn0uDnWXx98dyxn XThi24Br2CXje+1f2JOhUF2CerxSWcoeZG/gSIwUzHLLuPL+vJHwyh9AUWMW8fHKxgIc etCi7E6TVF/iXBzb2UJskgedjnQXsFeS2UklQzzd7B5iCH8Nhcp0JUEYKMZcD3Ns8fqX oGxqGWAp19o6KsVK5i5haE8mpGJlSbCFFVApdA8PbMXY8PSdtx+/Nd/fFs9cRFRaM0mN o/+uelPkhDHqkuF///8SDIITY9IzsjMUWXOTscNgvDYXlICn1E7GYTkPuV1eMiQdvpGs lFMg== X-Gm-Message-State: AOJu0YyrHz0bB/Ywzt27bdUmbVaCMdRVQ2J/XZ9AqmgPFaRlDhpUqKyh 6NKUFtAIbs1F8Yli0z/xPlM= X-Received: by 2002:a92:c248:0:b0:35c:50f7:b18c with SMTP id k8-20020a92c248000000b0035c50f7b18cmr934433ilo.0.1702069513690; Fri, 08 Dec 2023 13:05:13 -0800 (PST) Received: from celestia.nettie.lan ([2001:470:42c4:101:971d:15c7:de39:3b4b]) by smtp.gmail.com with ESMTPSA id g12-20020a056e020d0c00b0035d5a1760c1sm736458ilj.69.2023.12.08.13.05.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Dec 2023 13:05:13 -0800 (PST) From: Sam Edwards <cfsworks@gmail.com> X-Google-Original-From: Sam Edwards <CFSworks@gmail.com> To: Mathias Nyman <mathias.nyman@intel.com>, Thinh Nguyen <Thinh.Nguyen@synopsys.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Heiko Stuebner <heiko@sntech.de>, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Sam Edwards <CFSworks@gmail.com> Subject: [PATCH 1/2] xhci: Introduce "disable-usb3" DT property/quirk Date: Fri, 8 Dec 2023 14:04:57 -0700 Message-ID: <20231208210458.912776-2-CFSworks@gmail.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231208210458.912776-1-CFSworks@gmail.com> References: <20231208210458.912776-1-CFSworks@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 pete.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 (pete.vger.email [0.0.0.0]); Fri, 08 Dec 2023 13:05:26 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784749261092088691 X-GMAIL-MSGID: 1784749261092088691 |
Series |
Allow disabling USB3 ports in xHCI/DWC3
|
|
Commit Message
Sam Edwards
Dec. 8, 2023, 9:04 p.m. UTC
Some systems may have xHCI controllers that enumerate USB 3.0 ports, but
these ports nevertheless cannot be used. Perhaps enabling them triggers a
hardware bug, or perhaps they simply aren't connected and it would be
confusing to the user to see an unusable USB 3.0 rhub show up -- whatever
the case may be, it's reasonable to want to disable these ports.
Add a DT property (and associated quirk) to the xHCI driver that skips
over (i.e. ignores and doesn't initialize) any USB 3.0 ports discovered
during driver initialization.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
---
Documentation/devicetree/bindings/usb/usb-xhci.yaml | 4 ++++
drivers/usb/host/xhci-mem.c | 4 ++++
drivers/usb/host/xhci-plat.c | 3 +++
drivers/usb/host/xhci.h | 1 +
4 files changed, 12 insertions(+)
Comments
On 08/12/2023 22:04, Sam Edwards wrote: > Some systems may have xHCI controllers that enumerate USB 3.0 ports, but > these ports nevertheless cannot be used. Perhaps enabling them triggers a > hardware bug, or perhaps they simply aren't connected and it would be > confusing to the user to see an unusable USB 3.0 rhub show up -- whatever > the case may be, it's reasonable to want to disable these ports. > > Add a DT property (and associated quirk) to the xHCI driver that skips > over (i.e. ignores and doesn't initialize) any USB 3.0 ports discovered > during driver initialization. > > Signed-off-by: Sam Edwards <CFSworks@gmail.com> > --- > Documentation/devicetree/bindings/usb/usb-xhci.yaml | 4 ++++ Bindings are always separate patches. Please do not sneak in properties without DT review. Please use scripts/get_maintainers.pl to get a list of necessary people and lists to CC. It might happen, that command when run on an older kernel, gives you outdated entries. Therefore please be sure you base your patches on recent Linux kernel. You missed at least devicetree list (maybe more), so this won't be tested by automated tooling. Performing review on untested code might be a waste of time, thus I will skip this patch entirely till you follow the process allowing the patch to be tested. Please kindly resend and include all necessary To/Cc entries. Best regards, Krzysztof
On 12/9/23 06:53, Krzysztof Kozlowski wrote: > On 08/12/2023 22:04, Sam Edwards wrote: >> Some systems may have xHCI controllers that enumerate USB 3.0 ports, but >> these ports nevertheless cannot be used. Perhaps enabling them triggers a >> hardware bug, or perhaps they simply aren't connected and it would be >> confusing to the user to see an unusable USB 3.0 rhub show up -- whatever >> the case may be, it's reasonable to want to disable these ports. >> >> Add a DT property (and associated quirk) to the xHCI driver that skips >> over (i.e. ignores and doesn't initialize) any USB 3.0 ports discovered >> during driver initialization. >> >> Signed-off-by: Sam Edwards <CFSworks@gmail.com> >> --- >> Documentation/devicetree/bindings/usb/usb-xhci.yaml | 4 ++++ Hi Krzysztof, > > Bindings are always separate patches. > > Please do not sneak in properties without DT review. > It makes sense that the new property should be introduced in a separate patch. I'll ensure that is the case in v2. (If there is one -- see below.) > Please use scripts/get_maintainers.pl to get a list of necessary people > and lists to CC. It might happen, that command when run on an older > kernel, gives you outdated entries. Therefore please be sure you base > your patches on recent Linux kernel. > > You missed at least devicetree list (maybe more), so this won't be > tested by automated tooling. I have tried (and failed) to find the documentation for this linux-devicetree bot. Do you have the link? In particular, I'd like to ensure that patch 2/2 (the one that actually changes established behavior) is tested sufficiently thoroughly. > Performing review on untested code might be > a waste of time, thus I will skip this patch entirely till you follow > the process allowing the patch to be tested. That's fine; this patch has just failed review anyway (due to the new property not being introduced in a separate patch), and I'll need to prepare and send a v2 to proceed. However as I mentioned in the cover, this is a semi-RFC. I haven't discussed the overall idea with anyone yet, so to avoid wasting my own time, I need to give the USB folks ample opportunity to object to the proposed changes or suggest improvements before investing more effort in refining the patchset. As of now, I'm only seeking commentary, not formal review. I'd appreciate any insights on the approach I've taken and whether there are any potential challenges or alternatives that haven't been explored yet. Therefore, I'll hold off on CC-ing linux-devicetree at this stage to keep the focus on the broader concept, and will loop them in (with any other recipients as appropriate) for v2 when (and if!) there's consensus here on linux-usb that the general direction is worth pursuing. > > Please kindly resend and include all necessary To/Cc entries. > > Best regards, > Krzysztof > Happy Saturday, Sam
On 09/12/2023 20:26, Sam Edwards wrote: >> Performing review on untested code might be >> a waste of time, thus I will skip this patch entirely till you follow >> the process allowing the patch to be tested. > > That's fine; this patch has just failed review anyway (due to the new > property not being introduced in a separate patch), and I'll need to > prepare and send a v2 to proceed. However as I mentioned in the cover, > this is a semi-RFC. I haven't discussed the overall idea with anyone > yet, so to avoid wasting my own time, I need to give the USB folks ample It does not really explain why you did not Cc some of the maintainers. If this is a RFC, even though not marked as such in subject prefix, then I guess all maintainers should be involved for comments. Best regards, Krzysztof
On 12/10/23 04:10, Krzysztof Kozlowski wrote: > It does not really explain why you did not Cc some of the maintainers. > If this is a RFC, even though not marked as such in subject prefix, then > I guess all maintainers should be involved for comments. Hi Krzysztof, More simply put: I don't want to waste anyone's time by seeking review/commentary from linux-devicetree on a property enabling a feature that someone here on linux-usb might soon deem (summarily) untenable. I agree fully that I need (and want) the DT reviewers' sign-off on this new property, and I'll get more serious about that (and other things) in v2. I just need to know if there's going to be a v2 first. Warm regards, Sam
Am Freitag, 8. Dezember 2023, 22:04:57 CET schrieb Sam Edwards: > Some systems may have xHCI controllers that enumerate USB 3.0 ports, but > these ports nevertheless cannot be used. Perhaps enabling them triggers a > hardware bug, or perhaps they simply aren't connected and it would be > confusing to the user to see an unusable USB 3.0 rhub show up -- whatever > the case may be, it's reasonable to want to disable these ports. > > Add a DT property (and associated quirk) to the xHCI driver that skips > over (i.e. ignores and doesn't initialize) any USB 3.0 ports discovered > during driver initialization. > > Signed-off-by: Sam Edwards <CFSworks@gmail.com> I'm very much unsure, where the line goes between hw-quirk and dt-is-not-a-configuration-space - in this specific instance. DT is meant to describe the actual hardware present and not how any operating system supports it. So having that usb3phy present in the kernel - even if only in a more limited form as you describe would be my preference. But for a short-term thing, the usb3-phy in the binding is optional, so so you could "just" deduce the no-usb3 state in your code from its absence from the dt-node? Heiko > Documentation/devicetree/bindings/usb/usb-xhci.yaml | 4 ++++ > drivers/usb/host/xhci-mem.c | 4 ++++ > drivers/usb/host/xhci-plat.c | 3 +++ > drivers/usb/host/xhci.h | 1 + > 4 files changed, 12 insertions(+) > > diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.yaml b/Documentation/devicetree/bindings/usb/usb-xhci.yaml > index 180a261c3e8f..8a64e747260a 100644 > --- a/Documentation/devicetree/bindings/usb/usb-xhci.yaml > +++ b/Documentation/devicetree/bindings/usb/usb-xhci.yaml > @@ -25,6 +25,10 @@ properties: > description: Set if the controller has broken port disable mechanism > type: boolean > > + disable-usb3: > + description: Ignore (don't initialize, don't use) USB3 ports > + type: boolean > + > imod-interval-ns: > description: Interrupt moderation interval > default: 5000 > diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c > index 0a37f0d511cf..bf8fcab626e4 100644 > --- a/drivers/usb/host/xhci-mem.c > +++ b/drivers/usb/host/xhci-mem.c > @@ -1968,6 +1968,10 @@ static void xhci_add_in_port(struct xhci_hcd *xhci, unsigned int num_ports, > minor_revision = XHCI_EXT_PORT_MINOR(temp); > > if (major_revision == 0x03) { > + /* Ignore USB3 ports entirely if USB3 support is disabled. */ > + if (xhci->quirks & XHCI_DISABLE_USB3) > + return; > + > rhub = &xhci->usb3_rhub; > /* > * Some hosts incorrectly use sub-minor version for minor > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c > index b93161374293..75285fb5bbbc 100644 > --- a/drivers/usb/host/xhci-plat.c > +++ b/drivers/usb/host/xhci-plat.c > @@ -249,6 +249,9 @@ int xhci_plat_probe(struct platform_device *pdev, struct device *sysdev, const s > if (device_property_read_bool(tmpdev, "quirk-broken-port-ped")) > xhci->quirks |= XHCI_BROKEN_PORT_PED; > > + if (device_property_read_bool(tmpdev, "disable-usb3")) > + xhci->quirks |= XHCI_DISABLE_USB3; > + > device_property_read_u32(tmpdev, "imod-interval-ns", > &xhci->imod_interval); > } > diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h > index 5df370482521..c53fbeea478f 100644 > --- a/drivers/usb/host/xhci.h > +++ b/drivers/usb/host/xhci.h > @@ -1906,6 +1906,7 @@ struct xhci_hcd { > #define XHCI_RESET_TO_DEFAULT BIT_ULL(44) > #define XHCI_ZHAOXIN_TRB_FETCH BIT_ULL(45) > #define XHCI_ZHAOXIN_HOST BIT_ULL(46) > +#define XHCI_DISABLE_USB3 BIT_ULL(47) > > unsigned int num_active_eps; > unsigned int limit_active_eps; >
On 12/12/23 12:31, Heiko Stuebner wrote: > Am Freitag, 8. Dezember 2023, 22:04:57 CET schrieb Sam Edwards: >> Some systems may have xHCI controllers that enumerate USB 3.0 ports, but >> these ports nevertheless cannot be used. Perhaps enabling them triggers a >> hardware bug, or perhaps they simply aren't connected and it would be >> confusing to the user to see an unusable USB 3.0 rhub show up -- whatever >> the case may be, it's reasonable to want to disable these ports. >> >> Add a DT property (and associated quirk) to the xHCI driver that skips >> over (i.e. ignores and doesn't initialize) any USB 3.0 ports discovered >> during driver initialization. >> >> Signed-off-by: Sam Edwards <CFSworks@gmail.com> Ahoy Heiko, Glad to have you in the thread! > I'm very much unsure, where the line goes between hw-quirk and > dt-is-not-a-configuration-space - in this specific instance. > > DT is meant to describe the actual hardware present and not how > any operating system supports it. I can plumb this quirk through something other than DT if there's an objection to it; however, the intended meaning of this property is indeed hardware-description and not OS-configuration: "This xHC does NOT support USB3. Do not let it tell you otherwise by enumerating USB3 ports; it is mistaken. Attempting to enable the USB3 'ports' will at worst provoke a hardware bug and at best register a usb3 rhub for something that doesn't physically exist." For v2, I should probably rename the property from something "imperative" ("disable-usb3;") to something "declarative," like "no-usb3;" or "usb3-unconnected;" in order to reflect this intended meaning better. The linux-devicetree reviewers (which I will be looping in with v2) will probably prefer a name like that anyway. > So having that usb3phy present in the kernel - even if only in > a more limited form as you describe would be my preference. > > > But for a short-term thing, the usb3-phy in the binding is optional, so > so you could "just" deduce the no-usb3 state in your code from its > absence from the dt-node? Ah, so while there is a short-term benefit, this is actually meant to be long-term: on the Turing RK1 PCB itself, USB-DWC3 #0 is only wired for USB 2.0, not USB 3.0. The corresponding USBDP PHY pins are connected to (dedicated) DisplayPort pins. This means there are 4 options: 1. Proceed without enabling that USB-DWC3 at all, giving up USB 2.0. 2. Enable the USBDP in USB3 mode, gaining USB 2.0 but giving up DP. 3. Enable the USBDP in DP mode, having the USB3-PIPE backend initialized (but disconnected from the frontend), as a "pacifier" for the DWC3 so it doesn't start misbehaving. 4. Disable the USB3 ports on the xHC side, by... a. Telling the xHCI driver that it shouldn't enable USB3 ports. b. Configuring the DWC3 not to enable USB3 (see the RK3588 TRM for usb3otg0_host_u3_port_disable) c. Configuring the DWC3's number of USB3 ports (usb3otg0_host_num_u3_port) Users won't like #1 or #2, and may be confused by #3 due to the dummy port that shows up. Options #2 and #3 aren't possible until a USBDP driver lands (though you're right that this is only a short-term concern). Option 4a is what I'm currently trying to do because I believe having physically-inaccessible USB3 ports show up in Linux is undesirable in any case, but I can switch to 4b/4c if we want something more SoC-specific. So (as far as RK3588 is concerned) with option(s) 4(a/b/c), while this does let USB2.0 work before the USBDP driver lands, the "real" benefit is that it requires neither a dummy port nor powering up a block of the chip (the PHY's USB3-specific block) that isn't actually usable/useful because it doesn't connect to a USB 3.0 socket/device. Though if that still doesn't sound appealing, I'm happy to change up the approach -- I guess the question then is whether it's because you *like* option 3, or *dislike* option 4. Cheers, Sam > > > Heiko > > > >> Documentation/devicetree/bindings/usb/usb-xhci.yaml | 4 ++++ >> drivers/usb/host/xhci-mem.c | 4 ++++ >> drivers/usb/host/xhci-plat.c | 3 +++ >> drivers/usb/host/xhci.h | 1 + >> 4 files changed, 12 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.yaml b/Documentation/devicetree/bindings/usb/usb-xhci.yaml >> index 180a261c3e8f..8a64e747260a 100644 >> --- a/Documentation/devicetree/bindings/usb/usb-xhci.yaml >> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.yaml >> @@ -25,6 +25,10 @@ properties: >> description: Set if the controller has broken port disable mechanism >> type: boolean >> >> + disable-usb3: >> + description: Ignore (don't initialize, don't use) USB3 ports >> + type: boolean >> + >> imod-interval-ns: >> description: Interrupt moderation interval >> default: 5000 >> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c >> index 0a37f0d511cf..bf8fcab626e4 100644 >> --- a/drivers/usb/host/xhci-mem.c >> +++ b/drivers/usb/host/xhci-mem.c >> @@ -1968,6 +1968,10 @@ static void xhci_add_in_port(struct xhci_hcd *xhci, unsigned int num_ports, >> minor_revision = XHCI_EXT_PORT_MINOR(temp); >> >> if (major_revision == 0x03) { >> + /* Ignore USB3 ports entirely if USB3 support is disabled. */ >> + if (xhci->quirks & XHCI_DISABLE_USB3) >> + return; >> + >> rhub = &xhci->usb3_rhub; >> /* >> * Some hosts incorrectly use sub-minor version for minor >> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c >> index b93161374293..75285fb5bbbc 100644 >> --- a/drivers/usb/host/xhci-plat.c >> +++ b/drivers/usb/host/xhci-plat.c >> @@ -249,6 +249,9 @@ int xhci_plat_probe(struct platform_device *pdev, struct device *sysdev, const s >> if (device_property_read_bool(tmpdev, "quirk-broken-port-ped")) >> xhci->quirks |= XHCI_BROKEN_PORT_PED; >> >> + if (device_property_read_bool(tmpdev, "disable-usb3")) >> + xhci->quirks |= XHCI_DISABLE_USB3; >> + >> device_property_read_u32(tmpdev, "imod-interval-ns", >> &xhci->imod_interval); >> } >> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h >> index 5df370482521..c53fbeea478f 100644 >> --- a/drivers/usb/host/xhci.h >> +++ b/drivers/usb/host/xhci.h >> @@ -1906,6 +1906,7 @@ struct xhci_hcd { >> #define XHCI_RESET_TO_DEFAULT BIT_ULL(44) >> #define XHCI_ZHAOXIN_TRB_FETCH BIT_ULL(45) >> #define XHCI_ZHAOXIN_HOST BIT_ULL(46) >> +#define XHCI_DISABLE_USB3 BIT_ULL(47) >> >> unsigned int num_active_eps; >> unsigned int limit_active_eps; >> > > > >
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.yaml b/Documentation/devicetree/bindings/usb/usb-xhci.yaml index 180a261c3e8f..8a64e747260a 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/usb-xhci.yaml @@ -25,6 +25,10 @@ properties: description: Set if the controller has broken port disable mechanism type: boolean + disable-usb3: + description: Ignore (don't initialize, don't use) USB3 ports + type: boolean + imod-interval-ns: description: Interrupt moderation interval default: 5000 diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index 0a37f0d511cf..bf8fcab626e4 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -1968,6 +1968,10 @@ static void xhci_add_in_port(struct xhci_hcd *xhci, unsigned int num_ports, minor_revision = XHCI_EXT_PORT_MINOR(temp); if (major_revision == 0x03) { + /* Ignore USB3 ports entirely if USB3 support is disabled. */ + if (xhci->quirks & XHCI_DISABLE_USB3) + return; + rhub = &xhci->usb3_rhub; /* * Some hosts incorrectly use sub-minor version for minor diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index b93161374293..75285fb5bbbc 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -249,6 +249,9 @@ int xhci_plat_probe(struct platform_device *pdev, struct device *sysdev, const s if (device_property_read_bool(tmpdev, "quirk-broken-port-ped")) xhci->quirks |= XHCI_BROKEN_PORT_PED; + if (device_property_read_bool(tmpdev, "disable-usb3")) + xhci->quirks |= XHCI_DISABLE_USB3; + device_property_read_u32(tmpdev, "imod-interval-ns", &xhci->imod_interval); } diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h index 5df370482521..c53fbeea478f 100644 --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -1906,6 +1906,7 @@ struct xhci_hcd { #define XHCI_RESET_TO_DEFAULT BIT_ULL(44) #define XHCI_ZHAOXIN_TRB_FETCH BIT_ULL(45) #define XHCI_ZHAOXIN_HOST BIT_ULL(46) +#define XHCI_DISABLE_USB3 BIT_ULL(47) unsigned int num_active_eps; unsigned int limit_active_eps;