From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from kroah.org ([198.145.64.141]:47851 "EHLO coco.kroah.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754073Ab0LGEX0 (ORCPT ); Mon, 6 Dec 2010 23:23:26 -0500 Date: Mon, 6 Dec 2010 20:22:07 -0800 From: Greg KH Subject: Re: [RFC 1/2] USB: Notify OTG errors to user space via uevents Message-ID: <20101207042207.GA29098@kroah.com> References: <1291639071-10862-1-git-send-email-pkondeti@codeaurora.org> <20101206155826.GD23214@kroah.com> <4CFDAE90.607@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CFDAE90.607@codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-ID: To: Pavan Kondeti Cc: gregkh@suse.de, linux-usb@vger.kernel.org, linux-arm-msm@vger.kernel.org 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