On Wed, Nov 23, 2016 at 09:35:36AM +0100, Andrzej Pietrasiewicz wrote:
> The ->drop_item() is indeed a void function, the ->drop_link() is
> actually not. This, together with the fact that the value of ->drop_link()
> is silently ignored suggests, that it is the ->drop_link() return
> type that sho
The EHCI specification states the following in the SUSP bit description:
In the Suspend state, the port is sensitive to resume detection.
Note that the bit status does not change until the port is suspended and
that there may be a delay in suspending a port if there is a transaction
currently in pr
Hi,
Mathias Nyman writes:
> On 24.11.2016 15:33, Felipe Balbi wrote:
>> Instead of always defaulting to a 256-entry array,
>> we can dynamically allocate devs based on what HW
>> tells us it supports.
>>
>> Note that we can't, yet, purge MAX_HC_SLOTS
>> completely because of struct
>> xhci_devic
On Thu, 2016-11-24 at 11:57 +0200, Heikki Krogerus wrote:
> On Wed, Nov 23, 2016 at 09:12:04PM -0800, Guenter Roeck wrote:
> > In our implementation, the default preferred role is determined by the
> > low level driver (as, in my understanding, is suggested by the standard).
> > This means that th
On Monday, November 28, 2016 11:51:37 AM CET Geert Uytterhoeven wrote:
> On Tue, Nov 22, 2016 at 3:30 PM, Arnd Bergmann wrote:
> > Building without CONFIG_PM causes a harmless warning:
> >
> > drivers/usb/musb/musb_core.c:2041:12: error: ‘musb_run_resume_work’ defined
> > but not used [-Werror=un
On Tue, Nov 22, 2016 at 3:30 PM, Arnd Bergmann wrote:
> Building without CONFIG_PM causes a harmless warning:
>
> drivers/usb/musb/musb_core.c:2041:12: error: ‘musb_run_resume_work’ defined
> but not used [-Werror=unused-function]
>
> Removing the #ifdef around the PM code and instead marking the
This is a cleanup patch only, no functional changes. The idea is just to
make sure for loops look the same all over the driver.
Signed-off-by: Felipe Balbi
---
drivers/usb/host/xhci-dbg.c | 20 ++--
drivers/usb/host/xhci-mem.c | 10 +-
drivers/usb/host/xhci.c | 14 +++
Stop Endpoint command can come at any point and we
have no control of that. We should make sure to
handle COMP_STOP on SETUP phase as well, otherwise
urb->actual_lenght might be set to negative values
in some occasions such as below:
urb->length = 4;
build_control_transfer_td_for(urb, ep);
When calling xhci_dbg_regs() we actually _do_ want to know XHCI's
version. This might help figure out why certain problems only happen
in some cases.
Signed-off-by: Felipe Balbi
---
drivers/usb/host/xhci-dbg.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/dri
Hi Mathias,
These four patches help with two minor details in XHCI and also
implement a couple cleanups.
Patch 1 reduces the amount of memory used by our virt_device array by
discovering from the HW how many slots we can support.
Patch 2 makes COMP_STOP work when a Stop Endpoint command is issue
On 28.11.2016 09:24, Greg KH wrote:
On Mon, Nov 28, 2016 at 09:53:52AM +0800,
wan.ahmad.zainie.wan.moha...@intel.com wrote:
From: Wan Ahmad Zainie
Intel Apollo Lake also requires XHCI_PME_STUCK_QUIRK.
Adding its PCI ID to quirk.
Signed-off-by: Wan Ahmad Zainie
---
drivers/usb/host/xhci-pc
Instead of always defaulting to a 256-entry array,
we can dynamically allocate devs based on what HW
tells us it supports.
Note that we can't, yet, purge MAX_HC_SLOTS
completely because of struct
xhci_device_context_array reliance on it.
Signed-off-by: Felipe Balbi
---
drivers/usb/host/xhci-hub
Hi Arnd,
On Mon, Nov 28, 2016 at 11:54 AM, Arnd Bergmann wrote:
> On Monday, November 28, 2016 11:51:37 AM CET Geert Uytterhoeven wrote:
>> On Tue, Nov 22, 2016 at 3:30 PM, Arnd Bergmann wrote:
>> > Building without CONFIG_PM causes a harmless warning:
>> >
>> > drivers/usb/musb/musb_core.c:2041
2016-11-26 22:17 GMT+01:00 Bjørn Mork :
> Bjørn Mork writes:
>
>> Finally, I found my modems (or at least a number of them) again today.
>> But I'm sorry to say, that the troublesome Huawei E3372h-153 is still
>> giving us a hard time. It does not work with your patch. The symptom is
>> the same
On Thu, 24 Nov 2016 19:42:04 +0900, OGAWA Hirofumi
wrote:
> If you need my help for something, let me know either publicly or
> privately what way you want.
So, I fail a lot. And in ways totally unrelated to this patchset.
My goal is to get a kernel image built with a trivial platform patch
for
Documentation/filesystems/configfs/configfs.txt says:
"When unlink(2) is called on the symbolic link, the source item is
notified via the ->drop_link() method. Like the ->drop_item() method,
this is a void function and cannot return failure."
The ->drop_item() is indeed a void function, the ->dr
Vincent Pelletier writes:
> I fail to build 4.8.9 vanilla:
> Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not
> supported by compiler
Probably, debian's gcc default-pie issue. Below patch may fix it.
> I succeed to build 4.9-rc9 vanilla (starting from the same .config as
>
COMP_SUCCESS should only be asserted on a *true* sucessful transfer. Any
other cases are bogus and we should aim to catch them. One easy way to
get bug reports is to trigger a WARN_ONCE() on such cases.
Signed-off-by: Felipe Balbi
---
drivers/usb/host/xhci-ring.c | 28 +++
Cleanup only. This patch is a mechaninal rename to make sure our macros
for TRB completion codes match what the specification uses to refer to
such errors. The idea behind this is that it makes it far easier to grep
the specification and match it with implementation.
Signed-off-by: Felipe Balbi
-
Hi Mathias,
these two cleanups are proposals for now, hence RFC on subject.
Let me know what you think of the idea.
Felipe Balbi (2):
usb: host: xhci: rename completion codes to match spec
usb: host: xhci: WARN on unexpected COMP_SUCCESS
drivers/usb/host/xhci-hub.c | 3 +-
drivers/usb/ho
OGAWA Hirofumi writes:
>> I succeed to build 4.9-rc9 vanilla (starting from the same .config as
>> with 4.8.9) but it then fails to load produced modules. During the
>> build I have the following warnings:
>> WARNING: "_copy_from_user" [drivers/hid/hid.ko] has no CRC!
>
> Looks like, CONFIG_MOD
On Mon, Nov 28, 2016 at 11:19:32AM +0100, Oliver Neukum wrote:
> On Thu, 2016-11-24 at 11:57 +0200, Heikki Krogerus wrote:
> > On Wed, Nov 23, 2016 at 09:12:04PM -0800, Guenter Roeck wrote:
>
> > > In our implementation, the default preferred role is determined by the
> > > low level driver (as, i
On Mon, 28 Nov 2016 21:57:11 +0900, OGAWA Hirofumi
wrote:
> OGAWA Hirofumi writes:
> Hm, this issue might be same with 4efca4ed05cbdfd13ec3e8cb623fb77d6e4ab187.
> But it was already including into 4.9-rc7.
My bad, it was rc6, not rc9.
> can you try 4.9-rc7 if older one?
Updated & rebased, buil
On 28.11.2016 09:41, Baolin Wang wrote:
On 28 November 2016 at 15:21, Greg KH wrote:
On Mon, Nov 28, 2016 at 02:29:25PM +0800, Baolin Wang wrote:
Hi Mathias,
On 24 November 2016 at 19:16, Baolin Wang wrote:
Since these 'return' statements are not generally useful in void
function, remove th
On Mon, 28 Nov 2016, Changming Huang wrote:
> The EHCI specification states the following in the SUSP bit description:
> In the Suspend state, the port is sensitive to resume detection.
> Note that the bit status does not change until the port is suspended and
> that there may be a delay in suspen
There is no suspend / resume support for da8xx.
Add the PM methods to da8xx glue.
In addition, introduce a new quirk to not clear the devctl register.
Clearing devctl will power off vbus on da8xx platform
(when it is host mode) and then devices will be disconnected on resume.
The quirk name (MUSB_
On da8xx, VBUS is not maintained during suspend when musb is in host mode.
On resume, all the connected devices will be disconnected and then will
be enumerated again.
This happens because MUSB_DEVCTL is cleared during suspend.
Add a quirk to preserve MUSB_DEVCTL during a suspend.
Signed-off-by: A
On da8xx, VBUS is not maintained during suspend when musb is in host mode.
On resume, all the connected devices will be disconnected and then will
be enumerated again.
This happens because MUSB_DEVCTL is cleared during suspend.
MUSB_DEVCTL is clear twice: once by da8xx_musb_disable()
and once musb_
Implement PM methods specifics for da8xx glue.
The only thing to do is to power off the phy.
As the registers are in retention during suspend,
there is no need to save them.
Signed-off-by: Alexandre Bailon
---
drivers/usb/musb/da8xx.c | 29 +
1 file changed, 29 insert
Vincent Pelletier writes:
>> I couldn't reproduce that "no CRC"
>> issue with debian kernel's .config
>
> I did not diff recently my .config with debian's. I think I based it on
> Debian's 4.2 and then let it evolve "naturally" following vanilla.
> I checked all diffs against Debian's 4.8 and red
On Mon, Nov 28, 2016 at 04:23:23PM +0200, Heikki Krogerus wrote:
> On Mon, Nov 28, 2016 at 11:19:32AM +0100, Oliver Neukum wrote:
> > On Thu, 2016-11-24 at 11:57 +0200, Heikki Krogerus wrote:
> > > On Wed, Nov 23, 2016 at 09:12:04PM -0800, Guenter Roeck wrote:
> >
> > > > In our implementation, th
On Wed, Nov 23, 2016 at 02:24:27PM +0200, Mathias Nyman wrote:
> the tt_info provided by a HS hub might be in use to by a child device
> Make sure we free the devices in the correct order.
>
> This is needed in special cases such as when xhci controller is
> reset when resuming from hibernate, and
>From 1ea511f4fd3ed082beee53130625570a6b6b8d82 Mon Sep 17 00:00:00 2001
Message-Id:
<1ea511f4fd3ed082beee53130625570a6b6b8d82.1480378291.git.johny...@synopsys.com>
Subject: [PATCH] usb: dwc3: pci: Add "linux,sysdev_is_parent" property
To: Felipe Balbi , linux-usb@vger.kernel.org
Cc: John Youn , Sr
Calling platform_device_add_properties() replaces existing properties so
the "linux,sysdev_is_parent" property doesn't get set. Add this property
to each platform.
Fixes: d64ff406e51e ("usb: dwc3: use bus->sysdev for DMA configuration")
Signed-off-by: John Youn
---
Hi Felipe,
Can you queue for
On 11/24/2016 1:15 PM, Stefan Wahren wrote:
> Hi John,
>
>> John Youn hat am 18. Oktober 2016 um 02:36
>> geschrieben:
>>
>>
>> This reverts commit aa381a7259c3 ("usb: dwc2: gadget: fix TX FIFO size
>> and address initialization").
>>
>> The original commit removed the FIFO size programming per e
Hi Ralph,
On 11/21/2016 09:40 AM, Ralph Sennhauser wrote:
I tried your new usbport trigger in Linux 4.9 with little luck as can be seen in
the following output of the serial console.
I'm really happy my trigger got some attention. I'm sorry it crashes for you,
I never experienced any crash so
On 28 November 2016 at 23:14, Mathias Nyman
wrote:
> On 28.11.2016 09:41, Baolin Wang wrote:
>>
>> On 28 November 2016 at 15:21, Greg KH wrote:
>>>
>>> On Mon, Nov 28, 2016 at 02:29:25PM +0800, Baolin Wang wrote:
Hi Mathias,
On 24 November 2016 at 19:16, Baolin Wang
wrot
Hi Johan,
Johan Hovold 於 2016/11/24 下午 11:04 寫道:
On Mon, Nov 14, 2016 at 01:37:59PM +0800, Ji-Ze Hong (Peter Hong) wrote:
This driver is for Fintek F81532/F81534 USB to Serial Ports IC.
+ }
+
+ if (size_bulk_out != F81534_WRITE_BUFFER_SIZE ||
+ size_bulk_in
Thanks a lot, Alan.
That is my fault, will fix it and send one new version.
Best Regards
Jerry Huang
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Monday, November 28, 2016 11:58 PM
To: Jerry Huang
Cc: gre...@linuxfoundation.org; Ramneek Mehresh ;
julia.
On 11/22/2016 12:51 PM, Christian Lamparter wrote:
> On Monday, November 21, 2016 7:32:30 PM CET John Youn wrote:
>> On 11/21/2016 1:10 PM, Christian Lamparter wrote:
>>> On Monday, November 21, 2016 12:16:31 PM CET John Youn wrote:
On 11/18/2016 12:18 PM, Christian Lamparter wrote:
> On F
Hi,
On Wed, Nov 16, 2016 at 10:42:03AM +0300, Max Uvarov wrote:
> Some times dma transfer to usb endpoint fails:
>
> [ 78.378283] musb-hdrc musb-hdrc.1.auto: Start TX10 dma
> [ 78.410763] musb-hdrc musb-hdrc.1.auto: OUT/TX10 end, csr 3400, dma
> [ 78.410896] musb-hdrc musb-hdrc.1.auto: complete d
On 28 November 2016 at 19:00, Felipe Balbi wrote:
> Instead of always defaulting to a 256-entry array,
> we can dynamically allocate devs based on what HW
> tells us it supports.
>
> Note that we can't, yet, purge MAX_HC_SLOTS
> completely because of struct
> xhci_device_context_array reliance on
The EHCI specification states the following in the SUSP bit description:
In the Suspend state, the port is sensitive to resume detection.
Note that the bit status does not change until the port is suspended and
that there may be a delay in suspending a port if there is a transaction
currently in pr
On Mon, 2016-11-28 at 12:11 -0800, Guenter Roeck wrote:
> On Mon, Nov 28, 2016 at 04:23:23PM +0200, Heikki Krogerus wrote:
> > On Mon, Nov 28, 2016 at 11:19:32AM +0100, Oliver Neukum wrote:
> The Type-C specification states (in 4.5.2.2.11):
>
> "Note: if both Try.SRC and Try.SNK mechanisms are im
44 matches
Mail list logo
