linux-kernel - Re: x86/Kconfig: where to place a new chipset

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] [day] [month] [year] [list]

Message-ID: <4EA8F216.30807@zytor.com>
Date:	Thu, 27 Oct 2011 07:54:30 +0200
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Alessandro Rubini <rubini@...dd.com>
CC:	linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
	x86@...nel.org, giancarlo.asnaghi@...com
Subject: Re: x86/Kconfig: where to place a new chipset

On 10/27/2011 03:17 AM, Alessandro Rubini wrote:
> Hello.
> 
> I'm currently working on a PCIe chipset (or IO-Hub), called STA2X11.
> The device hosts a number of peripherals (sata, ether, spi, uart, ...)
> and a DMA controller.  The individual PCI functions can't be enabled
> by themselves, as chip support must be activated first.  This is both
> because some internal mappings must be setup and because internal
> device functions rely on the internal DMA engine. Actually, an
> instance of swiotlb is being used.
> 
> While I'm sure core code should be in arch/x86/platform (and there is
> where I placed the initialization code), I'm wondering where should
> the device fall in the Kconfig tree. I tend to put it in the
> X86_32_NON_STANDARD stanza, even if the resulting kernel will also
> work on standard computers (the "SGI Visual Workstation" config option
> does the same).
> 
> On the other hand, the device can either be the core chipset (main use
> case) or it can be plugged on a PCIe board.
> 

The nonstandard platform location seems fine to me.

	-hpa

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