From: David Lechner <david@lechnology.com>
To: Axel Haslam <ahaslam@baylibre.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
robh+dt@kernel.org, Sekhar Nori <nsekhar@ti.com>,
Alan Stern <stern@rowland.harvard.edu>,
Kevin Hilman <khilman@baylibre.com>,
Sergei Shtylyov <sshtylyov@ru.mvista.com>,
linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH/RFT 07/12] USB: ohci-da8xx: Request gpios and handle interrupt in the driver
Date: Wed, 12 Oct 2016 18:31:18 -0500 [thread overview]
Message-ID: <ca0cd34a-c904-e3b8-b9a9-55017265dc89@lechnology.com> (raw)
In-Reply-To: <CAKXjFTMO_tCzLxc5wznrW_g6rxMYT8jBgHCtiFfpHq_6M=RZWA@mail.gmail.com>
On 10/12/2016 10:01 AM, Axel Haslam wrote:
> I agree that we should use a regulator for the vbus power.
> i will make that change. However, im not so sure about using the
> regulator for the overcurrent handling. There seems to be no other
> driver doing this, and as you mention, we would need to change the regulator
> framework, which might not be justifiable. I think there is not another way
> to handle the over current notification other than powering the port off.
The regulator framework has REGULATOR_EVENT_OVER_CURRENT already.
Perhaps this could be of some use? For example you could extend the
existing gpio-regulator driver with an optional overcurrent gpio pin.
>
> how about using regulator for vbus, but keeping gpio for overcurrent
> notifications?
See the suggestion above about extending the gpio-regulator driver.
> For the usersapce handling you describe above, maybe we should be able to
> listen for an usb overcurrent uevent in userspace? it seems this
> question was asked
> a couple of years back[1], but im not sure what the conclusion was. In any case,
> we could have DT and non-DT based ohci-da8xx working,
> And could work on a uevent notification for the scenario you describe
> above which
> i think is not specific to the ohci-da8xx.
>
> [1]http://linux-usb.vger.kernel.narkive.com/SjcUB5hk/how-best-to-get-over-current-notification-to-user-application
Thanks for the link. Too bad it seems nothing ever became of this. I
guess it will be up to me to bring up the discussion again if I really
want it.
next prev parent reply other threads:[~2016-10-13 0:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-07 16:42 [PATCH/RFT 00/12] Add DT support for ohci-da8xx ahaslam
2016-10-07 16:42 ` [PATCH/RFT 01/12] ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable ahaslam
2016-10-07 16:42 ` [PATCH/RFT 02/12] ARM: davinci: hawk: add full constraints for ohci plat boot ahaslam
2016-10-07 16:42 ` [PATCH/RFT 03/12] ARM: davinci: rename root_hub to platform_data ahaslam
2016-10-07 16:42 ` [PATCH/RFT 04/12] USB: ohci-da8xx: Divide power up time in the ohci driver ahaslam
2016-10-07 16:42 ` [PATCH/RFT 05/12] USB: ohci-da8xx: Fix probe for devices with no vbus/oci gpio ahaslam
2016-10-07 16:42 ` [PATCH/RFT 06/12] ARM: davinci: hawk: Remove oci and vbus gpios ahaslam
2016-10-07 16:42 ` [PATCH/RFT 07/12] USB: ohci-da8xx: Request gpios and handle interrupt in the driver ahaslam
2016-10-10 23:18 ` David Lechner
2016-10-12 15:01 ` Axel Haslam
2016-10-12 23:31 ` David Lechner [this message]
2016-10-07 16:42 ` [PATCH/RFT 08/12] ARM: davinci: register the usb20_phy clock on the SoC file ahaslam
2016-10-10 23:27 ` David Lechner
2016-10-07 16:42 ` [PATCH/RFT 09/12] usb: host: ohci-da8xx: Add devicetree bindings documentation ahaslam
2016-10-10 21:35 ` Rob Herring
2016-10-10 23:33 ` David Lechner
2016-10-07 16:42 ` [PATCH/RFT 10/12] USB: ohci-da8xx: Add device tree support ahaslam
2016-10-07 16:42 ` [PATCH/RFT 11/12] ARM: dts: da850: Add the usb ohci device node ahaslam
2016-10-07 17:11 ` Sergei Shtylyov
2016-10-07 16:42 ` [PATCH/RFT 12/12] ARM: dts: da850-lcdk: enable ohci usb ahaslam
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=ca0cd34a-c904-e3b8-b9a9-55017265dc89@lechnology.com \
--to=david@lechnology.com \
--cc=ahaslam@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=khilman@baylibre.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=robh+dt@kernel.org \
--cc=sshtylyov@ru.mvista.com \
--cc=stern@rowland.harvard.edu \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®