On Thu, Apr 2, 2015 at 11:48 AM, Peter Chen wrote:
>
>> Yes
>>
>> >> reported as self powered, per port power limit is 500 mA, so the
>> >> device may be configured and maybe work normal.
>> >>
>> >
>> > I see your hub report its max power is 100 mA, so if it can report as
>> > self powered, then
> Yes
>
> >> reported as self powered, per port power limit is 500 mA, so the
> >> device may be configured and maybe work normal.
> >>
> >
> > I see your hub report its max power is 100 mA, so if it can report as
> > self powered, then the hub's behavior is correct, and will not be
> > rejected
On Thu, Apr 2, 2015 at 9:10 AM, Peter Chen wrote:
> On Wed, Apr 01, 2015 at 10:57:54AM +0800, Rong Wang wrote:
>> Hi Alan,
>>
>> Thanks for the confirmative answer, since I suspect it's the bug
>> of the hub first, but all the three hubs at my hand report the same
>> status.
>>
>> I can see why th
On 3/24/2015 2:00 AM, Mian Yousaf Kaukab wrote:
> Hi,
> This patchset consists of some bug fixes and feature enhancements for
> the dwc2 driver. All the patches are verified on dwc2 v3.0a with
> dedicated fifos. Main focus of testing was with dma enabled. Although
> basic testing without dma was al
On Wed, Apr 01, 2015 at 10:57:54AM +0800, Rong Wang wrote:
> Hi Alan,
>
> Thanks for the confirmative answer, since I suspect it's the bug
> of the hub first, but all the three hubs at my hand report the same
> status.
>
> I can see why the hubs are reported as self powered, e.g. if there's
> a d
On Wed, Apr 01, 2015 at 06:29:05PM +0100, Baxter, Jim wrote:
> >
> > FunctionFS is very specific, because read/write operations are directly
> > translated into USB requests, which are asynchronous, so you cannot use
> > O_NONBLOCK.
> >
> > If you need non-blocking API you can use Asynchronous I/
On Wed, Apr 01, 2015 at 10:35:16AM -0400, Alan Stern wrote:
> On Wed, 1 Apr 2015, Peter Chen wrote:
>
> > > This is bad. All the endpoints have maxpacket = 1023, and that's much
> > > too big for this test. We need a maxpacket size of 64 (maybe a little
> > > bigger but not much).
> > >
> >
Hi Roger,
On 04/01/2015 08:58 PM, Roger Quadros wrote:
> Hi Chanwoo,
>
> On 01/04/15 10:23, Robert Baldyga wrote:
>> IRQ handler touches info->edev, so if interrupt occurs before extcon
>> device initialization it can cause NULL pointer dereference. Doing extcon
>> initialization before IRQ handl
* Andrew Morton [150401 14:36]:
> On Wed, 18 Mar 2015 15:48:02 -0700 Tony Lindgren wrote:
>
> > Looks like dm81xx can only do 32-bit fifo reads like am35x. Let's set
> > up musb-dsps with a custom read_fifo function based on the compatible
> > flag.
> >
> > Otherwise we can get the following er
On Wed, 18 Mar 2015 15:48:02 -0700 Tony Lindgren wrote:
> Looks like dm81xx can only do 32-bit fifo reads like am35x. Let's set
> up musb-dsps with a custom read_fifo function based on the compatible
> flag.
>
> Otherwise we can get the following errors when starting dhclient on a
> asix USB Eth
Getting phys by index instead of phy names so that we do
not have to create a naming scheme when multiple phys are present
Signed-off-by: Arun Ramamurthy
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/usb/host/ohci-platform.c | 70 ++--
1 file c
Getting phys by index instead of phy names so that we do
not have to create a naming scheme when multiple phys
are present
Signed-off-by: Arun Ramamurthy
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/usb/host/ehci-platform.c | 70 ++--
1 file c
Some generic drivers, such as ehci, may use multiple phys and for such
drivers referencing phy(s) by name(s) does not make sense. Instead of
inventing new naming schemes and using custom code to iterate through them,
such drivers are better of using nameless phy bindings and using this newly
introd
This patch set adds a new API to get phy by index when multiple
phys are present. This patch is based on discussion with Arnd Bergmann
about dt bindings for multiple phys.
History:
v1:
- Removed null pointers on Dmitry's suggestion
- Improved documentation in commit messages
- Exporte
>
> FunctionFS is very specific, because read/write operations are directly
> translated into USB requests, which are asynchronous, so you cannot use
> O_NONBLOCK.
>
> If you need non-blocking API you can use Asynchronous I/O (AIO). You can
> find some examples in kernel sources (tools/usb/ffs-ai
Am Wed, 1 Apr 2015 09:59:04 -0400 (EDT)
schrieb Alan Stern :
> On Wed, 1 Apr 2015, Marc Joliet wrote:
>
> > > If it supports a USB keyboard, it might still go through and initialize
> > > all the USB devices.
> >
> > Hah! I should have thought of that. Well, I tried the following: unplug
>
On Wed, Apr 01 2015, Robert Baldyga wrote:
> FunctionFS can't support O_NONBLOCK because read/write operatons are
> directly translated into USB requests which are asynchoronous, so we
> can't know how long we will have to wait for request completion. For
> this reason in case of open with O_NONBL
On Wed, 1 Apr 2015, Oliver Neukum wrote:
> On Wed, 2015-04-01 at 10:01 -0400, Alan Stern wrote:
> > On Wed, 1 Apr 2015, Oliver Neukum wrote:
> >
> > > On Tue, 2015-03-31 at 13:09 -0400, Alan Stern wrote:
> > > > In other words, if the device is currently in runtime suspend with
> > > > remote wa
On Wed, 1 Apr 2015, Peter Chen wrote:
> > This is bad. All the endpoints have maxpacket = 1023, and that's much
> > too big for this test. We need a maxpacket size of 64 (maybe a little
> > bigger but not much).
> >
>
> Back to this issue, 1024 bytes is only ~70% for frame, why it reports
>
On Wed, 2015-04-01 at 10:01 -0400, Alan Stern wrote:
> On Wed, 1 Apr 2015, Oliver Neukum wrote:
>
> > On Tue, 2015-03-31 at 13:09 -0400, Alan Stern wrote:
> > > In other words, if the device is currently in runtime suspend with
> > > remote wakeup enabled, but device_may_wakeup() returns 0 (so th
On Wed, 1 Apr 2015, Oliver Neukum wrote:
> On Tue, 2015-03-31 at 13:09 -0400, Alan Stern wrote:
> > In other words, if the device is currently in runtime suspend with
> > remote wakeup enabled, but device_may_wakeup() returns 0 (so that the
> > device should be disabled for wakeup when the syste
On Wed, 1 Apr 2015, Marc Joliet wrote:
> > If it supports a USB keyboard, it might still go through and initialize
> > all the USB devices.
>
> Hah! I should have thought of that. Well, I tried the following: unplug the
> drive before booting, plug it in once GRUB loads, and then boot the ker
On Wed, 1 Apr 2015, Rong Wang wrote:
> Hi Alan,
>
> Thanks for the confirmative answer, since I suspect it's the bug
> of the hub first, but all the three hubs at my hand report the same
> status.
I have had some hubs that made the same mistake.
> I can see why the hubs are reported as self pow
On Tue, 2015-03-31 at 13:09 -0400, Alan Stern wrote:
> In other words, if the device is currently in runtime suspend with
> remote wakeup enabled, but device_may_wakeup() returns 0 (so that the
> device should be disabled for wakeup when the system goes into
> suspend), then the prepare callback
Hi Chanwoo,
On 01/04/15 10:23, Robert Baldyga wrote:
> IRQ handler touches info->edev, so if interrupt occurs before extcon
> device initialization it can cause NULL pointer dereference. Doing extcon
> initialization before IRQ handler registration fixes this problem.
>
> Signed-off-by: Robert Ba
Hi Roger,
On 04/01/2015 01:28 PM, Roger Quadros wrote:
> Robert,
>
> On 01/04/15 10:23, Robert Baldyga wrote:
>> This patch adds VBUS pin detection support to extcon-usb-gpio driver.
>> It allows to use this driver with boards which have both VBUS and ID
>> pins, or only one of them.
>>
>> Follow
On Fri, Mar 27, 2015 at 03:46:01PM +0100, Johan Hovold wrote:
> Hi Greg,
>
> Here are a few new device ids including a minor probe-logic clean up for
> 4.0-rc6.
>
> Thanks,
> Johan
>
>
> The following changes since commit 06e5801b8cb3fc057d88cb4dc03c0b64b2744cda:
>
> Linux 4.0-rc4 (2015-03-1
On 01/04/15 10:23, Robert Baldyga wrote:
> Add information about VBUS pin detection support, 'debounce' property
> and some other details.
>
> Signed-off-by: Robert Baldyga
Acked-by: Roger Quadros
cheers,
-roger
> ---
> .../devicetree/bindings/extcon/extcon-usb-gpio.txt | 28
> +
On 01/04/15 10:23, Robert Baldyga wrote:
> This patch adds devicetree property for setting debounce value. It allows
> to set debounce time shorter or longer depending on the needs of given
> platform.
>
> Signed-off-by: Robert Baldyga
Acked-by: Roger Quadros
cheers,
-roger
> ---
> drivers/e
Robert,
On 01/04/15 10:23, Robert Baldyga wrote:
> This patch adds VBUS pin detection support to extcon-usb-gpio driver.
> It allows to use this driver with boards which have both VBUS and ID
> pins, or only one of them.
>
> Following table of states presents relationship between this signals
> a
FunctionFS can't support O_NONBLOCK because read/write operatons are
directly translated into USB requests which are asynchoronous, so we
can't know how long we will have to wait for request completion. For
this reason in case of open with O_NONBLOCK flag we return -EWOULDBLOCK.
Signed-off-by: Rob
Am Tue, 31 Mar 2015 09:54:07 -0400 (EDT)
schrieb Alan Stern :
> On Tue, 31 Mar 2015, Marc Joliet wrote:
>
> > > Like Matt suggested, the most reasonable possibility is an interaction
> > > with the BIOS.
> >
> > Like I said in my replay to Matt, the BIOS doesn't support booting via USB.
> > T
Hi,
On 03/31/2015 08:53 PM, Baxter, Jim wrote:
> Hi,
>
> I have been looking at an issue where a phone that is the Function FS
> host sometimes locks up and causes the function:
> static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data
> *io_data) in drivers/usb/gadget/function/f_fs.c
Add information about VBUS pin detection support, 'debounce' property
and some other details.
Signed-off-by: Robert Baldyga
---
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 28 --
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/
This patch adds VBUS pin detection support to extcon-usb-gpio driver.
It allows to use this driver with boards which have both VBUS and ID
pins, or only one of them.
Following table of states presents relationship between this signals
and detected cable type:
State |ID | VBU
Hello,
This patch set modifies extcon-usb-gpio driver fixing bugs, and adds
new features - VBUS pin detection support and 'debounce' property in
devicetree node. It also updates documentation with information about
new features.
More detailed description of changes can be found in commit messages
IRQ handler touches info->edev, so if interrupt occurs before extcon
device initialization it can cause NULL pointer dereference. Doing extcon
initialization before IRQ handler registration fixes this problem.
Signed-off-by: Robert Baldyga
Acked-by: Roger Quadros
---
drivers/extcon/extcon-usb-g
This patch adds devicetree property for setting debounce value. It allows
to set debounce time shorter or longer depending on the needs of given
platform.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-usb-gpio.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff
On Mon, Mar 30, 2015 at 10:03:07AM -0400, Alan Stern wrote:
> On Mon, 30 Mar 2015, Peter Chen wrote:
>
> > > That's strange. Can you please post the /sys/kernel/debug/usb/devices
> > > file (with the UAC2 gadget plugged in), and also collect a usbmon trace
> > > of the test?
> > >
> >
> > It
39 matches
Mail list logo
