Re: [PATCH/RFC 6/6] Treewide: Remove depends on HAS_DMA in case of platform dependency

ncy on HAS_DMA, as they are selected from > SND_SOC_APQ8016_SBC. > > Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> for drivers/usb/gadget/: Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com> -- balbi signature.asc Description: PGP signature

Re: [PATCH/RFC 6/6] Treewide: Remove depends on HAS_DMA in case of platform dependency

ncy on HAS_DMA, as they are selected from > SND_SOC_APQ8016_SBC. > > Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> for drivers/usb/gadget/: Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com> -- balbi signature.asc Description: PGP signature

Re: [PATCH/RFC 6/6] Treewide: Remove depends on HAS_DMA in case of platform dependency

cted from > SND_SOC_APQ8016_SBC. > > Signed-off-by: Geert Uytterhoeven for drivers/usb/gadget/: Acked-by: Felipe Balbi -- balbi signature.asc Description: PGP signature

Re: [PATCH/RFC 6/6] Treewide: Remove depends on HAS_DMA in case of platform dependency

ncy on HAS_DMA, as they are selected from > SND_SOC_APQ8016_SBC. > > Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> for drivers/usb/gadget/: Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com> -- balbi signature.asc Description: PGP signature

Re: [PATCH 01/14] usb: dwc2: Rename hibernation to partial_power_down

Grigor Tovmasyan writes: > From: Vardan Mikayelyan > > No-op change, only rename. > > This code was misnamed originally. It was only responsible for partial > power down and not for hibernation. > > Rename core_params->hibernation to

Re: [PATCH/RFC 6/6] Treewide: Remove depends on HAS_DMA in case of platform dependency

ncy on HAS_DMA, as they are selected from > SND_SOC_APQ8016_SBC. > > Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> for drivers/usb/gadget/: Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com> -- balbi signature.asc Description: PGP signature _

Re: [PATCH/RFC 3/6] usb: gadget: Add NO_DMA dummies for DMA mapping API

-by: Geert Uytterhoeven <ge...@linux-m68k.org> Should I take this or is it going with the rest of the series? If you wanna take it through Trivial or something like that: Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com> -- balbi signature.asc Description: PGP signature

Re: [PATCH/RFC 3/6] usb: gadget: Add NO_DMA dummies for DMA mapping API

-by: Geert Uytterhoeven <ge...@linux-m68k.org> Should I take this or is it going with the rest of the series? If you wanna take it through Trivial or something like that: Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com> -- balbi signature.asc Description: PGP signature

Re: [PATCH/RFC 3/6] usb: gadget: Add NO_DMA dummies for DMA mapping API

-by: Geert Uytterhoeven <ge...@linux-m68k.org> Should I take this or is it going with the rest of the series? If you wanna take it through Trivial or something like that: Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com> -- balbi signature.asc Description: PGP signature

Re: [PATCH/RFC 3/6] usb: gadget: Add NO_DMA dummies for DMA mapping API

hould I take this or is it going with the rest of the series? If you wanna take it through Trivial or something like that: Acked-by: Felipe Balbi -- balbi signature.asc Description: PGP signature

Re: [PATCH] usb: dwc2: Fix kernel doc's warnings.

Hi, Grigor Tovmasyan writes: > Added descriptions for all not described parameters. > > Signed-off-by: Grigor Tovmasyan Fails to apply: checking file drivers/usb/dwc2/core.c Hunk #2 succeeded at 390 with fuzz 2 (offset -11 lines). Hunk #3

Re: [PATCH] usb: dwc3: debugfs: Re-use DEFINE_SHOW_ATTRIBUTE() macro

Andy Shevchenko <andriy.shevche...@linux.intel.com> writes: > On Thu, 2018-02-15 at 13:16 +0200, Felipe Balbi wrote: >> ...instead of open coding file operations followed by custom ->open() >> callbacks per each attribute. >> > > Reviewed-by: Andy Shevchenk

Re: [PATCH 0/6] usb: dwc2: minor fixes

Felipe Balbi <ba...@kernel.org> writes: > Hi, > > Grigor Tovmasyan <grigor.tovmas...@synopsys.com> writes: >> This series contains patches which are already have been sent in >> "usb: dwc2: fixes, enhancements and new features" series. >> >>

Re: [PATCH 5/6] usb: dwc2: eliminate irq parameter from dwc2_gadget_init

