linux-kernel - Re: How to "register" a GSI for a non PCI non ISA device

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:	Wed, 25 Jan 2012 00:56:53 -0500
From:	Len Brown <lenb@...nel.org>
To:	Guillaume Knispel <gknispel@...formatique.com>
CC:	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
	Guillaume Knispel <gknispel@...ncall.com>,
	Xavier Carcelle <xcarcelle@...ncall.com>,
	Noé Rubinstein 
	<nrubinstein@...ncall.com>
Subject: Re: How to "register" a GSI for a non PCI non ISA device

On 01/24/2012 12:42 PM, Guillaume Knispel wrote:

> Hi,
> 
> I'm building a PC platform with additional non-PCI and non-ISA devices:
> they are basically simple telecom chipsets connected to an SPI and an
> old school parallel bus (Intel LEB bus) and GPIO pins that can be used
> as interrupts through the IO APIC which exposes 40 GSI. From the point
> of view of the software the SPI, LEB, and GPIO are provided by PCI
> devices (in reality they are embedded controllers in an Intel SoC
> 80579). Anyway I'm not sure the additional GSI are described anywhere
> in whatever black magic ACPI / legacy BIOS table they could be
> (but I've complete control over the FW, so I can had whatever is
>  needed when I know it).

What is the benefit of implementing ACPI on this custom system?

-Len

> But as my devices are neither PCI nor ISA, I don't know how i can get
> access to the custom GSI interrupt from a LKM. acpi_register_gsi() used
> to be exported but is not anymore and I guess this is mandatory that
> this function is called to prepare internal structures (maybe irq_desc)
> and most importantly to configure to level triggering active low.
> 
> So I'm thinking about writing black magic DSDT stuffs or whatever,
> which i might be able to sort of do after reading the fabulous ACPI
> specifications. Any feedback or pointer would be highly welcome.
> 
> BTW when Linux devs says that bios writers are writing shit, yeah, they
> do, and given the state of complexity of the PC platform, I'm at the
> risk to do it too because I'm not supposed to delay the production of
> our system by one additional year just to completely learn how the
> shitty PC "standards" are supposed to work. From a more personal
> point of view when I'm reading the ACPI or other related specs tainted
> by MS and their desire to put GUID everywhere and other terrible ideas,
> I would rather prefer being high to not endure that much pain.
> 
> As more and more x86 systems are directly designed to run Linux and
> only tested with it, with some of those (like our own) being built
> by people having complete control on the board and firmware (Coreboot),
> maybe it is time to define a legacy-free variant of the x86 plateform
> (especially on the FW/OS interface) for the free software and free
> hardware design world, so that we aren't restricted and slowed down by
> retro-compatible technologies dedicated at running MS-DOS and created
> with the explicit goal to be hard to use for anything else than
> Windows NT.
> 
> Cheers!


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