On Mon, May 01, 2023 at 01:43:22PM -0500, Rob Herring wrote: > On Sat, Apr 29, 2023 at 1:52 AM David Gibson > wrote: > > > > On Fri, Apr 28, 2023 at 01:32:17PM +0200, Uwe Kleine-König wrote: > > > From: Uwe Kleine-König > > > > > > A string that contains '\0' can be written as a list of strings e.g. > > > > > > clock-names = "di0_pll\0di1_pll\0di0_sel\0di1_sel\0di2_sel\0di3_sel\0di0\0di1"; > > > > > > is equivalent to > > > > > > clock-names = "di0_pll", "di1_pll", "di0_sel", "di1_sel", "di2_sel", "di3_sel", "di0", "di1"; > > > > > > The latter is easier to read, to use this format instead. > > > > > > Two test files are adapted accordingly to keep the test suite happy. > > > > > > Signed-off-by: Uwe Kleine-König > > > --- > > > Changes since (implicit) v1, sent with Message-Id: > > > 20230426182405.572729-1-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org: > > > > > > - Adapt the test suite > > > > > > tests/type-preservation.dt.yaml | 2 +- > > > tests/type-preservation.dts | 2 +- > > > treesource.c | 2 +- > > > 3 files changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/tests/type-preservation.dt.yaml b/tests/type-preservation.dt.yaml > > > index a0cc64cc4b69..e238d395aa02 100644 > > > --- a/tests/type-preservation.dt.yaml > > > +++ b/tests/type-preservation.dt.yaml > > > @@ -12,7 +12,7 @@ > > > int16-matrix: [!u16 [0x1234, 0x5678], [0x90ab, 0xcdef]] > > > int64: [!u64 [0x200000000]] > > > int64-array: [!u64 [0x100000000, 0x0]] > > > - a-string-with-nulls: ["foo\0bar", "baz"] > > > + a-string-array: ["foo", "bar", "baz"] > > > > > > Ah. I was afraid of this. So "fixing" the test highlights another > > problem. It's pretty clear to me that the whole point of this test is > > to test the preservation of the internal \0, as distinct from the > > separate strings later in there. So, this is exercising an edge case > > of the typing markers we now add. > > > > Now.. personally, I've never been particularly convinced that the type > > preservation stuff was a particularly good idea. It will never be > > perfect, and it can give a misleading impression that information is > > preserved into the dtb which isn't. But, it's pretty well established > > now, and I assume people had reasons for wanting it. > > I don't really think so. It was a side effect of adding the yaml > support AFAICT. Before commit 32b9c6130762 ("Preserve datatype markers > when emitting dts format"), any '\0' was not maintained. Right, which also introduced this test, presumbly to verify those semantics. > Speaking of the YAML output, at least for dtschema, it is no longer > being used with using dtb format directly for over a year now. Support > for yaml encoding in dtschema was removed completely in the January > release. Perhaps in dtc it should be deprecated for some time if not > just outright removed. I'm not aware of anyone else using it. Oh, that's good to hear. I've long thought the yaml output was a bad idea, because it makes people think the dtb encodes type information which it doesn't and can't. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson