Hi,
On 06/06/16 06:04, Lu Baolu wrote:
> Hi Peter,
>
> On 06/06/2016 09:25 AM, Peter Chen wrote:
>> On Sun, Jun 05, 2016 at 02:55:56PM +0800, Lu Baolu wrote:
>>> Hi Peter,
>>>
>>> On 06/04/2016 10:28 AM, Peter Chen wrote:
On Sat, Jun 04, 2016 at 12:06:06AM +0800, Lu Baolu wrote:
>> from
On Mon, Jun 06, 2016 at 11:04:48AM +0800, Lu Baolu wrote:
> Hi Peter,
>
> On 06/06/2016 09:25 AM, Peter Chen wrote:
> > On Sun, Jun 05, 2016 at 02:55:56PM +0800, Lu Baolu wrote:
> >> Hi Peter,
> >>
> >> On 06/04/2016 10:28 AM, Peter Chen wrote:
> >>> On Sat, Jun 04, 2016 at 12:06:06AM +0800, Lu Ba
Hi Peter,
On 06/06/2016 03:02 PM, Peter Chen wrote:
> >> But this code is better co-work with OTG/Dual-role framework, we'd
> >> better have only interface that the user can know which role for the
> >> current port.
> >> OTG/Dual-role framework and portmux framework are not ov
On 06/05/2016 07:54 PM, Sudip Mukherjee wrote:
> On Friday 03 June 2016 09:29 AM, Krzysztof Opasiak wrote:
>>
>>
>> On 06/02/2016 03:22 PM, Sudip Mukherjee wrote:
>>> We have been dereferencing udc before checking it. Lets use it after it
>>> has been checked.
>>>
>>
>> To be honest I have mixed
> Try moving the first executable line:
>
> ed->state = ED_OPER;
>
> to the end of the routine, just before the "return 0;". That should
> fix the problem.
Yep, this does the trick. I removed my NULL-check before list_del and
nothing bad happens anymore.
Apparently this bug also prevent
On Mon, Jun 06, 2016 at 10:20:37AM +0200, Krzysztof Opasiak wrote:
>
>
> On 06/05/2016 07:54 PM, Sudip Mukherjee wrote:
> >
> > Yes, I should have seen earlier that the only caller has already
> > dereferenced udc. So maybe the following will be appropriate in this
> > situation.
> >
>
> Your
The newer SoCs (rk3366, rk3399) of Rock-chip take a different usb-phy
IP block than rk3288 and before, and most of phy-related registers are
also different from the past, so a new phy driver is required necessarily.
These series patches add phy-rockchip-inno-usb2.c and the corresponding
documentat
Signed-off-by: Frank Wang
---
Changes in v3:
- Added 'clocks' and 'clock-names' optional properties.
- Specified 'otg-port' and 'host-port' as the sub-node name.
Changes in v2:
- Changed vbus_host optional property from gpio to regulator.
- Specified vbus_otg-supply optional property.
- Spe
The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
than rk3288 and before, and most of phy-related registers are also
different from the past, so a new phy driver is required necessarily.
Signed-off-by: Frank Wang
---
Changes in v3:
- Resolved the mapping defect between fixed val
This patch adds support for PID 0x1206 of Telit LE910.
The reserved usb interfaces belong to an adb device and an ECM device.
Since the interfaces positions are the same than the ones for
0x1043 PID of Telit LE922, telit_le922_blacklist_usbcfg3 is used.
Following the lsusb output:
Bus 001 Device
This patch adds support for 0x1206 PID of Telit LE910.
Since the interfaces positions are the same than the ones for
0x1043 PID of Telit LE922, telit_le922_blacklist_usbcfg3 is used.
Signed-off-by: Daniele Palmas
---
drivers/usb/serial/option.c | 3 +++
1 file changed, 3 insertions(+)
diff --g
On Mon, Jun 06, 2016 at 05:20:03PM +0800, Frank Wang wrote:
> Signed-off-by: Frank Wang
> ---
>
> Changes in v3:
> - Added 'clocks' and 'clock-names' optional properties.
> - Specified 'otg-port' and 'host-port' as the sub-node name.
>
> Changes in v2:
> - Changed vbus_host optional property
Hi All,
While looking at libusb today I ended up looking at the
reap-after-disconnect code.
What stands out is that libusb expects to be able to
reap all outstanding urbs on a device on receiving
a POLL_ERR status from poll (on supported kernels).
But the usbfs poll implementation will return P
Am Montag, 6. Juni 2016, 12:27:54 schrieb Mark Rutland:
> On Mon, Jun 06, 2016 at 05:20:03PM +0800, Frank Wang wrote:
> > Signed-off-by: Frank Wang
> > ---
> >
> > Changes in v3:
> > - Added 'clocks' and 'clock-names' optional properties.
> > - Specified 'otg-port' and 'host-port' as the sub-no
tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
testing/next
head: 89fe2b5ab11cdf6a67d4492d893e70e330aa7060
commit: 231b31ca34485552fe27e67dc6d30d06079c7648 [64/67] usb: gadget: move
gadget API functions to udc-core
config: x86_64-randconfig-s1-06061834 (attached as .confi
Hi,
kbuild test robot writes:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
> testing/next
> head: 89fe2b5ab11cdf6a67d4492d893e70e330aa7060
> commit: 231b31ca34485552fe27e67dc6d30d06079c7648 [64/67] usb: gadget: move
> gadget API functions to udc-core
> config: x86_
Hi,
Felipe Balbi writes:
> [ Unknown signature status ]
>
> Hi,
>
> kbuild test robot writes:
>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
>> testing/next
>> head: 89fe2b5ab11cdf6a67d4492d893e70e330aa7060
>> commit: 231b31ca34485552fe27e67dc6d30d06079c7648 [64/67]
On Thu, Jun 02, 2016 at 05:14:05PM +0200, Hans de Goede wrote:
> From: Reinder de Haan
>
> At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
> reset lines, the controller will not initialize while the reset for
> its companion is still asserted, which means we need to de-assert
On Fri, Jun 03, 2016 at 11:39:27AM -0700, Guenter Roeck wrote:
> On Fri, Jun 03, 2016 at 06:17:46PM +0300, Heikki Krogerus wrote:
> [ ... ]
> > > > >
> > > > > In my test case, this gives me
> > > > > /sys/class/type-c/usbc0/
> > > > > usbc0.svid:18d1
> > > > > usbc0.svid:18d1/mod
On Mon, 2016-06-06 at 16:28 +0300, Heikki Krogerus wrote:
> I would prefer lower case letters. I don't know the SIDs there are at
> them moment, other then Display Port. Do you know them?
>
> I don't think we can ever guarantee that in every case we will be able
> to provide a human readable name
Hi,
On Fri, Jun 03, 2016 at 10:20:01PM +0200, Pavel Machek wrote:
> On Thu 2016-05-19 15:44:54, Heikki Krogerus wrote:
> > The purpose of this class is to provide unified interface for user
> > space to get the status and basic information about USB Type-C
> > Connectors in the system, control dat
tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
testing/next
head: 89fe2b5ab11cdf6a67d4492d893e70e330aa7060
commit: 231b31ca34485552fe27e67dc6d30d06079c7648 [64/67] usb: gadget: move
gadget API functions to udc-core
config: arm-multi_v5_defconfig (attached as .config)
comp
The RTL8153-AD supports a persistent system specific MAC address.
This means a device plugged into two different systems with host side
support will show different (but persistent) MAC addresses.
This information for the system's persistent MAC address is burned in when
the system HW is built and
Since this is a Realtek feature, I feel this shouldn't be moved into a platform
MAC address lookup. The code should only be run when the correct Realtek device
is plugged in.
Changes from v2:
* Only apply to RTL8153-AD w/ eFuse pass through mac address pass thru
bit set.
* Drop matching DMI
On Mon, Jun 06, 2016 at 09:15:20AM -0500, Mario Limonciello wrote:
> Since this is a Realtek feature, I feel this shouldn't be moved into a
> platform
> MAC address lookup. The code should only be run when the correct Realtek
> device
> is plugged in.
>
> Changes from v2:
> * Only apply to RTL
> + /* returns _AUXMAC_#AABBCCDDEEFF# */
> + status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, &buffer);
> + obj = (union acpi_object *)buffer.pointer;
> + if (ACPI_SUCCESS(status)) {
> + if (obj->type != ACPI_TYPE_BUFFER ||
> + obj->string.length !
On Mon, Jun 06, 2016 at 04:45:09PM +0300, Heikki Krogerus wrote:
> Hi,
>
> On Fri, Jun 03, 2016 at 10:20:01PM +0200, Pavel Machek wrote:
> > On Thu 2016-05-19 15:44:54, Heikki Krogerus wrote:
> > > The purpose of this class is to provide unified interface for user
> > > space to get the status and
On Mon, Jun 06, 2016 at 09:15:21AM -0500, Mario Limonciello wrote:
> The RTL8153-AD supports a persistent system specific MAC address.
> This means a device plugged into two different systems with host side
> support will show different (but persistent) MAC addresses.
>
> This information for the
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Monday, June 6, 2016 9:40 AM
> To: Limonciello, Mario
> Cc: hayesw...@realtek.com; LKML ; Netdev
> ; Linux USB ;
> pali.ro...@gmail.com; anthony.w...@canonical.com
> Subject: Re: [PATCH v3] r8152: Add support
On Mon, Jun 06, 2016 at 01:44:23PM +0200, Hans de Goede wrote:
> Hi All,
>
> While looking at libusb today I ended up looking at the
> reap-after-disconnect code.
>
> What stands out is that libusb expects to be able to
> reap all outstanding urbs on a device on receiving
> a POLL_ERR status from
On Mon, Jun 06, 2016 at 02:43:37PM +, mario_limoncie...@dell.com wrote:
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Monday, June 6, 2016 9:40 AM
> > To: Limonciello, Mario
> > Cc: hayesw...@realtek.com; LKML ; Netdev
> > ; Linux USB ;
> > pali
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Monday, June 6, 2016 9:50 AM
> To: Limonciello, Mario
> Cc: hayesw...@realtek.com; linux-ker...@vger.kernel.org;
> net...@vger.kernel.org; linux-usb@vger.kernel.org; pali.ro...@gmail.com;
> anthony.w...@canoni
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Monday, June 6, 2016 9:40 AM
> To: Limonciello, Mario
> Cc: hayesw...@realtek.com; LKML ; Netdev
> ; Linux USB ;
> pali.ro...@gmail.com; anthony.w...@canonical.com
> Subject: Re: [PATCH v3] r8152: Add support
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Monday, June 6, 2016 9:41 AM
> To: Limonciello, Mario
> Cc: hayesw...@realtek.com; LKML ; Netdev
> ; Linux USB ;
> pali.ro...@gmail.com; anthony.w...@canonical.com; Greg KH
>
> Subject: Re: [PATCH v3] r8152: Add supp
Hi,
Baolin Wang writes:
> On ARM64 platform, it will set 'dummy_dma_ops' for device dma_ops if
> it did not call 'arch_setup_dma_ops' at device creation time, that will
> cause failure when setting the dma mask for device.
>
> Thus this patch set the xhci device dma_ops from the parent device if
Hi,
On 06-06-16 16:48, Greg Kroah-Hartman wrote:
On Mon, Jun 06, 2016 at 01:44:23PM +0200, Hans de Goede wrote:
Hi All,
While looking at libusb today I ended up looking at the
reap-after-disconnect code.
What stands out is that libusb expects to be able to
reap all outstanding urbs on a devic
Phasing out generic reset line requests enables us to make some better
decisions on when and how to (de)assert said lines. If an 'exclusive'
line is requested, we know a device *requires* a reset and that it's
preferable to act upon a request right away. However, if a 'shared'
reset line is reque
On the STiH410 B2120 development board the MiPHY28lp shares its reset
line with the Synopsys DWC3 SuperSpeed (SS) USB 3.0 Dual-Role-Device
(DRD). New functionality in the reset subsystems forces consumers to
be explicit when requesting shared/exclusive reset lines.
Signed-off-by: Lee Jones
---
Standardise the way inline functions:
devm_reset_control_get_shared_by_index
devm_reset_control_get_exclusive_by_index
... are formatted.
Signed-off-by: Lee Jones
---
include/linux/reset.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/reset.h b/inclu
On the STiH410 B2120 development board the MiPHY28lp shares its reset
line with the Synopsys DWC3 SuperSpeed (SS) USB 3.0 Dual-Role-Device
(DRD). New functionality in the reset subsystems forces consumers to
be explicit when requesting shared/exclusive reset lines.
Signed-off-by: Lee Jones
---
Phasing out generic reset line requests enables us to make some better
decisions on when and how to (de)assert said lines. If an 'exclusive'
line is requested, we know a device *requires* a reset and that it's
preferable to act upon a request right away. However, if a 'shared'
reset line is reque
Consumers need to be able to specify whether they are requesting an
'exclusive' or 'shared' reset line no matter which API (of_*, devm_*,
etc) they are using. This change allows users of the optional_* API
in particular to specify that their request is for a 'shared' line.
Signed-off-by: Lee Jone
We're about to split the current API into two, where consumers will
be forced to be explicit when requesting reset lines. The choice
will be to either the call the *_exclusive or *_shared variant
depending on whether they can actually tolorate not being asserted
when that request is made.
The new
Consumers need to be able to specify whether they are requesting an
'exclusive' or 'shared' reset line no matter which API (of_*, devm_*,
etc) they are using. This change allows users of the of_* API in
particular to specify that their request is for a 'shared' line.
Signed-off-by: Lee Jones
---
On Mon, Jun 06, 2016 at 04:45:09PM +0300, Heikki Krogerus wrote:
> Hi,
>
> On Fri, Jun 03, 2016 at 10:20:01PM +0200, Pavel Machek wrote:
> > On Thu 2016-05-19 15:44:54, Heikki Krogerus wrote:
> > > The purpose of this class is to provide unified interface for user
> > > space to get the status and
On Mon, Jun 06, 2016 at 02:56:32PM +, mario_limoncie...@dell.com wrote:
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Monday, June 6, 2016 9:40 AM
> > To: Limonciello, Mario
> > Cc: hayesw...@realtek.com; LKML ; Netdev
> > ; Linux USB ;
> > pali
> Apparently this bug also prevented scheduling of endpoints which
> failed to schedule once in the past. Formerly I was getting only one
>
> usbatm_submit_urb: urb 0x8807f1568b00 submission failed (-28)!
>
> from ueagle-atm and now I'm getting regular spam. I think there's good
> chance that
On Mon, 6 Jun 2016, Hans de Goede wrote:
> Hi,
>
> On 06-06-16 16:48, Greg Kroah-Hartman wrote:
> > On Mon, Jun 06, 2016 at 01:44:23PM +0200, Hans de Goede wrote:
> >> Hi All,
> >>
> >> While looking at libusb today I ended up looking at the
> >> reap-after-disconnect code.
> >>
> >> What stands
On the STiH410 B2120 development board the ST EHCI IP shares its reset
line with the OHCI IP. New functionality in the reset subsystems forces
consumers to be explicit when requesting shared/exclusive reset lines.
Signed-off-by: Lee Jones
---
drivers/usb/host/ohci-st.c | 4 ++--
1 file changed,
On the STiH410 B2120 development board the ST EHCI IP shares its reset
line with the OHCI IP. New functionality in the reset subsystems forces
consumers to be explicit when requesting shared/exclusive reset lines.
Signed-off-by: Lee Jones
---
drivers/usb/host/ehci-st.c | 4 ++--
1 file changed,
On the STiH410 B2120 development board the ports on the Generic PHY
share their reset lines with each other. New functionality in the
reset subsystems forces consumers to be explicit when requesting
shared/exclusive reset lines.
Signed-off-by: Lee Jones
---
drivers/phy/phy-stih407-usb.c | 4 ++-
The RTL8153-AD supports a persistent system specific MAC address.
This means a device plugged into two different systems with host side
support will show different (but persistent) MAC addresses.
This information for the system's persistent MAC address is burned in when
the system HW is built and
> > Realtek has this in their Windows driver that all OEM's will be taking.
> > Another OEM would just need to burn the right information into the SPI at
> > manufacturing and expose it to the DSDT.
>
> Where it the match up for the Realtek bit to corrispond with this
> specific ACPI field? If it
tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
testing/next
head: 89fe2b5ab11cdf6a67d4492d893e70e330aa7060
commit: 231b31ca34485552fe27e67dc6d30d06079c7648 [64/67] usb: gadget: move
gadget API functions to udc-core
config: arm-pxa_defconfig (attached as .config)
compiler:
On Mon, Jun 06, 2016 at 05:24:57PM +, mario_limoncie...@dell.com wrote:
> That said, I would be highly surprised if Realtek decided to implement
> with another OEM differently. It would increase their code complexity
> on Windows as well since this is part of the generic driver.
Ah, it's refr
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Mario Limonciello
> Sent: Monday, June 06, 2016 12:19
> To: hayesw...@realtek.com
> Cc: LKML; Netdev; Linux USB; pali.ro...@gmail.com;
> anthony.w...@canonical.com; Greg KH;
On Mon, 6 Jun 2016, Lee Jones wrote:
> On the STiH410 B2120 development board the ST EHCI IP shares its reset
> line with the OHCI IP. New functionality in the reset subsystems forces
> consumers to be explicit when requesting shared/exclusive reset lines.
>
> Signed-off-by: Lee Jones
For this
> -Original Message-
> From: Konstantin Shkolnyy [mailto:konstantin.shkol...@silabs.com]
> Sent: Monday, June 6, 2016 12:43 PM
> To: Limonciello, Mario ;
> hayesw...@realtek.com
> Cc: LKML ; Netdev
> ; Linux USB ;
> pali.ro...@gmail.com; anthony.w...@canonical.com; Greg KH
>
> Subject: RE:
On Sat, 4 Jun 2016, Marco Chiappero wrote:
> On 31/05/2016 16:34, Alan Stern wrote:
> > On Tue, 31 May 2016, Mathias Nyman wrote:
> >
> >>
> >> xhci specs say that port will move from Disconnected (PLS = RX_DETECT) to
> >> Polling if "SuperSpeed far-end receiver terminations are detected"
> >>
> >
On Mon, 6 Jun 2016, Michał Pecio wrote:
> > Apparently this bug also prevented scheduling of endpoints which
> > failed to schedule once in the past. Formerly I was getting only one
> >
> > usbatm_submit_urb: urb 0x8807f1568b00 submission failed (-28)!
> >
> > from ueagle-atm and now I'm get
Felipe Balbi writes:
> instead of having infinite loop and always checking
> timeout value as a break condition, we can just
> decrement timeout inside while's condition.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/dwc3/gadget.c | 18 ++
> 1 file changed, 6 insertions(+
> > As I said, it now reports ENOSPC errors if there are low-speed
> > devices or significant isochronous transfers on the bus.
>
> It's quite possible that those are genuine errors. That is, the
> requested bandwidth may be more than the bus can provide.
Possible. This modem runs 1007 byte I
Currently it is possible to build in some subset of usb functions
*OR* some gadget module. This is limited only by Kconfig not
any functionality.
This patch removes this limitation. With this patch it is possible
to set up all build combinations:
1) Multiple gadgets build in
2) Part of functions b
Hi,
Am Mittwoch, 1. Juni 2016, 10:02:09 schrieb Krzysztof Kozlowski:
> My third approach for a USB power sequence which fixes usb3503+lan
> on Odroid U3 board if it was initialized by bootloader
> (e.g. for TFTP boot).
I was just tackling a similar bringup problem regarding an embedded usb hub
a
On Mon, 6 Jun 2016, Michał Pecio wrote:
> > > As I said, it now reports ENOSPC errors if there are low-speed
> > > devices or significant isochronous transfers on the bus.
> >
> > It's quite possible that those are genuine errors. That is, the
> > requested bandwidth may be more than the bus
On 06/06/2016 09:40 PM, Krzysztof Opasiak wrote:
> config USB_G_ACM_MS
> tristate "CDC Composite Device (ACM and mass storage)"
> depends on BLOCK
> - select USB_LIBCOMPOSITE
> - select USB_U_SERIAL
> - select USB_F_ACM
> - select USB_F_MASS_STORAGE
> + depends o
Hi Alan,
thank you for your effort. I applied it to 4.6.0 and I haven't seen
the USBSAN message reported anymore about this (though I do for ext4
and IP stack for example).
Tested-By: Martin MOKREJŠ
Alan Stern wrote:
Several people have reported that UBSAN doesn't like the pointer
arithmetic
The only caller of get_gadget_descs() has already dereferenced udc
before calling this function, so udc can not be NULL at this point of
the code and hence no use of checking it.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/usbip/vudc_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
On 06/06/2016 11:23 PM, Sudip Mukherjee wrote:
> The only caller of get_gadget_descs() has already dereferenced udc
> before calling this function, so udc can not be NULL at this point of
> the code and hence no use of checking it.
>
> Signed-off-by: Sudip Mukherjee
> ---
> drivers/usb/usbip/v
subscribe linux-usb
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
> That's clear enough.
>
> ISO IN 1007 bytes -> 793 us
> INT IN 32 bytes -> 35 us
>--
>825 us
>
> The additional requirements are:
>
> ISO IN 48 bytes -> 45 us -> 870 us total
> ISO IN 192 bytes -> 158 us
Hi,
I need help with getting http://www.linux-usb.org/gadget/usb.c working on my
Beagle Bone Black based embedded board. I'm using TI Processor SDK 2.00.02.11
with their linux kernel linux-4.1.18+gitAUTOINC+bbe8cfc1da-gbbe8cfc. My
application is based on the usb.c example and it worked OK with t
On Mon, Jun 06, 2016 at 09:40:33PM +0200, Krzysztof Opasiak wrote:
> Currently it is possible to build in some subset of usb functions
> *OR* some gadget module. This is limited only by Kconfig not
> any functionality.
>
> This patch removes this limitation. With this patch it is possible
> to set
On Mon, Jun 06, 2016 at 04:16:17PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Felipe Balbi writes:
> > [ Unknown signature status ]
> >
> > Hi,
> >
> > kbuild test robot writes:
> >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
> >> testing/next
> >> head: 89fe2b5ab11cdf
On 6 June 2016 at 22:59, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> On ARM64 platform, it will set 'dummy_dma_ops' for device dma_ops if
>> it did not call 'arch_setup_dma_ops' at device creation time, that will
>> cause failure when setting the dma mask for device.
>>
>> Thus this pa
Hi Heiko & Mark,
On 2016/6/6 20:33, Heiko Stübner wrote:
Am Montag, 6. Juni 2016, 12:27:54 schrieb Mark Rutland:
On Mon, Jun 06, 2016 at 05:20:03PM +0800, Frank Wang wrote:
Signed-off-by: Frank Wang
---
Changes in v3:
- Added 'clocks' and 'clock-names' optional properties.
- Specified 'o
Hi Roger
>
> For Mux devices implementing dual-role, the mux device driver _must_ use
> OTG/dual-role core API so that a common ABI is presented to user space for
> OTG/dual-role.
That's the only point we have concern, do dual role switch through
OTG/dual-role core, not do it by itself.
>
> I
Hi Heiko,
On 2016/6/7 10:59, Frank Wang wrote:
Hi Heiko & Mark,
On 2016/6/6 20:33, Heiko Stübner wrote:
Am Montag, 6. Juni 2016, 12:27:54 schrieb Mark Rutland:
On Mon, Jun 06, 2016 at 05:20:03PM +0800, Frank Wang wrote:
Signed-off-by: Frank Wang
---
Changes in v3:
- Added 'clocks' and 'c
>On Fri, 3 Jun 2016, Chung-Geol Kim wrote:
>
>> Yes, you are right, The presentational errors in order to obtain an
>> understanding of the process.
>> Therefore, I will be happy to explain again the diagrammatic representation
>> as shown below.
>> If using usb 3.0 storage(OTG), you can see as b
On 06/06/2016 10:43 PM, Heiko Stübner wrote:
> Hi,
>
> Am Mittwoch, 1. Juni 2016, 10:02:09 schrieb Krzysztof Kozlowski:
>> My third approach for a USB power sequence which fixes usb3503+lan
>> on Odroid U3 board if it was initialized by bootloader
>> (e.g. for TFTP boot).
>
> I was just tackling
Hi Jun,
On 06/07/2016 11:03 AM, Jun Li wrote:
> Hi Roger
>
>>
>> For Mux devices implementing dual-role, the mux device driver _must_ use
>> OTG/dual-role core API so that a common ABI is presented to user space for
>> OTG/dual-role.
> That's the only point we have concern, do dual role switch t
81 matches
Mail list logo
