On Wed, Nov 01, 2017 at 11:38:13PM +0100, L. Rose wrote:
> Hi, thanks for replying!
>
> > Could you send acpidump to me?
> Sorry, but can you point me a URL where to get acpidump? I'm running
> arch, but any x86_64-binary or source code should be fine. Couldn't find
> it anywhere on the net.
It i
On Thu, Nov 02, 2017 at 09:36:42AM +0800, Lu Baolu wrote:
> Hi Greg,
>
> On 09/05/2017 09:58 AM, Lu Baolu wrote:
> > xHCI compatible USB host controllers(i.e. super-speed USB3 controllers)
> > can be implemented with the Debug Capability(DbC). It presents a debug
> > device which is fully complian
On 01/11/17 17:45, Alan Stern wrote:
> On Wed, 1 Nov 2017, Roger Quadros wrote:
>
>>> Roger, would you like to send in a follow-up patch that removes the now
>>> unnecessary code from dummy_udc_set_speed() in dummy_hcd.c?
>>>
>>
>> Sure. I have a question though.
>>
>> In dummy_udc_set_speed() we
USB 3.1 added a PTM_STATUS type. Let's add a define for it and
following patches will let usb_get_status() accept the new argument.
Signed-off-by: Felipe Balbi
---
drivers/usb/core/message.c | 4 ++--
include/uapi/linux/usb/ch9.h | 4
2 files changed, 6 insertions(+), 2 deletions(-)
diff
Hi,
Here's the new revision of PTM status support patches with the changes
requested by Alan Stern.
Changes since v1:
- move code around to avoid two changes to all users of
usb_get_status()
Felipe Balbi (5):
usb: core: add Status Type definitions
usb: core: rename usb_get_
This new helper is a simple wrapper around usb_get_status(). This
patch is in preparation to adding support for fetching PTM_STATUS
types. No functional changes.
Signed-off-by: Felipe Balbi
---
drivers/staging/wlan-ng/hfa384x_usb.c | 4 ++--
drivers/usb/core/driver.c | 4 ++--
driver
This new 'type' parameter will allows interested drivers to request
for PTM status or Standard status.
Signed-off-by: Felipe Balbi
---
drivers/usb/core/message.c | 47 +++---
include/linux/usb.h| 5 +++--
2 files changed, 43 insertions(+), 9 delet
Drivers who are interested in the PTM status stype, should use this
new helper to make sure they issue the correct GetStatus message.
Signed-off-by: Felipe Balbi
---
include/linux/usb.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 6228
This makes it a lot clearer that we're expecting a recipient as the
argument. A follow-up patch will use the argument 'type' as the status
type selector (standard or ptm).
Signed-off-by: Felipe Balbi
---
drivers/usb/core/message.c | 6 +++---
include/linux/usb.h| 2 +-
2 files changed, 4
The UDC core ensures that .udc_set_speed() is called with
a speed that is a minimum of the max speeds supported
by the gadget function driver and the UDC driver.
We can now use the speed argument as is.
Get rid of the debug print as that condition will never happen.
Signed-off-by: Roger Quadros
Hi,
Greg Kroah-Hartman writes:
>> > xHCI compatible USB host controllers(i.e. super-speed USB3 controllers)
>> > can be implemented with the Debug Capability(DbC). It presents a debug
>> > device which is fully compliant with the USB framework and provides the
>> > equivalent of a very high perf
On Thu, Nov 02, 2017 at 11:15:43AM +0200, Felipe Balbi wrote:
>
> Hi,
>
> Greg Kroah-Hartman writes:
> >> > xHCI compatible USB host controllers(i.e. super-speed USB3 controllers)
> >> > can be implemented with the Debug Capability(DbC). It presents a debug
> >> > device which is fully compliant
Hi,
Greg Kroah-Hartman writes:
>> Greg Kroah-Hartman writes:
>> >> > xHCI compatible USB host controllers(i.e. super-speed USB3 controllers)
>> >> > can be implemented with the Debug Capability(DbC). It presents a debug
>> >> > device which is fully compliant with the USB framework and provides
Hi,
+Dan and Guenter
I'm sorry for the late reply. These slipped under my radar. I do
have a one more proposal below, and a few nits..
On Wed, Oct 18, 2017 at 01:22:48PM -0700, Badhri Jagan Sridharan wrote:
> At present, TCPM code assumes that local device supports
> variable/batt pdos and alway
While usb_control_msg function expects timeout in miliseconds, a value
of HZ is used. Replace it with USB_CTRL_GET_TIMEOUT and also fix error
message which looks like:
udlfb: Read EDID byte 78 failed err ff92
as error is either negative errno or number of bytes transferred use %d
format specifi
+Dan and Guenter,
I don't have any problems with this, but since I had those few
comments for the 2/2 of this series, few nitpics below..
On Wed, Oct 18, 2017 at 01:22:47PM -0700, Badhri Jagan Sridharan wrote:
> The source and sink caps should follow the following rules.
> This patch validates wh
On 01 November 2017 17:20, Greg Kroah-Hartman wrote:
> On Wed, Nov 01, 2017 at 05:03:10PM +, Adam Thomson wrote:
> > This commit adds a header providing definitions for handling Alert
> > messages. Currently the header only focuses on handling incoming
> > alerts.
> >
> > Signed-off-by: Adam T
On 01 November 2017 17:21, Greg Kroah-Hartman wrote:
> On Wed, Nov 01, 2017 at 05:03:11PM +, Adam Thomson wrote:
> > This commit adds a header providing definitions for handling
> > Status messages. Currently the header only focuses on handling
> > incoming Status messages.
> >
> > Signed-off-
Hi Bjorn,
On Wed, 2017-11-01 at 15:24 -0700, Bjorn Andersson wrote:
[...]
> > > This looks more or less identical to how regulators and clocks already
> > > deals with resources in bulk; see regulator_bulk_data and clk_bulk_data
> > > and their associated functions.
> > >
> > > I would really lik
On 01 November 2017 20:09, Jack Pham wrote:
> Hi Adam,
>
> On Wed, Nov 01, 2017 at 05:03:09PM +, Adam Thomson wrote:
> > This commit adds definitions for PD Rev 3.0 messages, including
> > APDO PPS and extended message support for TCPM.
> >
> > Signed-off-by: Adam Thomson
> > ---
> > include
On Thu, 2 Nov 2017, Roger Quadros wrote:
> On 01/11/17 17:45, Alan Stern wrote:
> > On Wed, 1 Nov 2017, Roger Quadros wrote:
> >
> >>> Roger, would you like to send in a follow-up patch that removes the now
> >>> unnecessary code from dummy_udc_set_speed() in dummy_hcd.c?
> >>>
> >>
> >> Sure. I
On Thu, 2 Nov 2017, Roger Quadros wrote:
> The UDC core ensures that .udc_set_speed() is called with
> a speed that is a minimum of the max speeds supported
> by the gadget function driver and the UDC driver.
>
> We can now use the speed argument as is.
>
> Get rid of the debug print as that con
On 10/31/2017 07:03 PM, Bart Van Assche wrote:
> Considerable time ago the legacy gadget menu was added inside the
> USB_ETH choice. I think this was a mistake and that the legacy
> gadget menu should have been added after "endchoice" instead of
> before. Hence this patch.
>
> Fixes: commit 8443f2
The support for 36-bit addresses originally came with an incorrect
printk format for dma addresses. Felipe changed the format string it
while applying, but the result was still incorrect, since we now have
to pass a pointer to the address instead of the integer value:
drivers/usb/mtu3/mtu3_qmu.c:
Hi,
This is the trace output: https://pastebin.com/apt56yGe
I'm going to ask in Arch forums to see how I can get the differences
of the xhci_hcd module in both versions of the kernel.
Thanks.
Regards.
2017-11-01 12:11 GMT+01:00 Mathias Nyman :
> On 31.10.2017 16:45, Juan Simón wrote:
>>
>> Hi,
>>
The time_t type and time_to_tm() function are deprecated because
of y2038 problems. In this driver, they are used to pretty-print
the timestamp of the firmware build. This is fine as long as
we don't get a firmware build past 2038.
Converting to time64_t and time64_to_tm() avoids the deprecated
in
On Thu, Nov 02, 2017 at 03:28:19PM +0100, Juan Simón wrote:
> Hi,
> This is the trace output: https://pastebin.com/apt56yGe
>
> I'm going to ask in Arch forums to see how I can get the differences of the
> xhci_hcd module in both versions of the kernel.
The arch kernels are the same as the kernel
Hi,
Arnd Bergmann writes:
> The support for 36-bit addresses originally came with an incorrect
> printk format for dma addresses. Felipe changed the format string it
> while applying, but the result was still incorrect, since we now have
> to pass a pointer to the address instead of the integer
We had another go at it and this is what we have now.
Already we can tell that it's much more efficient when we have multiple
errors in a row we don't send as much clear requests.
Can somebody comment?
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 26bda88..0f5a91
From: Colin Ian King
Don't populate the const array max_packet_array on the stack, instead make
it static. Makes the object code smaller by over 90 bytes:
Before:
textdata bss dec hex filename
343375612 128 400779c8d renesas_usb3.o
After:
textdata b
On Thu, Nov 02, 2017 at 03:34:27PM +0100, Arnd Bergmann wrote:
> The time_t type and time_to_tm() function are deprecated because
> of y2038 problems. In this driver, they are used to pretty-print
> the timestamp of the firmware build. This is fine as long as
> we don't get a firmware build past 20
When babble condition happens, the musb controller might automatically
turns off VBUS. On DA8xx platform, the controller generates drvvbus
interrupt for turning off VBUS along with the babble interrupt.
In this case, we should handle the babble interrupt first and recover
from the babble condition
The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f:
Linux 4.14-rc4 (2017-10-08 20:53:29 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git
tags/usb-serial-4.15-rc1
for you to fetch changes up to 7c36e6e
> What do you mean by "device app runs to completion"? What is the "device
> app"? Is it the functionfs application you're talking about? And by
> "completion"
> do you mean that it completely stops running or is it just sleeping waiting
> for
> some input?
"device app runs to completion" means
On Thu, Nov 02, 2017 at 05:27:27PM +0100, Johan Hovold wrote:
> The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f:
>
> Linux 4.14-rc4 (2017-10-08 20:53:29 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-
On Thu, Nov 02, 2017 at 04:37:51PM +, andy_purc...@keysight.com wrote:
> > What do you mean by "device app runs to completion"? What is the "device
> > app"? Is it the functionfs application you're talking about? And by
> > "completion"
> > do you mean that it completely stops running or is it
On Thu, Nov 02, 2017 at 11:40:12AM +, Adam Thomson wrote:
> On 01 November 2017 17:20, Greg Kroah-Hartman wrote:
>
> > On Wed, Nov 01, 2017 at 05:03:10PM +, Adam Thomson wrote:
> > > This commit adds a header providing definitions for handling Alert
> > > messages. Currently the header onl
On Thu, Nov 02, 2017 at 12:38:57PM +0200, Felipe Balbi wrote:
>
> Hi,
>
> Greg Kroah-Hartman writes:
> >> Greg Kroah-Hartman writes:
> >> >> > xHCI compatible USB host controllers(i.e. super-speed USB3
> >> >> > controllers)
> >> >> > can be implemented with the Debug Capability(DbC). It prese
On 02.11.2017 16:31, Juan Simón wrote:
Hi,
This is the trace output: https://pastebin.com/apt56yGe
Thanks
xhci logs look pretty good to me. A interrupt transfer TRB is queued
asking for 32 bytes from the mouse, and mouse replies with 15 bytes.
After this and we immediately queue the next TRB.
On 02 November 2017 16:49, Greg Kroah-Hartman wrote:
> On Thu, Nov 02, 2017 at 11:40:12AM +, Adam Thomson wrote:
> > On 01 November 2017 17:20, Greg Kroah-Hartman wrote:
> >
> > > On Wed, Nov 01, 2017 at 05:03:10PM +, Adam Thomson wrote:
> > > > This commit adds a header providing definiti
On Thu, Nov 02, 2017 at 05:34:22PM +, Adam Thomson wrote:
> On 02 November 2017 16:49, Greg Kroah-Hartman wrote:
>
> > On Thu, Nov 02, 2017 at 11:40:12AM +, Adam Thomson wrote:
> > > On 01 November 2017 17:20, Greg Kroah-Hartman wrote:
> > >
> > > > On Wed, Nov 01, 2017 at 05:03:10PM +
Hello,
I have a second issue with a functionfs USB-device implementation.
The scenario is this:
1) USB-device app starts up, runs fine
2) ssh to the device, kill the app with CTRL-C
3) try to start the USB-device app 2nd time
PANIC
dmesg output:
[ 2553.87] [ cut here ]---
* Bin Liu [171031 18:35]:
> Hi,
>
> On Tue, Oct 31, 2017 at 12:56:40PM -0500, Adam Ford wrote:
> > We have a situation where occasionally the USB glitches where the D-
> > glitches low at or near an end of frame (EOF) or end of packet (EOP).
> > We're using the TWL4030 with MUSB on an OMAP3 proce
On Thu, Nov 2, 2017 at 2:43 PM, Tony Lindgren wrote:
> * Bin Liu [171031 18:35]:
>> Hi,
>>
>> On Tue, Oct 31, 2017 at 12:56:40PM -0500, Adam Ford wrote:
>> > We have a situation where occasionally the USB glitches where the D-
>> > glitches low at or near an end of frame (EOF) or end of packet (E
When asix_suspend() is called dev->driver_priv might not have been
assigned a value, so we need to check that it's not NULL.
Found by syzkaller.
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] PREEMPT SMP KA
On Thu, 2 Nov 2017, Gervais, Francois wrote:
> We had another go at it and this is what we have now.
>
> Already we can tell that it's much more efficient when we have multiple
> errors in a row we don't send as much clear requests.
>
> Can somebody comment?
>
> diff --git a/drivers/usb/musb/mu
Hello,
>
> And where is your swap? What happens if you just do not have swap at all?
Our system has no swap. Running 'top' says 0 total, 0 free, 0 used
>
> > A colleague claims mlockall() does not help, and says it is not a good
> > idea anyway.
>
> That's not true, have you tried it?
Dev
On Thu, Nov 02, 2017 at 08:43:04PM +, andy_purc...@keysight.com wrote:
> Hello,
>
>
> >
> > And where is your swap? What happens if you just do not have swap at all?
> Our system has no swap. Running 'top' says 0 total, 0 free, 0 used
then your program can not get swapped out, so this wh
Greg,
> >
> > >
> > > And where is your swap? What happens if you just do not have swap at all?
> > Our system has no swap. Running 'top' says 0 total, 0 free, 0 used
>
> then your program can not get swapped out, so this whole thing is crazy.
Colleague says when there is memory pressure, prog
hi,
On Thu, 2017-11-02 at 15:30 +0100, Arnd Bergmann wrote:
> The support for 36-bit addresses originally came with an incorrect
> printk format for dma addresses. Felipe changed the format string it
> while applying, but the result was still incorrect, since we now have
> to pass a pointer to the
Hi Alex,
On Tue, Oct 31, 2017 at 08:11:30AM -0500, Alex Elder wrote:
> No Qualcomm SoC requires the "phy-msm-usb.c" USB phy driver support
> any more, so remove the code.
>
> Suggested-by: Stephen Boyd
> Signed-off-by: Alex Elder
> Acked-by: Bjorn Andersson
> Acked-by: Andy Gross
> ---
> -#
The last two remaining drivers (ehci-msm.c and phy-msm-usb.c) that
needed this header were recently removed, so delete this now-unused
file.
Signed-off-by: Jack Pham
---
include/linux/usb/msm_hsusb_hw.h | 77
1 file changed, 77 deletions(-)
delete mode 1
Hi,
On 11/03/2017 12:51 AM, Greg Kroah-Hartman wrote:
> On Thu, Nov 02, 2017 at 12:38:57PM +0200, Felipe Balbi wrote:
>> >
>> > Hi,
>> >
>> > Greg Kroah-Hartman writes:
> >> Greg Kroah-Hartman writes:
>>> > >> >> > xHCI compatible USB host controllers(i.e. super-speed USB3
>>> >
On Fri, Nov 03, 2017 at 08:45:46AM +0800, Lu Baolu wrote:
> Hi,
>
> On 11/03/2017 12:51 AM, Greg Kroah-Hartman wrote:
> > On Thu, Nov 02, 2017 at 12:38:57PM +0200, Felipe Balbi wrote:
> >> >
> >> > Hi,
> >> >
> >> > Greg Kroah-Hartman writes:
> > >> Greg Kroah-Hartman writes:
> >>> >
54 matches
Mail list logo