Grigor Tovmasyan writes: > From: Vardan Mikayelyan > > The irq is available in hsotg already, so there's no need to pass it as > separate function parameter. > > Signed-off-by: Vardan Mikayelyan > Signed-off-by: Grigor

Re: [PATCH 0/6] usb: dwc2: minor fixes

Hi, Grigor Tovmasyan writes: > This series contains patches which are already have been sent in > "usb: dwc2: fixes, enhancements and new features" series. > > That patch series was too large, and based on community feedbacks decided to > split that series into

Re: [PATCH v2 02/49] usb: dwc2: Force mode optimizations

Grigor Tovmasyan writes: > From: Vardan Mikayelyan > > If the dr_mode is USB_DR_MODE_OTG, forcing the mode is needed during > driver probe to get the host and device specific HW parameters. Then we > clear the force mode bits so that the core

[PATCH] usb: dwc3: debugfs: Re-use DEFINE_SHOW_ATTRIBUTE() macro

...instead of open coding file operations followed by custom ->open() callbacks per each attribute. Signed-off-by: Felipe Balbi <felipe.ba...@linux.intel.com> --- drivers/usb/dwc3/debugfs.c | 79 -- 1 file changed, 34 insertions(+), 45

RE: UAC2 gadget not recognized on Windows 10

Hi, Robert Bielik writes: >> >> I guess UAC1 doesn't need feedback endpoints, right? Seems like that >> >> should be something specific to UAC2. At least for now. >> > >> > It seems like it is needed there aswell, see >> >

RE: UAC2 gadget not recognized on Windows 10

Hi, Robert Bielik writes: >> I guess UAC1 doesn't need feedback endpoints, right? Seems like that >> should be something specific to UAC2. At least for now. > > It seems like it is needed there aswell, see > http://www.usb.org/developers/docs/devclass_docs/audio10.pdf

RE: UAC2 gadget not recognized on Windows 10

Hi, Robert Bielik writes: >> >> Indeed, that's also mandated by USB spec. Seems like we need to patch >> >> f_uac2.c. Can you check if setting the IN endpoint as implicit feedback >> >> data is enough? >> > >> > Just tried your proposed patches on 4.15.1 (with an RPi

RE: UAC2 gadget not recognized on Windows 10

Hi, Robert Bielik writes: >> Indeed, that's also mandated by USB spec. Seems like we need to patch >> f_uac2.c. Can you check if setting the IN endpoint as implicit feedback >> data is enough? > > Just tried your proposed patches on 4.15.1 (with an RPi Zero) and with >

RE: UAC2 gadget not recognized on Windows 10

Hi, Robert Bielik writes: >> > It seems such a feedback endpoint is now required by the standard: >> > "The USB 2.0 specification states that if isochronous OUT data >> > endpoint uses the asynchronous synchronization, an isochronous >> > feedback endpoint is needed."

RE: UAC2 gadget not recognized on Windows 10

Hi, Robert Bielik writes: >> "Wait, never mind – I recognize that failing status code. usbaudio2.sys is >> complaining that you have an asynchronous data OUT endpoint but it can’t >> find a corresponding feedback endpoint." >> >> Unfortunately I have no idea what that

Re: [PATCH 2/2] usb: dwc3: drd: Fix lock-up on ID change during system suspend/resume

Hi, Roger Quadros writes: > Adding/removing host/gadget controller before .pm_complete() > causes a lock-up. Let's prevent any dual-role state change > between .pm_prepare() and .pm_complete() to fix this. > > Signed-off-by: Roger Quadros > --- >

Re: [PATCH 2/2] usb: dwc3: drd: Fix lock-up on ID change during system suspend/resume

Hi, Roger Quadros writes: > Adding/removing host/gadget controller before .pm_complete() > causes a lock-up. Let's prevent any dual-role state change > between .pm_prepare() and .pm_complete() to fix this. > > Signed-off-by: Roger Quadros > --- >

Re: [PATCH 2/2] usb: dwc3: drd: Fix lock-up on ID change during system suspend/resume

Hi, Roger Quadros writes: > Adding/removing host/gadget controller before .pm_complete() > causes a lock-up. Let's prevent any dual-role state change > between .pm_prepare() and .pm_complete() to fix this. > > Signed-off-by: Roger Quadros > --- > drivers/usb/dwc3/core.c | 31

