Re: [PATCH v3 1/3] usb: udc: allow adding and removing the same gadget device

Hi, Alan Stern writes: > On Mon, 3 Apr 2017, Roger Quadros wrote: > >> allow usb_del_gadget_udc() and usb add_gadget_udc() to be called >> repeatedly on the same gadget->dev structure. >> >> We need to clear the gadget->dev structure so that kobject_init() >> doesn't complain about already

Re: [PATCH 2/2] usb: misc: refactor code

Hi, "Gustavo A. R. Silva" writes: > Code refactoring to make the flow easier to follow. > > Cc: Alan Stern > Cc: Greg Kroah-Hartman > Signed-off-by: Gustavo A. R. Silva > --- >

Re: [PATCH 2/2] usb: misc: refactor code

Hi, "Gustavo A. R. Silva" writes: > Code refactoring to make the flow easier to follow. > > Cc: Alan Stern > Cc: Greg Kroah-Hartman > Signed-off-by: Gustavo A. R. Silva > --- > drivers/usb/misc/usbtest.c | 67 > +- > 1 file changed, 30

Re: dwc2_hc_chhltd_intr_dma - ChHltd set errors?

Hi, Minas Harutyunyan writes: >> We've noticed that when using usb ethernet adapters on HiKey, we >> occasionally see errors like: >> >> dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 0 - ChHltd set, >> but reason is unknown >> dwc2

Re: dwc2_hc_chhltd_intr_dma - ChHltd set errors?

Hi, Minas Harutyunyan writes: >> We've noticed that when using usb ethernet adapters on HiKey, we >> occasionally see errors like: >> >> dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 0 - ChHltd set, >> but reason is unknown >> dwc2 f72c.usb: hcint 0x0002,

Re: [PATCH] dwc2: gadget: Fix in control write transfers

Hi, Minas Harutyunyan writes: >> Minas Harutyunyan writes: >>> After data out stage gadget driver should not initate ZLP on control EP, >>> because it is up to function driver. >> >> not true always, depends on return value from

Re: [PATCH] dwc2: gadget: Fix in control write transfers

Hi, Minas Harutyunyan writes: >> Minas Harutyunyan writes: >>> After data out stage gadget driver should not initate ZLP on control EP, >>> because it is up to function driver. >> >> not true always, depends on return value from ->setup(). Which problem >> did you have? Which gadget driver?

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

Hi, Roger Quadros <rog...@ti.com> writes: > On 31/03/17 15:00, Felipe Balbi wrote: >> >> Hi, >> >> Roger Quadros <rog...@ti.com> writes: >>>>>> Your first implementation could be just that. Refactoring what needs to >>&g

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

Hi, Roger Quadros writes: > On 31/03/17 15:00, Felipe Balbi wrote: >> >> Hi, >> >> Roger Quadros writes: >>>>>> Your first implementation could be just that. Refactoring what needs to >>>>>> be refactored, then patching &quo

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

Hi, Roger Quadros writes: Your first implementation could be just that. Refactoring what needs to be refactored, then patching "mode" debugfs to work properly in that case. Only add otg.c/drd.c after "mode" debugfs file is stable, because then you know what

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

Hi, Roger Quadros writes: Your first implementation could be just that. Refactoring what needs to be refactored, then patching "mode" debugfs to work properly in that case. Only add otg.c/drd.c after "mode" debugfs file is stable, because then you know what needs to be taken

Re: [PATCH v3 2/7] UDC: Rename amd5536udc driver file based on IP

Hi, Raviteja Garimella writes: > This patch renames the amd5536udc.c that has the core driver > functionality of Synopsys UDC to snps_udc_core.c > > The symbols exported here can be used by any UDC driver that uses > the same Synopsys IP. > > Signed-off-by:

Re: [PATCH v3 2/7] UDC: Rename amd5536udc driver file based on IP

Hi, Raviteja Garimella writes: > This patch renames the amd5536udc.c that has the core driver > functionality of Synopsys UDC to snps_udc_core.c > > The symbols exported here can be used by any UDC driver that uses > the same Synopsys IP. > > Signed-off-by: Raviteja Garimella unfortunately,

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

