From mboxrd@z Thu Jan 1 00:00:00 1970 From: 'David Gibson' Subject: Re: A question about generated phandle during dtb=>dts conversion Date: Fri, 5 Nov 2021 14:57:48 +1100 Message-ID: References: <005e01d7cfc8$8034c5f0$809e51d0$@etri.re.kr> <014201d7d092$21cb4050$6561c0f0$@etri.re.kr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lyI+PiAPISMjMqmp" Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1636103645; bh=GiWEzJVHfzhF8d0re+JUNhTfjayKOiifSFyrOPgIY8E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HoxZrKaduz30Y12mtiBrc2HNioo8aiagucY07ZVDleD0fmpIn8JLyElkc1+U6mBYB O34NsHPh+lclcibon4INIueLL1CgAGJ5EGOcykGho6WPCK9QRkQDi0ZT3GO6Yy/7g3 gZK4tjfcmTNAnEPsYqmVmDucUqr4Lnx8bsdyp+ko= Content-Disposition: inline In-Reply-To: <014201d7d092$21cb4050$6561c0f0$@etri.re.kr> List-ID: To: Chan Kim Cc: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org --lyI+PiAPISMjMqmp Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 03, 2021 at 06:06:47PM +0900, Chan Kim wrote: >=20 > Hi, David Gibson, > Thank you for the answer. I can understand it now. > Best regards, > Chan Kim > > -----Original Message----- > > From: David Gibson > > Sent: Wednesday, November 3, 2021 11:34 AM > > To: Chan Kim > > Cc: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > Subject: Re: A question about generated phandle during dtb=3D>dts conve= rsion > >=20 > > On Tue, Nov 02, 2021 at 06:03:27PM +0900, Chan Kim wrote: > > > Hello, all > > > I extracted a dtb file from qemu execution (arm virt machine) and > > > converted the dtb file to dts file using dtc. > > > But for some node that is referenced by other nodes, the phandle is > > > generated like =93phandle =3D <0x8000>=94 as shown below. > >=20 > > Note that the value is generated by qemu and is in the dtb. It's not > > generated by dtc during decompilation. > >=20 > > > apb-pclk { > > > =A0=A0=A0=A0=A0=A0=A0 phandle =3D <0x8000>; > > > =A0=A0=A0=A0=A0=A0=A0 clock-output-names =3D "clk24mhz"; > > > =A0=A0=A0=A0=A0=A0=A0 clock-frequency =3D <0x16e3600>; > > > =A0=A0=A0=A0=A0=A0=A0 #clock-cells =3D <0x00>; > > > =A0=A0=A0=A0=A0=A0=A0 compatible =3D "fixed-clock"; > > > =A0=A0=A0 }; > > > > > > And another node is using this phandle like this. (the clocks is the > > > phandle for the apb-pclk above.) > > > > > > pl061@9030000 { > > > =A0=A0=A0=A0=A0=A0=A0 phandle =3D <0x8003>; > > > =A0=A0=A0=A0=A0=A0=A0 clock-names =3D "apb_pclk"; > > > =A0=A0=A0=A0=A0=A0=A0 clocks =3D <0x8000>; > > > =A0=A0=A0=A0=A0=A0=A0 interrupts =3D <0x00 0x07 0x04>; > > > =A0=A0=A0=A0=A0=A0=A0 gpio-controller; > > > =A0=A0=A0=A0=A0=A0=A0 #gpio-cells =3D <0x02>; > > > =A0=A0=A0=A0=A0=A0=A0 compatible =3D "arm,pl061\0arm,primecell"; > > > =A0=A0=A0=A0=A0=A0=A0 reg =3D <0x00 0x9030000 0x00 0x1000>; > > > =A0=A0=A0 }; > > > > > > When I convert the dts back to the dtb, dtc doesn=92t understand the > > > phandle and complains that it is not a phandle referenece. > > > > > > dts.dts:276.3-21: Warning (clocks_property): /pl061@9030000:clocks: > > > cell 0 is not a phandle reference > > > > > > I=92ve checked event with this warning, the phandle reference is being > > > preserved through out the procedure. > > > So, if I want to extract a dtb and convert it to dts, edit some and > > > convert it back to dtb, how can I prevent this kind of phandle warnin= g? > > > And why doesn't dtc add labels to the referenced nodes and let other > > > nodes use that label as phandle? > >=20 > > The short answer is because dtc doesn't know it's a phandle. dtb is no= t a > > self-describing format - the properties are just bytestrings, and you n= eed > > to know what you're expecting in there in order to decode them (that's > > what dt bindings give you). > >=20 > > So the only way that dtc could know that those 4 bytes in the 'clocks' > > property are actually a phandle is by specifically knowing about the > > "clocks" property. dtc has *some* knowledge of specific properties in = the > > checks, but it's far from complete (and complete knowledge of the bindi= ngs > > is pretty much out of scope for dtc). > >=20 > > But.. for the normal case of writing a dts file directly, it's useful to > > get a warning if you don't use a reference somewhere you probably should > > (anywhere that's a phandle), so dtc does check that. > >=20 > > So, I think basically in just the same way that you might expect genera= ted > > or decompiled code to be rather messy and generate compiler warnings, s= o a > > decompiled dts might have messy things and generate warnings. You can > > switch off the warnings explicitly if you need (-Wno-clocks_property in > > this case). Actually, a nicer way of handling this just occurred to me. It would probably be a good idea to add to the dts syntax a new tag, maybe "/strict/". Without this tag, checks which rely on information that's only in the source, not the dtb (types, phandles etc.) would be disabled by default. The tag itself obviously wouldn't be encoded into the dtb, so if you compiled then decompiled the tag would be lost, meaning that the output dtb wouldn't trigger checks. Unfortunately, I'm very unlikely to have time to implement this any time soon. --=20 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 --lyI+PiAPISMjMqmp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAmGEq7kACgkQbDjKyiDZ s5K9cQ//Vh+PFVHryG13LNAPo43qpBLx0YBs4JzOCNghvuIHAhJhpaV/+ptfVl8x w79+ov1QnyycW7W3PV/k29z7FkJoInad9KgRIHPFSO7iS7sk/6GbVXo3HA/sxgEA nB7ZzDyJNEy7AflcBrS89V18/MH/LcX9FR2CPywjjJNLLBCzzBHbkaNT3zG2vKVz IOcPUGhtkYKOY9QcZlARtwsMBKai2XoOKgLNBgnsdoVwScSkRmfbHXpQurHeA4Sl QWJEk5g9tu3fxIJb+kiVjaG0jA+xkhGKRQIKm0w3r16cJg8PPuB04FbyWGPWR5it qCTCQhGxvLqX11yX9myjifyx3r7CB0P+jv1AI+A4yek6nFfS6s8QPxWRDwi7BH5a 3HJoZiao92XpI/LlkKFHbJ19J9lTPHgM452oscmhWT8V7so4IdZVrBU5wQoCzUE8 H+ous2PmqfCq6MSM+gos+RuaRuZSfS3MX1oWmY/gqYxj+lXcAYYbe0yc2LN7stX5 0UB6aXp6zon+Jl7rY0+1cHw1GyOV4jrJA2jLqXNbNieD8LFSlKoDwz/iaGCRKSaL KKyFLqjIhHvrNAl77zOBzpTJgkFYs+iO64oNm5doGgAoO/2+vpvK3xGl9iQEpXx0 JhVidKn/71cE7hkvQQnLfejznfK5ByZ4TFeA/lzCSilZHnLpHQE= =nrln -----END PGP SIGNATURE----- --lyI+PiAPISMjMqmp--