Re: [PATCH v2 03/13] hw/arm/npcm7xx_boards: Replace drive_get_next() by drive_get()
Havard Skinnemoen writes:
> On Wed, Nov 17, 2021 at 8:34 AM Markus Armbruster wrote:
>>
>> drive_get_next() is basically a bad idea. It returns the "next" block
>> backend of a certain interface type. "Next" means bus=0,unit=N, where
>> subsequent calls count N up from zero, per interface type.
>>
>> This lets you define unit numbers implicitly by execution order. If the
>> order changes, or new calls appear "in the middle", unit numbers change.
>> ABI break. Hard to spot in review.
>>
>> Machine "quanta-gbs-bmc" connects just one backend with
>> drive_get_next(), but with a helper function. Change it to use
>> drive_get() directly. This makes the unit numbers explicit in the
>> code.
>>
>> Cc: Havard Skinnemoen
>> Cc: Tyrone Ting
>> Cc: Peter Maydell
>> Cc: qemu-...@nongnu.org
>> Signed-off-by: Markus Armbruster
>> ---
>> hw/arm/npcm7xx_boards.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/hw/arm/npcm7xx_boards.c b/hw/arm/npcm7xx_boards.c
>> index dec7d16ae5..d8a49e4e85 100644
>> --- a/hw/arm/npcm7xx_boards.c
>> +++ b/hw/arm/npcm7xx_boards.c
>> @@ -84,9 +84,9 @@ static void npcm7xx_connect_dram(NPCM7xxState *soc,
>> MemoryRegion *dram)
>> _abort);
>> }
>>
>> -static void sdhci_attach_drive(SDHCIState *sdhci)
>> +static void sdhci_attach_drive(SDHCIState *sdhci, int unit)
>> {
>> -DriveInfo *di = drive_get_next(IF_SD);
>> +DriveInfo *di = drive_get(IF_SD, 0, unit);
>
> +Hao Wu IIRC the chip has separate SD and eMMC buses. Would it make
> sense to take the bus number as a parameter as well? Is bus 0 the
> right one to use in this case?
>
> The existing code always uses bus 0, so this is an improvement either way.
Using separate buses for different kinds of devices would be neater, but
it also would be an incompatible change. I can't judge whether
incompatible change is okay here.
This patch is just refactoring code. An interface change, if desired,
should be a separate patch.
> Reviewed-by: Havard Skinnemoen
Thanks!
>
>> BlockBackend *blk = di ? blk_by_legacy_dinfo(di) : NULL;
>>
>> BusState *bus = qdev_get_child_bus(DEVICE(sdhci), "sd-bus");
>> @@ -374,7 +374,7 @@ static void quanta_gbs_init(MachineState *machine)
>>drive_get(IF_MTD, 0, 0));
>>
>> quanta_gbs_i2c_init(soc);
>> -sdhci_attach_drive(>mmc.sdhci);
>> +sdhci_attach_drive(>mmc.sdhci, 0);
>> npcm7xx_load_kernel(machine, soc);
>> }
>>
>> --
>> 2.31.1
>>
Re: [PATCH v2 03/13] hw/arm/npcm7xx_boards: Replace drive_get_next() by drive_get()
Yes, there's SD and MMC buses. It looks like the current code only supports
mmc ("soc->mmc.sdhci") but not the sd ("soc->sd.sdhci").
It's probably good to make the bus number a parameter as well and use them
to distinguish. We might need a separate patch to do that.
On Wed, Nov 17, 2021 at 8:54 AM Havard Skinnemoen
wrote:
> On Wed, Nov 17, 2021 at 8:34 AM Markus Armbruster
> wrote:
> >
> > drive_get_next() is basically a bad idea. It returns the "next" block
> > backend of a certain interface type. "Next" means bus=0,unit=N, where
> > subsequent calls count N up from zero, per interface type.
> >
> > This lets you define unit numbers implicitly by execution order. If the
> > order changes, or new calls appear "in the middle", unit numbers change.
> > ABI break. Hard to spot in review.
> >
> > Machine "quanta-gbs-bmc" connects just one backend with
> > drive_get_next(), but with a helper function. Change it to use
> > drive_get() directly. This makes the unit numbers explicit in the
> > code.
> >
> > Cc: Havard Skinnemoen
> > Cc: Tyrone Ting
> > Cc: Peter Maydell
> > Cc: qemu-...@nongnu.org
> > Signed-off-by: Markus Armbruster
> > ---
> > hw/arm/npcm7xx_boards.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/hw/arm/npcm7xx_boards.c b/hw/arm/npcm7xx_boards.c
> > index dec7d16ae5..d8a49e4e85 100644
> > --- a/hw/arm/npcm7xx_boards.c
> > +++ b/hw/arm/npcm7xx_boards.c
> > @@ -84,9 +84,9 @@ static void npcm7xx_connect_dram(NPCM7xxState *soc,
> MemoryRegion *dram)
> > _abort);
> > }
> >
> > -static void sdhci_attach_drive(SDHCIState *sdhci)
> > +static void sdhci_attach_drive(SDHCIState *sdhci, int unit)
> > {
> > -DriveInfo *di = drive_get_next(IF_SD);
> > +DriveInfo *di = drive_get(IF_SD, 0, unit);
>
> +Hao Wu IIRC the chip has separate SD and eMMC buses. Would it make
> sense to take the bus number as a parameter as well? Is bus 0 the
> right one to use in this case?
>
> The existing code always uses bus 0, so this is an improvement either way.
>
> Reviewed-by: Havard Skinnemoen
>
> > BlockBackend *blk = di ? blk_by_legacy_dinfo(di) : NULL;
> >
> > BusState *bus = qdev_get_child_bus(DEVICE(sdhci), "sd-bus");
> > @@ -374,7 +374,7 @@ static void quanta_gbs_init(MachineState *machine)
> >drive_get(IF_MTD, 0, 0));
> >
> > quanta_gbs_i2c_init(soc);
> > -sdhci_attach_drive(>mmc.sdhci);
> > +sdhci_attach_drive(>mmc.sdhci, 0);
> > npcm7xx_load_kernel(machine, soc);
> > }
> >
> > --
> > 2.31.1
> >
>
Re: [PATCH v2 03/13] hw/arm/npcm7xx_boards: Replace drive_get_next() by drive_get()
On Wed, Nov 17, 2021 at 8:34 AM Markus Armbruster wrote:
>
> drive_get_next() is basically a bad idea. It returns the "next" block
> backend of a certain interface type. "Next" means bus=0,unit=N, where
> subsequent calls count N up from zero, per interface type.
>
> This lets you define unit numbers implicitly by execution order. If the
> order changes, or new calls appear "in the middle", unit numbers change.
> ABI break. Hard to spot in review.
>
> Machine "quanta-gbs-bmc" connects just one backend with
> drive_get_next(), but with a helper function. Change it to use
> drive_get() directly. This makes the unit numbers explicit in the
> code.
>
> Cc: Havard Skinnemoen
> Cc: Tyrone Ting
> Cc: Peter Maydell
> Cc: qemu-...@nongnu.org
> Signed-off-by: Markus Armbruster
> ---
> hw/arm/npcm7xx_boards.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/hw/arm/npcm7xx_boards.c b/hw/arm/npcm7xx_boards.c
> index dec7d16ae5..d8a49e4e85 100644
> --- a/hw/arm/npcm7xx_boards.c
> +++ b/hw/arm/npcm7xx_boards.c
> @@ -84,9 +84,9 @@ static void npcm7xx_connect_dram(NPCM7xxState *soc,
> MemoryRegion *dram)
> _abort);
> }
>
> -static void sdhci_attach_drive(SDHCIState *sdhci)
> +static void sdhci_attach_drive(SDHCIState *sdhci, int unit)
> {
> -DriveInfo *di = drive_get_next(IF_SD);
> +DriveInfo *di = drive_get(IF_SD, 0, unit);
+Hao Wu IIRC the chip has separate SD and eMMC buses. Would it make
sense to take the bus number as a parameter as well? Is bus 0 the
right one to use in this case?
The existing code always uses bus 0, so this is an improvement either way.
Reviewed-by: Havard Skinnemoen
> BlockBackend *blk = di ? blk_by_legacy_dinfo(di) : NULL;
>
> BusState *bus = qdev_get_child_bus(DEVICE(sdhci), "sd-bus");
> @@ -374,7 +374,7 @@ static void quanta_gbs_init(MachineState *machine)
>drive_get(IF_MTD, 0, 0));
>
> quanta_gbs_i2c_init(soc);
> -sdhci_attach_drive(>mmc.sdhci);
> +sdhci_attach_drive(>mmc.sdhci, 0);
> npcm7xx_load_kernel(machine, soc);
> }
>
> --
> 2.31.1
>