Hi, Roger Quadros writes: Roger Quadros writes: > dra7 OTG core limits the host controller to USB2.0 (high-speed) mode > when we're operating in dual-role. yeah, that's not a quirk. DRA7 supports OTGv2, not OTGv3. There was no USB3 when

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

Hi, Roger Quadros writes: Roger Quadros writes: > dra7 OTG core limits the host controller to USB2.0 (high-speed) mode > when we're operating in dual-role. yeah, that's not a quirk. DRA7 supports OTGv2, not OTGv3. There was no USB3 when OTGv2 was written.

Re: [PATCH] dwc2: gadget: Fix in control write transfers

Hi, Minas Harutyunyan writes: > After data out stage gadget driver should not initate ZLP on control EP, > because it is up to function driver. not true always, depends on return value from ->setup(). Which problem did you have? Which gadget driver? How did you

Re: [PATCH] dwc2: gadget: Fix in control write transfers

Hi, Minas Harutyunyan writes: > After data out stage gadget driver should not initate ZLP on control EP, > because it is up to function driver. not true always, depends on return value from ->setup(). Which problem did you have? Which gadget driver? How did you reproduce? Which other tests did

Re: [PATCH linux-next v2 3/4] usb: gadget: udc: atmel: Use dev_warn() to display EP configuration error

Hi, cristian.bir...@microchip.com writes: > From: Cristian Birsan > > Use dev_warn() to display EP configuration error to avoid silent failure. > > Signed-off-by: Cristian Birsan > --- > drivers/usb/gadget/udc/atmel_usba_udc.c | 6

Re: [PATCH linux-next v2 3/4] usb: gadget: udc: atmel: Use dev_warn() to display EP configuration error

Hi, cristian.bir...@microchip.com writes: > From: Cristian Birsan > > Use dev_warn() to display EP configuration error to avoid silent failure. > > Signed-off-by: Cristian Birsan > --- > drivers/usb/gadget/udc/atmel_usba_udc.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > >

Re: [PATCH linux-next v2 1/4] usb: gadget: udc: atmel: Check fifo configuration values against device tree

Hi, cristian.bir...@microchip.com writes: > From: Cristian Birsan > > Check fifo configuration values against device tree values for endpoint fifo > in auto configuration mode (fifo_mode=0). > > Signed-off-by: Cristian Birsan > ---

Re: [PATCH linux-next v2 1/4] usb: gadget: udc: atmel: Check fifo configuration values against device tree

Hi, cristian.bir...@microchip.com writes: > From: Cristian Birsan > > Check fifo configuration values against device tree values for endpoint fifo > in auto configuration mode (fifo_mode=0). > > Signed-off-by: Cristian Birsan > --- > drivers/usb/gadget/udc/atmel_usba_udc.c | 24

Re: [PATCH v3 1/2] usb: dwc3: use BIT() macro where possible

Hi, Roger Quadros writes: > To avoid checkpatch warnings with new patches let's > start using the BIT() macro wherever possible. > > Signed-off-by: Roger Quadros this didn't apply cleanly, I have manually applied it since it was so simple. Please make sure

Re: [PATCH v3 1/2] usb: dwc3: use BIT() macro where possible

Hi, Roger Quadros writes: > To avoid checkpatch warnings with new patches let's > start using the BIT() macro wherever possible. > > Signed-off-by: Roger Quadros this didn't apply cleanly, I have manually applied it since it was so simple. Please make sure testing/next looks good (I'll push

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

Hi, Roger Quadros writes: >>> 3) All this becomes even more complex for configfs based gadget driver. >>> >>> So using stop/start gadget is a much simpler solution really as UDC software >>> side of things remain unchanged and the gadget driver can persist between >>> role

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

Hi, Roger Quadros writes: >>> 3) All this becomes even more complex for configfs based gadget driver. >>> >>> So using stop/start gadget is a much simpler solution really as UDC software >>> side of things remain unchanged and the gadget driver can persist between >>> role switches. >> >> I

Re: [PATCH v2 3/4] usb: dwc3: add dual-role support

Hi Roger Quadros writes: For something that simple, we wouldn't even need to use OTG FSM layer because that brings no benefit for such a simple requirement. >>> >>> no no. I think you got it wrong. I'm not using the OTG FSM layer at all :). >> >> what are all the

Re: [PATCH v2 3/4] usb: dwc3: add dual-role support

