Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

On Tue, Jun 20, 2017 at 2:32 AM, Alan Stern wrote: > > It's possible that the test was invalid. Kai-Heng did not say whether > /sys/.../power/wakeup was set to "enabled" for both the EHCI controller > and the USB root hub beneath it, before the test was started. If >

Re: Reply Urgent

Hello, How are you doing? I have been sent to inform you that, We have an inheritance of a deceased client with your surname. Contact Mr Andrew Bailey Reply Email To: myinf...@gmail.com with your "Full Names" for more info. Thanks for your understanding. Reply ASAP thank you. Melissa.

Re: [PATCH v15 2/7] power: add power sequence library

On Mon, Jun 19, 2017 at 11:48:05AM +0200, Ulf Hansson wrote: > [...] > > >> > > >> > Unlike the MMC design, there is no dts entry to indicate whether this > >> > device needs pwrseq or not at this design, it will only carry out power > >> > on sequence after matching. So, return -EPROBE_DEFER may

Re: [GIT PULL] USB-serial fixes for v4.12-rc6

On Fri, Jun 16, 2017 at 02:44:19PM +0200, Johan Hovold wrote: > The following changes since commit 32c1431eea4881a6b17bd7c639315010aeefa452: > > Linux 4.12-rc5 (2017-06-11 16:48:20 -0700) > > are available in the git repository at: > >

Re: [PATCH] usb: Fix microtek driver compilation errors

On Tue, Jun 06, 2017 at 03:05:46PM +0200, Greg KH wrote: > On Tue, Jun 06, 2017 at 02:18:10PM +0200, Mariusz Skamra wrote: > > This fixes compilation errors due to missing scsi_cmnd.h include. > > > > usb/image/microtek.c: In function ‘mts_slave_alloc’: > > usb/image/microtek.c:326:3: error:

Re: [GIT PULL] USB changes for v4.13 merge window

On Mon, Jun 19, 2017 at 09:41:31AM +0300, Felipe Balbi wrote: > > Hi Greg, > > here's my pull request for the current merge window. Patches have been > in linux-next for a while and there's time for them to soak a little > more. > > Note that you're gonna get a conflict when merging this on >

[PATCH] phy: qcom-qmp: Fix failure path in phy_init functions

Fixing the clk enable failure path in qcom_qmp_phy_init() and cleanup the reset control deassertion failure path in qcom_qmp_phy_com_init(). Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets") Cc: Kishon Vijay Abraham I Signed-off-by: Vivek Gautam

Re: [PATCH v5 3/6] reset: hide reset control arrays behind struct reset_control

Hi Philipp, On 06/19/2017 05:48 PM, Philipp Zabel wrote: Hi Vivek, On Tue, 2017-06-13 at 12:16 +0530, Vivek Gautam wrote: [...] @@ -102,18 +94,6 @@ static inline struct reset_control *__devm_reset_control_get( return optional ? NULL : ERR_PTR(-ENOTSUPP); } -static inline

[PATCH v6 2/4] usb: dwc3: of-simple: Re-order resource handling in remove

From: Vivek Gautam Move clock handling after of_platform_depopulate to achieve a sequence that is reverse of the probe sequence. Cc: Felipe Balbi Signed-off-by: Vivek Gautam --- No changes since v5. ---

