RE: [PATCH v5] usb: ohci-at91: Forcibly suspend ports while USB suspend

Hi Alan, > -Original Message- > From: Alan Stern [mailto:st...@rowland.harvard.edu] > Sent: 2016年8月4日 23:02 > To: Wenyou Yang > Cc: Greg Kroah-Hartman ; Nicolas Ferre > ; Alexandre Belloni

Re: functionfs example

Hi, Patrick Doyle writes: > So far, the Google hasn't helped me much, so I'd like to play "Ask the > experts". > > Can anybody point me at an example of code using functionfs. > > I have legacy code that works with gadgetfs that I would like to > convert to use functionfs, so

functionfs example

So far, the Google hasn't helped me much, so I'd like to play "Ask the experts". Can anybody point me at an example of code using functionfs. I have legacy code that works with gadgetfs that I would like to convert to use functionfs, so a wiki page or presentation walking through that process

Re: [Letux-kernel] [PATCH v2] musb: omap2430: do not assume balanced enable()/disable()

On Thu, 4 Aug 2016 16:49:30 +0200 "H. Nikolaus Schaller" wrote: > > Rationale: > > > > The charger driver calls pm_runtime_get_sync(bci->transceiver->dev); > > which should indirectly call twl4030_usb_set_mode to set the > > POWER_CTRL_OTG_ENAB bit. This enables the

Re: [PATCH] USB: fix invalid memory access in hub_activate()

On 04-08-16, 11:49, Viresh Kumar wrote: > On 04-08-16, 14:47, Alan Stern wrote: > > On Thu, 4 Aug 2016, Viresh Kumar wrote: > > > > > On 04-08-16, 11:20, Alan Stern wrote: > > > > Yes, it could lead to this deadlock. > > > > > > > > > Should we rather have device_trylock instead of device_lock >

[PATCH V2] usb: hub: Fix unbalanced reference count/memory leak/deadlocks

Memory leak and unbalanced reference count: If the hub gets disconnected while the core is still activating it, this can result in leaking memory of few USB structures. This will happen if we have done a kref_get() from hub_activate() and scheduled a delayed work item for HUB_INIT2/3. Now if

Re: [PATCH] USB: fix invalid memory access in hub_activate()

On Thu, 4 Aug 2016, Viresh Kumar wrote: > On 04-08-16, 11:49, Viresh Kumar wrote: > > On 04-08-16, 14:47, Alan Stern wrote: > > > On Thu, 4 Aug 2016, Viresh Kumar wrote: > > > > > > > On 04-08-16, 11:20, Alan Stern wrote: > > > > > Yes, it could lead to this deadlock. > > > > > > > > > > >

Re: [PATCH] USB: fix invalid memory access in hub_activate()

On Thu, 4 Aug 2016, Viresh Kumar wrote: > > > What about another patch on top of my patch to fix the deadlock? > > > > Or another patch in place of yours to fix both problems. Has your > > patch been merged yet? I don't see it in any of the branches in > >

Re: usbtmc: vendor specific i/o

On Thu, Aug 04, 2016 at 06:59:30AM +0200, Greg Kroah-Hartman wrote: > On Wed, Aug 03, 2016 at 09:06:25AM +0200, Ladislav Michl wrote: > > Yes, also was lacking proper description and signoff. So, I'm considering > > ioctls based approach okay, although that question (the only one I really > > had)

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

When DMA is not used, I see the same behavior: lots of zero-length packages received. Can It be related to some kind of USB overflow due to long input data processing with disabled IRQ? When HCD_BC is used then part of processing is postponed and this can explain greater throughput due to better

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

I've just found that in such cases, when DMA actual length is zero, both cppi41_channel->prog_len and txstate.residue equal 960 at musb_cppi41 line 225: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_cppi41.c#n225 2016-08-04 22:08 GMT+03:00 Matwey V.

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

I've just found that dma->actual_len equals to zero in most cases at musb_host.c line 1946. And this produces zero-length packages. http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/musb/musb_host.c#n1946 Any ideas why? 2016-08-04 19:57 GMT+03:00 Matwey V.

