On Mon, Aug 24, 2015 at 04:21:11PM +0300, Roger Quadros wrote:
> Hi,
>
> This series centralizes OTG/Dual-role functionality in the kernel.
> As of now I've got Dual-role functionality working pretty reliably on
> dra7-evm and am437x-gp-evm.
>
> DWC3 controller and platform related patches will b
Le 02/12/2015 20:36, Alexandre Belloni a écrit :
> The interrupt handler, ohci_hcd_at91_overcurrent_irq may be called right
> after registration. At that time, pdev->dev.platform_data is not yet set,
> leading to a NULL pointer dereference.
>
> Fixes: e4df92279fd9 (USB: host: ohci-at91: merge loop
Peter,
On 03/12/15 13:49, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:11PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> This series centralizes OTG/Dual-role functionality in the kernel.
>> As of now I've got Dual-role functionality working pretty reliably on
>> dra7-evm and am437x-gp-evm.
>>
>>
Hi Felipe,
On 12/02/2015 07:55 PM, Felipe Balbi wrote:
> So far, dwc3 has always missed request->zero
> handling for every endpoint. Let's implement
> that so we can handle cases where transfer must
> be finished with a ZLP.
>
> Note that dwc3 is a little special. Even though
> we're dealing with
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
Changes since v1:
- Using xhci_find_next_ext_cap() as suggested by Baolu
- Protection agains unbalanced uregistering as suggested by David Cohen
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 xHC
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
On Tue, Dec 01 2015, Felipe Balbi wrote:
> 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-of
Hi Heikki,
I'm sorry for delay reply.
On 2015년 12월 03일 18:29, 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. For those platfor
Hello.
On 12/2/2015 10:11 PM, John Youn wrote:
From: Douglas Anderson
Previously dwc2_get_hwparams() was changing GUSBCFG and not putting it
back the way it was (specifically it set and cleared FORCEHOSTMODE).
Since we want to move dwc2_core_reset() _before_ dwc2_get_hwparams() we
should make
On 12/3/2015 5:46 PM, Sergei Shtylyov wrote:
From: Douglas Anderson
Previously dwc2_get_hwparams() was changing GUSBCFG and not putting it
back the way it was (specifically it set and cleared FORCEHOSTMODE).
Since we want to move dwc2_core_reset() _before_ dwc2_get_hwparams() we
should make su
Hi,
Robert Baldyga writes:
>> @@ -1171,6 +1197,17 @@ static int dwc3_gadget_ep_queue(struct usb_ep *ep,
>> struct usb_request *request,
>>
>> spin_lock_irqsave(&dwc->lock, flags);
>> ret = __dwc3_gadget_ep_queue(dep, req);
>> +
>> +/*
>> + * Okay, here's the thing, if gadget
So far, dwc3 has always missed request->zero
handling for every endpoint. Let's implement
that so we can handle cases where transfer must
be finished with a ZLP.
Note that dwc3 is a little special. Even though
we're dealing with a ZLP, we still need a buffer
of wMaxPacketSize bytes; to hide that d
On Thu, 3 Dec 2015 bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=89511
>
> bradha...@fastmail.us changed:
>
>What|Removed |Added
>
>
On Thu, 3 Dec 2015, Nicolas Ferre wrote:
> Le 02/12/2015 20:36, Alexandre Belloni a �crit :
> > The interrupt handler, ohci_hcd_at91_overcurrent_irq may be called right
> > after registration. At that time, pdev->dev.platform_data is not yet set,
> > leading to a NULL pointer dereference.
> >
> >
On Thu, 3 Dec 2015, Steinar H. Gunderson wrote:
> On Wed, Dec 02, 2015 at 10:54:52AM -0500, Alan Stern wrote:
> >> [ 28.796244] DMAR: Allocating domain for 2-2 failed
> > I don't know what the reason is for that. It may be that your kernel
> > isn't configured to allocate as much coherent me
dt1:uname -a
Linux dt1 3.19.0-33-generic #38~14.04.1-Ubuntu SMP Fri Nov 6 18:17:28
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
See attached for relevant kernel log.
I have the error:
blk_update_request: critical target error, dev sdb, sector 0
JBD2: recovery failed
EXT4-fs (sdb): error loading jou
On Thu, 3 Dec 2015, brad wrote:
> dt1:uname -a
> Linux dt1 3.19.0-33-generic #38~14.04.1-Ubuntu SMP Fri Nov 6 18:17:28
> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> See attached for relevant kernel log.
The log was short enough to be included directly in the email message
rather than as an att
Thanks! That worked. I was able to read & write. How to make that
permanent?
On 12/03/2015 10:00 AM, Alan Stern wrote:
On Thu, 3 Dec 2015, brad wrote:
dt1:uname -a
Linux dt1 3.19.0-33-generic #38~14.04.1-Ubuntu SMP Fri Nov 6 18:17:28
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
See attached
It seems to be permanent? After reboot I still have this and I can
mount the drive
dt1:cat /sys/block/sdb/device/scsi_disk/4\:0\:0\:0/cache_type
write through
On 12/03/2015 10:17 AM, brad wrote:
Thanks! That worked. I was able to read & write. How to make that
permanent?
On 12/03/201
On Thu, 3 Dec 2015, brad wrote:
> Thanks! That worked. I was able to read & write. How to make that
> permanent?
You can create a udev rule that will do it automatically.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord.
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management proto
Signed-off-by: Bjørn Mork
---
Documentation/ABI/testing/sysfs-class-net-qmi | 23 +++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-net-qmi
diff --git a/Documentation/ABI/testing/sysfs-class-net-qmi
b/Documentation/ABI/testing/sys
This turned out to be a bootloader device ID. No need for
that in this driver. It will only provide a single serial
function.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
in
MDM9x30 based modems appear to go into a deeper sleep when
suspended without "Remote Wakeup" enabled. The QMI interface
will not respond unless a "set DTR" control request is sent
on resume. The effect is similar to a QMI_CTL SYNC request,
resetting (some of) the firmware state.
We allow userspac
We add new device IDs all the time, often without any testing on
actual hardware. This is usually OK as long as the device is similar
to already supported devices, using the same chipset and firmware
basis. But the Sierra Wireless MC7455 is an example of a new chipset
generation. Adding it based o
Signed-off-by: Bjørn Mork
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea1751283b49..e9d444a88e48 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11159,6 +11159,13 @@ L: linux-usb@vger.kernel.org
S: Supported
F: drivers/us
Assume the minidriver has taken care of all L2 header parsing
if it sets skb->protocol. This allows the minidriver to
support non-ethernet L2 headers, and even operate without
any L2 header at all.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/usbnet.c | 5 -
1 file changed, 4 insertions(+)
On Thu, 3 Dec 2015, brad wrote:
> It seems to be permanent? After reboot I still have this and I can
> mount the drive
>
> dt1:cat /sys/block/sdb/device/scsi_disk/4\:0\:0\:0/cache_type
> write through
I don't understand. The change you make by writing to the sysfs file
is not permanent. It
This is an old problem, but it was never resolved and it still affects
people (Bugzilla #89511). In short, there are USB-(S)ATA bridges that
claim to be write-back but don't support the SYNCHRONIZE CACHE command.
This causes errors when filesystems try to flush data out to the disk.
On Mon, 22
Well, If you don't understand, then I sure don't :)
When I wrote 'temporary write through' to cache_type, and cat'd the file
it read 'write through'
After 2 reboots and at least one power cycle on the ext HD cache_type
still has 'write through'
dmesg shows this now:
... [sdb] Assuming drive
Hello.
On 12/03/2015 12:29 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 i
On 12/03/2015 12:29 PM, 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. For those platforms where the FW does not take care
of the mux
On Thu, 2015-12-03 at 19:24 +0100, Bjørn Mork wrote:
> We add new device IDs all the time, often without any testing on
> actual hardware. This is usually OK as long as the device is similar
> to already supported devices, using the same chipset and firmware
> basis. But the Sierra Wireless MC7455
On Thu, 2015-12-03 at 19:24 +0100, Bjørn Mork wrote:
> Assume the minidriver has taken care of all L2 header parsing
> if it sets skb->protocol. This allows the minidriver to
> support non-ethernet L2 headers, and even operate without
> any L2 header at all.
>
> Signed-off-by: Bjørn Mork
Acked-b
On Thu, 3 Dec 2015, brad wrote:
> Well, If you don't understand, then I sure don't :)
> When I wrote 'temporary write through' to cache_type, and cat'd the file
> it read 'write through'
>
> After 2 reboots and at least one power cycle on the ext HD cache_type
> still has 'write through'
>
> d
On Thu, Dec 03, 2015 at 10:37:27AM -0500, Alan Stern wrote:
>> FWIW, I tried against &ps->dev->bus->controller, and it didn't give me any
>> error messages, but still returns NULL.
> I'm at a loss.
Seemingly controller is already a pointer, so the & is redundant. No idea why
it didn't crash plai
struct usb_request have 3 flags which might be
important to know about during debug. This patch
shows each of the 3 flags as a single letter:
z -> for zero
s -> short not okay
i -> interrupt
A capital letter means the feature is enabled
while a lower case letter means it is disabled;
Thus 'zsI'
On Thu, 3 Dec 2015, Steinar H. Gunderson wrote:
> On Thu, Dec 03, 2015 at 10:37:27AM -0500, Alan Stern wrote:
> >> FWIW, I tried against &ps->dev->bus->controller, and it didn't give me any
> >> error messages, but still returns NULL.
> > I'm at a loss.
>
> Seemingly controller is already a poi
My recent Intel box is spewing these messages:
xhci_hcd :00:14.0: xHCI Host Controller
xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2
usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2:
On Thu, Dec 3, 2015 at 2:26 PM, Don Zickus wrote:
> My recent Intel box is spewing these messages:
>
> xhci_hcd :00:14.0: xHCI Host Controller
> xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2
> usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
> usb usb2: New
On Thu, Dec 03, 2015 at 10:18:20PM +0100, Steinar H. Gunderson wrote:
> But you still think usb_alloc_coherent() is the better way to go? Should be
> easy enough to change, just let me know.
I must be doing something wrong, because I don't seem to get any frames
from my video capture, and when I c
On driver detach, devm_phy_release() will put a refcount to
the phy, so gets a refconut to it before return.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-core.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-
when use the default value 8 of RG_USB20_SQTH, the HS receiver
sensitivity test of HQA will fail, set it as 2 to fix up the
issue.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-mt65xx-usb3.
calibrate HS slew rate and switch 100uA current to SSUSB
to improve HS eye diagram of HQA test.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c | 99 +--
1 file changed, 96 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/phy-mt65xx-us
when ip fail to enter sleep mode, register access protection will
be disabed, at the same time if all clocks are disabled, access
register will hang up AHB bus.
the common case causes ip sleep fail is that after all ports enter
U3 but before ip enters sleep mode, a port receives a resume
signal('K'
From: "Du, Changbin"
Queue a request to disabled ep doesn't make sense, and induce caller
make mistakes.
Here is a example for the android mtp gadget function driver. A mem
corruption can happen on below senario.
1) On disconnect, mtp driver disable its EPs,
2) During send_file_work and receive
From: "Du, Changbin"
When usb_ep_enable on a enabled ep, the configuration of the ep probably
has changed. In this scenario, the ep configuration in hw should be
reprogrammed by udc driver. Hence, it is better to return an error to
inform the caller.
Signed-off-by: Du, Changbin
---
include/lin
From: "Du, Changbin"
To stop an out endpoint, software should set sets the Global OUT NAK,
but not the Global Non-periodic IN NAK. This driver bug leads the out-ep
failed be in disabled state with below error.
dwc2_hsotg_ep_stop_xfr: timeout DOEPCTL.EPDisable
Signed-off-by: Du, Changbin
---
d
49 matches
Mail list logo