[PATCH v6 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

From: Vivek Gautam Make use of of_reset_control_array_get_exclusive() to manage an array of reset controllers available with the device. Cc: Jon Hunter Cc: Thierry Reding Signed-off-by: Vivek Gautam

[PATCH v6 3/4] usb: dwc3: of-simple: Add support to get resets for the device

From: Vivek Gautam Add support to get a list of resets available for the device. These resets must be kept de-asserted until the device is in use. Cc: Felipe Balbi Signed-off-by: Vivek Gautam [p.za...@pengutronix.de:

[PATCH v6 0/4] reset: APIs to manage a list of resets

A set of patches to allow consumers to get and de/assert or trigger a number of resets at the same time. A patch on top of Vivek's original API extension is added to hide the reset_control_array behind a struct reset_control so that the consumer doesn't have to care about the difference between a

[PATCH v6 1/4] reset: Add APIs to manage array of resets

From: Vivek Gautam Many devices may want to request a bunch of resets and control them. So it's better to manage them as an array. Add APIs to _get() an array of reset_control, reusing the _assert(), _deassert(), and _reset() APIs for single reset controls. Since

[GIT PULL] Immutable branch between MFD and X86 due for the v4.13 merge window

Enjoy! The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-x86-v4.13 for you to fetch changes up to

Re: [PATCH 08/12] Add USB quirk for HVR-950q to avoid intermittent device resets

> I've accepted the other patches in this patch series for the media subsystem, > but this patch should go through the USB subsystem. Cc-ed linux-usb. > > Acked-by: Hans Verkuil I'm not sure who on the linux-usb mailing list would need to deal with this, but would be

Re: [GIT PULL] Immutable branch between MFD and X86 due for the v4.13 merge window

On Mon, Jun 19, 2017 at 5:48 PM, Lee Jones wrote: > Enjoy! Thanks! I suppose this one kbuild bot doesn't complain about :-) Darren, do we need it or we can survive until v4.13-rc1? > > The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: > >

Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

On Mon, 19 Jun 2017, Bjorn Helgaas wrote: > > > Have you tested it with system suspend? That is, if you suspend the > > > whole computer, does plugging or unplugging a USB device cause the > > > system to wake up? > > > > No, the system will not wake up when plugging or unplugging. > > Tried

Re: [PATCH v6 1/4] reset: Add APIs to manage array of resets

Hi Vivek, [auto build test WARNING on pza/reset/next] [also build test WARNING on v4.12-rc6 next-20170619] [cannot apply to balbi-usb/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits

[PATCH v4] xhci: Bad Ethernet performance plugged in ASM1042A host

Clean up patch originally submitted by Jiahu Chang https://www.spinics.net/lists/linux-usb/msg158310.html When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad performance was manifesting in Web browser use (like download large file such as ISO

Re: [PATCH v6 1/4] reset: Add APIs to manage array of resets

Hi Vivek, [auto build test WARNING on pza/reset/next] [also build test WARNING on v4.12-rc6 next-20170619] [cannot apply to balbi-usb/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits

Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

On Mon, Jun 19, 2017 at 11:30:18AM +0800, Kai-Heng Feng wrote: > On Sat, Jun 17, 2017 at 1:30 AM, Alan Stern wrote: > > On Sat, 17 Jun 2017, Kai-Heng Feng wrote: > > > >> On Fri, Jun 16, 2017 at 11:07 AM, Kai-Heng Feng > >> wrote: > >> > On

FW: Unable to perform remote wakeup of host with USB HID Composite Device

Hello, I have been trying to get my composite HID gadget to work in BIOS via the Boot Protocol. However, I've noticed that the set_protocol() command to switch the device to boot mode from report mode is not implemented in the hidg_setup function in the HID function driver (f_hid.c). How hard

Boot mode Support for HID gadget

Hello, I have been trying to get my composite HID gadget to work in BIOS via the Boot Protocol. However, I've noticed that the set_protocol() command to switch the device to boot mode from report mode is not implemented in the hidg_setup function in the HID function driver (f_hid.c). How hard

Re: [GIT PULL] Immutable branch between MFD and X86 due for the v4.13 merge window

On Mon, Jun 19, 2017 at 06:08:27PM +0300, Andy Shevchenko wrote: > On Mon, Jun 19, 2017 at 5:48 PM, Lee Jones wrote: > > Enjoy! > > Thanks! > > I suppose this one kbuild bot doesn't complain about :-) > > Darren, do we need it or we can survive until v4.13-rc1? I suggest

Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

On Monday, June 19, 2017 02:32:57 PM Alan Stern wrote: > On Mon, 19 Jun 2017, Bjorn Helgaas wrote: > > > > > Have you tested it with system suspend? That is, if you suspend the > > > > whole computer, does plugging or unplugging a USB device cause the > > > > system to wake up? > > > > > > No,

Re: [PATCH v15 2/7] power: add power sequence library

[...] >> > >> > Unlike the MMC design, there is no dts entry to indicate whether this >> > device needs pwrseq or not at this design, it will only carry out power >> > on sequence after matching. So, return -EPROBE_DEFER may not work since >> > this device may never need pwrseq. >> >> Then, how

Re: [PATCH v15 2/7] power: add power sequence library

On 15 June 2017 at 12:06, Peter Chen wrote: > On Thu, Jun 15, 2017 at 11:35:20AM +0200, Ulf Hansson wrote: >> On 15 June 2017 at 11:11, Peter Chen wrote: >> > On Thu, Jun 15, 2017 at 10:11:45AM +0200, Ulf Hansson wrote: >> >> > Yes, you are right.

[PATCH 0/1] xhci fix for usb-linus

Hi Greg Only one AMD Promontory fix for usb-linus. Not sure if it's too late for 4.12 but AMD seem quite eager to get this upstream. Thanks Mathias Jiahau Chang (1): xhci: Limit USB2 port wake support for AMD Promontory hosts drivers/usb/host/xhci-hub.c | 3 +++ drivers/usb/host/xhci-pci.c

[PATCH 1/1] xhci: Limit USB2 port wake support for AMD Promontory hosts

From: Jiahau Chang For AMD Promontory xHCI host, although you can disable USB 2.0 ports in BIOS settings, those ports will be enabled anyway after you remove a device on that port and re-plug it in again. It's a known limitation of the chip. As a workaround we can clear the

[GIT PULL] USB changes for v4.13 merge window

Hi Greg, here's my pull request for the current merge window. Patches have been in linux-next for a while and there's time for them to soak a little more. Note that you're gonna get a conflict when merging this on f_mass_storage, you should use the version coming from my tree which was authored

Re: [PATCH v15 2/7] power: add power sequence library

On Mon, Jun 19, 2017 at 10:09:58AM +0200, Ulf Hansson wrote: > On 15 June 2017 at 12:06, Peter Chen wrote: > > On Thu, Jun 15, 2017 at 11:35:20AM +0200, Ulf Hansson wrote: > >> On 15 June 2017 at 11:11, Peter Chen wrote: > >> > On Thu, Jun 15, 2017

Re: [PATCH v5 3/6] reset: hide reset control arrays behind struct reset_control

Hi Vivek, On Tue, 2017-06-13 at 12:16 +0530, Vivek Gautam wrote: [...] > > @@ -102,18 +94,6 @@ static inline struct reset_control > > *__devm_reset_control_get( > > return optional ? NULL : ERR_PTR(-ENOTSUPP); > > } > > > > -static inline > > -int reset_control_array_assert(struct

Re: [PATCH v5 6/6] soc/tegra: pmc: Use the new reset APIs to manage reset controllers

On Thu, 2017-06-01 at 18:52 +0200, Philipp Zabel wrote: > From: Vivek Gautam > > Make use of reset_control_array_*() set of APIs to manage > an array of reset controllers available with the device. > > Cc: Jon Hunter > Cc: Thierry Reding