Hi Roger Quadros writes: For something that simple, we wouldn't even need to use OTG FSM layer because that brings no benefit for such a simple requirement. >>> >>> no no. I think you got it wrong. I'm not using the OTG FSM layer at all :). >> >> what are all the otg_fsm mentions

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

Hi, Roger Quadros writes: >> Roger Quadros writes: Roger Quadros writes: > dra7 OTG core limits the host controller to USB2.0 (high-speed) mode > when we're operating in dual-role. yeah, that's not a quirk. DRA7 supports

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

Hi, Roger Quadros writes: >> Roger Quadros writes: Roger Quadros writes: > dra7 OTG core limits the host controller to USB2.0 (high-speed) mode > when we're operating in dual-role. yeah, that's not a quirk. DRA7 supports OTGv2, not OTGv3. There was no USB3 when

Re: [PATCH v2 3/4] usb: dwc3: add dual-role support

Hi, Roger Quadros writes: >>> @@ -839,6 +841,505 @@ static int dwc3_core_get_phy(struct dwc3 *dwc) >>> return 0; >>> } >>> >>> +static int dwc3_drd_start_host(struct dwc3 *dwc, int on, bool skip); >>> +static int dwc3_drd_start_gadget(struct dwc3 *dwc, int on); >>> + >>>

Re: [PATCH v2 3/4] usb: dwc3: add dual-role support

