Re: Working with usbfs
On Sun, Jan 11, 2015 at 03:01:55AM +0600, Rohan Vichare wrote: > Hi Sir, > > Actually, I wanted use the usbfs_get_node function to get the inode. Really? For what? Care to point me at your kernel code that uses this function? > Can you let me how can i approach this now. Where can read something > about it. The source code should be sufficient, right? What more do you need? :) What exactly are you trying to do here? > Note: I am not using libusb. Want to learn more about kernel space coding. What kernel driver needs access to that function? It shouldn't, as that is not how you write a USB kernel driver. confused, 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
[RESEND PATCH v2 1/2] usb: serial: handle -EPROTO quietly in generic_read_bulk
If a USB serial device is unplugged while there is an active program using the device it will spam the logs with -EPROTO (71) messages as it attempts to retry. Most serial usb drivers (metro-usb, pl2303, mos7840, ...) only output these messages for debugging. The generic driver treats these as errors. Change the default output for the generic serial driver from error to debug. Signed-off-by: Jeremiah Mahler --- drivers/usb/serial/generic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c index 1bd1922..2d7207b 100644 --- a/drivers/usb/serial/generic.c +++ b/drivers/usb/serial/generic.c @@ -373,7 +373,7 @@ void usb_serial_generic_read_bulk_callback(struct urb *urb) __func__, urb->status); return; default: - dev_err(&port->dev, "%s - nonzero urb status: %d\n", + dev_dbg(&port->dev, "%s - nonzero urb status: %d\n", __func__, urb->status); goto resubmit; } -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v2 2/2] usb: serial: handle -ENODEV quietly in generic_submit_read_urb
If a USB serial device (e.g. /dev/ttyUSB0) with an active program is
unplugged, an -ENODEV (19) error will be produced after it gives up
trying to resubmit a read.
usb_serial_generic_submit_read_urb - usb_submit_urb failed: -19
Add -ENODEV as one of the permanent errors along with -EPERM that
usb_serial_generic_submit_read_urb() handles quietly without an error.
Signed-off-by: Jeremiah Mahler
---
drivers/usb/serial/generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 2d7207b..ccf1df7 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -286,7 +286,7 @@ static int usb_serial_generic_submit_read_urb(struct
usb_serial_port *port,
res = usb_submit_urb(port->read_urbs[index], mem_flags);
if (res) {
- if (res != -EPERM) {
+ if (res != -EPERM && res != -ENODEV) {
dev_err(&port->dev,
"%s - usb_submit_urb failed: %d\n",
__func__, res);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v2 0/2] usb: serial: handle -ENODEV and -EPROTO quietly
(Jan 15) Just a resend of v2 [1]. [1]: https://lkml.org/lkml/2014/12/20/16 If a USB serial device (e.g. /dev/ttyUSB0) with an active program is unplugged, a bunch of -ENODEV and -EPROTO errors will be produced in the logs. This patch set quiets these messages without changing the original behavior. This change is beneficial when using daemons such as slcand, which is similar to pppd or slip, that cannot determine whether they should exit until after the USB serial device is unplugged. Producing these error messages for a normal use case is not helpful. Jeremiah Mahler (2): usb: serial: handle -EPROTO quietly in generic_read_bulk usb: serial: handle -ENODEV quietly in generic_submit_read_urb drivers/usb/serial/generic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 3/5] usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver.
> From: Yunzhi Li [mailto:l...@rock-chips.com]
> Sent: Saturday, January 10, 2015 8:07 AM
>
> 在 2015/1/9 10:15, Paul Zimmerman 写道:
> >> [...]
> >>/*
> >> - * Attempt to find a generic PHY, then look for an old style
> >> - * USB PHY, finally fall back to pdata
> >> + * If platform probe couldn't find a generic PHY or an old style
> >> + * USB PHY, fall back to pdata
> >> */
> >> - phy = devm_phy_get(dev, "usb2-phy");
> >> - if (IS_ERR(phy)) {
> >> - uphy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> >> - if (IS_ERR(uphy)) {
> >> - /* Fallback for pdata */
> >> - plat = dev_get_platdata(dev);
> >> - if (!plat) {
> >> - dev_err(dev,
> >> - "no platform data or transceiver defined\n");
> >> - return -EPROBE_DEFER;
> >> - }
> >> - hsotg->plat = plat;
> >> - } else
> >> - hsotg->uphy = uphy;
> >> - } else {
> >> - hsotg->phy = phy;
> >> + if (IS_ERR_OR_NULL(hsotg->phy) && IS_ERR_OR_NULL(hsotg->uphy)) {
> >> + plat = dev_get_platdata(dev);
> >> + if (!plat) {
> >> + dev_err(dev,
> >> + "no platform data or transceiver defined\n");
> >> + return -EPROBE_DEFER;
> > Hi Yunzhi,
> >
> > Testing Felipe's testing/next branch on an Altera SOCFPGA platform,
> > the driver never loads because it always returns -EPROBE_DEFER here.
> > Apparently the SOCFPGA platform does not have any platform data
> > defined, because dev_get_platdata() always returns NULL.
> >
> > If I remove the -EPROBE_DEFER return and have it continue on, the
> > driver works. Reverting the patch also makes it work.
> When I debug this problem, I checked socfpga.dtsi, there is a
> usbphy node defined for each
> dwc2 controller, so I think when running dwc2_driver_probe() uphy =
> devm_usb_get_phy()
> should get a valid usbphy pointer and hsotg->uphy will not be NULL or
> ERROR, then in dwc2_gadget_init()
> it will not return -EPROBE_DEFER. I have no idea about why you meet
> -EPROBE_DEFER, could you please tell
> me what's the return value of devm_usb_get_phy() on your socfpga board ?
I'm away from the hardware right now, but I just found this in a saved
boot log:
[1.097268] usb_phy_generic soc:usbphy@0: Error requesting RESET GPIO
[1.097285] usb_phy_generic: probe of soc:usbphy@0 failed with error -2
So that probably explains it. I'll dig into this some more on Monday.
--
Paul
Re: Working with usbfs
On Sun, 11 Jan 2015, Rohan Vichare wrote: > Hi, > > Wanted to use the usbfs, Inode/Dentry functions. I used to work with > 2..6.32. Now using the Linux 3.x but didn't found > driver/usb/core/inode.c file. Please how this changes are placed in > new kernel version. The usbfs code is now contained entirely in drivers/usb/core/devio.c. 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: What is usb fs driver used for
On Sun, 11 Jan 2015, vichy wrote: > hi all: > usually the usb_driver is matched by usb_device_id or usb_dynids. > But there is any of them above defined in usb fs driver. > if so, what is usb fs driver used for when registered in the usb_init > of core/usb.c? usbfs is meant for userspace programs that want to control a USB device. For example, libusb uses usbfs. usbfs does not bind to devices based on any sort of device ID. Instead, it gets bound to a device whenever a user program opens a USB device node (/dev/bus/usb/...). 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: Working with usbfs
On Sun, Jan 11, 2015 at 01:34:51AM +0600, Rohan Vichare wrote: > Hi, > > Wanted to use the usbfs, Inode/Dentry functions. I used to work with > 2..6.32. Now using the Linux 3.x but didn't found > driver/usb/core/inode.c file. Please how this changes are placed in > new kernel version. Use the device nodes in /dev/usb/* instead, they provide the same functionality as the old mounted usbfs files did. If you use libusb, you don't have to change your program at all, it will handle the api changes just fine. hope this helps, 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
Working with usbfs
Hi, Wanted to use the usbfs, Inode/Dentry functions. I used to work with 2..6.32. Now using the Linux 3.x but didn't found driver/usb/core/inode.c file. Please how this changes are placed in new kernel version. Thanks & Regards, Rohan. -- 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: What is usb fs driver used for
On Sun, Jan 11, 2015 at 12:26:51AM +0800, vichy wrote: > hi all: > usually the usb_driver is matched by usb_device_id or usb_dynids. > But there is any of them above defined in usb fs driver. > if so, what is usb fs driver used for when registered in the usb_init > of core/usb.c? Look at /dev/usb/ for the device nodes that usbfs creates so that tools like 'lsusb' and libusb will work. hope this helps, 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
What is usb fs driver used for
hi all: usually the usb_driver is matched by usb_device_id or usb_dynids. But there is any of them above defined in usb fs driver. if so, what is usb fs driver used for when registered in the usb_init of core/usb.c? appreciate all your kine explanation in the advance, -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 3/5] usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver.
Hi paul:
在 2015/1/9 10:15, Paul Zimmerman 写道:
[...]
/*
-* Attempt to find a generic PHY, then look for an old style
-* USB PHY, finally fall back to pdata
+* If platform probe couldn't find a generic PHY or an old style
+* USB PHY, fall back to pdata
*/
- phy = devm_phy_get(dev, "usb2-phy");
- if (IS_ERR(phy)) {
- uphy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- if (IS_ERR(uphy)) {
- /* Fallback for pdata */
- plat = dev_get_platdata(dev);
- if (!plat) {
- dev_err(dev,
- "no platform data or transceiver defined\n");
- return -EPROBE_DEFER;
- }
- hsotg->plat = plat;
- } else
- hsotg->uphy = uphy;
- } else {
- hsotg->phy = phy;
+ if (IS_ERR_OR_NULL(hsotg->phy) && IS_ERR_OR_NULL(hsotg->uphy)) {
+ plat = dev_get_platdata(dev);
+ if (!plat) {
+ dev_err(dev,
+ "no platform data or transceiver defined\n");
+ return -EPROBE_DEFER;
Hi Yunzhi,
Testing Felipe's testing/next branch on an Altera SOCFPGA platform,
the driver never loads because it always returns -EPROBE_DEFER here.
Apparently the SOCFPGA platform does not have any platform data
defined, because dev_get_platdata() always returns NULL.
If I remove the -EPROBE_DEFER return and have it continue on, the
driver works. Reverting the patch also makes it work.
When I debug this problem, I checked socfpga.dtsi, there is a
usbphy node defined for each
dwc2 controller, so I think when running dwc2_driver_probe() uphy =
devm_usb_get_phy()
should get a valid usbphy pointer and hsotg->uphy will not be NULL or
ERROR, then in dwc2_gadget_init()
it will not return -EPROBE_DEFER. I have no idea about why you meet
-EPROBE_DEFER, could you please tell
me what's the return value of devm_usb_get_phy() on your socfpga board ?
I am testing with the driver built-in. I haven't tried it as a module
yet.
Any ideas? Is the -EPROBE_DEFER return really needed here?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 3/5] usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver.
Hi Paul:
On 2015/1/9 10:15, Paul Zimmerman wrote:
/*
-* Attempt to find a generic PHY, then look for an old style
-* USB PHY, finally fall back to pdata
+* If platform probe couldn't find a generic PHY or an old style
+* USB PHY, fall back to pdata
*/
- phy = devm_phy_get(dev, "usb2-phy");
- if (IS_ERR(phy)) {
- uphy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- if (IS_ERR(uphy)) {
- /* Fallback for pdata */
- plat = dev_get_platdata(dev);
- if (!plat) {
- dev_err(dev,
- "no platform data or transceiver defined\n");
- return -EPROBE_DEFER;
- }
- hsotg->plat = plat;
- } else
- hsotg->uphy = uphy;
- } else {
- hsotg->phy = phy;
+ if (IS_ERR_OR_NULL(hsotg->phy) && IS_ERR_OR_NULL(hsotg->uphy)) {
+ plat = dev_get_platdata(dev);
+ if (!plat) {
+ dev_err(dev,
+ "no platform data or transceiver defined\n");
+ return -EPROBE_DEFER;
Hi Yunzhi,
Testing Felipe's testing/next branch on an Altera SOCFPGA platform,
the driver never loads because it always returns -EPROBE_DEFER here.
Apparently the SOCFPGA platform does not have any platform data
defined, because dev_get_platdata() always returns NULL.
If I remove the -EPROBE_DEFER return and have it continue on, the
driver works. Reverting the patch also makes it work.
I am testing with the driver built-in. I haven't tried it as a module
yet.
Any ideas? Is the -EPROBE_DEFER return really needed here?
Yeah, I agree -EPROBE_DEFER is no need here, because the phy driver
is optional, it shouldn't
break the usb controller driver probe procedure. I will fix it then
resend this patch. Thank you
for testing .
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] gpio: dln2: use bus_sync_unlock instead of scheduling work
On Fri, Jan 9, 2015 at 7:58 PM, Linus Walleij wrote: > On Fri, Jan 9, 2015 at 12:40 AM, Octavian Purdila > wrote: >> On Thu, Jan 1, 2015 at 9:56 AM, Linus Walleij >> wrote: >>> On Thu, Dec 11, 2014 at 2:02 PM, Octavian Purdila >>> wrote: >>> Use the irq_chip bus_sync_unlock method to update hardware registers instead of scheduling work from the mask/unmask methods. This simplifies a bit the driver and make it more uniform with the other GPIO IRQ drivers. Signed-off-by: Octavian Purdila >>> >>> Patch applied for fixes. >>> >> >> Hi Linus, >> >> I don't see the patch applied, could you please consider it for the >> -for-next branch? > > Ah sorry I thought only the first patch was a critical fix. > Applied this to fixes too now. Working on queueing the > GPIO fixes. Hi Linus, Its not a critical fix, its just a clean-up. I thought it would go in the the for-next branch (for 3.20) and since I did not see it there I thought it got lost. Sorry for any confusion I may have caused, I am not familiar with the GPIO branch work-flow. -- 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
