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