On Fri, 14 Jul 2023 21:50:01 +0300
Michael Tokarev <m...@tls.msk.ru> wrote:
> 14.07.2023 21:22, Alex Williamson wrote:
> > On Fri, 14 Jul 2023 14:38:06 +0300
> > Michael Tokarev <m...@tls.msk.ru> wrote:
> >
> >> diff --git a/hw/ppc/spapr_pci_vfio.c b/hw/ppc/spapr_pci_vfio.c
> >> index d8aeee0b7e..12e7790cf6 100644
> >> --- a/hw/ppc/spapr_pci_vfio.c
> >> +++ b/hw/ppc/spapr_pci_vfio.c
> >> @@ -39,7 +39,7 @@ static void spapr_phb_vfio_eeh_reenable(SpaprPhbState
> >> *sphb)
> >> void spapr_phb_vfio_reset(DeviceState *qdev)
> >> {
> >> /*
> >> - * The PE might be in frozen state. To reenable the EEH
> >> + * The PE might be in frozen state. To re-enable the EEH
> >> * functionality on it will clean the frozen state, which
> >> * ensures that the contained PCI devices will work properly
> >> * after reboot.
> >
> > This looks like personal preference, I can't actually find a source
> > that indicates "reenable" is anything other than a valid alternative of
> > "re-enable". Thanks,
>
> Well, it was one of the questionable suggestions from codespell. I like
> the re-enable better but in this case I don't really care for one way or
> another. I can drop this and other similar fixes. This one definitely
> does not hurt my eyes when I see it ;)
>
> $ git diff qemu-master..spelling | grep -c re-enable
> 8
>
> I can drop those 8 out of 400 :)
If we consider codespell to be the authority I guess we can leave it,
but it seems a bit pedantic to me. Thanks,
Alex
