public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC v1 1/2] documentation/iommu: Add description of Hisilicon System MMU binding
Date: Tue, 17 Jun 2014 09:14:41 +0200	[thread overview]
Message-ID: <6270066.3Z82jfEmEA@wuerfel> (raw)
In-Reply-To: <20140616182645.GD16758@arm.com>

On Monday 16 June 2014 19:26:45 Will Deacon wrote:
> On Mon, Jun 16, 2014 at 06:25:35PM +0100, Arnd Bergmann wrote:
> > On Monday 16 June 2014 17:45:17 Will Deacon wrote:
> > > On Mon, Jun 16, 2014 at 05:42:10PM +0100, Arnd Bergmann wrote:
> > > > We have to migrate the driver to the new binding anyway, it may be
> > > > a bit painful, but there are not really any users yet so there
> > > > is a chance we can remove the nonstandard code at some point,
> > > > perhaps in a few years.
> > > 
> > > The only way I see this working is if we kill the existing binding and move
> > > exclusively to the new one. I'm actually ok with that (we have no in-tree
> > > users), but it needs to happen ASAP in my opinion, otherwise we increase the
> > > window where the old binding can be adopted.
> > 
> > I agree. I was hoping to get the generic binding ready for 3.16, but that
> > didn't happen. Maybe we can add a small patch to the binding to explain
> > that it will change in the future.
> 
> Perhaps, but saying "don't use this" isn't much better than just ripping out
> the support altogether. That said, I won't object to a patch adding a big
> fat warning to the current binding docs if it dissuades people from using
> what we currently have.

Ok.

> > > Note that the next version of the ARM SMMU (v3) is considerably different to
> > > the current architecture, so a new driver (using the new bindings) will be
> > > required.
> > > 
> > > This actually opens a wider question: if we don't have an in-tree user for a
> > > device-tree binding, do we consider that binding to be unused?
> > 
> > Not in general, but often. We don't require dts files to be in the kernel,
> > so we have to apply a bit of common sense. If anyone knows of out-of-tree
> > users of the binding that are actually working with upstream kernels,
> > we need a migration path. Anything that also requires out-of-tree kernel
> > patches however is something we don't have to worry about.
> 
> Ok. If Thierry's binding gets in for 3.17, then I'll try to convert the ARM
> SMMU driver over to it for 3.18 providing we don't grow any in-tree users of
> the existing binding in the meantime (or 3.17 depending on how early it gets
> queued).
> 
> Sound fair?

Sounds good. Let's make sure we get this done quickly now. I think there
isn't much controversy left with the binding, though this particular one
has been tough in the past.

	Arnd

  reply	other threads:[~2014-06-17  7:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-05 13:37 [PATCH RFC v1 0/2] Add support for Hisilicon SMMU architecture Zhen Lei
2014-06-05 13:37 ` [PATCH RFC v1 1/2] documentation/iommu: Add description of Hisilicon System MMU binding Zhen Lei
2014-06-05 15:26   ` Mark Rutland
2014-06-06  6:48   ` Arnd Bergmann
2014-06-06 11:07     ` Dave Martin
2014-06-11  8:12       ` leizhen
2014-06-16 16:26       ` Will Deacon
2014-06-16 16:42         ` Arnd Bergmann
2014-06-16 16:45           ` Will Deacon
2014-06-16 17:25             ` Arnd Bergmann
2014-06-16 18:26               ` Will Deacon
2014-06-17  7:14                 ` Arnd Bergmann [this message]
2014-06-17 11:49                   ` Thierry Reding
2014-06-18 11:10                 ` Varun Sethi
2014-06-18 12:31                   ` Will Deacon
2014-06-20  9:54                     ` Varun Sethi
2014-06-20 17:49                       ` Will Deacon
2014-06-20 18:57                         ` Varun Sethi
2014-06-24 14:30                           ` Will Deacon
2014-06-17  7:57           ` leizhen
2014-06-16 16:44     ` Arnd Bergmann
2014-06-05 13:37 ` [PATCH RFC v1 2/2] iommu/hisilicon: Add support for Hisilicon Ltd. System MMU architecture Zhen Lei
2014-06-05 15:21 ` [PATCH RFC v1 0/2] Add support for Hisilicon SMMU architecture Mark Rutland
2014-06-06  0:21   ` leizhen

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=6270066.3Z82jfEmEA@wuerfel \
    --to=arnd@arndb.de \
    --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