From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46913) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1euOUC-0000wM-KF for qemu-devel@nongnu.org; Fri, 09 Mar 2018 15:19:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1euOU9-0003dJ-G5 for qemu-devel@nongnu.org; Fri, 09 Mar 2018 15:19:28 -0500 Received: from mail-pl0-x243.google.com ([2607:f8b0:400e:c01::243]:34289) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1euOU9-0003d0-8H for qemu-devel@nongnu.org; Fri, 09 Mar 2018 15:19:25 -0500 Received: by mail-pl0-x243.google.com with SMTP id u13-v6so5836451plq.1 for ; Fri, 09 Mar 2018 12:19:25 -0800 (PST) Sender: Guenter Roeck Date: Fri, 9 Mar 2018 12:19:21 -0800 From: Guenter Roeck Message-ID: <20180309201921.GA28623@roeck-us.net> References: <1520444223-8389-1-git-send-email-linux@roeck-us.net> <20180308171239.GA22206@roeck-us.net> <201803081028.39635.wpaul@windriver.com> <20180309182030.GA22836@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Bill Paul , QEMU Developers , Andrey Smirnov , Chris Healy , Jason Wang , Jean-Christophe Dubois On Fri, Mar 09, 2018 at 06:48:43PM +0000, Peter Maydell wrote: > On 9 March 2018 at 18:20, Guenter Roeck wrote: > > On Fri, Mar 09, 2018 at 05:47:16PM +0000, Peter Maydell wrote: > >> Thanks for that really useful writeup. So if I understand correctly > >> we have several choices here: > >> > >> (1) we could implement a model of the IOMUX block that is at least > >> sufficient to support guests that configure it to route the ENET interrupt > >> line to a GPIO pin. Then we could apply this patch that fixes the ENET > >> line definitions. Old kernels would continue to work (for the same > >> reason they worked on hardware), and new ones would work now too. > >> This is in some ways the preferred option, but it's possibly a lot > >> of code and we're nearly in freeze for 2.12. > >> > >> (2) we could leave everything as it is for 2.12. This would mean that > >> at least we don't regress setups that used to work on older QEMU versions. > >> Downside is that we wouldn't be able to run Linux v4.15+, or other > >> guest OSes that don't have the bug that older Linux kernels do. > >> (Presumably we'd only do this on the understanding that we were going > >> to go down route (1) for 2.13.) > >> > >> (3) we could apply this patch for 2.12. Linux v4.15+ now works, as > >> do other guest OSes that use the ENET interrupt. v4.1 and older Linux > >> guests that used to boot in QEMU stop doing so, and 4.2-4.9 boot but > >> lose the ethernet device support. Perhaps for 2.13 we might > >> take route (1) to make those older guests start working again. > >> > >> Do I have that right? > >> > > Pretty much. > > > >> None of these options seems especially palatable to me, so we're > >> choosing the lesser evil, I think... (unless somebody wants to say > >> that option (1) would be 20 lines of code and here's the patch :-)) > >> I guess in the absence of (1) that (3) is better than (2) ? > >> > > > > I would prefer (2). This is what I decided to use in my "local" > > version of qemu. Older versions of Linux can be fixed by applying one > > (4.2..4.9) or two (4.1 and older) upstream patches; anyone interested > > running those kernels in qemu with Ethernet working should apply those > > patches (or, alternatively, provide a patch adding IOMUX support to > > qemu). > > Did you mean "prefer (3) [apply this patch]" ? The rest of the paragraph > makes more sense if you did. > Yes, sorry. Guenter