Re: [PATCH v4 3/7] usb: chipidea: add otg id switch and vbus connect/disconnect detect
On Thu, Dec 27, 2012 at 08:21:55AM +0100, Marek Vasut wrote:
> Dear Peter Chen,
>
> [...]
> > +
> > +#define CI_VBUS_STABLE_TIMEOUT 500
>
> Shall we not change this to static const int instead ?
Is it a must?
I find the similar at drivers/usb/core/hub.c
2433 #define PORT_RESET_TRIES5
2434 #define SET_ADDRESS_TRIES 2
2435 #define GET_DESCRIPTOR_TRIES2
2436 #define SET_CONFIG_TRIES(2 * (use_both_schemes + 1))
2437 #define USE_NEW_SCHEME(i) ((i) / 2 == (int)old_scheme_first)
2438
2439 #define HUB_ROOT_RESET_TIME 50 /* times are in msec */
2440 #define HUB_SHORT_RESET_TIME10
2441 #define HUB_BH_RESET_TIME 50
2442 #define HUB_LONG_RESET_TIME 200
2443 #define HUB_RESET_TIMEOUT 500
>
> [...]
>
> > --- a/drivers/usb/chipidea/udc.c
> > +++ b/drivers/usb/chipidea/udc.c
> > @@ -1371,6 +1371,7 @@ static int ci13xxx_vbus_session(struct usb_gadget
> > *_gadget, int is_active) pm_runtime_get_sync(&_gadget->dev);
> > hw_device_reset(ci, USBMODE_CM_DC);
> > hw_device_state(ci, ci->ep0out->qh.dma);
> > + dev_dbg(ci->dev, "Connected to host\n");
> > } else {
> > hw_device_state(ci, 0);
> > if (ci->platdata->notify_event)
> > @@ -1378,6 +1379,7 @@ static int ci13xxx_vbus_session(struct usb_gadget
> > *_gadget, int is_active) CI13XXX_CONTROLLER_STOPPED_EVENT);
> > _gadget_stop_activity(&ci->gadget);
> > pm_runtime_put_sync(&_gadget->dev);
> > + dev_dbg(ci->dev, "disconnected from host\n");
>
> Keep the capital letters at the begining of the sentence consistent -- either
> start with capital D here or fix the capital C above.
Thanks, I will change "d" to "D".
>
> > }
> > }
>
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/7] usb: chipidea: add otg id switch and vbus connect/disconnect detect
Dear Peter Chen, > On Thu, Dec 27, 2012 at 08:21:55AM +0100, Marek Vasut wrote: > > Dear Peter Chen, > > > > [...] > > > > > + > > > +#define CI_VBUS_STABLE_TIMEOUT 500 > > > > Shall we not change this to static const int instead ? > > Is it a must? > I find the similar at drivers/usb/core/hub.c [...] No it's not. I was just pondering now that it's a local constant, it might just be like that. Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] usb: phy: samsung: Add support to set pmu isolation
Hi Russell,
On Thu, Dec 27, 2012 at 5:56 AM, Russell King - ARM Linux
wrote:
> On Wed, Dec 26, 2012 at 05:58:32PM +0530, Vivek Gautam wrote:
>> + if (!ret)
>> + sphy->phyctrl_pmureg = ioremap(reg[0], reg[1]);
>> +
>> + of_node_put(usbphy_pmu);
>> +
>> + if (IS_ERR_OR_NULL(sphy->phyctrl_pmureg)) {
>
> No. Learn what the error return values are from functions. Using the
> wrong ones is buggy. ioremap() only ever returns NULL on error. You
> must check against NULL, and not use the IS_ERR stuff.
>
True, i should have checked the things. :-(
ioremap() won't return error. Will amend this to check against NULL.
>> +/*
>> + * Set isolation here for phy.
>> + * SOCs control this by controlling corresponding PMU registers
>> + */
>> +static void samsung_usbphy_set_isolation(struct samsung_usbphy *sphy, int
>> on)
>> +{
>> + u32 reg;
>> + int en_mask;
>> +
>> + if (!sphy->phyctrl_pmureg) {
>> + dev_warn(sphy->dev, "Can't set pmu isolation\n");
>> + return;
>> + }
>> +
>> + reg = readl(sphy->phyctrl_pmureg);
>> +
>> + en_mask = sphy->drv_data->devphy_en_mask;
>> +
>> + if (on)
>> + writel(reg & ~en_mask, sphy->phyctrl_pmureg);
>> + else
>> + writel(reg | en_mask, sphy->phyctrl_pmureg);
>
> What guarantees that this read-modify-write sequence of this register safe?
> And, btw, this can't be optimised very well because of the barrier inside
> writel(). This would be better:
>
> if (on)
> reg &= ~en_mask;
> else
> reg |= en_mask;
>
> writel(reg, sphy->phyctrl_pmureg);
>
Sure will amend this.
A similar way suggested by Sylwester in the earlier mail in this thread:
reg = on ? reg & ~mask : reg | mask;
writel(reg, sphy->phyctrl_pmureg);
Does this look fine ?
>> +static inline struct samsung_usbphy_drvdata
>> +*samsung_usbphy_get_driver_data(struct platform_device *pdev)
>> {
>> if (pdev->dev.of_node) {
>> const struct of_device_id *match;
>> match = of_match_node(samsung_usbphy_dt_match,
>> pdev->dev.of_node);
>> - return (int) match->data;
>> + return (struct samsung_usbphy_drvdata *) match->data;
>
> match->data is a const void pointer. Is there a reason you need this
> cast here? What if you made the returned pointer from this function
> also const and fixed up all its users (no user should modify this
> data.)
>
Right, we won't need this cast since match->data is a void pointer.
Will also make the returned pointer const.
>> #ifdef CONFIG_OF
>> static const struct of_device_id samsung_usbphy_dt_match[] = {
>> {
>> .compatible = "samsung,s3c64xx-usbphy",
>> - .data = (void *)TYPE_S3C64XX,
>> + .data = (void *)&usbphy_s3c64xx,
>
> Why do you need this cast?
>
True we don't need this cast. Will remove this one.
>> }, {
>> .compatible = "samsung,exynos4210-usbphy",
>> - .data = (void *)TYPE_EXYNOS4210,
>> + .data = (void *)&usbphy_exynos4,
>
> Ditto.
True we don't need this cast. Will remove this one.
Thanks for the review :-)
--
Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] usb: chipidea: add otg file
On Thu, Dec 27, 2012 at 02:59:58PM +0800, Peter Chen wrote:
> Implement struct usb_otg, In that way, calling otg_set_peripheral
> will not be failed at udc.c.
>
> Signed-off-by: Peter Chen
> ---
> Changes for v4:
> - Some tiny changes, like delete unused header files
>
> drivers/usb/chipidea/Makefile |2 +-
> drivers/usb/chipidea/ci.h |2 +
> drivers/usb/chipidea/otg.c| 60
> +
> drivers/usb/chipidea/otg.h|6
> 4 files changed, 69 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index d92ca32..11f513c 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -2,7 +2,7 @@ ccflags-$(CONFIG_USB_CHIPIDEA_DEBUG) := -DDEBUG
>
> obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc.o
>
> -ci_hdrc-y:= core.o
> +ci_hdrc-y:= core.o otg.o
> ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC) += udc.o
> ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST) += host.o
> ci_hdrc-$(CONFIG_USB_CHIPIDEA_DEBUG) += debug.o
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index d738603..8702871 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -129,6 +129,7 @@ struct hw_bank {
> * @vbus_active: is VBUS active
> * @transceiver: pointer to USB PHY, if any
> * @hcd: pointer to usb_hcd for ehci host driver
> + * @otg: for otg support
> */
> struct ci13xxx {
> struct device *dev;
> @@ -164,6 +165,7 @@ struct ci13xxx {
> boolglobal_phy;
> struct usb_phy *transceiver;
> struct usb_hcd *hcd;
> + struct usb_otg otg;
I'd really like to know how this is going to proceed.
The ULPI driver currently allocates a struct usb_otg and sets
otg->set_host and otg->set_vbus. Since now the chipidea driver uses its
own struct usb_otg, this will not work with ULPI support.
I see some ways out of this:
- Use a pointer above instead of an own struct usb_otg in the ci driver.
- move the set_host and set_vbus callbacks to struct usb_phy.
I'd like to have this solved before we merge this patch.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] usb: phy: samsung: Add support to set pmu isolation
Hi Sylwester,
On Thu, Dec 27, 2012 at 4:00 AM, Sylwester Nawrocki
wrote:
> On 12/26/2012 01:28 PM, Vivek Gautam wrote:
>>
>> Adding support to parse device node data in order to get
>> required properties to set pmu isolation for usb-phy.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>> .../devicetree/bindings/usb/samsung-usbphy.txt | 31
>> drivers/usb/phy/samsung-usbphy.c | 145
>> +---
>> 2 files changed, 155 insertions(+), 21 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>> b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>> index 7b26e2d..6b873fd 100644
>> --- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>> +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>> @@ -9,3 +9,34 @@ Required properties:
>> - compatible : should be "samsung,exynos4210-usbphy"
>> - reg : base physical address of the phy registers and length of memory
>> mapped
>> region.
>> +
>> +Optional properties:
>> +- #address-cells: should be '1' when usbphy node has a child node with
>> 'reg'
>> + property.
>> +- #size-cells: should be '1' when usbphy node has a child node with 'reg'
>> + property.
>> +
>> +- The child node 'usbphy-pmu' to the node usbphy should provide the
>> following
>> + information required by usb-phy controller to enable/disable the phy.
>> + - reg : base physical address of PHY control register in PMU which
>> + enables/disables the phy controller.
>> + The size of this register is the total sum of size of all
>> phy-control
>> + registers that the SoC has. For example, the size will be
>> + '0x4' in case we have only one phy-control register (like in
>> S3C64XX) or
>> + '0x8' in case we have two phy-control registers (like in
>> Exynos4210)
>> + and so on.
>> +
>> +Example:
>> + - Exysno4210
>
>
> s/Exysno/Exynos
>
Sure will amend this.
>
>> +
>> + usbphy@125B {
>> + #address-cells =<1>;
>> + #size-cells =<1>;
>> + compatible = "samsung,exynos4210-usbphy";
>> + reg =<0x125B 0x100>;
>> +
>> + usbphy-pmu {
>> + /* USB device and host PHY_CONTROL registers */
>> + reg =<0x10020704 0x8>;
>> + };
>> + };
>> diff --git a/drivers/usb/phy/samsung-usbphy.c
>> b/drivers/usb/phy/samsung-usbphy.c
>> index 5c5e1bb5..b9f4f42 100644
>> --- a/drivers/usb/phy/samsung-usbphy.c
>> +++ b/drivers/usb/phy/samsung-usbphy.c
>> @@ -60,20 +60,42 @@
>> #define MHZ (1000*1000)
>> #endif
>>
>> +#define S3C64XX_USBPHY_ENABLE (0x1<< 16)
>> +#define EXYNOS_USBPHY_ENABLE (0x1<< 0)
>> +
>> enum samsung_cpu_type {
>> TYPE_S3C64XX,
>> TYPE_EXYNOS4210,
>> };
>>
>> /*
>> + * struct samsung_usbphy_drvdata - driver data for various SoC variants
>> + * @cpu_type: machine identifier
>> + * @devphy_en_mask: device phy enable mask for PHY CONTROL register
>> + *
>> + * Here we have a separate mask for device type phy.
>> + * Having different masks for host and device type phy helps
>> + * in setting independent masks in case of SoCs like S5PV210,
>> + * in which PHY0 and PHY1 enable bits belong to same register
>> + * placed at [0] and [1] respectively.
>
>
> "and are placed at positions 0 and 1 respectively" ?
>
Ok, will change this.
>
>> + * Although for newer SoCs like exynos these bits belong to
>> + * different registers altogether placed at [0].
>> + */
>> +struct samsung_usbphy_drvdata {
>> + int cpu_type;
>> + int devphy_en_mask;
>> +};
>> +
>> +/*
>>* struct samsung_usbphy - transceiver driver state
>>* @phy: transceiver structure
>>* @plat: platform data
>>* @dev: The parent device supplied to the probe function
>>* @clk: usb phy clock
>>* @regs: usb phy register memory base
>> + * @phyctrl_pmureg: usb device phy-control pmu register memory base
>
>
> nit: Perhaps we could just call it "pmureg' ?
>
Sure we can use the name 'pmureg'.
>
>>* @ref_clk_freq: reference clock frequency selection
>> - * @cpu_type: machine identifier
>> + * @drv_data: driver data available for different cpu types
>
>
> Actually it's for different SoCs, not CPUs, right ?
>
Right, will change this.
>
>>*/
>> struct samsung_usbphy {
>> struct usb_phy phy;
>> @@ -81,12 +103,67 @@ struct samsung_usbphy {
>> struct device *dev;
>> struct clk *clk;
>> void __iomem*regs;
>> + void __iomem*phyctrl_pmureg;
>> int ref_clk_freq;
>> - int cpu_type;
>> + const struct samsung_usbphy_drvdata *drv_data;
>> };
>>
>> #define phy_to_sphy(x)container_of((x), struct
>> samsung_usbphy, phy)
>>
>> +static int samsung_usbphy_parse_dt_param(struct samsung_usbphy *sphy)
>
>
Re: [PATCH 2/2] USB: ehci-s5p: Add to get interrupt from DT
Hi Sergei,
Yes, you are right.
I made this patch to read its interrupt number from dtb directly. But
now platform_get_irq() returns correct irq since "OF_DEV_AUXDATA(...)"
is added as my first patch.
This patch is useless.
Thanks and best regards,
Dongjin.
On Thu, Dec 27, 2012 at 5:18 AM, Sergei Shtylyov wrote:
>
> Hello.
>
> On 12/26/2012 09:42 PM, Dongjin Kim wrote:
>
> > This patch support to get interrupt resource from device tree as well as
> > platform device if ehci node is defined in device tree and it's irq is
> > described.
>
> > Signed-off-by: Dongjin Kim
> > ---
> > drivers/usb/host/ehci-s5p.c |8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
>
> > diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
> > index 319dcfa..0fc5e5e 100644
> > --- a/drivers/usb/host/ehci-s5p.c
> > +++ b/drivers/usb/host/ehci-s5p.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -156,7 +157,12 @@ static int s5p_ehci_probe(struct platform_device
> > *pdev)
> > goto fail_io;
> > }
> >
> > - irq = platform_get_irq(pdev, 0);
> > + if (pdev->dev.of_node)
> > + irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
>
>platform_get_irq() should still work for device tree based platform
> devices.
> I don't see the point on the patch?
>
> > + else {
> > + irq = platform_get_irq(pdev, 0);
> > + }
>
>Hm, why {} out of the blue? Both arms of *if* are single-stratement.
>
> > +
>
>No need for empty line here.
>
> > if (!irq) {
> > dev_err(&pdev->dev, "Failed to get IRQ\n");
> > err = -ENODEV;
>
> WBR, Sergei
>
--
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: Regression in kernel 3.8-rc1 bisected to commit adfa79d: I now get many "unable to enumerate USB device" messages
On 12/26/2012 09:56 PM, Alan Stern wrote: This looks like a matter of getting modules to load in the right order. Apparently your OHCI controller doesn't work right if the EHCI driver isn't present. Before the troublesome commit, this meant ehci-hcd had to be loaded before ohci-hcd. Now it means ehci-hcd and ehci-pci both have to be loaded before ohci-hcd. In the dmesg log you provided, ehci-hcd was loaded before ohci-hcd but ehci-pci was loaded after. Of course, when everything is built into the kernel (not as modules) then questions of loading order don't arise. You can test this hypothesis by booting a kernel without that commit and blacklisting ehci-hcd, so that it doesn't get loaded automatically. See if the errors start to come, and see if they stop when you load ehci-hcd manually. I could not do exactly the experiment that you wanted, as ehci-hcd was loaded even though it was blacklisted. Rather than solve that problem, I generated a kernel from just before commit adfa79d with ohci-hcd built in and ehci-hcd as a module. This one generated the errors, but they stopped when ehci-hcd loaded. I also tested a 3.8-rc1 kernel with ehci-hcd and ehcd-pci built in and ohci-hcd as a module. No errors for that one. Your hypothesis looks correct. I hope there is some way to force ehci-pci to load as soon as ehci-hcd is loaded, and before ohci-hcd loads, but if there is not, I know how to prevent the errors on my system even though this solution won't help the users of distro kernels. At least this time the errors stop once all 3 modules are loaded, and the number of error outputs is limited. Thanks, Larry -- 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 0/3] ARM: dts: omap: add dt data for MUSB
Hi, On Thu, Sep 20, 2012 at 05:21:15AM +0200, Benoit Cousson wrote: > On 09/19/2012 11:32 AM, Kishon Vijay Abraham I wrote: > > This patch series adds dt data to get MUSB working in omap4 and omap3 > > > > Changes from v2: > > * Changes the subject of all the patches to include "ARM: dts:" > > * Added reg property and interrupt property for "usb_otg_hs". Previously > > these > > were obtained from ti,hwmods property. > > * Rebased on > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git > > devel-dt > > > > Changes from v1: > > Just removed the omap-usb2 dt data and sent that as a separate patch. > > > > Kishon Vijay Abraham I (3): > > ARM: dts: Add twl6030-usb data > > ARM: dts: Add twl4030-usb data > > ARM: dts: omap: Add usb_otg and glue data > > Thanks for the update. I've just pulled the series for 3.7. I wonder what happened to the patch #3 (Add usb_otg and glue data) of this series? Why was it dropped? I cannot see it in 3.7 or 3.8-rc1. A. -- 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 ports freeze with 0471:206c Philips (or NXP) MCE IR Receiver - Spinel plusf0r ASUS connected at boot time
Hi guys, Does anyone have any ideas about this problem yet? Did anyone even see this message?:) I'm sorry for capturing your attention but I'm not even sure if I'm right posting this bug here. Is it correct place? Or is there some bug tracker I could use? Any additional info required? I'd perform any required actions possible on my side to help to debug this bug. On Thu, Dec 20, 2012 at 1:57 AM, Eugene Lipchansky wrote: > > Hi, > > I've got the ASUS N73SV laptop with an infra red usb receiver. When I boot > with it connected I get usb ports frozen for 10-20 seconds i.e. my external > keyboard/mouse are not working for a few seconds after system is completely > loaded and shows gdm screen. In some cases usb ports don't unfreeze so > only reboot helps. There a some debug info shown in the dmesg - see below. > > But in general IR remote works fine. Moreover - if I connect the receiver > after > the system is completely loaded - all works just fine. Bun "lsusb -v" hangs! > No problems in dmesg though. > > Not sure if this is connected problem, but sometimes system hangs on shutdown, > (frequently when ir receiver connected). > > > My OS: > Linux laptop 3.6.10-1-ARCH #1 SMP PREEMPT Tue Dec 11 09:40:17 CET 2012 > x86_64 GNU/Linux > > > dmesg: > https://docs.google.com/open?id=0B72UpQeUfGO1QVJtbnIyX1J6Qm8 > > start looking from: > [4.968525] BUG: unable to handle kernel NULL pointer dereference > at 0002 > > > lsusb: > https://docs.google.com/open?id=0B72UpQeUfGO1R3AtOXk1cERiR0k > > > the problem device here is: > Bus 003 Device 005: ID 0471:206c Philips (or NXP) MCE IR Receiver - > Spinel plusf0r ASUS > > > with the device connected at boot time "lsusb -v" hangs! > lsusb -v: > https://docs.google.com/open?id=0B72UpQeUfGO1dzdkb01lNmFaalk > > > But if I connect device after the system is completely loaded "lsusb > -v" works fine: > lsusb -v: > https://docs.google.com/open?id=0B72UpQeUfGO1MFRyOXoyZy1mb2c > > Any thoughts please? -- 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: Regression in kernel 3.8-rc1 bisected to commit adfa79d: I now get many "unable to enumerate USB device" messages
On Thu, 27 Dec 2012, Larry Finger wrote: > I could not do exactly the experiment that you wanted, as ehci-hcd was loaded > even though it was blacklisted. Rather than solve that problem, I generated a > kernel from just before commit adfa79d with ohci-hcd built in and ehci-hcd as > a > module. This one generated the errors, but they stopped when ehci-hcd loaded. > I > also tested a 3.8-rc1 kernel with ehci-hcd and ehcd-pci built in and ohci-hcd > as > a module. No errors for that one. Your hypothesis looks correct. > > I hope there is some way to force ehci-pci to load as soon as ehci-hcd is > loaded, and before ohci-hcd loads, but if there is not, I know how to prevent > the errors on my system even though this solution won't help the users of > distro > kernels. At least this time the errors stop once all 3 modules are loaded, > and > the number of error outputs is limited. This is now a userspace issue. Perhaps a change to a udev rule will prevent ohci-hcd from loading until ehci-pci is in place. Or a change to a startup script in your initramfs. However the problem gets solved, there doesn't seem to be much the kernel can do about it. 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: help with dummy_hcd and g_zero
Questions like this should always be posted to the linux-usb mailing list. On Thu, 27 Dec 2012, Dan Clapp wrote: > Hello Alan, > > First, let me start by thanking you for supplying you code. I > appreciate it. I think this is the way we would like to go to test our > system before we actually get hardware made. > > I am getting desperate! I have been trying to use your "dummy_hcd.ko" > and g_zero.ko module to try and run usb test and eventually get to write > my own usb device driver. > > However, I keep freezing up my system when I install the g_zero device > driver. > > I was wondering if can either point me in the correct direction, and or > give me a couple of hints as to what i am doing wrong: > > Here is what I am doing: > > Running on Fedora 14 virtual machine. Fedora 14 is about two years old now, and it isn't supported any more (no more software updates, bug fixes, or security fixes). Shouldn't you use something more up-to-date? > I compiled and was successfully generated dummy_hcd, gadgetfs and g_zero. > > First I load in the dummy_hcd stuff: > > #insmod dummy_hcd.ko > #mkdir /dev/gadget > #insmod gadgetfs.ko This is your mistake. You should not load gadgetfs.ko. > #mount -t gadgetfs none /dev/gadget > > At this point I can see both a dummy_hcd and dummy_ucd (at /proc/bus/usb > and /dev/gadget respectively). > > # ls /dev/gadget > dummy_udc > # ls /proc/bus/usb > 001 002 003 devices > > where in devices we have: > > [root@localhost gadget]# cat /proc/bus/usb/devices > > T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 > B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 > D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=1d6b ProdID=0002 Rev= 2.06 > S: Manufacturer=Linux 2.6.35.14-106.fc14.i686 dummy_hcd > S: Product=Dummy host controller > S: SerialNumber=dummy_hcd > C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA > I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms > > T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 > B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 > D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=1d6b ProdID=0001 Rev= 2.06 > S: Manufacturer=Linux 2.6.35.14-106.fc14.i686 uhci_hcd > S: Product=UHCI Host Controller > S: SerialNumber=:02:00.0 > C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA > I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms > > T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 7 > D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 > P: Vendor=0e0f ProdID=0002 Rev= 1.00 > S: Product=VMware Virtual USB Hub > C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA > I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms > > T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 > B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 > D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=1d6b ProdID=0002 Rev= 2.06 > S: Manufacturer=Linux 2.6.35.14-106.fc14.i686 ehci_hcd > S: Product=EHCI Host Controller > S: SerialNumber=:02:03.0 > C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA > I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms > [root@localhost gadget]# > > > Now I want to put a "device" on the dummy_ucd bus 3. > > I try and insert g_zero.ko > > #insmod g_zero.ko > > This is where things go bad - my system hangs and I need to reboot. > Nothing is in dmesg output with regards to this command. The system should not hang. Instead, the insmod command should simply fail. Does the same thing happen if you use a 3.8-rc1 kernel? > Do you have any examples, or help you can give me? > > How do I specify that g_zero should be attached to the dummy_hcd bus? It will attach there automatically if gadgetfs isn't already attached there first. > Any help or guidance is greatly appreciated! > > Thanks, You're welcome. 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: Regression in kernel 3.8-rc1 bisected to commit adfa79d: I now get many "unable to enumerate USB device" messages
On 12/27/2012 05:18 PM, Alan Stern wrote: On Thu, 27 Dec 2012, Larry Finger wrote: I could not do exactly the experiment that you wanted, as ehci-hcd was loaded even though it was blacklisted. Rather than solve that problem, I generated a kernel from just before commit adfa79d with ohci-hcd built in and ehci-hcd as a module. This one generated the errors, but they stopped when ehci-hcd loaded. I also tested a 3.8-rc1 kernel with ehci-hcd and ehcd-pci built in and ohci-hcd as a module. No errors for that one. Your hypothesis looks correct. I hope there is some way to force ehci-pci to load as soon as ehci-hcd is loaded, and before ohci-hcd loads, but if there is not, I know how to prevent the errors on my system even though this solution won't help the users of distro kernels. At least this time the errors stop once all 3 modules are loaded, and the number of error outputs is limited. This is now a userspace issue. Perhaps a change to a udev rule will prevent ohci-hcd from loading until ehci-pci is in place. Or a change to a startup script in your initramfs. However the problem gets solved, there doesn't seem to be much the kernel can do about it. Thanks for looking at this. At the moment, there are no udev rules on my system that mention "ehci" or "ohci". Perhaps a suitable one can be prepared. In addition, I still need to look at the startup scripts to see if there is a possible fix there. Larry -- 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: How to add USB device ID
On 12/21/12 10:22 PM, "Greg KH" wrote: >On Fri, Dec 21, 2012 at 05:54:33PM -0600, Kevin K wrote: >> I use an USB device that looks like a serial port to the kernel. >>However, >> since the Device ID is unknown, I have to either modprobe usbserial with >> the vendor/id codes as parameters, or modify generic.c so it knows to >> handle the device. I have been going with the code modification since >> there are 2 versions of this device with different numbers, and you can >> only do 1 on the command line. >> >> What is the "right" way to see if it can be pushed into mainline >>support? >> It seems overkill to write another driver that essentially wraps around >> generic.c. > >No it isn't overkill, we have a few drivers like this. What type of USB >serial chip is this device? Perhaps we should just add the device ids >to an existing driver? > >thanks, > >greg k-h Sorry to not respond until now. I missed some time due to a cold and the holiday. I don't know the actual serial chip, but I went and ran lsusb -v on a system with it. What I guess makes it complicated is that the device is a multifunction device. Depending on configuration, it can appear as both a serial port and a rndis_host based network device. On Red Hat EL 6, lsusb shows the following: Bus 003 Device 002: ID 229c: Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x229c idProduct 0x bcdDevice1.00 iManufacturer 1 Raytheon iProduct2 TacLink 3300 COM iSerial 3 1197 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 75 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 4 CDC ADM W/IAD bmAttributes 0x80 (Bus Powered) MaxPower 400mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 0 None iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 0 None iInterface 6 HOST COM INTERFACE CDC Header: bcdCDC 1.10 CDC Call Management: bmCapabilities 0x00 bDataInterface 1 CDC ACM: bmCapabilities 0x00 CDC Union: bMasterInterface0 bSlaveInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 6 HOST COM INTERFACE Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Device Status: 0x (Bus Powered) When the RNDIS mode is enabled, the ID changes to 229c:0001, and the rndis_host mode works without any kernel change other than making sure the module is loaded. Thanks, Kevin -- 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#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Wed, 26 Dec 2012, Octavio Alvarez wrote: > >> It can't hurt to try the test. Does the patch below make any > >> difference? > > > > Thank you for the patch, but it makes no difference. :( Too bad. > I looked for more instances of "linux immediate wakeup" and found > interesting links. They are regarding EHCI, but I wonder if > something similar could affect OHCI as well. > > > First, two threads in linux-pm from 2010: > > http://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025063.html > [PATCH] ehci: Disable wake on overcurrent (WKOC_E) > > http://lists.linux-foundation.org/pipermail/linux-pm/2010-April/025064.html > [PATCH v2] [RFC] ehci: Disable wake on overcurrent (WKOC_E) and disconnect > (WKDISC_E) > > Do you think this may affect OHCI too in some similar way? No, I don't think so. The mechanisms used by EHCI and OHCI for controlling the wakeup setting (and in particular, wake on overcurrent) are totally different. > --- > > Then, three links, apparently regarding EHCI about the usage of +5VSB > instead of the +5V line for powering the USB controller. > > Could the experiment with switching the +5V and +5VSB lines be relevant as > well for OCHI? In fact, this message _is_ about OHCI. > http://www.gossamer-threads.com/lists/mythtv/users/316830 > ASUS M2NPV-VM It's certainly worth trying this out. > > I figured out that you have to enable the +5VSB jumper on all the > > USB hubs that have devices connected to them, even if you're not going > > to use them to wake up the box! In other words, turn them ALL on, not > > just the one where the wake-up device is connected. Don't worry about > > joysticks waking up your machine randomly, because they won't; > > apparently only devices with power buttons can do so. > > --- > > https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/128315 > > > Suspend started working after changing the USB from +5V to +5VSB. I do > > get a message about half the times that 1 application refused to freeze: > > Plasma. After the suspend attempt, I have to kill plasma and restart it. > > If I try suspending again it works most of the time. But this seems like > > an unrelated bug. > > --- > > http://www.gossamer-threads.com/lists/mythtv/users/309798 > > > Additionally, you need to have the motherboard jumper for USB host > > controller set so that it gets power during S3. If hardware jumpers on the motherboard are in the wrong position, it definitely could cause the sort of problem you've been experiencing. 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 v4 2/7] usb: chipidea: add otg file
On Thu, Dec 27, 2012 at 11:47:58AM +0100, Sascha Hauer wrote:
> On Thu, Dec 27, 2012 at 02:59:58PM +0800, Peter Chen wrote:
> > struct ci13xxx {
> > struct device *dev;
> > @@ -164,6 +165,7 @@ struct ci13xxx {
> > boolglobal_phy;
> > struct usb_phy *transceiver;
> > struct usb_hcd *hcd;
> > + struct usb_otg otg;
>
> I'd really like to know how this is going to proceed.
>
> The ULPI driver currently allocates a struct usb_otg and sets
> otg->set_host and otg->set_vbus. Since now the chipidea driver uses its
> own struct usb_otg, this will not work with ULPI support.
We discussed before that the otg is not related to phy.
The struct usb_otg is better allocated at the otg driver, not phy driver.
I have a look at other phy drivers(drivers/usb/phy), now, there
is no one to create struct usb_otg at their phy drivers. To solve this
problem, we may need to modify ulpi phy driver.
To integrate ULPI phy, we may need to do:
- Make ulpi as a platform driver
- Override otg.set_host, and otg.set_vbus with ulpi's at
otg_ulpi_create or what else.
- Call otg_ulpi_create at the end of ci13xxx_imx_probe (before
pm_runtime_no_callbacks) if the phy is ulpi.
>
> I see some ways out of this:
>
> - Use a pointer above instead of an own struct usb_otg in the ci driver.
> - move the set_host and set_vbus callbacks to struct usb_phy.
>
> I'd like to have this solved before we merge this patch.
>
> Sascha
>
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
>
--
Best Regards,
Peter Chen
--
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
