Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933464AbcJMAtC (ORCPT ); Wed, 12 Oct 2016 20:49:02 -0400 Received: from vern.gendns.com ([206.190.152.46]:53118 "EHLO vern.gendns.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933152AbcJMAsy (ORCPT ); Wed, 12 Oct 2016 20:48:54 -0400 Subject: Re: [PATCH/RFT 07/12] USB: ohci-da8xx: Request gpios and handle interrupt in the driver To: Axel Haslam References: <1475858577-10366-1-git-send-email-ahaslam@baylibre.com> <1475858577-10366-8-git-send-email-ahaslam@baylibre.com> <22f1532a-b651-3330-b2ce-9a64a35c85af@lechnology.com> Cc: Greg KH , robh+dt@kernel.org, Sekhar Nori , Alan Stern , Kevin Hilman , Sergei Shtylyov , linux-usb@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org From: David Lechner Message-ID: Date: Wed, 12 Oct 2016 18:31:18 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vern.gendns.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lechnology.com X-Get-Message-Sender-Via: vern.gendns.com: authenticated_id: davidmain+lechnology.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: vern.gendns.com: davidmain@lechnology.com X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1550 Lines: 34 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.