qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 03/13] hw/arm/npcm7xx_boards: Replace drive_get_next() by


From: Markus Armbruster
Subject: Re: [PATCH v2 03/13] hw/arm/npcm7xx_boards: Replace drive_get_next() by drive_get()
Date: Thu, 18 Nov 2021 07:56:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Havard Skinnemoen <hskinnemoen@google.com> writes:

> On Wed, Nov 17, 2021 at 8:34 AM Markus Armbruster <armbru@redhat.com> 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 <hskinnemoen@google.com>
>> Cc: Tyrone Ting <kfting@nuvoton.com>
>> Cc: Peter Maydell <peter.maydell@linaro.org>
>> Cc: qemu-arm@nongnu.org
>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>> ---
>>  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)
>>                               &error_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 <hskinnemoen@google.com>

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(&soc->mmc.sdhci);
>> +    sdhci_attach_drive(&soc->mmc.sdhci, 0);
>>      npcm7xx_load_kernel(machine, soc);
>>  }
>>
>> --
>> 2.31.1
>>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]