Re: [PATCH v3 8/9] phy: add Broadcom Kona USB2 PHY driver
Hi,
On Monday 25 November 2013 11:46 PM, Matt Porter wrote:
Add a driver for the internal Broadcom Kona USB 2.0 PHY found
on the BCM281xx family of SoCs.
Signed-off-by: Matt Porter matt.por...@linaro.org
---
drivers/phy/Kconfig | 6 ++
drivers/phy/Makefile| 1 +
drivers/phy/phy-bcm-kona-usb2.c | 158
3 files changed, 165 insertions(+)
create mode 100644 drivers/phy/phy-bcm-kona-usb2.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index a344f3d..2e87fa8 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -51,4 +51,10 @@ config PHY_EXYNOS_DP_VIDEO
help
Support for Display Port PHY found on Samsung EXYNOS SoCs.
+config BCM_KONA_USB2_PHY
+ tristate Broadcom Kona USB2 PHY Driver
+ depends on GENERIC_PHY
+ help
+ Enable this to support the Broadcom Kona USB 2.0 PHY.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..c447f1a 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
+obj-$(CONFIG_BCM_KONA_USB2_PHY) += phy-bcm-kona-usb2.o
obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)+= phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
new file mode 100644
index 000..2c54fb8
--- /dev/null
+++ b/drivers/phy/phy-bcm-kona-usb2.c
@@ -0,0 +1,158 @@
+/*
+ * phy-bcm-kona-usb2.c - Broadcom Kona USB2 Phy Driver
+ *
+ * Copyright (C) 2013 Linaro Limited
+ * Matt Porter matt.por...@linaro.org
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/of.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/io.h
+#include linux/clk.h
+#include linux/phy/phy.h
arrange the headers in alphabetical order so that it's easy while adding new
headers. Just my preference.
+
+#define OTGCTL (0)
+#define OTGCTL_OTGSTAT2 (1 31)
+#define OTGCTL_OTGSTAT1 (1 30)
+#define OTGCTL_PRST_N_SW (1 11)
+#define OTGCTL_HRESET_N (1 10)
+#define OTGCTL_UTMI_LINE_STATE1 (1 9)
+#define OTGCTL_UTMI_LINE_STATE0 (1 8)
+
+#define P1CTL(8)
+#define P1CTL_SOFT_RESET (1 1)
+#define P1CTL_NON_DRIVING(1 0)
you can use BIT() instead.
+
+struct bcm_kona_usb {
+ void __iomem *regs;
+};
+
+static void bcm_kona_usb_phy_power(struct bcm_kona_usb *phy, int on)
+{
+ u32 val;
+
+ val = readl(phy-regs + OTGCTL);
+ if (on) {
+ /* Configure and power PHY */
+ val = ~(OTGCTL_OTGSTAT2 | OTGCTL_OTGSTAT1 |
+ OTGCTL_UTMI_LINE_STATE1 | OTGCTL_UTMI_LINE_STATE0);
+ val |= OTGCTL_PRST_N_SW | OTGCTL_HRESET_N;
+ } else {
+ val = ~(OTGCTL_PRST_N_SW | OTGCTL_HRESET_N);
+ }
+ writel(val, phy-regs + OTGCTL);
+}
+
+static int bcm_kona_usb_phy_init(struct phy *gphy)
+{
+ struct bcm_kona_usb *phy = phy_get_drvdata(gphy);
+ u32 val;
+
+ /* Soft reset PHY */
+ val = readl(phy-regs + P1CTL);
+ val = ~P1CTL_NON_DRIVING;
+ val |= P1CTL_SOFT_RESET;
+ writel(val, phy-regs + P1CTL);
+ writel(val ~P1CTL_SOFT_RESET, phy-regs + P1CTL);
+ /* Reset needs to be asserted for 2ms */
+ mdelay(2);
+ writel(val | P1CTL_SOFT_RESET, phy-regs + P1CTL);
+
+ return 0;
+}
+
+static int bcm_kona_usb_phy_power_on(struct phy *gphy)
+{
+ struct bcm_kona_usb *phy = phy_get_drvdata(gphy);
+
+ bcm_kona_usb_phy_power(phy, 1);
+
+ return 0;
+}
+
+static int bcm_kona_usb_phy_power_off(struct phy *gphy)
+{
+ struct bcm_kona_usb *phy = phy_get_drvdata(gphy);
+
+ bcm_kona_usb_phy_power(phy, 0);
+
+ return 0;
+}
+
+static struct phy_ops ops = {
+ .init = bcm_kona_usb_phy_init,
+ .power_on = bcm_kona_usb_phy_power_on,
+ .power_off = bcm_kona_usb_phy_power_off,
+ .owner = THIS_MODULE,
owner is aligned differently..
+};
+
+static int bcm_kona_usb2_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct bcm_kona_usb *phy;
+ struct resource *res;
+ struct phy *gphy;
+ struct phy_provider *phy_provider;
+
+
Re: [PATCH v3 9/9] ARM: dts: add usb udc support to bcm281xx
Hi,
On Monday 25 November 2013 11:46 PM, Matt Porter wrote:
Adds USB OTG/PHY and clock support to BCM281xx and enables
UDC support on the bcm11351-brt and bcm28155-ap boards.
Signed-off-by: Matt Porter matt.por...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
Reviewed-by: Tim Kryger tim.kry...@linaro.org
---
arch/arm/boot/dts/bcm11351-brt.dts | 6 ++
arch/arm/boot/dts/bcm11351.dtsi| 18 ++
arch/arm/boot/dts/bcm28155-ap.dts | 8
3 files changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/bcm11351-brt.dts
b/arch/arm/boot/dts/bcm11351-brt.dts
index 23cd16d..396b704 100644
--- a/arch/arm/boot/dts/bcm11351-brt.dts
+++ b/arch/arm/boot/dts/bcm11351-brt.dts
@@ -44,5 +44,11 @@
status = okay;
};
+ usbotg: usb@3f12 {
+ status = okay;
+ };
using usbotg could have been better. I mean if you have something like
usbotg, you realise that the node has been created somewhere and we are just
referencing it here to add more properties.
Thanks
Kishon
--
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 v2] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks
There are already a generic callbacks that does this. Normally the generic callbacks is used from buses and power domains. My new callbacks are intended to be used from the driver, so those are kind of different from the others in that sense. Hmm. I see. For that to work, the subsystem's .suspend() and .resume() callbacks will have to be implemented in a special way, because of the unknown runtime PM status of devices while those callbacks are being executed. Not sure I understand why you think the runtime PM status is unknown? In .suspend the runtime status can still be changed. Since the PM core disables runtime PM before invoking .suspend_late and since the PM core will keep runtime PM disabled until after the .resume_early has been invoked, it will be safe to operate on the runtime PM callbacks during this period - if the driver/bus are adopted for it. While the .resume callback gets invoked, the runtime status are restored to it's previous state, which the bus/driver would expect. Do you want me to send a patch for a driver that uses these callbacks? I suppose it would clarify how I am thinking... Presumably you think about subsystems that don't implement those callbacks at all? If you mean that drivers is not a part of the term subsystem here, then I somewhat agree. My view is that it will be mostly drivers that make use of these callbacks. Though, I don't think we need to prevent subsystems or power domains from using them, they will only have to know what the consequences are. :-) Maybe there could even be some cases were it actually makes good sense of using them for subsystems, even if I yet not have come a cross such a case. Kind regards Ulf Hansson Rafael -- 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 2/3] ARM: dts: keystone: Add usb devicetree bindings
On 11/26/2013 1:46 AM, WingMan Kwok wrote:
Added device tree support for TI's Keystone USB driver and updated the
Documentation with device tree binding information.
On Keystone II platforms, we use no-op phy driver.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: WingMan Kwok w-kw...@ti.com
---
.../devicetree/bindings/usb/keystone-usb.txt | 43
arch/arm/boot/dts/keystone.dtsi| 27
2 files changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/keystone-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/keystone-usb.txt
b/Documentation/devicetree/bindings/usb/keystone-usb.txt
new file mode 100644
index 000..a67de8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/keystone-usb.txt
@@ -0,0 +1,43 @@
+TI Keystone Soc USB Controller
+
+DWC3 GLUE
+
+Required properties:
+ - compatible: should be ti,keystone-dwc3.
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+ with 'reg' property.
+ - reg : Address and length of the register set for the device. First pair
+ is the USB subsystem specific register set. Second pair is the
+ USB subsystem PHY control register set.
+ - interrupts : The irq number of this device that is used to interrupt the
+ MPU.
+ - ranges: allows valid 1:1 translation between child's address space and
+ parent's address space.
+ - clocks: Clock IDs array as required by the controller.
+ - clock-names: names of clocks correseponding to IDs in the clock property.
+
+Sub-nodes:
+The dwc3 core should be added as subnode to Keystone DWC3 glue.
+- dwc3 :
+ The binding details of dwc3 can be found in:
+ Documentation/devicetree/bindings/usb/dwc3.txt
+
+Example:
+ usb: usb@268 {
+ compatible = ti,keystone-dwc3;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x268 0x1
+ 0x2620738 32;
+ clocks = clkusb;
+ clock-names = usb;
+ interrupts = GIC_SPI 393 IRQ_TYPE_EDGE_RISING;
+ ranges;
+
+ dwc3@269 {
+ compatible = synopsys,dwc3;
+ reg = 0x269 0x7;
+ interrupts = GIC_SPI 393 IRQ_TYPE_EDGE_RISING;
+ usb-phy = usb2_phy, usb3_phy;
+ };
+ };
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index f6d6d9e..1e1049c 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -181,5 +181,32 @@
interrupts = GIC_SPI 300 IRQ_TYPE_EDGE_RISING;
clocks = clkspi;
};
+
+ usb2_phy: usb2_phy {
+ compatible = usb-nop-xceiv;
+ };
+
+ usb3_phy: usb3_phy {
+ compatible = usb-nop-xceiv;
+ };
+
+ usb: usb@268 {
+ compatible = ti,keystone-dwc3;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x268 0x1
+ 0x2620738 32;
+ clocks = clkusb;
+ clock-names = usb;
+ interrupts = GIC_SPI 393 IRQ_TYPE_EDGE_RISING;
You don't have seperate interrrupt for wrapper and core?
Is it the same interrupt shared between XHCI,DWC3 and wrapper?
+ ranges;
+
+ dwc3@269 {
+ compatible = synopsys,dwc3;
+ reg = 0x269 0x7;
+ interrupts = GIC_SPI 393 IRQ_TYPE_EDGE_RISING;
+ usb-phy = usb2_phy, usb3_phy;
+ };
+ };
};
};
--
-George
--
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: huawei E5776 (hilink) 3.12--3.13 not working anymore
Thomas Schäfer tschae...@t-online.de writes: Hi, I have it already mentioned somewhere. Sorry for duplicates. The Huawei E5776 (normal use, classic IPv4, hilink mode (with webinterface and RFC1918 IP- config including NAT) So this is always connected and you don't normally use ModemManager or any other userspace utility to manage it? I guess it should be a wwan device at all then, but I don't see how we can avoid that given that both PID and subclass/protocol is same as managed modems. Anyway, this is obviously not the problem in your case. worked well with 3.12 and before, but it doesn't work any more with 3.13. At least one local branded version of the huawei E3776 is also affected. Yes, and you already tested reverting all changes to cdc_ncm with that modem, was that so? You still have the same problems with the v3.12 version of cdc_ncm running on v3.13-rc1+? How about looking at usbmon differences? That should show us where things start to go wrong. Bjørn -- 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] usb: s3c-hsotg: change dependency to PLAT_SAMSUNG
On device tree based Samsung SoC platforms (like Exynos) no platform devices are defined and CONFIG_S3C_DEV_USB_HSOTG is no longer available, so change the driver dependency to more generic and appropriate CONFIG_PLAT_SAMSUNG, as the driver can be used on almost all Samsung platforms. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/usb/gadget/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index a91e642..83983ee 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -295,7 +295,7 @@ config USB_PXA27X config USB_S3C_HSOTG tristate S3C HS/OtG USB Device controller - depends on S3C_DEV_USB_HSOTG + depends on PLAT_SAMSUNG help The Samsung S3C64XX USB2.0 high-speed gadget controller integrated into the S3C64XX series SoC. -- 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
Re: huawei E5776 (hilink) 3.12--3.13 not working anymore
Am 27.11.2013 13:33, schrieb Bjørn Mork: Thomas Schäfer tschae...@t-online.de writes: Hi, I have it already mentioned somewhere. Sorry for duplicates. The Huawei E5776 (normal use, classic IPv4, hilink mode (with webinterface and RFC1918 IP- config including NAT) So this is always connected and you don't normally use ModemManager or any other userspace utility to manage it? Yes. I am not sure if Networkmanager was involved, but if so, he did only dhcp. (or I started the dhcpcd ) I guess it should be a wwan device at all then, but I don't see how we can avoid that given that both PID and subclass/protocol is same as managed modems. Some other hilink-devices, I have seen, use cdc_ether instead, still working with 3.13. Anyway, this is obviously not the problem in your case. worked well with 3.12 and before, but it doesn't work any more with 3.13. At least one local branded version of the huawei E3776 is also affected. Yes, and you already tested reverting all changes to cdc_ncm with that modem, was that so? You still have the same problems with the v3.12 version of cdc_ncm running on v3.13-rc1+? If I remember correctly yes. How about looking at usbmon differences? That should show us where things start to go wrong. I will try it tonight. Thomas PS: in the meantime I was shocked by the change of 0930:1319 Ericsson H5321gw from cdc_ncm to mbim in older kernel-versions. But this is a different site. I will test mbim on this device later, because first tests are stopped by compiling problems at the live-CD. -- 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 v2] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks
On Wednesday, November 27, 2013 10:59:57 AM Ulf Hansson wrote: There are already a generic callbacks that does this. Normally the generic callbacks is used from buses and power domains. My new callbacks are intended to be used from the driver, so those are kind of different from the others in that sense. Hmm. I see. For that to work, the subsystem's .suspend() and .resume() callbacks will have to be implemented in a special way, because of the unknown runtime PM status of devices while those callbacks are being executed. Not sure I understand why you think the runtime PM status is unknown? In .suspend the runtime status can still be changed. Since the PM core disables runtime PM before invoking .suspend_late and since the PM core will keep runtime PM disabled until after the .resume_early has been invoked, it will be safe to operate on the runtime PM callbacks during this period - if the driver/bus are adopted for it. While the .resume callback gets invoked, the runtime status are restored to it's previous state, which the bus/driver would expect. Do you want me to send a patch for a driver that uses these callbacks? I suppose it would clarify how I am thinking... Presumably you think about subsystems that don't implement those callbacks at all? If you mean that drivers is not a part of the term subsystem here, then I somewhat agree. My view is that it will be mostly drivers that make use of these callbacks. Though, I don't think we need to prevent subsystems or power domains from using them, they will only have to know what the consequences are. :-) Maybe there could even be some cases were it actually makes good sense of using them for subsystems, even if I yet not have come a cross such a case. We first need to clarify the terminology as that seems to be the source of the confusion to some extent at least. When I (or Alan presumably too) say a subsystem, I mean a bus type, a device type or a device class as represented by struct bus_type, struct device_type and struct class, respectively. So a subsystem callback means the specific callback defined in the given bus type, device type or device class object. You can think about that as of subsystem level if that's easier. So that's what we mean when we talk about subsystems, not the whole collection of drivers and the code above them. Now, say you have a bus type. Usually, the bus type's PM callbacks will run device drivers' PM callbacks. Quite often they will do things to hardware in addition to what the drivers do. But if your driver's .suspend_late() depends on the runtime PM status of the device, then the bus type's .suspend() needs to preserve that status. That is, it cannot do anything to the hardware that may cause the runtime PM status of the device to become stale. That makes the .suspend() somewhat special, doesn't it? Now I *guess* that your goal is something like if that device has been runtime suspended, don't touch it, which is a reasonable goal to have. I'd like to implement something like that too, but I think that it needs to be done differently. Actually, my idea is to allow the subsystem-level .prepare() callback to let the core know if the device needs to be handled during the given suspend/resume cycle. It may be arranged, for example, so that if the subsystem-level (e.g. bus type) .prepare() returns a positive number, the core will put the device into a special list and it won't take it into consideration at all during the whole cycle. Why this way? Because subsystems have much better ways to determine whether or not it is necessary to access the device during the upcoming system suspend/resume cycle than the core does. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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: huawei E5776 (hilink) 3.12--3.13 not working anymore
Thomas Schäfer tschae...@t-online.de writes: Am 27.11.2013 13:33, schrieb Bjørn Mork: Thomas Schäfer tschae...@t-online.de writes: Hi, I have it already mentioned somewhere. Sorry for duplicates. The Huawei E5776 (normal use, classic IPv4, hilink mode (with webinterface and RFC1918 IP- config including NAT) So this is always connected and you don't normally use ModemManager or any other userspace utility to manage it? Yes. I am not sure if Networkmanager was involved, but if so, he did only dhcp. (or I started the dhcpcd ) I guess it should be a wwan device at all then, but I don't see how we can avoid that given that both PID and subclass/protocol is same as managed modems. Some other hilink-devices, I have seen, use cdc_ether instead, still working with 3.13. Anyway, this is obviously not the problem in your case. worked well with 3.12 and before, but it doesn't work any more with 3.13. At least one local branded version of the huawei E3776 is also affected. Yes, and you already tested reverting all changes to cdc_ncm with that modem, was that so? You still have the same problems with the v3.12 version of cdc_ncm running on v3.13-rc1+? If I remember correctly yes. How about looking at usbmon differences? That should show us where things start to go wrong. I will try it tonight. Thomas PS: in the meantime I was shocked by the change of 0930:1319 Ericsson H5321gw from cdc_ncm to mbim in older kernel-versions. Yes, that is a problem caused by the shared NCM/MBIM function these devices use. The choice must be made by the kernel, because it is a choice between different drivers. The best I could come up with is the cdc_ncm module parameter setting the policy: prefer_mbim=N implies that NCM is preferred. You can set the parameter when loading cdc_ncm, or any time later by writing to /sys/module/cdc_ncm/parameters/prefer_mbim. But you'll have to force the modem to be reprobed somehow after making a change, so it's probably best to set the option in a modprobe config file for built-in modems like the H5321gw Bjørn -- 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] A patch fro support alcatel's new products
On Wed, Nov 27, 2013 at 05:54:03AM +, Yanan, SUO(MBB-SZ-TCT) wrote: Hi : We want make our new product work well on Linux(fedora, Debian, Ubuntu) Android, and have make patch tested ,It,s perfect. It is? :) Unfortunatly you sent this email in html form, with a base64 attachment, which means I can't really apply it, and you typed the mailing list address incorrectly (hand fixed...) Can you please read the kernel file, Documentation/email_clients.txt and fix your email client to be able to send the patch properly? Also, the whitespace in your patch is really odd, why didn't you use tabs for the device ids? And you added some new lines for no reason. Also, do you really need the blasklist bits? Why? Can you please clean up the formatting of the patch and resend it not in html format, so that the mailing list can get it? 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
Re: 【PATCH】USB：add new zte 3g-modem's pid to option.c
On Wed, Nov 27, 2013 at 05:01:59PM +0800, zhang.ju...@zte.com.cn wrote:
Signed-off-by: Jun zhang zhang.ju...@zte.com.cn
--- drivers/usb/serial/option.cThu Nov 21 04:37:52 2013
+++ drivers/usb/serial/option_bac.cWed Nov 27 16:00:58 2013
@@ -1427,6 +1427,19 @@
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x05) },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x86, 0x10) },
+{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xffe9, 0xff, 0xff,
0xff) },
+/* Backup */
What do you mean by backup here?
+{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff8b, 0xff, 0xff,
0xff) },
+{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff8c, 0xff, 0xff,
0xff) },
+{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff8d, 0xff, 0xff,
0xff) },
+{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff8e, 0xff, 0xff,
0xff) },
+{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff8f, 0xff, 0xff,
0xff) },
+{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff90, 0xff, 0xff,
0xff) },
+{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff91, 0xff, 0xff,
0xff) },
+{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff92, 0xff, 0xff,
0xff) },
+{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff93, 0xff, 0xff,
0xff) },
+{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff94, 0xff, 0xff,
0xff) },
+
Did you run your patch through scripts/checkpatch.pl? You added extra
whitespace here.
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
Re: [PATCH v2] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks
We first need to clarify the terminology as that seems to be the source of the confusion to some extent at least. When I (or Alan presumably too) say a subsystem, I mean a bus type, a device type or a device class as represented by struct bus_type, struct device_type and struct class, respectively. So a subsystem callback means the specific callback defined in the given bus type, device type or device class object. You can think about that as of subsystem level if that's easier. So that's what we mean when we talk about subsystems, not the whole collection of drivers and the code above them. Thanks, this makes it perfectly clear now. I will try to improve while communicating. So we have subsystems, power domains and drivers to consider. Now, say you have a bus type. Usually, the bus type's PM callbacks will run device drivers' PM callbacks. Quite often they will do things to hardware in addition to what the drivers do. But if your driver's .suspend_late() depends on the runtime PM status of the device, then the bus type's .suspend() needs to preserve that status. That is, it cannot do anything to the hardware that may cause the runtime PM status of the device to become stale. That makes the .suspend() somewhat special, doesn't it? I agree, but I can see why this should be a problem for each and every driver/bus. Do note that idea here is only to provide the option of allowing runtime PM callbacks to be executed as a part of the suspend_late - resume_early sequence. It is not a rule, it will have to be decided for each subsystem/driver it they can benefit from this set up. Now I *guess* that your goal is something like if that device has been runtime suspended, don't touch it, which is a reasonable goal to have. I'd like to implement something like that too, but I think that it needs to be done differently. That is just a minor important part, but nice to have. Please have look at the recently submitted patch set, [PATCH 0/5] PM: Enable option of re-use runtime PM callbacks at system suspend, I hope the cover letter will describe my intention better. Actually, my idea is to allow the subsystem-level .prepare() callback to let the core know if the device needs to be handled during the given suspend/resume cycle. It may be arranged, for example, so that if the subsystem-level (e.g. bus type) .prepare() returns a positive number, the core will put the device into a special list and it won't take it into consideration at all during the whole cycle. Why this way? Because subsystems have much better ways to determine whether or not it is necessary to access the device during the upcoming system suspend/resume cycle than the core does. I am not sure I understand how this will solve my issues (except the minor if that device has been runtime suspended, don't touch it - thing). I will still have to have a complex power domain and still drivers/buses need wrapper functions around their the runtime PM callbacks to invoke them during system suspend, if they need them. In my view, I don't think your idea is conflict or can replace what I suggest. Both can improve the situation, but maybe for different scenarios. Kind regards Ulf Hansson Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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 v2] PM / Sleep: Add pm_generic functions to re-use runtime PM callbacks
On 27 November 2013 17:05, Ulf Hansson ulf.hans...@linaro.org wrote: We first need to clarify the terminology as that seems to be the source of the confusion to some extent at least. When I (or Alan presumably too) say a subsystem, I mean a bus type, a device type or a device class as represented by struct bus_type, struct device_type and struct class, respectively. So a subsystem callback means the specific callback defined in the given bus type, device type or device class object. You can think about that as of subsystem level if that's easier. So that's what we mean when we talk about subsystems, not the whole collection of drivers and the code above them. Thanks, this makes it perfectly clear now. I will try to improve while communicating. So we have subsystems, power domains and drivers to consider. Now, say you have a bus type. Usually, the bus type's PM callbacks will run device drivers' PM callbacks. Quite often they will do things to hardware in addition to what the drivers do. But if your driver's .suspend_late() depends on the runtime PM status of the device, then the bus type's .suspend() needs to preserve that status. That is, it cannot do anything to the hardware that may cause the runtime PM status of the device to become stale. That makes the .suspend() somewhat special, doesn't it? can - can't I agree, but I can see why this should be a problem for each and every driver/bus. Do note that idea here is only to provide the option of allowing runtime PM callbacks to be executed as a part of the suspend_late - resume_early sequence. It is not a rule, it will have to be decided for each subsystem/driver it they can benefit from this set up. Now I *guess* that your goal is something like if that device has been runtime suspended, don't touch it, which is a reasonable goal to have. I'd like to implement something like that too, but I think that it needs to be done differently. That is just a minor important part, but nice to have. Please have look at the recently submitted patch set, [PATCH 0/5] PM: Enable option of re-use runtime PM callbacks at system suspend, I hope the cover letter will describe my intention better. Actually, my idea is to allow the subsystem-level .prepare() callback to let the core know if the device needs to be handled during the given suspend/resume cycle. It may be arranged, for example, so that if the subsystem-level (e.g. bus type) .prepare() returns a positive number, the core will put the device into a special list and it won't take it into consideration at all during the whole cycle. Why this way? Because subsystems have much better ways to determine whether or not it is necessary to access the device during the upcoming system suspend/resume cycle than the core does. I am not sure I understand how this will solve my issues (except the minor if that device has been runtime suspended, don't touch it - thing). I will still have to have a complex power domain and still drivers/buses need wrapper functions around their the runtime PM callbacks to invoke them during system suspend, if they need them. In my view, I don't think your idea is conflict or can replace what I suggest. Both can improve the situation, but maybe for different scenarios. Kind regards Ulf Hansson Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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: Xhci Host not allowed to send get device desc at addr zero
Hi Pratyush, Douglas Turner pointed me to this thread discussion http://www.spinics.net/lists/linux-usb/msg95103.html seems there is some issue to use new scheme enumeration with super speed devices Hi Sarah, Any comments will be appreciated Thanks, Aymen -Original Message- From: Pratyush Anand [mailto:pratyush.an...@gmail.com] Sent: mardi 26 novembre 2013 14:06 To: Aymen BOUATTAY; sarah.a.sh...@linux.intel.com Cc: linux-usb@vger.kernel.org Subject: Re: Xhci Host not allowed to send get device desc at addr zero Hi Aymen On Tue, Nov 26, 2013 at 4:31 PM, Aymen BOUATTAY aymen.bouat...@st.com wrote: Hi, I'm using Kernel release 3.4 with an embedded xhci host controller Seems USB core driver does not allow xhci controller to send a get device descriptor at address zero As when a device is attached to the root hub, usb core driver reset the device and if the link is superspeed than do a set_address LeCroy Compliance test TD7.06 Data Payload Packet Framing Robustness test script expects for get device descriptor at @ zero from host How to let xhci controller sending a get device descriptor command before setting an address to USB3 device ? It does not work because USE_NEW_SCHEME has not been enabled for super speed devices. I see following comment An xHCI controller cannot send any packets to a device until a set address command successfully completes. in commit c6515272b858742962c1de0f3bf497a048b9abd7 Author: Sarah Sharp sarah.a.sh...@linux.intel.com Date: Mon Apr 27 19:57:26 2009 -0700 USB: Support for addressing a USB device under xHCI Hi Sarah, But as per usb3.0 specs section 9.4.3 get descriptor should be allowed in default state. xhci specs is not very clear about it. xhci specs says once a successful address device command has completed, system software can issue USB GET_DESCRIPTOR request through Default Control Endpoint to retrieve the USB Device, configuration, etc. descriptors from USB device. So, what if XHCI Software issues, SET ADDRESS(0) followed by GET DESC(Device). Regards Pratyush Thanks, Aymen -- 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 -- 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: huawei E5776 (hilink) 3.12--3.13 not working anymore
On 2013-11-27 04:22, Thomas Schäfer wrote: Hi, I have it already mentioned somewhere. Sorry for duplicates. The Huawei E5776 (normal use, classic IPv4, hilink mode (with webinterface and RFC1918 IP- config including NAT) worked well with 3.12 and before, but it doesn't work any more with 3.13. At least one local branded version of the huawei E3776 is also affected. Thomas Thomas, this is an ncm device afaik and support has been moved from cdc_ncm to huawei_cdc_ncm in 3.13 -- 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: BUG: usb: obex in g_nokia.ko causing kernel panic
On Tuesday 26 November 2013 20:03:11 Felipe Balbi wrote: Hi, On Tue, Nov 26, 2013 at 12:59:13PM -0600, Felipe Balbi wrote: diff --git a/drivers/usb/gadget/f_obex.c b/drivers/usb/gadget/f_obex.c index ad39f1d..4af2f06 100644 --- a/drivers/usb/gadget/f_obex.c +++ b/drivers/usb/gadget/f_obex.c @@ -267,10 +267,12 @@ static void obex_connect(struct gserial *g) if (!obex-can_activate) return; +#if 0 status = usb_function_activate(g-func); if (status) DBG(cdev, obex ttyGS%d function activate -- %d\n, obex-port_num, status); +#endif } static void obex_disconnect(struct gserial *g) @@ -282,10 +284,12 @@ static void obex_disconnect(struct gserial *g) if (!obex-can_activate) return; +#if 0 status = usb_function_deactivate(g-func); if (status) DBG(cdev, obex ttyGS%d function deactivate -- %d\n, obex-port_num, status); +#endif } /*- -- --*/ @@ -372,6 +376,7 @@ static int obex_bind(struct usb_configuration *c, struct usb_function *f) if (status) goto fail; +#if 0 /* Avoid letting this gadget enumerate until the userspace * OBEX server is active. */ @@ -381,6 +386,7 @@ static int obex_bind(struct usb_configuration *c, struct usb_function *f) obex-port_num, status); else obex-can_activate = true; +#endif DBG(cdev, obex ttyGS%d: %s speed IN/%s OUT/%s\n, Hi, with above patch g_nokia.ko working and not crashing. yeah, makes sense. We shouldn't call phy operations in atomic context. I'll see how easy it would be to fix that. Real patch coming soon(-ish). I think we could send diff below for the -rc cycle and figure out a better to handle this for the merge window. Can you check if it also works with patch below ? diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 2a408cd..8aa59a2 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -659,7 +659,6 @@ static int omap2430_runtime_suspend(struct device *dev) OTG_INTERFSEL); omap2430_low_level_exit(musb); - phy_power_off(musb-phy); } return 0; @@ -674,7 +673,6 @@ static int omap2430_runtime_resume(struct device *dev) omap2430_low_level_init(musb); musb_writel(musb-mregs, OTG_INTERFSEL, musb-context.otg_interfsel); - phy_power_on(musb-phy); } return 0; Hi, I applied similar patch (commented usb_phy_set_suspend instead phy_power_on/off) on 3.12-rc5 and it working too, no crash. I do not have rebased n900 patches on top of 3.13 tree, so I cannot check it. But I think phy_power_on/off doing same as usb_phy_set_suspend in 3.12. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: zte_ev not properly handling ZTE AC2726 CDMA modems
On Wed, 27 Nov 2013, Johan Hovold wrote: I am attaching the output that I am getting in the syslog. Note that I have two usb modems connected to that router and that's how I am able to debug it. 2-1 is an external USB2.0 hub, 2-1.2 is the ZTE modem, and 2-1.1 is a Huawei CDMA modem, which is working fine. The problem happens both with and without a hub. The transmissions are failing with -ENOENT (-2), and the clear tt buffer are related to the hub. Can you get a log from when not using the hub? Could you try reproducing this on v3.12? Alan, what do you think of this? The -ENOENT means that the transfers were cancelled. Perhaps because of a timeout or perhaps for some other reason. The clear tt buffer lines are merely side effects of the cancelled transfers. Running the test without the external hub ought to eliminate them. It would simplify the test results, so it's worth doing. Also, it might be worthwhile to collect a usbmon trace during the test. The output might be meaningful to somebody who understands how this driver is supposed to work. Alan Stern -- 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 v3 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls
On Tue, Nov 26, 2013 at 03:46:26PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Monday 25 November 2013 11:45 PM, Matt Porter wrote:
This adds a pair of APIs that allows the generic PHY subsystem to
provide information on the PHY bus width. The PHY provider driver may
use phy_set_bus_width() to set the bus width that the PHY supports.
The controller driver may then use phy_get_bus_width() to fetch the
PHY bus width in order to properly configure the controller.
Signed-off-by: Matt Porter matt.por...@linaro.org
---
include/linux/phy/phy.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 6d72269..6ca6c61 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -46,6 +46,7 @@ struct phy_ops {
* @mutex: mutex to protect phy_ops
* @init_count: used to protect when the PHY is used by multiple consumers
* @power_count: used to protect when the PHY is used by multiple consumers
+ * @bus_width: used to specify data width of the PHY bus
*/
struct phy {
struct device dev;
@@ -55,6 +56,7 @@ struct phy {
struct mutexmutex;
int init_count;
int power_count;
+ int bus_width;
the bus_width can be part of the attrs struct which you initially proposed.
Soon there will be requests for other attributes being added (e.g., speed).
Agreed, I'll merge the accessors with the original attrs struct.
};
/**
@@ -127,6 +129,14 @@ int phy_init(struct phy *phy);
int phy_exit(struct phy *phy);
int phy_power_on(struct phy *phy);
int phy_power_off(struct phy *phy);
+static inline int phy_get_bus_width(struct phy *phy)
+{
+ return phy-bus_width;
+}
+static inline void phy_set_bus_width(struct phy *phy, int bus_width)
u32 bus_width?
will update
+{
+ phy-bus_width = bus_width;
+}
struct phy *phy_get(struct device *dev, const char *string);
struct phy *devm_phy_get(struct device *dev, const char *string);
void phy_put(struct phy *phy);
@@ -199,6 +209,16 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
}
+static inline int phy_get_bus_width(struct phy *phy)
+{
+ return -ENOSYS;
+}
+
+static inline void phy_set_bus_width(struct phy *phy, bus_width)
er.. has this been compile tested?
*sigh* obviously not, will address this.
-Matt
--
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 v3 2/9] staging: dwc2: update DT binding to add generic clock/phy properties
On Tue, Nov 26, 2013 at 03:49:30PM +0530, Kishon Vijay Abraham I wrote: On Monday 25 November 2013 11:46 PM, Matt Porter wrote: dwc2/s3c-hsotg require a single clock to be specified and optionally a generic phy. On the s3c-hsotg driver old style USB phy support is present as a fallback so the generic phy properties are optional. Signed-off-by: Matt Porter matt.por...@linaro.org --- Documentation/devicetree/bindings/staging/dwc2.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/staging/dwc2.txt b/Documentation/devicetree/bindings/staging/dwc2.txt index 1a1b7cf..b8b42b6 100644 --- a/Documentation/devicetree/bindings/staging/dwc2.txt +++ b/Documentation/devicetree/bindings/staging/dwc2.txt @@ -5,6 +5,12 @@ Required properties: - compatible : snps,dwc2 - reg : Should contain 1 register range (address and length) - interrupts : Should contain 1 interrupt +- clocks: clock provider specifier +- clock-names: shall be otg +- phys: phy provider specifier +- phy-names: shall be device lets mention in the Documentation too that the phy properties are optional. apart from that.. Good point, will do so. Acked-by: Kishon Vijay Abraham I kis...@ti.com +Refer to clk/clock-bindings.txt for generic clock consumer properties +Refer to phy/phy-bindings.txt for generic phy consumer properties Example: @@ -12,4 +18,8 @@ Example: compatible = ralink,rt3050-usb, snps,dwc2; reg = 0x101c 4; interrupts = 18; + clocks = usb_otg_ahb_clk; + clock-names = otg; + phys = usbphy; + phy-names = device; }; -- 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 v3 5/9] usb: gadget: s3c-hsotg: use generic phy_init()/phy_exit() support
On Tue, Nov 26, 2013 at 03:53:32PM +0530, Kishon Vijay Abraham I wrote: Hi, On Monday 25 November 2013 11:46 PM, Matt Porter wrote: If a generic phy is present, call phy_init()/phy_exit(). This supports generic phys that must be soft reset before power on. Signed-off-by: Matt Porter matt.por...@linaro.org --- drivers/usb/gadget/s3c-hsotg.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c index da3879b..8dfe33f 100644 --- a/drivers/usb/gadget/s3c-hsotg.c +++ b/drivers/usb/gadget/s3c-hsotg.c @@ -3622,6 +3622,9 @@ static int s3c_hsotg_probe(struct platform_device *pdev) goto err_supplies; } + if (hsotg-phy) IS_ERR? If your phy_get fails *phy* will have a error value.. Yes, thanks. I'll fix these and also note that the same issue exists in Kamil's patch for these same hsotg-phy conditional uses. I'll work with Kamil to either get those addressed there or in a follow on fix. + phy_init(hsotg-phy); + /* usb phy enable */ s3c_hsotg_phy_enable(hsotg); @@ -3715,6 +3718,8 @@ static int s3c_hsotg_remove(struct platform_device *pdev) } s3c_hsotg_phy_disable(hsotg); + if (hsotg-phy) same here. Ok. Thanks Kishon -- 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 v3 6/9] usb: gadget: s3c-hsotg: get phy bus width from phy subsystem
On Tue, Nov 26, 2013 at 03:58:45PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Monday 25 November 2013 11:46 PM, Matt Porter wrote:
Adds support for querying the phy bus width from the generic phy
subsystem. Configure UTMI bus width in GUSBCFG based on this value.
Signed-off-by: Matt Porter matt.por...@linaro.org
---
drivers/usb/gadget/s3c-hsotg.c | 14 +-
drivers/usb/gadget/s3c-hsotg.h | 1 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index 8dfe33f..be41585 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -144,6 +144,7 @@ struct s3c_hsotg_ep {
* @regs: The memory area mapped for accessing registers.
* @irq: The IRQ number we are using
* @supplies: Definition of USB power supplies
+ * @phyif: PHY interface width
* @dedicated_fifos: Set if the hardware has dedicated IN-EP fifos.
* @num_of_eps: Number of available EPs (excluding EP0)
* @debug_root: root directrory for debugfs.
@@ -171,6 +172,7 @@ struct s3c_hsotg {
struct regulator_bulk_data supplies[ARRAY_SIZE(s3c_hsotg_supply_names)];
+ u32 phyif;
unsigned intdedicated_fifos:1;
unsigned char num_of_eps;
@@ -2276,7 +2278,7 @@ static void s3c_hsotg_core_init(struct s3c_hsotg
*hsotg)
*/
/* set the PLL on, remove the HNP/SRP and set the PHY */
- writel(GUSBCFG_PHYIf16 | GUSBCFG_TOutCal(7) |
+ writel(hsotg-phyif | GUSBCFG_TOutCal(7) |
(0x5 10), hsotg-regs + GUSBCFG);
s3c_hsotg_init_fifo(hsotg);
@@ -3622,6 +3624,16 @@ static int s3c_hsotg_probe(struct platform_device
*pdev)
goto err_supplies;
}
+ /* Set default UTMI width */
+ hsotg-phyif = GUSBCFG_PHYIf16;
+
+ /*
+* If using the generic PHY framework, check if the PHY bus
+* width is 8-bit and set the phyif appropriately.
+*/
+ if (hsotg-phy (phy_get_bus_width(phy) == 8))
what if the phy has error value here?
I'm addressing this like the other !IS_ERR checks. In the platform data
case, we'll have an error value here, and need to use the default. Until
the platform data case is removed (those platform board files removed),
we assume (correctly) that they use a phy interface width of 16.
-Matt
--
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 v3 7/9] phy: add Broadcom Kona USB2 PHY DT binding
On Tue, Nov 26, 2013 at 04:01:05PM +0530, Kishon Vijay Abraham I wrote: Hi, On Monday 25 November 2013 11:46 PM, Matt Porter wrote: Add a binding that describes the Broadcom Kona USB2 PHY found on the BCM281xx family of SoCs. Signed-off-by: Matt Porter matt.por...@linaro.org --- .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt | 15 +++ 1 file changed, 15 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt diff --git a/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt new file mode 100644 index 000..3dc8b3d --- /dev/null +++ b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt you should name this bcm-phy. Then you can add binding info of all (future) PHY IP from broadcom here. other than that this looks fine.. Ok, sounds reasonable. I've noticed that convention with the TI USB bindings...I'll do the same. Acked-by: Kishon Vijay Abraham I kis...@ti.com Thanks Kishon -- 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 v3 8/9] phy: add Broadcom Kona USB2 PHY driver
On Wed, Nov 27, 2013 at 02:21:52PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Monday 25 November 2013 11:46 PM, Matt Porter wrote:
Add a driver for the internal Broadcom Kona USB 2.0 PHY found
on the BCM281xx family of SoCs.
Signed-off-by: Matt Porter matt.por...@linaro.org
---
drivers/phy/Kconfig | 6 ++
drivers/phy/Makefile| 1 +
drivers/phy/phy-bcm-kona-usb2.c | 158
3 files changed, 165 insertions(+)
create mode 100644 drivers/phy/phy-bcm-kona-usb2.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index a344f3d..2e87fa8 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -51,4 +51,10 @@ config PHY_EXYNOS_DP_VIDEO
help
Support for Display Port PHY found on Samsung EXYNOS SoCs.
+config BCM_KONA_USB2_PHY
+ tristate Broadcom Kona USB2 PHY Driver
+ depends on GENERIC_PHY
+ help
+ Enable this to support the Broadcom Kona USB 2.0 PHY.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..c447f1a 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
diff --git a/drivers/phy/phy-bcm-kona-usb2.c
b/drivers/phy/phy-bcm-kona-usb2.c
new file mode 100644
index 000..2c54fb8
--- /dev/null
+++ b/drivers/phy/phy-bcm-kona-usb2.c
@@ -0,0 +1,158 @@
+/*
+ * phy-bcm-kona-usb2.c - Broadcom Kona USB2 Phy Driver
+ *
+ * Copyright (C) 2013 Linaro Limited
+ * Matt Porter matt.por...@linaro.org
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/of.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/io.h
+#include linux/clk.h
+#include linux/phy/phy.h
arrange the headers in alphabetical order so that it's easy while adding new
headers. Just my preference.
yeah, same here. just development creep that I will address.
+
+#define OTGCTL (0)
+#define OTGCTL_OTGSTAT2(1 31)
+#define OTGCTL_OTGSTAT1(1 30)
+#define OTGCTL_PRST_N_SW (1 11)
+#define OTGCTL_HRESET_N(1 10)
+#define OTGCTL_UTMI_LINE_STATE1(1 9)
+#define OTGCTL_UTMI_LINE_STATE0(1 8)
+
+#define P1CTL (8)
+#define P1CTL_SOFT_RESET (1 1)
+#define P1CTL_NON_DRIVING (1 0)
you can use BIT() instead.
will do
+
+struct bcm_kona_usb {
+ void __iomem *regs;
+};
+
+static void bcm_kona_usb_phy_power(struct bcm_kona_usb *phy, int on)
+{
+ u32 val;
+
+ val = readl(phy-regs + OTGCTL);
+ if (on) {
+ /* Configure and power PHY */
+ val = ~(OTGCTL_OTGSTAT2 | OTGCTL_OTGSTAT1 |
+OTGCTL_UTMI_LINE_STATE1 | OTGCTL_UTMI_LINE_STATE0);
+ val |= OTGCTL_PRST_N_SW | OTGCTL_HRESET_N;
+ } else {
+ val = ~(OTGCTL_PRST_N_SW | OTGCTL_HRESET_N);
+ }
+ writel(val, phy-regs + OTGCTL);
+}
+
+static int bcm_kona_usb_phy_init(struct phy *gphy)
+{
+ struct bcm_kona_usb *phy = phy_get_drvdata(gphy);
+ u32 val;
+
+ /* Soft reset PHY */
+ val = readl(phy-regs + P1CTL);
+ val = ~P1CTL_NON_DRIVING;
+ val |= P1CTL_SOFT_RESET;
+ writel(val, phy-regs + P1CTL);
+ writel(val ~P1CTL_SOFT_RESET, phy-regs + P1CTL);
+ /* Reset needs to be asserted for 2ms */
+ mdelay(2);
+ writel(val | P1CTL_SOFT_RESET, phy-regs + P1CTL);
+
+ return 0;
+}
+
+static int bcm_kona_usb_phy_power_on(struct phy *gphy)
+{
+ struct bcm_kona_usb *phy = phy_get_drvdata(gphy);
+
+ bcm_kona_usb_phy_power(phy, 1);
+
+ return 0;
+}
+
+static int bcm_kona_usb_phy_power_off(struct phy *gphy)
+{
+ struct bcm_kona_usb *phy = phy_get_drvdata(gphy);
+
+ bcm_kona_usb_phy_power(phy, 0);
+
+ return 0;
+}
+
+static struct phy_ops ops = {
+ .init = bcm_kona_usb_phy_init,
+ .power_on = bcm_kona_usb_phy_power_on,
+ .power_off = bcm_kona_usb_phy_power_off,
+ .owner = THIS_MODULE,
owner is aligned differently..
ok
+};
+
+static int bcm_kona_usb2_probe(struct
Re: [RFC PATCH] usb: gadget/uvc: add streaming and data event handling
Hi Michal,
Thank you for the patch, and sorry for the late reply.
On Friday 06 September 2013 00:18:54 Michael Grzeschik wrote:
This patch lets the kernel handle setup and data events of
the uvc gadget. It is generating its response data by the
prepared usb uvc control descriptores.
For now only simple probe and commit events are generated and
stored inside the uvc_device structure.
While I like to idea of handling requests in the kernel without userspace
intervention, the current implementation is too limited. All requests but
streaming control requests are ignored. The unsupported requests should be
forwarded to userspace instead (there's no way to handle controls in the
kernel).
The implementation of streaming control requests is in my opinion also
problematic. UVC_GET_MIN and UVC_GET_DEF return the same values and don't
support use cases where the default value should be different than the minimum
value. The compression quality isn't handled, and should be forwarded to
userspace. Setting the streaming commit control during streaming isn't
disallowed.
To summarize my point, this is an interesting idea, but the implementation
hasn't reached a point where it could be mainlined.
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
drivers/usb/gadget/f_uvc.c| 273 ---
drivers/usb/gadget/uvc.h | 7 ++
drivers/usb/gadget/uvc_v4l2.c | 12 --
3 files changed, 265 insertions(+), 27 deletions(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index e2a1f50..73fdf90 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -213,20 +213,257 @@ static const struct usb_descriptor_header * const
uvc_ss_streaming[] = { */
static void
+uvc_get_format(struct uvc_device *uvc, struct uvc_streaming_control *ctrl,
struct v4l2_format *fmt)
+{
+ unsigned int nframes = 1, pformat = 1;
+ struct usb_composite_dev *cdev = uvc-func.config-cdev;
+ const struct uvc_descriptor_header * const *uvc_streaming_cls;
+ const struct uvc_descriptor_header *format, *frame;
+ struct uvc_input_header_descriptor *input;
+ unsigned int absdiff, count;
+
+ /* main descriptor */
+ uvc_streaming_cls = uvc-desc.fs_streaming;
+ if (gadget_is_dualspeed(cdev-gadget))
+ uvc_streaming_cls = uvc-desc.hs_streaming;
+ if (gadget_is_superspeed(cdev-gadget))
+ uvc_streaming_cls = uvc-desc.ss_streaming;
+
+ /* input header */
+ input = (struct uvc_input_header_descriptor *) *uvc_streaming_cls;
+ ctrl-bFormatIndex =
+ clamp((unsigned int)ctrl-bFormatIndex, 1U, (unsigned
int)input-bNumFormats);
+
+ /* format header */
+ do {
+ uvc_streaming_cls += nframes; /* skip to the next format header
*/
+ format = *uvc_streaming_cls;
+ if (format-bDescriptorSubType == UVC_VS_FORMAT_UNCOMPRESSED) {
+ struct uvc_format_uncompressed *yuyv =
+ (struct uvc_format_uncompressed *)format;
+ nframes = yuyv-bNumFrameDescriptors;
+ fmt-fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV;
+ } else if (format-bDescriptorSubType == UVC_VS_FORMAT_MJPEG) {
+ struct uvc_format_mjpeg *mjpeg =
+ (struct uvc_format_mjpeg *)format;
+ nframes = mjpeg-bNumFrameDescriptors;
+ fmt-fmt.pix.pixelformat = V4L2_PIX_FMT_MJPEG;
+ }
+ pformat++;
+ } while (pformat ctrl-bFormatIndex);
+
+ ctrl-bFrameIndex = clamp((unsigned int)ctrl-bFrameIndex, 1U, nframes);
+
+ /* frame header */
+ uvc_streaming_cls += ctrl-bFrameIndex;
+ frame = *uvc_streaming_cls;
+ if (format-bDescriptorSubType == UVC_VS_FORMAT_UNCOMPRESSED) {
+ struct uvc_frame_uncompressed *yuyv =
+ (struct uvc_frame_uncompressed *)frame;
+ fmt-fmt.pix.width = yuyv-wWidth;
+ fmt-fmt.pix.height = yuyv-wHeight;
+ fmt-fmt.pix.sizeimage = fmt-fmt.pix.width *
fmt-fmt.pix.height *
2;
+ fmt-fmt.pix.priv = yuyv-dwDefaultFrameInterval;
+ if (ctrl-dwFrameInterval) {
+ absdiff = ctrl-dwFrameInterval -
yuyv-dwFrameInterval[0];
+ for (count = 1; count yuyv-bFrameIntervalType;
count++) {
+ unsigned int tmpdiff = ctrl-dwFrameInterval -
yuyv-dwFrameInterval[count];
+ if (tmpdiff absdiff) {
+ absdiff = tmpdiff;
+ fmt-fmt.pix.priv =
yuyv-dwFrameInterval[count];
+ }
+ }
+ }
+ } else if (format-bDescriptorSubType == UVC_VS_FORMAT_MJPEG) {
+ struct uvc_frame_mjpeg *mjpeg =
+
Re: [PATCH v3 9/9] ARM: dts: add usb udc support to bcm281xx
On Wed, Nov 27, 2013 at 02:27:19PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Monday 25 November 2013 11:46 PM, Matt Porter wrote:
Adds USB OTG/PHY and clock support to BCM281xx and enables
UDC support on the bcm11351-brt and bcm28155-ap boards.
Signed-off-by: Matt Porter matt.por...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
Reviewed-by: Tim Kryger tim.kry...@linaro.org
---
arch/arm/boot/dts/bcm11351-brt.dts | 6 ++
arch/arm/boot/dts/bcm11351.dtsi| 18 ++
arch/arm/boot/dts/bcm28155-ap.dts | 8
3 files changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/bcm11351-brt.dts
b/arch/arm/boot/dts/bcm11351-brt.dts
index 23cd16d..396b704 100644
--- a/arch/arm/boot/dts/bcm11351-brt.dts
+++ b/arch/arm/boot/dts/bcm11351-brt.dts
@@ -44,5 +44,11 @@
status = okay;
};
+ usbotg: usb@3f12 {
+ status = okay;
+ };
using usbotg could have been better. I mean if you have something like
usbotg, you realise that the node has been created somewhere and we are just
referencing it here to add more properties.
That's normally my preference, but Christian owns this file and doesn't
like that syntax. Instead, I'm conforming with the rest of the .dts
entries. He and I discussed moving to label references a while back and
that's a no go.
Thanks,
Matt
--
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: BUG: usb: obex in g_nokia.ko causing kernel panic
Hi, On Wed, Nov 27, 2013 at 05:40:42PM +0100, Pali Rohár wrote: @@ -282,10 +284,12 @@ static void obex_disconnect(struct gserial *g) if (!obex-can_activate) return; +#if 0 status = usb_function_deactivate(g-func); if (status) DBG(cdev, obex ttyGS%d function deactivate -- %d\n, obex-port_num, status); +#endif } /*- -- --*/ @@ -372,6 +376,7 @@ static int obex_bind(struct usb_configuration *c, struct usb_function *f) if (status) goto fail; +#if 0 /* Avoid letting this gadget enumerate until the userspace * OBEX server is active. */ @@ -381,6 +386,7 @@ static int obex_bind(struct usb_configuration *c, struct usb_function *f) obex-port_num, status); else obex-can_activate = true; +#endif DBG(cdev, obex ttyGS%d: %s speed IN/%s OUT/%s\n, Hi, with above patch g_nokia.ko working and not crashing. yeah, makes sense. We shouldn't call phy operations in atomic context. I'll see how easy it would be to fix that. Real patch coming soon(-ish). I think we could send diff below for the -rc cycle and figure out a better to handle this for the merge window. Can you check if it also works with patch below ? diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 2a408cd..8aa59a2 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -659,7 +659,6 @@ static int omap2430_runtime_suspend(struct device *dev) OTG_INTERFSEL); omap2430_low_level_exit(musb); - phy_power_off(musb-phy); } return 0; @@ -674,7 +673,6 @@ static int omap2430_runtime_resume(struct device *dev) omap2430_low_level_init(musb); musb_writel(musb-mregs, OTG_INTERFSEL, musb-context.otg_interfsel); - phy_power_on(musb-phy); } return 0; Hi, I applied similar patch (commented usb_phy_set_suspend instead phy_power_on/off) on 3.12-rc5 and it working too, no crash. I do not have rebased n900 patches on top of 3.13 tree, so I cannot check it. But I think phy_power_on/off doing same as usb_phy_set_suspend in 3.12. cool, I'll send this during the -rc and Cc stable, then I'll manually backport it to stable later. -- balbi signature.asc Description: Digital signature
Re: [REWORKED PATCH 1/5] usb: phy: fsm: don't depend on indirect includes
On Wed, Nov 27, 2013 at 11:14:56AM +0900, Anton Tikhomirov wrote: Hi Felipe, Hi, On Tue, Nov 26, 2013 at 10:33:44AM -0600, Felipe Balbi wrote: this header uses spinlocks and errno values, so we must include linux/spinlock.h and linux/errno.h to avoid build errors. Signed-off-by: Felipe Balbi ba...@ti.com Anton, I had to rework your patch series quite a bit in order to make Thank you. it acceptable. It seems unlikely that you compile-tested your series, considering we would very clearly see build errors after moving the header around. Your driver depends (or depended?) too much on indirect header inclusions. Currently only Freescale OTG Transceiver Driver uses OTG FSM. After applying patches it was compiled without errors. usually allmodconfig, allyesconfig, allnoconfig with different architectures uncovers a bunch of errors. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: s3c-hsotg: change dependency to PLAT_SAMSUNG
On Wed, Nov 27, 2013 at 02:03:22PM +0100, Marek Szyprowski wrote:
On device tree based Samsung SoC platforms (like Exynos) no platform
devices are defined and CONFIG_S3C_DEV_USB_HSOTG is no longer available,
so change the driver dependency to more generic and appropriate
CONFIG_PLAT_SAMSUNG, as the driver can be used on almost all Samsung
platforms.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index a91e642..83983ee 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -295,7 +295,7 @@ config USB_PXA27X
config USB_S3C_HSOTG
tristate S3C HS/OtG USB Device controller
- depends on S3C_DEV_USB_HSOTG
+ depends on PLAT_SAMSUNG
I would rather change this to depends on ARM || COMPILE_TEST, this would
force people to make sure that driver can be used on single zImage
kernels.
All you need is the diff below:
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index 9875d9c..db797f2 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -36,8 +36,6 @@
#include linux/usb/phy.h
#include linux/platform_data/s3c-hsotg.h
-#include mach/map.h
-
#include s3c-hsotg.h
static const char * const s3c_hsotg_supply_names[] = {
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 4/4] usb/gadget: f_sourcesink: add configfs support
Hi, On Wed, Nov 27, 2013 at 08:38:25AM +0100, Andrzej Pietrasiewicz wrote: W dniu 26.11.2013 20:51, Felipe Balbi pisze: On Thu, Nov 07, 2013 at 08:41:28AM +0100, Andrzej Pietrasiewicz wrote: Add support for using the sourcesink function in gadgets composed with configfs. Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com fuzz on Kconfig, please check [1] [1] http://bit.ly/18mbMMQ [1] http://bit.ly/18mbMMQ [1] http://bit.ly/1aRYYMC both look good to me. The fuzz most probably results from the fact that the gadget zero configfs support series has been originally applied by me onto the FunctionFS configfs support series. You can find the result here: http://git.linaro.org/gitweb?p=people/mszyprowski/linux-srpol.git;a=shortlog;h=refs/heads/usb-gadget-configfs AP PS. Have you got any considerations about the above mentioned FunctionFS series? yeah, it's in my review queue for today :-) -- balbi signature.asc Description: Digital signature
Re: [RESEND GIT PULL v2] USB fixes for v3.13-rc2
On Mon, Nov 25, 2013 at 01:36:51PM -0600, Felipe Balbi wrote: Hi Greg, Here's my first set of fixes for this -rc cycle. Please consider merging them on your usb-linus branch. Let me know if you need any changes to this pull request. I did a test merge of this tag with your usb-linus branch and it merges just fine. cheers ps: now with proper tag :-) sorry about that The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v3.13-rc2 That worked, now pulled and pushed out, 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
Re: [PATCH 1/3] usb: dwc3: Add Keystone specific glue layer
On Wednesday 27 November 2013 12:41 PM, Felipe Balbi wrote:
Hi,
On Wed, Nov 27, 2013 at 02:49:54PM +0530, George Cherian wrote:
+ error = of_platform_populate(node, NULL, NULL, dev);
+ if (error) {
+ dev_err(pdev-dev, failed to create dwc3 core\n);
+ goto err_core;
+ }
+
+ return 0;
+
+err_core:
+ kdwc3_disable_irqs(kdwc);
+err_irq:
+ kdwc3_disable(kdwc);
+
+ return error;
+}
+
+static int kdwc3_remove(struct platform_device *pdev)
+{
+ struct dwc3_keystone *kdwc = platform_get_drvdata(pdev);
+
+ if (kdwc) {
+ kdwc3_disable_irqs(kdwc);
+ kdwc3_disable(kdwc);
+ platform_set_drvdata(pdev, NULL);
+ }
+ return 0;
+}
+
You need to unregister the child nodes in remove.
Also why can't the dwc3-omap driver be reused, Felipe??
I believe the TI wrapper for Keystone is similar to that of AM437x or
OMAP5.
it is very similar indeed, if it can be easily re-use that glue, I'd
rather not add another.
Initial idea was actually to use same driver but the integration IP
is quite different on Keystone vs OMAP which lead to have a separate
glue layer. They look similar but there are differences in terms of phys,
interrupts, register space. And also non OTG support, runtime PM
vs clock etc for now.
After all the glue is really a very small code describes the integration
details thanks to nice abstracted dwc3 core layer. So as discussed
over irc, keeping the separate glue is preferred but do let us know
if you think otherwise.
Regards,
Santosh
--
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: possible xhci regression: usb 3.0 hdd disconnects immediately
On 11/25/2013 03:37 PM, b3nmore wrote: Hi, I can't get my external usb 3.0 hdd to work on usb 3.0 ports with kernels 3.11, 3.12.0, 3.13-rc1, it only works on usb 2 ports. dmesg shows, that it disconnects immediately after it is plugged in. Then it continues to connect and disconnect indefinitely: Never mind, I just found out, that the bios of my mainboard was messing things up. Sorry for the noise. -- 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 1/3] usb: dwc3: Add Keystone specific glue layer
On Wed, Nov 27, 2013 at 01:32:04PM -0500, Santosh Shilimkar wrote:
On Wednesday 27 November 2013 12:41 PM, Felipe Balbi wrote:
Hi,
On Wed, Nov 27, 2013 at 02:49:54PM +0530, George Cherian wrote:
+ error = of_platform_populate(node, NULL, NULL, dev);
+ if (error) {
+ dev_err(pdev-dev, failed to create dwc3 core\n);
+ goto err_core;
+ }
+
+ return 0;
+
+err_core:
+ kdwc3_disable_irqs(kdwc);
+err_irq:
+ kdwc3_disable(kdwc);
+
+ return error;
+}
+
+static int kdwc3_remove(struct platform_device *pdev)
+{
+ struct dwc3_keystone *kdwc = platform_get_drvdata(pdev);
+
+ if (kdwc) {
+ kdwc3_disable_irqs(kdwc);
+ kdwc3_disable(kdwc);
+ platform_set_drvdata(pdev, NULL);
+ }
+ return 0;
+}
+
You need to unregister the child nodes in remove.
Also why can't the dwc3-omap driver be reused, Felipe??
I believe the TI wrapper for Keystone is similar to that of AM437x or
OMAP5.
it is very similar indeed, if it can be easily re-use that glue, I'd
rather not add another.
Initial idea was actually to use same driver but the integration IP
is quite different on Keystone vs OMAP which lead to have a separate
glue layer. They look similar but there are differences in terms of phys,
interrupts, register space. And also non OTG support, runtime PM
vs clock etc for now.
All of those can be easily taken care of:
a) PHY - different phy driver
b) non-OTG - there's a register on dwc3 which we can use
c) runtime vs clock - we can add optional clock support on dwc3-omap.c
what *really* prevents us from using the same, is register layout and
the fact that on OMAP, nobody wants drivers accessing SYS* registers (a
mistake IMO). That would be a lot more difficult to make generic.
BTW, OMAP isn't OTG either, it doesn't support the OTG specification
even though it can act in both roles. Same applies for keystone, if I'm
reading my docs correctly.
After all the glue is really a very small code describes the integration
details thanks to nice abstracted dwc3 core layer. So as discussed
over irc, keeping the separate glue is preferred but do let us know
if you think otherwise.
yeah, let's keep it separate. Keystone is, in general, an entire new SoC
architecture anyway.
--
balbi
signature.asc
Description: Digital signature
Re: huawei E5776 (hilink) 3.12--3.13 not working anymore
Am 27.11.2013 13:33, schrieb Bjørn Mork: How about looking at usbmon differences? That should show us where things start to go wrong. Here are the two cases 3.12 with a short connection dhcp and ping 3.13 with failing dhcp I hope I caught the right bus. Because of the size of files (1MB) I send the traces only as link, not as attachment. http://www.cis.uni-muenchen.de/~thomas/e5776-usb-capture-3.12.good-case.pcapng http://www.cis.uni-muenchen.de/~thomas/e5776-usb-capture-3.13.bad-case.pcapng Thomas -- 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 2/3] ARM: dts: keystone: Add usb devicetree bindings
On Wednesday 27 November 2013 04:59 AM, George Cherian wrote:
On 11/26/2013 1:46 AM, WingMan Kwok wrote:
Added device tree support for TI's Keystone USB driver and updated the
Documentation with device tree binding information.
On Keystone II platforms, we use no-op phy driver.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: WingMan Kwok w-kw...@ti.com
---
.../devicetree/bindings/usb/keystone-usb.txt | 43
arch/arm/boot/dts/keystone.dtsi| 27
2 files changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/keystone-usb.txt
[...]
diff --git a/arch/arm/boot/dts/keystone.dtsi
b/arch/arm/boot/dts/keystone.dtsi
index f6d6d9e..1e1049c 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -181,5 +181,32 @@
interrupts = GIC_SPI 300 IRQ_TYPE_EDGE_RISING;
clocks = clkspi;
};
+
+usb2_phy: usb2_phy {
+compatible = usb-nop-xceiv;
+};
+
+usb3_phy: usb3_phy {
+compatible = usb-nop-xceiv;
+};
+
+usb: usb@268 {
+compatible = ti,keystone-dwc3;
+#address-cells = 1;
+#size-cells = 1;
+reg = 0x268 0x1
+ 0x2620738 32;
+clocks = clkusb;
+clock-names = usb;
+interrupts = GIC_SPI 393 IRQ_TYPE_EDGE_RISING;
You don't have seperate interrrupt for wrapper and core?
Is it the same interrupt shared between XHCI,DWC3 and wrapper?
You don't need actually two seperate interrupts.
DWC3 core actually registers IRQ for XHCI. And in OMAP case, there
is one more IRQ in wrapper. After checking with Felipe, it seems
the OMAP wrapper interrupt was more for debug purpose than any real
use.
On Keystone only one IRQ is used and the handling is managed
through IRQF_SHARED and that is also mainly because the IRQ
ack needs special write to EOI register unlike OMAP.
Regards,
Santosh
--
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
Advice on usb-next pull
Hi Greg, I've got a potential pull request to send you for usb-next, but I wanted to get your advice on it first. It contains a series of patches from Xenia to remove the xhci_readl/writel variants in order to just replace them with standard readl and writel calls. Normally I would queue these for usb-next. However, any bug fix patch that will be queued for usb-linus that touches code around xHCI register reads or writes is going to cause merge conflicts in usb-next. The register manipulation is scattered all through the driver, so it's pretty likely we will get a merge conflict sometime in 3.13. How do you want me to handle any merge conflicts, or will you handle them? The two pull requests I'm considering sending you are: https://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/log/?h=for-usb-linus-queue https://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/log/?h=for-usb-next-queue I've been testing the for-usb-next-queue branch on top of 3.12-rc6 for the last week, and the patches are stable. Sarah Sharp -- 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 v5 06/17] clk: at91: add PMC pll clocks
Quoting Boris BREZILLON (2013-11-12 13:57:19)
+static const struct clk_ops pll_ops = {
+ .prepare = clk_pll_prepare,
+ .is_prepared = clk_pll_is_ready,
+ .disable = clk_pll_disable,
+ .is_enabled = clk_pll_is_ready,
+ .recalc_rate = clk_pll_recalc_rate,
+ .round_rate = clk_pll_round_rate,
+ .set_rate = clk_pll_set_rate,
+};
Hi Boris,
It is a bit strange to see only a .prepare and .disable callback
populated. What happens if a driver calls clk_disable and then
clk_enable? You clock will still be disabled in hardware.
Regards,
Mike
--
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: Advice on usb-next pull
On Wed, Nov 27, 2013 at 01:42:40PM -0800, Sarah Sharp wrote: Hi Greg, I've got a potential pull request to send you for usb-next, but I wanted to get your advice on it first. It contains a series of patches from Xenia to remove the xhci_readl/writel variants in order to just replace them with standard readl and writel calls. Normally I would queue these for usb-next. However, any bug fix patch that will be queued for usb-linus that touches code around xHCI register reads or writes is going to cause merge conflicts in usb-next. And what's the odds of that really happening? The register manipulation is scattered all through the driver, so it's pretty likely we will get a merge conflict sometime in 3.13. How do you want me to handle any merge conflicts, or will you handle them? I can handle them. If they are too tough, I'll ask for help :) 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
Re: Advice on usb-next pull
On Wed, Nov 27, 2013 at 01:51:05PM -0800, Greg KH wrote: On Wed, Nov 27, 2013 at 01:42:40PM -0800, Sarah Sharp wrote: Hi Greg, I've got a potential pull request to send you for usb-next, but I wanted to get your advice on it first. It contains a series of patches from Xenia to remove the xhci_readl/writel variants in order to just replace them with standard readl and writel calls. Normally I would queue these for usb-next. However, any bug fix patch that will be queued for usb-linus that touches code around xHCI register reads or writes is going to cause merge conflicts in usb-next. And what's the odds of that really happening? The register manipulation is scattered all through the driver, so it's pretty likely we will get a merge conflict sometime in 3.13. How do you want me to handle any merge conflicts, or will you handle them? I can handle them. If they are too tough, I'll ask for help :) Ok, thanks! Sarah Sharp -- 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: 3.12.1 Virt dev invalid for slot_id 0x1 from drivers/usb/host/xhci.c
On Mon, Nov 25, 2013 at 11:41:47AM -0700, Shuah Khan wrote:
I started seeing the following on my Samsung Series on 3.12.1
Is this bad? Looks like the following WARN_ON is firing:
drivers/usb/host/xhci.c:
if (WARN_ON(!virt_dev)) {
/*
* In plug/unplug torture test with an NEC controller,
* a zero-dereference was observed once due to
virt_dev = 0.
* Print useful debug rather than crash if it is
observed again!
*/
xhci_warn(xhci, Virt dev invalid for slot_id 0x%x!\n,
udev-slot_id);
return -EINVAL;
}
As the comment says, the WARN_ON was there so we can track down why this
specific NULL pointer dereference bug could have been hit.
What are the specific steps to reproduce this? It looks like it's
coming from a device resume path. Did you have auto-suspend enabled for
your USB devices, or did this warning occur right after an S3 resume?
Can you enable CONFIG_USB_DEBUG and CONFIG_DYNAMIC_DEBUG, and send me
dmesg starting from just before you trigger the WARN_ON()? I need to
see what the xHCI driver state that causes this might be.
Sarah Sharp
[ 565.276187] [ cut here ]
[ 565.276198] WARNING: CPU: 2 PID: 2228 at
drivers/usb/host/xhci.c:3748 xhci_address_device+0x57b/0x630()
[ 565.276262] Modules linked in: parport_pc ppdev arc4 iwldvm
rfcomm bnep mac80211 i915 ext2 joydev x86_pkg_temp_thermal coretemp
kvm_intel kvm iwlwifi uvcvideo videobuf2_vmalloc cfg80211
videobuf2_memops snd_hda_codec_hdmi videobuf2_core videodev
drm_kms_helper snd_hda_codec_realtek ghash_clmulni_intel aesni_intel
drm snd_hda_intel aes_x86_64 btusb media ablk_helper snd_hda_codec
cryptd bluetooth lrw gf128mul glue_helper hid_generic samsung_laptop
usbhid tpm_infineon hid snd_hwdep snd_pcm psmouse snd_page_alloc
snd_timer microcode i2c_algo_bit lpc_ich serio_raw lp parport video
wmi tpm_tis mac_hid r8169 mii
[ 565.276267] CPU: 2 PID: 2228 Comm: kworker/u16:39 Not tainted 3.12.1+ #11
[ 565.276269] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
900X3C/900X3D/900X4C/900X4D/SAMSUNG_NP1234567890, BIOS P03AAC
07/12/2012
[ 565.276278] Workqueue: events_unbound async_run_entry_fn
[ 565.276285] 0009 88002fb0fb00 816bf0c1
[ 565.276289] 88002fb0fb38 8104d5fd 88040cc7e000
[ 565.276293] 8803f0195800 0002
88002fb0fb48
[ 565.276294] Call Trace:
[ 565.276307] [816bf0c1] dump_stack+0x45/0x56
[ 565.276314] [8104d5fd] warn_slowpath_common+0x7d/0xa0
[ 565.276318] [8104d6da] warn_slowpath_null+0x1a/0x20
[ 565.276324] [8150a43b] xhci_address_device+0x57b/0x630
[ 565.276330] [814d49d4] hub_port_init+0x1f4/0xa40
[ 565.276335] [814d5336] usb_reset_and_verify_device+0x116/0x730
[ 565.276340] [814d2ced] ? hub_port_status+0xdd/0x120
[ 565.276345] [814d7bd0] usb_port_resume+0x2f0/0x5c0
[ 565.276352] [814eb535] generic_resume+0x15/0x30
[ 565.276358] [814e26e7] usb_resume_both+0x107/0x150
[ 565.276366] [814d1e30] ? usb_for_each_dev+0x30/0x30
[ 565.276372] [814e325f] usb_resume+0x1f/0xd0
[ 565.276377] [814d1e30] ? usb_for_each_dev+0x30/0x30
[ 565.276383] [814d1e43] usb_dev_restore+0x13/0x20
[ 565.276392] [8143c179] dpm_run_callback+0x49/0xa0
[ 565.276398] [8143c2d6] device_resume+0xc6/0x1f0
[ 565.276404] [8143c41d] async_resume+0x1d/0x50
[ 565.276409] [810766c7] async_run_entry_fn+0x37/0x130
[ 565.276418] [81068357] process_one_work+0x177/0x410
[ 565.276424] [81068f91] worker_thread+0x121/0x3a0
[ 565.276431] [81068e70] ? manage_workers.isra.25+0x2b0/0x2b0
[ 565.276436] [8106f730] kthread+0xc0/0xd0
[ 565.276442] [8106f670] ? kthread_create_on_node+0x120/0x120
[ 565.276448] [816ced2c] ret_from_fork+0x7c/0xb0
[ 565.276453] [8106f670] ? kthread_create_on_node+0x120/0x120
[ 565.276456] ---[ end trace 115d14352276d432 ]---
[ 565.276460] xhci_hcd :03:00.0: Virt dev invalid for slot_id 0x1!
[ 565.478224] [ cut here ]
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
--
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
VIA chipset not supported by xhci drivers?
I wasn’t able to get the 7-port Orico controller working, so I swapped it out for a 4-port (single chip) Anker instead. $ sudo lspci -v -s 03:00.0 03:00.0 USB controller: VIA Technologies, Inc. VL80x xHCI USB 3.0 Controller (rev 03) (prog-if 30 [XHCI]) Subsystem: VIA Technologies, Inc. VL80x xHCI USB 3.0 Controller Flags: bus master, fast devsel, latency 0, IRQ 43 Memory at fbdff000 (32-bit, non-prefetchable) [size=4K] Capabilities: [80] Power Management version 3 Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [c4] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Kernel driver in use: xhci_hcd $ and from “lsusb -v”: Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 3 bMaxPacketSize0 9 idVendor 0x1d6b Linux Foundation idProduct 0x0003 3.0 root hub bcdDevice3.11 iManufacturer 3 Linux 3.11.7-100.fc18.x86_64 xhci_hcd iProduct2 xHCI Host Controller iSerial 1 :03:00.0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 31 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 bMaxBurst 0 Hub Descriptor: bLength 12 bDescriptorType 42 nNbrPorts 4 wHubCharacteristic 0x0009 Per-port power switching Per-port overcurrent protection bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere bHubDecLat 0.0 micro seconds wHubDelay 0 nano seconds DeviceRemovable0x00 Hub Port Status: Port 1: .02a0 5Gbps power Rx.Detect Port 2: .02a0 5Gbps power Rx.Detect Port 3: .02a0 5Gbps power Rx.Detect Port 4: .02a0 5Gbps power Rx.Detect Binary Object Store Descriptor: bLength 5 bDescriptorType15 wTotalLength 15 bNumDeviceCaps 1 SuperSpeed USB Device Capability: bLength10 bDescriptorType16 bDevCapabilityType 3 bmAttributes 0x02 Latency Tolerance Messages (LTM) Supported wSpeedsSupported 0x0008 Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 3 Lowest fully-functional device speed is SuperSpeed (5Gbps) bU1DevExitLat 4 micro seconds bU2DevExitLat 231 micro seconds Device Status: 0x0001 Self Powered This time when I tried to plug in a Western Digital Passport drive, I got: Nov 26 15:07:27 builder kernel: [864975.137714] usb 9-1: Device not responding to set address. Nov 26 15:07:27 builder kernel: [864975.338699] usb 9-1: Device not responding to set address. Nov 26 15:07:28 builder kernel: [864975.539506] usb 9-1: device not accepting address 43, error -71 Nov 26 15:07:28 builder kernel: [864976.293815] usb 9-1: Device not responding to set address. Nov 26 15:07:29 builder kernel: [864976.494778] usb 9-1: Device not responding to set address. Nov 26 15:07:29 builder kernel: [864976.695594] usb 9-1: device not accepting address 45, error -71 ... Nov 26 15:09:07 builder kernel: [865074.813213] usb 9-1: Device not responding to set address. Nov 26 15:09:07 builder kernel: [865075.014135] usb 9-1: Device not responding to set address. Nov 26 15:09:07 builder kernel: [865075.214942] usb 9-1: device not accepting address 89, error -71 Nov 26 15:09:08 builder kernel: [865075.969269] usb 9-1: Device not responding to set address. Nov 26 15:09:08 builder kernel: [865076.170220] usb 9-1: Device not responding to set address. Nov 26 15:09:09 builder kernel: [865076.371024] usb 9-1: device not accepting address 91, error -71 I was looking at my kernel sources (3.11.7-100.fc18.x86_64) and I noticed that the usb subtree doesn’t explicitly mention
Re: [PATCH v5 08/17] clk: at91: add PMC system clocks
Quoting Boris BREZILLON (2013-11-12 14:05:35) This patch adds new at91 system clock implementation using common clk framework. Some peripherals need to enable a system clock in order to work properly. Each system clock is given an id based on the bit position in SCER/SCDR registers. Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com --- drivers/clk/at91/Makefile |1 + drivers/clk/at91/clk-system.c | 137 + drivers/clk/at91/pmc.c|5 ++ drivers/clk/at91/pmc.h|3 + 4 files changed, 146 insertions(+) create mode 100644 drivers/clk/at91/clk-system.c diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile index e28fb2b..c2b7068 100644 --- a/drivers/clk/at91/Makefile +++ b/drivers/clk/at91/Makefile @@ -4,3 +4,4 @@ obj-y += pmc.o obj-y += clk-main.o clk-pll.o clk-plldiv.o clk-master.o +obj-y += clk-system.o diff --git a/drivers/clk/at91/clk-system.c b/drivers/clk/at91/clk-system.c new file mode 100644 index 000..1c086f4 --- /dev/null +++ b/drivers/clk/at91/clk-system.c @@ -0,0 +1,137 @@ +/* + * drivers/clk/at91/clk-system.c Nitpick: it's better to not put file paths in a comment block in case the file name or path is changed. Regards, Mike -- 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 v3 5/9] usb: gadget: s3c-hsotg: use generic phy_init()/phy_exit() support
On Wed, Nov 27, 2013 at 12:13:25PM -0500, Matt Porter wrote: On Tue, Nov 26, 2013 at 03:53:32PM +0530, Kishon Vijay Abraham I wrote: Hi, On Monday 25 November 2013 11:46 PM, Matt Porter wrote: If a generic phy is present, call phy_init()/phy_exit(). This supports generic phys that must be soft reset before power on. Signed-off-by: Matt Porter matt.por...@linaro.org --- drivers/usb/gadget/s3c-hsotg.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c index da3879b..8dfe33f 100644 --- a/drivers/usb/gadget/s3c-hsotg.c +++ b/drivers/usb/gadget/s3c-hsotg.c @@ -3622,6 +3622,9 @@ static int s3c_hsotg_probe(struct platform_device *pdev) goto err_supplies; } + if (hsotg-phy) IS_ERR? If your phy_get fails *phy* will have a error value.. Yes, thanks. I'll fix these and also note that the same issue exists in Kamil's patch for these same hsotg-phy conditional uses. I'll work with Kamil to either get those addressed there or in a follow on fix. I spoke too soon. If devm_phy_get fails, we don't set hsotg-phy and probe defer thus not reaching this point. Since hsotg-phy is either NULL or a valid struct phy *, this is correct as is throughout the driver. + phy_init(hsotg-phy); + /* usb phy enable */ s3c_hsotg_phy_enable(hsotg); @@ -3715,6 +3718,8 @@ static int s3c_hsotg_remove(struct platform_device *pdev) } s3c_hsotg_phy_disable(hsotg); + if (hsotg-phy) same here. Ok. Same above, this will be NULL on failure (but is only applicable at this point on the platform data path. -Matt -- 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 4/5] xhci: fix sparse warning in xhci-trace.h
From: Xenia Ragiadakou burzalod...@gmail.com This patch fixes the following sparse warnings: drivers/usb/host/./xhci-trace.h:116:1: warning: cast to restricted __le32 drivers/usb/host/./xhci-trace.h:116:1: warning: cast to restricted __le32 drivers/usb/host/./xhci-trace.h:116:1: warning: restricted __le32 degrades to integer drivers/usb/host/./xhci-trace.h:116:1: warning: restricted __le32 degrades to integer by converting the field 'trb' of the trace buffer entry structure from array with elements of type __le32 to an array with elements of type u8. Into the trb array are copied the contents of the TRB that generated the event. The trace-cmd tool with the help of plugin_xhci.py will use this field to parse the TRB contents in a human readable way. This patch should be backported to kernels as old as 3.12, that contain the commit 63a23b9a7451660525c90b08219e14e701e294f1 xhci: add xhci_cmd_completion trace event Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com Cc: sta...@vger.kernel.org --- drivers/usb/host/xhci-trace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h index afe093340834..dde3959b7a33 100644 --- a/drivers/usb/host/xhci-trace.h +++ b/drivers/usb/host/xhci-trace.h @@ -116,7 +116,7 @@ DECLARE_EVENT_CLASS(xhci_log_event, __field(u64, dma) __field(u32, status) __field(u32, flags) - __dynamic_array(__le32, trb, 4) + __dynamic_array(u8, trb, sizeof(struct xhci_generic_trb)) ), TP_fast_assign( __entry-va = trb_va; -- 1.8.3.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
[PATCH 1/5] xhci: convert TRB_CYCLE to le32 before using it to set Link TRB's cycle bit
From: Xenia Ragiadakou burzalod...@gmail.com
This patch converts TRB_CYCLE to le32 to update correctly the Cycle Bit in
'control' field of the link TRB.
This bug was found using sparse.
This patch should be backported to kernels as old as 3.4, that contain
the commit 186a7ef13a8fa3bc7cca1ccd33bd469b931e46de xHCI: set cycle
state when allocate rings
Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-mem.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 49b8bd063fab..90709cf45ee5 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -57,7 +57,7 @@ static struct xhci_segment *xhci_segment_alloc(struct
xhci_hcd *xhci,
/* If the cycle state is 0, set the cycle bit to 1 for all the TRBs */
if (cycle_state == 0) {
for (i = 0; i TRBS_PER_SEGMENT; i++)
- seg-trbs[i].link.control |= TRB_CYCLE;
+ seg-trbs[i].link.control |= cpu_to_le32(TRB_CYCLE);
}
seg-dma = dma;
seg-next = NULL;
@@ -308,7 +308,8 @@ static void xhci_reinit_cached_ring(struct xhci_hcd *xhci,
sizeof(union xhci_trb)*TRBS_PER_SEGMENT);
if (cycle_state == 0) {
for (i = 0; i TRBS_PER_SEGMENT; i++)
- seg-trbs[i].link.control |= TRB_CYCLE;
+ seg-trbs[i].link.control |=
+ cpu_to_le32(TRB_CYCLE);
}
/* All endpoint rings have link TRBs */
xhci_link_segments(xhci, seg, seg-next, type);
--
1.8.3.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
[PATCH 5/5] xhci: fix incorrect type in assignment in xhci_address_device()
From: Xenia Ragiadakou burzalod...@gmail.com The field 'dev_info' in struct xhci_slot_ctx has type __le32 and it needs to be converted to CPU byteorder for the correct retrieval of its subfield 'Context Entries'. This field is used by the trace event 'xhci_address_ctx' to trace only the contexts of valid endpoints. This bug was found using sparse. This patch should be backported to kernels as old as 3.12, that contain the commit 1d27fabec068a204186c6af10e05f23911c0c902 xhci: add xhci_address_ctx trace event Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com Cc: sta...@vger.kernel.org --- drivers/usb/host/xhci.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 4265b48856f6..a96b35cf4fa7 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -3771,7 +3771,7 @@ int xhci_address_device(struct usb_hcd *hcd, struct usb_device *udev) xhci_dbg(xhci, Slot ID %d Input Context:\n, udev-slot_id); xhci_dbg_ctx(xhci, virt_dev-in_ctx, 2); trace_xhci_address_ctx(xhci, virt_dev-in_ctx, - slot_ctx-dev_info 27); + le32_to_cpu(slot_ctx-dev_info) 27); spin_lock_irqsave(xhci-lock, flags); cmd_trb = xhci_find_next_enqueue(xhci-cmd_ring); @@ -3850,7 +3850,7 @@ int xhci_address_device(struct usb_hcd *hcd, struct usb_device *udev) xhci_dbg(xhci, Slot ID %d Input Context:\n, udev-slot_id); xhci_dbg_ctx(xhci, virt_dev-in_ctx, 2); trace_xhci_address_ctx(xhci, virt_dev-in_ctx, - slot_ctx-dev_info 27); + le32_to_cpu(slot_ctx-dev_info) 27); xhci_dbg(xhci, Slot ID %d Output Context:\n, udev-slot_id); xhci_dbg_ctx(xhci, virt_dev-out_ctx, 2); /* @@ -3859,7 +3859,7 @@ int xhci_address_device(struct usb_hcd *hcd, struct usb_device *udev) */ slot_ctx = xhci_get_slot_ctx(xhci, virt_dev-out_ctx); trace_xhci_address_ctx(xhci, virt_dev-out_ctx, - slot_ctx-dev_info 27); + le32_to_cpu(slot_ctx-dev_info) 27); /* Zero the input context control for later use */ ctrl_ctx-add_flags = 0; ctrl_ctx-drop_flags = 0; -- 1.8.3.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
[PATCH 3/5] xhci: fix derivation of TRB's DMA address in xhci_log_event Trace Event Class
From: Xenia Ragiadakou burzalod...@gmail.com This patch fixes the retrieval of the DMA address of the TRB that generated the event by converting the field[0] (low address bits) and field[1] (high address bits) to CPU byteorder and then typecasting field[1] to u64 so that the bitshift will not lead to overflow. In the original code, the typecasting of le32 to u64 was incorrect and the subsequent conversion to le64 reverts the low and high address parts. This bug was found using sparse. This patch should be backported to kernels as old as 3.12, that contain the commit 63a23b9a7451660525c90b08219e14e701e294f1 xhci: add xhci_cmd_completion trace event Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com Cc: sta...@vger.kernel.org --- drivers/usb/host/xhci-trace.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h index 20364cc8d2fb..afe093340834 100644 --- a/drivers/usb/host/xhci-trace.h +++ b/drivers/usb/host/xhci-trace.h @@ -120,8 +120,8 @@ DECLARE_EVENT_CLASS(xhci_log_event, ), TP_fast_assign( __entry-va = trb_va; - __entry-dma = le64_to_cpu(((u64)ev-field[1]) 32 | - ev-field[0]); + __entry-dma = ((u64)le32_to_cpu(ev-field[1])) 32 | + le32_to_cpu(ev-field[0]); __entry-status = le32_to_cpu(ev-field[2]); __entry-flags = le32_to_cpu(ev-field[3]); memcpy(__get_dynamic_array(trb), trb_va, -- 1.8.3.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
[PATCH 2/5] xhci: fix incorrect type in assignment in handle_device_notification()
From: Xenia Ragiadakou burzalod...@gmail.com
This patch converts Event TRB's 3rd field, which has type le32, to CPU
byteorder before using it to retrieve the Slot ID with TRB_TO_SLOT_ID macro.
This bug was found using sparse.
This patch should be backported to kernels as old as 3.4, that contain
the commit 623bef9e03a60adc623b09673297ca7a1cdfb367 USB/xhci: Enable
remote wakeup for USB3 devices.
Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 1e2f3f495843..22da09388a74 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1655,7 +1655,7 @@ static void handle_device_notification(struct xhci_hcd
*xhci,
u32 slot_id;
struct usb_device *udev;
- slot_id = TRB_TO_SLOT_ID(event-generic.field[3]);
+ slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event-generic.field[3]));
if (!xhci-devs[slot_id]) {
xhci_warn(xhci, Device Notification event for
unused slot %u\n, slot_id);
--
1.8.3.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
[PATCH 01/10] xhci: replace USB_MAXINTERFACES with config-desc.bNumInterface
From: Xenia Ragiadakou burzalod...@gmail.com
This patch replaces USB_MAXINTERFACES with config-desc.bNumInterface in
the termination condition for the loop that updates the LPM timeout of the
endpoints on the cofiguration's interfaces, in xhci_calculate_lpm_timeout(),
to avoid unnecessary loop cycles since most configurations come with 1-2
interfaces while USB_MAXINTERFACES is 32.
Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index a96b35cf4fa7..1798c5353102 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4455,7 +4455,7 @@ static u16 xhci_calculate_lpm_timeout(struct usb_hcd *hcd,
if (!config)
return timeout;
- for (i = 0; i USB_MAXINTERFACES; i++) {
+ for (i = 0; i config-desc.bNumInterfaces; i++) {
struct usb_driver *driver;
struct usb_interface *intf = config-interface[i];
--
1.8.3.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
[PATCH 09/10] xhci: replace xhci_read_64() with readq()
From: Xenia Ragiadakou burzalod...@gmail.com
Function xhci_read_64() is used to read 64bit xHC registers residing in MMIO.
On 32bit systems, xHC registers need to be read with 32bit accesses by
reading first the lower 32bits and then the higher 32bits.
Replace all calls to xhci_read_64() with calls to readq() and include
asm-generic/io-64-nonatomic-lo-hi.h header file, so that if the system
is not 64bit, readq() will read registers in 32bit chunks with low-high order.
This is done to reduce code duplication since 64bit low-high read logic
is already implemented and to take advantage of inherent atomic 64bit
read operations on 64bit systems.
Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci-dbg.c | 6 +++---
drivers/usb/host/xhci-mem.c | 6 +++---
drivers/usb/host/xhci-ring.c | 6 +++---
drivers/usb/host/xhci.c | 12 ++--
drivers/usb/host/xhci.h | 10 ++
5 files changed, 17 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index eb009a457fb5..b016d38199f2 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -203,12 +203,12 @@ void xhci_print_ir_set(struct xhci_hcd *xhci, int set_num)
addr, (unsigned int)temp);
addr = ir_set-erst_base;
- temp_64 = xhci_read_64(xhci, addr);
+ temp_64 = readq(addr);
xhci_dbg(xhci, %p: ir_set.erst_base = @%08llx\n,
addr, temp_64);
addr = ir_set-erst_dequeue;
- temp_64 = xhci_read_64(xhci, addr);
+ temp_64 = readq(addr);
xhci_dbg(xhci, %p: ir_set.erst_dequeue = @%08llx\n,
addr, temp_64);
}
@@ -412,7 +412,7 @@ void xhci_dbg_cmd_ptrs(struct xhci_hcd *xhci)
{
u64 val;
- val = xhci_read_64(xhci, xhci-op_regs-cmd_ring);
+ val = readq(xhci-op_regs-cmd_ring);
xhci_dbg(xhci, // xHC command ring deq ptr low bits + flags = @%08x\n,
lower_32_bits(val));
xhci_dbg(xhci, // xHC command ring deq ptr high bits = @%08x\n,
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index bce4391a0e7d..4b87026f8a5a 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1958,7 +1958,7 @@ static void xhci_set_hc_event_deq(struct xhci_hcd *xhci)
xhci_warn(xhci, WARN something wrong with SW event ring
dequeue ptr.\n);
/* Update HC event ring dequeue pointer */
- temp = xhci_read_64(xhci, xhci-ir_set-erst_dequeue);
+ temp = readq(xhci-ir_set-erst_dequeue);
temp = ERST_PTR_MASK;
/* Don't clear the EHB bit (which is RW1C) because
* there might be more events to service.
@@ -2312,7 +2312,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
(unsigned long long)xhci-cmd_ring-first_seg-dma);
/* Set the address in the Command Ring Control register */
- val_64 = xhci_read_64(xhci, xhci-op_regs-cmd_ring);
+ val_64 = readq(xhci-op_regs-cmd_ring);
val_64 = (val_64 (u64) CMD_RING_RSVD_BITS) |
(xhci-cmd_ring-first_seg-dma (u64) ~CMD_RING_RSVD_BITS) |
xhci-cmd_ring-cycle_state;
@@ -2396,7 +2396,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
// Set ERST base address for ir_set 0 = 0x%llx,
(unsigned long long)xhci-erst.erst_dma_addr);
- val_64 = xhci_read_64(xhci, xhci-ir_set-erst_base);
+ val_64 = readq(xhci-ir_set-erst_base);
val_64 = ERST_PTR_MASK;
val_64 |= (xhci-erst.erst_dma_addr (u64) ~ERST_PTR_MASK);
xhci_write_64(xhci, val_64, xhci-ir_set-erst_base);
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index bc46cce46db8..339733b8524a 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -313,7 +313,7 @@ static int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
return 0;
}
- temp_64 = xhci_read_64(xhci, xhci-op_regs-cmd_ring);
+ temp_64 = readq(xhci-op_regs-cmd_ring);
if (!(temp_64 CMD_RING_RUNNING)) {
xhci_dbg(xhci, Command ring had been stopped\n);
return 0;
@@ -2871,7 +2871,7 @@ hw_died:
/* Clear the event handler busy flag (RW1C);
* the event ring should be empty.
*/
- temp_64 = xhci_read_64(xhci, xhci-ir_set-erst_dequeue);
+ temp_64 = readq(xhci-ir_set-erst_dequeue);
xhci_write_64(xhci, temp_64 | ERST_EHB,
xhci-ir_set-erst_dequeue);
spin_unlock(xhci-lock);
@@ -2885,7 +2885,7 @@ hw_died:
*/
while (xhci_handle_event(xhci) 0) {}
- temp_64 = xhci_read_64(xhci,
[PATCH 04/10] xhci: fix incorrect type in assignment in xhci_count_num_new_endpoints()
From: Xenia Ragiadakou burzalod...@gmail.com The fields 'add_flags' and 'drop_flags' in struct xhci_input_control_ctx have type __le32 and need to be converted to CPU byteorder before being used to derive the number of added endpoints. This bug was found using sparse. This patch is not suitable for stable, since the bug would only be triggered on big endian systems, and the code only runs for Intel xHCI host controllers, which are always integrated into little endian systems. Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com --- drivers/usb/host/xhci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 1798c5353102..b7289e9a44dd 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -1892,8 +1892,8 @@ static u32 xhci_count_num_new_endpoints(struct xhci_hcd *xhci, * (bit 1). The default control endpoint is added during the Address * Device command and is never removed until the slot is disabled. */ - valid_add_flags = ctrl_ctx-add_flags 2; - valid_drop_flags = ctrl_ctx-drop_flags 2; + valid_add_flags = le32_to_cpu(ctrl_ctx-add_flags) 2; + valid_drop_flags = le32_to_cpu(ctrl_ctx-drop_flags) 2; /* Use hweight32 to count the number of ones in the add flags, or * number of endpoints added. Don't count endpoints that are changed -- 1.8.3.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
[PATCH 10/10] xhci: replace xhci_write_64() with writeq()
From: Xenia Ragiadakou burzalod...@gmail.com
Function xhci_write_64() is used to write 64bit xHC registers residing in MMIO.
On 32bit systems, xHC registers need to be written with 32bit accesses by
writing first the lower 32bits and then the higher 32bits. The header file
asm-generic/io-64-nonatomic-lo-hi.h ensures that on 32bit systems writeq() will
will write 64bit registers in 32bit chunks with low-high order.
Replace all calls to xhci_write_64() with calls to writeq().
This is done to reduce code duplication since 64bit low-high write logic
is already implemented and to take advantage of inherent atomic 64bit
write operations on 64bit systems.
Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci-mem.c | 8
drivers/usb/host/xhci-ring.c | 8 +++-
drivers/usb/host/xhci.c | 8
drivers/usb/host/xhci.h | 29 +
4 files changed, 20 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 4b87026f8a5a..873c272b3ef5 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1967,7 +1967,7 @@ static void xhci_set_hc_event_deq(struct xhci_hcd *xhci)
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
// Write event ring dequeue pointer,
preserving EHB bit);
- xhci_write_64(xhci, ((u64) deq (u64) ~ERST_PTR_MASK) | temp,
+ writeq(((u64) deq (u64) ~ERST_PTR_MASK) | temp,
xhci-ir_set-erst_dequeue);
}
@@ -2269,7 +2269,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
// Device context base array address = 0x%llx (DMA),
%p (virt),
(unsigned long long)xhci-dcbaa-dma, xhci-dcbaa);
- xhci_write_64(xhci, dma, xhci-op_regs-dcbaa_ptr);
+ writeq(dma, xhci-op_regs-dcbaa_ptr);
/*
* Initialize the ring segment pool. The ring must be a contiguous
@@ -2318,7 +2318,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
xhci-cmd_ring-cycle_state;
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
// Setting command ring address to 0x%x, val);
- xhci_write_64(xhci, val_64, xhci-op_regs-cmd_ring);
+ writeq(val_64, xhci-op_regs-cmd_ring);
xhci_dbg_cmd_ptrs(xhci);
xhci-lpm_command = xhci_alloc_command(xhci, true, true, flags);
@@ -2399,7 +2399,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
val_64 = readq(xhci-ir_set-erst_base);
val_64 = ERST_PTR_MASK;
val_64 |= (xhci-erst.erst_dma_addr (u64) ~ERST_PTR_MASK);
- xhci_write_64(xhci, val_64, xhci-ir_set-erst_base);
+ writeq(val_64, xhci-ir_set-erst_base);
/* Set the event ring dequeue address */
xhci_set_hc_event_deq(xhci);
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 339733b8524a..fe9208a5d103 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -319,8 +319,7 @@ static int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
return 0;
}
xhci-cmd_ring_state = CMD_RING_STATE_ABORTED;
- xhci_write_64(xhci, temp_64 | CMD_RING_ABORT,
- xhci-op_regs-cmd_ring);
+ writeq(temp_64 | CMD_RING_ABORT, xhci-op_regs-cmd_ring);
/* Section 4.6.1.2 of xHCI 1.0 spec says software should
* time the completion od all xHCI commands, including
@@ -2872,8 +2871,7 @@ hw_died:
* the event ring should be empty.
*/
temp_64 = readq(xhci-ir_set-erst_dequeue);
- xhci_write_64(xhci, temp_64 | ERST_EHB,
- xhci-ir_set-erst_dequeue);
+ writeq(temp_64 | ERST_EHB, xhci-ir_set-erst_dequeue);
spin_unlock(xhci-lock);
return IRQ_HANDLED;
@@ -2900,7 +2898,7 @@ hw_died:
/* Clear the event handler busy flag (RW1C); event ring is empty. */
temp_64 |= ERST_EHB;
- xhci_write_64(xhci, temp_64, xhci-ir_set-erst_dequeue);
+ writeq(temp_64, xhci-ir_set-erst_dequeue);
spin_unlock(xhci-lock);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 858e992729c9..7fe6f664054f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -762,11 +762,11 @@ static void xhci_restore_registers(struct xhci_hcd *xhci)
{
writel(xhci-s3.command, xhci-op_regs-command);
writel(xhci-s3.dev_nt, xhci-op_regs-dev_notification);
- xhci_write_64(xhci, xhci-s3.dcbaa_ptr, xhci-op_regs-dcbaa_ptr);
+ writeq(xhci-s3.dcbaa_ptr, xhci-op_regs-dcbaa_ptr);
writel(xhci-s3.config_reg, xhci-op_regs-config_reg);
writel(xhci-s3.erst_size, xhci-ir_set-erst_size);
- xhci_write_64(xhci, xhci-s3.erst_base,
[PATCH 05/10] xhci: fix incorrect type in assignment in xhci_count_num_dropped_endpoints()
From: Xenia Ragiadakou burzalod...@gmail.com The fields 'add_flags' and 'drop_flags' in struct xhci_input_control_ctx have type __le32 and need to be converted to CPU byteorder before being used to derive the number of dropped endpoints. This bug was found using sparse. This patch is not suitable for stable, since the bug would only be triggered on big endian systems, and the code only runs for Intel xHCI host controllers, which are always integrated into little endian systems. Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com --- drivers/usb/host/xhci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index b7289e9a44dd..900ba36ee2b8 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -1909,8 +1909,8 @@ static unsigned int xhci_count_num_dropped_endpoints(struct xhci_hcd *xhci, u32 valid_add_flags; u32 valid_drop_flags; - valid_add_flags = ctrl_ctx-add_flags 2; - valid_drop_flags = ctrl_ctx-drop_flags 2; + valid_add_flags = le32_to_cpu(ctrl_ctx-add_flags) 2; + valid_drop_flags = le32_to_cpu(ctrl_ctx-drop_flags) 2; return hweight32(valid_drop_flags) - hweight32(valid_add_flags valid_drop_flags); -- 1.8.3.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
[PATCH 08/10] xhci: replace xhci_writel() with writel()
From: Xenia Ragiadakou burzalod...@gmail.com
Function xhci_writel() is used to write a 32bit value in xHC registers residing
in MMIO address space. It takes as first argument a pointer to the xhci_hcd
although it does not use it. xhci_writel() internally simply calls writel().
This creates an illusion that xhci_writel() is an xhci specific function that
has to be called in a context where a pointer to xhci_hcd is available.
Remove xhci_writel() wrapper function and replace its calls with calls to
writel() to make the code more straight-forward.
Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 35 ++
drivers/usb/host/xhci-mem.c | 6 +++---
drivers/usb/host/xhci-ring.c | 8 +++
drivers/usb/host/xhci.c | 51 +---
drivers/usb/host/xhci.h | 8 ---
5 files changed, 47 insertions(+), 61 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 70ed7c94e917..9992fbfec85f 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -342,7 +342,7 @@ static void xhci_disable_port(struct usb_hcd *hcd, struct
xhci_hcd *xhci,
}
/* Write 1 to disable the port */
- xhci_writel(xhci, port_status | PORT_PE, addr);
+ writel(port_status | PORT_PE, addr);
port_status = readl(addr);
xhci_dbg(xhci, disable port, actual port %d status = 0x%x\n,
wIndex, port_status);
@@ -388,7 +388,7 @@ static void xhci_clear_port_change_bit(struct xhci_hcd
*xhci, u16 wValue,
return;
}
/* Change bits are all write 1 to clear */
- xhci_writel(xhci, port_status | status, addr);
+ writel(port_status | status, addr);
port_status = readl(addr);
xhci_dbg(xhci, clear port %s change, actual port %d status = 0x%x\n,
port_change_bit, wIndex, port_status);
@@ -419,7 +419,7 @@ void xhci_set_link_state(struct xhci_hcd *xhci, __le32
__iomem **port_array,
temp = xhci_port_state_to_neutral(temp);
temp = ~PORT_PLS_MASK;
temp |= PORT_LINK_STROBE | link_state;
- xhci_writel(xhci, temp, port_array[port_id]);
+ writel(temp, port_array[port_id]);
}
static void xhci_set_remote_wake_mask(struct xhci_hcd *xhci,
@@ -445,7 +445,7 @@ static void xhci_set_remote_wake_mask(struct xhci_hcd *xhci,
else
temp = ~PORT_WKOC_E;
- xhci_writel(xhci, temp, port_array[port_id]);
+ writel(temp, port_array[port_id]);
}
/* Test and clear port RWC bit */
@@ -458,7 +458,7 @@ void xhci_test_and_clear_bit(struct xhci_hcd *xhci, __le32
__iomem **port_array,
if (temp port_bit) {
temp = xhci_port_state_to_neutral(temp);
temp |= port_bit;
- xhci_writel(xhci, temp, port_array[port_id]);
+ writel(temp, port_array[port_id]);
}
}
@@ -838,8 +838,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
temp |= PORT_CSC | PORT_PEC | PORT_WRC |
PORT_OCC | PORT_RC | PORT_PLC |
PORT_CEC;
- xhci_writel(xhci, temp | PORT_PE,
- port_array[wIndex]);
+ writel(temp | PORT_PE, port_array[wIndex]);
temp = readl(port_array[wIndex]);
break;
}
@@ -894,8 +893,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
* However, khubd will ignore the roothub events until
* the roothub is registered.
*/
- xhci_writel(xhci, temp | PORT_POWER,
- port_array[wIndex]);
+ writel(temp | PORT_POWER, port_array[wIndex]);
temp = readl(port_array[wIndex]);
xhci_dbg(xhci, set port power, actual port %d status
= 0x%x\n, wIndex, temp);
@@ -910,7 +908,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
break;
case USB_PORT_FEAT_RESET:
temp = (temp | PORT_RESET);
- xhci_writel(xhci, temp, port_array[wIndex]);
+ writel(temp, port_array[wIndex]);
temp = readl(port_array[wIndex]);
xhci_dbg(xhci, set port reset, actual port %d status
= 0x%x\n, wIndex, temp);
@@ -925,7 +923,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
break;
case USB_PORT_FEAT_BH_PORT_RESET:
temp |= PORT_WR;
-
[PATCH 03/10] xhci: remove unnecessary check in xhci_free_stream_info()
From: Xenia Ragiadakou burzalod...@gmail.com This patch removes the unneccessary check 'if (stream_info)' because there is already a check few lines above which ensures that stream_info is not NULL. Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com --- drivers/usb/host/xhci-mem.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index 90709cf45ee5..1445e08819cf 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -722,8 +722,7 @@ void xhci_free_stream_info(struct xhci_hcd *xhci, stream_info-stream_ctx_array, stream_info-ctx_array_dma); - if (stream_info) - kfree(stream_info-stream_rings); + kfree(stream_info-stream_rings); kfree(stream_info); } -- 1.8.3.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
[PATCH 07/10] xhci: replace xhci_readl() with readl()
From: Xenia Ragiadakou burzalod...@gmail.com
Function xhci_readl() is used to read 32bit xHC registers residing in MMIO
address space. It takes as first argument a pointer to the xhci_hcd although
it does not use it. xhci_readl() internally simply calls readl(). This creates
an illusion that xhci_readl() is an xhci specific function that has to be
called in a context where a pointer to xhci_hcd is available.
Remove the unnecessary xhci_readl() wrapper function and replace its calls to
with calls to readl() to make the code more straightforward.
Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci-dbg.c | 36 +--
drivers/usb/host/xhci-hub.c | 71 ++--
drivers/usb/host/xhci-mem.c | 20 +--
drivers/usb/host/xhci-ring.c | 12 +++
drivers/usb/host/xhci.c | 86 ++--
drivers/usb/host/xhci.h | 5 ---
6 files changed, 112 insertions(+), 118 deletions(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 73503a81ee81..eb009a457fb5 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -32,7 +32,7 @@ void xhci_dbg_regs(struct xhci_hcd *xhci)
xhci_dbg(xhci, // xHCI capability registers at %p:\n,
xhci-cap_regs);
- temp = xhci_readl(xhci, xhci-cap_regs-hc_capbase);
+ temp = readl(xhci-cap_regs-hc_capbase);
xhci_dbg(xhci, // @%p = 0x%x (CAPLENGTH AND HCIVERSION)\n,
xhci-cap_regs-hc_capbase, temp);
xhci_dbg(xhci, // CAPLENGTH: 0x%x\n,
@@ -44,13 +44,13 @@ void xhci_dbg_regs(struct xhci_hcd *xhci)
xhci_dbg(xhci, // xHCI operational registers at %p:\n, xhci-op_regs);
- temp = xhci_readl(xhci, xhci-cap_regs-run_regs_off);
+ temp = readl(xhci-cap_regs-run_regs_off);
xhci_dbg(xhci, // @%p = 0x%x RTSOFF\n,
xhci-cap_regs-run_regs_off,
(unsigned int) temp RTSOFF_MASK);
xhci_dbg(xhci, // xHCI runtime registers at %p:\n, xhci-run_regs);
- temp = xhci_readl(xhci, xhci-cap_regs-db_off);
+ temp = readl(xhci-cap_regs-db_off);
xhci_dbg(xhci, // @%p = 0x%x DBOFF\n, xhci-cap_regs-db_off, temp);
xhci_dbg(xhci, // Doorbell array at %p:\n, xhci-dba);
}
@@ -61,7 +61,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci)
xhci_dbg(xhci, xHCI capability registers at %p:\n, xhci-cap_regs);
- temp = xhci_readl(xhci, xhci-cap_regs-hc_capbase);
+ temp = readl(xhci-cap_regs-hc_capbase);
xhci_dbg(xhci, CAPLENGTH AND HCIVERSION 0x%x:\n,
(unsigned int) temp);
xhci_dbg(xhci, CAPLENGTH: 0x%x\n,
@@ -69,7 +69,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci)
xhci_dbg(xhci, HCIVERSION: 0x%x\n,
(unsigned int) HC_VERSION(temp));
- temp = xhci_readl(xhci, xhci-cap_regs-hcs_params1);
+ temp = readl(xhci-cap_regs-hcs_params1);
xhci_dbg(xhci, HCSPARAMS 1: 0x%x\n,
(unsigned int) temp);
xhci_dbg(xhci, Max device slots: %u\n,
@@ -79,7 +79,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci)
xhci_dbg(xhci, Max ports: %u\n,
(unsigned int) HCS_MAX_PORTS(temp));
- temp = xhci_readl(xhci, xhci-cap_regs-hcs_params2);
+ temp = readl(xhci-cap_regs-hcs_params2);
xhci_dbg(xhci, HCSPARAMS 2: 0x%x\n,
(unsigned int) temp);
xhci_dbg(xhci, Isoc scheduling threshold: %u\n,
@@ -87,7 +87,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci)
xhci_dbg(xhci, Maximum allowed segments in event ring: %u\n,
(unsigned int) HCS_ERST_MAX(temp));
- temp = xhci_readl(xhci, xhci-cap_regs-hcs_params3);
+ temp = readl(xhci-cap_regs-hcs_params3);
xhci_dbg(xhci, HCSPARAMS 3 0x%x:\n,
(unsigned int) temp);
xhci_dbg(xhci, Worst case U1 device exit latency: %u\n,
@@ -95,14 +95,14 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci)
xhci_dbg(xhci, Worst case U2 device exit latency: %u\n,
(unsigned int) HCS_U2_LATENCY(temp));
- temp = xhci_readl(xhci, xhci-cap_regs-hcc_params);
+ temp = readl(xhci-cap_regs-hcc_params);
xhci_dbg(xhci, HCC PARAMS 0x%x:\n, (unsigned int) temp);
xhci_dbg(xhci, HC generates %s bit addresses\n,
HCC_64BIT_ADDR(temp) ? 64 : 32);
/* FIXME */
xhci_dbg(xhci, FIXME: more HCCPARAMS debugging\n);
- temp = xhci_readl(xhci, xhci-cap_regs-run_regs_off);
+ temp = readl(xhci-cap_regs-run_regs_off);
xhci_dbg(xhci, RTSOFF 0x%x:\n, temp RTSOFF_MASK);
}
@@ -110,7 +110,7 @@ static void xhci_print_command_reg(struct xhci_hcd *xhci)
{
u32 temp;
-
[GIT PULL] xhci: Sparse fixes, replace xhci_read/write, misc
The following changes since commit 172a894f74e090f3aada7b0347d334ad9db14a36: xhci: fix incorrect type in assignment in xhci_address_device() (2013-11-18 10:10:13 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-next-2013-11-27 for you to fetch changes up to 0a18329ee52b60937a522fb237876c032a3d79b6: xhci: replace xhci_write_64() with writeq() (2013-11-18 11:45:37 -0800) xhci: Sparse fixes, replace xhci_read/write, misc Hi Greg, Here's ten patches for 3.14. They include some non-urgent cleanups, and the patches to replace the xhci_read/write variants with standard read/write calls. This also includes a couple of streams fixes, but not the full set from Hans. (I'll test those next week.) The goal is to get both the xHCI driver streams support and the UAS driver fixed up for 3.14. We don't want to mark the fixes for stable, as all the code changes are really too big for stable. Please merge usb-linus into usb-next before pulling this request. Sarah Sharp Xenia Ragiadakou (10): xhci: replace USB_MAXINTERFACES with config-desc.bNumInterface xhci: fix SCT_FOR_CTX(p) macro xhci: remove unnecessary check in xhci_free_stream_info() xhci: fix incorrect type in assignment in xhci_count_num_new_endpoints() xhci: fix incorrect type in assignment in xhci_count_num_dropped_endpoints() xhci: remove conversion from generic to pci device in xhci_mem.c xhci: replace xhci_readl() with readl() xhci: replace xhci_writel() with writel() xhci: replace xhci_read_64() with readq() xhci: replace xhci_write_64() with writeq() drivers/usb/host/xhci-dbg.c | 42 +- drivers/usb/host/xhci-hub.c | 106 +-- drivers/usb/host/xhci-mem.c | 63 drivers/usb/host/xhci-ring.c | 34 - drivers/usb/host/xhci.c | 167 +- drivers/usb/host/xhci.h | 54 +++--- 6 files changed, 213 insertions(+), 253 deletions(-) -- 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/10] xhci: fix SCT_FOR_CTX(p) macro
From: Xenia Ragiadakou burzalod...@gmail.com
SCT_FOR_CTX(p) is defined as (((p) 1) 0x7) in which case if we want
to set the stream context type to SCT_SSA_256 i.e 0x7 (although secondary
stream arrays are not yet supported) using this macro definition we will
get actually 0x6 which is not what we want.
This patch fixes the above issue by defining the SCT_FOR_CTX(p) macro as
(((p) 0x7) 1)
Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 03c74b7965f8..a33e8b5bf7a2 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -752,7 +752,7 @@ struct xhci_stream_ctx {
};
/* Stream Context Types (section 6.4.1) - bits 3:1 of stream ctx deq ptr */
-#defineSCT_FOR_CTX(p) (((p) 1) 0x7)
+#defineSCT_FOR_CTX(p) (((p) 0x7) 1)
/* Secondary stream array type, dequeue pointer is to a transfer ring */
#defineSCT_SEC_TR 0
/* Primary stream array type, dequeue pointer is to a transfer ring */
--
1.8.3.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
[PATCH 06/10] xhci: remove conversion from generic to pci device in xhci_mem.c
From: Xenia Ragiadakou burzalod...@gmail.com
This patch removes the to_pci_dev() conversion performed to generic struct
device since it is not actually useful (the pointer to the generic device
can be used directly rather through a conversion to pci_dev) and it is pci
bus specific.
This isn't stable material because this code will produce harmless
behavior on non-PCI xHCI hosts. The pci_device pointer is never
dereferenced, only used to re-calculate the underlying device pointer.
Signed-off-by: Xenia Ragiadakou burzalod...@gmail.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci-mem.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 1445e08819cf..99e7251c2b65 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -433,10 +433,10 @@ static void xhci_free_stream_ctx(struct xhci_hcd *xhci,
unsigned int num_stream_ctxs,
struct xhci_stream_ctx *stream_ctx, dma_addr_t dma)
{
- struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)-self.controller);
+ struct device *dev = xhci_to_hcd(xhci)-self.controller;
if (num_stream_ctxs MEDIUM_STREAM_ARRAY_SIZE)
- dma_free_coherent(pdev-dev,
+ dma_free_coherent(dev,
sizeof(struct xhci_stream_ctx)*num_stream_ctxs,
stream_ctx, dma);
else if (num_stream_ctxs = SMALL_STREAM_ARRAY_SIZE)
@@ -461,10 +461,10 @@ static struct xhci_stream_ctx
*xhci_alloc_stream_ctx(struct xhci_hcd *xhci,
unsigned int num_stream_ctxs, dma_addr_t *dma,
gfp_t mem_flags)
{
- struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)-self.controller);
+ struct device *dev = xhci_to_hcd(xhci)-self.controller;
if (num_stream_ctxs MEDIUM_STREAM_ARRAY_SIZE)
- return dma_alloc_coherent(pdev-dev,
+ return dma_alloc_coherent(dev,
sizeof(struct xhci_stream_ctx)*num_stream_ctxs,
dma, mem_flags);
else if (num_stream_ctxs = SMALL_STREAM_ARRAY_SIZE)
@@ -1616,7 +1616,7 @@ static void scratchpad_free(struct xhci_hcd *xhci)
{
int num_sp;
int i;
- struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)-self.controller);
+ struct device *dev = xhci_to_hcd(xhci)-self.controller;
if (!xhci-scratchpad)
return;
@@ -1624,13 +1624,13 @@ static void scratchpad_free(struct xhci_hcd *xhci)
num_sp = HCS_MAX_SCRATCHPAD(xhci-hcs_params2);
for (i = 0; i num_sp; i++) {
- dma_free_coherent(pdev-dev, xhci-page_size,
+ dma_free_coherent(dev, xhci-page_size,
xhci-scratchpad-sp_buffers[i],
xhci-scratchpad-sp_dma_buffers[i]);
}
kfree(xhci-scratchpad-sp_dma_buffers);
kfree(xhci-scratchpad-sp_buffers);
- dma_free_coherent(pdev-dev, num_sp * sizeof(u64),
+ dma_free_coherent(dev, num_sp * sizeof(u64),
xhci-scratchpad-sp_array,
xhci-scratchpad-sp_dma);
kfree(xhci-scratchpad);
@@ -1692,7 +1692,7 @@ void xhci_free_command(struct xhci_hcd *xhci,
void xhci_mem_cleanup(struct xhci_hcd *xhci)
{
- struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)-self.controller);
+ struct device *dev = xhci_to_hcd(xhci)-self.controller;
struct xhci_cd *cur_cd, *next_cd;
int size;
int i, j, num_ports;
@@ -1700,7 +1700,7 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
/* Free the Event Ring Segment Table and the actual Event Ring */
size = sizeof(struct xhci_erst_entry)*(xhci-erst.num_entries);
if (xhci-erst.entries)
- dma_free_coherent(pdev-dev, size,
+ dma_free_coherent(dev, size,
xhci-erst.entries, xhci-erst.erst_dma_addr);
xhci-erst.entries = NULL;
xhci_dbg_trace(xhci, trace_xhci_dbg_init, Freed ERST);
@@ -1748,7 +1748,7 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
Freed medium stream array pool);
if (xhci-dcbaa)
- dma_free_coherent(pdev-dev, sizeof(*xhci-dcbaa),
+ dma_free_coherent(dev, sizeof(*xhci-dcbaa),
xhci-dcbaa, xhci-dcbaa-dma);
xhci-dcbaa = NULL;
--
1.8.3.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: [GIT PULL] xhci: Big-endian sparse fixes.
On Wed, Nov 27, 2013 at 03:14:40PM -0800, Sarah Sharp wrote: The following changes since commit 7d49f0bac41ee9b012af1efe2f725d91a87a8fe9: USB: Maintainers change for usb serial drivers (2013-10-31 08:53:52 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-11-27 for you to fetch changes up to 172a894f74e090f3aada7b0347d334ad9db14a36: xhci: fix incorrect type in assignment in xhci_address_device() (2013-11-18 10:10:13 -0800) xhci: Big-endian sparse fixes. Hi Greg, Here's five sparse cleanups that make the xHCI driver actually work on big-endian machines. They're all marked for stable. Why is a new feature like big-endian support for xhci a stable thing? And something that isn't ok for 3.13-final? You can't have it both ways, sorry. 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
Re: [GIT PULL] xhci: Big-endian sparse fixes.
On Wed, Nov 27, 2013 at 03:36:02PM -0800, Greg Kroah-Hartman wrote: On Wed, Nov 27, 2013 at 03:14:40PM -0800, Sarah Sharp wrote: The following changes since commit 7d49f0bac41ee9b012af1efe2f725d91a87a8fe9: USB: Maintainers change for usb serial drivers (2013-10-31 08:53:52 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-11-27 for you to fetch changes up to 172a894f74e090f3aada7b0347d334ad9db14a36: xhci: fix incorrect type in assignment in xhci_address_device() (2013-11-18 10:10:13 -0800) xhci: Big-endian sparse fixes. Hi Greg, Here's five sparse cleanups that make the xHCI driver actually work on big-endian machines. They're all marked for stable. Why is a new feature like big-endian support for xhci a stable thing? And something that isn't ok for 3.13-final? Wait, sorry, this is for 3.13-final? totally confused. And if it is, is this a regression? It looks like a new feature to me. 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
Re: [GIT PULL] xhci: Big-endian sparse fixes.
On Wed, Nov 27, 2013 at 03:36:56PM -0800, Greg Kroah-Hartman wrote: On Wed, Nov 27, 2013 at 03:36:02PM -0800, Greg Kroah-Hartman wrote: On Wed, Nov 27, 2013 at 03:14:40PM -0800, Sarah Sharp wrote: The following changes since commit 7d49f0bac41ee9b012af1efe2f725d91a87a8fe9: USB: Maintainers change for usb serial drivers (2013-10-31 08:53:52 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-11-27 for you to fetch changes up to 172a894f74e090f3aada7b0347d334ad9db14a36: xhci: fix incorrect type in assignment in xhci_address_device() (2013-11-18 10:10:13 -0800) xhci: Big-endian sparse fixes. Hi Greg, Here's five sparse cleanups that make the xHCI driver actually work on big-endian machines. They're all marked for stable. Why is a new feature like big-endian support for xhci a stable thing? It's not a new feature. The xHCI driver has supported big-endian systems for ages (since 3.0 I think). There were several xHCI structures that had variables marked with __le32 to make sure the driver continued to work on big-endian systems. However, I was lax, and code got into 3.4 and 3.12 that broke the driver under big endian systems. Sparse found those issues, and Xenia cleaned them up. And something that isn't ok for 3.13-final? Wait, sorry, this is for 3.13-final? These are fixes to be queued for 3.13. totally confused. And if it is, is this a regression? It looks like a new feature to me. Yes, it's a regression that has been there since 3.4. No one complained about it since then, so I seriously considered whether they should go into stable or not. Does that explanation make sense? Sarah Sharp -- 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: 3.12.1 Virt dev invalid for slot_id 0x1 from drivers/usb/host/xhci.c
On 11/27/2013 02:59 PM, Sarah Sharp wrote:
On Mon, Nov 25, 2013 at 11:41:47AM -0700, Shuah Khan wrote:
I started seeing the following on my Samsung Series on 3.12.1
Is this bad? Looks like the following WARN_ON is firing:
drivers/usb/host/xhci.c:
if (WARN_ON(!virt_dev)) {
/*
* In plug/unplug torture test with an NEC controller,
* a zero-dereference was observed once due to
virt_dev = 0.
* Print useful debug rather than crash if it is
observed again!
*/
xhci_warn(xhci, Virt dev invalid for slot_id 0x%x!\n,
udev-slot_id);
return -EINVAL;
}
As the comment says, the WARN_ON was there so we can track down why this
specific NULL pointer dereference bug could have been hit.
What are the specific steps to reproduce this? It looks like it's
coming from a device resume path. Did you have auto-suspend enabled for
your USB devices, or did this warning occur right after an S3 resume?
Can you enable CONFIG_USB_DEBUG and CONFIG_DYNAMIC_DEBUG, and send me
dmesg starting from just before you trigger the WARN_ON()? I need to
see what the xHCI driver state that causes this might be.
Sarah Sharp
I forgot to mention that this problem is seen when I run suspend-to-disk
test in reboot mode. Reproduced it again on 3.12.2-rc1 once and dmesg
buffer wrapped around before I could save the log.
I enabled CONFIG_USB_DEBUG and I already had CONFIG_DYNAMIC_DEBUG
enabled in config.
It doesn't seem to happen every time I to suspend-to-disk. I will try
again and send you the log.
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
--
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: [REWORKED PATCH 1/5] usb: phy: fsm: don't depend on indirect includes
Hi, On Wed, Nov 27, 2013 at 11:14:56AM +0900, Anton Tikhomirov wrote: Hi Felipe, Hi, On Tue, Nov 26, 2013 at 10:33:44AM -0600, Felipe Balbi wrote: this header uses spinlocks and errno values, so we must include linux/spinlock.h and linux/errno.h to avoid build errors. Signed-off-by: Felipe Balbi ba...@ti.com Anton, I had to rework your patch series quite a bit in order to make Thank you. it acceptable. It seems unlikely that you compile-tested your series, considering we would very clearly see build errors after moving the header around. Your driver depends (or depended?) too much on indirect header inclusions. Currently only Freescale OTG Transceiver Driver uses OTG FSM. After applying patches it was compiled without errors. usually allmodconfig, allyesconfig, allnoconfig with different architectures uncovers a bunch of errors. Thank you Felipe. I'll be more careful next time. -- 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/3] usb: gadget: goku_udc: use DEFINE_PCI_DEVICE_TABLE macro
This macro is used to create a struct pci_device_id array.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/gadget/goku_udc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/goku_udc.c b/drivers/usb/gadget/goku_udc.c
index f827680..120ba8a 100644
--- a/drivers/usb/gadget/goku_udc.c
+++ b/drivers/usb/gadget/goku_udc.c
@@ -1803,7 +1803,7 @@ err:
/*-*/
-static const struct pci_device_id pci_ids[] = { {
+static DEFINE_PCI_DEVICE_TABLE(pci_ids) = { {
.class =((PCI_CLASS_SERIAL_USB 8) | 0xfe),
.class_mask = ~0,
.vendor = 0x102f, /* Toshiba */
--
1.7.10.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 3/3] usb: gadget: net2280: use DEFINE_PCI_DEVICE_TABLE macro
This macro is used to create a struct pci_device_id array.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/gadget/net2280.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/net2280.c b/drivers/usb/gadget/net2280.c
index fc85217..e267a5a 100644
--- a/drivers/usb/gadget/net2280.c
+++ b/drivers/usb/gadget/net2280.c
@@ -2853,7 +2853,7 @@ static void net2280_shutdown (struct pci_dev *pdev)
/*-*/
-static const struct pci_device_id pci_ids [] = { {
+static DEFINE_PCI_DEVICE_TABLE(pci_ids) = { {
.class =((PCI_CLASS_SERIAL_USB 8) | 0xfe),
.class_mask = ~0,
.vendor = 0x17cc,
--
1.7.10.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 1/5] USB: EHCI: use DEFINE_PCI_DEVICE_TABLE macro
This macro is used to create a struct pci_device_id array.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/host/ehci-pci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 3e86bf4..5b30f59 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -328,7 +328,7 @@ static const struct ehci_driver_overrides pci_overrides
__initconst = {
/*-*/
/* PCI driver selection metadata; PCI hotplugging uses this */
-static const struct pci_device_id pci_ids [] = { {
+static DEFINE_PCI_DEVICE_TABLE(pci_ids) = { {
/* handle any USB 2.0 EHCI controller */
PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_EHCI, ~0),
.driver_data = (unsigned long) ehci_pci_hc_driver,
--
1.7.10.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 2/5] USB: OHCI: use DEFINE_PCI_DEVICE_TABLE macro
This macro is used to create a struct pci_device_id array.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/host/ohci-pci.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-pci.c b/drivers/usb/host/ohci-pci.c
index 90879e9..762e20a 100644
--- a/drivers/usb/host/ohci-pci.c
+++ b/drivers/usb/host/ohci-pci.c
@@ -164,7 +164,7 @@ static int ohci_quirk_amd700(struct usb_hcd *hcd)
}
/* List of quirks for OHCI */
-static const struct pci_device_id ohci_pci_quirks[] = {
+static DEFINE_PCI_DEVICE_TABLE(ohci_pci_quirks) = {
{
PCI_DEVICE(PCI_VENDOR_ID_AMD, 0x740c),
.driver_data = (unsigned long)ohci_quirk_amd756,
@@ -256,7 +256,7 @@ static const struct ohci_driver_overrides pci_overrides
__initconst = {
.reset =ohci_pci_reset,
};
-static const struct pci_device_id pci_ids [] = { {
+static DEFINE_PCI_DEVICE_TABLE(pci_ids) = { {
/* handle any USB OHCI controller */
PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_OHCI, ~0),
.driver_data = (unsigned long) ohci_pci_hc_driver,
--
1.7.10.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 3/5] USB: xHCI: use DEFINE_PCI_DEVICE_TABLE macro
This macro is used to create a struct pci_device_id array.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/host/xhci-pci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index b8dffd5..3f75a32 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -357,7 +357,7 @@ static const struct hc_driver xhci_pci_hc_driver = {
/*-*/
/* PCI driver selection metadata; PCI hotplugging uses this */
-static const struct pci_device_id pci_ids[] = { {
+static DEFINE_PCI_DEVICE_TABLE(pci_ids) = { {
/* handle any USB 3.0 xHCI controller */
PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_XHCI, ~0),
.driver_data = (unsigned long) xhci_pci_hc_driver,
--
1.7.10.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 4/5] USB: whci-hcd: use DEFINE_PCI_DEVICE_TABLE macro
This macro is used to create a struct pci_device_id array.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/host/whci/hcd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/whci/hcd.c b/drivers/usb/host/whci/hcd.c
index 1b0888f..1192f6a 100644
--- a/drivers/usb/host/whci/hcd.c
+++ b/drivers/usb/host/whci/hcd.c
@@ -355,7 +355,7 @@ static void __exit whci_hc_driver_exit(void)
module_exit(whci_hc_driver_exit);
/* PCI device ID's that we handle (so it gets loaded) */
-static struct pci_device_id __used whci_hcd_id_table[] = {
+static __used DEFINE_PCI_DEVICE_TABLE(whci_hcd_id_table) = {
{ PCI_DEVICE_CLASS(PCI_CLASS_WIRELESS_WHCI, ~0) },
{ /* empty last entry */ }
};
--
1.7.10.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 5/5] USB: isp1760: use DEFINE_PCI_DEVICE_TABLE macro
This macro is used to create a struct pci_device_id array.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/host/isp1760-if.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/isp1760-if.c b/drivers/usb/host/isp1760-if.c
index df931e9..7771861 100644
--- a/drivers/usb/host/isp1760-if.c
+++ b/drivers/usb/host/isp1760-if.c
@@ -322,7 +322,7 @@ static void isp1761_pci_shutdown(struct pci_dev *dev)
printk(KERN_ERR ips1761_pci_shutdown\n);
}
-static const struct pci_device_id isp1760_plx [] = {
+static DEFINE_PCI_DEVICE_TABLE(isp1760_plx) = {
{
.class = PCI_CLASS_BRIDGE_OTHER 8,
.class_mask = ~0,
--
1.7.10.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 v2 2/2] usb: chipidea: usbmisc: Add support for i.MX51 CPU
On Tue, Nov 26, 2013 at 07:36:50PM +0400, Alexander Shiyan wrote:
This adds i.MX51 as the next user of the usbmisc driver.
Functionality is similar to i.MX53, so at this stage simply
reuse existing i.MX53 calls.
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
---
drivers/usb/chipidea/usbmisc_imx.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index 4381c5a6..cd061ab 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -204,6 +204,10 @@ static const struct of_device_id usbmisc_imx_dt_ids[] = {
.data = imx27_usbmisc_ops,
},
{
+ .compatible = fsl,imx51-usbmisc,
+ .data = imx53_usbmisc_ops,
If it simply uses imx53 ops, why do we need to introduce a new
compatible?
Shawn
+ },
+ {
.compatible = fsl,imx53-usbmisc,
.data = imx53_usbmisc_ops,
},
--
1.8.3.2
--
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 -next] staging: dwc2: fix sparse non static symbol warning
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Fixes the following sparse warning:
drivers/staging/dwc2/core.c:2672:6: warning:
symbol 'dwc2_set_param_uframe_sched' was not declared. Should it be static?
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/staging/dwc2/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/dwc2/core.c b/drivers/staging/dwc2/core.c
index c0b122a..ffc3fa7 100644
--- a/drivers/staging/dwc2/core.c
+++ b/drivers/staging/dwc2/core.c
@@ -2669,7 +2669,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
return 0;
}
-void dwc2_set_param_uframe_sched(struct dwc2_hsotg *hsotg, int val)
+static void dwc2_set_param_uframe_sched(struct dwc2_hsotg *hsotg, int val)
{
if (DWC2_OUT_OF_BOUNDS(val, 0, 1)) {
if (val = 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 1/3] usb: gadget: goku_udc: use DEFINE_PCI_DEVICE_TABLE macro
On Thu, Nov 28, 2013 at 11:02:26AM +0900, Jingoo Han wrote: This macro is used to create a struct pci_device_id array. And it shouldn't be used, please don't. 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
Re: 答复: Re: 【PATCH】USB：add new zte 3g-modem's pid to option.c
On Thu, Nov 28, 2013 at 10:46:51AM +0800, zhang.ju...@zte.com.cn wrote: Signed-off-by: Jun zhang zhang.ju...@zte.com.cn You failed to answer my question from before, why? --- drivers/usb/serial/option.c2013-11-21 04:37:52.0 +0800 +++ option_bac.c2013-11-28 14:13:54.480576688 +0800 I need to be able to apply a patch with 'patch -p1', please read Documentation/SubmittingPatches for how to do this correctly. Care to try again? 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
Re: musb： bluk_split only worked for the first segment(PIO only)
It is by hardware, but in some platforms, for example TI AM335x, these
features are not supported even though the register bits are set.
It's a weird registers, so I think it should do a special
musb_read_configdata
and return the right register value. Then the musb_core_init will do the right
thing.
So in AM335x Arago 3.2 kernel, struct musb_hdrc_config has two flags
to specify if the features are supported or not. For mainline kernel,
I would think we need a flag in dtb to workaround this bug.
On Thu, Nov 28, 2013 at 2:20 AM, Bin Liu binml...@gmail.com wrote:
On Tue, Nov 26, 2013 at 8:22 PM, Yingchun Li sword.l.dra...@gmail.com wrote:
On Wed, Nov 27, 2013 at 12:38 AM, Bin Liu binml...@gmail.com wrote:
On Thu, Nov 21, 2013 at 4:40 AM, Yingchun Li sword.l.dra...@gmail.com
wrote:
hi,
if musb bulk_split is enable, the segment size will be set according
to hw_ep-max_packet_sz_tx, and the segment will be writen to fifo.
But after the first tranfser end, the segment size will be set no larger
than qh-maxpacket (in musb_host_tx),and the bluk_split make no sense.
so please check the following patch, I have tested it on my board.
For the platforms which do not support bulk split/combine, I would
think the right fix should be set musb-bulk_combine = false, and
musb-bulk_split = false at the end of musb_core_init() in
musb_core.c.
Is it enabled/disabled by hardware features:
musb_core.c--musb_core_init
if (reg MUSB_CONFIGDATA_MPTXE) {
strcat(aInfo, , bulk split);
musb-bulk_split = true;
}
It is by hardware, but in some platforms, for example TI AM335x, these
features are not supported even though the register bits are set.
So in AM335x Arago 3.2 kernel, struct musb_hdrc_config has two flags
to specify if the features are supported or not. For mainline kernel,
I would think we need a flag in dtb to workaround this bug.
-Bin.
-Bin.
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 6582a20..f251132 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1455,8 +1455,8 @@ done:
* (and presumably, FIFO is not half-full) we should write *two*
* packets before updating TXCSR; other docs disagree...
*/
- if (length qh-maxpacket)
- length = qh-maxpacket;
+ if (length qh-segsize)
+ length = qh-segsize;
/* Unmap the buffer so that CPU can use it */
usb_hcd_unmap_urb_for_dma(musb-hcd, urb);
--
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
--
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 1/3] usb: gadget: goku_udc: use DEFINE_PCI_DEVICE_TABLE macro
On Thursday, November 28, 2013 11:02 AM, Jingoo Han wrote:
This macro is used to create a struct pci_device_id array.
Signed-off-by: Jingoo Han jg1@samsung.com
Please, ignore these patches.
As Greg Kroah-Hartman said, I will send the patch to remove
'DEFINE_PCI_DEVICE_TABLE' instead.
Sorry for annoying. :-)
Best regards,
Jingoo Han
---
drivers/usb/gadget/goku_udc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/goku_udc.c b/drivers/usb/gadget/goku_udc.c
index f827680..120ba8a 100644
--- a/drivers/usb/gadget/goku_udc.c
+++ b/drivers/usb/gadget/goku_udc.c
@@ -1803,7 +1803,7 @@ err:
/*-*/
-static const struct pci_device_id pci_ids[] = { {
+static DEFINE_PCI_DEVICE_TABLE(pci_ids) = { {
.class =((PCI_CLASS_SERIAL_USB 8) | 0xfe),
.class_mask = ~0,
.vendor = 0x102f, /* Toshiba */
--
1.7.10.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 1/5] USB: UHCI: remove DEFINE_PCI_DEVICE_TABLE macro
Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro
is not preferred.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/host/uhci-pci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/uhci-pci.c b/drivers/usb/host/uhci-pci.c
index 4cd7988..940304c 100644
--- a/drivers/usb/host/uhci-pci.c
+++ b/drivers/usb/host/uhci-pci.c
@@ -279,7 +279,7 @@ static const struct hc_driver uhci_driver = {
.hub_control = uhci_hub_control,
};
-static DEFINE_PCI_DEVICE_TABLE(uhci_pci_ids) = { {
+static const struct pci_device_id uhci_pci_ids[] = { {
/* handle any USB UHCI controller */
PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_UHCI, ~0),
.driver_data = (unsigned long) uhci_driver,
--
1.7.10.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 3/5] usb: dwc3: pci: remove DEFINE_PCI_DEVICE_TABLE macro
Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro
is not preferred.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/dwc3/dwc3-pci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 31443ae..665686e 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -182,7 +182,7 @@ static void dwc3_pci_remove(struct pci_dev *pci)
pci_disable_device(pci);
}
-static DEFINE_PCI_DEVICE_TABLE(dwc3_pci_id_table) = {
+static const struct pci_device_id dwc3_pci_id_table[] = {
{
PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3),
--
1.7.10.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 4/5] usb: gadget: pch_udc: remove DEFINE_PCI_DEVICE_TABLE macro
Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro
is not preferred.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/gadget/pch_udc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/pch_udc.c b/drivers/usb/gadget/pch_udc.c
index 32d5e92..78a3d92 100644
--- a/drivers/usb/gadget/pch_udc.c
+++ b/drivers/usb/gadget/pch_udc.c
@@ -3210,7 +3210,7 @@ finished:
return retval;
}
-static DEFINE_PCI_DEVICE_TABLE(pch_udc_pcidev_id) = {
+static const struct pci_device_id pch_udc_pcidev_id[] = {
{
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_EG20T_UDC),
.class = (PCI_CLASS_SERIAL_USB 8) | 0xfe,
--
1.7.10.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 5/5] usb: gadget: amd5536udc: remove DEFINE_PCI_DEVICE_TABLE macro
Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro
is not preferred.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/gadget/amd5536udc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/amd5536udc.c b/drivers/usb/gadget/amd5536udc.c
index 54a1e29..f0ff4a6 100644
--- a/drivers/usb/gadget/amd5536udc.c
+++ b/drivers/usb/gadget/amd5536udc.c
@@ -3338,7 +3338,7 @@ static int udc_remote_wakeup(struct udc *dev)
}
/* PCI device parameters */
-static DEFINE_PCI_DEVICE_TABLE(pci_id) = {
+static const struct pci_device_id pci_id[] = {
{
PCI_DEVICE(PCI_VENDOR_ID_AMD, 0x2096),
.class =(PCI_CLASS_SERIAL_USB 8) | 0xfe,
--
1.7.10.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: Need help to support USB3.0 HID Keyboard device
On Tuesday 26 November 2013 09:40 PM, Greg KH wrote: On Tue, Nov 26, 2013 at 03:26:04PM +0530, Bhavik Kothari wrote: On Friday 22 November 2013 10:25 PM, Greg KH wrote: On Fri, Nov 22, 2013 at 04:47:10PM +0530, Bhavik Kothari wrote: Hi, I have been working on USB3.0 device driver and wanted to support USB3.0 HID (keyboard). To support HID Keyboard device, I have made below Interface descriptor: Interface Descriptor with alternate settings 0: bLength = 0x9; bDescriptorType = 0x4 (USB_DT_INTERFACE); bInterfaceNumber = 0x0; bAlternateSetting = 0x0; bNumEndpoints = 0x0; bInterfaceClass = (0x3) USB_CLASS_HID; bInterfaceSubClass = 0x0; bInterfaceProtocol = 0x1 (keyboard); iInterface = 0x0; Interface Descriptor with alternate settings 1 along with Super speed endpoints: bLength = 0x9; bDescriptorType = 0x4 (USB_DT_INTERFACE); bInterfaceNumber = 0x0; bAlternateSetting = 0x1; bNumEndpoints = 0x2; (One for EP IN Interrupt and other for EP OUT Interrupt) bInterfaceClass = (0x3) USB_CLASS_HID; bInterfaceSubClass = 0x0; bInterfaceProtocol = 0x1 (keyboard); iInterface = 0x0; However, when xHCI does set_config at that time Interface zero and alternate setting is zero, it never does set_interface with interface zero and alternate setting one, hence host does not detect HID device. So, would you please assist me that what I have to do, so host does set interface with alternate setting one. It's up to a userspace program to switch to the alternate interface, right? The OS can't just know to do that without some type of interaction from you. Have you run your device under the USB verification test suite for Windows? I suggest you do that first, to ensure the firmware is working properly before worrying about how Linux is handling the device. thanks, greg k-h . Hi Greg, Yes, I have run USB3.0 device with USB verification test suite (USB3.0 CV) for Windows, and it passes all test points. However, with same implementation, host does not issue set interface with alternate setting one. That sounds correct. I am not sure what to do either from device or Host side, so, Host (xHCI) issues set interface with interface number zero or any other with alternate setting one or more than zero (because alternate setting zero is alloted for control ep, if transfer type is periodic (Interrupt / Isochronous)) Can you please assist me on this, what should I do / implement? Did you read Alan's response to your questions? What about what he said to do? thanks, greg k-h Hi Greg / Alan, Yes, I have read Alan's response, and I have implemented the same way (Alternate setting is zero it has endpoints, and Endpoint max packet size is 64 bytes instead of 1024 bytes). Now, Windows CV gets passed Host detects HID (keyboard) driver too. Actually I wanted to know for a knowledge purpose, if I have multiple alternate settings then how Host should do set interface with alternate setting (other than zero) for periodic (Interrupt Isochronous) transfers. Thanks for your help Alan. Thanks, Bhavik Kothari -- 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 v3 5/9] usb: gadget: s3c-hsotg: use generic phy_init()/phy_exit() support
On Thursday 28 November 2013 04:06 AM, Matt Porter wrote: On Wed, Nov 27, 2013 at 12:13:25PM -0500, Matt Porter wrote: On Tue, Nov 26, 2013 at 03:53:32PM +0530, Kishon Vijay Abraham I wrote: Hi, On Monday 25 November 2013 11:46 PM, Matt Porter wrote: If a generic phy is present, call phy_init()/phy_exit(). This supports generic phys that must be soft reset before power on. Signed-off-by: Matt Porter matt.por...@linaro.org --- drivers/usb/gadget/s3c-hsotg.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c index da3879b..8dfe33f 100644 --- a/drivers/usb/gadget/s3c-hsotg.c +++ b/drivers/usb/gadget/s3c-hsotg.c @@ -3622,6 +3622,9 @@ static int s3c_hsotg_probe(struct platform_device *pdev) goto err_supplies; } + if (hsotg-phy) IS_ERR? If your phy_get fails *phy* will have a error value.. Yes, thanks. I'll fix these and also note that the same issue exists in Kamil's patch for these same hsotg-phy conditional uses. I'll work with Kamil to either get those addressed there or in a follow on fix. I spoke too soon. If devm_phy_get fails, we don't set hsotg-phy and probe defer thus not reaching this point. Since hsotg-phy is either NULL or a valid struct phy *, this is correct as is throughout the driver. + phy_init(hsotg-phy); + /* usb phy enable */ s3c_hsotg_phy_enable(hsotg); @@ -3715,6 +3718,8 @@ static int s3c_hsotg_remove(struct platform_device *pdev) } s3c_hsotg_phy_disable(hsotg); + if (hsotg-phy) same here. Ok. Same above, this will be NULL on failure (but is only applicable at this point on the platform data path. Ah ok.. Btw where is phy_get being called? Is it not part of this series? Thanks Kishon -Matt -- 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: VIA chipset not supported by xhci drivers?
On Wed, Nov 27, 2013 at 03:00:40PM -0700, Philip Prindeville wrote: I wasn’t able to get the 7-port Orico controller working, so I swapped it out for a 4-port (single chip) Anker instead. $ sudo lspci -v -s 03:00.0 03:00.0 USB controller: VIA Technologies, Inc. VL80x xHCI USB 3.0 Controller (rev 03) (prog-if 30 [XHCI]) Subsystem: VIA Technologies, Inc. VL80x xHCI USB 3.0 Controller Flags: bus master, fast devsel, latency 0, IRQ 43 Memory at fbdff000 (32-bit, non-prefetchable) [size=4K] Capabilities: [80] Power Management version 3 Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [c4] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Kernel driver in use: xhci_hcd See the xhci_hcd driver properly binds to this, it goes off of the PCI class codes, not the product id. This time when I tried to plug in a Western Digital Passport drive, I got: Nov 26 15:07:27 builder kernel: [864975.137714] usb 9-1: Device not responding to set address. Nov 26 15:07:27 builder kernel: [864975.338699] usb 9-1: Device not responding to set address. Nov 26 15:07:28 builder kernel: [864975.539506] usb 9-1: device not accepting address 43, error -71 Nov 26 15:07:28 builder kernel: [864976.293815] usb 9-1: Device not responding to set address. Nov 26 15:07:29 builder kernel: [864976.494778] usb 9-1: Device not responding to set address. Nov 26 15:07:29 builder kernel: [864976.695594] usb 9-1: device not accepting address 45, error -71 ... Nov 26 15:09:07 builder kernel: [865074.813213] usb 9-1: Device not responding to set address. Nov 26 15:09:07 builder kernel: [865075.014135] usb 9-1: Device not responding to set address. Nov 26 15:09:07 builder kernel: [865075.214942] usb 9-1: device not accepting address 89, error -71 Nov 26 15:09:08 builder kernel: [865075.969269] usb 9-1: Device not responding to set address. Nov 26 15:09:08 builder kernel: [865076.170220] usb 9-1: Device not responding to set address. Nov 26 15:09:09 builder kernel: [865076.371024] usb 9-1: device not accepting address 91, error -71 But that's not good at all. Does 3.12 work better for you? 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
Re: [PATCH v2 2/2] usb: chipidea: usbmisc: Add support for i.MX51 CPU
Hello.
On Tue, Nov 26, 2013 at 07:36:50PM +0400, Alexander Shiyan wrote:
This adds i.MX51 as the next user of the usbmisc driver.
Functionality is similar to i.MX53, so at this stage simply
reuse existing i.MX53 calls.
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
---
drivers/usb/chipidea/usbmisc_imx.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index 4381c5a6..cd061ab 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -204,6 +204,10 @@ static const struct of_device_id usbmisc_imx_dt_ids[]
= {
.data = imx27_usbmisc_ops,
},
{
+ .compatible = fsl,imx51-usbmisc,
+ .data = imx53_usbmisc_ops,
If it simply uses imx53 ops, why do we need to introduce a new
compatible?
This has been discussed here:
http://www.spinics.net/lists/linux-usb/msg97502.html
Additionally, fsl,imx51-usbmisc string already present in imx51.dtsi.
Thanks.
---
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
[PATCH 7/8] usb/gadget: f_uvc: use usb_gstrings_attach
Attach strings to gadget with usb_strings_attach.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/f_uvc.c | 29 -
1 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index fcf398a..9e1deff 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -796,6 +796,7 @@ uvc_function_bind(struct usb_configuration *c, struct
usb_function *f)
{
struct usb_composite_dev *cdev = c-cdev;
struct uvc_device *uvc = to_uvc(f);
+ struct usb_string *us;
unsigned int max_packet_mult;
unsigned int max_packet_size;
struct usb_ep *ep;
@@ -871,22 +872,18 @@ uvc_function_bind(struct usb_configuration *c, struct
usb_function *f)
uvc_hs_streaming_ep.bEndpointAddress = uvc-video.ep-address;
uvc_ss_streaming_ep.bEndpointAddress = uvc-video.ep-address;
- /* String descriptors are global, we only need to allocate string IDs
-* for the first UVC function. UVC functions beyond the first (if any)
-* will reuse the same IDs.
-*/
- if (uvc_en_us_strings[UVC_STRING_CONTROL_IDX].id == 0) {
- ret = usb_string_ids_tab(c-cdev, uvc_en_us_strings);
- if (ret)
- goto error;
- uvc_iad.iFunction =
- uvc_en_us_strings[UVC_STRING_CONTROL_IDX].id;
- uvc_control_intf.iInterface =
- uvc_en_us_strings[UVC_STRING_CONTROL_IDX].id;
- ret = uvc_en_us_strings[UVC_STRING_STREAMING_IDX].id;
- uvc_streaming_intf_alt0.iInterface = ret;
- uvc_streaming_intf_alt1.iInterface = ret;
+ us = usb_gstrings_attach(cdev, uvc_function_strings,
+ARRAY_SIZE(uvc_en_us_strings));
+ if (IS_ERR(us)) {
+ ret = PTR_ERR(us);
+ goto error;
}
+ uvc_iad.iFunction = us[UVC_STRING_CONTROL_IDX].id;
+ uvc_control_intf.iInterface = us[UVC_STRING_CONTROL_IDX].id;
+ ret = us[UVC_STRING_STREAMING_IDX].id;
+ uvc_streaming_intf_alt0.iInterface = ret;
+ uvc_streaming_intf_alt1.iInterface = ret;
+
/* Allocate interface IDs. */
if ((ret = usb_interface_id(c, f)) 0)
@@ -1009,7 +1006,6 @@ static void uvc_unbind(struct usb_configuration *c,
struct usb_function *f)
uvc-control_ep-driver_data = NULL;
uvc-video.ep-driver_data = NULL;
- uvc_en_us_strings[UVC_STRING_CONTROL_IDX].id = 0;
usb_ep_free_request(cdev-gadget-ep0, uvc-control_req);
kfree(uvc-control_buf);
@@ -1034,7 +1030,6 @@ struct usb_function *uvc_alloc(struct
usb_function_instance *fi)
/* Register the function. */
uvc-func.name = uvc;
- uvc-func.strings = uvc_function_strings;
uvc-func.bind = uvc_function_bind;
uvc-func.unbind = uvc_unbind;
uvc-func.get_alt = uvc_function_get_alt;
--
1.7.0.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 1/8] usb/gadget: uvc: move descriptors to their only user
A bunch of descriptors is defined in webcam.c. They are used only
by f_uvc. Move them to their only user.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/f_uvc.c | 271 +++
drivers/usb/gadget/f_uvc.h |7 +-
drivers/usb/gadget/webcam.c | 243 +--
3 files changed, 252 insertions(+), 269 deletions(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index e2a1f50..ac0ac82 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -29,21 +29,255 @@
#include uvc.h
unsigned int uvc_gadget_trace_param;
+DECLARE_UVC_HEADER_DESCRIPTOR(1);
+
+static const struct UVC_HEADER_DESCRIPTOR(1) uvc_control_header = {
+ .bLength= UVC_DT_HEADER_SIZE(1),
+ .bDescriptorType= USB_DT_CS_INTERFACE,
+ .bDescriptorSubType = UVC_VC_HEADER,
+ .bcdUVC = cpu_to_le16(0x0100),
+ .wTotalLength = 0, /* dynamic */
+ .dwClockFrequency = cpu_to_le32(4800),
+ .bInCollection = 0, /* dynamic */
+ .baInterfaceNr[0] = 0, /* dynamic */
+};
+
+static const struct uvc_camera_terminal_descriptor uvc_camera_terminal = {
+ .bLength= UVC_DT_CAMERA_TERMINAL_SIZE(3),
+ .bDescriptorType= USB_DT_CS_INTERFACE,
+ .bDescriptorSubType = UVC_VC_INPUT_TERMINAL,
+ .bTerminalID= 1,
+ .wTerminalType = cpu_to_le16(0x0201),
+ .bAssocTerminal = 0,
+ .iTerminal = 0,
+ .wObjectiveFocalLengthMin = cpu_to_le16(0),
+ .wObjectiveFocalLengthMax = cpu_to_le16(0),
+ .wOcularFocalLength = cpu_to_le16(0),
+ .bControlSize = 3,
+ .bmControls[0] = 2,
+ .bmControls[1] = 0,
+ .bmControls[2] = 0,
+};
+
+static const struct uvc_processing_unit_descriptor uvc_processing = {
+ .bLength= UVC_DT_PROCESSING_UNIT_SIZE(2),
+ .bDescriptorType= USB_DT_CS_INTERFACE,
+ .bDescriptorSubType = UVC_VC_PROCESSING_UNIT,
+ .bUnitID= 2,
+ .bSourceID = 1,
+ .wMaxMultiplier = cpu_to_le16(16*1024),
+ .bControlSize = 2,
+ .bmControls[0] = 1,
+ .bmControls[1] = 0,
+ .iProcessing= 0,
+};
+
+static const struct uvc_output_terminal_descriptor uvc_output_terminal = {
+ .bLength= UVC_DT_OUTPUT_TERMINAL_SIZE,
+ .bDescriptorType= USB_DT_CS_INTERFACE,
+ .bDescriptorSubType = UVC_VC_OUTPUT_TERMINAL,
+ .bTerminalID= 3,
+ .wTerminalType = cpu_to_le16(0x0101),
+ .bAssocTerminal = 0,
+ .bSourceID = 2,
+ .iTerminal = 0,
+};
+
+DECLARE_UVC_INPUT_HEADER_DESCRIPTOR(1, 2);
+
+static const struct UVC_INPUT_HEADER_DESCRIPTOR(1, 2) uvc_input_header = {
+ .bLength= UVC_DT_INPUT_HEADER_SIZE(1, 2),
+ .bDescriptorType= USB_DT_CS_INTERFACE,
+ .bDescriptorSubType = UVC_VS_INPUT_HEADER,
+ .bNumFormats= 2,
+ .wTotalLength = 0, /* dynamic */
+ .bEndpointAddress = 0, /* dynamic */
+ .bmInfo = 0,
+ .bTerminalLink = 3,
+ .bStillCaptureMethod= 0,
+ .bTriggerSupport= 0,
+ .bTriggerUsage = 0,
+ .bControlSize = 1,
+ .bmaControls[0][0] = 0,
+ .bmaControls[1][0] = 4,
+};
+
+static const struct uvc_format_uncompressed uvc_format_yuv = {
+ .bLength= UVC_DT_FORMAT_UNCOMPRESSED_SIZE,
+ .bDescriptorType= USB_DT_CS_INTERFACE,
+ .bDescriptorSubType = UVC_VS_FORMAT_UNCOMPRESSED,
+ .bFormatIndex = 1,
+ .bNumFrameDescriptors = 2,
+ .guidFormat =
+ { 'Y', 'U', 'Y', '2', 0x00, 0x00, 0x10, 0x00,
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71},
+ .bBitsPerPixel = 16,
+ .bDefaultFrameIndex = 1,
+ .bAspectRatioX = 0,
+ .bAspectRatioY = 0,
+ .bmInterfaceFlags = 0,
+ .bCopyProtect = 0,
+};
+
+DECLARE_UVC_FRAME_UNCOMPRESSED(1);
+DECLARE_UVC_FRAME_UNCOMPRESSED(3);
+
+static const struct UVC_FRAME_UNCOMPRESSED(3) uvc_frame_yuv_360p = {
+ .bLength= UVC_DT_FRAME_UNCOMPRESSED_SIZE(3),
+ .bDescriptorType= USB_DT_CS_INTERFACE,
+ .bDescriptorSubType = UVC_VS_FRAME_UNCOMPRESSED,
+ .bFrameIndex= 1,
+ .bmCapabilities = 0,
+ .wWidth = cpu_to_le16(640),
+ .wHeight= cpu_to_le16(360),
+ .dwMinBitRate =
[PATCH 3/8] usb/gadget: uvc: separately compile some components of f_uvc
Compile uvc_queue, uvc_v4l2, uvc_video separately so that later they can
be all combined in a separately compiled f_uvc.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/Makefile|2 +-
drivers/usb/gadget/f_uvc.c |2 +
drivers/usb/gadget/f_uvc.h |8 +++
drivers/usb/gadget/uvc.h |1 +
drivers/usb/gadget/uvc_queue.c | 42 +++
drivers/usb/gadget/uvc_queue.h | 35 +
drivers/usb/gadget/uvc_v4l2.c |4 ++-
drivers/usb/gadget/uvc_v4l2.h | 21
drivers/usb/gadget/uvc_video.c | 10 +++-
drivers/usb/gadget/uvc_video.h | 24 ++
drivers/usb/gadget/webcam.c|6 +
11 files changed, 120 insertions(+), 35 deletions(-)
create mode 100644 drivers/usb/gadget/uvc_v4l2.h
create mode 100644 drivers/usb/gadget/uvc_video.h
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index f1af396..75bb72e 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -80,7 +80,7 @@ g_multi-y := multi.o
g_hid-y:= hid.o
g_dbgp-y := dbgp.o
g_nokia-y := nokia.o
-g_webcam-y := webcam.o
+g_webcam-y := webcam.o uvc_queue.o uvc_v4l2.o uvc_video.o
g_ncm-y:= ncm.o
g_acm_ms-y := acm_ms.o
g_tcm_usb_gadget-y := tcm_usb_gadget.o
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index aecd2db..501f5cc 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -27,6 +27,8 @@
#include media/v4l2-event.h
#include uvc.h
+#include uvc_video.h
+#include uvc_v4l2.h
unsigned int uvc_gadget_trace_param;
unsigned int streaming_interval;
diff --git a/drivers/usb/gadget/f_uvc.h b/drivers/usb/gadget/f_uvc.h
index 6732c0d..b27e05f 100644
--- a/drivers/usb/gadget/f_uvc.h
+++ b/drivers/usb/gadget/f_uvc.h
@@ -16,6 +16,14 @@
#include linux/usb/composite.h
#include linux/usb/video.h
+#include uvc.h
+
+void uvc_function_setup_continue(struct uvc_device *uvc);
+
+void uvc_function_connect(struct uvc_device *uvc);
+
+void uvc_function_disconnect(struct uvc_device *uvc);
+
int uvc_bind_config(struct usb_configuration *c,
unsigned int streaming_interval_webcam,
unsigned int streaming_maxpacket_webcam,
diff --git a/drivers/usb/gadget/uvc.h b/drivers/usb/gadget/uvc.h
index 7a9111d..33e82b9 100644
--- a/drivers/usb/gadget/uvc.h
+++ b/drivers/usb/gadget/uvc.h
@@ -58,6 +58,7 @@ struct uvc_event
#include linux/version.h
#include media/v4l2-fh.h
#include media/v4l2-device.h
+#include linux/usb/composite.h
#include uvc_queue.h
diff --git a/drivers/usb/gadget/uvc_queue.c b/drivers/usb/gadget/uvc_queue.c
index 0bb5d50..aa25186 100644
--- a/drivers/usb/gadget/uvc_queue.c
+++ b/drivers/usb/gadget/uvc_queue.c
@@ -125,8 +125,7 @@ static struct vb2_ops uvc_queue_qops = {
.wait_finish = uvc_wait_finish,
};
-static int uvc_queue_init(struct uvc_video_queue *queue,
- enum v4l2_buf_type type)
+int uvc_queue_init(struct uvc_video_queue *queue, enum v4l2_buf_type type)
{
int ret;
@@ -151,7 +150,7 @@ static int uvc_queue_init(struct uvc_video_queue *queue,
/*
* Free the video buffers.
*/
-static void uvc_free_buffers(struct uvc_video_queue *queue)
+void uvc_free_buffers(struct uvc_video_queue *queue)
{
mutex_lock(queue-mutex);
vb2_queue_release(queue-queue);
@@ -161,8 +160,8 @@ static void uvc_free_buffers(struct uvc_video_queue *queue)
/*
* Allocate the video buffers.
*/
-static int uvc_alloc_buffers(struct uvc_video_queue *queue,
-struct v4l2_requestbuffers *rb)
+int uvc_alloc_buffers(struct uvc_video_queue *queue,
+ struct v4l2_requestbuffers *rb)
{
int ret;
@@ -173,8 +172,8 @@ static int uvc_alloc_buffers(struct uvc_video_queue *queue,
return ret ? ret : rb-count;
}
-static int uvc_query_buffer(struct uvc_video_queue *queue,
- struct v4l2_buffer *buf)
+int uvc_query_buffer(struct uvc_video_queue *queue,
+struct v4l2_buffer *buf)
{
int ret;
@@ -185,8 +184,8 @@ static int uvc_query_buffer(struct uvc_video_queue *queue,
return ret;
}
-static int uvc_queue_buffer(struct uvc_video_queue *queue,
- struct v4l2_buffer *buf)
+int uvc_queue_buffer(struct uvc_video_queue *queue,
+struct v4l2_buffer *buf)
{
unsigned long flags;
int ret;
@@ -210,8 +209,8 @@ done:
* Dequeue a video buffer. If nonblocking is false, block until a buffer is
* available.
*/
-static int uvc_dequeue_buffer(struct uvc_video_queue *queue,
-
[PATCH 8/8] usb/gadget: f_uvc: add configfs support
Add support for using uvc as a component of a composite gadget
set up with configfs.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Documentation/ABI/testing/configfs-usb-gadget-uvc | 11 +
drivers/usb/gadget/Kconfig| 12 +
drivers/usb/gadget/f_uvc.c| 229 +
drivers/usb/gadget/u_uvc.h|9 +
4 files changed, 261 insertions(+), 0 deletions(-)
create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-uvc
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc
b/Documentation/ABI/testing/configfs-usb-gadget-uvc
new file mode 100644
index 000..e9f9663
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc
@@ -0,0 +1,11 @@
+What: /config/usb-gadget/gadget/functions/uvc.name
+Date: Nov 2013
+KenelVersion: 3.13
+Description:
+ The attributes:
+
+ streaming_interval - 1..16
+ streaming_maxpacket - 1..1023 (fs), 1..3072 (hs/ss)
+ streaming_maxburst - 0..15 (ss only)
+ trace - trace level bitmask,
+ common for all uvc instances
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index c8a72e0..1e863ad 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -692,6 +692,18 @@ config USB_CONFIGFS_MASS_STORAGE
device (in much the same way as the loop device driver),
specified as a module parameter or sysfs option.
+config USB_CONFIGFS_F_UVC
+ boolean USB Webcam function
+ depends on USB_CONFIGFS
+ depends on VIDEO_DEV
+ select USB_LIBCOMPOSITE
+ select VIDEOBUF2_VMALLOC
+ select USB_F_UVC
+ help
+ The Webcam function acts as a composite USB Audio and Video Class
+ device. It provides a userspace API to process UVC control requests
+ and stream video data to the host.
+
config USB_ZERO
tristate Gadget Zero (DEVELOPMENT)
select USB_LIBCOMPOSITE
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index 9e1deff..4df877b 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -961,6 +961,220 @@ error:
return ret;
}
+static inline struct f_uvc_opts *to_f_uvc_opts(struct config_item *item)
+{
+ return container_of(to_config_group(item), struct f_uvc_opts,
+ func_inst.group);
+}
+
+CONFIGFS_ATTR_STRUCT(f_uvc_opts);
+CONFIGFS_ATTR_OPS(f_uvc_opts);
+
+static void uvc_attr_release(struct config_item *item)
+{
+ struct f_uvc_opts *opts = to_f_uvc_opts(item);
+
+ usb_put_function_instance(opts-func_inst);
+}
+
+static struct configfs_item_operations uvc_item_ops = {
+ .release= uvc_attr_release,
+ .show_attribute = f_uvc_opts_attr_show,
+ .store_attribute= f_uvc_opts_attr_store,
+};
+
+static ssize_t uvc_opts_trace_show(struct f_uvc_opts *opts, char *page)
+{
+ int result;
+
+ mutex_lock(opts-lock);
+ result = sprintf(page, %d, uvc_gadget_trace_param);
+ mutex_unlock(opts-lock);
+
+ return result;
+}
+
+static ssize_t uvc_opts_trace_store(struct f_uvc_opts *opts,
+ const char *page, size_t len)
+{
+ int ret;
+ u32 num;
+
+ mutex_lock(opts-lock);
+ if (opts-refcnt) {
+ ret = -EBUSY;
+ goto end;
+ }
+
+ ret = kstrtou32(page, 0, num);
+ if (ret)
+ goto end;
+
+ uvc_gadget_trace_param = num;
+ ret = len;
+
+end:
+ mutex_unlock(opts-lock);
+ return ret;
+}
+
+static struct f_uvc_opts_attribute f_uvc_opts_trace =
+ __CONFIGFS_ATTR(trace, S_IRUGO | S_IWUSR, uvc_opts_trace_show,
+ uvc_opts_trace_store);
+
+static ssize_t uvc_opts_streaming_interval_show(struct f_uvc_opts *opts,
+ char *page)
+{
+ int result;
+
+ mutex_lock(opts-lock);
+ result = sprintf(page, %d, opts-streaming_interval);
+ mutex_unlock(opts-lock);
+ result = 0;
+
+ return result;
+}
+
+static ssize_t uvc_opts_streaming_interval_store(struct f_uvc_opts *opts,
+const char *page, size_t len)
+{
+ int ret;
+ u8 num;
+
+ mutex_lock(opts-lock);
+ if (opts-refcnt) {
+ ret = -EBUSY;
+ goto end;
+ }
+
+ ret = kstrtou8(page, 0, num);
+ if (ret)
+ goto end;
+
+ if (num 16) {
+ ret = -EINVAL;
+ goto end;
+ }
+ opts-streaming_interval = num;
+ ret = len;
+
+end:
+ mutex_unlock(opts-lock);
+ return ret;
+}
+
+static struct f_uvc_opts_attribute f_uvc_opts_streaming_interval =
[PATCH 5/8] usb/gadget: webcam: convert webcam to new interface of f_uvc
Use the new function interface of f_uvc.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/Kconfig |1 +
drivers/usb/gadget/Makefile |4 +-
drivers/usb/gadget/f_uvc.c |4 ---
drivers/usb/gadget/webcam.c | 46 +-
4 files changed, 35 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 6032e84..c8a72e0 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -1144,6 +1144,7 @@ config USB_G_WEBCAM
depends on VIDEO_DEV
select USB_LIBCOMPOSITE
select VIDEOBUF2_VMALLOC
+ select USB_F_UVC
help
The Webcam Gadget acts as a composite USB Audio and Video Class
device. It provides a userspace API to process UVC control requests
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index d2aeea3..eac0e08 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -63,7 +63,7 @@ usb_f_rndis-y := f_rndis.o
obj-$(CONFIG_USB_F_RNDIS) += usb_f_rndis.o
usb_f_mass_storage-y := f_mass_storage.o storage_common.o
obj-$(CONFIG_USB_F_MASS_STORAGE)+= usb_f_mass_storage.o
-usb_f_uvc-u:= f_uvc.o
+usb_f_uvc-y:= f_uvc.o uvc_queue.o uvc_v4l2.o uvc_video.o
obj-$(CONFIG_USB_F_UVC)+= usb_f_uvc.o
#
@@ -82,7 +82,7 @@ g_multi-y := multi.o
g_hid-y:= hid.o
g_dbgp-y := dbgp.o
g_nokia-y := nokia.o
-g_webcam-y := webcam.o uvc_queue.o uvc_v4l2.o uvc_video.o
+g_webcam-y := webcam.o
g_ncm-y:= ncm.o
g_acm_ms-y := acm_ms.o
g_tcm_usb_gadget-y := tcm_usb_gadget.o
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index 647713f..cadc248 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -1067,10 +1067,6 @@ uvc_bind_config(struct usb_configuration *c,
uvc-state = UVC_STATE_DISCONNECTED;
- streaming_interval = streaming_interval_webcam;
- streaming_maxpacket = streaming_maxpacket_webcam;
- streaming_maxburst = streaming_maxburst_webcam;
- uvc_gadget_trace_param = uvc_gadget_trace_webcam;
uvc-desc.fs_control = uvc_fs_control_cls;
uvc-desc.ss_control = uvc_ss_control_cls;
diff --git a/drivers/usb/gadget/webcam.c b/drivers/usb/gadget/webcam.c
index 994e386..a9fdee5 100644
--- a/drivers/usb/gadget/webcam.c
+++ b/drivers/usb/gadget/webcam.c
@@ -15,15 +15,7 @@
#include linux/module.h
#include linux/usb/video.h
-/*
- * Kbuild is not very cooperative with respect to linking separately
- * compiled library objects into one module. So for now we won't use
- * separate compilation ... ensuring init/exit sections work to shrink
- * the runtime footprint, and giving us at least some parts of what
- * a gcc --combine ... part1.c part2.c part3.c ... build would.
- */
-#define USBF_UVC_INCLUDED
-#include f_uvc.c
+#include u_uvc.h
USB_GADGET_COMPOSITE_OPTIONS();
@@ -82,6 +74,9 @@ static struct usb_gadget_strings *webcam_device_strings[] = {
NULL,
};
+static struct usb_function_instance *fi_uvc;
+static struct usb_function *f_uvc;
+
static struct usb_device_descriptor webcam_device_descriptor = {
.bLength= USB_DT_DEVICE_SIZE,
.bDescriptorType= USB_DT_DEVICE,
@@ -106,10 +101,17 @@ static struct usb_device_descriptor
webcam_device_descriptor = {
static int __init
webcam_config_bind(struct usb_configuration *c)
{
- return uvc_bind_config(c, streaming_interval_webcam,
- streaming_maxpacket_webcam,
- streaming_maxburst_webcam,
- uvc_gadget_trace_param_webcam);
+ int status = 0;
+
+ f_uvc = usb_get_function(fi_uvc);
+ if (IS_ERR(f_uvc))
+ return PTR_ERR(f_uvc);
+
+ status = usb_add_function(c, f_uvc);
+ if (status 0)
+ usb_put_function(f_uvc);
+
+ return status;
}
static struct usb_configuration webcam_config_driver = {
@@ -123,14 +125,30 @@ static struct usb_configuration webcam_config_driver = {
static int /* __init_or_exit */
webcam_unbind(struct usb_composite_dev *cdev)
{
+ if (!IS_ERR_OR_NULL(f_uvc))
+ usb_put_function(f_uvc);
+ if (!IS_ERR_OR_NULL(fi_uvc))
+ usb_put_function_instance(fi_uvc);
return 0;
}
static int __init
webcam_bind(struct usb_composite_dev *cdev)
{
+ struct f_uvc_opts *uvc_opts;
int ret;
+ fi_uvc = usb_get_function_instance(uvc);
+ if (IS_ERR(fi_uvc))
+ return PTR_ERR(fi_uvc);
+
+ uvc_opts = container_of(fi_uvc, struct f_uvc_opts,
[PATCH 6/8] usb/gadget: f_uvc: remove compatibility layer
There are no users of the old interface left. Remove it.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/f_uvc.c | 129
1 files changed, 0 insertions(+), 129 deletions(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index cadc248..fcf398a 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -439,16 +439,12 @@ static const struct usb_descriptor_header * const
uvc_ss_streaming[] = {
NULL,
};
-#ifndef USBF_UVC_INCLUDED
-
void uvc_set_trace_param(unsigned int uvc_gadget_trace_param_webcam)
{
uvc_gadget_trace_param = uvc_gadget_trace_param_webcam;
}
EXPORT_SYMBOL(uvc_set_trace_param);
-#endif
-
/* --
* Control requests
*/
@@ -808,44 +804,6 @@ uvc_function_bind(struct usb_configuration *c, struct
usb_function *f)
INFO(cdev, uvc_function_bind\n);
-#ifdef USBF_UVC_INCLUDED
- /* Sanity check the streaming endpoint module parameters.
-*/
- streaming_interval = clamp(streaming_interval, 1U, 16U);
- streaming_maxpacket = clamp(streaming_maxpacket, 1U, 3072U);
- streaming_maxburst = min(streaming_maxburst, 15U);
-
- /* Fill in the FS/HS/SS Video Streaming specific descriptors from the
-* module parameters.
-*
-* NOTE: We assume that the user knows what they are doing and won't
-* give parameters that their UDC doesn't support.
-*/
- if (streaming_maxpacket = 1024) {
- max_packet_mult = 1;
- max_packet_size = streaming_maxpacket;
- } else if (streaming_maxpacket = 2048) {
- max_packet_mult = 2;
- max_packet_size = streaming_maxpacket / 2;
- } else {
- max_packet_mult = 3;
- max_packet_size = streaming_maxpacket / 3;
- }
-
- uvc_fs_streaming_ep.wMaxPacketSize = min(streaming_maxpacket, 1023U);
- uvc_fs_streaming_ep.bInterval = streaming_interval;
-
- uvc_hs_streaming_ep.wMaxPacketSize = max_packet_size;
- uvc_hs_streaming_ep.wMaxPacketSize |= ((max_packet_mult - 1) 11);
- uvc_hs_streaming_ep.bInterval = streaming_interval;
-
- uvc_ss_streaming_ep.wMaxPacketSize = max_packet_size;
- uvc_ss_streaming_ep.bInterval = streaming_interval;
- uvc_ss_streaming_comp.bmAttributes = max_packet_mult - 1;
- uvc_ss_streaming_comp.bMaxBurst = streaming_maxburst;
- uvc_ss_streaming_comp.wBytesPerInterval =
- max_packet_size * max_packet_mult * streaming_maxburst;
-#else
opts = container_of(f-fi, struct f_uvc_opts, func_inst);
/* Sanity check the streaming endpoint module parameters.
*/
@@ -884,7 +842,6 @@ uvc_function_bind(struct usb_configuration *c, struct
usb_function *f)
uvc_ss_streaming_comp.bMaxBurst = opts-streaming_maxburst;
uvc_ss_streaming_comp.wBytesPerInterval =
max_packet_size * max_packet_mult * opts-streaming_maxburst;
-#endif
/* Allocate endpoints. */
ep = usb_ep_autoconfig(cdev-gadget, uvc_control_ep);
@@ -1011,88 +968,6 @@ error:
* USB gadget function
*/
-#ifdef USBF_UVC_INCLUDED
-
-static void
-uvc_old_function_unbind(struct usb_configuration *c, struct usb_function *f)
-{
- struct usb_composite_dev *cdev = c-cdev;
- struct uvc_device *uvc = to_uvc(f);
-
- INFO(cdev, uvc_function_unbind\n);
-
- video_unregister_device(uvc-vdev);
- v4l2_device_unregister(uvc-v4l2_dev);
- uvc-control_ep-driver_data = NULL;
- uvc-video.ep-driver_data = NULL;
-
- uvc_en_us_strings[UVC_STRING_CONTROL_IDX].id = 0;
- usb_ep_free_request(cdev-gadget-ep0, uvc-control_req);
- kfree(uvc-control_buf);
-
- usb_free_all_descriptors(f);
-
- kfree(uvc);
-}
-
-/**
- * uvc_bind_config - add a UVC function to a configuration
- * @c: the configuration to support the UVC instance
- * Context: single threaded during gadget setup
- *
- * Returns zero on success, else negative errno.
- *
- * Caller must have called @uvc_setup(). Caller is also responsible for
- * calling @uvc_cleanup() before module unload.
- */
-int __init
-uvc_bind_config(struct usb_configuration *c,
- unsigned int streaming_interval_webcam,
- unsigned int streaming_maxpacket_webcam,
- unsigned int streaming_maxburst_webcam,
- unsigned int uvc_gadget_trace_webcam)
-{
- struct uvc_device *uvc;
- int ret = 0;
-
- /* TODO Check if the USB device controller supports the required
-* features.
-*/
- if (!gadget_is_dualspeed(c-cdev-gadget))
- return -EINVAL;
-
- uvc = kzalloc(sizeof(*uvc), GFP_KERNEL);
- if (uvc == NULL)
- return -ENOMEM;
-
- uvc-state =
[PATCH 4/8] usb/gadget: f_uvc: convert f_uvc to new function interface
Use the new function registration interface. It is required
in order to integrate configfs support.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/Kconfig |3 +
drivers/usb/gadget/Makefile |2 +
drivers/usb/gadget/f_uvc.c | 270 +++
drivers/usb/gadget/u_uvc.h | 32 +
drivers/usb/gadget/webcam.c |1 +
5 files changed, 232 insertions(+), 76 deletions(-)
create mode 100644 drivers/usb/gadget/u_uvc.h
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index a91e642..6032e84 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -542,6 +542,9 @@ config USB_F_RNDIS
config USB_F_MASS_STORAGE
tristate
+config USB_F_UVC
+ tristate
+
choice
tristate USB Gadget Drivers
default USB_ETH
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 75bb72e..d2aeea3 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -63,6 +63,8 @@ usb_f_rndis-y := f_rndis.o
obj-$(CONFIG_USB_F_RNDIS) += usb_f_rndis.o
usb_f_mass_storage-y := f_mass_storage.o storage_common.o
obj-$(CONFIG_USB_F_MASS_STORAGE)+= usb_f_mass_storage.o
+usb_f_uvc-u:= f_uvc.o
+obj-$(CONFIG_USB_F_UVC)+= usb_f_uvc.o
#
# USB gadget drivers
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index 501f5cc..647713f 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -11,6 +11,7 @@
*/
#include linux/kernel.h
+#include linux/module.h
#include linux/device.h
#include linux/errno.h
#include linux/fs.h
@@ -27,6 +28,7 @@
#include media/v4l2-event.h
#include uvc.h
+#include u_uvc.h
#include uvc_video.h
#include uvc_v4l2.h
@@ -304,7 +306,7 @@ static struct usb_gadget_strings *uvc_function_strings[] = {
#define UVC_STATUS_MAX_PACKET_SIZE 16 /* 16 bytes status */
-static struct usb_interface_assoc_descriptor uvc_iad __initdata = {
+static struct usb_interface_assoc_descriptor uvc_iad = {
.bLength= sizeof(uvc_iad),
.bDescriptorType= USB_DT_INTERFACE_ASSOCIATION,
.bFirstInterface= 0,
@@ -315,7 +317,7 @@ static struct usb_interface_assoc_descriptor uvc_iad
__initdata = {
.iFunction = 0,
};
-static struct usb_interface_descriptor uvc_control_intf __initdata = {
+static struct usb_interface_descriptor uvc_control_intf = {
.bLength= USB_DT_INTERFACE_SIZE,
.bDescriptorType= USB_DT_INTERFACE,
.bInterfaceNumber = UVC_INTF_VIDEO_CONTROL,
@@ -327,7 +329,7 @@ static struct usb_interface_descriptor uvc_control_intf
__initdata = {
.iInterface = 0,
};
-static struct usb_endpoint_descriptor uvc_control_ep __initdata = {
+static struct usb_endpoint_descriptor uvc_control_ep = {
.bLength= USB_DT_ENDPOINT_SIZE,
.bDescriptorType= USB_DT_ENDPOINT,
.bEndpointAddress = USB_DIR_IN,
@@ -336,7 +338,7 @@ static struct usb_endpoint_descriptor uvc_control_ep
__initdata = {
.bInterval = 8,
};
-static struct usb_ss_ep_comp_descriptor uvc_ss_control_comp __initdata = {
+static struct usb_ss_ep_comp_descriptor uvc_ss_control_comp = {
.bLength= sizeof(uvc_ss_control_comp),
.bDescriptorType= USB_DT_SS_ENDPOINT_COMP,
/* The following 3 values can be tweaked if necessary. */
@@ -345,14 +347,14 @@ static struct usb_ss_ep_comp_descriptor
uvc_ss_control_comp __initdata = {
.wBytesPerInterval = cpu_to_le16(UVC_STATUS_MAX_PACKET_SIZE),
};
-static struct uvc_control_endpoint_descriptor uvc_control_cs_ep __initdata = {
+static struct uvc_control_endpoint_descriptor uvc_control_cs_ep = {
.bLength= UVC_DT_CONTROL_ENDPOINT_SIZE,
.bDescriptorType= USB_DT_CS_ENDPOINT,
.bDescriptorSubType = UVC_EP_INTERRUPT,
.wMaxTransferSize = cpu_to_le16(UVC_STATUS_MAX_PACKET_SIZE),
};
-static struct usb_interface_descriptor uvc_streaming_intf_alt0 __initdata = {
+static struct usb_interface_descriptor uvc_streaming_intf_alt0 = {
.bLength= USB_DT_INTERFACE_SIZE,
.bDescriptorType= USB_DT_INTERFACE,
.bInterfaceNumber = UVC_INTF_VIDEO_STREAMING,
@@ -364,7 +366,7 @@ static struct usb_interface_descriptor
uvc_streaming_intf_alt0 __initdata = {
.iInterface = 0,
};
-static struct usb_interface_descriptor uvc_streaming_intf_alt1 __initdata = {
+static struct usb_interface_descriptor uvc_streaming_intf_alt1 = {
.bLength= USB_DT_INTERFACE_SIZE,
.bDescriptorType= USB_DT_INTERFACE,
.bInterfaceNumber = UVC_INTF_VIDEO_STREAMING,
@@ -376,7 +378,7
[PATCH 2/8] usb/gadget: uvc: move module parameters from f_uvc
When configfs support is integrated the future uvc function
module must not take any parameters. Move parameters to
webcam.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/f_uvc.c | 27 +--
drivers/usb/gadget/f_uvc.h |6 +-
drivers/usb/gadget/webcam.c | 27 ++-
3 files changed, 44 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index ac0ac82..aecd2db 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -29,6 +29,10 @@
#include uvc.h
unsigned int uvc_gadget_trace_param;
+unsigned int streaming_interval;
+unsigned int streaming_maxpacket;
+unsigned int streaming_maxburst;
+
DECLARE_UVC_HEADER_DESCRIPTOR(1);
static const struct UVC_HEADER_DESCRIPTOR(1) uvc_control_header = {
@@ -170,7 +174,6 @@ static const struct uvc_format_mjpeg uvc_format_mjpg = {
.bCopyProtect = 0,
};
-/*-*/
DECLARE_UVC_FRAME_MJPEG(1);
DECLARE_UVC_FRAME_MJPEG(3);
@@ -192,10 +195,6 @@ static const struct UVC_FRAME_MJPEG(3) uvc_frame_mjpg_360p
= {
.dwFrameInterval[2] = cpu_to_le32(500),
};
-/* module parameters specific to the Video streaming endpoint */
-static unsigned int streaming_interval = 1;
-module_param(streaming_interval, uint, S_IRUGO|S_IWUSR);
-MODULE_PARM_DESC(streaming_interval, 1 - 16);
static const struct UVC_FRAME_MJPEG(1) uvc_frame_mjpg_720p = {
.bLength= UVC_DT_FRAME_MJPEG_SIZE(1),
.bDescriptorType= USB_DT_CS_INTERFACE,
@@ -212,9 +211,6 @@ static const struct UVC_FRAME_MJPEG(1) uvc_frame_mjpg_720p
= {
.dwFrameInterval[0] = cpu_to_le32(500),
};
-static unsigned int streaming_maxpacket = 1024;
-module_param(streaming_maxpacket, uint, S_IRUGO|S_IWUSR);
-MODULE_PARM_DESC(streaming_maxpacket, 1 - 1023 (FS), 1 - 3072 (hs/ss));
static const struct uvc_color_matching_descriptor uvc_color_matching = {
.bLength= UVC_DT_COLOR_MATCHING_SIZE,
.bDescriptorType= USB_DT_CS_INTERFACE,
@@ -240,9 +236,6 @@ static const struct uvc_descriptor_header * const
uvc_ss_control_cls[] = {
NULL,
};
-static unsigned int streaming_maxburst;
-module_param(streaming_maxburst, uint, S_IRUGO|S_IWUSR);
-MODULE_PARM_DESC(streaming_maxburst, 0 - 15 (ss only));
static const struct uvc_descriptor_header * const uvc_fs_streaming_cls[] = {
(const struct uvc_descriptor_header *) uvc_input_header,
(const struct uvc_descriptor_header *) uvc_format_yuv,
@@ -978,7 +971,11 @@ error:
* calling @uvc_cleanup() before module unload.
*/
int __init
-uvc_bind_config(struct usb_configuration *c)
+uvc_bind_config(struct usb_configuration *c,
+ unsigned int streaming_interval_webcam,
+ unsigned int streaming_maxpacket_webcam,
+ unsigned int streaming_maxburst_webcam,
+ unsigned int uvc_gadget_trace_webcam)
{
struct uvc_device *uvc;
int ret = 0;
@@ -1016,6 +1013,10 @@ uvc_bind_config(struct usb_configuration *c)
uvc_ss_streaming_cls[0]-bDescriptorSubType != UVC_VS_INPUT_HEADER)
goto error;
+ streaming_interval = streaming_interval_webcam;
+ streaming_maxpacket = streaming_maxpacket_webcam;
+ streaming_maxburst = streaming_maxburst_webcam;
+ uvc_gadget_trace_param = uvc_gadget_trace_webcam;
uvc-desc.fs_control = uvc_fs_control_cls;
uvc-desc.ss_control = uvc_ss_control_cls;
uvc-desc.fs_streaming = uvc_fs_streaming_cls;
@@ -1060,6 +1061,4 @@ error:
return ret;
}
-module_param_named(trace, uvc_gadget_trace_param, uint, S_IRUGO|S_IWUSR);
-MODULE_PARM_DESC(trace, Trace level bitmask);
diff --git a/drivers/usb/gadget/f_uvc.h b/drivers/usb/gadget/f_uvc.h
index edfe772..6732c0d 100644
--- a/drivers/usb/gadget/f_uvc.h
+++ b/drivers/usb/gadget/f_uvc.h
@@ -16,7 +16,11 @@
#include linux/usb/composite.h
#include linux/usb/video.h
-int uvc_bind_config(struct usb_configuration *c);
+int uvc_bind_config(struct usb_configuration *c,
+ unsigned int streaming_interval_webcam,
+ unsigned int streaming_maxpacket_webcam,
+ unsigned int streaming_maxburst_webcam,
+ unsigned int uvc_gadget_trace_webcam);
#endif /* _F_UVC_H_ */
diff --git a/drivers/usb/gadget/webcam.c b/drivers/usb/gadget/webcam.c
index df809e7..6809dc2 100644
--- a/drivers/usb/gadget/webcam.c
+++ b/drivers/usb/gadget/webcam.c
@@ -29,6 +29,28 @@
#include f_uvc.c
USB_GADGET_COMPOSITE_OPTIONS();
+
+/*-*/
+
+/* module parameters specific to the Video streaming endpoint */
+static unsigned int streaming_interval_webcam = 1;
