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

2010-12-06 Thread 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
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2010-12-06 Thread 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.


--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2010-12-06 Thread Pavan Kondeti
On 12/7/2010 8:02 AM, pkond...@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.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2010-12-06 Thread Greg KH
On Mon, Dec 06, 2010 at 06:32:30PM -0800, pkond...@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
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2010-12-06 Thread Pavan Kondeti
On 12/7/2010 9:20 AM, Greg KH wrote:
 On Mon, Dec 06, 2010 at 06:32:30PM -0800, pkond...@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.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2010-12-06 Thread Greg KH
On Tue, Dec 07, 2010 at 09:18:32AM +0530, Pavan Kondeti wrote:
 On 12/7/2010 8:02 AM, pkond...@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
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2010-12-06 Thread 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, pkond...@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
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2010-12-06 Thread 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.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html