Hi,
John Youn writes:
> [ text/plain ]
> On 3/16/2016 6:56 AM, Felipe Balbi wrote:
>>
>> heh, +john
>>
>> Felipe Balbi writes:
>>> [ text/plain ]
>>>
>>> Hi,
>>>
>>> Roger Quadros writes:
[ text/plain ]
We will need this function for a workaround.
The function issues a softres
UDC driver should NEVER do anything behind
udc-core's back, so let's stop disabling endpoints
we don't exactly own - rather we provide as
resources for gadget drivers. This fixes the
regression reported by Gil.
Reported-by: Gil Weber
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/udc/atmel_
On Sun, 2016-03-20 at 11:43 +0100, Geert Uytterhoeven wrote:
> If CONFIG_PM=n:
>
> drivers/net/usb/lan78xx.c: In function ‘lan78xx_get_stats64’:
> drivers/net/usb/lan78xx.c:3274: error: ‘struct dev_pm_info’ has no
> member named ‘runtime_auto’
>
> If PM is disabled, the runtime_auto flag
Hi,
>UDC driver should NEVER do anything behind
>udc-core's back, so let's stop disabling endpoints
>we don't exactly own - rather we provide as
>resources for gadget drivers. This fixes the
>regression reported by Gil.
>
>Reported-by: Gil Weber
>Signed-off-by: Felipe Balbi
All is working for m
On Sun, 2016-03-20 at 18:09 +0100, Guido Trentalancia wrote:
> Hello.
>
> Considering that EM interference can last for a while (generally up to
> seconds), I am currently testing the following patch for module usbcore
> so that it is possible to specify an amount of time to wait before
> trying t
>> The full report of this issue can be found here:
>> http://seclists.org/bugtraq/2016/Mar/86
The subject and the body of the above message are not matching and
the message does not describe the gtco driver bug.
The full correct report of this issue can be found in the public
Red Hat Bugzilla:
I am sorry but the 't' option (i.e. US_FL_NO_ATA_1X) may not be robust enough.
Yesterday after leaving the system running for a few hours the usb disk would
no longer connect.
Today when I restarted the system with the 't' option, again the disk would
not connect.
I then tried repeatedly disc
On 21.03.2016 06:18, Rajesh Bhagat wrote:
Hi
I think clearing the whole command ring is a bit too much in this case.
It may cause issues for all attached devices when one command times out.
Hi Mathias,
I understand your point, But I want to understand how would completion handler
be cal
Hi Oliver,
that would be a misconfiguration issue, however I think we can set an upper
limit for the new parameter... Also consider that the other
"initial_descriptor_timeout" parameter is not limited by an upper limit...
And by the way, I should preferably modify the patch so that it correctl
Hi David,
On 21-03-16 10:08, David Webb wrote:
I am sorry but the 't' option (i.e. US_FL_NO_ATA_1X) may not be robust enough.
Yesterday after leaving the system running for a few hours the usb disk would
no longer connect.
Today when I restarted the system with the 't' option, again the disk wo
On Fri, 2016-03-18 at 12:36 -0400, Alan Stern wrote:
> @@ -1584,10 +1581,8 @@ static int hid_resume(struct usb_interfa
> static int hid_reset_resume(struct usb_interface *intf)
> {
> struct hid_device *hid = usb_get_intfdata(intf);
> - struct usbhid_device *usbhid = hid->driver_data;
>
An attack using the lack of sanity checking in probe
is known. This patch checks for the existance of a
second port.
CVE-2016-3136
Signed-off-by: Oliver Neukum
CC: sta...@vger.kernel.org
v1 - add sanity check for presence of a second port
v2 - add sanity check for an interrupt endpoint
---
driv
On Thu, 2016-03-17 at 10:47 -0400, Johan Hovold wrote:
> This looks like you just resent v1 (again, please include the revision
> in the mail Subject).
Indeed. Wrong directory.
Sorry
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the bo
An attack using the lack of sanity checking in probe
is known. This patch checks for the existance of a
second port.
CVE-2016-3136
Signed-off-by: Oliver Neukum
CC: sta...@vger.kernel.org
v1 - add sanity check for presence of a second port
v2 - add sanity check for an interrupt endpoint
---
driv
On Sun, Mar 20, 2016 at 06:57:30PM +0100, Guido Trentalancia wrote:
> Hello Greg !
>
> On dom, 2016-03-20 at 10:34 -0700, Greg KH wrote:
> > On Sun, Mar 20, 2016 at 06:09:57PM +0100, Guido Trentalancia wrote:
> > >
> > > [ 1295.575679] usb 6-2: FTDI USB Serial Device converter now
> > > attached
Good day,
I've noticed what I suspect to be a possible xHCI regression when
upgrading from kernel 3.19.51 to 4.2.0-30 generic SMP x64 which causes
various USB3.0 cameras to no longer stream data. It appears to be
limited to Intel 9 Series on-board controllers and the occasional NEC
PCIe USB3
Added support for Gemalto's Cinterion PH8 and AHxx products
with 2 RmNet Interfaces and products with 1 RmNet + 1 USB Audio interface.
The RmNet and USB Audio interfaces are blacklisted because they will be
handled by other drivers.
In addition some minor renaming and formatting.
Signed-off-by:
On Sat, Mar 19, 2016 at 09:59:12AM +0100, Hans de Goede wrote:
> Commit 64d513ac31bd ("scsi: use host wide tags by default") causes
> the scsi-core to queue more cmnds then we can handle on devices with
> multiple LUNs, limit the qdepth at the scsi-host level instead of
> per slave to fix this.
>
On Sat, Mar 19, 2016 at 10:06:16AM -0700, James Bottomley wrote:
> Help me understand this bug a bit more. Are you saying that the commit
> you identify is causing the block layer to queue more commands than
> you've set the per-lun limit to? In which case we have a serious
> problem for more tha
> -Original Message-
> From: Oliver Neukum [mailto:oneu...@suse.com]
> Sent: Monday, March 21, 2016 4:36 AM
> To: Geert Uytterhoeven
> Cc: Woojung Huh - C21699; UNGLinuxDriver; David S. Miller; Guenter Roeck;
> Rafael J. Wysocki; net...@vger.kernel.org; linux-usb@vger.kernel.org;
> linux...
The driver can be crashed with devices that expose crafted
descriptors with too few endpoints.
See:
http://seclists.org/bugtraq/2016/Mar/61
Signed-off-by: Oliver Neukum
v1 - added sanity checks
v2 - moved them to probe() to fix problems Johan pointed out
---
drivers/usb/serial/digi_acceleport.c
On Mon, 21 Mar 2016, Oliver Neukum wrote:
> On Sun, 2016-03-20 at 11:43 +0100, Geert Uytterhoeven wrote:
> > If CONFIG_PM=n:
> >
> > drivers/net/usb/lan78xx.c: In function ‘lan78xx_get_stats64’:
> > drivers/net/usb/lan78xx.c:3274: error: ‘struct dev_pm_info’ has no
> > member named ‘runti
> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: Sunday, March 20, 2016 6:59 PM
> To: Geert Uytterhoeven; Woojung Huh - C21699; UNGLinuxDriver; David S.
> Miller
> Cc: Rafael J. Wysocki; net...@vger.kernel.org; linux-usb@vger.kernel.org;
> linux...@vger.kernel.
On Sun, 20 Mar 2016, Guido Trentalancia wrote:
> Hello.
>
> Considering that EM interference can last for a while (generally up to
> seconds), I am currently testing the following patch for module usbcore
> so that it is possible to specify an amount of time to wait before
> trying to re-enable a
On Mon, 21 Mar 2016, Rajesh Bhagat wrote:
> I agree to your point. Actually the intent was to check the return status of
> reset_device which
> is currently being ignored. I encountered the reset_device failure case in
> resume operation (STR)
> which is increasing the time of resume and causi
Hello Alan,
thanks for getting back on this...
Il 21 marzo 2016 16:01:17 CET, Alan Stern ha
scritto:
>On Sun, 20 Mar 2016, Guido Trentalancia wrote:
>
>> Hello.
>>
>> Considering that EM interference can last for a while (generally up
>to
>> seconds), I am currently testing the following patc
On Mon, 21 Mar 2016, Oliver Neukum wrote:
> On Fri, 2016-03-18 at 12:36 -0400, Alan Stern wrote:
>
> > @@ -1584,10 +1581,8 @@ static int hid_resume(struct usb_interfa
> > static int hid_reset_resume(struct usb_interface *intf)
> > {
> > struct hid_device *hid = usb_get_intfdata(intf);
> > -
Consider also a couple of very common non-telecom EMI sources: vehicle engines
and lifts starting up. Both of them have a typical duration which I suppose is
of 1, 2 or at most 3 seconds (although I do not have exact figures or
references to them).
What would really help here is an ad-hoc study
The TX settings can be calibrated for particular hardware. The
phy is reset by Linux, so this cannot be handled by the bootloader.
The TRM mentions that the maximum resistance should be used for the
DN/DP calibration in order to pass USB certification.
The values for the TX registers are poorly
Add generic support for RGB LED's.
Basic idea is to use enum led_brightness also for the hue and saturation
color components.This allows to implement the color extension w/o
changes to struct led_classdev.
Select LEDS_CLASS_RGB to enable building drivers using the RGB extension.
Flag LED_SET_HUE
On Mon, 2016-03-21 at 10:57 -0400, Alan Stern wrote:
> One possible solution is to export a sysfs parameter to prevent
> statistics collection (or more generally, to change the interval at
> which it occurs).
Surely, not performing a task can hardly be beaten in terms of power
consumption. That
On Mon, 21 Mar 2016, Oliver Neukum wrote:
> On Mon, 2016-03-21 at 10:57 -0400, Alan Stern wrote:
>
> > One possible solution is to export a sysfs parameter to prevent
> > statistics collection (or more generally, to change the interval at
> > which it occurs).
>
> Surely, not performing a task
> But this leaves open the issue that querying the device too often will
> prevent it from going into autosuspend. It seems to me that the best
> way to deal with this is to make sure that the autosuspend timeout is
> shorter than the interal between queries, not to make the querying
> conditional
On Mon, 2016-03-21 at 14:24 -0400, Alan Stern wrote:
> On Mon, 21 Mar 2016, Oliver Neukum wrote:
>
> > On Mon, 2016-03-21 at 10:57 -0400, Alan Stern wrote:
> >
> > > One possible solution is to export a sysfs parameter to prevent
> > > statistics collection (or more generally, to change the inte
On Mon, 21 Mar 2016 woojung@microchip.com wrote:
> > But this leaves open the issue that querying the device too often will
> > prevent it from going into autosuspend. It seems to me that the best
> > way to deal with this is to make sure that the autosuspend timeout is
> > shorter than the i
On Mon, 21 Mar 2016, Oliver Neukum wrote:
> On Mon, 2016-03-21 at 14:24 -0400, Alan Stern wrote:
> > On Mon, 21 Mar 2016, Oliver Neukum wrote:
> >
> > > On Mon, 2016-03-21 at 10:57 -0400, Alan Stern wrote:
> > >
> > > > One possible solution is to export a sysfs parameter to prevent
> > > > sta
FOR YOUR INFORMATION DEAR BENEFICIARY,
Your Over-due ATM Card payment of $1.5MUSD by the UN Office have
deposited to the ATM MASTER CARD OFFICE. All you have to do now is to
contact the Office Manager Dr. peter Akupa Boni at:
(peterakupa...@gmail.com) and Phone number: +229 61 31 07 78 , he
will
On 3/18/2016 12:17 PM, John Youn wrote:
> On 3/16/2016 6:56 AM, Felipe Balbi wrote:
>>
>> heh, +john
>>
>> Felipe Balbi writes:
>>> [ text/plain ]
>>>
>>> Hi,
>>>
>>> Roger Quadros writes:
[ text/plain ]
We will need this function for a workaround.
The function issues a softreset o
> > > But this leaves open the issue that querying the device too often will
> > > prevent it from going into autosuspend. It seems to me that the best
> > > way to deal with this is to make sure that the autosuspend timeout is
> > > shorter than the interal between queries, not to make the queryi
On Mon, 21 Mar 2016 woojung@microchip.com wrote:
> > > > But this leaves open the issue that querying the device too often will
> > > > prevent it from going into autosuspend. It seems to me that the best
> > > > way to deal with this is to make sure that the autosuspend timeout is
> > > > sh
On Mon, 2016-03-21 at 11:46 -0400, Alan Stern wrote:
> On Mon, 21 Mar 2016, Oliver Neukum wrote:
>
> > On Fri, 2016-03-18 at 12:36 -0400, Alan Stern wrote:
> >
> > Almost. In case of reset_resume() it makes no sense to still
> > clear a halt or execute a reset that had been ordered. The
> > corre
Add a missing MODULE_DEVICE_TABLE() line which was causing the
sunxi-musb glue to not auto-load when build as a module.
Signed-off-by: Hans de Goede
---
drivers/usb/musb/sunxi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 4b472b8.
A bug in the CRTSCT handling caused RTS to alternate between
CRTSCTS=0 => "RTS transmits active signal" and
CRTSCTS=1 => "RTS receives flow control"
instead of
CRTSCTS=0 => "RTS is statically active" and
CRTSCTS=1 => "RTS receives flow control"
Signed-off-by: Konstantin Shkolnyy
---
drivers/usb/
Replaced several register write calls with one, to simplify adding error
handling.
Signed-off-by: Konstantin Shkolnyy
---
drivers/usb/serial/cp210x.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index b23
Added error handling to register accesses made by open(), so it doesn't
succeed if anything goes wrong.
Signed-off-by: Konstantin Shkolnyy
---
drivers/usb/serial/cp210x.c | 41 -
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/s
Documented "magic numbers" used in the CRTSCT flag code in terms of
register bit names from the chip specification.
Signed-off-by: Konstantin Shkolnyy
---
drivers/usb/serial/cp210x.c | 38 ++
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/drive
The CRTCTS flag code intended to clear the SERIAL_XOFF_CONTINUE flag, but
did it inconsistently. This change is non-functional for existing chips
because the driver never set the flag and it's clear by default.
Signed-off-by: Konstantin Shkolnyy
---
drivers/usb/serial/cp210x.c | 2 +-
1 file cha
On Mon, Mar 21, 2016 at 7:13 PM, Hans de Goede wrote:
> Add a missing MODULE_DEVICE_TABLE() line which was causing the
> sunxi-musb glue to not auto-load when build as a module.
>
> Signed-off-by: Hans de Goede
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
--
To unsubscribe
On Tue, Mar 22, 2016 at 01:31:40AM +, Lipengcheng wrote:
>Hi,
> we have a problem like that we can start kernel successfully without
> processing any other operations, but failed after pressing ctrl + c. After
> our analsys, it is because of that, ctrl + c will produce an interrupu
Hi,
On 03/22/2016 11:17 AM, Lipengcheng wrote:
> Hi,
> Thanks for your reply.
> When the suspend and resume process , the operation of press ctrl + c will
> produce an interruput and cause to allocate memory failed. It causes the usb3
> module can not be used and core dump after resume proce
On Tue, Mar 22, 2016 at 03:17:08AM +, Lipengcheng wrote:
> Hi,
> Thanks for your reply.
> When the suspend and resume process , the operation of press ctrl + c will
> produce an interruput and cause to allocate memory failed. It causes the usb3
> module can not be used and core dump after
On Tue, Mar 22, 2016 at 11:36:47AM +0800, Lu Baolu wrote:
> Hi,
>
> On 03/22/2016 11:17 AM, Lipengcheng wrote:
> > Hi,
> > Thanks for your reply.
> > When the suspend and resume process , the operation of press ctrl + c
> > will produce an interruput and cause to allocate memory failed. It ca
On Tue, Mar 22, 2016 at 03:51:27AM +, Lipengcheng wrote:
> Hi,
>Thanks Lu Baolu,
> >The core dump says "PC is at xhci_mem_cleanup+0x4e4/0x574 [xhci_hcd] ".
> >But this call flow shows error happens in dma allocation. Which is correct?
> >Or, anything I misunderstood?
> Sorry . I am not des
> -Original Message-
> From: Mathias Nyman [mailto:mathias.ny...@intel.com]
> Sent: Monday, March 21, 2016 2:46 PM
> To: Rajesh Bhagat ; Mathias Nyman
> ; linux-usb@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: gre...@linuxfoundation.org; Sriram Dash
> Subject: Re: [PATCH] usb:
Hi,
John Youn writes:
> [ text/plain ]
> On 3/18/2016 12:17 PM, John Youn wrote:
>> On 3/16/2016 6:56 AM, Felipe Balbi wrote:
>>>
>>> heh, +john
>>>
>>> Felipe Balbi writes:
[ text/plain ]
Hi,
Roger Quadros writes:
> [ text/plain ]
> We will need this function
Hi Felipe,
> From: Yoshihiro Shimoda
> Sent: Thursday, March 10, 2016 11:30 AM
>
> This patch set is based on the latest Felipe's usb.git / testing/next branch.
> (commit id = ac5706631325ae3695bfa1527101ab2b2f64859f)
Would you review the patch set?
I confirmed that the patch set could be applie
56 matches
Mail list logo
