lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1429109670.30601.5.camel@linaro.org>
Date:	Wed, 15 Apr 2015 17:54:30 +0300
From:	"Ivan T. Ivanov" <ivan.ivanov@...aro.org>
To:	Robert Baldyga <r.baldyga@...sung.com>
Cc:	Peter Chen <Peter.Chen@...escale.com>,
	Kumar Gala <galak@...eaurora.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-usb@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v2] usb: chipidea: Use extcon framework for VBUS and ID
 detect


Hi Robert,

On Wed, 2015-04-15 at 16:11 +0200, Robert Baldyga wrote:
> Hi Ivan,
> 
> On 04/15/2015 03:35 PM, Ivan T. Ivanov wrote:
> > On recent Qualcomm platforms VBUS and ID lines are not routed to
> > USB PHY LINK controller. Use extcon framework to receive connect
> > and disconnect ID and VBUS notification.
> > 
> > Signed-off-by: Ivan T. Ivanov ivanov@...aro.org>
> > ---
> > 
> > Changes since v0 [1], as per Peter Chen suggestions:
> > 
> > * Moved external connector parsing code to ci_get_platdata()
> > * Moved external connector related variables to struct ci_hdrc_platform_data
> > * Rename ci_host_notifier() to ci_id_notifier()
> > * Fixed device bindings description
> > * Use select EXTCON framework, instead of depends on.
> > 
> > [1] https://lkml.org/lkml/2015/4/9/116
> > 
> >  .../devicetree/bindings/usb/ci-hdrc-qcom.txt       |  9 +++
> >  drivers/usb/chipidea/Kconfig                       |  1 +
> >  drivers/usb/chipidea/core.c                        | 87 ++++++++++++++++++++++
> >  drivers/usb/chipidea/otg.c                         | 26 ++++++-
> >  include/linux/usb/chipidea.h                       | 17 +++++
> >  5 files changed, 139 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt 
> > b/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt
> > index f2899b5..c635aca 100644
> > --- a/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt
> > +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt
> > @@ -7,6 +7,14 @@ Required properties:
> >  - usb-phy:      phandle for the PHY device
> >  - dr_mode:      Should be "peripheral"
> > 
> > +Optional properties:
> > +- extcon:       phandles to external connector devices. First phandle
> > +                should point to external connector, which provide "USB"
> > +                cable events, the second should point to external connector
> > +                device, which provide "USB-HOST" cable events. If one of
> > +                the external connector devices is not required, empty <0>
> > +                phandle should be specified.
> 
> Do you expect to have "USB" and "USB-HOST" notifiers supplied by two
> different extcon drivers? It looks strange. I don't think so that we
> ever will need to deal with such weird configuration.

Yes. That is what I have today on my desk.

> 
> > +
> >  Examples:
> >        gadget@...55000 {
> >                 compatible = "qcom,ci-hdrc";
> > @@ -14,4 +22,5 @@ Examples:
> >                 dr_mode = "peripheral";
> >                 interrupts = <0 134 0>;
> >                 usb-phy = <&usbphy0>;
> > +               extcon = <0>, <&usb_id>;
> >         };
> > diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
> > index 5ce3f1d..5619b8c 100644
> > --- a/drivers/usb/chipidea/Kconfig
> > +++ b/drivers/usb/chipidea/Kconfig
> > @@ -1,6 +1,7 @@
> >  config USB_CHIPIDEA
> >         tristate "ChipIdea Highspeed Dual Role Controller"
> >         depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD && !USB_GADGET) || 
> > (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA
> > +       select EXTCON
> >         help
> >                         Say Y here if your system has a dual role high speed USB
> >                         controller based on ChipIdea silicon IP. Currently, only the
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index 74fea4f..e1d495d 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -47,6 +47,7 @@
> >  #include <linux/delay.h>
> >  #include <linux/device.h>
> >  #include <linux/dma-mapping.h>
> > +#include <linux/extcon.h>
> >  #include <linux/phy/phy.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/module.h>
> > @@ -557,9 +558,39 @@ static irqreturn_t ci_irq(int irq, void *data)
> >         return ret;
> >  }
> > 
> > +static int ci_vbus_notifier(struct notifier_block *nb, unsigned long event,
> > +                               void *ptr)
> > +{
> > +       struct ci_hdrc_cable *vbus = container_of(nb, struct ci_hdrc_cable, nb);
> > +
> > +       if (event)
> > +               vbus->state = true;
> > +       else
> > +               vbus->state = false;
> > +
> > +       return NOTIFY_DONE;
> > +}
> 
> Actually it's not true that "USB" cable state is equal to VBUS state.

But this is how it supposed to work right now, no?

I have to admit that the naming is really confusing.

> "USB" and "USB-HOST" are mutually exclusive, and when you have ID=0,
> which means "USB-HOST" is connected, "USB cable will be seen as
> disconnected even when VBUS=1.
> 
> We are currently discussing how to pass VBUS state to USB OTG drivers.
> You can find discussion here:
> http://www.spinics.net/lists/linux-usb/msg123895.html

Sure, I am following this discussion. When it settles down, I can change
this as appropriate, until then this is what we will have in 4.1.

It will be messy refactoring, I think. All extcon providers and consumers
are using strings to denote cable names. Not to mention that extcon-class
is using "USB-Host", while all others are using "USB-HOST".

Regards,
Ivan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