Re: [PATCH] usb: dwc3 dwc3_exynos_probe() change goto labels to meaningful names
On Tue, Jan 31, 2017 at 12:55 AM, Shuah Khan wrote:
> Change goto labels to meaningful names from a series of errNs.
>
> Signed-off-by: Shuah Khan
> ---
>
> Rebased to usb-next
>
> drivers/usb/dwc3/dwc3-exynos.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
> index 1515d45..98f74ff 100644
> --- a/drivers/usb/dwc3/dwc3-exynos.c
> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> @@ -147,53 +147,53 @@ static int dwc3_exynos_probe(struct platform_device
> *pdev)
> exynos->vdd33 = devm_regulator_get(dev, "vdd33");
> if (IS_ERR(exynos->vdd33)) {
> ret = PTR_ERR(exynos->vdd33);
> - goto err2;
> + goto vdd33_err;
While you are changing this in probe, care to change in
dwc3_exynos_register_phys() as well ?
[snip]
Regards
Vivek
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: phy: phy-qcom-8x16-usb: Remove redundant extcon register/unregister
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
---
drivers/usb/phy/phy-qcom-8x16-usb.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/phy/phy-qcom-8x16-usb.c
b/drivers/usb/phy/phy-qcom-8x16-usb.c
index fdf6863..b6a83a5 100644
--- a/drivers/usb/phy/phy-qcom-8x16-usb.c
+++ b/drivers/usb/phy/phy-qcom-8x16-usb.c
@@ -69,9 +69,6 @@ struct phy_8x16 {
struct reset_control*phy_reset;
- struct extcon_dev *vbus_edev;
- struct notifier_block vbus_notify;
-
struct gpio_desc*switch_gpio;
struct notifier_block reboot_notify;
};
@@ -131,7 +128,8 @@ static int phy_8x16_vbus_off(struct phy_8x16 *qphy)
static int phy_8x16_vbus_notify(struct notifier_block *nb, unsigned long event,
void *ptr)
{
- struct phy_8x16 *qphy = container_of(nb, struct phy_8x16, vbus_notify);
+ struct usb_phy *usb_phy = container_of(nb, struct usb_phy, vbus_nb);
+ struct phy_8x16 *qphy = container_of(usb_phy, struct phy_8x16, phy);
if (event)
phy_8x16_vbus_on(qphy);
@@ -187,7 +185,7 @@ static int phy_8x16_init(struct usb_phy *phy)
val = ULPI_PWR_OTG_COMP_DISABLE;
usb_phy_io_write(phy, val, ULPI_SET(ULPI_PWR_CLK_MNG_REG));
- state = extcon_get_state(qphy->vbus_edev, EXTCON_USB);
+ state = extcon_get_state(qphy->phy.edev, EXTCON_USB);
if (state)
phy_8x16_vbus_on(qphy);
else
@@ -289,15 +287,13 @@ static int phy_8x16_probe(struct platform_device *pdev)
phy->io_priv= qphy->regs + HSPHY_ULPI_VIEWPORT;
phy->io_ops = &ulpi_viewport_access_ops;
phy->type = USB_PHY_TYPE_USB2;
+ phy->vbus_nb.notifier_call = phy_8x16_vbus_notify;
+ phy->id_nb.notifier_call = NULL;
ret = phy_8x16_read_devicetree(qphy);
if (ret < 0)
return ret;
- qphy->vbus_edev = extcon_get_edev_by_phandle(phy->dev, 0);
- if (IS_ERR(qphy->vbus_edev))
- return PTR_ERR(qphy->vbus_edev);
-
ret = clk_set_rate(qphy->core_clk, INT_MAX);
if (ret < 0)
dev_dbg(phy->dev, "Can't boost core clock\n");
@@ -315,12 +311,6 @@ static int phy_8x16_probe(struct platform_device *pdev)
if (WARN_ON(ret))
goto off_clks;
- qphy->vbus_notify.notifier_call = phy_8x16_vbus_notify;
- ret = devm_extcon_register_notifier(&pdev->dev, qphy->vbus_edev,
- EXTCON_USB, &qphy->vbus_notify);
- if (ret < 0)
- goto off_power;
-
ret = usb_add_phy_dev(&qphy->phy);
if (ret)
goto off_power;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: phy: Introduce one extcon device into usb phy
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 extcon device into usb phy structure, and some other helper functions to register extcon. Suggested-by: NeilBrown Signed-off-by: Baolin Wang --- drivers/usb/phy/Kconfig | 17 ++--- drivers/usb/phy/phy.c | 44 include/linux/usb/phy.h |6 ++ 3 files changed, 64 insertions(+), 3 deletions(-) diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 61cef75..39fd6e7 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -13,6 +13,7 @@ config AB8500_USB tristate "AB8500 USB Transceiver Driver" depends on AB8500_CORE select USB_PHY + select EXTCON help Enable this to support the USB OTG transceiver in AB8500 chip. This transceiver supports high and full speed devices plus, @@ -23,6 +24,7 @@ config FSL_USB2_OTG depends on USB_EHCI_FSL && USB_FSL_USB2 && USB_OTG_FSM && PM depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 'y' select USB_PHY + select EXTCON help Enable this to support Freescale USB OTG transceiver. @@ -32,6 +34,7 @@ config ISP1301_OMAP depends on USB depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 'y' select USB_PHY + select EXTCON help If you say yes here you get support for the Philips ISP1301 USB-On-The-Go transceiver working with the OMAP OTG controller. @@ -55,6 +58,7 @@ config NOP_USB_XCEIV tristate "NOP USB Transceiver Driver" depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, NOP can't be built-in select USB_PHY + select EXTCON help This driver is to be used by all the usb transceiver which are either built-in with usb ip or which are autonomous and doesn't require any @@ -70,6 +74,7 @@ config AM335X_PHY_USB select USB_PHY select AM335X_CONTROL_USB select USB_COMMON + select EXTCON help This driver provides PHY support for that phy which part for the AM335x SoC. @@ -98,6 +103,7 @@ config USB_GPIO_VBUS depends on GPIOLIB || COMPILE_TEST depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 'y' select USB_PHY + select EXTCON help Provides simple GPIO VBUS sensing for controllers with an internal transceiver via the usb_phy interface, and @@ -116,9 +122,10 @@ config OMAP_OTG config TAHVO_USB tristate "Tahvo USB transceiver driver" - depends on MFD_RETU && EXTCON + depends on MFD_RETU depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 'y' select USB_PHY + select EXTCON help Enable this to support USB transceiver on Tahvo. This is used at least on Nokia 770. @@ -135,6 +142,7 @@ config USB_ISP1301 depends on USB || USB_GADGET depends on I2C select USB_PHY + select EXTCON help Say Y here to add support for the NXP ISP1301 USB transceiver driver. This chip is typically used as USB transceiver for USB host, gadget @@ -148,8 +156,8 @@ config USB_MSM_OTG depends on (USB || USB_GADGET) && (ARCH_QCOM || COMPILE_TEST) depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 'y' depends on RESET_CONTROLLER - depends on EXTCON select USB_PHY + select EXTCON help Enable this to support the USB OTG transceiver on Qualcomm chips. It handles PHY initialization, clock management, and workarounds @@ -162,9 +170,10 @@ config USB_MSM_OTG config USB_QCOM_8X16_PHY tristate "Qualcomm APQ8016/MSM8916 on-chip USB PHY controller support" depends on ARCH_QCOM || COMPILE_TEST - depends on RESET_CONTROLLER && EXTCON + depends on RESET_CONTROLLER select USB_PHY select USB_ULPI_VIEWPORT + select EXTCON help Enable this to support the USB transceiver on Qualcomm 8x16 chipsets. It handles PHY initialization, clock management, power management, @@ -178,6 +187,7 @@ config USB_MV_OTG depends on USB_EHCI_MV && USB_MV_UDC && PM && USB_OTG depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 'y' select USB_PHY + select EXTCON help Say Y here if you want to build Marvell USB OTG transciever driver in kernel (including PXA and MMP series). This driver @@ -190,6 +200,7 @@ config USB_MXS_PHY depends on ARCH_MXC || ARCH_MXS select STMP_DEVICE select USB_PHY + select EXT
Re: [PATCH] usb: xhci: fix HCSPARAMS 3 debug message
On Mon, Mar 13, 2017 at 07:14:18PM +0900, Yoichi Yuasa wrote: > Signed-off-by: Yoichi Yuasa > --- > drivers/usb/host/xhci-dbg.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) I can't take patches without any changelog text, sorry :( -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] phy: cpcap-usb: Add CPCAP PMIC USB support
Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a
multiplexing USB PHY.
This USB PHY can operate at least in four modes using pin multiplexing
and two control GPIOS:
- Pass through companion PHY for the SoC USB PHY
- ULPI PHY for the SoC
- Pass through USB for the modem
- UART debug console for the SoC
This patch adds support for droid 4 USB PHY and debug UART modes,
support for other modes can be added later on as needed.
Both peripheral and host mode are working for the USB. The
host mode depends on the cpcap-charger driver for VBUS.
VBUS and ID pin detection are done using cpcap-adc IIO ADC
driver.
Cc: devicet...@vger.kernel.org
Cc: Marcel Partap
Cc: Michael Scott
Cc: Sebastian Reichel
Signed-off-by: Tony Lindgren
---
.../devicetree/bindings/phy/phy-cpcap-usb.txt | 40 ++
drivers/phy/Kconfig| 8 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-cpcap-usb.c| 695 +
4 files changed, 744 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
create mode 100644 drivers/phy/phy-cpcap-usb.c
diff --git a/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
@@ -0,0 +1,40 @@
+Motorola CPCAP PMIC USB PHY binding
+
+Required properties:
+compatible: Shall be either "motorola,cpcap-usb-phy" or
+ "motorola,mapphone-cpcap-usb-phy"
+#phy-cells: Shall be 0
+interrupts: CPCAP PMIC interrupts used by the USB PHY
+interrupt-names: Interrupt names
+io-channels: IIO ADC channels used by the USB PHY
+io-channel-names: IIO ADC channel names
+vusb-supply: Regulator for the PHY
+
+Optional properties:
+pinctrl: Optional alternate pin modes for the PHY
+pinctrl-names: Names for optional pin modes
+mode-gpios: Optional GPIOs for configuring alternate modes
+
+Example:
+cpcap_usb2_phy: phy {
+ compatible = "motorola,mapphone-cpcap-usb-phy";
+ pinctrl-0 = <&usb_gpio_mux_sel1 &usb_gpio_mux_sel2>;
+ pinctrl-1 = <&usb_ulpi_pins>;
+ pinctrl-2 = <&usb_utmi_pins>;
+ pinctrl-3 = <&uart3_pins>;
+ pinctrl-names = "default", "ulpi", "utmi", "uart";
+ #phy-cells = <0>;
+ interrupts-extended = <
+ &cpcap 15 0 &cpcap 14 0 &cpcap 28 0 &cpcap 19 0
+ &cpcap 18 0 &cpcap 17 0 &cpcap 16 0 &cpcap 49 0
+ &cpcap 48 1
+ >;
+ interrupt-names =
+ "id_ground", "id_float", "se0conn", "vbusvld",
+ "sessvld", "sessend", "se1", "dm", "dp";
+ mode-gpios = <&gpio2 28 GPIO_ACTIVE_HIGH
+ &gpio1 0 GPIO_ACTIVE_HIGH>;
+ io-channels = <&cpcap_adc 2>, <&cpcap_adc 7>;
+ io-channel-names = "vbus", "id";
+ vusb-supply = <&vusb>;
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -47,6 +47,14 @@ config PHY_BERLIN_SATA
help
Enable this to support the SATA PHY on Marvell Berlin SoCs.
+config PHY_CPCAP_USB
+ tristate "CPCAP USB PHY driver"
+ depends on USB_SUPPORT
+ select GENERIC_PHY
+ select USB_PHY
+ help
+ Enable this for CPCAP USB to work.
+
config ARMADA375_USBCLUSTER_PHY
def_bool y
depends on MACH_ARMADA_375 || COMPILE_TEST
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PHY_BCM_NS_USB2) += phy-bcm-ns-usb2.o
obj-$(CONFIG_PHY_BCM_NS_USB3) += phy-bcm-ns-usb3.o
obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o
+obj-$(CONFIG_PHY_CPCAP_USB)+= phy-cpcap-usb.o
obj-$(CONFIG_PHY_DA8XX_USB)+= phy-da8xx-usb.o
obj-$(CONFIG_PHY_DM816X_USB) += phy-dm816x-usb.o
obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
diff --git a/drivers/phy/phy-cpcap-usb.c b/drivers/phy/phy-cpcap-usb.c
new file mode 100644
--- /dev/null
+++ b/drivers/phy/phy-cpcap-usb.c
@@ -0,0 +1,695 @@
+/*
+ * Motorola CPCAP PMIC USB PHY driver
+ * Copyright (C) 2017 Tony Lindgren
+ *
+ * Some parts based on earlier Motorola Linux kernel tree code in
+ * board-mapphone-usb.c and cpcap-usb-det.c:
+ * Copyright (C) 2007 - 2011 Motorola, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
RE: [PATCH net-next] r8152: simply the arguments
David Laight [mailto:david.lai...@aculab.com] > Sent: Thursday, March 16, 2017 10:28 PM [...] > If you are really lucky the compiler will optimise it away. > Otherwise it will generate another local variable and possibly > a register spill to stack. However, I could reduce the time for calculating the address, because I only calculate it once and save the result to a variable. Right? Best Regards, Hayes -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] r8152: check hw version first
Check hw version first in probe(). Do nothing if the driver doesn't
support the chip.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 102 ++--
1 file changed, 63 insertions(+), 39 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 4b85e95..3262a32 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -4236,44 +4236,6 @@ static const struct net_device_ops rtl8152_netdev_ops = {
.ndo_features_check = rtl8152_features_check,
};
-static void r8152b_get_version(struct r8152 *tp)
-{
- u32 ocp_data;
- u16 version;
-
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_TCR1);
- version = (u16)(ocp_data & VERSION_MASK);
-
- switch (version) {
- case 0x4c00:
- tp->version = RTL_VER_01;
- break;
- case 0x4c10:
- tp->version = RTL_VER_02;
- break;
- case 0x5c00:
- tp->version = RTL_VER_03;
- tp->mii.supports_gmii = 1;
- break;
- case 0x5c10:
- tp->version = RTL_VER_04;
- tp->mii.supports_gmii = 1;
- break;
- case 0x5c20:
- tp->version = RTL_VER_05;
- tp->mii.supports_gmii = 1;
- break;
- case 0x5c30:
- tp->version = RTL_VER_06;
- tp->mii.supports_gmii = 1;
- break;
- default:
- netif_info(tp, probe, tp->netdev,
- "Unknown version 0x%04x\n", version);
- break;
- }
-}
-
static void rtl8152_unload(struct r8152 *tp)
{
if (test_bit(RTL8152_UNPLUG, &tp->flags))
@@ -4338,14 +4300,66 @@ static int rtl_ops_init(struct r8152 *tp)
return ret;
}
+static u8 rtl_get_version(struct usb_interface *intf)
+{
+ struct usb_device *udev = interface_to_usbdev(intf);
+ u32 ocp_data = 0;
+ __le32 *tmp;
+ u8 version;
+ int ret;
+
+ tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
+ if (!tmp)
+ return 0;
+
+ ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+ RTL8152_REQ_GET_REGS, RTL8152_REQT_READ,
+ PLA_TCR0, MCU_TYPE_PLA, tmp, sizeof(*tmp), 500);
+ if (ret > 0)
+ ocp_data = (__le32_to_cpu(*tmp) >> 16) & VERSION_MASK;
+
+ kfree(tmp);
+
+ switch (ocp_data) {
+ case 0x4c00:
+ version = RTL_VER_01;
+ break;
+ case 0x4c10:
+ version = RTL_VER_02;
+ break;
+ case 0x5c00:
+ version = RTL_VER_03;
+ break;
+ case 0x5c10:
+ version = RTL_VER_04;
+ break;
+ case 0x5c20:
+ version = RTL_VER_05;
+ break;
+ case 0x5c30:
+ version = RTL_VER_06;
+ break;
+ default:
+ version = RTL_VER_UNKNOWN;
+ dev_info(&intf->dev, "Unknown version 0x%04x\n", ocp_data);
+ break;
+ }
+
+ return version;
+}
+
static int rtl8152_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
struct usb_device *udev = interface_to_usbdev(intf);
+ u8 version = rtl_get_version(intf);
struct r8152 *tp;
struct net_device *netdev;
int ret;
+ if (version == RTL_VER_UNKNOWN)
+ return -ENODEV;
+
if (udev->actconfig->desc.bConfigurationValue != 1) {
usb_driver_set_configuration(udev, 1);
return -ENODEV;
@@ -4365,8 +4379,18 @@ static int rtl8152_probe(struct usb_interface *intf,
tp->udev = udev;
tp->netdev = netdev;
tp->intf = intf;
+ tp->version = version;
+
+ switch (version) {
+ case RTL_VER_01:
+ case RTL_VER_02:
+ tp->mii.supports_gmii = 0;
+ break;
+ default:
+ tp->mii.supports_gmii = 1;
+ break;
+ }
- r8152b_get_version(tp);
ret = rtl_ops_init(tp);
if (ret)
goto out;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/5] usb: early: add support for early printk through USB3 debug port
Hi Ingo, On 03/16/2017 03:17 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> Hi Ingo, >> >> On 03/02/2017 02:40 PM, Ingo Molnar wrote: >>> * Lu Baolu wrote: >>> Hi Ingo, How about this version? Any further comments? >>> So I have re-read the review feedback I gave on Jan 19 and found at least >>> one >>> thing I pointed out that you didn't address in the latest patches ... >> Do you mind telling me which one is not addressed? Is it one of below >> feedbacks? > So one piece of feedback I gave was: > > | BTW., just a side note, some kernel developers (like PeterZ - and I do it > | sometimes too) remap early_printk to printk permanently and use it as their > main > | printk facility - because printk() reliability has suffered over the last > couple > | of years. > | > | So it's more than just early boot debugging - it's a very simple state-less > | logging facility to an external computer. > > But the latest Kconfig help text still says this: > > +config EARLY_PRINTK_USB_XDBC > + bool "Early printk via the xHCI debug port" > + depends on EARLY_PRINTK && PCI > + select EARLY_PRINTK_USB > + ---help--- > + Write kernel log output directly into the xHCI debug port. > + > + This is useful for kernel debugging when your machine crashes very > + early before the console code is initialized. For normal operation > + it is not recommended because it looks ugly and doesn't cooperate > + with klogd/syslogd or the X server. You should normally N here, > + unless you want to debug such a crash. > > ... while in reality it's an alternative lockless logging facility that goes > way > beyond debugging early boot crashes! > > Granted, I qualified that with 'just a side note'. I guess something like > this > would work: > > + One use for this feature is kernel debugging, for example when your > + machine crashes very early before the regular console code is > + initialized. Other uses include simpler, lockless logging instead of > a > + full-blown printk console driver + klogd. > + > + For normal production environments this is normally not recommended, > + because it doesn't feed events into klogd/syslogd and doesn't try to > + print anything on the screen. > + > + You should normally N here, unless you want to debug early crashes or > + need a very simple printk logging facility. Very appreciated for pointing this out. I will replace it. > > Another piece of feedback I gave was: > >>> +config USB_EARLY_PRINTK >>> + bool >> Also, could we standardize the nomencalture to not be a mixture of prefixes >> and >> postfixes - i.e. standardize on postfixes (as commonly done in the Kconfig >> space) and rename this one to EARLY_PRINTK_USB or so? > yet your latest submission still includes the very same postfixed config > switch > name that collides with the prefixed names such as EARLY_PRINTK_USB: > > --- a/drivers/usb/Kconfig > +++ b/drivers/usb/Kconfig > @@ -19,6 +19,9 @@ config USB_EHCI_BIG_ENDIAN_MMIO > config USB_EHCI_BIG_ENDIAN_DESC > bool > > +config USB_EARLY_PRINTK > + bool > + > menuconfig USB_SUPPORT > bool "USB support" > depends on HAS_IOMEM > > The problem I tried to point out with my review feedback is that we thus have > both: > > CONFIG_EARLY_PRINTK_USB=y > CONFIG_USB_EARLY_PRINTK=y > > ... which is confusing at the very least. > > On a second look, this config switch appears to be unused - is it a leftover > from > earlier patches? Yes, it is a leftover from the earlier patches. I should remove it. Sorry about it. > > The patches don't look too bad otherwise, so we are not far from having > something > acceptable, IMHO. > Thanks. For the typo and grammar issues, I will recheck the patches and ask some English speakers for review. Best regards, Lu Baolu -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] usbip: Fix-format-overflow
On Thu, Mar 16, 2017 at 09:04:54AM -0600, Shuah Khan wrote: > On 02/27/2017 01:31 AM, Jonathan Dieter wrote: > > The usbip userspace tools call sprintf()/snprintf() and don't check for > > the return value which can lead the paths to overflow, truncating the > > final file in the path. > > > > More urgently, GCC 7 now warns that these aren't checked with > > -Wformat-overflow, and with -Werror enabled in configure.ac, that makes > > these tools unbuildable. > > > > This patch fixes these problems by replacing sprintf() with snprintf() in > > one place and adding checks for the return value of snprintf(). > > > > Reviewed-by: Peter Senna Tschudin > > Signed-off-by: Jonathan Dieter > > Greg, > > Please pick this up. > > Acked-by: Shuah Khan Thanks, still digging through USB patches... -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] dwc2: Don't assume URB transfer_buffer are dword-aligned
On Thu, Mar 16, 2017 at 09:08:40PM -0300, Mauro Carvalho Chehab wrote: > The dwc2 hardware doesn't like to do DMA transfers without > aligning data in DWORD. The driver also assumes that, even > when there's no DMA, at dwc2_read_packet(). > > That cause buffer overflows, preventing some drivers to work. Why aren't the drivers being fixed? This is a well-known (hopefully) restriction on USB data buffers, can't the uvc_driver be fixed? > In the specific case of uvc_driver, it uses an array where > it caches the content of video controls, passing it to the > USB stack via usb_control_msg(). Typical controls use 1 or 2 > bytes. The net result is that other values of the buffer > gets overriden when this function is called. Not good, it should be fixed, otherwise you are going to have to try to fix up all host controllers :( thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC] dwc2: Don't assume URB transfer_buffer are dword-aligned
The dwc2 hardware doesn't like to do DMA transfers without
aligning data in DWORD. The driver also assumes that, even
when there's no DMA, at dwc2_read_packet().
That cause buffer overflows, preventing some drivers to work.
In the specific case of uvc_driver, it uses an array where
it caches the content of video controls, passing it to the
USB stack via usb_control_msg(). Typical controls use 1 or 2
bytes. The net result is that other values of the buffer
gets overriden when this function is called.
Fix it by changing the logic at dwc2_alloc_dma_aligned_buffer()
to ensure that the buffer used for DMA will be DWORD-aligned.
Detected with uvc driver.
Signed-off-by: Mauro Carvalho Chehab
---
On Raspberry Pi 3, I was unable to test dwc2_read_packet(), as this was
never called there. However, the change at the second hunk, e. g. at
dwc2_alloc_dma_aligned_buffer() made UVC to answer the same way
as on x86, while reading the values for the device controls.
drivers/usb/dwc2/hcd.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index a73722e27d07..c53d3c24d5b5 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -572,20 +572,26 @@ u32 dwc2_calc_frame_interval(struct dwc2_hsotg *hsotg)
void dwc2_read_packet(struct dwc2_hsotg *hsotg, u8 *dest, u16 bytes)
{
u32 __iomem *fifo = hsotg->regs + HCFIFO(0);
- u32 *data_buf = (u32 *)dest;
- int word_count = (bytes + 3) / 4;
- int i;
-
- /*
-* Todo: Account for the case where dest is not dword aligned. This
-* requires reading data from the FIFO into a u32 temp buffer, then
-* moving it into the data buffer.
-*/
+ u32 *data_buf = (u32 *)dest, tmp;
+ int word_count = bytes >> 2;
+ int i, j;
dev_vdbg(hsotg->dev, "%s(%p,%p,%d)\n", __func__, hsotg, dest, bytes);
for (i = 0; i < word_count; i++, data_buf++)
*data_buf = dwc2_readl(fifo);
+
+ /* Handle the case where the buffer is not dword-aligned */
+ if (bytes & 0x3) {
+ u8 *buf = (u8 *)data_buf;
+
+ tmp = dwc2_readl(fifo);
+
+ i <<= 2;
+ for (j = 0; i < bytes; j++, i++, dest++)
+ *buf = tmp >> (8 * j);
+ }
+
}
/**
@@ -2594,8 +2600,9 @@ static int dwc2_alloc_dma_aligned_buffer(struct urb *urb,
gfp_t mem_flags)
size_t kmalloc_size;
if (urb->num_sgs || urb->sg ||
- urb->transfer_buffer_length == 0 ||
- !((uintptr_t)urb->transfer_buffer & (DWC2_USB_DMA_ALIGN - 1)))
+ urb->transfer_buffer_length == 0 || (
+ !((uintptr_t)urb->transfer_buffer & (DWC2_USB_DMA_ALIGN - 1)) &&
+ !((uintptr_t)(urb->transfer_buffer + urb->transfer_buffer_length) &
(DWC2_USB_DMA_ALIGN - 1
return 0;
/* Allocate a buffer with enough padding for alignment */
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Input: fix NULL-derefs at probe
On Mon, Mar 13, 2017 at 04:45:52PM +0100, Johan Hovold wrote: > On Mon, Mar 13, 2017 at 04:15:18PM +0100, Oliver Neukum wrote: > > Am Montag, den 13.03.2017, 13:35 +0100 schrieb Johan Hovold: > > > This series fixes a number of NULL-pointer dereferences due to > > > missing > > > endpoint sanity checks that can be triggered by a malicious USB > > > device. > > > > At the risk of repeating myself, doesn't the sheer number of fixes > > demonstrate the need for a more centralized check? > > No, I don't think that follows. These are plain bugs that needs to be > fixed (cf. not checking for allocation failures or whatever) and > backported to the stable trees. > > I think I may have surveyed just about every USB driver this last week, > and there is no single pattern for how endpoints are verified and > retrieved that could easily be refactored into USB core. > > Now there are certain patterns that could benefit from a few helpers, > and some obvious bugs could then be caught by declaring those helpers as > __must_check. But specifically, you'd still be checking the return > value from the helpers. > > Then verifying the endpoint counts before calling driver probe, > typically only saves a bit of time while probing *malicious* devices > (and the occasional odd interface which cannot be matched on other > attributes). > > That being said, we could still add a centralised sanity check for a > large class of drivers (e.g. that do not use altsettings and only need > minimum constraints) but it's not going to obviate the need for careful > driver implementations. > > I'll be posting some more patches related to this shortly. There were some discussions about making and that would allow drivers declare endpoints they want and have USB core ether fill them or not even try to bind, but nothing concrete. Anyway, I do not think we should be blocking this patch series on it; if we come up with something clever we can always switch over. Applied the lot. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/11] net: usbnet: move to new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated. On usbnet, it
was often implemented with usbnet_{get|set}_settings.
In this serie, I add usbnet_{get|set}_link_ksettings
in the first patch, then I update all the driver to
use this new api, and in the last patch I remove the
old api usbnet_{get|set}_settings.
Philippe Reynes (11):
net: usb: usbnet: add new api ethtool_{get|set}_link_ksettings
net: usb: smsc95xx: use new api ethtool_{get|set}_link_ksettings
net: usb: sr9800: use new api ethtool_{get|set}_link_ksettings
net: usb: cdc_ncm: use new api ethtool_{get|set}_link_ksettings
net: usb: dm9601: use new api ethtool_{get|set}_link_ksettings
net: usb: mcs7830: use new api ethtool_{get|set}_link_ksettings
net: usb: sierra_net: use new api ethtool_{get|set}_link_ksettings
net: usb: smsc75xx: use new api ethtool_{get|set}_link_ksettings
net: usb: sr9700: use new api ethtool_{get|set}_link_ksettings
net: usb: asix: use new api ethtool_{get|set}_link_ksettings
net: usb: usb: remove old api ethtool_{get|set}_settings
drivers/net/usb/asix_devices.c | 12 ++--
drivers/net/usb/cdc_ncm.c |4 ++--
drivers/net/usb/dm9601.c |4 ++--
drivers/net/usb/mcs7830.c |4 ++--
drivers/net/usb/sierra_net.c |4 ++--
drivers/net/usb/smsc75xx.c |4 ++--
drivers/net/usb/smsc95xx.c | 24
drivers/net/usb/sr9700.c |4 ++--
drivers/net/usb/sr9800.c |4 ++--
drivers/net/usb/usbnet.c | 19 ++-
include/linux/usb/usbnet.h |8
11 files changed, 46 insertions(+), 45 deletions(-)
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/11] net: usb: usbnet: add new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We add the new api {get|set}_link_ksettings to this driver.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes
---
drivers/net/usb/usbnet.c | 36
include/linux/usb/usbnet.h |4
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 3de65ea..1b40b18 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -980,6 +980,40 @@ int usbnet_set_settings (struct net_device *net, struct
ethtool_cmd *cmd)
}
EXPORT_SYMBOL_GPL(usbnet_set_settings);
+int usbnet_get_link_ksettings(struct net_device *net,
+ struct ethtool_link_ksettings *cmd)
+{
+ struct usbnet *dev = netdev_priv(net);
+
+ if (!dev->mii.mdio_read)
+ return -EOPNOTSUPP;
+
+ return mii_ethtool_get_link_ksettings(&dev->mii, cmd);
+}
+EXPORT_SYMBOL_GPL(usbnet_get_link_ksettings);
+
+int usbnet_set_link_ksettings(struct net_device *net,
+ const struct ethtool_link_ksettings *cmd)
+{
+ struct usbnet *dev = netdev_priv(net);
+ int retval;
+
+ if (!dev->mii.mdio_write)
+ return -EOPNOTSUPP;
+
+ retval = mii_ethtool_set_link_ksettings(&dev->mii, cmd);
+
+ /* link speed/duplex might have changed */
+ if (dev->driver_info->link_reset)
+ dev->driver_info->link_reset(dev);
+
+ /* hard_mtu or rx_urb_size may change in link_reset() */
+ usbnet_update_max_qlen(dev);
+
+ return retval;
+}
+EXPORT_SYMBOL_GPL(usbnet_set_link_ksettings);
+
u32 usbnet_get_link (struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
@@ -1046,6 +1080,8 @@ void usbnet_set_msglevel (struct net_device *net, u32
level)
.get_msglevel = usbnet_get_msglevel,
.set_msglevel = usbnet_set_msglevel,
.get_ts_info= ethtool_op_get_ts_info,
+ .get_link_ksettings = usbnet_get_link_ksettings,
+ .set_link_ksettings = usbnet_set_link_ksettings,
};
/*-*/
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index 6e0ce8c..5bd8007 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -265,6 +265,10 @@ extern int usbnet_get_settings(struct net_device *net,
struct ethtool_cmd *cmd);
extern int usbnet_set_settings(struct net_device *net,
struct ethtool_cmd *cmd);
+extern int usbnet_get_link_ksettings(struct net_device *net,
+struct ethtool_link_ksettings *cmd);
+extern int usbnet_set_link_ksettings(struct net_device *net,
+const struct ethtool_link_ksettings *cmd);
extern u32 usbnet_get_link(struct net_device *net);
extern u32 usbnet_get_msglevel(struct net_device *);
extern void usbnet_set_msglevel(struct net_device *, u32);
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/11] net: usb: cdc_ncm: use new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes
---
drivers/net/usb/cdc_ncm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index f317984..b6c1d3a 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -131,8 +131,6 @@ static void cdc_ncm_get_strings(struct net_device
__always_unused *netdev, u32 s
static void cdc_ncm_update_rxtx_max(struct usbnet *dev, u32 new_rx, u32
new_tx);
static const struct ethtool_ops cdc_ncm_ethtool_ops = {
- .get_settings = usbnet_get_settings,
- .set_settings = usbnet_set_settings,
.get_link = usbnet_get_link,
.nway_reset= usbnet_nway_reset,
.get_drvinfo = usbnet_get_drvinfo,
@@ -142,6 +140,8 @@ static void cdc_ncm_get_strings(struct net_device
__always_unused *netdev, u32 s
.get_sset_count= cdc_ncm_get_sset_count,
.get_strings = cdc_ncm_get_strings,
.get_ethtool_stats = cdc_ncm_get_ethtool_stats,
+ .get_link_ksettings = usbnet_get_link_ksettings,
+ .set_link_ksettings = usbnet_set_link_ksettings,
};
static u32 cdc_ncm_check_rx_max(struct usbnet *dev, u32 new_rx)
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/11] net: usb: usb: remove old api ethtool_{get|set}_settings
The function usbnet_{get|set}_settings is no longer used,
so we remove it.
Signed-off-by: Philippe Reynes
---
drivers/net/usb/usbnet.c | 35 ---
include/linux/usb/usbnet.h |4
2 files changed, 0 insertions(+), 39 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 1b40b18..13d4ec5 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -947,39 +947,6 @@ int usbnet_open (struct net_device *net)
* they'll probably want to use this base set.
*/
-int usbnet_get_settings (struct net_device *net, struct ethtool_cmd *cmd)
-{
- struct usbnet *dev = netdev_priv(net);
-
- if (!dev->mii.mdio_read)
- return -EOPNOTSUPP;
-
- return mii_ethtool_gset(&dev->mii, cmd);
-}
-EXPORT_SYMBOL_GPL(usbnet_get_settings);
-
-int usbnet_set_settings (struct net_device *net, struct ethtool_cmd *cmd)
-{
- struct usbnet *dev = netdev_priv(net);
- int retval;
-
- if (!dev->mii.mdio_write)
- return -EOPNOTSUPP;
-
- retval = mii_ethtool_sset(&dev->mii, cmd);
-
- /* link speed/duplex might have changed */
- if (dev->driver_info->link_reset)
- dev->driver_info->link_reset(dev);
-
- /* hard_mtu or rx_urb_size may change in link_reset() */
- usbnet_update_max_qlen(dev);
-
- return retval;
-
-}
-EXPORT_SYMBOL_GPL(usbnet_set_settings);
-
int usbnet_get_link_ksettings(struct net_device *net,
struct ethtool_link_ksettings *cmd)
{
@@ -1072,8 +1039,6 @@ void usbnet_set_msglevel (struct net_device *net, u32
level)
/* drivers may override default ethtool_ops in their bind() routine */
static const struct ethtool_ops usbnet_ethtool_ops = {
- .get_settings = usbnet_get_settings,
- .set_settings = usbnet_set_settings,
.get_link = usbnet_get_link,
.nway_reset = usbnet_nway_reset,
.get_drvinfo= usbnet_get_drvinfo,
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index 5bd8007..e2b5691 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -261,10 +261,6 @@ extern netdev_tx_t usbnet_start_xmit(struct sk_buff *skb,
extern void usbnet_resume_rx(struct usbnet *);
extern void usbnet_purge_paused_rxq(struct usbnet *);
-extern int usbnet_get_settings(struct net_device *net,
- struct ethtool_cmd *cmd);
-extern int usbnet_set_settings(struct net_device *net,
- struct ethtool_cmd *cmd);
extern int usbnet_get_link_ksettings(struct net_device *net,
struct ethtool_link_ksettings *cmd);
extern int usbnet_set_link_ksettings(struct net_device *net,
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/11] net: usb: asix: use new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes
---
drivers/net/usb/asix_devices.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 0dd5106..38456d0 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -136,9 +136,9 @@ static int asix_ioctl (struct net_device *net, struct ifreq
*rq, int cmd)
.get_eeprom_len = asix_get_eeprom_len,
.get_eeprom = asix_get_eeprom,
.set_eeprom = asix_set_eeprom,
- .get_settings = usbnet_get_settings,
- .set_settings = usbnet_set_settings,
.nway_reset = usbnet_nway_reset,
+ .get_link_ksettings = usbnet_get_link_ksettings,
+ .set_link_ksettings = usbnet_set_link_ksettings,
};
static void ax88172_set_multicast(struct net_device *net)
@@ -301,9 +301,9 @@ static int ax88172_bind(struct usbnet *dev, struct
usb_interface *intf)
.get_eeprom_len = asix_get_eeprom_len,
.get_eeprom = asix_get_eeprom,
.set_eeprom = asix_set_eeprom,
- .get_settings = usbnet_get_settings,
- .set_settings = usbnet_set_settings,
.nway_reset = usbnet_nway_reset,
+ .get_link_ksettings = usbnet_get_link_ksettings,
+ .set_link_ksettings = usbnet_set_link_ksettings,
};
static int ax88772_link_reset(struct usbnet *dev)
@@ -775,9 +775,9 @@ static void ax88772_unbind(struct usbnet *dev, struct
usb_interface *intf)
.get_eeprom_len = asix_get_eeprom_len,
.get_eeprom = asix_get_eeprom,
.set_eeprom = asix_set_eeprom,
- .get_settings = usbnet_get_settings,
- .set_settings = usbnet_set_settings,
.nway_reset = usbnet_nway_reset,
+ .get_link_ksettings = usbnet_get_link_ksettings,
+ .set_link_ksettings = usbnet_set_link_ksettings,
};
static int marvell_phy_init(struct usbnet *dev)
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/11] net: usb: sr9700: use new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes
---
drivers/net/usb/sr9700.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
index 4a1e9c4..950a3a9 100644
--- a/drivers/net/usb/sr9700.c
+++ b/drivers/net/usb/sr9700.c
@@ -249,9 +249,9 @@ static int sr9700_ioctl(struct net_device *netdev, struct
ifreq *rq, int cmd)
.set_msglevel = usbnet_set_msglevel,
.get_eeprom_len = sr9700_get_eeprom_len,
.get_eeprom = sr9700_get_eeprom,
- .get_settings = usbnet_get_settings,
- .set_settings = usbnet_set_settings,
.nway_reset = usbnet_nway_reset,
+ .get_link_ksettings = usbnet_get_link_ksettings,
+ .set_link_ksettings = usbnet_set_link_ksettings,
};
static void sr9700_set_multicast(struct net_device *netdev)
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/11] net: usb: sierra_net: use new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes
---
drivers/net/usb/sierra_net.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index ac69f28..c8f60b8 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@@ -648,9 +648,9 @@ static u32 sierra_net_get_link(struct net_device *net)
.get_link = sierra_net_get_link,
.get_msglevel = usbnet_get_msglevel,
.set_msglevel = usbnet_set_msglevel,
- .get_settings = usbnet_get_settings,
- .set_settings = usbnet_set_settings,
.nway_reset = usbnet_nway_reset,
+ .get_link_ksettings = usbnet_get_link_ksettings,
+ .set_link_ksettings = usbnet_set_link_ksettings,
};
static int sierra_net_get_fw_attr(struct usbnet *dev, u16 *datap)
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/11] net: usb: smsc75xx: use new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes
---
drivers/net/usb/smsc75xx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 0b17b40..1ab0ff4 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -743,13 +743,13 @@ static int smsc75xx_ethtool_set_wol(struct net_device
*net,
.get_drvinfo= usbnet_get_drvinfo,
.get_msglevel = usbnet_get_msglevel,
.set_msglevel = usbnet_set_msglevel,
- .get_settings = usbnet_get_settings,
- .set_settings = usbnet_set_settings,
.get_eeprom_len = smsc75xx_ethtool_get_eeprom_len,
.get_eeprom = smsc75xx_ethtool_get_eeprom,
.set_eeprom = smsc75xx_ethtool_set_eeprom,
.get_wol= smsc75xx_ethtool_get_wol,
.set_wol= smsc75xx_ethtool_set_wol,
+ .get_link_ksettings = usbnet_get_link_ksettings,
+ .set_link_ksettings = usbnet_set_link_ksettings,
};
static int smsc75xx_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/11] net: usb: mcs7830: use new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes
---
drivers/net/usb/mcs7830.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/mcs7830.c b/drivers/net/usb/mcs7830.c
index 4f345bd..5771ff2 100644
--- a/drivers/net/usb/mcs7830.c
+++ b/drivers/net/usb/mcs7830.c
@@ -464,9 +464,9 @@ static void mcs7830_get_regs(struct net_device *net, struct
ethtool_regs *regs,
.get_link = usbnet_get_link,
.get_msglevel = usbnet_get_msglevel,
.set_msglevel = usbnet_set_msglevel,
- .get_settings = usbnet_get_settings,
- .set_settings = usbnet_set_settings,
.nway_reset = usbnet_nway_reset,
+ .get_link_ksettings = usbnet_get_link_ksettings,
+ .set_link_ksettings = usbnet_set_link_ksettings,
};
static const struct net_device_ops mcs7830_netdev_ops = {
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/11] net: usb: smsc95xx: use new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes
---
drivers/net/usb/smsc95xx.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 831aa33..4a8bf96 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -853,32 +853,32 @@ static void set_mdix_status(struct net_device *net, __u8
mdix_ctrl)
pdata->mdix_ctrl = mdix_ctrl;
}
-static int smsc95xx_get_settings(struct net_device *net,
-struct ethtool_cmd *cmd)
+static int smsc95xx_get_link_ksettings(struct net_device *net,
+ struct ethtool_link_ksettings *cmd)
{
struct usbnet *dev = netdev_priv(net);
struct smsc95xx_priv *pdata = (struct smsc95xx_priv *)(dev->data[0]);
int retval;
- retval = usbnet_get_settings(net, cmd);
+ retval = usbnet_get_link_ksettings(net, cmd);
- cmd->eth_tp_mdix = pdata->mdix_ctrl;
- cmd->eth_tp_mdix_ctrl = pdata->mdix_ctrl;
+ cmd->base.eth_tp_mdix = pdata->mdix_ctrl;
+ cmd->base.eth_tp_mdix_ctrl = pdata->mdix_ctrl;
return retval;
}
-static int smsc95xx_set_settings(struct net_device *net,
-struct ethtool_cmd *cmd)
+static int smsc95xx_set_link_ksettings(struct net_device *net,
+ const struct ethtool_link_ksettings *cmd)
{
struct usbnet *dev = netdev_priv(net);
struct smsc95xx_priv *pdata = (struct smsc95xx_priv *)(dev->data[0]);
int retval;
- if (pdata->mdix_ctrl != cmd->eth_tp_mdix_ctrl)
- set_mdix_status(net, cmd->eth_tp_mdix_ctrl);
+ if (pdata->mdix_ctrl != cmd->base.eth_tp_mdix_ctrl)
+ set_mdix_status(net, cmd->base.eth_tp_mdix_ctrl);
- retval = usbnet_set_settings(net, cmd);
+ retval = usbnet_set_link_ksettings(net, cmd);
return retval;
}
@@ -889,8 +889,6 @@ static int smsc95xx_set_settings(struct net_device *net,
.get_drvinfo= usbnet_get_drvinfo,
.get_msglevel = usbnet_get_msglevel,
.set_msglevel = usbnet_set_msglevel,
- .get_settings = smsc95xx_get_settings,
- .set_settings = smsc95xx_set_settings,
.get_eeprom_len = smsc95xx_ethtool_get_eeprom_len,
.get_eeprom = smsc95xx_ethtool_get_eeprom,
.set_eeprom = smsc95xx_ethtool_set_eeprom,
@@ -898,6 +896,8 @@ static int smsc95xx_set_settings(struct net_device *net,
.get_regs = smsc95xx_ethtool_getregs,
.get_wol= smsc95xx_ethtool_get_wol,
.set_wol= smsc95xx_ethtool_set_wol,
+ .get_link_ksettings = smsc95xx_get_link_ksettings,
+ .set_link_ksettings = smsc95xx_set_link_ksettings,
};
static int smsc95xx_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/11] net: usb: sr9800: use new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes
---
drivers/net/usb/sr9800.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/sr9800.c b/drivers/net/usb/sr9800.c
index a50df0d..a696b62 100644
--- a/drivers/net/usb/sr9800.c
+++ b/drivers/net/usb/sr9800.c
@@ -524,9 +524,9 @@ static int sr_set_mac_address(struct net_device *net, void
*p)
.set_wol= sr_set_wol,
.get_eeprom_len = sr_get_eeprom_len,
.get_eeprom = sr_get_eeprom,
- .get_settings = usbnet_get_settings,
- .set_settings = usbnet_set_settings,
.nway_reset = usbnet_nway_reset,
+ .get_link_ksettings = usbnet_get_link_ksettings,
+ .set_link_ksettings = usbnet_set_link_ksettings,
};
static int sr9800_link_reset(struct usbnet *dev)
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/11] net: usb: dm9601: use new api ethtool_{get|set}_link_ksettings
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes
---
drivers/net/usb/dm9601.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/dm9601.c b/drivers/net/usb/dm9601.c
index 0b4bdd3..fea1b64 100644
--- a/drivers/net/usb/dm9601.c
+++ b/drivers/net/usb/dm9601.c
@@ -281,9 +281,9 @@ static int dm9601_ioctl(struct net_device *net, struct
ifreq *rq, int cmd)
.set_msglevel = usbnet_set_msglevel,
.get_eeprom_len = dm9601_get_eeprom_len,
.get_eeprom = dm9601_get_eeprom,
- .get_settings = usbnet_get_settings,
- .set_settings = usbnet_set_settings,
.nway_reset = usbnet_nway_reset,
+ .get_link_ksettings = usbnet_get_link_ksettings,
+ .set_link_ksettings = usbnet_set_link_ksettings,
};
static void dm9601_set_multicast(struct net_device *net)
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] usb: orion-echi: Add support for the Armada 3700
On Thu, Mar 09, 2017 at 06:52:56PM +0100, Gregory CLEMENT wrote: > From: Hua Jing s/echi/ehci/ in the subject. > > - Add a new compatible string for the Armada 3700 SoCs > > - add sbuscfg support for orion usb controller driver. For the SoCs > without hlock, need to program BAWR/BARD/AHBBRST fields in the sbuscfg > register to guarantee the AHB master's burst would not overrun or > underrun the FIFO. > > - the sbuscfg register has to be set after the usb controller reset, > otherwise the value would be overridden to 0. In order to do this, the > reset callback is registered. > > [gregory.clem...@free-electrons.com: - reword commit and comments >- fix error path in ehci_orion_drv_reset() >- fix checkpatch warning] > Signed-off-by: Hua Jing > Signed-off-by: Gregory CLEMENT > Reviewed-by: Andrew Lunn > --- > .../devicetree/bindings/usb/ehci-orion.txt | 4 ++- Otherwise, Acked-by: Rob Herring > drivers/usb/host/ehci-orion.c | 36 > ++ > 2 files changed, 39 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
TI TUSB7340 xHCI Host Controllers lock up
Hello, I'm having an issue with a pcie connected Texas Instruments TUSB7340 host controller. I've been stress testing an embedded ARM system by writing then reading back large blocks of data to UAS connected USB 3.0 storage. A typical test run writes 128GB of data and I'd say about 75% of the time the run is interrupted by the following crash: xhci_hcd 0001:01:00.0: xHCI host not responding to stop endpoint command. xhci_hcd 0001:01:00.0: Assuming host is dying, halting host. xhci_hcd 0001:01:00.0: Host not halted after 16000 microseconds. xhci_hcd 0001:01:00.0: Non-responsive xHCI host is not halting. xhci_hcd 0001:01:00.0: Completing active URBs anyway. xhci_hcd 0001:01:00.0: HC died; cleaning up usb 1-3: USB disconnect, device number 2 usb 2-1: USB disconnect, device number 2 After this point the host controller will not respond. Removing the driver and reinserting it produces: xhci_hcd 0001:01:00.0: xHCI Host Controller xhci_hcd 0001:01:00.0: new USB bus registered, assigned bus number 1 xhci_hcd 0001:01:00.0: Host not halted after 16000 microseconds. xhci_hcd 0001:01:00.0: can't setup: -110 xhci_hcd 0001:01:00.0: USB bus 1 deregistered xhci_hcd 0001:01:00.0: init 0001:01:00.0 fail, -110 xhci_hcd: probe of 0001:01:00.0 failed with error -110 Only a power cycle brings the host controller back. My initial attempts were with a 4.4.0 kernel, but I can reproduce it with 4.9.15 and 4.11-rc2. I don't have enough data yet to say with certainty, but anecdotally it seems like the crash occurs more frequently with the newer kernels. I've tried several different storage devices, and the crash appears regardless of what I'm writing to. There appears to be quite a list of errata posted for the TUSB73x0 host controllers: ( http://www.ti.com/lit/er/sllz076/sllz076.pdf ) and I noticed that recently Roger Quadros added a patch to address one of the issues. This patch didn't resolve my issue however. There appeared to be some discussion about other issues with this chip over the years, the most recent being ( http://marc.info/?l=linux-usb&m=147745611801558&w=2 ) but I can't tell from recent sources what specific issues if any have been resolved and adopted into the driver. I'm not very familiar with the USB stack so I'm hoping someone here can help point me in the right direction. Thanks for any help anyone can offer, Ryan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] usb: hub: Fix error loop seen after hub communication errors
While stress testing a usb controller using a bind/unbind looop, the
following error loop was observed.
usb 7-1.2: new low-speed USB device number 3 using xhci-hcd
usb 7-1.2: hub failed to enable device, error -108
usb 7-1-port2: cannot disable (err = -22)
usb 7-1-port2: couldn't allocate usb_device
usb 7-1-port2: cannot disable (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
** 57 printk messages dropped ** hub 7-1:1.0: activate --> -22
** 82 printk messages dropped ** hub 7-1:1.0: hub_ext_port_status failed (err =
-22)
This continues forever. After adding tracebacks into the code,
the call sequence leading to this is found to be as follows.
[] hub_activate+0x368/0x7b8
[] hub_resume+0x2c/0x3c
[] usb_resume_interface.isra.6+0x128/0x158
[] usb_suspend_both+0x1e8/0x288
[] usb_runtime_suspend+0x3c/0x98
[] __rpm_callback+0x48/0x7c
[] rpm_callback+0xa8/0xd4
[] rpm_suspend+0x84/0x758
[] rpm_idle+0x2c8/0x498
[] __pm_runtime_idle+0x60/0xac
[] usb_autopm_put_interface+0x6c/0x7c
[] hub_event+0x10ac/0x12ac
[] process_one_work+0x390/0x6b8
[] worker_thread+0x480/0x610
[] kthread+0x164/0x178
[] ret_from_fork+0x10/0x40
kick_hub_wq() is called from hub_activate() even after failures to
communicate with the hub. This results in an endless sequence of
hub event -> hub activate -> wq trigger -> hub event -> ...
Provide two solutions for the problem.
- Only trigger the hub event queue if communication with the hub
was successful.
- After a suspend failure, only resume already suspended interfaces
if the communication with the device is still possible.
Each of the changes fixes the observed problem. Use both to improve
robustness.
Signed-off-by: Guenter Roeck
---
v3: In hub.c, abort immediately if hub_port_status() returns an error.
Since hub_port_status() already logs the error, don't log it again.
In device,c, log the error return value from usb_suspend_device()
if usb_get_status() failed as well.
Don't check if the hub is still accessible if the error returned
from hub_port_status() is -EBUSY.
v2: Instead of not triggering the hub wq after an error to submit an urb,
implement a more complex error detection and handling. Do it in two
places. Marked as RFC to determine if one (or both) of those solutions
are viable.
drivers/usb/core/driver.c | 18 ++
drivers/usb/core/hub.c| 5 -
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index cdee5130638b..7ebdf2a4e8fe 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -1331,6 +1331,24 @@ static int usb_suspend_both(struct usb_device *udev,
pm_message_t msg)
*/
if (udev->parent && !PMSG_IS_AUTO(msg))
status = 0;
+
+ /*
+* If the device is inaccessible, don't try to resume
+* suspended interfaces and just return the error.
+*/
+ if (status && status != -EBUSY) {
+ int err;
+ u16 devstat;
+
+ err = usb_get_status(udev, USB_RECIP_DEVICE, 0,
+&devstat);
+ if (err) {
+ dev_err(&udev->dev,
+ "Failed to suspend device, error %d\n",
+ status);
+ goto done;
+ }
+ }
}
/* If the suspend failed, resume interfaces that did get suspended */
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 5a420657f9f7..5ab7cd09e1a4 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1066,6 +1066,9 @@ static void hub_activate(struct usb_hub *hub, enum
hub_
Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
On Thu, Mar 16, 2017 at 2:14 PM, Diego Viola wrote: > On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern > wrote: >> On Thu, 16 Mar 2017, Ulf Hansson wrote: >> >>> +Alan >>> >>> On 15 March 2017 at 15:00, Diego Viola wrote: >>> > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola >>> > wrote: >>> >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola >>> >> wrote: >>> >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola >>> >>> wrote: >>> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola >>> wrote: >>> > On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola >>> > wrote: >>> >> Hi Greg, >>> >> >>> >> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH >>> >> wrote: >>> >>> On Wed, Mar 08, 2017 at 03:49:19PM -0300, Diego Viola wrote: >>> It hangs on resume from suspend if I have USB 3.0 enabled on the >>> BIOS, >>> it works fine with ehci_hcd or USB 2.0. >>> >>> The way I reproduce the problem is with this command: >>> >>> $ i3lock && systemctl suspend >>> >>> This is what I see on the screen when it hangs: >>> >>> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg >>> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg >>> >>> Some logs: >>> >>> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt >>> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt >>> >>> I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH. >>> >>> I also tried Linux 4.10.1 and I could reproduce this problem there >>> as well. >>> >>> Please let me know if I could provide more info. >>> >>> >>> >>> Has any previous kernel ever worked properly before? If so, any >>> >>> chance >>> >>> you can use 'git bisect' to find the offending commit? >>> >> >>> >> I'm not sure, this is my work machine and I've only started using it >>> >> recently (since about a month ago or so). >>> >> >>> >> I will try older kernels and see if I get any different results, I >>> >> will report back in any case. >>> >> >>> >>> >>> >>> And are you sure you have updated your bios to the latest version? >>> >> >>> >> Yes. >>> >> >>> >>> >>> >>> thanks, >>> >>> >>> >>> greg k-h >>> >> >>> >> Thanks, >>> >> Diego >>> > >>> > I found another workaround, I can suspend/resume fine with `i3lock && >>> > systemctl suspend` if I disconnect/unplug all my USB devices >>> > (keyboard, mouse, etc). This with the default settings in the BIOS >>> > (both USB 2.0 and 3.0 enabled). >>> > >>> > I'm also seeing some messages like this in dmesg: >>> > >>> > [ 16.172190] usb 2-6: device descriptor read/64, error -110 >>> > >>> > Would this indicate a hardware/firmware/power issue? >>> > >>> > Thanks, >>> > Diego >>> >>> OK, I've built Linux 4.4.52 (I did a localmodconfig) and rebooted into >>> it, I did a suspend/resume and it hanged the first time I tried to >>> resume, which isn't much different than using the latest kernel. >>> >>> My dmesg is still being spammed with these messages: >>> >>> [ 260.043673] usb 2-1: Device not responding to setup address. >>> [ 260.246918] usb 2-1: device not accepting address 15, error -71 >>> [ 260.633662] usb 2-1: new high-speed USB device number 17 using >>> xhci_hcd >>> [ 261.341340] usb 2-1: USB disconnect, device number 17 >>> >>> I guess it's safe to assume at this point that this is a hardware >>> problem? >>> >>> Thanks, >>> Diego >>> >>> >>> >>> Hello, >>> >>> >>> >>> I've found something interesting and what it seems to be the cause of >>> >>> my problem. >>> >>> >>> >>> As soon as I boot my system I can see this process being in the D-state: >>> >>> >>> >>> [root@myhost ~]# ps aux | grep " D" >>> >>> root 269 0.0 0.0 0 0 ?D14:11 0:00 >>> >>> [rtsx_usb_ms_2] >>> >>> root 1424 0.0 0.0 10788 2172 pts/2S+ 14:19 0:00 grep D >>> >>> [root@myhost ~]# >>> >>> >>> >>> I'm not exactly sure why that is, but if I do a 'rmmod rtsx_usb_ms' >>> >>> the problem is gone. I already tried suspending/resuming ~40 times >>> >>> after I disabled the module and the suspend/resume problem is gone. >>> >>> That's a good observation! >>> >>> It suspect the drivers/memstick/host/rtsx_usb_ms.c isn't behaving >>> properly from PM point of view. Perhaps it tries to access its device >>> while it from a runtime PM point view still is in a runtime suspended >>> state. Exactly why I don't know yet. >>> >>> Moreover we have had issues with this driver before and its >>> corresponding SD card driver in drivers/mmc/host/rtsx_usb_sdmmc.c. On >>> top of that, both their corresponding devices shares the same usb mfd >
RE: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t
> On Tue, 2017-03-14 at 12:29 +, Reshetova, Elena wrote:
> > > Elena Reshetova writes:
> > >
> > > > refcount_t type and corresponding API should be
> > > > used instead of atomic_t when the variable is used as
> > > > a reference counter. This allows to avoid accidental
> > > > refcounter overflows that might lead to use-after-free
> > > > situations.
> > > >
> > > > Signed-off-by: Elena Reshetova
> > > > Signed-off-by: Hans Liljestrand
> > > > Signed-off-by: Kees Cook
> > > > Signed-off-by: David Windsor
> > > > ---
> > > > drivers/md/md.c | 6 +++---
> > > > drivers/md/md.h | 3 ++-
> > > > 2 files changed, 5 insertions(+), 4 deletions(-)
> > >
> > > When booting linux-next (specifically 5be4921c9958ec) I'm seeing
> > > the
> > > backtrace below. I suspect this patch is just exposing an existing
> > > issue?
> >
> > Yes, we have actually been following this issue in the another
> > thread.
> > It looks like the object is re-used somehow, but I can't quite
> > understand how just by reading the code.
> > This was what I put into the previous thread:
> >
> > "The log below indicates that you are using your refcounter in a bit
> > weird way in mddev_find().
> > However, I can't find the place (just by reading the code) where you
> > would increment refcounter from zero (vs. setting it to one).
> > It looks like you either iterate over existing nodes (and increment
> > their counters, which should be >= 1 at the time of increment) or
> > create a new node, but then mddev_init() sets the counter to 1. "
> >
> > If you can help to understand what is going on with the object
> > creation/destruction, would be appreciated!
> >
> > Also Shaohua Li stopped this patch coming from his tree since the
> > issue was caught at that time, so we are not going to merge this
> > until we figure it out.
>
> Asking on the correct list (dm-devel) would have got you the easy
> answer: The refcount behind mddev->active is a genuine atomic. It has
> refcount properties but only if the array fails to initialise (in that
> case, final put kills it). Once it's added to the system as a gendisk,
> it cannot be freed until md_free(). Thus its ->active count can go to
> zero (when it becomes inactive; usually because of an unmount). On a
> simple allocation regardless of outcome, the last executed statement in
> md_alloc is mddev_put(): that destroys the device if we didn't manage
> to create it or returns 0 and adds an inactive device to the system
> which the user can get with mddev_find().
Thank you James for explaining this! I guess in this case, the conversion
doesn't make sense.
And sorry about not asking in a correct place: we are handling many similar
patches now and while I try to reach the right audience using get_maintainer
script, it doesn't always succeeds.
Best Regards,
Elena.
>
> James
>
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern wrote: > On Thu, 16 Mar 2017, Ulf Hansson wrote: > >> +Alan >> >> On 15 March 2017 at 15:00, Diego Viola wrote: >> > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola wrote: >> >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola >> >> wrote: >> >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola >> >>> wrote: >> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola >> wrote: >> > On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola >> > wrote: >> >> Hi Greg, >> >> >> >> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH >> >> wrote: >> >>> On Wed, Mar 08, 2017 at 03:49:19PM -0300, Diego Viola wrote: >> It hangs on resume from suspend if I have USB 3.0 enabled on the >> BIOS, >> it works fine with ehci_hcd or USB 2.0. >> >> The way I reproduce the problem is with this command: >> >> $ i3lock && systemctl suspend >> >> This is what I see on the screen when it hangs: >> >> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg >> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg >> >> Some logs: >> >> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt >> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt >> >> I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH. >> >> I also tried Linux 4.10.1 and I could reproduce this problem there >> as well. >> >> Please let me know if I could provide more info. >> >>> >> >>> Has any previous kernel ever worked properly before? If so, any >> >>> chance >> >>> you can use 'git bisect' to find the offending commit? >> >> >> >> I'm not sure, this is my work machine and I've only started using it >> >> recently (since about a month ago or so). >> >> >> >> I will try older kernels and see if I get any different results, I >> >> will report back in any case. >> >> >> >>> >> >>> And are you sure you have updated your bios to the latest version? >> >> >> >> Yes. >> >> >> >>> >> >>> thanks, >> >>> >> >>> greg k-h >> >> >> >> Thanks, >> >> Diego >> > >> > I found another workaround, I can suspend/resume fine with `i3lock && >> > systemctl suspend` if I disconnect/unplug all my USB devices >> > (keyboard, mouse, etc). This with the default settings in the BIOS >> > (both USB 2.0 and 3.0 enabled). >> > >> > I'm also seeing some messages like this in dmesg: >> > >> > [ 16.172190] usb 2-6: device descriptor read/64, error -110 >> > >> > Would this indicate a hardware/firmware/power issue? >> > >> > Thanks, >> > Diego >> >> OK, I've built Linux 4.4.52 (I did a localmodconfig) and rebooted into >> it, I did a suspend/resume and it hanged the first time I tried to >> resume, which isn't much different than using the latest kernel. >> >> My dmesg is still being spammed with these messages: >> >> [ 260.043673] usb 2-1: Device not responding to setup address. >> [ 260.246918] usb 2-1: device not accepting address 15, error -71 >> [ 260.633662] usb 2-1: new high-speed USB device number 17 using >> xhci_hcd >> [ 261.341340] usb 2-1: USB disconnect, device number 17 >> >> I guess it's safe to assume at this point that this is a hardware >> problem? >> >> Thanks, >> Diego >> >>> >> >>> Hello, >> >>> >> >>> I've found something interesting and what it seems to be the cause of >> >>> my problem. >> >>> >> >>> As soon as I boot my system I can see this process being in the D-state: >> >>> >> >>> [root@myhost ~]# ps aux | grep " D" >> >>> root 269 0.0 0.0 0 0 ?D14:11 0:00 >> >>> [rtsx_usb_ms_2] >> >>> root 1424 0.0 0.0 10788 2172 pts/2S+ 14:19 0:00 grep D >> >>> [root@myhost ~]# >> >>> >> >>> I'm not exactly sure why that is, but if I do a 'rmmod rtsx_usb_ms' >> >>> the problem is gone. I already tried suspending/resuming ~40 times >> >>> after I disabled the module and the suspend/resume problem is gone. >> >> That's a good observation! >> >> It suspect the drivers/memstick/host/rtsx_usb_ms.c isn't behaving >> properly from PM point of view. Perhaps it tries to access its device >> while it from a runtime PM point view still is in a runtime suspended >> state. Exactly why I don't know yet. >> >> Moreover we have had issues with this driver before and its >> corresponding SD card driver in drivers/mmc/host/rtsx_usb_sdmmc.c. On >> top of that, both their corresponding devices shares the same usb mfd >> device as parent, which is managed by drivers/mfd/rtsx_usb.c. >> >> Unfortunate my knowledge about USB is still in the learning phase, >> however I know well about runtime PM ans system sus
Re: [PATCH v2 net-next] r8152: simply the arguments
From: Hayes Wang Date: Thu, 16 Mar 2017 14:32:22 +0800 > Replace &tp->napi with napi and tp->netdev with netdev. > > Signed-off-by: Hayes Wang Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/29] USB: serial: io_ti: drop redundant read-urb check
Drop the redundant read-urb check from open. The presence of a bulk-in
endpoint is now verified during probe and core has allocated the
corresponding resources.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/io_ti.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index a962082cf3b0..f3ed131d14bf 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -1952,12 +1952,6 @@ static int edge_open(struct tty_struct *tty, struct
usb_serial_port *port)
/* start up our bulk read urb */
urb = port->read_urb;
- if (!urb) {
- dev_err(&port->dev, "%s - no read urb present, exiting\n",
- __func__);
- status = -EINVAL;
- goto unlink_int_urb;
- }
edge_port->ep_read_urb_state = EDGE_READ_URB_RUNNING;
urb->context = edge_port;
status = usb_submit_urb(urb, GFP_KERNEL);
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/29] USB: serial: io_ti: always require a bulk-out endpoint
These devices always require at least one bulk-out endpoint so let core
verify that.
This avoids attempting to send bulk data to the default pipe when
downloading firmware in boot mode.
Note that further endpoints are still needed when not in boot mode.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/io_ti.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index 989795ab064a..c315836793b3 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -2747,6 +2747,7 @@ static struct usb_serial_driver edgeport_1port_device = {
.description= "Edgeport TI 1 port adapter",
.id_table = edgeport_1port_id_table,
.num_ports = 1,
+ .num_bulk_out = 1,
.open = edge_open,
.close = edge_close,
.throttle = edge_throttle,
@@ -2785,6 +2786,7 @@ static struct usb_serial_driver edgeport_2port_device = {
.description= "Edgeport TI 2 port adapter",
.id_table = edgeport_2port_id_table,
.num_ports = 2,
+ .num_bulk_out = 1,
.open = edge_open,
.close = edge_close,
.throttle = edge_throttle,
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/29] USB: serial: omninet: use generic write implementation
Now that the endpoint-port mapping has been properly set up during
probe, we can switch to using the more efficient generic write
implementation.
Note that this currently mean that chars_in_buffer now overcounts
slightly as we always write a full endpoint-sized packet.
Also add a copyright entry.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/omninet.c | 93
1 file changed, 17 insertions(+), 76 deletions(-)
diff --git a/drivers/usb/serial/omninet.c b/drivers/usb/serial/omninet.c
index 558a620d8868..efcd7feed6f4 100644
--- a/drivers/usb/serial/omninet.c
+++ b/drivers/usb/serial/omninet.c
@@ -1,6 +1,8 @@
/*
* USB ZyXEL omni.net LCD PLUS driver
*
+ * Copyright (C) 2013,2017 Johan Hovold
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License version
* 2 as published by the Free Software Foundation.
@@ -32,10 +34,8 @@
/* function prototypes */
static void omninet_process_read_urb(struct urb *urb);
-static void omninet_write_bulk_callback(struct urb *urb);
-static int omninet_write(struct tty_struct *tty, struct usb_serial_port *port,
- const unsigned char *buf, int count);
-static int omninet_write_room(struct tty_struct *tty);
+static int omninet_prepare_write_buffer(struct usb_serial_port *port,
+ void *buf, size_t count);
static int omninet_calc_num_ports(struct usb_serial *serial,
struct usb_serial_endpoints *epds);
static int omninet_port_probe(struct usb_serial_port *port);
@@ -59,10 +59,8 @@ static struct usb_serial_driver zyxel_omninet_device = {
.calc_num_ports = omninet_calc_num_ports,
.port_probe = omninet_port_probe,
.port_remove = omninet_port_remove,
- .write =omninet_write,
- .write_room = omninet_write_room,
- .write_bulk_callback = omninet_write_bulk_callback,
.process_read_urb = omninet_process_read_urb,
+ .prepare_write_buffer = omninet_prepare_write_buffer,
};
static struct usb_serial_driver * const serial_drivers[] = {
@@ -157,81 +155,24 @@ static void omninet_process_read_urb(struct urb *urb)
tty_flip_buffer_push(&port->port);
}
-static int omninet_write(struct tty_struct *tty, struct usb_serial_port *port,
- const unsigned char *buf, int count)
+static int omninet_prepare_write_buffer(struct usb_serial_port *port,
+ void *buf, size_t count)
{
struct omninet_data *od = usb_get_serial_port_data(port);
- struct omninet_header *header = (struct omninet_header *)
- port->write_urb->transfer_buffer;
- int result;
-
- if (count == 0) {
- dev_dbg(&port->dev, "%s - write request of 0 bytes\n",
__func__);
- return 0;
- }
-
- if (!test_and_clear_bit(0, &port->write_urbs_free)) {
- dev_dbg(&port->dev, "%s - already writing\n", __func__);
- return 0;
- }
-
- count = (count > OMNINET_PAYLOADSIZE) ? OMNINET_PAYLOADSIZE : count;
-
- memcpy(port->write_urb->transfer_buffer + OMNINET_HEADERLEN,
- buf, count);
-
- usb_serial_debug_data(&port->dev, __func__, count,
- port->write_urb->transfer_buffer);
-
- header->oh_seq = od->od_outseq++;
- header->oh_len = count;
- header->oh_xxx = 0x03;
- header->oh_pad = 0x00;
-
- /* send the data out the bulk port, always 64 bytes */
- port->write_urb->transfer_buffer_length = OMNINET_BULKOUTSIZE;
-
- result = usb_submit_urb(port->write_urb, GFP_ATOMIC);
- if (result) {
- set_bit(0, &port->write_urbs_free);
- dev_err_console(port,
- "%s - failed submitting write urb, error %d\n",
- __func__, result);
- } else
- result = count;
-
- return result;
-}
-
-
-static int omninet_write_room(struct tty_struct *tty)
-{
- struct usb_serial_port *port = tty->driver_data;
- int room = 0; /* Default: no room */
+ struct omninet_header *header = buf;
- if (test_bit(0, &port->write_urbs_free))
- room = port->bulk_out_size - OMNINET_HEADERLEN;
+ count = min_t(size_t, count, OMNINET_PAYLOADSIZE);
- dev_dbg(&port->dev, "%s - returns %d\n", __func__, room);
+ count = kfifo_out_locked(&port->write_fifo, buf + OMNINET_HEADERLEN,
+ count, &port->lock);
- return room;
-}
-
-static void omninet_write_bulk_callback(struct urb *urb)
-{
-/* struct omninet_header *header = (struct omninet_header *)
-
[PATCH 28/29] USB: serial: f81534: clean up calc_num_ports
Clean up calc_num_ports with respect to handling older chips that lack
config data.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/f81534.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c
index be106f4e3e57..365e3acd6c6c 100644
--- a/drivers/usb/serial/f81534.c
+++ b/drivers/usb/serial/f81534.c
@@ -681,12 +681,13 @@ static int f81534_calc_num_ports(struct usb_serial
*serial,
++num_port;
}
- if (num_port)
- return num_port;
+ if (!num_port) {
+ dev_warn(&serial->interface->dev,
+ "no config found, assuming 4 ports\n");
+ num_port = 4; /* Nothing found, oldest version IC */
+ }
- dev_warn(&serial->interface->dev, "%s: Read Failed. default 4 ports\n",
- __func__);
- return 4; /* Nothing found, oldest version IC */
+ return num_port;
}
static void f81534_set_termios(struct tty_struct *tty,
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/29] USB: serial: mos7720: clean up mcs7715 port setup
Clean up the mcs7715 port setup by using the new endpoint-remap
functionality provided by core. Instead of poking around in internal
port-structure fields, simply swap the endpoint descriptors of the two
ports in calc_num_ports before the port structures are even allocated.
Note that we still need to override the default interrupt completion
handler.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/mos7720.c | 52 +---
1 file changed, 20 insertions(+), 32 deletions(-)
diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c
index 9ec3e4fb9678..eabea0bc1a04 100644
--- a/drivers/usb/serial/mos7720.c
+++ b/drivers/usb/serial/mos7720.c
@@ -977,8 +977,20 @@ static int mos77xx_calc_num_ports(struct usb_serial
*serial,
struct usb_serial_endpoints *epds)
{
u16 product = le16_to_cpu(serial->dev->descriptor.idProduct);
- if (product == MOSCHIP_DEVICE_ID_7715)
+
+ if (product == MOSCHIP_DEVICE_ID_7715) {
+ /*
+* The 7715 uses the first bulk in/out endpoint pair for the
+* parallel port, and the second for the serial port. We swap
+* the endpoint descriptors here so that the the first and
+* only registered port structure uses the serial-port
+* endpoints.
+*/
+ swap(epds->bulk_in[0], epds->bulk_in[1]);
+ swap(epds->bulk_out[0], epds->bulk_out[1]);
+
return 1;
+ }
return 2;
}
@@ -1904,46 +1916,22 @@ static int mos7720_startup(struct usb_serial *serial)
product = le16_to_cpu(serial->dev->descriptor.idProduct);
dev = serial->dev;
- /*
-* The 7715 uses the first bulk in/out endpoint pair for the parallel
-* port, and the second for the serial port. Because the usbserial core
-* assumes both pairs are serial ports, we must engage in a bit of
-* subterfuge and swap the pointers for ports 0 and 1 in order to make
-* port 0 point to the serial port. However, both moschip devices use a
-* single interrupt-in endpoint for both ports (as mentioned a little
-* further down), and this endpoint was assigned to port 0. So after
-* the swap, we must copy the interrupt endpoint elements from port 1
-* (as newly assigned) to port 0, and null out port 1 pointers.
-*/
- if (product == MOSCHIP_DEVICE_ID_7715) {
- struct usb_serial_port *tmp = serial->port[0];
- serial->port[0] = serial->port[1];
- serial->port[1] = tmp;
- serial->port[0]->interrupt_in_urb = tmp->interrupt_in_urb;
- serial->port[0]->interrupt_in_buffer = tmp->interrupt_in_buffer;
- serial->port[0]->interrupt_in_endpointAddress =
- tmp->interrupt_in_endpointAddress;
- serial->port[1]->interrupt_in_urb = NULL;
- serial->port[1]->interrupt_in_buffer = NULL;
-
- if (serial->port[0]->interrupt_in_urb) {
- struct urb *urb = serial->port[0]->interrupt_in_urb;
-
- urb->complete = mos7715_interrupt_callback;
- }
- }
-
/* setting configuration feature to one */
usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
(__u8)0x03, 0x00, 0x01, 0x00, NULL, 0x00, 5000);
-#ifdef CONFIG_USB_SERIAL_MOS7715_PARPORT
if (product == MOSCHIP_DEVICE_ID_7715) {
+ struct urb *urb = serial->port[0]->interrupt_in_urb;
+
+ if (urb)
+ urb->complete = mos7715_interrupt_callback;
+
+#ifdef CONFIG_USB_SERIAL_MOS7715_PARPORT
ret_val = mos7715_parport_init(serial);
if (ret_val < 0)
return ret_val;
- }
#endif
+ }
/* start the interrupt urb */
ret_val = usb_submit_urb(serial->port[0]->interrupt_in_urb, GFP_KERNEL);
if (ret_val) {
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
On Thu, Mar 16, 2017 at 1:02 PM, Diego Viola wrote: > On Thu, Mar 16, 2017 at 12:51 PM, Diego Viola wrote: >> On Thu, Mar 16, 2017 at 12:45 PM, Diego Viola wrote: >>> On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern >>> wrote: On Thu, 16 Mar 2017, Ulf Hansson wrote: > +Alan > > On 15 March 2017 at 15:00, Diego Viola wrote: > > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola > > wrote: > >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola > >> wrote: > >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola > >>> wrote: > On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola > wrote: > > On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola > > wrote: > >> Hi Greg, > >> > >> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH > >> wrote: > >>> On Wed, Mar 08, 2017 at 03:49:19PM -0300, Diego Viola wrote: > It hangs on resume from suspend if I have USB 3.0 enabled on the > BIOS, > it works fine with ehci_hcd or USB 2.0. > > The way I reproduce the problem is with this command: > > $ i3lock && systemctl suspend > > This is what I see on the screen when it hangs: > > https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg > https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg > > Some logs: > > https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt > https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt > > I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH. > > I also tried Linux 4.10.1 and I could reproduce this problem > there as well. > > Please let me know if I could provide more info. > >>> > >>> Has any previous kernel ever worked properly before? If so, any > >>> chance > >>> you can use 'git bisect' to find the offending commit? > >> > >> I'm not sure, this is my work machine and I've only started using > >> it > >> recently (since about a month ago or so). > >> > >> I will try older kernels and see if I get any different results, I > >> will report back in any case. > >> > >>> > >>> And are you sure you have updated your bios to the latest version? > >> > >> Yes. > >> > >>> > >>> thanks, > >>> > >>> greg k-h > >> > >> Thanks, > >> Diego > > > > I found another workaround, I can suspend/resume fine with `i3lock > > && > > systemctl suspend` if I disconnect/unplug all my USB devices > > (keyboard, mouse, etc). This with the default settings in the BIOS > > (both USB 2.0 and 3.0 enabled). > > > > I'm also seeing some messages like this in dmesg: > > > > [ 16.172190] usb 2-6: device descriptor read/64, error -110 > > > > Would this indicate a hardware/firmware/power issue? > > > > Thanks, > > Diego > > OK, I've built Linux 4.4.52 (I did a localmodconfig) and rebooted > into > it, I did a suspend/resume and it hanged the first time I tried to > resume, which isn't much different than using the latest kernel. > > My dmesg is still being spammed with these messages: > > [ 260.043673] usb 2-1: Device not responding to setup address. > [ 260.246918] usb 2-1: device not accepting address 15, error -71 > [ 260.633662] usb 2-1: new high-speed USB device number 17 using > xhci_hcd > [ 261.341340] usb 2-1: USB disconnect, device number 17 > > I guess it's safe to assume at this point that this is a hardware > problem? > > Thanks, > Diego > >>> > >>> Hello, > >>> > >>> I've found something interesting and what it seems to be the cause of > >>> my problem. > >>> > >>> As soon as I boot my system I can see this process being in the > >>> D-state: > >>> > >>> [root@myhost ~]# ps aux | grep " D" > >>> root 269 0.0 0.0 0 0 ?D14:11 0:00 > >>> [rtsx_usb_ms_2] > >>> root 1424 0.0 0.0 10788 2172 pts/2S+ 14:19 0:00 grep > >>> D > >>> [root@myhost ~]# > >>> > >>> I'm not exactly sure why that is, but if I do a 'rmmod rtsx_usb_ms' > >>> the problem is gone. I already tried suspending/resuming ~40 times > >>> after I disabled the module and the suspend/resume problem is gone. > > That's a good observation! > > It suspect the drivers/memstick/host/rtsx_usb_ms.c isn
[PATCH 21/29] USB: serial: ti_usb_3410_5052: always require a bulk-out endpoint
These devices always require at least one bulk-out endpoint so let core
verify that.
This avoids attempting to send bulk data to the default pipe when
downloading firmware in boot mode.
Note that further endpoints are still needed when not in boot mode.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ti_usb_3410_5052.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index 3107bf5d1c96..e16558b63fcc 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -427,6 +427,7 @@ static struct usb_serial_driver ti_1port_device = {
.description= "TI USB 3410 1 port adapter",
.id_table = ti_id_table_3410,
.num_ports = 1,
+ .num_bulk_out = 1,
.attach = ti_startup,
.release= ti_release,
.port_probe = ti_port_probe,
@@ -459,6 +460,7 @@ static struct usb_serial_driver ti_2port_device = {
.description= "TI USB 5052 2 port adapter",
.id_table = ti_id_table_5052,
.num_ports = 2,
+ .num_bulk_out = 1,
.attach = ti_startup,
.release= ti_release,
.port_probe = ti_port_probe,
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 22/29] USB: serial: visor: drop redundant calc_num_ports callback
Drop the redundant calc_num_ports callback from the clie_5 type, for
which the callback always returns zero and hence falls back to the type
num_ports value (2).
Signed-off-by: Johan Hovold
---
drivers/usb/serial/visor.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/serial/visor.c b/drivers/usb/serial/visor.c
index 3f943f877ac2..8b4429e4a73c 100644
--- a/drivers/usb/serial/visor.c
+++ b/drivers/usb/serial/visor.c
@@ -197,7 +197,6 @@ static struct usb_serial_driver clie_5_device = {
.unthrottle = usb_serial_generic_unthrottle,
.attach = clie_5_attach,
.probe =visor_probe,
- .calc_num_ports = visor_calc_num_ports,
.read_int_callback =visor_read_int_callback,
};
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/29] USB: serial: io_ti: verify interrupt endpoint at probe
Verify that the required interrupt endpoint is present at probe rather
than at open to avoid allocating resources for an unusable device.
Note that the endpoint is only required when in download mode.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/io_ti.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index c315836793b3..a962082cf3b0 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -1933,13 +1933,6 @@ static int edge_open(struct tty_struct *tty, struct
usb_serial_port *port)
if (edge_serial->num_ports_open == 0) {
/* we are the first port to open, post the interrupt urb */
urb = edge_serial->serial->port[0]->interrupt_in_urb;
- if (!urb) {
- dev_err(&port->dev,
- "%s - no interrupt urb present, exiting\n",
- __func__);
- status = -EINVAL;
- goto release_es_lock;
- }
urb->context = edge_serial;
status = usb_submit_urb(urb, GFP_KERNEL);
if (status) {
@@ -2553,7 +2546,8 @@ static int edge_calc_num_ports(struct usb_serial *serial,
/* Make sure we have the required endpoints when in download mode. */
if (serial->interface->cur_altsetting->desc.bNumEndpoints > 1) {
if (epds->num_bulk_in < num_ports ||
- epds->num_bulk_out < num_ports) {
+ epds->num_bulk_out < num_ports ||
+ epds->num_interrupt_in < 1) {
dev_err(dev, "required endpoints missing\n");
return -ENODEV;
}
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 23/29] USB: serial: visor: clean up clie_5 endpoint hack
Use the new endpoint-remap functionality to configure the ports for
clie_5 devices.
Note that the same bulk-out endpoint is being used for both ports.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/visor.c | 57 +++---
1 file changed, 23 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/serial/visor.c b/drivers/usb/serial/visor.c
index 8b4429e4a73c..41d135f46fa0 100644
--- a/drivers/usb/serial/visor.c
+++ b/drivers/usb/serial/visor.c
@@ -42,10 +42,11 @@ static int visor_probe(struct usb_serial *serial,
const struct usb_device_id *id);
static int visor_calc_num_ports(struct usb_serial *serial,
struct usb_serial_endpoints *epds);
+static int clie_5_calc_num_ports(struct usb_serial *serial,
+ struct usb_serial_endpoints *epds);
static void visor_read_int_callback(struct urb *urb);
static int clie_3_5_startup(struct usb_serial *serial);
static int treo_attach(struct usb_serial *serial);
-static int clie_5_attach(struct usb_serial *serial);
static int palm_os_3_probe(struct usb_serial *serial,
const struct usb_device_id *id);
static int palm_os_4_probe(struct usb_serial *serial,
@@ -190,13 +191,14 @@ static struct usb_serial_driver clie_5_device = {
.description = "Sony Clie 5.0",
.id_table = clie_id_5_table,
.num_ports =2,
+ .num_bulk_out = 2,
.bulk_out_size =256,
.open = visor_open,
.close =visor_close,
.throttle = usb_serial_generic_throttle,
.unthrottle = usb_serial_generic_unthrottle,
- .attach = clie_5_attach,
.probe =visor_probe,
+ .calc_num_ports = clie_5_calc_num_ports,
.read_int_callback =visor_read_int_callback,
};
@@ -477,6 +479,25 @@ static int visor_calc_num_ports(struct usb_serial *serial,
return num_ports;
}
+static int clie_5_calc_num_ports(struct usb_serial *serial,
+ struct usb_serial_endpoints *epds)
+{
+ /*
+* TH55 registers 2 ports.
+* Communication in from the UX50/TH55 uses the first bulk-in
+* endpoint, while communication out to the UX50/TH55 uses the second
+* bulk-out endpoint.
+*/
+
+ /*
+* FIXME: Should we swap the descriptors instead of using the same
+*bulk-out endpoint for both ports?
+*/
+ epds->bulk_out[0] = epds->bulk_out[1];
+
+ return serial->type->num_ports;
+}
+
static int clie_3_5_startup(struct usb_serial *serial)
{
struct device *dev = &serial->dev->dev;
@@ -588,38 +609,6 @@ static int treo_attach(struct usb_serial *serial)
return 0;
}
-static int clie_5_attach(struct usb_serial *serial)
-{
- struct usb_serial_port *port;
- unsigned int pipe;
- int j;
-
- /* TH55 registers 2 ports.
- Communication in from the UX50/TH55 uses bulk_in_endpointAddress
- from port 0. Communication out to the UX50/TH55 uses
- bulk_out_endpointAddress from port 1
-
- Lets do a quick and dirty mapping
-*/
-
- /* some sanity check */
- if (serial->num_bulk_out < 2) {
- dev_err(&serial->interface->dev, "missing bulk out
endpoints\n");
- return -ENODEV;
- }
-
- /* port 0 now uses the modified endpoint Address */
- port = serial->port[0];
- port->bulk_out_endpointAddress =
- serial->port[1]->bulk_out_endpointAddress;
-
- pipe = usb_sndbulkpipe(serial->dev, port->bulk_out_endpointAddress);
- for (j = 0; j < ARRAY_SIZE(port->write_urbs); ++j)
- port->write_urbs[j]->pipe = pipe;
-
- return 0;
-}
-
module_usb_serial_driver(serial_drivers, id_table_combined);
MODULE_AUTHOR(DRIVER_AUTHOR);
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/29] USB: serial: mos7840: clean up endpoint sanity check
Clean up the endpoint sanity check by letting core verify the single
interrupt endpoint, and verifying the bulk endpoints in calc_num_ports
after having determined the number of ports.
Note that the static type num_ports field was neither correct or used
(since calc_num_ports never returns zero).
Signed-off-by: Johan Hovold
---
drivers/usb/serial/mos7840.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 326d6c5055ef..770b3a470232 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -2108,23 +2108,23 @@ static int mos7840_calc_num_ports(struct usb_serial
*serial,
struct usb_serial_endpoints *epds)
{
int device_type = (unsigned long)usb_get_serial_data(serial);
- int mos7840_num_ports;
+ int num_ports;
- mos7840_num_ports = (device_type >> 4) & 0x000F;
+ num_ports = (device_type >> 4) & 0x000F;
- return mos7840_num_ports;
-}
+ /*
+* num_ports is currently never zero as device_type is one of
+* MOSCHIP_DEVICE_ID_78{1,2,4}0.
+*/
+ if (num_ports == 0)
+ return -ENODEV;
-static int mos7840_attach(struct usb_serial *serial)
-{
- if (serial->num_bulk_in < serial->num_ports ||
- serial->num_bulk_out < serial->num_ports ||
- serial->num_interrupt_in < 1) {
+ if (epds->num_bulk_in < num_ports || epds->num_bulk_out < num_ports) {
dev_err(&serial->interface->dev, "missing endpoints\n");
return -ENODEV;
}
- return 0;
+ return num_ports;
}
static int mos7840_port_probe(struct usb_serial_port *port)
@@ -2385,7 +2385,7 @@ static struct usb_serial_driver moschip7840_4port_device
= {
},
.description = DRIVER_DESC,
.id_table = id_table,
- .num_ports = 4,
+ .num_interrupt_in = 1,
.open = mos7840_open,
.close = mos7840_close,
.write = mos7840_write,
@@ -2402,7 +2402,6 @@ static struct usb_serial_driver moschip7840_4port_device
= {
.tiocmset = mos7840_tiocmset,
.tiocmiwait = usb_serial_generic_tiocmiwait,
.get_icount = usb_serial_generic_get_icount,
- .attach = mos7840_attach,
.port_probe = mos7840_port_probe,
.port_remove = mos7840_port_remove,
.read_bulk_callback = mos7840_bulk_in_callback,
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/29] USB: serial: omninet: clean up port setup
These devices use the second bulk-out endpoint for writing. Instead of
using the resources of the second port structure setup by core, use the
new endpoint-remap functionality to simply ignore the first bulk-out
endpoint. This specifically avoids allocating resources for the unused
endpoint.
Note that the disconnect callback was always redundant as all URBs would
have been killed by USB core on disconnect.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/omninet.c | 47
1 file changed, 21 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/serial/omninet.c b/drivers/usb/serial/omninet.c
index 7be40dfa3620..558a620d8868 100644
--- a/drivers/usb/serial/omninet.c
+++ b/drivers/usb/serial/omninet.c
@@ -36,7 +36,8 @@ static void omninet_write_bulk_callback(struct urb *urb);
static int omninet_write(struct tty_struct *tty, struct usb_serial_port *port,
const unsigned char *buf, int count);
static int omninet_write_room(struct tty_struct *tty);
-static void omninet_disconnect(struct usb_serial *serial);
+static int omninet_calc_num_ports(struct usb_serial *serial,
+ struct usb_serial_endpoints *epds);
static int omninet_port_probe(struct usb_serial_port *port);
static int omninet_port_remove(struct usb_serial_port *port);
@@ -54,15 +55,14 @@ static struct usb_serial_driver zyxel_omninet_device = {
},
.description = "ZyXEL - omni.net lcd plus usb",
.id_table = id_table,
- .num_ports =1,
.num_bulk_out = 2,
+ .calc_num_ports = omninet_calc_num_ports,
.port_probe = omninet_port_probe,
.port_remove = omninet_port_remove,
.write =omninet_write,
.write_room = omninet_write_room,
.write_bulk_callback = omninet_write_bulk_callback,
.process_read_urb = omninet_process_read_urb,
- .disconnect = omninet_disconnect,
};
static struct usb_serial_driver * const serial_drivers[] = {
@@ -103,6 +103,16 @@ struct omninet_data {
__u8od_outseq; /* Sequence number for bulk_out URBs */
};
+static int omninet_calc_num_ports(struct usb_serial *serial,
+ struct usb_serial_endpoints *epds)
+{
+ /* We need only the second bulk-out for our single-port device. */
+ epds->bulk_out[0] = epds->bulk_out[1];
+ epds->num_bulk_out = 1;
+
+ return 1;
+}
+
static int omninet_port_probe(struct usb_serial_port *port)
{
struct omninet_data *od;
@@ -150,13 +160,9 @@ static void omninet_process_read_urb(struct urb *urb)
static int omninet_write(struct tty_struct *tty, struct usb_serial_port *port,
const unsigned char *buf, int count)
{
- struct usb_serial *serial = port->serial;
- struct usb_serial_port *wport = serial->port[1];
-
struct omninet_data *od = usb_get_serial_port_data(port);
struct omninet_header *header = (struct omninet_header *)
- wport->write_urb->transfer_buffer;
-
+ port->write_urb->transfer_buffer;
int result;
if (count == 0) {
@@ -171,11 +177,11 @@ static int omninet_write(struct tty_struct *tty, struct
usb_serial_port *port,
count = (count > OMNINET_PAYLOADSIZE) ? OMNINET_PAYLOADSIZE : count;
- memcpy(wport->write_urb->transfer_buffer + OMNINET_HEADERLEN,
+ memcpy(port->write_urb->transfer_buffer + OMNINET_HEADERLEN,
buf, count);
usb_serial_debug_data(&port->dev, __func__, count,
- wport->write_urb->transfer_buffer);
+ port->write_urb->transfer_buffer);
header->oh_seq = od->od_outseq++;
header->oh_len = count;
@@ -183,11 +189,11 @@ static int omninet_write(struct tty_struct *tty, struct
usb_serial_port *port,
header->oh_pad = 0x00;
/* send the data out the bulk port, always 64 bytes */
- wport->write_urb->transfer_buffer_length = OMNINET_BULKOUTSIZE;
+ port->write_urb->transfer_buffer_length = OMNINET_BULKOUTSIZE;
- result = usb_submit_urb(wport->write_urb, GFP_ATOMIC);
+ result = usb_submit_urb(port->write_urb, GFP_ATOMIC);
if (result) {
- set_bit(0, &wport->write_urbs_free);
+ set_bit(0, &port->write_urbs_free);
dev_err_console(port,
"%s - failed submitting write urb, error %d\n",
__func__, result);
@@ -201,13 +207,10 @@ static int omninet_write(struct tty_struct *tty, struct
usb_serial_port *port,
static int omninet_write_room(struct tty_struct *tty)
{
struct usb_serial_port *port = tty->driver_data;
-
[PATCH 04/29] USB: serial: relax generic driver bulk-endpoint requirement
Relax the generic driver bulk-endpoint requirement. The driver handles
devices without bulk-out endpoints just fine these days.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/generic.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 2d3599f014e2..35cb8c0e584f 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -52,10 +52,12 @@ static int usb_serial_generic_calc_num_ports(struct
usb_serial *serial,
struct usb_serial_endpoints *epds)
{
struct device *dev = &serial->interface->dev;
- int num_ports = epds->num_bulk_out;
+ int num_ports;
+
+ num_ports = max(epds->num_bulk_in, epds->num_bulk_out);
if (num_ports == 0) {
- dev_err(dev, "Generic device with no bulk out, not allowed.\n");
+ dev_err(dev, "device has no bulk endpoints\n");
return -ENODEV;
}
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/29] USB: serial: io_ti: use calc_num_endpoints to verify endpoints
Use the calc_num_ports rather than attach callback to verify that the
required endpoints are present when in download mode.
This avoids allocating port resources for interfaces that won't be bound.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/io_ti.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index a76b95d32157..989795ab064a 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -2544,19 +2544,30 @@ static void edge_heartbeat_work(struct work_struct
*work)
edge_heartbeat_schedule(serial);
}
-static int edge_startup(struct usb_serial *serial)
+static int edge_calc_num_ports(struct usb_serial *serial,
+ struct usb_serial_endpoints *epds)
{
- struct edgeport_serial *edge_serial;
- int status;
- u16 product_id;
+ struct device *dev = &serial->interface->dev;
+ unsigned char num_ports = serial->type->num_ports;
/* Make sure we have the required endpoints when in download mode. */
if (serial->interface->cur_altsetting->desc.bNumEndpoints > 1) {
- if (serial->num_bulk_in < serial->num_ports ||
- serial->num_bulk_out < serial->num_ports)
+ if (epds->num_bulk_in < num_ports ||
+ epds->num_bulk_out < num_ports) {
+ dev_err(dev, "required endpoints missing\n");
return -ENODEV;
+ }
}
+ return num_ports;
+}
+
+static int edge_startup(struct usb_serial *serial)
+{
+ struct edgeport_serial *edge_serial;
+ int status;
+ u16 product_id;
+
/* create our private serial structure */
edge_serial = kzalloc(sizeof(struct edgeport_serial), GFP_KERNEL);
if (!edge_serial)
@@ -2741,6 +2752,7 @@ static struct usb_serial_driver edgeport_1port_device = {
.throttle = edge_throttle,
.unthrottle = edge_unthrottle,
.attach = edge_startup,
+ .calc_num_ports = edge_calc_num_ports,
.disconnect = edge_disconnect,
.release= edge_release,
.port_probe = edge_port_probe,
@@ -2778,6 +2790,7 @@ static struct usb_serial_driver edgeport_2port_device = {
.throttle = edge_throttle,
.unthrottle = edge_unthrottle,
.attach = edge_startup,
+ .calc_num_ports = edge_calc_num_ports,
.disconnect = edge_disconnect,
.release= edge_release,
.port_probe = edge_port_probe,
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/29] USB: serial: f81534: use calc_num_endpoints to verify endpoints
Simplify the endpoint sanity check by letting core verify that the
required endpoints are present and moving the max-packet check to
calc_num_ports.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/f81534.c | 55 +
1 file changed, 11 insertions(+), 44 deletions(-)
diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c
index 385087c008ed..a4b1fea4453e 100644
--- a/drivers/usb/serial/f81534.c
+++ b/drivers/usb/serial/f81534.c
@@ -614,12 +614,21 @@ static int f81534_find_config_idx(struct usb_serial
*serial, u8 *index)
static int f81534_calc_num_ports(struct usb_serial *serial,
struct usb_serial_endpoints *epds)
{
+ struct device *dev = &serial->interface->dev;
+ int size_bulk_in = usb_endpoint_maxp(epds->bulk_in[0]);
+ int size_bulk_out = usb_endpoint_maxp(epds->bulk_out[0]);
u8 setting[F81534_CUSTOM_DATA_SIZE];
u8 setting_idx;
u8 num_port = 0;
int status;
size_t i;
+ if (size_bulk_out != F81534_WRITE_BUFFER_SIZE ||
+ size_bulk_in != F81534_MAX_RECEIVE_BLOCK_SIZE) {
+ dev_err(dev, "unsupported endpoint max packet size\n");
+ return -ENODEV;
+ }
+
/* Check had custom setting */
status = f81534_find_config_idx(serial, &setting_idx);
if (status) {
@@ -1115,49 +1124,6 @@ static int f81534_setup_ports(struct usb_serial *serial)
return 0;
}
-static int f81534_probe(struct usb_serial *serial,
- const struct usb_device_id *id)
-{
- struct usb_endpoint_descriptor *endpoint;
- struct usb_host_interface *iface_desc;
- struct device *dev;
- int num_bulk_in = 0;
- int num_bulk_out = 0;
- int size_bulk_in = 0;
- int size_bulk_out = 0;
- int i;
-
- dev = &serial->interface->dev;
- iface_desc = serial->interface->cur_altsetting;
-
- for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
- endpoint = &iface_desc->endpoint[i].desc;
-
- if (usb_endpoint_is_bulk_in(endpoint)) {
- ++num_bulk_in;
- size_bulk_in = usb_endpoint_maxp(endpoint);
- }
-
- if (usb_endpoint_is_bulk_out(endpoint)) {
- ++num_bulk_out;
- size_bulk_out = usb_endpoint_maxp(endpoint);
- }
- }
-
- if (num_bulk_in != 1 || num_bulk_out != 1) {
- dev_err(dev, "expected endpoints not found\n");
- return -ENODEV;
- }
-
- if (size_bulk_out != F81534_WRITE_BUFFER_SIZE ||
- size_bulk_in != F81534_MAX_RECEIVE_BLOCK_SIZE) {
- dev_err(dev, "unsupported endpoint max packet size\n");
- return -ENODEV;
- }
-
- return 0;
-}
-
static int f81534_attach(struct usb_serial *serial)
{
struct f81534_serial_private *serial_priv;
@@ -1381,12 +1347,13 @@ static struct usb_serial_driver f81534_device = {
},
.description = DRIVER_DESC,
.id_table = f81534_id_table,
+ .num_bulk_in = 1,
+ .num_bulk_out = 1,
.open = f81534_open,
.close =f81534_close,
.write =f81534_write,
.tx_empty = f81534_tx_empty,
.calc_num_ports = f81534_calc_num_ports,
- .probe =f81534_probe,
.attach = f81534_attach,
.port_probe = f81534_port_probe,
.dtr_rts = f81534_dtr_rts,
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/29] USB: serial: ipaq: use calc_num_endpoints to verify endpoints
Use the calc_num_ports rather than attach callback to determine which
interface to bind to in order to avoid allocating port-resources for
interfaces that won't be bound.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ipaq.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/ipaq.c b/drivers/usb/serial/ipaq.c
index df5f1a7d7c6f..c638571f0175 100644
--- a/drivers/usb/serial/ipaq.c
+++ b/drivers/usb/serial/ipaq.c
@@ -574,20 +574,22 @@ static int ipaq_calc_num_ports(struct usb_serial *serial,
ipaq_num_ports = 2;
}
+ /*
+* Some of the devices in ipaq_id_table[] are composite, and we
+* shouldn't bind to all the interfaces. This test will rule out
+* some obviously invalid possibilities.
+*/
+ if (epds->num_bulk_in < ipaq_num_ports ||
+ epds->num_bulk_out < ipaq_num_ports) {
+ return -ENODEV;
+ }
+
return ipaq_num_ports;
}
static int ipaq_startup(struct usb_serial *serial)
{
- /* Some of the devices in ipaq_id_table[] are composite, and we
-* shouldn't bind to all the interfaces. This test will rule out
-* some obviously invalid possibilities.
-*/
- if (serial->num_bulk_in < serial->num_ports ||
- serial->num_bulk_out < serial->num_ports)
- return -ENODEV;
-
if (serial->dev->actconfig->desc.bConfigurationValue != 1) {
/*
* FIXME: HP iPaq rx3715, possibly others, have 1 config that
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/29] USB: serial: f81534: abort probe on early errors
We can now abort probe early after an error in calc_num_ports by
returning an errno instead of attempting to continue probing but not
register any ports.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/f81534.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c
index a4b1fea4453e..be106f4e3e57 100644
--- a/drivers/usb/serial/f81534.c
+++ b/drivers/usb/serial/f81534.c
@@ -634,7 +634,7 @@ static int f81534_calc_num_ports(struct usb_serial *serial,
if (status) {
dev_err(&serial->interface->dev, "%s: find idx failed: %d\n",
__func__, status);
- return 0;
+ return status;
}
/*
@@ -650,7 +650,7 @@ static int f81534_calc_num_ports(struct usb_serial *serial,
dev_err(&serial->interface->dev,
"%s: get custom data failed: %d\n",
__func__, status);
- return 0;
+ return status;
}
dev_dbg(&serial->interface->dev,
@@ -666,7 +666,7 @@ static int f81534_calc_num_ports(struct usb_serial *serial,
dev_err(&serial->interface->dev,
"%s: read failed: %d\n", __func__,
status);
- return 0;
+ return status;
}
dev_dbg(&serial->interface->dev, "%s: read default config\n",
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 26/29] USB: serial: mxuport: add endpoint sanity check
Add an explicit sanity check to make sure we have the expected
endpoints. This will provide a descriptive error message in case an
expected endpoint is missing when probing.
Note that the driver already gracefully fails to probe (albeit with a
less descriptive error message) if a bulk-in endpoint is missing, and an
attempt to write to a port whose device lack a bulk-out endpoint would
fail with -ENODEV.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/mxuport.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/mxuport.c b/drivers/usb/serial/mxuport.c
index 3355737cbfd1..34142feffd4d 100644
--- a/drivers/usb/serial/mxuport.c
+++ b/drivers/usb/serial/mxuport.c
@@ -1373,6 +1373,8 @@ static struct usb_serial_driver mxuport_device = {
},
.description= "MOXA UPort",
.id_table = mxuport_idtable,
+ .num_bulk_in= 2,
+ .num_bulk_out = 1,
.probe = mxuport_probe,
.port_probe = mxuport_port_probe,
.attach = mxuport_attach,
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/29] USB: serial: add calc_num_ports callback to generic driver
Add a calc_num_ports callback to the generic driver and verify that the
device has the required endpoints there instead of in core.
Note that the generic driver num_ports field was never used.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/generic.c| 18 --
drivers/usb/serial/usb-serial.c | 27 ---
include/linux/usb/serial.h | 1 -
3 files changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 8c7600472019..2d3599f014e2 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -48,14 +48,28 @@ static int usb_serial_generic_probe(struct usb_serial
*serial,
return 0;
}
-struct usb_serial_driver usb_serial_generic_device = {
+static int usb_serial_generic_calc_num_ports(struct usb_serial *serial,
+ struct usb_serial_endpoints *epds)
+{
+ struct device *dev = &serial->interface->dev;
+ int num_ports = epds->num_bulk_out;
+
+ if (num_ports == 0) {
+ dev_err(dev, "Generic device with no bulk out, not allowed.\n");
+ return -ENODEV;
+ }
+
+ return num_ports;
+}
+
+static struct usb_serial_driver usb_serial_generic_device = {
.driver = {
.owner =THIS_MODULE,
.name = "generic",
},
.id_table = generic_device_ids,
- .num_ports =1,
.probe =usb_serial_generic_probe,
+ .calc_num_ports = usb_serial_generic_calc_num_ports,
.throttle = usb_serial_generic_throttle,
.unthrottle = usb_serial_generic_unthrottle,
.resume = usb_serial_generic_resume,
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index f8ae09e2cff5..101eb105d78e 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -850,28 +850,17 @@ static int usb_serial_probe(struct usb_interface
*interface,
retval = -ENODEV;
goto err_free_epds;
}
-#ifdef CONFIG_USB_SERIAL_GENERIC
- if (type == &usb_serial_generic_device) {
- num_ports = epds->num_bulk_out;
- if (num_ports == 0) {
- dev_err(ddev, "Generic device with no bulk out, not
allowed.\n");
- retval = -EIO;
+
+ if (type->calc_num_ports) {
+ retval = type->calc_num_ports(serial, epds);
+ if (retval < 0)
goto err_free_epds;
- }
- }
-#endif
- if (!num_ports) {
- /* if this device type has a calc_num_ports function, call it */
- if (type->calc_num_ports) {
- retval = type->calc_num_ports(serial, epds);
- if (retval < 0)
- goto err_free_epds;
- num_ports = retval;
- }
- if (!num_ports)
- num_ports = type->num_ports;
+ num_ports = retval;
}
+ if (!num_ports)
+ num_ports = type->num_ports;
+
if (num_ports > MAX_NUM_PORTS) {
dev_warn(ddev, "too many ports requested: %d\n", num_ports);
num_ports = MAX_NUM_PORTS;
diff --git a/include/linux/usb/serial.h b/include/linux/usb/serial.h
index da528818cfd8..e2f0ab07eea5 100644
--- a/include/linux/usb/serial.h
+++ b/include/linux/usb/serial.h
@@ -379,7 +379,6 @@ extern void usb_serial_handle_dcd_change(struct
usb_serial_port *usb_port,
extern int usb_serial_bus_register(struct usb_serial_driver *device);
extern void usb_serial_bus_deregister(struct usb_serial_driver *device);
-extern struct usb_serial_driver usb_serial_generic_device;
extern struct bus_type usb_serial_bus_type;
extern struct tty_driver *usb_serial_tty_driver;
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/29] USB: serial: move pl2303 hack out of usb-serial core
Some pl2303 devices require the use of the interrupt endpoint of an
unrelated interface. This has so far been dealt with in usb-serial core,
but can now be moved to a driver calc_num_ports callback.
Note that we relax the endpoint requirements checked by core and instead
verify that we have an interrupt-in endpoint in calc_num_ports for all
devices so that the hack can first be applied.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/pl2303.c | 57 +++--
drivers/usb/serial/usb-serial.c | 40 -
2 files changed, 55 insertions(+), 42 deletions(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 60840004568a..b8edd7bc71f2 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -218,6 +218,59 @@ static int pl2303_probe(struct usb_serial *serial,
return 0;
}
+static int pl2303_calc_num_ports(struct usb_serial *serial,
+ struct usb_serial_endpoints *epds)
+{
+ struct usb_interface *interface = serial->interface;
+ struct usb_device *dev = serial->dev;
+ struct device *ddev = &interface->dev;
+ struct usb_host_interface *iface_desc;
+ struct usb_endpoint_descriptor *endpoint;
+ unsigned int i;
+
+ /* BEGIN HORRIBLE HACK FOR PL2303 */
+ /* this is needed due to the looney way its endpoints are set up */
+ if (((le16_to_cpu(dev->descriptor.idVendor) == PL2303_VENDOR_ID) &&
+(le16_to_cpu(dev->descriptor.idProduct) == PL2303_PRODUCT_ID)) ||
+ ((le16_to_cpu(dev->descriptor.idVendor) == ATEN_VENDOR_ID) &&
+(le16_to_cpu(dev->descriptor.idProduct) == ATEN_PRODUCT_ID)) ||
+ ((le16_to_cpu(dev->descriptor.idVendor) == ALCOR_VENDOR_ID) &&
+(le16_to_cpu(dev->descriptor.idProduct) == ALCOR_PRODUCT_ID)) ||
+ ((le16_to_cpu(dev->descriptor.idVendor) == SIEMENS_VENDOR_ID) &&
+(le16_to_cpu(dev->descriptor.idProduct) ==
SIEMENS_PRODUCT_ID_EF81))) {
+ if (interface != dev->actconfig->interface[0]) {
+ /* check out the endpoints of the other interface*/
+ iface_desc =
dev->actconfig->interface[0]->cur_altsetting;
+ for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
+ endpoint = &iface_desc->endpoint[i].desc;
+ if (usb_endpoint_is_int_in(endpoint)) {
+ /* we found a interrupt in endpoint */
+ dev_dbg(ddev, "found interrupt in for
Prolific device on separate interface\n");
+ if (epds->num_interrupt_in <
ARRAY_SIZE(epds->interrupt_in))
+
epds->interrupt_in[epds->num_interrupt_in++] = endpoint;
+ }
+ }
+ }
+
+ /* Now make sure the PL-2303 is configured correctly.
+* If not, give up now and hope this hack will work
+* properly during a later invocation of usb_serial_probe
+*/
+ if (epds->num_bulk_in == 0 || epds->num_bulk_out == 0) {
+ dev_info(ddev, "PL-2303 hack: descriptors matched but
endpoints did not\n");
+ return -ENODEV;
+ }
+ }
+ /* END HORRIBLE HACK FOR PL2303 */
+
+ if (epds->num_interrupt_in < 1) {
+ dev_err(ddev, "required interrupt-in endpoint missing\n");
+ return -ENODEV;
+ }
+
+ return 1;
+}
+
static int pl2303_startup(struct usb_serial *serial)
{
struct pl2303_serial_private *spriv;
@@ -930,10 +983,9 @@ static struct usb_serial_driver pl2303_device = {
.name = "pl2303",
},
.id_table = id_table,
- .num_ports =1,
.num_bulk_in = 1,
.num_bulk_out = 1,
- .num_interrupt_in = 1,
+ .num_interrupt_in = 0, /* see pl2303_calc_num_ports */
.bulk_in_size = 256,
.bulk_out_size =256,
.open = pl2303_open,
@@ -949,6 +1001,7 @@ static struct usb_serial_driver pl2303_device = {
.process_read_urb = pl2303_process_read_urb,
.read_int_callback =pl2303_read_int_callback,
.probe =pl2303_probe,
+ .calc_num_ports = pl2303_calc_num_ports,
.attach = pl2303_startup,
.release = pl2303_release,
.port_probe = pl2303_port_probe,
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index 101eb105d78e..0fa2030c275c 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include "pl2303.
[PATCH 01/29] USB: serial: allow subdrivers to modify port-endpoint mapping
Allow subdrivers to modify the port-endpoint mapping by passing the
endpoint descriptors to calc_num_ports.
The callback can now also be used to verify that the required endpoints
exists and abort probing otherwise.
This will allow us to get rid of a few hacks in subdrivers that are
already modifying the port-endpoint mapping (or aborting probe due to
missing endpoints), but only after the port structures have been setup.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/f81534.c | 3 ++-
drivers/usb/serial/ipaq.c | 6 --
drivers/usb/serial/mos7720.c| 3 ++-
drivers/usb/serial/mos7840.c| 3 ++-
drivers/usb/serial/mxuport.c| 3 ++-
drivers/usb/serial/quatech2.c | 3 ++-
drivers/usb/serial/sierra.c | 3 ++-
drivers/usb/serial/usb-serial.c | 19 ++-
drivers/usb/serial/visor.c | 6 --
include/linux/usb/serial.h | 19 ---
10 files changed, 42 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c
index 22f23a429a95..385087c008ed 100644
--- a/drivers/usb/serial/f81534.c
+++ b/drivers/usb/serial/f81534.c
@@ -611,7 +611,8 @@ static int f81534_find_config_idx(struct usb_serial
*serial, u8 *index)
* The f81534_calc_num_ports() will run to "new style" with checking
* F81534_PORT_UNAVAILABLE section.
*/
-static int f81534_calc_num_ports(struct usb_serial *serial)
+static int f81534_calc_num_ports(struct usb_serial *serial,
+ struct usb_serial_endpoints *epds)
{
u8 setting[F81534_CUSTOM_DATA_SIZE];
u8 setting_idx;
diff --git a/drivers/usb/serial/ipaq.c b/drivers/usb/serial/ipaq.c
index ec1b8f2c1183..df5f1a7d7c6f 100644
--- a/drivers/usb/serial/ipaq.c
+++ b/drivers/usb/serial/ipaq.c
@@ -33,7 +33,8 @@ static int initial_wait;
/* Function prototypes for an ipaq */
static int ipaq_open(struct tty_struct *tty,
struct usb_serial_port *port);
-static int ipaq_calc_num_ports(struct usb_serial *serial);
+static int ipaq_calc_num_ports(struct usb_serial *serial,
+ struct usb_serial_endpoints *epds);
static int ipaq_startup(struct usb_serial *serial);
static const struct usb_device_id ipaq_id_table[] = {
@@ -550,7 +551,8 @@ static int ipaq_open(struct tty_struct *tty,
return usb_serial_generic_open(tty, port);
}
-static int ipaq_calc_num_ports(struct usb_serial *serial)
+static int ipaq_calc_num_ports(struct usb_serial *serial,
+ struct usb_serial_endpoints *epds)
{
/*
* some devices have 3 endpoints, the 3rd of which
diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c
index df45ebad5f6f..9ec3e4fb9678 100644
--- a/drivers/usb/serial/mos7720.c
+++ b/drivers/usb/serial/mos7720.c
@@ -973,7 +973,8 @@ static void mos7720_bulk_out_data_callback(struct urb *urb)
tty_port_tty_wakeup(&mos7720_port->port->port);
}
-static int mos77xx_calc_num_ports(struct usb_serial *serial)
+static int mos77xx_calc_num_ports(struct usb_serial *serial,
+ struct usb_serial_endpoints *epds)
{
u16 product = le16_to_cpu(serial->dev->descriptor.idProduct);
if (product == MOSCHIP_DEVICE_ID_7715)
diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 3821c53fcee9..326d6c5055ef 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -2104,7 +2104,8 @@ static int mos7840_probe(struct usb_serial *serial,
return 0;
}
-static int mos7840_calc_num_ports(struct usb_serial *serial)
+static int mos7840_calc_num_ports(struct usb_serial *serial,
+ struct usb_serial_endpoints *epds)
{
int device_type = (unsigned long)usb_get_serial_data(serial);
int mos7840_num_ports;
diff --git a/drivers/usb/serial/mxuport.c b/drivers/usb/serial/mxuport.c
index c88215a0fa3d..bf543e6c05ea 100644
--- a/drivers/usb/serial/mxuport.c
+++ b/drivers/usb/serial/mxuport.c
@@ -946,7 +946,8 @@ static void mxuport_set_termios(struct tty_struct *tty,
* Determine how many ports this device has dynamically. It will be
* called after the probe() callback is called, but before attach().
*/
-static int mxuport_calc_num_ports(struct usb_serial *serial)
+static int mxuport_calc_num_ports(struct usb_serial *serial,
+ struct usb_serial_endpoints *epds)
{
unsigned long features = (unsigned long)usb_get_serial_data(serial);
diff --git a/drivers/usb/serial/quatech2.c b/drivers/usb/serial/quatech2.c
index fdbb904d153f..6ddcaa2de902 100644
--- a/drivers/usb/serial/quatech2.c
+++ b/drivers/usb/serial/quatech2.c
@@ -246,7 +246,8 @@ static inline int update_mctrl(struct qt2_port_private
*port_priv,
return status;
}
-static int qt2_calc_num_ports(struct usb_serial *serial)
+static int qt2_calc_num_ports(struct usb_s
[PATCH 29/29] USB: serial: f81534: clean up port bulk-out setup
Setup each port to use the first bulk-out endpoint in calc_num_ports so
that core allocates the corresponding port resources for us.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/f81534.c | 62 -
1 file changed, 11 insertions(+), 51 deletions(-)
diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c
index 365e3acd6c6c..3d616a2a9f96 100644
--- a/drivers/usb/serial/f81534.c
+++ b/drivers/usb/serial/f81534.c
@@ -687,6 +687,17 @@ static int f81534_calc_num_ports(struct usb_serial *serial,
num_port = 4; /* Nothing found, oldest version IC */
}
+ /*
+* Setup bulk-out endpoint multiplexing. All ports share the same
+* bulk-out endpoint.
+*/
+ BUILD_BUG_ON(ARRAY_SIZE(epds->bulk_out) < F81534_NUM_PORT);
+
+ for (i = 1; i < num_port; ++i)
+ epds->bulk_out[i] = epds->bulk_out[0];
+
+ epds->num_bulk_out = num_port;
+
return num_port;
}
@@ -1078,53 +1089,6 @@ static void f81534_write_usb_callback(struct urb *urb)
}
}
-static int f81534_setup_ports(struct usb_serial *serial)
-{
- struct usb_serial_port *port;
- u8 port0_out_address;
- int buffer_size;
- size_t i;
-
- /*
-* In our system architecture, we had 2 or 4 serial ports,
-* but only get 1 set of bulk in/out endpoints.
-*
-* The usb-serial subsystem will generate port 0 data,
-* but port 1/2/3 will not. It's will generate write URB and buffer
-* by following code and use the port0 read URB for read operation.
-*/
- for (i = 1; i < serial->num_ports; ++i) {
- port0_out_address = serial->port[0]->bulk_out_endpointAddress;
- buffer_size = serial->port[0]->bulk_out_size;
- port = serial->port[i];
-
- if (kfifo_alloc(&port->write_fifo, PAGE_SIZE, GFP_KERNEL))
- return -ENOMEM;
-
- port->bulk_out_size = buffer_size;
- port->bulk_out_endpointAddress = port0_out_address;
-
- port->write_urbs[0] = usb_alloc_urb(0, GFP_KERNEL);
- if (!port->write_urbs[0])
- return -ENOMEM;
-
- port->bulk_out_buffers[0] = kzalloc(buffer_size, GFP_KERNEL);
- if (!port->bulk_out_buffers[0])
- return -ENOMEM;
-
- usb_fill_bulk_urb(port->write_urbs[0], serial->dev,
- usb_sndbulkpipe(serial->dev,
- port0_out_address),
- port->bulk_out_buffers[0], buffer_size,
- serial->type->write_bulk_callback, port);
-
- port->write_urb = port->write_urbs[0];
- port->bulk_out_buffer = port->bulk_out_buffers[0];
- }
-
- return 0;
-}
-
static int f81534_attach(struct usb_serial *serial)
{
struct f81534_serial_private *serial_priv;
@@ -1141,10 +1105,6 @@ static int f81534_attach(struct usb_serial *serial)
mutex_init(&serial_priv->urb_mutex);
- status = f81534_setup_ports(serial);
- if (status)
- return status;
-
/* Check had custom setting */
status = f81534_find_config_idx(serial, &serial_priv->setting_idx);
if (status) {
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/29] USB: serial: aircable: use calc_num_endpoints to verify endpoints
Use the calc_num_ports rather than probe callback to determine which
interface to bind to.
This allows us to remove some duplicate code.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/aircable.c | 36
1 file changed, 8 insertions(+), 28 deletions(-)
diff --git a/drivers/usb/serial/aircable.c b/drivers/usb/serial/aircable.c
index 80a9845cd93f..569c2200ba42 100644
--- a/drivers/usb/serial/aircable.c
+++ b/drivers/usb/serial/aircable.c
@@ -29,12 +29,6 @@
* is any other control code, I will simply check for the first
* one.
*
- * The driver registers himself with the USB-serial core and the USB Core. I
had
- * to implement a probe function against USB-serial, because other way, the
- * driver was attaching himself to both interfaces. I have tried with different
- * configurations of usb_serial_driver with out exit, only the probe function
- * could handle this correctly.
- *
* I have taken some info from a Greg Kroah-Hartman article:
* http://www.linuxjournal.com/article/6573
* And from Linux Device Driver Kit CD, which is a great work, the authors
taken
@@ -93,30 +87,17 @@ static int aircable_prepare_write_buffer(struct
usb_serial_port *port,
return count + HCI_HEADER_LENGTH;
}
-static int aircable_probe(struct usb_serial *serial,
- const struct usb_device_id *id)
+static int aircable_calc_num_ports(struct usb_serial *serial,
+ struct usb_serial_endpoints *epds)
{
- struct usb_host_interface *iface_desc = serial->interface->
- cur_altsetting;
- struct usb_endpoint_descriptor *endpoint;
- int num_bulk_out = 0;
- int i;
-
- for (i = 0; i < iface_desc->desc.bNumEndpoints; i++) {
- endpoint = &iface_desc->endpoint[i].desc;
- if (usb_endpoint_is_bulk_out(endpoint)) {
- dev_dbg(&serial->dev->dev,
- "found bulk out on endpoint %d\n", i);
- ++num_bulk_out;
- }
- }
-
- if (num_bulk_out == 0) {
- dev_dbg(&serial->dev->dev, "Invalid interface, discarding\n");
+ /* Ignore the first interface, which has no bulk endpoints. */
+ if (epds->num_bulk_out == 0) {
+ dev_dbg(&serial->interface->dev,
+ "ignoring interface with no bulk-out endpoints\n");
return -ENODEV;
}
- return 0;
+ return 1;
}
static int aircable_process_packet(struct usb_serial_port *port,
@@ -164,9 +145,8 @@ static struct usb_serial_driver aircable_device = {
.name = "aircable",
},
.id_table = id_table,
- .num_ports =1,
.bulk_out_size =HCI_COMPLETE_FRAME,
- .probe =aircable_probe,
+ .calc_num_ports = aircable_calc_num_ports,
.process_read_urb = aircable_process_read_urb,
.prepare_write_buffer = aircable_prepare_write_buffer,
.throttle = usb_serial_generic_throttle,
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 24/29] USB: serial: visor: clean up treo endpoint hack
Use the new endpoint-remap functionality to configure the ports for
treo devices instead of poking around in the port structures after the
ports have been setup.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/visor.c | 82 ++
1 file changed, 24 insertions(+), 58 deletions(-)
diff --git a/drivers/usb/serial/visor.c b/drivers/usb/serial/visor.c
index 41d135f46fa0..9f3317a940ef 100644
--- a/drivers/usb/serial/visor.c
+++ b/drivers/usb/serial/visor.c
@@ -46,7 +46,6 @@ static int clie_5_calc_num_ports(struct usb_serial *serial,
struct usb_serial_endpoints *epds);
static void visor_read_int_callback(struct urb *urb);
static int clie_3_5_startup(struct usb_serial *serial);
-static int treo_attach(struct usb_serial *serial);
static int palm_os_3_probe(struct usb_serial *serial,
const struct usb_device_id *id);
static int palm_os_4_probe(struct usb_serial *serial,
@@ -176,7 +175,6 @@ static struct usb_serial_driver handspring_device = {
.close =visor_close,
.throttle = usb_serial_generic_throttle,
.unthrottle = usb_serial_generic_unthrottle,
- .attach = treo_attach,
.probe =visor_probe,
.calc_num_ports = visor_calc_num_ports,
.read_int_callback =visor_read_int_callback,
@@ -471,11 +469,35 @@ static int visor_probe(struct usb_serial *serial,
static int visor_calc_num_ports(struct usb_serial *serial,
struct usb_serial_endpoints *epds)
{
+ unsigned int vid = le16_to_cpu(serial->dev->descriptor.idVendor);
int num_ports = (int)(long)(usb_get_serial_data(serial));
if (num_ports)
usb_set_serial_data(serial, NULL);
+ /*
+* Only swap the bulk endpoints for the Handspring devices with
+* interrupt in endpoints, which for now are the Treo devices.
+*/
+ if (!(vid == HANDSPRING_VENDOR_ID || vid == KYOCERA_VENDOR_ID) ||
+ epds->num_interrupt_in == 0)
+ goto out;
+
+ if (epds->num_bulk_in < 2 || epds->num_interrupt_in < 2) {
+ dev_err(&serial->interface->dev, "missing endpoints\n");
+ return -ENODEV;
+ }
+
+ /*
+* It appears that Treos and Kyoceras want to use the
+* 1st bulk in endpoint to communicate with the 2nd bulk out endpoint,
+* so let's swap the 1st and 2nd bulk in and interrupt endpoints.
+* Note that swapping the bulk out endpoints would break lots of
+* apps that want to communicate on the second port.
+*/
+ swap(epds->bulk_in[0], epds->bulk_in[1]);
+ swap(epds->interrupt_in[0], epds->interrupt_in[1]);
+out:
return num_ports;
}
@@ -553,62 +575,6 @@ static int clie_3_5_startup(struct usb_serial *serial)
return result;
}
-static int treo_attach(struct usb_serial *serial)
-{
- struct usb_serial_port *swap_port;
-
- /* Only do this endpoint hack for the Handspring devices with
-* interrupt in endpoints, which for now are the Treo devices. */
- if (!((le16_to_cpu(serial->dev->descriptor.idVendor)
- == HANDSPRING_VENDOR_ID) ||
- (le16_to_cpu(serial->dev->descriptor.idVendor)
- == KYOCERA_VENDOR_ID)) ||
- (serial->num_interrupt_in == 0))
- return 0;
-
- if (serial->num_bulk_in < 2 || serial->num_interrupt_in < 2) {
- dev_err(&serial->interface->dev, "missing endpoints\n");
- return -ENODEV;
- }
-
- /*
- * It appears that Treos and Kyoceras want to use the
- * 1st bulk in endpoint to communicate with the 2nd bulk out endpoint,
- * so let's swap the 1st and 2nd bulk in and interrupt endpoints.
- * Note that swapping the bulk out endpoints would break lots of
- * apps that want to communicate on the second port.
- */
-#define COPY_PORT(dest, src) \
- do { \
- int i; \
- \
- for (i = 0; i < ARRAY_SIZE(src->read_urbs); ++i) { \
- dest->read_urbs[i] = src->read_urbs[i]; \
- dest->read_urbs[i]->context = dest; \
- dest->bulk_in_buffers[i] = src->bulk_in_buffers[i]; \
- } \
- dest->read_urb = src->read_urb; \
- dest->bulk_in_endpointAddress = src->bulk_in_endpointAddress;\
- dest->bulk_in_buffer = src->bulk_in_buffer; \
-
[PATCH 11/29] USB: serial: ipaq: always register a single port
Use the calc_num_ports callback to ignore unused endpoints.
The driver binds to any interface with at least one bulk-in and one
bulk-out endpoint, but some devices can have three or more endpoints of
which only either the first or second pair of endpoints is needed.
This avoids allocating resources for unused endpoints, and specifically
a port is no longer registered for the unused first endpoint pair when
there are more than three endpoints.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ipaq.c | 41 +++--
1 file changed, 15 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/serial/ipaq.c b/drivers/usb/serial/ipaq.c
index c638571f0175..cde0dcdce9c4 100644
--- a/drivers/usb/serial/ipaq.c
+++ b/drivers/usb/serial/ipaq.c
@@ -555,39 +555,32 @@ static int ipaq_calc_num_ports(struct usb_serial *serial,
struct usb_serial_endpoints *epds)
{
/*
-* some devices have 3 endpoints, the 3rd of which
-* must be ignored as it would make the core
-* create a second port which oopses when used
+* Some of the devices in ipaq_id_table[] are composite, and we
+* shouldn't bind to all the interfaces. This test will rule out
+* some obviously invalid possibilities.
*/
- int ipaq_num_ports = 1;
-
- dev_dbg(&serial->dev->dev, "%s - numberofendpoints: %d\n", __func__,
- (int)serial->interface->cur_altsetting->desc.bNumEndpoints);
+ if (epds->num_bulk_in == 0 || epds->num_bulk_out == 0)
+ return -ENODEV;
/*
-* a few devices have 4 endpoints, seemingly Yakuma devices,
-* and we need the second pair, so let them have 2 ports
-*
-* TODO: can we drop port 1 ?
+* A few devices have four endpoints, seemingly Yakuma devices, and
+* we need the second pair.
*/
- if (serial->interface->cur_altsetting->desc.bNumEndpoints > 3) {
- ipaq_num_ports = 2;
+ if (epds->num_bulk_in > 1 && epds->num_bulk_out > 1) {
+ epds->bulk_in[0] = epds->bulk_in[1];
+ epds->bulk_out[0] = epds->bulk_out[1];
}
/*
-* Some of the devices in ipaq_id_table[] are composite, and we
-* shouldn't bind to all the interfaces. This test will rule out
-* some obviously invalid possibilities.
+* Other devices have 3 endpoints, but we only use the first bulk in
+* and out endpoints.
*/
- if (epds->num_bulk_in < ipaq_num_ports ||
- epds->num_bulk_out < ipaq_num_ports) {
- return -ENODEV;
- }
+ epds->num_bulk_in = 1;
+ epds->num_bulk_out = 1;
- return ipaq_num_ports;
+ return 1;
}
-
static int ipaq_startup(struct usb_serial *serial)
{
if (serial->dev->actconfig->desc.bConfigurationValue != 1) {
@@ -601,10 +594,6 @@ static int ipaq_startup(struct usb_serial *serial)
return -ENODEV;
}
- dev_dbg(&serial->dev->dev,
- "%s - iPAQ module configured for %d ports\n", __func__,
- serial->num_ports);
-
return usb_reset_configuration(serial->dev);
}
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 27/29] USB: serial: mxuport: clean up port bulk-out setup
Setup each port to use the first bulk-out endpoint in calc_num_ports so
that core allocates the corresponding port resources for us.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/mxuport.c | 103 +--
1 file changed, 12 insertions(+), 91 deletions(-)
diff --git a/drivers/usb/serial/mxuport.c b/drivers/usb/serial/mxuport.c
index 34142feffd4d..3aef091fe88b 100644
--- a/drivers/usb/serial/mxuport.c
+++ b/drivers/usb/serial/mxuport.c
@@ -951,6 +951,7 @@ static int mxuport_calc_num_ports(struct usb_serial *serial,
{
unsigned long features = (unsigned long)usb_get_serial_data(serial);
int num_ports;
+ int i;
if (features & MX_UPORT_2_PORT) {
num_ports = 2;
@@ -966,6 +967,17 @@ static int mxuport_calc_num_ports(struct usb_serial
*serial,
num_ports = 2;
}
+ /*
+* Setup bulk-out endpoint multiplexing. All ports share the same
+* bulk-out endpoint.
+*/
+ BUILD_BUG_ON(ARRAY_SIZE(epds->bulk_out) < 16);
+
+ for (i = 1; i < num_ports; ++i)
+ epds->bulk_out[i] = epds->bulk_out[0];
+
+ epds->num_bulk_out = num_ports;
+
return num_ports;
}
@@ -1149,102 +1161,11 @@ static int mxuport_port_probe(struct usb_serial_port
*port)
port->port_number);
}
-static int mxuport_alloc_write_urb(struct usb_serial *serial,
- struct usb_serial_port *port,
- struct usb_serial_port *port0,
- int j)
-{
- struct usb_device *dev = interface_to_usbdev(serial->interface);
-
- set_bit(j, &port->write_urbs_free);
- port->write_urbs[j] = usb_alloc_urb(0, GFP_KERNEL);
- if (!port->write_urbs[j])
- return -ENOMEM;
-
- port->bulk_out_buffers[j] = kmalloc(port0->bulk_out_size, GFP_KERNEL);
- if (!port->bulk_out_buffers[j])
- return -ENOMEM;
-
- usb_fill_bulk_urb(port->write_urbs[j], dev,
- usb_sndbulkpipe(dev, port->bulk_out_endpointAddress),
- port->bulk_out_buffers[j],
- port->bulk_out_size,
- serial->type->write_bulk_callback,
- port);
- return 0;
-}
-
-
-static int mxuport_alloc_write_urbs(struct usb_serial *serial,
- struct usb_serial_port *port,
- struct usb_serial_port *port0)
-{
- int j;
- int ret;
-
- for (j = 0; j < ARRAY_SIZE(port->write_urbs); ++j) {
- ret = mxuport_alloc_write_urb(serial, port, port0, j);
- if (ret)
- return ret;
- }
- return 0;
-}
-
-
static int mxuport_attach(struct usb_serial *serial)
{
struct usb_serial_port *port0 = serial->port[0];
struct usb_serial_port *port1 = serial->port[1];
- struct usb_serial_port *port;
int err;
- int i;
- int j;
-
- /*
-* Throw away all but the first allocated write URBs so we can
-* set them up again to fit the multiplexing scheme.
-*/
- for (i = 1; i < serial->num_bulk_out; ++i) {
- port = serial->port[i];
- for (j = 0; j < ARRAY_SIZE(port->write_urbs); ++j) {
- usb_free_urb(port->write_urbs[j]);
- kfree(port->bulk_out_buffers[j]);
- port->write_urbs[j] = NULL;
- port->bulk_out_buffers[j] = NULL;
- }
- port->write_urbs_free = 0;
- }
-
- /*
-* All write data is sent over the first bulk out endpoint,
-* with an added header to indicate the port. Allocate URBs
-* for each port to the first bulk out endpoint.
-*/
- for (i = 1; i < serial->num_ports; ++i) {
- port = serial->port[i];
- port->bulk_out_size = port0->bulk_out_size;
- port->bulk_out_endpointAddress =
- port0->bulk_out_endpointAddress;
-
- err = mxuport_alloc_write_urbs(serial, port, port0);
- if (err)
- return err;
-
- port->write_urb = port->write_urbs[0];
- port->bulk_out_buffer = port->bulk_out_buffers[0];
-
- /*
-* Ensure each port has a fifo. The framework only
-* allocates a fifo to ports with a bulk out endpoint,
-* where as we need one for every port.
-*/
- if (!kfifo_initialized(&port->write_fifo)) {
- err = kfifo_alloc(&port->write_fifo, PAGE_SIZE,
- GFP_KERNEL);
- if (err)
- return err;
- }
- }
/*
* All data
[PATCH 00/29] USB: serial: add port-endpoint-remap support
USB-serial core assigns endpoints to ports based on the order of the endpoint descriptors. This mostly works fine, but some drivers have had to resort to hacks to override this default. This series enables subdrivers to modify the default port-endport mapping by passing the endpoints to the drivers as part of probe. This allows for clean ups in USB-serial core as well as in several subdrivers. Note that this also enables the omninet driver to use the generic write implementation. Johan Johan Hovold (29): USB: serial: allow subdrivers to modify port-endpoint mapping USB: serial: add probe callback to generic driver USB: serial: add calc_num_ports callback to generic driver USB: serial: relax generic driver bulk-endpoint requirement USB: serial: move pl2303 hack out of usb-serial core USB: serial: pl2303: clean up legacy endpoint hack USB: serial: aircable: use calc_num_endpoints to verify endpoints USB: serial: f81534: use calc_num_endpoints to verify endpoints USB: serial: f81534: abort probe on early errors USB: serial: ipaq: use calc_num_endpoints to verify endpoints USB: serial: ipaq: always register a single port USB: serial: io_ti: use calc_num_endpoints to verify endpoints USB: serial: io_ti: always require a bulk-out endpoint USB: serial: io_ti: verify interrupt endpoint at probe USB: serial: io_ti: drop redundant read-urb check USB: serial: mos7720: clean up mcs7715 port setup USB: serial: mos7720: always require an interrupt endpoint USB: serial: mos7840: clean up endpoint sanity check USB: serial: omninet: clean up port setup USB: serial: omninet: use generic write implementation USB: serial: ti_usb_3410_5052: always require a bulk-out endpoint USB: serial: visor: drop redundant calc_num_ports callback USB: serial: visor: clean up clie_5 endpoint hack USB: serial: visor: clean up treo endpoint hack USB: serial: mxuport: register two ports for unknown devices USB: serial: mxuport: add endpoint sanity check USB: serial: mxuport: clean up port bulk-out setup USB: serial: f81534: clean up calc_num_ports USB: serial: f81534: clean up port bulk-out setup drivers/usb/serial/aircable.c | 36 ++--- drivers/usb/serial/f81534.c | 137 --- drivers/usb/serial/generic.c | 32 +++- drivers/usb/serial/io_ti.c| 41 +- drivers/usb/serial/ipaq.c | 51 +--- drivers/usb/serial/mos7720.c | 55 + drivers/usb/serial/mos7840.c | 26 +++--- drivers/usb/serial/mxuport.c | 133 --- drivers/usb/serial/omninet.c | 124 +++-- drivers/usb/serial/pl2303.c | 73 +++-- drivers/usb/serial/quatech2.c | 3 +- drivers/usb/serial/sierra.c | 3 +- drivers/usb/serial/ti_usb_3410_5052.c | 2 + drivers/usb/serial/usb-serial.c | 76 ++ drivers/usb/serial/visor.c| 146 -- include/linux/usb/serial.h| 20 - 16 files changed, 359 insertions(+), 599 deletions(-) -- 2.12.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 25/29] USB: serial: mxuport: register two ports for unknown devices
Print a message and register two ports for interfaces for which we do
not know how many ports there are instead of binding, allocating
resources, but not register any ports.
This provides a hint that anyone adding a dynamic device id must also
provide a reference id (driver info) from which the port count can be
retrieved, for example:
echo 0 0x110A 0x1410 > new_id
Signed-off-by: Johan Hovold
---
drivers/usb/serial/mxuport.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/serial/mxuport.c b/drivers/usb/serial/mxuport.c
index bf543e6c05ea..3355737cbfd1 100644
--- a/drivers/usb/serial/mxuport.c
+++ b/drivers/usb/serial/mxuport.c
@@ -950,17 +950,23 @@ static int mxuport_calc_num_ports(struct usb_serial
*serial,
struct usb_serial_endpoints *epds)
{
unsigned long features = (unsigned long)usb_get_serial_data(serial);
+ int num_ports;
+
+ if (features & MX_UPORT_2_PORT) {
+ num_ports = 2;
+ } else if (features & MX_UPORT_4_PORT) {
+ num_ports = 4;
+ } else if (features & MX_UPORT_8_PORT) {
+ num_ports = 8;
+ } else if (features & MX_UPORT_16_PORT) {
+ num_ports = 16;
+ } else {
+ dev_warn(&serial->interface->dev,
+ "unknown device, assuming two ports\n");
+ num_ports = 2;
+ }
- if (features & MX_UPORT_2_PORT)
- return 2;
- if (features & MX_UPORT_4_PORT)
- return 4;
- if (features & MX_UPORT_8_PORT)
- return 8;
- if (features & MX_UPORT_16_PORT)
- return 16;
-
- return 0;
+ return num_ports;
}
/* Get the version of the firmware currently running. */
@@ -1367,7 +1373,6 @@ static struct usb_serial_driver mxuport_device = {
},
.description= "MOXA UPort",
.id_table = mxuport_idtable,
- .num_ports = 0,
.probe = mxuport_probe,
.port_probe = mxuport_port_probe,
.attach = mxuport_attach,
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/29] USB: serial: pl2303: clean up legacy endpoint hack
Implement the "horrible endpoint hack" for some legacy devices as a
quirk and clean up the code somewhat.
Note that the bulk-endpoint check can be removed as core will already
have verified this.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/pl2303.c | 84 +
1 file changed, 46 insertions(+), 38 deletions(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index b8edd7bc71f2..c9ebefd8f35f 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -33,9 +33,11 @@
#define PL2303_QUIRK_UART_STATE_IDX0 BIT(0)
#define PL2303_QUIRK_LEGACYBIT(1)
+#define PL2303_QUIRK_ENDPOINT_HACK BIT(2)
static const struct usb_device_id id_table[] = {
- { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID) },
+ { USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID),
+ .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ2) },
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_DCU11) },
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_RSAQ3) },
@@ -48,7 +50,8 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(PL2303_VENDOR_ID, PL2303_PRODUCT_ID_ZTEK) },
{ USB_DEVICE(IODATA_VENDOR_ID, IODATA_PRODUCT_ID) },
{ USB_DEVICE(IODATA_VENDOR_ID, IODATA_PRODUCT_ID_RSAQ5) },
- { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID) },
+ { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID),
+ .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
{ USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID2) },
{ USB_DEVICE(ATEN_VENDOR_ID2, ATEN_PRODUCT_ID) },
{ USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID) },
@@ -68,7 +71,8 @@ static const struct usb_device_id id_table[] = {
.driver_info = PL2303_QUIRK_UART_STATE_IDX0 },
{ USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_X75),
.driver_info = PL2303_QUIRK_UART_STATE_IDX0 },
- { USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_EF81) },
+ { USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_EF81),
+ .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
{ USB_DEVICE(BENQ_VENDOR_ID, BENQ_PRODUCT_ID_S81) }, /* Benq/Siemens
S81 */
{ USB_DEVICE(SYNTECH_VENDOR_ID, SYNTECH_PRODUCT_ID) },
{ USB_DEVICE(NOKIA_CA42_VENDOR_ID, NOKIA_CA42_PRODUCT_ID) },
@@ -78,7 +82,8 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(SPEEDDRAGON_VENDOR_ID, SPEEDDRAGON_PRODUCT_ID) },
{ USB_DEVICE(DATAPILOT_U2_VENDOR_ID, DATAPILOT_U2_PRODUCT_ID) },
{ USB_DEVICE(BELKIN_VENDOR_ID, BELKIN_PRODUCT_ID) },
- { USB_DEVICE(ALCOR_VENDOR_ID, ALCOR_PRODUCT_ID) },
+ { USB_DEVICE(ALCOR_VENDOR_ID, ALCOR_PRODUCT_ID),
+ .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
{ USB_DEVICE(WS002IN_VENDOR_ID, WS002IN_PRODUCT_ID) },
{ USB_DEVICE(COREGA_VENDOR_ID, COREGA_PRODUCT_ID) },
{ USB_DEVICE(YCCABLE_VENDOR_ID, YCCABLE_PRODUCT_ID) },
@@ -218,7 +223,12 @@ static int pl2303_probe(struct usb_serial *serial,
return 0;
}
-static int pl2303_calc_num_ports(struct usb_serial *serial,
+/*
+ * Use interrupt endpoint from first interface if available.
+ *
+ * This is needed due to the looney way its endpoints are set up.
+ */
+static int pl2303_endpoint_hack(struct usb_serial *serial,
struct usb_serial_endpoints *epds)
{
struct usb_interface *interface = serial->interface;
@@ -228,43 +238,41 @@ static int pl2303_calc_num_ports(struct usb_serial
*serial,
struct usb_endpoint_descriptor *endpoint;
unsigned int i;
- /* BEGIN HORRIBLE HACK FOR PL2303 */
- /* this is needed due to the looney way its endpoints are set up */
- if (((le16_to_cpu(dev->descriptor.idVendor) == PL2303_VENDOR_ID) &&
-(le16_to_cpu(dev->descriptor.idProduct) == PL2303_PRODUCT_ID)) ||
- ((le16_to_cpu(dev->descriptor.idVendor) == ATEN_VENDOR_ID) &&
-(le16_to_cpu(dev->descriptor.idProduct) == ATEN_PRODUCT_ID)) ||
- ((le16_to_cpu(dev->descriptor.idVendor) == ALCOR_VENDOR_ID) &&
-(le16_to_cpu(dev->descriptor.idProduct) == ALCOR_PRODUCT_ID)) ||
- ((le16_to_cpu(dev->descriptor.idVendor) == SIEMENS_VENDOR_ID) &&
-(le16_to_cpu(dev->descriptor.idProduct) ==
SIEMENS_PRODUCT_ID_EF81))) {
- if (interface != dev->actconfig->interface[0]) {
- /* check out the endpoints of the other interface*/
- iface_desc =
dev->actconfig->interface[0]->cur_altsetting;
- for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
- endpoint = &iface_desc->endpoint[i].desc;
- if (usb_endpoint_is_int_in(endpoint)) {
- /* we found a interrupt in endpoi
[PATCH 02/29] USB: serial: add probe callback to generic driver
Add a probe callback to the generic driver and print the
only-for-testing message there.
This is a first step in getting rid of the CONFIG_USB_SERIAL_GENERIC
ifdef from usb-serial core.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/generic.c| 12
drivers/usb/serial/usb-serial.c | 2 --
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 49ce2be90fa0..8c7600472019 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -37,6 +37,17 @@ MODULE_PARM_DESC(product, "User specified USB idProduct");
static struct usb_device_id generic_device_ids[2]; /* Initially all zeroes. */
+static int usb_serial_generic_probe(struct usb_serial *serial,
+ const struct usb_device_id *id)
+{
+ struct device *dev = &serial->interface->dev;
+
+ dev_info(dev, "The \"generic\" usb-serial driver is only for testing
and one-off prototypes.\n");
+ dev_info(dev, "Tell linux-usb@vger.kernel.org to add your device to a
proper driver.\n");
+
+ return 0;
+}
+
struct usb_serial_driver usb_serial_generic_device = {
.driver = {
.owner =THIS_MODULE,
@@ -44,6 +55,7 @@ struct usb_serial_driver usb_serial_generic_device = {
},
.id_table = generic_device_ids,
.num_ports =1,
+ .probe =usb_serial_generic_probe,
.throttle = usb_serial_generic_throttle,
.unthrottle = usb_serial_generic_unthrottle,
.resume = usb_serial_generic_resume,
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index f0761f491c5f..f8ae09e2cff5 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -858,8 +858,6 @@ static int usb_serial_probe(struct usb_interface *interface,
retval = -EIO;
goto err_free_epds;
}
- dev_info(ddev, "The \"generic\" usb-serial driver is only for
testing and one-off prototypes.\n");
- dev_info(ddev, "Tell linux-usb@vger.kernel.org to add your
device to a proper driver.\n");
}
#endif
if (!num_ports) {
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/29] USB: serial: mos7720: always require an interrupt endpoint
This driver have treated the interrupt endpoint as optional despite it
always being present (according to the datasheet). Let's consider it
mandatory instead.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/mos7720.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c
index eabea0bc1a04..b1f6b275e7c1 100644
--- a/drivers/usb/serial/mos7720.c
+++ b/drivers/usb/serial/mos7720.c
@@ -1923,8 +1923,7 @@ static int mos7720_startup(struct usb_serial *serial)
if (product == MOSCHIP_DEVICE_ID_7715) {
struct urb *urb = serial->port[0]->interrupt_in_urb;
- if (urb)
- urb->complete = mos7715_interrupt_callback;
+ urb->complete = mos7715_interrupt_callback;
#ifdef CONFIG_USB_SERIAL_MOS7715_PARPORT
ret_val = mos7715_parport_init(serial);
@@ -2025,6 +2024,7 @@ static struct usb_serial_driver moschip7720_2port_driver
= {
.id_table = id_table,
.num_bulk_in= 2,
.num_bulk_out = 2,
+ .num_interrupt_in = 1,
.calc_num_ports = mos77xx_calc_num_ports,
.open = mos7720_open,
.close = mos7720_close,
--
2.12.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
On Thu, Mar 16, 2017 at 12:51 PM, Diego Viola wrote: > On Thu, Mar 16, 2017 at 12:45 PM, Diego Viola wrote: >> On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern >> wrote: >>> On Thu, 16 Mar 2017, Ulf Hansson wrote: >>> +Alan On 15 March 2017 at 15:00, Diego Viola wrote: > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola > wrote: >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola >> wrote: >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola >>> wrote: On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola wrote: > On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola > wrote: >> Hi Greg, >> >> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH >> wrote: >>> On Wed, Mar 08, 2017 at 03:49:19PM -0300, Diego Viola wrote: It hangs on resume from suspend if I have USB 3.0 enabled on the BIOS, it works fine with ehci_hcd or USB 2.0. The way I reproduce the problem is with this command: $ i3lock && systemctl suspend This is what I see on the screen when it hangs: https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg Some logs: https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH. I also tried Linux 4.10.1 and I could reproduce this problem there as well. Please let me know if I could provide more info. >>> >>> Has any previous kernel ever worked properly before? If so, any >>> chance >>> you can use 'git bisect' to find the offending commit? >> >> I'm not sure, this is my work machine and I've only started using it >> recently (since about a month ago or so). >> >> I will try older kernels and see if I get any different results, I >> will report back in any case. >> >>> >>> And are you sure you have updated your bios to the latest version? >> >> Yes. >> >>> >>> thanks, >>> >>> greg k-h >> >> Thanks, >> Diego > > I found another workaround, I can suspend/resume fine with `i3lock && > systemctl suspend` if I disconnect/unplug all my USB devices > (keyboard, mouse, etc). This with the default settings in the BIOS > (both USB 2.0 and 3.0 enabled). > > I'm also seeing some messages like this in dmesg: > > [ 16.172190] usb 2-6: device descriptor read/64, error -110 > > Would this indicate a hardware/firmware/power issue? > > Thanks, > Diego OK, I've built Linux 4.4.52 (I did a localmodconfig) and rebooted into it, I did a suspend/resume and it hanged the first time I tried to resume, which isn't much different than using the latest kernel. My dmesg is still being spammed with these messages: [ 260.043673] usb 2-1: Device not responding to setup address. [ 260.246918] usb 2-1: device not accepting address 15, error -71 [ 260.633662] usb 2-1: new high-speed USB device number 17 using xhci_hcd [ 261.341340] usb 2-1: USB disconnect, device number 17 I guess it's safe to assume at this point that this is a hardware problem? Thanks, Diego >>> >>> Hello, >>> >>> I've found something interesting and what it seems to be the cause of >>> my problem. >>> >>> As soon as I boot my system I can see this process being in the >>> D-state: >>> >>> [root@myhost ~]# ps aux | grep " D" >>> root 269 0.0 0.0 0 0 ?D14:11 0:00 >>> [rtsx_usb_ms_2] >>> root 1424 0.0 0.0 10788 2172 pts/2S+ 14:19 0:00 grep >>> D >>> [root@myhost ~]# >>> >>> I'm not exactly sure why that is, but if I do a 'rmmod rtsx_usb_ms' >>> the problem is gone. I already tried suspending/resuming ~40 times >>> after I disabled the module and the suspend/resume problem is gone. That's a good observation! It suspect the drivers/memstick/host/rtsx_usb_ms.c isn't behaving properly from PM point of view. Perhaps it tries to access its device while it from a runtime PM point view still is in a runtime suspended state. Exactly why I don't know yet. Moreo
Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern wrote: > On Thu, 16 Mar 2017, Ulf Hansson wrote: > >> +Alan >> >> On 15 March 2017 at 15:00, Diego Viola wrote: >> > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola wrote: >> >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola >> >> wrote: >> >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola >> >>> wrote: >> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola >> wrote: >> > On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola >> > wrote: >> >> Hi Greg, >> >> >> >> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH >> >> wrote: >> >>> On Wed, Mar 08, 2017 at 03:49:19PM -0300, Diego Viola wrote: >> It hangs on resume from suspend if I have USB 3.0 enabled on the >> BIOS, >> it works fine with ehci_hcd or USB 2.0. >> >> The way I reproduce the problem is with this command: >> >> $ i3lock && systemctl suspend >> >> This is what I see on the screen when it hangs: >> >> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg >> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg >> >> Some logs: >> >> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt >> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt >> >> I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH. >> >> I also tried Linux 4.10.1 and I could reproduce this problem there >> as well. >> >> Please let me know if I could provide more info. >> >>> >> >>> Has any previous kernel ever worked properly before? If so, any >> >>> chance >> >>> you can use 'git bisect' to find the offending commit? >> >> >> >> I'm not sure, this is my work machine and I've only started using it >> >> recently (since about a month ago or so). >> >> >> >> I will try older kernels and see if I get any different results, I >> >> will report back in any case. >> >> >> >>> >> >>> And are you sure you have updated your bios to the latest version? >> >> >> >> Yes. >> >> >> >>> >> >>> thanks, >> >>> >> >>> greg k-h >> >> >> >> Thanks, >> >> Diego >> > >> > I found another workaround, I can suspend/resume fine with `i3lock && >> > systemctl suspend` if I disconnect/unplug all my USB devices >> > (keyboard, mouse, etc). This with the default settings in the BIOS >> > (both USB 2.0 and 3.0 enabled). >> > >> > I'm also seeing some messages like this in dmesg: >> > >> > [ 16.172190] usb 2-6: device descriptor read/64, error -110 >> > >> > Would this indicate a hardware/firmware/power issue? >> > >> > Thanks, >> > Diego >> >> OK, I've built Linux 4.4.52 (I did a localmodconfig) and rebooted into >> it, I did a suspend/resume and it hanged the first time I tried to >> resume, which isn't much different than using the latest kernel. >> >> My dmesg is still being spammed with these messages: >> >> [ 260.043673] usb 2-1: Device not responding to setup address. >> [ 260.246918] usb 2-1: device not accepting address 15, error -71 >> [ 260.633662] usb 2-1: new high-speed USB device number 17 using >> xhci_hcd >> [ 261.341340] usb 2-1: USB disconnect, device number 17 >> >> I guess it's safe to assume at this point that this is a hardware >> problem? >> >> Thanks, >> Diego >> >>> >> >>> Hello, >> >>> >> >>> I've found something interesting and what it seems to be the cause of >> >>> my problem. >> >>> >> >>> As soon as I boot my system I can see this process being in the D-state: >> >>> >> >>> [root@myhost ~]# ps aux | grep " D" >> >>> root 269 0.0 0.0 0 0 ?D14:11 0:00 >> >>> [rtsx_usb_ms_2] >> >>> root 1424 0.0 0.0 10788 2172 pts/2S+ 14:19 0:00 grep D >> >>> [root@myhost ~]# >> >>> >> >>> I'm not exactly sure why that is, but if I do a 'rmmod rtsx_usb_ms' >> >>> the problem is gone. I already tried suspending/resuming ~40 times >> >>> after I disabled the module and the suspend/resume problem is gone. >> >> That's a good observation! >> >> It suspect the drivers/memstick/host/rtsx_usb_ms.c isn't behaving >> properly from PM point of view. Perhaps it tries to access its device >> while it from a runtime PM point view still is in a runtime suspended >> state. Exactly why I don't know yet. >> >> Moreover we have had issues with this driver before and its >> corresponding SD card driver in drivers/mmc/host/rtsx_usb_sdmmc.c. On >> top of that, both their corresponding devices shares the same usb mfd >> device as parent, which is managed by drivers/mfd/rtsx_usb.c. >> >> Unfortunate my knowledge about USB is still in the learning phase, >> however I know well about runtime PM ans system sus
Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
On Thu, Mar 16, 2017 at 12:45 PM, Diego Viola wrote: > On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern > wrote: >> On Thu, 16 Mar 2017, Ulf Hansson wrote: >> >>> +Alan >>> >>> On 15 March 2017 at 15:00, Diego Viola wrote: >>> > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola >>> > wrote: >>> >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola >>> >> wrote: >>> >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola >>> >>> wrote: >>> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola >>> wrote: >>> > On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola >>> > wrote: >>> >> Hi Greg, >>> >> >>> >> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH >>> >> wrote: >>> >>> On Wed, Mar 08, 2017 at 03:49:19PM -0300, Diego Viola wrote: >>> It hangs on resume from suspend if I have USB 3.0 enabled on the >>> BIOS, >>> it works fine with ehci_hcd or USB 2.0. >>> >>> The way I reproduce the problem is with this command: >>> >>> $ i3lock && systemctl suspend >>> >>> This is what I see on the screen when it hangs: >>> >>> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg >>> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg >>> >>> Some logs: >>> >>> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt >>> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt >>> >>> I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH. >>> >>> I also tried Linux 4.10.1 and I could reproduce this problem there >>> as well. >>> >>> Please let me know if I could provide more info. >>> >>> >>> >>> Has any previous kernel ever worked properly before? If so, any >>> >>> chance >>> >>> you can use 'git bisect' to find the offending commit? >>> >> >>> >> I'm not sure, this is my work machine and I've only started using it >>> >> recently (since about a month ago or so). >>> >> >>> >> I will try older kernels and see if I get any different results, I >>> >> will report back in any case. >>> >> >>> >>> >>> >>> And are you sure you have updated your bios to the latest version? >>> >> >>> >> Yes. >>> >> >>> >>> >>> >>> thanks, >>> >>> >>> >>> greg k-h >>> >> >>> >> Thanks, >>> >> Diego >>> > >>> > I found another workaround, I can suspend/resume fine with `i3lock && >>> > systemctl suspend` if I disconnect/unplug all my USB devices >>> > (keyboard, mouse, etc). This with the default settings in the BIOS >>> > (both USB 2.0 and 3.0 enabled). >>> > >>> > I'm also seeing some messages like this in dmesg: >>> > >>> > [ 16.172190] usb 2-6: device descriptor read/64, error -110 >>> > >>> > Would this indicate a hardware/firmware/power issue? >>> > >>> > Thanks, >>> > Diego >>> >>> OK, I've built Linux 4.4.52 (I did a localmodconfig) and rebooted into >>> it, I did a suspend/resume and it hanged the first time I tried to >>> resume, which isn't much different than using the latest kernel. >>> >>> My dmesg is still being spammed with these messages: >>> >>> [ 260.043673] usb 2-1: Device not responding to setup address. >>> [ 260.246918] usb 2-1: device not accepting address 15, error -71 >>> [ 260.633662] usb 2-1: new high-speed USB device number 17 using >>> xhci_hcd >>> [ 261.341340] usb 2-1: USB disconnect, device number 17 >>> >>> I guess it's safe to assume at this point that this is a hardware >>> problem? >>> >>> Thanks, >>> Diego >>> >>> >>> >>> Hello, >>> >>> >>> >>> I've found something interesting and what it seems to be the cause of >>> >>> my problem. >>> >>> >>> >>> As soon as I boot my system I can see this process being in the D-state: >>> >>> >>> >>> [root@myhost ~]# ps aux | grep " D" >>> >>> root 269 0.0 0.0 0 0 ?D14:11 0:00 >>> >>> [rtsx_usb_ms_2] >>> >>> root 1424 0.0 0.0 10788 2172 pts/2S+ 14:19 0:00 grep D >>> >>> [root@myhost ~]# >>> >>> >>> >>> I'm not exactly sure why that is, but if I do a 'rmmod rtsx_usb_ms' >>> >>> the problem is gone. I already tried suspending/resuming ~40 times >>> >>> after I disabled the module and the suspend/resume problem is gone. >>> >>> That's a good observation! >>> >>> It suspect the drivers/memstick/host/rtsx_usb_ms.c isn't behaving >>> properly from PM point of view. Perhaps it tries to access its device >>> while it from a runtime PM point view still is in a runtime suspended >>> state. Exactly why I don't know yet. >>> >>> Moreover we have had issues with this driver before and its >>> corresponding SD card driver in drivers/mmc/host/rtsx_usb_sdmmc.c. On >>> top of that, both their corresponding devices shares the same usb mfd
Re: [PATCH] usb: dwc3 dwc3_exynos_probe() change goto labels to meaningful names
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 me to do?
thanks,
-- Shuah
>
> drivers/usb/dwc3/dwc3-exynos.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
> index 1515d45..98f74ff 100644
> --- a/drivers/usb/dwc3/dwc3-exynos.c
> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> @@ -147,53 +147,53 @@ static int dwc3_exynos_probe(struct platform_device
> *pdev)
> exynos->vdd33 = devm_regulator_get(dev, "vdd33");
> if (IS_ERR(exynos->vdd33)) {
> ret = PTR_ERR(exynos->vdd33);
> - goto err2;
> + goto vdd33_err;
> }
> ret = regulator_enable(exynos->vdd33);
> if (ret) {
> dev_err(dev, "Failed to enable VDD33 supply\n");
> - goto err2;
> + goto vdd33_err;
> }
>
> exynos->vdd10 = devm_regulator_get(dev, "vdd10");
> if (IS_ERR(exynos->vdd10)) {
> ret = PTR_ERR(exynos->vdd10);
> - goto err3;
> + goto vdd10_err;
> }
> ret = regulator_enable(exynos->vdd10);
> if (ret) {
> dev_err(dev, "Failed to enable VDD10 supply\n");
> - goto err3;
> + goto vdd10_err;
> }
>
> ret = dwc3_exynos_register_phys(exynos);
> if (ret) {
> dev_err(dev, "couldn't register PHYs\n");
> - goto err4;
> + goto phys_err;
> }
>
> if (node) {
> ret = of_platform_populate(node, NULL, NULL, dev);
> if (ret) {
> dev_err(dev, "failed to add dwc3 core\n");
> - goto err5;
> + goto populate_err;
> }
> } else {
> dev_err(dev, "no device node, failed to add dwc3 core\n");
> ret = -ENODEV;
> - goto err5;
> + goto populate_err;
> }
>
> return 0;
>
> -err5:
> +populate_err:
> platform_device_unregister(exynos->usb2_phy);
> platform_device_unregister(exynos->usb3_phy);
> -err4:
> +phys_err:
> regulator_disable(exynos->vdd10);
> -err3:
> +vdd10_err:
> regulator_disable(exynos->vdd33);
> -err2:
> +vdd33_err:
> clk_disable_unprepare(exynos->axius_clk);
> axius_clk_err:
> clk_disable_unprepare(exynos->susp_clk);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] usbip: Fix-format-overflow
On 02/27/2017 01:31 AM, Jonathan Dieter wrote:
> The usbip userspace tools call sprintf()/snprintf() and don't check for
> the return value which can lead the paths to overflow, truncating the
> final file in the path.
>
> More urgently, GCC 7 now warns that these aren't checked with
> -Wformat-overflow, and with -Werror enabled in configure.ac, that makes
> these tools unbuildable.
>
> This patch fixes these problems by replacing sprintf() with snprintf() in
> one place and adding checks for the return value of snprintf().
>
> Reviewed-by: Peter Senna Tschudin
> Signed-off-by: Jonathan Dieter
Greg,
Please pick this up.
Acked-by: Shuah Khan
thanks,
-- Shuah
> ---
> Changes since v3
> * Cast sizeof to long unsigned when printing errors to fix building for
> 32-bit
>architectures
>
> tools/usb/usbip/libsrc/usbip_common.c | 9 -
> tools/usb/usbip/libsrc/usbip_host_common.c | 28 +++-
> 2 files changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/tools/usb/usbip/libsrc/usbip_common.c
> b/tools/usb/usbip/libsrc/usbip_common.c
> index ac73710..1517a23 100644
> --- a/tools/usb/usbip/libsrc/usbip_common.c
> +++ b/tools/usb/usbip/libsrc/usbip_common.c
> @@ -215,9 +215,16 @@ int read_usb_interface(struct usbip_usb_device *udev,
> int i,
> struct usbip_usb_interface *uinf)
> {
> char busid[SYSFS_BUS_ID_SIZE];
> + int size;
> struct udev_device *sif;
>
> - sprintf(busid, "%s:%d.%d", udev->busid, udev->bConfigurationValue, i);
> + size = snprintf(busid, sizeof(busid), "%s:%d.%d",
> + udev->busid, udev->bConfigurationValue, i);
> + if (size < 0 || (unsigned int)size >= sizeof(busid)) {
> + err("busid length %i >= %lu or < 0", size,
> + (long unsigned)sizeof(busid));
> + return -1;
> + }
>
> sif = udev_device_new_from_subsystem_sysname(udev_context, "usb",
> busid);
> if (!sif) {
> diff --git a/tools/usb/usbip/libsrc/usbip_host_common.c
> b/tools/usb/usbip/libsrc/usbip_host_common.c
> index 9d41522..6ff7b60 100644
> --- a/tools/usb/usbip/libsrc/usbip_host_common.c
> +++ b/tools/usb/usbip/libsrc/usbip_host_common.c
> @@ -40,13 +40,20 @@ struct udev *udev_context;
> static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
> {
> char status_attr_path[SYSFS_PATH_MAX];
> + int size;
> int fd;
> int length;
> char status;
> int value = 0;
>
> - snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",
> - udev->path);
> + size = snprintf(status_attr_path, sizeof(status_attr_path),
> + "%s/usbip_status", udev->path);
> + if (size < 0 || (unsigned int)size >= sizeof(status_attr_path)) {
> + err("usbip_status path length %i >= %lu or < 0", size,
> + (long unsigned)sizeof(status_attr_path));
> + return -1;
> + }
> +
>
> fd = open(status_attr_path, O_RDONLY);
> if (fd < 0) {
> @@ -218,6 +225,7 @@ int usbip_export_device(struct usbip_exported_device
> *edev, int sockfd)
> {
> char attr_name[] = "usbip_sockfd";
> char sockfd_attr_path[SYSFS_PATH_MAX];
> + int size;
> char sockfd_buff[30];
> int ret;
>
> @@ -237,10 +245,20 @@ int usbip_export_device(struct usbip_exported_device
> *edev, int sockfd)
> }
>
> /* only the first interface is true */
> - snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
> - edev->udev.path, attr_name);
> + size = snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
> + edev->udev.path, attr_name);
> + if (size < 0 || (unsigned int)size >= sizeof(sockfd_attr_path)) {
> + err("exported device path length %i >= %lu or < 0", size,
> + (long unsigned)sizeof(sockfd_attr_path));
> + return -1;
> + }
>
> - snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
> + size = snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
> + if (size < 0 || (unsigned int)size >= sizeof(sockfd_buff)) {
> + err("socket length %i >= %lu or < 0", size,
> + (long unsigned)sizeof(sockfd_buff));
> + return -1;
> + }
>
> ret = write_sysfs_attribute(sockfd_attr_path, sockfd_buff,
> strlen(sockfd_buff));
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
On Thu, 16 Mar 2017, Ulf Hansson wrote: > +Alan > > On 15 March 2017 at 15:00, Diego Viola wrote: > > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola wrote: > >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola wrote: > >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola wrote: > On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola > wrote: > > On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola > > wrote: > >> Hi Greg, > >> > >> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH > >> wrote: > >>> On Wed, Mar 08, 2017 at 03:49:19PM -0300, Diego Viola wrote: > It hangs on resume from suspend if I have USB 3.0 enabled on the > BIOS, > it works fine with ehci_hcd or USB 2.0. > > The way I reproduce the problem is with this command: > > $ i3lock && systemctl suspend > > This is what I see on the screen when it hangs: > > https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg > https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg > > Some logs: > > https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt > https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt > > I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH. > > I also tried Linux 4.10.1 and I could reproduce this problem there > as well. > > Please let me know if I could provide more info. > >>> > >>> Has any previous kernel ever worked properly before? If so, any > >>> chance > >>> you can use 'git bisect' to find the offending commit? > >> > >> I'm not sure, this is my work machine and I've only started using it > >> recently (since about a month ago or so). > >> > >> I will try older kernels and see if I get any different results, I > >> will report back in any case. > >> > >>> > >>> And are you sure you have updated your bios to the latest version? > >> > >> Yes. > >> > >>> > >>> thanks, > >>> > >>> greg k-h > >> > >> Thanks, > >> Diego > > > > I found another workaround, I can suspend/resume fine with `i3lock && > > systemctl suspend` if I disconnect/unplug all my USB devices > > (keyboard, mouse, etc). This with the default settings in the BIOS > > (both USB 2.0 and 3.0 enabled). > > > > I'm also seeing some messages like this in dmesg: > > > > [ 16.172190] usb 2-6: device descriptor read/64, error -110 > > > > Would this indicate a hardware/firmware/power issue? > > > > Thanks, > > Diego > > OK, I've built Linux 4.4.52 (I did a localmodconfig) and rebooted into > it, I did a suspend/resume and it hanged the first time I tried to > resume, which isn't much different than using the latest kernel. > > My dmesg is still being spammed with these messages: > > [ 260.043673] usb 2-1: Device not responding to setup address. > [ 260.246918] usb 2-1: device not accepting address 15, error -71 > [ 260.633662] usb 2-1: new high-speed USB device number 17 using > xhci_hcd > [ 261.341340] usb 2-1: USB disconnect, device number 17 > > I guess it's safe to assume at this point that this is a hardware > problem? > > Thanks, > Diego > >>> > >>> Hello, > >>> > >>> I've found something interesting and what it seems to be the cause of > >>> my problem. > >>> > >>> As soon as I boot my system I can see this process being in the D-state: > >>> > >>> [root@myhost ~]# ps aux | grep " D" > >>> root 269 0.0 0.0 0 0 ?D14:11 0:00 > >>> [rtsx_usb_ms_2] > >>> root 1424 0.0 0.0 10788 2172 pts/2S+ 14:19 0:00 grep D > >>> [root@myhost ~]# > >>> > >>> I'm not exactly sure why that is, but if I do a 'rmmod rtsx_usb_ms' > >>> the problem is gone. I already tried suspending/resuming ~40 times > >>> after I disabled the module and the suspend/resume problem is gone. > > That's a good observation! > > It suspect the drivers/memstick/host/rtsx_usb_ms.c isn't behaving > properly from PM point of view. Perhaps it tries to access its device > while it from a runtime PM point view still is in a runtime suspended > state. Exactly why I don't know yet. > > Moreover we have had issues with this driver before and its > corresponding SD card driver in drivers/mmc/host/rtsx_usb_sdmmc.c. On > top of that, both their corresponding devices shares the same usb mfd > device as parent, which is managed by drivers/mfd/rtsx_usb.c. > > Unfortunate my knowledge about USB is still in the learning phase, > however I know well about runtime PM ans system suspend, so perhaps I > still might be able to help. > > Anyway, I have looped in Alan, let's see if he has some input to this. Is the rtsx_usb_ms device attached to an xHCI controller? How is
Re: [PATCH] mmc: ushc: fix NULL-deref at probe
On 13 March 2017 at 13:40, Johan Hovold wrote:
> Make sure to check the number of endpoints to avoid dereferencing a
> NULL-pointer should a malicious device lack endpoints.
>
> Fixes: 53f3a9e26ed5 ("mmc: USB SD Host Controller (USHC) driver")
> Cc: stable # 2.6.37
> Cc: David Vrabel
> Signed-off-by: Johan Hovold
Thanks, applied for fixes!
Kind regards
Uffe
> ---
> drivers/mmc/host/ushc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mmc/host/ushc.c b/drivers/mmc/host/ushc.c
> index d2c386f09d69..1d843357422e 100644
> --- a/drivers/mmc/host/ushc.c
> +++ b/drivers/mmc/host/ushc.c
> @@ -426,6 +426,9 @@ static int ushc_probe(struct usb_interface *intf, const
> struct usb_device_id *id
> struct ushc_data *ushc;
> int ret;
>
> + if (intf->cur_altsetting->desc.bNumEndpoints < 1)
> + return -ENODEV;
> +
> mmc = mmc_alloc_host(sizeof(struct ushc_data), &intf->dev);
> if (mmc == NULL)
> return -ENOMEM;
> --
> 2.12.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH net-next] r8152: simply the arguments
From: Hayes Wang
> Sent: 16 March 2017 06:28
> Replace &tp->napi with napi and tp->netdev with netdev.
>
> Signed-off-by: Hayes Wang
> ---
> drivers/net/usb/r8152.c | 44 +++-
> 1 file changed, 27 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 227e1fd..e480e9f 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -1761,6 +1761,7 @@ static int rx_bottom(struct r8152 *tp, int budget)
> unsigned long flags;
> struct list_head *cursor, *next, rx_queue;
> int ret = 0, work_done = 0;
> + struct napi_struct *napi = &tp->napi;
>
> if (!skb_queue_empty(&tp->rx_queue)) {
> while (work_done < budget) {
> @@ -1773,7 +1774,7 @@ static int rx_bottom(struct r8152 *tp, int budget)
> break;
>
> pkt_len = skb->len;
> - napi_gro_receive(&tp->napi, skb);
> + napi_gro_receive(napi, skb);
...
I'm not sure this makes the code any more readable.
It isn't even needed to shorten any long lines.
If you are really lucky the compiler will optimise it away.
Otherwise it will generate another local variable and possibly
a register spill to stack.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
+Alan On 15 March 2017 at 15:00, Diego Viola wrote: > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola wrote: >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola wrote: >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola wrote: On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola wrote: > On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola wrote: >> Hi Greg, >> >> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH >> wrote: >>> On Wed, Mar 08, 2017 at 03:49:19PM -0300, Diego Viola wrote: It hangs on resume from suspend if I have USB 3.0 enabled on the BIOS, it works fine with ehci_hcd or USB 2.0. The way I reproduce the problem is with this command: $ i3lock && systemctl suspend This is what I see on the screen when it hangs: https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg Some logs: https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH. I also tried Linux 4.10.1 and I could reproduce this problem there as well. Please let me know if I could provide more info. >>> >>> Has any previous kernel ever worked properly before? If so, any chance >>> you can use 'git bisect' to find the offending commit? >> >> I'm not sure, this is my work machine and I've only started using it >> recently (since about a month ago or so). >> >> I will try older kernels and see if I get any different results, I >> will report back in any case. >> >>> >>> And are you sure you have updated your bios to the latest version? >> >> Yes. >> >>> >>> thanks, >>> >>> greg k-h >> >> Thanks, >> Diego > > I found another workaround, I can suspend/resume fine with `i3lock && > systemctl suspend` if I disconnect/unplug all my USB devices > (keyboard, mouse, etc). This with the default settings in the BIOS > (both USB 2.0 and 3.0 enabled). > > I'm also seeing some messages like this in dmesg: > > [ 16.172190] usb 2-6: device descriptor read/64, error -110 > > Would this indicate a hardware/firmware/power issue? > > Thanks, > Diego OK, I've built Linux 4.4.52 (I did a localmodconfig) and rebooted into it, I did a suspend/resume and it hanged the first time I tried to resume, which isn't much different than using the latest kernel. My dmesg is still being spammed with these messages: [ 260.043673] usb 2-1: Device not responding to setup address. [ 260.246918] usb 2-1: device not accepting address 15, error -71 [ 260.633662] usb 2-1: new high-speed USB device number 17 using xhci_hcd [ 261.341340] usb 2-1: USB disconnect, device number 17 I guess it's safe to assume at this point that this is a hardware problem? Thanks, Diego >>> >>> Hello, >>> >>> I've found something interesting and what it seems to be the cause of >>> my problem. >>> >>> As soon as I boot my system I can see this process being in the D-state: >>> >>> [root@myhost ~]# ps aux | grep " D" >>> root 269 0.0 0.0 0 0 ?D14:11 0:00 >>> [rtsx_usb_ms_2] >>> root 1424 0.0 0.0 10788 2172 pts/2S+ 14:19 0:00 grep D >>> [root@myhost ~]# >>> >>> I'm not exactly sure why that is, but if I do a 'rmmod rtsx_usb_ms' >>> the problem is gone. I already tried suspending/resuming ~40 times >>> after I disabled the module and the suspend/resume problem is gone. That's a good observation! It suspect the drivers/memstick/host/rtsx_usb_ms.c isn't behaving properly from PM point of view. Perhaps it tries to access its device while it from a runtime PM point view still is in a runtime suspended state. Exactly why I don't know yet. Moreover we have had issues with this driver before and its corresponding SD card driver in drivers/mmc/host/rtsx_usb_sdmmc.c. On top of that, both their corresponding devices shares the same usb mfd device as parent, which is managed by drivers/mfd/rtsx_usb.c. Unfortunate my knowledge about USB is still in the learning phase, however I know well about runtime PM ans system suspend, so perhaps I still might be able to help. Anyway, I have looped in Alan, let's see if he has some input to this. >>> >>> Diego >> >> Adding Roger Tseng to the CC also. >> >> Diego > > According to this document: > > http://downloads.dell.com/manuals/all-products/esuprt_laptop/esuprt_inspiron_laptop/inspiron-15-5558-laptop_reference%20guide_en-us.pdf > > My computer only has a SD card slot and no MEMSTICK slot. > > lsusb says this though: > > Bus 001 Device 005: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 > Card
Re: unexpected TRB Type 4, Disable of device-initiated U1 failed
On 15.03.2017 22:48, Nathan Shearer wrote: Does earlier kernels work better? 4.10 has a change in USB 3 port disabling which is also called when usb core fails to address a device. 37be6676 usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices Older kernels would re-enable usb3 ports immediately after port disable. I can try some older kernels if it will help. Which versions should I compile and try? 4.9 without any additions Does dock work in other ports after power cycle? No. I'm using usb ports directly on the motherboard, and once the port/dock is disabled, it continues to not work even if I transfer the dock to another port. My USB keyboard and mouse do continue to work though. Odd, sounds like the Dock gets into some really weird state. does disabled port react to other USB devices? Yes, connecting a 2nd USB keyboard+mouse combo device to the disabled port does work. Connecting the usb dock back to that port again and the dock is still disabled. Connecting a small USB drive to the same port and the small usb drive does work. It seems the computer/kernel is remembering that the dock is a disabled device somehow. Sounds like the device is really in a odd state. Here is /var/log/messages for Vanilla Sources 4.10.3 with xhci debugging enabled (cleaned it up a bit) Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Successful setup address command Mar 15 13:48:50 varws03 kernel: usb 4-4: new SuperSpeed USB device number 2 using xhci_hcd Mar 15 13:48:50 varws03 kernel: usb 4-4: New USB device found, idVendor=0480, idProduct=a006 Mar 15 13:48:50 varws03 kernel: usb 4-4: New USB device strings: Mfr=2, Product=3, SerialNumber=1 Mar 15 13:48:50 varws03 kernel: usb 4-4: Product: ASM1351 Mar 15 13:48:50 varws03 kernel: usb 4-4: Manufacturer: Asmedia Mar 15 13:48:50 varws03 kernel: usb 4-4: SerialNumber: 123456789116 Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Successful Endpoint Configure command Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Set up evaluate context for LPM MEL change. Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Successful evaluate context command Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Set up evaluate context for LPM MEL change. Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Successful evaluate context command Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Set up evaluate context for LPM MEL change. Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Successful evaluate context command Way too many Maximum exit latency (MEL) commands, probably due to unnecessary U1 and U2 enable/disable requests. Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Adding 2 ep ctxs, 13 now active. Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Successful Endpoint Configure command Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Set up evaluate context for LPM MEL change. Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Successful evaluate context command Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Driver wants 257 stream IDs (including stream 0). Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Ep 0x83 only supports 32 stream IDs. driver asking for 257 streams, ep supports 32. Oliver, does this look normal for UAS? Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Need 64 stream ctx entries for 33 stream IDs. Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Allocating 33 streams and 64 stream context array entries. Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Setting stream 1 ring ptr to 0x400c57003 ... Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Setting stream 32 ring ptr to 0x400c9f003 Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Allocating 33 streams and 64 stream context array entries. Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Setting stream 1 ring ptr to 0x400ca2003 Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Setting stream 32 ring ptr to 0x400ce2003 Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Allocating 33 streams and 64 stream context array entries. Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Setting stream 32 ring ptr to 0x400d25003 Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Setting number of stream ctx array entries to 64 Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Setting number of stream ctx array entries to 64 Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Setting number of stream ctx array entries to 64 Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: Successful Endpoint Configure command Mar 15 13:48:50 varws03 kernel: usbcore: registered new interface driver uas Mar 15 13:48:50 varws03 kernel: xhci_hcd :00:14.0: ep 0x83 - asked Mar 15 13:48:50 varws03 kernel: sd 6:0:0:0: [sdb] Spinning up disk... Mar 15 13:49:29 varws03 kernel: sd 6:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 infl
Re: [PATCH 00/21] USB: serial: refactor endpoint sanity checks
On Thu, Mar 02, 2017 at 12:51:13PM +0100, Johan Hovold wrote: > This series refactors the endpoint sanity checks by allowing subdrivers > to specify a minimum number of endpoints required per type and letting > core verify this during probe. > > Note that the checks are minimum (i.e. we allow further unused > endpoints) and are verified only after the subdriver probe callbacks > returns where the altsetting may have been changed or an interface may > have been rejected based on some other property (e.g. interface number). > > This series also moves the endpoint descriptor arrays used to determine > the port-endpoint mapping of the stack and increases the maximum number > of ports a device can register to 16, something which specifically > enables the upper eight ports of some Moxa devices. > > Note that a follow-on series will pass the endpoint descriptors to the > subdrivers, something which allows for clean ups of more elaborate > sanity checks as well as the port-endpoint mapping to be modified (and > some related hacks to be removed). I've now applied this series for -next, and will be posting the follow-on series mentioned above shortly. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/16] USB: core: add helpers to retrieve endpoints in reverse order
On Wed, Mar 15, 2017 at 04:58:47PM +0100, Bjørn Mork wrote:
> Johan Hovold writes:
>
> > + if ((!bulk_in || *bulk_in) && (!bulk_out || *bulk_out) &&
> > + (!int_in || *int_in) && (!int_out || *int_out)) {
> > + return true;
> > + }
> > +
> > + return false;
> > +}
>
>
> Maybe I asked this before and got a good answer? I don't remember...
>
> But why not
>
> return (!bulk_in || *bulk_in) && (!bulk_out || *bulk_out) &&
> (!int_in || *int_in) && (!int_out || *int_out);
>
>
> ?
This was probably mostly a refactoring artifact this time, although I do
tend to try to avoid return statements that span multiple lines.
I'll fix this up in a v2.
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] usbip: Fix-format-overflow
On Mon, 2017-02-27 at 10:31 +0200, Jonathan Dieter wrote: > The usbip userspace tools call sprintf()/snprintf() and don't check for > the return value which can lead the paths to overflow, truncating the > final file in the path. > > More urgently, GCC 7 now warns that these aren't checked with > -Wformat-overflow, and with -Werror enabled in configure.ac, that makes > these tools unbuildable. > > This patch fixes these problems by replacing sprintf() with snprintf() in > one place and adding checks for the return value of snprintf(). > > > Reviewed-by: Peter Senna Tschudin > > Signed-off-by: Jonathan Dieter > --- > Changes since v3 > * Cast sizeof to long unsigned when printing errors to fix building for > 32-bit > architectures Just wanted to check if there's anything else I need to do to make this ready? Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/5] usb: early: add support for early printk through USB3 debug port
* Lu Baolu wrote: > Hi Ingo, > > On 03/02/2017 02:40 PM, Ingo Molnar wrote: > > * Lu Baolu wrote: > > > >> Hi Ingo, > >> > >> How about this version? Any further comments? > > So I have re-read the review feedback I gave on Jan 19 and found at least > > one > > thing I pointed out that you didn't address in the latest patches ... > > Do you mind telling me which one is not addressed? Is it one of below > feedbacks? So one piece of feedback I gave was: | BTW., just a side note, some kernel developers (like PeterZ - and I do it | sometimes too) remap early_printk to printk permanently and use it as their main | printk facility - because printk() reliability has suffered over the last couple | of years. | | So it's more than just early boot debugging - it's a very simple state-less | logging facility to an external computer. But the latest Kconfig help text still says this: +config EARLY_PRINTK_USB_XDBC + bool "Early printk via the xHCI debug port" + depends on EARLY_PRINTK && PCI + select EARLY_PRINTK_USB + ---help--- + Write kernel log output directly into the xHCI debug port. + + This is useful for kernel debugging when your machine crashes very + early before the console code is initialized. For normal operation + it is not recommended because it looks ugly and doesn't cooperate + with klogd/syslogd or the X server. You should normally N here, + unless you want to debug such a crash. ... while in reality it's an alternative lockless logging facility that goes way beyond debugging early boot crashes! Granted, I qualified that with 'just a side note'. I guess something like this would work: + One use for this feature is kernel debugging, for example when your + machine crashes very early before the regular console code is + initialized. Other uses include simpler, lockless logging instead of a + full-blown printk console driver + klogd. + + For normal production environments this is normally not recommended, + because it doesn't feed events into klogd/syslogd and doesn't try to + print anything on the screen. + + You should normally N here, unless you want to debug early crashes or + need a very simple printk logging facility. Another piece of feedback I gave was: > > +config USB_EARLY_PRINTK > > + bool > > Also, could we standardize the nomencalture to not be a mixture of prefixes > and > postfixes - i.e. standardize on postfixes (as commonly done in the Kconfig > space) and rename this one to EARLY_PRINTK_USB or so? yet your latest submission still includes the very same postfixed config switch name that collides with the prefixed names such as EARLY_PRINTK_USB: --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -19,6 +19,9 @@ config USB_EHCI_BIG_ENDIAN_MMIO config USB_EHCI_BIG_ENDIAN_DESC bool +config USB_EARLY_PRINTK + bool + menuconfig USB_SUPPORT bool "USB support" depends on HAS_IOMEM The problem I tried to point out with my review feedback is that we thus have both: CONFIG_EARLY_PRINTK_USB=y CONFIG_USB_EARLY_PRINTK=y ... which is confusing at the very least. On a second look, this config switch appears to be unused - is it a leftover from earlier patches? The patches don't look too bad otherwise, so we are not far from having something acceptable, IMHO. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
