From: Chunfeng Yun <email@example.com> To: Thierry Reding <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: Wed, 26 May 2021 09:44:47 +0800 [thread overview] Message-ID: <1621993487.26501.19.camel@mhfsdcap03> (raw) In-Reply-To: <YKzhPnMU3PXx+tXK@orome.fritz.box> On Tue, 2021-05-25 at 13:36 +0200, Thierry Reding wrote: > 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. Got it, thanks a lot > > Thierry _______________________________________________ linux-arm-kernel mailing list email@example.com http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2021-05-26 1:47 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 2021-05-26 1:44 ` Chunfeng Yun [this message]
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=1621993487.26501.19.camel@mhfsdcap03 \ --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).