From: Guenter Roeck <linux@roeck-us.net> To: Finn Thain <fthain@telegraphics.com.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>, Joshua Thompson <funaho@jurai.org>, Geert Uytterhoeven <geert@linux-m68k.org>, linux-m68k@lists.linux-m68k.org, Laurent Vivier <lvivier@redhat.com>, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/9] macintosh/via-macii: Poll the device most likely to respond Date: Sun, 9 Aug 2020 18:16:59 -0700 [thread overview] Message-ID: <e3252495-2d5e-269f-6fa2-f46bbf609a53@roeck-us.net> (raw) In-Reply-To: <alpine.LNX.2.23.453.2008100844450.8@nippy.intranet> Hi, On 8/9/20 3:58 PM, Finn Thain wrote: > On Sun, 9 Aug 2020, Guenter Roeck wrote: > >> Hi, >> >> On Sun, Jun 28, 2020 at 02:23:12PM +1000, Finn Thain wrote: >>> Poll the most recently polled device by default, rather than the lowest >>> device address that happens to be enabled in autopoll_devs. This improves >>> input latency. Re-use macii_queue_poll() rather than duplicate that logic. >>> This eliminates a static struct and function. >>> >>> Fixes: d95fd5fce88f0 ("m68k: Mac II ADB fixes") # v5.0+ >>> Tested-by: Stan Johnson <userm57@yahoo.com> >>> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> >> >> With this patch applied, the qemu "q800" emulation no longer works and >> is stuck in early boot. Any idea why that might be the case, and/or how >> to debug it ? >> > > The problem you're seeing was mentioned in the cover letter, > https://lore.kernel.org/linux-m68k/cover.1593318192.git.fthain@telegraphics.com.au/ > > Since this series was merged, Linus' tree is no longer compatible with > long-standing QEMU bugs. > > The best way to fix this is to upgrade QEMU (latest is 5.1.0-rc3). Or use > the serial console instead of the framebuffer console. > I have no problem with that. Actually, I had checked the qemu commit log, but somehow I had missed missed the commits there. > I regret the inconvenience but the alternative was worse: adding code to > Linux to get compatibility with QEMU bugs (which were added to QEMU due to > Linux bugs). > > My main concern is correct operation on actual hardware, as always. But > some QEMU developers are working on support for operating systems besides > Linux. > > Therefore, I believe that both QEMU and Linux should aim for compatibility > with actual hardware and not bug compatibility with each other. > I absolutely agree. I repeated the test on the mainline kernel with qemu v5.1-rc3, and it works. I also made sure that older versions of Linux still work with the qemu v5.1.0-rc3. So everything is good, and sorry for the noise. Thanks, Guenter
WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net> To: Finn Thain <fthain@telegraphics.com.au> Cc: Laurent Vivier <lvivier@redhat.com>, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, Geert Uytterhoeven <geert@linux-m68k.org>, linuxppc-dev@lists.ozlabs.org, Joshua Thompson <funaho@jurai.org> Subject: Re: [PATCH 2/9] macintosh/via-macii: Poll the device most likely to respond Date: Sun, 9 Aug 2020 18:16:59 -0700 [thread overview] Message-ID: <e3252495-2d5e-269f-6fa2-f46bbf609a53@roeck-us.net> (raw) In-Reply-To: <alpine.LNX.2.23.453.2008100844450.8@nippy.intranet> Hi, On 8/9/20 3:58 PM, Finn Thain wrote: > On Sun, 9 Aug 2020, Guenter Roeck wrote: > >> Hi, >> >> On Sun, Jun 28, 2020 at 02:23:12PM +1000, Finn Thain wrote: >>> Poll the most recently polled device by default, rather than the lowest >>> device address that happens to be enabled in autopoll_devs. This improves >>> input latency. Re-use macii_queue_poll() rather than duplicate that logic. >>> This eliminates a static struct and function. >>> >>> Fixes: d95fd5fce88f0 ("m68k: Mac II ADB fixes") # v5.0+ >>> Tested-by: Stan Johnson <userm57@yahoo.com> >>> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> >> >> With this patch applied, the qemu "q800" emulation no longer works and >> is stuck in early boot. Any idea why that might be the case, and/or how >> to debug it ? >> > > The problem you're seeing was mentioned in the cover letter, > https://lore.kernel.org/linux-m68k/cover.1593318192.git.fthain@telegraphics.com.au/ > > Since this series was merged, Linus' tree is no longer compatible with > long-standing QEMU bugs. > > The best way to fix this is to upgrade QEMU (latest is 5.1.0-rc3). Or use > the serial console instead of the framebuffer console. > I have no problem with that. Actually, I had checked the qemu commit log, but somehow I had missed missed the commits there. > I regret the inconvenience but the alternative was worse: adding code to > Linux to get compatibility with QEMU bugs (which were added to QEMU due to > Linux bugs). > > My main concern is correct operation on actual hardware, as always. But > some QEMU developers are working on support for operating systems besides > Linux. > > Therefore, I believe that both QEMU and Linux should aim for compatibility > with actual hardware and not bug compatibility with each other. > I absolutely agree. I repeated the test on the mainline kernel with qemu v5.1-rc3, and it works. I also made sure that older versions of Linux still work with the qemu v5.1.0-rc3. So everything is good, and sorry for the noise. Thanks, Guenter
next prev parent reply other threads:[~2020-08-10 1:18 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-28 4:23 [PATCH 0/9] Macintosh II ADB driver fixes Finn Thain 2020-06-28 4:23 ` Finn Thain 2020-06-28 4:23 ` [PATCH 7/9] macintosh/via-macii: Use unsigned type for autopoll_devs variable Finn Thain 2020-06-28 4:23 ` Finn Thain 2020-06-28 4:23 ` [PATCH 2/9] macintosh/via-macii: Poll the device most likely to respond Finn Thain 2020-06-28 4:23 ` Finn Thain 2020-08-09 18:55 ` Guenter Roeck 2020-08-09 18:55 ` Guenter Roeck 2020-08-09 22:58 ` Finn Thain 2020-08-09 22:58 ` Finn Thain 2020-08-10 1:16 ` Guenter Roeck [this message] 2020-08-10 1:16 ` Guenter Roeck 2020-06-28 4:23 ` [PATCH 6/9] macintosh/via-macii: Use bool type for reading_reply variable Finn Thain 2020-06-28 4:23 ` Finn Thain 2020-06-28 4:23 ` [PATCH 1/9] macintosh/via-macii: Access autopoll_devs when inside lock Finn Thain 2020-06-28 4:23 ` Finn Thain 2020-08-09 19:01 ` Guenter Roeck 2020-08-09 19:01 ` Guenter Roeck 2020-08-09 23:15 ` Finn Thain 2020-08-09 23:15 ` Finn Thain 2020-06-28 4:23 ` [PATCH 9/9] macintosh/via-macii: Clarify definition of macii_init() Finn Thain 2020-06-28 4:23 ` Finn Thain 2020-06-28 4:23 ` [PATCH 5/9] macintosh/via-macii: Handle poll replies correctly Finn Thain 2020-06-28 4:23 ` Finn Thain 2020-06-28 4:23 ` [PATCH 4/9] macintosh/via-macii: Remove read_done state Finn Thain 2020-06-28 4:23 ` Finn Thain 2020-06-28 4:23 ` [PATCH 3/9] macintosh/via-macii: Handle /CTLR_IRQ signal correctly Finn Thain 2020-06-28 4:23 ` Finn Thain 2020-06-28 4:23 ` [PATCH 8/9] macintosh/via-macii: Use the stack for reset request storage Finn Thain 2020-06-28 4:23 ` Finn Thain 2020-07-27 7:26 ` [PATCH 0/9] Macintosh II ADB driver fixes Michael Ellerman 2020-07-27 7:26 ` Michael Ellerman
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=e3252495-2d5e-269f-6fa2-f46bbf609a53@roeck-us.net \ --to=linux@roeck-us.net \ --cc=benh@kernel.crashing.org \ --cc=fthain@telegraphics.com.au \ --cc=funaho@jurai.org \ --cc=geert@linux-m68k.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-m68k@lists.linux-m68k.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=lvivier@redhat.com \ --cc=mark.cave-ayland@ilande.co.uk \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.