mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime@cerno.tech>
To: "Michal Suchánek" <msuchanek@suse.de>
Cc: linux-arm-kernel@lists.infradead.org,
	Rob Herring <robh+dt@kernel.org>, Chen-Yu Tsai <wens@csie.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: dts: sun8i: h2+: Enable optional SPI flash on Orange Pi Zero board
Date: Mon, 19 Oct 2020 12:08:40 +0200	[thread overview]
Message-ID: <20201019100840.vntpu7d2eiun3zek@gilmour.lan> (raw)
In-Reply-To: <20201012170325.GS29778@kitsune.suse.cz>

[-- Attachment #1: Type: text/plain, Size: 3325 bytes --]

On Mon, Oct 12, 2020 at 07:03:25PM +0200, Michal Suchánek wrote:
> > > > 
> > > > > Also the boards that do not have the flsh are either broken or
> > > > > obsolete.
> > > > 
> > > > Making general statements without arguments doesn't really make it true
> > > > though. Plenty of boards to have flash and are neither broken nor
> > > > obsolete.
> > >
> > > Cannot parse this.
> > 
> > "Plenty of boards do not have flash and are neither broken nor obsolete"
> The product description of Orange Pi Zero clearly states there is a
> flash memory: http://www.orangepi.org/orangepizero/
> 
> When you order an Orange Pi Zero it comes with a flash memory. That is
> not what the device tree describes. The device tree is supposed to
> descrbe the hardware. If it does not it is broken.
> 
> If you have a board without a flash memory I do not know what it is but
> it is clearly not an Orange Pi Zero because it comes with one.

If you're buying it today, yes. If you take a random Orange Pi Zero that
has been sold at any point in time, you cannot make that statement.

> > > > 
> > > > > So most of the time enabling the flash chip is the right thing.
> > > > > 
> > > > > Or do we need two DTBs like sun8i-h2-plus-orangepi-zero.dts and
> > > > > sun8i-h2-plus-orangepi-zero-no-spi-nor.dts
> > > > 
> > > > No, you need sun8i-h2-plus-orangepi-zero plus an overlay for the
> > > > SPI-NOR.
> > >
> > > The flash is part of the board.
> > 
> > Not always though.
> No, it always comes with one. You must be speaking of a different board
> then.
> > 
> > > There is no need for an overlay.
> > 
> > Overlays are here to deal with the "not always though" situation...
>
> There are no overlays in the kernel. Please show me tho code in the
> kernel for handling overlays.

You're the one that mentioned the kernel here, but here you are:
https://elixir.bootlin.com/linux/v5.9.1/source/include/linux/of.h#L1455

And a driver using it:
https://elixir.bootlin.com/linux/v5.9.1/source/drivers/gpu/drm/rcar-du/rcar_du_of.c#L44

> > > And overlays don't exist.
> > 
> > If you want to believe that, please go ahead.
> > 
> > But there's support for it in libfdt, and you can either apply them
> > directly through the U-Boot command line, or bundle them in a FIT image.
>
> And as you state the user ususally does not know which version of the Pi
> they have. How are they supposed to know that they should apply an
> overlay through u-boot commandline (if they even get to see one)

Documentation?

> bundle them in a FIT image (if they are even using a FIT image).

That would be the distro's job, not the user's.

> I am doing neither. I boot a standard distribution kernel from EFI
> grub.
> 
> I understand that it would be nice to support two almost identical
> boards with a single device tree. However, if an error about missing
> flash memory is not acceptable, and the kernel does not support
> enabling the flash memory dynamically we need two device trees then.

You keep moving the goalposts, but U-boot is perfectly able to apply an
overlay automatically at boot without the user's intervention. We're
already making it select various DTs for the pine64 and pine64+ to have
a single image for both, or for the pinephone variants.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      reply	other threads:[~2020-10-19 10:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-29  8:30 Michal Suchanek
2020-10-08 15:13 ` Maxime Ripard
2020-10-08 16:02   ` Michal Suchánek
2020-10-08 17:14     ` Maxime Ripard
2020-10-08 17:40       ` Michal Suchánek
2020-10-12 15:35         ` Maxime Ripard
2020-10-12 17:03           ` Michal Suchánek
2020-10-19 10:08             ` Maxime Ripard [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201019100840.vntpu7d2eiun3zek@gilmour.lan \
    --to=maxime@cerno.tech \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msuchanek@suse.de \
    --cc=robh+dt@kernel.org \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®