Re: [PATCH 0/4] usb: gadget: fotg210-udc: Fixes and cleanup

Hi, Christophe JAILLET writes: > This serie aims to fix 2 issues. (path 2 & 4) > > The 2nd patch fixes a memory leak. It uses devm_ function a simplify the > handling of the memory. > > The 4th patch fixes a potential invalid pointer dereference. > > The 2 other

Re: [PATCH 0/4] usb: gadget: fotg210-udc: Fixes and cleanup

Hi, Christophe JAILLET writes: > This serie aims to fix 2 issues. (path 2 & 4) > > The 2nd patch fixes a memory leak. It uses devm_ function a simplify the > handling of the memory. > > The 4th patch fixes a potential invalid pointer dereference. > > The 2 other

Re: [PATCH 0/4] usb: gadget: fotg210-udc: Fixes and cleanup

Hi, Christophe JAILLET writes: > This serie aims to fix 2 issues. (path 2 & 4) > > The 2nd patch fixes a memory leak. It uses devm_ function a simplify the > handling of the memory. > > The 4th patch fixes a potential invalid pointer dereference. > > The 2 other ones, are just clean-ups to

Re: [PATCH v2] usb: dwc3: core: Fix ULPI PHYs and prevent phy_get/ulpi_init during suspend/resume

Roger Quadros writes: > In order for ULPI PHYs to work, dwc3_phy_setup() and dwc3_ulpi_init() > must be doene before dwc3_core_get_phy(). > > commit 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before > initializing phys") > broke this. > > The other issue is that

Re: [PATCH v2] usb: dwc3: core: Fix ULPI PHYs and prevent phy_get/ulpi_init during suspend/resume

Roger Quadros writes: > In order for ULPI PHYs to work, dwc3_phy_setup() and dwc3_ulpi_init() > must be doene before dwc3_core_get_phy(). > > commit 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before > initializing phys") > broke this. > > The other issue is that

Re: [PATCH v2] usb: dwc3: core: Fix ULPI PHYs and prevent phy_get/ulpi_init during suspend/resume

Roger Quadros writes: > In order for ULPI PHYs to work, dwc3_phy_setup() and dwc3_ulpi_init() > must be doene before dwc3_core_get_phy(). > > commit 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before > initializing phys") > broke this. > > The other issue is that

Re: Should debugfs be world-readable?

Hi, Greg Kroah-Hartman <gre...@linuxfoundation.org> writes: > On Wed, Feb 07, 2018 at 01:41:27PM +0200, Felipe Balbi wrote: >> >> Hi guys, >> >> I've been thinking about this for a while now. Should we allow debugfs >> files be world-readable? >

Should debugfs be world-readable?

Hi guys, I've been thinking about this for a while now. Should we allow debugfs files be world-readable? Many of these files expose addresses to kernel data. For example dwc3 dumps out the TRB ring of every endpoint: # cat dwc3.37.auto/ep1in/trb_ring

Re: usb drivers in userspace

Hi, Ran Shalit <ransha...@gmail.com> writes: > On Tue, Feb 6, 2018 at 1:35 PM, Felipe Balbi > <felipe.ba...@linux.intel.com> wrote: >> >> Hi, >> >> Ran Shalit <ransha...@gmail.com> writes: >>> Hello, >>> >>> Is it possibl

Re: usb drivers in userspace

