On 05/17/2017 06:01 PM, Krzysztof Kozlowski wrote:
On Wed, May 17, 2017 at 12:58:38PM +0200, Richard Leitner wrote:
...
1. Currently usb251xb uses i2c_smbus_*, usb3503 uses regmap_* and
usb4604 uses i2c_master_* functions for the hub configuration. What
would be the preferred solution?
regmap
Hi Johan,
> -Original Message-
> From: Johan Hovold
> Sent: Wednesday, May 17, 2017 6:00 PM
>
> On Wed, May 17, 2017 at 04:53:07AM +, Yoshihiro Shimoda wrote:
> > Hi Johan,
> >
> > > From: Johan Hovold
> > > Sent: Tuesday, May 16, 2017 11:26 PM
> > >
> > > Make sure do drop the refere
Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some hard-wired USB devices
works abnormal or can't be recogniz
We have an well-known problem that the device needs to do some power
sequence before it can be recognized by related host, the typical
example like hard-wired mmc devices and usb devices.
This power sequence is hard to be described at device tree and handled by
related host driver, so we have crea
From: Joshua Clayton
Give usb nodes #address and #size attributes, so that a child node
representing a permanently connected device such as an onboard hub may
be addressed with a attribute
Signed-off-by: Joshua Clayton
Signed-off-by: Peter Chen
---
arch/arm/boot/dts/imx6qdl.dtsi | 6 ++
From: Joshua Clayton
Previously the onboard hub was made to work by treating its
reset gpio as a regulator enable.
Get rid of that kludge now that pwseq has added reset gpio support
Move pin muxing the hub reset pin into the usbh1 group
Signed-off-by: Joshua Clayton
Signed-off-by: Peter Chen
-
The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it. Besides, using gpio pinctrl setting for USB2415's reset pin.
Signed-off-by: Peter Chen
Signed-off-by: Josh
Add optional properties for power sequence.
Signed-off-by: Peter Chen
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/usb/usb-device.txt | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt
b/Documentatio
Add binding doc for generic power sequence library.
Signed-off-by: Peter Chen
Acked-by: Philipp Zabel
Acked-by: Rob Herring
---
.../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/binding
This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
power sequence instances will be added at postcore_initcall, the match
criteria is compatible string first, if the compatible string is not
matched between dt
Hi all,
Here are patches I promised several months ago so we can eventually
get rid of ohci-omap3 in favor of ohci-platform as suggested by
Alan Stern.
I think we need to wait a while before removing ohci-omap3, so
I just added a warning for now to urge people to move to use
ohci-platform instead
This is needed in preparation of adding support for omap3 and
later OHCI. The runtime PM will only do something on platforms
that implement it.
Cc: devicet...@vger.kernel.org
Cc: Hans de Goede
Cc: Rob Herring
Cc: Roger Quadros
Cc: Yoshihiro Shimoda
Signed-off-by: Tony Lindgren
---
drivers/us
Add remote-wakeup-connected for omap OHCI as that's needed by
ehci-platform driver.
Cc: devicet...@vger.kernel.org
Cc: Hans de Goede
Cc: Rob Herring
Cc: Roger Quadros
Cc: Yoshihiro Shimoda
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/omap3.dtsi | 1 +
arch/arm/boot/dts/omap4.dtsi | 1 +
We can't just remove ohci-omap3 as that could make some people's
systems unusable for keyboard and mouse. Let's print a warning for
now, and then remove the driver in a year or so.
Cc: Hans de Goede
Cc: Rob Herring
Cc: Roger Quadros
Cc: Yoshihiro Shimoda
Signed-off-by: Tony Lindgren
---
driv
With the runtime PM implemented for ohci-platform driver, we can
now support omap3 and later OHCI by adding one device tree
property.
Cc: Hans de Goede
Cc: Rob Herring
Cc: Roger Quadros
Cc: Yoshihiro Shimoda
Signed-off-by: Tony Lindgren
---
Documentation/devicetree/bindings/usb/usb-ohci.txt
I came to this patch series when wanted to do two things:
- use UAC1 as virtual ALSA sound card on gadget side,
just like UAC2 is used so it's possible to do rate
resampling
- have both playback/capture support in UAC1
Since I wanted to have same behavior for both UAC1/UAC2,
obviously I've
Abstract the peripheral side ALSA sound card code from
the f_uac2 function into a component that can be called
by various functions, so the various flavors can be split
apart and selectively reused.
Visible changes:
- add uac_params structure to pass audio paramteres for
g_audio_setup
- make
This patch adds a new function 'f_uac1_acard'
(f_uac1 with virtual "ALSA card") that
uses recently created u_audio API. Comparing
to legacy f_uac1 function implementation it
doesn't require any real Audio codec to be
present on the device. In f_uac1_acard audio
streams are simply sinked to and sour
Simplify f_uac2 by removing platform driver/device
creation; use composite's usb_gadget device as
parent for sound card and for debug prints.
This removes extra layer of code without any functional
change.
Signed-off-by: Ruslan Bilovol
---
drivers/usb/gadget/function/f_uac2.c | 107 +
Hi,
I have an Anker USB hub, which is using the VL812 chipset. It works
perfectly when plug/unplug USB2 flash drives. It does not work at all
(dmesg is quiet) when I plug/unplug USB3 flash drives.
It works in Windows. It kinda works in FreeBSD (the USB3 device just
works at USB2 speeds).
Howeve
The function is not used, but is probably kept around for debugging and
symmetry with usb_ocp_write(). Adding the attribute fixes the following
clang warning:
drivers/net/usb/r8152.c:825:5: error: unused function 'usb_ocp_read'
[-Werror,-Wunused-function]
Signed-off-by: Matthias Kaehlcke
---
The function is not used, but it looks useful for debugging. Adding the
attribute fixes the following clang warning:
drivers/net/usb/net1080.c:271:20: error: unused function
'nc_dump_ttl' [-Werror,-Wunused-function]
Signed-off-by: Matthias Kaehlcke
---
drivers/net/usb/net1080.c | 2 +-
1 fi
On Fri, May 12, 2017 at 04:57:48PM +0300, Peter Ujfalusi wrote:
> For the DMA we have ch (channel), dmareq and sync_dev parameters both
> within the tusb_omap_dma_ch and tusb_omap_dma_ch struct.
one of the two "tusb_omap_dma_ch" should be "tusb_omap_dma".
Regards,
-Bin.
--
To unsubscribe from thi
On Fri, May 12, 2017 at 04:57:48PM +0300, Peter Ujfalusi wrote:
> For the DMA we have ch (channel), dmareq and sync_dev parameters both
> within the tusb_omap_dma_ch and tusb_omap_dma_ch struct.
> By creating a common struct the code can be simplified when selecting
> between the shared or multicha
On Fri, May 12, 2017 at 04:57:46PM +0300, Peter Ujfalusi wrote:
> When using the g_ncm for networking this flag will make sure that the
> buffer is alligned to 32bit so the DMA can be used to offload the data
s/alligned/aligned/
Regards,
-Bin.
> movement.
>
> Signed-off-by: Peter Ujfalusi
> Te
On Wed, 17 May 2017, Rainer Koenig wrote:
> Oops, pressed the "send button too quickly, sorry"
>
> Am 16.05.2017 um 16:20 schrieb Alan Stern:
> > You've got a BIOS developer in the same building? That's a great
> > resource! Maybe together you can find out what condition is causing
> > the BIOS
From: Bjørn Mork
Date: Tue, 16 May 2017 20:24:10 +0200
> Jim Baxter writes:
>
>> The CDC-NCM driver can require large amounts of memory to create
>> skb's and this can be a problem when the memory becomes fragmented.
>>
>> This especially affects embedded systems that have constrained
>> resour
For non-pd case, Should I instead say that the low level driver might optionally
choose to perform a best case effort of performing a role swap by disconnect
and reconnect ?
Does the following description look better ?
Description:
The supported power roles. This attribute can be
Hi Greg,
Here are the couple musb fixes for v4.12-rc2. One fixes an regression caused in
the runtime PM refactoring in musb since v4.9, and the other fixes a register
cross-talk between rx and tx in tusb6010 since the beginning when the driver was
merged.
Please let me know if any change is neede
From: Peter Ujfalusi
We have one register for each EP to set the maximum packet size for both
TX and RX.
If for example an RX programming would happen before the previous TX
transfer finishes we would reset the TX packet side.
To fix this issue, only modify the TX or RX part of the register.
Fi
From: Tony Lindgren
Commit d8e5f0eca1e8 ("usb: musb: Fix hardirq-safe hardirq-unsafe
lock order error") caused a regression where musb keeps trying to
enable host mode with no cable connected. This seems to be caused
by the fact that now phy is enabled earlier, and we are wrongly
trying to force
On Wed, May 17, 2017 at 12:58:38PM +0200, Richard Leitner wrote:
> Hello,
> due to the fact (all?) the Microchip (former SMSC) USB hubs share the
> same I2C configuration interface, I'm currently working on harmonizing
> those USB Hub drivers. Currently this affects the usb251xb, usb3503 and
> usb4
From: Alan Stern
With threaded interrupts, bottom-half handlers are called with
interrupts enabled. Therefore they can't safely use spin_lock(); they
have to use spin_lock_irqsave(). Lockdep warns about a violation
occurring in xhci_irq():
==
From: Thomas Petazzoni
platform_get_irq() returns an error code, but the xhci-plat driver
ignores it and always returns -ENODEV. This is not correct, and
prevents -EPROBE_DEFER from being propagated properly.
CC:
Signed-off-by: Thomas Petazzoni
Signed-off-by: Mathias Nyman
---
drivers/usb/ho
In 4.11 TRB completion codes were renamed to match spec.
Completion codes for command ring stopped and endpoint stopped
were mixed, leading to failures while handling a stopped command ring.
Use the correct completion code for command ring stopped events.
Fixes: 0b7c105a04ca ("usb: host: xhci: r
Hi Greg
A bunch of smaller fixes for usb-linus this time, including among others
a lock inversion fix by Alan.
-Mathias
Alan Stern (1):
USB: xhci: fix lock-inversion problem
Mathias Nyman (3):
usb: xhci: trace URB before giving it back instead of after
xhci: apply PME_STUCK_QUIRK and MISS
From: Peter Chen
According to xHCI spec Figure 30: Interrupt Throttle Flow Diagram
If PCI Message Signaled Interrupts (MSI or MSI-X) are enabled,
then the assertion of the Interrupt Pending (IP) flag in Figure 30
generates a PCI Dword write. The IP flag is automatically c
Intel Denverton microserver is Atom based and need the PME and CAS quirks
as well.
Cc: stable
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-pci.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 7
From: Matthias Lange
There is no reason to restrict allocations to the first 16MB ISA DMA
addresses.
It is causing problems in a virtualization setup with enabled IOMMU
(x86_64). The result is that USB is not working in the VM.
CC:
Signed-off-by: Matthias Lange
Signed-off-by: Mathias Nyman
-
Don't access any members of a URB after giving it back.
URB might be freed by then already.
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 74bf5c6.
From: Peter Chen
According to xHCI ch4.20 Scratchpad Buffers, the Scratchpad
Buffer needs to be zeroed.
...
The following operations take place to allocate
Scratchpad Buffers to the xHC:
...
b. Software clears the Scratchpad Buffer to '0'
Cc: stab
On Wed, May 17, 2017 at 04:30:50PM +0200, Bjørn Mork wrote:
> In their infinite wisdom, and never ending quest for end user frustration,
> Lenovo has decided to use new USB device IDs for the wwan modules in
> their 2017 laptops. The actual hardware is still the Sierra Wireless
> EM7455 or EM7430,
In their infinite wisdom, and never ending quest for end user frustration,
Lenovo has decided to use a new USB device ID for the wwan modules in
their 2017 laptops. The actual hardware is still the Sierra Wireless
EM7455 or EM7430, depending on region.
Signed-off-by: Bjørn Mork
---
drivers/net/
In their infinite wisdom, and never ending quest for end user frustration,
Lenovo has decided to use new USB device IDs for the wwan modules in
their 2017 laptops. The actual hardware is still the Sierra Wireless
EM7455 or EM7430, depending on region.
Cc:
Signed-off-by: Bjørn Mork
---
drivers/
From: Greg KH
> Sent: 16 May 2017 11:19
> Format specifier %p can leak kernel addresses while not valuing the
> kptr_restrict system settings. When kptr_restrict is set to (1), kernel
> pointers printed using the %pK format specifier will be replaced with
> Zeros. Debugging Note : &pK prints only Z
On Wed, May 17, 2017 at 06:02:47AM -0700, Guenter Roeck wrote:
> On 05/17/2017 05:38 AM, Heikki Krogerus wrote:
> > Hi guys,
> >
> > On Wed, May 17, 2017 at 02:36:44AM -0700, Guenter Roeck wrote:
> > > On 05/17/2017 12:34 AM, Oliver Neukum wrote:
> > > > Am Mittwoch, den 17.05.2017, 00:32 -0700 sc
On Wed, May 17, 2017 at 04:02:33PM +0300, Felipe Balbi wrote:
> %p will leak kernel pointers, so let's not expose the information on
> dmesg and instead use %pK. %pK will only show the actual addresses if
> explicitly enabled under /proc/sys/kernel/kptr_restrict.
>
> Signed-off-by: Felipe Balbi
>
Hi,
On Fri, Apr 14, 2017 at 02:43:27PM -0400, Damien Riegel wrote:
> This patchset adds a way for the MSM USB phy to notify a power supply
> when the charging state changes. It achieves that using the extcon
> subsystem.
>
> The first patch makes sure msm_otg_notify_charger is called after the
>
Instead of printing out enqueue and dequeue pointer value as a header
to the output, let's mark the TRBs in question with 'E' and 'D'. The
output looks slightly easier to read.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/debugfs.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(
Document a few details about DWC3 in order to help people report bugs
and debug DWC3.
Signed-off-by: Felipe Balbi
---
Documentation/driver-api/usb/dwc3.rst | 712 +
Documentation/driver-api/usb/index.rst | 1 +
2 files changed, 713 insertions(+)
create mode 10
This is where all other USB ReST documentation has moved to.
Signed-off-by: Felipe Balbi
---
Documentation/driver-api/usb/index.rst | 2 ++
Documentation/{ => driver-api}/usb/typec.rst | 0
Documentation/{ => driver-api}/usb/usb3-debug-port.rst | 0
3 files changed, 2 i
Instead of going for a 512 byte buffer and using snprintf(), let's
rely on helps __string() and __assign_str() where possible.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/trace.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/trace.h b/
No functional changes, just making sure we can use these for ReST docs
later.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.h | 44 +
drivers/usb/dwc3/ep0.c| 2 +-
drivers/usb/dwc3/gadget.c | 121 +++---
drivers/usb/dwc3/ga
No functional changes, just a slight readability improvement.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index e4e872c703f1..d2bd28dc28b6 100
Instead, we can require caller to pass a buffer for the function to
use. This cleans things quite a bit.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/debug.h | 13 ++---
drivers/usb/dwc3/trace.h | 4 +++-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc
Instead of *always* dumping raw ctrl bytes, let's decode standard
requests which will make the lives of those debugging DWC3 quite a bit
easier.
Output will now look like so:
irq/34-dwc3-1594 [000] d..1 107.573081: dwc3_ctrl_req: Get Device
Descriptor(Index = 0, Length = 18)
irq/34-dwc3-1594
Currently, default vary will not accomodate superspeed endpoints
causing unexpected babble errors in the IN direction. Let's update
default 'vary' parameter so that we can maintain a "short-less"
transfer as hinted at the comment.
Reported-by: Ammy Yi
Signed-off-by: Felipe Balbi
---
tools/usb/t
On 05/17/2017 05:38 AM, Heikki Krogerus wrote:
Hi guys,
On Wed, May 17, 2017 at 02:36:44AM -0700, Guenter Roeck wrote:
On 05/17/2017 12:34 AM, Oliver Neukum wrote:
Am Mittwoch, den 17.05.2017, 00:32 -0700 schrieb Badhri Jagan
Sridharan:
Hi,
"Two independent set of mechanisms are defined to
%p will leak kernel pointers, so let's not expose the information on
dmesg and instead use %pK. %pK will only show the actual addresses if
explicitly enabled under /proc/sys/kernel/kptr_restrict.
Signed-off-by: Felipe Balbi
---
Inspired by a recent patch Greg posted. Note that I've kept
tracepoi
On Sat, May 13, 2017 at 03:49:17PM +0200, Markus Heiser wrote:
> Even if this file is not yet included in any toctree, it is parsed by
> Sphinx since it is named '.rst'. This patch fixes the following two
> ERRORs from Sphinx build:
>
> Documentation/usb/typec.rst:116: ERROR: Error in "kernel-doc"
Hi guys,
On Wed, May 17, 2017 at 02:36:44AM -0700, Guenter Roeck wrote:
> On 05/17/2017 12:34 AM, Oliver Neukum wrote:
> > Am Mittwoch, den 17.05.2017, 00:32 -0700 schrieb Badhri Jagan
> > Sridharan:
> >
> > Hi,
> >
> > > "Two independent set of mechanisms are defined to allow a USB Type-C
> > >
On Wed, May 17, 2017 at 12:07:50PM +0200, Michael Grzeschik wrote:
> The usbip stack dynamically allocates the transfer_buffer of each urb in
> stub_recv_cmd_submit depending on the requested transfer_buffer_length
> set via the received tcp packet.
>
> As the usbip layer never reuses the always d
Mauro Carvalho Chehab writes:
> The USB gadget documentation is not at DocBook anymore.
> The main file was converted to ReST, and stored at
> Documentation/driver-api/usb/gadget.rst, but there are
> still several plain text files related to gadget under
> Documentation/usb.
>
> So, be generic an
Oops, pressed the "send button too quickly, sorry"
Am 16.05.2017 um 16:20 schrieb Alan Stern:
> You've got a BIOS developer in the same building? That's a great
> resource! Maybe together you can find out what condition is causing
> the BIOS to initiate a reboot.
We got everything here. We got
Hello,
due to the fact (all?) the Microchip (former SMSC) USB hubs share the
same I2C configuration interface, I'm currently working on harmonizing
those USB Hub drivers. Currently this affects the usb251xb, usb3503 and
usb4604 drivers. To avoid preventable efforts (and patch versions) I
have some
Am 16.05.2017 um 16:20 schrieb Alan Stern:
> You've got a BIOS developer in the same building? That's a great
> resource! Maybe together you can find out what condition is causing
> the BIOS to initiate a reboot.
We got everything here. We got hardware developers for our mainboards
and systems,
From: Oliver Neukum (oneu...@suse.com) Sent: Wed, 17 May 2017 09:44:20 +0200
> Am Dienstag, den 16.05.2017, 20:24 +0200 schrieb Bjørn Mork:
>>
>> I must say that I don't like the additional complexity added here. If
>> there are memory issues and you can reduce the buffer size to
>> USB_CDC_NCM_
linux-usb-ow...@vger.kernel.org schrieb am 17.05.2017 09:08:39:
> > I'm not sure for 100%, but I assume that reading the IN pipe could be
> > setup asynchronously (e.g. with usb_submit_urb(..)) just before
sending
> > send_request_dev_dep_msg_in(..).
> > USBTMC_SIZE_IOBUFFER = 2kB is a bottleneck
Some functions might want to have very, very long request queues. We
can't make any assumptions about how many requests we *are* able to
map, so instead of mapping requests early, let's map them late. This
way, functions can queue as many requests as they'd like but we won't
take DMA resources unti
We don't need a big fat warning with stack dump at all. Running out of
TRBs is a normal condition and we will have more TRBs available as
soon as some transfers complete.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --gi
The usbip stack dynamically allocates the transfer_buffer of each urb in
stub_recv_cmd_submit depending on the requested transfer_buffer_length
set via the received tcp packet.
As the usbip layer never reuses the always different sized
transfer_buffer it can add URB_FREE_BUFFER to every urbs trans
On 05/17/2017 01:08 AM, Greg Kroah-Hartman wrote:
On Wed, May 17, 2017 at 12:32:19AM -0700, Badhri Jagan Sridharan wrote:
With this CL the lower level drivers are reponsible to check and make sure
responsible
that the role swap can be performed.
What is a "CL"?
Too much Gerrit. "Change
On Tue, May 16, 2017 at 11:14:46AM +0200, Michael Grzeschik wrote:
> On Mon, May 15, 2017 at 05:37:52PM +0200, Michael Grzeschik wrote:
> > The usbip stack dynamically allocates the transfer_buffer of each urb in
> > stub_recv_cmd_submit depending on the requested transfer_buffer_length
> > set via
On Thu, Apr 06, 2017 at 06:03:21AM +0800, Yuyang Du wrote:
> The commit 0775a9cbc694e8c7 ("usbip: vhci extension: modifications
> to vhci driver") introduced several bugs relating to the number of
> ports amd the port status. In addition, a small improvement is made
> to the vhci_hcd module.
Can y
On 05/17/2017 12:34 AM, Oliver Neukum wrote:
Am Mittwoch, den 17.05.2017, 00:32 -0700 schrieb Badhri Jagan
Sridharan:
Hi,
"Two independent set of mechanisms are defined to allow a USB Type-C
DRP to functionally swap power and data roles. When USB PD is
supported, power and data role swapping i
On Wed, May 17, 2017 at 10:51:48AM +0300, Felipe Balbi wrote:
>
> Hi Greg,
>
> here's my first pull request for v4.12-rc cycle. Only 6 patches this
> time around. Where applicable, patches were tested on a few Intel
> platforms I have available.
>
> Let me know if you want anything to be changed
On Wed, May 17, 2017 at 04:53:07AM +, Yoshihiro Shimoda wrote:
> Hi Johan,
>
> > From: Johan Hovold
> > Sent: Tuesday, May 16, 2017 11:26 PM
> >
> > Make sure do drop the reference taken to the companion device during
> > resume.
> >
> > Fixes: d4d75128b8fd ("usb: host: ehci-platform: fix us
On Tue, May 16, 2017 at 11:54:41PM +0300, Andrey Korolyov wrote:
> This patch adds support for recognition of ARM-USB-TINY(H) devices which
> are almost identical to ARM-USB-OCD(H) but lacking separate barrel jack
> and serial console.
>
> By suggestion from Johan Hovold it is possible to replace
On Tue, May 16, 2017 at 05:04:37PM +0200, guido.kie...@rohde-schwarz.com wrote:
>
> Sounds good. I think if we decide to extend the usbtmc driver then we will
> hopefully find some driver developers within the companies who are
> experienced :-)
If you all are maintaining a Windows driver, I'm
Calculate wMaxPacketSize before endpoint matching the
descriptor is found.
This allows audio gadget to be used with controllers
which have a shortage or unavailability of endpoints
that can handle max packet size of 1023 (FS) or 1024
(HS).
With this audio gadget can be used on TI's OMAP-L138 SoC
On Tue, May 16, 2017 at 07:37:31PM -0500, Alberto Ladron wrote:
> On Tue, May 16, 2017 at 01:44:47PM +0800, kbuild test robot wrote:
> Hi,
>
>Here is the fix. Or I have to resubmit the whole patch?
The whole patch, of course, you can't break the build with any
individual patch, yours is long
On Wed, May 17, 2017 at 12:32:19AM -0700, Badhri Jagan Sridharan wrote:
> With this CL the lower level drivers are reponsible to check and make sure
> that the role swap can be performed.
What is a "CL"?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
On Tue, May 16, 2017 at 09:17:23PM -0500, Alberto Ladron wrote:
> Signed-off-by: Alberto Ladron
I can't take patches without any changelog text.
Also only do "one logical thing" per patch, and no, fixing all coding
style issues is not "one thing".
Also, where are patches 1/3 and 2/3?
And final
Hi Greg,
here's my first pull request for v4.12-rc cycle. Only 6 patches this
time around. Where applicable, patches were tested on a few Intel
platforms I have available.
Let me know if you want anything to be changed.
cheers
The following changes since commit 2ea659a9ef488125eb46da6eb571de5e
Hi,
Roger Quadros writes:
> On 21/04/17 15:58, Roger Quadros wrote:
>> Commit 08a36b543803 ("usb: dwc3: gadget: simplify __dwc3_gadget_ep_queue()")
>> caused a small change in the way ISO transfer is handled in the case
>> when XferInProgress event happens on Isoc EP with an active transfer.
>>
Am Dienstag, den 16.05.2017, 20:24 +0200 schrieb Bjørn Mork:
>
> I must say that I don't like the additional complexity added here. If
> there are memory issues and you can reduce the buffer size to
> USB_CDC_NCM_NTB_MIN_OUT_SIZE, then why don't you just set a lower tx_max
> buffer size in the fi
Hi Felipe,
On 21/04/17 15:58, Roger Quadros wrote:
> Commit 08a36b543803 ("usb: dwc3: gadget: simplify __dwc3_gadget_ep_queue()")
> caused a small change in the way ISO transfer is handled in the case
> when XferInProgress event happens on Isoc EP with an active transfer.
> This caused a performan
Am Mittwoch, den 17.05.2017, 00:32 -0700 schrieb Badhri Jagan
Sridharan:
Hi,
> "Two independent set of mechanisms are defined to allow a USB Type-C
> DRP to functionally swap power and data roles. When USB PD is
> supported, power and data role swapping is performed as a subsequent
> step followi
Am Dienstag, den 16.05.2017, 21:17 -0500 schrieb Alberto Ladron:
> Signed-off-by: Alberto Ladron
> ---
> drivers/usb/storage/shuttle_usbat.c | 83
> ++---
> 1 file changed, 41 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/usb/storage/shuttle_usbat.c
>
With this CL the lower level drivers are reponsible to check and make sure
that the role swap can be performed.
This facilitates the lower level driver to attempt to perform role swap
through initial connection process.
Quoting from the Type-C specification release(page 24),
role swaps are not li
Signed-off-by: Alberto Ladron
---
drivers/usb/storage/shuttle_usbat.c | 83 ++---
1 file changed, 41 insertions(+), 42 deletions(-)
diff --git a/drivers/usb/storage/shuttle_usbat.c
b/drivers/usb/storage/shuttle_usbat.c
index 3b0294e..9eddc40 100644
--- a/drivers/
guido.kie...@rohde-schwarz.com wrote:
> linux-usb-ow...@vger.kernel.org schrieb am 15.05.2017 15:20:22:
>> Von: Greg KH
>> On Mon, May 15, 2017 at 02:47:48PM +0200, Guido.Kiener@x wrote:
>>> 2. As we have looked at the Linux driver, we’ve noticed that performance
>>> of the usbtmc_read() f
92 matches
Mail list logo
