Hi,
Alexey Khoroshilov writes:
> Hello,
>
> usb_add_gadget_udc_release() gets release() argument that allows to
> release user resources.
>
> As far as I can see, the release() is called on error paths
> of usb_add_gadget_udc_release() as a result of
> put_device(&gadget->dev);
> except for the
Hi,
Rail Shafigulin writes:
>> Rail Shafigulin writes:
>>> Let me apologize for emailing directly to the list as I'm not one of
>>> the developers and just starting out with USB and UVC. After searching
>>
>> the list is open to anybody and we welcome newcomers :-)
>>
>>> online for about a wee
Some time ago Thierry Reding sent out patches that enabled UDC on NVIDIA
Tegra, unfortunately they haven't got enough traction to get into the
kernel. I've rebased those patches and added a fix for the Ethernet USB
Gadget on Tegra20, Marc Dietrich tested UDC driver on AC100 (Tegra20),
Nicolas Chauv
NVIDIA Tegra20 UDC can't cope with unaligned DMA and require a USB gadget
quirk that avoids SKB buffer alignment to be set in order to make Ethernet
Gadget working. Later Tegra generations do not require that quirk. Let's
add a new platform data flag that allows to enable USB gadget quirk for
platf
From: Thierry Reding
Override the compatible string of the first USB controller to enable
device mode.
Signed-off-by: Thierry Reding
---
arch/arm/boot/dts/tegra114-dalmore.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
b/arch/arm/boo
Override the compatible string of the first USB controller to enable
device mode.
Signed-off-by: Dmitry Osipenko
Tested-by: Marc Dietrich
Acked-by: Stephen Warren
---
arch/arm/boot/dts/tegra20-paz00.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
Since NVIDIA Tegra is supported now by the ChipIdea USB driver, let's
enable this driver in tegra_defconfig.
Signed-off-by: Dmitry Osipenko
---
arch/arm/configs/tegra_defconfig | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/configs/tegra_defconfig b/arch/
That quirk is required to make USB Ethernet gadget working on HW that
can't cope with unaligned DMA. For some reason only f_ncm sets up that
quirk, let's setup it directly in u_ether so other network models would
have that quirk applied as well. All network models have been tested with
ChipIdea UDC
From: Thierry Reding
All of these Tegra SoC generations have a ChipIdea UDC IP block that can
be used for device mode communication with a host. Implement rudimentary
support that doesn't allow switching between host and device modes.
Tested-by: Michał Mirosław
Signed-off-by: Thierry Reding
[d
From: Thierry Reding
Override the compatible string of the first USB controller to enable
device mode.
Signed-off-by: Thierry Reding
Acked-by: Stephen Warren
---
arch/arm/boot/dts/tegra30-beaver.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/tegra30-beav
From: Thierry Reding
Override the compatible string of the first USB controller to enable
device mode.
Signed-off-by: Thierry Reding
Tested-by: Nicolas Chauvet
Acked-by: Stephen Warren
---
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 12 +++-
1 file changed, 11 insertions(+), 1 deleti
Peter, you've applied the v3 of this patch to your local tree and so it is
already in linux-next. Don't you mind to pick up a newer version of the patch?
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More ma
Hi Greg
Patch 8/9 is a usb core change that increases reset signaling time for
root hub ports for all hosts. Just wanted to point this out to you and Alan.
It should end up saving port reset time in most cases.
The rest adds xhci port tracing, tunes xhci bus resume and
sorts out firmware revision
bus_resume() tried to resume the same ports the bus_suspend()
suspeded. This caused PLC timeouts in case a suspended device disconnected
and was not in a resumable state at bus_resume().
Add a check to make sure the link state is either U3 or resuming
before actually resuming the link.
At the sam
Add definitions for all port link states defined in xhci
specification for PORTSC register.
Will be needed for human readable port status tracing
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host
Add PORTSC Port status and control register decoder to
show human readable tracing of portsc register
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.h | 81 +
1 file changed, 81 insertions(+)
diff --git a/drivers/usb/host/xhci.h b/drivers/
From: Yoshihiro Shimoda
This patch adds firmware_name selection by soc_device_match() to
use other firmware name in the future. (For now, using the firmware
is the same as before.)
Signed-off-by: Yoshihiro Shimoda
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-rcar.c | 33
From: Yoshihiro Shimoda
This patch adds support for R-Car H3 ES2.0. Since this SoC revision
(or later) should use the V3 firmware, the driver needs to check
the revision via soc_device_match().
Signed-off-by: Yoshihiro Shimoda
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-rcar.c | 7
temp and temp1 variables are used for port status (portsc) and
command register. Give them more descriptive names
No functional changes
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/driver
Track the port status in a human readble way each time we get a
port status change event
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 2 ++
drivers/usb/host/xhci-trace.h | 23 +++
2 files changed, 25 insertions(+)
diff --git a/drivers/usb/host/xhci-ring.
Save 80ms device enumeration time by increasing root hub port reset time
The 50ms reset signaling time is not enough for most root hub ports.
Increasing the reset time to 60ms allows host controllers to finish port
reset and removes a retry causing an extra 50ms delay.
The USB 2 specification req
From: Yoshihiro Shimoda
Since the firmware_name is decided by xhci-rcar.c on R-Car Gen3 now,
this patch removes 2 things:
- Remove struct xhci_plat_priv xhci_plat_renesas_rcar_r8a7796.
- Remoce .firmware_name from xhci_plat_renesas_rcar_gen3.
The behavior is the same as before.
Signed-off-by:
Hi,
Mathias Nyman writes:
> Track the port status in a human readble way each time we get a
> port status change event
>
> Signed-off-by: Mathias Nyman
> ---
> drivers/usb/host/xhci-ring.c | 2 ++
> drivers/usb/host/xhci-trace.h | 23 +++
> 2 files changed, 25 insertions(
On Tue, Aug 15, 2017 at 04:26:07PM -0700, Badhri Jagan Sridharan wrote:
> Submitted couple of patches for the missing pieces in TCPM.
> Those patches along with "usb: typec: update partner power delivery
> support with opmode"
> seems to address the issue of reporting the right value for
> supports
On 16.08.2017 14:45, Felipe Balbi wrote:
Hi,
Mathias Nyman writes:
Track the port status in a human readble way each time we get a
port status change event
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 2 ++
drivers/usb/host/xhci-trace.h | 23 +++
gadget_release() is responsible for cleanup dev memory.
But if net2280_probe() fails after dev allocation, then
gadget_release() become unregistered and dev memory leaks.
Also net2280_remove() calls usb_del_gadget_udc() which
perform schedule_delayed_work() with gadget_release(), so
it is possible
On Wed, 16 Aug 2017, Mathias Nyman wrote:
> Save 80ms device enumeration time by increasing root hub port reset time
>
> The 50ms reset signaling time is not enough for most root hub ports.
> Increasing the reset time to 60ms allows host controllers to finish port
> reset and removes a retry caus
On Wed, 16 Aug 2017, Alexey Khoroshilov wrote:
> Hello,
>
> usb_add_gadget_udc_release() gets release() argument that allows to
> release user resources.
>
> As far as I can see, the release() is called on error paths
> of usb_add_gadget_udc_release() as a result of
> put_device(&gadget->dev);
On Wed, 16 Aug 2017, Anton Vasilyev wrote:
> gadget_release() is responsible for cleanup dev memory.
> But if net2280_probe() fails after dev allocation, then
> gadget_release() become unregistered and dev memory leaks.
This isn't needed if usb_add_gadget_udc_release() is fixed, right?
> Also ne
On Wed, Aug 16, 2017 at 11:01:20AM +0800, pierre Kuo wrote:
> try to fix some codeing style issue, such as "space prohibited" and "not
> initialise statics".
Only do one type of thing in a single patch please. And no, "fix all
coding style issues" is not a single thing.
This needs to be multiple
On 16.08.2017 18:29, Alan Stern wrote:
On Wed, 16 Aug 2017, Anton Vasilyev wrote:
gadget_release() is responsible for cleanup dev memory.
But if net2280_probe() fails after dev allocation, then
gadget_release() become unregistered and dev memory leaks.
This isn't needed if usb_add_gadget_ud
On Wed, 16 Aug 2017, Anton Vasilyev wrote:
> On 16.08.2017 18:29, Alan Stern wrote:
> > On Wed, 16 Aug 2017, Anton Vasilyev wrote:
> >
> >> gadget_release() is responsible for cleanup dev memory.
> >> But if net2280_probe() fails after dev allocation, then
> >> gadget_release() become unregistere
Hello,
Launchpad.net:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711151
Regards,
--
Cristian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 16, 2017 at 01:40:48PM -0300, Cristian wrote:
> Hello,
>
> Launchpad.net:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711151
What are we supposed to do with a one line description and a pointer to
some random distro bug site?
Please, if you want our help, give us the need
From: Stephen Warren
When the gadget serial device has no associated TTY, do not pass any
received data into the TTY layer for processing; simply drop it instead.
This prevents the TTY layer from calling back into the gadget serial
driver, which will then crash in e.g. gs_write_room() due to lack
Add CYPRESS_VID vid and CYPRESS_WICED_BT_USB and CYPRESS_WICED_WL_USB
device IDs to ftdi_sio driver
Signed-off-by: Jeffrey Chu
---
drivers/usb/serial/ftdi_sio.c | 2 ++
drivers/usb/serial/ftdi_sio_ids.h | 7 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c
On Wed, Aug 16, 2017 at 05:07:26PM -0400, Jeffrey Chu wrote:
> Add CYPRESS_VID vid and CYPRESS_WICED_BT_USB and CYPRESS_WICED_WL_USB
> device IDs to ftdi_sio driver
>
> Signed-off-by: Jeffrey Chu
> ---
> drivers/usb/serial/ftdi_sio.c | 2 ++
> drivers/usb/serial/ftdi_sio_ids.h | 7 +++
>
On 16.08.2017 18:24, Alan Stern wrote:
> On Wed, 16 Aug 2017, Alexey Khoroshilov wrote:
>
>> Hello,
>>
>> usb_add_gadget_udc_release() gets release() argument that allows to
>> release user resources.
>>
>> As far as I can see, the release() is called on error paths
>> of usb_add_gadget_udc_relea
Hi,
On Tue, Jul 25, 2017 at 8:40 AM, Chunfeng Yun wrote:
> On Thu, 2017-07-13 at 12:59 +0200, Martin Blumenstingl wrote:
>> Many SoC platforms have separate devices for the USB PHY which are
>> registered through the generic PHY framework. These PHYs have to be
>> enabled to make the USB controll
For 66AK2Gx there is a requirement to use PM Runtime to properly manage
clocks and the power domains. Therefore, add PM runtime support. Remove
legacy clock api's calls since other users of this driver worked without
these clock apis calls.
Signed-off-by: Franklin S Cooper Jr
---
drivers/usb/dwc
Add support for 66AK2G usb instances. However, the driver needs to be updated
to support PM_RUNTIME. This update has been validated to work on K2L and boot
tested on K2HK and K2E.
Version 2:
Clarify clock properties requirements in binding document
Franklin S Cooper Jr (2):
usb: dwc3: keystone:
Update various properties to properly indicate their requirement depending
on the SoC.
Signed-off-by: Franklin S Cooper Jr
---
Version 2:
Clarify clock requirements in binding document
Documentation/devicetree/bindings/usb/keystone-usb.txt | 17 +++--
1 file changed, 15 insertions(+
On Wed, Aug 16, 2017 at 04:10:00PM +0300, Mathias Nyman wrote:
> On 16.08.2017 14:45, Felipe Balbi wrote:
> >
> > Hi,
> >
> > Mathias Nyman writes:
> > > Track the port status in a human readble way each time we get a
> > > port status change event
> > >
> > > Signed-off-by: Mathias Nyman
> >
xhci_disable_slot() is a helper for disabling a slot when a device
goes away or recovers from error situations. Currently, it returns
success when it sees a dead host. This is not the right way to go.
It should return error and let the invoker know that disable slot
command was failed due to a dead
If xhci_disable_slot() returns success, a disable slot command
trb was queued in the command ring. The command completion
handler will free the virtual device data structure associated
with the slot. On the other hand, when xhci_disable_slot()
returns error, the invokers should take the responsibil
Xhci driver handles USB transaction errors on transfer events,
but transaction errors are possible on address device command
completion events as well.
The xHCI specification (section 4.6.5) says: A USB Transaction
Error Completion Code for an Address Device Command may be due
to a Stall response
xhci_disable_slot() is a helper for disabling a slot when a device
goes away or recovers from error situations. Currently, it checks
the corespoding virt-dev pointer and returns directly (w/o issuing
disable slot command) if it's null.
This is unnecessary and will cause problems in case where virt
xhci_disable_slot() allows the invoker to pass a command pointer
as paramenter. Otherwise, it will allocate one. This will cause
memory leak when a command structure was allocated inside of this
function while queuing command trb fails. Another problem comes up
when the invoker passed a command poi
Xhci driver handles USB transaction errors on transfer events,
but transaction errors are possible on address device command
completion events as well.
The xHCI specification (section 4.6.5) says: A USB Transaction
Error Completion Code for an Address Device Command may be due
to a Stall response
Hi,
On Mon, Oct 31, 2016 at 12:57 AM, Felipe Balbi
wrote:
>
> Hi,
>
> Joseph Kogut writes:
>> Well, after comparing the kernel log from both systems, it seems that
>> the device controller simply isn't being enumerated by the kernel for
>> some reason.
>>
>> Here's the relevant section from the
On Tue, Aug 8, 2017 at 11:27 AM, Thang Q. Nguyen wrote:
> XHCI specification 1.1 does not require xHCI-compliant controllers
> to always enable hardware USB2 LPM. However, the current xHCI
> driver always enable it when seeing HLC=1.
> This patch supports an option for users to control disabling
>
Hi,
Joseph Kogut writes:
>>> Here's the relevant section from the Android kernel:
>>>
>>> <6>[0.612857] PCI host bridge to bus :00
>>> <6>[0.612869] pci_bus :00: root bus resource [bus 00-ff]
>>> <6>[0.612877] pci_bus :00: root bus resource [io 0x-0x006f]
>>> <6>[
Hi,
Mathias Nyman writes:
>> Mathias Nyman writes:
>>> Track the port status in a human readble way each time we get a
>>> port status change event
>>>
>>> Signed-off-by: Mathias Nyman
>>> ---
>>> drivers/usb/host/xhci-ring.c | 2 ++
>>> drivers/usb/host/xhci-trace.h | 23
Hi Stephen,
On Fri, Jul 14, 2017 at 02:40:05PM -0700, Stephen Boyd wrote:
> We currently have three device nodes for the same USB hardware
> block, as evident by the reuse of the same reg address multiple
> times. Now that the chipidea driver fully supports OTG with the
> MSM wrapper we can collap
54 matches
Mail list logo
