Hi Benjamin,
On Wed, Jun 7, 2017 at 9:11 AM, Benjamin Tissoires
wrote:
> Hi Philip,
>
> On Jun 07 2017 or thereabouts, Philipp Zabel wrote:
[...]
> 2 things:
> - the 2 patches should be squashed together. There is no point having a
> single patch for just 2 defines not used anywhere else.
> - I
Hi,
On 08-06-17 02:00, Rafael J. Wysocki wrote:
Hi All,
This series is a replacement for commit eed4d47efe95 (ACPI / sleep: Ignore
spurious SCI wakeups from suspend-to-idle) which is still there in 4.12-rc4 but
will be reverted shortly, because it triggered issues on quite a few systems.
The l
On Jun 08 2017 or thereabouts, Philipp Zabel wrote:
> Hi Benjamin,
>
> On Wed, Jun 7, 2017 at 9:11 AM, Benjamin Tissoires
> wrote:
> > Hi Philip,
> >
> > On Jun 07 2017 or thereabouts, Philipp Zabel wrote:
> [...]
> > 2 things:
> > - the 2 patches should be squashed together. There is no point ha
Benjamin Herrenschmidt writes:
> And another one :-)
>
> So the virtual hub needs a vendor/device ID.
>
> What is the policy here ? Can I get one from LF for it ? Or should the
> HW vendor provide one here ? (I'm not sure they have one, I will have
> to ask).
>
> I will provide a way to override
This looks wrong:
#define EndpointRequest \
((USB_DIR_IN|USB_TYPE_STANDARD|USB_RECIP_INTERFACE)<<8)
#define EndpointOutRequest \
((USB_DIR_OUT|USB_TYPE_STANDARD|USB_RECIP_INTERFACE)<<8)
Shouldn't it be USB_RECIP_ENDPOINT ?
If I'm right, we had issues with some of the set/clear fe
On Thu, 2017-06-08 at 10:18 +0200, Bjørn Mork wrote:
> Benjamin Herrenschmidt writes:
>
> > And another one :-)
> >
> > So the virtual hub needs a vendor/device ID.
> >
> > What is the policy here ? Can I get one from LF for it ? Or should the
> > HW vendor provide one here ? (I'm not sure they
On Thu, Jun 08, 2017 at 06:38:40PM +1000, Benjamin Herrenschmidt wrote:
> Alan, do you know the process to get one of the LF IDs ? Is that a
> reasonable request ?
Again, just ask me for one, I'm the one that give them out :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsu
Rafael,
On Thu, Jun 08, 2017 at 02:00:40AM +0200, Rafael J. Wysocki wrote:
> Hi All,
>
> This series is a replacement for commit eed4d47efe95 (ACPI / sleep: Ignore
> spurious SCI wakeups from suspend-to-idle) which is still there in 4.12-rc4
> but
> will be reverted shortly, because it triggered
Hi Alan,
Alan Stern writes:
> On Wed, 7 Jun 2017, Felipe Balbi wrote:
>
>> Move the code which was part of pullup() to the newly introduced
>> method.
>
> Comments inline...
thanks for your comments. I think I've fixed them all.
8<---
On Thu, 2017-06-08 at 08:12 +0200, Greg KH wrote:
> On Thu, Jun 08, 2017 at 04:04:43PM +1000, Benjamin Herrenschmidt wrote:
> > And another one :-)
> >
> > So the virtual hub needs a vendor/device ID.
> >
> > What is the policy here ? Can I get one from LF for it ?
>
> Yes, just ask me and I'll
We don't (yet) support PTM_STATUS messages so let's not reply to them
erroneously.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/ep0.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 8cfce8425101..827e376bfa97 100644
--- a/driver
On Wed, Jun 7, 2017 at 11:20 PM, Alan Stern wrote:
> On Wed, 7 Jun 2017, Andrey Konovalov wrote:
>
>> On Wed, Jun 7, 2017 at 4:43 PM, Alan Stern wrote:
>> > On Wed, 7 Jun 2017, Andrey Konovalov wrote:
>> >
>> >> Hi,
>> >>
>> >> I've got the following error report while fuzzing the kernel with
>>
TUSB1211 is software compatible with TUSB1210 and as such we don't
need an entire new driver to control it. Let's add its product ID to
the existing TUSB1210 driver instead.
Signed-off-by: Felipe Balbi
---
drivers/phy/phy-tusb1210.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -
If PHY is suspended by the time we want to issue ULPI transfers, we
will observe timeouts on the ULPI interface. In order to avoid such
issue, let's make sure PHY is resumed before issuing a ULPI transfer.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/ulpi.c | 12
1 file changed,
If don't reorder initialization like this, we will never be able to
get a reference to ULPI PHYs.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 455d89a
If PHY is entering Host mode, we need to enable VBUS.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 3cbbffaee258..f9d7f2fe76e3 100644
->set_mode() can be used to tell PHY to prepare itself to enter USB
Host/Peripheral mode and that's very important for DRD
configurations.
Signed-off-by: Felipe Balbi
---
drivers/phy/phy-tusb1210.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/p
On Thursday, June 08, 2017 10:42:02 AM Dominik Brodowski wrote:
> Rafael,
>
> On Thu, Jun 08, 2017 at 02:00:40AM +0200, Rafael J. Wysocki wrote:
> > Hi All,
> >
> > This series is a replacement for commit eed4d47efe95 (ACPI / sleep: Ignore
> > spurious SCI wakeups from suspend-to-idle) which is s
Hi Peter
I have a look at your patches
(http://www.spinics.net/lists/linux-usb/msg157134.html) and I wonder
if power sequence is applicable only on hub node? hub are probed too late
(after ci_ulpi_init). Do
you think it is possible to read a power sequence in dts from ci_ulpi_init?
Thanks
Fabi
On Thu, Jun 08, 2017 at 07:39:15PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2017-06-08 at 08:12 +0200, Greg KH wrote:
> > On Thu, Jun 08, 2017 at 04:04:43PM +1000, Benjamin Herrenschmidt wrote:
> > > And another one :-)
> > >
> > > So the virtual hub needs a vendor/device ID.
> > >
> > > Wh
On Thu, 8 Jun 2017, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> hcd_pci_resume_noirq() used as a universal _resume_noirq handler for
> PCI USB controllers calls pci_back_from_sleep() which is unnecessary
> and may become problematic.
>
> It is unnecessary, because the PCI bus type ca
On Thu, 8 Jun 2017, Benjamin Herrenschmidt wrote:
> Another question ...
>
> Do i need to support dequeue() on EP0 ?
Yes. I don't know if any drivers ever dequeue requests from ep0, but
it should be supported.
There is one other special requirement for ep0. When a new setup
packet arrives, a
On Thu, 8 Jun 2017, Benjamin Herrenschmidt wrote:
> This looks wrong:
>
> #define EndpointRequest \
> ((USB_DIR_IN|USB_TYPE_STANDARD|USB_RECIP_INTERFACE)<<8)
> #define EndpointOutRequest \
> ((USB_DIR_OUT|USB_TYPE_STANDARD|USB_RECIP_INTERFACE)<<8)
>
> Shouldn't it be USB_RECIP_ENDPOI
On Thu, 8 Jun 2017, Felipe Balbi wrote:
> Hi Alan,
>
> Alan Stern writes:
> > On Wed, 7 Jun 2017, Felipe Balbi wrote:
> >
> >> Move the code which was part of pullup() to the newly introduced
> >> method.
> >
> > Comments inline...
>
> thanks for your comments. I think I've fixed them all.
>
>
On Thu, 8 Jun 2017, Andrey Konovalov wrote:
> On Wed, Jun 7, 2017 at 11:20 PM, Alan Stern wrote:
> > On Wed, 7 Jun 2017, Andrey Konovalov wrote:
> >
> >> On Wed, Jun 7, 2017 at 4:43 PM, Alan Stern
> >> wrote:
> >> > On Wed, 7 Jun 2017, Andrey Konovalov wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >>
From: Rafał Miłecki
This version of my patchset (V5) differs by renaming #source-cells to the
#trigger-source-cells and documenting it in the leds/common.txt.
I'd epxect both patches to go through Greg's usb.git if accepted.
For a reference (and before someome comes with already rejected soluti
From: Rafał Miłecki
Some LEDs can be related to a specific device(s) described in the DT.
This property allows specifying such relations. E.g. USB LED should
usually be used to indicate some USB port(s) state.
Please note this binding is designed to be generic and not influenced by
any operating
From: Rafał Miłecki
This uses DT info to read relation description of LEDs and USB ports. If
DT has properly described LEDs, trigger will know when to turn them on.
Signed-off-by: Rafał Miłecki
---
V2: Update to use "led-triggers"
V3: Update to use "trigger-sources"
V5: Read #trigger-source-cel
From: Rafał Miłecki
Signed-off-by: Rafał Miłecki
---
This patch *should not* be applied. It's only an EXAMPLE and that's why it uses
that weird 3/2 number.
It's a proof of concept, it was tested & will be submitted through ARM tree if
previous patches get accepted.
V3: Switch to the new bindin
On Thu, Jun 8, 2017 at 5:55 PM, Alan Stern wrote:
> On Thu, 8 Jun 2017, Andrey Konovalov wrote:
>
>> On Wed, Jun 7, 2017 at 11:20 PM, Alan Stern
>> wrote:
>> > On Wed, 7 Jun 2017, Andrey Konovalov wrote:
>> >
>> >> On Wed, Jun 7, 2017 at 4:43 PM, Alan Stern
>> >> wrote:
>> >> > On Wed, 7 Jun 2
A NULL-pointer dereference bug in gadgetfs was uncovered by syzkaller:
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 2 PID: 4820 Comm: syz-executor
Hi,
Alan Stern writes:
> On Thu, 8 Jun 2017, Felipe Balbi wrote:
>
>> Hi Alan,
>>
>> Alan Stern writes:
>> > On Wed, 7 Jun 2017, Felipe Balbi wrote:
>> >
>> >> Move the code which was part of pullup() to the newly introduced
>> >> method.
>> >
>> > Comments inline...
>>
>> thanks for your com
> Normally in this situation I'd recommend bisection. However, this case
> may be simple enough for a usbmon trace to provide the answer.
With a shared file system between the T100TA and a big machine it's not
too hard to do some builds:
commit 76dd1fbebbaebab294dc09230960238746b883b1
is the of
On Thu, 8 Jun 2017, Alan Cox wrote:
> > Normally in this situation I'd recommend bisection. However, this case
> > may be simple enough for a usbmon trace to provide the answer.
>
> With a shared file system between the T100TA and a big machine it's not
> too hard to do some builds:
>
> commit
On Thu, 8 Jun 2017, Felipe Balbi wrote:
> > Any results on testing the new memory barrier and exception handling
> > patches for f_mass_storage?
>
> Oh, I couldn't reproduce anymore. I thought I had told ya. Hopefully,
> this will be the last we hear from this problem :-s
Does that mean you wi
On Thu, Jun 8, 2017 at 12:49 PM, Alan Stern wrote:
>
> So maybe CONFIG_HID_ASUS should default to Y? I'll leave it up to Hans
> to straighten this out.
No, I think the main problem is that the hid_have_special_driver[]
array change is garbage.
It adds the ASUS ID, regardless of whether the spec
From: Yueyao Zhu
Instead of calling usb_enable_autosuspend() to change the configuration
of a USB device as an interface driver, enable autosuspend for every
interfaces that the driver claims.
Signed-off-by: Yueyao Zhu
---
sound/usb/card.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a
From: Yueyao Zhu
An interface driver can allow/disallow autosuspend power control
for an interface, and if all the interfaces of the active configuration
are allowed for autosuspend, autosuspend should be enabled
on the usb device.
Signed-off-by: Yueyao Zhu
---
drivers/usb/core/driver.c | 55 +
From: Yueyao Zhu
usage pages only points to CONSUMER. This allows autosuspend
to be enabled and thus power saved on CONSUMER hid devices.
Yet hid devices use other usage pages are not affected, e.g.
keyboard, mouse.
Signed-off-by: Yueyao Zhu
---
drivers/hid/usbhid/hid-core.c | 37 +
From: Yueyao Zhu
Currently, if a USB driver would like to enable autosuspend on the USB
device, usb_enable_autosuspend() seems to be the only option. However,
this acts on the device level, and other interfaces might not desire
to autosuspend the USB device.
For example, for the usb digital audi
On Thursday, June 08, 2017 11:24:55 AM Alan Stern wrote:
> On Thu, 8 Jun 2017, Rafael J. Wysocki wrote:
>
> > From: Rafael J. Wysocki
> >
> > hcd_pci_resume_noirq() used as a universal _resume_noirq handler for
> > PCI USB controllers calls pci_back_from_sleep() which is unnecessary
> > and may
On Thu, 2017-06-08 at 11:30 -0400, Alan Stern wrote:
> On Thu, 8 Jun 2017, Benjamin Herrenschmidt wrote:
>
> > Another question ...
> >
> > Do i need to support dequeue() on EP0 ?
>
> Yes. I don't know if any drivers ever dequeue requests from ep0, but
> it should be supported.
>
> There is o
On Thu, 2017-06-08 at 11:30 -0400, Alan Stern wrote:
> On Thu, 8 Jun 2017, Benjamin Herrenschmidt wrote:
>
> > Another question ...
> >
> > Do i need to support dequeue() on EP0 ?
>
> Yes. I don't know if any drivers ever dequeue requests from ep0, but
> it should be supported.
Talking of whi
v2 : fix coding format
When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
performance was manifesting in Web browser use (like download
large file such as ISO image). It is known limitation of
ASM1042A that is not compatible with driver scheduling,
As a workaround we can modify flow c
Hi,
Jiahau Chang writes:
> v2 : fix coding format
this doesn't need to be in the commit log. You should place such notes
after the tearline (---) below
> When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad
> performance was manifesting in Web browser use (like download
> large file
Allow for ftrace data to be exported over a USB Gadget
Controller. With this, we have a potentially very fast pipe for
transmitting ftrace data to a Host PC for further analysis.
Note that in order to decode the data, one needs access to kernel
symbols in order to convert binary data into function
On Wed, Jun 7, 2017 at 9:09 PM, Alan Stern wrote:
> On Wed, 7 Jun 2017, lingareddy praneethreddy wrote:
>
>> On Tue, Jun 6, 2017 at 7:38 PM, Alan Stern wrote:
>> >>On Tue, 6 Jun 2017, lingareddy praneethreddy wrote:
>> >>
>> >> I am using Chipidea HDRC on imx6sl platform. On connecting USB stick
Hi,
"Lars Chang(張家豪)" writes:
>> -Original Message-
>> From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
>> Sent: Friday, June 09, 2017 2:04 PM
>> To: Jiahau Chang; linux-usb@vger.kernel.org; mathias.ny...@intel.com
>> Cc: Brain Lee(李魁中); mario.limoncie...@dell.com; Justin_CY Chen
Hi everyone,
here is a bug that occurs when a RTL8153 is connected to the host via an
ASM1042A chip. I wrongly submitted a report at bugzilla.kernel.org - sorry for
that.
RTL8153 connected via ASM1042A is used in Dell's TB15 and TB16 docks. So anyone
using these docks is probably affected.
To
> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> Sent: Friday, June 09, 2017 2:04 PM
> To: Jiahau Chang; linux-usb@vger.kernel.org; mathias.ny...@intel.com
> Cc: Brain Lee(李魁中); mario.limoncie...@dell.com; Justin_CY Chen(陳志勇);
> keith_w...@dell.com; Yd Tse
On Fri, Jun 09, 2017 at 11:57:23AM +0530, lingareddy praneethreddy wrote:
> On Wed, Jun 7, 2017 at 9:09 PM, Alan Stern wrote:
> > On Wed, 7 Jun 2017, lingareddy praneethreddy wrote:
> >
> >> On Tue, Jun 6, 2017 at 7:38 PM, Alan Stern
> >> wrote:
> >> >>On Tue, 6 Jun 2017, lingareddy praneethredd
On Fri, Jun 09, 2017 at 06:33:39AM +, Lars Chang(張家豪) wrote:
> ==
> This email and any attachments to it contain confidential information and are
> intended solely for the use of the
Hi,
Alan Stern writes:
> On Thu, 8 Jun 2017, Felipe Balbi wrote:
>
>> > Any results on testing the new memory barrier and exception handling
>> > patches for f_mass_storage?
>>
>> Oh, I couldn't reproduce anymore. I thought I had told ya. Hopefully,
>> this will be the last we hear from this p
53 matches
Mail list logo
