Re: [PATCH 2/5] usb: xhci: plat: Create both HCDs before adding them
fixed Kishon's id. On 21/04/15 12:49, Roger Quadros wrote: On 20/04/15 15:35, Mathias Nyman wrote: Hi On 02.04.2015 15:23, Roger Quadros wrote: As xhci_hcd is now allocated by usb_create_hcd(), we don't need to add the primary HCD before creating the shared HCD. Creating the shared HCD before adding the primary HCD is particularly useful for the OTG use case so that we know at the OTG core if the HCD is in single configuration or dual (primary + shared) configuration. This doesn't apply as commit 7b8ef22ea547b80475ac7feab06fb15e0fc143d8 usb: xhci: plat: Add USB phy support changed xhci-plat.c since. I rebased it, and the changed version is sitting in the for-usb-next branch in: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git But it appeared to me that usb_add_hcd() and usb_remove_hcd() will also call phy init and remove functions. As the order how hcds are created and added would change I'd need some more eyes on this to see if it will cause regression. Or maybe in the best case we could get rid of the Add USB phy support patch as we will call xhci_add_hcd() for the first hcd much later, and it could maybe init the phy for us? I thought usb_phy_*() stuff would be deprecated and we should use phy framework instead i.e. phy_init() and friends. In fact usb_add_hcd() is already handling the phy for us. So I'm in favor of getting rid of commit 7b8ef22ea547b80475ac7feab06fb15e0fc143d8 (usb: xhci: plat: Add USB phy support) cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: phy: msm: Use extcon framework for VBUS and ID detection
On Thu, 2015-04-09 at 11:34 +0300, Ivan T. Ivanov wrote: On recent Qualcomm platforms VBUS and ID lines are not routed to USB PHY LINK controller. Use extcon framework to receive connect and disconnect ID and VBUS notification. Signed-off-by: Ivan T. Ivanov iva...@linaro.org Hi Felipe, Did you have any comments on this and/or following patches? Regards, Ivan -- 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 v2 00/13] USB: OTG/DRD Core functionality
On 20/04/15 06:05, Peter Chen wrote: On Tue, Apr 14, 2015 at 01:41:47PM +0300, Roger Quadros wrote: This is an attempt to centralize OTG/Dual-role functionality in the kernel. As of now I've got Dual-role functionality working pretty reliably on dra7-evm. xhci side of things for OTG/DRD use are fixed in http://thread.gmane.org/gmane.linux.kernel/1923161 Hi Roger, Currently, there are two main problems for DRD/OTG framework. - For multi-platform supports, we may define CONFIG_USB_OTG, but the gadget should not add its otg descriptor to its configuration descriptors if it does not support one of otg features (SRP/HNP/ADP). Macpaul Lin's patch set [1] is the right way to do it. Agreed. That check (whether OTG descriptor can be added and which version of it) has to be done at runtime and it must be added only if hardware supports OTG _and_ kernel OTG support is enabled. Ok, let's put this patch set in mainline first, since your patch set may need some information from it. - We are lack of framework to handle OTG (DRD) switch, it is great you are designing it. The main problem for this framework is how to handle DRD/OTG FSM unify. My thought is we add two paths for them separate. For easy, I suggest if the platform supports one of otg features, then it goes to fully otg fsm, else it goes to simply otg fsm (like your drd fsm). If you agree with it too, you may not need to add another dr_mode value. It would be nice that way but unfortunately it does't work in all cases. e.g. What if the SoC itself supports all OTG features but the board is not designed for OTG. Or the product designer simply is not interested in full OTG support but just dual-role. So we need some flexibility for the device tree/platform-data to specify that. This is where a new dr_mode == dual- role is needed. Since dr_mode has been widely used now, if we add a new property for it, we need to change all drivers. Your OTG/DRD framework needs to (partial) use otg fsm, and we will not teach old driver to use it since there are some driver related stuffs. SRP/HNP/ADP support can be board level capabilities, and we may consider the otg device which does not support otg fsm (hardware finishes fsm). So I suggest we have below properties at dts: - otg-support /* fully otg support */ - otg-fsm-support /* fully otg fsm support */ - otg-ver /* eh otg supplement version */ - adp-support /* board adp support */ - srp-support /* board srp support */ - hnp-support /* board hnp support */ Currently, if CONFIG_USB_OTG and CONFIG_USB_OTG_FSM are enabled, we will have otg fsm code (usb-otg-fsm.c). if (otg-support otg-fsm-support) this device has fully otg support, and will follow full otg fsm transitions. else this device is drd, and will follow simple otg fsm transtions. Peter -- 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 v2 06/13] usb: hcd: Add hcd add/remove functions for OTG use
On 20/04/15 16:56, Alan Stern wrote: On Mon, 20 Apr 2015, Roger Quadros wrote: I don't understand this. Why do you want to defer the add/remove if the device is OTG? Don't host controller drivers expect these things to execute synchronously? Sorry for the wrong information. We actually defer only the add as the OTG state machine might not yet be in Host ready mode. The remove is always synchronous and we ensure that the HCD is removed when usb_otg_unregister_hcd() returns. That's okay then, but it does leave one potential hole. What happens if usb_add_hcd() is deferred for so long that usb_remove_hcd() gets called before the add can complete? We keep track of the HCD state in the OTG state machine and if it was not yet added then _usb_remove_hcd() is not called during usb_otg_unregister_hcd() in the usb_remove_hcd() call. cheers, -roger -- 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] Revert usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap
This reverts commit 70843f623b58 (usb: host: ehci-msm: Use
devm_ioremap_resource instead of devm_ioremap), because msm_otg
and this driver are using same address space to access AHB mode
and USB command registers.
Cc: Vivek Gautam gautam.vi...@samsung.com
Signed-off-by: Ivan T. Ivanov ivan.iva...@linaro.org
---
drivers/usb/host/ehci-msm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 9db74ca..275c92e 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -88,13 +88,20 @@ static int ehci_msm_probe(struct platform_device *pdev)
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- hcd-regs = devm_ioremap_resource(pdev-dev, res);
- if (IS_ERR(hcd-regs)) {
- ret = PTR_ERR(hcd-regs);
+ if (!res) {
+ dev_err(pdev-dev, Unable to get memory resource\n);
+ ret = -ENODEV;
goto put_hcd;
}
+
hcd-rsrc_start = res-start;
hcd-rsrc_len = resource_size(res);
+ hcd-regs = devm_ioremap(pdev-dev, hcd-rsrc_start, hcd-rsrc_len);
+ if (!hcd-regs) {
+ dev_err(pdev-dev, ioremap failed\n);
+ ret = -ENOMEM;
+ goto put_hcd;
+ }
/*
* OTG driver takes care of PHY initialization, clock management,
--
1.9.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
Re: [PATCH 2/5] usb: xhci: plat: Create both HCDs before adding them
On 20/04/15 15:35, Mathias Nyman wrote: Hi On 02.04.2015 15:23, Roger Quadros wrote: As xhci_hcd is now allocated by usb_create_hcd(), we don't need to add the primary HCD before creating the shared HCD. Creating the shared HCD before adding the primary HCD is particularly useful for the OTG use case so that we know at the OTG core if the HCD is in single configuration or dual (primary + shared) configuration. This doesn't apply as commit 7b8ef22ea547b80475ac7feab06fb15e0fc143d8 usb: xhci: plat: Add USB phy support changed xhci-plat.c since. I rebased it, and the changed version is sitting in the for-usb-next branch in: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git But it appeared to me that usb_add_hcd() and usb_remove_hcd() will also call phy init and remove functions. As the order how hcds are created and added would change I'd need some more eyes on this to see if it will cause regression. Or maybe in the best case we could get rid of the Add USB phy support patch as we will call xhci_add_hcd() for the first hcd much later, and it could maybe init the phy for us? I thought usb_phy_*() stuff would be deprecated and we should use phy framework instead i.e. phy_init() and friends. In fact usb_add_hcd() is already handling the phy for us. So I'm in favor of getting rid of commit 7b8ef22ea547b80475ac7feab06fb15e0fc143d8 (usb: xhci: plat: Add USB phy support) cheers, -roger -- 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] usbip: tools for userspace URBs transmission
On Tue, Apr 14, 2015 at 10:00 AM, Nobuo Iwata nobuo.iw...@fujixerox.co.jp wrote: diff --git a/tools/usb/usbip/libsrc/usbip_ux.h b/tools/usb/usbip/libsrc/usbip_ux.h new file mode 100644 index 000..7506a1c --- /dev/null +++ b/tools/usb/usbip/libsrc/usbip_ux.h +#include ../../../../include/uapi/linux/usbip_ux.h This is an absolute no-no. It is not mandatory that users have a kernel tree when compiling the userspace utility - for example, when they get the sources from their distro. Instead, that header will be included by the distro in the exported kernel headers you find in /usr/include. So you can just refer this as linux/usbip_ux.h but it won't be available until distros pick it up. -- 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: gadget: g_multi does not work with net2280
-Original Message- From: Ricardo Ribalda Delgado [mailto:ricardo.riba...@gmail.com] Sent: Tuesday, April 21, 2015 1:33 AM To: Praveen Murali Cc: linux-usb@vger.kernel.org; ba...@ti.com; min...@mina86.com Subject: Re: usb: gadget: g_multi does not work with net2280 Can you try with the latest kernel from linux-next? Yes, I will give it a shot. There are some patches from Mian Yousaf Kaukab yousaf.kau...@intel.com, that might be related to your problem Is it libcomposite where the fixes were made? Regards ps: Make sure your mail client works in text mode or you wont be able to send mails to the mailing list. Sorry about that, dint realize that my settings got reset; and I was wondering why the mail bounced :-) -- Ricardo Ribalda
Re: [RFC PATCH 0/3] Enable connecting DSA-based switch to the USB RMII interface.
I would however say that sysfs is the wrong API. The linux network stack uses netlink for most configuration activities. So i would suggest adding a netlink binding to DSA, and place the code in net/dsa/, not within an MDIO driver. I suppose we could do that, but that sounds like a pretty radical change in how DSA is currently configured (that is statically at boot time), part in order to allow booting from DSA-enabled network devices (e.g: nfsroot). We would keep both DT and platform device. But statically at boot does not work for a USB hotpluggable switch! Andrew -- 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 0/3] Enable connecting DSA-based switch to the USB RMII interface.
On 21/04/15 10:39, Andrew Lunn wrote: I would however say that sysfs is the wrong API. The linux network stack uses netlink for most configuration activities. So i would suggest adding a netlink binding to DSA, and place the code in net/dsa/, not within an MDIO driver. I suppose we could do that, but that sounds like a pretty radical change in how DSA is currently configured (that is statically at boot time), part in order to allow booting from DSA-enabled network devices (e.g: nfsroot). We would keep both DT and platform device. But statically at boot does not work for a USB hotpluggable switch! Is the switch really hotpluggable, or it is the USB-Ethernet adapter connecting to it? If the former, then I agree, if not, I would imagine that there is nothing that prevents creating the switch device first, and wait for its master_netdev to show up later before it starts doing anything useful? -- Florian -- 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 0/3] Enable connecting DSA-based switch to the USB RMII interface.
On 21/04/15 05:47, Andrew Lunn wrote: Hi Jan Interesting work, but i think the architecture is wrong. DSA needs an Ethernet device, an MDIO bus, and information about ports on the switch. That requirement is completely artificial as it is today, and just comes from arbitrary limitations imposed in the initial DSA design, something that I am still trying to get away from. The MDIO bus and the Ethernet need no knowledge of DSA. So putting your DSA configuration code in the MDIO driver is wrong. I agree with that. The problem you have is where the put the configuration data. There are the currently two choices, using a platform driver, which you can find some examples of in arch/arm/mach-orion5x, or via device tree. Or you need a new method. Part of your problem is hotplug, since you have a USB device, and no stable names for the ethernet device nor the MDIO device. Your hardware is not fixed, you could hang any switch off the USB device. So it does sound like you need a user space API. I would however say that sysfs is the wrong API. The linux network stack uses netlink for most configuration activities. So i would suggest adding a netlink binding to DSA, and place the code in net/dsa/, not within an MDIO driver. I suppose we could do that, but that sounds like a pretty radical change in how DSA is currently configured (that is statically at boot time), part in order to allow booting from DSA-enabled network devices (e.g: nfsroot). Device tree overlays might be a solution, if you can dynamically load a blob as part of a USB hotplug event. What makes it easier is that both the Ethernet device and MDIO bus are on the same USB device, so all your phandles are within the blob. What is your long term goal? Is this just a development tool? Are you thinking of making a product which integrates both the switch and the USB ethernet onto a USB dongle? This could also change the architecture, since it makes the configuration more fixed. My goal in reworking this weird DSA device/driver model is that you could just register your switch devices as an enhanced phy_driver/spi_driver/pci_driver etc..., such that libphy-ready drivers could just take advantage of that when they scan/detect their MDIO buses and find a switch. We are not quite there yet, but some help could be welcome, here are the WIP patches (tested with platform_driver only so far): https://github.com/ffainelli/linux/tree/dsa-model-b53 -- Florian -- 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 00/11] usbip: features to USB over WebSocket
Hi, Managed to go through your series and looks like you've spent some time on this. Good job! However, given the density of the patches, I haven't really been able to go through every line of code. I did do some basic testing and made some comments where needed. Shuah, Greg, do you think more thorought review is needed? Thanks, Valentina -- 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 0/3] Enable connecting DSA-based switch to the USB RMII interface.
On 21/04/15 10:30, Andrew Lunn wrote: My goal in reworking this weird DSA device/driver model is that you could just register your switch devices as an enhanced phy_driver/spi_driver/pci_driver etc..., such that libphy-ready drivers could just take advantage of that when they scan/detect their MDIO buses and find a switch. We are not quite there yet, but some help could be welcome, here are the WIP patches (tested with platform_driver only so far): We are hijacking another thread, but... I don't understand you here. Who calls dsa_switch_register()? Any driver which is backing the underlying device, if this is a PCI(e) switch, a pci_driver's probe function gets called, and then registers with DSA a switch device, very much like this: https://github.com/ffainelli/linux/commit/f94efc3d7b489955351c01efeafcc89939df388e I know of a board coming soon which has three switch chips on it. There is one MDIO device in the Soc, but there is an external MDIO multiplexor controlled via gpio lines, such that each switch has its own MDIO bus. The DT binding does not support this currently, but the underlying data structures do. How do you envisage dsa_switch_register() to work in such a setup? I would envision something where we can scan all of these switches individually using their respective device drivers, with the help of Device Tree or platform_data, figure out which position in a dsa_switch_tree they should have, and make sure that we create a dsa_switch_tree which reflects that, taking probe ordering into account. All of these switches would be phy_driver instances, like this: https://github.com/ffainelli/linux/commit/4a5c6b17de36377f6a71423b91f80bc1c7fee7be We can keep discussing the details in a separate thread, I think that would be useful. -- Florian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] drivers/usb/chipidea/debuc.c: avoid out of bound read
Hello Peter, thanks for reviewing. On 21.04.2015 03:32, Peter Chen wrote: On Fri, Apr 17, 2015 at 08:04:13AM +0200, Heinrich Schuchardt wrote: A string written by the user may not be zero terminated. sscanf may read memory beyond the buffer if no zero byte is found. Signed-off-by: Heinrich Schuchardt xypron.g...@gmx.de --- drivers/usb/chipidea/debug.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c index dfb05ed..ef08af3 100644 --- a/drivers/usb/chipidea/debug.c +++ b/drivers/usb/chipidea/debug.c @@ -88,9 +88,13 @@ static ssize_t ci_port_test_write(struct file *file, const char __user *ubuf, char buf[32]; int ret; -if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count))) +count = min_t(size_t, sizeof(buf) - 1, count); +if (copy_from_user(buf, ubuf, count)) return -EFAULT; Any reasons to change above? Otherwise we would have two lines with the term min_t(size_t, sizeof(buf) - 1, count). This would make the code harder to read. +/* sscanf requires a zero terminated string */ +buf[count] = 0; + I prefer using '\0' If you confirm the rest of the patch is ok, I will send an updated patch. Best regards Heinrich if (sscanf(buf, %u, mode) != 1) return -EINVAL; -- 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 04/11] usbip: kernel module for userspace URBs transmission
Looks ok. Valentina -- 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 0/3] Enable connecting DSA-based switch to the USB RMII interface.
My goal in reworking this weird DSA device/driver model is that you could just register your switch devices as an enhanced phy_driver/spi_driver/pci_driver etc..., such that libphy-ready drivers could just take advantage of that when they scan/detect their MDIO buses and find a switch. We are not quite there yet, but some help could be welcome, here are the WIP patches (tested with platform_driver only so far): We are hijacking another thread, but... I don't understand you here. Who calls dsa_switch_register()? I know of a board coming soon which has three switch chips on it. There is one MDIO device in the Soc, but there is an external MDIO multiplexor controlled via gpio lines, such that each switch has its own MDIO bus. The DT binding does not support this currently, but the underlying data structures do. How do you envisage dsa_switch_register() to work in such a setup? Thanks Andrew -- 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] usbip: readme about user space URBs transmission
Looks good. -- 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] Revert usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap
On Tue, 2015-04-21 at 16:46 +0530, Vivek Gautam wrote: Hi, On Tuesday, April 21, 2015 12:41 PM Ivan T. Ivanov iva...@linaro.org wrote: This reverts commit 70843f623b58 (usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap), because msm_otg and this driver are using same address space to access AHB mode and USB command registers. Cc: Vivek Gautam vi...@samsung.com Since ehci-msm and msm_otg both want to control few USB registers, it makes sense to request ioremap'ed region in both drivers. Acked-by: Vivek Gautam vi...@samsung.com I can see a patch in mailing list for adding both ehci-host and otg on msm [1]. But I think it has not yet made it to mainline kernel. [1] [v3,04/11] ARM: dts: apq8064: Add USB OTG support https://patches.linaro.org/47067/ Thanks. Ivan -- 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 3/3] driver/net/usb: Add support for DSA to ax88772b
Jan Kaisrlik kaisr...@fel.cvut.cz writes:
From: Jan Kaisrlik ja.kaisr...@gmail.com
This patch adds a possibility to use the RMII interface of the ax88772b
instead of the Ethernet PHY which is used now.
Binding DSA to a USB device is done via sysfs.
---
drivers/net/usb/asix.h | 7 ++
drivers/net/usb/asix_devices.c | 258
-
2 files changed, 261 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/asix.h b/drivers/net/usb/asix.h
index 5d049d0..6b1a5f5 100644
--- a/drivers/net/usb/asix.h
+++ b/drivers/net/usb/asix.h
@@ -174,6 +174,13 @@ struct asix_rx_fixup_info {
struct asix_common_private {
struct asix_rx_fixup_info rx_fixup_info;
+#ifdef CONFIG_NET_DSA
+ struct kobject kobj;
+ struct mii_bus *mdio;
+ int use_embphy;
+ bool dsa_up;
+ struct usbnet *dev;
+#endif
};
extern const struct driver_info ax88172a_info;
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index bf49792..57b3a34 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -35,6 +35,88 @@
#define PHY_MODE_RTL8211CL 0x000C
+#ifdef CONFIG_NET_DSA
+
+#define AX88772_RMII 0x02
+#define AX88772_MAX_PORTS 0x20
+#define MV88e6065_ID 0x0c89
+
+#include linux/phy.h
+#include net/dsa.h
+
+#define to_asix_obj(x) container_of(x, struct asix_common_private, kobj)
+#define to_asix_attr(x) container_of(x, struct asix_attribute, attr)
+
+static int mii_asix_read(struct mii_bus *bus, int phy_id, int regnum)
+{
+ return asix_mdio_read(((struct usbnet *)bus-priv)-net, phy_id,
regnum);
+}
+
+static int mii_asix_write(struct mii_bus *bus, int phy_id, int regnum, u16
val)
+{
+ asix_mdio_write(((struct usbnet *)bus-priv)-net, phy_id, regnum, val);
+ return 0;
+}
+
+static int ax88772_init_mdio(struct usbnet *dev){
+ struct asix_common_private *priv = dev-driver_priv;
+ int ret, i;
+
+ priv-mdio = mdiobus_alloc();
+ if (!priv-mdio) {
+ netdev_err(dev-net, Could not allocate mdio bus\n);
+ return -ENOMEM;
+ }
+
+ priv-mdio-priv = (void *)dev;
+ priv-mdio-read = mii_asix_read;
+ priv-mdio-write = mii_asix_write;
+ priv-mdio-name = ax88772 mdio bus;
+ priv-mdio-parent = dev-udev-dev;
+
+ /* mii bus name is usb-usb bus number-usb device number */
+ snprintf(priv-mdio-id, MII_BUS_ID_SIZE,
usb-%03d:%03d,dev-udev-bus-busnum, dev-udev-devnum);
+
+ priv-mdio-irq = kzalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
+ if (!priv-mdio-irq) {
+ ret = -ENOMEM;
+ goto free;
+ }
+
+ for (i = 0; i PHY_MAX_ADDR; i++)
+ priv-mdio-irq[i] = PHY_POLL;
+
+ ret = mdiobus_register(priv-mdio);
+ if (ret) {
+ netdev_err(dev-net, Could not register MDIO bus\n);
+ goto free_irq;
+ }
+
+ netdev_info(dev-net, registered mdio bus %s\n, priv-mdio-id);
+ return 0;
+
+free_irq:
+ kfree(priv-mdio-irq);
+free:
+ mdiobus_free(priv-mdio);
+ return ret;
+}
There is already identical code in drivers/net/usb/ax88172a.c. Any
chance these ASIX devices can share some code, or does it all have to be
duplicated for each new chip?
+// dsa_free(); TODO
Probably not like that...
+static ssize_t usb_dsa_store(struct asix_common_private *priv,
+ struct asix_attribute *attr, const char *buf, size_t count)
+{
+ ax88772_set_bind_dsa(priv);
+ return count;
+}
+
+static ssize_t usb_dsa_show(struct asix_common_private *priv,
+ struct asix_attribute *attr, char *buf)
+{
+ return scnprintf(buf, PAGE_SIZE, usb_dsa_binding.\n);
+}
I'm not sure I understand this at all. What kind of userspace API are
you trying to provide here? Maybe you could document these attributes
Documentation/ABI/testing/ to make it more clear?
+static void driver_release(struct kobject *kobj)
+{
+ pr_debug(driver: '%s': %s\n, kobject_name(kobj), __func__);
+// kfree(drv_priv); TODO free
+}
Ah, I guess you might have missed this section of
Documentation/kobject.txt ?:
One important point cannot be overstated: every kobject must have a
release() method, and the kobject must persist (in a consistent state)
until that method is called. If these constraints are not met, the
code is flawed. Note that the kernel will warn you if you forget to
provide a release() method. Do not try to get rid of this warning by
providing an empty release function; you will be mocked mercilessly
by the kobject maintainer if you attempt this.
Better CC Greg KH on your next attempt to make sure you get the mocking
you deserve :-)
+static ssize_t usb_dsa_attr_show(struct kobject *kobj,
+ struct attribute *attr,
+ char *buf)
+{
+ struct asix_attribute *attribute;
+ struct asix_common_private *priv;
+
+
Re: [RFC PATCH 0/3] Enable connecting DSA-based switch to the USB RMII interface.
Hi Jan Interesting work, but i think the architecture is wrong. DSA needs an Ethernet device, an MDIO bus, and information about ports on the switch. The MDIO bus and the Ethernet need no knowledge of DSA. So putting your DSA configuration code in the MDIO driver is wrong. The problem you have is where the put the configuration data. There are the currently two choices, using a platform driver, which you can find some examples of in arch/arm/mach-orion5x, or via device tree. Or you need a new method. Part of your problem is hotplug, since you have a USB device, and no stable names for the ethernet device nor the MDIO device. Your hardware is not fixed, you could hang any switch off the USB device. So it does sound like you need a user space API. I would however say that sysfs is the wrong API. The linux network stack uses netlink for most configuration activities. So i would suggest adding a netlink binding to DSA, and place the code in net/dsa/, not within an MDIO driver. Device tree overlays might be a solution, if you can dynamically load a blob as part of a USB hotplug event. What makes it easier is that both the Ethernet device and MDIO bus are on the same USB device, so all your phandles are within the blob. What is your long term goal? Is this just a development tool? Are you thinking of making a product which integrates both the switch and the USB ethernet onto a USB dongle? This could also change the architecture, since it makes the configuration more fixed. Andrew -- 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] Documentation usb serial: fixed how to provide vendor and product id
On Tue, Apr 21, 2015 at 01:57:05PM +0200, Bjørn Mork wrote: Johan Hovold jo...@kernel.org writes: On Mon, Apr 20, 2015 at 10:15:20PM +0200, Marek Belisko wrote: From: H. Nikolaus Schaller h...@goldelico.com The parameters vendor= and product= are only available if compiled as a kernel module Really? I believe you should be able to do usbserial.vendor=vid usbserial.product=pid on the command line if usbserial is built-in. Not that I recommend doing that. But it should work. You're right, the commit message is a little misleading, but the updated documentation is correct. The current text does not mention the option to pass module parameters on the kernel command line explicitly either. Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 00/13] USB: OTG/DRD Core functionality
On 21/04/15 09:04, Peter Chen wrote: On 20/04/15 06:05, Peter Chen wrote: On Tue, Apr 14, 2015 at 01:41:47PM +0300, Roger Quadros wrote: This is an attempt to centralize OTG/Dual-role functionality in the kernel. As of now I've got Dual-role functionality working pretty reliably on dra7-evm. xhci side of things for OTG/DRD use are fixed in http://thread.gmane.org/gmane.linux.kernel/1923161 Hi Roger, Currently, there are two main problems for DRD/OTG framework. - For multi-platform supports, we may define CONFIG_USB_OTG, but the gadget should not add its otg descriptor to its configuration descriptors if it does not support one of otg features (SRP/HNP/ADP). Macpaul Lin's patch set [1] is the right way to do it. Agreed. That check (whether OTG descriptor can be added and which version of it) has to be done at runtime and it must be added only if hardware supports OTG _and_ kernel OTG support is enabled. Ok, let's put this patch set in mainline first, since your patch set may need some information from it. - We are lack of framework to handle OTG (DRD) switch, it is great you are designing it. The main problem for this framework is how to handle DRD/OTG FSM unify. My thought is we add two paths for them separate. For easy, I suggest if the platform supports one of otg features, then it goes to fully otg fsm, else it goes to simply otg fsm (like your drd fsm). If you agree with it too, you may not need to add another dr_mode value. It would be nice that way but unfortunately it does't work in all cases. e.g. What if the SoC itself supports all OTG features but the board is not designed for OTG. Or the product designer simply is not interested in full OTG support but just dual-role. So we need some flexibility for the device tree/platform-data to specify that. This is where a new dr_mode == dual- role is needed. Since dr_mode has been widely used now, if we add a new property for it, we need to change all drivers. Your OTG/DRD framework needs to (partial) use otg fsm, and we will not teach old driver to use it since there are some driver related stuffs. fair enough. Let's not change dr_mode then and decide based on other parameters. SRP/HNP/ADP support can be board level capabilities, and we may consider the otg device which does not support otg fsm (hardware finishes fsm). So I suggest we have below properties at dts: - otg-support /* fully otg support */ - otg-fsm-support /* fully otg fsm support */ what is the difference between otg-support and otg-fsm-support? - otg-ver /* eh otg supplement version */ we can get otg version from the OTG controller. What exactly is the otg-ver in dts for? - adp-support /* board adp support */ - srp-support /* board srp support */ - hnp-support /* board hnp support */ So if these options are not provided in DTS but the OTG core supports them then we keep the respective feature disabled? Won't this need dts change for existing boards? Instead how about having disable flags instead. - adp-disable /* board doesn't support adp */ - srp-disable /* board doesn't support srp */ - hnp-disable /* board doesn't support hnp */ Now, if the flags are not provided in dts we use the OTG core's flags. Currently, if CONFIG_USB_OTG and CONFIG_USB_OTG_FSM are enabled, we will have otg fsm code (usb-otg-fsm.c). if (otg-support otg-fsm-support) this device has fully otg support, and will follow full otg fsm transitions. else this device is drd, and will follow simple otg fsm transtions. cheers, -roger -- 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] Documentation usb serial: fixed how to provide vendor and product id
On Mon, Apr 20, 2015 at 10:15:20PM +0200, Marek Belisko wrote: From: H. Nikolaus Schaller h...@goldelico.com While trying to test a Cinterion GSM/GPS/3G module I had reconfigured the USB interface by mistake and therefore needed to run a different USB driver than CDC-ACM. It turned out that I need the usbserial driver. This file is an official description how to use it: Documentation/usb/usb-serial.txt But it is outdated. The parameters vendor= and product= are only available if compiled as a kernel module and have been superseded by a /sys interface. Here was the solution: https://bbs.archlinux.org/viewtopic.php?id=175499 insmod usbserial vendor=0x product=0x becomes (first is vendor, second is product) modprobe usbserial echo /sys/bus/usb-serial/drivers/generic/new_id This patch changes the documentation file to describe the modern variant. Please note that the old one still works (if compiled as module). Signed-off-by: H. Nikolaus Schaller h...@goldelico.com Signed-off-by: Marek Belisko ma...@goldelico.com --- - fixed 2 sentences suggested by Johan Hovold Thanks for fixing this. Looks good now. Acked-by: Johan Hovold jo...@kernel.org Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] usb: xhci: plat: Create both HCDs before adding them
On Tue, Apr 21, 2015 at 12:49:54PM +0300, Roger Quadros wrote: On 20/04/15 15:35, Mathias Nyman wrote: Hi On 02.04.2015 15:23, Roger Quadros wrote: As xhci_hcd is now allocated by usb_create_hcd(), we don't need to add the primary HCD before creating the shared HCD. Creating the shared HCD before adding the primary HCD is particularly useful for the OTG use case so that we know at the OTG core if the HCD is in single configuration or dual (primary + shared) configuration. This doesn't apply as commit 7b8ef22ea547b80475ac7feab06fb15e0fc143d8 usb: xhci: plat: Add USB phy support changed xhci-plat.c since. I rebased it, and the changed version is sitting in the for-usb-next branch in: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git But it appeared to me that usb_add_hcd() and usb_remove_hcd() will also call phy init and remove functions. As the order how hcds are created and added would change I'd need some more eyes on this to see if it will cause regression. Or maybe in the best case we could get rid of the Add USB phy support patch as we will call xhci_add_hcd() for the first hcd much later, and it could maybe init the phy for us? I thought usb_phy_*() stuff would be deprecated and we should use phy framework instead i.e. phy_init() and friends. Except that all drivers have not been converted yet... So it's not really an option until then. In fact usb_add_hcd() is already handling the phy for us. If it handles USB phy, then I don't really have an issue with it. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: usb: gadget: g_multi does not work with net2280
Can you try with the latest kernel from linux-next? There are some patches from Mian Yousaf Kaukab yousaf.kau...@intel.com, that might be related to your problem Regards ps: Make sure your mail client works in text mode or you wont be able to send mails to the mailing list. On Tue, Apr 21, 2015 at 2:39 AM, Praveen Murali pmur...@logicube.com wrote: Hi Ricardo, I am trying to get the g_multi gadget driver to work on a PLX 3380 chip (using net2280 driver). For some reason, when I connect my device to a Windows PC, although it shows up the RNDIS and mass storage endpoints, it does not seem to be able to activate either of them. I am using linux.inf from Documentation/usb to configure the RNDIS interface on my Windows PC. However, it works fine on a Linux PC. Following are some experiments I have tried with limited success 1. When I remove all interfaces, other than RNDIS ones from the g_multi driver and comment out the special handling for net2280 interrupt transfer endpoints in epautoconf.c-usb_ep_autoconfig_ss(), the RNDIS interface gets activated properly; at this stage I can assign IP addresses’s and communicate. 2. When I remove all interfaces, other than the mass storage one from the g_multi driver, the mass storage device shows up properly on Windows host. 3. If I comment out the special handling for net2280 interrupt transfer endpoints in epautoconf.c-usb_ep_autoconfig_ss() but keep all interfaces in g_multi, even though the interfaces show up on Windows host, they cannot be activated (trying to install the linux.inf results in a “cannot start device code 10” error). I started with a 3.16.7-ckt4 kernel and ported the USB338x driver from PLX website; that did not work. So, I now I am testing with the 4.0 release. At this point, it looks like an either/or for me. Is there something I am missing here? Let me know if you need any logs for this. Thanks, Praveen -- Ricardo Ribalda -- 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 v2 1/3] uas: Allow uas_use_uas_driver to return usb-storage flags
uas_use_uas_driver may set some US_FL_foo flags during detection, currently
these are stored in a local variable and then throw away, but these may be
of interest to the caller, so add an extra parameter to (optionally) return
the detected flags, and use this in the uas driver.
Cc: sta...@vger.kernel.org # 3.16
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Add Cc stable@vger
---
drivers/usb/storage/uas-detect.h | 6 +-
drivers/usb/storage/uas.c| 6 +++---
drivers/usb/storage/usb.c| 2 +-
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/storage/uas-detect.h b/drivers/usb/storage/uas-detect.h
index 9893d69..63ae161 100644
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -51,7 +51,8 @@ static int uas_find_endpoints(struct usb_host_interface *alt,
}
static int uas_use_uas_driver(struct usb_interface *intf,
- const struct usb_device_id *id)
+ const struct usb_device_id *id,
+ unsigned long *flags_ret)
{
struct usb_host_endpoint *eps[4] = { };
struct usb_device *udev = interface_to_usbdev(intf);
@@ -132,5 +133,8 @@ static int uas_use_uas_driver(struct usb_interface *intf,
return 0;
}
+ if (flags_ret)
+ *flags_ret = flags;
+
return 1;
}
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 6cdabdc..c6109c1 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -887,8 +887,9 @@ static int uas_probe(struct usb_interface *intf, const
struct usb_device_id *id)
struct Scsi_Host *shost = NULL;
struct uas_dev_info *devinfo;
struct usb_device *udev = interface_to_usbdev(intf);
+ unsigned long dev_flags;
- if (!uas_use_uas_driver(intf, id))
+ if (!uas_use_uas_driver(intf, id, dev_flags))
return -ENODEV;
if (uas_switch_interface(udev, intf))
@@ -910,8 +911,7 @@ static int uas_probe(struct usb_interface *intf, const
struct usb_device_id *id)
devinfo-udev = udev;
devinfo-resetting = 0;
devinfo-shutdown = 0;
- devinfo-flags = id-driver_info;
- usb_stor_adjust_quirks(udev, devinfo-flags);
+ devinfo-flags = dev_flags;
init_usb_anchor(devinfo-cmd_urbs);
init_usb_anchor(devinfo-sense_urbs);
init_usb_anchor(devinfo-data_urbs);
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index 5600c33..db6f6b5 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -1080,7 +1080,7 @@ static int storage_probe(struct usb_interface *intf,
/* If uas is enabled and this device can do uas then ignore it. */
#if IS_ENABLED(CONFIG_USB_UAS)
- if (uas_use_uas_driver(intf, id))
+ if (uas_use_uas_driver(intf, id, NULL))
return -ENXIO;
#endif
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] uas: Add US_FL_MAX_SECTORS_240 flag
The usb-storage driver sets max_sectors = 240 in its scsi-host template,
for uas we do not want to do that for all devices, but testing has shown
that some devices need it.
This commit adds a US_FL_MAX_SECTORS_240 flag for such devices, and
implements support for it in uas.c, while at it it also adds support
for US_FL_MAX_SECTORS_64 to uas.c.
Cc: sta...@vger.kernel.org # 3.16
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Document new 'g' flag in kernel-parameters.txt
-Add Cc stable@vger
---
Documentation/kernel-parameters.txt | 2 ++
drivers/usb/storage/uas.c | 10 +-
drivers/usb/storage/usb.c | 6 +-
include/linux/usb_usual.h | 2 ++
4 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 274252f..4ddf5b5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3774,6 +3774,8 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
READ_CAPACITY_16 command);
f = NO_REPORT_OPCODES (don't use report opcodes
command, uas only);
+ g = MAX_SECTORS_240 (don't transfer more than
+ 240 sectors at a time, uas only);
h = CAPACITY_HEURISTICS (decrease the
reported device capacity by one
sector if the number is odd);
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index c6109c1..6d3122a 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -759,7 +759,10 @@ static int uas_eh_bus_reset_handler(struct scsi_cmnd *cmnd)
static int uas_slave_alloc(struct scsi_device *sdev)
{
- sdev-hostdata = (void *)sdev-host-hostdata;
+ struct uas_dev_info *devinfo =
+ (struct uas_dev_info *)sdev-host-hostdata;
+
+ sdev-hostdata = devinfo;
/* USB has unusual DMA-alignment requirements: Although the
* starting address of each scatter-gather element doesn't matter,
@@ -778,6 +781,11 @@ static int uas_slave_alloc(struct scsi_device *sdev)
*/
blk_queue_update_dma_alignment(sdev-request_queue, (512 - 1));
+ if (devinfo-flags US_FL_MAX_SECTORS_64)
+ blk_queue_max_hw_sectors(sdev-request_queue, 64);
+ else if (devinfo-flags US_FL_MAX_SECTORS_240)
+ blk_queue_max_hw_sectors(sdev-request_queue, 240);
+
return 0;
}
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index db6f6b5..6c10c88 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -479,7 +479,8 @@ void usb_stor_adjust_quirks(struct usb_device *udev,
unsigned long *fflags)
US_FL_SINGLE_LUN | US_FL_NO_WP_DETECT |
US_FL_NO_READ_DISC_INFO | US_FL_NO_READ_CAPACITY_16 |
US_FL_INITIAL_READ10 | US_FL_WRITE_CACHE |
- US_FL_NO_ATA_1X | US_FL_NO_REPORT_OPCODES);
+ US_FL_NO_ATA_1X | US_FL_NO_REPORT_OPCODES |
+ US_FL_MAX_SECTORS_240);
p = quirks;
while (*p) {
@@ -520,6 +521,9 @@ void usb_stor_adjust_quirks(struct usb_device *udev,
unsigned long *fflags)
case 'f':
f |= US_FL_NO_REPORT_OPCODES;
break;
+ case 'g':
+ f |= US_FL_MAX_SECTORS_240;
+ break;
case 'h':
f |= US_FL_CAPACITY_HEURISTICS;
break;
diff --git a/include/linux/usb_usual.h b/include/linux/usb_usual.h
index a7f2604..7f5f78b 100644
--- a/include/linux/usb_usual.h
+++ b/include/linux/usb_usual.h
@@ -77,6 +77,8 @@
/* Cannot handle ATA_12 or ATA_16 CDBs */ \
US_FLAG(NO_REPORT_OPCODES, 0x0400) \
/* Cannot handle MI_REPORT_SUPPORTED_OPERATION_CODES */ \
+ US_FLAG(MAX_SECTORS_240,0x0800) \
+ /* Sets max_sectors to 240 */ \
#define US_FLAG(name, value) US_FL_##name = value ,
enum { US_DO_ALL_FLAGS };
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] uas: Set max_sectors_240 quirk for ASM1053 devices
Testing has shown that ASM1053 devices do not work properly with transfers
larger than 240 sectors, so set max_sectors to 240 on these.
Cc: sta...@vger.kernel.org # 3.16
Reported-by: Steve Bangert sbang...@frontier.com
Signed-off-by: Hans de Goede hdego...@redhat.com
Tested-by: Steve Bangert sbang...@frontier.com
---
Changes in v2:
-Add Cc stable@vger
-Add Tested-by tag
---
drivers/usb/storage/uas-detect.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/storage/uas-detect.h b/drivers/usb/storage/uas-detect.h
index 63ae161..f58caa9 100644
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -74,7 +74,7 @@ static int uas_use_uas_driver(struct usb_interface *intf,
* this writing the following versions exist:
* ASM1051 - no uas support version
* ASM1051 - with broken (*) uas support
-* ASM1053 - with working uas support
+* ASM1053 - with working uas support, but problems with large xfers
* ASM1153 - with working uas support
*
* Devices with these chips re-use a number of device-ids over the
@@ -104,6 +104,9 @@ static int uas_use_uas_driver(struct usb_interface *intf,
} else if (usb_ss_max_streams(eps[1]-ss_ep_comp) == 32) {
/* Possibly an ASM1051, disable uas */
flags |= US_FL_IGNORE_UAS;
+ } else {
+ /* ASM1053, these have issues with large transfers */
+ flags |= US_FL_MAX_SECTORS_240;
}
}
--
2.3.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: Polling a usbfs file descriptor.
On Mon, 20 Apr 2015, Dave Mielke wrote: It seems (from inspecting libusb) that poll()ing a usbfs file descriptor for output can be used to determine when a urb can be reaped. A user has sent me a patch to our code that does this, and it actually does seem to work. So far, I haven't found any documentation on this. Is it okay for us to use this capability? Yes, it's okay. A userspace ABI like that isn't going to go away. It's also true that you can poll for POLLERR or POLLHUP to see when a device has been disconnected, although libusb probably isn't interested in doing that. Can anyone point me to documentation that formally describes how it works? As far as I can see, there isn't any documentation for usbfs at all apart from Documentation/usb/proc_usb_info.txt, which is woefully out of date. 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 v2 1/3] uas: Allow uas_use_uas_driver to return usb-storage flags
On Tue, 21 Apr 2015, Hans de Goede wrote: uas_use_uas_driver may set some US_FL_foo flags during detection, currently these are stored in a local variable and then throw away, but these may be of interest to the caller, so add an extra parameter to (optionally) return the detected flags, and use this in the uas driver. Cc: sta...@vger.kernel.org # 3.16 Signed-off-by: Hans de Goede hdego...@redhat.com For this whole series: Acked-by: Alan Stern st...@rowland.harvard.edu -- 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 irq event bogus return value ffffff94
On Tue, 21 Apr 2015, Joe Lawrence wrote: On 04/21/2015 08:21 AM, Mathias Nyman wrote: [...] On the other hand if we just removed xhci, and share the interrupt with somebody else who is also generating an interrupts, then we would probably continue to read 0x from the status reg and should return IRQ_NONE. Yes, I think this was Sergei's concern as well and IRQ_NONE is probably the safer value on a shared line. Unfortunately ehci-hcd.c, fotg210-hcd.c, fusbh200-hcd.c, ohci-hcd.c, oxu210hp-hcd.c all return dead controller irq with IRQ_HANDLED. I don't have all that hardware to test a change across the board. :( I don't have all that hardware either, but changing them sounds like a good idea. I will take care of it. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pl2303: Remove antiquated support for I330 phone
Samsung has just released a portable USB3 SSD, coming in a very small
and nice form factor. It's USB ID is 04e8:8001, which unfortunately is
already used by the pl2303 USB serial driver for the Samsung I330 phone
cradle. This phone was manufactured in 2001, and I seriously doubt it is
still in use on any contemporary networks. Having pl2303 pick up this
device ID results in conflicts with the usb-storage driver, which
handles the newly released portable USB3 SSD. In this patch I remove the
device ID of the old antiquated telephone from the pl2303 driver, so
that usb-storage can handle it.
Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com
---
drivers/usb/serial/pl2303.c | 1 -
drivers/usb/serial/pl2303.h | 4
2 files changed, 5 deletions(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 829604d..f5257af 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -61,7 +61,6 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(DCU10_VENDOR_ID, DCU10_PRODUCT_ID) },
{ USB_DEVICE(SITECOM_VENDOR_ID, SITECOM_PRODUCT_ID) },
{ USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_ID) },
- { USB_DEVICE(SAMSUNG_VENDOR_ID, SAMSUNG_PRODUCT_ID) },
{ USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_SX1),
.driver_info = PL2303_QUIRK_UART_STATE_IDX0 },
{ USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_X65),
diff --git a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h
index 71fd9da..e3b7af8 100644
--- a/drivers/usb/serial/pl2303.h
+++ b/drivers/usb/serial/pl2303.h
@@ -62,10 +62,6 @@
#define ALCATEL_VENDOR_ID 0x11f7
#define ALCATEL_PRODUCT_ID 0x02df
-/* Samsung I330 phone cradle */
-#define SAMSUNG_VENDOR_ID 0x04e8
-#define SAMSUNG_PRODUCT_ID 0x8001
-
#define SIEMENS_VENDOR_ID 0x11f5
#define SIEMENS_PRODUCT_ID_SX1 0x0001
#define SIEMENS_PRODUCT_ID_X65 0x0003
--
2.3.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: default value of power/wakeup
On Tue, 21 Apr 2015, Tom Yan wrote: On 21 April 2015 at 03:44, Alan Stern st...@rowland.harvard.edu wrote: The generic driver includes code for enabling wakeup by default, Is there a part of code which can shows this? It seems to me that the usbhid module is loaded for all USB HID devices, so I doubt a bit: [tom@localhost ~]$ journalctl -b -1 | grep hid Apr 21 05:00:36 localhost kernel: hidraw: raw HID events driver (C) Jiri Kosina Apr 21 05:00:36 localhost kernel: usbcore: registered new interface driver usbhid Apr 21 05:00:36 localhost kernel: usbhid: USB HID core driver Apr 21 05:00:36 localhost kernel: hid-generic 0003:046D:C52E.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-:00:14.0-14/input0 Apr 21 05:00:36 localhost kernel: hid-generic 0003:046D:C52E.0002: input,hiddev0,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-:00:14.0-14/input1 [tom@localhost ~]$ journalctl -b -2 | grep hid Apr 21 04:59:58 localhost kernel: hidraw: raw HID events driver (C) Jiri Kosina Apr 21 04:59:58 localhost kernel: usbcore: registered new interface driver usbhid Apr 21 04:59:58 localhost kernel: usbhid: USB HID core driver Apr 21 04:59:58 localhost kernel: logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-:00:14.0-13/input2 Apr 21 04:59:58 localhost kernel: logitech-hidpp-device 0003:046D:4024.0004: input,hidraw1: USB HID v1.11 Keyboard [Logitech K400] on usb-:00:14.0-13:1 [tom@localhost ~]$ lsusb -t /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M |__ Port 13: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 13: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 13: Dev 2, If 2, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 14: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 14: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M You see this because logitech_djreceiver overrides the setting of the ll_driver field in struct hid_device. Briefly, usbhid/hid-core.c initializes the wakeup setting in usbhid_start(), which is the .start member of usb_hid_driver, which is assigned (in usbhid_probe()) to hid-ll_driver. But the logi_dj_recv_add_djhid_device() routine in hid-logitech-dj.c changes dj_hiddev-ll_driver to logi_dj_ll_driver, and its .start member is logi_dj_ll_start(), which does not initialize the wakeup setting. Since usbhid_start() never gets called, the device doesn't get enabled for wakeup. See the logi_dj_probe() routine for more details about how this works. 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] Revert usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap
On Tue, 21 Apr 2015, Ivan T. Ivanov wrote:
This reverts commit 70843f623b58 (usb: host: ehci-msm: Use
devm_ioremap_resource instead of devm_ioremap), because msm_otg
and this driver are using same address space to access AHB mode
and USB command registers.
Um, this patch is in fact _not_ a reversion of 70843f623b58. That
commit removed 4 lines of code and added 3. If this were truly a
reversion, it would remove 3 lines and add 4. Instead it adds 10.
Please make this a true reversion.
Alan Stern
Cc: Vivek Gautam gautam.vi...@samsung.com
Signed-off-by: Ivan T. Ivanov ivan.iva...@linaro.org
---
drivers/usb/host/ehci-msm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 9db74ca..275c92e 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -88,13 +88,20 @@ static int ehci_msm_probe(struct platform_device *pdev)
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- hcd-regs = devm_ioremap_resource(pdev-dev, res);
- if (IS_ERR(hcd-regs)) {
- ret = PTR_ERR(hcd-regs);
+ if (!res) {
+ dev_err(pdev-dev, Unable to get memory resource\n);
+ ret = -ENODEV;
goto put_hcd;
}
+
hcd-rsrc_start = res-start;
hcd-rsrc_len = resource_size(res);
+ hcd-regs = devm_ioremap(pdev-dev, hcd-rsrc_start, hcd-rsrc_len);
+ if (!hcd-regs) {
+ dev_err(pdev-dev, ioremap failed\n);
+ ret = -ENOMEM;
+ goto put_hcd;
+ }
/*
* OTG driver takes care of PHY initialization, clock management,
--
1.9.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
Re: [PATCH v2] Documentation usb serial: fixed how to provide vendor and product id
Johan Hovold jo...@kernel.org writes: On Mon, Apr 20, 2015 at 10:15:20PM +0200, Marek Belisko wrote: From: H. Nikolaus Schaller h...@goldelico.com The parameters vendor= and product= are only available if compiled as a kernel module Really? I believe you should be able to do usbserial.vendor=vid usbserial.product=pid on the command line if usbserial is built-in. Not that I recommend doing that. But it should work. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 11/11] usbip: USB over WebSocket
Nobuo Iwata nobuo.iw...@fujixerox.co.jp writes:
Implementation of this patch depends on Poco C++
(http://pocoproject.org/).
Really? Is that OK?
--- /dev/null
+++ b/tools/usb/usbip/websocket/COPYING
This cannot possibly be necessary. Pointing to the toplevel COPYING
file should be more than enough, if anything at all.
And BTW, the same goes for the tools/usb/usbip/COPYING that seems to
have snuck in somehow. I also wonder a bit about the AUTHORS file both
places. We have git and MAINTAINERS for such things, don't we?
--- /dev/null
+++ b/tools/usb/usbip/websocket/configure.ac
@@ -0,0 +1,61 @@
+dnl Process this file with autoconf to produce a configure script.
+
+AC_PREREQ(2.59)
+AC_INIT([usbip-utils], [1.1.1], [linux-usb@vger.kernel.org])
+AC_DEFINE([USBIP_VERSION], [0x0111], [binary-coded decimal version
number])
This should either use the upper level definitions or have its own
namespace. Defining the same symbols at different levels is a recipe
for confusion. In fact, you are already out of sync with the
definitions in tools/usb/usbip/configure.ac
+extern C {
+#include usbip_common.h
+#include usbip_host_driver.h
+#include usbip.h
+}
+
+using namespace ::Poco;
+using namespace ::Poco::Net;
+using namespace ::Poco::Util;
+using namespace ::Usbip::WebSock::Poco;
Yuck. Any reason this cannot be written in C?
Bjørn
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] usb: xhci: plat: Create both HCDs before adding them
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21/04/15 11:08, Maxime Ripard wrote: On Tue, Apr 21, 2015 at 12:49:54PM +0300, Roger Quadros wrote: On 20/04/15 15:35, Mathias Nyman wrote: Hi On 02.04.2015 15:23, Roger Quadros wrote: As xhci_hcd is now allocated by usb_create_hcd(), we don't need to add the primary HCD before creating the shared HCD. Creating the shared HCD before adding the primary HCD is particularly useful for the OTG use case so that we know at the OTG core if the HCD is in single configuration or dual (primary + shared) configuration. This doesn't apply as commit 7b8ef22ea547b80475ac7feab06fb15e0fc143d8 usb: xhci: plat: Add USB phy support changed xhci-plat.c since. I rebased it, and the changed version is sitting in the for-usb-next branch in: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git But it appeared to me that usb_add_hcd() and usb_remove_hcd() will also call phy init and remove functions. As the order how hcds are created and added would change I'd need some more eyes on this to see if it will cause regression. Or maybe in the best case we could get rid of the Add USB phy support patch as we will call xhci_add_hcd() for the first hcd much later, and it could maybe init the phy for us? I thought usb_phy_*() stuff would be deprecated and we should use phy framework instead i.e. phy_init() and friends. Except that all drivers have not been converted yet... So it's not really an option until then. In fact usb_add_hcd() is already handling the phy for us. If it handles USB phy, then I don't really have an issue with it. It handles usb_phy as well. It just expects hcd-usb_phy to be set. cheers, - -roger -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVNiqDAAoJENJaa9O+djCTwy0QAMCz+99lbMbp9feC7wVOThgd MNjFEpWYMS+Cz0nlwoLQB+uV46WRclR5HNfHCJAclcfp/O+iNXmxrRgAmCVqdzAd d+54nquoWV4IJy/YdJ1GCiG7IDpEYBjJ2Cp99ZAUtqx3KchR6yVHH8CpM0738X9+ SZj9x2xqNeX29UaOIQtRRfoMB2g7SZjJqEa/sILXptVSVvVSbWnyFpKVelQD/MpX yIyFVapFvZ4podkB09YryHTj0xqo6VXTy4ngk9BTtO0Cf9f3Yea6G/hTJbCJ8WZA cyYaO0qJyMKCNQDYvabQ3UZk9IG7XPs//qDnmtzYMdZIJ9piBgQN8gw1cSrv/txi FVKdKSuR2lNDAB0XaRFnB9WIbpEr4Q/OKkTFKT6Cu7T1iMkTMrlartpboiWpRXQJ B4lz9sxiNGcYThOfXqdwQX0s62RZNwfOYA4qX61DJwttYiEyuagXdR/WtfkkAJ6C HYN5zEQhw+YkBuU+28+ulnJW4057nNAYUD2qbXJ7Dr7D7ThX8PkUYZu5D0BFjrF6 cIBksnbmgWuoUdBYtTDlYRbwGv/iZ/NnBZFE0xMqzNMKM7j7YQR/BkS2fbHZw+lk RvG5XUhpCeJ7olW/xgxSNmH9tSIxkRLHNJZ4xcmpjR1Ba3QRYDG22GhEX+pX9bcy 0TcyxgHvprTGH5OFZuHX =OA20 -END PGP SIGNATURE- -- 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 irq event bogus return value ffffff94
On 20.04.2015 23:39, Alan Stern wrote: On Mon, 20 Apr 2015, Joe Lawrence wrote: On Mon, Apr 20, 2015 at 01:35:40PM -0400, Alan Stern wrote: On Mon, 20 Apr 2015, Joe Lawrence wrote: So -ESHUTDOWN = -108 (0xff94) provoked bad_action_ret into reporting a bogus return value and stack trace above. As far as I know, -Eanything is never a valid return code for an IRQ handler. Shouldn't this always return either IRQ_NONE or IRQ_HANDLED? Hi Alan -- I would think so, though the stack trace in the STS_FATAL case might interesting to somebody? (Not sure what info in such trace is useful since it's an irq handler.) Even then, it should probably be replaced with a WARN_ONCE or similar instead of inadvertently through the bogus irq return value. How about the following one-liner? -- Joe --8-- --8-- --8-- From f8030d1cabbab1e7e5b0a0ba67fa4cd0a944d416 Mon Sep 17 00:00:00 2001 From: Joe Lawrence joe.lawre...@stratus.com Date: Mon, 20 Apr 2015 15:40:47 -0400 Subject: [PATCH] xhci: gracefully handle xhci_irq dead device If the xHCI host controller has died (ie, device removed) or suffered other serious fatal error (STS_FATAL), then xhci_irq should handle this condition with IRQ_HANDLED instead of -ESHUTDOWN. Signed-off-by: Joe Lawrence joe.lawre...@stratus.com --- drivers/usb/host/xhci-ring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index f5397a517c54..0402b80d2c85 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2640,7 +2640,7 @@ irqreturn_t xhci_irq(struct usb_hcd *hcd) xhci_halt(xhci); hw_died: spin_unlock(xhci-lock); -return -ESHUTDOWN; +return IRQ_HANDLED; } /* That seems good to me, and I assume it prevents your warning. Mathias knows a lot more about xhci-hcd than I do, though. Looks good to me, at least on STS_FATAL we know the interrupt is from xhci and should return IRQ_HANDLED. Probably also when we read 0x from the xhci status reg it's due to a removed xhci. On the other hand if we just removed xhci, and share the interrupt with somebody else who is also generating an interrupts, then we would probably continue to read 0x from the status reg and should return IRQ_NONE. Anyways, not a very likely situation and anything is better than -ESHUTDOWN. I tried to figure out the reason behind the -ESHUTDOWN, but looks like it has always just been there. It was added with the interrupt handler code and wasn't mentioned in the commit message. I'll add you patch and send it forward once rc1 is out -Mathias -- 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 irq event bogus return value ffffff94
On 04/21/2015 08:21 AM, Mathias Nyman wrote: [...] On the other hand if we just removed xhci, and share the interrupt with somebody else who is also generating an interrupts, then we would probably continue to read 0x from the status reg and should return IRQ_NONE. Yes, I think this was Sergei's concern as well and IRQ_NONE is probably the safer value on a shared line. Unfortunately ehci-hcd.c, fotg210-hcd.c, fusbh200-hcd.c, ohci-hcd.c, oxu210hp-hcd.c all return dead controller irq with IRQ_HANDLED. I don't have all that hardware to test a change across the board. :( Anyways, not a very likely situation and anything is better than -ESHUTDOWN. I tried to figure out the reason behind the -ESHUTDOWN, but looks like it has always just been there. It was added with the interrupt handler code and wasn't mentioned in the commit message. I'll add you patch and send it forward once rc1 is out Thanks! -- Joe -- 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] Revert usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap
On Tue, 2015-04-21 at 11:04 -0400, Alan Stern wrote: On Tue, 21 Apr 2015, Ivan T. Ivanov wrote: This reverts commit 70843f623b58 (usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap), because msm_otg and this driver are using same address space to access AHB mode and USB command registers. Um, this patch is in fact _not_ a reversion of 70843f623b58. That commit removed 4 lines of code and added 3. If this were truly a reversion, it would remove 3 lines and add 4. Instead it adds 10. Please make this a true reversion. Right, but I will have to revert 2 commits then, is this ok? Ivan -- 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: default value of power/wakeup
On Tue, 21 Apr 2015, Tom Yan wrote: By blacklisting the hid-generic, I think I can confirm hid-generic is the module that matters. Though I'm curious how it use the code from usbhid/hid-core.c because I couldn't find a clue in the short hid-generic.c. In fact, hid-generic.c contains no executable code at all! What matters is that it is a driver and it can bind to a device. Take a look at the hid_device_probe() routine in hid-core.c, and bear in mind that hid_hw_start() is an inline routine which calls hdev-ll_driver-start(). Anyway I don't know much about coding so it's not really my concern. But I think the fact hid-generic sets a default (no matter if it's enabled or disabled) brings a problem. The reason is, the wakeup attribute is not initialized or created by hid-generic, so udev can apply a rule related to the attribute before hid-generic get loaded (which seems to be what it is doing, see https://bugs.freedesktop.org/show_bug.cgi?id=90041). If the module gets loaded or reloaded afterwards, the value would be set to the hard-coded default anyway. This is a similar problem affecting all devices. The wakeup attribute in sysfs (along with all the other power-related sysfs attributes) gets created before the device is probed. Consequently, any changes made by drivers in their probe routines don't show up in the initial sysfs files. Perhaps it is possible to change the behaviour by rewriting some bits of udev, but I don't see the point of doing so. IMHO these hard-coded default should be avoid from all drivers until it is really necessary, and when it is needed, it's best to have the default set right at the point when the attribute is initialized if possible. Setting the default when the attribute gets initialized is not possible in this case. The wakeup attribute belongs to the USB device, but the fact that the device can act as a keyboard is hidden away in one of the interfaces (and the interfaces are registered _after_ the device). Things would be a little better if the wakeup attribute were a property of the interface, but it isn't. Anyway, you're suggesting that drivers should never override sysfs attribute values. But there doesn't seem to be any other way to implement the kernel's policy that wakeup should be enabled by default for all keyboard devices. After all, only the driver knows whether or not the device it manages is a keyboard. 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: gadget: g_multi does not work with net2280
-Original Message- From: Ricardo Ribalda Delgado [mailto:ricardo.riba...@gmail.com] Sent: Tuesday, April 21, 2015 1:33 AM To: Praveen Murali Cc: linux-usb@vger.kernel.org; ba...@ti.com; min...@mina86.com Subject: Re: usb: gadget: g_multi does not work with net2280 Can you try with the latest kernel from linux-next? Hi Ricardo, I tried this with the kernel from linux-next tree; that did not work for me either. The g_multi driver crashes the kernel on load (stack trace is attached). I was able to use the configfs to export the RNDIS and mass storage functions, but its again either/or (only one of them works). I played around with the endpoint assignments and the pattern I am seeing here is that the interface that gets the first set of endpoints works. That is, even if RNDIS is the first interface but I force it to use the endpoints other than 1, 2, or 3 it will not work. Similarly, with mass storage only function it needs endpoints 1 and 2 or 2 and 3 to work correctly. Now, this is a problem only when the host is Windows, Linux host works either ways. Does windows expect the endpoint numbering to be a certain way? Is this an issue with the usb3380? Or do I need a linux-usbstor .inf similar to the linux.inf for RNDIS? Also, any idea as to how this was tested to originally? There are some patches from Mian Yousaf Kaukab yousaf.kau...@intel.com, that might be related to your problem Is it libcomposite where the fixes were made? This was a silly question, please disregard. Regards Thanks, Praveen [ 84.871585] using random self ethernet address [ 84.871595] using random host ethernet address [ 84.877473] Number of LUNs=8 [ 84.877489] Mass Storage Function, version: 2009/09/11 [ 84.877496] LUN: removable file: (no medium) [ 84.877508] Number of LUNs=1 [ 84.877592] LUN: file: /dev/sda [ 84.877597] Number of LUNs=1 [ 84.878125] usb0: HOST MAC 7e:d1:bd:a1:d1:3e [ 84.878206] usb0: MAC e6:59:0c:3e:3d:e1 [ 84.880877] g_multi gadget: unable to autoconfigure all endpoints [ 84.880940] net2280_disable: Invalid ep=8800c88b17e8 or ep-desc [ 84.880989] net2280_disable: Invalid ep=8800c88b13c0 or ep-desc [ 84.881033] net2280_disable: Invalid ep=8800c88b1458 or ep-desc [ 84.881076] net2280_disable: Invalid ep=8800c88b14f0 or ep-desc [ 84.881239] BUG: unable to handle kernel NULL pointer dereference at 0008 [ 84.881348] IP: [a053f382] handle_exception+0x17a/0x2d5 [usb_f_mass_storage] [ 84.881441] PGD c8f2b067 PUD c8ae8067 PMD 0 [ 84.881571] Oops: 0002 [#1] SMP [ 84.881670] Modules linked in: usb_f_acm u_serial usb_f_rndis g_multi(+) usb_f_mass_storage libcomposite u_ether xt_multiport iptable_filter ip_tables x_tables hid_generic joydev hid_multitouch padlock_aes padlock_sha iscsi_target_mod target_core_mod configfs usbhid hid uhci_hcd via_cputemp hwmon_vid ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi cfg80211 rfkill i2c_viapro psmouse ehci_pci i2c_core ehci_hcd serio_raw xhci_pci snd_hda_codec_hdmi xhci_hcd snd_hda_codec_via net2280 snd_hda_codec_generic udc_core usbcore snd_hda_intel snd_hda_controller shpchp usb_common snd_hda_codec snd_hda_core snd_pcm snd_timer snd_hwdep snd soundcore parport_pc ppdev nfsd nfs_acl auth_rpcgss oid_registry evdev nfs fscache lockd acpi_cpufreq sunrpc grace processor thermal_sys lp parport loop ext4 jbd2 mbcache crc16 sd_mod ata_generic firewire_ohci firewire_core crc_itu_t mvsas libsas pata_via libata scsi_transport_sas scsi_mod button [ 84.884026] CPU: 1 PID: 2118 Comm: file-storage Not tainted 4.0.0-3-amd64-next-20150421 #5 [ 84.884026] Hardware name: VIA technology Inc. VX900/EPIA-M860, BIOS 101 07/16/2014 [ 84.884026] task: 8800ca2433d0 ti: 8800c8b04000 task.ti: 8800c8b04000 [ 84.884026] RIP: 0010:[a053f382] [a053f382] handle_exception+0x17a/0x2d5 [usb_f_mass_storage] [ 84.884026] RSP: 0018:8800c8b07d78 EFLAGS: 00010046 [ 84.884026] RAX: 0001 RBX: 8800364cd000 RCX: [ 84.884026] RDX: RSI: 0286 RDI: 8800364cd060 [ 84.884026] RBP: 8800ca2433d0 R08: 8800c8b04000 R09: 817de000 [ 84.884026] R10: R11: R12: 8800364cd060 [ 84.884026] R13: R14: 0286 R15: [ 84.884026] FS: () GS:88011fc8() knlGS: [ 84.884026] CS: 0010 DS: ES: CR0: 8005003b [ 84.884026] CR2: 0008 CR3: c866c000 CR4: 06e0 [ 84.884026] Stack: [ 84.884026] 8800cb200880 8106337e 88011fc95228 0001 [ 84.884026] 88011fc951c0 88011fc151c0 8800ca2433d0 81063b56 [ 84.884026] 0001 88011fc151c0 8800ca2433d0 81066066
Re: [PATCH 1/1] drivers/usb/chipidea/debuc.c: avoid out of bound read
On Tue, Apr 21, 2015 at 09:25:41PM +0200, Heinrich Schuchardt wrote: Hello Peter, thanks for reviewing. On 21.04.2015 03:32, Peter Chen wrote: On Fri, Apr 17, 2015 at 08:04:13AM +0200, Heinrich Schuchardt wrote: A string written by the user may not be zero terminated. sscanf may read memory beyond the buffer if no zero byte is found. Signed-off-by: Heinrich Schuchardt xypron.g...@gmx.de --- drivers/usb/chipidea/debug.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c index dfb05ed..ef08af3 100644 --- a/drivers/usb/chipidea/debug.c +++ b/drivers/usb/chipidea/debug.c @@ -88,9 +88,13 @@ static ssize_t ci_port_test_write(struct file *file, const char __user *ubuf, char buf[32]; int ret; - if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count))) + count = min_t(size_t, sizeof(buf) - 1, count); + if (copy_from_user(buf, ubuf, count)) return -EFAULT; Any reasons to change above? Otherwise we would have two lines with the term min_t(size_t, sizeof(buf) - 1, count). Sorry, two lines of min_t(..)? Why I can't find it? This would make the code harder to read. + /* sscanf requires a zero terminated string */ + buf[count] = 0; + I prefer using '\0' If you confirm the rest of the patch is ok, I will send an updated patch. Best regards Heinrich if (sscanf(buf, %u, mode) != 1) return -EINVAL; -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 00/13] USB: OTG/DRD Core functionality
On Tue, Apr 21, 2015 at 10:34:01AM +0300, Roger Quadros wrote: On 21/04/15 09:04, Peter Chen wrote: On 20/04/15 06:05, Peter Chen wrote: On Tue, Apr 14, 2015 at 01:41:47PM +0300, Roger Quadros wrote: This is an attempt to centralize OTG/Dual-role functionality in the kernel. As of now I've got Dual-role functionality working pretty reliably on dra7-evm. xhci side of things for OTG/DRD use are fixed in http://thread.gmane.org/gmane.linux.kernel/1923161 Hi Roger, Currently, there are two main problems for DRD/OTG framework. - For multi-platform supports, we may define CONFIG_USB_OTG, but the gadget should not add its otg descriptor to its configuration descriptors if it does not support one of otg features (SRP/HNP/ADP). Macpaul Lin's patch set [1] is the right way to do it. Agreed. That check (whether OTG descriptor can be added and which version of it) has to be done at runtime and it must be added only if hardware supports OTG _and_ kernel OTG support is enabled. Ok, let's put this patch set in mainline first, since your patch set may need some information from it. - We are lack of framework to handle OTG (DRD) switch, it is great you are designing it. The main problem for this framework is how to handle DRD/OTG FSM unify. My thought is we add two paths for them separate. For easy, I suggest if the platform supports one of otg features, then it goes to fully otg fsm, else it goes to simply otg fsm (like your drd fsm). If you agree with it too, you may not need to add another dr_mode value. It would be nice that way but unfortunately it does't work in all cases. e.g. What if the SoC itself supports all OTG features but the board is not designed for OTG. Or the product designer simply is not interested in full OTG support but just dual-role. So we need some flexibility for the device tree/platform-data to specify that. This is where a new dr_mode == dual- role is needed. Since dr_mode has been widely used now, if we add a new property for it, we need to change all drivers. Your OTG/DRD framework needs to (partial) use otg fsm, and we will not teach old driver to use it since there are some driver related stuffs. fair enough. Let's not change dr_mode then and decide based on other parameters. SRP/HNP/ADP support can be board level capabilities, and we may consider the otg device which does not support otg fsm (hardware finishes fsm). So I suggest we have below properties at dts: - otg-support /* fully otg support */ - otg-fsm-support /* fully otg fsm support */ what is the difference between otg-support and otg-fsm-support? Like I mentioned at above, the hardware finishes HNP/SRP which does not use otg fsm code (usb-otg-fsm.c), most of legacy otg platforms (musb?) use this way, for these platforms, only need to set otg-support = 1 For platforms which software finishes HNP/SRP using otg fsm code, need to set both flags. For platforms which only do role switch through id pin, do not need to set both. - otg-ver /* eh otg supplement version */ we can get otg version from the OTG controller. What exactly is the otg-ver in dts for? Since most of otg stuffs are software's, eg, for otg descriptor, we will only use otg 2.0 descriptor when both CONFIG_USB_OTG20 and otg-ver = 20 are set. - adp-support /* board adp support */ - srp-support /* board srp support */ - hnp-support /* board hnp support */ So if these options are not provided in DTS but the OTG core supports them then we keep the respective feature disabled? Yes. Won't this need dts change for existing boards? Does you know any dts based platform supports hnp/srp? For chipidea platform, currently, we depends on kernel configurations (CONFIG_USB_OTG_FSM), but it is incorrect way. Instead how about having disable flags instead. - adp-disable/* board doesn't support adp */ - srp-disable/* board doesn't support srp */ - hnp-disable/* board doesn't support hnp */ Now, if the flags are not provided in dts we use the OTG core's flags. How the OTG core's know if it supports these? Currently, if CONFIG_USB_OTG and CONFIG_USB_OTG_FSM are enabled, we will have otg fsm code (usb-otg-fsm.c). if (otg-support otg-fsm-support) this device has fully otg support, and will follow full otg fsm transitions. else this device is drd, and will follow simple otg fsm transtions. cheers, -roger -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: gadget: g_multi does not work with net2280
Praveen On Wed, Apr 22, 2015 at 6:59 AM, Praveen Murali pmur...@logicube.com wrote: -Original Message- From: Ricardo Ribalda Delgado [mailto:ricardo.riba...@gmail.com] Sent: Tuesday, April 21, 2015 1:33 AM To: Praveen Murali Cc: linux-usb@vger.kernel.org; ba...@ti.com; min...@mina86.com Subject: Re: usb: gadget: g_multi does not work with net2280 Can you try with the latest kernel from linux-next? Hi Ricardo, I tried this with the kernel from linux-next tree; that did not work for me either. The g_multi driver crashes the kernel on load (stack trace is attached). I was able to use the configfs to export the RNDIS and mass storage functions, but its again either/or (only one of them works). I played around with the endpoint assignments and the pattern I am seeing here is that the interface that gets the first set of endpoints works. That is, even if RNDIS is the first interface but I force it to use the endpoints other than 1, 2, or 3 it will not work. Similarly, with mass storage only function it needs endpoints 1 and 2 or 2 and 3 to work correctly. Now, this is a problem only when the host is Windows, Linux host works either ways. Does windows expect the endpoint numbering to be a certain way? Is this an issue with the usb3380? Or do I need a linux-usbstor .inf similar to the linux.inf for RNDIS? Also, any idea as to how this was tested to originally? There are some patches from Mian Yousaf Kaukab yousaf.kau...@intel.com, that might be related to your problem Is it libcomposite where the fixes were made? This was a silly question, please disregard. Regards Thanks, Praveen This is windows limitation. . Could you let me know which widows you are using and secondly at which interface you are connecting RNDIS. Actually if I am correct there is a issue with few of windows. RNDIS will not work if it is not the first interface. When I was working long time back it was Windows XP service pack 2 which has almost the same issue. ~Rajeev -- 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: default value of power/wakeup
By blacklisting the hid-generic, I think I can confirm hid-generic is the module that matters. Though I'm curious how it use the code from usbhid/hid-core.c because I couldn't find a clue in the short hid-generic.c. Anyway I don't know much about coding so it's not really my concern. But I think the fact hid-generic sets a default (no matter if it's enabled or disabled) brings a problem. The reason is, the wakeup attribute is not initialized or created by hid-generic, so udev can apply a rule related to the attribute before hid-generic get loaded (which seems to be what it is doing, see https://bugs.freedesktop.org/show_bug.cgi?id=90041). If the module gets loaded or reloaded afterwards, the value would be set to the hard-coded default anyway. Perhaps it is possible to change the behaviour by rewriting some bits of udev, but I don't see the point of doing so. IMHO these hard-coded default should be avoid from all drivers until it is really necessary, and when it is needed, it's best to have the default set right at the point when the attribute is initialized if possible. On 21 April 2015 at 05:20, Tom Yan tom.t...@gmail.com wrote: On 21 April 2015 at 03:44, Alan Stern st...@rowland.harvard.edu wrote: The generic driver includes code for enabling wakeup by default, Is there a part of code which can shows this? It seems to me that the usbhid module is loaded for all USB HID devices, so I doubt a bit: [tom@localhost ~]$ journalctl -b -1 | grep hid Apr 21 05:00:36 localhost kernel: hidraw: raw HID events driver (C) Jiri Kosina Apr 21 05:00:36 localhost kernel: usbcore: registered new interface driver usbhid Apr 21 05:00:36 localhost kernel: usbhid: USB HID core driver Apr 21 05:00:36 localhost kernel: hid-generic 0003:046D:C52E.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-:00:14.0-14/input0 Apr 21 05:00:36 localhost kernel: hid-generic 0003:046D:C52E.0002: input,hiddev0,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-:00:14.0-14/input1 [tom@localhost ~]$ journalctl -b -2 | grep hid Apr 21 04:59:58 localhost kernel: hidraw: raw HID events driver (C) Jiri Kosina Apr 21 04:59:58 localhost kernel: usbcore: registered new interface driver usbhid Apr 21 04:59:58 localhost kernel: usbhid: USB HID core driver Apr 21 04:59:58 localhost kernel: logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-:00:14.0-13/input2 Apr 21 04:59:58 localhost kernel: logitech-hidpp-device 0003:046D:4024.0004: input,hidraw1: USB HID v1.11 Keyboard [Logitech K400] on usb-:00:14.0-13:1 [tom@localhost ~]$ lsusb -t /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M |__ Port 13: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 13: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 13: Dev 2, If 2, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 14: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 14: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M -- 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 3/3] driver/net/usb: Add support for DSA to ax88772b
From: Jan Kaisrlik ja.kaisr...@gmail.com
This patch adds a possibility to use the RMII interface of the ax88772b
instead of the Ethernet PHY which is used now.
Binding DSA to a USB device is done via sysfs.
---
drivers/net/usb/asix.h | 7 ++
drivers/net/usb/asix_devices.c | 258 -
2 files changed, 261 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/asix.h b/drivers/net/usb/asix.h
index 5d049d0..6b1a5f5 100644
--- a/drivers/net/usb/asix.h
+++ b/drivers/net/usb/asix.h
@@ -174,6 +174,13 @@ struct asix_rx_fixup_info {
struct asix_common_private {
struct asix_rx_fixup_info rx_fixup_info;
+#ifdef CONFIG_NET_DSA
+ struct kobject kobj;
+ struct mii_bus *mdio;
+ int use_embphy;
+ bool dsa_up;
+ struct usbnet *dev;
+#endif
};
extern const struct driver_info ax88172a_info;
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index bf49792..57b3a34 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -35,6 +35,88 @@
#definePHY_MODE_RTL8211CL 0x000C
+#ifdef CONFIG_NET_DSA
+
+#define AX88772_RMII 0x02
+#define AX88772_MAX_PORTS 0x20
+#define MV88e6065_ID 0x0c89
+
+#include linux/phy.h
+#include net/dsa.h
+
+#define to_asix_obj(x) container_of(x, struct asix_common_private, kobj)
+#define to_asix_attr(x) container_of(x, struct asix_attribute, attr)
+
+static int mii_asix_read(struct mii_bus *bus, int phy_id, int regnum)
+{
+ return asix_mdio_read(((struct usbnet *)bus-priv)-net, phy_id,
regnum);
+}
+
+static int mii_asix_write(struct mii_bus *bus, int phy_id, int regnum, u16 val)
+{
+ asix_mdio_write(((struct usbnet *)bus-priv)-net, phy_id, regnum, val);
+ return 0;
+}
+
+static int ax88772_init_mdio(struct usbnet *dev){
+ struct asix_common_private *priv = dev-driver_priv;
+ int ret, i;
+
+ priv-mdio = mdiobus_alloc();
+ if (!priv-mdio) {
+ netdev_err(dev-net, Could not allocate mdio bus\n);
+ return -ENOMEM;
+ }
+
+ priv-mdio-priv = (void *)dev;
+ priv-mdio-read = mii_asix_read;
+ priv-mdio-write = mii_asix_write;
+ priv-mdio-name = ax88772 mdio bus;
+ priv-mdio-parent = dev-udev-dev;
+
+ /* mii bus name is usb-usb bus number-usb device number */
+ snprintf(priv-mdio-id, MII_BUS_ID_SIZE,
usb-%03d:%03d,dev-udev-bus-busnum, dev-udev-devnum);
+
+ priv-mdio-irq = kzalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
+ if (!priv-mdio-irq) {
+ ret = -ENOMEM;
+ goto free;
+ }
+
+ for (i = 0; i PHY_MAX_ADDR; i++)
+ priv-mdio-irq[i] = PHY_POLL;
+
+ ret = mdiobus_register(priv-mdio);
+ if (ret) {
+ netdev_err(dev-net, Could not register MDIO bus\n);
+ goto free_irq;
+ }
+
+ netdev_info(dev-net, registered mdio bus %s\n, priv-mdio-id);
+ return 0;
+
+free_irq:
+ kfree(priv-mdio-irq);
+free:
+ mdiobus_free(priv-mdio);
+ return ret;
+}
+
+static void ax88772_remove_mdio(struct usbnet *dev)
+{
+ struct asix_common_private *priv = dev-driver_priv;
+
+// dsa_free(); TODO
+
+ netdev_info(dev-net, deregistering mdio bus %s\n, priv-mdio-id);
+ mdiobus_unregister(priv-mdio);
+ kfree(priv-mdio-irq);
+ mdiobus_free(priv-mdio);
+ kfree(priv);
+}
+
+#endif
+
struct ax88172_int_data {
__le16 res1;
u8 link;
@@ -301,6 +383,27 @@ static int ax88772_reset(struct usbnet *dev)
int ret, embd_phy;
u16 rx_ctl;
+#ifdef CONFIG_NET_DSA
+ int temp = AX88772_RMII;
+ struct asix_common_private *priv = dev-driver_priv;
+
+ if (priv-use_embphy == 1) {
+ data-phymode = PHY_MODE_MARVELL;
+ data-ledmode = 0;
+
+ /* Set AX88772 to enable RMII interface for external PHY */
+ asix_write_cmd(dev, AX_CMD_SW_PHY_SELECT, 0, 0, 0, NULL);
+ asix_write_cmd(dev, AX_CMD_SW_PHY_SELECT, 0, 0, 1, temp);
+
+ asix_sw_reset(dev, 0);
+ msleep(150);
+
+ asix_write_rx_ctl(dev, 0);
+ msleep(60);
+ }
+
+#endif
+
ret = asix_write_gpio(dev,
AX_GPIO_RSE | AX_GPIO_GPO_2 | AX_GPIO_GPO2EN, 5);
if (ret 0)
@@ -415,11 +518,131 @@ static const struct net_device_ops ax88772_netdev_ops = {
.ndo_set_rx_mode= asix_set_multicast,
};
+
+#ifdef CONFIG_NET_DSA
+struct asix_attribute {
+ struct attribute attr;
+ ssize_t (*show)(struct asix_common_private *priv, struct asix_attribute
*attr, char *buf);
+ ssize_t (*store)(struct asix_common_private *priv, struct
asix_attribute *attr, const char *buf, size_t count);
+};
+
+static int ax88772_set_bind_dsa(struct asix_common_private *priv)
+{
+ struct usbnet *dev = priv-dev;
+ int i, ret, embd_phy;
+ u32 phyid;
[RFC PATCH 2/3] net/dsa: Allow probing dsa from usbnet
From: Jan Kaisrlik ja.kaisr...@gmail.com
This patch adds a function which helps to connect net device
to DSA switch based on mii_bus and netdev.
The switch parameters of the switch are configured in fill_platform_data().
Currently, the configuration data is hardcoded in the code.
I don't know how to pass the configuration data from
user space.
It is not possible to determine the configuration data in plug-and-play
manner in mv88e6060 driver.
I have thought about two possibilities how to do that. First one is to
load data from the device tree, because loading from device tree is
already implemented in dsa_of_probe().
Second possibility is to send configuration of switch via sysfs.
In my opinion, the second one is better because I have already used
sysfs to bind USB to DSA in patch 3/3.
---
include/net/dsa.h | 3 ++
net/dsa/dsa.c | 121 ++
2 files changed, 124 insertions(+)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index ed3c34b..df7b748 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -290,4 +290,7 @@ static inline bool dsa_uses_tagged_protocol(struct
dsa_switch_tree *dst)
{
return dst-rcv != NULL;
}
+
+int dsa_probe_mii(struct mii_bus *bus, struct net_device * dev);
+
#endif
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index e2c0703..cb5d9c2 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -798,6 +798,127 @@ out:
return ret;
}
+static int fill_platform_data(struct dsa_platform_data *pd,
+ struct mii_bus *bus, struct device * parent){
+ struct dsa_chip_data * cd;
+ int i;
+
+ static struct device_node dn = {
+ .name = name,
+ .type = type,
+ .phandle = 0,
+ .full_name = fullname,
+ .fwnode = {1},
+ .properties = NULL,
+ .deadprops = NULL,
+ .parent = NULL,
+ .child = NULL,
+ .sibling = NULL,
+ .kobj = {NULL},
+ ._flags = 0,
+ .data = NULL
+ };
+ static struct device_node dnc = {
+ .name = name,
+ .type = type,
+ .phandle = 0,
+ .full_name = fullname,
+ .fwnode = {1},
+ .properties = NULL,
+ .deadprops = NULL,
+ .parent = dn,
+ .child = NULL,
+ .sibling = NULL,
+ .kobj = {NULL},
+ ._flags = 0,
+ .data = NULL
+ };
+ static char *port_names[12] = {0, 1, 2, 3, 4,
+ 5, 6, 7, 8, 9, 10, 11};
+
+ pd-nr_chips = 1;
+ pd-netdev = parent;
+
+ cd = kzalloc(sizeof(*cd), GFP_KERNEL);
+ if (cd == NULL)
+ return -ENOMEM;
+
+ pd-chip = cd;
+
+ cd-host_dev = parent;
+ cd-sw_addr = 0x10;
+ cd-eeprom_len = 256;
+ cd-of_node = dn;
+ cd-rtable = 0;
+
+// cd-of_node = kzalloc(sizeof(*cd-of_node), GFP_KERNEL);
+// if(cd-of_node == NULL)
+// goto free;
+
+ for (i = 0; i DSA_MAX_PORTS; i++) {
+ cd-port_names[i] = port_names[i];
+ cd-port_dn[i] = dnc;
+ }
+
+ return 0;
+
+//free:
+// kfree(cd);
+// return -ENOMEM;
+}
+
+int dsa_probe_mii(struct mii_bus *bus, struct net_device * dev)
+{
+ struct dsa_platform_data *pd;
+ struct dsa_switch_tree *dst;
+ int ret;
+
+ pr_notice_once(Distributed Switch Architecture driver version %s\n,
+ dsa_driver_version);
+
+ if (dev == NULL || bus == NULL)
+ return -EINVAL;
+
+ pd = kzalloc(sizeof(*pd), GFP_KERNEL);
+ if (pd == NULL) {
+ ret = -ENOMEM;
+ goto freep;
+ }
+
+ ret = fill_platform_data(pd, bus, bus-parent); //TODO fix it!
+ if (ret)
+ goto freep;
+
+ if (dev-dsa_ptr != NULL) {
+ dev_put(dev);
+ ret = -EEXIST;
+ goto freep;
+ }
+
+ dst = kzalloc(sizeof(*dst), GFP_KERNEL);
+ if (dst == NULL) {
+ dev_put(dev);
+ ret = -ENOMEM;
+ goto freed;
+ }
+
+ dev_set_drvdata(bus-parent, dst);
+
+ dst-pd = pd;
+ dst-master_netdev = dev;
+
+ dsa_probe_common(dst, bus-parent);
+
+ return 0;
+
+freed:
+ kfree(dst);
+freep:
+ kfree(pd);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(dsa_probe_mii);
+
static int dsa_remove(struct platform_device *pdev)
{
struct dsa_switch_tree *dst = platform_get_drvdata(pdev);
--
2.1.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
[RFC PATCH 1/3] net/dsa: Refactor dsa_probe()
From: Jan Kaisrlik ja.kaisr...@gmail.com
This patch refactors dsa_probe in order to simplify code in the patch 2/3.
---
net/dsa/dsa.c | 82 ++-
1 file changed, 47 insertions(+), 35 deletions(-)
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 3731714..e2c0703 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -699,12 +699,56 @@ static inline void dsa_of_remove(struct platform_device
*pdev)
}
#endif
-static int dsa_probe(struct platform_device *pdev)
+static int dsa_probe_common(struct dsa_switch_tree *dst, struct device *parent)
{
+ struct dsa_platform_data *pd = dst-pd;
+ struct net_device *dev = dst-master_netdev;
+ int i;
+
+ dst-cpu_switch = -1;
+ dst-cpu_port = -1;
+
+ for (i = 0; i pd-nr_chips; i++) {
+ struct dsa_switch *ds;
+
+ ds = dsa_switch_setup(dst, i, parent, pd-chip[i].host_dev);
+ if (IS_ERR(ds)) {
+ netdev_err(dev, [%d]: couldn't create dsa switch
instance (error %ld)\n,
+ i, PTR_ERR(ds));
+ continue;
+ }
+
+ dst-ds[i] = ds;
+ if (ds-drv-poll_link != NULL)
+ dst-link_poll_needed = 1;
+ }
+
+ /*
+* If we use a tagging format that doesn't have an ethertype
+* field, make sure that all packets from this point on get
+* sent to the tag format's receive function.
+*/
+ wmb();
+ dev-dsa_ptr = (void *)dst;
+
+ if (dst-link_poll_needed) {
+ INIT_WORK(dst-link_poll_work, dsa_link_poll_work);
+ init_timer(dst-link_poll_timer);
+ dst-link_poll_timer.data = (unsigned long)dst;
+ dst-link_poll_timer.function = dsa_link_poll_timer;
+ dst-link_poll_timer.expires = round_jiffies(jiffies + HZ);
+ add_timer(dst-link_poll_timer);
+ }
+
+ return 0;
+
+}
+
+static int dsa_probe(struct platform_device *pdev){
struct dsa_platform_data *pd = pdev-dev.platform_data;
struct net_device *dev;
struct dsa_switch_tree *dst;
- int i, ret;
+ int ret;
pr_notice_once(Distributed Switch Architecture driver version %s\n,
dsa_driver_version);
@@ -743,40 +787,8 @@ static int dsa_probe(struct platform_device *pdev)
dst-pd = pd;
dst-master_netdev = dev;
- dst-cpu_switch = -1;
- dst-cpu_port = -1;
-
- for (i = 0; i pd-nr_chips; i++) {
- struct dsa_switch *ds;
-
- ds = dsa_switch_setup(dst, i, pdev-dev, pd-chip[i].host_dev);
- if (IS_ERR(ds)) {
- netdev_err(dev, [%d]: couldn't create dsa switch
instance (error %ld)\n,
- i, PTR_ERR(ds));
- continue;
- }
-
- dst-ds[i] = ds;
- if (ds-drv-poll_link != NULL)
- dst-link_poll_needed = 1;
- }
-
- /*
-* If we use a tagging format that doesn't have an ethertype
-* field, make sure that all packets from this point on get
-* sent to the tag format's receive function.
-*/
- wmb();
- dev-dsa_ptr = (void *)dst;
- if (dst-link_poll_needed) {
- INIT_WORK(dst-link_poll_work, dsa_link_poll_work);
- init_timer(dst-link_poll_timer);
- dst-link_poll_timer.data = (unsigned long)dst;
- dst-link_poll_timer.function = dsa_link_poll_timer;
- dst-link_poll_timer.expires = round_jiffies(jiffies + HZ);
- add_timer(dst-link_poll_timer);
- }
+ dsa_probe_common(dst, pdev-dev);
return 0;
--
2.1.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
[RFC PATCH 0/3] Enable connecting DSA-based switch to the USB RMII interface.
From: Jan Kaisrlik ja.kaisr...@gmail.com This RFC patch enables connecting a DSA-based switch to the USB RMII interface. I use switch Marvell 88E6065 as the DSA-based switch connected to USB RMII interface provides by Asix AX88772b. I temporarily modified the mv88e6060 driver to work with 88E6065. Jan Kaisrlik (3): net/dsa: Refactor dsa_probe() net/dsa: Allow probing dsa from usbnet driver/net/usb: Add support for DSA to ax88772b drivers/net/usb/asix.h | 7 ++ drivers/net/usb/asix_devices.c | 258 - include/net/dsa.h | 3 + net/dsa/dsa.c | 197 ++- 4 files changed, 429 insertions(+), 36 deletions(-) -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap
Hi,
On Tuesday, April 21, 2015 12:41 PM Ivan T. Ivanov
ivan.iva...@linaro.org wrote:
This reverts commit 70843f623b58 (usb: host: ehci-msm: Use
devm_ioremap_resource instead of devm_ioremap), because msm_otg
and this driver are using same address space to access AHB mode
and USB command registers.
Cc: Vivek Gautam gautam.vi...@samsung.com
Since ehci-msm and msm_otg both want to control few USB registers,
it makes sense to request ioremap'ed region in both drivers.
Acked-by: Vivek Gautam gautam.vi...@samsung.com
I can see a patch in mailing list for adding both ehci-host and otg on msm
[1].
But I think it has not yet made it to mainline kernel.
[1] [v3,04/11] ARM: dts: apq8064: Add USB OTG support
https://patches.linaro.org/47067/
Signed-off-by: Ivan T. Ivanov ivan.iva...@linaro.org
---
drivers/usb/host/ehci-msm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 9db74ca..275c92e 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -88,13 +88,20 @@ static int ehci_msm_probe(struct platform_device
*pdev)
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- hcd-regs = devm_ioremap_resource(pdev-dev, res);
- if (IS_ERR(hcd-regs)) {
- ret = PTR_ERR(hcd-regs);
+ if (!res) {
+ dev_err(pdev-dev, Unable to get memory resource\n);
+ ret = -ENODEV;
goto put_hcd;
}
+
hcd-rsrc_start = res-start;
hcd-rsrc_len = resource_size(res);
+ hcd-regs = devm_ioremap(pdev-dev, hcd-rsrc_start, hcd-rsrc_len);
+ if (!hcd-regs) {
+ dev_err(pdev-dev, ioremap failed\n);
+ ret = -ENOMEM;
+ goto put_hcd;
+ }
/*
* OTG driver takes care of PHY initialization, clock management,
--
1.9.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
Re: [PATCH v2 01/11] usbip: exporting devices
Hi, I looked around your patch and tested it and looks good. However, I do have 2 nit-picks: * I noticed in some places you've used labels such as err0 and err1. Please replace them with something more relevant to their functionality, such as what you're cleaning up after. There are examples of this both in USB/IP code and throughout the kernel. * when calling open_hc_device(), you're using magic constants - 0 and 1. Define them as constants with meaningful names. Valentina -- 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] Revert usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap
On Tue, 21 Apr 2015, Ivan T. Ivanov wrote: On Tue, 2015-04-21 at 11:04 -0400, Alan Stern wrote: On Tue, 21 Apr 2015, Ivan T. Ivanov wrote: This reverts commit 70843f623b58 (usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap), because msm_otg and this driver are using same address space to access AHB mode and USB command registers. Um, this patch is in fact _not_ a reversion of 70843f623b58. That commit removed 4 lines of code and added 3. If this were truly a reversion, it would remove 3 lines and add 4. Instead it adds 10. Please make this a true reversion. Right, but I will have to revert 2 commits then, is this ok? Yes, that's okay. I hadn't noticed that e507bf577e5a touched the same code. Just mention them both in the patch description. 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 PATCH 1/3] net/dsa: Refactor dsa_probe()
On 21/04/15 06:26, Jan Kaisrlik wrote: From: Jan Kaisrlik ja.kaisr...@gmail.com This patch refactors dsa_probe in order to simplify code in the patch 2/3. It does not look like you are working on the latest net-next tree, that part of the code has already been refactored to have separate helper functions such as dsa_setup_dst(), dsa_switch_setup() and dsa_switch_setup_one(). -- Florian -- 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 02/11] usbip: readme and manuals about exporting devices
On Tue, Apr 14, 2015 at 10:00 AM, Nobuo Iwata nobuo.iw...@fujixerox.co.jp wrote: -server:# usbip bind --busid=1-2 +dev:# usbip bind --busid=1-2 - Bind usbip-host.ko to the device of busid 1-2. -- A usb device 1-2 is now exportable to other hosts! -- Use 'usbip unbind --busid=1-2' when you want to shutdown exporting and use the device locally. +- USB device 1-2 is now importable from other computer! + +dev:# usbip unbind --busid=1-2 +- Unind usbip-host.ko from the device of busid 1-2. +- USB device 1-2 is not importable from other computer. I see various parameters, such as --busid, followed by an = sign. This looks like a thing thoughout the manual. Although this syntax works as well, I think we should be consistent and not include =. I, personally, prefer having --busid busid instead of --busid=busid. Valentina -- 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] pl2303: Remove antiquated support for I330 phone
On Tue, Apr 21, 2015 at 05:07:05PM +0200, Jason A. Donenfeld wrote:
Samsung has just released a portable USB3 SSD, coming in a very small
and nice form factor. It's USB ID is 04e8:8001, which unfortunately is
already used by the pl2303 USB serial driver for the Samsung I330 phone
cradle. This phone was manufactured in 2001, and I seriously doubt it is
still in use on any contemporary networks. Having pl2303 pick up this
device ID results in conflicts with the usb-storage driver, which
handles the newly released portable USB3 SSD. In this patch I remove the
device ID of the old antiquated telephone from the pl2303 driver, so
that usb-storage can handle it.
Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com
---
drivers/usb/serial/pl2303.c | 1 -
drivers/usb/serial/pl2303.h | 4
2 files changed, 5 deletions(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 829604d..f5257af 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -61,7 +61,6 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(DCU10_VENDOR_ID, DCU10_PRODUCT_ID) },
{ USB_DEVICE(SITECOM_VENDOR_ID, SITECOM_PRODUCT_ID) },
{ USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_ID) },
- { USB_DEVICE(SAMSUNG_VENDOR_ID, SAMSUNG_PRODUCT_ID) },
How about adding a .driver_info quirk, that checks the device to see if
it matches a mass storage device? If so, don't accept the probe, which
will keep the driver from working on the SSD device, and still keep
working on the old docking station.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Polling a usbfs file descriptor.
On Tue, 21 Apr 2015, Dave Mielke wrote: [quoted lines by Alan Stern on 2015/04/21 at 10:50 -0400] Yes, it's okay. A userspace ABI like that isn't going to go away. It's also true that you can poll for POLLERR or POLLHUP to see when a device has been disconnected, although libusb probably isn't interested in doing that. Out of curiosity, do you know why one must poll for output (rather than for input)? I have no idea. Perhaps someone decided to do it that way because you need to have the file open for writing before you can submit or reap URBs. JDoes writability precisely mean that there's at least one user-submitted URB that can now be reaped? Yes. The exact test is: if (file-f_mode FMODE_WRITE !list_empty(ps-async_completed)) mask |= POLLOUT | POLLWRNORM; where ps-async_completed is the list of completed but not-yet-reaped URBs. 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 v2 03/11] usbip: safe completion against usb_kill_urb()
On Tue, Apr 14, 2015 at 10:00 AM, Nobuo Iwata
nobuo.iw...@fujixerox.co.jp wrote:
stub_shutdown_connection() : drivers/usb/usbip/stub_dev.c
stub_device_cleanup_urbs() : drivers/usb/usbip/stub_main.c
requests to kill pending URBs and clears priv lists.
stub_complete() : drivers/usb/usbip/stub_tx.c might be called with URBs
to have been requested to kill.
To avoid kernel panic, this patch ignores killed URBs linked to cleared
priv lists.
To know the killed URBs in stub_complete(), sdev-ud.tcp_socket which
cleared before stub_device_cleanup_urbs() is checked.
Signed-off-by: Nobuo Iwata nobuo.iw...@fujixerox.co.jp
---
drivers/usb/usbip/stub_tx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/usbip/stub_tx.c b/drivers/usb/usbip/stub_tx.c
index dbcabc9..f19f321 100644
--- a/drivers/usb/usbip/stub_tx.c
+++ b/drivers/usb/usbip/stub_tx.c
@@ -97,7 +97,9 @@ void stub_complete(struct urb *urb)
/* link a urb to the queue of tx. */
spin_lock_irqsave(sdev-priv_lock, flags);
- if (priv-unlinking) {
+ if (sdev-ud.tcp_socket == NULL) {
+ dev_info(urb-dev-dev, discard a urb for closed
connection);
+ } else if (priv-unlinking) {
stub_enqueue_ret_unlink(sdev, priv-seqnum, urb-status);
stub_free_priv_and_urb(priv);
} else {
--
2.1.0
Looks good.
--
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: Polling a usbfs file descriptor.
[quoted lines by Alan Stern on 2015/04/21 at 10:50 -0400] Yes, it's okay. A userspace ABI like that isn't going to go away. It's also true that you can poll for POLLERR or POLLHUP to see when a device has been disconnected, although libusb probably isn't interested in doing that. Out of curiosity, do you know why one must poll for output (rather than for input)? JDoes writability precisely mean that there's at least one user-submitted URB that can now be reaped? -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.org/ -- 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
