From: andre.przywara@arm.com (Andre Przywara)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 01/16] FDT: introduce global phandle allocation
Date: Mon, 19 Dec 2016 18:43:29 +0000 [thread overview]
Message-ID: <80430161-b363-4740-0eef-8cb73bc2ecbd@arm.com> (raw)
In-Reply-To: <be44a9ad-f820-9a62-9a5d-682867674e91@arm.com>
Hi Marc,
On 09/12/16 11:55, Marc Zyngier wrote:
> Hi Andre,
>
> On 04/11/16 17:31, Andre Przywara wrote:
>> Allocating an FDT phandle (a unique identifier) using a static
>> variable in a static inline function defined in a header file works
>> only if all users are in the same source file. So trying to allocate
>> a handle from two different compilation units fails.
>> Introduce global phandle allocation and reference code to properly
>> allocate unique phandles.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>> Makefile | 1 +
>> arm/fdt.c | 2 +-
>> arm/gic.c | 2 +-
>> include/kvm/fdt.h | 10 +++++-----
>> kvm-fdt.c | 26 ++++++++++++++++++++++++++
>> 5 files changed, 34 insertions(+), 7 deletions(-)
>> create mode 100644 kvm-fdt.c
>>
>> diff --git a/Makefile b/Makefile
>> index 1f0196f..e4a4002 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -98,6 +98,7 @@ OBJS += kvm-ipc.o
>> OBJS += builtin-sandbox.o
>> OBJS += virtio/mmio.o
>> OBJS += hw/i8042.o
>> +OBJS += kvm-fdt.o
>>
>> # Translate uname -m into ARCH string
>> ARCH ?= $(shell uname -m | sed -e s/i.86/i386/ -e s/ppc.*/powerpc/ \
>> diff --git a/arm/fdt.c b/arm/fdt.c
>> index 381d48f..8bcfffb 100644
>> --- a/arm/fdt.c
>> +++ b/arm/fdt.c
>> @@ -114,7 +114,7 @@ static int setup_fdt(struct kvm *kvm)
>> {
>> struct device_header *dev_hdr;
>> u8 staging_fdt[FDT_MAX_SIZE];
>> - u32 gic_phandle = fdt__alloc_phandle();
>> + u32 gic_phandle = fdt__get_phandle(PHANDLE_GIC);
>> u64 mem_reg_prop[] = {
>> cpu_to_fdt64(kvm->arch.memory_guest_start),
>> cpu_to_fdt64(kvm->ram_size),
>> diff --git a/arm/gic.c b/arm/gic.c
>> index d6d6dd0..b60437e 100644
>> --- a/arm/gic.c
>> +++ b/arm/gic.c
>> @@ -222,7 +222,7 @@ void gic__generate_fdt_nodes(void *fdt, u32 phandle, enum irqchip_type type)
>> _FDT(fdt_property_cell(fdt, "#interrupt-cells", GIC_FDT_IRQ_NUM_CELLS));
>> _FDT(fdt_property(fdt, "interrupt-controller", NULL, 0));
>> _FDT(fdt_property(fdt, "reg", reg_prop, sizeof(reg_prop)));
>> - _FDT(fdt_property_cell(fdt, "phandle", phandle));
>> + _FDT(fdt_property_cell(fdt, "phandle", fdt__get_phandle(PHANDLE_GIC)));
>> _FDT(fdt_end_node(fdt));
>> }
>>
>> diff --git a/include/kvm/fdt.h b/include/kvm/fdt.h
>> index 53d85a4..cd2bb72 100644
>> --- a/include/kvm/fdt.h
>> +++ b/include/kvm/fdt.h
>> @@ -8,6 +8,10 @@
>> #include <linux/types.h>
>>
>> #define FDT_MAX_SIZE 0x10000
>> +#define FDT_INVALID_PHANDLE 0
>> +#define FDT_IS_VALID_PHANDLE(phandle) ((phandle) != FDT_INVALID_PHANDLE)
>> +
>> +enum phandles {PHANDLE_GIC, PHANDLES_MAX};
>>
>> /* Those definitions are generic FDT values for specifying IRQ
>> * types and are used in the Linux kernel internally as well as in
>> @@ -33,10 +37,6 @@ enum irq_type {
>> } \
>> } while (0)
>>
>> -static inline u32 fdt__alloc_phandle(void)
>> -{
>> - static u32 phandle = 0;
>> - return ++phandle;
>> -}
>> +u32 fdt__get_phandle(enum phandles phandle);
>>
>> #endif /* KVM__FDT_H */
>> diff --git a/kvm-fdt.c b/kvm-fdt.c
>> new file mode 100644
>> index 0000000..d05f3fe
>> --- /dev/null
>> +++ b/kvm-fdt.c
>> @@ -0,0 +1,26 @@
>> +/*
>> + * Commonly used FDT functions.
>> + */
>> +
>> +#include <stdio.h>
>> +#include "kvm/fdt.h"
>> +#include "kvm/util.h"
>> +
>> +u32 phandles[PHANDLES_MAX] = {};
>
> It is a bit weird that you're initializing this to zero...
>
>> +u32 next_phandle = 1;
>> +
>> +u32 fdt__get_phandle(enum phandles phandle)
>> +{
>> + u32 ret;
>> +
>> + if (phandle >= PHANDLES_MAX)
>> + return FDT_INVALID_PHANDLE;
>> +
>> + ret = phandles[phandle];
>> + if (ret == FDT_INVALID_PHANDLE) {
>
> and yet test against a #define that isn't the initializer.
Well, yes. The problem is that AFAIK you cannot initialize an array
easily with all the values getting set to something other than zero.
So I could write
u32 phandles[PHANDLES_MAX] = {FDT_INVALID_PHANDLE};
above, but as that would only set the first member to
FDT_INVALID_PHANDLE (and all the others to 0), so it would rely on the
define actually being zero to work reliably. So my thought was to avoid
readers falling into this trap by not specifying the reset value
explicitly. Also that's the reason that 0 is the invalid value, which I
don't like too much, tbh.
So shall I make this a comment then?
Or do I miss something here?
> Also, given that fdt__get_phandle() can now fail by returning
> FDT_INVALID_HANDLE, maybe we should abort instead of returning something
> that is definitely wrong and use it blindly (which is going to be fun to
> debug...).
Yes, good point. Given that this hints at an internal error, die() seems
to be the appropriate action here.
Cheers,
Andre.
>
>
>> + ret = next_phandle++;
>> + phandles[phandle] = ret;
>> + }
>> +
>> + return ret;
>> +}
>>
>
> Thanks,
>
> M.
>
next prev parent reply other threads:[~2016-12-19 18:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-04 17:31 [PATCH v8 00/16] kvmtool: arm: ITS emulation and GSI routing support Andre Przywara
2016-11-04 17:31 ` [PATCH v8 01/16] FDT: introduce global phandle allocation Andre Przywara
2016-12-09 11:55 ` Marc Zyngier
2016-12-19 18:43 ` Andre Przywara [this message]
2016-12-20 9:43 ` Andrew Jones
2016-12-09 12:03 ` Marc Zyngier
2016-12-19 18:43 ` Andre Przywara
2017-02-01 16:44 ` André Przywara
2017-02-01 17:13 ` Marc Zyngier
2017-02-02 16:31 ` Andre Przywara
2016-11-04 17:31 ` [PATCH v8 02/16] arm: use new phandle allocation functions Andre Przywara
2016-12-09 13:26 ` Marc Zyngier
2016-11-04 17:31 ` [PATCH v8 03/16] irq: move IRQ routing into irq.c Andre Przywara
2016-12-09 14:41 ` Marc Zyngier
2016-11-04 17:31 ` [PATCH v8 04/16] MSI-X: update GSI routing after changed MSI-X configuration Andre Przywara
2016-12-09 17:13 ` Marc Zyngier
2016-12-19 18:44 ` Andre Przywara
2016-11-04 17:31 ` [PATCH v8 05/16] virtio: fix endianness check for vhost support Andre Przywara
2016-11-04 17:31 ` [PATCH v8 06/16] PCI: Only allocate IRQ routing entry when available Andre Przywara
2016-11-04 17:31 ` [PATCH v8 07/16] update public Linux headers for GICv3 ITS emulation Andre Przywara
2016-11-04 17:31 ` [PATCH v8 08/16] arm: gic: allow 32-bit compilation Andre Przywara
2016-11-04 17:31 ` [PATCH v8 09/16] arm: allow creation of an MSI register frame region Andre Przywara
2016-11-04 17:31 ` [PATCH v8 10/16] arm: FDT: create MSI controller DT node Andre Przywara
2016-11-04 17:31 ` [PATCH v8 11/16] add kvm__check_vm_capability Andre Przywara
2016-11-04 17:31 ` [PATCH v8 12/16] PCI: inject PCI device ID on MSI injection Andre Przywara
2016-11-04 17:32 ` [PATCH v8 13/16] arm: setup SPI IRQ routing tables Andre Przywara
2016-11-04 17:32 ` [PATCH v8 14/16] extend GSI IRQ routing to take a device ID Andre Przywara
2016-11-04 17:32 ` [PATCH v8 15/16] arm64: enable GICv3-ITS emulation Andre Przywara
2016-11-04 17:32 ` [PATCH v8 16/16] arm: add support for vGICv3 and vITS Andre Przywara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=80430161-b363-4740-0eef-8cb73bc2ecbd@arm.com \
--to=andre.przywara@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox