[PATCH] USB: serial: mos7840: Add a product ID for the new product
From: JackyChou
Add a new PID 0x7843 to the driver.
Let the new products be able to set up 3 serial ports with the driver.
Signed-off-by: JackyChou
---
drivers/usb/serial/mos7840.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index b42bad85097a..7667b22fa2f7 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -94,6 +94,7 @@
/* The native mos7840/7820 component */
#define USB_VENDOR_ID_MOSCHIP 0x9710
#define MOSCHIP_DEVICE_ID_7840 0x7840
+#define MOSCHIP_DEVICE_ID_7843 0x7843
#define MOSCHIP_DEVICE_ID_7820 0x7820
#define MOSCHIP_DEVICE_ID_7810 0x7810
/* The native component can have its vendor/device id's overridden
@@ -176,6 +177,7 @@ enum mos7840_flag {
static const struct usb_device_id id_table[] = {
{USB_DEVICE(USB_VENDOR_ID_MOSCHIP, MOSCHIP_DEVICE_ID_7840)},
+ {USB_DEVICE(USB_VENDOR_ID_MOSCHIP, MOSCHIP_DEVICE_ID_7843)},
{USB_DEVICE(USB_VENDOR_ID_MOSCHIP, MOSCHIP_DEVICE_ID_7820)},
{USB_DEVICE(USB_VENDOR_ID_MOSCHIP, MOSCHIP_DEVICE_ID_7810)},
{USB_DEVICE(USB_VENDOR_ID_BANDB, BANDB_DEVICE_ID_USO9ML2_2)},
@@ -298,7 +300,7 @@ static int mos7840_set_uart_reg(struct usb_serial_port
*port, __u16 reg,
val = val & 0x00ff;
/* For the UART control registers, the application number need
to be Or'ed */
- if (port->serial->num_ports == 4) {
+ if (port->serial->num_ports == 4 || port->serial->num_ports == 3) {
val |= ((__u16)port->port_number + 1) << 8;
} else {
if (port->port_number == 0) {
@@ -332,7 +334,7 @@ static int mos7840_get_uart_reg(struct usb_serial_port
*port, __u16 reg,
return -ENOMEM;
/* Wval is same as application number */
- if (port->serial->num_ports == 4) {
+ if (port->serial->num_ports == 4 || port->serial->num_ports == 3) {
Wval = ((__u16)port->port_number + 1) << 8;
} else {
if (port->port_number == 0) {
@@ -2071,9 +2073,12 @@ static int mos7840_probe(struct usb_serial *serial,
VENDOR_READ_LENGTH, MOS_WDR_TIMEOUT);
/* For a MCS7840 device GPIO0 must be set to 1 */
- if (buf[0] & 0x01)
- device_type = MOSCHIP_DEVICE_ID_7840;
- else if (mos7810_check(serial))
+ if (buf[0] & 0x01) {
+ if (product == MOSCHIP_DEVICE_ID_7843)
+ device_type = MOSCHIP_DEVICE_ID_7843;
+ else
+ device_type = MOSCHIP_DEVICE_ID_7840;
+ } else if (mos7810_check(serial))
device_type = MOSCHIP_DEVICE_ID_7810;
else
device_type = MOSCHIP_DEVICE_ID_7820;
@@ -2091,7 +2096,10 @@ static int mos7840_calc_num_ports(struct usb_serial
*serial,
int device_type = (unsigned long)usb_get_serial_data(serial);
int num_ports;
- num_ports = (device_type >> 4) & 0x000F;
+ if (device_type == MOSCHIP_DEVICE_ID_7843)
+ num_ports = 3;
+ else
+ num_ports = (device_type >> 4) & 0x000F;
/*
* num_ports is currently never zero as device_type is one of
@@ -2146,7 +2154,8 @@ static int mos7840_port_probe(struct usb_serial_port
*port)
mos7840_port->SpRegOffset = 0x0;
mos7840_port->ControlRegOffset = 0x1;
mos7840_port->DcrRegOffset = 0x4;
- } else if ((mos7840_port->port_num == 2) && (serial->num_ports == 4)) {
+ } else if ((mos7840_port->port_num == 2) &&
+ ((serial->num_ports == 4) || (serial->num_ports == 3))) {
mos7840_port->SpRegOffset = 0x8;
mos7840_port->ControlRegOffset = 0x9;
mos7840_port->DcrRegOffset = 0x16;
@@ -2154,7 +2163,8 @@ static int mos7840_port_probe(struct usb_serial_port
*port)
mos7840_port->SpRegOffset = 0xa;
mos7840_port->ControlRegOffset = 0xb;
mos7840_port->DcrRegOffset = 0x19;
- } else if ((mos7840_port->port_num == 3) && (serial->num_ports == 4)) {
+ } else if ((mos7840_port->port_num == 3) &&
+ ((serial->num_ports == 4) || (serial->num_ports == 3))) {
mos7840_port->SpRegOffset = 0xa;
mos7840_port->ControlRegOffset = 0xb;
mos7840_port->DcrRegOffset = 0x19;
--
2.17.1
Re: [PATCH 3/3] usb: dwc3: Support option to disable USB2 LPM
Hi Roger, On 11/9/2018 3:58 AM, Roger Quadros wrote: > Hi, > > On 08/11/18 04:10, Thinh Nguyen wrote: >> Support the option to disable USB2 LPM. Set xhci "usb2-lpm-disable" >> property via "snps,usb2-lpm-disable" property. >> >> Signed-off-by: Thinh Nguyen >> --- >> drivers/usb/dwc3/core.c | 2 ++ >> drivers/usb/dwc3/core.h | 2 ++ >> drivers/usb/dwc3/host.c | 5 - >> 3 files changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c >> index a4068a7b95dd..f6b80a545a78 100644 >> --- a/drivers/usb/dwc3/core.c >> +++ b/drivers/usb/dwc3/core.c >> @@ -1248,6 +1248,8 @@ static void dwc3_get_properties(struct dwc3 *dwc) >> &hird_threshold); >> dwc->usb3_lpm_capable = device_property_read_bool(dev, >> "snps,usb3_lpm_capable"); >> +dwc->usb2_lpm_disable = device_property_read_bool(dev, >> +"snps,usb2-lpm-disable"); > Can we use the same logic as usb3_lpm instead? > i.e. enable USB2 LPM only if "snps,usb2_lpm_capable" is present in DT. > This is because older platforms that are not tested for usb2 lpm > might break if you enable it by default. I follow the same logic as usb-xhci property. The usb2-lpm-disable property from xHCI has been around for awhile. Do you suggest to change the property for xHCI then? > Also can we have some consistency in usage of '-' vs '_'? Right.. I agree. I've been using '-' as it is the preferred syntax as most of the properties, but some old properties use '_'. Do you have any suggestion? Thanks, Thinh
Re: [PATCH 4/4] usb: dwc3: gadget: check if dep->frame_number is still valid
Hi Felipe,
On 11/9/2018 3:04 AM, Felipe Balbi wrote:
> Hi again,
>
> Felipe Balbi writes:
>> In the case of interval of 1ms, it will start on the next interval.
>>> frame_number + max(4, interval) will start at least 4 uframes in the future.
>>>
>>> In any case, what about immediately retry the START_TRANSFER command
>>> with a new frame_number + (interval*retry) should it fail with
>>> bus-expiry? You can set the number of retries to maybe 5 times. This
>>> should remove the need to do time stamping.
>> That seems like a good idea. Something like below? (on top of $subject)
>>
>> modified drivers/usb/dwc3/core.h
>> @@ -37,6 +37,7 @@
>> #define DWC3_EP0_SETUP_SIZE 512
>> #define DWC3_ENDPOINTS_NUM 32
>> #define DWC3_XHCI_RESOURCES_NUM 2
>> +#define DWC3_ISOC_MAX_RETRIES 5
>>
>> #define DWC3_SCRATCHBUF_SIZE4096/* each buffer is assumed to be
>> 4KiB */
>> #define DWC3_EVENT_BUFFERS_SIZE 4096
>> modified drivers/usb/dwc3/gadget.c
>> @@ -1271,20 +1271,29 @@ static int __dwc3_gadget_start_isoc(struct dwc3_ep
>> *dep)
>> u64 current_timestamp;
>> u64 diff_timestamp;
>> u32 elapsed_frames;
>> +int retries;
>> +int delta = 1
>> +int ret;
>>
>> if (list_empty(&dep->pending_list)) {
>> dep->flags |= DWC3_EP_PENDING_REQUEST;
>> return -EAGAIN;
>> }
>>
>> -current_timestamp = ktime_get_ns();
>> -diff_timestamp = current_timestamp - dep->frame_timestamp;
>> -elapsed_frames = DIV_ROUND_UP_ULL(diff_timestamp, 125000);
>> +for (i = 0; i < DWC3_ISOC_MAX_RETRIES; i++) {
>> +current_timestamp = ktime_get_ns();
>> +diff_timestamp = current_timestamp - dep->frame_timestamp;
>> +elapsed_frames = DIV_ROUND_UP_ULL(diff_timestamp, 125000);
>>
>> -dep->frame_number += elapsed_frames;
>> -dep->frame_number = DWC3_ALIGN_FRAME(dep);
>> +dep->frame_number += elapsed_frames + (delta * i);
> the other possibility is that we can call DWC3_ALIGN_FRAME() n times
> since that will put the transfer on the following interval. That would
> look like so:
>
> modified drivers/usb/dwc3/core.h
> @@ -37,6 +37,7 @@
> #define DWC3_EP0_SETUP_SIZE 512
> #define DWC3_ENDPOINTS_NUM 32
> #define DWC3_XHCI_RESOURCES_NUM 2
> +#define DWC3_ISOC_MAX_RETRIES5
>
> #define DWC3_SCRATCHBUF_SIZE 4096/* each buffer is assumed to be 4KiB */
> #define DWC3_EVENT_BUFFERS_SIZE 4096
> modified drivers/usb/dwc3/gadget.c
> @@ -27,7 +27,7 @@
> #include "gadget.h"
> #include "io.h"
>
> -#define DWC3_ALIGN_FRAME(d) (((d)->frame_number + (d)->interval) \
> +#define DWC3_ALIGN_FRAME(d, n) (((d)->frame_number + ((d)->interval *
> (n))) \
> & ~((d)->interval - 1))
>
> /**
> @@ -1271,20 +1271,28 @@ static int __dwc3_gadget_start_isoc(struct dwc3_ep
> *dep)
> u64 current_timestamp;
> u64 diff_timestamp;
> u32 elapsed_frames;
> + int retries;
> + int ret;
>
> if (list_empty(&dep->pending_list)) {
> dep->flags |= DWC3_EP_PENDING_REQUEST;
> return -EAGAIN;
> }
>
> - current_timestamp = ktime_get_ns();
> - diff_timestamp = current_timestamp - dep->frame_timestamp;
> - elapsed_frames = DIV_ROUND_UP_ULL(diff_timestamp, 125000);
> + for (i = 0; i < DWC3_ISOC_MAX_RETRIES; i++) {
> + current_timestamp = ktime_get_ns();
> + diff_timestamp = current_timestamp - dep->frame_timestamp;
> + elapsed_frames = DIV_ROUND_UP_ULL(diff_timestamp, 125000);
>
> - dep->frame_number += elapsed_frames;
> - dep->frame_number = DWC3_ALIGN_FRAME(dep);
> + dep->frame_number += elapsed_frames;
> + dep->frame_number = DWC3_ALIGN_FRAME(dep, i);
>
> - return __dwc3_gadget_kick_transfer(dep);
> + ret = __dwc3_gadget_kick_transfer(dep);
> + if (ret != -EAGAIN)
> + break;
> + }
> +
> + return ret;
> }
>
> static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request
> *req)
>
>
I like the second method. But do we need to keep track of the
frame_timestamp? I don't think it accurately reflects the timestamp of
XferNotReady frame number.
As for the number of retries, we should adjust it according to the
service interval. For example, for larger service interval such as 16,
then we don't need to try more than once. To calculate the max number of
retries, we can do this check (where interval is from 1 to 16):
if (interval >= (16 - (MAX_NUM_RETRIES >> 1))
num_retries = 1 << (16 - interval);
Please check my math..
If it fails for over 5 times in a row, then we should probably wait for
the next XferNotReady to get the frame_number again. Also 5 is an
arbitrary number I came up without any testing, we can probably decide
on a better number. What do you think?
BR,
Thinh
Re: [PATCH v1 2/5] extcon: Return -EPROBE_DEFER when extcon device is not found
Hi Andy,
On 2018년 11월 11일 03:10, Andy Shevchenko wrote:
> All current users of extcon_get_extcon_dev() API considers
> an extcon device a mandatory to appear. Thus, they all convert
> NULL pointer to -EPROBE_DEFER error code.
>
> There is one more caller anticipated with the same requirements.
>
> To decrease a code duplication and a burden to the callers,
> return -EPROBE_DEFER directly from extcon_get_extcon_dev().
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/extcon/extcon-axp288.c| 4 ++--
> drivers/extcon/extcon.c | 2 +-
> drivers/power/supply/axp288_charger.c | 8
> drivers/usb/phy/phy-omap-otg.c| 6 +++---
> drivers/usb/typec/tcpm/fusb302.c | 4 ++--
> 5 files changed, 12 insertions(+), 12 deletions(-)
Acked-by: Chanwoo Choi
Best Regards,
Chanwoo Choi
>
> diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
> index a983708b77a6..3472d3b756ed 100644
> --- a/drivers/extcon/extcon-axp288.c
> +++ b/drivers/extcon/extcon-axp288.c
> @@ -360,8 +360,8 @@ static int axp288_extcon_probe(struct platform_device
> *pdev)
> name = acpi_dev_get_first_match_name("INT3496", NULL, -1);
> if (name) {
> info->id_extcon = extcon_get_extcon_dev(name);
> - if (!info->id_extcon)
> - return -EPROBE_DEFER;
> + if (IS_ERR(info->id_extcon))
> + return PTR_ERR(info->id_extcon);
>
> dev_info(dev, "controlling USB role\n");
> } else {
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index 5ab0498be652..2bd0f2f33f05 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -884,7 +884,7 @@ struct extcon_dev *extcon_get_extcon_dev(const char
> *extcon_name)
> if (!strcmp(sd->name, extcon_name))
> goto out;
> }
> - sd = NULL;
> + sd = ERR_PTR(-EPROBE_DEFER);
> out:
> mutex_unlock(&extcon_dev_list_lock);
> return sd;
> diff --git a/drivers/power/supply/axp288_charger.c
> b/drivers/power/supply/axp288_charger.c
> index 735658ee1c60..8558577fccf5 100644
> --- a/drivers/power/supply/axp288_charger.c
> +++ b/drivers/power/supply/axp288_charger.c
> @@ -768,17 +768,17 @@ static int axp288_charger_probe(struct platform_device
> *pdev)
> info->regmap_irqc = axp20x->regmap_irqc;
>
> info->cable.edev = extcon_get_extcon_dev(AXP288_EXTCON_DEV_NAME);
> - if (info->cable.edev == NULL) {
> + if (IS_ERR(info->cable.edev)) {
> dev_dbg(&pdev->dev, "%s is not ready, probe deferred\n",
> AXP288_EXTCON_DEV_NAME);
> - return -EPROBE_DEFER;
> + return PTR_ERR(info->cable.edev);
> }
>
> if (acpi_dev_present(USB_HOST_EXTCON_HID, NULL, -1)) {
> info->otg.cable = extcon_get_extcon_dev(USB_HOST_EXTCON_NAME);
> - if (info->otg.cable == NULL) {
> + if (IS_ERR(info->otg.cable)) {
> dev_dbg(dev, "EXTCON_USB_HOST is not ready, probe
> deferred\n");
> - return -EPROBE_DEFER;
> + return PTR_ERR(info->otg.cable);
> }
> dev_info(&pdev->dev,
>"Using " USB_HOST_EXTCON_HID " extcon for usb-id\n");
> diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
> index ee0863c6553e..605314ddcd3d 100644
> --- a/drivers/usb/phy/phy-omap-otg.c
> +++ b/drivers/usb/phy/phy-omap-otg.c
> @@ -91,12 +91,12 @@ static int omap_otg_probe(struct platform_device *pdev)
> int ret;
> u32 rev;
>
> - if (!config || !config->extcon)
> + if (!config)
> return -ENODEV;
>
> extcon = extcon_get_extcon_dev(config->extcon);
> - if (!extcon)
> - return -EPROBE_DEFER;
> + if (IS_ERR(extcon))
> + return PTR_ERR(extcon);
>
> otg_dev = devm_kzalloc(&pdev->dev, sizeof(*otg_dev), GFP_KERNEL);
> if (!otg_dev)
> diff --git a/drivers/usb/typec/tcpm/fusb302.c
> b/drivers/usb/typec/tcpm/fusb302.c
> index 43b64d9309d0..6d332066202b 100644
> --- a/drivers/usb/typec/tcpm/fusb302.c
> +++ b/drivers/usb/typec/tcpm/fusb302.c
> @@ -1767,8 +1767,8 @@ static int fusb302_probe(struct i2c_client *client,
>*/
> if (device_property_read_string(dev, "fcs,extcon-name", &name) == 0) {
> chip->extcon = extcon_get_extcon_dev(name);
> - if (!chip->extcon)
> - return -EPROBE_DEFER;
> + if (IS_ERR(chip->extcon))
> + return PTR_ERR(chip->extcon);
> }
>
> chip->vbus = devm_regulator_get(chip->dev, "vbus");
>
Re: [PATCH v6 2/3] usb: dwc3: Add disabling of start_transfer failure quirk
On Thu, Nov 08, 2018 at 12:06:57PM -0800, Thinh Nguyen wrote: > DWC_usb31 peripheral v1.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 SW workaround. Add this quirk to > disable the SW workaround when it is not needed. > > Synopsys STAR 9001202023: Wrong microframe number for isochronous IN > endpoints. > > Signed-off-by: Thinh Nguyen > --- > Documentation/devicetree/bindings/usb/dwc3.txt | 3 +++ > 1 file changed, 3 insertions(+) Acked-by: Rob Herring
Re: [PATCH v1 1/5] drivercore: Revert "deferral race condition fix"
Hi,
On 11/10/18 7:36 PM, Andy Shevchenko wrote:
On Sat, Nov 10, 2018 at 10:26:22AM -0800, Greg Kroah-Hartman wrote:
On Sat, Nov 10, 2018 at 08:10:57PM +0200, Andy Shevchenko wrote:
Consider the following scenario.
There are two independent devices coupled together by functional dependencies:
- USB OTG (dwc3-pci)
- extcon (tested with extcon-intel-mrfld, not yet in upstream)
Each of the driver services a corresponding device is built as a module. In the
Buildroot environment the modules are probed by alphabetical ordering of their
modaliases. The latter comes to the case when USB OTG driver will be probed
first followed by extcon one.
So, if the platform anticipates extcon device to be appeared, in the above case
we will get deferred probe of USB OTG, because of ordering.
Now, a cherry on top of the cake, the deferred probing list contains
the only two modules, i.e. USB OTG and extcon. Due to above circumstances,
values in the local_trigger_count and deferred_trigger_count are not the same,
and thus provokes deferred probe triggering again and again.
...
[ 20.678332] platform dwc3.0.auto: Retrying from deferred list
[ 20.694743] platform dwc3.0.auto: Driver dwc3 requests probe deferral
[ 20.701254] platform dwc3.0.auto: Added to deferred list
[ 20.706620] platform dwc3.0.auto: driver_deferred_probe_add_trigger 1 2
[ 20.713732] platform dwc3.0.auto: Retrying from deferred list
[ 20.730035] platform dwc3.0.auto: Driver dwc3 requests probe deferral
[ 20.736540] platform dwc3.0.auto: Added to deferred list
[ 20.741889] platform dwc3.0.auto: driver_deferred_probe_add_trigger 3 4
[ 20.748991] platform dwc3.0.auto: Retrying from deferred list
[ 20.765416] platform dwc3.0.auto: Driver dwc3 requests probe deferral
[ 20.771914] platform dwc3.0.auto: Added to deferred list
[ 20.777279] platform dwc3.0.auto: driver_deferred_probe_add_trigger 5 6
...
Deeper investigation shows the culprit commit 58b116bce136
("drivercore: deferral race condition fix") which was dedicated to fix some
other issue while bringing a regression.
This reverts commit 58b116bce13612e5aa6fcd49ecbd4cf8bb59e835 for good until
we will have better solution.
Cc: Grant Likely
Cc: Peter Ujfalusi
Cc: Greg Kroah-Hartman
Cc: Mark Brown
Cc: Felipe Balbi
Cc: Andrzej Hajda
Signed-off-by: Andy Shevchenko
---
drivers/base/dd.c | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
Shouldn't there be a "Fixes:" line and cc: stable here?
I'm not sure (yet). I would like to hear from people first, especially from
Grant (I spoke to him already for the matters at ELCE in Edinburg).
Perhaps, Hans can have a chance to test this and comment on.
I'm currently hitting a regression in 4.20-rc1 which causes it to not
boot on my Cherry Trail test devices (sdhci driver times out so it
cannot find its root filesystem).
I'm currently debugging this (it looks like I need todo a full bisect to
find the cause) once I've that working, if I hit something which look
likes you've described I will give this patch a test. But currently I
cannot reproduce the problem you describe.
As for patches 2-55, they look good to me:
Ackeed-by: Hans de Goede
Regards,
Hans
RE: [PATCH V6 00/10] usb: dwc3: Fix broken BULK stream support to dwc3 gadget driver
Hi Felipe, Please let me know if you have any comments on this patch series. If you think patches are good, can we proceed with them ? Thanks, Anurag Kumar Vulisha >-Original Message- >From: Anurag Kumar Vulisha [mailto:anurag.kumar.vuli...@xilinx.com] >Sent: Saturday, October 13, 2018 6:45 PM >To: Felipe Balbi ; Greg Kroah-Hartman >; Alan Stern ; Johan >Hovold ; Jaejoong Kim ; Benjamin >Herrenschmidt ; Roger Quadros >Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; >v.anuragku...@gmail.com; Thinh Nguyen ; Tejas Joglekar >; Ajay Yugalkishore Pandey ; >Anurag Kumar Vulisha >Subject: [PATCH V6 00/10] usb: dwc3: Fix broken BULK stream support to dwc3 >gadget driver > >This patch series fixes the broken BULK streaming support in >dwc3 gadget driver and also adds timer into udc/core.c to avoid deadlock for >the >endpoints which are bulk stream capable. > >Changes in v6: > 1. Added timer into udc/core.c for stream capable endpoint > as suggested by "Felipe Balbi" > >Changes in v5: > 1. Removed the dev_dbg prints as suggested bt "Thinh Nguyen" > >Changes in v4: > 1. Corrected the commit message and stream timeout description > as suggested by "Thinh Nguyen" > >Changes in v3: > 1. Added the changes suggested by "Thinh Nguyen" > >Changes in v2: > 1. Added "usb: dwc3:" in subject heading > >Anurag Kumar Vulisha (10): > usb: gadget: udc: Add timer for stream capable endpoints > usb: dwc3: gadget: Add stream timeout handler for avoiding deadlock > usb: dwc3: gadget: Remove references to dep->stream_capable > usb: dwc3: update stream id in depcmd > usb: dwc3: make controller clear transfer resources after complete > usb: dwc3: don't issue no-op trb for stream capable endpoints > usb: dwc3: check for requests in started list for stream capable >endpoints > usb: dwc3: Correct the logic for checking TRB full in >__dwc3_prepare_one_trb() > usb: dwc3: Check for IOC/LST bit in both event->status and TRB->ctrl >fields > usb: dwc3: Check MISSED ISOC bit only for ISOC endpoints > > drivers/usb/dwc3/core.h | 2 -- > drivers/usb/dwc3/gadget.c | 67 +--- > drivers/usb/gadget/udc/core.c | 71 >++- > include/linux/usb/gadget.h| 12 > 4 files changed, 138 insertions(+), 14 deletions(-) > >-- >2.1.1
