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]

Date:	Mon, 22 Jul 2013 00:41:34 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Lee Jones <lee.jones@...aro.org>,
	Darren Hart <dvhart@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"peter.p.waskiewicz.jr" <peter.p.waskiewicz.jr@...el.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	danders <danders@...cuitco.com>,
	"vishal.l.verma" <vishal.l.verma@...el.com>,
	Matthew Garrett <matthew.garrett@...ula.com>,
	Grant Likely <grant.likely@...aro.org>,
	Richard Purdie <richard.purdie@...uxfoundation.org>,
	platform-driver-x86 <platform-driver-x86@...r.kernel.org>
Subject: Re: [PATCH 4/8] minnowboard: Add base platform driver for the
 MinnowBoard

On Sat, Jul 20, 2013 at 07:37:54PM +0200, Linus Walleij wrote:
> On Thu, Jul 4, 2013 at 6:26 PM, Mark Brown <broonie@...nel.org> wrote:

> > We should really have a subsystem for this too - the general idea idea
> > of identifying boards, fit options and so on by looking at things like
> > GPIOs or numbers in flash is really common.

> Would it then be a bus following the pattern we chiseled out for
> the soc bus? (Greg, Lee & Arnd architectured this.)

I'd expect it to be a bus, yes.

> There we needed a struct device * on an overarching level to
> tie in the sysfs entries reading out the SoC properties. But
> it would be the same thing with in-kernel accessors for these
> properties.

I'd expect us to end up with devices for the modules doing the mapping.
I'm not sure what the accessors you're thinking about would be, this
should hopefully be transparent to devices sitting on the boards
otherwise it seems like there's not that much point really.

> So it would be the same pattern above with a board bus, in
> DT syntax:

> board {
>      soc {
>      };
> };

I'm not 100% sure what this means, sorry?  If you're saying it'd be
something that sits within the master board for the system (whatever
that happens to be) then yes.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)