From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VFWrG-0005DY-7D for mharc-grub-devel@gnu.org; Fri, 30 Aug 2013 18:07:58 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFWr6-0005DK-6G for grub-devel@gnu.org; Fri, 30 Aug 2013 18:07:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VFWqx-0005QB-Nx for grub-devel@gnu.org; Fri, 30 Aug 2013 18:07:48 -0400 Received: from smtp.volny.cz ([2001:4de8:71c:62::33]:57036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFWqx-0005Pi-DP for grub-devel@gnu.org; Fri, 30 Aug 2013 18:07:39 -0400 Received: from [192.168.6.11] (unknown [193.86.90.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: starous@volny.cz) by smtp.volny.cz (Postfix) with ESMTPSA id EE00F260AA1 for ; Sat, 31 Aug 2013 00:07:35 +0200 (CEST) Message-ID: <522117AC.4050401@volny.cz> Date: Sat, 31 Aug 2013 00:07:40 +0200 From: =?windows-1252?Q?Ale=9A_Nesrsta?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: Missing USB devices. References: <20130807201137.08332daf@opensuse.site> <520534A0.4030009@volny.cz> <52056C1F.5070003@volny.cz> <521D0A45.5000407@volny.cz> <521D1C4E.3060503@gmail.com> In-Reply-To: <521D1C4E.3060503@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4de8:71c:62::33 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 22:07:56 -0000 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