From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dario Binacchi <dariobin@libero.it>
Date: Tue, 16 Mar 2021 21:57:08 +0100 (CET)
Subject: [PATCH 1/2] of: addr: Abort address translation for parent
 nodes missing 'ranges'
In-Reply-To: <CAEUhbmXTo61V0Eyf53gjfAG4ZaW0jAAXetv6xgBBa5i+YxWD1g@mail.gmail.com>
References: <1614324949-61314-1-git-send-email-bmeng.cn@gmail.com>
 <CAPnjgZ3DW3VzYXroUr5M6yK1027VvAXjSyA4aPMf2FygJeYfug@mail.gmail.com>
 <CAPnjgZ2GWEDLOffMjVwA1o_e0AS1KRTRXYza3hS9kefyZDot9Q@mail.gmail.com>
 <CAEUhbmW837_QRz99TOGewBsEhfPt6vfNTZYvANQSFf+rJgbZTg@mail.gmail.com>
 <CAPnjgZ1kjRvUG-Usu35GjzzUKTh6gEmAeqBCMUBgvdgAJKJgBQ@mail.gmail.com>
 <221726458.466078.1615848548744@mail1.libero.it>
 <CAEUhbmXTo61V0Eyf53gjfAG4ZaW0jAAXetv6xgBBa5i+YxWD1g@mail.gmail.com>
Message-ID: <1656397533.509401.1615928228931@mail1.libero.it>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Bin,

> Il 16/03/2021 02:28 Bin Meng <bmeng.cn@gmail.com> ha scritto:
> 
>  
> Hi Dario,
> 
> On Tue, Mar 16, 2021 at 6:49 AM Dario Binacchi <dariobin@libero.it> wrote:
> >
> >
> > > Il 15/03/2021 19:23 Simon Glass <sjg@chromium.org> ha scritto:
> > >
> > >
> > > +Tom Rini too
> > >
> > >
> > > On Tue, 16 Mar 2021 at 03:48, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > +Dario Binacchi
> > > >
> > > > On Mon, Mar 15, 2021 at 3:11 PM Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > Hi Bin,
> > > > >
> > > > > On Wed, 3 Mar 2021 at 14:54, Simon Glass <sjg@chromium.org> wrote:
> > > > > >
> > > > > > On Fri, 26 Feb 2021 at 00:36, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > The implementation of of_translate_one() was taken from the one in
> > > > > > > Linux kernel drivers/of/address.c, and the Linux one added a quirk
> > > > > > > for Apple Macs that don't have the <ranges> property in the parent
> > > > > > > node. Since U-Boot does not support Apple Macs, remove the comment
> > > > > > > block and adhere to the spec to abort the translation.
> > > > > > >
> > > > > > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > > > > > > ---
> > > > > > >
> > > > > > >  drivers/core/of_addr.c | 24 ++++++------------------
> > > > > > >  1 file changed, 6 insertions(+), 18 deletions(-)
> > > > > >
> > > > > > Reviewed-by: Simon Glass <sjg@chromium.org>
> > > > >
> > > > > Unfortunately this seems to cause a test failure for
> > > > > ut_dm_fdt_translation. Can you please take a look?
> > > >
> > > > It seems the no "ranges" property was intentionally removed by the
> > > > following commit:
> > > >
> > > > commit d64b9cdcd475eb7f07b49741ded87e24dae4a5fc
> > > > Author: Dario Binacchi <dariobin@libero.it>
> > > > Date:   Wed Dec 30 00:16:21 2020 +0100
> > > >
> > > >     fdt: translate address if #size-cells = <0>
> > > >
> > > >     The __of_translate_address routine translates an address from the
> > > >     device tree into a CPU physical address. A note in the description of
> > > >     the routine explains that the crossing of any level with
> > > >     since inherited from IBM. This does not happen for Texas Instruments, or
> > > >     at least for the beaglebone device tree. Without this patch, in fact,
> > > >     the translation into physical addresses of the registers contained in the
> > > >     am33xx-clocks.dtsi nodes would not be possible. They all have a parent
> > > >     with #size-cells = <0>.
> > > >
> > > > It looks the commit was needed for beaglebone board.
> > > >
> > > > Dario, could you please comment on why U-Boot needs to done like this,
> > > > while Linux kernel has this check? Is the beaglebone board not working
> > > > in Linux?
> > > >
> >
> > Beaglebone is working in Linux, but I think Linux walks the device tree less
> > fully than u-boot.
> > I was surprised by the address translation error when traversing nodes with
> > size cells 0. And for this reason I added the CONFIG_OF_TRANSLATE_ZERO_SIZE_CELLS
> > symbol to fix the issue, not enabled by default, thus making the change backwards
> > compatible.
> 
> Could you please prepare a patch against upstream Linux kernel, so
> that U-Boot can be in sync with it?

With pleasure. But how do I justify the patch since it doesn't fix any bugs? 
Can I refer to the patches developed for U-boot?

Best regards,
Dario

> 
> Regards,
> Bin