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 X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C371C433E0 for ; Thu, 31 Dec 2020 09:54:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 71EC5223E8 for ; Thu, 31 Dec 2020 09:54:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726515AbgLaJyN (ORCPT ); Thu, 31 Dec 2020 04:54:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33912 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726230AbgLaJyM (ORCPT ); Thu, 31 Dec 2020 04:54:12 -0500 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45FC4C061575 for ; Thu, 31 Dec 2020 01:53:32 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id b26so43077591lff.9 for ; Thu, 31 Dec 2020 01:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M9V0ZomxWf5FI6Pzw3Hb0y0s9lG9QTEQPE+MoCBxoaw=; b=MyoI/oDbk1eBXNR6Q1xj1TEt28OJWIUQXMTmH9g4iQ2KI/499qhTqvkBfbV9FL6OJI ozYKs7ZfqDV9IoVQDG7t5WI8UfOHkyKcpnuSqazBoYZu+E+RnC6WWknVe0Z3mr3XK/xh TRiTJSdzopiIHuftMe95xOUGtAnFyrYaiZX/8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M9V0ZomxWf5FI6Pzw3Hb0y0s9lG9QTEQPE+MoCBxoaw=; b=rjM/Z/IhrmSC3PIWjObPBYuNuzWOcqqAxmDkJqUwg4uh5e8rWqPwo86zn05Z2T3CXi NZgZXQgScjRM38AjNZR9/E4mtIWo+ydAEwe3j95tNwEbo8nXkBcK0ddxh8s0Ok7KgPUs ZV7Ho/LGRDXB9wXRdQpiCD7za4jWc3nnXaFEq5AksNaSqrNCaMG5LJibZHc7zfZo+VCT ZrHYDaqWRqJVxGvMFeuBp/oFrvO3M8wqGVe82bd3tA0Dt6z3lIBKqI5kPP0SVz8BTj5V tMMS9rwjZsGTBfXzuLm1VVqd9rQ1HwlRJkvJV77tWbLPj98b5RsApmsTnJUjiYPeKJaJ MQpQ== X-Gm-Message-State: AOAM532XOe4/VXHf5HT6zL1Pwj0dya97ruvTrbmm+TzXs72QL78cpyxn 9NNuFhIxwstsUwg0u7r5zFCGwIZ2QPKPKJObIxhPsA== X-Google-Smtp-Source: ABdhPJyNNZPt1wfoVD+7d/vQ025wnymJUtRR4PYDYtvCI4JzcbGJrjpUgp6diGSdnvGBTaDm2kpNOhpGX13hQ36MXKc= X-Received: by 2002:a05:6512:3e7:: with SMTP id n7mr23736548lfq.585.1609408410757; Thu, 31 Dec 2020 01:53:30 -0800 (PST) MIME-Version: 1.0 References: <20201226163037.43691-1-vitaly.wool@konsulko.com> In-Reply-To: From: Vitaly Wool Date: Thu, 31 Dec 2020 10:53:36 +0100 Message-ID: Subject: Re: [PATCH] riscv: add BUILTIN_DTB support for MMU-enabled targets To: Anup Patel Cc: linux-riscv , "linux-kernel@vger.kernel.org List" , Bin Meng , Palmer Dabbelt , Damien Le Moal , devicetree@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 29, 2020 at 6:05 AM Anup Patel wrote: > > On Mon, Dec 28, 2020 at 10:08 PM Vitaly Wool wrote: > > > > On Mon, Dec 28, 2020 at 3:10 PM Anup Patel wrote: > > > > > > On Mon, Dec 28, 2020 at 7:05 PM Vitaly Wool wrote: > > > > > > > > On Mon, Dec 28, 2020 at 12:59 PM Anup Patel wrote: > > > > > > > > > > On Sat, Dec 26, 2020 at 10:03 PM Vitaly Wool wrote: > > > > > > > > > > > > Sometimes, especially in a production system we may not want to > > > > > > use a "smart bootloader" like u-boot to load kernel, ramdisk and > > > > > > device tree from a filesystem on eMMC, but rather load the kernel > > > > > > from a NAND partition and just run it as soon as we can, and in > > > > > > this case it is convenient to have device tree compiled into the > > > > > > kernel binary. Since this case is not limited to MMU-less systems, > > > > > > let's support it for these which have MMU enabled too. > > > > > > > > > > > > Signed-off-by: Vitaly Wool > > > > > > --- > > > > > > arch/riscv/Kconfig | 1 - > > > > > > arch/riscv/mm/init.c | 12 ++++++++++-- > > > > > > 2 files changed, 10 insertions(+), 3 deletions(-) > > > > > > > > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > > > > > index 2b41f6d8e458..9464b4e3a71a 100644 > > > > > > --- a/arch/riscv/Kconfig > > > > > > +++ b/arch/riscv/Kconfig > > > > > > @@ -419,7 +419,6 @@ endmenu > > > > > > > > > > > > config BUILTIN_DTB > > > > > > def_bool n > > > > > > - depends on RISCV_M_MODE > > > > > > depends on OF > > > > > > > > > > > > menu "Power management options" > > > > > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > > > > > > index 87c305c566ac..5d1c7a3ec01c 100644 > > > > > > --- a/arch/riscv/mm/init.c > > > > > > +++ b/arch/riscv/mm/init.c > > > > > > @@ -194,12 +194,20 @@ void __init setup_bootmem(void) > > > > > > setup_initrd(); > > > > > > #endif /* CONFIG_BLK_DEV_INITRD */ > > > > > > > > > > > > + /* > > > > > > + * If DTB is built in, no need to reserve its memblock. > > > > > > + * OTOH, initial_boot_params has to be set to properly copy DTB > > > > > > + * before unflattening later on. > > > > > > + */ > > > > > > + if (IS_ENABLED(CONFIG_BUILTIN_DTB)) > > > > > > + initial_boot_params = __va(dtb_early_pa); > > > > > > > > > > Don't assign initial_boot_params directly here because the > > > > > early_init_dt_scan() will do it. > > > > > > > > early_init_dt_scan will set initial_boot_params to dtb_early_va from > > > > the early mapping which will be gone by the time > > > > unflatten_and_copy_device_tree() is called. > > > > > > That's why we are doing early_init_dt_verify() again for the MMU-enabled > > > case which already takes care of your concern. > > > > I might be out in the woods here but... Do you mean the call to > > early_init_dt_verify() in setup_arch() which is compiled out > > completely in the CONFIG_BUILTIN_DTB case? > > Or is there any other call that I'm overlooking? > > Sorry for the confusion, what I meant was that we are calling > early_init_dt_verify() from setup_arch() for the MMU-enabled > with built-in DTB disabled case to update "initial_boot_params" > after the boot CPU has switched from early_pg_dir to swapper_pg_dir. > > For MMU-enabled with built-in DTB case, if setup_vm() sets the > dtb_early_va and dtb_early_pa correctly then early_init_dt_scan() > called from setup_arch() will automatically set correct value for > "initial_boot_params". Oh I think I get it now. You are suggesting to skip the temporary mapping for DT altogether since it is anyway in the kernel mapping range, aren't you? That does make sense indeed, thanks :) > It is strange that early_init_dt_verify() is being compiled-out for you > because the early_init_dt_scan() called from setup_arch() also uses > early_init_dt_verify(). I quickly compiled the NoMMU kernel for K210 > which also uses built-in DTB and I see that early_init_dt_verify() > is not being compiled-out when built-in DTB is enabled. I did not say that early_init_dt_verify() is compiled out, it's the call to it in setup_arch() that is compiled out if BUILTIN_DTB is selected. However, if I understand you correctly now, it should not matter if we don't set dtb_early_va to point to the temporary mapping. Best regards, Vitaly > > Regards, > Anup > > > > > Best regards, > > Vitaly > > > > > We use early_init_dt_verify() like most architectures to set the initial DTB. > > > > > > > > > > > > The setup_vm() is supposed to setup dtb_early_va and dtb_early_pa > > > > > for MMU-enabled case so please add a "#ifdef" over there for the > > > > > built-in DTB case. > > > > > > > > > > > + else > > > > > > + memblock_reserve(dtb_early_pa, fdt_totalsize(dtb_early_va)); > > > > > > + > > > > > > /* > > > > > > * Avoid using early_init_fdt_reserve_self() since __pa() does > > > > > > * not work for DTB pointers that are fixmap addresses > > > > > > */ > > > > > > > > > > This comment needs to be updated and moved along the memblock_reserve() > > > > > statement. > > > > > > > > > > > - memblock_reserve(dtb_early_pa, fdt_totalsize(dtb_early_va)); > > > > > > - > > > > > > early_init_fdt_scan_reserved_mem(); > > > > > > dma_contiguous_reserve(dma32_phys_limit); > > > > > > memblock_allow_resize(); > > > > > > -- > > > > > > 2.29.2 > > > > > > > > > > > > > > > > This patch should be based upon Damiens builtin DTB patch. > > > > > Refer, https://www.spinics.net/lists/linux-gpio/msg56616.html > > > > > > > > Thanks for the pointer, however I don't think our patches have > > > > intersections. Besides, Damien is dealing with the MMU-less case > > > > there. > > > > > > Damien's patch is also trying to move to use generic BUILTIN_DTB > > > support for the MMU-less case so it is similar work hence the chance > > > of patch conflict. > > > > > > Regards, > > > Anup 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 X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1FFB6C433E0 for ; Thu, 31 Dec 2020 09:53:48 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B4D6020786 for ; Thu, 31 Dec 2020 09:53:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B4D6020786 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=baVTOwor94cwqyvlyZWMMbWvHThCOsInw9ccwrHnHFQ=; b=LYSlK6Oe+mpEwhStOjOdz9G93 fbtqXD6sg3WE3lRc2rX45s3UmbEWZCSdycx8LjTE72p1GnIDZGS2+Q9WaaRC8xE815Jl+Rwny7htQ xekNuApCT4mJYmRjxUTLSkeHdGm9V9k9FWEGDV5f5ForNrMqhtteI+KSZ9YrdmfD199XonwC+JPUF UN7co/rcK8DAQIhrH7my4q7h3NXQTqmdzIlJIbhI5dtOaYJlNwtDkFn9EJL3HqvbTzIIYZQpCzouL Q/Hkz0wNyyomt9JVWNZxf2YmtPI7gBcmKCxxu4JzmVYD5SsS149eICgLTKzzrds/fb+vKbb9JFWwz hStZBDsOQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kuueH-0005bE-BL; Thu, 31 Dec 2020 09:53:37 +0000 Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kuueE-0005ad-Gb for linux-riscv@lists.infradead.org; Thu, 31 Dec 2020 09:53:35 +0000 Received: by mail-lf1-x134.google.com with SMTP id s26so43023993lfc.8 for ; Thu, 31 Dec 2020 01:53:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M9V0ZomxWf5FI6Pzw3Hb0y0s9lG9QTEQPE+MoCBxoaw=; b=MyoI/oDbk1eBXNR6Q1xj1TEt28OJWIUQXMTmH9g4iQ2KI/499qhTqvkBfbV9FL6OJI ozYKs7ZfqDV9IoVQDG7t5WI8UfOHkyKcpnuSqazBoYZu+E+RnC6WWknVe0Z3mr3XK/xh TRiTJSdzopiIHuftMe95xOUGtAnFyrYaiZX/8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M9V0ZomxWf5FI6Pzw3Hb0y0s9lG9QTEQPE+MoCBxoaw=; b=B0zVXfhz9cKFt7y99GwypFLvC7KUJvjBTXkiHd+NAcriOlCOv3KmHHgoQFZlTF6WdC Vp8rfFdDl8dWpIXgmscaS9OY5vERwAxh/EmXxYXXxlOMcanqREHuim7ffmkS9kQ7Cq1U diKAph/nmH4GBtyM84tlsG6fxN0Zvd6NZKLk3l8iuI+2oMk6DqICzIyIjOAzVh9lo7xW JVsyCzI5KwEYV/uaHPGiaAKn45rQZW9CEZzSnMZHqt3ALSEn9ErATqME+eEWC/55S12y rW9YRrTlPCzfCCgQzN37pguqUdqU6ILv5PdWvfJWuWE8wLYoBVzKZ4X0fbZqlwhIVB63 +58Q== X-Gm-Message-State: AOAM531EIbE8orPUmArE8DMQ+0Ai2KJipPMu8Uy8hb0P2wSzs0KjqZRi wSAqdDH/sTEJWOROhTvR3okDjVBg/e6lHTLHRbYbrQ== X-Google-Smtp-Source: ABdhPJyNNZPt1wfoVD+7d/vQ025wnymJUtRR4PYDYtvCI4JzcbGJrjpUgp6diGSdnvGBTaDm2kpNOhpGX13hQ36MXKc= X-Received: by 2002:a05:6512:3e7:: with SMTP id n7mr23736548lfq.585.1609408410757; Thu, 31 Dec 2020 01:53:30 -0800 (PST) MIME-Version: 1.0 References: <20201226163037.43691-1-vitaly.wool@konsulko.com> In-Reply-To: From: Vitaly Wool Date: Thu, 31 Dec 2020 10:53:36 +0100 Message-ID: Subject: Re: [PATCH] riscv: add BUILTIN_DTB support for MMU-enabled targets To: Anup Patel X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201231_045334_667418_43430C2F X-CRM114-Status: GOOD ( 45.16 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Damien Le Moal , Bin Meng , Palmer Dabbelt , "linux-kernel@vger.kernel.org List" , linux-riscv Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Tue, Dec 29, 2020 at 6:05 AM Anup Patel wrote: > > On Mon, Dec 28, 2020 at 10:08 PM Vitaly Wool wrote: > > > > On Mon, Dec 28, 2020 at 3:10 PM Anup Patel wrote: > > > > > > On Mon, Dec 28, 2020 at 7:05 PM Vitaly Wool wrote: > > > > > > > > On Mon, Dec 28, 2020 at 12:59 PM Anup Patel wrote: > > > > > > > > > > On Sat, Dec 26, 2020 at 10:03 PM Vitaly Wool wrote: > > > > > > > > > > > > Sometimes, especially in a production system we may not want to > > > > > > use a "smart bootloader" like u-boot to load kernel, ramdisk and > > > > > > device tree from a filesystem on eMMC, but rather load the kernel > > > > > > from a NAND partition and just run it as soon as we can, and in > > > > > > this case it is convenient to have device tree compiled into the > > > > > > kernel binary. Since this case is not limited to MMU-less systems, > > > > > > let's support it for these which have MMU enabled too. > > > > > > > > > > > > Signed-off-by: Vitaly Wool > > > > > > --- > > > > > > arch/riscv/Kconfig | 1 - > > > > > > arch/riscv/mm/init.c | 12 ++++++++++-- > > > > > > 2 files changed, 10 insertions(+), 3 deletions(-) > > > > > > > > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > > > > > index 2b41f6d8e458..9464b4e3a71a 100644 > > > > > > --- a/arch/riscv/Kconfig > > > > > > +++ b/arch/riscv/Kconfig > > > > > > @@ -419,7 +419,6 @@ endmenu > > > > > > > > > > > > config BUILTIN_DTB > > > > > > def_bool n > > > > > > - depends on RISCV_M_MODE > > > > > > depends on OF > > > > > > > > > > > > menu "Power management options" > > > > > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > > > > > > index 87c305c566ac..5d1c7a3ec01c 100644 > > > > > > --- a/arch/riscv/mm/init.c > > > > > > +++ b/arch/riscv/mm/init.c > > > > > > @@ -194,12 +194,20 @@ void __init setup_bootmem(void) > > > > > > setup_initrd(); > > > > > > #endif /* CONFIG_BLK_DEV_INITRD */ > > > > > > > > > > > > + /* > > > > > > + * If DTB is built in, no need to reserve its memblock. > > > > > > + * OTOH, initial_boot_params has to be set to properly copy DTB > > > > > > + * before unflattening later on. > > > > > > + */ > > > > > > + if (IS_ENABLED(CONFIG_BUILTIN_DTB)) > > > > > > + initial_boot_params = __va(dtb_early_pa); > > > > > > > > > > Don't assign initial_boot_params directly here because the > > > > > early_init_dt_scan() will do it. > > > > > > > > early_init_dt_scan will set initial_boot_params to dtb_early_va from > > > > the early mapping which will be gone by the time > > > > unflatten_and_copy_device_tree() is called. > > > > > > That's why we are doing early_init_dt_verify() again for the MMU-enabled > > > case which already takes care of your concern. > > > > I might be out in the woods here but... Do you mean the call to > > early_init_dt_verify() in setup_arch() which is compiled out > > completely in the CONFIG_BUILTIN_DTB case? > > Or is there any other call that I'm overlooking? > > Sorry for the confusion, what I meant was that we are calling > early_init_dt_verify() from setup_arch() for the MMU-enabled > with built-in DTB disabled case to update "initial_boot_params" > after the boot CPU has switched from early_pg_dir to swapper_pg_dir. > > For MMU-enabled with built-in DTB case, if setup_vm() sets the > dtb_early_va and dtb_early_pa correctly then early_init_dt_scan() > called from setup_arch() will automatically set correct value for > "initial_boot_params". Oh I think I get it now. You are suggesting to skip the temporary mapping for DT altogether since it is anyway in the kernel mapping range, aren't you? That does make sense indeed, thanks :) > It is strange that early_init_dt_verify() is being compiled-out for you > because the early_init_dt_scan() called from setup_arch() also uses > early_init_dt_verify(). I quickly compiled the NoMMU kernel for K210 > which also uses built-in DTB and I see that early_init_dt_verify() > is not being compiled-out when built-in DTB is enabled. I did not say that early_init_dt_verify() is compiled out, it's the call to it in setup_arch() that is compiled out if BUILTIN_DTB is selected. However, if I understand you correctly now, it should not matter if we don't set dtb_early_va to point to the temporary mapping. Best regards, Vitaly > > Regards, > Anup > > > > > Best regards, > > Vitaly > > > > > We use early_init_dt_verify() like most architectures to set the initial DTB. > > > > > > > > > > > > The setup_vm() is supposed to setup dtb_early_va and dtb_early_pa > > > > > for MMU-enabled case so please add a "#ifdef" over there for the > > > > > built-in DTB case. > > > > > > > > > > > + else > > > > > > + memblock_reserve(dtb_early_pa, fdt_totalsize(dtb_early_va)); > > > > > > + > > > > > > /* > > > > > > * Avoid using early_init_fdt_reserve_self() since __pa() does > > > > > > * not work for DTB pointers that are fixmap addresses > > > > > > */ > > > > > > > > > > This comment needs to be updated and moved along the memblock_reserve() > > > > > statement. > > > > > > > > > > > - memblock_reserve(dtb_early_pa, fdt_totalsize(dtb_early_va)); > > > > > > - > > > > > > early_init_fdt_scan_reserved_mem(); > > > > > > dma_contiguous_reserve(dma32_phys_limit); > > > > > > memblock_allow_resize(); > > > > > > -- > > > > > > 2.29.2 > > > > > > > > > > > > > > > > This patch should be based upon Damiens builtin DTB patch. > > > > > Refer, https://www.spinics.net/lists/linux-gpio/msg56616.html > > > > > > > > Thanks for the pointer, however I don't think our patches have > > > > intersections. Besides, Damien is dealing with the MMU-less case > > > > there. > > > > > > Damien's patch is also trying to move to use generic BUILTIN_DTB > > > support for the MMU-less case so it is similar work hence the chance > > > of patch conflict. > > > > > > Regards, > > > Anup _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv