linux-kernel - Re: [PATCH 4/8] minnowboard: Add base platform driver for the MinnowBoard

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]

Message-ID: <1372222365.9179.4.camel@x230>
Date:	Wed, 26 Jun 2013 04:52:46 +0000
From:	Matthew Garrett <matthew.garrett@...ula.com>
To:	Darren Hart <dvhart@...ux.intel.com>
CC:	Olof Johansson <olof@...om.net>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"peter.p.waskiewicz.jr@...el.com" <peter.p.waskiewicz.jr@...el.com>,
	"andriy.shevchenko@...ux.intel.com" 
	<andriy.shevchenko@...ux.intel.com>,
	"danders@...cuitco.com" <danders@...cuitco.com>,
	"vishal.l.verma@...el.com" <vishal.l.verma@...el.com>,
	Grant Likely <grant.likely@...aro.org>,
	"Linus Walleij" <linus.walleij@...aro.org>,
	Richard Purdie <richard.purdie@...uxfoundation.org>,
	"platform-driver-x86@...r.kernel.org" 
	<platform-driver-x86@...r.kernel.org>
Subject: Re: [PATCH 4/8] minnowboard: Add base platform driver for the
 MinnowBoard

On Tue, 2013-06-25 at 21:43 -0700, Darren Hart wrote:

> 1) I need time, possibly a couple of months, to get proper ACPI support
> for these drivers into the firmware. Then I can rewrite these as ACPI
> drivers as is proper for an x86 board. I've already started down this
> path.

A couple of months pushes you back one kernel release. It's not a huge
deal. I think I side with Olof here - the kernel developers have pushed
back against hardcoded and NIHed ARM device descriptors, and given that
we have a perfectly reasonable standard in the X86 world (ie, ACPI), I'm
not enthusiastic about merging something that's (a) going to be
superseded in the near future and (b) may end up serving as an example
to others who think this is ok.

Do these boards currently boot any other OSes?

> See what happens when core kernel people are allowed to write driver
> code? How does this relate to converting this over to an ACPI device
> driver? I guess I would replace the above with
> MODULE_DEVICE_TABLE(acpi, ...) ? If I do the above.... is this still an
> evil board-file? What makes the acpi method of discover superior to
> setting up linux-hotplug via dmi?

MODULE_DEVICE_TABLE is invisible to the running driver, it just exports
metadata that udev will use to decide whether to load the driver. If a
driver is intended to deal with a specific board, DMI makes sense. If
it's intended to deal with a specific ACPI device (ie, something with a
_HID that defines the programming model), ACPI makes sense.

-- 
Matthew Garrett | mjg59@...f.ucam.org