[RFC 1/2] USB: Notify OTG errors to user space via uevents

[RFC 1/2] USB: Notify OTG errors to user space via uevents

[Pavankumar Kondeti]

OTG specification mandates no silent failures and all errors should
be reported to the user.  The spec itself does not give the exact
error description. But recommends the error message to be self
explanatory.  Provide otg_notify_error() utility for USB core and
OTG driver to send the error codes to user space.  All the error
code values are described in include/linux/usb/ch9.h.  The user space
application can listen to netlink socket and parse the buffer for
"MODULE=OTG" and "ERROR=n", where 'n' contains the error code.

Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
---
 Documentation/ABI/testing/uevent-otg_errors |   12 +++++++++++
 drivers/usb/otg/otg.c                       |   26 +++++++++++++++++++++++++
 include/linux/usb/ch9.h                     |   28 +++++++++++++++++++++++++++
 include/linux/usb/otg.h                     |    6 +++++
 4 files changed, 72 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/ABI/testing/uevent-otg_errors

diff --git a/Documentation/ABI/testing/uevent-otg_errors b/Documentation/ABI/testing/uevent-otg_errors
new file mode 100644
index 0000000..85b6d3b
--- /dev/null
+++ b/Documentation/ABI/testing/uevent-otg_errors
@@ -0,0 +1,12 @@
+What:		OTG error codes
+Date:		December 2010
+Contact:	linux-usb@vger.kernel.org
+Description:
+		USB OTG specification mandates no silent failures.  It also
+		recommends the error message to be self explanatory.  All
+		the OTG error codes are described in include/linux/usb/ch9.h
+
+		The error code is notified to user space via uevent. User
+		space application can listen to netlink socket and parse
+		the buffer for "MODULE=OTG" and "ERROR=n" where n has the
+		error code value.
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index 0a43a7d..8532a39 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -64,3 +64,29 @@ int otg_set_transceiver(struct otg_transceiver *x)
 	return 0;
 }
 EXPORT_SYMBOL(otg_set_transceiver);