[PATCH] usb: musb: remove redundant stack buffers

aDate is always the empty string, so entirely pointless. The aRevision formatting might as well be done as part of the pr_debug() call - that also avoids it altogether if pr_debug is compiled out. Signed-off-by: Rasmus Villemoes --- drivers/usb/musb/musb_core.c | 12

Re: [PATCH] USB: fix invalid memory access in hub_activate()

On 04-08-16, 14:47, Alan Stern wrote: > On Thu, 4 Aug 2016, Viresh Kumar wrote: > > > On 04-08-16, 11:20, Alan Stern wrote: > > > Yes, it could lead to this deadlock. > > > > > > > Should we rather have device_trylock instead of device_lock > > > > > > No. > > > > > > > > @@ -1031,10 +1031,20

Re: [PATCH] USB: fix invalid memory access in hub_activate()

On Thu, 4 Aug 2016, Viresh Kumar wrote: > On 04-08-16, 11:20, Alan Stern wrote: > > Yes, it could lead to this deadlock. > > > > > Should we rather have device_trylock instead of device_lock > > > > No. > > > > > > @@ -1031,10 +1031,20 @@ static void hub_activate(struct usb_hub > > > >

Re: [PACTH v1] cdc-wdm: Clear read pipeline in case of error

On 2016-08-03 06:39 AM, Oliver Neukum wrote: On Tue, 2016-08-02 at 10:37 -0400, Robert Foss wrote: On 2016-08-02 09:59 AM, Oliver Neukum wrote: On Tue, 2016-08-02 at 09:54 -0400, Robert Foss wrote: On 2016-08-02 08:23 AM, Oliver Neukum wrote: On Thu, 2016-07-28 at 14:19 -0400,

Re: [PATCH] USB: fix invalid memory access in hub_activate()

On 04-08-16, 11:20, Alan Stern wrote: > Yes, it could lead to this deadlock. > > > Should we rather have device_trylock instead of device_lock > > No. > > > > @@ -1031,10 +1031,20 @@ static void hub_activate(struct usb_hub > > > unsigned delay; > > > > > > /* Continue a partial

Re: [PATCH 2/2] usb: dwc3: core: allow device to runtime_suspend several times

On Thu, 4 Aug 2016, Felipe Balbi wrote: > Hi, > > Alan Stern writes: > > > On Thu, 4 Aug 2016, Felipe Balbi wrote: > > > >> > What are you trying to accomplish? Is the problem that wakeup signals > >> > only cause the platform device to be runtime-resumed, but you

Re: [PATCH 1/1] Add driver for smsc usb251x i2c configuration

On Tue, Aug 02, 2016 at 04:31:54PM +0200, Fabien Lahoudere wrote: > This driver copy the configuration of the controller EEPROM via i2c. > Configuration information is available in Documentation/usb/usb251x.txt > > Signed-off-by: Fabien Lahoudere > --- >

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

I've just found that many packages in URBs have zero actual_length (It is a question why). Then the following end of frame criteria leads to `frame underflow' message: if (flen < pdev->vlast_packet_size) { /* Shorter packet... end of frame */

Re: [PATCH 2/2] usb: dwc3: core: allow device to runtime_suspend several times

Hi, Alan Stern writes: > On Thu, 4 Aug 2016, Felipe Balbi wrote: > >> > What are you trying to accomplish? Is the problem that wakeup signals >> > only cause the platform device to be runtime-resumed, but you also need >> > the HCD to wake up? And conversely,

Re: [PATCH 2/2] usb: dwc3: core: allow device to runtime_suspend several times

On Thu, 4 Aug 2016, Felipe Balbi wrote: > > What are you trying to accomplish? Is the problem that wakeup signals > > only cause the platform device to be runtime-resumed, but you also need > > the HCD to wake up? And conversely, whenever the HCD gets > > runtime-suspended you also want the

Re: [Letux-kernel] [PATCH v2] musb: omap2430: do not assume balanced enable()/disable()

On Thu, 4 Aug 2016 18:31:29 +0200 Andreas Kemnade wrote: > Hi, > > On Thu, 4 Aug 2016 07:29:19 -0700 > Tony Lindgren wrote: > > > Hi, > > > > * H. Nikolaus Schaller [160803 10:07]: > > > All this prevents detection of cable

Re: [Letux-kernel] [PATCH v2] musb: omap2430: do not assume balanced enable()/disable()

Hi, On Thu, 4 Aug 2016 07:29:19 -0700 Tony Lindgren wrote: > Hi, > > * H. Nikolaus Schaller [160803 10:07]: > > All this prevents detection of cable plugin-events and VBUS > > measurement and setting OTG_EN before charging is attempted. > > So I gave

Re: [PATCH 2/2] usb: dwc3: core: allow device to runtime_suspend several times

Hi, Alan Stern writes: > On Wed, 3 Aug 2016, Felipe Balbi wrote: > >> >> --- a/drivers/usb/dwc3/core.c >> >> +++ b/drivers/usb/dwc3/core.c >> >> @@ -1192,6 +1192,7 @@ static int dwc3_runtime_resume(struct device *dev) >> >> } >> >> >> >>

Re: [PATCH] USB: fix invalid memory access in hub_activate()

Viresh, I believe this bug report indicates we need to use the alternate approach instead of your "usb: hub: Fix unbalanced reference count and memory leak" patch. On Thu, 4 Aug 2016 mgau...@codeaurora.org wrote: > On 2015-12-17 00:02, Alan Stern wrote: > > Commit 8520f38099cc ("USB: change

Re: [PATCH v5] usb: ohci-at91: Forcibly suspend ports while USB suspend

On Thu, 4 Aug 2016, Wenyou Yang wrote: > The usb controller does not managed correctly the suspend mode for > the ehci. In echi mode, there is no way to have utmi_suspend_o_n[1] > suspend without any device connected to it. This is why this specific > control is added to fix this issue. The

Re: [Letux-kernel] [PATCH v2] musb: omap2430: do not assume balanced enable()/disable()

* H. Nikolaus Schaller [160804 07:50]: > > Am 04.08.2016 um 16:29 schrieb Tony Lindgren : > > > > So I gave this patch a try but it now blocks all deeper SoC idle > > states as the PHY stays active. I think the real fix is to make > > sure the charger

Re: [Letux-kernel] [PATCH v2] musb: omap2430: do not assume balanced enable()/disable()

Hi Tony, > Am 04.08.2016 um 16:29 schrieb Tony Lindgren : > > Hi, > > * H. Nikolaus Schaller [160803 10:07]: >> All this prevents detection of cable plugin-events and VBUS measurement >> and setting OTG_EN before charging is attempted. > > So I gave this

Re: [Letux-kernel] [PATCH v2] musb: omap2430: do not assume balanced enable()/disable()

Hi, * H. Nikolaus Schaller [160803 10:07]: > All this prevents detection of cable plugin-events and VBUS measurement > and setting OTG_EN before charging is attempted. So I gave this patch a try but it now blocks all deeper SoC idle states as the PHY stays active. I think

Re: [PATCH] usb:serial: Add Fintek F81532/534 driver

Hi Alan, One Thousand Gnomes 於 2016/7/29 下午 08:48 寫道: O +static int f81534_set_normal_register(struct usb_device *dev, u16 reg, u8 data) +{ + size_t count = F81534_USB_MAX_RETRY; + int status; + u8 *tmp; + + tmp = kmalloc(sizeof(u8), GFP_KERNEL); + if (!tmp) +

Re: [PATCH v4 2/6] power: add power sequence library

On Wed, Aug 03, 2016 at 03:16:58PM -0700, Matthias Kaehlcke wrote: > El Tue, Aug 02, 2016 at 11:30:48AM +0800 Peter Chen ha dit: > > > diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c > > > > ... > > > > +static DEFINE_MUTEX(pwrseq_list_mutex); > > +static