Since these 'return' statements are not generally useful in void function,
remove them.
Signed-off-by: Baolin Wang
---
drivers/usb/host/xhci-hub.c |2 --
drivers/usb/host/xhci-mem.c |1 -
drivers/usb/host/xhci-ring.c |4
drivers/usb/host/xhci.c |3 ---
4 files changed
2016-11-23 19:38 GMT+01:00 Bjørn Mork :
> Daniele Palmas writes:
>> 2016-11-23 15:49 GMT+01:00 Bjørn Mork :
>>> Daniele Palmas writes:
2016-11-21 10:49 GMT+01:00 Bjørn Mork :
> Daniele Palmas writes:
>
>> it turned out that resetting the interface in cdc_ncm_init after
>> ge
Hi,
Mathias Nyman writes:
> 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 all virt_devices are freed.
>
> Al
Hello.
On 11/24/2016 11:13 AM, Baolin Wang wrote:
Since these 'return' statements are not generally useful in void function,
remove them.
Signed-off-by: Baolin Wang
[...]
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 48a26d378..d6f59a3 100644
--- a/drivers/usb
As per USB specification, in the Suspend state, the status bit does
not change until the port is suspended. However, there may be a delay
in suspending a port if there is a transaction currently in progress
on the bus.
In the USBDR controller, the PORTSCx[SUSP] bit changes immediately when
the app
On 24.11.2016 11:02, Felipe Balbi wrote:
Hi,
Mathias Nyman writes:
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
On Wed, Nov 23, 2016 at 09:12:04PM -0800, Guenter Roeck wrote:
> Hello Heikki,
>
> On 11/22/2016 06:11 AM, Heikki Krogerus wrote:
> [ ... ]
> > +
> > +struct typec_port *typec_register_port(struct device *dev,
> > + const struct typec_capability *cap)
> > +{
> > +
Vincent Pelletier writes:
> On Wed, 23 Nov 2016 22:48:35 +0900, OGAWA Hirofumi
> wrote:
>> ping?
>
> FWIW, I intend to run this patch on the hardware which caused the
> issue (thanks Mathias for the CC !).
>
> So far, in the very short attempt I made, I failed to even build the
> kernel (some st
The da8xx ohci controller is not working after suspend and resume.
This is because only the root hub is being resumed.
Balance the ohci_suspend of the suspend path with an ohci_resume
in the resume path so that we resume the entire controller, and not
just the root hub.
Also, while we are here,
Hi,
On 24 November 2016 at 17:30, Sergei Shtylyov
wrote:
> Hello.
>
> On 11/24/2016 11:13 AM, Baolin Wang wrote:
>
>> Since these 'return' statements are not generally useful in void function,
>> remove them.
>>
>> Signed-off-by: Baolin Wang
>
> [...]
>>
>> diff --git a/drivers/usb/host/xhci-mem
Hi,
Mathias Nyman writes:
>>> + /* are any devices using this tt_info? */
>>> + for (i = 1; i < HCS_MAX_SLOTS(xhci->hcs_params1); i++) {
>>
>> off-by-one here ? Why is i starting from 1?
>>
>>> + vdev = xhci->devs[i];
>
> slit_id 0 is
Since these 'return' statements are not generally useful in void
function, remove them. Also remove one unuseful 'break' statement
in xhci_setup_addressable_virt_dev() function.
Signed-off-by: Baolin Wang
---
Changes since v1:
- Add description of removing 'break' statement in commitlog.
---
dr
>From: Changming Huang [mailto:jerry.hu...@nxp.com]
>As per USB specification, in the Suspend state, the status bit does not change
>until
>the port is suspended. However, there may be a delay in suspending a port if
>there
>is a transaction currently in progress on the bus.
>
>In the USBDR contr
On 24.11.2016 13:03, Felipe Balbi wrote:
Hi,
Mathias Nyman writes:
+ /* are any devices using this tt_info? */
+ for (i = 1; i < HCS_MAX_SLOTS(xhci->hcs_params1); i++) {
off-by-one here ? Why is i starting from 1?
+
The USB Type-C class is meant to provide unified interface to the
userspace to present the USB Type-C ports in a system.
Changes since v12:
- Added prefer_role member to typec_capability structure as requested by Guenter
Changes since v11:
- The port drivers are responsible of removing the altern
The purpose of USB Type-C connector class is to provide
unified interface for the user space to get the status and
basic information about USB Type-C connectors on a system,
control over data role swapping, and when the port supports
USB Power Delivery, also control over power role swapping
and Alt
Make a simple helper for matching strings with sysfs
attribute files. In most parts the same as match_string(),
except sysfs_match_string() uses sysfs_streq() instead of
strcmp() for matching. This is more convenient when used
with sysfs attributes.
Signed-off-by: Heikki Krogerus
Reviewed-by: Gue
This adds driver for the USB Type-C PHY on Intel WhiskeyCove
PMIC which is available on some of the Intel Broxton SoC
based platforms.
Signed-off-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
drivers/usb/typec/Kconfig | 14 ++
drivers/usb/typec/Makefile | 1 +
drivers/usb/typ
On 16-11-23 02:29 PM, Mark Lord wrote:
On 16-11-23 10:12 AM, Hayes Wang wrote:
Mark Lord [ml...@pobox.com]
[...]
What does this code do:
static void r8153_set_rx_early_size(struct r8152 *tp)
{
u32 mtu = tp->netdev->mtu;
u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HL
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Baolin-Wang/usb-host-plat-Enable-xhci-plat-runtime-PM/20161124-012323
> config: x86_64-randconfig-x008-201647 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
&
Mark Lord [mailto:ml...@pobox.com]
> Sent: Wednesday, November 23, 2016 9:41 PM
[...]
> >static void r8153_set_rx_early_size(struct r8152 *tp)
> >{
> >u32 mtu = tp->netdev->mtu;
> >u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4;
> >
> >ocp_write_word(tp,
On 16.11.2016 07:01, OGAWA Hirofumi wrote:
Now, xhci_abort_cmd_ring() is sleepable. So no reason to use busy loop
anymore.
- Convert udelay(1000) => msleep(1).
Sounds good.
- Add xhci_handshake_sleep(), and use it.
This seems a but overkill, I'd rather don't have xhci_handshake(),
xhci_ha
Mark Lord [mailto:ml...@pobox.com]
> Sent: Thursday, November 24, 2016 8:31 PM
[...]
> Nope. Guard zones did not fix it, so it's probably not a prefetch issue.
> Oddly, adding a couple of memory barriers to specific places in the driver
> does help, A LOT. Still not 100%, but it did pass 1800 reb
Hi Mathias,
these two patches help with two minor details in XHCI.
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 issued
while we're still in SETUP stage. No
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
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);
Mathias Nyman writes:
>> - Add xhci_handshake_sleep(), and use it.
>
> This seems a but overkill, I'd rather don't have xhci_handshake(),
> xhci_handshake_sleep() and __xhci_handshake() to maintain.
I agree about it. However, on other hand, I thought about the
possibility/effort to decreasing us
The following changes since commit a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6:
Linux 4.9-rc5 (2016-11-13 10:32:32 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.9-rc7
for you to fetch changes up to c0da038d7afed2892346fd
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.
>
> F81532 spec:
> https://drive.google.com/file/d/0B8vRwwYO7aMFOTRRMmhWQVNvajQ/view?usp=
> sharing
>
> F81534 spec:
> https://drive.google.com/file/d/0B8vRww
On 16-11-24 08:26 AM, Hayes Wang wrote:
..
Besides, it doesn't seem to occur for all platforms. I have
tested the iperf more than 26 hours, and it still works fine.
I think I would get the same result on x86 or x86_64 platform.
..
x86 has near fully-coherent memory, so it is the "easy" platform
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_device_context_array reliance on it.
Signed-off-by: F
On 24.11.2016 15:33, Felipe Balbi wrote:
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;
From: Hayes Wang
Date: Thu, 24 Nov 2016 13:26:55 +
> I don't think the garbage results from our driver or device.
This is my impression with what has been presented so far as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@v
From: Mark Lord
Date: Thu, 24 Nov 2016 07:31:17 -0500
> Any way we look at it though, the chip/driver are simply unreliable,
> and relying upon hardware checksums (which fail due to the driver
> looking at garbage rather than the checksum bits) leads to data
> corruption.
If the cpu/DMA implemen
On 16-11-24 11:21 AM, David Miller wrote:
From: Hayes Wang
Date: Thu, 24 Nov 2016 13:26:55 +
I don't think the garbage results from our driver or device.
This is my impression with what has been presented so far as well.
It's not garbage.
The latest run with the debug code I posted her
On Thu, 24 Nov 2016, Sriram Dash wrote:
> >From: Changming Huang [mailto:jerry.hu...@nxp.com]
> >As per USB specification, in the Suspend state, the status bit does not
> >change until
> >the port is suspended. However, there may be a delay in suspending a port if
> >there
> >is a transaction cu
On 16-11-24 11:43 AM, Mark Lord wrote:
..
But how does this ASCII data end up at offset zero of the rx buffer??
Not possible -- this isn't even stale data, because only an rx_desc could
be at that offset in that buffer.
Answering my own question here, I suspect it ends up there as a result
of o
From: Mark Lord
Date: Thu, 24 Nov 2016 11:43:53 -0500
> So even if this were a platform memory coherency issue, one should
> still never see ASCII data at the beginning of an rx buffer.
I'm not so convinced, since this is the kind of random corruption one
would expect to see when dealing with vi
From: Mark Lord
Date: Thu, 24 Nov 2016 12:00:15 -0500
> It seems I am being overly helpful here.
Either you want to cry or you want to keep helping us track down
this problem. It is your choice, and your choice alone.
Please do not pretend otherwise, everyone else in this thread is
operating w
Hello,
currently I am trying to get the USB controllers on the Amlogic Meson
GXL SoCs working: there is one dwc2 and dwc3 controller each.
The SoC itself provides 3x USB2 PHYs and 1x USB3 PHY.
I wrote drivers for both of them based on the vendor kernel, see [0]
The PHY registers of the USB2 PHYs
On 16-11-24 12:11 PM, David Miller wrote:
> From: Mark Lord
> Date: Thu, 24 Nov 2016 11:43:53 -0500
>
>> So even if this were a platform memory coherency issue, one should
>> still never see ASCII data at the beginning of an rx buffer.
>
> I'm not so convinced, since this is the kind of random c
On Thu, Nov 24, 2016 at 11:43:53AM -0500, Mark Lord wrote:
> On 16-11-24 11:21 AM, David Miller wrote:
> > From: Hayes Wang
> > Date: Thu, 24 Nov 2016 13:26:55 +
> >
> > > I don't think the garbage results from our driver or device.
> > This is my impression with what has been presented so fa
On 16-11-24 01:34 PM, Mark Lord wrote:
>From tracing through the powerpc arch code, this is the buffer that
> is being directly DMA'd into. And the USB layer does an invalidate_dcache
> on that entire buffer before initiating the DMA (confirmed via printk).
Slight correction: the invalidate_dcac
On 16-11-24 01:42 PM, Greg KH wrote:
>
> Have you tried using usbmon?
This system is running rootfs over NFS, so usbmon
isn't realistically going to be usable in that scenario
without a lot of reconfiguration of the setup (which in itself
might obscure the original problem).
There is a hardware U
On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote:
> One thought: bulk data streams are byte streams, not packets.
> Scheduling on the USB bus can break up larger transfers across
> multiple in-kernel buffers. A "real" URB buffer on USB2 is max 512 bytes.
> The driver is providing 16384-b
On 16-11-24 02:00 PM, Greg KH wrote:
> On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote:
>> One thought: bulk data streams are byte streams, not packets.
>> Scheduling on the USB bus can break up larger transfers across
>> multiple in-kernel buffers. A "real" URB buffer on USB2 is max 51
On Thu, Nov 24, 2016 at 02:10:36PM -0500, Mark Lord wrote:
> On 16-11-24 02:00 PM, Greg KH wrote:
> > On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote:
> >> One thought: bulk data streams are byte streams, not packets.
> >> Scheduling on the USB bus can break up larger transfers across
>
On 11/23/2016 04:24 AM, 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 all virt_devices are free
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 endpoint. The
> DPTXFSIZn register is also used for DI
Mark Lord :
[...]
> >From tracing through the powerpc arch code, this is the buffer that
> is being directly DMA'd into. And the USB layer does an invalidate_dcache
> on that entire buffer before initiating the DMA (confirmed via printk).
>
> The driver itself NEVER writes anything to that buffe
On 16-11-24 07:27 PM, Francois Romieu wrote:
>
> Through aliasing the URB was given a page that contains said (previously)
> received file. The ethernet chip/usb host does not write anything in it.
I don't see how that could be possible. Please elaborate.
The URB buffers are statically allocated
The EHCI specification states the following in the SUSP bit description:
In the Suspend state, the port is senstive to resume detection.
Note that the bit status does not change untile the port is suspended and
that there may be a delay in susupending a port if there is a transaction
currently in p
Mark Lord [mailto:ml...@pobox.com]
> Sent: Thursday, November 24, 2016 11:25 PM
[...]
> x86 has near fully-coherent memory, so it is the "easy" platform
> to get things working on. But Linux supports a very diverse number
> of platforms, with varying degrees of cache/memory coherency,
> and it can
Mark Lord [mailto:ml...@pobox.com]
> Sent: Friday, November 25, 2016 12:44 AM
[...]
> The bad data in this case is ASCII:
>
> "SRC=m3400:/ TARGET=/m340"
>
> This data is what is seen in /run/mount/utab, a file that is read/written
> over NFS on
> each boot.
>
> "SRC=m3400:/ TA
> Mark Lord [mailto:ml...@pobox.com]
> > Sent: Friday, November 25, 2016 12:44 AM
> [...]
> > The bad data in this case is ASCII:
> >
> > "SRC=m3400:/ TARGET=/m340"
> >
> > This data is what is seen in /run/mount/utab, a file that is read/written
> > over NFS
> on
> > each boot.
> >
> >
55 matches
Mail list logo