Hi, Ran Shalit writes: > Hello, > > Is it possible to write a usb driver in userspace ? > I see that for peripheral/gadget, there is gadgetfs which can be used for > that. > > What about host drivers ? > Can we use for example vfio (seems to be used with pci so I'm not >

Re: Q: Does mass storage gadget use DMA ?

Hi, Ran Shalit writes: > Hello, > > I check code in: > https://elixir.free-electrons.com/linux/v3.3/source/drivers/usb/gadget/f_mass_storage.c > but I see no API usage of DMA, yet it is being mentioned as if it is used. but it is used. It's just managed by the UDC driver

Re: Q: Does mass storage gadget use DMA ?

Hi, Felipe Balbi <felipe.ba...@linux.intel.com> writes: >> I check code in: >> https://elixir.free-electrons.com/linux/v3.3/source/drivers/usb/gadget/f_mass_storage.c ps: v3.3 realy??? You really need to upgrade that :-) -- balbi -- To unsubscribe from this l

Re: [PATCH 2/3] usb: dwc3: of-simple: add support for shared and pulsed reset lines

Hi, Martin Blumenstingl writes: > Some SoCs (such as Amlogic Meson GXL for example) share the reset line > with other components (in case of the Meson GXL example there's a shared > reset line between the USB2 PHYs, USB3 PHYs and the dwc3 controller). >

Re: [PATCH 2/4] usb: dwc3: add dwc3 glue layer for UniPhier SoCs

Hi, Kunihiko Hayashi writes: > Hello Felipe, > > Thank you for your comments. > > On Tue, 23 Jan 2018 15:12:36 +0200 wrote: > >> >> Hi, >> >> Kunihiko Hayashi writes: >> > Add a specific glue layer for

Re: [PATCH 2/4] usb: dwc3: add dwc3 glue layer for UniPhier SoCs

Hi, Kunihiko Hayashi writes: > Hello Felipe, > > Thank you for your comments. > > On Tue, 23 Jan 2018 15:12:36 +0200 wrote: > >> >> Hi, >> >> Kunihiko Hayashi writes: >> > Add a specific glue layer for UniPhier SoC platform to support >> > USB host mode. It manages hardware operating

Re: [PATCH 2/4] usb: dwc3: add dwc3 glue layer for UniPhier SoCs

Hi, Kunihiko Hayashi writes: > Hello Felipe, > > Thank you for your comments. > > On Tue, 23 Jan 2018 15:12:36 +0200 wrote: > >> >> Hi, >> >> Kunihiko Hayashi writes: >> > Add a specific glue layer for

Re: [PATCH 2/4] usb: dwc3: add dwc3 glue layer for UniPhier SoCs

Hi, Kunihiko Hayashi writes: > Add a specific glue layer for UniPhier SoC platform to support > USB host mode. It manages hardware operating sequences to enable multiple > clock gates and assert resets, and to prepare to use dwc3 controller > on the SoC. > > This

Re: [PATCH 2/4] usb: dwc3: add dwc3 glue layer for UniPhier SoCs

Hi, Kunihiko Hayashi writes: > Add a specific glue layer for UniPhier SoC platform to support > USB host mode. It manages hardware operating sequences to enable multiple > clock gates and assert resets, and to prepare to use dwc3 controller > on the SoC. > > This patch also handles the physical

Re: [PATCH 2/4] usb: dwc3: add dwc3 glue layer for UniPhier SoCs

Hi, Kunihiko Hayashi writes: > Add a specific glue layer for UniPhier SoC platform to support > USB host mode. It manages hardware operating sequences to enable multiple > clock gates and assert resets, and to prepare to use dwc3 controller > on the SoC. > > This

Re: [PATCH 3/6] USB: move many drivers to use DEVICE_ATTR_WO

gt; but thanks to a script from Joe Perches, this was easily done. > > Reported-by: Joe Perches <j...@perches.com> > Cc: Peter Chen <peter.c...@nxp.com> > Cc: Felipe Balbi <ba...@kernel.org> > Cc: Johan Hovold <jo...@kernel.org> > Cc: Valentina Manea <v

Re: [PATCH 2/6] USB: move many drivers to use DEVICE_ATTR_RO

ly, > but thanks to a script from Joe Perches, this was easily done. > > Reported-by: Joe Perches <j...@perches.com> > Cc: Matthieu CASTET <castet.matth...@free.fr> > Cc: Stanislaw Gruszka <stf...@wp.pl> > Cc: Oliver Neukum <oneu...@suse.com> > Cc: Pet

Re: [PATCH 1/6] USB: move many drivers to use DEVICE_ATTR_RW

c: Alan Stern <st...@rowland.harvard.edu> > Cc: Mathias Nyman <mathias.ny...@intel.com> > Cc: Bin Liu <b-...@ti.com> > Cc: Felipe Balbi <ba...@kernel.org> > Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> for drivers/usb/phy: Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com> -- balbi signature.asc Description: PGP signature

Re: at91_udc Bug: USB gadget unplug not noticed by kernel

Hi, Ana Rodriguez Lopez writes: > Hello Felipe, > > I am not an expert on Linux Kernel but I have a problem with the USB > gadget and the origin seems to be there. > > I am working with Kernel 4.13.0 on Stamp 9G20 from Taskit GmbH (CPU: rather recent, kudos :-) >

Re: [PATCH] usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS

Hi, Lars-Peter Clausen writes: >> Lars-Peter Clausen writes: >>> Some UDC drivers (like the DWC3) expect that the response to a setup() >> >> not some, but *all*. You can only queue a response later IFF you return >> USB_GADGET_DELAYED_STATUS. > > Yeah, but

Re: [PATCH] usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS

Hi, Lars-Peter Clausen writes: > Some UDC drivers (like the DWC3) expect that the response to a setup() not some, but *all*. You can only queue a response later IFF you return USB_GADGET_DELAYED_STATUS. > request is queued from within the setup function itself so that it is >

Re: [PATCH v2 1/2] usb: dwc3: gadget: Set maxpacket size for ep0 IN

Hi, Thinh Nguyen <thinh.ngu...@synopsys.com> writes: > Hi, > > On 1/11/2018 12:16 AM, Felipe Balbi wrote: >> >> Hi, >> >> Thinh Nguyen <thinh.ngu...@synopsys.com> writes: >>> There are 2 control endpoint structures for DWC3. However,

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

Hi, Roger Quadros writes: >> Roger Quadros writes: >> -ret = dwc3_core_soft_reset(dwc); >> +ret = dwc3_core_get_phy(dwc); > > we can get_phy in dwc3_core_init() as it will get called on resume(). > This was the $subject of this

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

Hi, Roger Quadros writes: >> Roger Quadros writes: >> -ret = dwc3_core_soft_reset(dwc); >> +ret = dwc3_core_get_phy(dwc); > > we can get_phy in dwc3_core_init() as it will get called on resume(). > This was the $subject of this

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

Hi, Roger Quadros writes: >> Roger Quadros writes: >> -ret = dwc3_core_soft_reset(dwc); >> +ret = dwc3_core_get_phy(dwc); > > we can get_phy in dwc3_core_init() as it will get called on resume(). > This was the $subject of this patch. indeed.

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi, Roger Quadros writes: >>> In host mode runtime suspend/resume could happen very often with >>> device connected, and resetting h/w on every runtime_resume might not >>> be desired. And PHYs drivers can also support runtime_suspend which >>> would be preferred instead of

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi, Roger Quadros writes: >>> In host mode runtime suspend/resume could happen very often with >>> device connected, and resetting h/w on every runtime_resume might not >>> be desired. And PHYs drivers can also support runtime_suspend which >>> would be preferred instead of

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi, Roger Quadros writes: >>> In host mode runtime suspend/resume could happen very often with >>> device connected, and resetting h/w on every runtime_resume might not >>> be desired. And PHYs drivers can also support runtime_suspend which >>> would be preferred instead of shutting down phy.

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi, Manu Gautam writes: On 27/09/17 14:19, Manu Gautam wrote: > Driver powers-off PHYs and reinitializes DWC3 core and gadget on > resume. While this works fine for gadget mode but in host > mode there is not re-initialization of host stack. Also,

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi, Manu Gautam writes: On 27/09/17 14:19, Manu Gautam wrote: > Driver powers-off PHYs and reinitializes DWC3 core and gadget on > resume. While this works fine for gadget mode but in host > mode there is not re-initialization of host stack. Also,

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi, Manu Gautam writes: On 27/09/17 14:19, Manu Gautam wrote: > Driver powers-off PHYs and reinitializes DWC3 core and gadget on > resume. While this works fine for gadget mode but in host > mode there is not re-initialization of host stack. Also, resetting > bus as part of

Re: [PATCH 10/15] usb: dwc3: gadget: Set maxpacket size for ep0 IN

Hi, Thinh Nguyen writes: > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c > index bdf2a2014ebd..6ae924d95cbc 100644 > --- a/drivers/usb/dwc3/gadget.c > +++ b/drivers/usb/dwc3/gadget.c > @@ -2751,6 +2751,8 @@ static void

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

Hi, Roger Quadros writes: - ret = dwc3_core_soft_reset(dwc); + ret = dwc3_core_get_phy(dwc); >>> >>> we can get_phy in dwc3_core_init() as it will get called on resume(). >>> This was the $subject of this patch. >> >> indeed. thanks :-) >> > > oops sorry. I meant we

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

Hi, Roger Quadros writes: - ret = dwc3_core_soft_reset(dwc); + ret = dwc3_core_get_phy(dwc); >>> >>> we can get_phy in dwc3_core_init() as it will get called on resume(). >>> This was the $subject of this patch. >> >> indeed. thanks :-) >> > > oops sorry. I meant we can't call

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

