qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Bill Paul <wpaul@windriver.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Andrey Smirnov <andrew.smirnov@gmail.com>,
	Chris Healy <cphealy@gmail.com>, Jason Wang <jasowang@redhat.com>,
	Jean-Christophe Dubois <jcd@tribudubois.net>
Subject: Re: [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines
Date: Fri, 9 Mar 2018 12:19:21 -0800	[thread overview]
Message-ID: <20180309201921.GA28623@roeck-us.net> (raw)
In-Reply-To: <CAFEAcA85BTihe_spKnRjraJ65YB6ja0OfG6b03ojj8cE-s410A@mail.gmail.com>

On Fri, Mar 09, 2018 at 06:48:43PM +0000, Peter Maydell wrote:
> On 9 March 2018 at 18:20, Guenter Roeck <linux@roeck-us.net> 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

  reply	other threads:[~2018-03-09 20:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-07 17:37 [Qemu-devel] [PATCH] fsl-imx6: Swap Ethernet interrupt defines Guenter Roeck
2018-03-08 10:50 ` Peter Maydell
2018-03-08 14:47   ` Guenter Roeck
2018-03-08 14:51     ` Peter Maydell
2018-03-08 15:05       ` Guenter Roeck
2018-03-08 17:12       ` Guenter Roeck
2018-03-08 18:28         ` Bill Paul
2018-03-08 19:22           ` Guenter Roeck
2018-03-09 17:47           ` Peter Maydell
2018-03-09 18:20             ` Guenter Roeck
2018-03-09 18:48               ` Peter Maydell
2018-03-09 20:19                 ` Guenter Roeck [this message]
2018-03-09 18:53               ` Bill Paul
2018-03-09 18:57                 ` Bill Paul
2018-03-09 21:38                 ` Guenter Roeck
2018-03-09 23:03                   ` Bill Paul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180309201921.GA28623@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=andrew.smirnov@gmail.com \
    --cc=cphealy@gmail.com \
    --cc=jasowang@redhat.com \
    --cc=jcd@tribudubois.net \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=wpaul@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).