linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: ION DTS changes for HiKey in -next
Date: Mon, 11 Jan 2016 10:09:02 +0000	[thread overview]
Message-ID: <20160111100902.GA6499@leverpostej> (raw)
In-Reply-To: <568FFC8B.3090101@labbott.name>

On Fri, Jan 08, 2016 at 10:14:35AM -0800, Laura Abbott wrote:
> On 1/8/16 5:55 AM, Mark Rutland wrote:
> >On Fri, Jan 08, 2016 at 12:44:39PM +0000, Mark Brown wrote:
> >>On Thu, Jan 07, 2016 at 09:02:14PM -0800, Greg Kroah-Hartman wrote:
> >>>On Thu, Jan 07, 2016 at 05:37:44PM +0000, Mark Brown wrote:
> >>
> >>>>I was just looking at DTs in -next and noticed that there is a patch
> >>>>59dfafd03fc (arm64: dts: Add dts files to enable ION on Hi6220 SoC)
> >>>>which adds at DT doing something for ION.  Are we sure this should be
> >>>>going into the main production DT?  The bindings haven't been reviewed
> >>>>as far as I can tell, the matching driver is only in staging and hasn't
> >>>>been posted upstream.
> >>
> >>>Isn't "staging" upstream enough for this?  :)
> >>
> >>I wouldn't have thought so, DTs are supposed to be an ABI so we want
> >>proper review and having had a quick glance this doesn't look like it's
> >>a hardware description so it's not clear to me it should be in DT at all.
> >
> >Indeed.
> >
> >The driver and the binding before that don't really belong either,
> >I would have NAK'd those on devicetree at vger.kernel.org, though it
> >appears I either missed them or they never made it to that list.
> >
> > From my PoV there should not be a platform-specific ION binding. If we
> >need one at all, people should work on the proposed generic binding [1]
> >or figure out how to do this with the existing reserved-memory bindings.
> >
> >Thanks,
> >Mark.
> >
> >[1] https://lkml.org/lkml/2015/10/6/854
> 
> I posted v2 back in November
> (http://article.gmane.org/gmane.linux.drivers.driver-project.devel/80475)
> but there wasn't much in the way of review comments. More feedback there
> would be appreciated or I can resend.

A resend would be appeciated, as that's easier to reply to.

I'm still a little fuzzy on why this can't be done with reserved-memory,
but that's a discussion better left for the thread with the patches.

Thanks,
Mark.

  parent reply	other threads:[~2016-01-11 10:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-07 17:37 ION DTS changes for HiKey in -next Mark Brown
2016-01-08  5:02 ` Greg Kroah-Hartman
2016-01-08 12:44   ` Mark Brown
2016-01-08 13:55     ` Mark Rutland
2016-01-08 18:14       ` Laura Abbott
2016-01-09  5:05         ` Greg Kroah-Hartman
2016-01-11 15:18           ` Laura Abbott
2016-01-11 10:09         ` Mark Rutland [this message]
2016-01-09  5:05       ` Greg Kroah-Hartman

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=20160111100902.GA6499@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).