Hi, Roger Quadros writes: - ret = dwc3_core_soft_reset(dwc); + ret = dwc3_core_get_phy(dwc); >>> >>> we can get_phy in dwc3_core_init() as it will get called on resume(). >>> This was the $subject of this patch. >> >> indeed. thanks :-) >> > > oops sorry. I meant we

Re: [PATCH v2 1/2] usb: dwc3: gadget: Set maxpacket size for ep0 IN

Hi, Thinh Nguyen writes: > There are 2 control endpoint structures for DWC3. However, the driver > only updates the OUT direction control endpoint structure during > ConnectDone event. DWC3 driver needs to update the endpoint max packet > size for control IN endpoint

Re: [PATCH v2 2/2] usb: dwc3: ep0: Reset TRB counter for ep0 IN

Hi, Thinh Nguyen writes: > In control read transfer completion handler, the driver needs to reset > the TRB enqueue counter. Since there is one control endpoint structure > for each direction, we must also track the TRB enqueue counter for each > direction. Currently

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi, Manu Gautam writes: >> On 27/09/17 14:19, Manu Gautam wrote: >>> Driver powers-off PHYs and reinitializes DWC3 core and gadget on >>> resume. While this works fine for gadget mode but in host >>> mode there is not re-initialization of host stack. Also, resetting >>>

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi, Manu Gautam writes: >> On 27/09/17 14:19, Manu Gautam wrote: >>> Driver powers-off PHYs and reinitializes DWC3 core and gadget on >>> resume. While this works fine for gadget mode but in host >>> mode there is not re-initialization of host stack. Also, resetting >>>

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi, Manu Gautam writes: >> On 27/09/17 14:19, Manu Gautam wrote: >>> Driver powers-off PHYs and reinitializes DWC3 core and gadget on >>> resume. While this works fine for gadget mode but in host >>> mode there is not re-initialization of host stack. Also, resetting >>> bus as part of

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

