lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 10 Feb 2016 18:55:55 -0800
From:	Florian Fainelli <f.fainelli@...il.com>
To:	David Daney <ddaney@...iumnetworks.com>,
	Aaro Koskinen <aaro.koskinen@....fi>
Cc:	Matt Redfearn <matt.redfearn@...tec.com>,
	linux-mmc@...r.kernel.org, david.daney@...ium.com,
	ulf.hansson@...aro.org, linux-mips@...ux-mips.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	Zubair.Kakakhel@...tec.com,
	Aleksey Makarov <aleksey.makarov@...iumnetworks.com>,
	Chandrakala Chavva <cchavva@...iumnetworks.com>,
	Aleksey Makarov <aleksey.makarov@...iga.com>,
	Leonid Rosenboim <lrosenboim@...iumnetworks.com>,
	Peter Swain <pswain@...ium.com>,
	Aaron Williams <aaron.williams@...ium.com>
Subject: Re: [PATCH v5] mmc: OCTEON: Add host driver for OCTEON MMC controller

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?
-- 
Florian

Powered by blists - more mailing lists