Re: Missing USB devices.

["Aleš Nesrsta" <starous@volny.cz>]

Hi guys,
sorry for the delay - I was too busy on business trip...


Vladimir:
...
>> I am waiting mainly for Vladimir's "Go on!" :-)
> I don't see any messages in mymailbox from you tagged as pending
> patches. Can you tell me the date and subject?
Oh, sorry, maybe I missed something. (Exists/Are somewhere written some 
exact rules how to ask for patch commit?)

I sent the patch for testing at 18.7.2013 18:10 CET in ML thread named 
"[PATCH] Re: [grub-devel] loongson-2f mini-pc (fuloong) elf image 
generation.".
And I wrote some comments related to it at 23.7.2013 23:05 CET in the 
same thread.
But, you are right, nowhere is some exact asking for patch commit.


Christian:
> I'm thinking of the EHCI hand-over. In the case of EHCI handover beeing successful within the timeout, you never clear the USBLEGCTLSTS register (SMI's). You do that in the other cases however. Why? I can not think of any case of a successful handover with SMI's still enabled. To what purpose? A buggy BIOS would maybe act upon such stuff? Maybe thats a case for lost devices etc?
Yes, it could be the bug.

But it is the question:

1) I expect BIOS disables all related SMI during handover procedure of 
EHCI (or OHCI, it has similar procedure).
AFAIK, EHCI (and possibly also OHCI) specification doesn't say anything 
about resetting of SMI bits by OS after handover procedure - but maybe 
it is common thing which it is not worth mentioning.

2) According to the specification, default state of SMI bits should be 0 
-> i.e., after EHCI reset (which is done immediately after ownership 
handover) I expect these bits should be 0. But maybe I am wrong. - ?

Did you try this change? You are probably experienced programmer, so I 
expect such change should be not problem to you... :-) What result did 
you get?


> Also, I've been toying with the black magic EHCI hand-back. I've gotten it to work for some machines. The problem with GRUB and USB is that if you enable USB you have no more control over USB in case a OS needs input before loading it's own USB stack. Do you have any experience with this? Could we make such code execution optional on environment etc (because hand back is even more buggy than everything else.. :)) Maybe users can use it in corner cases when they need USB-input with usb-support in GRUB... if it'll work on their hardware that is.
I don't understand this part - What do you mean by (black magic) EHCI 
hand-back? Do you mean procedure which returns EHCI ownership back to 
the BIOS (SMM) ?
Oh, maybe I understand in this case - You are probably pointing to the 
situation when some OS boots and it wants some input from keyboard to 
select something in boot process - is it correct?
Hmm, maybe it can happen, but I didn't see such situation yet - but I am 
not expert nor OS experimenter/developer etc. :-)
AFAIK, USB drivers are loaded very early or they are (at least can be) 
integral part of any nowadays kernel. I.e., I think such situation can 
happen only in some very very special cases, so it is the question, if 
we should spent our time to try to solve it - or?


BR,
Ales