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

Message-ID: <20120124184203.1b0878c2@xilun>
Date:	Tue, 24 Jan 2012 18:42:03 +0100
From:	Guillaume Knispel <gknispel@...formatique.com>
To:	linux-kernel@...r.kernel.org
Cc:	linux-acpi@...r.kernel.org,
	Guillaume Knispel <gknispel@...ncall.com>,
	Xavier Carcelle <xcarcelle@...ncall.com>,
	Noé Rubinstein <nrubinstein@...ncall.com>
Subject: How to "register" a GSI for a non PCI non ISA device

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).

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!
-- 
Guillaume Knispel
Avencall - 10 bis, rue Lucien Voilin - 92800 Puteaux

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