[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v8 0/4] i386: expose floppy-related objects in S
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH v8 0/4] i386: expose floppy-related objects in SSDT |
Date: |
Thu, 3 Mar 2016 20:29:57 +0200 |
On Thu, Mar 03, 2016 at 06:48:38PM +0300, Roman Kagan wrote:
> On Wed, Mar 02, 2016 at 05:10:58PM +0200, Michael S. Tsirkin wrote:
> > On Wed, Mar 02, 2016 at 06:08:41PM +0300, Denis V. Lunev wrote:
> > > On 02/17/2016 09:25 PM, Roman Kagan wrote:
> > > >Windows on UEFI systems is only capable of detecting the presence and
> > > >the type of floppy drives via corresponding ACPI objects.
> > > >
> > > >Those objects are added in patch 4; the preceding ones pave the way to
> > > >it, by making the necessary data public and by moving the whole floppy
> > > >drive controller description into runtime-generated SSDT.
> > > >
> > > >Roman Kagan (4):
> > > > i386/acpi: make floppy controller object dynamic
> > > > i386: expose floppy drive CMOS type
> > > > fdc: add function to determine drive chs limits
> > > > i386: populate floppy drive information in DSDT
> > > >
> > > >Signed-off-by: Roman Kagan <address@hidden>
> > > >Cc: Igor Mammedov <address@hidden>
> > > >Cc: "Michael S. Tsirkin" <address@hidden>
> > > >Cc: Marcel Apfelbaum <address@hidden>
> > > >Cc: John Snow <address@hidden>
> > > >Cc: Laszlo Ersek <address@hidden>
> > > >Cc: Kevin O'Connor <address@hidden>
> > > >---
> > > >changes since v7:
> > > > - rebased to latest master
> > > > - use drive max c,h,s rather than the current diskette geometry
> > > >
> > > > hw/block/fdc.c | 23 +++++++++++++
> > > > hw/i386/acpi-build.c | 92
> > > > ++++++++++++++++++++++++++++++++++++--------------
> > > > hw/i386/pc.c | 2 +-
> > > > include/hw/block/fdc.h | 2 ++
> > > > include/hw/i386/pc.h | 1 +
> > > > 5 files changed, 94 insertions(+), 26 deletions(-)
> > > >
> > > Michael, we have obtained Reviwed-by: from John.
> > > Does this set is good to be accepted or your
> > > last comment is mandatory?
> >
> > Pls do but you can make it a separate patch on top
> > if you prefer.
>
> Sorry I must have lost the track: I thought that all your concerns had
> been addressed by John's comment. Can you please point out what issues
> still remain in this patchset that prevent it from being merged?
>
> Thanks,
> Roman.
it's in my tree so nothing.
I prefer refactoring the loop slightly, by patch on top.