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
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
>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
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
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 & 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
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
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 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
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
> 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
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
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
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(
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
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
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
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
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
> > 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
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(+
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
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"
> >>
> >
> -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 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: 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, 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
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:
> > 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
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
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 ++-
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 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 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
> 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, 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
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
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
---
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
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
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
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
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
> -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
> -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: 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
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
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
> -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
> + /* 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
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
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
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
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
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
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 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
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]
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_
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
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
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
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
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
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
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
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
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
> 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 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
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 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,
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
81 matches
Mail list logo