Hi, Roger Quadros writes: >> Roger Quadros writes: >>> Felipe, >>> >>> On 10/01/18 15:11, Roger Quadros wrote: The USB PHYs should be requested only once during the life cycle of this driver. As dwc3_core_init() is called during system

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

Hi, Roger Quadros writes: >> Roger Quadros writes: >>> Felipe, >>> >>> On 10/01/18 15:11, Roger Quadros wrote: The USB PHYs should be requested only once during the life cycle of this driver. As dwc3_core_init() is called during system

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

Hi, Roger Quadros writes: >> Roger Quadros writes: >>> Felipe, >>> >>> On 10/01/18 15:11, Roger Quadros wrote: The USB PHYs should be requested only once during the life cycle of this driver. As dwc3_core_init() is called during system suspend/resume it will result in

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

Hi, Roger Quadros writes: > Felipe, > > On 10/01/18 15:11, Roger Quadros wrote: >> The USB PHYs should be requested only once during the life cycle of >> this driver. >> >> As dwc3_core_init() is called during system suspend/resume >> it will result in multiple calls to

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

Hi, Roger Quadros writes: > Felipe, > > On 10/01/18 15:11, Roger Quadros wrote: >> The USB PHYs should be requested only once during the life cycle of >> this driver. >> >> As dwc3_core_init() is called during system suspend/resume >> it will result in multiple calls to

Re: [PATCH] usb: dwc3: core: Don't try to get PHYs during suspend/resume

Hi, Roger Quadros writes: > Felipe, > > On 10/01/18 15:11, Roger Quadros wrote: >> The USB PHYs should be requested only once during the life cycle of >> this driver. >> >> As dwc3_core_init() is called during system suspend/resume >> it will result in multiple calls to dwc3_core_get_phy()

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi, Roger Quadros writes: > Hi Manu, > > On 27/09/17 14:19, Manu Gautam wrote: >> Driver powers-off PHYs and reinitializes DWC3 core and gadget on >> resume. While this works fine for gadget mode but in host >> mode there is not re-initialization of host stack. Also, resetting >>

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi, Roger Quadros writes: > Hi Manu, > > On 27/09/17 14:19, Manu Gautam wrote: >> Driver powers-off PHYs and reinitializes DWC3 core and gadget on >> resume. While this works fine for gadget mode but in host >> mode there is not re-initialization of host stack. Also, resetting >>

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi, Roger Quadros writes: > Hi Manu, > > On 27/09/17 14:19, Manu Gautam wrote: >> Driver powers-off PHYs and reinitializes DWC3 core and gadget on >> resume. While this works fine for gadget mode but in host >> mode there is not re-initialization of host stack. Also, resetting >> bus as part of