Hi, Roger Quadros writes: >>> @@ -839,6 +841,505 @@ static int dwc3_core_get_phy(struct dwc3 *dwc) >>> return 0; >>> } >>> >>> +static int dwc3_drd_start_host(struct dwc3 *dwc, int on, bool skip); >>> +static int dwc3_drd_start_gadget(struct dwc3 *dwc, int on); >>> + >>> +/* dwc->lock

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

Hi, Roger Quadros writes: >> Roger Quadros writes: >>> dra7 OTG core limits the host controller to USB2.0 (high-speed) mode >>> when we're operating in dual-role. >> >> yeah, that's not a quirk. DRA7 supports OTGv2, not OTGv3. There was no >> USB3 when OTGv2 was

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

Hi, Roger Quadros writes: >> Roger Quadros writes: >>> dra7 OTG core limits the host controller to USB2.0 (high-speed) mode >>> when we're operating in dual-role. >> >> yeah, that's not a quirk. DRA7 supports OTGv2, not OTGv3. There was no >> USB3 when OTGv2 was written. >> >> DRA7 just

Re: [PATCH v2] usb: phy: isp1301: Add OF device ID table

Hi, Javier Martinez Canillas writes: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that

Re: [PATCH v2] usb: phy: isp1301: Add OF device ID table

Hi, Javier Martinez Canillas writes: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the MODALIAS reported

Re: [PATCH v2 2/2] usb: dwc2: add multiple clocks handling

Hi, Heiko Stübner writes: > Am Donnerstag, 9. Februar 2017, 10:44:39 CET schrieb Frank Wang: >> Since dwc2 may have one or more input clocks need to manage for some >> platform, so this adds change clk to clk's array of struct dwc2_hsotg >> to handle more clocks operation. >>

Re: [PATCH v2 2/2] usb: dwc2: add multiple clocks handling

Hi, Heiko Stübner writes: > Am Donnerstag, 9. Februar 2017, 10:44:39 CET schrieb Frank Wang: >> Since dwc2 may have one or more input clocks need to manage for some >> platform, so this adds change clk to clk's array of struct dwc2_hsotg >> to handle more clocks operation. >> >> Signed-off-by:

Re: [PATCH v3 2/2] usb: gadget: reword configuration choices

Hi, Randy Dunlap writes: >> @@ -477,6 +477,12 @@ choice >>not be able work with that controller, or might need to implement >>a less common variant of a device class protocol. >> >> + The available choices each represent a single precomposed USB >>

Re: [PATCH v3 2/2] usb: gadget: reword configuration choices

Hi, Randy Dunlap writes: >> @@ -477,6 +477,12 @@ choice >>not be able work with that controller, or might need to implement >>a less common variant of a device class protocol. >> >> + The available choices each represent a single precomposed USB >> + gadget

Re: [PATCH v2 2/2] usb: phy: phy-qcom-8x16-usb: Remove redundant extcon register/unregister

Hi, Baolin Wang writes: > Since usb phy core has added common code to register or unregister > extcon device, then phy-qcom-8x16-usb driver does not need its own > code to register/unregister extcon device, then remove them. > > Signed-off-by: Baolin Wang

Re: [PATCH v2 2/2] usb: phy: phy-qcom-8x16-usb: Remove redundant extcon register/unregister

Hi, Baolin Wang writes: > Since usb phy core has added common code to register or unregister > extcon device, then phy-qcom-8x16-usb driver does not need its own > code to register/unregister extcon device, then remove them. > > Signed-off-by: Baolin Wang so previous patch helped *ONE* single

Re: [PATCH v2 1/2] usb: phy: Introduce one extcon device into usb phy

Hi, Baolin Wang writes: > Usually usb phy need register one extcon device to get the connection > notifications. It will remove some duplicate code if the extcon device > is registered using common code instead of each phy driver having its > own related extcon APIs. So

Re: [PATCH v2 1/2] usb: phy: Introduce one extcon device into usb phy

Hi, Baolin Wang writes: > Usually usb phy need register one extcon device to get the connection > notifications. It will remove some duplicate code if the extcon device > is registered using common code instead of each phy driver having its > own related extcon APIs. So we add one pointer of

Re: [PATCH] usb: gadget: pch_udc: don't update td->next after it has been released to the pool

20ce Author: Gustavo A. R. Silva <garsi...@embeddedor.com> AuthorDate: Fri Mar 10 15:39:32 2017 -0600 Commit: Felipe Balbi <felipe.ba...@linux.intel.com> CommitDate: Wed Mar 22 11:21:10 2017 +0200 usb: gadget: udc: remove pointer dereference after free Remove pointer derefer

Re: [PATCH] usb: gadget: pch_udc: don't update td->next after it has been released to the pool

dma_addr_t)td->next; > dma_pool_free(dev->data_requests, td, addr); > - td->next = 0x00; I already have a patch for this, thanks 1f459262b0e1649a1e5ad12fa4c66eb76c2220ce Author: Gustavo A. R. Silva AuthorDate: Fri Mar 10 15:39:32 2017 -0600 Commit:

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

Hi, Roger Quadros writes: > dra7 OTG core limits the host controller to USB2.0 (high-speed) mode > when we're operating in dual-role. yeah, that's not a quirk. DRA7 supports OTGv2, not OTGv3. There was no USB3 when OTGv2 was written. DRA7 just shouldn't use OTG core altogether.

Re: [PATCH v2 4/4] usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode

Hi, Roger Quadros writes: > dra7 OTG core limits the host controller to USB2.0 (high-speed) mode > when we're operating in dual-role. yeah, that's not a quirk. DRA7 supports OTGv2, not OTGv3. There was no USB3 when OTGv2 was written. DRA7 just shouldn't use OTG core altogether. In fact, this

Re: [PATCH v2 3/4] usb: dwc3: add dual-role support

Hi, Roger Quadros writes: > If dr_mode is "otg" then support dual role mode of operation. > > Get ID and VBUS information from the OTG controller > and put the controller in the appropriate state. > > This is our dual-role state table. > > IDVBUSdual-role state > --

Re: [PATCH v2 3/4] usb: dwc3: add dual-role support

Hi, Roger Quadros writes: > If dr_mode is "otg" then support dual role mode of operation. > > Get ID and VBUS information from the OTG controller > and put the controller in the appropriate state. > > This is our dual-role state table. > > IDVBUSdual-role state > --

Re: [PATCH v2 0/4] usb: dwc3: dual-role support

Roger Quadros writes: > Hi, > > We rely on the OTG controller block or Extcon to provide us with > VBUS and ID line status via an interrupt. > > This is then used to switch the controller between host, peripheral > and idle roles based on the following table. > > ID VBUS

Re: [PATCH v2 0/4] usb: dwc3: dual-role support

Roger Quadros writes: > Hi, > > We rely on the OTG controller block or Extcon to provide us with > VBUS and ID line status via an interrupt. > > This is then used to switch the controller between host, peripheral > and idle roles based on the following table. > > ID VBUSdual-role state

Re: [PATCH 2/7] usb: dwc3: dwc3-omap: fix dwc3_omap_probe() do put_sync when get_sync works

Hi, Shuah Khan writes: > dwc3_omap_probe() does pm_runtime_put_sync() in its err1 handling when > pm_runtime_get_sync() fails. Fix it to do put_sync only when get_sync > succeeds. > > Signed-off-by: Shuah Khan sorry, not taking any of these

Re: [PATCH 2/7] usb: dwc3: dwc3-omap: fix dwc3_omap_probe() do put_sync when get_sync works

Hi, Shuah Khan writes: > dwc3_omap_probe() does pm_runtime_put_sync() in its err1 handling when > pm_runtime_get_sync() fails. Fix it to do put_sync only when get_sync > succeeds. > > Signed-off-by: Shuah Khan sorry, not taking any of these pointless patches. There's nothing wrong with the

Re: [PATCH 1/7] usb: dwc3: core: fix dwc3_probe() to not do put_sync when get_sync fails

Hi, Shuah Khan writes: > dwc3_probe() does pm_runtime_put_sync() in its err1 handling when > pm_runtime_get_sync() fails. Move the pm_runtime_put_sync() under > err2 instead as it is used in error paths after pm_runtime_get_sync() > succeeds. there's nothing wrong

Re: [PATCH 1/7] usb: dwc3: core: fix dwc3_probe() to not do put_sync when get_sync fails

Hi, Shuah Khan writes: > dwc3_probe() does pm_runtime_put_sync() in its err1 handling when > pm_runtime_get_sync() fails. Move the pm_runtime_put_sync() under > err2 instead as it is used in error paths after pm_runtime_get_sync() > succeeds. there's nothing wrong with current code. Read the

Re: [PATCH 0/7] dwc3 - bug fixes and use meaningful goto labels

Hi, Shuah Khan writes: > This patch series consists of two fixes and changes to goto labels we *NEVER* put cleanups and fixes together. > to use meaningful names. > > While working on goto label changes, I noticed put_sync calls without > successful get_sync in error

Re: [PATCH 0/7] dwc3 - bug fixes and use meaningful goto labels

Hi, Shuah Khan writes: > This patch series consists of two fixes and changes to goto labels we *NEVER* put cleanups and fixes together. > to use meaningful names. > > While working on goto label changes, I noticed put_sync calls without > successful get_sync in error legs. The first two

Re: [PATCH] usb: gadget: Correct usb EP argument for BOT status request

_uas *fu) >> usb_ep_free_request(fu->ep_in, fu->bot_req_in); >> usb_ep_free_request(fu->ep_out, fu->bot_req_out); >> usb_ep_free_request(fu->ep_out, fu->cmd.req); >> -usb_ep_free_request(fu->ep_out, fu->bot_status.req); >> +usb_ep_free_request(fu-&

Re: [PATCH] usb: gadget: Correct usb EP argument for BOT status request

ot_req_in); >> usb_ep_free_request(fu->ep_out, fu->bot_req_out); >> usb_ep_free_request(fu->ep_out, fu->cmd.req); >> -usb_ep_free_request(fu->ep_out, fu->bot_status.req); >> +usb_ep_free_request(fu->ep_in, fu->bot_status.req); >> &

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

Hi, Baolin Wang writes: > I don't yet understand why we can't just keep runtime pm disabled as a > default for xhci platform devices. > It could be enabled by whatever creates the platform device by setting > some > device property > (or

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

Hi, Baolin Wang writes: > I don't yet understand why we can't just keep runtime pm disabled as a > default for xhci platform devices. > It could be enabled by whatever creates the platform device by setting > some > device property > (or equivalent), which would be

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

Hi, Baolin Wang writes: >>> I don't yet understand why we can't just keep runtime pm disabled as a >>> default for xhci platform devices. >>> It could be enabled by whatever creates the platform device by setting some >>> device property >>> (or equivalent), which would

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

Hi, Baolin Wang writes: >>> I don't yet understand why we can't just keep runtime pm disabled as a >>> default for xhci platform devices. >>> It could be enabled by whatever creates the platform device by setting some >>> device property >>> (or equivalent), which would be checked in

Re: [PATCH] usb: dwc3 dwc3_exynos_probe() change goto labels to meaningful names

Shuah Khan writes: > On 01/30/2017 12:25 PM, Shuah Khan wrote: >> Change goto labels to meaningful names from a series of errNs. >> >> Signed-off-by: Shuah Khan >> --- >> >> Rebased to usb-next > > Hi Felipe, > > Are you planning to get this

Re: [PATCH] usb: dwc3 dwc3_exynos_probe() change goto labels to meaningful names

Shuah Khan writes: > On 01/30/2017 12:25 PM, Shuah Khan wrote: >> Change goto labels to meaningful names from a series of errNs. >> >> Signed-off-by: Shuah Khan >> --- >> >> Rebased to usb-next > > Hi Felipe, > > Are you planning to get this in or is there something you are > waiting in for

Re: [PATCH 2/2] usb; dwc3: of-simple: Add support to get resets for the device

Hi, Vivek Gautam <vivek.gau...@codeaurora.org> writes: > On Fri, Mar 10, 2017 at 4:54 PM, Felipe Balbi <ba...@kernel.org> wrote: >> Vivek Gautam <vivek.gau...@codeaurora.org> writes: >> >>> Add support to get a list of resets available for the device.

Re: [PATCH 2/2] usb; dwc3: of-simple: Add support to get resets for the device

Hi, Vivek Gautam writes: > On Fri, Mar 10, 2017 at 4:54 PM, Felipe Balbi wrote: >> Vivek Gautam writes: >> >>> Add support to get a list of resets available for the device. >>> These resets must be kept de-asserted until the device is >>> in use

Re: [PATCH v2] usb: gadget: legacy gadgets are optional

Hi, Romain Izard <romain.izard@gmail.com> writes: > Hello Felipe, > > 2017-03-10 10:15 GMT+01:00 Felipe Balbi <ba...@kernel.org>: >> >> Hi, >> >> Romain Izard <romain.izard@gmail.com> writes: >>> With commit "usb: ga

Re: [PATCH v2] usb: gadget: legacy gadgets are optional

Hi, Romain Izard writes: > Hello Felipe, > > 2017-03-10 10:15 GMT+01:00 Felipe Balbi : >> >> Hi, >> >> Romain Izard writes: >>> With commit "usb: gadget: don't couple configfs to legacy gadgets" >>> it is possible to build a modul

Re: [PATCH v2] usb: gadget: legacy gadgets are optional

Hi, Romain Izard writes: > With commit "usb: gadget: don't couple configfs to legacy gadgets" > it is possible to build a modular kernel with both built-in configfs > support and modular legacy gadget drivers. > > But when building a kernel without modules, it is

Re: [PATCH v2] usb: gadget: legacy gadgets are optional

Hi, Romain Izard writes: > With commit "usb: gadget: don't couple configfs to legacy gadgets" > it is possible to build a modular kernel with both built-in configfs > support and modular legacy gadget drivers. > > But when building a kernel without modules, it is also necessary to be > able to

Re: [PATCH v3] usb: gadget: udc: remove pointer dereference after free

"Gustavo A. R. Silva" writes: > Remove pointer dereference after free. > > Addresses-Coverity-ID: 1091173 > Acked-by: Michal Nazarewicz > Signed-off-by: Gustavo A. R. Silva > --- > Changes in v2: > Move pointer dereference

Re: [PATCH v3] usb: gadget: udc: remove pointer dereference after free

"Gustavo A. R. Silva" writes: > Remove pointer dereference after free. > > Addresses-Coverity-ID: 1091173 > Acked-by: Michal Nazarewicz > Signed-off-by: Gustavo A. R. Silva > --- > Changes in v2: > Move pointer dereference before pci_pool_free() > Set pointer to NULL after free > > Changes

Re: [PATCH v2 2/3] usb: dwc3: use BIT() macro where possible

Roger Quadros writes: > To avoid checkpatch warnings with new patches let's > start using the BIT() macro wherever possible. > > Signed-off-by: Roger Quadros unfortunately doesn't apply: checking file drivers/usb/dwc3/core.h Hunk #2 succeeded at 67 (offset 1

Re: [PATCH v2 2/3] usb: dwc3: use BIT() macro where possible

Roger Quadros writes: > To avoid checkpatch warnings with new patches let's > start using the BIT() macro wherever possible. > > Signed-off-by: Roger Quadros unfortunately doesn't apply: checking file drivers/usb/dwc3/core.h Hunk #2 succeeded at 67 (offset 1 line). Hunk #3 succeeded at 177

RE: [PATCH v4 3/3] USB3/DWC3: Enable undefined length INCR burst type

Hi, Jerry Huang writes: >> >> -- >> >> 1.7.9.5 >> > Hi, Balbi and all guys, >> > Any comment for these patches? Can they be accepted? >> >> Rob had comments which you didn't reply yet. I cannot take this patchset >> yet ;-) >> > Balbi, > > I look into his mail again,

RE: [PATCH v4 3/3] USB3/DWC3: Enable undefined length INCR burst type

Hi, Jerry Huang writes: >> >> -- >> >> 1.7.9.5 >> > Hi, Balbi and all guys, >> > Any comment for these patches? Can they be accepted? >> >> Rob had comments which you didn't reply yet. I cannot take this patchset >> yet ;-) >> > Balbi, > > I look into his mail again, which was based v3, and I

Re: [PATCH 2/2] usb; dwc3: of-simple: Add support to get resets for the device

Vivek Gautam <vivek.gau...@codeaurora.org> writes: > Add support to get a list of resets available for the device. > These resets must be kept de-asserted until the device is > in use. > > Cc: Felipe Balbi <ba...@kernel.org> > Signed-off-by: Vivek Gautam <vivek.g

Re: [PATCH 2/2] usb; dwc3: of-simple: Add support to get resets for the device

Vivek Gautam writes: > Add support to get a list of resets available for the device. > These resets must be kept de-asserted until the device is > in use. > > Cc: Felipe Balbi > Signed-off-by: Vivek Gautam how do you plan on merging this since it depends on previous

Re: [PATCH] usb: gadget: f_fs: simplify ffs_dev name handling

Hi, Michal Nazarewicz writes: > Currently ffs_dev::name can be either allocated by the client of > the ffs_dev structure or by the f_fs.c core itself. The former > is used by g_ffs while the latter happens with configfs. > > Historically, g_ffs did not need to allocate

Re: [PATCH] usb: gadget: f_fs: simplify ffs_dev name handling

Hi, Michal Nazarewicz writes: > Currently ffs_dev::name can be either allocated by the client of > the ffs_dev structure or by the f_fs.c core itself. The former > is used by g_ffs while the latter happens with configfs. > > Historically, g_ffs did not need to allocate separate buffer for >

Re: [PATCH RESEND^2] usb: gadget: udc: atmel: fix debug output

Hi, Arnd Bergmann writes: > The debug output now contains the wrong variable, as seen from the compiler > warning: > > drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_enable': > drivers/usb/gadget/udc/atmel_usba_udc.c:632:550: error: 'ept_cfg' may be used >

Re: [PATCH RESEND^2] usb: gadget: udc: atmel: fix debug output

Hi, Arnd Bergmann writes: > The debug output now contains the wrong variable, as seen from the compiler > warning: > > drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_enable': > drivers/usb/gadget/udc/atmel_usba_udc.c:632:550: error: 'ept_cfg' may be used > uninitialized in this

Re: [PATCH] uvc-gadget: Fix Set Interface (alternate setting) response behaviour

Hi, Laurent Pinchart <laurent.pinch...@ideasonboard.com> writes: > Hi Felipe, > > On Tuesday 07 Mar 2017 12:57:40 Felipe Balbi wrote: >> Laurent Pinchart writes: >> > On Friday 03 Mar 2017 13:17:15 Roger Quadros wrote: >> >> On altern

Re: [PATCH] uvc-gadget: Fix Set Interface (alternate setting) response behaviour

Hi, Laurent Pinchart writes: > Hi Felipe, > > On Tuesday 07 Mar 2017 12:57:40 Felipe Balbi wrote: >> Laurent Pinchart writes: >> > On Friday 03 Mar 2017 13:17:15 Roger Quadros wrote: >> >> On alternate setting change, webcam gadget sends us a UVC_EVENT_S

Re: [PATCH] uvc-gadget: Fix Set Interface (alternate setting) response behaviour

Hi, Laurent Pinchart writes: > Hi Roger, > > Thank you for the patch. > > On Friday 03 Mar 2017 13:17:15 Roger Quadros wrote: >> On alternate setting change, webcam gadget sends us a UVC_EVENT_STREAMON >> or UVC_EVENT_STREAMOFF event. It expects delayed status

Re: [PATCH] uvc-gadget: Fix Set Interface (alternate setting) response behaviour

Hi, Laurent Pinchart writes: > Hi Roger, > > Thank you for the patch. > > On Friday 03 Mar 2017 13:17:15 Roger Quadros wrote: >> On alternate setting change, webcam gadget sends us a UVC_EVENT_STREAMON >> or UVC_EVENT_STREAMOFF event. It expects delayed status response on >> STREAMON event only

Re: [PATCH 1/4 linux-next] usb: gadget: udc: atmel: Check fifo configuration values against device tree

cristian.bir...@microchip.com writes: > From: Cristian Birsan > > Check fifo configuration values against device tree values for endpoint > fifo in auto configuration mode (fifo_mode=0). > > Signed-off-by: Cristian Birsan > --- >

Re: [PATCH 1/4 linux-next] usb: gadget: udc: atmel: Check fifo configuration values against device tree

cristian.bir...@microchip.com writes: > From: Cristian Birsan > > Check fifo configuration values against device tree values for endpoint > fifo in auto configuration mode (fifo_mode=0). > > Signed-off-by: Cristian Birsan > --- > drivers/usb/gadget/udc/atmel_usba_udc.c | 26

Re: [PATCH v3 17/20] usb: gadget: pch_udc: Replace PCI pool old API

iewed-by: Peter Senna Tschudin <peter.se...@collabora.com> Fine by me: Acked-by: Felipe Balbi <felipe.ba...@linux.intel.com> -- balbi signature.asc Description: PGP signature

Re: [PATCH v3 17/20] usb: gadget: pch_udc: Replace PCI pool old API

din Fine by me: Acked-by: Felipe Balbi -- balbi signature.asc Description: PGP signature

Re: [PATCH] uvc-gadget: Fix Set Interface (alternate setting) response behaviour

Hi, Roger Quadros writes: > <<< No Message Collected >>> You need to resend this. See also [1] [1] https://marc.info/?l=linux-usb=148854335620717=2 -- balbi signature.asc Description: PGP signature

Re: [PATCH] uvc-gadget: Fix Set Interface (alternate setting) response behaviour

Hi, Roger Quadros writes: > <<< No Message Collected >>> You need to resend this. See also [1] [1] https://marc.info/?l=linux-usb=148854335620717=2 -- balbi signature.asc Description: PGP signature

Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

Hi, Alan Stern writes: >> Alan Stern writes: >> >> So I am not sure how the Gadget driver can figure out that it needs to >> >> usb_ep_queue() another request for status stage when handling the >> >> no-data control? >> > >> > Gadget

Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

Hi, Alan Stern writes: >> Alan Stern writes: >> >> So I am not sure how the Gadget driver can figure out that it needs to >> >> usb_ep_queue() another request for status stage when handling the >> >> no-data control? >> > >> > Gadget drivers already queue status-stage requests for no-data >> >

Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

Hi, Baolin Wang writes: >>> > Baolin Wang writes: >>> (One possible approach would be to have the setup routine return >>> different values for explicit and implicit status stages -- for >>> example, return 1 if it wants to submit

Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

Hi, Baolin Wang writes: >>> > Baolin Wang writes: >>> (One possible approach would be to have the setup routine return >>> different values for explicit and implicit status stages -- for >>> example, return 1 if it wants to submit an explicit status request. >>> That

Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

Hi, Alan Stern writes: >> So I am not sure how the Gadget driver can figure out that it needs to >> usb_ep_queue() another request for status stage when handling the >> no-data control? > > Gadget drivers already queue status-stage requests for no-data > control-OUT

Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

Hi, Alan Stern writes: >> So I am not sure how the Gadget driver can figure out that it needs to >> usb_ep_queue() another request for status stage when handling the >> no-data control? > > Gadget drivers already queue status-stage requests for no-data > control-OUT requests. The difficulty

Re: [PATCH v17 0/3] USB Type-C Connector class

> - Partner attribute "accessory" is hidden when the partner type is not > "Accessory". > > Changes since v2: > - Notification on role and alternate mode changes > - cleanups > > Changes since v1: > - Completely rewrote alternate mode support > - Pat

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