[no subject]

2017-07-03 Thread Finanzdienstleistungen Pvt Ltd


Brauchen Sie ein persönliches oder geschäftliches Darlehen ohne 
Stress und schnelle Genehmigung? Wenn ja, kontaktieren Sie uns heute, da wir 
derzeit Darlehen zu einem hervorragenden Zinssatz anbieten. Unser Darlehen ist 
gesichert und sicher, unsere Kunden Glück ist unsere Stärke. Für 
weitere Informationen und Bewerbung
--
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 v1 1/1] usb:xhci: update condition to select bus->sysdev from parent device

2017-07-03 Thread Thang Q. Nguyen
On Tue, Jun 6, 2017 at 2:11 PM, Thang Q. Nguyen  wrote:
> For commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA
> configuration"), sysdev points to devices known to the system firmware
> or hardware for DMA parameters.
> However, the parent of the system firmware/hardware device checking
> logic does not work in ACPI boot mode. This patch updates the formulation
> to check this case in both DT and ACPI.
>
> Signed-off-by: Tung Nguyen 
> Signed-off-by: Thang Q. Nguyen 
> ---
>  drivers/usb/host/xhci-plat.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index c04144b..e3e342a 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -187,7 +187,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  * 3. xhci_plat is grandchild of a pci device (dwc3-pci)
>  */
> sysdev = &pdev->dev;
> -   if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node)
> +   if (sysdev->parent && (sysdev->fwnode->type == FWNODE_PDATA) &&
> +   (is_of_node(sysdev->parent->fwnode) ||
> +   is_acpi_device_node(sysdev->parent->fwnode)))
> sysdev = sysdev->parent;
>  #ifdef CONFIG_PCI
> else if (sysdev->parent && sysdev->parent->parent &&
> --
> 1.7.1
>
Hi,
Do you have any comment on this patch?

Regards,
Thang Q. Nguyen
--
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: [GIT PULL] USB/PHY patches for 4.13-rc1

2017-07-03 Thread Stephen Rothwell
Hi all,

On Mon, 3 Jul 2017 16:58:47 +0200 Greg KH  wrote:
>
> All of these have been in linux-next for a while with no reported
> issues.

I have been carrying the following merge fix patch for the merge
against the uuid tree (now in Linus' tree):

From: Stephen Rothwell 
Date: Thu, 29 Jun 2017 14:36:10 +1000
Subject: [PATCH] usb: typec: fix for "ACPI: Switch to use generic guid_t in
 acpi_evaluate_dsm()"

Signed-off-by: Stephen Rothwell 
---
 drivers/usb/typec/ucsi/ucsi_acpi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c 
b/drivers/usb/typec/ucsi/ucsi_acpi.c
index 3fb2e48e1c91..7b7c9373a9b6 100644
--- a/drivers/usb/typec/ucsi/ucsi_acpi.c
+++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
@@ -23,14 +23,14 @@ struct ucsi_acpi {
struct device *dev;
struct ucsi *ucsi;
struct ucsi_ppm ppm;
-   uuid_le uuid;
+   guid_t uuid;
 };
 
 static int ucsi_acpi_dsm(struct ucsi_acpi *ua, int func)
 {
union acpi_object *obj;
 
-   obj = acpi_evaluate_dsm(ACPI_HANDLE(ua->dev), ua->uuid.b, 1, func,
+   obj = acpi_evaluate_dsm(ACPI_HANDLE(ua->dev), &ua->uuid, 1, func,
NULL);
if (!obj) {
dev_err(ua->dev, "%s: failed to evaluate _DSM %d\n",
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell
--
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: [linux-next][PATCH] usb: dwc3: omap: remove IRQ_NOAUTOEN used with shared irq

2017-07-03 Thread Grygorii Strashko



On 07/02/2017 11:27 PM, Vignesh R wrote:

Hi,

On Saturday 01 July 2017 01:04 AM, Strashko, Grygorii wrote:



On 06/29/2017 01:03 AM, Tony Lindgren wrote:

* Vignesh R  [170628 21:21]:



On Thursday 29 June 2017 05:01 AM, Strashko, Grygorii wrote:

IRQ_NOAUTOEN can't be used with shared IRQs and Kernel now will triggers
warning if it happns, since commit 04c848d39879 ("genirq: Warn when
IRQ_NOAUTOEN is used with shared interrupts"). And this is the case for
OMAP DWC 3 driver.

Hence, remove IRQ_NOAUTOEN flag and instead call disable_irq() before
disabling PM runtime in probe error path handling.


Or, how about requesting the irq at the end of probe after extcon
registration?


Hmm yeah, what prevents the issue that we tried to fix with commit
12a7f17fac5b ("usb: dwc3: omap: fix race of pm runtime with irq handler
in probe")?


No, I think. There should be the disable_irq() call any way
before pm_runtime_put_sync(dev);| pm_runtime_disable(dev); -
once IRQ is requested driver can't know if IRQ handler is running now or not
unless it will call disable_irq()/free_irq().

But, I've also thought about moving request_irq() down (seems
it can be moved even after of_platform_populate()).
looks like it can be separate patch.



commit 12a7f17fac5b says PM runtime can race with IRQ handler when
deferred probing happening due to extcon, therefore IRQ_NOAUTOEN was set
and disable_irq() call was added. If IRQ handler registration is moved
to a place after of_platform_populate(), then we can be sure that extcon
is registered and there wont be any deferred probe or race with irq
handler and PM runtime. Would disable_irq() still be needed then?



You might be correct, so feel free to send a patch.

--
regards,
-grygorii
--
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] usb: serial: Add support for Qivicon USB ZigBee dongle

2017-07-03 Thread Dan Williams
On Mon, 2017-07-03 at 10:16 +0200, Frans Klaver wrote:
> On Mon, Jul 3, 2017 at 10:13 AM, Johan Hovold 
> wrote:
> > On Fri, Jun 30, 2017 at 02:49:55PM +0200, Frans Klaver wrote:
> > > On Fri, Jun 30, 2017 at 2:44 PM, Stefan Triller  > > ller.de> wrote:
> > > > The German Telekom offers a ZigBee USB Stick under the brand
> > > > name Qivicon
> > > > for their SmartHome Home Base in its 1. Generation. The
> > > > productId is not
> > > > known by the according kernel module, this patch adds support
> > > > for it.
> > > > 
> > > > Signed-off-by: Stefan Triller 
> > > 
> > > Reviewed-by: Frans Klaver 
> > 
> > Thanks for the patch and review. I've queued this one up for -rc2.
> 
> I guess this could go into stable as well?

Random question, but what protocol does the serial interface speak?

Dan
--
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 3/3] power: wm831x_power: Support USB charger current limit management

2017-07-03 Thread Sebastian Reichel
Hi,

On Mon, Jul 03, 2017 at 02:07:15PM +0800, Baolin Wang wrote:
> Integrate with the newly added USB charger interface to limit the current
> we draw from the USB input based on the input device configuration
> identified by the USB stack, allowing us to charge more quickly from high
> current inputs without drawing more current than specified from others.
> 
> Signed-off-by: Mark Brown 
> Signed-off-by: Baolin Wang 

Missing DT binding documentation, otherwise fine with me.
Would be nice to convert existing drivers:

$ git grep -l extcon -- drivers/power/supply
drivers/power/supply/axp288_charger.c
drivers/power/supply/bq24190_charger.c
drivers/power/supply/charger-manager.c
drivers/power/supply/qcom_smbb.c

-- Sebastian

> ---
>  drivers/power/supply/wm831x_power.c |   61 
> +++
>  1 file changed, 61 insertions(+)
> 
> diff --git a/drivers/power/supply/wm831x_power.c 
> b/drivers/power/supply/wm831x_power.c
> index 7082301..3e3480708 100644
> --- a/drivers/power/supply/wm831x_power.c
> +++ b/drivers/power/supply/wm831x_power.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -31,6 +32,8 @@ struct wm831x_power {
>   char usb_name[20];
>   char battery_name[20];
>   bool have_battery;
> + struct usb_phy *usb_phy;
> + struct notifier_block usb_notify;
>  };
>  
>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
> @@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>  };
>  
> +/* In milliamps */
> +static const unsigned int wm831x_usb_limits[] = {
> + 0,
> + 2,
> + 100,
> + 500,
> + 900,
> + 1500,
> + 1800,
> + 550,
> +};
> +
> +static int wm831x_usb_limit_change(struct notifier_block *nb,
> +unsigned long limit, void *data)
> +{
> + struct wm831x_power *wm831x_power = container_of(nb,
> +  struct wm831x_power,
> +  usb_notify);
> + unsigned int i, best;
> +
> + /* Find the highest supported limit */
> + best = 0;
> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
> + if (limit >= wm831x_usb_limits[i] &&
> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
> + best = i;
> + }
> +
> + dev_dbg(wm831x_power->wm831x->dev,
> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
> +
> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
> + WM831X_USB_ILIM_MASK, best);
> +
> + return 0;
> +}
> +
>  /*
>   *   Battery properties
>   */
> @@ -607,6 +647,22 @@ static int wm831x_power_probe(struct platform_device 
> *pdev)
>   }
>   }
>  
> + power->usb_phy = devm_usb_get_phy_by_phandle(&pdev->dev,
> +  "usb-phy", 0);
> + if (IS_ERR(power->usb_phy)) {
> + ret = PTR_ERR(power->usb_phy);
> + dev_err(&pdev->dev, "Failed to find USB phy: %d\n", ret);
> + goto err_bat_irq;
> + }
> +
> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
> + ret = usb_register_notifier(power->usb_phy,
> + &power->usb_notify);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to register notifier: %d\n", ret);
> + goto err_bat_irq;
> + }
> +
>   return ret;
>  
>  err_bat_irq:
> @@ -637,6 +693,11 @@ static int wm831x_power_remove(struct platform_device 
> *pdev)
>   struct wm831x *wm831x = wm831x_power->wm831x;
>   int irq, i;
>  
> + if (wm831x_power->usb_phy) {
> + usb_unregister_notifier(wm831x_power->usb_phy,
> + &wm831x_power->usb_notify);
> + }
> +
>   for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
>   irq = wm831x_irq(wm831x, 
>platform_get_irq_byname(pdev,
> -- 
> 1.7.9.5
> 


signature.asc
Description: PGP signature


[GIT PULL] USB/PHY patches for 4.13-rc1

2017-07-03 Thread Greg KH
The following changes since commit 41f1830f5a7af77cf5c86359aba3cbd706687e52:

  Linux 4.12-rc6 (2017-06-19 22:19:37 +0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/usb-4.13-rc1

for you to fetch changes up to 6836796de4019944f4ba4c99a360e8250fd2e735:

  Add USB quirk for HVR-950q to avoid intermittent device resets (2017-06-29 
14:49:06 +0200)


USB/PHY patches for 4.13-rc1

Here is the big patchset of USB and PHY driver updates for 4.13-rc1.

On the PHY side, they decided to move files around to "make things
easier" in their tree.  Hopefully that wasn't a mistake, but in
linux-next testing, we haven't had any reported problems.

There's the usual set of gadget and xhci and musb updates in here as
well, along with a number of smaller updates for a raft of different USB
drivers.  Full details in the shortlog, nothing really major.

All of these have been in linux-next for a while with no reported
issues.

Signed-off-by: Greg Kroah-Hartman 


Alan Stern (8):
  USB: f_mass_storage: improve async notification handling
  USB: f_mass_storage: improve memory barriers and synchronization
  USB: ene_usb6250: fix first command execution
  USB: ene_usb6250: fix SCSI residue overwriting
  USB: ene_usb6250: implement REQUEST SENSE
  USB: ene_usb6250: remove subroutine duplication
  USB: ene_usb6250: turn off the Removable flag
  USB: add usbfs ioctl to retrieve the connection speed

Alexandre Bailon (1):
  usb: musb: musb_cppi41: Defer probe only if DMA is not ready

Alexandre Belloni (1):
  usb: gadget: udc: atmel: Remove unnecessary macros

Andy Shevchenko (4):
  extcon: int3496: Switch to devm_acpi_dev_add_driver_gpios()
  usb: misc: usbsevseg: Use sysfs_match_string() helper
  usb: gadget: udc: atmel: Remove AVR32 bits from the driver
  usb: dwc3: gadget: increase readability of dwc3_gadget_init_endpoints()

Arnd Bergmann (1):
  phy: cpcap-usb: add MUSB dependency

Arvind Yadav (6):
  usb: host: ehci-exynos: Handle return value of clk_prepare_enable
  usb: mtu3: Handle return value of clk_prepare_enable
  usb: mtu3: Handle return value of clk_prepare_enable
  usb: gadget: mv_udc: Handle return value of clk_prepare_enable.
  usb: dwc3: exynos: Handle return value of clk_prepare_enable
  usb: host: ohci-pxa27x: Handle return value of clk_prepare_enable

Badhri Jagan Sridharan (1):
  usb: typec: Add a sysfs node to manage port type

Baolin Wang (3):
  usb: phy: Introduce one extcon device into usb phy
  usb: phy: phy-qcom-8x16-usb: Remove redundant extcon register/unregister
  usb: phy: phy-msm-usb: Remove redundant extcon register/unregister

Benjamin Herrenschmidt (2):
  usb/uhci: Add support for Aspeed BMC SoCs
  usb: Fix typo in the definition of Endpoint[out]Request

Dan Carpenter (1):
  usb: gadget: udc-xilinx: clean up a variable name

Devin Heitmueller (1):
  Add USB quirk for HVR-950q to avoid intermittent device resets

Eugene Korenevsky (1):
  USB hub_probe: rework ugly goto-into-compound-statement

Felipe Balbi (23):
  usb: dwc3: gadget: don't WARN about lack of TRBs
  usb: dwc3: gadget: lazily map requests for DMA
  usb: dwc3: replace %p with %pK
  tools: usb: testusb: update default vary for superspeed
  usb: dwc3: update documentation
  usb: dwc3: debugfs: slightly improve output of trb_ring
  usb: dwc3: gadget: slight cleanup to dwc3_process_event_entry()
  usb: dwc3: trace: rely on __string() and __assign_str()
  usb: dwc3: debug: remove static char buffer from dwc3_decode_event()
  usb: dwc3: trace: decode ctrl request
  usb: dwc3: add ReST documentation
  usb: move ReST documentation to Documentation/driver-api/usb/
  phy: tusb1210: add support for TUSB1211
  phy: tusb1210: implement ->set_mode()
  usb: gadget: core: introduce ->udc_set_speed() method
  usb: dwc3: gadget: implement ->udc_set_speed()
  usb: gadget: dummy: implement ->udc_set_speed()
  usb: gadget: udc: add a 'function' sysfs file
  Documentation: ABI: sysfs-class-udc: remove duplicated entry
  usb: dwc3: ep0: make sure wValue is 0 on GetStatus()
  usb: dwc3: ulpi: conditionally resume ULPI PHY
  usb: dwc3: core: initialize ULPI before trying to get the PHY
  usb: dwc3: core: program PHY for proper DRD modes

Florian Fainelli (2):
  usb: core: Check URB setup_packet and transfer_buffer sanity
  usb: udc: core: Error if req->buf is either from vmalloc or stack

Frank Wang (1):
  phy: rockchip-inno-usb2: add support of usb2-phy for rk3228 SoCs

Geliang Tang (2):
  usb: cdc-wdm: use memdup_user
  USB: iowarrior: use memdup_user

Greg Kroah-Hartman (8):
  Merge 4.12-rc2 into usb-next
  Merge 4.12-rc5 into us

[PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

2017-07-03 Thread Manu Gautam
Driver powers-off PHYs and reinitializes DWC3 core and gadget on
resume. While this works fine for gadget mode but in host
mode there is not re-initialization of host stack. Also, resetting
bus as part of bus_suspend/resume is not correct which could affect
(or disconnect) connected devices.
Fix this by not reinitializing core on suspend/resume in host mode
for HOST only and OTG/drd configurations.

Signed-off-by: Manu Gautam 

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c22c37d..fc556a4 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -924,6 +924,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
 
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
+   dwc->current_dr_role = DWC3_GCTL_PRTCAP_DEVICE;
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_DEVICE);
ret = dwc3_gadget_init(dwc);
if (ret) {
@@ -933,6 +934,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
}
break;
case USB_DR_MODE_HOST:
+   dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST;
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST);
ret = dwc3_host_init(dwc);
if (ret) {
@@ -1280,21 +1282,19 @@ static int dwc3_suspend_common(struct dwc3 *dwc)
 {
unsigned long   flags;
 
-   switch (dwc->dr_mode) {
-   case USB_DR_MODE_PERIPHERAL:
-   case USB_DR_MODE_OTG:
+   switch (dwc->current_dr_role) {
+   case DWC3_GCTL_PRTCAP_DEVICE:
spin_lock_irqsave(&dwc->lock, flags);
dwc3_gadget_suspend(dwc);
spin_unlock_irqrestore(&dwc->lock, flags);
+   dwc3_core_exit(dwc);
break;
-   case USB_DR_MODE_HOST:
+   case DWC3_GCTL_PRTCAP_HOST:
default:
/* do nothing */
break;
}
 
-   dwc3_core_exit(dwc);
-
return 0;
 }
 
@@ -1303,18 +1303,17 @@ static int dwc3_resume_common(struct dwc3 *dwc)
unsigned long   flags;
int ret;
 
-   ret = dwc3_core_init(dwc);
-   if (ret)
-   return ret;
+   switch (dwc->current_dr_role) {
+   case DWC3_GCTL_PRTCAP_DEVICE:
+   ret = dwc3_core_init(dwc);
+   if (ret)
+   return ret;
 
-   switch (dwc->dr_mode) {
-   case USB_DR_MODE_PERIPHERAL:
-   case USB_DR_MODE_OTG:
spin_lock_irqsave(&dwc->lock, flags);
dwc3_gadget_resume(dwc);
spin_unlock_irqrestore(&dwc->lock, flags);
-   /* FALLTHROUGH */
-   case USB_DR_MODE_HOST:
+   break;
+   case DWC3_GCTL_PRTCAP_HOST:
default:
/* do nothing */
break;
@@ -1325,7 +1324,7 @@ static int dwc3_resume_common(struct dwc3 *dwc)
 
 static int dwc3_runtime_checks(struct dwc3 *dwc)
 {
-   switch (dwc->dr_mode) {
+   switch (dwc->current_dr_role) {
case USB_DR_MODE_PERIPHERAL:
case USB_DR_MODE_OTG:
if (dwc->connected)
@@ -1368,12 +1367,11 @@ static int dwc3_runtime_resume(struct device *dev)
if (ret)
return ret;
 
-   switch (dwc->dr_mode) {
-   case USB_DR_MODE_PERIPHERAL:
-   case USB_DR_MODE_OTG:
+   switch (dwc->current_dr_role) {
+   case DWC3_GCTL_PRTCAP_DEVICE:
dwc3_gadget_process_pending_events(dwc);
break;
-   case USB_DR_MODE_HOST:
+   case DWC3_GCTL_PRTCAP_HOST:
default:
/* do nothing */
break;
@@ -1389,13 +1387,12 @@ static int dwc3_runtime_idle(struct device *dev)
 {
struct dwc3 *dwc = dev_get_drvdata(dev);
 
-   switch (dwc->dr_mode) {
-   case USB_DR_MODE_PERIPHERAL:
-   case USB_DR_MODE_OTG:
+   switch (dwc->current_dr_role) {
+   case DWC3_GCTL_PRTCAP_DEVICE:
if (dwc3_runtime_checks(dwc))
return -EBUSY;
break;
-   case USB_DR_MODE_HOST:
+   case DWC3_GCTL_PRTCAP_HOST:
default:
/* do nothing */
break;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na 
Linux Foundation Collaborative Project

--
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 2/2] usb: dwc3: pci: Runtime resume child device from wq

2017-07-03 Thread Manu Gautam
Driver currently resumes and increments pm usage_count
of its child device (dwc3 main) from its runtime_resume
handler. This requires dwc3 runtime_resume to perform
pm_runtime_put to decrement the pm usage_count. However
runtime_put from dwc3 happens for non pci drivers
(e.g. dwc3-if-simple.c) as well which results in dwc3
pm usage_count becoming negative after couple of
runtime suspend resume iterations. Fix this by
performing runtime_get/put from dwc3-pci driver only
using workqueue.

Signed-off-by: Manu Gautam 

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index fc556a4..87dedb9 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1378,7 +1378,6 @@ static int dwc3_runtime_resume(struct device *dev)
}
 
pm_runtime_mark_last_busy(dev);
-   pm_runtime_put(dev);
 
return 0;
 }
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 84a2ceb..e354acc 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -61,6 +62,7 @@ struct dwc3_pci {
u8 uuid[16];
 
unsigned int has_dsm_for_pm:1;
+   struct work_struct wakeup_work;
 };
 
 static const struct acpi_gpio_params reset_gpios = { 0, 0, false };
@@ -174,6 +176,22 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
return 0;
 }
 
+#ifdef CONFIG_PM
+static void dwc3_pci_resume_work(struct work_struct *work)
+{
+   struct dwc3_pci *dwc = container_of(work, struct dwc3_pci, wakeup_work);
+   struct platform_device *dwc3 = dwc->dwc3;
+   int ret;
+
+   ret = pm_runtime_get_sync(&dwc3->dev);
+   if (ret)
+   return;
+
+   pm_runtime_mark_last_busy(&dwc3->dev);
+   pm_runtime_put_sync_autosuspend(&dwc3->dev);
+}
+#endif
+
 static int dwc3_pci_probe(struct pci_dev *pci,
const struct pci_device_id *id)
 {
@@ -233,6 +251,9 @@ static int dwc3_pci_probe(struct pci_dev *pci,
device_set_run_wake(dev, true);
pci_set_drvdata(pci, dwc);
pm_runtime_put(dev);
+#ifdef CONFIG_PM
+   INIT_WORK(&dwc->wakeup_work, dwc3_pci_resume_work);
+#endif
 
return 0;
 err:
@@ -244,6 +265,9 @@ static void dwc3_pci_remove(struct pci_dev *pci)
 {
struct dwc3_pci *dwc = pci_get_drvdata(pci);
 
+#ifdef CONFIG_PM
+   cancel_work_sync(&dwc->wakeup_work);
+#endif
device_init_wakeup(&pci->dev, false);
pm_runtime_get(&pci->dev);
platform_device_unregister(dwc->dwc3);
@@ -319,14 +343,15 @@ static int dwc3_pci_runtime_suspend(struct device *dev)
 static int dwc3_pci_runtime_resume(struct device *dev)
 {
struct dwc3_pci *dwc = dev_get_drvdata(dev);
-   struct platform_device  *dwc3 = dwc->dwc3;
int ret;
 
ret = dwc3_pci_dsm(dwc, PCI_INTEL_BXT_STATE_D0);
if (ret)
return ret;
 
-   return pm_runtime_get(&dwc3->dev);
+   queue_work(pm_wq, &dwc->wakeup_work);
+
+   return 0;
 }
 #endif /* CONFIG_PM */
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na 
Linux Foundation Collaborative Project

--
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] net: cdc_mbim: apply "NDP to end" quirk to HP lt4132

2017-07-03 Thread David Miller
From: Tore Anderson 
Date: Sat,  1 Jul 2017 15:20:02 +0200

> The HP lt4132 LTE/HSPA+ 4G Module (03f0:a31d) is a rebranded Huawei
> ME906s-158 device. It, like the ME906s-158, requires the "NDP to end"
> quirk for correct operation.
> 
> Signed-off-by: Tore Anderson 

Applied, thank you.
--
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] usb: atm: ueagle-atm: fix spelling mistake: "submition" -> "submission"

2017-07-03 Thread Colin King
From: Colin Ian King 

Trivial fix to spelling mistake in uea_err error message

Signed-off-by: Colin Ian King 
---
 drivers/usb/atm/ueagle-atm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/atm/ueagle-atm.c b/drivers/usb/atm/ueagle-atm.c
index df67815f74e6..a7b69360949e 100644
--- a/drivers/usb/atm/ueagle-atm.c
+++ b/drivers/usb/atm/ueagle-atm.c
@@ -2212,7 +2212,7 @@ static int uea_boot(struct uea_softc *sc)
ret = usb_submit_urb(sc->urb_int, GFP_KERNEL);
if (ret < 0) {
uea_err(INS_TO_USBDEV(sc),
-  "urb submition failed with error %d\n", ret);
+  "urb submission failed with error %d\n", ret);
goto err1;
}
 
-- 
2.11.0

--
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: Null Pointer Dereference in mceusb

2017-07-03 Thread Johan Hovold
On Mon, Jul 03, 2017 at 03:41:59PM +0700, Lars Melin wrote:
> On 2017-07-03 15:10, Johan Hovold wrote:
> > On Thu, Jun 29, 2017 at 07:41:24PM +0200, Sebastian wrote:
> >> Sorry for the long delay, Johan.
> >>
> >> 2017-06-01 9:20 GMT+02:00 Johan Hovold :
> >>> [ +CC: media list ]
> >>>
> >>> On Wed, May 31, 2017 at 08:25:42PM +0200, Sebastian wrote:
> >>>
> >>> What is the lsusb -v output for your device? And have you successfully
> >>> used this device with this driver before?
> >>>
> >>
> >> No, the device wasn't successfully used before that- it crashed every time,
> >> so I threw away the usb receiver. This is also the reason why I cannot give
> >> you the lsusb output. But I can give you the VID:PID -> 03ee:2501 if that
> >> is of any help?
> > 
> > Ok, so it's not necessarily a (recent) regression at least. I can't seem
> > to find anyone else posting lsusb -v output for that device
> > unfortunately.
> > 
> 
> Googling "03ee:2501 bDescriptorType" leads us to:
> https://sourceforge.net/p/lirc/mailman/message/12852102/

Thanks, Lars. Appears I didn't google hard enough.

Well that device has both a bulk IN and OUT endpoint, so if Sebastian's
device has the same descriptors, I'm left without an hypothesis as to
what would have caused the crash.

We'd need to get this verified on a recent mainline kernel (rather than
an older Ubuntu one) and then take it from there.

Thanks,
Johan
--
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 3/3] power: wm831x_power: Support USB charger current limit management

2017-07-03 Thread Charles Keepax
On Mon, Jul 03, 2017 at 02:07:15PM +0800, Baolin Wang wrote:
> Integrate with the newly added USB charger interface to limit the current
> we draw from the USB input based on the input device configuration
> identified by the USB stack, allowing us to charge more quickly from high
> current inputs without drawing more current than specified from others.
> 
> Signed-off-by: Mark Brown 
> Signed-off-by: Baolin Wang 
> ---

>  /*
>   *   Battery properties
>   */
> @@ -607,6 +647,22 @@ static int wm831x_power_probe(struct platform_device 
> *pdev)
>   }
>   }
>  
> + power->usb_phy = devm_usb_get_phy_by_phandle(&pdev->dev,
> +  "usb-phy", 0);
> + if (IS_ERR(power->usb_phy)) {
> + ret = PTR_ERR(power->usb_phy);
> + dev_err(&pdev->dev, "Failed to find USB phy: %d\n", ret);
> + goto err_bat_irq;
> + }
> +

We should probably update the binding documentation for this as
well: mfd/wm831x.txt

Also I am not sure this needs to be implemented now, but what is
the plan regarding pdata systems? Generally the driver supports
both and it would be nice to know there is a way forward for that
even if we don't implement it yet.

Thanks,
Charles
--
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 1/1] net: cdc_ncm: Reduce memory use when kernel memory low

2017-07-03 Thread David Miller
From: Jim Baxter 
Date: Wed, 28 Jun 2017 21:35:29 +0100

> The CDC-NCM driver can require large amounts of memory to create
> skb's and this can be a problem when the memory becomes fragmented.
> 
> This especially affects embedded systems that have constrained
> resources but wish to maximise the throughput of CDC-NCM with 16KiB
> NTB's.
> 
> The issue is after running for a while the kernel memory can become
> fragmented and it needs compacting.
> If the NTB allocation is needed before the memory has been compacted
> the atomic allocation can fail which can cause increased latency,
> large re-transmissions or disconnections depending upon the data
> being transmitted at the time.
> This situation occurs for less than a second until the kernel has
> compacted the memory but the failed devices can take a lot longer to
> recover from the failed TX packets.
> 
> To ease this temporary situation I modified the CDC-NCM TX path to
> temporarily switch into a reduced memory mode which allocates an NTB
> that will fit into a USB_CDC_NCM_NTB_MIN_OUT_SIZE (default 2048 Bytes)
> sized memory block and only transmit NTB's with a single network frame
> until the memory situation is resolved.
> Each time this issue occurs we wait for an increasing number of
> reduced size allocations before requesting a full size one to not
> put additional pressure on a low memory system.
> 
> Once the memory is compacted the CDC-NCM data can resume transmitting
> at the normal tx_max rate once again.
> 
> Signed-off-by: Jim Baxter 

Patch applied, thanks.
--
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: Moxa UPort 1150 and RS-422/485… what's the "proper" way to switch modes

2017-07-03 Thread Johan Hovold
On Thu, Jun 29, 2017 at 08:50:32PM +0100, Alan Cox wrote:
> So IMHO there are two cases
> 
> 1. The configuration is fixed in the hardware - in which case we should
> automatically set it in kernel, or from device tree.

Right.

> 2. The configuration is soft - in which case you need an ioctl you can
> use on the port to change it - irrespective of whether sysfs also handles
> it. For simple permissions reasons and also to avoid races you need that
> ioctl.

Ok, but if we are going to extend and use the RS485 ioctl for this, I
think we should just stick to that and not add a sysfs-interface as
well.

I'll take a closer look at this.

> We intentionally have lots of spare space left to extend the RS485 ioctl,
> and we have termiox which contains even more room and historically in
> other Unixen dealt with all sorts of weird and wonderful parameters used
> on stuff like synchronous ports.

Yes, your foresight when adding (generalising) that ioctl might come in
handy now. :)

Thanks,
Johan
--
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: Null Pointer Dereference in mceusb

2017-07-03 Thread Lars Melin

On 2017-07-03 15:10, Johan Hovold wrote:

On Thu, Jun 29, 2017 at 07:41:24PM +0200, Sebastian wrote:

Sorry for the long delay, Johan.

2017-06-01 9:20 GMT+02:00 Johan Hovold :

[ +CC: media list ]

On Wed, May 31, 2017 at 08:25:42PM +0200, Sebastian wrote:

What is the lsusb -v output for your device? And have you successfully
used this device with this driver before?



No, the device wasn't successfully used before that- it crashed every time,
so I threw away the usb receiver. This is also the reason why I cannot give
you the lsusb output. But I can give you the VID:PID -> 03ee:2501 if that
is of any help?


Ok, so it's not necessarily a (recent) regression at least. I can't seem
to find anyone else posting lsusb -v output for that device
unfortunately.



Googling "03ee:2501 bDescriptorType" leads us to:
https://sourceforge.net/p/lirc/mailman/message/12852102/

/Lars

--
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] usb: serial: Add support for Qivicon USB ZigBee dongle

2017-07-03 Thread Johan Hovold
On Mon, Jul 03, 2017 at 10:16:22AM +0200, Frans Klaver wrote:
> On Mon, Jul 3, 2017 at 10:13 AM, Johan Hovold  wrote:
> > On Fri, Jun 30, 2017 at 02:49:55PM +0200, Frans Klaver wrote:
> >> On Fri, Jun 30, 2017 at 2:44 PM, Stefan Triller  
> >> wrote:
> >> > The German Telekom offers a ZigBee USB Stick under the brand name Qivicon
> >> > for their SmartHome Home Base in its 1. Generation. The productId is not
> >> > known by the according kernel module, this patch adds support for it.
> >> >
> >> > Signed-off-by: Stefan Triller 
> >>
> >> Reviewed-by: Frans Klaver 
> >
> > Thanks for the patch and review. I've queued this one up for -rc2.
> 
> I guess this could go into stable as well?

Yes, I'll just add the stable tag when I apply the patch.

Thanks,
Johan
--
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] usb: serial: Add support for Qivicon USB ZigBee dongle

2017-07-03 Thread Frans Klaver
On Mon, Jul 3, 2017 at 10:13 AM, Johan Hovold  wrote:
> On Fri, Jun 30, 2017 at 02:49:55PM +0200, Frans Klaver wrote:
>> On Fri, Jun 30, 2017 at 2:44 PM, Stefan Triller  
>> wrote:
>> > The German Telekom offers a ZigBee USB Stick under the brand name Qivicon
>> > for their SmartHome Home Base in its 1. Generation. The productId is not
>> > known by the according kernel module, this patch adds support for it.
>> >
>> > Signed-off-by: Stefan Triller 
>>
>> Reviewed-by: Frans Klaver 
>
> Thanks for the patch and review. I've queued this one up for -rc2.

I guess this could go into stable as well?

Frans
--
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] usb: serial: Add support for Qivicon USB ZigBee dongle

2017-07-03 Thread Johan Hovold
On Fri, Jun 30, 2017 at 02:49:55PM +0200, Frans Klaver wrote:
> On Fri, Jun 30, 2017 at 2:44 PM, Stefan Triller  
> wrote:
> > The German Telekom offers a ZigBee USB Stick under the brand name Qivicon
> > for their SmartHome Home Base in its 1. Generation. The productId is not
> > known by the according kernel module, this patch adds support for it.
> >
> > Signed-off-by: Stefan Triller 
> 
> Reviewed-by: Frans Klaver 

Thanks for the patch and review. I've queued this one up for -rc2.

Johan
--
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: Null Pointer Dereference in mceusb

2017-07-03 Thread Johan Hovold
On Thu, Jun 29, 2017 at 07:41:24PM +0200, Sebastian wrote:
> Sorry for the long delay, Johan.
> 
> 2017-06-01 9:20 GMT+02:00 Johan Hovold :
> > [ +CC: media list ]
> >
> > On Wed, May 31, 2017 at 08:25:42PM +0200, Sebastian wrote:
> >
> > What is the lsusb -v output for your device? And have you successfully
> > used this device with this driver before?
> >
> 
> No, the device wasn't successfully used before that- it crashed every time,
> so I threw away the usb receiver. This is also the reason why I cannot give
> you the lsusb output. But I can give you the VID:PID -> 03ee:2501 if that
> is of any help?

Ok, so it's not necessarily a (recent) regression at least. I can't seem
to find anyone else posting lsusb -v output for that device
unfortunately.

> > Can you reproduce this with a more recent mainline kernel (e.g.
> > 4.11.3)?
> 
> Unfortunately no :(
> 
> >
> > This looks like something which could happen if the device is lacking an
> > OUT endpoint, and a sanity check to catch that recently went in (and was
> > backported to the non-EOL stable trees).
> 
> I could buy the same device again and try?

If you're willing to that, that'd very helpful; either to verify that
the crash is already fixed (as mentioned above), or to allow us to track
down the separate issue.

Thanks,
Johan
--
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] usb: typec: include linux/device.h in ucsi.h

2017-07-03 Thread Heikki Krogerus
On Fri, Jun 30, 2017 at 05:46:16PM +0200, Arnd Bergmann wrote:
> The new driver causes a build failure in some configurations:
> 
> In file included from /git/arm-soc/drivers/usb/typec/ucsi/trace.h:9:0,
>  from /git/arm-soc/drivers/usb/typec/ucsi/trace.c:2:
> drivers/usb/typec/ucsi/ucsi.h:331:39: error: 'struct device' declared inside 
> parameter list will not be visible outside of this definition or declaration 
> [-Werror]
> 
> This includes the required header file.
> 
> Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface")
> Signed-off-by: Arnd Bergmann 

Acked-by: Heikki Krogerus 

> ---
>  drivers/usb/typec/ucsi/ucsi.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/typec/ucsi/ucsi.h b/drivers/usb/typec/ucsi/ucsi.h
> index 6b0d2f0918c6..8a88f45822e3 100644
> --- a/drivers/usb/typec/ucsi/ucsi.h
> +++ b/drivers/usb/typec/ucsi/ucsi.h
> @@ -3,6 +3,7 @@
>  #define __DRIVER_USB_TYPEC_UCSI_H
>  
>  #include 
> +#include 
>  #include 
>  
>  /* 
> -- */
> -- 
> 2.9.0

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