Hi Florian.

On 11/02/16 02:55, Florian Fainelli wrote:

Le 10/02/2016 16:32, David Daney a écrit :

quoted

On 02/10/2016 03:49 PM, Aaro Koskinen wrote:

quoted

Hi,

On Wed, Feb 10, 2016 at 10:02:23AM -0800, David Daney wrote:

quoted

On 02/10/2016 09:36 AM, Matt Redfearn wrote:

quoted

+        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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html