Re: [PATCH] phy: qcom-qmp: Add dependency on COMMON_CLK

[Kishon Vijay Abraham I]

On Friday 07 April 2017 01:37 AM, Vivek Gautam wrote:
> The driver uses clock provider interface, and therefore
> it fails to build when enabled for COMPILE_TEST, since
> COMMON_CLK is not enabled at that time.
> So, make PHY_QCOM_QMP depend on COMMON_CLK as well.
> 
> Cc: Fengguang Wu 
> Cc: Kishon Vijay Abraham I 
> Signed-off-by: Vivek Gautam 
> ---
> 
> Hi Kishon,
> 
> This patch is fixing the build failures for architectures
> such as, tile, and ia64, that don't enable COMMON_CLK by default.
> You can either squash this into the qmp phy driver patch,
> or put it as a separate patch with 'Fix' tag.
> Let me know if you want me to add a 'fix' tag with a reference
> to the commit ID.

I squashed it with your earlier patch and pushed.

Thanks
Kishon

> 
> Regards
> Vivek
> 
>  drivers/phy/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index bb8140355608..8550d3dc0b71 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -441,7 +441,7 @@ config PHY_STIH407_USB
>  
>  config PHY_QCOM_QMP
>   tristate "Qualcomm QMP PHY Driver"
> - depends on OF && (ARCH_QCOM || COMPILE_TEST)
> + depends on OF && COMMON_CLK && (ARCH_QCOM || COMPILE_TEST)
>   select GENERIC_PHY
>   help
> Enable this to support the QMP PHY transceiver that is used
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv3] phy: cpcap-usb: Add CPCAP PMIC USB support

[Tony Lindgren]

Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a
multiplexing USB PHY.

This USB PHY can operate at least in four modes using pin multiplexing
and two control GPIOS:

- Pass through companion PHY for the SoC USB PHY
- ULPI PHY for the SoC
- Pass through USB for the modem
- UART debug console for the SoC

This patch adds support for droid 4 USB PHY and debug UART modes,
support for other modes can be added later on as needed.

Both peripheral and host mode are working for the USB. The
host mode depends on the cpcap-charger driver for VBUS.

VBUS and ID pin detection are done using cpcap-adc IIO ADC
driver.

Cc: devicet...@vger.kernel.org
Cc: Marcel Partap 
Cc: Michael Scott 
Acked-by: Rob Herring 
Tested-by: Sebastian Reichel 
Signed-off-by: Tony Lindgren 
---

Changes since v2:
- Added extcon support as requested by Kishon

- Added Rob's ack

- Folded in Kconfig randconfig build fix to add depends on IIO

Changes since v1:
- Use iio_read_channel_processed() instead of iio_read_channel_scaled()
  as changed in the v2 of the ADC driver

- Kept Tested-by from Sebastian Reichel  as the change
  from v1 is trivial

---
 .../devicetree/bindings/phy/phy-cpcap-usb.txt  |  40 ++
 drivers/phy/Kconfig|   8 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-cpcap-usb.c| 734 +
 4 files changed, 783 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
 create mode 100644 drivers/phy/phy-cpcap-usb.c

diff --git a/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
@@ -0,0 +1,40 @@
+Motorola CPCAP PMIC USB PHY binding
+
+Required properties:
+compatible: Shall be either "motorola,cpcap-usb-phy" or
+   "motorola,mapphone-cpcap-usb-phy"
+#phy-cells: Shall be 0
+interrupts: CPCAP PMIC interrupts used by the USB PHY
+interrupt-names: Interrupt names
+io-channels: IIO ADC channels used by the USB PHY
+io-channel-names: IIO ADC channel names
+vusb-supply: Regulator for the PHY
+
+Optional properties:
+pinctrl: Optional alternate pin modes for the PHY
+pinctrl-names: Names for optional pin modes
+mode-gpios: Optional GPIOs for configuring alternate modes
+
+Example:
+cpcap_usb2_phy: phy {
+   compatible = "motorola,mapphone-cpcap-usb-phy";
+   pinctrl-0 = <_gpio_mux_sel1 _gpio_mux_sel2>;
+   pinctrl-1 = <_ulpi_pins>;
+   pinctrl-2 = <_utmi_pins>;
+   pinctrl-3 = <_pins>;
+   pinctrl-names = "default", "ulpi", "utmi", "uart";
+   #phy-cells = <0>;
+   interrupts-extended = <
+15 0  14 0  28 0  19 0
+18 0  17 0  16 0  49 0
+48 1
+   >;
+   interrupt-names =
+   "id_ground", "id_float", "se0conn", "vbusvld",
+   "sessvld", "sessend", "se1", "dm", "dp";
+   mode-gpios = < 28 GPIO_ACTIVE_HIGH
+  0 GPIO_ACTIVE_HIGH>;
+   io-channels = <_adc 2>, <_adc 7>;
+   io-channel-names = "vbus", "id";
+   vusb-supply = <>;
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -47,6 +47,14 @@ config PHY_BERLIN_SATA
help
  Enable this to support the SATA PHY on Marvell Berlin SoCs.
 
+config PHY_CPCAP_USB
+   tristate "CPCAP USB PHY driver"
+   depends on USB_SUPPORT && IIO
+   select GENERIC_PHY
+   select USB_PHY
+   help
+ Enable this for CPCAP USB to work.
+
 config ARMADA375_USBCLUSTER_PHY
def_bool y
depends on MACH_ARMADA_375 || COMPILE_TEST
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PHY_BCM_NS_USB2)   += phy-bcm-ns-usb2.o
 obj-$(CONFIG_PHY_BCM_NS_USB3)  += phy-bcm-ns-usb3.o
 obj-$(CONFIG_PHY_BERLIN_USB)   += phy-berlin-usb.o
 obj-$(CONFIG_PHY_BERLIN_SATA)  += phy-berlin-sata.o
