Re: [Qemu-devel] [PATCH v8 0/4] i386: expose floppy-related objects in SSDT

[Michael S. Tsirkin]

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.