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 87DA1C433EF for ; Thu, 27 Jan 2022 15:07:14 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 85B6B83820; Thu, 27 Jan 2022 16:06:45 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org 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; unprotected) header.d=chromium.org header.i=@chromium.org header.b="ara5beLs"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4FAA88365D; Thu, 27 Jan 2022 16:06:20 +0100 (CET) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 27494837CD for ; Thu, 27 Jan 2022 16:06:15 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-ot1-x32c.google.com with SMTP id g15-20020a9d6b0f000000b005a062b0dc12so2818545otp.4 for ; Thu, 27 Jan 2022 07:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Nm17w869MhNK6Nnp6cfIBYPuRv00Z+yMvtfasVBqv6o=; b=ara5beLsKOYjJICuNcJBDSGbclE7bPTL0TKFMOMHVFnILK4hv85/u2kmztLj/F9Uie sOJ9Ra67Zu4//fhjeXNR+FpijOL1z2rC4lW9zaS4g4PA90MagI83gQTmWRSuTRgqeXQ/ vCBfb+c2INO+JvDhv41pwHf5QO1JvMBQ2lisk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Nm17w869MhNK6Nnp6cfIBYPuRv00Z+yMvtfasVBqv6o=; b=xHwBRgkiEEMnJCnhe7VQFz417DXQnoEo/Lsds+vnMLoBG24C4RqGHYopCrsgeOpjDZ RWWZLbNvwBAWw888k491hrtY9DYGfMl+CqyTtX7TMsrS/AteZMVd5dDH8SJnfuo2LsqC EbozUgizFg2jySwg2oiot+IU5Exxo+mA93iE9hajNe19w6TXGTjcD3Ct5FyFtaBoSQX3 7x6JZd4XAEI0mB82/epmQAiKzqZqShHtDqEQnAAlbUbtjhXmBvPJyet+dAcM6mtVzRPs V0IOgAW4XspQp4lK38vlU7WAVQSI/2fKHxd5z0wpyCYijfm1ALZk1ik3f2VwxqRZdJoj CEcA== X-Gm-Message-State: AOAM533MMdaWaWDnAtN7L6XQvAL3O2xA3+2m7QTPbWB5QAXd6qTo7y0t mYN8TNpyF0HcbnSo93hTBt0OxyTFN1dZg1a8C3BvjP1KfVo= X-Google-Smtp-Source: ABdhPJyOPbgsHoPR1IOGkNQqQLai/OzWEE8N6MqReMXnDtyNtKCFzmAP6c6Eeh1v5b2XwCx9Fh2BCEdrjvE96ufWmLs= X-Received: by 2002:a9d:6a42:: with SMTP id h2mr2246620otn.269.1643295972696; Thu, 27 Jan 2022 07:06:12 -0800 (PST) MIME-Version: 1.0 References: <20220106132100.56f55e02@thinkpad> <20220106171007.7f39094c@thinkpad> <20220106175540.365e8585@thinkpad> In-Reply-To: <20220106175540.365e8585@thinkpad> From: Simon Glass Date: Thu, 27 Jan 2022 08:05:59 -0700 Message-ID: Subject: Re: difference between fdtdec and fdt_support ? To: =?UTF-8?B?TWFyZWsgQmVow7pu?= Cc: U-Boot Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.5 at phobos.denx.de X-Virus-Status: Clean Hi Marek, On Thu, 6 Jan 2022 at 09:55, Marek Beh=C3=BAn wrote: > > On Thu, 6 Jan 2022 09:15:17 -0700 > Simon Glass wrote: > > > Hi Marek, > > > > On Thu, 6 Jan 2022 at 09:10, Marek Beh=C3=BAn wrot= e: > > > > > > On Thu, 6 Jan 2022 08:48:48 -0700 > > > Simon Glass wrote: > > > > > > > Hi Marek, > > > > > > > > On Thu, 6 Jan 2022 at 05:21, Marek Beh=C3=BAn = wrote: > > > > > > > > > > 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(), wh= ich I > > > > > would rather expect in fdt_support by name fdt_node_is_available(= ), or > > > > > something like that. > > > > > > > > Should be moved to ofnode > > > > > > ?? But this function is needed for example when fixing device tree fo= r > > > Linux. > > > > > > > > > > > > > Also fdtdec does a strange thing with compatible strings: it decl= ares > > > > > an enum for compatible strings and then a map which maps this enu= m > > > > > values to compatible strings... Why not just use the compatible s= trings? > > > > > > > > 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 t= here is a > > > > * good reason why driver-model conversion is infeasible. Examples = include > > > > * 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. > > > > > > 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. > > > > 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. Yes, indeed, but really these uses should be dropped and converted to driver model. > > > > > > > > > > > > > > What is the purpose of having two files implementing fdt stuff? > > > > > > > > fdtdec - for reading from the DT. Should go away and be replaced wi= th > > > > the ofnode API, and fdtaddr.c > > > > fdt_support - for updating the DT, e.g. for fixups before booting a= n OS > > > > > > 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().) > > > > OK. > > > > 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? It isn't implemented, but we should add it. It is a simple piece of code to flatten the tree. Regards, Simon