Allow handling SS+ USB devices correctly.
Signed-off-by: Oliver Neukum
---
sound/usb/card.c | 4
sound/usb/helper.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/sound/usb/card.c b/sound/usb/card.c
index 3fc6358..69860da 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
Allow for SS+ USB devices
Signed-off-by: Oliver Neukum
---
sound/usb/midi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/usb/midi.c b/sound/usb/midi.c
index 47de8af..7ba9292 100644
--- a/sound/usb/midi.c
+++ b/sound/usb/midi.c
@@ -911,6 +911,7 @@ static void
On Fri, 2016-05-13 at 18:59 +0200, Bjørn Mork wrote:
> Bjørn Mork writes:
>
> > The driver enforces a strict one-to-one relationship between the
> > received RESPONSE_AVAILABLE notifications and messages read from
> > the device. At the same time, it will cancel the interrupt URB
> > when there i
On Tue, 2016-05-17 at 21:24 +0200, Bjørn Mork wrote:
> Oliver Neukum writes:
>
> > On Fri, 2016-05-13 at 18:59 +0200, Bjørn Mork wrote:
> >> Bjørn Mork writes:
> >>
> >> > The driver enforces a strict one-to-one relationship between the
> >&
On Tue, 2016-05-17 at 23:30 -0700, Guenter Roeck wrote:
> On Wed, May 18, 2016 at 02:13:30AM +0200, Heinrich Schuchardt wrote:
> > (!count || count < 4) is always true.
>
> Even if count >= 4 ?
The check for !count is redundant, though. Gcc, however,
will surely simplify the expression.
On Wed, 2016-05-18 at 01:39 +0200, Bjørn Mork wrote:
> Oliver Neukum writes:
> > On Tue, 2016-05-17 at 21:24 +0200, Bjørn Mork wrote:
> >> Oliver Neukum writes:
> >>
> >> > On Fri, 2016-05-13 at 18:59 +0200, Bjørn Mork wrote:
> >> >> Bjørn
On Wed, 2016-05-18 at 10:40 +0300, Andrey Ryabinin wrote:
> 2016-05-18 1:16 GMT+03:00 Greg Kroah-Hartman :
> > On Tue, May 17, 2016 at 05:52:40PM -0400, Valdis Kletnieks wrote:
> >> So, not content in the amount of breakage I generate already, I
> >> compiled with UBSAN enabled...
> >>
> >> The imm
On Wed, 2016-05-18 at 12:16 +0300, Andrey Ryabinin wrote:
> 2016-05-18 11:18 GMT+03:00 Oliver Neukum :
> > On Wed, 2016-05-18 at 10:40 +0300, Andrey Ryabinin wrote:
> >> 2016-05-18 1:16 GMT+03:00 Greg Kroah-Hartman :
> >> > On Tue, May 17, 2016 at 05:52:40PM
Hi,
I've been going through the drivers with an eye on security.
And a question arose. How do we know that a device that claims
to be a chaoskey is really a chaoskey?
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a
On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> The purpose of this class is to provide unified interface for user
> space to get the status and basic information about USB Type-C
> Connectors in the system, control data role swapping, and when USB PD
> is available, also power role swa
On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> + dev->class = &typec_class;
> + dev->parent = parent;
> + dev->type = &typec_partner_dev_type;
> + dev_set_name(dev, "%s-partner", dev_name(&port->dev));
> +
> + ret = device_register(dev);
> + if (ret) {
> +
On Thu, 2016-05-19 at 14:12 -0400, Dave Tian wrote:
> > The Chaoskey device explicitly does not address physical
> > attacks. Assuming physical security makes things a lot easier, and
> > one
> > of the simplifications is that we can assume that any physical
> > device
> > connected to the machin
On Thu, 2016-05-19 at 12:52 -0700, Keith Packard wrote:
> Oliver Neukum writes:
>
> > I think we would need to use a form of public key cryptography
> > in the same manner used to verify authorship of emails. The host
> > would provide a nonce value that the device encry
On Thu, 2016-05-19 at 21:59 +0200, Oliver Neukum wrote:
> On Thu, 2016-05-19 at 12:52 -0700, Keith Packard wrote:
> > Oliver Neukum writes:
> >
> > > I think we would need to use a form of public key cryptography
> > > in the same manner used to verify authorshi
On Mon, 2016-05-16 at 02:43 +, YAMAMOTO Hiroyuki wrote:
> Hi USB serial experts,
>
> I am trying to support ZTE 403ZT modem by linux serial driver.
>
> Currently, option driver can not be used for the modem, because USB Class
> Code of the modem does not match.
> Linux driver has 0xff as USB
On Fri, 2016-05-20 at 14:24 +0300, Heikki Krogerus wrote:
> On Thu, May 19, 2016 at 04:47:17PM +0200, Oliver Neukum wrote:
> >
> > Please explain. How does that express DRP but prefered master?
>
> Sorry but I'm not sure what you mean here. If the port is capable of
>
On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> Like I've told some of you guys, I'm trying to implement a bus for
> the Alternate Modes, but I'm still nowhere near finished with that
> one, so let's just get the class ready now. The altmode bus should in
> any case not affect the users
On Fri, 2016-05-20 at 17:13 -0700, Steve Calfee wrote:
> A clever attacker would provide a false USB key which is "almost"
> random. This would allow them to decrypt messages based on the false
> key, with nobody else knowing there was a vulnerability. An almost
> random number simplifies cracking
On Fri, 2016-05-20 at 22:51 -0700, Guenter Roeck wrote:
> On 05/20/2016 06:37 AM, Oliver Neukum wrote:
> > On Fri, 2016-05-20 at 14:24 +0300, Heikki Krogerus wrote:
> >> On Thu, May 19, 2016 at 04:47:17PM +0200, Oliver Neukum wrote:
> >>>
> >>> Ple
On Sun, 2016-05-22 at 08:54 -0700, Guenter Roeck wrote:
> Hi Oliver,
>
> On 05/20/2016 11:43 PM, Oliver Neukum wrote:
> > On Fri, 2016-05-20 at 22:51 -0700, Guenter Roeck wrote:
> >> On 05/20/2016 06:37 AM, Oliver Neukum wrote:
> >>> On Fri, 2016-05-20 a
On Mon, 2016-05-23 at 12:57 +0300, Heikki Krogerus wrote:
> Hi Oliver,
>
> On Fri, May 20, 2016 at 04:19:59PM +0200, Oliver Neukum wrote:
> > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > > Like I've told some of you guys, I'm trying to imple
On Mon, 2016-05-23 at 13:39 +0200, Martin Kepplinger wrote:
> It's *really* fun to use as an input tablet though! So let's support this
> for everybody.
Hi,
I am afraid there are a few issues.
1. Why the kernel thread?
2. This driver has questionable power management.
Regards
On Mon, 2016-05-23 at 14:43 +0200, Martin Kepplinger wrote:
> Am 2016-05-23 um 14:26 schrieb Oliver Neukum:
> > On Mon, 2016-05-23 at 13:39 +0200, Martin Kepplinger wrote:
> >
> >> It's *really* fun to use as an input tablet though! So let's support th
On Mon, 2016-05-23 at 06:27 -0700, Guenter Roeck wrote:
> >> Good question. I originally added a sysfs attribute
> 'preferred-mode' to
> >> my code, but then concluded that this is supposed to be provided
> >> by the platform and added it as platform data instead, with
> (currently)
> >> no means t
On Mon, 2016-05-23 at 07:43 -0700, Guenter Roeck wrote:
> On 05/23/2016 06:58 AM, Oliver Neukum wrote:
> > Now I am confused. Are you saying that the choice of Alternate Mode does
> > not belong into user space?
> >
>
> No; sorry for the confusion. The above was me
On Mon, 2016-05-23 at 10:09 -0700, Guenter Roeck wrote:
> On Mon, May 23, 2016 at 01:25:19PM +0200, Oliver Neukum wrote:
> > On Mon, 2016-05-23 at 12:57 +0300, Heikki Krogerus wrote:
> >
> > A reset is a generic function, so it does not belong to specific
> > drivers
On Tue, 2016-05-24 at 13:08 +0300, Heikki Krogerus wrote:
> Hi Guenter,
>
> On Mon, May 23, 2016 at 09:52:12AM -0700, Guenter Roeck wrote:
> > On Mon, May 23, 2016 at 05:55:04PM +0200, Oliver Neukum wrote:
> > > On Mon, 2016-05-23 at 07:43 -0700, Guenter Roeck wrote:
>
On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
Hi,
as this discussion seems to go in circles, I am starting anew
at the top.
> Like I've told some of you guys, I'm trying to implement a bus for
> the Alternate Modes, but I'm still nowhere near finished with that
> one, so let's just g
evice. When the pen is out of range, we just
> don't get any URBs and don't do anything.
> Like all other mouses or input tablets, we don't use runtime PM.
>
> Signed-off-by: Martin Kepplinger
> ---
>
> Thanks for having a look. Any more suggestions on this?
>
it claims to be is left
to the individual drivers. If that cannot be done in kernel
space, the admin still can call a device trustworthy.
To guard the entropy pool against malicious spoof we assume
the quality of an unverified source's entropy to be 0.
Signed-off-by: Oliver Neukum
---
driver
On Wed, 2016-05-25 at 17:04 +0300, Heikki Krogerus wrote:
> I'm not against leaving the responsibility of registering the alternate
> modes to the drivers. I'm a little bit worried about relying then on
> the drivers to also handle the unregistering accordingly, but I can
> live with that. But we
On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote:
> Hi guys,
>
> I'm attaching a diff instead of full v3. I'm not yet adding attributes
> for the reset and cable_reset. I still don't understand what is the
> case where the userspace would need to be able to tricker reset? Why
> isn't it en
On Mon, 2016-05-30 at 22:46 -0400, Dave Mielke wrote:
> Is this the right mailing list for ttyACM device issues, or should I be
> contactring the serial device people? Just in case this is the right place,
> here's the issue.
>
> I'm using Linux kernel 3.11.10-100.fc18.x86_64. I'm using termios,
93673bd350 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Tue, 31 May 2016 10:08:47 +0200
Subject: [PATCH] hid-elo: kill not flush the work
Flushing a work that reschedules itself is not a sensible
operation. It needs to be killed.
Signed-off-by: Oliver Neukum
---
drivers/hid/hid-elo.c | 2 +
On Tue, 2016-05-31 at 11:31 +0300, Heikki Krogerus wrote:
> Hi Oliver,
>
> On Mon, May 30, 2016 at 03:59:27PM +0200, Oliver Neukum wrote:
> > On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote:
> > > Hi guys,
> > >
> > > I'm attachin
gt; On Tue, May 31, 2016 at 10:48:29AM +0200, Oliver Neukum wrote:
> > > > > On Tue, 2016-05-31 at 11:31 +0300, Heikki Krogerus wrote:
> > > > > > Hi Oliver,
> > > > > >
> > > > > > On Mon, May 30, 2016 at 03:59:27PM
On Wed, 2016-06-01 at 11:23 +0300, Heikki Krogerus wrote:
> I think we can still add them later if they are still seen as
> necessity later on, tough I seriously doubt it. It would not be
> ideal, but adding an attribute should not really break anything,
> right? Removing would.
However, how do we
On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> Just noticed that the "active" file is for now read only, but it needs
> to be changed to writable. That file will of course provide means for
> the userspace to Exit and Enter modes. But please note that the
> responsibility of the depend
On Wed, 2016-06-01 at 08:48 -0400, Sandhya Bankar wrote:
> Use "foo *bar" instead of "foo * bar".
>
> Signed-off-by: Sandhya Bankar
Acked-by: Oliver Neukum
> ---
> drivers/usb/image/microtek.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(
On Wed, 2016-06-01 at 06:34 -0700, Guenter Roeck wrote:
> The class code would not explicitly learn about the reset,
> but it would be informed about the exited modes.
That has drawbacks
- it doesn't tell you what caused the mode to be left (if you
UFP, it may be the regular command)
- it is a
On Wed, 2016-06-01 at 16:29 -0700, Guenter Roeck wrote:
> On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote:
> > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > > Just noticed that the "active" file is for now read only, but it needs
> >
On Wed, 2016-06-01 at 23:37 -0700, Guenter Roeck wrote:
> On 06/01/2016 11:24 PM, Oliver Neukum wrote:
> > On Wed, 2016-06-01 at 06:34 -0700, Guenter Roeck wrote:
> >> The class code would not explicitly learn about the reset,
> >> but it would be informed about the exi
On Mon, 2016-06-06 at 16:28 +0300, Heikki Krogerus wrote:
> I would prefer lower case letters. I don't know the SIDs there are at
> them moment, other then Display Port. Do you know them?
>
> I don't think we can ever guarantee that in every case we will be able
> to provide a human readable name
A small update to unify error handling during probe().
Signed-off-by: Oliver Neukum
---
drivers/usb/class/cdc-acm.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 1620542..2e5dea8 100644
--- a/drivers
Hi,
it turns out that the common parser in usbnet leads to dependency
hell. It just makes no sense for serial code to depend on a network
driver. So, is it OK for this to live in generic USB code or should
I make a generic CDC module?
--
To unsubscribe from this list: send the line "unsubscribe
This introduces the common parser for extra CDC headers now that it no longer
depends on usbnet.
Signed-off-by: Oliver Neukum
---
drivers/usb/class/cdc-acm.c | 68 +++--
1 file changed, 10 insertions(+), 58 deletions(-)
diff --git a/drivers/usb/class/cdc
Now that the common parser resides in USB core, it can
be used for CDC-WDM.
Signed-off-by: Oliver Neukum
---
drivers/usb/class/cdc-wdm.c | 30 +-
1 file changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
The dependencies were impossible to handle preventing
drivers for CDC devices not which are not network drivers
from using the common parser.
Signed-off-by: Oliver Neukum
---
drivers/net/usb/usbnet.c | 138
drivers/usb/core/message.c | 153
On Thu, 2016-06-09 at 11:26 +0200, Oliver Neukum wrote:
> The dependencies were impossible to handle preventing
> drivers for CDC devices not which are not network drivers
> from using the common parser.
Hi Greg,
this is just for discussion. Something went wrong mailing it.
On Wed, 2016-06-01 at 14:55 +0200, Martin Kepplinger wrote:
> It's *really* fun to use as an input tablet though! So let's support this
> for everybody.
Nice job, but a few issues are left. I'll comment in the code.
> +static void pegasus_close(struct input_dev *dev)
> +{
> + struct pegasus
On Fri, 2016-06-10 at 15:27 +0200, Martin Kepplinger wrote:
> >> +input_set_abs_params(input_dev, ABS_X, -1500, 1500, 8, 0);
> >> +input_set_abs_params(input_dev, ABS_Y, 1600, 3000, 8, 0);
> >> +
> >> +pegasus_set_mode(pegasus, PEN_MODE_XY, NOTETAKER_LED_MOUSE);
> >
> > If you need to
On Fri, 2016-06-10 at 17:34 +0300, Heikki Krogerus wrote:
> +static ssize_t
> +preferred_role_store(struct device *dev, struct device_attribute
> *attr,
> +const char *buf, size_t size)
> +{
> + struct typec_port *port = to_typec_port(dev);
> + enum typec_role role;
On Mon, 2016-06-13 at 00:37 +0200, Ladislav Michl wrote:
> On Sun, Jun 12, 2016 at 11:03:45PM +0200, Ladislav Michl wrote:
> > Once ttyACM0 starts behave strangely, read() returns only what's in buffer
> > before
> > ttyACM0 was opened and then hangs infinitely. As this bug is hard to
> > trigger
On Tue, 2016-05-31 at 09:18 +0200, Hans de Goede wrote:
> Commit 198de51dbc34 ("USB: uas: Limit qdepth at the scsi-host level")
> removed the scsi_change_queue_depth() call from uas_slave_configure()
> assuming that the slave would inherit the host's queue_depth, which
> that commit sets to the sam
On Mon, 2016-06-13 at 15:31 +0200, Martin Kepplinger wrote:
> In close() we only need usb_autopm_put_interface(), in reset_resume()
Sorry, that is a misunderstanding. You need not carry
about power management in close() at all. But it must
be balanced of course.
Regards
Ol
On Tue, 2016-06-14 at 07:51 +0200, Heiner Kallweit wrote:
> + ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW);
> + if (ret)
> + return ret;
> +
> + minor = ((struct hidraw *) hdev->hidraw)->minor;
> +
> + ret = dc_init_device(dcdev);
That is a race condition. You announce
On Tue, 2016-06-14 at 13:20 +0200, Martin Kepplinger wrote:
> * Fix usb_autopm calls to be balanced
> * In reset_resume() we need to set the device mode
> * In suspend() we must cancel the workqueue's work
>
> Signed-off-by: Martin Kepplinger
Looks good to me.
Regards
On Tue, 2016-06-14 at 20:27 +0530, shishir tiwari wrote:
> Hi ,
>
> We are trying to open and close ttyUSB0 port and using 'chat' command
> to communicate in while loop using shell script.but after 30-40 times
> '#' reply is not coming for 'ls' command.
>
> shell script::
> while
> (
> stty -F /d
On Tue, 2016-06-14 at 21:34 +0200, Heiner Kallweit wrote:
> Am 14.06.2016 um 10:05 schrieb Oliver Neukum:
> > On Tue, 2016-06-14 at 07:51 +0200, Heiner Kallweit wrote:
> >
> >> + ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW);
> >> + if (ret)
> >> +
On Mon, 2016-06-20 at 17:10 +0530, Muni Sekhar wrote:
> #define USB_CTRL_GET_TIMEOUT5000
>
> #define USB_CTRL_SET_TIMEOUT5000
>
>
>
>
>
> Does the above mentioned timeouts will vary based on the packet length
> of control transfers (8, 16, 32 or 64 bytes)?
Those timeouts are for res
On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> The purpose of this class is to provide unified interface for user
> space to get the status and basic information about USB Type-C
> Connectors in the system, control data role swapping, and when USB PD
> is available, also power role swa
On Tue, 2016-06-21 at 06:24 -0700, Guenter Roeck wrote:
> On 06/21/2016 06:08 AM, Oliver Neukum wrote:
> > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> >> The purpose of this class is to provide unified interface for user
> >> space to get the status and
On Tue, 2016-06-21 at 17:51 +0300, Heikki Krogerus wrote:
> +What: /sys/class/typec//supported_data_roles
> +Data: June 2016
> +Contact: Heikki Krogerus
> +Description:
> + Lists the USB data roles, host or device, the port is
> capable
> + of su
On Tue, 2016-06-21 at 16:58 +0300, Heikki Krogerus wrote:
> On Tue, Jun 21, 2016 at 03:08:52PM +0200, Oliver Neukum wrote:
>
> > The firmware will surely want to display something. So it is possible
> > that we start the OS will a valid power contract. How do we deal
> >
On Wed, 2016-06-22 at 04:12 +, Saurin G. Suthar wrote:
> [ 845.375281] cdc_acm 4-1:1.1: acm_read_bulk_callback - urb 15, len 0
> [ 845.375353] cdc_acm 4-1:1.1: acm_read_bulk_callback - non-zero urb
> status: -2
> [ 845.375452] cdc_acm 4-1:1.0: acm_tty_cleanup
> [ 845.375543] tty ttyACM0: ac
On Wed, 2016-06-22 at 12:31 +0300, Heikki Krogerus wrote:
Hi,
> > Now correct me, if I am misreading the spec. I am sure the system
> > will boot unless it needs ridiculous amounts of power, but
> > will we see anything on the screen? As far as I can tell the spec
> > actually says that you canno
On Wed, 2016-06-22 at 12:50 +0300, Heikki Krogerus wrote:
> On Tue, Jun 21, 2016 at 10:25:05PM +0200, Oliver Neukum wrote:
> > On Tue, 2016-06-21 at 17:51 +0300, Heikki Krogerus wrote:
> > > +What: /sys/class/typec//supported_data_roles
> > > +Data:
On Wed, 2016-06-22 at 13:03 +0300, Heikki Krogerus wrote:
> On Wed, Jun 22, 2016 at 12:50:16PM +0300, Heikki Krogerus wrote:
>
> > But if the port is DRP, we will always be able to swap the data role
> > between DFP and UFP.
>
> Just to clarify: DRP as it's defined in Type-C spec < 1.2 means the
On Wed, 2016-06-22 at 14:44 +0300, Heikki Krogerus wrote:
> If our port is DRD (which would be DRP in the port controller spec),
> the supported_power_roles will list:
>
> device, host
>
> And the power role, if the port is Source only, the
> supported_power_roles will list:
>
>
On Wed, 2016-06-22 at 17:38 +0300, Heikki Krogerus wrote:
> On Wed, Jun 22, 2016 at 03:47:03PM +0200, Oliver Neukum wrote:
> > On Wed, 2016-06-22 at 14:44 +0300, Heikki Krogerus wrote:
> > > If our port is DRD (which would be DRP in the port controller spec),
> > > the
On Thu, 2016-06-23 at 11:23 +0300, Heikki Krogerus wrote:
> On Wed, Jun 22, 2016 at 06:44:18PM +0200, Oliver Neukum wrote:
> No it's not. DRP means a port that can operate as _either_ Source
> (host) or Sink (device), but not at the same time..
Yes, but it is unclear what you w
On Sun, 2016-07-03 at 21:59 +0200, Bjørn Mork wrote:
> default:
> @@ -200,10 +200,29 @@ static void wdm_in_callback(struct urb *urb)
> desc->reslength = length;
> }
> }
> +
> + /*
> + * If desc->resp_count is unset, then the urb was s
On Sun, 2016-07-03 at 22:24 +0200, Bjørn Mork wrote:
> Several Lenovo users have reported problems with their Sierra
> Wireless EM7455 modem. The driver has loaded successfully and
> the MBIM management channel has appeared to work, including
> establishing a connection to the mobile network. But n
On Wed, 2016-06-29 at 14:27 +0300, Heikki Krogerus wrote:
> About the end user of the interface, I think Oliver knows more about
> that. But I would imagine that the use cases will be something like,
> for example, on systems that need prefer sertain roles, perhaps Host
> for example on some serve
On Friday 23 November 2012 14:40:37 Jan Pohanka wrote:
> I have tried to reproduce this behavior directly on my PC, but there it
> works like a charm - at first I thought that the problem lies in cdc_acm
> driver, but today I tried to desolder the hub and connect the USB modem
> directly to t
Hi Alan,
did you ever recieve any feedback concerning the patch you wrote
the patch in the message mentioned above for? I am getting reports
from customers that it fixes issues with NVIDIA chipsets.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscri
Hi,
in usb_unbind_interface() we call usb_cancel_queued_reset() before
restoring altsetting 0. This seems wrong to me. If a driver found it
necessary to reset a device we cannot simply ignore that. I'd say
that we should wait for the work to finish, not cancel it.
What do you say?
Regards
On Saturday 24 November 2012 17:45:35 Jim Passmore wrote:
> On Machine B, within seconds, it kills my keyboard, either by having no
> response, or by sending repeating keypresses (on 2 occasions had it send
> either "n" or "enter" as if I were holding down the key). Obviously, not
> very useful.
On Monday 26 November 2012 10:42:48 Daniele Palmas wrote:
> Hello,
>
> I'm using the modem Telit HE910 with cdc-acm driver.
>
> I've found that after a suspend and resume of the operating system
> (e.g. pm-suspend), the modem does not answer anymore.
>
> Collecting logs with an usb sniffer, it s
On Monday 26 November 2012 13:29:09 Daniele Palmas wrote:
> Ok. Do you have any hint for adding the code in the proper place?
First we need to define a new quirk.
> >> According to the USB 2.0 specs it seems to me that this feature should
> >> be always requested when suspending a device, so pr
On Monday 26 November 2012 14:43:13 Clemens Ladisch wrote:
> > If it has to be running, the easiest fix would be the patch like
> > below. This will turn off the autopm essentially, but better than
> > breakage.
> >
> > @@ -2074,6 +2077,8 @@ static void snd_usbmidi_input_start_ep(struct
> > snd_
On Friday 23 November 2012 11:42:02 Alan Stern wrote:
> On Fri, 23 Nov 2012, Oliver Neukum wrote:
>
> > Hi Alan,
> >
> > did you ever recieve any feedback concerning the patch you wrote
> > the patch in the message mentioned above for? I am getting reports
> >
On Monday 26 November 2012 12:06:21 Alan Stern wrote:
> Still, this is an important consideration. It means that remote wakeup
> doesn't need to be enabled when the driver isn't present. Which means
> that the cdc-acm driver is indeed the right place to fix this problem
> -- although the way you
On Monday 26 November 2012 13:40:28 Alan Stern wrote:
> Of course, there would still be a problem if the system was suspended
> while this program was running and using the modem. There's no way to
> tell usbfs that remote wakeup is required.
Exactly. Also there's an unavoidable window when kick
On Tuesday 27 November 2012 10:30:02 Alan Stern wrote:
> I disagree. The usbfs interface is not as capable as the kernel's
> internal API; that has always been true. One of its limitations is the
> inability to request remote wakeups. We could add that to usbfs, but
> for now it isn't there.
Y
On Thursday 29 November 2012 14:06:12 Gerd Hoffmann wrote:
> Add uas_unlink_data_urbs function to cancel in-flight data urbs.
> Moves existing code into a separate function.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/usb/storage/uas.c | 32 ++--
> 1 files chan
On Thursday 29 November 2012 14:06:15 Gerd Hoffmann wrote:
> diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
> index dd23b61..5f498db 100644
> --- a/drivers/usb/storage/uas.c
> +++ b/drivers/usb/storage/uas.c
> @@ -717,8 +717,22 @@ static int uas_eh_abort_handler(struct scsi_cmnd
reset anyway.
Signed-off-by: Oliver Neukum
---
drivers/usb/core/hub.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 1af04bd..ded05b0 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2899,7
On Thursday 29 November 2012 15:31:54 Gerd Hoffmann wrote:
> On 11/29/12 14:20, Oliver Neukum wrote:
> > On Thursday 29 November 2012 14:06:12 Gerd Hoffmann wrote:
> >> Add uas_unlink_data_urbs function to cancel in-flight data urbs.
> >> Moves existing co
reset anyway.
Signed-off-by: Oliver Neukum
---
drivers/usb/core/hub.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 1af04bd..4ef2cf6 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2944,7
On Thursday 06 December 2012 18:51:25 Chen Gang wrote:
> Hello Greg Kroah-Hartman:
>
> in drivers/usb/core/message.c:
> at line 943, status is kmalloc ( sizeof u16 )
> at line 952, assign the value of status to data
> at line 953, free status.
>
> it is better to let "u16 status" instead
On Monday 10 December 2012 11:51:41 Steve Glendinning wrote:
> This is a work in-progress patch. It's not yet complete but
> I thought I'd share it for comments, feedback and testing.
>
> This patch enables dynamic autosuspend for all devices
> supported by the driver, but it will only actually w
On Tuesday 11 December 2012 10:24:57 Ming Lei wrote:
> On Mon, Dec 10, 2012 at 10:18 PM, Steve Glendinning wrote:
> > Thanks, so something like this should do the job?
>
> This will do, but not simple as clearing .manage_power function
> pointer in bind(), and still disable runtime suspend for l
On Tuesday 11 December 2012 20:53:19 Ming Lei wrote:
> In fact, I have test data which can show a much power save
> on OMAP3 based beagle board plus asix usbnet device with
> the periodic work. IMO, the power save after introducing periodic
> timer depends on the arch or platform, there should be m
On Friday 14 December 2012 09:31:41 Alan Cox wrote:
> On Fri, 14 Dec 2012 03:01:24 +
> "Fangxiaozhi (Franko)" wrote:
>
> > Dear Alan:
> >
> > This prevents people getting access to the storage device if they want.
> > In our device, after its switching, it will keep the cdrom por
On Friday 14 December 2012 10:28:31 Fangxiaozhi wrote:
Hi,
> > For such devices we should put the switching code into generic code, not a
> > device driver so that we have a chance to do reset_resume() on those
> > devices.
> --Because in many embedded linux system, they don't include
On Friday 14 December 2012 13:35:04 Steve Glendinning wrote:
> Thanks Ming, I've updated this.
Very good. Good catch Ming.
> > IMO, it is better to keep smsc95xx_info.manage_power as NULL
> > for devices without FEATURE_AUTOSUSPEND, so that fewer code
> > and follow the current .mange_power usag
On Tuesday 18 December 2012 13:10:25 Lucas Stach wrote:
> diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
> index 9bbeabf..8e9516f 100644
> --- a/include/linux/usb/usbnet.h
> +++ b/include/linux/usb/usbnet.h
> @@ -106,6 +106,7 @@ struct driver_info {
> */
> #define FLAG_MULT
On Tuesday 18 December 2012 14:24:32 Lucas Stach wrote:
> Am Dienstag, den 18.12.2012, 14:11 +0100 schrieb Oliver Neukum:
> > On Tuesday 18 December 2012 13:10:25 Lucas Stach wrote:
> > > diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
> > > in
On Tuesday 18 December 2012 13:10:26 Lucas Stach wrote:
> --- a/drivers/net/usb/asix_devices.c
> +++ b/drivers/net/usb/asix_devices.c
> @@ -495,6 +495,10 @@ static int ax88772_bind(struct usbnet *dev, struct
> usb_interface *intf)
> dev->rx_urb_size = 2048;
> }
>
> +
1 - 100 of 1943 matches
Mail list logo
