linux-kernel - Re: [advice sought] EOMA68 kernel support

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: <20120310130055.5bd5263a@pyramind.ukuu.org.uk>
Date:	Sat, 10 Mar 2012 13:00:55 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	lkcl luke <luke.leighton@...il.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux on small ARM machines 
	<arm-netbook@...ts.phcomp.co.uk>
Subject: Re: [advice sought] EOMA68 kernel support

On Sat, 10 Mar 2012 06:45:15 +0000
lkcl luke <luke.leighton@...il.com> wrote:

> On Fri, Mar 9, 2012 at 10:41 PM, lkcl luke <luke.leighton@...il.com> wrote:
> 
> > the implications of that split, for the linux kernel source code, are
> > a bit... scarey :)
> 
>  ... so, real simple very basic, concrete and necessary question:
> where the hell in the linux kernel tree should support for eoma68 be
> added??

It sounds to me like a bus.

>  * driver support can't be added to drivers/ because although a device
> with an EOMA68 CPU card *requires* drivers, it's not *actual* drivers
> being added, it's driver *grouping* code that's required, and that
> concept simply does... not... exist.

Actually we stick busses in drivers too (see pci...)

>  * architecture support can't be added to arch/ because that contains
> code for CPUs not code that is about helping to support multiple CPUs.
>  eoma isn't a CPU.

See above.. it's a bus

> very basic question.  where the hell should EOMA support source code go?
> 
> bearing in mind that the first CPU card is an Allwinner A10, the next
> one is likely to be an AMD Fusion, the one after that could be from
> icubecorp, the one after that a multi-core SMP xtensa, etc.

Off the top of my head I suspect you want

drivers/eoma68/

which is the bus interface and glue including reading the device tree
data for the current board you are plugged into and building a device
tree from that.

lib/eoma68

or some similar name, which is the library routines everything using
eoma68 needs

arch/[x86.arm,..]/platform/eoma68/..

probably the platform code for each system.


I don't btw see the problem with your device trees and display. If you've
got a device tree on *both* the CPU card and the I/O boards then you've
got all the data in the right places.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/