On Thu, Jul 23, 2009 at 7:46 AM, Markus Rechberger<mrechber...@gmail.com> wrote: > one thing, you might remove that autodetecting part and taking a > footprint of unknown devices > this causes more problems than everything else with those devices. > Maybe make this optional if someone wants to force autodetection over > it it might be acceptable > but doing that by default can also heat up devices. > Also if it thinks it has detected something, after toggling some gpios > the footprint might look different > again after reloading it.. it's just a failed technique doing it that way...
I agree that I'm not particularly happy with how the autodetection logic works today. The current logic though is based on the power-on-reset states of the GPIOs and GPOs though, so we are only changing the GPIOs if the board matches a known profile. That said, unless the hardware design was laid out such that the device would burn out if no driver were loaded at all, I think the risk is pretty minimal for a device that does not match a known profile. If Empia wants to describe a better heuristic for identifying their various hardware designs with the same USB ID but different board layouts and GPIO configs, that would be useful information and eliminate the need for autodetection code. Anyway, I'll take a look at the code and see if I can determine specifically where the errors are occurring in your case. The fun of dealing with hardware vendors that let their customers use default USB IDs for different hardware designs.... :-) Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
