On Mon, Aug 01, 2016 at 08:40:02PM +0200, Ladislav Michl wrote:
> Hi,
>
> I need to ask usbtmc device for vendor specific data. What about adding ioctl
> which switches MsgIDs to be vendor specific? Or are there other, better,
> options? Patch bellow ilustrates changes to allow reading and writing
The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it.
Signed-off-by: Peter Chen
---
arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 +-
1 file
Add optional properties for power sequence.
Signed-off-by: Peter Chen
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/usb/usb-device.txt | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt
b/Documentatio
From: Peter Chen
At device tree, we have no device node for chipidea core,
the glue layer's node is the parent node for host and udc
device. But in related driver, the parent device is chipidea
core. So, in order to let the common driver get parent's node,
we let the core's device node equals glu
On Fri, Jul 29, 2016 at 01:06:48PM -0700, Matthias Kaehlcke wrote:
> >...
> >
> >+static int pwrseq_generic_get(struct device_node *np, struct pwrseq *pwrseq)
> >+{
> >+struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> >+enum of_gpio_flags flags;
> >+int reset_gpio, ret =
Add binding doc for generic power sequence library.
Signed-off-by: Peter Chen
Acked-by: Philipp Zabel
Acked-by: Rob Herring
---
.../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/binding
Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some hard-wired USB devices
works abnormal or can't be recogniz
We have an well-known problem that the device needs to do some power
sequence before it can be recognized by related host, the typical
example like hard-wired mmc devices and usb devices.
This power sequence is hard to be described at device tree and handled by
related host driver, so we have crea
Hi all,
This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocat
This patchs split out the extcon APIs of extcon provider driver in order to
prevent the direct access of struct extcon_dev by extcon consumer driver.
The extcon consumer driver don't need to handle the extcon provider APIs.
The extcon subsystem has two type of extcon drivers as following:
- extcon
On 31-07-16, 23:31, Matwey V. Kornilov wrote:
> Hello,
>
> I've also just found that the same commit breaks cpufreq on BeagleBone Black
> :)
>
> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
> (as i
On Mon, Aug 01, 2016 at 07:55:10AM -0700, Joshua Clayton wrote:
>
>
> On 07/28/2016 09:41 AM, Fabio Estevam wrote:
> > Hi Joshua,
> >
> > On Thu, Jul 28, 2016 at 12:56 PM, Joshua Clayton
> > wrote:
> >
> >> I assume there is a v4 coming due to rmk's comments on patch 5.
> >> I couldn't figure ou
Erroneous or malicious endpoint descriptors may have non-zero bits in
reserved positions, or out-of-bounds values. This patch helps prevent
these from causing problems by bounds-checking the wMaxPacketValue
entries in endpoint descriptors and capping the values at the maximum
allowed.
This issue
On Mon Aug 01 2016 14:28:46 GMT-0400 (EDT), Greg KH wrote:
> On Mon, Aug 01, 2016 at 02:04:06PM -0400, Alan Stern wrote:
>> On Mon, 1 Aug 2016, roswest wrote:
>>
>>> Alan,
>>>
>>> I think it would be more accurate to put Jake Lamberson as the reporter
>>> and tester.
>>
>> I could mention him in
On Mon, Aug 01, 2016 at 02:04:06PM -0400, Alan Stern wrote:
> On Mon, 1 Aug 2016, roswest wrote:
>
> > Alan,
> >
> > I think it would be more accurate to put Jake Lamberson as the reporter
> > and tester.
>
> I could mention him in the body of the patch description. But it
> doesn't seem approp
On Mon, Aug 01, 2016 at 12:18:54PM -0400, Alan Stern wrote:
> Erroneous or malicious endpoint descriptors may have non-zero bits in
> reserved positions, or out-of-bounds values. This patch helps prevent
> these from causing problems by bounds-checking the wMaxPacketValue
> entries in endpoint des
On Mon, 1 Aug 2016, Tejun Heo wrote:
> Hello,
>
> On Mon, Aug 01, 2016 at 03:50:36PM +0200, Michal Hocko wrote:
> > > All that would do is deferring the deadlock, right? I'm not sure it
> > > makes a lot of sense to protect an IO path against memory pressure
> > > half-way. It either can be dep
Hi,
I need to ask usbtmc device for vendor specific data. What about adding ioctl
which switches MsgIDs to be vendor specific? Or are there other, better,
options? Patch bellow ilustrates changes to allow reading and writing vendor
specific messages.
Thank you,
ladis
diff --git a/drivers
On Mon, 1 Aug 2016, roswest wrote:
> Alan,
>
> I think it would be more accurate to put Jake Lamberson as the reporter
> and tester.
I could mention him in the body of the patch description. But it
doesn't seem appropriate to list him as the reporter or tester because
he didn't report anything
On Mon 01-08-16 14:00:57, Alan Stern wrote:
> On Mon, 1 Aug 2016, Tejun Heo wrote:
>
> > Hello,
> >
> > On Mon, Aug 01, 2016 at 03:50:36PM +0200, Michal Hocko wrote:
> > > > All that would do is deferring the deadlock, right? I'm not sure it
> > > > makes a lot of sense to protect an IO path aga
2016-08-01 20:06 GMT+03:00 Viresh Kumar :
> On 01-08-16, 20:01, Matwey V. Kornilov wrote:
>> With this patch, there is no cpufreq directory here.
>>
>> Without this patch, the output is the following:
>>
>> nohostname:~ # uname -a
>> Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul
Once ulpi operations use the parent device directly, this will be
needed during the operations used in ulpi_register() itself, so set
the parent field before calling any ulpi operations.
Signed-off-by: Tal Shorer
---
drivers/usb/common/ulpi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(
The old api callbacks, read() and write(), are not referenced anywhere.
Remove them.
Signed-off-by: Tal Shorer
---
include/linux/ulpi/interface.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/ulpi/interface.h b/include/linux/ulpi/interface.h
index d8189d0..71f3c99 100644
---
The old read, write callbacks in struct ulpi_ops have been deprecated
in favor of new callbacks that pass the parent device directly.
Replace the used callbacks in dwc3's ulpi component with the new api.
Signed-off-by: Tal Shorer
---
drivers/usb/dwc3/ulpi.c | 12 ++--
1 file changed, 6 i
If the registered has the new api callbacks {read|write}_dev, call
these instead of the deprecated read, write functions. If the
registered does not support the new callbacks, revert to calling the
old ones as before.
Signed-off-by: Tal Shorer
---
drivers/usb/common/ulpi.c | 8 ++--
1 file c
Add these two new api callbacks to struct ulpi_ops. These are different
than read, write in that they pass the parent device directly instead
of via the ops argument.
They are intended to replace the old api functions.
Signed-off-by: Tal Shorer
---
include/linux/ulpi/interface.h | 2 ++
1 file c
None of the core ulpi functions perform any changes to the operations
struct, and logically as a struct that contains function pointers
there's no reason it shouldn't be constant.
Signed-off-by: Tal Shorer
---
drivers/usb/common/ulpi.c | 3 ++-
include/linux/ulpi/driver.h| 2 +-
include
With the removal of the old {read|write} operations, we can now safely
rename the new api operations {read|write}_dev to use the shorter and
clearer names {read|write}, respectively.
Signed-off-by: Tal Shorer
---
drivers/usb/common/ulpi.c | 4 ++--
drivers/usb/dwc3/ulpi.c| 4 ++--
i
Now that all users use the new api callbacks, remove the calls to the
old api functions and force new interface drivers to use the new api.
Signed-off-by: Tal Shorer
---
drivers/usb/common/ulpi.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/commo
Operations now use ulpi->dev.parent directly instead of via the
ulpi_ops struct, making this field unused. Remove it.
Signed-off-by: Tal Shorer
---
drivers/usb/common/ulpi.c | 1 -
include/linux/ulpi/interface.h | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/u
ulpi_register_interface() accepts a const struct ulpi_ops and dwc3
doesn't perform any changes to this struct at runtime, so there's no
reason it shouldn't be constant.
Signed-off-by: Tal Shorer
---
drivers/usb/dwc3/ulpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
struct ulpi_ops is defined as follows:
struct ulpi_ops {
struct device *dev;
int (*read)(struct ulpi_ops *ops, u8 addr);
int (*write)(struct ulpi_ops *ops, u8 addr, u8 val);
};
Upon calling ulpi_register_interface(), the struct device argument is
put inside the struct ulpi
pwc module output with trace=511 is the following:
[ 24.793109] usbcore: registered new interface driver Philips webcam
[ 29.276979] pwc: Unsupported pixel format
[ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
bytesperline=640, sizeimage=460800, pixelformat=YU12
[ 29.277090
On 01-08-16, 20:01, Matwey V. Kornilov wrote:
> With this patch, there is no cpufreq directory here.
>
> Without this patch, the output is the following:
>
> nohostname:~ # uname -a
> Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul 15
> 08:08:50 UTC 2016 (ecd9058) armv7l armv7l a
Alan,
I think it would be more accurate to put Jake Lamberson as the reporter
and tester.
Thanks,
Rosie
On Mon Aug 01 2016 12:18:54 GMT-0400 (EDT), Alan Stern wrote:
> Erroneous or malicious endpoint descriptors may have non-zero bits in
> reserved positions, or out-of-bounds values. This patch
2016-08-01 19:50 GMT+03:00 Viresh Kumar :
> On 31-07-16, 23:31, Matwey V. Kornilov wrote:
>> Hello,
>>
>> I've also just found that the same commit breaks cpufreq on BeagleBone Black
>> :)
>>
>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>> frequency, which is unlisted
Hi Mike,
On Mon, Aug 1, 2016 at 12:05 PM, Mike Murdoch wrote:
> On 2016-08-01 13:57, Durval Menezes wrote:
> > Hi Mathias,
> >
> > On Mon, Aug 1, 2016 at 8:20 AM, Mathias Nyman
> > wrote:
> >>> On 01.08.2016 13:15, Durval Menezes wrote:
> >>> Hello Mike, Mathias, list,
> >>>
> >>> On 06.02.2016
On Mon, Aug 1, 2016 at 11:55 AM, Joshua Clayton
wrote:
> Thanks a million, Fabio!
>
> 'usbcore.autosuspend=-1' quiets the errors.
>
> ~joshua
>
> P.S. I guess this technically is a bug in chipidea usb.
> I'll give it a quick once over, though I am not very familiar
> with USB core or the CI drive
On Mon, 1 Aug 2016, Marc Ohlf wrote:
> In ehci_turn_off_all_ports() all EHCI port register bits
> (except the PORT_RWC_BITS) are set to zero.
Even the PORT_WRC_BITS are set to 0. Oddly enough, the way to set
those bits to 0 is to write a 1 to them (see Table 2-16 in the EHCI
spec).
> On some
Kamal Mostafa writes:
> Commit 27a41a83ec54 ("xhci: Cleanup only when releasing primary hcd")
> causes a soft lockup at boot when XHCI_STATE_HALTED, preventing
> VirtualBox 5.1.x from booting if USB3.0 is enabled.
>
> Revert to allowing xhci_irq to handle the interrupt when
> XHCI_STATE_HALTED bu
Erroneous or malicious endpoint descriptors may have non-zero bits in
reserved positions, or out-of-bounds values. This patch helps prevent
these from causing problems by bounds-checking the wMaxPacketValue
entries in endpoint descriptors and capping the values at the maximum
allowed.
Signed-off-
Commit 27a41a83ec54 ("xhci: Cleanup only when releasing primary hcd")
causes a soft lockup at boot when XHCI_STATE_HALTED, preventing
VirtualBox 5.1.x from booting if USB3.0 is enabled.
Revert to allowing xhci_irq to handle the interrupt when
XHCI_STATE_HALTED but not XHCI_STATE_DYING.
Fixes: 27a
Introduce an attribute "inquiry_string" to the lun.
In some environments, e. g. BIOS boot menus, the inquiry string
is the only information about devices presented to the user. The
default string depends on the "cdrom" bit of the first lun as
well as the kernel version and allows no further custom
Hello,
On 2016-08-01 13:57, Durval Menezes wrote:
> Hi Mathias,
>
> On Mon, Aug 1, 2016 at 8:20 AM, Mathias Nyman
> wrote:
>>> On 01.08.2016 13:15, Durval Menezes wrote:
>>> Hello Mike, Mathias, list,
>>>
>>> On 06.02.2016 19:08, Mike Murdoch wrote:
>>> Bug ID: 111251
>>>
>>> I have a NEC uPD720
On 07/28/2016 09:41 AM, Fabio Estevam wrote:
> Hi Joshua,
>
> On Thu, Jul 28, 2016 at 12:56 PM, Joshua Clayton
> wrote:
>
>> I assume there is a v4 coming due to rmk's comments on patch 5.
>> I couldn't figure out where to null the of_node in error paths, but in
>> testing
>> we did put a line
Hello,
On Mon, Aug 01, 2016 at 03:50:36PM +0200, Michal Hocko wrote:
> > All that would do is deferring the deadlock, right? I'm not sure it
> > makes a lot of sense to protect an IO path against memory pressure
> > half-way. It either can be depended during memory reclaim or it
> > can't.
>
>
On Fri 29-07-16 09:11:47, Tejun Heo wrote:
> Hello, Alan.
>
> On Wed, Jul 27, 2016 at 04:45:19PM -0400, Alan Stern wrote:
> > > Hmm... That doesn't really make them dependable during memory reclaim.
> >
> > True. But it does mean that they can't cause a deadlock by waiting
> > indefinitely for s
Hi Mathias,
On Mon, Aug 1, 2016 at 8:20 AM, Mathias Nyman
wrote:
> > On 01.08.2016 13:15, Durval Menezes wrote:
> > Hello Mike, Mathias, list,
> >
> > On 06.02.2016 19:08, Mike Murdoch wrote:
> > Bug ID: 111251
> >
> > I have a NEC uPD720200 USB3.0 controller in a Thinkpad W520 laptop on
> > k
Hi,
Tal Shorer writes:
> struct ulpi_ops is defined as follows:
>
> struct ulpi_ops {
> struct device *dev;
> int (*read)(struct ulpi_ops *ops, u8 addr);
> int (*write)(struct ulpi_ops *ops, u8 addr, u8 val);
> };
>
> Upon calling ulpi_register_interface(), the struct dev
Hi
On 01.08.2016 13:15, Durval Menezes wrote:
Hello Mike, Mathias, list,
On 06.02.2016 19:08, Mike Murdoch wrote:
Bug ID: 111251
I have a NEC uPD720200 USB3.0 controller in a Thinkpad W520 laptop on
kernel 4.4.1-gentoo.
0e:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
Controlle
Hello Mike, Mathias, list,
On 06.02.2016 19:08, Mike Murdoch wrote:
> Bug ID: 111251
>
> I have a NEC uPD720200 USB3.0 controller in a Thinkpad W520 laptop on
> kernel 4.4.1-gentoo.
>
> 0e:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
> Controller (rev 04) (prog-if 30 [XHCI])
>
Hi,
On 01-08-16 10:18, Icenowy Zheng wrote:
01.08.2016, 15:27, "Hans de Goede" :
Hi,
On 01-08-16 09:05, Icenowy Zheng wrote:
clocks = <&ccu CLK_A64_BUS_OHCI1>,
<&ccu CLK_A64_BUS_EHCI1>,
<&ccu CLK_A6
In ehci_turn_off_all_ports() all EHCI port register bits
(except the PORT_RWC_BITS) are set to zero.
On some hardware, this can lead to an system hang,
when ehci_port_power() accesses the already cleaned registers.
This patch changes the order of cleanup.
First call ehci_port_power() which respect
Hi,
Robert Jarzmik writes:
> Felipe Balbi writes:
>
>> Hi Robert,
>>
>> Robert Jarzmik writes:
>>> Felipe Balbi writes:
>>>
Hi,
Robert Jarzmik writes:
> I don't know if there are other users than pxa, I'll make the assumption
> there
> aren't.
yeah, we c
Hi,
On 01-08-16 09:05, Icenowy Zheng wrote:
clocks = <&ccu CLK_A64_BUS_OHCI1>,
<&ccu CLK_A64_BUS_EHCI1>,
<&ccu CLK_A64_USB_OHCI0>,
<&ccu CLK_A64_USB_OHCI1>;
On A64, EHCI re
Currently the Linux kernel does not provide any standard integration of this
feature that integrates the USB subsystem with the system power regulation
provided by PMICs meaning that either vendors must add this in their kernels
or USB gadget devices based on Linux (such as mobile phones) may not b
For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.
It will report to the usb charger when the gadget state is changed,
then the usb charger can do the power things.
Signed-off-by: Baolin Wang
Reviewed-by: Li Ju
When the usb gadget supporting for usb charger is ready, the usb charger
can implement the usb_charger_plug_by_gadget() function, usb_charger_exit()
function and dev_to_uchger() function by getting 'struct usb_charger' from
'struct gadget'.
Signed-off-by: Baolin Wang
Reviewed-by: Li Jun
Tested-b
This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.
The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the
Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.
Signed-off-
On Sunday, July 31, 2016 7:25:36 PM CEST Icenowy Zheng wrote:
> Allwinner A64 EHCI requires 4 clocks to be enabled.
>
> Signed-off-by: Icenowy Zheng
>
Can you say what those four clocks are?
Are you sure that it's not just a case of a clock being
incorrectly described in the clk driver, i.e. y
61 matches
Mail list logo
