RE: [RFC/RFT usb-next v1 5/6] usb: chipidea: do not set the "phy" field in struct usb_hcd

[Peter Chen]

 
> > Martin, you design has no problem for most of cases, but some hardware
> > needs special sequence for phy control. I will give an example below.
> great to hear that this should work for most devices!
> 
> >> it would be great if you could explain the issue behind this (and
> >> thereby answer the
> >> question: why we would not want the HCD core to manage the PHY states)!
> >>
> >>
> > Eg, taking Qualcomm USB2 controller as an example, it even does not
> > allow chipidea core to manage its power operation, see
> > CI_HDRC_OVERRIDE_PHY_CONTROL at chipidea driver (usb/chipidea/core.c).
> Its phy_power_on is called after ehci controller reset has finished.
> > (usb/chipidea/ci_hdrc_msm.c).
> I see, thank you for explaining this!
> 
> what do you think about replacing the two following fields from struct 
> usb_hcd:
>   struct usb_phy *usb_phy;
>   struct phy *phy;
> with:
>   /*
>* do not manage the PHY state in the HCD core, instead let the driver 
> handle
>* this (for example if the PHY can only be turned on after a specific 
> event)
>*/
>   bool skip_phy_initialization;
> 
> maybe I should also do this together with my other series which adds the PHY
> wrapper to the HCD core (or even as a separate series, which would be merged
> before this and the PHY wrapper series). what do you think?
> 
> 
 
Hi Martin,

I think it is better to do this in one series.

Peter

Re: [PATCH 1/3] dt-bindings: usb: add support for dwc3 controller on Amlogic Meson GX

[Rob Herring]

On Sun, Jan 28, 2018 at 09:03:31PM +0100, Martin Blumenstingl wrote:
> Amlogic Meson GX SoCs (GXL and AXG) come with a (host-only) dwc3 USB
> controller. This requires a clock to be enabled and a reset line to be
> pulsed to get the hardware into a known state.
> Add the documentation for this IP block, similar to "qcom,dwc3.txt".
> 
> Signed-off-by: Martin Blumenstingl 
> ---
>  .../devicetree/bindings/usb/amlogic,dwc3.txt   | 42 
> ++
>  1 file changed, 42 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/amlogic,dwc3.txt

Reviewed-by: Rob Herring 

--
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: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector

[Rob Herring]

On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
> These bindings allow to describe most known standard USB connectors
> and it should be possible to extend it if necessary.
> USB connectors, beside USB can be used to route other protocols,
> for example UART, Audio, MHL. In such case every device passing data
> through the connector should have appropriate graph bindings.
> 
> Signed-off-by: Andrzej Hajda 
> ---
> v2:
> - moved connector type(A,B,C) to compatible string (Rob),
> - renamed size property to type (Rob),
> - changed type description to be less confusing (Laurent),
> - removed vendor specific compatibles (implied by graph port number),

How so? More below...

> - added requirement of connector being a child of IC (Rob),
> - removed max-mode (subtly suggested by Rob, it should be detected anyway
>   by USB Controller in runtime, downside is that device is not able to
>   report its real capabilities, maybe better would be to make it optional(?)),
> - assigned port numbers to data buses (Rob).
> 
> Regards
> Andrzej
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  .../bindings/connector/usb-connector.txt   | 48 
> ++
>  1 file changed, 48 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/connector/usb-connector.txt
> 
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> new file mode 100644
> index ..02020f5d760a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -0,0 +1,48 @@
> +USB Connector
> +=
> +
> +USB connector node represents physical USB connector. It should be
> +a child of USB interface controller.
> +
> +Required properties:
> +- compatible: describes type of the connector, must be one of:
> +"usb-a-connector", "usb-b-connector", "usb-c-connector",

Nit: one per line.

> +
> +Optional properties:
> +- label: symbolic name for the connector
> +- type: size of the connector, should be specified in case of USB-A, USB-B
> +  non-standard (large) connector sizes: "mini", "micro"
> +
> +Required nodes:
> +- any data bus to the connector should be modeled using the OF graph bindings
> +  specified in bindings/graph.txt, unless the bus is between parent node and
> +  the connector. Since single connector can have multpile data buses every 
> bus
> +  has assigned OF graph port number as follows:
> +0: High Speed (HS), present in all connectors,
> +1: Super Speed (SS), present in SS capable connectors,
> +2: Sideband use (SBU), present in USB-C,
> +3: Mobile High-Definition Link (MHL), present in 11-pin Samsung micro-USB

This is un-muxed unlike Type-C where the signals are muxed with USB SS. 
That makes me think the Samsung connector should have its own compatible 
string.

Can we go ahead and define the video modes of Type-C? Normally, if 2 
data streams are mutually exclusive, then they are a single port with 2 
endpoints. So we'd either have 2 endpoints on port 1 or we stick with 
port 3 is always video. We can still know what is mutually exclusive 
based on the compatible. 

