[PATCH RFC v1 1/2] documentation/iommu: Add description of Hisilicon System MMU binding

Varun Sethi Varun.Sethi at freescale.com
Wed Jun 18 04:10:11 PDT 2014


Hi Will,

> -----Original Message-----
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> bounces at lists.infradead.org] On Behalf Of Will Deacon
> Sent: Monday, June 16, 2014 11:57 PM
> To: Arnd Bergmann
> Cc: Kefeng Wang; Catalin Marinas; Tianhong Ding; huxinwei at huawei.com;
> Zefan Li; Zhen Lei; Dave P Martin; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH RFC v1 1/2] documentation/iommu: Add description of
> Hisilicon System MMU binding
> 
> 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.
> 
> > > 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?
Would you be considering the handling of hot plug masters in the arm-smmu driver while incorporating the new binding?

-Varun



More information about the linux-arm-kernel mailing list