我的信息在:

你的老朋友邀你来Q群:343257759 抢红包 抢秒杀 抢vip 什么都要抢。太刺激了。不靠手气只拼手速

RE: [PATCH v4 2/2] usb: dwc3: add debugfs node to dump FIFO/Queue available space

Hello, Sergei, > > From: "Du, Changbin" > > > > For DWC3 USB controller, the Global Debug Queue/FIFO Space Available > > Register(GDBGFIFOSPACE) can be used to dump FIFO/Queue available > space. > > Space needed before (. Okay. > > > This can be used to check some

Re: [-next] BUG_ON in scsi_target_destroy()

Hello, On (04/13/16 08:14), James Bottomley wrote: [..] > How about good grief no! A device with multiple targets will get it's > lists screwed with this > > The STARGET_REMOVE state you added only applies to the case we're > trying to kill a target. In the natural operation case, which is

Re: [PATCHv3 2/2] usb: dwc2: Add reset control to dwc2

On Thursday 14 April 2016, dingu...@opensource.altera.com wrote: > @@ -337,6 +338,17 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg > *hsotg) > { > int i, ret; > > + hsotg->reset = devm_reset_control_get(hsotg->dev, "dwc2"); > + if (IS_ERR(hsotg->reset)) { > +

Re: [PATCH v2 2/2] phy: phy-mt65xx-usb3: add support for mt2701 platform

Hi, On Wed, 2016-04-13 at 19:01 +0530, Kishon Vijay Abraham I wrote: > Hi, > > On Monday 11 April 2016 01:11 PM, Chunfeng Yun wrote: > > A new compatible string, "mediatek,mt2701-u3phy", is added. > > > > Some register settings to avoid RX sensitivity level degradation > > which may arise on

Re: [PATCH v2 1/2] dt-bindings: phy-mt65xx-usb: add support for mt2701 platform

Hi, On Wed, 2016-04-13 at 18:56 +0530, Kishon Vijay Abraham I wrote: > Hi, > > On Monday 11 April 2016 01:11 PM, Chunfeng Yun wrote: > > A new compatible string, "mediatek,mt2701-u3phy", is added. > > how about changing the commit log to something like below? > Add a new compatible string for

Re: [PATCH v2 1/2] dt-bindings: phy-mt65xx-usb: add support for mt2701 platform

Hi, On Wed, 2016-04-13 at 12:00 +0200, Matthias Brugger wrote: > > On 11/04/16 09:41, Chunfeng Yun wrote: > > A new compatible string, "mediatek,mt2701-u3phy", is added. > > > > Signed-off-by: Chunfeng Yun > > --- > > .../devicetree/bindings/phy/phy-mt65xx-usb.txt

[PATCH 1/2] Documentation: dt-bindings: dwc2: add the resets and reset-names property

From: Dinh Nguyen Document the optional 'resets' and 'reset-names' property for the DWC2 usb core. Signed-off-by: Dinh Nguyen --- Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland

[PATCHv3 2/2] usb: dwc2: Add reset control to dwc2

From: Dinh Nguyen Allow for platforms that have a reset controller driver in place to bring the USB IP out of reset. Signed-off-by: Dinh Nguyen --- v4: use dev_dbg() if not a -EPROBE_DEFER v3: fix compile error v2: move to

RE: [PATCH 1/1] usb: lpm: add boot flag to disable lpm

Mathias provided me with some usb device calls I could use to resolve this in software (pm_runtime_get_xxx(), pm_runtime_put()), but I'm not familiar with the API, so I'd need some help figure out how to get the `struct device*' handle for my current device and issuing those calls within my

Re: [PATCH 1/1] usb: lpm: add boot flag to disable lpm

On Wed, Apr 13, 2016 at 03:21:09PM -0700, Matthew Giassa wrote: > The devices support LPM and are USB3.0 certified, and they work fine in > Windows using the same Intel 8/9/10 Series USB host controllers, along > with Renesas and Fresco controllers. On Linux the devices either seize > up or slow

RE: [PATCH 1/1] usb: lpm: add boot flag to disable lpm

The devices support LPM and are USB3.0 certified, and they work fine in Windows using the same Intel 8/9/10 Series USB host controllers, along with Renesas and Fresco controllers. On Linux the devices either seize up or slow down dramatically ever since LPM support was enabled. I could always

Re: [PATCH 1/1] usb: lpm: add boot flag to disable lpm

On Wed, Apr 13, 2016 at 02:37:35PM -0700, Matthew Giassa wrote: > Thank you for the feedback Greg. This is my first attempt to submit a > kernel patch. > > Is there a better approach to this? The only other option at my disposal > is to add about 200 products to the quirks.c file, and routinely

RE: [PATCH 1/1] usb: lpm: add boot flag to disable lpm

Thank you for the feedback Greg. This is my first attempt to submit a kernel patch. Is there a better approach to this? The only other option at my disposal is to add about 200 products to the quirks.c file, and routinely update that list as new products are released. I need to implement some

Re: [PATCH 1/1] usb: lpm: add boot flag to disable lpm

On Wed, Apr 13, 2016 at 02:25:08PM -0700, Matthew Giassa wrote: > commit 4e8998d462ab06900949a3099706a19177484c09 > Author: Matthew > Date: Wed Apr 13 13:37:21 2016 -0700 Why is this here? > > Adding new kernel parameter that allows users to skip the check > for

[PATCH 1/1] usb: lpm: add boot flag to disable lpm

commit 4e8998d462ab06900949a3099706a19177484c09 Author: Matthew Date: Wed Apr 13 13:37:21 2016 -0700 Adding new kernel parameter that allows users to skip the check for whether or not LPM is supported. This resolves erratic power state changes with certain U3V

Re: [PATCH v2 06/11] phy: da8xx-usb: new driver for DA8XX SoC USB PHY

On 04/01/2016 08:16 AM, Kishon Vijay Abraham I wrote: +EXPORT_SYMBOL_GPL(da8xx_usb20_phy_set_mode); Don't prefer export symbols from PHY driver. That'll create unnecessary dependencies between the controller and the PHY. I think it'll be better to create a new attribute and use it? Just

Re: [PATCH v3 09/16] phy: da8xx-usb: new driver for DA8xx SoC USB PHY

On 04/13/2016 08:20 AM, Kishon Vijay Abraham I wrote: Don't prefer export symbols from PHY driver. That'll create unnecessary dependencies between the controller and the PHY. To see how to fix it, please see my comment for the previous version of your patch. Thanks Kishon What is the

Re: [RFC] Change bcdUSB in older kernels to return 0x0310 for SuperSpeed

On Wed, 13 Apr 2016, John Youn wrote: > > Besides, this doesn't say what the version number of a non-Enhanced > > SuperSpeed device should be. I don't see why the USBCV would conclude > > that a non-Enhanced device needs to set the version to 0x0310. > > Non-Enhanced SuperSpeed (i.e. HS and

Re: [RFC] Change bcdUSB in older kernels to return 0x0310 for SuperSpeed

On 4/13/2016 7:58 AM, Alan Stern wrote: > On Tue, 12 Apr 2016, John Youn wrote: > >>> Wait, even SuperSpeed GEN1-only devices *must* set bcdUSB to 0x0310 ? Do >>> you have a reference to that ? I find that pretty odd because this means >>> that if I take any of my USB3 devices that I already have

Re: [PATCHv3] usb: dwc2: Add reset control to dwc2

On 4/13/2016 11:52 AM, Dinh Nguyen wrote: > On 04/13/2016 11:23 AM, Stefan Wahren wrote: > >>> + hsotg->reset = devm_reset_control_get(hsotg->dev, "dwc2"); >> >> shouldn't this be documented in >> Documentation/devicetree/bindings/usb/dwc2.txt ? >> > > Sure, I can document it. > >>> + if

RE: USB xHCI regression after upgrading from kernel 3.19.0-51 to 4.2.0-34.]

On Wed, 13 Apr 2016, Matthew Giassa wrote: > I will look into doing that. I think it would be preferable to add some > functionality to mark all devices matching a certain VendorID rather > than dumping the entire device table into `quirks.c', as I'd have to > routinely update it every time we

Re: [PATCHv3] usb: dwc2: Add reset control to dwc2

On 04/13/2016 11:23 AM, Stefan Wahren wrote: >> +hsotg->reset = devm_reset_control_get(hsotg->dev, "dwc2"); > > shouldn't this be documented in > Documentation/devicetree/bindings/usb/dwc2.txt ? > Sure, I can document it. >> +if (IS_ERR(hsotg->reset)) { >> +

RE: USB xHCI regression after upgrading from kernel 3.19.0-51 to 4.2.0-34.]

I will look into doing that. I think it would be preferable to add some functionality to mark all devices matching a certain VendorID rather than dumping the entire device table into `quirks.c', as I'd have to routinely update it every time we release a new product. In the meantime, if there's a

RE: USB xHCI regression after upgrading from kernel 3.19.0-51 to 4.2.0-34.]

On Wed, 13 Apr 2016, Matthew Giassa wrote: > Hi Felipe, Mathias; > > I pulled a clean copy of v4.5 and applied the patch suggested by Felipe, > and the issue is no longer present. I would like to disable this > behavior via changes to my software instead of requiring customers to > build a

RE: USB xHCI regression after upgrading from kernel 3.19.0-51 to 4.2.0-34.]

Hi Felipe, Mathias; I pulled a clean copy of v4.5 and applied the patch suggested by Felipe, and the issue is no longer present. I would like to disable this behavior via changes to my software instead of requiring customers to build a custom kernel. What would be the ideal solution to this

Re: [PATCH] usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value

On 11.04.2016 18:44, Peter Griffin wrote: Hi Mathias, On Fri, 25 Mar 2016, Peter Griffin wrote: Otherwise generic-xhci and xhci-platform which have no data get wrongly detected as XHCI_PLAT_TYPE_MARVELL_ARMADA by xhci_plat_type_is(). This fixes a regression in v4.5 for STiH407 family SoC's

[PATCH 1/1] usb: host: xhci-plat: Make enum xhci_plat_type start at a non zero value

From: Peter Griffin Otherwise generic-xhci and xhci-platform which have no data get wrongly detected as XHCI_PLAT_TYPE_MARVELL_ARMADA by xhci_plat_type_is(). This fixes a regression in v4.5 for STiH407 family SoC's which use the synopsis dwc3 IP, whereby the

RE: USB xHCI regression after upgrading from kernel 3.19.0-51 to 4.2.0-34.]

One more question: this issue does not occur if I intentionally do not claim the interface via libusb_claim_interface() before requesting streaming image data from the camera. Does this make any sense? It's to my understanding I should always claim the interface before issuing r/w calls to the

Re: [PATCHv3] usb: dwc2: Add reset control to dwc2

Hi Dinh, > From: Dinh Nguyen > > Allow for platforms that have a reset controller driver in place to bring the > USB IP out of reset. > > Signed-off-by: Dinh Nguyen > diff --git a/drivers/usb/dwc2/platform.c

Re: [-next] BUG_ON in scsi_target_destroy()

On Wed, 2016-04-13 at 10:41 +0200, Johannes Thumshirn wrote: > Hi Sergey, Xiong, > > Can you try below patch? > > On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote: > > Hello, > > > > commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96 > > Author: Johannes Thumshirn

Re: ehci-dbg prints random memory (# CONFIG_DYNAMIC_DEBUG is not set)

On Wed, 13 Apr 2016, Rafał Miłecki wrote: > Hi, > > I'm trying to debug some EHCI issue so I enabled debugging by adding > ccflags-y := -DDEBUG > to the drivers/usb/host/Makefile > > Some of debugging lines contain random memory, e.g.: > ehci-platform ehci-platform.0: .|��`|���5P5@�3�.��*�.|��o

Re: [PATCHv4 2/3] usb: storage: scsiglue: limit USB3 devices to 2048 sectors

On Wed, 13 Apr 2016, Felipe Balbi wrote: > USB3 devices, because they are much newer, have much > less chance of having issues with larger transfers. > > We still keep a limit because anything above 2048 > sectors really rendered negligible speed > improvements, so we will simply ignore > that.

Re: [RFC] Change bcdUSB in older kernels to return 0x0310 for SuperSpeed

On Tue, 12 Apr 2016, John Youn wrote: > > Wait, even SuperSpeed GEN1-only devices *must* set bcdUSB to 0x0310 ? Do > > you have a reference to that ? I find that pretty odd because this means > > that if I take any of my USB3 devices that I already have today, and run > > them against latest

Re: Tascam US-122L - Corrupt USB descriptor

On Wed, April 13, 2016 3:01 am, Clemens Ladisch wrote: > Simon Wood wrote: > >> I have been struggling for the past few days to get a Tascam US-122L >> (USB >> sound-card/midi interface) working, despite reading numerous forum >> postings I have only been able to get the midi portion working. > >

Re: ehci-dbg prints random memory (# CONFIG_DYNAMIC_DEBUG is not set)

On Wed, Apr 13, 2016 at 08:44:25AM +0200, Rafał Miłecki wrote: > Hi, > > I'm trying to debug some EHCI issue so I enabled debugging by adding > ccflags-y := -DDEBUG > to the drivers/usb/host/Makefile > > Some of debugging lines contain random memory, e.g.: > ehci-platform ehci-platform.0:

Re: [-next] BUG_ON in scsi_target_destroy()

On Mittwoch, 13. April 2016 23:47:04 CEST Sergey Senozhatsky wrote: > Hi, > > On (04/13/16 10:41), Johannes Thumshirn wrote: > > Hi Sergey, Xiong, > > > > Can you try below patch? > > it panics my system. > first it warn_on-s in lib/kobject.c:244 > > then NULL dereferences > do_scan_async >

Re: [PATCH V3] phy: bcm-ns-usb2: new driver for USB 2.0 PHY on Northstar

Hi, On Monday 11 April 2016 03:13 PM, Rafał Miłecki wrote: > Northstar is a family of SoCs used in home routers. They have USB 2.0 > and 3.0 controllers with PHYs that need to be properly initialized. > This driver provides PHY init support in a generic way and can be bound > with an EHCI

Re: [-next] BUG_ON in scsi_target_destroy()

Hi, On (04/13/16 10:41), Johannes Thumshirn wrote: > Hi Sergey, Xiong, > > Can you try below patch? it panics my system. first it warn_on-s in lib/kobject.c:244 then NULL dereferences do_scan_async __scsi_remove_device scsi_target_reap device_del dpm_sysfs_remove

Re: [PATCH v2 2/2] phy: phy-mt65xx-usb3: add support for mt2701 platform

Hi, On Monday 11 April 2016 01:11 PM, Chunfeng Yun wrote: > A new compatible string, "mediatek,mt2701-u3phy", is added. > > Some register settings to avoid RX sensitivity level degradation > which may arise on mt8173 platform are separated from other > platforms. > > Signed-off-by: Chunfeng Yun

Re: [PATCH v2 1/2] dt-bindings: phy-mt65xx-usb: add support for mt2701 platform

Hi, On Monday 11 April 2016 01:11 PM, Chunfeng Yun wrote: > A new compatible string, "mediatek,mt2701-u3phy", is added. how about changing the commit log to something like below? Add a new compatible string for "mt2701" Thanks Kishon > > Signed-off-by: Chunfeng Yun

Re: [PATCH v3 09/16] phy: da8xx-usb: new driver for DA8xx SoC USB PHY

Hi, On Friday 25 March 2016 05:21 AM, David Lechner wrote: > This is a new phy driver for the SoC USB controllers on the TI DA8xx > family of microcontrollers. The USB 1.1 PHY is just a simple on/off. > The USB 2.0 PHY also allows overriding the VBUS and ID pins. > > Signed-off-by: David Lechner

Re: [PATCH v2 1/2] dt-bindings: phy-mt65xx-usb: add support for mt2701 platform

On 11/04/16 09:41, Chunfeng Yun wrote: A new compatible string, "mediatek,mt2701-u3phy", is added. Signed-off-by: Chunfeng Yun --- .../devicetree/bindings/phy/phy-mt65xx-usb.txt |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Reviewed-by:

Re: Tascam US-122L - Corrupt USB descriptor

Simon Wood wrote: > I have been struggling for the past few days to get a Tascam US-122L (USB > sound-card/midi interface) working, despite reading numerous forum > postings I have only been able to get the midi portion working. Does it show up with "aplay -l"? > I note that the USB descriptor

Re: [-next] BUG_ON in scsi_target_destroy()

Hi Sergey, Xiong, Can you try below patch? On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote: > Hello, > > commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96 > Author: Johannes Thumshirn > Date: Tue Apr 5 11:50:44 2016 +0200 > > scsi: Add intermediate

Re: [PATCHv4 2/3] usb: storage: scsiglue: limit USB3 devices to 2048 sectors

Hi, Oliver Neukum writes: > On Wed, 2016-04-13 at 08:42 +0300, Felipe Balbi wrote: >> USB3 devices, because they are much newer, have much >> less chance of having issues with larger transfers. >> >> We still keep a limit because anything above 2048 >> sectors really rendered

Re: [PATCHv4 2/3] usb: storage: scsiglue: limit USB3 devices to 2048 sectors

On Wed, 2016-04-13 at 08:42 +0300, Felipe Balbi wrote: > USB3 devices, because they are much newer, have much > less chance of having issues with larger transfers. > > We still keep a limit because anything above 2048 > sectors really rendered negligible speed > improvements, so we will simply

[PATCH 1/1] doc: usb: chipidea: update the doc for OTG FSM

Since we have added otg version and HNP polling support, update related documentation. Signed-off-by: Peter Chen --- Documentation/usb/chipidea.txt | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/Documentation/usb/chipidea.txt

Tascam US-122L - Corrupt USB descriptor

Hi all, I have been struggling for the past few days to get a Tascam US-122L (USB sound-card/midi interface) working, despite reading numerous forum postings I have only been able to get the midi portion working. I note that the USB descriptor seems to be corrupt. It declares 2 interfaces, but

ehci-dbg prints random memory (# CONFIG_DYNAMIC_DEBUG is not set)

Hi, I'm trying to debug some EHCI issue so I enabled debugging by adding ccflags-y := -DDEBUG to the drivers/usb/host/Makefile Some of debugging lines contain random memory, e.g.: ehci-platform ehci-platform.0: .|��`|���5P5@�3�.��*�.|��o It's caused by dbg_status, dbg_cmd and dbg_port calling