> +
> +Example
> +---
> +
> +muic_max77843@66 {
> + ...
> + musb_con: connector {
> + compatible = "usb-b-connector";
> + label = "micro-USB";
> + type = "micro";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@3 {
> + reg = <3>;
> + musb_con_mhl_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> +};
> -- 
> 2.15.1
> 
--
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 v4 08/15] usb: dwc3: Make TX/RX threshold configurable

[Rob Herring]

On Wed, Jan 31, 2018 at 01:16:38PM -0800, Thinh Nguyen wrote:
> DWC_usb31 periodic transfer at 48K+ bytes per interval may need
> modification to the TX/RX packet threshold to achieve optimal result.
> Add properties to make it configurable.
> 
> By default, periodic ESS TX and RX threshold are not enabled. To enable
> TX or RX threshold (host mode only), both packet threshold count and max
> burst size properties must be set to a valid non-zero value 1-16.
> 
> DWC_usb31 programming guide section 1.2.3 and 1.2.4.
> 
> Cc: John Youn 
> Signed-off-by: Thinh Nguyen 
> ---
>  Documentation/devicetree/bindings/usb/dwc3.txt | 16 
>  1 file changed, 16 insertions(+)

Reviewed-by: Rob Herring 
--
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

[PATCH/resend] usb: gadget: udc: renesas_usb3: fix oops in renesas_usb3_remove()

[Yoshihiro Shimoda]

This patch fixes an issue that the renesas_usb3_remove() causes
NULL pointer dereference because the usb3_to_dev() macro will use
the gadget instance and it will be deleted before.

Fixes: cf06df3fae28 ("usb: gadget: udc: renesas_usb3: move 
pm_runtime_{en,dis}able()")
Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/gadget/udc/renesas_usb3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
index 6e87af2..409cde4 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -2410,7 +2410,7 @@ static int renesas_usb3_remove(struct platform_device 
*pdev)
__renesas_usb3_ep_free_request(usb3->ep0_req);
if (usb3->phy)
phy_put(usb3->phy);
-   pm_runtime_disable(usb3_to_dev(usb3));
+   pm_runtime_disable(>dev);
 
return 0;
 }
-- 
1.9.1

--
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

[PATCH v2 1/1] usb: host: ehci: always enable interrupt for qtd completion at test mode

[Peter Chen]

At former code, the SETUP stage does not enable interrupt
for qtd completion, it relies on IAA watchdog to complete
interrupt, then the transcation would be considered timeout
if the flag need_io_watchdog is cleared by platform code.

In this commit, we always add enable interrupt for qtd completion,
then the qtd completion can be notified by hardware interrupt.

Signed-off-by: Peter Chen 
---
Changes for v2:
- Add flag "QTD_IOC" in parameter for qtd_fill

 drivers/usb/host/ehci-q.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index 8815832..3276304 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -1188,10 +1188,10 @@ static int submit_single_step_set_feature(
 * 15 secs after the setup
 */
if (is_setup) {
-   /* SETUP pid */
+   /* SETUP pid, and interrupt after SETUP completion */
qtd_fill(ehci, qtd, urb->setup_dma,
sizeof(struct usb_ctrlrequest),
-   token | (2 /* "setup" */ << 8), 8);
+   QTD_IOC | token | (2 /* "setup" */ << 8), 8);
 
submit_async(ehci, urb, _list, GFP_ATOMIC);
return 0; /*Return now; we shall come back after 15 seconds*/
@@ -1228,12 +1228,8 @@ static int submit_single_step_set_feature(
qtd_prev->hw_next = QTD_NEXT(ehci, qtd->qtd_dma);
list_add_tail(>qtd_list, head);
 
-   /* dont fill any data in such packets */
-   qtd_fill(ehci, qtd, 0, 0, token, 0);
-
-   /* by default, enable interrupt on urb completion */
-   if (likely(!(urb->transfer_flags & URB_NO_INTERRUPT)))
-   qtd->hw_token |= cpu_to_hc32(ehci, QTD_IOC);
+   /* Interrupt after STATUS completion */
+   qtd_fill(ehci, qtd, 0, 0, token | QTD_IOC, 0);
 
submit_async(ehci, urb, _list, GFP_KERNEL);
 
-- 
2.7.4

--
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

[PATCH 11/20] usb: gadget: udc: Remove USB_GADGET_DUALSPEED select

[Ulf Magnusson]

USB_GADGET_DUALSPEED was removed by commit 85b8614d7223 ("usb: gadget:
get rid of USB_GADGET_{DUAL,SUPER}SPEED"), but the USB_SNP_UDC_PLAT
symbol still selects it.

Remove the USB_GADGET_DUALSPEED select from USB_SNP_UDC_PLAT.

Discovered with the
https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
script.

Signed-off-by: Ulf Magnusson 
---
 drivers/usb/gadget/udc/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 1e9567091d86..0875d38476ee 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -274,7 +274,6 @@ config USB_SNP_UDC_PLAT
tristate "Synopsys USB 2.0 Device controller"
depends on USB_GADGET && OF && HAS_DMA
depends on EXTCON || EXTCON=n
-   select USB_GADGET_DUALSPEED
select USB_SNP_CORE
default ARCH_BCM_IPROC
help
-- 
2.14.1

--
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: [RFC/RFT usb-next v1 5/6] usb: chipidea: do not set the "phy" field in struct usb_hcd

[Martin Blumenstingl]

Hi Peter,

On Mon, Jan 29, 2018 at 4:30 AM, Peter Chen  wrote:
>
>> >
>> >>
>> >> Now that usb_add_hcd parses all generic PHYs anyways the code which
>> >> skips initialization of a single PHY will go away.
>> >> Remove the code which sets struct usb_hcd's phy field from the
>> >> chipidea driver as this field will go away soon.
>> >>
>> >> Signed-off-by: Martin Blumenstingl
>> >> 
>> >> ---
>> >>  drivers/usb/chipidea/host.c | 4 +---
>> >>  1 file changed, 1 insertion(+), 3 deletions(-)
>> >>
>> >> diff --git a/drivers/usb/chipidea/host.c
>> >> b/drivers/usb/chipidea/host.c index 19d60ed7e41f..fc324767cb0f 100644
>> >> --- a/drivers/usb/chipidea/host.c
>> >> +++ b/drivers/usb/chipidea/host.c
>> >> @@ -124,9 +124,7 @@ static int host_start(struct ci_hdrc *ci)
>> >>
>> >>   hcd->power_budget = ci->platdata->power_budget;
>> >>   hcd->tpl_support = ci->platdata->tpl_support;
>> >> - if (ci->phy)
>> >> - hcd->phy = ci->phy;
>> >> - else
>> >> + if (!ci->phy)
>> >>   hcd->usb_phy = ci->usb_phy;
>> >>
>> >
>> > The reason hcd->phy is initialized by chipidea core is we do not need
>> > HCD core to touch PHY, and PHY operation is shared for both device and host
>> mode for chipidea.
>> Chunfeng wanted me to drop the mtu3 patch because I forgot about device mode 
>> in
>> the mtu3 driver.
>> however, the chipidea driver seems to be different because I'm not dropping 
>> the
>> whole phy_{init,power_on,power_off,exit} code from it, but only a "flag" 
>> that tells the
>> HCD core to skip managing the USB PHY
>>
>> > If I understand correct, your HCD core PHY wrapper patch set will do
>> > PHY operation if there is a "phy" node under controller's? If it is
>> > correct, you may supply one way to let the HCD core bypass phy operations 
>> > for
>> some USB controllers, eg dual-role controllers.
>> > Thanks.
>> could you please explain why the HCD core should not manage the the PHYs when
>> the chipidea driver is used?
>>
>> my understanding is that all phy_{init,power_on,power_off,exit}
>> operations are ref-counted internally in the PHY framework this means that 
>> if the
>> chipidea driver calls phy_{init,power_on} first then the same functions 
>> called from
>> within the HCD core are no-ops (except for the ref-counting) so I think it 
>> should not
>> change anything - however, I have no hardware to actually prove that.
>
> Martin, you design has no problem for most of cases, but some hardware needs 
> special
> sequence for phy control. I will give an example below.
great to hear that this should work for most devices!

>> it would be great if you could explain the issue behind this (and thereby 
>> answer the
>> question: why we would not want the HCD core to manage the PHY states)!
>>
>>
> Eg, taking Qualcomm USB2 controller as an example, it even does not allow 
> chipidea core
> to manage its power operation, see CI_HDRC_OVERRIDE_PHY_CONTROL at chipidea 
> driver
> (usb/chipidea/core.c). Its phy_power_on is called after ehci controller reset 
> has finished.
> (usb/chipidea/ci_hdrc_msm.c).
I see, thank you for explaining this!

what do you think about replacing the two following fields from struct usb_hcd:
  struct usb_phy *usb_phy;
  struct phy *phy;
with:
  /*
   * do not manage the PHY state in the HCD core, instead let the driver handle
   * this (for example if the PHY can only be turned on after a specific event)
   */
  bool skip_phy_initialization;

maybe I should also do this together with my other series which adds
the PHY wrapper to the HCD core (or even as a separate series, which
would be merged before this and the PHY wrapper series). what do you
think?


Regards
Martin
--
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: [Bug 197863] Thinkpad X240 resume dramatically slower on kernels 4.13+

[Bjørn Mork]

Greg KH  writes:
> On Sat, Feb 03, 2018 at 07:25:54PM +0100, Markus Demleitner wrote:
>
>> It's 662591461c4b9a1e3b9b159dbf37648a585ebaae.  To my eyes, it even
>> looks plausible that it's causing the problematic behaviour, but
>> since I can't say I understand what I'd be doing if I dabbled with
>> the change, I've refrained from guessing how to fix it.
>> 
>> I'm happy to try patches, though.
>
> Ok, thanks.  I've added the authors of this patch to the email here,
> perhaps they have an idea of what is going on?

This thing made me curious enough to dive into code I don't understand,
as I have experienced the annoying crazy fan behaviour in resume a few
times on my X1 Carbon 4th gen.

Maybe I missed something, but it looks like commit

 c3a696b6e8f8 ("ACPI / EC: Use busy polling mode when GPE is not enabled")

introduced suspend/resume busy polling for the "boot EC" unintentionally?

The patch moved acpi_ec_leave_noirq() and acpi_ec_leave_noirq()
functions outside the #ifdef CONFIG_PM_SLEEP, so they could be reused
while installing handlers.  But when doing that the

   if (ec == first_ec)

conditions on suspend/resume were silently dropped.  I assume the
intention might have been to move those intto acpi_ec_suspend_noirq()
and acpi_ec_resume_noirq() instead? But that didn't happen AFAICS.

Or did I misunderstand this completely?  Not unlikely given that I have
zero clue about what this code is doing...

But I do wonder if the attached (completely untested!!) patch makes
things any better?


Bjørn

>From 82b8f437a243854a3f1d3c82f85520fd2b71 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= 
Date: Sun, 4 Feb 2018 21:15:36 +0100
Subject: [PATCH] Revert "ACPI / EC: Drop EC noirq hooks to fix a regression"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This reverts commit 662591461c4b9a1e3b9b159dbf37648a585ebaae
and re-introduce the conditions dropped by commit c3a696b6e8f8
("ACPI / EC: Use busy polling mode when GPE is not enabled")

Fixes: c3a696b6e8f8 ("ACPI / EC: Use busy polling mode when GPE is not enabled")
Signed-off-by: Bjørn Mork 
---
 drivers/acpi/ec.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index d9f38c645e4a..24a772f66847 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -1905,6 +1905,26 @@ int __init acpi_ec_ecdt_probe(void)
 }
 
 #ifdef CONFIG_PM_SLEEP
+static int acpi_ec_suspend_noirq(struct device *dev)
+{
+	struct acpi_ec *ec =
+		acpi_driver_data(to_acpi_device(dev));
+
+	if (ec == first_ec)
+		acpi_ec_enter_noirq(ec);
+	return 0;
+}
+
+static int acpi_ec_resume_noirq(struct device *dev)
+{
+	struct acpi_ec *ec =
+		acpi_driver_data(to_acpi_device(dev));
+
+	if (ec == first_ec)
+		acpi_ec_leave_noirq(ec);
+	return 0;
+}
+
 static int acpi_ec_suspend(struct device *dev)
 {
 	struct acpi_ec *ec =
-- 
2.11.0

Re: [PATCH] option: Add support for Quectel EP06

[Bjørn Mork]

Johan Hovold  writes:

> IIRC we have already started reusing entries, but the names have not
> always been made generic in the process. I think Bjørn may have proposed
> a generic naming scheme at some point, but that essentially just meant
> we encoded the two masks in the name.

Maybe. I dont' remember.

> Then we may just move over to
> encoding the masks directly in driver_data instead, at least if 16 bits
> is enough.

Agreed.

>> IIRC I considered just dumping the BIT(x) into the .driver_info but
>> then we'd only have 16 bits for each of send_setup and reserved on 32-
>> bit arches and I wasn't sure that was enough.  I've seen some devices
>> with lots of interfaces.  But doing it this way might have been clearer
>> than a sidecar struct like option_blacklist_info.
>
> Yeah, we should probably consider moving over to something like that.
> 16 bits would at least be enough for the devices we currently have
> blacklists for.

Yes, I think the current driver documents pretty well that we don't need
backlists for high interface numbers.

Checking the devices I have ever used, the only ones I found with
interface numbers higher than 16 were the Sierra Wireless modems of the
MDM9200/MDM9600 generation.  THe used 19 and 20 for two of their
QMI/RMNET functions.  But they are handled by the qcserial driver, so
that's not an issue wrt option.

I say go for the simple bitmasks!

You might also consider a general blacklist for stuff like ADB which
always need blacklisting.  By now, Google owns ff/42/xx whether you like
it or not.


Bjørn
--
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

[PATCH v3] Add delay-init quirk for Corsair K70 RGB keyboards

[JackStocker]

Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
start correctly at boot.

Device ids found here:
usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: Corsair K70 RGB Gaming Keyboard

Signed-off-by: JackStocker 
---
Changes in v3:
  - Added correct v1 commit message.
Changes in v2:
  - Moved K70 entry above Strafe to preserve ascending order.

 drivers/usb/core/quirks.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index a6aaf2f..0405d68 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -218,6 +218,9 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x1a0a, 0x0200), .driver_info =
USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
 
+   /* Corsair K70 RGB */
+   { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* Corsair Strafe RGB */
{ USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
 
-- 
2.7.4

--
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 v2] Add delay-init quirk for Corsair K70 RGB keyboards

[Kai Heng Feng]

> On 5 Feb 2018, at 12:18 AM, JackStocker  wrote:
> 
> Do you mean like this?

Yes, with proper commit message.

> 
> Signed-off-by: JackStocker 
> ---
> drivers/usb/core/quirks.c | 3 +++
> 1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
> index a6aaf2f..0405d68 100644
> --- a/drivers/usb/core/quirks.c
> +++ b/drivers/usb/core/quirks.c
> @@ -218,6 +218,9 @@ static const struct usb_device_id usb_quirk_list[] = {
>   { USB_DEVICE(0x1a0a, 0x0200), .driver_info =
>   USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
> 
> + /* Corsair K70 RGB */
> + { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
> +
>   /* Corsair Strafe RGB */
>   { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
> 
> -- 
> 2.7.4
> 

--
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

[PATCH v2] Add delay-init quirk for Corsair K70 RGB keyboards

[JackStocker]

Do you mean like this?

Signed-off-by: JackStocker 
---
 drivers/usb/core/quirks.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index a6aaf2f..0405d68 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -218,6 +218,9 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x1a0a, 0x0200), .driver_info =
USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
 
+   /* Corsair K70 RGB */
+   { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* Corsair Strafe RGB */
{ USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
 
-- 
2.7.4

--
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: power management problems in ehci-omap

[H. Nikolaus Schaller]

Hi,
Andreas seems to be travelling back from FOSDEM so I jump in with best of my 
knowledge.

> Am 04.02.2018 um 12:34 schrieb Michael Nazzareno Trimarchi 
> :
> 
> Hi
> 
> On Sun, Feb 4, 2018 at 12:07 PM, H. Nikolaus Schaller  
> wrote:
>> Hi Michael,
>> 
>>> Am 04.02.2018 um 11:55 schrieb Michael Nazzareno Trimarchi 
>>> :
>>> 
>>> Hi Andreas
>>> 
>>> On Sun, Feb 4, 2018 at 11:50 AM, Andreas Kemnade  
>>> wrote:
 Hi,
 
 On Sun, 4 Feb 2018 09:43:45 +0100
 Michael Nazzareno Trimarchi  wrote:
 
> Hi Andreas
> 
> On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade  
> wrote:
>> On Sun, 4 Feb 2018 00:10:50 +0100
>> Michael Nazzareno Trimarchi  wrote:
>> 
>>> Hi
>>> 
>>> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade  
>>> wrote:
 Hi,
 
 I booted a 4.15 kernel without udev and loaded modules piece by piece 
 to analyze
 pm problems. modprobe ehci-omap increases current by around 35mA and
 also rmmod ehci-omap does not let it go down at all.
 
 I expect that removing hardware does the same thing
>> nonsense sentence from me, was to tired. I would expect that removing 
>> the modules
>> properly powers down the device.
 
 Also suspend current increases by around 15mA if that module is loaded.
 I tested with having everything disabled which is attached to that usb 
 bus.
 
>>> 
>>> Do you have an LTE connected to the usb?
>>> 
>> Yes, there is a UMTS modem attached, but it was off during the tests.
>> It did not enumerate on the modem.
>> 
> 
> Just to understand if the suspend current drop was connected to the
> suspend of lte modem on your side.
> So you don't have anything connected on usb bus?
> 
 Suspend current is increased when the ehci-omap module is loaded
 in comparison to the state. I tested with the modem disabled, so there
 is nothing on the bus. Increased suspend current is one thing,
 current_before_modprobe_ehci_omap != current_after_rmmod_ehci_omap.
 
 I am testing with init=some_testscript.sh, so no userspace
 is doing strange things. No module autoload or something.
 
>>> 
>>> How many port are configured and how is the phy part connected to the
>>> ehci controller?
>>> Can you point me the schematic page?
>> 
>> it is essentially a copy from BeagleBoard XM.
>> 
>> Schematics of the GTA04 are here:
>> 
>>http://projects.goldelico.com/p/gta04-main/downloads/48/
>> 
>> USB PHY is on page 9.
>> 
> 
> I see. GPIO174 is controlled by you during boot or connected to the dts?
> I don't find in mainline the connection to the physical and it's own
> programming.
> Can you check if the phy is in reset when module is remove?

The reset gpio is defined in the respective board-DTS:

https://elixir.free-electrons.com/linux/v4.15/source/arch/arm/boot/dts/omap3-beagle-xm.dts#L88
https://elixir.free-electrons.com/linux/v4.15/source/arch/arm/boot/dts/omap3-gta04.dtsi#L120

BR,
Nikolaus

--
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] Add delay-init quirk for Corsair K70 RGB keyboards

[Kai Heng Feng]

> On 2 Feb 2018, at 11:51 PM, JackStocker  wrote:
> 
> From: Jack Stocker 
> 
> Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
> Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
> start correctly at boot.
> 
> Device ids found here:
> usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
> usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 3-3: Product: Corsair K70 RGB Gaming Keyboard 
> 
> Signed-off-by: Jack Stocker 
> ---
> drivers/usb/core/quirks.c | 3 +++
> 1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
> index a6aaf2f..9eb92dc 100644
> --- a/drivers/usb/core/quirks.c
> +++ b/drivers/usb/core/quirks.c
> @@ -221,6 +221,9 @@ static const struct usb_device_id usb_quirk_list[] = {
>   /* Corsair Strafe RGB */
>   { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
> 
> + /* Corsair K70 RGB */
> + { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
> +

I think this change should move up, to make the table follows an ascending 
order.

>   /* MIDI keyboard WORLDE MINI */
>   { USB_DEVICE(0x1c75, 0x0204), .driver_info =
>   USB_QUIRK_CONFIG_INTF_STRINGS },
> -- 
> 2.7.4
> 

--
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: power management problems in ehci-omap

[Michael Nazzareno Trimarchi]

Hi

On Sun, Feb 4, 2018 at 12:07 PM, H. Nikolaus Schaller  
wrote:
> Hi Michael,
>
>> Am 04.02.2018 um 11:55 schrieb Michael Nazzareno Trimarchi 
>> :
>>
>> Hi Andreas
>>
>> On Sun, Feb 4, 2018 at 11:50 AM, Andreas Kemnade  
>> wrote:
>>> Hi,
>>>
>>> On Sun, 4 Feb 2018 09:43:45 +0100
>>> Michael Nazzareno Trimarchi  wrote:
>>>
 Hi Andreas

 On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade  
 wrote:
> On Sun, 4 Feb 2018 00:10:50 +0100
> Michael Nazzareno Trimarchi  wrote:
>
>> Hi
>>
>> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade  
>> wrote:
>>> Hi,
>>>
>>> I booted a 4.15 kernel without udev and loaded modules piece by piece 
>>> to analyze
>>> pm problems. modprobe ehci-omap increases current by around 35mA and
>>> also rmmod ehci-omap does not let it go down at all.
>>>
>>> I expect that removing hardware does the same thing
> nonsense sentence from me, was to tired. I would expect that removing the 
> modules
> properly powers down the device.
>>>
>>> Also suspend current increases by around 15mA if that module is loaded.
>>> I tested with having everything disabled which is attached to that usb 
>>> bus.
>>>
>>
>> Do you have an LTE connected to the usb?
>>
> Yes, there is a UMTS modem attached, but it was off during the tests.
> It did not enumerate on the modem.
>

 Just to understand if the suspend current drop was connected to the
 suspend of lte modem on your side.
 So you don't have anything connected on usb bus?

>>> Suspend current is increased when the ehci-omap module is loaded
>>> in comparison to the state. I tested with the modem disabled, so there
>>> is nothing on the bus. Increased suspend current is one thing,
>>> current_before_modprobe_ehci_omap != current_after_rmmod_ehci_omap.
>>>
>>> I am testing with init=some_testscript.sh, so no userspace
>>> is doing strange things. No module autoload or something.
>>>
>>
>> How many port are configured and how is the phy part connected to the
>> ehci controller?
>> Can you point me the schematic page?
>
> it is essentially a copy from BeagleBoard XM.
>
> Schematics of the GTA04 are here:
>
> http://projects.goldelico.com/p/gta04-main/downloads/48/
>
> USB PHY is on page 9.
>

I see. GPIO174 is controlled by you during boot or connected to the dts?
I don't find in mainline the connection to the physical and it's own
programming.
Can you check if the phy is in reset when module is remove?

Michael


> BR,
> Nikolaus
>
>>
>> michael
>>
>>
>>> Regards,
>>> Andreas
>>
>>
>>
>> --
>> | Michael Nazzareno Trimarchi Amarula Solutions BV |
>> | COO  -  Founder  Cruquiuskade 47 |
>> | +31(0)851119172 Amsterdam 1018 AM NL |
>> |  [`as] http://www.amarulasolutions.com   |
>> ___
>> http://projects.goldelico.com/p/gta04-kernel/
>> Letux-kernel mailing list
>> letux-ker...@openphoenux.org
>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
>



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
--
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: power management problems in ehci-omap

[H. Nikolaus Schaller]

Hi Michael,

> Am 04.02.2018 um 11:55 schrieb Michael Nazzareno Trimarchi 
> :
> 
> Hi Andreas
> 
> On Sun, Feb 4, 2018 at 11:50 AM, Andreas Kemnade  wrote:
>> Hi,
>> 
>> On Sun, 4 Feb 2018 09:43:45 +0100
>> Michael Nazzareno Trimarchi  wrote:
>> 
>>> Hi Andreas
>>> 
>>> On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade  
>>> wrote:
 On Sun, 4 Feb 2018 00:10:50 +0100
 Michael Nazzareno Trimarchi  wrote:
 
> Hi
> 
> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade  
> wrote:
>> Hi,
>> 
>> I booted a 4.15 kernel without udev and loaded modules piece by piece to 
>> analyze
>> pm problems. modprobe ehci-omap increases current by around 35mA and
>> also rmmod ehci-omap does not let it go down at all.
>> 
>> I expect that removing hardware does the same thing
 nonsense sentence from me, was to tired. I would expect that removing the 
 modules
 properly powers down the device.
>> 
>> Also suspend current increases by around 15mA if that module is loaded.
>> I tested with having everything disabled which is attached to that usb 
>> bus.
>> 
> 
> Do you have an LTE connected to the usb?
> 
 Yes, there is a UMTS modem attached, but it was off during the tests.
 It did not enumerate on the modem.
 
>>> 
>>> Just to understand if the suspend current drop was connected to the
>>> suspend of lte modem on your side.
>>> So you don't have anything connected on usb bus?
>>> 
>> Suspend current is increased when the ehci-omap module is loaded
>> in comparison to the state. I tested with the modem disabled, so there
>> is nothing on the bus. Increased suspend current is one thing,
>> current_before_modprobe_ehci_omap != current_after_rmmod_ehci_omap.
>> 
>> I am testing with init=some_testscript.sh, so no userspace
>> is doing strange things. No module autoload or something.
>> 
> 
> How many port are configured and how is the phy part connected to the
> ehci controller?
> Can you point me the schematic page?

it is essentially a copy from BeagleBoard XM.

Schematics of the GTA04 are here:

http://projects.goldelico.com/p/gta04-main/downloads/48/

USB PHY is on page 9.

BR,
Nikolaus

> 
> michael
> 
> 
>> Regards,
>> Andreas
> 
> 
> 
> -- 
> | Michael Nazzareno Trimarchi Amarula Solutions BV |
> | COO  -  Founder  Cruquiuskade 47 |
> | +31(0)851119172 Amsterdam 1018 AM NL |
> |  [`as] http://www.amarulasolutions.com   |
> ___
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> letux-ker...@openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel

--
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: power management problems in ehci-omap

[Michael Nazzareno Trimarchi]

Hi Andreas

On Sun, Feb 4, 2018 at 11:50 AM, Andreas Kemnade  wrote:
> Hi,
>
> On Sun, 4 Feb 2018 09:43:45 +0100
> Michael Nazzareno Trimarchi  wrote:
>
>> Hi Andreas
>>
>> On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade  wrote:
>> > On Sun, 4 Feb 2018 00:10:50 +0100
>> > Michael Nazzareno Trimarchi  wrote:
>> >
>> >> Hi
>> >>
>> >> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade  
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > I booted a 4.15 kernel without udev and loaded modules piece by piece 
>> >> > to analyze
>> >> > pm problems. modprobe ehci-omap increases current by around 35mA and
>> >> > also rmmod ehci-omap does not let it go down at all.
>> >> >
>> >> > I expect that removing hardware does the same thing
>> > nonsense sentence from me, was to tired. I would expect that removing the 
>> > modules
>> > properly powers down the device.
>> >> >
>> >> > Also suspend current increases by around 15mA if that module is loaded.
>> >> > I tested with having everything disabled which is attached to that usb 
>> >> > bus.
>> >> >
>> >>
>> >> Do you have an LTE connected to the usb?
>> >>
>> > Yes, there is a UMTS modem attached, but it was off during the tests.
>> > It did not enumerate on the modem.
>> >
>>
>> Just to understand if the suspend current drop was connected to the
>> suspend of lte modem on your side.
>> So you don't have anything connected on usb bus?
>>
> Suspend current is increased when the ehci-omap module is loaded
> in comparison to the state. I tested with the modem disabled, so there
> is nothing on the bus. Increased suspend current is one thing,
> current_before_modprobe_ehci_omap != current_after_rmmod_ehci_omap.
>
> I am testing with init=some_testscript.sh, so no userspace
> is doing strange things. No module autoload or something.
>

How many port are configured and how is the phy part connected to the
ehci controller?
Can you point me the schematic page?

michael


> Regards,
> Andreas



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
--
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: power management problems in ehci-omap

[Andreas Kemnade]

Hi,

On Sun, 4 Feb 2018 09:43:45 +0100
Michael Nazzareno Trimarchi  wrote:

> Hi Andreas
> 
> On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade  wrote:
> > On Sun, 4 Feb 2018 00:10:50 +0100
> > Michael Nazzareno Trimarchi  wrote:
> >  
> >> Hi
> >>
> >> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade  
> >> wrote:  
> >> > Hi,
> >> >
> >> > I booted a 4.15 kernel without udev and loaded modules piece by piece to 
> >> > analyze
> >> > pm problems. modprobe ehci-omap increases current by around 35mA and
> >> > also rmmod ehci-omap does not let it go down at all.
> >> >
> >> > I expect that removing hardware does the same thing  
> > nonsense sentence from me, was to tired. I would expect that removing the 
> > modules
> > properly powers down the device.  
> >> >
> >> > Also suspend current increases by around 15mA if that module is loaded.
> >> > I tested with having everything disabled which is attached to that usb 
> >> > bus.
> >> >  
> >>
> >> Do you have an LTE connected to the usb?
> >>  
> > Yes, there is a UMTS modem attached, but it was off during the tests.
> > It did not enumerate on the modem.
> >  
> 
> Just to understand if the suspend current drop was connected to the
> suspend of lte modem on your side.
> So you don't have anything connected on usb bus?
> 
Suspend current is increased when the ehci-omap module is loaded
in comparison to the state. I tested with the modem disabled, so there
is nothing on the bus. Increased suspend current is one thing,
current_before_modprobe_ehci_omap != current_after_rmmod_ehci_omap.

I am testing with init=some_testscript.sh, so no userspace
is doing strange things. No module autoload or something.

Regards,
Andreas
--
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: power management problems in ehci-omap

[Michael Nazzareno Trimarchi]

Hi Andreas

On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade  wrote:
> On Sun, 4 Feb 2018 00:10:50 +0100
> Michael Nazzareno Trimarchi  wrote:
>
>> Hi
>>
>> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade  
>> wrote:
>> > Hi,
>> >
>> > I booted a 4.15 kernel without udev and loaded modules piece by piece to 
>> > analyze
>> > pm problems. modprobe ehci-omap increases current by around 35mA and
>> > also rmmod ehci-omap does not let it go down at all.
>> >
>> > I expect that removing hardware does the same thing
> nonsense sentence from me, was to tired. I would expect that removing the 
> modules
> properly powers down the device.
>> >
>> > Also suspend current increases by around 15mA if that module is loaded.
>> > I tested with having everything disabled which is attached to that usb bus.
>> >
>>
>> Do you have an LTE connected to the usb?
>>
> Yes, there is a UMTS modem attached, but it was off during the tests.
> It did not enumerate on the modem.
>

Just to understand if the suspend current drop was connected to the
suspend of lte modem on your side.
So you don't have anything connected on usb bus?

Michael

>> Michael
>>
>> > System was
>> > GTA04A5 (with dm3730 processor and usb3322 phy)
>> >
>> > I know it has worked once, but I do not remember the version.
>> >
>> > The kernel config used can be found here:
>> > http://misc.andi.de1.cc/config-4.15.gz
>> >
> Regards,
> Andreas



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
--
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: power management problems in ehci-omap

[Andreas Kemnade]

On Sun, 4 Feb 2018 00:10:50 +0100
Michael Nazzareno Trimarchi  wrote:

> Hi
> 
> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade  wrote:
> > Hi,
> >
> > I booted a 4.15 kernel without udev and loaded modules piece by piece to 
> > analyze
> > pm problems. modprobe ehci-omap increases current by around 35mA and
> > also rmmod ehci-omap does not let it go down at all.
> >
> > I expect that removing hardware does the same thing
nonsense sentence from me, was to tired. I would expect that removing the 
modules
properly powers down the device.
> >
> > Also suspend current increases by around 15mA if that module is loaded.
> > I tested with having everything disabled which is attached to that usb bus.
> >  
> 
> Do you have an LTE connected to the usb?
> 
Yes, there is a UMTS modem attached, but it was off during the tests.
It did not enumerate on the modem.

> Michael
> 
> > System was
> > GTA04A5 (with dm3730 processor and usb3322 phy)
> >
> > I know it has worked once, but I do not remember the version.
> >
> > The kernel config used can be found here:
> > http://misc.andi.de1.cc/config-4.15.gz
> >
Regards,
Andreas
--
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