This driver is for Fintek F81532/F81534 USB to Serial Ports IC.
Features:
1. F81534 is 1-to-4 & F81532 is 1-to-2 serial ports IC
2. Support Baudrate from B50 to B150 (excluding B100).
3. The RTS signal can be transformed their behavior with
configuration by ioctl TIOCGRS485/TIOCSRS485
On 12/01/2015 09:32 PM, Heikki Krogerus wrote:
> Intel Braswell/Cherrytrail has an internal mux that shares
> one USB port between USB Device Controller and xHCI. The
> same mux is found on several SOCs from Intel, but only on
> a few Cherrytrail based platforms the OS is expected to
> configure
Hi Felipe,
On 17.10.2015 22:24, Vladimir Zapolskiy wrote:
> If common clock framework is configured, the driver generates warnings,
> which is fixed by this change:
>
> WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:728
> clk_core_enable+0x2c/0xf0()
> Modules linked in:
> CPU: 0 PID: 1
xHCI debug capability (DbC) is an optional functionality provided
by an xHCI host controller. Software learns this capability by
walking through the extended capability list in mmio of the host.
This patch introduces the code to probe and initialize the debug
capability hardware during early boot.
This patch adds a sysfs file for users to check 1) whether the debug
capability is implemented by hardware; 2) if supported, which state
does it stay at.
With a host that supports debug port, a file named "debug_port_state"
will be created under the device sysfs directory. Reading this file
will s
On Intel platforms, if the debug target is connected with debug
host, enabling DCE bit in command register leads to a port hung
state. In the hung state, the host system will not see a port
connected status bit set. Hence debug target fails to be probed.
The state could be resolved by performing a
Hi,
This patch series adds support for early printk through USB3 debug port.
USB3 debug port is described in xHCI specification as an optional extended
capability.
The first patch adds a file in sysfs, through which users can check
whether the debug capability is supported by a specific host cont
DbC might exit configured state in some cases (refer to 7.6.4.4 in
xHCI spec 1.1). Software needs detect and clear this situation by
clearing DCCTRL.DCR and wait until the DbC configured before read
or write oprations.
Signed-off-by: Lu Baolu
---
drivers/usb/early/xhci-dbc.c | 28 +++
This patch adds interfaces for bulk out and bulk in ops. These
interfaces could be used to implement early printk bootconsole
or hook to various system debuggers.
Signed-off-by: Lu Baolu
---
drivers/usb/early/xhci-dbc.c | 373 +++
include/linux/usb/xhci-db
"printk" is not suitable for dbc debugging especially when console
is in usage. This patch adds a debug buffer in dbc driver and puts
the debug messages in this local buffer. The debug buffer could be
dumped whenever the console is not in use. This part of code will
not be visible unless DBC_DEBUG
xHCI compatible USB3 host controller may provide debug capability
which enables low-level system debug over USB. In order to probing
this debug capability, Linux kernel needs to map and access the
mmio of the host controller during early boot.
This patch adds permenent fixmap pages in fixed_addres
Add support for early printk by writing debug messages to the USB3
debug port. Users can use this type of early printk by specifying
kernel parameter of "earlyprintk=xdbc". This gives users a chance
of providing debug output.
Signed-off-by: Lu Baolu
---
Documentation/kernel-parameters.txt | 1 +
In case of endpoint stall, software is able to detect the situation
by reading DCCTRL.HIT or DCCTRL.HOT bits. DbC follows the normal USB
framework to handle endpoint stall. When software detects endpoint
stall situation, it should wait until endpoint is recovered before
read or write oprations.
Si
This patch add dbc debug device support in usb_debug driver.
Signed-off-by: Lu Baolu
Acked-by: Johan Hovold
---
drivers/usb/serial/usb_debug.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/serial/usb_debug.c b/drivers/usb/serial/us
After DbC setup, debug target needs to wait until tty driver and
application (e.g. mincom) on debug taget start. Otherwise, out
messages might be ignored.
This patch adds a ping/pong mechanism between debug target and
host. Debug target will be waiting there until user presses 'Y'
or 'y' in the t
Add Documentation/usb/xhci-dbc.txt. This document includes
development status and user guide for USB3 debug port.
Signed-off-by: Lu Baolu
---
Documentation/usb/xhci-dbc.txt | 350 +
MAINTAINERS| 1 +
drivers/usb/early/xhci-dbc.c |
On 2 December 2015 at 04:05, Greg KH wrote:
> On Fri, Nov 06, 2015 at 05:46:30PM +0530, Saurabh Sengar wrote:
>> added iounmap inorder to free memory mapped to base before returning
>>
>> Signed-off-by: Saurabh Sengar
>> ---
>> drivers/usb/host/pci-quirks.c | 4 ++--
>> 1 file changed, 2 inserti
On Wed, Dec 02, 2015 at 01:02:28AM +, Rogan Dawes wrote:
> Thanks Greg.
>
> At a high level, what is needed to implement a new type of USB device gadget,
> such as a display link device?
A lot of work :)
> I assume there is a small kernel portion that simply relays data to user
> space,
> a
On Wed, Dec 02, 2015 at 02:14:48AM +0200, Rogan Dawes wrote:
> Hi folks,
>
> I'm wondering if it is possible/reasonable to try to turn a linux
> device with host and OTG ports into something that looks and acts like
> a USB hub?
Nope, go spend $10 and buy a USB hub, it's cheaper and will work
pro
On Wed, Oct 14, 2015 at 01:16:37AM +0530, Muthu M wrote:
> Added support for Billboard Capability descriptor as per Universal
> Serial Bus Device Class Definition for Billboard Devices Revision 1.1
>
> Signed-off-by: Muthu M
> Reviewed-by: Felipe Balbi
> ---
> lsusb.c | 114
> +
On Sat, Apr 04, 2015 at 01:44:58PM +0200, Stefan Tauner wrote:
> Signed-off-by: Stefan Tauner
> ---
>
> Hi Greg,
>
> I think DIGImend has eventually moved their code to github so
> git submodule update --init for usbutils fails:
> Cloning into 'usbhid-dump'...
> fatal: Could not read from remote
Hi folks,
I'm wondering if it is possible/reasonable to try to turn a linux device with
host and OTG ports into something that looks and acts like a USB hub?
The objective is to allow me to monitor the USB traffic from a Windows host to
facilitate writing a device emulator on the Linux device.
Hi Jiri,
On Tue, Dec 1, 2015 at 8:36 AM, Jiri Kosina wrote:
> On Fri, 20 Nov 2015, Ioan-Adrian Ratiu wrote:
>
>> The critical section protected by usbhid->lock in hid_ctrl() is too
>> big and because of this it causes a recursive deadlock. "Too big" means
>> the case statement and the call to hid
On Tue, Dec 1, 2015 at 4:48 PM, Alan Stern wrote:
> On Tue, 1 Dec 2015, Alan Cooper wrote:
>
>> On Tue, Dec 1, 2015 at 2:35 PM, Alan Stern wrote:
>> >> I'm now sure the host in "non-compliant".
>> >
>> > It is non-compliant if it turns off Vbus power during suspend. But
>> > that may be caused b
On Tue, Dec 01, 2015 at 11:44:19PM +0100, Rafał Miłecki wrote:
> On 1 December 2015 at 23:28, Greg KH wrote:
> > On Fri, Oct 23, 2015 at 11:36:56PM +0200, Hauke Mehrtens wrote:
> >> This patch adds support for the USB 3.0 controller in the bcm53xx
> >> Northstar SoC.
> >> These patches are based
On Tue, Dec 01, 2015 at 03:52:54PM +0100, Oliver Neukum wrote:
> The documentation wrongly implied that it is a core parameter.
> That is not true. If usbcore is compiled as a module, a module
> parameter needs a prefix.
>
> Signed-off-by: Oliver Neukum
> ---
> Documentation/kernel-parameters.tx
On 1 December 2015 at 23:28, Greg KH wrote:
> On Fri, Oct 23, 2015 at 11:36:56PM +0200, Hauke Mehrtens wrote:
>> This patch adds support for the USB 3.0 controller in the bcm53xx Northstar
>> SoC.
>> These patches are based on top of usb-next.
>>
>> This also adds a fake doorbell quirk which is n
On 12/1/2015 2:34 PM, Florian Fainelli wrote:
On 25/10/15 15:52, Hauke Mehrtens wrote:
On 10/24/2015 12:40 AM, Florian Fainelli wrote:
On 23/10/15 14:37, Hauke Mehrtens wrote:
From: Rafał Miłecki
Signed-off-by: Rafał Miłecki
Signed-off-by: Hauke Mehrtens
---
[snip]
+
+ switch (
On Mon, Nov 30, 2015 at 12:14:59PM -0500, Alan Stern wrote:
> As I recall, Markus's original patch took care of this by checking to
> see whether the transfer buffer was in one of the mmap'ed areas. If it
> was then the transfer would be zerocopy; otherwise it would be normal.
> That seems like
On 25/10/15 15:52, Hauke Mehrtens wrote:
> On 10/24/2015 12:40 AM, Florian Fainelli wrote:
>> On 23/10/15 14:37, Hauke Mehrtens wrote:
>>> From: Rafał Miłecki
>>>
>>> Signed-off-by: Rafał Miłecki
>>> Signed-off-by: Hauke Mehrtens
>>> ---
>>
>> [snip]
>>
>>> +
>>> + switch (chipinfo->id) {
>>>
On Fri, Nov 06, 2015 at 05:46:30PM +0530, Saurabh Sengar wrote:
> added iounmap inorder to free memory mapped to base before returning
>
> Signed-off-by: Saurabh Sengar
> ---
> drivers/usb/host/pci-quirks.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb
On Fri, Oct 23, 2015 at 11:36:56PM +0200, Hauke Mehrtens wrote:
> This patch adds support for the USB 3.0 controller in the bcm53xx Northstar
> SoC.
> These patches are based on top of usb-next.
>
> This also adds a fake doorbell quirk which is needed for this controller
>
> changes since:
> v2:
On Tue, Dec 01, 2015 at 11:09:23PM +0100, Jiri Kosina wrote:
> On Tue, 1 Dec 2015, Adrien Vergé wrote:
>
> > All ELAN hid devices seem to require the ALWAYS_POLL quirk. Let's use
> > this quirk for all devices from this vendor, rather than maintaining a
> > list of all its known product IDs.
> >
On Tue, 1 Dec 2015, Adrien Vergé wrote:
> All ELAN hid devices seem to require the ALWAYS_POLL quirk. Let's use
> this quirk for all devices from this vendor, rather than maintaining a
> list of all its known product IDs.
>
> Tested-by: Adrien Vergé
> Signed-off-by: Adrien Vergé
Reviewed-by: B
On Tue, 1 Dec 2015, Alan Cooper wrote:
> On Tue, Dec 1, 2015 at 2:35 PM, Alan Stern wrote:
> >> I'm now sure the host in "non-compliant".
> >
> > It is non-compliant if it turns off Vbus power during suspend. But
> > that may be caused by the platform more than by the controller itself.
> >
>
>
subscribe
--
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
Mathias Nyman wrote:
Hi
There are some xhci resume related issues which might be related to this.
Host and device initiated resume functions race, and we end up with this
similar output:
Nov 26 02:24:18 vostro kernel: xhci_hcd :0b:00.0: suspend failed because a
port is resuming
Nov 26 0
Hi,
David Cohen writes:
> Hi Felipe,
>
> On Tue, Dec 01, 2015 at 02:34:34PM -0600, Felipe Balbi wrote:
>
> [snip]
>
>> > +EXPORT_SYMBOL_GPL(intel_usb_mux_register);
>> > +
>> > +void intel_usb_mux_unregister(struct intel_usb_mux *mux)
>> > +{
>> > + extcon_unregister_notifier(&mux->edev, EXTCON
Hi Felipe,
On Tue, Dec 01, 2015 at 02:34:34PM -0600, Felipe Balbi wrote:
[snip]
> > +EXPORT_SYMBOL_GPL(intel_usb_mux_register);
> > +
> > +void intel_usb_mux_unregister(struct intel_usb_mux *mux)
> > +{
> > + extcon_unregister_notifier(&mux->edev, EXTCON_USB_HOST, &mux->nb);
> > + extcon_dev
Hi,
Heikki Krogerus writes:
> Intel Braswell/Cherrytrail has an internal mux that shares
> one USB port between USB Device Controller and xHCI. The
> same mux is found on several SOCs from Intel, but only on
> a few Cherrytrail based platforms the OS is expected to
> configure it. Normally BIOS
Hi,
Heikki Krogerus writes:
> Several Intel PCHs and SOCs have an internal mux that is
> used to share one USB port between USB Device Controller and
> xHCI. The mux is normally handled by System FW/BIOS, but not
> always. For those platforms where the FW does not take care
> of the mux, this dr
Hi Heikki,
Follow my comments below.
On Tue, Dec 01, 2015 at 03:32:37PM +0200, Heikki Krogerus wrote:
> Several Intel PCHs and SOCs have an internal mux that is
> used to share one USB port between USB Device Controller and
> xHCI. The mux is normally handled by System FW/BIOS, but not
> always.
On Tue, Dec 1, 2015 at 2:35 PM, Alan Stern wrote:
>> I'm now sure the host in "non-compliant".
>
> It is non-compliant if it turns off Vbus power during suspend. But
> that may be caused by the platform more than by the controller itself.
>
I wasn't able to find any document that states that VBU
On Tue, Dec 1, 2015 at 11:46 AM, Josh Boyer wrote:
> On Mon, Nov 30, 2015 at 7:47 PM, Dmitry Torokhov
> wrote:
>> On Mon, Nov 30, 2015 at 3:36 PM, Greg Kroah-Hartman
>> wrote:
>>> On Mon, Nov 30, 2015 at 02:56:09PM -0800, Dmitry Torokhov wrote:
On Mon, Nov 30, 2015 at 2:18 PM, Greg Kroah-Ha
On Mon, Nov 30, 2015 at 7:47 PM, Dmitry Torokhov
wrote:
> On Mon, Nov 30, 2015 at 3:36 PM, Greg Kroah-Hartman
> wrote:
>> On Mon, Nov 30, 2015 at 02:56:09PM -0800, Dmitry Torokhov wrote:
>>> On Mon, Nov 30, 2015 at 2:18 PM, Greg Kroah-Hartman
>>> wrote:
>>> > On Mon, Nov 30, 2015 at 01:11:50PM -
On Tue, 1 Dec 2015, Alan Cooper wrote:
> On Tue, Dec 1, 2015 at 11:07 AM, Alan Stern wrote:
> > On Tue, 1 Dec 2015, Oliver Neukum wrote:
> >
> >> On Tue, 2015-12-01 at 10:41 -0500, Alan Stern wrote:
> >> > > A recent patch, 7fa40910e0bf5ef32eca49595d950cb24f6402bf, added a
> >> > > CONNECTED retr
This is the fifth version of a patchset which originally aimed to fix a buggy
touchscreen from ELAN Microelectronics.
Changes since v4:
- Cast HID_ANY_ID to an __u16 so to keep gcc happy on AVR32 arch.
Changes since v3:
- Use HID_ANY_ID to define a vendor-ID-global quirk, as suggested by
Benjam
Like other buggy models that had their fixes [1], the touchscreen with
id 04f3:21b8 from ELAN Microelectronics needs the device-qualifier
quirk. Otherwise, it fails to respond, blocks the boot for a random
amount of time and pollutes dmesg with:
[ 2887.373196] usb 1-5: new full-speed USB device nu
All ELAN hid devices seem to require the ALWAYS_POLL quirk. Let's use
this quirk for all devices from this vendor, rather than maintaining a
list of all its known product IDs.
Tested-by: Adrien Vergé
Signed-off-by: Adrien Vergé
---
drivers/hid/hid-ids.h | 5 -
drivers/hid/usbhid/h
Fixed all comments suggested by the linux-usb list.
changes in v6:
- Removed patches already applied in Balbi's tree
- Cleanups on pre-allocation usb requrests patch
- Fixed indentention on patch 1
- Added patch which fails set_alt if a failure happened while
allocating usb requests
change
This avoids duplication of USB requests for OUT endpoint and
re-enabling endpoints.
Signed-off-by: Felipe F. Tonello
---
drivers/usb/gadget/function/f_midi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/function/f_midi.c
b/drivers/usb/gadget/funct
This ensures that the midi function will only work if the proper number of
IN and OUT requrests are allocated. Otherwise the function will work with less
requests then what the user wants.
Signed-off-by: Felipe F. Tonello
---
drivers/usb/gadget/function/f_midi.c | 3 ++-
1 file changed, 2 insert
This patch introduces pre-allocation of IN endpoint USB requests. This
improves on latency (requires no usb request allocation on transmit) and avoid
several potential probles on allocating too many usb requests (which involves
DMA pool allocation problems).
This implementation also handles better
On Tue, Dec 1, 2015 at 12:12 PM, Alan Cooper wrote:
> On Tue, Dec 1, 2015 at 11:07 AM, Alan Stern wrote:
>> On Tue, 1 Dec 2015, Oliver Neukum wrote:
>>
>>> On Tue, 2015-12-01 at 10:41 -0500, Alan Stern wrote:
>>> > > A recent patch, 7fa40910e0bf5ef32eca49595d950cb24f6402bf, added a
>>> > > CONNEC
On Tue, Nov 24, 2015 at 04:02:05PM +0100, Adrien Vergé wrote:
> All ELAN hid devices seem to require the ALWAYS_POLL quirk. Let's use
> this quirk for all devices from this vendor, rather than maintaining a
> list of all its known product IDs.
>
> Tested-by: Adrien Vergé
> Signed-off-by: Adrien V
On Mon, Nov 23, 2015 at 10:28:25AM +0100, Johan Hovold wrote:
> On Sun, Nov 22, 2015 at 11:47:17AM +0100, Jonas Jonsson wrote:
> > Some modems, such as the Telit UE910, are using an Infineon Flash Loader
> > utility. It has two interfaces, 2/2/0 (Abstract Modem) and 10/0/0 (CDC
> > Data). The latte
On Thu, Nov 26, 2015 at 09:24:23AM +0100, Johan Hovold wrote:
> Hi Greg,
>
> Some minor device-id fixes for v4.4-rc3. Note that I included the patch
> that blacklists the flash-loader device in cdc-acm.
>
> Thanks,
> Johan
>
>
> The following changes since commit 1ec218373b8ebda821aec00bb156a9c
On Mon, Nov 23, 2015 at 10:47:27AM -0600, Felipe Balbi wrote:
> Hi Greg,
>
> Here's my second round of fixes for current -rc as promissed.
>
> Let me know if you want anything to be changed, but response
> may be slow.
>
> 'vacation-mode' is a major mode which prevents emacs from being
> used :-
Hi!
Alexandre Belloni wrote:
> ohci_hcd_at91_drv_probe() has four at91_for_each_port. They can be merged
> into two loops without changing the driver behaviour.
Not so much, I bisected the following panic to the commit matching this patch
(e4df92279fd9e01532f65e5ba397877799ed6252).
Reverting tha
On Tue, Dec 1, 2015 at 11:07 AM, Alan Stern wrote:
> On Tue, 1 Dec 2015, Oliver Neukum wrote:
>
>> On Tue, 2015-12-01 at 10:41 -0500, Alan Stern wrote:
>> > > A recent patch, 7fa40910e0bf5ef32eca49595d950cb24f6402bf, added a
>> > > CONNECTED retry for a different reason and I could simply increase
On Tue, Dec 01, 2015 at 08:53:57AM +0100, Oliver Neukum wrote:
> On Mon, 2015-11-30 at 17:09 -0800, Greg Kroah-Hartman wrote:
> > > that would loop through endpoints so that drivers do not have to
> > > open-code the loop and we indeed need to fix the drivers that
> > blindly
> > > grab endpoints a
On Fri, 20 Nov 2015, Ioan-Adrian Ratiu wrote:
> The critical section protected by usbhid->lock in hid_ctrl() is too
> big and because of this it causes a recursive deadlock. "Too big" means
> the case statement and the call to hid_input_report() do not need to be
> protected by the spinlock (no UR
On Tue, 1 Dec 2015, Oliver Neukum wrote:
> On Tue, 2015-12-01 at 10:41 -0500, Alan Stern wrote:
> > > A recent patch, 7fa40910e0bf5ef32eca49595d950cb24f6402bf, added a
> > > CONNECTED retry for a different reason and I could simply increase
> > > this retry time. Any thoughts?
> >
> > I don't kno
On Wed, 2015-11-25 at 17:50 +0100, Hans de Goede wrote:
> From: Reinder de Haan
>
> Note this commit only adds support for phys 1-3, phy 0, the otg phy,
> is
> not yet (fully) supported after this commit.
>
> Signed-off-by: Reinder de Haan
> Signed-off-by: Hans de Goede
> ---
> Changes in v2:
On Mon, 30 Nov 2015, Mathias Nyman wrote:
> usb2 ports need to signal resume for 20ms before moving to U0 state.
> Both device and host can initiate resume.
>
> On host initated resume port is set to resume state, sleep 20ms,
> and finally set port to U0 state.
That's an odd approach. The assum
On Tue, 2015-12-01 at 10:41 -0500, Alan Stern wrote:
> > A recent patch, 7fa40910e0bf5ef32eca49595d950cb24f6402bf, added a
> > CONNECTED retry for a different reason and I could simply increase
> > this retry time. Any thoughts?
>
> I don't know. You've got a non-compliant host combined with an
On Mon, 30 Nov 2015, Alan Cooper wrote:
> I'm seeing a problem that looks like an issue in the USB-Persist
> feature. I'm finding that all my 3.0 thumb drives are torn down and
> brought back up (fail USB-Persist) during resume from "suspend to
> memory" if they are plugged into a 2.0 EHCI/OHCI on
On Tue, 1 Dec 2015, Hans Yang wrote:
> When a USB 3.0 mass storage device is disconnected in transporting
> state, storage device driver may handle it as a transport error and
> reset the device by invoking usb_reset_and_verify_device()
> and following could happen:
>
> in usb_reset_and_verify_de
Hi,
Mathias Nyman writes:
> On 01.12.2015 16:32, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Mathias Nyman writes:
>>> usb2 ports need to signal resume for 20ms before moving to U0 state.
>>
>> at least 20ms ;-) Recently, we decided to drive resume for 40ms to
>> support devices with broken FW.
>>
>
>
On 01.12.2015 16:32, Felipe Balbi wrote:
Hi,
Mathias Nyman writes:
usb2 ports need to signal resume for 20ms before moving to U0 state.
at least 20ms ;-) Recently, we decided to drive resume for 40ms to
support devices with broken FW.
True, but specs talk about 20ms, and I'm just trying
Hi,
Rasmus Villemoes writes:
> aRevision is only used once, so we might as well do the formatting as
> part of the pr_debug. This eliminates the stack buffer, and avoids
> doing the formatting at all when pr_debug is compiled out.
>
> Signed-off-by: Rasmus Villemoes
this needs to be rebased on
The documentation wrongly implied that it is a core parameter.
That is not true. If usbcore is compiled as a module, a module
parameter needs a prefix.
Signed-off-by: Oliver Neukum
---
Documentation/kernel-parameters.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Doc
The module should fail to load.
Signed-off-by: Oliver Neukum
CC: sta...@kernel.org
---
drivers/usb/host/xhci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 6bbe3c3..1efb1f8 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/ho
It shouldn't matter how usbcore is compiled. As it is a subsystem,
the correct way to use nousb should be usbcore.nousb
Signed-off-by: Oliver Neukum
---
drivers/usb/core/usb.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 1382c90..9
Dear Oliver,
I applied your patch and recompiled my kernel (4.2.3) on the host.
However I'm not getting more debug info. How can I enable the output of
netdev_dbg ?
I've enabled debug-support in my kernel and changed the loglevel:
# cat /proc/sys/kernel/printk
8 4 1 7
Also th
Hi,
Mathias Nyman writes:
> usb2 ports need to signal resume for 20ms before moving to U0 state.
at least 20ms ;-) Recently, we decided to drive resume for 40ms to
support devices with broken FW.
> Both device and host can initiate resume.
>
> On host initated resume port is set to resume stat
Hi Li,
Li Jun writes:
>> > I am sorry I did not consider the legacy OTG design, this patch should
>> > be dropped.
>>
>> there is no "legacy" OTG design. OTG requires a bus suspend to enter
>> HNP, and that's achieved by stopping all transfers and avoid new URB
>> submission so usbcore can put
On Tue, 2015-12-01 at 14:44 +0100, Bjørn Mork wrote:
> Oliver Neukum writes:
>
> > On Tue, 2015-12-01 at 10:41 +0100, Alexander Krause wrote:
> >
> >> Messages on the host are:
> >> [44685.879438] usb 3-1.2: new high-speed USB device number 83 using
> >> xhci_hcd
> >> [44685.979721] usb 3-1.2: co
Oliver Neukum writes:
> On Tue, 2015-12-01 at 10:41 +0100, Alexander Krause wrote:
>
>> Messages on the host are:
>> [44685.879438] usb 3-1.2: new high-speed USB device number 83 using
>> xhci_hcd
>> [44685.979721] usb 3-1.2: config 1 interface 0 altsetting 0 endpoint
>> 0x83 has an invalid bInte
Hi,
This is a driver for an internal mux which is available on most modern
Intel platforms that shares an USB port between USB Device Controller
and xHCI. Normally BIOS or ACPI take care of it, but on some platforms
that is not possible, and the OS has to control it.
When the mux needs to be hand
Several Intel PCHs and SOCs have an internal mux that is
used to share one USB port between USB Device Controller and
xHCI. The mux is normally handled by System FW/BIOS, but not
always. For those platforms where the FW does not take care
of the mux, this driver is needed.
Signed-off-by: Heikki Kr
Intel Braswell/Cherrytrail has an internal mux that shares
one USB port between USB Device Controller and xHCI. The
same mux is found on several SOCs from Intel, but only on
a few Cherrytrail based platforms the OS is expected to
configure it. Normally BIOS takes care of it.
The driver for the mux
v3..v4:
- rebased onto current Nicholas' tree
(b1c06ebadd277421c3f59569708ed356eb5dded5,
tcm_usb_gadget: Fix enabled attribute failure)
The commit hash-id onto which the series is rebased should be:
1cc92aed7192caa8987bba0f88226f57e9b4ed73
Sorry for confusion,
AP
--
To unsubscribe from th
Prepare for factoring out f_tcm from a legacy gadget.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/usb/gadget/legacy/tcm_usb_gadget.c | 25 +
drivers/usb/gadget/legacy/tcm_usb_gadget.h | 3 +--
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/u
Prepare for splitting tcm_usb_gadget into legacy gadget proper and f_tcm.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/usb/gadget/legacy/tcm_usb_gadget.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadge
Do not directly use file static strings definitions in instances of f_tcm.
Instead use usb_gstrings_attach.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/usb/gadget/function/f_tcm.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/gadget/func
Simplify the function.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/usb/gadget/legacy/tcm_usb_gadget.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index b6e46a0..98064b
Converting tcm to the new function interface requires converting
USB tcm's function code and its users.
This patch converts the f_tcm.c to the new function interface.
The file can be now compiled into a separate module usb_f_tcm.ko.
The old function interface is provided by means of preprocessor
The only instance is guaranteed with TPG_INSTANCES defined to 1.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/usb/gadget/function/f_tcm.c | 9 -
drivers/usb/gadget/function/tcm.h | 2 --
2 files changed, 11 deletions(-)
diff --git a/drivers/usb/gadget/function/f_tcm.c
b/drivers/u
Convert the only user of old tcm function interface so that the old
interface can be removed.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/usb/gadget/legacy/Kconfig | 1 +
drivers/usb/gadget/legacy/tcm_usb_gadget.c | 62 +-
2 files changed, 53 insertions
Prepare for converting tcm to new function registration interface.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/usb/gadget/function/f_tcm.c| 2151
drivers/usb/gadget/function/tcm.h | 132 ++
drivers/usb/gadget/legacy/tcm_usb_gadget.c | 2132 +---
Dear All,
This series adds support to tcm usb gadget for composing it with configfs.
@target-devel folks: You might be wondering why add configfs for something
which already supports configfs. In tcm_usb_gadget configfs has beeen
used for configuring the SCSI target part, but the usb gadget part
Allow using the tcm function as a component of a gadget composed with
ConfigFS.
Signed-off-by: Andrzej Pietrasiewicz
---
Documentation/ABI/testing/configfs-usb-gadget-tcm | 6 ++
drivers/usb/gadget/Kconfig| 14 +
drivers/usb/gadget/function/f_tcm.c | 72
There are no old function interface users left.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/usb/gadget/function/f_tcm.c | 87 +++--
1 file changed, 6 insertions(+), 81 deletions(-)
diff --git a/drivers/usb/gadget/function/f_tcm.c
b/drivers/usb/gadget/functi
Simplify function code.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/usb/gadget/legacy/tcm_usb_gadget.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index 9
Hi
There are some xhci resume related issues which might be related to this.
Host and device initiated resume functions race, and we end up with this
similar output:
Nov 26 02:24:18 vostro kernel: xhci_hcd :0b:00.0: suspend failed because a
port is resuming
Nov 26 02:24:18 vostro kernel:
On Tue, Nov 03, 2015 at 09:51:11PM -0600, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen writes:
> > On Tue, Nov 03, 2015 at 07:56:55AM -0600, Felipe Balbi wrote:
> >>
> >> Hi,
> >>
> >> Nathan Sullivan writes:
> >> > The USB OTG support currently depends on power management
> >> > (CONFIG_PM) be
On Tue, 2015-12-01 at 10:41 +0100, Alexander Krause wrote:
> Messages on the host are:
> [44685.879438] usb 3-1.2: new high-speed USB device number 83 using
> xhci_hcd
> [44685.979721] usb 3-1.2: config 1 interface 0 altsetting 0 endpoint
> 0x83 has an invalid bInterval 32, changing to 9
> [44685.
Hi all,
following from bugzilla.kernel.org I'm now writing to this group.
The short summary is, that I'm trying to get the USB- gadget running
with a ARM device.
In my case it's the Arietta G25 (Atmel AT91SAM9G25 SoC) from ACME:
http://www.acmesystems.it/arietta
Everything seems to work at the
Hi Nicholas,
W dniu 29.11.2015 o 07:16, Nicholas A. Bellinger pisze:
Hi Andrzej & Co,
On Mon, 2015-11-23 at 09:22 +0100, Andrzej Pietrasiewicz wrote:
W dniu 15.11.2015 o 00:27, Nicholas A. Bellinger pisze:
Hi Andrzej & Co,
Ok, I've added both series into target-pending/queue-next so
1 - 100 of 102 matches
Mail list logo