Re: [usb_add_gadget_udc_release] BUG: KASAN: double-free or invalid-free in (null)

e7: >> slab_free at mm/slub.c:2973 >> (inlined by) kfree at >> mm/slub.c:3899 >> [ 38.605034] usb_add_gadget_udc_release+0x693/0x6ca: >>

Re: [usb_add_gadget_udc_release] BUG: KASAN: double-free or invalid-free in (null)

slab_free at mm/slub.c:2973 >> (inlined by) kfree at >> mm/slub.c:3899 >> [ 38.605034] usb_add_gadget_udc_release+0x693/0x6ca: >> usb_a

Re: [usb_add_gadget_udc_release] BUG: KASAN: double-free or invalid-free in (null)

e7: >> slab_free at mm/slub.c:2973 >> (inlined by) kfree at >> mm/slub.c:3899 >> [ 38.605034] usb_add_gadget_udc_release+0x693/0x6ca: >>

Re: [GIT PULL] USB: changes for v4.16 merge window

Hi, Alan Stern <st...@rowland.harvard.edu> writes: > On Mon, 8 Jan 2018, Felipe Balbi wrote: > >> >> Hi Greg, >> >> Here are my changes for this merge window. Let me know if you want >> anything to be changed. >> >> Patches have

Re: [PATCH 14/15] usb: dwc3: Add disabling of start_transfer failure quirk

Hi, Rob Herring writes: > On Fri, Jan 05, 2018 at 12:16:02PM -0800, Thinh Nguyen wrote: >> In DWC_usb31 version 1.70a-ea06 and prior needs a SW workaround for isoc >> START TRANSFER command failure. However, some affected versions may have >> RTL patches to fix this without a

Re: [PATCH 10/15] usb: dwc3: gadget: Set maxpacket size for ep0 IN

Hi, Thinh Nguyen <thinh.ngu...@synopsys.com> writes: > Hi, > > On 1/8/2018 4:06 AM, Felipe Balbi wrote: >> >> Hi, >> >> Thinh Nguyen <thinh.ngu...@synopsys.com> writes: >>> There are 2 control endpoint structures for DWC3. However, the driv

Re: [PATCH 12/15] usb: dwc3: Dump LSP and BMU debug info

Hi, Thinh Nguyen writes: > Dump LSP and BMU debug info. > > Signed-off-by: Thinh Nguyen > --- > drivers/usb/dwc3/core.h| 5 + > drivers/usb/dwc3/debugfs.c | 5 + > 2 files changed, 10 insertions(+) > > diff --git

Re: [PATCH 10/15] usb: dwc3: gadget: Set maxpacket size for ep0 IN

Hi, Thinh Nguyen writes: > There are 2 control endpoint structures for DWC3. However, the driver > only updates the OUT direction control endpoint structure during > ConnectDone event. DWC3 driver needs to update the endpoint max packet > size for control IN endpoint

Re: [PATCH 09/15] usb: dwc3: Check for ESS TX/RX threshold config

Hi, Thinh Nguyen writes: > Check and configure TX/RX threshold for DWC_usb31. Update dwc3 structure > with new variables to store these threshold configurations. couldn't we calculate these in runtime? Then we wouldn't need new Device Properties. -- balbi

Re: [PATCH 03/15] usb: dwc3: Update DWC_usb31 GTXFIFOSIZ reg fields

Hi, Thinh Nguyen writes: > Update two GTXFIFOSIZ bit fields for the DWC_usb31 controller. TXFDEP > is a 15-bit value instead of 16-bit value, and bit 15 is TXFRAMNUM. > > The GTXFIFOSIZ register for DWC_usb31 is as follows: >

Re: [PATCH 01/15] usb: dwc3: Device SoftReset PHY synchonization delay

