Re: [PATCH v5 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
On Wed, Sep 12, 2012 at 4:38 PM, Marc Kleine-Budde m...@pengutronix.de wrote: On 09/12/2012 12:45 PM, Praveen Paneri wrote: This driver uses usb_phy interface to interact with s3c-hsotg. Supports phy_init and phy_shutdown functions to enable/disable phy. Tested with smdk6410 and smdkv310. More SoCs can be brought under later. Signed-off-by: Praveen Paneri p.pan...@samsung.com Acked-by: Heiko Stuebner he...@sntech.de --- .../devicetree/bindings/usb/samsung-usbphy.txt |9 + drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/samsung-usbphy.c | 371 include/linux/platform_data/samsung-usbphy.h | 27 ++ 5 files changed, 416 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode 100644 drivers/usb/phy/samsung-usbphy.c create mode 100644 include/linux/platform_data/samsung-usbphy.h diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt new file mode 100644 index 000..fefd9c8 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -0,0 +1,9 @@ +* Samsung's usb phy transceiver + +The Samsung's phy transceiver is used for controlling usb otg phy for +s3c-hsotg usb device controller. + +Required properties: +- compatible : should be samsung,exynos4210-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 63c339b..313685f 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -32,3 +32,11 @@ config MV_U3D_PHY help Enable this to support Marvell USB 3.0 phy controller for Marvell SoC. + +config SAMSUNG_USBPHY + bool Samsung USB PHY controller Driver + depends on USB_S3C_HSOTG + select USB_OTG_UTILS + help + Enable this to support Samsung USB phy controller for samsung + SoCs. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index b069f29..55dcfc1 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o obj-$(CONFIG_USB_ISP1301)+= isp1301.o obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o +obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c new file mode 100644 index 000..b00d01b --- /dev/null +++ b/drivers/usb/phy/samsung-usbphy.c @@ -0,0 +1,371 @@ +/* linux/drivers/usb/phy/samsung-usbphy.c + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Author: Praveen Paneri p.pan...@samsung.com + * + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * 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/platform_device.h +#include linux/clk.h +#include linux/delay.h +#include linux/err.h +#include linux/io.h +#include linux/of.h +#include linux/usb/otg.h +#include linux/platform_data/samsung-usbphy.h + +/* Register definitions */ + +#define S3C_PHYPWR (0x00) + +#define S3C_PHYPWR_NORMAL_MASK (0x19 0) +#define S3C_PHYPWR_OTG_DISABLE (1 4) +#define S3C_PHYPWR_ANALOG_POWERDOWN (1 3) +#define S3C_PHYPWR_FORCE_SUSPEND (1 1) +/* For Exynos4 */ +#define EXYNOS4_PHYPWR_NORMAL_MASK (0x39 0) +#define EXYNOS4_PHYPWR_SLEEP (1 5) + +#define S3C_PHYCLK (0x04) + +#define S3C_PHYCLK_MODE_SERIAL (1 6) +#define S3C_PHYCLK_EXT_OSC (1 5) +#define S3C_PHYCLK_COMMON_ON_N (1 4) +#define S3C_PHYCLK_ID_PULL (1 2) +#define S3C_PHYCLK_CLKSEL_MASK (0x3 0) +#define S3C_PHYCLK_CLKSEL_SHIFT (0) +#define S3C_PHYCLK_CLKSEL_48M(0x0 0) +#define S3C_PHYCLK_CLKSEL_12M(0x2 0) +#define S3C_PHYCLK_CLKSEL_24M(0x3 0) + +#define S3C_RSTCON (0x08) + +#define S3C_RSTCON_PHYCLK(1 2) +#define
[patch] USB: chipidea: fix vs | bug
There is a '' vs '|' typo in the original code so the condition is never true and we don't queue the work. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index 2f45bba..5294f81 100644 --- a/drivers/usb/chipidea/udc.c +++ b/drivers/usb/chipidea/udc.c @@ -1680,7 +1680,7 @@ static irqreturn_t udc_irq(struct ci13xxx *ci) intr = hw_read(ci, OP_OTGSC, ~0); hw_write(ci, OP_OTGSC, ~0, intr); - if (intr (OTGSC_AVVIE OTGSC_AVVIS)) + if (intr (OTGSC_AVVIE | OTGSC_AVVIS)) queue_work(ci-wq, ci-vbus_work); spin_unlock(ci-lock); -- 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 4/4]: ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc
Git should show this as a move, not as a add a file and remove a file type patch. Are you generating it properly? Whats the proper way to do this? I did a git mv, git commit and than git diff on that commit hash. Also, why move it? Are there other modules that need to use it? thanks, greg k-h we discussed this a while ago, i had some trouble getting the patches due to changing my workplace. -- 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: phy: signedness bug in suspend/resume
ret should be signed here for the error handling to work.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 15ab3d6..d36c282 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -120,7 +120,7 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
static int omap_usb2_suspend(struct usb_phy *x, int suspend)
{
- u32 ret;
+ int ret;
struct omap_usb *phy = phy_to_omapusb(x);
if (suspend !phy-is_suspended) {
@@ -223,7 +223,7 @@ static int omap_usb2_runtime_suspend(struct device *dev)
static int omap_usb2_runtime_resume(struct device *dev)
{
- u32 ret = 0;
+ int ret;
struct platform_device *pdev = to_platform_device(dev);
struct omap_usb *phy = platform_get_drvdata(pdev);
--
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 4/4]: ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc
Also, why move it? Are there other modules that need to use it? Fullquote from Aug, 24: - Although i removed the dependency from ezusb to usb_serial, ezusb.c still resides in drivers/usb/serial. Can you give me a hint, where to put it instead? I would like to do that with an additional patch. Why do you want to move it? because is has nothing to do with any serial stuff anymore... Fair enough, how about drivers/usb/misc/ instead? 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: chipidea: fix vs | bug
On Fri, Sep 14, 2012 at 09:50:56AM +0300, Dan Carpenter wrote: There is a '' vs '|' typo in the original code so the condition is never true and we don't queue the work. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index 2f45bba..5294f81 100644 --- a/drivers/usb/chipidea/udc.c +++ b/drivers/usb/chipidea/udc.c @@ -1680,7 +1680,7 @@ static irqreturn_t udc_irq(struct ci13xxx *ci) intr = hw_read(ci, OP_OTGSC, ~0); hw_write(ci, OP_OTGSC, ~0, intr); - if (intr (OTGSC_AVVIE OTGSC_AVVIS)) + if (intr (OTGSC_AVVIE | OTGSC_AVVIS)) It's not what I meant. Should be if ((intr OTGSC_AVVIE) (intr OTGSC_AVVIS)) I'm still testing it. Thanks Richard queue_work(ci-wq, ci-vbus_work); spin_unlock(ci-lock); -- 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 06/11] USB: mxs-phy: add basic otg support
On Wed, Sep 12, 2012 at 01:39:01PM +0300, Heikki Krogerus wrote:
Hi,
On Tue, Aug 28, 2012 at 03:03:12PM +0800, Richard Zhao wrote:
+static int mxs_phy_set_host(struct usb_otg *otg, struct usb_bus *host)
+{
Shouldn't you at least save the host pointer?
otg-host = host;
It looks making sense, though it's not called by chipidea driver.
+ return 0;
+}
+
+static int mxs_phy_set_peripheral(struct usb_otg *otg,
+ struct usb_gadget *gadget)
+{
And the same with the gadget?
Thanks
Richard
+ return 0;
+}
--
heikki
--
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 05/11] USB: chipidea: don't let probe fail if otg controller start one role failed
On Wed, Sep 12, 2012 at 01:47:54PM +0300, Alexander Shishkin wrote:
Richard Zhao richard.z...@freescale.com writes:
On Tue, Sep 11, 2012 at 10:23:55AM +0300, Alexander Shishkin wrote:
Richard Zhao richard.z...@freescale.com writes:
On Wed, Aug 29, 2012 at 12:48:15PM +0300, Alexander Shishkin wrote:
Richard Zhao richard.z...@freescale.com writes:
On Wed, Aug 29, 2012 at 11:10:33AM +0300, Alexander Shishkin wrote:
Richard Zhao richard.z...@freescale.com writes:
On Tue, Aug 28, 2012 at 11:38:23AM +0300, Alexander Shishkin wrote:
Richard Zhao richard.z...@freescale.com writes:
One role failed, but the other role will possiblly still work.
For example, when udc start failed, if plug in a host device,
it works.
If you're a host device, ci-role should be HOST at this point and
ci_role_start() shouldn't fail. If ci-role is detected wrongly,
the
role detection must be fixed. If ci_role_start() fails for host,
but it
still works when it's called again after the id pin change is
detected,
again, the problem is elsewhere.
The check is only for OTG device. For single role device, it just
fail
if it start the role failed.
Sorry, can you rephrase?
Signed-off-by: Richard Zhao richard.z...@freescale.com
---
drivers/usb/chipidea/core.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/core.c
b/drivers/usb/chipidea/core.c
index 19ef324..8fd390a 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -473,8 +473,11 @@ static int __devinit ci_hdrc_probe(struct
platform_device *pdev)
ret = ci_role_start(ci, ci-role);
if (ret) {
dev_err(dev, can't start %s role\n,
ci_role(ci)-name);
- ret = -ENODEV;
- goto rm_wq;
+ ci-role = CI_ROLE_END;
So are you relying on id pin interrupt for initializing the role
after
this? Can you provide more details?
Yes. The ID pin detect still works. My case is, gadget role failed,
host role works. I was trying not to ruin host function.
But it shouldn't even try to start the gadget, because ci_otg_role()
should set ci-role to HOST before ci_role_start() happens.
It depends on ID pin. If ID pin is gadget and gadget is not support
well,
ci_role_start will fail. See below example.
Another question is, why does gadget start fail?
There's one example:
If usb phy don't support otg yet, otg_set_peripheral will fail, and
then cause udc_start fail.
So you should drop the CI13XXX_REQUIRE_TRANSCEIVER flag from imx
platform data till the phy is fully implemented.
It's just an example. We can not assume udc_start always success. If it
fails, isn't it better to continue support of host than say game over?
Ok, I think what we need here is to rework error handling around role
switching, so that we can allow certain things to fail and retry at a
later point (say at id pin change), while being careful about the other
failures.
If this patch is not crucial for imx right now, I'd prefer to leave it
out.
That's OK. but I hope other function related patch can be merged for
3.7 :)
Also 6/11 seems quite pointless to me. Otherwise, I'll send them to Greg
today.
If set_peripheral is null, udc_start will fail. Or you prefer removing
checking of otg_set_peripheral returned value?
Thanks
Richard
Regards,
--
Alex
--
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 06/11] USB: mxs-phy: add basic otg support
diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c
index c1a67cb..6a03e97 100644
--- a/drivers/usb/otg/mxs-phy.c
+++ b/drivers/usb/otg/mxs-phy.c
@@ -97,12 +97,24 @@ static int mxs_phy_on_disconnect(struct usb_phy *phy,
int port)
return 0;
}
+static int mxs_phy_set_host(struct usb_otg *otg, struct usb_bus *host)
+{
+ return 0;
+}
+
+static int mxs_phy_set_peripheral(struct usb_otg *otg,
+ struct usb_gadget *gadget)
+{
+ return 0;
+}
+
static int mxs_phy_probe(struct platform_device *pdev)
{
struct resource *res;
void __iomem *base;
struct clk *clk;
struct mxs_phy *mxs_phy;
+ struct usb_otg *otg;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
@@ -139,6 +151,15 @@ static int mxs_phy_probe(struct platform_device
*pdev)
mxs_phy-clk = clk;
+ otg = devm_kzalloc(pdev-dev, sizeof(struct usb_otg), GFP_KERNEL);
+ if (!otg)
+ return -ENOMEM;
+ otg-phy = mxs_phy-phy;
+ otg-set_host = mxs_phy_set_host;
+ otg-set_peripheral = mxs_phy_set_peripheral;
+
+ mxs_phy-phy.otg = otg;
+
Put otg struct at PHY driver is not a good practice.
Only OTG driver who handles ID interrupt cases about host and gadget struct.
PHY is a transceiver, it not cares otg, host and device at all.
platform_set_drvdata(pdev, mxs_phy-phy);
return 0;
--
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: [PATCH RFC 1/3] usb: phy: fix the error check
Hi,
On Thu, Sep 13, 2012 at 7:44 PM, Shubhrajyoti D shubhrajy...@ti.com wrote:
The functions pm_runtime_get_sync and clk_enable
return a signed value. So the variable used to
store should be signed otherwise a negative value may be
wrongly interpreted.
While at it also remove the initialisation of ret to zero.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
FWIW:
Acked-by: Kishon Vijay Abraham I kis...@ti.com
---
untested
drivers/usb/phy/omap-usb2.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 15ab3d6..d36c282 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -120,7 +120,7 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
static int omap_usb2_suspend(struct usb_phy *x, int suspend)
{
- u32 ret;
+ int ret;
struct omap_usb *phy = phy_to_omapusb(x);
if (suspend !phy-is_suspended) {
@@ -223,7 +223,7 @@ static int omap_usb2_runtime_suspend(struct device *dev)
static int omap_usb2_runtime_resume(struct device *dev)
{
- u32 ret = 0;
+ int ret;
struct platform_device *pdev = to_platform_device(dev);
struct omap_usb *phy = platform_get_drvdata(pdev);
--
1.7.5.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
--
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: usb3 writes fail with transcend rdf8 + ASMedia ASM1042 woes
On Thu, Sep 13, 2012 at 14:57:20 -0700, Sarah Sharp wrote: On Sat, Aug 25, 2012 at 12:31:46PM +0300, Sami Farin wrote: ... I plugged rdf8 reader into usb3 port, mounted it (vfat), cat garbage out.bin , at the end ls showed a bit over 25200 byte file, then empty dir listing (df showed input/output error). When mounted with rdf8 reader plugged into usb2 port the dir listing was intact, like it did not manage to write anything when in usb3.. Hi Sami, I'm back from vacation and I took a look at your log. It seems like your device works fine for a while, and then it doesn't respond to a transfer. The usb-storage driver attempts to reset it, and the Set Address command times out, which causes issues in the xHCI driver. Hello, thanks for analyzing my logs =) I tried usb-next kernel. It works much better with sanXi reader (20120824111628.usmh54g2iv2yx...@m.safari.iki.fi for more info), though not very fast read/write speeds (can xhci debug slow it down?). But with RDF8 reader I just got write errors pretty quickly after starting writing to the Transcend SDHC. With Sandisk card it works OK just like with older kernels. (Also, my Nikon D60 has no trouble accessing any of the cards.) dmesg-xhci.txt https://docs.google.com/file/d/0B_EMXtsx7o56Z2dFYnpUM05iNFk/edit usbmon-rdf8-usb3.txt https://docs.google.com/file/d/0B_EMXtsx7o56OWNSTEVkX2xkRnc/edit usbmon-rdf8-usb2.txt https://docs.google.com/file/d/0B_EMXtsx7o56ZUd1Tk9DR2xlTGM/edit -- Do what you love because life is too short for anything else. -- 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
tulip Ethernet driver messes up USB keyboard
Hi lists, After installing an old 100Mbit PCI Ethernet card to my machine, it has complained a few times about spurious interrupts (nobody cared) at a random time of the day. After the oops is reported, my USB keyboard (HP smart card keyboard) stops working properly -- it has lots of delay, it misses some keystrokes and also causes stuck keys. Strangely enough my USB mouse continues to work without problems. Apparently the USB controller and the Ethernet card share an interrupt line. Un-/replugging the keyboard does not help. So far I have simply rebooted to fix the issue. I haven't been able to reproduce this on will despite my best attempts. The Ethernet card is driven by the tulip driver and is listed as ADMtek NC100 Network Everywhere Fast Ethernet 10/100 (rev 11) in lspci. My motherboard uses the Intel H77 chipset (ASRock H77 Pro4/MVP) Here are two slightly different examples of the oops report; the effect is the same: kernel: irq 16: nobody cared (try booting with the irqpoll option) kernel: Pid: 0, comm: swapper/2 Not tainted 3.5.3-1-ARCH #1 kernel: Call Trace: kernel: IRQ [810d4d3d] __report_bad_irq+0x3d/0xe0 kernel: [810d5033] note_interrupt+0x1a3/0x1f0 kernel: [810d292f] handle_irq_event_percpu+0xbf/0x260 kernel: [810d2b18] handle_irq_event+0x48/0x70 kernel: [810d5b4a] handle_fasteoi_irq+0x5a/0x100 kernel: [810160c2] handle_irq+0x22/0x40 kernel: [81484cea] do_IRQ+0x5a/0xe0 kernel: [8147c12a] common_interrupt+0x6a/0x6a kernel: EOI [a02d8f01] ? acpi_idle_enter_c1+0xda/0x104 [processor] kernel: [a02d8edc] ? acpi_idle_enter_c1+0xb5/0x104 [processor] kernel: [8134f159] cpuidle_enter+0x19/0x20 kernel: [8134f7a6] cpuidle_idle_call+0xa6/0x330 kernel: [8101daaf] cpu_idle+0xbf/0x130 kernel: [8146a19b] start_secondary+0x203/0x20a kernel: handlers: kernel: [a012c0b0] usb_hcd_irq [usbcore] kernel: [a023b1c0] tulip_interrupt [tulip] kernel: Disabling IRQ #16 kernel: irq 16: nobody cared (try booting with the irqpoll option) kernel: Pid: 0, comm: swapper/0 Not tainted 3.5.3-1-ARCH #1 kernel: Call Trace: kernel: IRQ [810d4d3d] __report_bad_irq+0x3d/0xe0 kernel: [810d5033] note_interrupt+0x1a3/0x1f0 kernel: [810d292f] handle_irq_event_percpu+0xbf/0x260 kernel: [810d2b18] handle_irq_event+0x48/0x70 kernel: [810d5b4a] handle_fasteoi_irq+0x5a/0x100 kernel: [810160c2] handle_irq+0x22/0x40 kernel: [81484cea] do_IRQ+0x5a/0xe0 kernel: [8147c12a] common_interrupt+0x6a/0x6a kernel: EOI [a01b6f01] ? acpi_idle_enter_c1+0xda/0x104 [processor] kernel: [a01b6edc] ? acpi_idle_enter_c1+0xb5/0x104 [processor] kernel: [8134f159] cpuidle_enter+0x19/0x20 kernel: [8134f7a6] cpuidle_idle_call+0xa6/0x330 kernel: [8101daaf] cpu_idle+0xbf/0x130 kernel: [81456fbc] rest_init+0x80/0x84 kernel: [818bbc35] start_kernel+0x3c1/0x3ce kernel: [818bb673] ? repair_env_string+0x5e/0x5e kernel: [818bb356] x86_64_start_reservations+0x131/0x135 kernel: [818bb45a] x86_64_start_kernel+0x100/0x10f kernel: handlers: kernel: [a012c0b0] usb_hcd_irq [usbcore] kernel: [a02b41c0] tulip_interrupt [tulip] kernel: Disabling IRQ #16 These are after a fresh reboot... % lspci |grep Eth 03:00.0 Ethernet controller: ADMtek NC100 Network Everywhere Fast Ethernet 10/100 (rev 11) 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06) % dmesg |egrep -i 'eth|tulip' [7.868120] tulip: Linux Tulip driver version 1.1.15 (Feb 27, 2007) [7.868146] tulip: tulip_init_one: Enabled WOL support for AN983B [7.870487] tulip0: MII transceiver #1 config 1000 status 786d advertising 05e1 [7.893274] net eth0: ADMtek Comet rev 17 at Port 0xe000, 00:06:25:48:7f:16, IRQ 16 [7.902994] systemd-udevd[162]: renamed network interface eth0 to eth1 [7.989822] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [7.990148] r8169 :04:00.0: eth0: RTL8168evl/8111evl at 0xc90005798000, bc:5f:f4:44:29:6c, XID 0c900800 IRQ 47 [7.990150] r8169 :04:00.0: eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] [ 16.032206] r8169 :04:00.0: eth0: link down [ 16.032568] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 18.287417] r8169 :04:00.0: eth0: link up [ 18.287761] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 18.437518] tulip :03:00.0: eth1: tulip_stop_rxtx() failed (CSR5 0xfc664010 CSR6 0xff972113) [ 18.437530] net eth1: Setting full-duplex based on MII#1 link partner capability of 45e1 Somewhat suspect is the tulip_stop_rxtx() failed line. I also get that line every time I stop the interface (using ip link set eth1 down): Sep 14 12:40:11 wrx kernel: tulip :03:00.0: eth1: tulip_stop_rxtx() failed (CSR5 0xfc664010 CSR6
[PATCH] staging: usbip: vhci_hcd: Fixed oops during removal of vhci_hcd
In response to usbip detach -p [port_number] user command,vhci_shoutdown_connection gets executed which kills tcp_tx,tcp_rx kernel threads and then vhci_device_reset resets all usb_device struct variables except kernel thread pointers. so, at the time of vhci_hcd removal vhci_shoutdown_connection tries to kill kernel threads which are already killed. Signed-off-by: navin patidar nav...@cdac.in --- drivers/staging/usbip/vhci_hcd.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd.c index 6076f42..b1f427c 100644 --- a/drivers/staging/usbip/vhci_hcd.c +++ b/drivers/staging/usbip/vhci_hcd.c @@ -858,6 +858,9 @@ static void vhci_device_reset(struct usbip_device *ud) if (vdev-udev) usb_put_dev(vdev-udev); vdev-udev = NULL; + /* Reset kernel thread pointers */ + ud-tcp_rx = NULL; + ud-tcp_tx = NULL; ud-tcp_socket = NULL; ud-status = VDEV_ST_NULL; -- 1.7.9.5 --- This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. --- -- 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] staging: usbip: stub_dev: Fixed oops during removal of usbip_host
stub_device_reset should set kernel thread pointers to NULL.
so that at the time of usbip_host removal stub_shoutdown_connection
doesn't try to kill kernel threads which are already killed.
Signed-off-by: navin patidar nav...@cdac.in
---
drivers/staging/usbip/stub_dev.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/staging/usbip/stub_dev.c
index 92ced35..f584af8 100644
--- a/drivers/staging/usbip/stub_dev.c
+++ b/drivers/staging/usbip/stub_dev.c
@@ -192,16 +192,13 @@ static void stub_shutdown_connection(struct usbip_device
*ud)
if (ud-tcp_tx)
kthread_stop_put(ud-tcp_tx);
- /*
-* 2. close the socket
+ /* 2. close the socket
*
* tcp_socket is freed after threads are killed so that usbip_xmit does
* not touch NULL socket.
*/
- if (ud-tcp_socket) {
+ if (ud-tcp_socket)
sock_release(ud-tcp_socket);
- ud-tcp_socket = NULL;
- }
/* 3. free used data */
stub_device_cleanup_urbs(sdev);
@@ -233,6 +230,13 @@ static void stub_device_reset(struct usbip_device *ud)
dev_dbg(udev-dev, device reset);
+ /*reset tcp socket*/
+ ud-tcp_socket = NULL;
+
+ /*reset kernel thread pointers */
+ ud-tcp_rx = NULL;
+ ud-tcp_tx = NULL;
+
ret = usb_lock_device_for_reset(udev, sdev-interface);
if (ret 0) {
dev_err(udev-dev, lock for reset\n);
--
1.7.9.5
---
This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
---
--
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
INTR descriptors in webcam gadget (f_uvc)
Hi Laurent, I've been looking at the UVC's descriptors. There is one interrupt endpoint described by uvc_fs_control_ep. The bInterval is set to 8 which means every 8ms on FS. The exact same descriptor is used on high speed. Here the 8 means 2^(8-1) * 125µs = every 16ms. Is this on purpose? Would it be okay to adjust it to either 16ms or 8ms on both speeds? I've been looking further and I noticed that you allocate an endpoint for this via usb_ep_autoconfig() but you never allocate a request for it and never send/receive and data. Is here some code missing? This remembers me of something: does this gadget work or are some patches required / pending? Sebastian -- 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 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
On Wed, Sep 12, 2012 at 9:51 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Praveen, Marc,
On Wednesday 12 of September 2012 13:08:26 Marc Kleine-Budde wrote:
+static const struct of_device_id samsung_usbphy_dt_match[];
+
+static inline int samsung_usbphy_get_driver_data(struct
platform_device *pdev) +{
+#ifdef CONFIG_OF
if (IS_ENABLED(CONFIG_OF) pdev-dev.of_node)
Is this check needed at all?
In case of CONFIG_OF disabled, of_node should always be NULL and there is a
but I guess it can also be NULL when CONFIG_OF is enabled but the
driver is probed non DT way.
dummy macro provided for of_match_node, so it should compile and work just
fine.
--
Best regards,
Tomasz Figa
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
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] usb: gadget: lpc32xx_udc: Disable setup request error message
On 12/09/12 22:33, Alexandre Pereira da Silva wrote:
This message is an debugging message. It's useful for finding protocol
details but it's not necessarily an error.
Signed-off-by: Alexandre Pereira da Silva aletes@gmail.com
Acked-by: Roland Stigge sti...@antcom.de
Yes, the Kevin Wells at NXP confirmed this some time ago. Thanks!
---
drivers/usb/gadget/lpc32xx_udc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/lpc32xx_udc.c
b/drivers/usb/gadget/lpc32xx_udc.c
index 21a9861..d1cf1f4 100644
--- a/drivers/usb/gadget/lpc32xx_udc.c
+++ b/drivers/usb/gadget/lpc32xx_udc.c
@@ -2399,7 +2399,7 @@ static void udc_handle_ep0_setup(struct lpc32xx_udc
*udc)
if (i 0) {
/* setup processing failed, force stall */
- dev_err(udc-dev,
+ dev_dbg(udc-dev,
req %02x.%02x protocol STALL; stat %d\n,
reqtype, req, i);
udc-ep0state = WAIT_FOR_SETUP;
--
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 4/4]: ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc
On Fri, Sep 14, 2012 at 08:52:58AM +0200, Rene Buergel wrote: Git should show this as a move, not as a add a file and remove a file type patch. Are you generating it properly? Whats the proper way to do this? I did a git mv, git commit and than git diff on that commit hash. Thatis okay but while you create the patch you should use the -M switch in `git format-patch` command. You could also try to use `git send-email` which should create proper threads and avoid copy/paste formating problems (in case there were any). Sebastian -- 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: serial: ftdi_sio: option to hide selected interfaces of multiple interfaces convertes
Add parametrs to hide some of converter interfaces against ftdi_sio driver.
This allows on multiple-interfaces converter (such as ft2232, ft4232)
use uart with kernel driver and use e.g. I2C or SPI (on other interface)
with libusb or other kernel-driver.
Signed-off-by: Robert Ryszard Paciorek r.pacio...@icm.edu.pl
---
--- drivers/usb/serial/ftdi_sio.c.org 2012-09-12 10:51:44.779427134 +
+++ drivers/usb/serial/ftdi_sio.c 2012-09-12 13:54:40.210930196 +
@@ -1633,10 +1633,19 @@ static void remove_sysfs_attrs(struct us
* ***
*/
+/* Module parameter to control ignoring some interfaces on multiple
+ interfaces converter such as ft2232, ft4232:
+ignore_mask - bit mask of ignoring interfaces
+ignore_only_on_dev - product name of device with ignore interfaces
+*/
+unsigned short ignore_mask;
+char *ignore_only_on_dev;
+
/* Probe function to check for special devices */
static int ftdi_sio_probe(struct usb_serial *serial,
const struct usb_device_id *id)
{
+ int i;
struct ftdi_sio_quirk *quirk =
(struct ftdi_sio_quirk *)id-driver_info;
@@ -1646,6 +1655,21 @@ static int ftdi_sio_probe(struct usb_ser
return ret;
}
+ if (ignore_mask != 0x00 (ignore_only_on_dev == NULL
+ || strcmp(serial-dev-product, ignore_only_on_dev) == 0)) {
+ struct usb_interface *interface = serial-interface;
+ struct usb_host_config *actconfig = serial-dev-actconfig;
+
+ for (i = 0; i 8 i USB_MAXINTERFACES; i++) {
+ if ((ignore_maski) 0x01
+interface == actconfig-interface[i]) {
+ dev_info(serial-dev-dev,
+ Ignoring interface %d\n, i);
+ return -ENODEV;
+ }
+ }
+ }
+
usb_set_serial_data(serial, (void *)id-driver_info);
return 0;
@@ -2440,3 +2464,8 @@ MODULE_PARM_DESC(product, User specifie
module_param(ndi_latency_timer, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(ndi_latency_timer, NDI device latency timer override);
+
+module_param(ignore_mask, ushort, 0);
+MODULE_PARM_DESC(ignore_mask, Bit mask of ignoring interfaces
(default=0x) (ushort));
+module_param(ignore_only_on_dev, charp, 0);
+MODULE_PARM_DESC(ignore_only_on_dev, USB product name of device where we
ignore interfaces (default NULL == all devices) (string));
--
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 05/11] USB: chipidea: don't let probe fail if otg controller start one role failed
Richard Zhao richard.z...@freescale.com writes:
On Wed, Sep 12, 2012 at 01:47:54PM +0300, Alexander Shishkin wrote:
Richard Zhao richard.z...@freescale.com writes:
On Tue, Sep 11, 2012 at 10:23:55AM +0300, Alexander Shishkin wrote:
Richard Zhao richard.z...@freescale.com writes:
On Wed, Aug 29, 2012 at 12:48:15PM +0300, Alexander Shishkin wrote:
Richard Zhao richard.z...@freescale.com writes:
On Wed, Aug 29, 2012 at 11:10:33AM +0300, Alexander Shishkin wrote:
Richard Zhao richard.z...@freescale.com writes:
On Tue, Aug 28, 2012 at 11:38:23AM +0300, Alexander Shishkin
wrote:
Richard Zhao richard.z...@freescale.com writes:
One role failed, but the other role will possiblly still work.
For example, when udc start failed, if plug in a host device,
it works.
If you're a host device, ci-role should be HOST at this point
and
ci_role_start() shouldn't fail. If ci-role is detected wrongly,
the
role detection must be fixed. If ci_role_start() fails for host,
but it
still works when it's called again after the id pin change is
detected,
again, the problem is elsewhere.
The check is only for OTG device. For single role device, it just
fail
if it start the role failed.
Sorry, can you rephrase?
Signed-off-by: Richard Zhao richard.z...@freescale.com
---
drivers/usb/chipidea/core.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/core.c
b/drivers/usb/chipidea/core.c
index 19ef324..8fd390a 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -473,8 +473,11 @@ static int __devinit ci_hdrc_probe(struct
platform_device *pdev)
ret = ci_role_start(ci, ci-role);
if (ret) {
dev_err(dev, can't start %s role\n,
ci_role(ci)-name);
- ret = -ENODEV;
- goto rm_wq;
+ ci-role = CI_ROLE_END;
So are you relying on id pin interrupt for initializing the role
after
this? Can you provide more details?
Yes. The ID pin detect still works. My case is, gadget role
failed,
host role works. I was trying not to ruin host function.
But it shouldn't even try to start the gadget, because ci_otg_role()
should set ci-role to HOST before ci_role_start() happens.
It depends on ID pin. If ID pin is gadget and gadget is not support
well,
ci_role_start will fail. See below example.
Another question is, why does gadget start fail?
There's one example:
If usb phy don't support otg yet, otg_set_peripheral will fail, and
then cause udc_start fail.
So you should drop the CI13XXX_REQUIRE_TRANSCEIVER flag from imx
platform data till the phy is fully implemented.
It's just an example. We can not assume udc_start always success. If it
fails, isn't it better to continue support of host than say game over?
Ok, I think what we need here is to rework error handling around role
switching, so that we can allow certain things to fail and retry at a
later point (say at id pin change), while being careful about the other
failures.
If this patch is not crucial for imx right now, I'd prefer to leave it
out.
That's OK. but I hope other function related patch can be merged for
3.7 :)
Also 6/11 seems quite pointless to me. Otherwise, I'll send them to Greg
today.
If set_peripheral is null, udc_start will fail. Or you prefer removing
checking of otg_set_peripheral returned value?
I guess for now we could do something like
if (retval
!(ci-platdata-flags CI13XXX_REQUIRE_TRANSCEIVER))
goto remove_dbg;
... or implement an otg driver. :)
Regards,
--
Alex
--
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 06/11] USB: mxs-phy: add basic otg support
On Fri, Sep 14, 2012 at 04:56:13PM +0800, Chen Peter-B29397 wrote:
diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c
index c1a67cb..6a03e97 100644
--- a/drivers/usb/otg/mxs-phy.c
+++ b/drivers/usb/otg/mxs-phy.c
@@ -97,12 +97,24 @@ static int mxs_phy_on_disconnect(struct usb_phy *phy,
int port)
return 0;
}
+static int mxs_phy_set_host(struct usb_otg *otg, struct usb_bus *host)
+{
+ return 0;
+}
+
+static int mxs_phy_set_peripheral(struct usb_otg *otg,
+ struct usb_gadget *gadget)
+{
+ return 0;
+}
+
static int mxs_phy_probe(struct platform_device *pdev)
{
struct resource *res;
void __iomem *base;
struct clk *clk;
struct mxs_phy *mxs_phy;
+ struct usb_otg *otg;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
@@ -139,6 +151,15 @@ static int mxs_phy_probe(struct platform_device
*pdev)
mxs_phy-clk = clk;
+ otg = devm_kzalloc(pdev-dev, sizeof(struct usb_otg), GFP_KERNEL);
+ if (!otg)
+ return -ENOMEM;
+ otg-phy = mxs_phy-phy;
+ otg-set_host = mxs_phy_set_host;
+ otg-set_peripheral = mxs_phy_set_peripheral;
+
+ mxs_phy-phy.otg = otg;
+
Put otg struct at PHY driver is not a good practice.
Only OTG driver who handles ID interrupt cases about host and gadget struct.
PHY is a transceiver, it not cares otg, host and device at all.
I understand your concern, but this patch don't mean to restructure
common code.
Thanks
Richard
platform_set_drvdata(pdev, mxs_phy-phy);
return 0;
--
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
f_uac2: why do you save two u8 in one u16?
looking at f_uac2.c I found this interresting piece of code:
|struct audio_dev {
| /* Currently active {Interface[15:8] | AltSettings[7:0]} */
| __u16 ac_alt, as_out_alt, as_in_alt;
|âŠ
|};
|
|âŠ
|#define ALT_SET(x, a) do {(x) = ~0xff; (x) |= (a); } while (0)
|#define ALT_GET(x) ((x) 0xff)
|#define INTF_SET(x, i) do {(x) = 0xff; (x) |= ((i) 8); } while (0)
|#define INTF_GET(x) ((x 8) 0xff)
|âŠ
|ALT_SET(agdev-as_out_alt, 0);
|INTF_SET(agdev-as_out_alt, ret);
|âŠ
Could one of you two explain to me why smashing two different things (an
interface number and an alternative setting number) into one variable
and using a Macro to seperate them again was a good idea?
Sebastian
--
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: f_uac2: why do you save two u8 in one u16?
On Fri, Sep 14, 2012 at 12:53:56PM +0200, Sebastian Andrzej Siewior wrote:
looking at f_uac2.c I found this interresting piece of code:
|struct audio_dev {
| /* Currently active {Interface[15:8] | AltSettings[7:0]} */
| __u16 ac_alt, as_out_alt, as_in_alt;
|âŠ
|};
|
|âŠ
|#define ALT_SET(x, a) do {(x) = ~0xff; (x) |= (a); } while (0)
|#define ALT_GET(x) ((x) 0xff)
|#define INTF_SET(x, i) do {(x) = 0xff; (x) |= ((i) 8); } while (0)
|#define INTF_GET(x) ((x 8) 0xff)
|âŠ
|ALT_SET(agdev-as_out_alt, 0);
|INTF_SET(agdev-as_out_alt, ret);
|âŠ
Could one of you two explain to me why smashing two different things (an
interface number and an alternative setting number) into one variable
and using a Macro to seperate them again was a good idea?
Another thing. alsa_uac2_init() calling platform_device_register() and
platform_driver_register()? Why is that helpful can't you just call
snd_uac2_probe() right away?
You have poor (read as non-existing) error recovery in case something
goes wrong during the allocation endpoint/interface/request.
What do I need to test this gadget?
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 2/3] usb: twl6030: fix the error check for omap_usb2_set_comparator
Hello.
On 13-09-2012 18:56, ABRAHAM, KISHON VIJAY wrote:
The function omap_usb2_set_comparator may return -ENODEV.
Use a signed variable to store and check so that the value
is not wrongly interpreted as a large positive number.
While at it lets use the err variable to do the same.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
untested
drivers/usb/otg/twl6030-usb.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index fcadef7..11c22f3 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
[...]
@@ -331,8 +330,8 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
twl-comparator.set_vbus= twl6030_set_vbus;
twl-comparator.start_srp = twl6030_start_srp;
- ret = omap_usb2_set_comparator(twl-comparator);
- if (ret == -ENODEV) {
+ err = omap_usb2_set_comparator(twl-comparator);
+ if (err == -ENODEV) {
While at that can you just change the above to use IS_ERR?
IS_ERR() operates on pointers, not on integers. You probably meant:
if (err 0)
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: [PATCH] staging: usbip: stub_dev: Fixed oops during removal of usbip_host
Hello.
On 14-09-2012 13:53, navin patidar wrote:
stub_device_reset should set kernel thread pointers to NULL.
so that at the time of usbip_host removal stub_shoutdown_connection
doesn't try to kill kernel threads which are already killed.
Signed-off-by: navin patidar nav...@cdac.in
---
drivers/staging/usbip/stub_dev.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/staging/usbip/stub_dev.c
index 92ced35..f584af8 100644
--- a/drivers/staging/usbip/stub_dev.c
+++ b/drivers/staging/usbip/stub_dev.c
@@ -192,16 +192,13 @@ static void stub_shutdown_connection(struct usbip_device
*ud)
if (ud-tcp_tx)
kthread_stop_put(ud-tcp_tx);
- /*
-* 2. close the socket
+ /* 2. close the socket
It's the preferred comment style -- why modify it?
*
* tcp_socket is freed after threads are killed so that usbip_xmit does
* not touch NULL socket.
*/
- if (ud-tcp_socket) {
+ if (ud-tcp_socket)
sock_release(ud-tcp_socket);
- ud-tcp_socket = NULL;
- }
/* 3. free used data */
stub_device_cleanup_urbs(sdev);
@@ -233,6 +230,13 @@ static void stub_device_reset(struct usbip_device *ud)
dev_dbg(udev-dev, device reset);
+ /*reset tcp socket*/
Add spaces after /* and before */, please.
+ ud-tcp_socket = NULL;
+
+ /*reset kernel thread pointers */
Here too.
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
[PATCH] usb: gadget: s3c-hsotg: Add device tree support
This patch adds device tree support for s3c-hsotg driver
used for Samsung platforms.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
.../devicetree/bindings/usb/s3c-hsotg.txt | 16
drivers/usb/gadget/s3c-hsotg.c | 20
2 files changed, 36 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/s3c-hsotg.txt
diff --git a/Documentation/devicetree/bindings/usb/s3c-hsotg.txt
b/Documentation/devicetree/bindings/usb/s3c-hsotg.txt
new file mode 100644
index 000..30b26c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/s3c-hsotg.txt
@@ -0,0 +1,16 @@
+Samsung HSOTG controller s3c-hsotg
+
+Required properties:
+ - compatible : should be samsung,exynos-hsotg.
+ - reg : should contain at least address and length of the standard HSOTG
+register set for the device.
+ - interrupts : one HSOTG interrupt should be described here.
+
+Example (Samsung Origen):
+
+ usb@1248 {
+ compatible = samsung,exynos-hsotg;
+ reg = 0x1248 0x2;
+ interrupts = 0 71 0;
+ };
+
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index b13e0bb..d7f557f 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -28,6 +28,7 @@
#include linux/io.h
#include linux/slab.h
#include linux/clk.h
+#include linux/of.h
#include linux/regulator/consumer.h
#include linux/usb/ch9.h
@@ -3485,6 +3486,8 @@ static void s3c_hsotg_release(struct device *dev)
kfree(hsotg);
}
+static u64 s3c_hsotg_dma_mask = DMA_BIT_MASK(32);
+
/**
* s3c_hsotg_probe - probe function for hsotg driver
* @pdev: The platform information for the driver
@@ -3507,6 +3510,14 @@ static int __devinit s3c_hsotg_probe(struct
platform_device *pdev)
return -EINVAL;
}
+ /*
+* Right now device-tree probed devices don't get dma_mask set.
+*/
+ if (!pdev-dev.dma_mask)
+ pdev-dev.dma_mask = s3c_hsotg_dma_mask;
+ if (!pdev-dev.coherent_dma_mask)
+ pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+
hsotg = devm_kzalloc(pdev-dev, sizeof(struct s3c_hsotg), GFP_KERNEL);
if (!hsotg) {
dev_err(dev, cannot get memory\n);
@@ -3701,10 +3712,19 @@ static int __devexit s3c_hsotg_remove(struct
platform_device *pdev)
#define s3c_hsotg_resume NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_hsotg_match[] = {
+ { .compatible = samsung,exynos-hsotg },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_hsotg_match);
+#endif
+
static struct platform_driver s3c_hsotg_driver = {
.driver = {
.name = s3c-hsotg,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(exynos_hsotg_match),
},
.probe = s3c_hsotg_probe,
.remove = __devexit_p(s3c_hsotg_remove),
--
1.7.4.1
--
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
[RFC PATCH] drivers: phy: add generic PHY framework
The PHY framework provides a set of API's for the PHY drivers to
create/remove a PHY and the PHY users to obtain a reference to the PHY
using or without using phandle. If the PHY users has to obtain a reference to
the PHY without using phandle, the platform specfic intialization code (say
from board file) should have already called phy_bind with the binding
information. The binding information consists of phy's device name, phy
user device name and an index. The index is used when the same phy user
binds to mulitple phys.
PHY drivers should create the PHY by passing phy_descriptor that has
information about the PHY and ops like init, exit, suspend, resume,
poweron, shutdown.
Nyet-signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
This framework is actually intended to be used by all the PHY drivers in the
kernel. Though it's going to take a while for that, I intend to migrate
existing USB/OTG phy drivers to use this framework as we align on the design
of this framework. Once I migrate these phy drivers, I'll be able to test this
framework (I haven't tested this framework so far). I sent this patch early
so as to get review comments and align on the design. Thanks :-)
drivers/Kconfig |2 +
drivers/Makefile|2 +
drivers/phy/Kconfig | 13 ++
drivers/phy/Makefile|5 +
drivers/phy/phy-core.c | 437 +++
include/linux/phy/phy.h | 181
6 files changed, 640 insertions(+)
create mode 100644 drivers/phy/Kconfig
create mode 100644 drivers/phy/Makefile
create mode 100644 drivers/phy/phy-core.c
create mode 100644 include/linux/phy/phy.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index ece958d..8488818 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -152,4 +152,6 @@ source drivers/vme/Kconfig
source drivers/pwm/Kconfig
+source drivers/phy/Kconfig
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 5b42184..63d6bbe 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -38,6 +38,8 @@ obj-y += char/
# gpu/ comes after char for AGP vs DRM startup
obj-y += gpu/
+obj-y += phy/
+
obj-$(CONFIG_CONNECTOR)+= connector/
# i810fb and intelfb depend on char/agp/
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
new file mode 100644
index 000..34f7077
--- /dev/null
+++ b/drivers/phy/Kconfig
@@ -0,0 +1,13 @@
+#
+# PHY
+#
+
+menuconfig GENERIC_PHY
+ tristate Generic PHY Support
+ help
+ Generic PHY support.
+
+ This framework is designed to provide a generic interface for PHY
+ devices present in the kernel. This layer will have the generic
+ API by which phy drivers can create PHY using the phy framework and
+ phy users can obtain reference to the PHY.
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
new file mode 100644
index 000..9e9560f
--- /dev/null
+++ b/drivers/phy/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_GENERIC_PHY) += phy-core.o
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 000..c55446a
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,437 @@
+/*
+ * phy-core.c -- Generic Phy framework.
+ *
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/export.h
+#include linux/module.h
+#include linux/err.h
+#include linux/device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/phy/phy.h
+
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+ struct phy *phy = *(struct phy **)res;
+
+ phy_put(phy);
+}
+
+static int devm_phy_match(struct device *dev, void *res, void *match_data)
+{
+ return res == match_data;
+}
+
+static struct phy *phy_lookup(struct device *dev, u8 index)
+{
+ struct phy_bind *phy_bind = NULL;
+
+ list_for_each_entry(phy_bind, phy_bind_list, list) {
+ if (!(strcmp(phy_bind-dev_name, dev_name(dev)))
+ phy_bind-index == index)
+
Re: [PATCH] usb: serial: ftdi_sio: option to hide selected interfaces of multiple interfaces convertes
On Fri, Sep 14, 2012 at 10:04:02AM +, Robert Ryszard Paciorek wrote: Add parametrs to hide some of converter interfaces against ftdi_sio driver. This allows on multiple-interfaces converter (such as ft2232, ft4232) use uart with kernel driver and use e.g. I2C or SPI (on other interface) with libusb or other kernel-driver. Couldn't you instead do an unbind of that particular interface via sysfs? How do you pass that particular interface to your i2c / SPI? Signed-off-by: Robert Ryszard Paciorek r.pacio...@icm.edu.pl Sebastian -- 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] staging: usbip: stub_dev: Fixed oops during removal of usbip_host
On Fri, Sep 14, 2012 at 03:42:42PM +0400, Sergei Shtylyov wrote: diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/staging/usbip/stub_dev.c index 92ced35..f584af8 100644 --- a/drivers/staging/usbip/stub_dev.c +++ b/drivers/staging/usbip/stub_dev.c @@ -233,6 +230,13 @@ static void stub_device_reset(struct usbip_device *ud) dev_dbg(udev-dev, device reset); +/*reset tcp socket*/ Add spaces after /* and before */, please. +ud-tcp_socket = NULL; + +/*reset kernel thread pointers */ Here too. I'm not sure it is required to comment the obvious things. WBR, Sergei Sebastian -- 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: [RFC PATCH] drivers: phy: add generic PHY framework
On 09/14/2012 01:58 PM, Kishon Vijay Abraham I wrote:
The PHY framework provides a set of API's for the PHY drivers to
create/remove a PHY and the PHY users to obtain a reference to the PHY
using or without using phandle. If the PHY users has to obtain a reference to
the PHY without using phandle, the platform specfic intialization code (say
from board file) should have already called phy_bind with the binding
information. The binding information consists of phy's device name, phy
user device name and an index. The index is used when the same phy user
binds to mulitple phys.
PHY drivers should create the PHY by passing phy_descriptor that has
information about the PHY and ops like init, exit, suspend, resume,
poweron, shutdown.
Some comments inside.
While looking over the code, I was thinking why not abstract the phy
with a bus in the linux kernel. The ethernet phys are on the mdio_bus,
see /sys/bus/mdio_bus. This saves you hand crafting devices, drivers and
bindings,
Marc
Nyet-signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
This framework is actually intended to be used by all the PHY drivers in the
kernel. Though it's going to take a while for that, I intend to migrate
existing USB/OTG phy drivers to use this framework as we align on the design
of this framework. Once I migrate these phy drivers, I'll be able to test this
framework (I haven't tested this framework so far). I sent this patch early
so as to get review comments and align on the design. Thanks :-)
drivers/Kconfig |2 +
drivers/Makefile|2 +
drivers/phy/Kconfig | 13 ++
drivers/phy/Makefile|5 +
drivers/phy/phy-core.c | 437
+++
include/linux/phy/phy.h | 181
6 files changed, 640 insertions(+)
create mode 100644 drivers/phy/Kconfig
create mode 100644 drivers/phy/Makefile
create mode 100644 drivers/phy/phy-core.c
create mode 100644 include/linux/phy/phy.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index ece958d..8488818 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -152,4 +152,6 @@ source drivers/vme/Kconfig
source drivers/pwm/Kconfig
+source drivers/phy/Kconfig
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 5b42184..63d6bbe 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -38,6 +38,8 @@ obj-y += char/
# gpu/ comes after char for AGP vs DRM startup
obj-y+= gpu/
+obj-y+= phy/
+
obj-$(CONFIG_CONNECTOR) += connector/
# i810fb and intelfb depend on char/agp/
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
new file mode 100644
index 000..34f7077
--- /dev/null
+++ b/drivers/phy/Kconfig
@@ -0,0 +1,13 @@
+#
+# PHY
+#
+
+menuconfig GENERIC_PHY
+ tristate Generic PHY Support
+ help
+ Generic PHY support.
+
+ This framework is designed to provide a generic interface for PHY
+ devices present in the kernel. This layer will have the generic
+ API by which phy drivers can create PHY using the phy framework and
+ phy users can obtain reference to the PHY.
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
new file mode 100644
index 000..9e9560f
--- /dev/null
+++ b/drivers/phy/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 000..c55446a
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,437 @@
+/*
+ * phy-core.c -- Generic Phy framework.
+ *
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/export.h
+#include linux/module.h
+#include linux/err.h
+#include linux/device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/phy/phy.h
+
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+ struct phy *phy = *(struct phy **)res;
What
Re: [RFC] Documentation update for Isochronous URB handling
On 9/11/2012 8:11 PM, Alan Stern wrote: Here is a proposed update for the kernel's documentation on Isochronous URBs. It describes the behavior Clemens and I have been discussing, which isn't implemented yet. I'm working on separate patches to implement the new behavior for EHCI, OHCI, and UHCI. Pratyush, since you have been busily working on related issues for the dwc3, you might be interested in this too. Thanks for including me in CC. Whatever knowledge I have for the host software, this proposition seems correct to me. Do you think that similar flag make sense in gadget framework too? Currently, gadget driver does not impose any restrictions on when to transmit a request by hardware, so peripheral driver always schedule as per its own criteria. Regards Pratyush I have no idea how XHCI deals with these issues. Anyway, everyone please take a quick look and let me know if this seems okay. Alan Stern Index: usb-3.6/Documentation/usb/error-codes.txt === --- usb-3.6.orig/Documentation/usb/error-codes.txt +++ usb-3.6/Documentation/usb/error-codes.txt @@ -35,9 +35,8 @@ USB-specific: d) ISO: number_of_packets is 0 e) various other cases --EAGAINa) specified ISO start frame too early - b) (using ISO-ASAP) too much scheduled for the future - wait some time and try again. +-EXDEV ISO: URB_ISO_ASAP wasn't specified and all the frames + the URB would be scheduled in have already expired. -EFBIGHost controller driver can't schedule that many ISO frames. Index: usb-3.6/include/linux/usb.h === --- usb-3.6.orig/include/linux/usb.h +++ usb-3.6/include/linux/usb.h @@ -1101,8 +1101,8 @@ extern int usb_disabled(void); * Note: URB_DIR_IN/OUT is automatically set in usb_submit_urb(). */ #define URB_SHORT_NOT_OK 0x0001 /* report short reads as errors */ -#define URB_ISO_ASAP 0x0002 /* iso-only, urb-start_frame -* ignored */ +#define URB_ISO_ASAP 0x0002 /* iso-only; use the first unexpired +* slot in the schedule */ #define URB_NO_TRANSFER_DMA_MAP 0x0004 /* urb-transfer_dma valid on submit */ #define URB_NO_FSBR 0x0020 /* UHCI-specific */ #define URB_ZERO_PACKET 0x0040 /* Finish bulk OUT with short packet */ @@ -1281,15 +1281,20 @@ typedef void (*usb_complete_t)(struct ur * the transfer interval in the endpoint descriptor is logarithmic. * Device drivers must convert that value to linear units themselves.) * - * Isochronous URBs normally use the URB_ISO_ASAP transfer flag, telling - * the host controller to schedule the transfer as soon as bandwidth - * utilization allows, and then set start_frame to reflect the actual frame - * selected during submission. Otherwise drivers must specify the start_frame - * and handle the case where the transfer can't begin then. However, drivers - * won't know how bandwidth is currently allocated, and while they can - * find the current frame using usb_get_current_frame_number () they can't - * know the range for that frame number. (Ranges for frame counter values - * are HC-specific, and can go from 256 to 65536 frames from now.) + * If an isochronous endpoint queue isn't already running, the host + * controller will schedule a new URB to start as soon as bandwidth + * utilization allows. If the queue is running then a new URB will be + * scheduled to start in the first transfer slot following the end of the + * preceding URB, if that slot has not already expired. If the slot has + * expired (which can happen when IRQ delivery is delayed for a long time), + * the scheduling behavior depends on the URB_ISO_ASAP flag. If the flag + * is clear then the URB will be scheduled to start in the expired slot, + * implying that some of its packets will not be transferred; if the flag + * is set then the URB will be scheduled in the first unexpired slot, + * breaking the queue's synchronization. Upon URB completion, the + * start_frame field will be set to the (micro)frame number in which the + * transfer was scheduled. Ranges for frame counter values are HC-specific + * and can go from as low as 256 to as high as 65536 frames. * * Isochronous URBs have a different data transfer model, in part because * the quality of service is only best effort. Callers provide specially Index: usb-3.6/drivers/usb/core/urb.c === --- usb-3.6.orig/drivers/usb/core/urb.c +++ usb-3.6/drivers/usb/core/urb.c @@ -214,9 +214,25 @@ EXPORT_SYMBOL_GPL(usb_unanchor_urb); * urb-interval is modified to reflect the actual transfer period used * (normally some power of two units). And for isochronous urbs, *
USB problem on beagleboard clone
Hi all, we've designed two beagle board clones (two different layouts) for a customer. After quite some time without any problems they are now seeing USB problems on some of the boards. I have so far not been able to reproduce the problem... The USB port of the OMAP the problems appear on is connected through a TPS65950 to a LAN9514 USB Hub + Ethernet Chip. Attached is the kernel output. I'm not even sure if this is related to our board, or if this might be a misbehaving device?! If someone has an idea what this could be and what I could do to fix or at least further debug the problem please speak up. Cheers and thanks, Maximilian Schwerin. __ Maximilian Schwerin | maximilian.schwe...@tigris.de Tigris Elektronik GmbH | Wikingerufer 7 | 10555 Berlin, Germany | http://www.tigris.de Tel: +49 (30) 301048-30 | Fax: +49 (30) 301048-59 Geschäftsführer/CEO: Henry Westphal, Guido Kuhlmann Sitz der Gesellschaft/Company's registered office: Berlin Amtsgericht/Register: Berlin-Charlottenburg, HRB 71737 PGP-Keys: mailto:p...@tigris.de __ pgp0FTZs8qr9R.pgp Description: PGP signature
AW: USB problem on beagleboard clone
Sorry :-( With log now. -Ursprüngliche Nachricht- Von: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] Im Auftrag von Maximilian Schwerin Gesendet: Freitag, 14. September 2012 14:26 An: linux-o...@vger.kernel.org; linux-usb@vger.kernel.org Betreff: USB problem on beagleboard clone (PGP: Plain, Signed) Hi all, we've designed two beagle board clones (two different layouts) for a customer. After quite some time without any problems they are now seeing USB problems on some of the boards. I have so far not been able to reproduce the problem... The USB port of the OMAP the problems appear on is connected through a TPS65950 to a LAN9514 USB Hub + Ethernet Chip. Attached is the kernel output. I'm not even sure if this is related to our board, or if this might be a misbehaving device?! If someone has an idea what this could be and what I could do to fix or at least further debug the problem please speak up. Cheers and thanks, Maximilian Schwerin. USB_failures.log Description: USB_failures.log pgpH7fJDZixwI.pgp Description: PGP signature
Re: [RFC PATCH] drivers: phy: add generic PHY framework
Hi, On Fri, Sep 14, 2012 at 5:58 PM, Marc Kleine-Budde m...@pengutronix.de wrote: On 09/14/2012 01:58 PM, Kishon Vijay Abraham I wrote: The PHY framework provides a set of API's for the PHY drivers to create/remove a PHY and the PHY users to obtain a reference to the PHY using or without using phandle. If the PHY users has to obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. PHY drivers should create the PHY by passing phy_descriptor that has information about the PHY and ops like init, exit, suspend, resume, poweron, shutdown. Some comments inside. While looking over the code, I was thinking why not abstract the phy with a bus in the linux kernel. The ethernet phys are on the mdio_bus, see /sys/bus/mdio_bus. This saves you hand crafting devices, drivers and bindings, well... have to think about it. Marc Nyet-signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- This framework is actually intended to be used by all the PHY drivers in the kernel. Though it's going to take a while for that, I intend to migrate existing USB/OTG phy drivers to use this framework as we align on the design of this framework. Once I migrate these phy drivers, I'll be able to test this framework (I haven't tested this framework so far). I sent this patch early so as to get review comments and align on the design. Thanks :-) drivers/Kconfig |2 + drivers/Makefile|2 + drivers/phy/Kconfig | 13 ++ drivers/phy/Makefile|5 + drivers/phy/phy-core.c | 437 +++ include/linux/phy/phy.h | 181 6 files changed, 640 insertions(+) create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h diff --git a/drivers/Kconfig b/drivers/Kconfig index ece958d..8488818 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -152,4 +152,6 @@ source drivers/vme/Kconfig source drivers/pwm/Kconfig +source drivers/phy/Kconfig + endmenu diff --git a/drivers/Makefile b/drivers/Makefile index 5b42184..63d6bbe 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -38,6 +38,8 @@ obj-y += char/ # gpu/ comes after char for AGP vs DRM startup obj-y+= gpu/ +obj-y+= phy/ + obj-$(CONFIG_CONNECTOR) += connector/ # i810fb and intelfb depend on char/agp/ diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig new file mode 100644 index 000..34f7077 --- /dev/null +++ b/drivers/phy/Kconfig @@ -0,0 +1,13 @@ +# +# PHY +# + +menuconfig GENERIC_PHY + tristate Generic PHY Support + help + Generic PHY support. + + This framework is designed to provide a generic interface for PHY + devices present in the kernel. This layer will have the generic + API by which phy drivers can create PHY using the phy framework and + phy users can obtain reference to the PHY. diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile new file mode 100644 index 000..9e9560f --- /dev/null +++ b/drivers/phy/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for the phy drivers. +# + +obj-$(CONFIG_GENERIC_PHY)+= phy-core.o diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c new file mode 100644 index 000..c55446a --- /dev/null +++ b/drivers/phy/phy-core.c @@ -0,0 +1,437 @@ +/* + * phy-core.c -- Generic Phy framework. + * + * Copyright (C) 2012 Texas Instruments + * + * Author: Kishon Vijay Abraham I kis...@ti.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see http://www.gnu.org/licenses/. + */ + +#include linux/kernel.h +#include linux/export.h +#include linux/module.h +#include linux/err.h +#include linux/device.h +#include linux/slab.h +#include linux/of.h +#include linux/phy/phy.h + +static struct class *phy_class; +static LIST_HEAD(phy_list); +static DEFINE_MUTEX(phy_list_mutex); +static LIST_HEAD(phy_bind_list); + +static
Re: USB problem on beagleboard clone
Hi, On Fri, Sep 14, 2012 at 02:57:49PM +0200, Maximilian Schwerin wrote: Sorry :-( With log now. -Ursprüngliche Nachricht- Von: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] Im Auftrag von Maximilian Schwerin Gesendet: Freitag, 14. September 2012 14:26 An: linux-o...@vger.kernel.org; linux-usb@vger.kernel.org Betreff: USB problem on beagleboard clone (PGP: Plain, Signed) Hi all, we've designed two beagle board clones (two different layouts) for a customer. After quite some time without any problems they are now seeing USB problems on some of the boards. I have so far not been able to reproduce the problem... The USB port of the OMAP the problems appear on is connected through a TPS65950 to a LAN9514 USB Hub + Ethernet Chip. Attached is the kernel output. I'm not even sure if this is related to our board, or if this might be a misbehaving device?! If someone has an idea what this could be and what I could do to fix or at least further debug the problem please speak up. I have never seen that error before on any of the boards I have. One question though, if the port is always Host, why are you using the OTG subsystem instead of the actual Host Subsystem which has an EHCI controller ? -- balbi signature.asc Description: Digital signature
Re: USB problem on beagleboard clone
Hi again, On Fri, Sep 14, 2012 at 04:07:56PM +0300, Felipe Balbi wrote: On Fri, Sep 14, 2012 at 02:57:49PM +0200, Maximilian Schwerin wrote: Sorry :-( With log now. -Ursprüngliche Nachricht- Von: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] Im Auftrag von Maximilian Schwerin Gesendet: Freitag, 14. September 2012 14:26 An: linux-o...@vger.kernel.org; linux-usb@vger.kernel.org Betreff: USB problem on beagleboard clone (PGP: Plain, Signed) Hi all, we've designed two beagle board clones (two different layouts) for a customer. After quite some time without any problems they are now seeing USB problems on some of the boards. I have so far not been able to reproduce the problem... The USB port of the OMAP the problems appear on is connected through a TPS65950 to a LAN9514 USB Hub + Ethernet Chip. Attached is the kernel output. I'm not even sure if this is related to our board, or if this might be a misbehaving device?! If someone has an idea what this could be and what I could do to fix or at least further debug the problem please speak up. I have never seen that error before on any of the boards I have. One question though, if the port is always Host, why are you using the OTG subsystem instead of the actual Host Subsystem which has an EHCI controller ? Which kernel are you using ? Have you tried with v3.5 or something more recent ? -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH] drivers: phy: add generic PHY framework
On Fri, Sep 14, 2012 at 02:28:19PM +0200, Marc Kleine-Budde wrote: On 09/14/2012 01:58 PM, Kishon Vijay Abraham I wrote: The PHY framework provides a set of API's for the PHY drivers to create/remove a PHY and the PHY users to obtain a reference to the PHY using or without using phandle. If the PHY users has to obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. PHY drivers should create the PHY by passing phy_descriptor that has information about the PHY and ops like init, exit, suspend, resume, poweron, shutdown. Some comments inside. While looking over the code, I was thinking why not abstract the phy with a bus in the linux kernel. The ethernet phys are on the mdio_bus, see /sys/bus/mdio_bus. This saves you hand crafting devices, drivers and bindings, I don't think that's a good idea, actually. You can have USB PHYs which are memory mapped, or connected through i2c, or connected through any other bus. If the PHYs layer itself is a bus, it means we will need to register a device on two different buses, which doesn't sound very nice IMHO. -- balbi signature.asc Description: Digital signature
audio_buf_size in f_uac1.c
Hello, I was wondering where the audio_buf_size in f_uac1.c came from. Why exactly was this value chosen, and what would I need to change if I'd like to keep this value as low as possible to minimize latency? I tried adjusting the size of this buffer, and it does help latency, but this is just guesswork. Is there any way in determining the minimum value this buffer can be set at? Maybe it depends on other kernel parameters (tickrate?). Any help regarding this buffer size would be appreciated. Greetings Jan De Kock -- 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
AW: USB problem on beagleboard clone
Hi, -Ursprüngliche Nachricht- Von: Felipe Balbi [mailto:ba...@ti.com] Gesendet: Freitag, 14. September 2012 15:08 An: Maximilian Schwerin Cc: linux-o...@vger.kernel.org; linux-usb@vger.kernel.org Betreff: Re: USB problem on beagleboard clone (PGP: Plain, Unable to verify signature) Hi, On Fri, Sep 14, 2012 at 02:57:49PM +0200, Maximilian Schwerin wrote: Sorry :-( With log now. -Ursprüngliche Nachricht- Von: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] Im Auftrag von Maximilian Schwerin Gesendet: Freitag, 14. September 2012 14:26 An: linux-o...@vger.kernel.org; linux-usb@vger.kernel.org Betreff: USB problem on beagleboard clone (PGP: Plain, Signed) Hi all, we've designed two beagle board clones (two different layouts) for a customer. After quite some time without any problems they are now seeing USB problems on some of the boards. I have so far not been able to reproduce the problem... The USB port of the OMAP the problems appear on is connected through a TPS65950 to a LAN9514 USB Hub + Ethernet Chip. Attached is the kernel output. I'm not even sure if this is related to our board, or if this might be a misbehaving device?! If someone has an idea what this could be and what I could do to fix or at least further debug the problem please speak up. I have never seen that error before on any of the boards I have. One question though, if the port is always Host, why are you using the OTG subsystem instead of the actual Host Subsystem which has an EHCI controller ? -- balbi I'm still on 3.3 but am planing to go to a newer version. We used the OTG port so we would not need another chip on a rather small board. Cheers, m. pgp0DDvnCmyjj.pgp Description: PGP signature
[PATCH] staging: usbip: stub_dev: Fixed oops during removal of usbip_host
stub_device_reset should set kernel thread pointers to NULL.
so that at the time of usbip_host removal stub_shoutdown_connection
doesn't try to kill kernel threads which are already killed.
Signed-off-by: navin patidar nav...@cdac.in
---
drivers/staging/usbip/stub_dev.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/staging/usbip/stub_dev.c
index 92ced35..447a98c 100644
--- a/drivers/staging/usbip/stub_dev.c
+++ b/drivers/staging/usbip/stub_dev.c
@@ -198,10 +198,8 @@ static void stub_shutdown_connection(struct usbip_device
*ud)
* tcp_socket is freed after threads are killed so that usbip_xmit does
* not touch NULL socket.
*/
- if (ud-tcp_socket) {
+ if (ud-tcp_socket)
sock_release(ud-tcp_socket);
- ud-tcp_socket = NULL;
- }
/* 3. free used data */
stub_device_cleanup_urbs(sdev);
@@ -233,6 +231,9 @@ static void stub_device_reset(struct usbip_device *ud)
dev_dbg(udev-dev, device reset);
+ ud-tcp_socket = NULL;
+ ud-tcp_rx = NULL;
+ ud-tcp_tx = NULL;
ret = usb_lock_device_for_reset(udev, sdev-interface);
if (ret 0) {
dev_err(udev-dev, lock for reset\n);
--
1.7.9.5
---
This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
---
--
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: USB problem on beagleboard clone
On Fri, Sep 14, 2012 at 03:21:47PM +0200, Maximilian Schwerin wrote: Hi, -Ursprüngliche Nachricht- Von: Felipe Balbi [mailto:ba...@ti.com] Gesendet: Freitag, 14. September 2012 15:08 An: Maximilian Schwerin Cc: linux-o...@vger.kernel.org; linux-usb@vger.kernel.org Betreff: Re: USB problem on beagleboard clone (PGP: Plain, Unable to verify signature) Hi, On Fri, Sep 14, 2012 at 02:57:49PM +0200, Maximilian Schwerin wrote: Sorry :-( With log now. -Ursprüngliche Nachricht- Von: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] Im Auftrag von Maximilian Schwerin Gesendet: Freitag, 14. September 2012 14:26 An: linux-o...@vger.kernel.org; linux-usb@vger.kernel.org Betreff: USB problem on beagleboard clone (PGP: Plain, Signed) Hi all, we've designed two beagle board clones (two different layouts) for a customer. After quite some time without any problems they are now seeing USB problems on some of the boards. I have so far not been able to reproduce the problem... The USB port of the OMAP the problems appear on is connected through a TPS65950 to a LAN9514 USB Hub + Ethernet Chip. Attached is the kernel output. I'm not even sure if this is related to our board, or if this might be a misbehaving device?! If someone has an idea what this could be and what I could do to fix or at least further debug the problem please speak up. I have never seen that error before on any of the boards I have. One question though, if the port is always Host, why are you using the OTG subsystem instead of the actual Host Subsystem which has an EHCI controller ? -- balbi I'm still on 3.3 but am planing to go to a newer version. We used the OTG port so we would not need another chip on a rather small board. And which chip are you talking about ? You already have LAN9514 on your board anyway... -- balbi signature.asc Description: Digital signature
AW: USB problem on beagleboard clone
-Ursprüngliche Nachricht- Von: Felipe Balbi [mailto:ba...@ti.com] Gesendet: Freitag, 14. September 2012 15:19 An: Maximilian Schwerin Cc: ba...@ti.com; linux-o...@vger.kernel.org; linux-usb@vger.kernel.org Betreff: Re: USB problem on beagleboard clone (PGP: Plain, Unable to verify signature) On Fri, Sep 14, 2012 at 03:21:47PM +0200, Maximilian Schwerin wrote: Hi, -Ursprüngliche Nachricht- Von: Felipe Balbi [mailto:ba...@ti.com] Gesendet: Freitag, 14. September 2012 15:08 An: Maximilian Schwerin Cc: linux-o...@vger.kernel.org; linux-usb@vger.kernel.org Betreff: Re: USB problem on beagleboard clone (PGP: Plain, Unable to verify signature) Hi, On Fri, Sep 14, 2012 at 02:57:49PM +0200, Maximilian Schwerin wrote: Sorry :-( With log now. -Ursprüngliche Nachricht- Von: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] Im Auftrag von Maximilian Schwerin Gesendet: Freitag, 14. September 2012 14:26 An: linux-o...@vger.kernel.org; linux-usb@vger.kernel.org Betreff: USB problem on beagleboard clone (PGP: Plain, Signed) Hi all, we've designed two beagle board clones (two different layouts) for a customer. After quite some time without any problems they are now seeing USB problems on some of the boards. I have so far not been able to reproduce the problem... The USB port of the OMAP the problems appear on is connected through a TPS65950 to a LAN9514 USB Hub + Ethernet Chip. Attached is the kernel output. I'm not even sure if this is related to our board, or if this might be a misbehaving device?! If someone has an idea what this could be and what I could do to fix or at least further debug the problem please speak up. I have never seen that error before on any of the boards I have. One question though, if the port is always Host, why are you using the OTG subsystem instead of the actual Host Subsystem which has an EHCI controller ? -- balbi I'm still on 3.3 but am planing to go to a newer version. We used the OTG port so we would not need another chip on a rather small board. And which chip are you talking about ? You already have LAN9514 on your board anyway... -- balbi How would I connect the OMAP to the LAN9514 without a PHY? m. pgpVYyiE5KsRk.pgp Description: PGP signature
Re: XHCI: URB not cancelled during disconnect of a MSC device
On Fri, 14 Sep 2012, Ajay Gupta wrote: Aborting URBs from within HCD after device disconnect is appropriate. right? Not really. The HCD shouldn't need to pay attention to the connect status while handling URBs. Instead, the HCD should abort URBs when they fail because the device doesn't send any packets. This could happen because of a disconnect, or it could happen because the device's firmware has crashed. The cause doesn't matter. 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] usb: serial: ftdi_sio: option to hide selected interfaces of multiple interfaces convertes
On Fri, 14 Sep 2012, Robert Ryszard Paciorek wrote: Add parametrs to hide some of converter interfaces against ftdi_sio driver. This allows on multiple-interfaces converter (such as ft2232, ft4232) use uart with kernel driver and use e.g. I2C or SPI (on other interface) with libusb or other kernel-driver. Using a module parameter for this sort of thing is generally a bad idea. What will happen if there are several FTDI devices plugged in? You might want to ignore the interfaces on some of them but not on others. 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: [RFC] Documentation update for Isochronous URB handling
On Fri, 14 Sep 2012, Pratyush Anand wrote: Pratyush, since you have been busily working on related issues for the dwc3, you might be interested in this too. Thanks for including me in CC. Whatever knowledge I have for the host software, this proposition seems correct to me. Okay, good. I was hoping you could make sure that the dwc3 driver implements the new behavior. Do you think that similar flag make sense in gadget framework too? Currently, gadget driver does not impose any restrictions on when to transmit a request by hardware, so peripheral driver always schedule as per its own criteria. That's an excellent question. I really don't know the answer. It should be discussed with gadget authors who use isochronous endpoints in their drivers. Also, Felipe might have some ideas. 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] usb: serial: ftdi_sio: option to hide selected interfaces of multiple interfaces convertes
Hi, Dnia Friday 14 September 2012 12:02, Sebastian Andrzej Siewior napisał: On Fri, Sep 14, 2012 at 10:04:02AM +, Robert Ryszard Paciorek wrote: Add parametrs to hide some of converter interfaces against ftdi_sio driver. This allows on multiple-interfaces converter (such as ft2232, ft4232) use uart with kernel driver and use e.g. I2C or SPI (on other interface) with libusb or other kernel-driver. Couldn't you instead do an unbind of that particular interface via sysfs? On one FT4232 chip is 4 uart interfaces. Two first uart can be configured as I2C, SPI, JTAG, etc. I can unbind only full usb device not single interfaces on devices. When I try unbind interface I get write error: No such device How do you pass that particular interface to your i2c / SPI? For example: In similar kernel module to ftdi_sio I can select only other interfaces. Configuration of FT4232 is per interfaces, so there should be no conflict. Method of elimination some interfaces by return ENODEV is used in this driver for dedicated JTAG port in some devices - see ftdi_jtag_probe() and ftdi_stmclite_probe() function. This patch allows use this same solution for user defined hardware. Signed-off-by: Robert Ryszard Paciorek r.pacio...@icm.edu.pl Sebastian Regards, Robert -- 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: serial: ftdi_sio: option to hide selected interfaces of multiple interfaces convertes
Hi, Dnia Friday 14 September 2012 13:43, Alan Stern napisał: On Fri, 14 Sep 2012, Robert Ryszard Paciorek wrote: Add parametrs to hide some of converter interfaces against ftdi_sio driver. This allows on multiple-interfaces converter (such as ft2232, ft4232) use uart with kernel driver and use e.g. I2C or SPI (on other interface) with libusb or other kernel-driver. Using a module parameter for this sort of thing is generally a bad idea. I was thinking about use sysfs, but module parameter working nice while booting system and load different drivers (e.g. autodecect other module for ignoring interfaces). What will happen if there are several FTDI devices plugged in? You might want to ignore the interfaces on some of them but not on others. Patch add second parametr, who determinate USB product name of device, whose interfaces we want to ignore. Regards, Robert Paciorek -- 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] staging: usbip: stub_dev: Fixed oops during removal of usbip_host
Hello. On 09/14/2012 04:36 PM, navin patidar wrote: hi Sergei, checkpatch.pl http://checkpatch.pl didn't complain any thing about patch coding style. checkpatch.pl only complains about // comments, IIRC. But see Documentation/CodingStyle chapter 8 about multi-line comments. As for adding spaces, it's more for aesthetic reasons... Anyway thanks for reviewing the patch. i will send this patch again with corrections. Thanks you. --navin-patidar 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: [PATCH] staging: usbip: stub_dev: Fixed oops during removal of usbip_host
On Fri, Sep 14, 2012 at 06:51:33PM +0530, navin patidar wrote: stub_device_reset should set kernel thread pointers to NULL. so that at the time of usbip_host removal stub_shoutdown_connection doesn't try to kill kernel threads which are already killed. If you wanted to put a sample Oops stack trace in here, that would always be welcome. It's not something to resend over. Just an idea. --- This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. --- I don't think this text is allowed on patches. This is a thing where you probably will need to resend the patch. regards, dan carpenter -- 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: tulip Ethernet driver messes up USB keyboard
On Fri, Sep 14, 2012 at 12:49:45PM +0300, Marti Raudsepp wrote: After installing an old 100Mbit PCI Ethernet card to my machine, it has complained a few times about spurious interrupts (nobody cared) at a random time of the day. After the oops is reported, my USB keyboard (HP smart card keyboard) stops working properly -- it has lots of delay, it misses some keystrokes and also causes stuck keys. Strangely enough my USB mouse continues to work without problems. Apparently the USB controller and the Ethernet card share an interrupt line. Un-/replugging the keyboard does not help. So far I have simply rebooted to fix the issue. I haven't been able to reproduce this on will despite my best attempts. The Ethernet card is driven by the tulip driver and is listed as ADMtek NC100 Network Everywhere Fast Ethernet 10/100 (rev 11) in lspci. My motherboard uses the Intel H77 chipset (ASRock H77 Pro4/MVP) This board uses the ASMedia ASM1083 PCIe-to-PCI bridge (or maybe ASM1085 - hard to see from photos available on the net, and the PCI IDs for these chips are the same), which is known to have problems with interrupt handling: https://lkml.org/lkml/2012/1/30/216 I experience the same problem with ASUS P8P67 LE (except in my case the interrupt is not shared with anything, and the network card does not stop working completely, just gives horrible performance with 100ms pings). Some people use noirqdebug irqpoll as a workaround: http://lkml.indiana.edu/hypermail/linux/kernel/1204.1/03451.html But this workaround basically turns off the protection against stuck interrupts in the kernel, so the system could potentially be busy handling a stuck interrupt forever. You can also try to move the PCI card to another slot, so that it would use another interrupt, which might be not shared with USB or another important device. signature.asc Description: Digital signature
Re: [PATCH] staging: usbip: stub_dev: Fixed oops during removal of usbip_host
On Fri, Sep 14, 2012 at 05:16:38PM +0300, Dan Carpenter wrote: I don't think this text is allowed on patches. Oh Oh Oh Dan, I think you crossed a line here. You were not one of the recipient and you reviewed and forwarded the email but you should have deleted this email instead. Now legal action will be taken… regards, dan carpenter Sebastian -- 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] staging: usbip: stub_dev: Fixed oops during removal of usbip_host
hi, I have sent this patch again with corrections. thank for reviewing the patch. --navin-patidar On 9/14/12, Sebastian Andrzej Siewior sebast...@breakpoint.cc wrote: On Fri, Sep 14, 2012 at 03:42:42PM +0400, Sergei Shtylyov wrote: diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/staging/usbip/stub_dev.c index 92ced35..f584af8 100644 --- a/drivers/staging/usbip/stub_dev.c +++ b/drivers/staging/usbip/stub_dev.c @@ -233,6 +230,13 @@ static void stub_device_reset(struct usbip_device *ud) dev_dbg(udev-dev, device reset); + /*reset tcp socket*/ Add spaces after /* and before */, please. + ud-tcp_socket = NULL; + + /*reset kernel thread pointers */ Here too. I'm not sure it is required to comment the obvious things. WBR, Sergei Sebastian -- 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: serial: ftdi_sio: option to hide selected interfaces of multiple interfaces convertes
On Fri, Sep 14, 2012 at 01:55:46PM +, Robert Ryszard Paciorek wrote: Hi, Dnia Friday 14 September 2012 12:02, Sebastian Andrzej Siewior napisał: On Fri, Sep 14, 2012 at 10:04:02AM +, Robert Ryszard Paciorek wrote: Add parametrs to hide some of converter interfaces against ftdi_sio driver. This allows on multiple-interfaces converter (such as ft2232, ft4232) use uart with kernel driver and use e.g. I2C or SPI (on other interface) with libusb or other kernel-driver. Couldn't you instead do an unbind of that particular interface via sysfs? On one FT4232 chip is 4 uart interfaces. Two first uart can be configured as I2C, SPI, JTAG, etc. I can unbind only full usb device not single interfaces on devices. When I try unbind interface I get write error: No such device So that is something you might want to change. However back to the SPI/I2C thingy. You ignore one uart port and decide to use it as SPI host right? So you should get a reference somehow to this port so you can register a SPI host to the system right? How do you do this? How do you pass that particular interface to your i2c / SPI? For example: In similar kernel module to ftdi_sio I can select only other interfaces. Configuration of FT4232 is per interfaces, so there should be no conflict. Method of elimination some interfaces by return ENODEV is used in this driver for dedicated JTAG port in some devices - see ftdi_jtag_probe() and ftdi_stmclite_probe() function. And how is this port used? I just see that interface is beeing ignored. Regards, Robert Sebastian -- 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] staging: usbip: stub_dev: Fixed oops during removal of usbip_host
On Fri, Sep 14, 2012 at 04:28:33PM +0200, Sebastian Andrzej Siewior wrote: On Fri, Sep 14, 2012 at 05:16:38PM +0300, Dan Carpenter wrote: I don't think this text is allowed on patches. Oh Oh Oh Dan, I think you crossed a line here. You were not one of the recipient and you reviewed and forwarded the email but you should have deleted this email instead. Now legal action will be taken… Oh crap! Well, it's a good thing I am a fully AWCP certified survivalist. I'm off to live in the mountains until the statute of limitations runs out. If you need me, then print your email out and leave it under a rock. regards, dan carpenter -- 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: serial: ftdi_sio: option to hide selected interfaces of multiple interfaces convertes
On Fri, Sep 14, 2012 at 02:06:52PM +, Robert Ryszard Paciorek wrote: Hi, Dnia Friday 14 September 2012 13:43, Alan Stern napisał: On Fri, 14 Sep 2012, Robert Ryszard Paciorek wrote: Add parametrs to hide some of converter interfaces against ftdi_sio driver. This allows on multiple-interfaces converter (such as ft2232, ft4232) use uart with kernel driver and use e.g. I2C or SPI (on other interface) with libusb or other kernel-driver. Using a module parameter for this sort of thing is generally a bad idea. I was thinking about use sysfs, but module parameter working nice while booting system and load different drivers (e.g. autodecect other module for ignoring interfaces). What will happen if there are several FTDI devices plugged in? You might want to ignore the interfaces on some of them but not on others. Patch add second parametr, who determinate USB product name of device, whose interfaces we want to ignore. No, sorry, no new module parameters, I'm trying to delete them wherever possible. And this really will not work, you want to be able to handle hundreds of devices at the same time, with the same driver. A module parameter will not work there. 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: USB enumeration issue with wireless modem
On Fri, Sep 14, 2012 at 02:39:56PM +, Harris, Jeff wrote: I am seeing an error enumerating a USB device when discovering a Sierra Wireless MC5728 wireless modem. I get a unable to enumerate USB device on port 1 message on the first attempt at discovery. However, there is always an immediate second attempt that succeeds. The modem appears to function correctly. I am using 2.6.33.1 with an ISP1520 hub on our embedded product. If I use the same modem on a different product that connects directly to the USB controller in a Freescale 8314 processor, I sometimes get the same behavior though much less frequently. I do not get the errors at all if I use an older MC5727 modem. You do realize just how old, and obsolete, that kernel version is, right? What happens with the 3.5 kernel? 3.6-rc5? If you are stuck at 2.6.33.1, please contact the vendor who provided it to you, as they are the only ones that can support it. 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: USB enumeration issue with wireless modem
On Fri, 14 Sep 2012, Harris, Jeff wrote: I am seeing an error enumerating a USB device when discovering a Sierra Wireless MC5728 wireless modem. I get a unable to enumerate USB device on port 1 message on the first attempt at discovery. However, there is always an immediate second attempt that succeeds. The modem appears to function correctly. As long as it's working you shouldn't worry about that message. I am using 2.6.33.1 with an ISP1520 hub on our embedded product. If I use the same modem on a different product that connects directly to the USB controller in a Freescale 8314 processor, I sometimes get the same behavior though much less frequently. I do not get the errors at all if I use an older MC5727 modem. When the failure occurs, the hub_port_wait_reset function is returning ENOTCONN after checking (portchange USB_PORT_STAT_C_CONNECTION). Is there anything to be done other than to try and nice-down the message or contact the manufacturer? I have usbmon traces for both modems if they would be helpful. You don't need to do anything. It's not broken, so it doesn't have to be fixed. 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: USB problem on beagleboard clone
Hi, On Fri, Sep 14, 2012 at 03:38:56PM +0200, Maximilian Schwerin wrote: I have never seen that error before on any of the boards I have. One question though, if the port is always Host, why are you using the OTG subsystem instead of the actual Host Subsystem which has an EHCI controller ? -- balbi I'm still on 3.3 but am planing to go to a newer version. We used the OTG port so we would not need another chip on a rather small board. And which chip are you talking about ? You already have LAN9514 on your board anyway... -- balbi How would I connect the OMAP to the LAN9514 without a PHY? Fair enough.. for whatever reason I assumed you had external PHY with MUSB. But seems like you're using the internal PHY... Anyway, please check with my tree (see MAINTAINERS file), either master branch or musb branch and let me know if you have the same behavior. -- balbi signature.asc Description: Digital signature
RE: USB enumeration issue with wireless modem
I am using 2.6.33.1 with an ISP1520 hub on our embedded product. If I use the same modem on a different product that connects directly to the USB controller in a Freescale 8314 processor, I sometimes get the same behavior though much less frequently. I do not get the errors at all if I use an older MC5727 modem. When the failure occurs, the hub_port_wait_reset function is returning ENOTCONN after checking (portchange USB_PORT_STAT_C_CONNECTION). Is there anything to be done other than to try and nice-down the message or contact the manufacturer? I have usbmon traces for both modems if they would be helpful. You don't need to do anything. It's not broken, so it doesn't have to be fixed. Ok. Thanks for the feedback. I realize our kernel is quite old, so I was looking for any sort of well-known fix that I could back-port. For what appears to be more of a warning in this case, I'll just nice down the message. Jeff -- 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] Increase XHCI suspend timeout to 16ms
The Intel XHCI specification says that after clearing the run/stop bit
the controller may take up to 16ms to halt. We've seen a device take
14ms, which with the current timeout of 10ms causes the kernel to
abort the suspend. Increasing the timeout to the recommended value
fixes the problem.
Signed-off-by: Michael Spang sp...@chromium.org
---
drivers/usb/host/xhci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index c59d5b5..7710ccf 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -785,7 +785,7 @@ int xhci_suspend(struct xhci_hcd *xhci)
command = ~CMD_RUN;
xhci_writel(xhci, command, xhci-op_regs-command);
if (handshake(xhci, xhci-op_regs-status,
- STS_HALT, STS_HALT, 100*100)) {
+ STS_HALT, STS_HALT, XHCI_MAX_HALT_USEC)) {
xhci_warn(xhci, WARN: xHC CMD_RUN timeout\n);
spin_unlock_irq(xhci-lock);
return -ETIMEDOUT;
--
1.7.7.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: f_uac2: why do you save two u8 in one u16?
On Fri, Sep 14, 2012 at 4:44 PM, Sebastian Andrzej Siewior
sebast...@breakpoint.cc wrote:
On Fri, Sep 14, 2012 at 12:53:56PM +0200, Sebastian Andrzej Siewior wrote:
looking at f_uac2.c I found this interresting piece of code:
|struct audio_dev {
| /* Currently active {Interface[15:8] | AltSettings[7:0]} */
| __u16 ac_alt, as_out_alt, as_in_alt;
| 
|};
|
| 
|#define ALT_SET(x, a) do {(x) = ~0xff; (x) |= (a); } while (0)
|#define ALT_GET(x) ((x) 0xff)
|#define INTF_SET(x, i) do {(x) = 0xff; (x) |= ((i) 8); } while (0)
|#define INTF_GET(x) ((x 8) 0xff)
| 
|ALT_SET(agdev-as_out_alt, 0);
|INTF_SET(agdev-as_out_alt, ret);
| 
Could one of you two explain to me why smashing two different things (an
interface number and an alternative setting number) into one variable
and using a Macro to seperate them again was a good idea?
I don't see Interface and its AltSetting as different as you do.
Another thing. alsa_uac2_init() calling platform_device_register() and
platform_driver_register()? Why is that helpful can't you just call
snd_uac2_probe() right away?
That is a common practice for virtual drivers (see
sound/drivers/dummy.c) and it helps assign the snd_card's struct
device *.
You have poor (read as non-existing) error recovery in case something
goes wrong during the allocation endpoint/interface/request.
Please be more specific.
What do I need to test this gadget?
insmod g_audio.ko on gadget
connect usb cable
A new sound card will appear on each the Host and the Gadget. Use is
just like any other sound card. Playback on side could be captured on
the other or routed to speakers if your h/w has them.
--
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: usb3 writes fail with transcend rdf8 + ASMedia ASM1042 woes
On Fri, Sep 14, 2012 at 12:49:59PM +0300, Sami Farin wrote: Hello, thanks for analyzing my logs =) I tried usb-next kernel. It works much better with sanXi reader (20120824111628.usmh54g2iv2yx...@m.safari.iki.fi for more info), though not very fast read/write speeds (can xhci debug slow it down?). Yes, xHCI debug can slow it down. The logs show it is running at USB 3.0 speeds, so if turning off debugging doesn't help, it may be the device is just not very fast. Or maybe the xHCI driver needs more performance tuning (although I have seen at least 200 MB/s with a 512KB block size with O_DIRECT to /dev/null). But with RDF8 reader I just got write errors pretty quickly after starting writing to the Transcend SDHC. With Sandisk card it works OK just like with older kernels. (Also, my Nikon D60 has no trouble accessing any of the cards.) dmesg-xhci.txt https://docs.google.com/file/d/0B_EMXtsx7o56Z2dFYnpUM05iNFk/edit The RDF8 reader just happened to successfully respond to the Set Address Device, and it looks like there's no xHCI errors, so I think the issue must be with the SCSI command responses. I'm not a SCSI expert, so maybe Alan has the time to take a look at them? usbmon-rdf8-usb3.txt https://docs.google.com/file/d/0B_EMXtsx7o56OWNSTEVkX2xkRnc/edit usbmon-rdf8-usb2.txt https://docs.google.com/file/d/0B_EMXtsx7o56ZUd1Tk9DR2xlTGM/edit 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: XHCI: URB not cancelled during disconnect of a MSC device
On Fri, Sep 14, 2012 at 09:41:12AM -0400, Alan Stern wrote: On Fri, 14 Sep 2012, Ajay Gupta wrote: Aborting URBs from within HCD after device disconnect is appropriate. right? Not really. The HCD shouldn't need to pay attention to the connect status while handling URBs. Instead, the HCD should abort URBs when they fail because the device doesn't send any packets. This could happen because of a disconnect, or it could happen because the device's firmware has crashed. The cause doesn't matter. Alan, by HCD, do you mean host controller driver, or the host hardware? I'm getting a bit confused here. :) What exactly would you have me do in the xHCI driver that's different from its current behavior? 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: Samsung SCX-3205 scanner does not work with Toshiba Satellite L855
On Thu, Sep 13, 2012 at 10:39:36AM -0400, Alan Stern wrote: On Wed, 12 Sep 2012, Sarah Sharp wrote: I don't think unbinding the xHCI driver will switch the ports back to EHCI, unless xhci_shutdown is called when the driver is unbound, and Michal has the recent bug fix commit e95829f474f0db3a4d940cae1423783edd966027 xhci: Switch PPT ports to EHCI on shutdown. Should this be changed? The ehci-hcd driver faces a similar situation; it shares ports with companion UHCI/OHCI controllers. The ports are switched over to EHCI at bind time and switched back during unbind. Without something like this, it's impossible to force the ports to attach the lower-speed controller when you want, and it's impossible to use the ports when the higher-speed driver isn't loaded. I really don't want the Intel port switchover to work like the EHCI companion controllers. It's really just a hardware hack to get around the lack of official Windows support, and I would really rather utilize it as little as possible. Supporting it has already been a giant pain in the neck, and for the last two release candidates, it seems like there's a patch or two fixing something broken with that code in every bug fix pull request I send Greg. Adding something similar to the EHCI companion controller switchover on module unload would just add further complexity. I would rather that the Intel xHCI systems work similar to a system with any other third party xHCI host controller: if you have the xHCI driver loaded, your ports work; if you don't have it loaded, it doesn't. 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: usb3 writes fail with transcend rdf8 + ASMedia ASM1042 woes
On Fri, Sep 14, 2012 at 12:01:36 -0700, Sarah Sharp wrote: On Fri, Sep 14, 2012 at 12:49:59PM +0300, Sami Farin wrote: Hello, thanks for analyzing my logs =) I tried usb-next kernel. It works much better with sanXi reader (20120824111628.usmh54g2iv2yx...@m.safari.iki.fi for more info), though not very fast read/write speeds (can xhci debug slow it down?). I forgot to tell this quirk was not enabled in usb-next [4.299978] usb-storage 2-1.5.3:1.0: Quirks match for vid 8564 pid 4000: 4000 (US_FL_BULK_IGNORE_TAG) Maybe it would have been happier with the RDF8.. Yes, xHCI debug can slow it down. The logs show it is running at USB 3.0 speeds, so if turning off debugging doesn't help, it may be the device is just not very fast. Or maybe the xHCI driver needs more performance tuning (although I have seen at least 200 MB/s with a 512KB block size with O_DIRECT to /dev/null). usbmon slowed by a factor of 2.6, so I started thinking.. Do you have ASMedia ASM1042 in some of your test machines? But with RDF8 reader I just got write errors pretty quickly after starting writing to the Transcend SDHC. With Sandisk card it works OK just like with older kernels. (Also, my Nikon D60 has no trouble accessing any of the cards.) dmesg-xhci.txt https://docs.google.com/file/d/0B_EMXtsx7o56Z2dFYnpUM05iNFk/edit The RDF8 reader just happened to successfully respond to the Set Address Device, and it looks like there's no xHCI errors, so I think the issue must be with the SCSI command responses. I'm not a SCSI expert, so maybe Alan has the time to take a look at them? usbmon-rdf8-usb3.txt https://docs.google.com/file/d/0B_EMXtsx7o56OWNSTEVkX2xkRnc/edit usbmon-rdf8-usb2.txt https://docs.google.com/file/d/0B_EMXtsx7o56ZUd1Tk9DR2xlTGM/edit Sarah Sharp -- Do what you love because life is too short for anything else. -- 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: Fresco Logic Problem
On Thu, Aug 30, 2012 at 11:51:54AM +0430, A Sh wrote: Hello Ms.Sharp Greetings! Do you go by A? Your mail signature isn't very clear. :) When I plug a usb Flash Drive or DVB-T to my USB 3.0 Port I get following and nothing happens(USB Device isn't Recognized): do_IRQ: 3.176 No irq handler for vector (irq -1) I'm using linux kernel 3.2.0-29-generic from official ubuntu precise (12.04) repository. The related parts of lspci -vvv, lsusb -vvv and dmesg outputs are(you can find the complete outputs in attachments): *-- lspci -vvv (related part):* 04:00.0 USB controller: Fresco Logic Device 1400 (rev 01) (prog-if 30 [XHCI]) Can you please send me the output of `sudo lspci -vvv -n`? I need the PCI vendor and device ID, which this version of lspci doesn't provide. I'm wondering if you have a Fresco Logic host that doesn't support MSI, even though it claims to (see the MSI field in the Capabilities lines): 04:00.0 USB controller: Fresco Logic Device 1400 (rev 01) (prog-if 30 [XHCI]) Subsystem: Device 1d5c:1000 Physical Slot: 3 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 51 Region 0: Memory at d460 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: feeff00c Data: 41b1 Capabilities: [80] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 2us, L1 32us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Kernel driver in use: xhci_hcd I think the dmesg shows that MSI is enabled for the host controller: [1.988493] xhci_hcd :04:00.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [1.988529] xhci_hcd :04:00.0: setting latency timer to 64 [1.988537] xhci_hcd :04:00.0: xHCI Host Controller [1.988604] xhci_hcd :04:00.0: new USB bus registered, assigned bus number 3 [2.109283] xhci_hcd :04:00.0: irq 19, io mem 0xd460 [2.109363] xhci_hcd :04:00.0: irq 51 for MSI/MSI-X But you're getting an unhandled IRQ, so this Fresco Logic may need a quirk like the previous generation to avoid MSI. I'll need the vendor and device ID from the lspci to generate a new patch for you to test. Do you know how to compile a custom kernel? If not, I'll send you some directions. 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: XHCI: URB not cancelled during disconnect of a MSC device
On Fri, 14 Sep 2012, Sarah Sharp wrote: On Fri, Sep 14, 2012 at 09:41:12AM -0400, Alan Stern wrote: On Fri, 14 Sep 2012, Ajay Gupta wrote: Aborting URBs from within HCD after device disconnect is appropriate. right? Not really. The HCD shouldn't need to pay attention to the connect status while handling URBs. Instead, the HCD should abort URBs when they fail because the device doesn't send any packets. This could happen because of a disconnect, or it could happen because the device's firmware has crashed. The cause doesn't matter. Alan, by HCD, do you mean host controller driver, or the host hardware? I'm getting a bit confused here. :) Well, both really. The hardware should get a low-level error when the device fails to respond, and when the driver sees the error it should complete the URB accordingly. I don't know if abort is the right word; maybe fault or exception would be better. Whatever you call it, the end result should be that when the device is unplugged, any URBs in flight should complete very quickly. What exactly would you have me do in the xHCI driver that's different from its current behavior? I don't know what changes xhci-hcd needs. But earlier in this thread Ajay posted a log that seemed to show an URB being submitted right around the same time the device was unplugged (maybe a little before, maybe a little after), and 30 seconds later the URB was still in progress. Here's what he wrote: === Non Working case [ 2971.576389] Port Status Change Event for port 2 [ 2971.576487] [E.f2d0c480. === URB submitted but no error. [ 2971.585007] get port status, actual port 1 status = 0x4202c0 [ 2971.585079] Get port status returned 0x4102c0 [ 2971.585178] clear port connect change, actual port 1 status = 0x4002c0 [ 2971.585213] clear port link state change, actual port 1 status = 0x2c0 [ 2971.640030] get port status, actual port 1 status = 0x2d1 [ 2971.640031] Get port status returned 0x2d1 [ 2971.696029] get port status, actual port 1 status = 0x2d1 [ 2971.696031] Get port status returned 0x2d1 [ 2971.900031] get port status, actual port 1 status = 0x2d1 [ 2971.900034] Get port status returned 0x2d1 [ 2972.060480] Port Status Change Event for port 2 [ 2972.104039] get port status, actual port 1 status = 0x2802a0 [ 2972.104041] Get port status returned 0x3002a0 [ 2972.104079] clear port reset change, actual port 1 status = 0x802a0 [ 2972.104108] clear port warm(BH) reset change, actual port 1 status = 0x2a0 [ 2972.104138] clear port link state change, actual port 1 status = 0x2a0 [ 2972.104144] usb 6-2: USB disconnect, device number 6 === 30 seconds gap [ 3002.080058] Cancel URB f2d0c480, dev 2, ep 0x81, starting at offset 0x337ad060 == SCSI layer cancelling URB after 30 seconds [ 3002.080063]// Ding dong! [ 2972.060569] Stopped on Transfer TRB [ 3002.080817] Removing canceled TD starting at 0x337ad060 (dma). [ 3002.080820] Finding segment containing stopped TRB. [ 3002.080822] Finding endpoint context [ 3002.080823] Finding segment containing last TRB in TD. [ 3002.080825] Cycle state = 0x0 [ 3002.080827] New dequeue segment = f71628f0 (virtual) [ 3002.080828] New dequeue pointer = 0x337ad070 (DMA) [ 3002.080831] Set TR Deq Ptr cmd, new deq seg = f71628f0 (0x337ad000 dma), new deq ptr = f37ad070 (0x337ad070 dma), new cycle = 0 = That doesn't seem right. 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
Lifetime of descriptors in f_fs
Hi Michał,
I'm looking at the life time of descriptors in each gadget and now I got to
f_fs which brings me to this chunk:
|static ssize_t ffs_ep0_write(struct file *file, const char __user *buf,
| size_t len, loff_t *ptr)
|{
…
| switch (ffs-state) {
| case FFS_READ_DESCRIPTORS:
| case FFS_READ_STRINGS:
| /* Copy data */
| if (unlikely(len 16)) {
| ret = -EINVAL;
| break;
| }
|
| data = ffs_prepare_buffer(buf, len);
data contians the a new allocated buffer with data from userland
| if (IS_ERR(data)) {
| ret = PTR_ERR(data);
| break;
| }
…
|if (ffs-state == FFS_READ_DESCRIPTORS) {
| pr_info(read descriptors\n);
| ret = __ffs_data_got_descs(ffs, data, len);
sets up descriptors and sets f-descriptors and f-hs_descriptors for composite
| if (unlikely(ret 0))
| break;
|
| ffs-state = FFS_READ_STRINGS;
| ret = len;
| } else {
| pr_info(read strings\n);
| ret = __ffs_data_got_strings(ffs, data, len);
the same thing for strings
| if (unlikely(ret 0))
| break;
…
|return len;
| }
| break;
…
| default:
| ret = -EBADFD;
| break;
| }
|
| mutex_unlock(ffs-mutex);
| return ret;
AAAand we are gone
| }
Based on this I'm sure that data is leaked on the error path (on return from
__ffs_data_got_descs() / __ffs_data_got_strings()) because I don't see any
kfree() like I do in the FFS_ACTIVE case.
Let's assume everything goes as planned. When are the descriptors which are
set to f-descriptors f-hs_descriptors kfree()d?
Sebastian
--
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: serial: ftdi_sio: option to hide selected interfaces of multiple interfaces convertes
Dnia Friday 14 September 2012 14:35, Sebastian Andrzej Siewior napisał: On Fri, Sep 14, 2012 at 01:55:46PM +, Robert Ryszard Paciorek wrote: Hi, Dnia Friday 14 September 2012 12:02, Sebastian Andrzej Siewior napisał: On Fri, Sep 14, 2012 at 10:04:02AM +, Robert Ryszard Paciorek wrote: Add parametrs to hide some of converter interfaces against ftdi_sio driver. This allows on multiple-interfaces converter (such as ft2232, ft4232) use uart with kernel driver and use e.g. I2C or SPI (on other interface) with libusb or other kernel-driver. Couldn't you instead do an unbind of that particular interface via sysfs? On one FT4232 chip is 4 uart interfaces. Two first uart can be configured as I2C, SPI, JTAG, etc. I can unbind only full usb device not single interfaces on devices. When I try unbind interface I get write error: No such device So that is something you might want to change. Maybe this is a better solution, especially considering aversion to do this by the module parameters. Or maybe it is better to give support for I2C, SPI to ftdi_sio module and use sysfs to switch betwen uart/ic2c/spi ... However back to the SPI/I2C thingy. You ignore one uart port and decide to use it as SPI host right? So you should get a reference somehow to this port so you can register a SPI host to the system right? How do you do this? I plan do this with other kernel module, matching to the same device, but serving other interface. I haven't complete module yet, but in first tests this concept works ok. Robert -- 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: Lifetime of descriptors in f_fs
On Fri, Sep 14 2012, Sebastian Andrzej Siewior wrote:
Hi Michał,
I'm looking at the life time of descriptors in each gadget and now I got to
f_fs which brings me to this chunk:
|static ssize_t ffs_ep0_write(struct file *file, const char __user *buf,
| size_t len, loff_t *ptr)
|{
…
| switch (ffs-state) {
| case FFS_READ_DESCRIPTORS:
| case FFS_READ_STRINGS:
| /* Copy data */
| if (unlikely(len 16)) {
| ret = -EINVAL;
| break;
| }
|
| data = ffs_prepare_buffer(buf, len);
data contians the a new allocated buffer with data from userland
| if (IS_ERR(data)) {
| ret = PTR_ERR(data);
| break;
| }
…
|if (ffs-state == FFS_READ_DESCRIPTORS) {
| pr_info(read descriptors\n);
| ret = __ffs_data_got_descs(ffs, data, len);
sets up descriptors and sets f-descriptors and f-hs_descriptors for
composite
static int __ffs_data_got_descs(struct ffs_data *ffs,
char *const _data, size_t len)
{
…
ffs-raw_fs_descs_length = fs_len;
ffs-raw_descs_length= fs_len + ret;
ffs-raw_descs = _data;
Saved for later.
ffs-fs_descs_count = fs_count;
ffs-hs_descs_count = hs_count;
return 0;
einval:
ret = -EINVAL;
error:
kfree(_data);
Freed on error path.
return ret;
}
| if (unlikely(ret 0))
| break;
|
| ffs-state = FFS_READ_STRINGS;
| ret = len;
| } else {
| pr_info(read strings\n);
| ret = __ffs_data_got_strings(ffs, data, len);
the same thing for strings
static int __ffs_data_got_strings(struct ffs_data *ffs,
char *const _data, size_t len)
{
…
/*
* If we don't need any strings just return and free all
* memory.
*/
if (!needed_count) {
kfree(_data);
Freed on quick exit.
return 0;
}
…
/* Done! */
ffs-stringtabs = stringtabs;
ffs-raw_strings = _data;
Saved for later.
return 0;
error_free:
kfree(stringtabs);
error:
kfree(_data);
Freed on error path.
return -EINVAL;
}
| if (unlikely(ret 0))
| break;
…
|return len;
| }
| break;
…
| default:
| ret = -EBADFD;
| break;
| }
|
| mutex_unlock(ffs-mutex);
| return ret;
AAAand we are gone
| }
And later:
static void ffs_data_clear(struct ffs_data *ffs)
{
ENTER();
if (test_and_clear_bit(FFS_FL_CALL_CLOSED_CALLBACK, ffs-flags))
functionfs_closed_callback(ffs);
BUG_ON(ffs-gadget);
if (ffs-epfiles)
ffs_epfiles_destroy(ffs-epfiles, ffs-eps_count);
kfree(ffs-raw_descs);
Free descs saved for later.
kfree(ffs-raw_strings);
Free strings saved for later.
kfree(ffs-stringtabs);
}
Based on this I'm sure that data is leaked on the error path (on return from
__ffs_data_got_descs() / __ffs_data_got_strings()) because I don't see any
kfree() like I do in the FFS_ACTIVE case.
Let's assume everything goes as planned. When are the descriptors which are
set to f-descriptors f-hs_descriptors kfree()d?
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
pgpWVeRnqzbkn.pgp
Description: PGP signature
Re: usb3 writes fail with transcend rdf8 + ASMedia ASM1042 woes
On Fri, 14 Sep 2012, Sami Farin wrote: I forgot to tell this quirk was not enabled in usb-next [4.299978] usb-storage 2-1.5.3:1.0: Quirks match for vid 8564 pid 4000: 4000 (US_FL_BULK_IGNORE_TAG) Maybe it would have been happier with the RDF8.. Yes, that definitely is part of the story. But even if that quirk had been present, something would have gone wrong. A write command failed. Maybe with the quirk we would know why it failed. Try again with the quirk enabled and see what happens. 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
[PATCH] USB: remove CONFIG_EXPERIMENTAL dependancies
From: Greg Kroah-Hartman gre...@linuxfoundation.org As discussed at the kernel summit this year, CONFIG_EXPERIMENTAL means nothing, so let's get rid of it. Cc: Kees Cook keesc...@chromium.org Cc: Felipe Balbi ba...@ti.com Cc: David Herrmann dh.herrm...@googlemail.com Cc: Hauke Mehrtens ha...@hauke-m.de Cc: Alan Stern st...@rowland.harvard.edu Cc: Neil Zhang zhan...@marvell.com Cc: Randy Dunlap rdun...@xenotime.net Cc: Fabio Estevam fabio.este...@freescale.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- drivers/usb/core/Kconfig |2 +- drivers/usb/gadget/Kconfig | 17 ++--- drivers/usb/host/Kconfig | 22 ++ drivers/usb/wusbcore/Kconfig |3 +-- 4 files changed, 18 insertions(+), 26 deletions(-) Any objections to me applying this patch to the usb-next branch? diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig index 9981984..f70c1a1 100644 --- a/drivers/usb/core/Kconfig +++ b/drivers/usb/core/Kconfig @@ -56,7 +56,7 @@ config USB_SUSPEND config USB_OTG bool OTG support - depends on USB EXPERIMENTAL + depends on USB depends on USB_SUSPEND default n help diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index a53be32..dfb51a4 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -557,7 +557,7 @@ config USB_ZERO_HNPTEST one serve as the USB host instead (in the B-Host role). config USB_AUDIO - tristate Audio Gadget (EXPERIMENTAL) + tristate Audio Gadget depends on SND select USB_LIBCOMPOSITE select SND_PCM @@ -672,8 +672,7 @@ config USB_G_NCM dynamically linked module called g_ncm. config USB_GADGETFS - tristate Gadget Filesystem (EXPERIMENTAL) - depends on EXPERIMENTAL + tristate Gadget Filesystem help This driver provides a filesystem based API that lets user mode programs implement a single-configuration USB device, including @@ -681,15 +680,11 @@ config USB_GADGETFS All endpoints, transfer speeds, and transfer types supported by the hardware are available, through read() and write() calls. - Currently, this option is still labelled as EXPERIMENTAL because - of existing race conditions in the underlying in-kernel AIO core. - Say y to link the driver statically, or m to build a dynamically linked module called gadgetfs. config USB_FUNCTIONFS - tristate Function Filesystem (EXPERIMENTAL) - depends on EXPERIMENTAL + tristate Function Filesystem select USB_LIBCOMPOSITE select USB_FUNCTIONFS_GENERIC if !(USB_FUNCTIONFS_ETH || USB_FUNCTIONFS_RNDIS) help @@ -799,8 +794,8 @@ config USB_G_SERIAL make MS-Windows work with CDC ACM. config USB_MIDI_GADGET - tristate MIDI Gadget (EXPERIMENTAL) - depends on SND EXPERIMENTAL + tristate MIDI Gadget + depends on SND select USB_LIBCOMPOSITE select SND_RAWMIDI help @@ -867,7 +862,7 @@ config USB_G_ACM_MS dynamically linked module called g_acm_ms. config USB_G_MULTI - tristate Multifunction Composite Gadget (EXPERIMENTAL) + tristate Multifunction Composite Gadget depends on BLOCK NET select USB_G_MULTI_CDC if !USB_G_MULTI_RNDIS select USB_LIBCOMPOSITE diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 13cd6d5..b1deb0f 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -18,8 +18,8 @@ config USB_C67X00_HCD module will be called c67x00. config USB_XHCI_HCD - tristate xHCI HCD (USB 3.0) support (EXPERIMENTAL) - depends on USB USB_ARCH_HAS_XHCI EXPERIMENTAL + tristate xHCI HCD (USB 3.0) support + depends on USB USB_ARCH_HAS_XHCI ---help--- The eXtensible Host Controller Interface (xHCI) is standard for USB 3.0 SuperSpeed host controller hardware. @@ -262,7 +262,7 @@ config USB_ISP116X_HCD config USB_ISP1760_HCD tristate ISP 1760 HCD support - depends on USB EXPERIMENTAL + depends on USB ---help--- The ISP1760 chip is a USB 2.0 host controller. @@ -376,7 +376,7 @@ config USB_OHCI_HCD_PCI config USB_OHCI_HCD_SSB bool OHCI support for Broadcom SSB OHCI core (DEPRECATED) - depends on USB_OHCI_HCD (SSB = y || SSB = USB_OHCI_HCD) EXPERIMENTAL + depends on USB_OHCI_HCD (SSB = y || SSB = USB_OHCI_HCD) select USB_HCD_SSB select USB_OHCI_HCD_PLATFORM default n @@ -414,7 +414,7 @@ config USB_CNS3XXX_OHCI config USB_OHCI_HCD_PLATFORM bool Generic OHCI driver for a platform device - depends on USB_OHCI_HCD EXPERIMENTAL + depends on USB_OHCI_HCD default n ---help--- Adds an OHCI host driver for a generic platform device, which @@ -424,7 +424,7 @@
