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]

Message-ID: <CAErSpo5vCr4Y3Q6U1=yYLcSBH-85koMKDte4rzw4tyuKocYXYA@mail.gmail.com>
Date:	Thu, 26 Jan 2012 10:24:31 -0700
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Guillaume Knispel <gknispel@...formatique.com>
Cc:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Len Brown <lenb@...nel.org>, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org,
	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 Thu, Jan 26, 2012 at 9:22 AM, Guillaume Knispel
<gknispel@...formatique.com> wrote:
> On Thu, 26 Jan 2012 10:32:39 -0500
> Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:
>
>> On Thu, Jan 26, 2012 at 04:07:19PM +0100, Guillaume Knispel wrote:
>> > On Wed, 25 Jan 2012 14:02:14 -0500
>> > Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:
>> >
>> > > On Wed, Jan 25, 2012 at 06:23:14PM +0100, Guillaume Knispel wrote:
>> > >
>> > > > can't call it explicitly from my LKM, there should better be a way to
>> > > > make it be called when an ACPI thing is done, or maybe a legacy table
>> > > > parsed.
>> > >
>> > > Can you do it the way xen does? Look in arch/x86/xen/pci.c
>> >
>> > Did not found this file. Besides, isn't Xen a separate architecture
>>
>> Duh! I meant arch/x86/pci/xen.c
>>
>> > from mainline x86, compiled built-in? My goal is to only touch LKM and
>>
>> Not anymore. It is dynamically on if the kernel detects its running under the
>> hypervisor.
>>
>> I am still unclear what you are trying to do. Is it that
>> you have _PRT ACPI tables and your want to have your module be called
>> when those are parsed? If so, then __acpi_register_gsi is your guy -
>> and you can over-write it to your platform. Granted at that point that
>> function parameter should be guarded by some form of locking. Perhaps
>> provide a acpi_register_gsi_fnc() that can be exported out. Would
>> that work for you (I can cook up a patch for that)?
>
> Sorry if I was unclear, I'll try to make things more explicit.
>
> We build the platform which obviously differs a little from a PC (but
> just because of the presence of those additional non-ISA non-PCI
> devices), but as far as software is concerned we are trying to make the
> system run with a standard unmodified Linux kernel already built by
> Debian (because rebuilding our own would shift the maintenance of
> that kernel on us instead of Debian, and we would not be good at that)
>
> So what we can act on are the LKM and the system firmware, but not the
> bzImage.
>
> The problem I'm facing is that I don't know how to setup a GSI, what
> used to be done by directly calling acpi_register_gsi(), which was
> possible from an LKM when it was exported (for example in 2.6.18,
> which was the kernel used by Intel for their dev board).

A driver should never need to use acpi_register_gsi() directly.  It
sounds like you have a non-PCI device that would be described as an
ACPI device in the DSDT.  In the Device definition, you include a _CRS
method that tells the kernel what GSI it is using.  The PNPACPI
subsystem will parse _CRS and should do the acpi_register_gsi() for
you.  Then your driver would use pnp_register_driver() and pnp_irq()
to learn the IRQ.  drivers/tty/serial/8250_pnp.c is an example.

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