Hi, Thinh Nguyen writes: > From DWC_usb31 databook section 1.3.2, once DWC3_DCTL_CSFTRST bit is > cleared, we must wait at least 50ms before accessing the PHY domain > (synchronization delay). > > Signed-off-by: Thinh Nguyen > --- >

Re: [PATCH] usb: gadget: uvc:change the UVC_NUM_REQUESTS value

QUESTS 8 if you want to be taken seriously, the bare minimum you can do is to use scripts/get_maintainer.pl to help with a proper Cc list: $ scripts/get_maintainer.pl -f drivers/usb/gadget/function/uvc.h Laurent Pinchart <laurent.pinch...@ideasonboard.com> (maintainer:USB WEBCAM GA

Re: [PATCH] usb: gadget: uvc:change the UVC_NUM_REQUESTS value

QUESTS 8 if you want to be taken seriously, the bare minimum you can do is to use scripts/get_maintainer.pl to help with a proper Cc list: $ scripts/get_maintainer.pl -f drivers/usb/gadget/function/uvc.h Laurent Pinchart <laurent.pinch...@ideasonboard.com> (maintainer:USB WEBCAM GA

Re: [PATCH] usb: gadget: uvc:change the UVC_NUM_REQUESTS value

the bare minimum you can do is to use scripts/get_maintainer.pl to help with a proper Cc list: $ scripts/get_maintainer.pl -f drivers/usb/gadget/function/uvc.h Laurent Pinchart (maintainer:USB WEBCAM GADGET) Felipe Balbi (maintainer:USB GADGET/PERIPHERAL SUBSYSTEM) Greg Kroah-Hartman (supporter

Re: [PATCH] usb: dwc3: gadget: decrease the queued_requests in removal

Hi, Lipengcheng writes: > In removal requests, it is necessary to make the corresponding trb > disable state (HWO = 1) and dep->queued_requests a corresponding reduction. > It is better to use a alone funtion to disable trb (HWO = 0). this shouldn't be necessary. What

Re: [PATCH] usb: dwc3: gadget: decrease the queued_requests in removal

Hi, Lipengcheng writes: > In removal requests, it is necessary to make the corresponding trb > disable state (HWO = 1) and dep->queued_requests a corresponding reduction. > It is better to use a alone funtion to disable trb (HWO = 0). this shouldn't be necessary. What

Re: [PATCH] usb: dwc3: gadget: decrease the queued_requests in removal

Hi, Lipengcheng writes: > In removal requests, it is necessary to make the corresponding trb > disable state (HWO = 1) and dep->queued_requests a corresponding reduction. > It is better to use a alone funtion to disable trb (HWO = 0). this shouldn't be necessary. What problem are you facing?

RE: [PATCH] usb: dwc3: gadget:Core consumes a trb software to fill a trb, in ISO

Hi, Lipengcheng writes: >> Lipengcheng writes: >> >> > Iso transmission, the current process is that all trb(HWO=1) is handled. >> > Then core generate DWC3_DEPEVT_XFERNOTREADY event, Software begin >> > refill trb, this will produce 0 length

RE: [PATCH] usb: dwc3: gadget:Core consumes a trb software to fill a trb, in ISO

Hi, Lipengcheng writes: >> Lipengcheng writes: >> >> > Iso transmission, the current process is that all trb(HWO=1) is handled. >> > Then core generate DWC3_DEPEVT_XFERNOTREADY event, Software begin >> > refill trb, this will produce 0 length

RE: [PATCH] usb: dwc3: gadget:Core consumes a trb software to fill a trb, in ISO

Hi, Lipengcheng writes: >> Lipengcheng writes: >> >> > Iso transmission, the current process is that all trb(HWO=1) is handled. >> > Then core generate DWC3_DEPEVT_XFERNOTREADY event, Software begin >> > refill trb, this will produce 0 length package, the patch is to >> > achieve the core

[GIT PULL] USB: changes for v4.16 merge window

host: Don't retry NAKed transactions right away Felipe Balbi (3): usb: dwc3: debug: decode a few more features usb: gadget: add isoch_delay member usb: dwc3: ep0: use gadget->isoch_delay for isoch_delay value Lu Baolu (1): usb: gadget: u_serial: Use kfifo instead of homema

<    4   5   6   7   8   9   10   11   12   13   >