Re: [PATCH v5] mmc: OCTEON: Add host driver for OCTEON MMC controller

[Matt Redfearn]

Hi Florian.

On 11/02/16 02:55, Florian Fainelli wrote:
> Le 10/02/2016 16:32, David Daney a Ãcrit :
> > On 02/10/2016 03:49 PM, Aaro Koskinen wrote:
> > > Hi,
> > >
> > > On Wed, Feb 10, 2016 at 10:02:23AM -0800, David Daney wrote:
> > > > On 02/10/2016 09:36 AM, Matt Redfearn wrote:
> > > > > +        pr_warn(FW_WARN "%s: Legacy property '%s'. Please remove\n",
> > > > > +            node->full_name, legacy_name);
> > > > I don't like this warning message.
> > > >
> > > > The vast majority of people that see it will not be able to change their
> > > > firmware.  So it will be forever cluttering up their boot logs.
> > > Until they switch to use APPENDED_DTB. :-)
> > I am philosophically opposed to making the DTB an internal kernel
> > implementation detail.
> >
> > For OCTEON boards, it is an ABI between the boot firmware and the
> > kernel, and is impractical to change.
> >
> > One could argue that many years ago, when the decision was made (by me),
> > that we should have opted to carry in the kernel source code tree the
> > DTS files for all OCTEON boards ever made, but we did not do that.  Due
> > to the non-reversibility of time, the decision is hard to reverse.
> >
> > In the case of this MMC driver, the only real difference is that two
> > properties have legacy names that later had differing "official" names.
> >   The overhead of carrying the legacy bindings is very low.
> Since there is an existing FDT patching infrastructure in
> arch/mips/cavium-octeon/ would not that be a place where you could put
> an adaptation layer between your legacy firmware properties and the
> upstream binding?
Thanks for your constructive advice. That does, indeed, look like a 
better place to put this.

Thanks,
Matt