On 18.09.2015 23:25, Oliver Neukum wrote:
On Fri, 2015-09-18 at 09:56 -0700, Laura Abbott wrote:
Would you rather see a revert of the patch you gave rather than a new
one re-introducing the flag?
We need a big fat comment here saying that different tests should
different results and the quirk
Hi,
On 23-09-15 22:59, Bin Liu wrote:
Hi,
On 09/23/2015 02:53 PM, Hans de Goede wrote:
Hi,
On 23-09-15 19:10, Bin Liu wrote:
Hi,
On 09/22/2015 04:18 PM, Felipe Balbi wrote:
On Tue, Sep 22, 2015 at 02:31:18PM -0500, Bin Liu wrote:
Hi,
On 09/22/2015 09:40 AM, Felipe Balbi wrote:
On Mon, S
On Wed, Sep 23, 2015 at 06:24:33PM +0530, Subbaraya Sundeep Bhatta wrote:
> Based on board design USB controller needs explicit software
> access to ULPI PHY for controlling VBUS. This patch adds platform
> driver support for generic ULPI PHYs and provides a USB2 PHY device
> to controllers.
>
> S
On Wed, Sep 23, 2015 at 06:24:01PM +0530, Subbaraya Sundeep Bhatta wrote:
> This patch adds binding doc info for generic ULPI PHYs
> platform driver.
>
> Signed-off-by: Subbaraya Sundeep Bhatta
> ---
> .../devicetree/bindings/usb/ulpi-platform-phy.txt | 34
>
> 1 files c
Hi Peter,
> -Original Message-
> From: Peter Chen [mailto:peter.c...@freescale.com]
> Sent: Thursday, September 24, 2015 2:37 PM
> To: Subbaraya Sundeep Bhatta
> Cc: ba...@ti.com; devicet...@vger.kernel.org; kis...@ti.com;
> gre...@linuxfoundation.org; linux-usb@vger.kernel.org; linux-
> k
Hi Peter,
> -Original Message-
> From: Peter Chen [mailto:peter.c...@freescale.com]
> Sent: Thursday, September 24, 2015 2:41 PM
> To: Subbaraya Sundeep Bhatta
> Cc: ba...@ti.com; devicet...@vger.kernel.org; kis...@ti.com;
> gre...@linuxfoundation.org; linux-usb@vger.kernel.org; linux-
> k
On Thu, Sep 24, 2015 at 09:21:16AM +, Subbaraya Sundeep Bhatta wrote:
> > > +uphy->flags);
> > > +
> > > + uphy->usb_phy->set_vbus = usbphy_set_vbus;
> >
> > When you will call it?
>
> I am calling it in host.c and otg_fsm.c of Chipidea driver wherever
> regulator_enable/disable is called to
Hi Felipe,
Any comments on the below [v4] patches?
[PATCH 1/3][v4] Documentation: dt: dwc3: Add snps,quirk-frame-length-adjustment
property
[PATCH 2/3][v4] drivers: usb: dwc3: Add frame length adjustment quirk
[PATCH 3/3][v4] arm: dts: ls1021a: Add quirk for Erratum A009116
I will be taking fo
On Wed, Sep 23, 2015 at 07:15:16PM +0200, Hans-Christian Egtvedt wrote:
> Around Wed 23 Sep 2015 21:26:01 +0530 or thereabout, Sudip Mukherjee wrote:
> > On Mon, Sep 21, 2015 at 01:31:44PM +0530, Sudip Mukherjee wrote:
> >> On Mon, Sep 21, 2015 at 09:33:00AM +0200, Hans-Christian Egtvedt wrote:
> >
On 09/23/2015 10:08 PM, Steinar H. Gunderson wrote:
Hi again,
I'm trying to figure out why my xHCI controller refuses me to run two very
similar video cards at the same time. I'm not sure if this is a bug or if I'm
just misunderstanding, so let me see if I understand this right:
The interface
On 22/05/15 14:50, Felipe Balbi wrote:
> Hi,
>
> On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote:
>> I am trying to get the full-speed USB host working on an custom
>> AM3517 device with the 3.18.12 kernel. The hardware works (a
>> 2.6.37 kernel has been used for testing).
>>
>> Does
On Thu, Sep 24, 2015 at 02:09:41PM +0200, Krzysztof Opasiak wrote:
> Let's start from the beginning. Your device use ISO endpoints which means
> that host allocates specific amount of bandwidth on the bus. More over,
> interfaces in your devices has many alternate settings. Probably each of
> them
On 09/24/2015 02:50 PM, Steinar H. Gunderson wrote:
On Thu, Sep 24, 2015 at 02:09:41PM +0200, Krzysztof Opasiak wrote:
Let's start from the beginning. Your device use ISO endpoints which means
that host allocates specific amount of bandwidth on the bus. More over,
interfaces in your devices ha
On Thu, Sep 24, 2015 at 03:09:55PM +0200, Krzysztof Opasiak wrote:
> But still the problem may exist. Is the 2.16 GBit bandwidth for 4th altset?
No. The 2nd altset is 2.16, the 4th altset is 1.04. Unless my calculations
are wrong.
> Remember that according to USB spec not whole bandwidth can be u
Hi Felipe,
On 09/24/2015 03:37 AM, Hans de Goede wrote:
Hi,
On 23-09-15 22:59, Bin Liu wrote:
Hi,
On 09/23/2015 02:53 PM, Hans de Goede wrote:
Hi,
On 23-09-15 19:10, Bin Liu wrote:
Hi,
On 09/22/2015 04:18 PM, Felipe Balbi wrote:
On Tue, Sep 22, 2015 at 02:31:18PM -0500, Bin Liu wrote:
H
On 09/24/2015 03:14 PM, Steinar H. Gunderson wrote:
On Thu, Sep 24, 2015 at 03:09:55PM +0200, Krzysztof Opasiak wrote:
But still the problem may exist. Is the 2.16 GBit bandwidth for 4th altset?
No. The 2nd altset is 2.16, the 4th altset is 1.04. Unless my calculations
are wrong.
How do yo
On Thu, Sep 24, 2015 at 03:35:10PM +0200, Krzysztof Opasiak wrote:
>> No. The 2nd altset is 2.16, the 4th altset is 1.04. Unless my calculations
>> are wrong.
> How do you do your calculations?
Like I said in my initial email:
>>> The interface of each card has two relevant alternates, 2 and 4. N
On Wed, 23 Sep 2015, Steinar H. Gunderson wrote:
> Hi again,
>
> I'm trying to figure out why my xHCI controller refuses me to run two very
> similar video cards at the same time. I'm not sure if this is a bug or if I'm
> just misunderstanding, so let me see if I understand this right:
>
> The i
On Thu, Sep 24, 2015 at 10:17:19AM -0400, Alan Stern wrote:
> However, none of this answers the question of why you can use both
> cards on a different machine but not on yours. It comes down to the
> implementations of the xHCI controller chips. In USB-3, bandwidth
> allocation is handled by fir
On 09/24/2015 03:50 PM, Steinar H. Gunderson wrote:
On Thu, Sep 24, 2015 at 03:35:10PM +0200, Krzysztof Opasiak wrote:
No. The 2nd altset is 2.16, the 4th altset is 1.04. Unless my calculations
are wrong.
How do you do your calculations?
Like I said in my initial email:
The interface of e
Move function parameters to struct f_loopback to make them per instance
instead of having them as global variables. Since we can have multiple
instances of USB function we also want to have separate set of parameters
for each instance.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/functio
Move function parameters to struct f_sourcesink to make them per instance
instead of having them as global variables. Since we can have multiple
instances of USB function we also want to have separate set of parameters
for each instance.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/funct
Hi Felipe,
There are two bugfix patches. The problem was that function parameters
in f_sourcesink and f_loopback were stored in global variables, and in
result setting parameters in one function instance caused overwriting
them in all other instances. This patchset fixes this problem by replacing
Hi Felipe,
I see that Krzysztof Opasiak made the same change in patch
https://lkml.org/lkml/2015/9/22/578, so please just ignore my patch.
My first patch is still needed - I will resend it with CC: stable.
Thanks,
Robert Baldyga
On 09/24/2015 05:02 PM, Robert Baldyga wrote:
> Move function para
On 09/22/2015 08:40 PM, Krzysztof Opasiak wrote:
> Each instance of loopback function may have different qlen
> and buflen attributes values. When linking function to
> configuration those values had been assigned to global
> variables. Linking other instance to config overwrites those
> values.
>
On Thu, 24 Sep 2015, Steinar H. Gunderson wrote:
> On Thu, Sep 24, 2015 at 10:17:19AM -0400, Alan Stern wrote:
> > However, none of this answers the question of why you can use both
> > cards on a different machine but not on yours. It comes down to the
> > implementations of the xHCI controller
Move function parameters to struct f_sourcesink to make them per instance
instead of having them as global variables. Since we can have multiple
instances of USB function we also want to have separate set of parameters
for each instance.
Cc: # 3.10+
Signed-off-by: Robert Baldyga
---
drivers/usb
> >
> > Also, I'm finding that the patch series introduces a pretty large
> > bisection hole:
> >
> > include/linux/page-flags.h: In function 'PageYoung':
> > include/linux/page-flags.h:327: error: implicit declaration of function
> > 'PF_ANY'
> > include/linux/page-flags.h:327: error: invalid t
On Wed, Sep 23, 2015 at 7:54 AM, Subbaraya Sundeep Bhatta
wrote:
> This patch adds binding doc info for generic ULPI PHYs
> platform driver.
>
> Signed-off-by: Subbaraya Sundeep Bhatta
> ---
> .../devicetree/bindings/usb/ulpi-platform-phy.txt | 34
>
> 1 files changed, 3
On Thu, Sep 24, 2015 at 4:26 AM, Subbaraya Sundeep Bhatta
wrote:
> Hi Peter,
>
>> -Original Message-
>> From: Peter Chen [mailto:peter.c...@freescale.com]
>> Sent: Thursday, September 24, 2015 2:41 PM
>> To: Subbaraya Sundeep Bhatta
>> Cc: ba...@ti.com; devicet...@vger.kernel.org; kis...@t
On Thu, Sep 24, 2015 at 05:23:09PM +0200, Robert Baldyga wrote:
> Move function parameters to struct f_sourcesink to make them per instance
> instead of having them as global variables. Since we can have multiple
> instances of USB function we also want to have separate set of parameters
> for each
On Thu, Sep 24, 2015 at 05:19:12PM +0200, Robert Baldyga wrote:
> On 09/22/2015 08:40 PM, Krzysztof Opasiak wrote:
> > Each instance of loopback function may have different qlen
> > and buflen attributes values. When linking function to
> > configuration those values had been assigned to global
> >
On 09/24/2015 06:51 PM, Felipe Balbi wrote:
On Thu, Sep 24, 2015 at 05:19:12PM +0200, Robert Baldyga wrote:
On 09/22/2015 08:40 PM, Krzysztof Opasiak wrote:
Each instance of loopback function may have different qlen
and buflen attributes values. When linking function to
configuration those va
Hello Andrew,
> ES1-111M running BIOS v1.13 and have had no problems booting from an
> external USB stick to install Debian (using legacy mode -- I haven't
> tried UEFI). It also worked fine under v1.10 (factory-installed).
Thanks, that's good to know. Btw, I'm also using legacy mode.
Maybe I
> -Original Message-
> From: John Youn [mailto:john.y...@synopsys.com]
> Sent: September-23-15 9:21 PM
> To: Scott Branden; John Youn; Greg Kroah-Hartman; linux-
> u...@vger.kernel.org; Roman Bacik
> Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list
> Subject: Re: [PATCH v3 0/1] US
On 09/24/2015 06:49 PM, Felipe Balbi wrote:
On Thu, Sep 24, 2015 at 05:23:09PM +0200, Robert Baldyga wrote:
Move function parameters to struct f_sourcesink to make them per instance
instead of having them as global variables. Since we can have multiple
instances of USB function we also want to
Hi Alan,
> > Frankly, I don't dare to upgrade the BIOS right now.
>
> All right. Maybe at some point in the future. The thing is, I don't
> want to patch the kernel only to find that the problem has already been
> fixed in a newer BIOS.
Fair enough. I'll see if I can make time for setting th
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
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-
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
The usb charger framework is based on usb gadget. The usb charger
need to be notified the state changing of usb gadget to confirm the
usb charger state.
Thus this patch adds a notifier mechanism for usb gadget to report a
event to usb charger when the usb gadget state is changed.
Signed-off-by: B
For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.
Introduce a callback 'get_charger_type' which will implemented by
user for usb gadget operations to get the usb charger type.
Signed-off-by: Baolin Wang
---
d
When the usb gadget supporting for usb charger is ready, the usb charger
should get the type by the 'get_charger_type' callback which is implemented
by the usb gadget operations, and get the usb charger pointer from struct
'usb_gadget'.
Signed-off-by: Baolin Wang
---
drivers/usb/gadget/charger.c
On Thu, Sep 24, 2015 at 11:22:57AM -0400, Alan Stern wrote:
>> I assume there's no way I can lie to the chip? Like, if I know for a fact
>> that the card will send less data than the alternate claims (like,
>> I'm using a video mode that will require only a few hundred megabits/second
>> in practic
On Thu, 24 Sep 2015, Steinar H. Gunderson wrote:
> On Thu, Sep 24, 2015 at 11:22:57AM -0400, Alan Stern wrote:
> >> I assume there's no way I can lie to the chip? Like, if I know for a fact
> >> that the card will send less data than the alternate claims (like,
> >> I'm using a video mode that wil
On Thu, 24 Sep 2015, Jiri Kosina wrote:
> On Wed, 23 Sep 2015, Alan Stern wrote:
>
> > Your mistake was thinking that the driver for your keyboard is usbkbd.
> > It isn't. It's usbhid, as you can see in the "lsusb -t" output above.
>
> As Eric is absolutely not the first person ever who got c
On Thu, Sep 24, 2015 at 04:46:22PM -0400, Alan Stern wrote:
> It does. Grep for max_burst in drivers/usb/host/x*.c to see where it
> gets used. (Note that in a couple of places involving USB-2 devices,
> the code uses max_burst where it really means multiplicity.)
OK, so this is very curious.
IIRC, at least some of the Intel controllers require the bandwidth
calculations to be done by the xHCI driver, instead of doing it
themselves in hardware. Perhaps you're tripping over a bug in the xHCI
driver? Mathias is probably best the one to comment on this.
--
Paul
--
To unsubscribe from thi
On Thu, Sep 24, 2015 at 02:33:06PM -0700, Paul Zimmerman wrote:
> IIRC, at least some of the Intel controllers require the bandwidth
> calculations to be done by the xHCI driver, instead of doing it
> themselves in hardware. Perhaps you're tripping over a bug in the xHCI
> driver? Mathias is probab
Yep, that's the one.
--
Paul
On Thu, Sep 24, 2015 at 2:37 PM, Steinar H. Gunderson
wrote:
> On Thu, Sep 24, 2015 at 02:33:06PM -0700, Paul Zimmerman wrote:
>> IIRC, at least some of the Intel controllers require the bandwidth
>> calculations to be done by the xHCI driver, instead of doing it
>>
On Wed, Sep 23, 2015 at 10:08:05PM +0200, Steinar H. Gunderson wrote:
> I've tried on another machine and it works fine there, so my code should,
> at least on the surface of it, be fine.
PLOT TWIST:
I downgraded to Debian's 3.16 kernel. Both cards came up without a hitch.
But I only seem to get
On Fri, Sep 25, 2015 at 12:42:22AM +0200, Steinar H. Gunderson wrote:
> I downgraded to Debian's 3.16 kernel. Both cards came up without a hitch.
> But I only seem to get frames back from the second one.
...and after a quick app fix, I have capture from both cards.
Does this mean I have a long bi
Hi Peter,
On Tue, Sep 8, 2015 at 11:27 PM, Peter Chen wrote:
> I will queue both for next rc, thanks.
It would be nice if these patches could appear in linux-next soon.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
On 9/22/2015 6:15 AM, Mian Yousaf Kaukab wrote:
> Hi,
> This series consists of various bug fixes for both host and gadget
> sides. All patches are verified on dwc2 v3.0a with dedicated fifos.
> It would be good to get some Tested-bys for other platforms.
>
> It is based on testing/next branch in
On 9/24/2015 10:28 AM, Roman Bacik wrote:
>> -Original Message-
>> From: John Youn [mailto:john.y...@synopsys.com]
>> Sent: September-23-15 9:21 PM
>> To: Scott Branden; John Youn; Greg Kroah-Hartman; linux-
>> u...@vger.kernel.org; Roman Bacik
>> Cc: linux-ker...@vger.kernel.org; bcm-kerne
Hi Greg,
should I correct this?
Thanks
Stefan Koch
Am Mittwoch, den 23.09.2015, 03:40 +0800 schrieb kbuild test robot:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
> usb-testing
> head: ff8e2c560eca32043ed097099debac488a4bd99f
> commit: 4ad2ddce1a096dea71d42969515
On Fri, Sep 25, 2015 at 08:31:48AM +0200, Stefan Koch wrote:
> Hi Greg,
>
> should I correct this?
Yes, you can add a kerneldoc line for the new field you added, it
shouldn't be that hard.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a
57 matches
Mail list logo