+obj-$(CONFIG_PHY_CPCAP_USB)+= phy-cpcap-usb.o
 obj-$(CONFIG_PHY_DA8XX_USB)+= phy-da8xx-usb.o
 obj-$(CONFIG_PHY_DM816X_USB)   += phy-dm816x-usb.o
 obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
diff --git a/drivers/phy/phy-cpcap-usb.c b/drivers/phy/phy-cpcap-usb.c
new file mode 100644
--- /dev/null
+++ b/drivers/phy/phy-cpcap-usb.c
@@ -0,0 +1,734 @@
+/*
+ * Motorola CPCAP PMIC USB PHY driver
+ * Copyright (C) 2017 Tony Lindgren 
+ *
+ * Some parts based on earlier Motorola Linux kernel tree code in
+ * board-mapphone-usb.c and cpcap-usb-det.c:
+ * Copyright (C) 2007 - 2011 Motorola, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under 

Re: [PATCH 2/2] usb: host: xhci: using dma pool for scratchpad buffer

[Peter Chen]

On Thu, Mar 30, 2017 at 11:29:57AM +0300, Mathias Nyman wrote:
> >>
> >>the other way around. First you patch dma_alloc_coherent() to
> >>dma_zalloc_coherent() and that could go in during the -rc and possibly
> >>get a stable tag, since spec requires kernel to zero the memory area.
> >>
> >>--
> >>balbi
> >
> >In fact, it fixes two things at spec, the other thing is the scratchpad
> >buffer needs to be page_size boundary. I will send these two fixes
> >first.
> >
> 
> If I remember correctly dma_alloc_coherent() takes care of proper alignment
> and won't cross the boundary
> 

Sorry to reply late.

The dma_alloc_coherent design is different per platform, and both the
code include/linux/dma-mapping.h and doc Documentation/DMA-API.txt
does not mention boundary and alignment.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/6] usb: usbip tool: Check the return of get_nports()

[Yuyang Du]

On Fri, Apr 07, 2017 at 03:41:37PM +0200, Krzysztof Opasiak wrote:
> 
> 
> On 04/06/2017 12:03 AM, Yuyang Du wrote:
> >If we get nonpositive number of ports, there is no sense to
> >continue, then fail gracefully.
> >
> >In addition, the commit 0775a9cbc694e8c72 ("usbip: vhci extension:
> >modifications to vhci driver") introduced configurable numbers of
> >controllers and ports, but we have a static port number maximum,
> >MAXNPORT. If exceeded, the idev array will be overflown. We fix
> >it by validating the nports to make sure the port number max is
> >not exceeded.
> >
> >Signed-off-by: Yuyang Du 
> >---
> > tools/usb/usbip/libsrc/vhci_driver.c | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> >diff --git a/tools/usb/usbip/libsrc/vhci_driver.c 
> >b/tools/usb/usbip/libsrc/vhci_driver.c
> >index f659c14..151580a 100644
> >--- a/tools/usb/usbip/libsrc/vhci_driver.c
> >+++ b/tools/usb/usbip/libsrc/vhci_driver.c
> >@@ -220,9 +220,17 @@ int usbip_vhci_driver_open(void)
> > }
> >
> > vhci_driver->nports = get_nports();
> >-
> > dbg("available ports: %d", vhci_driver->nports);
> >
> >+if (vhci_driver->nports <=0) {
> >+err("no available ports");
> >+goto err;
> >+}
> >+else if (vhci_driver->nports > MAXNPORT) {
> >+err("port number exceeds %d", MAXNPORT);
> >+goto err;
> >+}
> >+
> > if (refresh_imported_device_list())
> > goto err;
> >
> >
> 
> Reviewed-by: Krzysztof Opasiak 

Thank you so much, Krzysztof.

Yuyang
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB Type-C Port Manager API concern

[Mats Karrman]

On 04/09/2017 05:16 PM, Guenter Roeck wrote:


Hi Mats,

On Sun, Apr 09, 2017 at 01:09:57AM +0200, Mats Karrman wrote:

I'm working on a tcpi driver and have some concern about the tcpm api.
The tcpm_register_port() is typically called from the probe function of
tcpi driver where the tcpm_port reference returned is stored in the
driver private data. The problem I ran into is that tcpm_register_port()
calls back to the not yet fully initialized tcpi driver, causing null-
pointer dereferences. This could of course be solved by extra logic in
the tcpi driver but I think it would be more elegant if the registration
of a port could be free of premature callbacks. E.g. it could be required
that the tcpi driver probe called tcpm_tcpc_reset() once it's done
initializing or the necessary data could be supplied in the call to
tcpm_register_port().
What do you think?

Let me think about it. In theory it should be possible to avoid callbacks into
the underlying driver until after the return from the registration code, but
that would still be racy if the underlying driver is not ready.

Basic problem seems to be that an API in general assumes that the caller is
ready to serve it once it registers itself. It is kind of unusual to have two
calls, one to register the driver and one to tell the infrastructure that it
is ready (which I assume your reset call would do). Ultimately this means
that the tcpm driver would have to have additional logic to identify if the
underlying driver is ready to handle callbacks.

Can you delay tcpm registration until after the underlying driver is ready,
ie typically to the end of its probe function ? Or am I misunderstanding
your problem ?


The problem I had was that I was trying to pull the same trick that you do ;)
I.e. the probe function calls tcpm_register_port() that is calling back
to the driver that was trying to call back to tcpm, just that the call to
tcpm_register_port() has not yet returned so the pointer to tcpm_port in the
driver data structure was still null.

I was able to fix the issue by commenting out the call to tcpm_init() at the
end of tcpm_register_port() and instead call ("your") tcpm_tcpc_reset(), that
currently does nothing but calling tcpm_init(), after I'm done.

Even though I'm not overly excited about the tcpm register function calling back
to the driver I don't think my fix is much better. I should live by my own words
and refrain from calling back to tcpm until registration has finished...

// Mats

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB Type-C Port Manager API concern

[Guenter Roeck]

Hi Mats,

On Sun, Apr 09, 2017 at 01:09:57AM +0200, Mats Karrman wrote:
> Hi Guenter,
> 
> From a previous thread:
> 
> On 03/08/2017 02:38 AM, Guenter Roeck wrote:
> >On 03/07/2017 02:30 PM, Mats Karrman wrote:
> >[ ... ]
> >
> >>
> >>I'm still struggling to catch up on what you guys have been up to during
> >>the
> >>last year or so :-) and came across some patches of Guenter from last
> >>October:
> >>
> >>http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1243527.html
> >>
> >>What happened to them? Has there been any progress since then?
> >>
> >
> >Updates to keep in sync with API changes, bug fixes, and minor
> >improvements,
> >for the most part. I can post a current version if there is interest.
> >The latest version is also available from
> >https://chromium-review.googlesource.com/#/c/389917/
> 
> I'm working on a tcpi driver and have some concern about the tcpm api.
> The tcpm_register_port() is typically called from the probe function of
> tcpi driver where the tcpm_port reference returned is stored in the
> driver private data. The problem I ran into is that tcpm_register_port()
> calls back to the not yet fully initialized tcpi driver, causing null-
> pointer dereferences. This could of course be solved by extra logic in
> the tcpi driver but I think it would be more elegant if the registration
> of a port could be free of premature callbacks. E.g. it could be required
> that the tcpi driver probe called tcpm_tcpc_reset() once it's done
> initializing or the necessary data could be supplied in the call to
> tcpm_register_port().
> What do you think?

Let me think about it. In theory it should be possible to avoid callbacks into
the underlying driver until after the return from the registration code, but
that would still be racy if the underlying driver is not ready.

Basic problem seems to be that an API in general assumes that the caller is
ready to serve it once it registers itself. It is kind of unusual to have two
calls, one to register the driver and one to tell the infrastructure that it
is ready (which I assume your reset call would do). Ultimately this means
that the tcpm driver would have to have additional logic to identify if the
underlying driver is ready to handle callbacks.

Can you delay tcpm registration until after the underlying driver is ready,
ie typically to the end of its probe function ? Or am I misunderstanding
your problem ?

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html