On Mo, 2018-10-15 at 13:12 -0400, Alan Stern wrote:
> On Mon, 15 Oct 2018, Andrey Konovalov wrote:
>
> Ah, I see the problem. In fact it is the same issue, but the commit
> mentioned above contains an error (is_in gets tested too soon). The
> fix is below; can you check it?
>
> Alan Stern
>
Th
On Mo, 2018-10-15 at 14:12 +0200, Julian Xhokaxhiu wrote:
> Hi Oliver,
>
> I'm currently using the latest 4.18.12 mainline ( on Arch
> https://www.archlinux.org/packages/core/x86_64/linux/ ), and yes
> you're right I am NOT using UAS at the moment. The link I left is
> because I noticed those erro
Good morning Oliver,
thank you very much for the reply. I will try to build a test kernel
hopefully later this evening and I'll get back to you.
Meanwhile you can see in the attachment in my first email the output
of `$ lsusb -v -d 152d:1561`
Is there a way to test UAS without recompiling the Ke
On Mo, 2018-10-15 at 09:50 -0400, Alan Stern wrote:
>
> It seems that a better approach would be to have an ioctl which would:
>
> fail if there are any active user URBs;
>
> drop the usbfs PM reference so the device can suspend;
>
> block interruptibly until the device
On Thu, 11 Oct 2018 14:29:54 -0400
Alan Stern wrote:
> On Thu, 11 Oct 2018, Mayuresh Kulkarni wrote:
>
> > On Tue, 9 Oct 2018 13:27:02 +0200
> > Greg KH wrote:
> >
> > > On Tue, Oct 09, 2018 at 10:51:53AM +0100, Mayuresh Kulkarni wrote:
> > > > With all due respect, one of the possible reason
On Mon, 15 Oct 2018 09:50:46 -0400
Alan Stern wrote:
> On Mon, 15 Oct 2018, Oliver Neukum wrote:
>
> > On Do, 2018-10-11 at 14:29 -0400, Alan Stern wrote:
> > > On Thu, 11 Oct 2018, Mayuresh Kulkarni wrote:
> > [..]
> > > > We are looking into closing the device instance during normal operation
From: Jon Hunter
Currently the XUSB power domains used by the Tegra xHCI controller are
never powered off on the removal of the driver, however, they will be
powered off on probe failure. Update the removal code to be consistent
with the probe failure path to power off the XUSB power domains.
Si
From: Jon Hunter
The generic power-domain framework has been updated to allow devices
that require more than one power-domain to create a new device for
each power-domain required and then link these new power-domain
devices to the consumer device.
Update the Tegra xHCI driver to use the new API
Hi Greg
These two patches are part 2/5 and 3/5 of the Tegra xhci genpd
support series.
It's how Jon Hunter proposed them to be merged:
" This series is making changes to more than one subsystem and at first
glance may look like a maintainers nightmare. However, my proposal is
this, once revie
On Wed 03-10-18 16:46:05, Jan Kara wrote:
> On Wed 03-10-18 17:19:33, Mathias Nyman wrote:
> > On 02.10.2018 17:53, Jan Kara wrote:
> > > On Tue 02-10-18 17:01:54, Mathias Nyman wrote:
> > > > On 02.10.2018 16:06, Jan Kara wrote:
> > > > > Hello,
> > > > >
> > > > > my wife has HP 255 G6 laptop. W
On Di, 2018-10-16 at 10:41 +0200, Julian Xhokaxhiu wrote:
> Good morning Oliver,
>
> thank you very much for the reply. I will try to build a test kernel
> hopefully later this evening and I'll get back to you.
>
> Meanwhile you can see in the attachment in my first email the output
> of `$ lsusb
On Di, 2018-10-16 at 12:10 +0100, Mayuresh Kulkarni wrote:
> On Mon, 15 Oct 2018 09:50:46 -0400
> Alan Stern wrote:
>
> > It seems that a better approach would be to have an ioctl which would:
> >
> > fail if there are any active user URBs;
> >
> > drop the usbfs PM reference so the dev
On Tue, 16 Oct 2018, Mayuresh Kulkarni wrote:
> > How about instead having a mechanism whereby your usrspace driver can
> > tell when the device does a remote wakeup? At that point it could
> > submit an URB via usbfs and receive the async notification.
> >
> > Alan Stern
>
> Unfortunately, t
On 16.10.2018 14:38, Jan Kara wrote:
On Wed 03-10-18 16:46:05, Jan Kara wrote:
On Wed 03-10-18 17:19:33, Mathias Nyman wrote:
On 02.10.2018 17:53, Jan Kara wrote:
On Tue 02-10-18 17:01:54, Mathias Nyman wrote:
On 02.10.2018 16:06, Jan Kara wrote:
Hello,
my wife has HP 255 G6 laptop. When it
On Tue, 16 Oct 2018, Mayuresh Kulkarni wrote:
> > It seems that a better approach would be to have an ioctl which would:
> >
> > fail if there are any active user URBs;
> >
> > drop the usbfs PM reference so the device can suspend;
> >
> > block interruptibly until the device resume
On Tue, 16 Oct 2018, Oliver Neukum wrote:
> On Mo, 2018-10-15 at 09:50 -0400, Alan Stern wrote:
> >
> > It seems that a better approach would be to have an ioctl which would:
> >
> > fail if there are any active user URBs;
> >
> > drop the usbfs PM reference so the device can su
+Andy
These have changed a bit since Andy gave his review.
On Fri, Oct 12, 2018 at 06:00:50PM +, Ajay Gupta wrote:
> Hi Heikki and Wolfram
> Do you have any comments on these changes?
Let me take one more look at the UCSI driver, just in case. Nothing's
probable going to happen for a while i
Hi Peter,
On Tue, Oct 16, 2018 at 2:02 AM Peter Chen wrote:
>
> For USB HSIC, the data and strobe pin needs to be pulled down
> at default, we consider it as "idle" state. When the USB host
> is ready to be used, the strobe pin needs to be pulled up,
> we consider it as "active" state.
>
> Signed
Hi Oliver,
to my surprise I was starting to attempt the patch of the code and the
rebuilt, 30 mins ago, when I noticed a new version was released in
Arch ( 4.18.14 ) so I decided to update and reboot, to see if actually
it changed something and...to my surprise it did!
$ uname -a
Linux anarchy 4.
On 2018-10-02 09:27, Wolfram Sang wrote:
> Hi,
>
We got confirmation from HW team about 4 byte read limitation. There
has to be a STOP after every single read cycle. One read cycle
supports maximum of
4 byte burst. I will update the patches with a comment on this.
>>>
>>> Could
Hello,
Open bug in launchpad.net
https://bugs.launchpad.net/bugs/1798166
"I have a wireless mouse powered by non-rechargeable battery. The
mouse works absolutely fine even with low battery level. Problem is,
Ubuntu gives notifications about the battery level all the time.
I have had this issue f
> I don't think SMBus is an option in this case since the intended client
> (Cypress
> something in patch 2/2) does xfers that would need 16-bit commands and I think
> they are always 8-bit in SMBus, no?
Yes. Command is 8 bit, data can be 16. Thanks for the heads up!
signature.asc
Description
> On Tue, Oct 16, 2018 at 2:02 AM Peter Chen wrote:
> >
> > For USB HSIC, the data and strobe pin needs to be pulled down at
> > default, we consider it as "idle" state. When the USB host is ready to
> > be used, the strobe pin needs to be pulled up, we consider it as
> > "active" state.
> >
> >
On Tue, Oct 16, 2018 at 04:15:34PM -0300, Cristian wrote:
> Hello,
>
> Open bug in launchpad.net
> https://bugs.launchpad.net/bugs/1798166
>
> "I have a wireless mouse powered by non-rechargeable battery. The
> mouse works absolutely fine even with low battery level. Problem is,
> Ubuntu gives no
num can be indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/usb/gadget/function/f_mass_storage.c:3177 fsg_lun_make() warn:
potential spectre issue 'fsg_opts->common->luns
Hi Greg,
"Gustavo A. R. Silva" writes:
> num can be indirectly controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> drivers/usb/gadget/function/f_mass_storage.c:3177 fsg_lun_make()
On Tue, Oct 16, 2018 at 02:28:19PM +0300, Felipe Balbi wrote:
>
> Hi Greg,
>
> "Gustavo A. R. Silva" writes:
>
> > num can be indirectly controlled by user-space, hence leading to
> > a potential exploitation of the Spectre variant 1 vulnerability.
> >
> > This issue was detected with the help
On 16.10.2018 14:37, Zeng Tao wrote:
It is introduced for the pre-0.96 xHC controllers, and the driver only
support HW LPM for 1.0 and later controllers.It's not actually used now
and is thought not to be used in the future any more, so just remove it.
Acked-by: Mathias Nyman
Please don't add
Upon success the update_status handler returns a positive number
corresponding to the number of bytes transferred by usb_control_msg.
However the return code of the update_status handler should indicate if
an error occurred(negative) or how many bytes of the user's input to sysfs
that was consumed.
From: Colin Ian King
Currently the call to atoi is being passed a single char string
that is not null terminated, so there is a potential read overrun
along the stack when parsing for an integer value. Fix this by
instead using a 2 char string that is initialized to all zeros
to ensure that a 1
Hi Mathias:
>-Original Message-
>From: Mathias Nyman [mailto:mathias.ny...@linux.intel.com]
>Sent: Tuesday, October 16, 2018 8:34 PM
>To: Zengtao (B) ; mathias.ny...@intel.com;
>gre...@linuxfoundation.org
>Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org
>Subject: Re: [PATCH] x
31 matches
Mail list logo
