devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>,
	Magnus Damm <magnus.damm@gmail.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v4 0/6] ARM: shmobile: r8a7740/sh73a0 DT Cache Handling
Date: Fri, 7 Aug 2015 09:34:55 +0900	[thread overview]
Message-ID: <20150807003455.GB1145@verge.net.au> (raw)
In-Reply-To: <CAMuHMdW5D2LGA=3+JDiAUhVtPmxk3ZJhAx3=JXFuAHBAgU_NTw@mail.gmail.com>

On Thu, Aug 06, 2015 at 09:17:38AM +0200, Geert Uytterhoeven wrote:
> On Thu, Aug 6, 2015 at 2:35 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Wed, Aug 05, 2015 at 10:58:04AM +0200, Geert Uytterhoeven wrote:
> >> This patch series add L1 and L2 cache descriptions to DT for r8a7740 and
> >> sh73a0, and migrates the shmobile DT-based generic r8a7740 and
> >> armadillo legacy platforms from calling l2x0_of_init() to the generic
> >> l2c OF initialization.
> 
> >> Dependencies:
> >>   - This series applies to renesas-devel-20150805-v4.2-rc5,
> >>   - Patch 2 depends on patch 1,
> >>   - Patch 4 depends on patch 2,
> 
> Sorry, "... on patch 3".
> 
> >>   - Patch 5 depends on patch 1 and on "ARM: 8395/1: l2c: Add support for
> >>     the "arm,shared-override" property" in arm/for-next,
> >>   - Patch 6 depends on patch 5.
> >>
> >> Given C code patches depending on DT patches in the same branch are
> >> frowned upon, I think it would be best if patch 1 (and patch 3, if
> >> anyone thinks we may fix the secondary CPU bringup issue during the next
> >> 3 months) are queued for v4.3. The other patches can be queued for
> >> 2016^H^H^H^Hv4.4.
> >
> > Sorry for surprising you with that merge-order requirement.
> 
> In theory it sounds fine, as DT and code are independent.
> Moving functionality from C to DT is something different...

I agree entirely. This is probably something that we should discuss
with the ARM SoC developers. But my feeling is that there should be
some scope for flexibility with regards to merge-order in such cases.

By which I mean we should try where possible, not to apply non-DT patches
on top of DT patches. But if circumstances arise where it seems to
be the best approach then we should to approach things pragmatically.

> > Unfortunately I am not comfortable with taking patch 1 for v4.3 because:
> > 1. Its now very late in the cycle
> 
> I understand.
> 
> > 2. There now seems to be some discussion around it.
> 
> Yeah, that's what v4s are for...
> 
> Let's wait and see if/when it settles...

Yes, lets.

> > I think I am happy to take the other patches for v4.4, now. But perhaps
> > I should wait for the discussion around patch 1 to conclude first?
> 
> Which other patches? Patch 3 has the same issue as patch 1. And all
> the rest depends on patch 1 or patch 3... So there's nothing left to
> apply yet...

Sorry for not being clearer. By other patches I meant patches 2 - 6 of this
series.  It seems that we should wait and I'm quite happy to do so.

      reply	other threads:[~2015-08-07  0:34 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-05  8:58 [PATCH v4 0/6] ARM: shmobile: r8a7740/sh73a0 DT Cache Handling Geert Uytterhoeven
     [not found] ` <1438765090-823-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
2015-08-05  8:58   ` [PATCH v4 1/6] ARM: shmobile: r8a7740 dtsi: Add L2 cache-controller node Geert Uytterhoeven
2015-08-05  9:34     ` Sudeep Holla
2015-08-05 10:44       ` Geert Uytterhoeven
     [not found]         ` <CAMuHMdXdEV+41mH338bDbazzqOErDLQkBUAj2+uVX4Wupn1ABQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-05 10:58           ` Sudeep Holla
     [not found]             ` <55C1EC3C.9000407-5wv7dgnIgG8@public.gmane.org>
2015-08-06 16:21               ` Geert Uytterhoeven
2015-08-07  9:45                 ` Sudeep Holla
2015-11-20 16:14                   ` Geert Uytterhoeven
2015-11-26 11:59                     ` Sudeep Holla
2015-08-05  8:58   ` [PATCH v4 2/6] ARM: shmobile: r8a7740 dtsi: Add L1 cache information to CPU node Geert Uytterhoeven
2015-08-05  8:58   ` [PATCH v4 3/6] ARM: shmobile: sh73a0 dtsi: Add L2 cache-controller node Geert Uytterhoeven
2015-08-05  8:58   ` [PATCH v4 6/6] ARM: shmobile: r8a7740: Remove mapping of L2 cache controller registers Geert Uytterhoeven
2015-08-05  8:58 ` [PATCH v4 4/6] ARM: shmobile: sh73a0 dtsi: Add L1 cache information to CPU nodes Geert Uytterhoeven
2015-08-05  8:58 ` [PATCH v4 5/6] ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization Geert Uytterhoeven
2015-08-06  0:35 ` [PATCH v4 0/6] ARM: shmobile: r8a7740/sh73a0 DT Cache Handling Simon Horman
2015-08-06  7:17   ` Geert Uytterhoeven
2015-08-07  0:34     ` Simon Horman [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=20150807003455.GB1145@verge.net.au \
    --to=horms@verge.net.au \
    --cc=devicetree@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=magnus.damm@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
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;
as well as URLs for NNTP newsgroup(s).