All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@gmail.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Simon Horman <horms+renesas@verge.net.au>,
	Marek Vasut <marek.vasut+renesas@gmail.com>
Subject: Re: [PATCH V3] ARM: shmobile: Rework the PMIC IRQ line quirk
Date: Wed, 13 Jun 2018 22:53:41 +0200	[thread overview]
Message-ID: <c86c2ae6-21de-391e-a23f-b70976e86852@gmail.com> (raw)
In-Reply-To: <CAMuHMdUmqAWHFoM5tRJA+FoH59J8L3z0BMKVO-FEv4RQbokJyg@mail.gmail.com>

On 06/13/2018 01:28 PM, Geert Uytterhoeven wrote:
> Hi Marek,

Hi,

[...]

>>>> But wait, since we control which machines this code runs on , can't we
>>>> assure they have valid DTs ? This situation with invalid DT starts to
>>>> look a bit hypothetical to me.
>>>
>>> That assumes you keep the list of machines to check, and don't want to fix the
>>> issue automatically when detected (on any R-Car Gen2 or RZ/G1 platform, so
>>> you still need to check for r8a779[0-4] and r8a774[23457]).
>>
>> Yes, I want to keep a list of machines to check, to be _sure_ some
>> machine doesn't randomly blow up.
> 
> Just checking for the presence of a "renesas,irqc" node should be sufficient.

How so? Any other R-Car machine can have the irqc node too. That's
fragile at best.

> Using that node would also get rid of the hardcoded IRQC_BASE address.
> Note that the code assumes IRQ2. If another IRQ is used, that won't harm
> much though (as in: if it didn't blow up before, it won't blow up now).

We could/should fix up the irqc detection though.

>>> Anyway, as we care about booting old DTBs on new kernels (for a while), we
>>> have a few more release cycles to bikeshed ;-)
>>
>> I was about to ask if this patch then makes any sense or not.
> 
> Sure. Less hard-coding is always better.
> Especially if it means we can make it work on more machines automatically :-)

I prefer to be in control of that.

-- 
Best regards,
Marek Vasut

WARNING: multiple messages have this Message-ID (diff)
From: marek.vasut@gmail.com (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3] ARM: shmobile: Rework the PMIC IRQ line quirk
Date: Wed, 13 Jun 2018 22:53:41 +0200	[thread overview]
Message-ID: <c86c2ae6-21de-391e-a23f-b70976e86852@gmail.com> (raw)
In-Reply-To: <CAMuHMdUmqAWHFoM5tRJA+FoH59J8L3z0BMKVO-FEv4RQbokJyg@mail.gmail.com>

On 06/13/2018 01:28 PM, Geert Uytterhoeven wrote:
> Hi Marek,

Hi,

[...]

>>>> But wait, since we control which machines this code runs on , can't we
>>>> assure they have valid DTs ? This situation with invalid DT starts to
>>>> look a bit hypothetical to me.
>>>
>>> That assumes you keep the list of machines to check, and don't want to fix the
>>> issue automatically when detected (on any R-Car Gen2 or RZ/G1 platform, so
>>> you still need to check for r8a779[0-4] and r8a774[23457]).
>>
>> Yes, I want to keep a list of machines to check, to be _sure_ some
>> machine doesn't randomly blow up.
> 
> Just checking for the presence of a "renesas,irqc" node should be sufficient.

How so? Any other R-Car machine can have the irqc node too. That's
fragile at best.

> Using that node would also get rid of the hardcoded IRQC_BASE address.
> Note that the code assumes IRQ2. If another IRQ is used, that won't harm
> much though (as in: if it didn't blow up before, it won't blow up now).

We could/should fix up the irqc detection though.

>>> Anyway, as we care about booting old DTBs on new kernels (for a while), we
>>> have a few more release cycles to bikeshed ;-)
>>
>> I was about to ask if this patch then makes any sense or not.
> 
> Sure. Less hard-coding is always better.
> Especially if it means we can make it work on more machines automatically :-)

I prefer to be in control of that.

-- 
Best regards,
Marek Vasut

  reply	other threads:[~2018-06-13 21:08 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-04 17:59 [PATCH V3] ARM: shmobile: Rework the PMIC IRQ line quirk Marek Vasut
2018-06-04 17:59 ` Marek Vasut
2018-06-05  8:07 ` Simon Horman
2018-06-05  8:07   ` Simon Horman
2018-06-05  9:21   ` Wolfram Sang
2018-06-05  9:21     ` Wolfram Sang
2018-06-05  9:57     ` Marek Vasut
2018-06-05  9:57       ` Marek Vasut
2018-06-05  9:46   ` Marek Vasut
2018-06-05  9:46     ` Marek Vasut
2018-06-11  9:56 ` Geert Uytterhoeven
2018-06-11  9:56   ` Geert Uytterhoeven
2018-06-11 12:08   ` Marek Vasut
2018-06-11 12:08     ` Marek Vasut
2018-06-11 13:03     ` Geert Uytterhoeven
2018-06-11 13:03       ` Geert Uytterhoeven
2018-06-11 13:35       ` Marek Vasut
2018-06-11 13:35         ` Marek Vasut
2018-06-11 13:49         ` Geert Uytterhoeven
2018-06-11 13:49           ` Geert Uytterhoeven
2018-06-11 14:04           ` Marek Vasut
2018-06-11 14:04             ` Marek Vasut
2018-06-11 14:10             ` Geert Uytterhoeven
2018-06-11 14:10               ` Geert Uytterhoeven
2018-06-11 14:19               ` Marek Vasut
2018-06-11 14:19                 ` Marek Vasut
2018-06-11 14:30                 ` Geert Uytterhoeven
2018-06-11 14:30                   ` Geert Uytterhoeven
2018-06-11 15:26                   ` Marek Vasut
2018-06-11 15:26                     ` Marek Vasut
2018-06-13 11:28                     ` Geert Uytterhoeven
2018-06-13 11:28                       ` Geert Uytterhoeven
2018-06-13 20:53                       ` Marek Vasut [this message]
2018-06-13 20:53                         ` Marek Vasut

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=c86c2ae6-21de-391e-a23f-b70976e86852@gmail.com \
    --to=marek.vasut@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --cc=horms+renesas@verge.net.au \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=marek.vasut+renesas@gmail.com \
    --cc=wsa+renesas@sang-engineering.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.