From: "Du, Changbin"
Queue a request to disabled ep doesn't make sense, and induce caller
make mistakes.
Here is a example for the android mtp gadget function driver. A mem
corruption can happen on below senario.
1) On disconnect, mtp driver disable its EPs,
2) During send_file_work and receive
On Fri, Dec 18, 2015 at 12:13 AM, Alan Stern wrote:
> On Wed, 16 Dec 2015, Rob Herring wrote:
>
>> On Mon, Dec 14, 2015 at 3:35 AM, Arnd Bergmann wrote:
>> > On Monday 14 December 2015 15:26:11 Peter Chen wrote:
>> >> Hi all,
>> >>
>> >> There is a known issue that the USB code can't handle USB H
On Thu, Dec 17, 2015 at 9:49 PM, Rob Herring wrote:
> On Wed, Dec 16, 2015 at 8:31 PM, Peter Chen wrote:
>> On Thu, Dec 17, 2015 at 12:13:07AM +0100, Arnd Bergmann wrote:
>>> On Wednesday 16 December 2015 16:59:39 Rob Herring wrote:
>>> > On Mon, Dec 14, 2015 at 3:35 AM, Arnd Bergmann wrote:
>>>
> >
> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> > index 3d583a1..0c5d9ea 100644
> > --- a/include/linux/usb/gadget.h
> > +++ b/include/linux/usb/gadget.h
> > @@ -402,6 +402,9 @@ static inline void usb_ep_free_request(struct
> usb_ep *ep,
> > static inline int usb_ep_
> The search, share, connect(?), and settings keys
I tested the patch again with xev and found that those "charm" keys
don't respond both on hid-microsoft and hid-multitouch, while other
keys respond. I'll have a further look.
Anyway, keys working with hid-microsoft also work with hid-multitouch,
On 12/17/2015 6:26 PM, Marek Vasut wrote:
> The "enumspd" field is located in register DSTS[2:1], but the code
> which checks the bitfield does not shift the value accordingly. This
> in turn causes incorrect detection of gadget link partner speed in
> dwc2_hsotg_irq_enumdone() .
>
> Shift the val
The "enumspd" field is located in register DSTS[2:1], but the code
which checks the bitfield does not shift the value accordingly. This
in turn causes incorrect detection of gadget link partner speed in
dwc2_hsotg_irq_enumdone() .
Shift the value accordingly to fix the problem with speed detection
On Friday, December 18, 2015 at 12:45:56 AM, John Youn wrote:
> On 12/17/2015 2:49 PM, Marek Vasut wrote:
> > The "enumspd" field is located in register DSTS[2:1], but the current
> > set of macros define the possible values without the necessary offset.
> > This in turn causes incorrect detection
Hi Sergei,
Except for just one comment below, Looks good to me.
Acked-by: Chanwoo Choi
I'll wait for a few days to get the review from DT maintainer
before applying it on extcon-next branch.
On 2015년 12월 18일 07:47, Sergei Shtylyov wrote:
> Maxim Integrated MAX3355E chip integrates a charge pump
On 2015년 12월 18일 06:20, Sergei Shtylyov wrote:
> Hello.
>
> On 12/17/2015 05:34 AM, Chanwoo Choi wrote:
>
>>> On 2015년 12월 17일 03:07, Sergei Shtylyov wrote:
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role tr
On 17.12.2015 23:36, Sergei Shtylyov wrote:
> Hello.
>
> On 12/17/2015 3:53 AM, Krzysztof Kozlowski wrote:
>
>>> Maxim Integrated MAX3355E chip integrates a charge pump and
>>> comparators to
>>> enable a system with an integrated USB OTG dual-role transceiver to
>>> function as an USB OTG dual-r
On 12/17/2015 2:49 PM, Marek Vasut wrote:
> The "enumspd" field is located in register DSTS[2:1], but the current
> set of macros define the possible values without the necessary offset.
> This in turn causes incorrect detection of gadget link partner speed
> in dwc2_hsotg_irq_enumdone() .
>
> The
The "enumspd" field is located in register DSTS[2:1], but the current
set of macros define the possible values without the necessary offset.
This in turn causes incorrect detection of gadget link partner speed
in dwc2_hsotg_irq_enumdone() .
The rest of the macros in dwc2/hw.h always define possibl
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also passes thru the ID signal from the USB OTG connector.
On som
On Thu, 17 Dec 2015, Christian wrote:
> T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> P: Vendor=05e3 ProdID=0745 Rev= 9.02
> S: Product=USB Storage
> S: SerialNumber=0902
> C:* #Ifs= 1 Cfg#= 1 Atr=80 M
Hello.
On 12/17/2015 05:34 AM, Chanwoo Choi wrote:
On 2015년 12월 17일 03:07, Sergei Shtylyov wrote:
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition
From: Bjørn Mork
Date: Thu, 17 Dec 2015 12:44:04 +0100
> The CDC descriptors found on these vendor specific functions should
> not be considered authoritative. They seem to be ignored by drivers
> for other systems, and the quality is therefore low.
>
> One device (1e0e:9001) has been reported
T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=05e3 ProdID=0745 Rev= 9.02
S: Product=USB Storage
S: SerialNumber=0902
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.)
Hello all,
No news since last week... Did someone have a look to my logfile? Any
chance to find a patch?
Seb.
Le 13/12/2015 22:46, Sébastien Deligny a écrit :
I've sent the logfile on Saturday, but I can't find my message in the
archive, move to spam? So here is the logfile simply past as te
Remove call to dwc2_hsotg_init() from dwc2_gadget_init(). The
gadget_init function should not access any device registers because the
mode isn't guaranteed here.
Also, this is already called elsewhere before anything starts on the
gadget so it is not necessary here.
Signed-off-by: John Youn
---
From: Yunzhi Li
We initiate dwc2 usb controller in BIOS, dwc2_core_reset() should
be called before dwc2_get_hwparams() to reset core registers to
default value. Without this the FIFO setting might be incorrect
because calculating FIFO size need power-on value of
GRXFSIZ/GNPTXFSIZ/HPTXFSIZ registe
The dwc2_core_reset() function exists in the core so use that one
instead.
Signed-off-by: John Youn
---
drivers/usb/dwc2/gadget.c | 50 +--
1 file changed, 1 insertion(+), 49 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadge
Reset already happens before this so just force the dr_mode.
Signed-off-by: John Youn
---
drivers/usb/dwc2/platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 5002806..a14d996 100644
--- a/drivers/usb/dwc2
The delay for force mode is only 25ms according to the databook.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 097fd9f..73f2771 100644
--- a/drivers/usb/dwc2/core.c
dwc2_core_reset() was previously renamed to
dwc2_core_reset_and_dr_force_mode(). Now add back dwc2_core_reset() which
performs only a basic core reset without forcing the mode.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 22 --
drivers/usb/dwc2/core.h | 1 +
2 fil
Use the previously cached hw params in the gadget. This saves a reset
and force mode in the gadget initialization during probe and makes
getting the hardware parameters consistent between gadget and host.
Signed-off-by: John Youn
---
drivers/usb/dwc2/gadget.c | 41 ---
Renamed dwc2_core_reset() to dwc2_core_reset_and_force_dr_mode(). This
describes what it is doing more accurately. This is in preparation of
introducing a plain dwc2_core_reset() function that only performs the
reset and doesn't force the mode.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.
Added functions to query the GHWCFG2.OTG_MODE. This tells us whether the
controller hardware is configured for OTG, device-only, or host-only.
Signed-off-by: John Youn
Tested-by: Douglas Anderson
Reviewed-by: Douglas Anderson
---
drivers/usb/dwc2/core.c | 37 +++
From: Yunzhi Li
I found that the probe function of dwc2 driver takes much time
when kernel boot up. There are many long delays in the probe
function these take almost 1 second.
This patch trying to reduce unnecessary delay time.
In dwc2_core_reset() I see it use two at least 20ms delays to
wait
The reset is required to get reset values of the hardware parameters but
the force mode is not. Move the base reset into dwc2_get_hwparams() and
do the reset and force mode afterwards.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 8
drivers/usb/dwc2/platform.c | 10 +++---
Adds separate functions to get the host and device specific hardware
parameters. The functions check whether the parameters need to be read
at all, depending on dr_mode, and forces the mode only if necessary.
This saves some delays during probe. This also adds two device mode
parameters that will b
Added functions to set force mode for host and device. These functions
will check the current mode and only force if needed thus avoiding
unnecessary force mode delays. However clearing the mode is currently
done unconditionally and with the delay in place. This is needed during
the connector ID st
These functions should go in core.h where they can be called from core,
device, or host.
Signed-off-by: John Youn
Reviewed-by: Douglas Anderson
Tested-by: Douglas Anderson
---
drivers/usb/dwc2/core.h | 12
drivers/usb/dwc2/hcd.h | 12
2 files changed, 12 insertions(+
The dr_mode parameter was being checked against how the dwc2 module
was being configured at compile time. But it wasn't checked against
the hardware capabilities, nor were the hardware capabilities checked
against the compilation parameters.
This commit adds those checks and adjusts dr_mode to an
From: Douglas Anderson
In (usb: dwc2: reset dwc2 core before dwc2_get_hwparams()) we added an
extra reset to the probe path for the dwc2 USB controllers. This
allowed proper detection of parameters even if the firmware had already
used the USB part.
Unfortunately, this extra reset is quite slow
From: Douglas Anderson
Calls to dwc2_core_reset() are currently very slow, taking at least
150ms (possibly more). It behooves us to take as many of these calls
out as possible.
It turns out that the calls in dwc2_fs_phy_init() and dwc2_hs_phy_init()
should (as documented in the code) only be ne
From: Douglas Anderson
Previously dwc2_get_hwparams() was changing GUSBCFG and not putting it
back the way it was (specifically it set and cleared FORCEHOSTMODE).
Since we want to move dwc2_core_reset() _before_ dwc2_get_hwparams() we
should make sure dwc2_get_hwparams() isn't messing with things
From: Douglas Anderson
On some host-only DWC2 ports (like the one in rk3288) when we set
GUSBCFG_FORCEHOSTMODE in GUSBCFG and then read back, we don't see the
bit set. Presumably that's because the port is always forced to HOST
mode so there's no reason to implement these status bits.
Since we
According to the databook, the core soft reset should be done before
checking for AHBIDLE. The gadget version of core reset had it correct
but the hcd version did not. This fixes the hcd version.
Signed-off-by: John Youn
Reviewed-by: Douglas Anderson
Tested-by: Douglas Anderson
---
drivers/usb
This series includes patches that were submitted earlier by Douglas
Anderson and Yunzhi Li to reduce delays during probe and get the
correct reset values of the hardware configuration registers. These
are patches 1-6 in this series.
I have additionally added patches to clean up the code around tha
On Wed, 16 Dec 2015, Rob Herring wrote:
> On Mon, Dec 14, 2015 at 3:35 AM, Arnd Bergmann wrote:
> > On Monday 14 December 2015 15:26:11 Peter Chen wrote:
> >> Hi all,
> >>
> >> There is a known issue that the USB code can't handle USB HUB's
> >> external pins well, in that case, it may cause some
If OF is disabled, we will try to define a stub for
of_usb_get_dr_mode_by_phy(), however that missed a
static inline annotation which made us redefine the
stub over and over again. Fix that.
Fixes: 98bfb3946695 ("usb: of: add an api to get
dr_mode by the phy node")
Signed-off-by: Felipe Ba
On Thu, 17 Dec 2015, Christian wrote:
> Hi,
>
> I have a problem with sdhc and sd-cards. I cannot access the cards because
> I always get I/O errors according to dmesg.
>
> I tried 2 types of card readers and 3 types of sdhc cards. I also tried the
> sdhc cards with sd-card adapters.
>
> I
Hi,
David Laight writes:
> From: Bin Liu
>> Sent: 17 December 2015 15:55
> ...
>> >> drivers/usb/common/built-in.o: In function
>> >> `of_usb_get_dr_mode_by_phy':
>> (.text+0x0): multiple definition of `of_usb_get_dr_mode_by_phy'
>> >> drivers/usb/chipidea/built-in.o:(.text+0xd61):
From: Bin Liu
> Sent: 17 December 2015 15:55
...
> >> drivers/usb/common/built-in.o: In function `of_usb_get_dr_mode_by_phy':
> (.text+0x0): multiple definition of `of_usb_get_dr_mode_by_phy'
> >> drivers/usb/chipidea/built-in.o:(.text+0xd61): first defined here
> >
> >
> > seems like
Felipe,
On 12/17/2015 09:52 AM, Felipe Balbi wrote:
Hi,
kbuild test robot writes:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
head: b7bd98b7db9fc8fe19da1a5ff0215311c6b95e46
commit: 98bfb39466954c69d2a448e6ddcab6d91cd48e25 [38/65] usb: of: add an api to
get d
Hi,
kbuild test robot writes:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
> head: b7bd98b7db9fc8fe19da1a5ff0215311c6b95e46
> commit: 98bfb39466954c69d2a448e6ddcab6d91cd48e25 [38/65] usb: of: add an api
> to get dr_mode by the phy node
> config: x86_64-acpi-red
tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
head: b7bd98b7db9fc8fe19da1a5ff0215311c6b95e46
commit: 98bfb39466954c69d2a448e6ddcab6d91cd48e25 [38/65] usb: of: add an api to
get dr_mode by the phy node
config: x86_64-acpi-redef (attached as .config)
reproduce:
Hi,
changbin...@intel.com writes:
> From: "Du, Changbin"
>
> Queue a request to disabled ep doesn't make sense, and induce caller
> make mistakes.
>
> Here is a example for the android mtp gadget function driver. A mem
> corruption can happen on below senario.
> 1) On disconnect, mtp driver dis
Hello.
On 12/17/2015 3:53 AM, Krzysztof Kozlowski wrote:
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also
On Wed, Dec 16, 2015 at 8:31 PM, Peter Chen wrote:
> On Thu, Dec 17, 2015 at 12:13:07AM +0100, Arnd Bergmann wrote:
>> On Wednesday 16 December 2015 16:59:39 Rob Herring wrote:
>> > On Mon, Dec 14, 2015 at 3:35 AM, Arnd Bergmann wrote:
>> > > On Monday 14 December 2015 15:26:11 Peter Chen wrote:
On 17.12.2015 15:26, Andor J Kiss wrote:
Hi,
I'll do my best - if you want more information, or I am unclear
please let me know. I've been using Ubuntu (and Debian derived distros
for about 10 years - so hopefully I'm slightly helpful).
I have noticed that on Ubuntu 15.10 (on a new Syste
Hi,
I'll do my best - if you want more information, or I am unclear
please let me know. I've been using Ubuntu (and Debian derived distros
for about 10 years - so hopefully I'm slightly helpful).
I have noticed that on Ubuntu 15.10 (on a new System76 Lemur laptop -
which I believe is ACER ba
Hi Bjorn,
2015-12-17 13:21 GMT+01:00 Bjørn Mork :
> Dan Williams writes:
>> On Wed, 2015-12-16 at 10:39 +0100, Daniele Palmas wrote:
>>> This patch series add support in the cdc_ncm driver for two devices
>>> based on the same platform, that are different only for carrier
>>> customization.
>>>
>
Hi Dan,
2015-12-16 18:12 GMT+01:00 Dan Williams :
> On Wed, 2015-12-16 at 10:39 +0100, Daniele Palmas wrote:
>> This patch series add support in the cdc_ncm driver for two devices
>> based on the same platform, that are different only for carrier
>> customization.
>>
>> The devices do not have ARP
Dan Williams writes:
> On Wed, 2015-12-16 at 10:39 +0100, Daniele Palmas wrote:
>> This patch series add support in the cdc_ncm driver for two devices
>> based on the same platform, that are different only for carrier
>> customization.
>>
>> The devices do not have ARP capabilities.
>>
>> Daniel
The CDC descriptors found on these vendor specific functions should
not be considered authoritative. They seem to be ignored by drivers
for other systems, and the quality is therefore low.
One device (1e0e:9001) has been reported to have such a bogus union
descriptor on the QMI function, making i
Hi Robert,
On 11/12/15 11:24, Robert Baldyga wrote:
> It seems that gitotious repository is no longer accessible, so we replace
> it with address to active repository.
>
> Signed-off-by: Robert Baldyga
> ---
> Documentation/usb/gadget-testing.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 dele
Hi Balbi,
On 16/12/15 16:03, Felipe Balbi wrote:
>
> Hi
>
> Felipe Ferreri Tonello writes:
>> Hi all,
>>
>> On 01/12/15 18:30, Felipe F. Tonello wrote:
>>> Fixed all comments suggested by the linux-usb list.
>>>
>>> changes in v6:
>>> - Removed patches already applied in Balbi's tree
>>> - Cl
Set DMA_MASK of usb platform device properly.
Signed-off-by: Sriram Dash
Signed-off-by: Ramneek Mehresh
---
drivers/usb/host/fsl-mph-dr-of.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 0c3826
Hi Felipe,
I can see that you have applied the documentation fix patch to your
tree. Have also you looked at the remaining patches of this series? What
do you think about this concept? Any comments?
Best regards,
Robert
On 12/11/2015 12:24 PM, Robert Baldyga wrote:
> Hi Felipe,
>
> Here is my n
From: "Du, Changbin"
Queue a request to disabled ep doesn't make sense, and induce caller
make mistakes.
Here is a example for the android mtp gadget function driver. A mem
corruption can happen on below senario.
1) On disconnect, mtp driver disable its EPs,
2) During send_file_work and receive
> >> 2.5.0
> >
> > With this patch, ep0 transfer breaks. it because the 'enabled' of ep0
> > is not set. Ep0 is not enabled by usb_ep_enable, but in UDC driver. So
> > there need another patch to set ep0's flag also.
>
> yeah, we don't like regressions :-) So the fix should come before
> $subject
On 16.12.2015 17:51, Andor J Kiss wrote:
Hello Mathias,
I've noticed that in Ubuntu (and some other Debian distributions, not sure
about Debian itself) that USB 3 to USB 3 doesn't work (USB3 port to USB2
thumbdrive okay, USB3 thumbdrive to USB3 port OK).
I'm using Ubuntu 15.10 (4.2.0-21-gener
Hi,
I have a problem with sdhc and sd-cards. I cannot access the cards because
I always get I/O errors according to dmesg.
I tried 2 types of card readers and 3 types of sdhc cards. I also tried the
sdhc cards with sd-card adapters.
Interesting is, that i both cases, sdhc card directly and
65 matches
Mail list logo
