Linux-Renesas-SoC Archive on lore.kernel.org
 help / color / Atom feed
From: Rob Herring <robh+dt@kernel.org>
To: "Marek Vašut" <marek.vasut@gmail.com>
Cc: devicetree@vger.kernel.org,
	Marek Vasut <marek.vasut+renesas@gmail.com>,
	Frank Rowand <frowand.list@gmail.com>,
	"open list:MEDIA DRIVERS FOR RENESAS - FCP" 
	<linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH V2] of: Fix of_empty_ranges_quirk()
Date: Fri, 13 Sep 2019 16:29:55 +0100
Message-ID: <CAL_JsqKSWD5EOGdvGS7Z8pd6OALRsqxv2GmVLd+9ZoOyPgbr-w@mail.gmail.com> (raw)
In-Reply-To: <20190907161537.27258-1-marek.vasut@gmail.com>

On Sat, Sep 7, 2019 at 5:15 PM <marek.vasut@gmail.com> wrote:
>
> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> The of_empty_ranges_quirk() returns a mix of boolean and signed integer
> types, which cannot work well. Replace that with boolean only and fix
> usage logic in of_translate_one() -- the check should trigger when the
> ranges are NULL and the quirk is applicable on the hardware.

Just moving to boolean has seemed like weak justification for this
churn, but now that I've seen your work on PCI dma-ranges it makes a
bit more sense.

We do have a problem that unlike 'ranges', 'dma-ranges' being missing
probably needs to be treated as 1:1 translation. I can't really
picture a case where dma-ranges would be used with a non-translatable
address. Perhaps a module with optional DMA and the DMA is not hooked
up. That could be expressed with dma-ranges with a 0 size or a
different compatible. So your v1 patch was perhaps correct change in
behavior, but only for dma-ranges. (I've written one that works in
both cases).

Rob

  parent reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-07 16:15 marek.vasut
2019-09-09 17:37 ` Rob Herring
2019-09-14 16:00   ` Marek Vasut
2019-09-13 15:29 ` Rob Herring [this message]
2019-09-14 16:05   ` Marek Vasut

Reply instructions:

You may reply publically 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=CAL_JsqKSWD5EOGdvGS7Z8pd6OALRsqxv2GmVLd+9ZoOyPgbr-w@mail.gmail.com \
    --to=robh+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=marek.vasut+renesas@gmail.com \
    --cc=marek.vasut@gmail.com \
    /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

Linux-Renesas-SoC Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-renesas-soc/0 linux-renesas-soc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-renesas-soc linux-renesas-soc/ https://lore.kernel.org/linux-renesas-soc \
		linux-renesas-soc@vger.kernel.org linux-renesas-soc@archiver.kernel.org
	public-inbox-index linux-renesas-soc


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-renesas-soc


AGPL code for this site: git clone https://public-inbox.org/ public-inbox