Re: [RFC 1/2] USB: Notify OTG errors to user space via uevents
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
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
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
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
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
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
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
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