+
+/**
+ * otg_notify_error - Notify the error to userspace via uevent
+ * @err: Error code
+ * Context: can sleep
+ *
+ * This function sends an uevent with the following extra env
+ * variables.
+ *
+ * MODULE=OTG
+ * ERROR=err
+ */
+int otg_notify_error(unsigned err)
+{
+	char module_name[16], error_code[16];
+	char *envp[] = { module_name, error_code, NULL };
+
+	if (!xceiv)
+		return -ENODEV;
+
+	snprintf(module_name, 16, "MODULE=%s", "OTG");
+	snprintf(error_code, 16, "ERROR=%u", err);
+
+	return kobject_uevent_env(&xceiv->dev->kobj, KOBJ_CHANGE, envp);
+}
+EXPORT_SYMBOL(otg_notify_error);
diff --git a/include/linux/usb/ch9.h b/include/linux/usb/ch9.h
index ab46194..4053d3b 100644
--- a/include/linux/usb/ch9.h
+++ b/include/linux/usb/ch9.h
@@ -884,4 +884,32 @@ enum usb_device_state {
  */
 #define USB_SELF_POWER_VBUS_MAX_DRAW		100
 
+/*
+ * OTG specification mandates no silent failures. The following errors must
+ * be reported to the user.
+ *
+ * USB_OTG_DEV_CONNECT_TIMEOUT_ERROR: When B-device is not attached to the
+ * A-device within Ta_WAIT_BCON time.
+ *
+ * USB_OTG_HNP_ENABLE_ERROR: When B-device is failed to accept B_HNP_ENABLE
+ * feature request.
+ *
+ * USB_OTG_DEV_NOT_SUPPORTED_ERROR: When the attached peripheral is not found
+ * in the Targeted Peripheral List (TPL) of the host device.
+ *
+ * USB_OTG_HUB_NOT_SUPPORTED_ERROR: When HUB class devices are not supported by
+ * the host device.
+ *
+ * USB_OTG_HNP_FAILED_ERROR: When an error occurred during HNP.
+ *
+ * USB_OTG_NO_RESP_FOR_SRP_ERROR: When A-device does not respond to B-device's
+ * SRP request.
+ */
+#define USB_OTG_DEV_CONNECT_TIMEOUT_ERROR	1
+#define USB_OTG_HNP_ENABLE_ERROR		2
+#define USB_OTG_DEV_NOT_SUPPORTED_ERROR		3
+#define USB_OTG_HUB_NOT_SUPPORTED_ERROR		4
+#define USB_OTG_HNP_FAILED_ERROR		5
+#define USB_OTG_NO_RESP_FOR_SRP_ERROR		6
+
 #endif /* __LINUX_USB_CH9_H */
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 0a5b371..3a91776 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -167,6 +167,7 @@ otg_shutdown(struct otg_transceiver *otg)
 #ifdef CONFIG_USB_OTG_UTILS
 extern struct otg_transceiver *otg_get_transceiver(void);
 extern void otg_put_transceiver(struct otg_transceiver *);
+extern int otg_notify_error(unsigned err);
 #else
 static inline struct otg_transceiver *otg_get_transceiver(void)
 {
@@ -176,6 +177,11 @@ static inline struct otg_transceiver *otg_get_transceiver(void)
 static inline void otg_put_transceiver(struct otg_transceiver *x)
 {
 }
+
+static int otg_notify_error(unsigned err)
+{
+	return -ENODEV;
+}
 #endif
 
 /* Context: can sleep */
-- 
1.7.1
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[RFC 2/2] USB: Notify OTG errors from hub driver

[Pavankumar Kondeti]

Notify OTG errors in the following cases

1. The connected peripheral is not found in TPL.
2. HUB class device is not found in TPL.
3. When peripheral is failed to accept b_hnp_enable/a_alt_hnp
feature request.

Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
---
 drivers/usb/core/hub.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index b98efae..4f9e781 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1243,6 +1243,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
 
 #ifdef	CONFIG_USB_OTG_BLACKLIST_HUB
 	if (hdev->parent) {
+		otg_notify_error(USB_OTG_HUB_NOT_SUPPORTED_ERROR);
 		dev_warn(&intf->dev, "ignoring external hub\n");
 		return -ENODEV;
 	}
@@ -1696,9 +1697,8 @@ static int usb_enumerate_device_otg(struct usb_device *udev)
 						: USB_DEVICE_A_ALT_HNP_SUPPORT,
 					0, NULL, 0, USB_CTRL_SET_TIMEOUT);
 				if (err < 0) {
-					/* OTG MESSAGE: report errors here,
-					 * customize to match your product.
-					 */
+					otg_notify_error(
+						USB_OTG_HNP_ENABLE_ERROR);
 					dev_info(&udev->dev,
 						"can't set HNP mode: %d\n",
 						err);
@@ -1710,6 +1710,7 @@ static int usb_enumerate_device_otg(struct usb_device *udev)
 
 	if (!is_targeted(udev)) {
 
+		otg_notify_error(USB_OTG_DEV_NOT_SUPPORTED_ERROR);
 		/* Maybe it can talk to us, though we can't talk to it.
 		 * (Includes HNP test device.)
 		 */
-- 
1.7.1
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [RFC 1/2] USB: Notify OTG errors to user space via uevents

[Greg KH]

On Mon, Dec 06, 2010 at 06:07:50PM +0530, Pavankumar Kondeti wrote:
> OTG specification mandates no silent failures and all errors should
> be reported to the user.  The spec itself does not give the exact
> error description. But recommends the error message to be self
> explanatory.  Provide otg_notify_error() utility for USB core and
> OTG driver to send the error codes to user space.  All the error
> code values are described in include/linux/usb/ch9.h.  The user space
> application can listen to netlink socket and parse the buffer for
> "MODULE=OTG" and "ERROR=n", where 'n' contains the error code.

How are you going to listen to the netlink socket that is already
grabbed by libudev?

Please, if you really want to do this, create your own netlink socket,
don't create new uevent messages that will just confused the existing
tools out there, that's ripe for big problems.

thanks,

greg k-h

Re: [RFC 1/2] USB: Notify OTG errors to user space via uevents

[pkondeti]

Hi Greg,

> On Mon, Dec 06, 2010 at 06:07:50PM +0530, Pavankumar Kondeti wrote:
>> OTG specification mandates no silent failures and all errors should
>> be reported to the user.  The spec itself does not give the exact
>> error description. But recommends the error message to be self
>> explanatory.  Provide otg_notify_error() utility for USB core and
>> OTG driver to send the error codes to user space.  All the error
>> code values are described in include/linux/usb/ch9.h.  The user space
>> application can listen to netlink socket and parse the buffer for
>> "MODULE=OTG" and "ERROR=n", where 'n' contains the error code.
>
> How are you going to listen to the netlink socket that is already
> grabbed by libudev?
>
Sorry. I never worked with udev. But I read udev documentation.
I thought an external script can be invoked by adding a udev rule
when MODULE=OTG is matched and ERROR value can be accessed
in the script via env variable.

> Please, if you really want to do this, create your own netlink socket,
> don't create new uevent messages that will just confused the existing
> tools out there, that's ripe for big problems.
>
I have seen examples in drivers  sending uevents for notifying docking
station status (drivers/acpi/dock.c) and when backlight brightness
changes (drivers/video/backlight/backlight.c). So I have taken this
approach.

Re: [RFC 1/2] USB: Notify OTG errors to user space via uevents

[Pavan Kondeti]

On 12/7/2010 8:02 AM, pkondeti@codeaurora.org wrote:
> Hi Greg,
> 
>> On Mon, Dec 06, 2010 at 06:07:50PM +0530, Pavankumar Kondeti wrote:
>>> OTG specification mandates no silent failures and all errors should
>>> be reported to the user.  The spec itself does not give the exact
>>> error description. But recommends the error message to be self
>>> explanatory.  Provide otg_notify_error() utility for USB core and
>>> OTG driver to send the error codes to user space.  All the error
>>> code values are described in include/linux/usb/ch9.h.  The user space
>>> application can listen to netlink socket and parse the buffer for
>>> "MODULE=OTG" and "ERROR=n", where 'n' contains the error code.
>>
>> How are you going to listen to the netlink socket that is already
>> grabbed by libudev?
>>
> Sorry. I never worked with udev. But I read udev documentation.
> I thought an external script can be invoked by adding a udev rule
> when MODULE=OTG is matched and ERROR value can be accessed
> in the script via env variable.
> 
I ran the sample program @ http://www.kernel.org/doc/pending/hotplug.txt
and udevd concurrently. I am able to capture all the uevents in sample
program.

-- 
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [RFC 1/2] USB: Notify OTG errors to user space via uevents

[Greg KH]

On Mon, Dec 06, 2010 at 06:32:30PM -0800, pkondeti@codeaurora.org wrote:
> Hi Greg,
> 
> > On Mon, Dec 06, 2010 at 06:07:50PM +0530, Pavankumar Kondeti wrote:
> >> OTG specification mandates no silent failures and all errors should
> >> be reported to the user.  The spec itself does not give the exact
> >> error description. But recommends the error message to be self
> >> explanatory.  Provide otg_notify_error() utility for USB core and
> >> OTG driver to send the error codes to user space.  All the error
> >> code values are described in include/linux/usb/ch9.h.  The user space
> >> application can listen to netlink socket and parse the buffer for
> >> "MODULE=OTG" and "ERROR=n", where 'n' contains the error code.
> >
> > How are you going to listen to the netlink socket that is already
> > grabbed by libudev?
> >
> Sorry. I never worked with udev. But I read udev documentation.
> I thought an external script can be invoked by adding a udev rule
> when MODULE=OTG is matched and ERROR value can be accessed
> in the script via env variable.

So, you created a new kernel/user ABI and never even tried it out to see
how someone would even use it?

{sigh}

I'm afraid to ask if you actually tested this code, let alone compiled
the thing...

> > Please, if you really want to do this, create your own netlink socket,
> > don't create new uevent messages that will just confused the existing
> > tools out there, that's ripe for big problems.
> >
> I have seen examples in drivers  sending uevents for notifying docking
> station status (drivers/acpi/dock.c)

That is when the hardware configuration of the system changes.

> and when backlight brightness changes
> (drivers/video/backlight/backlight.c).

Again, hardware configuration status changed.

> So I have taken this approach.

Please don't, this is NOT the way to get errors from the kernel back out
to userspace, because, as you have noted, this is not how any other
subsystem does it.

thanks,

greg k-h

Re: [RFC 1/2] USB: Notify OTG errors to user space via uevents

[Pavan Kondeti]

On 12/7/2010 9:20 AM, Greg KH wrote:
> On Mon, Dec 06, 2010 at 06:32:30PM -0800, pkondeti@codeaurora.org wrote:
>> Hi Greg,
>>
>>> On Mon, Dec 06, 2010 at 06:07:50PM +0530, Pavankumar Kondeti wrote:
>>>> OTG specification mandates no silent failures and all errors should
>>>> be reported to the user.  The spec itself does not give the exact
>>>> error description. But recommends the error message to be self
>>>> explanatory.  Provide otg_notify_error() utility for USB core and
>>>> OTG driver to send the error codes to user space.  All the error
>>>> code values are described in include/linux/usb/ch9.h.  The user space
>>>> application can listen to netlink socket and parse the buffer for
>>>> "MODULE=OTG" and "ERROR=n", where 'n' contains the error code.
>>>
>>> How are you going to listen to the netlink socket that is already
>>> grabbed by libudev?
>>>
>> Sorry. I never worked with udev. But I read udev documentation.
>> I thought an external script can be invoked by adding a udev rule
>> when MODULE=OTG is matched and ERROR value can be accessed
>> in the script via env variable.
> 
> So, you created a new kernel/user ABI and never even tried it out to see
> how someone would even use it?
> 
> {sigh}
> 
> I'm afraid to ask if you actually tested this code, let alone compiled
> the thing...
> 
I have tested this patch with a sample program @
http://www.kernel.org/doc/pending/hotplug.txt on busybox environment
where udevd is not running. After seeing your comments, I ran the same
program concurrently
with udev on Linux box.

>>> Please, if you really want to do this, create your own netlink socket,
>>> don't create new uevent messages that will just confused the existing
>>> tools out there, that's ripe for big problems.
>>>
>> I have seen examples in drivers  sending uevents for notifying docking
>> station status (drivers/acpi/dock.c)
> 
> That is when the hardware configuration of the system changes.
> 
>> and when backlight brightness changes
>> (drivers/video/backlight/backlight.c).
> 
> Again, hardware configuration status changed.
> 
Documentation/filesystems/gfs2-uevents.txt says OFFLINE uevent is sent
upon file system errors.

>> So I have taken this approach.
> 
> Please don't, this is NOT the way to get errors from the kernel back out
> to userspace, because, as you have noted, this is not how any other
> subsystem does it.
> 
Thanks for your feedback. Is there any other way kernel can send errors
to user space asynchronously? is /dev/ interface acceptable?

-- 
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [RFC 1/2] USB: Notify OTG errors to user space via uevents

[Greg KH]

On Tue, Dec 07, 2010 at 09:18:32AM +0530, Pavan Kondeti wrote:
> On 12/7/2010 8:02 AM, pkondeti@codeaurora.org wrote:
> > Hi Greg,
> > 
> >> On Mon, Dec 06, 2010 at 06:07:50PM +0530, Pavankumar Kondeti wrote:
> >>> OTG specification mandates no silent failures and all errors should
> >>> be reported to the user.  The spec itself does not give the exact
> >>> error description. But recommends the error message to be self
> >>> explanatory.  Provide otg_notify_error() utility for USB core and
> >>> OTG driver to send the error codes to user space.  All the error
> >>> code values are described in include/linux/usb/ch9.h.  The user space
> >>> application can listen to netlink socket and parse the buffer for
> >>> "MODULE=OTG" and "ERROR=n", where 'n' contains the error code.
> >>
> >> How are you going to listen to the netlink socket that is already
> >> grabbed by libudev?
> >>
> > Sorry. I never worked with udev. But I read udev documentation.
> > I thought an external script can be invoked by adding a udev rule
> > when MODULE=OTG is matched and ERROR value can be accessed
> > in the script via env variable.
> > 
> I ran the sample program @ http://www.kernel.org/doc/pending/hotplug.txt
> and udevd concurrently. I am able to capture all the uevents in sample
> program.

Interesting, but what userspace tool are you going to create to listen
to these events that all distros are now going to have to use?

Again, please, this is NOT the interface to get errors out of the kernel
for something as minor as USB OTG issues that we have been successfully
handling just fine for years now.

thanks,

greg k-h

Re: [RFC 1/2] USB: Notify OTG errors to user space via uevents

[Greg KH]

On Tue, Dec 07, 2010 at 09:50:22AM +0530, Pavan Kondeti wrote:
> On 12/7/2010 9:20 AM, Greg KH wrote:
> > On Mon, Dec 06, 2010 at 06:32:30PM -0800, pkondeti@codeaurora.org wrote:
> >> Hi Greg,
> >>
> >>> On Mon, Dec 06, 2010 at 06:07:50PM +0530, Pavankumar Kondeti wrote:
> >>>> OTG specification mandates no silent failures and all errors should
> >>>> be reported to the user.  The spec itself does not give the exact
> >>>> error description. But recommends the error message to be self
> >>>> explanatory.  Provide otg_notify_error() utility for USB core and
> >>>> OTG driver to send the error codes to user space.  All the error
> >>>> code values are described in include/linux/usb/ch9.h.  The user space
> >>>> application can listen to netlink socket and parse the buffer for
> >>>> "MODULE=OTG" and "ERROR=n", where 'n' contains the error code.
> >>>
> >>> How are you going to listen to the netlink socket that is already
> >>> grabbed by libudev?
> >>>
> >> Sorry. I never worked with udev. But I read udev documentation.
> >> I thought an external script can be invoked by adding a udev rule
> >> when MODULE=OTG is matched and ERROR value can be accessed
> >> in the script via env variable.
> > 
> > So, you created a new kernel/user ABI and never even tried it out to see
> > how someone would even use it?
> > 
> > {sigh}
> > 
> > I'm afraid to ask if you actually tested this code, let alone compiled
> > the thing...
> > 
> I have tested this patch with a sample program @
> http://www.kernel.org/doc/pending/hotplug.txt on busybox environment
> where udevd is not running. After seeing your comments, I ran the same
> program concurrently with udev on Linux box.

And both worked properly?  That's good, but again, you don't want to
have to write a new daemon just for your OTG messages, right?

> >>> Please, if you really want to do this, create your own netlink socket,
> >>> don't create new uevent messages that will just confused the existing
> >>> tools out there, that's ripe for big problems.
> >>>
> >> I have seen examples in drivers  sending uevents for notifying docking
> >> station status (drivers/acpi/dock.c)
> > 
> > That is when the hardware configuration of the system changes.
> > 
> >> and when backlight brightness changes
> >> (drivers/video/backlight/backlight.c).
> > 
> > Again, hardware configuration status changed.
> > 
> Documentation/filesystems/gfs2-uevents.txt says OFFLINE uevent is sent
> upon file system errors.

It is?  Ah, but that's a cluster system event change, right?  Odd, I
didn't really know about that one, we should poke those developers to
make sure this is really still happening.

> >> So I have taken this approach.
> > 
> > Please don't, this is NOT the way to get errors from the kernel back out
> > to userspace, because, as you have noted, this is not how any other
> > subsystem does it.
> > 
> Thanks for your feedback. Is there any other way kernel can send errors
> to user space asynchronously? is /dev/ interface acceptable?

Andi Kleen was working on a unified error reporting system for the
kernel for things like this and other subsystems.  Try working with him
on this as it sounds like it would be what you need.

good luck,

greg k-h

Re: [RFC 1/2] USB: Notify OTG errors to user space via uevents

[Pavan Kondeti]

On 12/7/2010 10:12 AM, Greg KH wrote:
>>> > > Please don't, this is NOT the way to get errors from the kernel back out
>>> > > to userspace, because, as you have noted, this is not how any other
>>> > > subsystem does it.
>>> > > 
>> > Thanks for your feedback. Is there any other way kernel can send errors
>> > to user space asynchronously? is /dev/ interface acceptable?
> Andi Kleen was working on a unified error reporting system for the
> kernel for things like this and other subsystems.  Try working with him
> on this as it sounds like it would be what you need.

Thanks for your inputs. I have looked at Andi Kleen's "Unified error
reporting -- A worthy goal?" But it talks mostly about platform errors.
I will work with him and find out if we can use his approach for
notifying OTG errors to user space.


-- 
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.