On Mon, Jun 24, 2019 at 10:33:23AM +0200, Oliver Neukum wrote:
> If you deregister a device you need to wake up all waiters
> as there will be no further wakeups.
>
> Signed-off-by: Oliver Neukum
> ---
> drivers/gnss/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
The usb phys are internal to the SoC and so it their 5V supply. With
this regulator added explicitly the following (harmless) boot messages
go away:
usb_phy_generic usbphy:usb-phy@0: usbphy:usb-phy@0 supply vcc not
found, using dummy regulator
usb_phy_generic usbphy:usb-phy@1: usb
On Mon, 2019-06-24 at 13:48 -0400, Alan Stern wrote:
> On Mon, 24 Jun 2019, Mayuresh Kulkarni wrote:
>
> >
> > On Fri, 2019-06-21 at 15:28 -0400, Alan Stern wrote:
> > >
> > > On Fri, 21 Jun 2019, Mayuresh Kulkarni wrote:
> > >
> > > >
> > > >
> > > > Hi Alan,
> > > >
> > > > With the sugges
Hello!
On 25.06.2019 13:04, Uwe Kleine-König wrote:
The usb phys are internal to the SoC and so it their 5V supply. With
s/it/is/?
this regulator added explicitly the following (harmless) boot messages
go away:
usb_phy_generic usbphy:usb-phy@0: usbphy:usb-phy@0 supply vcc not
f
Hello!
The subject has gpss ISO gnss. You hardly meant the General Purpose
System Simulation. :-)
On 24.06.2019 11:33, Oliver Neukum wrote:
If you deregister a device you need to wake up all waiters
as there will be no further wakeups.
Signed-off-by: Oliver Neukum
---
drivers/gnss/core.
On 24.6.2019 21.11, Alan Stern wrote:
On Sun, 23 Jun 2019, Harutyun Khachatryan wrote:
Dear Alan Stern,
I thought that I should wait Mathias's response. I am terribly sorry for
that. I am sending dmesg log and trace content as you asked. I tried the
procedure on kernel 5.1.12-050112-generic si
On Tue, 25 Jun 2019, Mayuresh Kulkarni wrote:
> > There are two possible ways a userspace program can monitor the
> > device's state:
> >
> > 1. The program can leave an URB (typically on an interrupt
> > endpoint) running constantly, and the device can send its
> > response t
In the current kernel, devio.c generates a number of compiler warnings
about taking the address of a member of a packed structure. The
warnings all look like this one:
drivers/usb/core/devio.c: In function ‘proc_do_submiturb’:
drivers/usb/core/devio.c:1489:43: warning: taking addr
Commit 4a2a8a2cce86 ("usbfs: private mutex for open, release, and
remove") is now obsolete. The commit was created back when we had
to handle both usbfs device nodes and the old usbdevfs filesystem
(/proc/bus/usb/), but usbdevfs no longer exists.
This means there's no longer any need to hold a mu
On Tue, Jun 25, 2019 at 04:03:58PM -0400, Alan Stern wrote:
> Commit 4a2a8a2cce86 ("usbfs: private mutex for open, release, and
> remove") is now obsolete. The commit was created back when we had
> to handle both usbfs device nodes and the old usbdevfs filesystem
> (/proc/bus/usb/), but usbdevfs n
> Subject: [PATCH] ARM: imx25: provide a fixed regulator for usb phys
>
> The usb phys are internal to the SoC and so it their 5V supply. With this
> regulator
> added explicitly the following (harmless) boot messages go away:
>
> usb_phy_generic usbphy:usb-phy@0: usbphy:usb-phy@0 supply
On 19-06-26 02:40, Peter Chen wrote:
>
> > Subject: [PATCH] ARM: imx25: provide a fixed regulator for usb phys
> >
> > The usb phys are internal to the SoC and so it their 5V supply. With this
> > regulator
> > added explicitly the following (harmless) boot messages go away:
> >
> > usb_ph
This change fixes below wrong warning messages:
[ 173.473153] xhci-hcd xhci-hcd.0.auto: WARN Wrong bounce buffer write length:
1024 != 990
[ 173.530633] xhci-hcd xhci-hcd.0.auto: WARN Wrong bounce buffer write length:
490 != 1014
[ 173.541598] xhci-hcd xhci-hcd.0.auto: WARN Wrong bounce buffe
13 matches
Mail list logo
