On Fri, 2013-08-16 at 22:25 +0200, Yann Cantin wrote:
> +/* IRQ */
> +static int ebeam_read_data(struct ebeam_device *ebeam, unsigned char *pkt)
> +{
> +
> +/*
> + * Packet description : 8 bytes
> + *
> + * nop packet : FF FF FF FF FF FF FF FF
> + *
> + * pkt[0] : Sensors
> + * bit 1 : ultraso
On Tue, Aug 06, 2013 at 03:03:29PM +0300, Jussi Kivilinna wrote:
> Patch fixes alauda not to use stack as URB transfer_buffer. URB buffers need
> to
> be DMA-able, which stack is not.
>
> Patch is only compile tested.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jussi Kivilinna
> ---
> driv
Brian Norris writes:
> On Tue, Aug 06, 2013 at 03:03:29PM +0300, Jussi Kivilinna wrote:
>> Patch fixes alauda not to use stack as URB transfer_buffer. URB buffers need
>> to
>> be DMA-able, which stack is not.
>>
>> Patch is only compile tested.
>>
>> Cc: sta...@vger.kernel.org
>> Signed-off-by
This patch introduces ehci_disable_event(), which is applied on
IAA_WATCHDOG and START_UNLINK_INTR timeouts if the two corresponding
events(IAA and intr URB submission) happened, so that we may avoid
unnecessary CPU wakeup by canceling the timer.
One simple test indicates about 7~8 timer expiratio
Hello Lee Jones,
This is a semi-automatic email about new static checker warnings.
The patch 2968da0b2c72: "usb: musb: ux500: attempt to find channels
by name before using pdata" from May 15, 2013, leads to the following
Smatch complaint:
drivers/usb/musb/ux500_dma.c:335 ux500_dma_controller_s
We need to unlock and enable IRQs before returning on error.
Signed-off-by: Dan Carpenter
---
I cannot compile this code.
diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index e64701d..5c42fc1 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cp
"ret" needs to be signed for the error handling to work.
Signed-off-by: Dan Carpenter
---
I can't compile this.
diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 844ab68..d266861 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
On Wed, Aug 21, 2013 at 09:59:27AM +0200, Bjørn Mork wrote:
> Brian Norris writes:
> > On Tue, Aug 06, 2013 at 03:03:29PM +0300, Jussi Kivilinna wrote:
> >> Patch fixes alauda not to use stack as URB transfer_buffer. URB buffers
> >> need to
> >> be DMA-able, which stack is not.
> >>
> >> Patch i
The "goto out" statements were wrong. We aren't holding any locks at
that point so we should return directly.
Signed-off-by: Dan Carpenter
---
I can't compile this.
diff --git a/drivers/usb/gadget/atmel_usba_udc.c
b/drivers/usb/gadget/atmel_usba_udc.c
index 40d2338..2cb52e0 100644
--- a/driver
There is no need to get an interface specification if we know it's the
wrong one.
Signed-off-by: Daniel Gimpelevich
---
drivers/net/usb/hso.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index cba1d46..5fb36ed 1006
As Sergei Shtylyov explained in the #mipslinux IRC channel:
[Mon 2013-08-19 12:28:21 PM PDT] guys, are you sure it's not "DMA
off stack" case?
[Mon 2013-08-19 12:28:35 PM PDT] it's a known stack corruptor on
non-coherent arches
[Mon 2013-08-19 12:31:48 PM PDT] headless: for usb/ehci?
[Mon 201
On Tue, 2013-08-20 at 23:29 -0700, David Miller wrote:
> Please submit this with a more appropriate subject line.
>
> After '[PATCH] ' there should be a subsystem or driver name
> prefix, followed up a semicolon. Here it could be "hso: ",
> so something like:
>
> [PATCH] hso: Fix stack corrupti
On 13.08.2013 14:40, Daniel Mack wrote:
> dsps_suspend() and dsps_resume() are called with the device that has the
> glue assigned as drvdata. Using dev->parent seems wrong and causes a
> NULL pointer exception on an AM33xx board.
>
> The code was introduced by commit c68bb4c6 ("usb: musb: dsps: c
Commit 7e8d5cd93fac ("USB: Add EHCI support for MX27 and MX31 based
boards") introduced code that could potentially lead to a NULL pointer
dereference on driver removal.
Fix this by checking for the value of pdata before dereferencing it.
Signed-off-by: Daniel Mack
Reported-by: Dan Carpenter
--
On Tue, Aug 20, 2013 at 03:50:37PM -0400, Alan Stern wrote:
> On Tue, 20 Aug 2013, Krzysztof Mazur wrote:
>
> > On Tue, Aug 20, 2013 at 02:18:57PM -0400, Alan Stern wrote:
> > > On Tue, 20 Aug 2013, Krzysztof Mazur wrote:
> > >
> > > > Ignoring usb_hub_create_port_device() errors cause later NULL
On 21.08.2013 11:41, Brian Norris wrote:
> On Wed, Aug 21, 2013 at 09:59:27AM +0200, Bjørn Mork wrote:
>> Brian Norris writes:
>>> On Tue, Aug 06, 2013 at 03:03:29PM +0300, Jussi Kivilinna wrote:
Patch fixes alauda not to use stack as URB transfer_buffer. URB buffers
need to
be DMA
>333if (!ux500_channel->dma_chan)
>334ux500_channel->dma_chan =
>335
> dma_request_channel(mask,
>336
and the attachment file is the result of
scripts/checkpatch.pl patch-commit-20130821
I'm sorry that I'm still finding the way to signed-off
3, Thanks again for your correct suggestion and Please check
the new device dr
Dear Francois Romieu :
1, all the format problems have been fixed
2, sr9700.h registers definition is re-written
3, Thanks for your detail checking and I have beed
scripts/checkpatch.pl the patch and please check it.
[PATCH] :
diff --git a/drivers/net/usb/Kconfi
Dear Joe :
Thanks a lot and I have been fixed all the problems mentioned
above. please check the following patch and thanks again.
[PATCH] :
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 287cc62..a94b196 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/n
On Wed, Aug 21, 2013 at 12:46 AM, Peter Chen wrote:
> Please compile g_ether as loadable module, not build-in.
Thanks, it works if I build g_ether as module on mx6.
mx28evk works fine if I build it as built-in though.
Any ideas of why g_ether does not work if built-in on mx6?
Thanks,
Fabio E
On Wed, 2013-08-21 at 18:07 +0800, liujunliang_ljl wrote:
> Thanks a lot and I have been fixed all the problems mentioned
> above. please check the following patch and thanks again.
Just trivial comments below:
> diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
[]
Dan Carpenter's automatic Smatch checker found an anomaly in the ux500
MUSB driver, whereby board data was checked before use in all but one
occasion. It is believed that it needs to be checked every time.
Smatch complaint:
drivers/usb/musb/ux500_dma.c:335 ux500_dma_controller_start()
e
On Tue, 2013-08-20 at 18:01 +0100, Pawel Moll wrote:
> On Tue, 2013-08-20 at 16:06 +0100, Pawel Moll wrote:
> > On Tue, 2013-08-20 at 16:01 +0100, Kumar Gala wrote:
> > > On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
> > >
> > > >
> > > > Hi,
> > > >
> > > > On Tue, 2013-08-20 at 09:33 -0
Hi Stephen,
On 8/20/2013 10:23 PM, Stephen Warren wrote:
>ID pins are connected to pcf8575, and the pcf8575's interrupt line is
>inturn connected to
>gpio bank6 pin 11, we use this gpio interrupt to detect the ID pin change.
In that case, the PCF8575 node needs to be a GPIO controller and an IR
From: "Ivan T. Ivanov"
DWC3 glue layer is hardware layer around Synopsys DesignWare
USB3 core. Its purpose is to supply Synopsys IP with required
clocks, voltages and interface it with the rest of the SoC.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/dwc3/Kconfig|8 +++
drivers/usb/dw
From: "Ivan T. Ivanov"
MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
(SNPS) and HS, SS PHY's control and configuration registers.
It could operate in device mode (SS, HS, FS) and host
mode (SS, HS, FS, LS).
Signed-off-by: Ivan T. Ivanov
---
.../devicetree/bindings/usb/msm-ssusb.t
From: "Ivan T. Ivanov"
Hi,
Here is fifth version of MSM USB3 drivers patches.
Changes since v4:
* Substitute references to "wc3" with just "dw" in USB PHY drivers and
file names. This is to indicate that the PHY's are DesignWare, but
not necessarily related to DWC3 IP core.
Changes since
From: "Ivan T. Ivanov"
These drivers handles control and configuration of the HS
and SS USB PHY transceivers. They are part of the driver
which manage Synopsys DesignWare USB3 controller stack
inside Qualcomm SoC's.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/Kconfig | 11 ++
d
On Wed, 21 Aug 2013, Ming Lei wrote:
> This patch introduces ehci_disable_event(), which is applied on
> IAA_WATCHDOG and START_UNLINK_INTR timeouts if the two corresponding
> events(IAA and intr URB submission) happened, so that we may avoid
> unnecessary CPU wakeup by canceling the timer.
>
> O
On Wed, 21 Aug 2013, Krzysztof Mazur wrote:
> > We should never have maxchild < bNbrPorts (unless maxchild is 0). But
> > just in case we do, changing the code is a good idea.
> >
> > Besides, "hub->maxchild" is shorter and easier to read than
> > "hub->descriptor->bNbrPorts". :-)
> >
>
> It
Commit c1117afb8589 (USB: OHCI: make ohci-pci a separate driver)
neglected to preserve the entries for the pci_suspend and pci_resume
driver callbacks. As a result, OHCI controllers don't work properly
during suspend and after hibernation.
This patch adds the missing callbacks to the driver.
Sig
From: Felipe Balbi
DWC3 enables USB3 functionality for OMAP5 boards,
it's safe to enable those drivers in omap2plus_defconfig.
Signed-off-by: Felipe Balbi
Acked-by: Tony Lindgren
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/configs/omap2plus_defconfig |9 +
1 file changed,
From: Felipe Balbi
USB3 block has a 64KiB space, another 64KiB is
used for the wrapper.
Without this change, resource_size() will get
confused and driver won't probe because size
will be negative.
Signed-off-by: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.d
From: Benoit Cousson
without that hwmod data, USB3 will not in OMAP5 boards.
Signed-off-by: Benoit Cousson
Signed-off-by: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45
1 file changed, 45 insertions(+)
d
From: Felipe Balbi
Without this node, there will be no palmas
driver to notify dwc3 that a cable has
been connected and, without that, dwc3
will never initialize.
[ kis...@ti.com: added dt properties for enabling vbus/id interrupts and fixed
vbus-supply value after SMPS10 is modeled as 2 regulat
From: Felipe Balbi
With these patches (plus a few others on the driver side which
will be going upstream soon) I could get functional USB3 with my
omap5-uevm platform.
Changes since v2:
- added dt properties for enabling vbus/id interrupts and fixed
vbus-supply value after SMPS10 is mode
From: Felipe Balbi
this patch fixes the DTS data for ocp2scp
node by adding the missing reg property.
Signed-off-by: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/o
On Wed, Aug 21, 2013 at 10:23 PM, Alan Stern wrote:
>
> Okay. You can add
>
> Acked-by: Alan Stern
>
> and submit it as a version-2 patch.
I think Greg will add the ack, so needn't v2.
>
> By the way, even though it's a little late to ask this... Why did you
> decide to move only the giveback
Hi Kishon,
On 21/08/2013 16:31, Kishon Vijay Abraham I wrote:
From: Felipe Balbi
With these patches (plus a few others on the driver side which
will be going upstream soon) I could get functional USB3 with my
omap5-uevm platform.
Changes since v2:
- added dt properties for enabling vb
On Tue, 20 Aug 2013, Kevin Archer wrote:
> Here are the registers for :00:1a.0 and :00:1d.0 prior to
> inserting any usb 2.0 device
> I have not included the "after" logs as there were no changes that
> occurred to the file(s) after a device was plugged in.
Forget about the 1d.0 stuff; th
On Tue, 20 Aug 2013, Kevin Archer wrote:
> DMESG log from CONFIG_DUMMY_IRQ per your instructions
>
> [ 8561.353244] ath9k: ath9k: Driver unloaded
> [ 8627.529948] ehci-pci :00:1a.0: remove, state 1
> [ 8627.529961] ehci-pci :00:1a.0: roothub graceful disconnect
> [ 8627.529973] usb usb1:
On Wed, 21 Aug 2013, Ming Lei wrote:
> > By the way, even though it's a little late to ask this... Why did you
> > decide to move only the giveback routine into a tasklet, instead of
> > moving the entire interrupt handler?
>
> Looks below reasons in my mind before preparing the tasklet patch:
>
Commit 94ae9843 (usb: phy: rename all phy drivers to phy-$name-usb.c)
renamed drivers/usb/phy/otg_fsm.h to drivers/usb/phy/phy-fsm-usb.h
but changed drivers/usb/phy/phy-fsm-usb.c to include not existing
"phy-otg-fsm.h" instead of new "phy-fsm-usb.h". This breaks building:
...
drivers/usb/phy/ph
Wrong capability bit was checked for best effort service latency.
bit 20 indicate port is BESL LPM capable (BLC),
bit 19 is hardware LPM capable (HLC)
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ext-caps.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drive
On Wed, Aug 21, 2013 at 06:06:02PM +0800, liujunliang_ljl wrote:
> Dear Francois Romieu :
>
> 1, all the format problems have been fixed
>
> 2, sr9700.h registers definition is re-written
>
> 3, Thanks for your detail checking and I have beed
> scripts/checkpatch.pl the
On Wed, Aug 21, 2013 at 01:43:19AM -0700, Daniel Gimpelevich wrote:
> As Sergei Shtylyov explained in the #mipslinux IRC channel:
> [Mon 2013-08-19 12:28:21 PM PDT] guys, are you sure it's not "DMA
> off stack" case?
> [Mon 2013-08-19 12:28:35 PM PDT] it's a known stack corruptor on
> non-cohe
On Wed, Aug 21, 2013 at 01:43:07AM -0700, Daniel Gimpelevich wrote:
> There is no need to get an interface specification if we know it's the
> wrong one.
>
> Signed-off-by: Daniel Gimpelevich
Acked-by: Greg Kroah-Hartman
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" i
On Wed, Aug 21, 2013 at 03:44:35PM +0100, Steve Cotton wrote:
> Hi Mathias,
>
> Sorry for a very late respose, replying to a 3-month old patch.
>
> Something looks odd in a558ccdcc71c - AFAICS these two calls to
> xhci_check_usb2_port_capability will always return the same value,
> so usb2_hw_lpm
On 08/21/2013 07:06 AM, George Cherian wrote:
> Hi Stephen,
>
> On 8/20/2013 10:23 PM, Stephen Warren wrote:
>>> >ID pins are connected to pcf8575, and the pcf8575's interrupt line is
>>> >inturn connected to
>>> >gpio bank6 pin 11, we use this gpio interrupt to detect the ID pin
>>> change.
>> In
Hi there,
I'm in the process of designing a VME=>USB interface, and I wanted to use the
FT232H, but according to FTDI, the throughput on Linux is only ~9MBytes/sec
using current kernels. In the past, it was ~40MBytes/sec. Sadly my Arm board is
delivered running Linux 3.4.29
I don't really want
On Wed, Aug 21, 2013 at 10:36:18AM -0700, Simon Gornall wrote:
> Hi there,
>
> I'm in the process of designing a VME=>USB interface, and I wanted to
> use the FT232H, but according to FTDI, the throughput on Linux is only
> ~9MBytes/sec using current kernels. In the past, it was ~40MBytes/sec.
> S
On Aug 21, 2013, at 10:39 AM, Greg KH wrote:
> On Wed, Aug 21, 2013 at 10:36:18AM -0700, Simon Gornall wrote:
>> Hi there,
>>
>> I'm in the process of designing a VME=>USB interface, and I wanted to
>> use the FT232H, but according to FTDI, the throughput on Linux is only
>> ~9MBytes/sec using
On Wed, Aug 21, 2013 at 10:53:32AM -0700, Simon Gornall wrote:
>
> On Aug 21, 2013, at 10:39 AM, Greg KH wrote:
>
> > On Wed, Aug 21, 2013 at 10:36:18AM -0700, Simon Gornall wrote:
> >> Hi there,
> >>
> >> I'm in the process of designing a VME=>USB interface, and I wanted to
> >> use the FT232H
On Aug 21, 2013, at 11:01 AM, Greg KH wrote:
> On Wed, Aug 21, 2013 at 10:53:32AM -0700, Simon Gornall wrote:
>>
>> On Aug 21, 2013, at 10:39 AM, Greg KH wrote:
>>
>>> On Wed, Aug 21, 2013 at 10:36:18AM -0700, Simon Gornall wrote:
Hi there,
I'm in the process of designing a VM
On Wed, Aug 21, 2013 at 11:07:49AM -0700, Simon Gornall wrote:
> >> I was hoping there was a "we changed it because..." reason. If you
> >> were unaware of the problem, I guess there's little you can do to fix
> >> it :)
> >>
> >> I'm not sure if this helps, but the driver they're talking about is
Hi Julius,
Thanks for the patch! Did you test with a USB analyzer to see if the
device was actually going into USB 2.0 Link PM? I'd like to confirm we
really aren't breaking anything for DW3 hosts by enabling this.
Sarah Sharp
On Tue, Aug 20, 2013 at 04:21:49PM -0700, Julius Werner wrote:
> Th
During "modprobe -r pch_udc" we receive a warning about freeing a "bad dma"
request.
* Properly free the requests from the PCI pool they where allocated in.
Signed-off-by: Mark Ferrell
---
drivers/usb/gadget/pch_udc.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff
Well timed removal of USB cable leaves g_serial unusable.
* It is possible that the g_serial driver can recieve a request to handle
SET_LINE_CODING in acm_setup() when the end-point is invalid. Further more,
acm_setup() will setup a completition handler for the request which results
in the
I sent this to Jiri Kosina and linux-kernel a week ago and
haven't gotten any attention. Maybe linux-usb can tell me
if this driver is any good.
From: David Barksdale
This patch adds support for the Silicon Labs CP2112
"Single-Chip HID USB to SMBus Master Bridge."
I wrote this to support a USB
On Wed, Aug 21, 2013 at 2:59 AM, Jussi Kivilinna wrote:
> On 21.08.2013 11:41, Brian Norris wrote:
>> On Wed, Aug 21, 2013 at 09:59:27AM +0200, Bjørn Mork wrote:
>>> Brian Norris writes:
On Tue, Aug 06, 2013 at 03:03:29PM +0300, Jussi Kivilinna wrote:
> Patch fixes alauda not to use stac
On Wed, Aug 21, 2013 at 02:52:31PM -0500, David Barksdale wrote:
> I sent this to Jiri Kosina and linux-kernel a week ago and
> haven't gotten any attention. Maybe linux-usb can tell me
> if this driver is any good.
Did you run it through the scripts/checkpatch.pl tool? It looks like
your spaces
From: David Barksdale
This patch adds support for the Silicon Labs CP2112
"Single-Chip HID USB to SMBus Master Bridge."
I wrote this to support a USB temperature and humidity
sensor I've been working on. It's been tested by using
SMBus byte-read, byte-data-read/write, and byte-word-read
transfe
On Wed, 21 August 2013 13:00:15 -0700, Brian Norris wrote:
>
> Yes, that's a good point. Quoting Documentation/stable_kernel_rules.txt:
>
> "It must be obviously correct and tested."
>
> Seeing as it was not tested, I am dropping the patch entirely (it is
> not stable material, and there is no p
liujunliang_ljl :
[...]
> diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
> new file mode 100644
> index 000..9c8f167
> --- /dev/null
> +++ b/drivers/net/usb/sr9700.c
[...]
> +static int sr_read(struct usbnet *dev, u8 reg, u16 length, void *data)
> +{
> + int err;
> +
> +
Hi Paul,
> > > @@ -365,6 +366,7 @@ struct dwc2_hsotg {
> > > u8 otg_port;
> > > u32 *frame_list;
> > > dma_addr_t frame_list_dma;
> > > + int next_sched_frame;
> >
> > This variable is still not really used, I think. Most of the mentions in
> > the patch are assignments, except for these tw
Yes,
I added the next_sched_frame to track the next uframe that there is
anything to do in the periodic schedule. The SOF interrupt is then
disabled until that uframe (although the FIQ still runs each uframe to
decide whether to trigger the USB interrupt)
Gordon
On 21/08/2013 22:24, "Matthijs K
On Wed, 14 Aug 2013, Clemens Ladisch wrote:
> > In other words, there should be enough URBs so that an entire ALSA
> > buffer can be queued at any time, subject only to the limit on the
> > maximum number of URBs and packets.
>
> The URB queue adds latency, so it should never be made too big, eve
> Thanks for the patch! Did you test with a USB analyzer to see if the
> device was actually going into USB 2.0 Link PM? I'd like to confirm we
> really aren't breaking anything for DW3 hosts by enabling this.
Yes, I did. The LPM transfers on the analyzer look good and the device
works as expect
On Thu, Aug 15, 2013 at 10:33:42PM +0200, Hans de Goede wrote:
> Hi,
>
> On 08/15/2013 12:42 PM, Hans de Goede wrote:
>
>
>
> >>What device did you find? I have yet to see a shipping device with
> >>streams...
> >
> >I don't know about streams, I'm hoping that having a uasp device means it
>
On Wed, Aug 21, 2013 at 03:11:12PM -0500, David Barksdale wrote:
> From: David Barksdale
>
> This patch adds support for the Silicon Labs CP2112
> "Single-Chip HID USB to SMBus Master Bridge."
>
> I wrote this to support a USB temperature and humidity
> sensor I've been working on. It's been tes
On Wed, Aug 21, 2013 at 02:43:55PM -0700, Julius Werner wrote:
> > Thanks for the patch! Did you test with a USB analyzer to see if the
> > device was actually going into USB 2.0 Link PM? I'd like to confirm we
> > really aren't breaking anything for DW3 hosts by enabling this.
>
> Yes, I did. T
Hi,
All issues addressed. Just a point :
>> +
>> +/* input final setup */
>> +ebeam_setup_input(ebeam, input_dev);
>> +
>> +err = input_register_device(ebeam->input);
>> +if (err) {
>> +dev_dbg(&intf->dev,
>> +"%s - input_register_device failed, err
On Wed, Aug 21, 2013 at 05:45:14PM -0700, Sarah Sharp wrote:
> On Wed, Aug 21, 2013 at 02:43:55PM -0700, Julius Werner wrote:
> > > Thanks for the patch! Did you test with a USB analyzer to see if the
> > > device was actually going into USB 2.0 Link PM? I'd like to confirm we
> > > really aren't
Remove device IDs of NCM-like (but not NCM-conformant) devices, that are
handled by the huawwei_cdc_ncm driver now.
Signed-off-by: Enrico Mioso
---
drivers/net/usb/cdc_ncm.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
in
This driver supports devices using the NCM protocol as an encapsulation layer
for other protocols, like the E3131 Huawei 3G modem. This driver was heavily
inspired by the qmi_wwan approach & code model.
Suggested-by: Bjorn Mork
Signed-off-by: Enrico Mioso
---
drivers/net/usb/Kconfig | 11 ++
These patches are all related to the new huawei_cdc_ncm driver, supporting
devices that use the NCM protocol as a transport layer for other protocols.
this is the case of the Huawei E3131 3G modem.
Thanks should go to bjorn and others who helped me with patience.
Enrico Mioso (3):
net: cdc_nc
Some drivers implementing NCM-like protocols, may re-use those functions, as is
the case in the huawei_cdc_ncm driver.
Export them via EXPORT_SYMBOL_GPL, in accordance with how other functions have
been exported.
Signed-off-by: Enrico Mioso
---
drivers/net/usb/cdc_ncm.c |6 --
include/
On Thu, Aug 22, 2013 at 04:30:40AM +0200, Enrico Mioso wrote:
> This driver supports devices using the NCM protocol as an encapsulation layer
> for other protocols, like the E3131 Huawei 3G modem. This driver was heavily
> inspired by the qmi_wwan approach & code model.
Line-wrap your changelog l
This patch redefine function xhci_readl.xhci_readl function doesn't use
xhci_hcd argument.
Hence there is no need of keeping it in the function arguments.
Redefining this function breaks other functions which calls this function.
This phatch also correct those calls in xhci driver.
Signed-off-
From: Greg KH
Date: Wed, 21 Aug 2013 09:25:07 -0700
> On Wed, Aug 21, 2013 at 01:43:07AM -0700, Daniel Gimpelevich wrote:
>> There is no need to get an interface specification if we know it's the
>> wrong one.
>>
>> Signed-off-by: Daniel Gimpelevich
>
> Acked-by: Greg Kroah-Hartman
Applied.
From: Greg KH
Date: Wed, 21 Aug 2013 09:24:47 -0700
> On Wed, Aug 21, 2013 at 01:43:19AM -0700, Daniel Gimpelevich wrote:
>> As Sergei Shtylyov explained in the #mipslinux IRC channel:
>> [Mon 2013-08-19 12:28:21 PM PDT] guys, are you sure it's not "DMA
>> off stack" case?
>> [Mon 2013-08-19 1
Hi,
I just recently moved an internal USB card reader from an ehci machine
to an xhci machine, and dmesg is filled with this message over and
over again:
[ 1596.047684] usb 1-8: reset high-speed USB device number 4 using xhci_hcd
[ 1596.090902] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called
> You need the USB 2.0 spec errata from 2011-11 that describes the changes
> made for BESL as well. It's in the USB2-LPM-Errata-final.pdf and
> USB2_LinkPowerMangement_ECN[final].pdf files in this zip file:
>
> http://www.usb.org/developers/docs/usb_20_070113.zip
>
> I agree though, it's all a con
Dear Friend,
I am contacting you to assist me in a transfer of $6,200,000.00 US dollars into
your personal bank account for the benefit of both of us, this transaction is
confidential and we MUST remain fiducially in all our dealings since I cannot
execute this opportunity alone without the s
The TLDR; version:
We've assumed that when a device disconnects after a resume from device
suspend, it was just a cheap, buggy device. It turns out that the USB
core simply wasn't waiting long enough for the devices to transition
from resume to U0, and it's actually been the USB core's fault all
> From: Julius Werner
> Sent: Wednesday, August 21, 2013 9:22 PM
>
> > You need the USB 2.0 spec errata from 2011-11 that describes the changes
> > made for BESL as well. It's in the USB2-LPM-Errata-final.pdf and
> > USB2_LinkPowerMangement_ECN[final].pdf files in this zip file:
> >
> > http://ww
On 8/21/2013 11:05 PM, Stephen Warren wrote:
On 08/21/2013 07:06 AM, George Cherian wrote:
Hi Stephen,
On 8/20/2013 10:23 PM, Stephen Warren wrote:
ID pins are connected to pcf8575, and the pcf8575's interrupt line is
inturn connected to
gpio bank6 pin 11, we use this gpio interrupt to detect
88 matches
Mail list logo
