From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9A0D9C433EF for ; Thu, 6 Jan 2022 16:55:49 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id E3EA280FCC; Thu, 6 Jan 2022 17:55:46 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=nic.cz Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=nic.cz header.i=@nic.cz header.b="LojQAHkD"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 0DE0A8303A; Thu, 6 Jan 2022 17:55:45 +0100 (CET) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 11DE580F9C for ; Thu, 6 Jan 2022 17:55:42 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=nic.cz Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=marek.behun@nic.cz Received: from thinkpad (unknown [172.20.6.87]) by mail.nic.cz (Postfix) with ESMTPSA id 91A14140BA3; Thu, 6 Jan 2022 17:55:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1641488141; bh=ieiN73VH0PetPdknBqIzYse98On8d4YmfC/yobLzdK0=; h=Date:From:To; b=LojQAHkDNGqFyNXM9NNvf0plLLUWL4qAu7zmNo7ibRxykafmSKe+9WboWGiF62IWC EbMbixq0B8zh0cr4jUAB20zniVrWj80tUYyCG0rGxOAvSWqkz4uR0j/EH2YrEcHTY0 7XWI6WnXrsTMMe7aFn2CvMS7i0EK6wTFUfff4FBw= Date: Thu, 6 Jan 2022 17:55:40 +0100 From: Marek =?UTF-8?B?QmVow7pu?= To: Simon Glass Cc: U-Boot Mailing List Subject: Re: difference between fdtdec and fdt_support ? Message-ID: <20220106175540.365e8585@thinkpad> In-Reply-To: References: <20220106132100.56f55e02@thinkpad> <20220106171007.7f39094c@thinkpad> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On Thu, 6 Jan 2022 09:15:17 -0700 Simon Glass wrote: > Hi Marek, >=20 > On Thu, 6 Jan 2022 at 09:10, Marek Beh=C3=BAn wrote: > > > > On Thu, 6 Jan 2022 08:48:48 -0700 > > Simon Glass wrote: > > =20 > > > Hi Marek, > > > > > > On Thu, 6 Jan 2022 at 05:21, Marek Beh=C3=BAn wr= ote: =20 > > > > > > > > Hi Simon, > > > > > > > > I am a little confused. > > > > > > > > We have > > > > common/fdt_support.c > > > > and > > > > lib/fdtdec.c > > > > > > > > The second one implements for example fdtdec_get_is_enabled(), whic= h I > > > > would rather expect in fdt_support by name fdt_node_is_available(),= or > > > > something like that. =20 > > > > > > Should be moved to ofnode =20 > > > > ?? But this function is needed for example when fixing device tree for > > Linux. > > =20 > > > > > > > > Also fdtdec does a strange thing with compatible strings: it declar= es > > > > an enum for compatible strings and then a map which maps this enum > > > > values to compatible strings... Why not just use the compatible str= ings? =20 > > > > > > Did you see the comment? > > > > > > * NOTE: This list is basically a TODO list for things that need to be > > > * converted to driver model. So don't add new things here unless the= re is a > > > * good reason why driver-model conversion is infeasible. Examples in= clude > > > * things which are used before driver model is available. > > > > > > This is effectively a list of things that should be converted to > > > driver model. The list should then go away. =20 > > > > Hmm. But can't that be simply made into a list in a comment? Because > > currently this is compiled in for every board that uses any such > > function from fdtdec, even if they don't use any string from those > > compatible strings. =20 >=20 > Well another option would be to delete the boards that need it, since > no one has seen fit to resolve this all these years. Or create some > drivers for them. I still don't quite understand why the compatible strings have to be in this fdtdec.c file. For example in arch/arm/mach-socfpga/clock_manager_arria10.c we call node =3D fdtdec_next_compatible(blob, 0, COMPAT_ALTERA_SOCFPGA_CLK_INIT); This constant, COMPAT_ALTERA_SOCFPGA_CLK_INIT, is an enum constant, which is then in fdtdec.c translated to string compatible with compat_names[id] for which fdt_node_offset_by_compatible() is used. So why not simply put this string constant into arch/arm/mach-socfpga/clock_manager_arria10.c by calling node =3D fdt_node_offset_by_compatible(blob, node, "altr,socfpga-a10-clk-init"); ?? That way at least the string literals won't be compiled in into every u-boot binary, even those that don't need those literals at all. > > =20 > > > > > > > > What is the purpose of having two files implementing fdt stuff? =20 > > > > > > fdtdec - for reading from the DT. Should go away and be replaced with > > > the ofnode API, and fdtaddr.c > > > fdt_support - for updating the DT, e.g. for fixups before booting an = OS =20 > > > > Thanks! Okay that makes sense. This means that we should also have > > fdt_node_is_available() in fdt_support.c which does the same thing. > > (For now this can be made a static inline function that calls > > fdtdec_get_is_enabled().) =20 >=20 > OK. >=20 > BTW fdt_support.c should really move to use ofnode. There are few > ofnode 'write' functions at present, but we should fill those out so > we don't need to use flattree for anything, with OF_LIVE is enabled. Can OF_LIVE then generate dtb for kernel? Marek