[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
>>
- Re: [PATCH v2 01/13] hw/sd/ssi-sd: Do not create SD card within controller's realize, (continued)
- [PATCH v2 13/13] blockdev: Drop unused drive_get_next(), Markus Armbruster, 2021/11/17
- [PATCH v2 12/13] hw/arm/aspeed: Replace drive_get_next() by drive_get(), Markus Armbruster, 2021/11/17
- [PATCH v2 08/13] hw/arm/xlnx-versal-virt: Replace drive_get_next() by drive_get(), Markus Armbruster, 2021/11/17
- [PATCH v2 03/13] hw/arm/npcm7xx_boards: Replace drive_get_next() by drive_get(), Markus Armbruster, 2021/11/17
- [PATCH v2 10/13] hw/arm/xlnx-zcu102: Replace drive_get_next() by drive_get(), Markus Armbruster, 2021/11/17
- [PATCH v2 11/13] hw/arm/xilinx_zynq: Replace drive_get_next() by drive_get(), Markus Armbruster, 2021/11/17
- [PATCH v2 06/13] hw/arm/mcimx6ul-evk: Replace drive_get_next() by drive_get(), Markus Armbruster, 2021/11/17
- [PATCH v2 05/13] hw/arm/imx25_pdk: Replace drive_get_next() by drive_get(), Markus Armbruster, 2021/11/17