From: Thierry Reding <email@example.com> To: Chunfeng Yun <firstname.lastname@example.org> Cc: Greg Kroah-Hartman <email@example.com>, Liam Girdwood <firstname.lastname@example.org>, Mark Brown <email@example.com>, Matthias Brugger <firstname.lastname@example.org>, Paul Cercueil <email@example.com>, Lee Jones <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org> Subject: Re: [PATCH v2 3/3] Revert "usb: common: usb-conn-gpio: Make VBUS supply optional" Date: Tue, 25 May 2021 13:36:30 +0200 [thread overview] Message-ID: <YKzhPnMU3PXx+tXK@orome.fritz.box> (raw) In-Reply-To: <1621835511.26501.14.camel@mhfsdcap03> [-- Attachment #1.1: Type: text/plain, Size: 2105 bytes --] On Mon, May 24, 2021 at 01:51:51PM +0800, Chunfeng Yun wrote: > On Fri, 2021-05-21 at 15:20 +0200, Thierry Reding wrote: > > On Wed, May 19, 2021 at 02:39:46PM +0800, Chunfeng Yun wrote: > > > Vbus is already an optional supply, if the vbus-supply is not > > > provided in DTS, will use a dummy regulator, > > > > That statement is not entirely correct. The dummy regulator is > > substituted only if the supply is in fact not optional. The idea behind > > that is to allow DTS files that don't specify all required regulators to > > get away with it, based on the assumption that the supply is one of > > those always-on supplies that are often not described in DTS. > Yes, you are right. > But from the point of result, it indeed can help to handle the absent > regulator. > > > > > the warning log is as below: > > > "supply vbus not found, using dummy regulator" > > > > And the reason why we get that warning is to point out that the DTS has > > a bug and that it should be fixed (by adding a proper regulator to take > > the place of the dummy). > > > > > This reverts commit 4ddf1ac79e5f082451cd549283d2eb7559ab6ca9. > > > > But if you read the description of that commit, the purpose of that > > patch was in fact to make the supply completely optional in the case > > where we already have the VBUS supply specified for the USB port that > > the connector is parented to. > Could you please give an example you mentioned? You can find examples of this in these: arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts > It seems prefer to provide vbus supply in connector instead of port > according to dt-binding My recollection is that the above (or at least some of them) predate USB connectors. It's possible that we could convert the above to have the VBUS supply listed in the connector instead of the port. However, since we have to preserve backwards compatibility with older device trees, we can't revert the commit anyway. Thierry [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list email@example.com http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-05-25 11:36 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-19 6:39 [PATCH v2 1/3] usb: common: usb-conn-gpio: fix NULL pointer dereference of charger Chunfeng Yun 2021-05-19 6:39 ` [PATCH v2 2/3] usb: common: usb-conn-gpio: use dev_err_probe() to print log Chunfeng Yun 2021-05-19 6:39 ` [PATCH v2 3/3] Revert "usb: common: usb-conn-gpio: Make VBUS supply optional" Chunfeng Yun 2021-05-21 13:20 ` Thierry Reding 2021-05-21 18:06 ` Greg Kroah-Hartman 2021-05-24 5:51 ` Chunfeng Yun 2021-05-25 11:36 ` Thierry Reding [this message] 2021-05-26 1:44 ` Chunfeng Yun
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YKzhPnMU3PXx+tXK@orome.fritz.box \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v2 3/3] Revert "usb: common: usb-conn-gpio: Make VBUS supply optional"' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).