Re: Unsupported device message, Compliance C.2, part 4

Hi all,

On 10/10/07, Aras Vaichas <[email protected]> wrote:
> Alan Stern wrote:
> > On Tue, 9 Oct 2007, Aras Vaichas wrote:
> >
> >> I just discovered that not all devices create a "product" file when inserted,
> >> so I've changed the script to look for a symbolic link to the device driver.
> >> AFAIK, an unknown device will not have this link (please correct me if I am wrong).

This discussion looks kinda useless to me.
No silent error requirement is just for OTG devices.

I actually have some patches from me and other contributors
implementing such messaging support through sysfs.

And it looks really good.

Such patch series also initialize otg targeted peripheral list (aka
whitelist) through board*.c files and implement some sort of dynamic
OTG TPL.

It's  not sent yet cuz there's also some implementation regarding vbus
error messaging that is done only for musb driver which is only in
linux-omap tree yet.

Maybe in a couple of weeks I'll have everything done and I'll be able
to share such work.


> >>
> >> ---- SNIP ----
> >>
> >> #!/bin/sh
> >>
> >> BASE="/sys/devices/platform/at91_ohci/usb1/1-1/1-1:1.0"
> >>
> >> indicated=0
> >> while [ 1 ]; do
> >>      sleep 1
> >>      if [ $indicated == 0 ]; then
> >>          if [ -d "$BASE" ]; then
> >>              indicated=1
> >>              if [ -h "$BASE/driver" ]; then
> >>                  logger "A known USB device has been inserted."
> >>              else
> >>                  logger "An unknown USB device has been inserted."
> >>              fi
> >>          fi
> >>      else
> >>          if [ ! -d "$BASE" ]; then
> >>              indicated=0
> >>          fi
> >>      fi
> >> done
> >
> > The principle is valid.  Ideally the script wouldn't poll at 1-second
> > intervals; instead it would be called by the hotplug system whenever a
> > new device was added and would check that device after a 1-second
> > delay.
> >
> > The script should also check to see whether there are no interface
> > subdirectories of the device directory.  If there aren't any, an error
> > message should be generated; it means the system wasn't able to
> > configure the device.
> >
> > There's some ambiguity about how to handle the situation where there
> > are multiple interfaces, some of which have drivers and some don't.  I
> > guess you can say that as long as any of the interfaces do have a
> > driver then the device is "known" or "supported".
>
> Alan,
>
> I think the best option is to take this over to hotplug/udev as I think it
> should be a userspace concern, especially considering the minority nature of
> the original problem.
>
> Thank you for the help.
>
> Aras
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> [email protected]
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
>


-- 
Best Regards,

Felipe Balbi
[email protected]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel