Hi,
after upgrade from 3.16 to 3.17.2 this device isn't in lsusb output
after plugging in :
Bus 004 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
(driver pl2303, usb to serial converter)
The only way how to make it functional is to boot machine with connected device.
But
On 13.11.2014 00:28, Felipe Balbi wrote:
> Hi,
>
> On Wed, Nov 12, 2014 at 04:54:06PM -0500, Alan Stern wrote:
>
> [...]
>
>>> and the doorbell will never rung. But even if I drop EP_HALTED from the
>>> check below and let EP doorbell be rung, nothing will happen because,
>>> according to XHCI s
Hi Heikki, Kishon,
On Tue, Nov 11, 2014 at 2:23 PM, Vivek Gautam wrote:
> Hi Kishon,
>
>
> On Tue, Nov 11, 2014 at 2:20 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 11 November 2014 02:07 PM, Vivek Gautam wrote:
>>> On Tue, Nov 11, 2014 at 12:12 PM, Kishon Vijay Abraham I
>>> wro
Hello,
On 2014-10-31 19:15, Paul Zimmerman wrote:
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Friday, October 31, 2014 1:04 AM
To: linux-usb@vger.kernel.org; linux-samsung-...@vger.kernel.org
Cc: Marek Szyprowski; Kyungmin Park; Robert Baldyga; Paul Zimmerman; Krzysztof
Kozlo
Hi,
On Thu, Nov 13, 2014 at 01:16:34PM +0200, Mathias Nyman wrote:
> On 13.11.2014 00:28, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Nov 12, 2014 at 04:54:06PM -0500, Alan Stern wrote:
> >
> > [...]
> >
> >>> and the doorbell will never rung. But even if I drop EP_HALTED from the
> >>> check b
Hello,
On 2014-10-31 19:46, Paul Zimmerman wrote:
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Friday, October 31, 2014 3:13 AM
This patch adds mutex, which protects initialization and
deinitialization procedures against suspend/resume methods.
Signed-off-by: Marek Szyprowski
Hi
On 13.11.2014 17:11, Felipe Balbi wrote:
> Hi,
>
> On Thu, Nov 13, 2014 at 01:16:34PM +0200, Mathias Nyman wrote:
>> On 13.11.2014 00:28, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Wed, Nov 12, 2014 at 04:54:06PM -0500, Alan Stern wrote:
>>>
>>> [...]
>>>
> and the doorbell will never rung. Bu
On Wed, 12 Nov 2014, Felipe Balbi wrote:
> > By the way, does the same sort of thing happen after a transfer
> > error (such as a CRC mismatch)? Does the xHCI controller change the
> > state to EP_STATE_HALTED? Or does it instead go directly to
>
> There are a few conditions in which XHCI wil
On Thu, Nov 13, 2014 at 10:17:07AM +0100, Milan Kocian wrote:
> Hi,
>
> after upgrade from 3.16 to 3.17.2 this device isn't in lsusb output
> after plugging in :
>
> Bus 004 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
> (driver pl2303, usb to serial converter)
>
> The o
On Thu, 13 Nov 2014, Mathias Nyman wrote:
> Currently we queue a reset endpoint command from the .endpoint_reset callback
> in host, this is far too late and should be moved
> to when we get a STALL event.
>
> xhci needs to reset control endpoints on stall as well [1]
>
> I got a testpatch fo
On Thu, Nov 13, 2014 at 10:31:55AM -0500, Alan Stern wrote:
> On Wed, 12 Nov 2014, Felipe Balbi wrote:
>
> > > By the way, does the same sort of thing happen after a transfer
> > > error (such as a CRC mismatch)? Does the xHCI controller change the
> > > state to EP_STATE_HALTED? Or does it ins
On Thu, Nov 13, 2014 at 07:44:20AM -0800, Greg KH wrote:
> On Thu, Nov 13, 2014 at 10:17:07AM +0100, Milan Kocian wrote:
> > Hi,
> >
> > after upgrade from 3.16 to 3.17.2 this device isn't in lsusb output
> > after plugging in :
> >
> > Bus 004 Device 002: ID 067b:2303 Prolific Technology, Inc. P
There is no message when PHY is not enabled, IRQ line can't be acquired, or
debugfs registration fails. This patch adds the messages.
Signed-off-by: Andy Shevchenko
---
drivers/usb/chipidea/core.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/c
On Thu, 13 Nov 2014, Mathias Nyman wrote:
> The comment for xhci_endpoint_reset says its called in_interrupt context?
> Does the usb core really call the .endpoint_reset in interrupt
> context? I tried to follow the codepaths in the usb core but couln't figure
> it out
It doesn't really say an
On Thu, Nov 13, 2014 at 04:59:32PM +0100, Milan Kocian wrote:
> On Thu, Nov 13, 2014 at 07:44:20AM -0800, Greg KH wrote:
> > On Thu, Nov 13, 2014 at 10:17:07AM +0100, Milan Kocian wrote:
> > > Hi,
> > >
> > > after upgrade from 3.16 to 3.17.2 this device isn't in lsusb output
> > > after plugging
Hello,
> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Thursday, November 13, 2014 3:44 AM
> To: Felipe Balbi
> Cc: Robert Baldyga; David Cohen; gre...@linuxfoundation.org; linux-
> u...@vger.kernel.org; linux-ker...@vger.kernel.org;
> min...@mina86.com; andrze...@s
On 11/07/2014 07:53 PM, Alan Stern wrote:
>> If I put pm_runtime_get_sync() + put in musb_resume() then the problem
>> is gone. I don't see ehci-hcd doing this in resume, in fact I don't see
>> ehci doing pm_runtime_* at all. So for ehci the device is probably
>> always RPM_ACTIVE.
>
> No, it does
There is a poll loop for max 25us for HS devices. Now guess what, I
tested it in gadget mode and forgot about the little detail. Nobody seem
to have it noticed…
This patch adds the missing logic for hostmode so it is recognized in
host and device mode properly.
Fixes: 50aea6fca771 ("usb: musb: cpp
On am335x-evm with musb in host mode and using it as a wakeup source the
following happens once the CPU comes out of suspend to ram:
|PM: Wakeup source MPU_WAKE
|PM: noirq resume of devices complete after 15.453 msecs
|PM: early resume of devices complete after 2.222 msecs
|PM: resume of devices co
On 13.11.2014 17:45, Alan Stern wrote:
> On Thu, 13 Nov 2014, Mathias Nyman wrote:
>
>> Currently we queue a reset endpoint command from the .endpoint_reset
>> callback in host, this is far too late and should be moved
>> to when we get a STALL event.
>>
>> xhci needs to reset control endpoints
On Thu, 13 Nov 2014, Sebastian Andrzej Siewior wrote:
> On 11/07/2014 07:53 PM, Alan Stern wrote:
> >> If I put pm_runtime_get_sync() + put in musb_resume() then the problem
> >> is gone. I don't see ehci-hcd doing this in resume, in fact I don't see
> >> ehci doing pm_runtime_* at all. So for ehc
Hi,
On Mon, Nov 10, 2014 at 02:52:59PM -0600, Felipe Balbi wrote:
> Hi Greg,
>
> Here's another minor for v3.18-rc5. Please consider
> merging to your usb-linus branch.
>
> Tested with AM437x SK and testusb.
>
> cheers
>
> The following changes since commit 206c5f60a3d902bc4b56dab2de3e88de5eb0
>
> Latest version of the patch is now in my tree in a reset-rework-v2 branch,
> with fixes comments and removed The brach includes the other dorbell ringing
> patch as well.
> both are on top of 3.18-rc4.
>
..with fixed function comments. The branch incudes the other doorbell patch as
well.
This patch adds a UDC driver for Broadcom's USB3.0 Peripheral core named BDC.
BDC supports control traffic on ep0 and bulk/Int/Isoch traffic on all other
endpoints.
Signed-off-by: Ashwini Pahuja
---
Changes for v3:
- Incorporated feeback by Felipe on the v2
- Made stubs for debug functions
- r
Hi Felipe,
I Just sent you the V3 PATCH, I think it should be good for your next
submission to Greg for 3.18-rc6, I guess it's too late for 3.18-rc5. I
really appreciate all your feedback from v1/v2.
Thanks
Ashwini
On Wed, Nov 12, 2014 at 12:35 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Nov 12,
Hi,
(your mailing is un-wrapping emails, I always end up with pretty long
lines and have to rewrap them)
On Thu, Nov 13, 2014 at 07:58:28PM +0200, Mathias Nyman wrote:
> > The algorithm described in the DVB tuner bug is clearly wrong, since
> > it doesn't move the dequeue pointer until usb_clear_
On 11/04/2014 11:12 AM, Greg KH wrote:
On Tue, Nov 04, 2014 at 10:50:33AM -0600, Mark Langsdorf wrote:
#endif
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id usb_xhci_acpi_match[] = {
+ /* APM X-Gene USB Controller */
+ { "PNP0D10", },
+ { }
+};
+MODULE_DEVICE_TABLE
On Thu, Nov 13, 2014 at 12:31:28PM -0600, Felipe Balbi wrote:
> Hi,
>
> (your mailing is un-wrapping emails, I always end up with pretty long
> lines and have to rewrap them)
>
> On Thu, Nov 13, 2014 at 07:58:28PM +0200, Mathias Nyman wrote:
> > > The algorithm described in the DVB tuner bug is c
On Thu, Nov 13, 2014 at 12:36:09PM -0600, Mark Langsdorf wrote:
> On 11/04/2014 11:12 AM, Greg KH wrote:
> >On Tue, Nov 04, 2014 at 10:50:33AM -0600, Mark Langsdorf wrote:
> #endif
> >>
> >>+#ifdef CONFIG_ACPI
> >>+static const struct acpi_device_id usb_xhci_acpi_match[] = {
> >>+ /* APM X-Gene
On Thu, Nov 13, 2014 at 08:06:05AM -0800, Greg KH wrote:
> On Thu, Nov 13, 2014 at 04:59:32PM +0100, Milan Kocian wrote:
> > On Thu, Nov 13, 2014 at 07:44:20AM -0800, Greg KH wrote:
> > > On Thu, Nov 13, 2014 at 10:17:07AM +0100, Milan Kocian wrote:
> > > > Hi,
> > > >
> > > > after upgrade from 3
On Thu, Nov 13, 2014 at 12:05:17PM -0600, Felipe Balbi wrote:
> Hi,
>
> On Mon, Nov 10, 2014 at 02:52:59PM -0600, Felipe Balbi wrote:
> > Hi Greg,
> >
> > Here's another minor for v3.18-rc5. Please consider
> > merging to your usb-linus branch.
> >
> > Tested with AM437x SK and testusb.
> >
> >
Hi,
(please don't top-post)
On Thu, Nov 13, 2014 at 11:26:50AM -0700, Ashwini Pahuja wrote:
> Hi Felipe,
>
> I Just sent you the V3 PATCH, I think it should be good for your next
> submission to Greg for 3.18-rc6, I guess it's too late for 3.18-rc5. I
> really appreciate all your feedback from v
On Thu, Nov 13, 2014 at 11:11:59AM -0800, Greg KH wrote:
> On Thu, Nov 13, 2014 at 12:05:17PM -0600, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Nov 10, 2014 at 02:52:59PM -0600, Felipe Balbi wrote:
> > > Hi Greg,
> > >
> > > Here's another minor for v3.18-rc5. Please consider
> > > merging to yo
On Mon, Nov 10, 2014 at 02:52:59PM -0600, Felipe Balbi wrote:
> Hi Greg,
>
> Here's another minor for v3.18-rc5. Please consider
> merging to your usb-linus branch.
>
> Tested with AM437x SK and testusb.
>
> cheers
>
> The following changes since commit 206c5f60a3d902bc4b56dab2de3e88de5eb06108:
On Thu, Nov 13, 2014 at 01:13:44PM -0600, Felipe Balbi wrote:
> > I just got back from Korea, sorry for the delay, will get to this
> > today...
>
> no problem, let me add your G+ to my 'following' circle :-p
I was only there for 48 hours, not even long enough to post anything
there...
greg "I f
Hi,
On Thu, Nov 13, 2014 at 11:18:39AM -0800, Greg KH wrote:
> On Thu, Nov 13, 2014 at 01:13:44PM -0600, Felipe Balbi wrote:
> > > I just got back from Korea, sorry for the delay, will get to this
> > > today...
> >
> > no problem, let me add your G+ to my 'following' circle :-p
>
> I was only t
usbhid->intf->needs_remote_wakeup is set when a device is
opened, and is cleared when a device is closed.
When a usbhid device that does not support remote wake
( i.e. !device_can_wakeup() ) is closed, we fail out of
autosuspend_check() because the autosuspend check is called
before the flag is cl
On Thu, 13 Nov 2014, Benson Leung wrote:
> usbhid->intf->needs_remote_wakeup is set when a device is
> opened, and is cleared when a device is closed.
>
> When a usbhid device that does not support remote wake
> ( i.e. !device_can_wakeup() ) is closed, we fail out of
> autosuspend_check() because
On Thu, Nov 13, 2014 at 12:41 PM, Alan Stern wrote:
> usbhid_stop probably doesn't need it. And it should be possible to fix
> usbhid_close more easily just by interchanging the two lines:
>
> - usb_kill_urb(usbhid->urbin);
> usbhid->intf->needs_remot
> From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
> Sent: Thursday, November 13, 2014 5:40 AM
>
> On 2014-10-31 19:15, Paul Zimmerman wrote:
> >> From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
> >> Sent: Friday, October 31, 2014 1:04 AM
> >> To: linux-usb@vger.kernel.org; linux-
> From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
> Sent: Thursday, November 13, 2014 7:18 AM
>
> On 2014-10-31 19:46, Paul Zimmerman wrote:
> >> From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
> >> Sent: Friday, October 31, 2014 3:13 AM
> >>
> >> This patch adds mutex, which pro
On Thu, 13 Nov 2014, Benson Leung wrote:
> On Thu, Nov 13, 2014 at 12:41 PM, Alan Stern
> wrote:
> > usbhid_stop probably doesn't need it. And it should be possible to fix
> > usbhid_close more easily just by interchanging the two lines:
> >
> > - usb_kill_urb(usbhid->urbi
From: David Miller
Date: Wed, 12 Nov 2014 22:31:46 -0500 (EST)
> From: Hayes Wang
> Date: Thu, 13 Nov 2014 02:31:14 +
>
>> My last method which I mentioned yesterday is similar to
>> this one. The difference is that I would re-use the rx
>> buffers, so I have to add them to the list for re-
usbhid->intf->needs_remote_wakeup is set when a device is
opened, and is cleared when a device is closed.
When a usbhid device that does not support remote wake
( i.e. !device_can_wakeup() ) is closed, we fail out of
autosuspend_check() because the autosuspend check is called
before the flag is cl
On Thu, Nov 13, 2014 at 1:18 PM, Alan Stern wrote:
> If you interchange the two lines then the flag _will_ be cleared before
> usb_kill_urb() and autosuspend_check() can run. This means your patch
> description is bogus.
Gotcha. v2 posted. Thanks for the direction.
--
Benson Leung
Software Eng
From: Alan Stern
From: Alan Stern
Remove special-purpose octeon drivers and instead use ehci-platform
and ohci-platform as suggested with
http://marc.info/?l=linux-mips&m=140139694721623&w=2
[andreas.herrmann:
fixed compile error]
Cc: David Daney
Cc: Alex Smith
Cc: Alan Stern
Signe
Instead rely on device tree information for ehci and ohci.
This was suggested with
http://www.linux-mips.org/archives/linux-mips/2014-05/msg00307.html
"The device tree will *always* have correct ehci/ohci clock
configuration, so use it. This allows us to remove a big chunk of
platform conf
Hi Alan,
With following patches I want to base octeon ehci/ohci device
configuration on device tree information.
I picked up patches that were submitted in May. See
http://marc.info/?l=linux-usb&m=140135823325811&w=2
and http://marc.info/?l=linux-mips&m=140139694721623&w=2
Patch #1 is your "unte
On Thu, 13 Nov 2014, Benson Leung wrote:
> On Thu, Nov 13, 2014 at 1:18 PM, Alan Stern wrote:
> > If you interchange the two lines then the flag _will_ be cleared before
> > usb_kill_urb() and autosuspend_check() can run. This means your patch
> > description is bogus.
>
> Gotcha. v2 posted. Th
On Thu, 13 Nov 2014, Andreas Herrmann wrote:
> Hi Alan,
>
> With following patches I want to base octeon ehci/ohci device
> configuration on device tree information.
>
> I picked up patches that were submitted in May. See
> http://marc.info/?l=linux-usb&m=140135823325811&w=2
> and http://marc.in
Hi Alan,
On Thu, Nov 13, 2014 at 2:11 PM, Alan Stern wrote:
> Wait a minute -- in your previous email you said this approach didn't
> work. So does it work or doesn't it?
Sorry for the confusion. The approach *does* work.
That was actually my original idea to fix the problem, but I saw other
p
ehci-octeon driver used a 64-bit dma_mask. With removal of ehci-octeon
and usage of ehci-platform ehci dma_mask is now limited to 32 bits
(coerced in ehci_platform_probe).
Provide a flag in ehci platform data to allow use of 64 bits for
dma_mask.
Cc: David Daney
Cc: Alex Smith
Cc: Alan Stern
S
Just want to ping this again to see if there is any comments, thanks.
On Tue, Nov 4, 2014 at 11:06 AM, Feng Kan wrote:
> Use dma_addr_t to support 64-bit plaforms, which access beyond the default
> 32 bit address range.
>
> Signed-off-by: Bao Truong
> Signed-off-by: Feng Kan
> ---
> Changes:
>
Add controller reset API, it may be used for host/otg driver in future.
Signed-off-by: Peter Chen
---
Changes for v2:
- Add return value check for controller reset at hw_device_reset
drivers/usb/chipidea/core.c | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(
The core driver has already done it, besides, move set driver data
operation just after ci has allocated successfully in case some
code (like ci_role_start) want to access this driver data.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/core.c | 2 +-
drivers/usb/chipidea/host.c | 1 -
2 fil
There's no such thing as "list_struct".
Signed-off-by: Andrey Utkin
---
drivers/gpu/drm/radeon/mkregtable.c | 24
drivers/media/pci/cx18/cx18-driver.h | 2 +-
include/linux/list.h | 34 +-
include/linux/plist.h
The hw_device_reset is dedicated to be used at device mode initializaiton,
so delete the parameter 'mode'. For host driver, the ehci driver will
all things.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/ci.h | 2 +-
drivers/usb/chipidea/core.c| 8
drivers/usb/chipidea/otg_
On Fri, 14 Nov 2014 05:09:55 +0400
Andrey Utkin wrote:
> There's no such thing as "list_struct".
I guess there isn't.
>
> Signed-off-by: Andrey Utkin
Acked-by: Steven Rostedt
-- Steve
> ---
> drivers/gpu/drm/radeon/mkregtable.c | 24
> drivers/media/pci/cx18/cx1
On Thu, Oct 30, 2014 at 12:36:42PM +0100, Antoine Tenart wrote:
> Add a function into the chipidea core to help drivers setup the internal
> ci_hdrc_platform_data structure. This helps not duplicating common code.
>
> The ci_hdrc_get_platdata function only setup non filled members of the
> structu
Hi Mathias,
This patch series has been acked by Alan Stern. There seems no further
comments from others. Can you please pull in it?
Thanks,
-baolu
On 2014年11月06日 10:50, Lu Baolu wrote:
This serie of patch reworks commit ff8cbf250b448aac35589f6075082c3fcad8a8fe.
This has been discussed at htt
Hi,
On Fri, Nov 14, 2014 at 08:03:15AM +0800, Peter Chen wrote:
> Add controller reset API, it may be used for host/otg driver in future.
you need a better commit log here. How would it be used ? when ? And,
more importantly, why ?
Why would we need to reset the IP outside of ->probe() ?
I don'
On Fri, Nov 14, 2014 at 08:03:16AM +0800, Peter Chen wrote:
> The hw_device_reset is dedicated to be used at device mode initializaiton,
> so delete the parameter 'mode'. For host driver, the ehci driver will
> all things.
this last sentence doesn't parse very well.
> Signed-off-by: Peter Chen
>
2014-11-13 13:36 GMT-08:00 Andreas Herrmann
:
> ehci-octeon driver used a 64-bit dma_mask. With removal of ehci-octeon
> and usage of ehci-platform ehci dma_mask is now limited to 32 bits
> (coerced in ehci_platform_probe).
>
> Provide a flag in ehci platform data to allow use of 64 bits for
> dma_
> I will figure out how to make dwc2 detect the device connect after auto
> suspend,
> or disable the auto suspend feature for the dwc2 hcd.
I think auto-suspend of the root hub device (which is what calls
bus_suspend, but is not the host controller device itself) is expected
to always happen and
David Miller [mailto:da...@davemloft.net]
> Sent: Friday, November 14, 2014 5:23 AM
[...]
> What if even the first r8152_submit_rx() fails? What ever will cause
> any of these retries to trigger at all?
According to the patch #1 "adjust r8152_submit_rx", the
r8152_submit_rx() would add the rx to
x86_32 kernel config
This is associated with [Bug 88131]
The bootlog is already in Bug 88131.
Kernel enabled PAE and HIGHMEM64G.
PCI bar0 base address is above 4G, xhci driver failed to work.
Yinghai Lu has already made some changes, please check it on bug 88131.
--
To unsubscribe from this list:
66 matches
Mail list logo
