RE: [PATCH 1/2] usb: chipiea: add flags for id and vbus from external block
> >
> > > >
> > > >
> > > > > drivers/usb/chipidea/core.c | 2 ++
> > > > > include/linux/usb/chipidea.h
> > > > > |
> > > > > 4
> > > > > 2 files changed, 6 insertions(+)
> > > > >
> > > > > diff --git a/drivers/usb/chipidea/core.c
> > > > > b/drivers/usb/chipidea/core.c index
> > > > > 7bfcbb2..0bfa850 100644
> > > > > --- a/drivers/usb/chipidea/core.c
> > > > > +++ b/drivers/usb/chipidea/core.c
> > > > > @@ -706,6 +706,7 @@ static int ci_get_platdata(struct device *dev,
> > > > > cable->edev = ext_vbus;
> > > > >
> > > > > if (!IS_ERR(ext_vbus)) {
> > > > > + platdata->ext_vbus = true;
> > > > > ret = extcon_get_state(cable->edev, EXTCON_USB);
> > > > > if (ret)
> > > > > cable->connected = true;
> > > > > @@ -718,6 +719,7 @@ static int ci_get_platdata(struct device *dev,
> > > > > cable->edev = ext_id;
> > > > >
> > > > > if (!IS_ERR(ext_id)) {
> > > > > + platdata->ext_id = true;
> > > > > ret = extcon_get_state(cable->edev, EXTCON_USB_HOST);
> > > > > if (ret)
> > > > > cable->connected = true;
> > > > > diff --git a/include/linux/usb/chipidea.h
> > > > > b/include/linux/usb/chipidea.h index
> > > > > 911e05a..cd72d82 100644
> > > > > --- a/include/linux/usb/chipidea.h
> > > > > +++ b/include/linux/usb/chipidea.h
> > > > > @@ -70,6 +70,10 @@ struct ci_hdrc_platform_data {
> > > > > struct regulator*reg_vbus;
> > > > > struct usb_otg_caps ci_otg_caps;
> > > > > booltpl_support;
> > > > > + /* ID state is from external event out side of USB */
> > > > > + boolext_id;
> > > > > + /* VBUS state is from external event out side of USB */
> > > > > + boolext_vbus;
> > > >
> > > > We already have struct ci_hdrc_cable at this structure, please use it
> > > > instead.
> > >
> > > I am going to extend ci_hdrc_cable also for type-C case, which has
> > > no edev, So it's OK to add a flag in ci_hdrc_cable for both edev and
> > > type-C to indicate external block is used?
> > >
> >
> > Why there is no external cable (edev) for Type-C case? If there is no
> > external cable phandle at controller dts, how driver knows the Type-C
> > connection
> occurs?
>
> The new usb_role class doesn't depends on edev, see how this can work on dwc3:
> https://patchwork.kernel.org/patch/10836519/
>
I see, you could add role switch class for chipidea first, then put Type-C on
it.
Peter
[PATCH] USB: gadget: f_hid: fix deadlock in f_hidg_write()
In f_hidg_write() the write_spinlock is acquired before calling
usb_ep_queue() which causes a deadlock when dummy_hcd is being used.
This is because dummy_queue() callbacks into f_hidg_req_complete() which
tries to acquire the same spinlock. This is (part of) the backtrace when
the deadlock occurs:
0xc06b1410 in f_hidg_req_complete
0xc06a590a in usb_gadget_giveback_request
0xc06cfff2 in dummy_queue
0xc06a4b96 in usb_ep_queue
0xc06b1eb6 in f_hidg_write
0x8127730b in __vfs_write
0x812774d1 in vfs_write
0x81277725 in SYSC_write
Fix this by releasing the write_spinlock before calling usb_ep_queue()
Signed-off-by: Radoslav Gerganov
---
drivers/usb/gadget/function/f_hid.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/function/f_hid.c
b/drivers/usb/gadget/function/f_hid.c
index 54e859d..492bb44 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -391,20 +391,20 @@ static ssize_t f_hidg_write(struct file *file, const char
__user *buffer,
req->complete = f_hidg_req_complete;
req->context = hidg;
+ spin_unlock_irqrestore(&hidg->write_spinlock, flags);
+
status = usb_ep_queue(hidg->in_ep, req, GFP_ATOMIC);
if (status < 0) {
ERROR(hidg->func.config->cdev,
"usb_ep_queue error on int endpoint %zd\n", status);
- goto release_write_pending_unlocked;
+ goto release_write_pending;
} else {
status = count;
}
- spin_unlock_irqrestore(&hidg->write_spinlock, flags);
return status;
release_write_pending:
spin_lock_irqsave(&hidg->write_spinlock, flags);
-release_write_pending_unlocked:
hidg->write_pending = 0;
spin_unlock_irqrestore(&hidg->write_spinlock, flags);
--
1.9.1
[PATCH] usb: dwc2: Fix channel disable flow
Channel disabling/halting should performed for enabled only channels
to avoid warnings "Unable to clear enable on channel N" which seen
if host works in Slave mode.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/hcd.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index dd82fa516f3f..d0f9afa48c68 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -2437,25 +2437,31 @@ static void dwc2_core_host_init(struct dwc2_hsotg
*hsotg)
num_channels = hsotg->params.host_channels;
for (i = 0; i < num_channels; i++) {
hcchar = dwc2_readl(hsotg, HCCHAR(i));
- hcchar &= ~HCCHAR_CHENA;
- hcchar |= HCCHAR_CHDIS;
- hcchar &= ~HCCHAR_EPDIR;
- dwc2_writel(hsotg, hcchar, HCCHAR(i));
+ if (hcchar & HCCHAR_CHENA) {
+ hcchar &= ~HCCHAR_CHENA;
+ hcchar |= HCCHAR_CHDIS;
+ hcchar &= ~HCCHAR_EPDIR;
+ dwc2_writel(hsotg, hcchar, HCCHAR(i));
+ }
}
/* Halt all channels to put them into a known state */
for (i = 0; i < num_channels; i++) {
hcchar = dwc2_readl(hsotg, HCCHAR(i));
- hcchar |= HCCHAR_CHENA | HCCHAR_CHDIS;
- hcchar &= ~HCCHAR_EPDIR;
- dwc2_writel(hsotg, hcchar, HCCHAR(i));
- dev_dbg(hsotg->dev, "%s: Halt channel %d\n",
- __func__, i);
-
- if (dwc2_hsotg_wait_bit_clear(hsotg, HCCHAR(i),
- HCCHAR_CHENA, 1000)) {
- dev_warn(hsotg->dev, "Unable to clear enable on
channel %d\n",
-i);
+ if (hcchar & HCCHAR_CHENA) {
+ hcchar |= HCCHAR_CHENA | HCCHAR_CHDIS;
+ hcchar &= ~HCCHAR_EPDIR;
+ dwc2_writel(hsotg, hcchar, HCCHAR(i));
+ dev_dbg(hsotg->dev, "%s: Halt channel %d\n",
+ __func__, i);
+
+ if (dwc2_hsotg_wait_bit_clear(hsotg, HCCHAR(i),
+ HCCHAR_CHENA,
+ 1000)) {
+ dev_warn(hsotg->dev,
+"Unable to clear enable on
channel %d\n",
+i);
+ }
}
}
}
--
2.11.0
Re: MUSB interrupt storm on device removal
Bin Liu writes:
> On Wed, Jan 23, 2019 at 03:55:47PM +0100, Johan Hovold wrote:
>> On Wed, Jan 23, 2019 at 08:09:47AM -0600, Bin Liu wrote:
>> > On Wed, Jan 23, 2019 at 09:55:49AM +0100, Johan Hovold wrote:
>> > > On Wed, Jan 23, 2019 at 07:52:12AM +0100, Greg Kroah-Hartman wrote:
>>
>> > > > That's not what any other host controller returns when a device is
>> > > > removed, so either you are going to have to fix all USB drives for this
>> > > > issue, or you need to fix the musb driver to not send this error for
>> > > > when a device is removed (hint, do the latter...)
>> > >
>> > > Right, this needs to be handle at the HCD level.
>> >
>> > Any reason usb_serial_generic_read_bulk_callback() doesn't handle
>> > -EPROTO in the same way as -EPIPE?
>>
>> Since it is supposed to be intermittent unlike, for example, -ENOENT or
>> -EPIPE (the latter which the device driver can recover from if it cares
>> to implement clearing of halt).
>
> Okay, makes sense.
>
>>
>> > > dwc2 fixed a similar lockup issue due to retried NAKed transaction by
>> > > not retrying immediately:
>> > >
>> > > 38d2b5fb75c1 ("usb: dwc2: host: Don't retry NAKed transactions right
>> > > away")
>> >
>> > Both cases are all about device removal, but this musb case is slightly
>> > different from this dwc2 case.
>> >
>> > It is all about re-transmitting which causes interrupt storm, but in
>> > this dwc2 case, it is the dwc2 driver doing the re-transmitting, so it
>> > makes sense to delay it in the dwc2 driver as this referred patch does,
>> >
>> > but in this musb case, musb driver reports transaction error to the usb
>> > serial driver, the usb serial driver issues the re-transmitting not the
>> > musb driver, so I don't think the delay should be added in the musb
>> > driver.
>>
>> I didn't say it was exactly the same.
>
> Yeah, I know. My point was the fix is in the place where re-transmitting
> happens, but
>
>> My point was that unless you fix this at the HCD level, you will need to
>> add complex recovery handling to every USB driver and completion handler
>> (~500 of those). But perhaps that is what it needed.
>
> okay, it probably make sense to handle the case in HCD because the
> number of HCD is much less.
>
>> I do see now that of all USB drivers we have two drivers that handles
>> -EPROTO by resubmitting after a delay, while a handful explicitly deals
>> with -EPROTO by simply stopping to resubmit (some probably bail out on
>> all errors, but the majority appear to resubmit on -EPROTO).
>
> Thanks for the info.
> I will handle this case in musb driver.
What's happening to this? There's no immediate urgency from my side,
but I don't want it to get forgotten either.
--
Måns Rullgård
Re: [PATCH v3 09/12] usb: dwc3: Registering a role switch in the DRD code.
Hi Yu, I love your patch! Perhaps something to improve: [auto build test WARNING on balbi-usb/next] [also build test WARNING on v5.0 next-20190305] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Yu-Chen/Add-support-for-usb-on-Hikey960/20190305-062824 base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) include/linux/rcupdate_wait.h:1: warning: no structured comments found include/linux/rcutree.h:1: warning: no structured comments found kernel/rcu/tree.c:710: warning: Excess function parameter 'irq' description in 'rcu_nmi_exit' include/linux/gfp.h:1: warning: no structured comments found include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.ibss' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.connect' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.keys' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.ie' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.ie_len' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.bssid' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.ssid' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.default_key' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.default_mgmt_key' not described in 'wireless_dev' include/net/cfg80211.h:4687: warning: Function parameter or member 'wext.prev_bssid_valid' not described in 'wireless_dev' include/net/mac80211.h:2393: warning: Function parameter or member 'radiotap_timestamp.units_pos' not described in 'ieee80211_hw' include/net/mac80211.h:2393: warning: Function parameter or member 'radiotap_timestamp.accuracy' not described in 'ieee80211_hw' include/net/mac80211.h:1004: warning: Function parameter or member 'control.rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.rts_cts_rate_idx' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.use_rts' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.use_cts_prot' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.short_preamble' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.skip_table' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.jiffies' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.vif' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.hw_key' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.flags' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'control.enqueue_time' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'ack' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'ack.cookie' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.rates' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.ack_signal' not described in 'ieee80211_tx_info' include/net/mac80211.h:1004: warning: Function parameter or member 'status.ampdu_ack_len' not described in 'ieee80211_tx_info
[PATCH] usbip: Remove unnecessary null check
"vdev" points to vhci_hcd->vdev[] array and vhci_hcd->vdev[] array
is not a pointer array but a structure array and it is already used
in vhci_urb_enqueue() and then passed to vhci_tx_urb() as an argument.
vhci_tx_urb() is not called except vhci_urb_enqueue(). So, "vdev"
can not be null pointer. This null check statement is meaningless.
Signed-off-by: Suwan Kim
---
drivers/usb/usbip/vhci_hcd.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index f46ee1fefe02..667d9c0ec905 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -654,15 +654,9 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
static void vhci_tx_urb(struct urb *urb, struct vhci_device *vdev)
{
struct vhci_priv *priv;
- struct vhci_hcd *vhci_hcd;
+ struct vhci_hcd *vhci_hcd = vdev_to_vhci_hcd(vdev);
unsigned long flags;
- if (!vdev) {
- pr_err("could not get virtual device");
- return;
- }
- vhci_hcd = vdev_to_vhci_hcd(vdev);
-
priv = kzalloc(sizeof(struct vhci_priv), GFP_ATOMIC);
if (!priv) {
usbip_event_add(&vdev->ud, VDEV_EVENT_ERROR_MALLOC);
--
2.20.1
Re: [PATCH] wusb: use correct format characters
Hallo
Am 28.02.19 um 12:52 schrieb Louis Taylor:
> When compiling with -Wformat, clang warns:
>
> ./include/linux/usb/wusb.h:245:5: warning: format specifies type
> 'unsigned short' but the argument has type 'u8' (aka 'unsigned char')
> [-Wformat]
> ckhdid->data[0], ckhdid->data[1],
> ^~~
>
> ckhdid->data is unconditionally defined as `u8 data[16]`, so this patch
> updates the format characters to the correct one for unsigned char types.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/378
> Signed-off-by: Louis Taylor
> ---
> include/linux/usb/wusb.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/usb/wusb.h b/include/linux/usb/wusb.h
> index 9e4a3213f2c2..0a3cdf10972d 100644
> --- a/include/linux/usb/wusb.h
> +++ b/include/linux/usb/wusb.h
> @@ -240,8 +240,8 @@ static inline size_t ckhdid_printf(char *pr_ckhdid,
> size_t size,
> const struct wusb_ckhdid *ckhdid)
> {
> return scnprintf(pr_ckhdid, size,
> - "%02hx %02hx %02hx %02hx %02hx %02hx %02hx %02hx "
> - "%02hx %02hx %02hx %02hx %02hx %02hx %02hx %02hx",
> + "%02hhu %02hhu %02hhu %02hhu %02hhu %02hhu %02hhu
> %02hhu "
> + "%02hhu %02hhu %02hhu %02hhu %02hhu %02hhu %02hhu
> %02hhu",
>ckhdid->data[0], ckhdid->data[1],
>ckhdid->data[2], ckhdid->data[3],
>ckhdid->data[4], ckhdid->data[5],
Re: [PATCH] wusb: use correct format characters
Test
Am 28.02.19 um 12:52 schrieb Louis Taylor:
> When compiling with -Wformat, clang warns:
>
> ./include/linux/usb/wusb.h:245:5: warning: format specifies type
> 'unsigned short' but the argument has type 'u8' (aka 'unsigned char')
> [-Wformat]
> ckhdid->data[0], ckhdid->data[1],
> ^~~
>
> ckhdid->data is unconditionally defined as `u8 data[16]`, so this patch
> updates the format characters to the correct one for unsigned char types.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/378
> Signed-off-by: Louis Taylor
> ---
> include/linux/usb/wusb.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/usb/wusb.h b/include/linux/usb/wusb.h
> index 9e4a3213f2c2..0a3cdf10972d 100644
> --- a/include/linux/usb/wusb.h
> +++ b/include/linux/usb/wusb.h
> @@ -240,8 +240,8 @@ static inline size_t ckhdid_printf(char *pr_ckhdid,
> size_t size,
> const struct wusb_ckhdid *ckhdid)
> {
> return scnprintf(pr_ckhdid, size,
> - "%02hx %02hx %02hx %02hx %02hx %02hx %02hx %02hx "
> - "%02hx %02hx %02hx %02hx %02hx %02hx %02hx %02hx",
> + "%02hhu %02hhu %02hhu %02hhu %02hhu %02hhu %02hhu
> %02hhu "
> + "%02hhu %02hhu %02hhu %02hhu %02hhu %02hhu %02hhu
> %02hhu",
>ckhdid->data[0], ckhdid->data[1],
>ckhdid->data[2], ckhdid->data[3],
>ckhdid->data[4], ckhdid->data[5],
Re: [PATCH v2 2/8] dt-bindings: phy: Add Amlogic G12A USB3+PCIE Combo PHY Bindings
Hi Neil, On Mon, Mar 4, 2019 at 11:38 AM Neil Armstrong wrote: > > Add the Amlogic G12A Family USB3 + PCIE Combo PHY Bindings. > > This PHY can provide exclusively USB3 or PCIE support on shared I/Os. > > Signed-off-by: Neil Armstrong > Reviewed-by: Martin Blumenstingl > --- > .../bindings/phy/meson-g12a-usb3-pcie-phy.txt | 22 +++ > 1 file changed, 22 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt > > diff --git > a/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt > b/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt > new file mode 100644 > index ..7cfc17e2df31 > --- /dev/null > +++ b/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt > @@ -0,0 +1,22 @@ > +* Amlogic G12A USB3 + PCIE Combo PHY binding > + > +Required properties: > +- compatible: Should be "amlogic,meson-g12a-usb3-pcie-phy" > +- #phys-cells: must be 1. The cell number is used to select the phy mode > + as defined in between PHY_TYPE_USB3 and > PHY_TYPE_PCIE > +- reg: The base address and length of the registers > +- clocks: a phandle to the 100MHz reference clock of this PHY > +- clock-names: must be "ref_clk" > +- resets: phandle to the reset lines for the PHY control > +- reset-names: must be "phy" one question on the resets: - in v1 you had three reset lines: RESET_PCIE_CTRL_A, RESET_PCIE_PHY, RESET_PCIE_APB - in v2 you only have the "phy" reset line. is this because the other two are connected to the PCIe controller (Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt) instead of the PHY? Regards Martin
[PATCH] USB: serial: ftdi_sio: add additional NovaTech products
Add PIDs for the NovaTech OrionLX+ and Orion I/O so they can be
automatically detected.
Signed-off-by: George McCollister
---
drivers/usb/serial/ftdi_sio.c | 2 ++
drivers/usb/serial/ftdi_sio_ids.h | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 77ef4c481f3c..4e0da23a0210 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -609,6 +609,8 @@ static const struct usb_device_id id_table_combined[] = {
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(FTDI_VID, FTDI_NT_ORIONLXM_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
+ { USB_DEVICE(FTDI_VID, FTDI_NT_ORIONLX_PLUS_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_NT_ORION_IO_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_SYNAPSE_SS200_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_CUSTOMWARE_MINIPLEX_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_CUSTOMWARE_MINIPLEX2_PID) },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index 975d02666c5a..cb0adba174a7 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -567,7 +567,9 @@
/*
* NovaTech product ids (FTDI_VID)
*/
-#define FTDI_NT_ORIONLXM_PID 0x7c90 /* OrionLXm Substation Automation
Platform */
+#define FTDI_NT_ORIONLXM_PID 0x7c90 /* OrionLXm Substation
Automation Platform */
+#define FTDI_NT_ORIONLX_PLUS_PID 0x7c91 /* OrionLX+ Substation
Automation Platform */
+#define FTDI_NT_ORION_IO_PID 0x7c92 /* Orion I/O */
/*
* Synapse Wireless product ids (FTDI_VID)
--
2.20.1
Re: [PATCH -next] usb: gadget: Remove dead branch code
Hello YueHaibing,
Thank you for the patch.
On Wed, Jan 23, 2019 at 10:31:36PM +0800, YueHaibing wrote:
> 'num' is a u8 variable, it never greater than 255,
> So the if branch is dead code and can be removed.
>
> Signed-off-by: YueHaibing
Reviewed-by: Laurent Pinchart
> ---
> drivers/usb/gadget/function/uvc_configfs.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/uvc_configfs.c
> b/drivers/usb/gadget/function/uvc_configfs.c
> index bc1e2af..8fe85cb 100644
> --- a/drivers/usb/gadget/function/uvc_configfs.c
> +++ b/drivers/usb/gadget/function/uvc_configfs.c
> @@ -1570,10 +1570,6 @@ uvcg_uncompressed_##cname##_store(struct config_item
> *item,\
> if (ret)\
> goto end; \
> \
> - if (num > 255) {\
> - ret = -EINVAL; \
> - goto end; \
> - } \
> u->desc.aname = num;\
> ret = len; \
> end: \
> @@ -1767,10 +1763,6 @@ uvcg_mjpeg_##cname##_store(struct config_item *item,
> \
> if (ret)\
> goto end; \
> \
> - if (num > 255) {\
> - ret = -EINVAL; \
> - goto end; \
> - } \
> u->desc.aname = num;\
> ret = len; \
> end: \
--
Regards,
Laurent Pinchart
Re: [PATCH] [v2]USB:serial:pl2303:add new Pull-Up mode to support PL2303HXD (TYPE_HX)
Hi Johan / Greg, Do you have time to review the patch? If there is no time.. Who else can review this patch? Because my boss has been asking me to update the Linux patch... Charles. Charles Yeh 於 2019年3月5日 週二 上午9:16寫道： > > Hi Johan, > Do you have time to review the two patch? > > Johan Hovold 於 2019年2月19日 週二 下午4:51寫道： > > > > On Tue, Feb 19, 2019 at 02:41:28PM +0800, Charles Yeh wrote: > > > Hi Johan & Greg, > > > > > > > > > Do you have received a new patch"[PATCH] [v2]USB:serial:pl2303:add new > > > Pull-Up mode to support PL2303HXD (TYPE_HX)"? > > > > > > If you have received a new patch, has the content been confirmed? > > > > > > Or tell me where needs to be modified. > > > > Yes, both patches you sent last week are in my queue. I just haven't had > > time to review them yet. > > > > Johan
Re: [PATCH] [v2]USB:serial:pl2303:add new Pull-Up mode to support PL2303HXD (TYPE_HX)
On Wed, Mar 06, 2019 at 12:42:29PM +0800, Charles Yeh wrote: > Hi Johan / Greg, > > Do you have time to review the patch? > If there is no time.. Who else can review this patch? > Because my boss has been asking me to update the Linux patch... It is the middle of the merge window and we can not accept any new patches until after 5.1-rc1 is out in 1 1/2 weeks. Please wait until thne before we can get to reviewing this. thanks, greg k-h
