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

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:	Thu, 11 Feb 2016 19:28:17 +0000
From:	"Maciej W. Rozycki" <macro@...tec.com>
To:	David Daney <ddaney@...iumnetworks.com>
CC:	Aaro Koskinen <aaro.koskinen@....fi>,
	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

On Thu, 11 Feb 2016, David Daney wrote:

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

 I concur, a very good decision as far as I'm concerned!

 I had the misfortune to work with some Freescale Power boards which used 
in-kernel DTS files in a hope to match the respective board's firmware 
(U-boot).  Needless to say, that didn't quite work.  The mapping of board 
resources was reportedly changed in some version of the firmware to give 
more flexibility and the DTS files bundled with Linux updated accordingly, 
however no version of the old files was kept around and maintained.  So a 
kernel upgrade, which turned out inevitable at one point, became a 
challenging task to update the DTS files so as to match the version of the 
firmware the boards had.

 With some pain I was eventually able to sort this out through patching 
the old DTS files to match the ever-changing DTS syntax and get them 
accepted for a DTB build and work to an acceptable extent with the then 
current version of Linux.  However some board resources were lost, for 
example the IDE interface was no longer accessible; fortunately I didn't 
need it, so I just left it like that and didn't figure out what else I'd 
have to do to regain access.

 So no, no standalone DTS/DTBs please, thank you very much.

  Maciej