Re: [PATCH v3 0/4] ide: implement simple legacy/native mode switching for PCI IDE controllers

[Kevin Wolf <kwolf@redhat.com>]

Am 17.11.2023 um 15:23 hat BALATON Zoltan geschrieben:
> On Thu, 16 Nov 2023, BALATON Zoltan wrote:
> > On Thu, 16 Nov 2023, Kevin Wolf wrote:
> > > Am 16.11.2023 um 11:33 hat Mark Cave-Ayland geschrieben:
> > > > This series adds a simple implementation of legacy/native mode
> > > > switching for PCI
> > > > IDE controllers and updates the via-ide device to use it.
> > > > 
> > > > The approach I take here is to add a new pci_ide_update_mode()
> > > > function which handles
> > > > management of the PCI BARs and legacy IDE ioports for each mode
> > > > to avoid exposing
> > > > details of the internal logic to individual PCI IDE controllers.
> > > > 
> > > > As noted in [1] this is extracted from a local WIP branch I have
> > > > which contains
> > > > further work in this area. However for the moment I've kept it simple (and
> > > > restricted it to the via-ide device) which is good enough for Zoltan's PPC
> > > > images whilst paving the way for future improvements after 8.2.
> > > > 
> > > > Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> > > > 
> > > > [1] https://lists.gnu.org/archive/html/qemu-devel/2023-10/msg05403.html
> > > > 
> > > > v3:
> > > > - Rebase onto master
> > > > - Move ide_portio_list[] and ide_portio_list2[] to IDE core to
> > > > prevent duplication in
> > > >   hw/ide/pci.c
> > > > - Don't zero BARs when switching from native mode to legacy
> > > > mode, instead always force
> > > >   them to read zero as suggested in the PCI IDE specification
> > > > (note: this also appears
> > > >   to fix the fuloong2e machine booting from IDE)
> > > > - Add comments in pci_ide_update_mode() suggested by Kevin
> > > > - Drop the existing R-B and T-B tags: whilst this passes my
> > > > local tests, the behaviour
> > > >   around zero BARs feels different enough here
> > > 
> > > Thanks, applied to the block branch.
> > 
> > I feel a bit left out of this conversation... Did Google or some other
> > spam filter decide again to filter my messages so you did not see them
> > at all? Could you confitm that you've got my previous two replies in
> > this thread so I know I'm not sending comments to /dev/null please?
> 
> Looks like there's some issue with these mails. They appear in the list
> archive but maybe not in people's mailboxes? Did any of you got this message
> and previous ones I've sent?
> https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg03180.html
> https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg03983.html

I received it, but at least the second one only after sending the mail
you replied to here.

For your specific concern, it seems to me that resetting BAR 4 on a
switch between compatibility mode and native mode is another via quirk
and should therefore be implemented in via.c rather than pci.c?

If I get a new version of the patches in the next few hours, I can
update the queued patches before sending a pull request, but otherwise
this can still be done in a separate patch.

Kevin