[PATCH] x86: HPET force enable for Soekris net6501

[PATCH] x86: HPET force enable for Soekris net6501

[Conrad Kostecki]

Hello,
as the Soekris net6501 does not have any ACPI implementation, HPET won't get enabled.
This patch enables HPET on such platforms.

[    0.430149] pci 0000:00:01.0: Force enabled HPET at 0xfed00000
[    0.644838] HPET: 3 timers in total, 0 timers will be used for per-cpu timer

Original patch by Peter Neubauer, slightly modified by me.
-> http://www.mail-archive.com/soekris-tech@lists.soekris.com/msg06462.html

Cheers
Conrad

Signed-off-by: Peter Neubauer <pneubauer@bluerwhite.org>
Signed-off-by: Conrad Kostecki <ck@conrad-kostecki.de>

--- a/arch/x86/kernel/quirks.c	2014-02-14 11:13:27.703432732 +0100
+++ b/arch/x86/kernel/quirks.c	2014-02-14 11:14:32.327496474 +0100
@@ -498,6 +498,25 @@ void force_hpet_resume(void)
 }
 
 /*
+ * Soekris net6501, based on Atom E6xx series, does not have ACPI.
+ * HPET should be force enabled on such platforms.
+ */
+static void e6xx_force_enable_hpet(struct pci_dev *dev)
+{
+	if (hpet_address || force_hpet_address)
+		return;
+
+	force_hpet_address = 0xFED00000;
+	force_hpet_resume_type = NONE_FORCE_HPET_RESUME;
+	dev_printk(KERN_DEBUG, &dev->dev, "Force enabled HPET at "
+		"0x%lx\n", force_hpet_address);
+	return;
+}
+
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E6XX_CU,
+			 e6xx_force_enable_hpet);
+
+/*
  * HPET MSI on some boards (ATI SB700/SB800) has side effect on
  * floppy DMA. Disable HPET MSI on such platforms.
  * See erratum #27 (Misinterpreted MSI Requests May Result in
--- a/include/linux/pci_ids.h	2014-02-14 11:13:00.575408953 +0100
+++ b/include/linux/pci_ids.h	2014-02-14 11:13:37.819442066 +0100
@@ -2854,6 +2854,7 @@
 #define PCI_DEVICE_ID_INTEL_82372FB_1	0x7601
 #define PCI_DEVICE_ID_INTEL_SCH_LPC	0x8119
 #define PCI_DEVICE_ID_INTEL_SCH_IDE	0x811a
+#define PCI_DEVICE_ID_INTEL_E6XX_CU	0x8183
 #define PCI_DEVICE_ID_INTEL_ITC_LPC	0x8186
 #define PCI_DEVICE_ID_INTEL_82454GX	0x84c4
 #define PCI_DEVICE_ID_INTEL_82450GX	0x84c5

Re: [PATCH] x86: HPET force enable for Soekris net6501

[H. Peter Anvin]

On 02/14/2014 02:23 AM, Conrad Kostecki wrote:
> Hello,
> as the Soekris net6501 does not have any ACPI implementation, HPET won't get enabled.
> This patch enables HPET on such platforms.
> 
> [    0.430149] pci 0000:00:01.0: Force enabled HPET at 0xfed00000
> [    0.644838] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
> 
> Original patch by Peter Neubauer, slightly modified by me.
> -> http://www.mail-archive.com/soekris-tech@lists.soekris.com/msg06462.html
> 
> Cheers
> Conrad

Are you sure this won't break any other E6xx platforms?

	-hpa

AW: [PATCH] x86: HPET force enable for Soekris net6501

[Conrad Kostecki]

> On 02/14/2014 02:23 AM, Conrad Kostecki wrote:
> > Hello,
> > as the Soekris net6501 does not have any ACPI implementation, HPET
> won't get enabled.
> > This patch enables HPET on such platforms.
> >
> > [    0.430149] pci 0000:00:01.0: Force enabled HPET at 0xfed00000
> > [    0.644838] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
> >
> > Original patch by Peter Neubauer, slightly modified by me.
> > -> http://www.mail-archive.com/soekris-
> tech@lists.soekris.com/msg06462.html
> >
> > Cheers
> > Conrad
> 
> Are you sure this won't break any other E6xx platforms?

Hm. I am not. The Soekris is my only device with an E6xx CPU. This one is special, as Soekris does not implement ACPI.
I don't know, how other E6xx systems do work. I guess, there will have ACPI. There seem not to be many out there.
This patch is now running for about six months without any problems for me.

I was also searching for some other systems. I found here only one manual.
There are at least the same vendor/device id shown, as used also in Soekris.
-> http://www.ekf.de/p/pc2/pc2_ug.pdf

Is there maybe any possibility to check for the specific Soekris model? At least MPTABLE identifies the Soekris:
[    0.000000] MPTABLE: OEM ID: Soekris
[    0.000000] MPTABLE: Product ID: net6501
[    0.000000] MPTABLE: APIC at: 0xFEE00000

Cheers
Conrad

Re: AW: [PATCH] x86: HPET force enable for Soekris net6501

[H. Peter Anvin]

On 02/14/2014 10:06 AM, Conrad Kostecki wrote:
> 
> Hm. I am not. The Soekris is my only device with an E6xx CPU. This one is special, as Soekris does not implement ACPI.
> I don't know, how other E6xx systems do work. I guess, there will have ACPI. There seem not to be many out there.
> This patch is now running for about six months without any problems for me.
> 
> I was also searching for some other systems. I found here only one manual.
> There are at least the same vendor/device id shown, as used also in Soekris.
> -> http://www.ekf.de/p/pc2/pc2_ug.pdf
> 
> Is there maybe any possibility to check for the specific Soekris model? At least MPTABLE identifies the Soekris:
> [    0.000000] MPTABLE: OEM ID: Soekris
> [    0.000000] MPTABLE: Product ID: net6501
> [    0.000000] MPTABLE: APIC at: 0xFEE00000
> 

Does it have DMI?

	-hpa

AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Conrad Kostecki]

> On 02/14/2014 10:06 AM, Conrad Kostecki wrote:
> >
> > Hm. I am not. The Soekris is my only device with an E6xx CPU. This one is
> special, as Soekris does not implement ACPI.
> > I don't know, how other E6xx systems do work. I guess, there will have
> ACPI. There seem not to be many out there.
> > This patch is now running for about six months without any problems for
> me.
> >
> > I was also searching for some other systems. I found here only one manual.
> > There are at least the same vendor/device id shown, as used also in
> Soekris.
> > -> http://www.ekf.de/p/pc2/pc2_ug.pdf
> >
> > Is there maybe any possibility to check for the specific Soekris model? At
> least MPTABLE identifies the Soekris:
> > [    0.000000] MPTABLE: OEM ID: Soekris
> > [    0.000000] MPTABLE: Product ID: net6501
> > [    0.000000] MPTABLE: APIC at: 0xFEE00000
> >
> 
> Does it have DMI?

Unfortunately not.

# dmidecode 2.12
# No SMBIOS nor DMI entry point found, sorry.

Cheers
Conrad

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[H. Peter Anvin]

On 02/14/2014 10:13 AM, Conrad Kostecki wrote:
>>
>> Does it have DMI?
> 
> Unfortunately not.
> 
> # dmidecode 2.12
> # No SMBIOS nor DMI entry point found, sorry.
> 

Sigh.  Does anyone have contacts at Soekris who can complain about this
stuff?

	-hpa

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Thomas Gleixner]

On Fri, 14 Feb 2014, H. Peter Anvin wrote:

> On 02/14/2014 10:13 AM, Conrad Kostecki wrote:
> >>
> >> Does it have DMI?
> > 
> > Unfortunately not.
> > 
> > # dmidecode 2.12
> > # No SMBIOS nor DMI entry point found, sorry.
> > 
> 
> Sigh.  Does anyone have contacts at Soekris who can complain about this
> stuff?

Well, lots of embedded stuff comes with a crippled BIOS. And there is
often no way to get any BIOS fixes from the vendor through the
subvendors and supplier chain.

I wish we could just use devicetree for such cases and fix the crud
ourself.

Thanks,

	tglx

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[H. Peter Anvin]

On 02/14/2014 10:21 AM, Thomas Gleixner wrote:
> On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> 
>> On 02/14/2014 10:13 AM, Conrad Kostecki wrote:
>>>>
>>>> Does it have DMI?
>>>
>>> Unfortunately not.
>>>
>>> # dmidecode 2.12
>>> # No SMBIOS nor DMI entry point found, sorry.
>>>
>>
>> Sigh.  Does anyone have contacts at Soekris who can complain about this
>> stuff?
> 
> Well, lots of embedded stuff comes with a crippled BIOS. And there is
> often no way to get any BIOS fixes from the vendor through the
> subvendors and supplier chain.
> 
> I wish we could just use devicetree for such cases and fix the crud
> ourself.
> 

We'd have to identify the platform, which is the main problem.  Right
now we support quirking for DMI or PCI, but I don't think we do for MPTABLE.

	-hpa

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Thomas Gleixner]

On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> On 02/14/2014 10:21 AM, Thomas Gleixner wrote:
> > I wish we could just use devicetree for such cases and fix the crud
> > ourself.
> > 
> 
> We'd have to identify the platform, which is the main problem.  Right
> now we support quirking for DMI or PCI, but I don't think we do for MPTABLE.

My point is that device tree support for some basic stuff like
hpet/ioapic and such would allow people like Conrad to avoid the
stupid hackery of quirks.

Building your own DT requires to read a datasheet as does hacking a
quirk, but its definitely simpler. And we can collect the DTs for
known boards either in the kernel or in some external repository.

People who are dealing with embedded stuff are not those who are
frightened by datasheets and building a custom kernel with some extra
blob.

I bet Conrad is also stuck with PIC on the E6xx CPU and that's a major
PITA. I have such a board as well and it simply sucks.

Now you can't hack an ioapic quirk because that's way to complex, but
we have proven with the ce4100 that it is reasonably simple to get
that stuff working nicely when you can read a datasheet. If we could
generalize that for a few crucial devices that would help a lot.

When I asked the board vendor why there are no acpi tables in the
device, I got the answer, that this is an embedded board and the
"BIOS" built with BLDK does not support that. We all know that's not
true, but how does that help?

The people who brought up the initial target OS (WinCE) on that board
worked around the lack of ACPI by hacking HPET support into the CE
preloader and switched all device drivers to use MSI because CE failed
to handle the PIC properly. That avoided that they needed to hack the
ioapic into submission as well.

That's the sad reality. And we have to cope with these boards whether
we like it or not.

Thanks,

	tglx

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[H. Peter Anvin]

We could also just add an ACPI table... same concept.  Still need to find it.

On February 14, 2014 10:38:24 AM PST, Thomas Gleixner <tglx@linutronix.de> wrote:
>On Fri, 14 Feb 2014, H. Peter Anvin wrote:
>> On 02/14/2014 10:21 AM, Thomas Gleixner wrote:
>> > I wish we could just use devicetree for such cases and fix the crud
>> > ourself.
>> > 
>> 
>> We'd have to identify the platform, which is the main problem.  Right
>> now we support quirking for DMI or PCI, but I don't think we do for
>MPTABLE.
>
>My point is that device tree support for some basic stuff like
>hpet/ioapic and such would allow people like Conrad to avoid the
>stupid hackery of quirks.
>
>Building your own DT requires to read a datasheet as does hacking a
>quirk, but its definitely simpler. And we can collect the DTs for
>known boards either in the kernel or in some external repository.
>
>People who are dealing with embedded stuff are not those who are
>frightened by datasheets and building a custom kernel with some extra
>blob.
>
>I bet Conrad is also stuck with PIC on the E6xx CPU and that's a major
>PITA. I have such a board as well and it simply sucks.
>
>Now you can't hack an ioapic quirk because that's way to complex, but
>we have proven with the ce4100 that it is reasonably simple to get
>that stuff working nicely when you can read a datasheet. If we could
>generalize that for a few crucial devices that would help a lot.
>
>When I asked the board vendor why there are no acpi tables in the
>device, I got the answer, that this is an embedded board and the
>"BIOS" built with BLDK does not support that. We all know that's not
>true, but how does that help?
>
>The people who brought up the initial target OS (WinCE) on that board
>worked around the lack of ACPI by hacking HPET support into the CE
>preloader and switched all device drivers to use MSI because CE failed
>to handle the PIC properly. That avoided that they needed to hack the
>ioapic into submission as well.
>
>That's the sad reality. And we have to cope with these boards whether
>we like it or not.
>
>Thanks,
>
>	tglx

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Thomas Gleixner]

On Fri, 14 Feb 2014, H. Peter Anvin wrote:

> We could also just add an ACPI table... same concept.  Still need to find it.

I'm fine with ACPI tables if we can provide simple means for embedded
users to load one via grub or just attach it to the kernel image.

Sure, the user needs to know how to prepare one, but for similar
platforms, e.g. e6xx based stuff the tables would look all the
same. We probably could just recycle those from the BLDK.

Thanks,

	tglx

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[H. Peter Anvin]

On 02/14/2014 11:15 AM, Thomas Gleixner wrote:
> 
> 
> On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> 
>> We could also just add an ACPI table... same concept.  Still need to find it.
> 
> I'm fine with ACPI tables if we can provide simple means for embedded
> users to load one via grub or just attach it to the kernel image.

That already exists, see Documentation/acpi/initrd_table_override.txt.

> Sure, the user needs to know how to prepare one, but for similar
> platforms, e.g. e6xx based stuff the tables would look all the
> same. We probably could just recycle those from the BLDK.

Yes, that might be a good way to do it.

	-hpa

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Thomas Gleixner]

On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> On 02/14/2014 11:15 AM, Thomas Gleixner wrote:
> > I'm fine with ACPI tables if we can provide simple means for embedded
> > users to load one via grub or just attach it to the kernel image.
> 
> That already exists, see Documentation/acpi/initrd_table_override.txt.

That requires, that you have already ACPI tables.

ACPI_SIG_RSDP cannot be overridden and that's the base table you need
to get ACPI going in the first place. So we need support for that and
probably for storing the tables at some non canonical place.

Thanks,

	tglx

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[H. Peter Anvin]

On 02/14/2014 11:59 AM, Thomas Gleixner wrote:
> On Fri, 14 Feb 2014, H. Peter Anvin wrote:
>> On 02/14/2014 11:15 AM, Thomas Gleixner wrote:
>>> I'm fine with ACPI tables if we can provide simple means for embedded
>>> users to load one via grub or just attach it to the kernel image.
>>
>> That already exists, see Documentation/acpi/initrd_table_override.txt.
> 
> That requires, that you have already ACPI tables.
> 
> ACPI_SIG_RSDP cannot be overridden and that's the base table you need
> to get ACPI going in the first place. So we need support for that and
> probably for storing the tables at some non canonical place.
> 

Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables,
so if explicitly overridden I'm not sure if one actually would need
them.  That doesn't mean our current code will work without them, though.

Thomas, Rafael, do you have any insights?

	-hpa

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Thomas Gleixner]

On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> On 02/14/2014 11:59 AM, Thomas Gleixner wrote:
> > On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> >> On 02/14/2014 11:15 AM, Thomas Gleixner wrote:
> >>> I'm fine with ACPI tables if we can provide simple means for embedded
> >>> users to load one via grub or just attach it to the kernel image.
> >>
> >> That already exists, see Documentation/acpi/initrd_table_override.txt.
> > 
> > That requires, that you have already ACPI tables.
> > 
> > ACPI_SIG_RSDP cannot be overridden and that's the base table you need
> > to get ACPI going in the first place. So we need support for that and
> > probably for storing the tables at some non canonical place.
> > 
> 
> Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables,
> so if explicitly overridden I'm not sure if one actually would need
> them.  That doesn't mean our current code will work without them, though.

I tried once to overload all of the tables, but failed miserably in
the ACPI dungeon. RSDP was the major pain point IIRC.

Thanks,

	tglx

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[H. Peter Anvin]

On 02/14/2014 01:16 PM, Thomas Gleixner wrote:
>>
>> Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables,
>> so if explicitly overridden I'm not sure if one actually would need
>> them.  That doesn't mean our current code will work without them, though.
> 
> I tried once to overload all of the tables, but failed miserably in
> the ACPI dungeon. RSDP was the major pain point IIRC.
> 

I suspect we need to handle the RSDP and RSDT/XSDT specially, since,
again, they are really just pointers to where to find the other tables.
 They are part of the discovery, not the data.

	-hpa

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Thomas Gleixner]

On Fri, 14 Feb 2014, H. Peter Anvin wrote:

> On 02/14/2014 01:16 PM, Thomas Gleixner wrote:
> >>
> >> Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables,
> >> so if explicitly overridden I'm not sure if one actually would need
> >> them.  That doesn't mean our current code will work without them, though.
> > 
> > I tried once to overload all of the tables, but failed miserably in
> > the ACPI dungeon. RSDP was the major pain point IIRC.
> > 
> 
> I suspect we need to handle the RSDP and RSDT/XSDT specially, since,
> again, they are really just pointers to where to find the other tables.
>  They are part of the discovery, not the data.

I'm aware of that and I tried to hack around it but failed miserably
due to lack of masochism. It was simpler to abuse the DT stuff to get
things done. :)

Thanks,

	tglx

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[H. Peter Anvin]

On 02/14/2014 01:47 PM, Thomas Gleixner wrote:
> 
> I'm aware of that and I tried to hack around it but failed miserably
> due to lack of masochism. It was simpler to abuse the DT stuff to get
> things done. :)
> 

Right... we should fix that, though.

	-hpa

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Thomas Renninger]

On Friday, February 14, 2014 10:16:41 PM Thomas Gleixner wrote:
> On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> > On 02/14/2014 11:59 AM, Thomas Gleixner wrote:
> > > On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> > >> On 02/14/2014 11:15 AM, Thomas Gleixner wrote:
> > >>> I'm fine with ACPI tables if we can provide simple means for embedded
> > >>> users to load one via grub or just attach it to the kernel image.
> > >> 
> > >> That already exists, see Documentation/acpi/initrd_table_override.txt.
> > > 
> > > That requires, that you have already ACPI tables.
> > > 
> > > ACPI_SIG_RSDP cannot be overridden and that's the base table you need
> > > to get ACPI going in the first place. So we need support for that and
> > > probably for storing the tables at some non canonical place.
> > 
> > Well, the RSDP and RSDT/XSDT are nothing but pointers to other tables,
> > so if explicitly overridden I'm not sure if one actually would need
> > them.  That doesn't mean our current code will work without them, though.
> 
> I tried once to overload all of the tables, but failed miserably in
> the ACPI dungeon. RSDP was the major pain point IIRC.

What exactly do you try to achieve?
I cannot imagine a use-case where RSDP  and XSDT overriding would help you.

Have you tried the current mechanism to override tables?
What is missing and for what do you need it for?

I need more context, maybe I can help then.

   Thomas

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[H. Peter Anvin]

What I gather is that they want to add tables where there are none, and that the ACPI code doesn't play along because there is no RSDP nor any RSDT/XSDT.

On February 17, 2014 8:28:05 AM PST, Thomas Renninger <trenn@suse.de> wrote:
>On Friday, February 14, 2014 10:16:41 PM Thomas Gleixner wrote:
>> On Fri, 14 Feb 2014, H. Peter Anvin wrote:
>> > On 02/14/2014 11:59 AM, Thomas Gleixner wrote:
>> > > On Fri, 14 Feb 2014, H. Peter Anvin wrote:
>> > >> On 02/14/2014 11:15 AM, Thomas Gleixner wrote:
>> > >>> I'm fine with ACPI tables if we can provide simple means for
>embedded
>> > >>> users to load one via grub or just attach it to the kernel
>image.
>> > >> 
>> > >> That already exists, see
>Documentation/acpi/initrd_table_override.txt.
>> > > 
>> > > That requires, that you have already ACPI tables.
>> > > 
>> > > ACPI_SIG_RSDP cannot be overridden and that's the base table you
>need
>> > > to get ACPI going in the first place. So we need support for that
>and
>> > > probably for storing the tables at some non canonical place.
>> > 
>> > Well, the RSDP and RSDT/XSDT are nothing but pointers to other
>tables,
>> > so if explicitly overridden I'm not sure if one actually would need
>> > them.  That doesn't mean our current code will work without them,
>though.
>> 
>> I tried once to overload all of the tables, but failed miserably in
>> the ACPI dungeon. RSDP was the major pain point IIRC.
>
>What exactly do you try to achieve?
>I cannot imagine a use-case where RSDP  and XSDT overriding would help
>you.
>
>Have you tried the current mechanism to override tables?
>What is missing and for what do you need it for?
>
>I need more context, maybe I can help then.
>
>   Thomas

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Thomas Renninger]

On Monday, February 17, 2014 09:19:03 AM H. Peter Anvin wrote:
> What I gather is that they want to add tables where there are none, and that
> the ACPI code doesn't play along because there is no RSDP nor any
> RSDT/XSDT.
Yep, this does currently not work.

Easiest I can think of instead of trying to modify RSDP or similar, is
to still pass the tables via unzipped, glued cpio which the kernel
can access early. The same way it is done for current ACPI table overriding
and early microcode passing.

Also find them via:
file = find_cpio_data(cpio_path, data, size, &offset);
(compare with drivers/acpi/osl.c)

and add them to (compare with drivers/acpi/acpica/acglobal.h):
/*
 * acpi_gbl_root_table_list is the master list of ACPI tables that were
 * found in the RSDT/XSDT.
 */
ACPI_EXTERN struct acpi_table_list acpi_gbl_root_table_list;

But right now, this is acpica internal only.
Most elegant way should be that ACPICA people would add another OS
callback:

acpi_status
acpi_os_physical_table_add(acpi_physical_address *address,
                                u32 *table_length));

which is called right after acpi_os_physical_table_override.

Implementation of it should be in osl.c again where it can easily
be tracked whether a table has been replaced already and need not to
be added, for example something like:
__initdata struct cpio_data overridden_tables[ACPI_OVERRIDE_TABLES];

ACPICA part should not be hard as well. It's some time ago, but it
may be a simple call to:
        /* Add the table to the global root table list */

        status = acpi_tb_store_table(table_desc->address, table_desc->pointer,
                                     table_desc->length, table_desc->flags,
                                     table_index);

if acpi_os_physical_table_add() has returned a valid address/length.
This would then add the table to acpica internal:

/*
 * acpi_gbl_root_table_list is the master list of ACPI tables that were
 * found in the RSDT/XSDT.
 */
ACPI_EXTERN struct acpi_table_list acpi_gbl_root_table_list;

and later all the tables in there get loaded and set up as if they
were passed from BIOS.

       Thomas


> On February 17, 2014 8:28:05 AM PST, Thomas Renninger <trenn@suse.de> wrote:
> >On Friday, February 14, 2014 10:16:41 PM Thomas Gleixner wrote:
> >> On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> >> > On 02/14/2014 11:59 AM, Thomas Gleixner wrote:
> >> > > On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> >> > >> On 02/14/2014 11:15 AM, Thomas Gleixner wrote:
> >> > >>> I'm fine with ACPI tables if we can provide simple means for
> >
> >embedded
> >
> >> > >>> users to load one via grub or just attach it to the kernel
> >
> >image.
> >
> >> > >> That already exists, see
> >
> >Documentation/acpi/initrd_table_override.txt.
> >
> >> > > That requires, that you have already ACPI tables.
> >> > > 
> >> > > ACPI_SIG_RSDP cannot be overridden and that's the base table you
> >
> >need
> >
> >> > > to get ACPI going in the first place. So we need support for that
> >
> >and
> >
> >> > > probably for storing the tables at some non canonical place.
> >> > 
> >> > Well, the RSDP and RSDT/XSDT are nothing but pointers to other
> >
> >tables,
> >
> >> > so if explicitly overridden I'm not sure if one actually would need
> >> > them.  That doesn't mean our current code will work without them,
> >
> >though.
> >
> >> I tried once to overload all of the tables, but failed miserably in
> >> the ACPI dungeon. RSDP was the major pain point IIRC.
> >
> >What exactly do you try to achieve?
> >I cannot imagine a use-case where RSDP  and XSDT overriding would help
> >you.
> >
> >Have you tried the current mechanism to override tables?
> >What is missing and for what do you need it for?
> >
> >I need more context, maybe I can help then.
> >
> >   Thomas

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[H. Peter Anvin]

On 02/17/2014 10:23 AM, Thomas Renninger wrote:
> 
> Easiest I can think of instead of trying to modify RSDP or similar, is
> to still pass the tables via unzipped, glued cpio which the kernel
> can access early. The same way it is done for current ACPI table overriding
> and early microcode passing.
> 

We shouldn't *need* an RSDP and RSDT/XSDT, though, since all they are
are pointers to the actual tables.  Rather than hacking around it we
should probably just fix the fundamental problem.

	-hpa

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Thomas Renninger]

On Monday, February 17, 2014 10:47:50 AM H. Peter Anvin wrote:
> On 02/17/2014 10:23 AM, Thomas Renninger wrote:
> > Easiest I can think of instead of trying to modify RSDP or similar, is
> > to still pass the tables via unzipped, glued cpio which the kernel
> > can access early. The same way it is done for current ACPI table
> > overriding
> > and early microcode passing.
> 
> We shouldn't *need* an RSDP and RSDT/XSDT, though, since all they are
> are pointers to the actual tables.  Rather than hacking around it we
> should probably just fix the fundamental problem.

That is what I described.
If something similar what I wrote gets implemented, you can simply
add ACPI tables to initrd as described here:
Documentation/acpi/initrd_table_override.txt
and if BIOS already provides them they get overridden, otherwise
they get added.

     Thomas

Re: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[H. Peter Anvin]

On 02/17/2014 11:25 AM, Thomas Renninger wrote:
> On Monday, February 17, 2014 10:47:50 AM H. Peter Anvin wrote:
>> On 02/17/2014 10:23 AM, Thomas Renninger wrote:
>>> Easiest I can think of instead of trying to modify RSDP or similar, is
>>> to still pass the tables via unzipped, glued cpio which the kernel
>>> can access early. The same way it is done for current ACPI table
>>> overriding
>>> and early microcode passing.
>>
>> We shouldn't *need* an RSDP and RSDT/XSDT, though, since all they are
>> are pointers to the actual tables.  Rather than hacking around it we
>> should probably just fix the fundamental problem.
> 
> That is what I described.
> If something similar what I wrote gets implemented, you can simply
> add ACPI tables to initrd as described here:
> Documentation/acpi/initrd_table_override.txt
> and if BIOS already provides them they get overridden, otherwise
> they get added.
> 

Right, that was the idea.  Thomas Gleixner said it didn't work.

	-hpa

ACPI: Also allow ACPI table adding via initrd not only overriding

[Thomas Renninger]

The ACPICA patches have to go into separate acpica repository first.
It should also be checked in acpica whether the table signature the OS likes
to add already exists (from BIOS). In this case the table must not be added.

Worked here by trying to override a DSDT and addind a BGRT table.

     Thomas

[PATCH 1/4] ACPI: Provide support for ACPI table adding via OS

[Thomas Renninger]

This is done the same way as the previous ACPI physical table override
mechanism.
How to override or add tables via initrd, please look up:
Documentation/acpi/initrd_table_override.txt

SSDTs can only be overridden, not added.

Overriding only happens if the OEM id of the table header matches the one
with the BIOS provided one.
All table types (SSDTs are an exception), must only show up once.
So either you:
   - Add a fresh new table for adding of which type (signature) none exists
     in the BIOS  -> OS ACPI table adding happens.
or
   - Add a table which already exists in BIOS, but the OEM id must match the
     one of the table of the same type (signature) that exists in BIOS already
     -> OS ACPI table overriding happens
     Typically one copies away the original ACPI table, disassembles,
     modifies (for example adding debug strings), compiles it and provides
     the table via initrd for overriding (will have the same OEM id).
     But this is not necessary, one could also come up with a selfmade
     table for overriding, by taking care that the signature and OEM id is
     the same as the one provided by BIOS

In ACPI table overriding case you see in dmesg:
   ACPI: Override [DSDT-  BXDSDT], this is unsafe: tainting kernel
   Disabling lock debugging due to kernel taint

In ACPI table adding case you see in dmesg (BGRT table got added):
   ACPI: Add [BGRT-SLIC-WKS], this is unsafe: tainting kernel
   ACPI: BGRT 000000007fffd1ba 000038 (v00 HPQOEM SLIC-WKS 01072009
         INTL 20130823)

Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: hpa@zytor.com
CC: tglx@linutronix.de
CC: ck@conrad-kostecki.de
CC: linux-kernel@vger.kernel.org
CC: x86@kernel.org
CC: mingo@redhat.com
CC: rjw@rjwysocki.net
CC: devel@acpica.org
---
 drivers/acpi/osl.c |   89 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 88 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index fc1aa79..07439b4 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -566,6 +566,8 @@ static const char * const table_sigs[] = {
 
 #define ACPI_OVERRIDE_TABLES 64
 static struct cpio_data __initdata acpi_initrd_files[ACPI_OVERRIDE_TABLES];
+/* Remember physical address of overriden or added tables */
+static acpi_physical_address acpi_table_overridden[ACPI_OVERRIDE_TABLES];
 
 #define MAP_CHUNK_SIZE   (NR_FIX_BTMAPS << PAGE_SHIFT)
 
@@ -715,7 +717,7 @@ acpi_os_physical_table_override(struct acpi_table_header *existing_table,
 	*address = 0;
 	return AE_OK;
 #else
-	int table_offset = 0;
+	int no, table_offset = 0;
 	struct acpi_table_header *table;
 
 	*table_length = 0;
@@ -759,6 +761,12 @@ acpi_os_physical_table_override(struct acpi_table_header *existing_table,
 		*table_length = table->length;
 		acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
 		*address = acpi_tables_addr + table_offset;
+		for (no = 0; no < ACPI_OVERRIDE_TABLES; no++) {
+			if (acpi_table_overridden[no] == 0) {
+				acpi_table_overridden[no] = *address;
+				break;
+			}
+		}
 		break;
 	} while (table_offset + ACPI_HEADER_SIZE < all_tables_size);
 
@@ -768,6 +776,85 @@ acpi_os_physical_table_override(struct acpi_table_header *existing_table,
 #endif
 }
 
+acpi_status
+acpi_os_physical_table_add(acpi_physical_address *address,
+			   u32 *table_length)
+{
+#ifndef CONFIG_ACPI_INITRD_TABLE_OVERRIDE
+	*table_length = 0;
+	*address = 0;
+	return AE_OK;
+#else
+	int no, table_offset = 0;
+	struct acpi_table_header *table;
+
+	*table_length = 0;
+	*address = 0;
+
+	if (!acpi_tables_addr)
+		return AE_OK;
+
+	do {
+		if (table_offset + ACPI_HEADER_SIZE > all_tables_size) {
+			WARN_ON(1);
+			return AE_OK;
+		}
+
+		table = acpi_os_map_memory(acpi_tables_addr + table_offset,
+					   ACPI_HEADER_SIZE);
+
+		if (table_offset + table->length > all_tables_size) {
+			acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
+			WARN_ON(1);
+			return AE_OK;
+		}
+
+		table_offset += table->length;
+
+		/* Do not add SSDTs for now, they might be intended to get
+		   overridden when an SSDT gets loaded dynamically in ACPI
+		   context at any time later */
+		if (!memcmp("SSDT", table->signature, 4)) {
+			acpi_os_unmap_memory(table,
+				     ACPI_HEADER_SIZE);
+			continue;
+		}
+
+		/* Only add tables that have not been overridden already */
+		for (no = 0; no < ACPI_OVERRIDE_TABLES; no++) {
+			if (acpi_table_overridden[no] == 0)
+				break;
+			if (acpi_table_overridden[no] ==
+			    acpi_tables_addr + table_offset - table->length)
+				break;
+		}
+		/* All tables have been added or overridden */
+		if (acpi_table_overridden[no] != 0) {
+			acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
+			continue;
+		}
+		/* Max table override/add limit reached */
+		if (no == ACPI_OVERRIDE_TABLES) {
+			acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
+			return AE_ERROR;
+		}
+
+		table_offset -= table->length;
+		*table_length = table->length;
+		*address = acpi_tables_addr + table_offset;
+		/* do not add this table again */
+		acpi_table_overridden[no] = *address;
+		pr_warn(PREFIX
+			"Add [%4.4s-%8.8s], this is unsafe: tainting kernel\n",
+			table->signature, table->oem_table_id);
+		add_taint(TAINT_OVERRIDDEN_ACPI_TABLE, LOCKDEP_NOW_UNRELIABLE);
+		acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
+		return AE_OK;
+	} while (table_offset + ACPI_HEADER_SIZE < all_tables_size);
+	return AE_OK;
+#endif
+}
+
 static irqreturn_t acpi_irq(int irq, void *dev_id)
 {
 	u32 handled;
-- 
1.7.6.1

Re: [PATCH 1/4] ACPI: Provide support for ACPI table adding via OS

[H. Peter Anvin]

Why can't you add SSDTs? It would be particularly useful.

On February 18, 2014 10:22:40 AM PST, Thomas Renninger <trenn@suse.de> wrote:
>This is done the same way as the previous ACPI physical table override
>mechanism.
>How to override or add tables via initrd, please look up:
>Documentation/acpi/initrd_table_override.txt
>
>SSDTs can only be overridden, not added.
>
>Overriding only happens if the OEM id of the table header matches the
>one
>with the BIOS provided one.
>All table types (SSDTs are an exception), must only show up once.
>So either you:
>- Add a fresh new table for adding of which type (signature) none
>exists
>     in the BIOS  -> OS ACPI table adding happens.
>or
>- Add a table which already exists in BIOS, but the OEM id must match
>the
>one of the table of the same type (signature) that exists in BIOS
>already
>     -> OS ACPI table overriding happens
>     Typically one copies away the original ACPI table, disassembles,
>  modifies (for example adding debug strings), compiles it and provides
>     the table via initrd for overriding (will have the same OEM id).
>     But this is not necessary, one could also come up with a selfmade
>  table for overriding, by taking care that the signature and OEM id is
>     the same as the one provided by BIOS
>
>In ACPI table overriding case you see in dmesg:
>   ACPI: Override [DSDT-  BXDSDT], this is unsafe: tainting kernel
>   Disabling lock debugging due to kernel taint
>
>In ACPI table adding case you see in dmesg (BGRT table got added):
>   ACPI: Add [BGRT-SLIC-WKS], this is unsafe: tainting kernel
>   ACPI: BGRT 000000007fffd1ba 000038 (v00 HPQOEM SLIC-WKS 01072009
>         INTL 20130823)
>
>Signed-off-by: Thomas Renninger <trenn@suse.de>
>CC: hpa@zytor.com
>CC: tglx@linutronix.de
>CC: ck@conrad-kostecki.de
>CC: linux-kernel@vger.kernel.org
>CC: x86@kernel.org
>CC: mingo@redhat.com
>CC: rjw@rjwysocki.net
>CC: devel@acpica.org
>---
>drivers/acpi/osl.c |   89
>+++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 88 insertions(+), 1 deletions(-)
>
>diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
>index fc1aa79..07439b4 100644
>--- a/drivers/acpi/osl.c
>+++ b/drivers/acpi/osl.c
>@@ -566,6 +566,8 @@ static const char * const table_sigs[] = {
> 
> #define ACPI_OVERRIDE_TABLES 64
>static struct cpio_data __initdata
>acpi_initrd_files[ACPI_OVERRIDE_TABLES];
>+/* Remember physical address of overriden or added tables */
>+static acpi_physical_address
>acpi_table_overridden[ACPI_OVERRIDE_TABLES];
> 
> #define MAP_CHUNK_SIZE   (NR_FIX_BTMAPS << PAGE_SHIFT)
> 
>@@ -715,7 +717,7 @@ acpi_os_physical_table_override(struct
>acpi_table_header *existing_table,
> 	*address = 0;
> 	return AE_OK;
> #else
>-	int table_offset = 0;
>+	int no, table_offset = 0;
> 	struct acpi_table_header *table;
> 
> 	*table_length = 0;
>@@ -759,6 +761,12 @@ acpi_os_physical_table_override(struct
>acpi_table_header *existing_table,
> 		*table_length = table->length;
> 		acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
> 		*address = acpi_tables_addr + table_offset;
>+		for (no = 0; no < ACPI_OVERRIDE_TABLES; no++) {
>+			if (acpi_table_overridden[no] == 0) {
>+				acpi_table_overridden[no] = *address;
>+				break;
>+			}
>+		}
> 		break;
> 	} while (table_offset + ACPI_HEADER_SIZE < all_tables_size);
> 
>@@ -768,6 +776,85 @@ acpi_os_physical_table_override(struct
>acpi_table_header *existing_table,
> #endif
> }
> 
>+acpi_status
>+acpi_os_physical_table_add(acpi_physical_address *address,
>+			   u32 *table_length)
>+{
>+#ifndef CONFIG_ACPI_INITRD_TABLE_OVERRIDE
>+	*table_length = 0;
>+	*address = 0;
>+	return AE_OK;
>+#else
>+	int no, table_offset = 0;
>+	struct acpi_table_header *table;
>+
>+	*table_length = 0;
>+	*address = 0;
>+
>+	if (!acpi_tables_addr)
>+		return AE_OK;
>+
>+	do {
>+		if (table_offset + ACPI_HEADER_SIZE > all_tables_size) {
>+			WARN_ON(1);
>+			return AE_OK;
>+		}
>+
>+		table = acpi_os_map_memory(acpi_tables_addr + table_offset,
>+					   ACPI_HEADER_SIZE);
>+
>+		if (table_offset + table->length > all_tables_size) {
>+			acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
>+			WARN_ON(1);
>+			return AE_OK;
>+		}
>+
>+		table_offset += table->length;
>+
>+		/* Do not add SSDTs for now, they might be intended to get
>+		   overridden when an SSDT gets loaded dynamically in ACPI
>+		   context at any time later */
>+		if (!memcmp("SSDT", table->signature, 4)) {
>+			acpi_os_unmap_memory(table,
>+				     ACPI_HEADER_SIZE);
>+			continue;
>+		}
>+
>+		/* Only add tables that have not been overridden already */
>+		for (no = 0; no < ACPI_OVERRIDE_TABLES; no++) {
>+			if (acpi_table_overridden[no] == 0)
>+				break;
>+			if (acpi_table_overridden[no] ==
>+			    acpi_tables_addr + table_offset - table->length)
>+				break;
>+		}
>+		/* All tables have been added or overridden */
>+		if (acpi_table_overridden[no] != 0) {
>+			acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
>+			continue;
>+		}
>+		/* Max table override/add limit reached */
>+		if (no == ACPI_OVERRIDE_TABLES) {
>+			acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
>+			return AE_ERROR;
>+		}
>+
>+		table_offset -= table->length;
>+		*table_length = table->length;
>+		*address = acpi_tables_addr + table_offset;
>+		/* do not add this table again */
>+		acpi_table_overridden[no] = *address;
>+		pr_warn(PREFIX
>+			"Add [%4.4s-%8.8s], this is unsafe: tainting kernel\n",
>+			table->signature, table->oem_table_id);
>+		add_taint(TAINT_OVERRIDDEN_ACPI_TABLE, LOCKDEP_NOW_UNRELIABLE);
>+		acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
>+		return AE_OK;
>+	} while (table_offset + ACPI_HEADER_SIZE < all_tables_size);
>+	return AE_OK;
>+#endif
>+}
>+
> static irqreturn_t acpi_irq(int irq, void *dev_id)
> {
> 	u32 handled;

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: [PATCH 1/4] ACPI: Provide support for ACPI table adding via OS

[Thomas Renninger]

On Tuesday, February 18, 2014 10:27:23 AM H. Peter Anvin wrote:
> Why can't you add SSDTs? It would be particularly useful.

There are 2 ways how ACPI tables get added:
   - Via pointer from a root table (XSDT or RSDT iirc)
   - Via load statement inside of ACPI context when ACPI BIOS
     code gets executed (iirc the physical address is passed).

The latter is only for SSDTs.
The problem is that you if you add an SSDT early, it might
have been intended for overriding when an SSDT gets dynamically
loaded later when the system is up which is particular useful as
well if you want to debug this specific BIOS table.

This could be workarounded via a boot param:
acpi=allow_ssdt_adding
But this is not nice. Maybe someone has a more elegant idea.
Something could still be added if someone is really needing this.

     Thomas

Re: [PATCH 1/4] ACPI: Provide support for ACPI table adding via OS

[H. Peter Anvin]

On 02/18/2014 10:44 AM, Thomas Renninger wrote:
> On Tuesday, February 18, 2014 10:27:23 AM H. Peter Anvin wrote:
>> Why can't you add SSDTs? It would be particularly useful.
> 
> There are 2 ways how ACPI tables get added:
>    - Via pointer from a root table (XSDT or RSDT iirc)
>    - Via load statement inside of ACPI context when ACPI BIOS
>      code gets executed (iirc the physical address is passed).
> 
> The latter is only for SSDTs.
> The problem is that you if you add an SSDT early, it might
> have been intended for overriding when an SSDT gets dynamically
> loaded later when the system is up which is particular useful as
> well if you want to debug this specific BIOS table.
> 
> This could be workarounded via a boot param:
> acpi=allow_ssdt_adding
> But this is not nice. Maybe someone has a more elegant idea.
> Something could still be added if someone is really needing this.

Since adding SSDTs is one of the things I really can imagine one would
do, I think we need to figure out how to do that.  I would think that
overriding would be the exception case.

	-hpa

Re: [PATCH 1/4] ACPI: Provide support for ACPI table adding via OS

[Thomas Renninger]

On Tuesday, February 18, 2014 12:51:07 PM H. Peter Anvin wrote:
> On 02/18/2014 10:44 AM, Thomas Renninger wrote:
> > On Tuesday, February 18, 2014 10:27:23 AM H. Peter Anvin wrote:
> >> Why can't you add SSDTs? It would be particularly useful.
> > 
> > There are 2 ways how ACPI tables get added:
> >    - Via pointer from a root table (XSDT or RSDT iirc)
> >    - Via load statement inside of ACPI context when ACPI BIOS
> >    
> >      code gets executed (iirc the physical address is passed).
> > 
> > The latter is only for SSDTs.
> > The problem is that you if you add an SSDT early, it might
> > have been intended for overriding when an SSDT gets dynamically
> > loaded later when the system is up which is particular useful as
> > well if you want to debug this specific BIOS table.
> > 
> > This could be workarounded via a boot param:
> > acpi=allow_ssdt_adding
> > But this is not nice. Maybe someone has a more elegant idea.
> > Something could still be added if someone is really needing this.
> 
> Since adding SSDTs is one of the things I really can imagine one would
> do, I think we need to figure out how to do that.  I would think that
> overriding would be the exception case.

You can always paste new code into the DSDT. It is effectively the same
than adding a new SSDT table.
The other way around, modifying or deleting broken code in a BIOS
provided SSDT needs overriding.

So in fact adding SSDTs is not necessary at all.
It would be a nice add-on, but it's not even worth introducing
an extra boot param or whatever confusion.
A hint in Documentation that adding additional ASL (ACPI Source Language)
code to the DSDT would be the same than creating and adding a new
SSDT table which is not possible should be enough.

The whole thing will always taint the kernel and is meant for
debugging only anyway.

   Thomas

RE: [Devel] [PATCH 1/4] ACPI: Provide support for ACPI table adding via OS

[Zheng, Lv]

Hi, Thomas

> From: Devel [mailto:devel-bounces@acpica.org] On Behalf Of Thomas Renninger
> Sent: Wednesday, February 19, 2014 7:23 PM
> 
> On Tuesday, February 18, 2014 12:51:07 PM H. Peter Anvin wrote:
> > On 02/18/2014 10:44 AM, Thomas Renninger wrote:
> > > On Tuesday, February 18, 2014 10:27:23 AM H. Peter Anvin wrote:
> > >> Why can't you add SSDTs? It would be particularly useful.
> > >
> > > There are 2 ways how ACPI tables get added:
> > >    - Via pointer from a root table (XSDT or RSDT iirc)
> > >    - Via load statement inside of ACPI context when ACPI BIOS
> > >
> > >      code gets executed (iirc the physical address is passed).
> > >
> > > The latter is only for SSDTs.
> > > The problem is that you if you add an SSDT early, it might
> > > have been intended for overriding when an SSDT gets dynamically
> > > loaded later when the system is up which is particular useful as
> > > well if you want to debug this specific BIOS table.
> > >
> > > This could be workarounded via a boot param:
> > > acpi=allow_ssdt_adding
> > > But this is not nice. Maybe someone has a more elegant idea.
> > > Something could still be added if someone is really needing this.
> >
> > Since adding SSDTs is one of the things I really can imagine one would
> > do, I think we need to figure out how to do that.  I would think that
> > overriding would be the exception case.
> 
> You can always paste new code into the DSDT. It is effectively the same
> than adding a new SSDT table.
> The other way around, modifying or deleting broken code in a BIOS
> provided SSDT needs overriding.
> 
> So in fact adding SSDTs is not necessary at all.
> It would be a nice add-on, but it's not even worth introducing
> an extra boot param or whatever confusion.
> A hint in Documentation that adding additional ASL (ACPI Source Language)
> code to the DSDT would be the same than creating and adding a new
> SSDT table which is not possible should be enough.

IMO, we need to load tables from RSDT/XSDT, they look like "static tables".
Given that we can live in the environment where table reloading is properly implemented by ACPICA, we won't face issues.
And the reloading feature is also required by ACPI specification.
If a table contains same "signature, oem_id, oem_table_id", it could be able to replace the old loaded one if the revision field is greater than the old one.

Actually I'm currently working on the parallel reloading support and all functionalities have been done.
This report is a bit hurry than I expected.
I'll try to prepare fixes (which seems to be dozens of patches) for the testers to validate.

Fortunately, specific to this bug, I don't think the reload requirement must be implemented as the new one doesn't contain a greater revision number.
So there might just be dead lock issues for this bug.

Thanks and best regards
-Lv

> 
> The whole thing will always taint the kernel and is meant for
> debugging only anyway.
> 
>    Thomas
> _______________________________________________
> Devel mailing list
> Devel@acpica.org
> https://lists.acpica.org/mailman/listinfo/devel

RE: [Devel] [PATCH 1/4] ACPI: Provide support for ACPI table adding via OS

[Zheng, Lv]

Hi, Thomas

> From: Devel [mailto:devel-bounces@acpica.org] On Behalf Of Thomas Renninger
> Sent: Wednesday, February 19, 2014 2:44 AM
> 
> On Tuesday, February 18, 2014 10:27:23 AM H. Peter Anvin wrote:
> > Why can't you add SSDTs? It would be particularly useful.
> 
> There are 2 ways how ACPI tables get added:
>    - Via pointer from a root table (XSDT or RSDT iirc)
>    - Via load statement inside of ACPI context when ACPI BIOS
>      code gets executed (iirc the physical address is passed).
> 
> The latter is only for SSDTs.
> The problem is that you if you add an SSDT early, it might
> have been intended for overriding when an SSDT gets dynamically
> loaded later when the system is up which is particular useful as
> well if you want to debug this specific BIOS table.
> 
> This could be workarounded via a boot param:
> acpi=allow_ssdt_adding
> But this is not nice. Maybe someone has a more elegant idea.
> Something could still be added if someone is really needing this.

I'm not sure if you are talking about the issue that:
If a system booted using customized DSDT embedded with SSDT, it also requires dynamic SSDT loading be prevented in ACPICA.

Thanks and best regards
-Lv


> 
>      Thomas
> _______________________________________________
> Devel mailing list
> Devel@acpica.org
> https://lists.acpica.org/mailman/listinfo/devel

[PATCH 2/4] ACPICA: Introduce new acpi_os_physical_table_add OS callback

[Thomas Renninger]

This one allows OS to add arbitrary ACPI tables.

ToDo: It should get checked whether a table with the same signature already
exists and if this is the case, adding should not happen.

Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: hpa@zytor.com
CC: tglx@linutronix.de
CC: ck@conrad-kostecki.de
CC: linux-kernel@vger.kernel.org
CC: x86@kernel.org
CC: mingo@redhat.com
CC: rjw@rjwysocki.net
CC: devel@acpica.org
---
 drivers/acpi/acpica/tbutils.c |   24 ++++++++++++++++++++++++
 include/acpi/acpiosxf.h       |    6 ++++++
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c
index 6412d3c..c763816 100644
--- a/drivers/acpi/acpica/tbutils.c
+++ b/drivers/acpi/acpica/tbutils.c
@@ -453,6 +453,8 @@ static acpi_status acpi_tb_validate_xsdt(acpi_physical_address xsdt_address)
  *
  ******************************************************************************/
 
+#define ACPI_MAX_TABLE_ADD 64
+
 acpi_status __init acpi_tb_parse_root_table(acpi_physical_address rsdp_address)
 {
 	struct acpi_table_rsdp *rsdp;
@@ -623,5 +625,27 @@ acpi_status __init acpi_tb_parse_root_table(acpi_physical_address rsdp_address)
 		}
 	}
 
+	/*
+	 * ACPI Table Add:
+	 * Allow the OS to add additional tables to the global root table list
+	 */
+	for (i = 0; i < ACPI_MAX_TABLE_ADD; i++) {
+		int tmp;
+		table_entry_size = 0;
+		address = 0;
+		status = acpi_os_physical_table_add(&address,
+						    &table_entry_size);
+		if (status == AE_OK && table_entry_size && address) {
+			table = acpi_os_map_memory(address, table_entry_size);
+			ACPI_INFO((AE_INFO, "Add OS provided table:"));
+			acpi_tb_print_table_header(address, table);
+			status = acpi_tb_store_table(address,
+						     table,
+						     table_entry_size,
+						     ACPI_TABLE_ORIGIN_MAPPED,
+						     &tmp);
+		} else
+			break;
+	}
 	return_ACPI_STATUS(AE_OK);
 }
diff --git a/include/acpi/acpiosxf.h b/include/acpi/acpiosxf.h
index 01e6c6d..70c00ed 100644
--- a/include/acpi/acpiosxf.h
+++ b/include/acpi/acpiosxf.h
@@ -111,6 +111,12 @@ acpi_os_physical_table_override(struct acpi_table_header *existing_table,
 				u32 *new_table_length);
 #endif
 
+#ifndef ACPI_USE_ALTERNATE_PROTOTYPE_acpi_os_physical_table_add
+acpi_status
+acpi_os_physical_table_add(acpi_physical_address * new_address,
+			   u32 *new_table_length);
+#endif
+
 /*
  * Spinlock primitives
  */
-- 
1.7.6.1

[PATCH 3/4] ACPICA: Add BGRT signature to known signatures

[Thomas Renninger]

In Linux there even exists a driver already making use of this table:
drivers/acpi/bgrt.c:MODULE_DESCRIPTION("BGRT boot graphic support");

Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: hpa@zytor.com
CC: tglx@linutronix.de
CC: ck@conrad-kostecki.de
CC: linux-kernel@vger.kernel.org
CC: x86@kernel.org
CC: mingo@redhat.com
CC: rjw@rjwysocki.net
CC: devel@acpica.org
---
 include/acpi/actbl2.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index 094a906..9ed1c20 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -83,6 +83,7 @@
 #define ACPI_SIG_WDAT           "WDAT"	/* Watchdog Action Table */
 #define ACPI_SIG_WDDT           "WDDT"	/* Watchdog Timer Description Table */
 #define ACPI_SIG_WDRT           "WDRT"	/* Watchdog Resource Table */
+#define ACPI_SIG_BGRT           "BGRT"  /* Boot Graphic Support */
 
 #ifdef ACPI_UNDEFINED_TABLES
 /*
-- 
1.7.6.1

[PATCH 4/4] ACPI: Add new table signatures that can be overridden/added.

[Thomas Renninger]

Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: hpa@zytor.com
CC: tglx@linutronix.de
CC: ck@conrad-kostecki.de
CC: linux-kernel@vger.kernel.org
CC: x86@kernel.org
CC: mingo@redhat.com
CC: rjw@rjwysocki.net
CC: devel@acpica.org
---
 drivers/acpi/osl.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 07439b4..deba2f0 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -38,6 +38,7 @@
 #include <linux/delay.h>
 #include <linux/workqueue.h>
 #include <linux/nmi.h>
+# define ACPI_UNDEFINED_TABLES 1
 #include <linux/acpi.h>
 #include <linux/efi.h>
 #include <linux/ioport.h>
@@ -559,7 +560,8 @@ static const char * const table_sigs[] = {
 	ACPI_SIG_IBFT, ACPI_SIG_IVRS, ACPI_SIG_MCFG, ACPI_SIG_MCHI,
 	ACPI_SIG_SLIC, ACPI_SIG_SPCR, ACPI_SIG_SPMI, ACPI_SIG_TCPA,
 	ACPI_SIG_UEFI, ACPI_SIG_WAET, ACPI_SIG_WDAT, ACPI_SIG_WDDT,
-	ACPI_SIG_WDRT, ACPI_SIG_DSDT, ACPI_SIG_FADT, ACPI_SIG_PSDT,
+	ACPI_SIG_WDRT, ACPI_SIG_BGRT, ACPI_SIG_ATKG, ACPI_SIG_GSCI,
+	ACPI_SIG_IEIT, ACPI_SIG_DSDT, ACPI_SIG_FADT, ACPI_SIG_PSDT,
 	ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, NULL };
 
 #define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)
-- 
1.7.6.1

RE: [Devel] ACPI: Also allow ACPI table adding via initrd not only overriding

[Moore, Robert]

acpi_load_table won't work?



> -----Original Message-----
> From: Devel [mailto:devel-bounces@acpica.org] On Behalf Of Thomas
> Renninger
> Sent: Tuesday, February 18, 2014 10:23 AM
> Cc: x86@kernel.org; ck@conrad-kostecki.de; linux-kernel@vger.kernel.org;
> mingo@redhat.com; hpa@zytor.com; tglx@linutronix.de; devel@acpica.org
> Subject: [Devel] ACPI: Also allow ACPI table adding via initrd not only
> overriding
> 
> The ACPICA patches have to go into separate acpica repository first.
> It should also be checked in acpica whether the table signature the OS
> likes to add already exists (from BIOS). In this case the table must not
> be added.
> 
> Worked here by trying to override a DSDT and addind a BGRT table.
> 
>      Thomas
> 
> _______________________________________________
> Devel mailing list
> Devel@acpica.org
> https://lists.acpica.org/mailman/listinfo/devel

Re: [Devel] ACPI: Also allow ACPI table adding via initrd not only overriding

[Thomas Renninger]

On Tuesday, February 18, 2014 06:38:45 PM Moore, Robert wrote:
> acpi_load_table won't work?

I guess not, there is:
        /* Must acquire the interpreter lock during this operation */
        status = acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER);

So the interpreter must be running already?
That would mean the adding can only happen much later.
This probably would eleminate most use cases for adding arbitrary
ACPI tables. Most tables (beside DSDT and SSDT) are needed really
early, otherwise the info could have been added as AML as well.

    Thomas 
 
> > -----Original Message-----
> > From: Devel [mailto:devel-bounces@acpica.org] On Behalf Of Thomas
> > Renninger
> > Sent: Tuesday, February 18, 2014 10:23 AM
> > Cc: x86@kernel.org; ck@conrad-kostecki.de; linux-kernel@vger.kernel.org;
> > mingo@redhat.com; hpa@zytor.com; tglx@linutronix.de; devel@acpica.org
> > Subject: [Devel] ACPI: Also allow ACPI table adding via initrd not only
> > overriding
> > 
> > The ACPICA patches have to go into separate acpica repository first.
> > It should also be checked in acpica whether the table signature the OS
> > likes to add already exists (from BIOS). In this case the table must not
> > be added.
> > 
> > Worked here by trying to override a DSDT and addind a BGRT table.
> > 
> >      Thomas
> > 
> > _______________________________________________
> > Devel mailing list
> > Devel@acpica.org
> > https://lists.acpica.org/mailman/listinfo/devel

RE: [Devel] ACPI: Also allow ACPI table adding via initrd not only overriding

[Moore, Robert]

Maybe not exactly "running", but at the very least, ACPICA must be initialized.

All of this of course depends on how early the table needs to be loaded.


> -----Original Message-----
> From: Thomas Renninger [mailto:trenn@suse.de]
> Sent: Tuesday, February 18, 2014 10:53 AM
> To: Moore, Robert
> Cc: x86@kernel.org; ck@conrad-kostecki.de; linux-kernel@vger.kernel.org;
> mingo@redhat.com; hpa@zytor.com; tglx@linutronix.de; devel@acpica.org
> Subject: Re: [Devel] ACPI: Also allow ACPI table adding via initrd not
> only overriding
> 
> On Tuesday, February 18, 2014 06:38:45 PM Moore, Robert wrote:
> > acpi_load_table won't work?
> 
> I guess not, there is:
>         /* Must acquire the interpreter lock during this operation */
>         status = acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER);
> 
> So the interpreter must be running already?
> That would mean the adding can only happen much later.
> This probably would eleminate most use cases for adding arbitrary ACPI
> tables. Most tables (beside DSDT and SSDT) are needed really early,
> otherwise the info could have been added as AML as well.
> 
>     Thomas
> 
> > > -----Original Message-----
> > > From: Devel [mailto:devel-bounces@acpica.org] On Behalf Of Thomas
> > > Renninger
> > > Sent: Tuesday, February 18, 2014 10:23 AM
> > > Cc: x86@kernel.org; ck@conrad-kostecki.de;
> > > linux-kernel@vger.kernel.org; mingo@redhat.com; hpa@zytor.com;
> > > tglx@linutronix.de; devel@acpica.org
> > > Subject: [Devel] ACPI: Also allow ACPI table adding via initrd not
> > > only overriding
> > >
> > > The ACPICA patches have to go into separate acpica repository first.
> > > It should also be checked in acpica whether the table signature the
> > > OS likes to add already exists (from BIOS). In this case the table
> > > must not be added.
> > >
> > > Worked here by trying to override a DSDT and addind a BGRT table.
> > >
> > >      Thomas
> > >
> > > _______________________________________________
> > > Devel mailing list
> > > Devel@acpica.org
> > > https://lists.acpica.org/mailman/listinfo/devel

Re: [Devel] ACPI: Also allow ACPI table adding via initrd not only overriding

[Thomas Renninger]

On Tuesday, February 18, 2014 07:59:17 PM Moore, Robert wrote:
> Maybe not exactly "running", but at the very least, ACPICA must be
> initialized.
> 
> All of this of course depends on how early the table needs to be loaded.

I'd say as early as possible.
Not sure about Thomas' use case.
I expect most of the extra tables are needed before ACPICA gets
initialized otherwise it could have been specified to put the info
into DSDT/SSDT via ASL.
Sooner or later people will hit the "I need it earlier" limit and
patch:
ACPICA: Introduce new acpi_os_physical_table_add OS callback
shows that it can be done early and that it integrates nicely
with only some additional lines.

   Thomas

Re: [Devel] ACPI: Also allow ACPI table adding via initrd not only overriding

[Thomas Gleixner]

On Wed, 19 Feb 2014, Thomas Renninger wrote:

> On Tuesday, February 18, 2014 07:59:17 PM Moore, Robert wrote:
> > Maybe not exactly "running", but at the very least, ACPICA must be
> > initialized.
> > 
> > All of this of course depends on how early the table needs to be loaded.
> 
> I'd say as early as possible.
> Not sure about Thomas' use case.

The case is a BIOS with complete lack of ACPI tables. So we have no
data about IOAPIC, HPET and other stuff.

The current acpi_initrd_override() call is sufficient, because its
called before acpi_boot_table_init(), which is the first function
accessing any of the tables.

Thanks,

	tglx

AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Conrad Kostecki]

> On 02/14/2014 10:13 AM, Conrad Kostecki wrote:
> >>
> >> Does it have DMI?
> >
> > Unfortunately not.
> >
> > # dmidecode 2.12
> > # No SMBIOS nor DMI entry point found, sorry.
> >
> 
> Sigh.  Does anyone have contacts at Soekris who can complain about this
> stuff?

I don't think, that Soekris will fix this. No model of Soekris ever had implemented DMI.
Their BIOS (called comBIOS) is completely written by them. Output is via serial port only.
At least I know, that the technical engineers at Soekris respond on sales@soekris.com.

Maybe the patch could be extended, that HPET would be only enabled if there is no ACPI present?

Re: AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Eric Sesterhenn]

Hello Conrad,

On 02/14/2014 07:28 PM, Conrad Kostecki wrote:
>> On 02/14/2014 10:13 AM, Conrad Kostecki wrote:
>>>>
>>>> Does it have DMI?
>>>
>>> Unfortunately not.
>>>
>>> # dmidecode 2.12
>>> # No SMBIOS nor DMI entry point found, sorry.
>>>
>>
>> Sigh.  Does anyone have contacts at Soekris who can 
>> complain about this stuff?
> 
> I don't think, that Soekris will fix this. No model of Soekris ever
> had implemented DMI. Their BIOS (called comBIOS) is completely written
> by them. Output is via serial port only. 
> At least I know, that the technical engineers at Soekris respond on 
> sales@soekris.com.
> 
> Maybe the patch could be extended, that HPET would be only enabled if 
> there is no ACPI present?
we are facing the same issue with these systems. Maybe the following patch,
which is based on yours, would be acceptable for mainline.

Best regards,
Eric Sesterhenn


This patch enables a quirk for the Soekris net6501 HPET if
pciquirks=soekris_e6xx" is supplied at the kernel commandline,
Without these patches the clocksource defaults to jiffies, which
is unstable.

Signed-off-by: Eric Sesterhenn <eric.sesterhenn@lsexperts.de>

diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index ff898bb..7c3faf5 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -6,6 +6,25 @@

 #include <asm/hpet.h>

+static int pciquirk_soekris;
+
+static int __init parse_pciquirks(char *str)
+{
+
+	while (str) {
+		char *next = strchr(str, ',');
+
+		if (next)
+			*next++ = 0;
+		if (!strncmp("soekris_e6xx", str, 12))
+			pciquirk_soekris = 1;
+		str = next;
+	}
+        return 1;
+}
+__setup("pciquirks=", parse_pciquirks);
+
+
 #if defined(CONFIG_X86_IO_APIC) && defined(CONFIG_SMP) && defined(CONFIG_PCI)

 static void quirk_intel_irqbalance(struct pci_dev *dev)
@@ -498,6 +517,28 @@ void force_hpet_resume(void)
 }

 /*
+ * Soekris net6501, based on Atom E6xx series, does not have ACPI.
+ * HPET should be force enabled on such platforms.
+ */
+static void e6xx_force_enable_hpet(struct pci_dev *dev)
+{
+	if (hpet_address || force_hpet_address)
+		return;
+
+	if (pciquirk_soekris != 1)
+		return;
+
+	force_hpet_address = 0xFED00000;
+	force_hpet_resume_type = NONE_FORCE_HPET_RESUME;
+	dev_printk(KERN_DEBUG, &dev->dev, "Force enabled HPET at "
+		"0x%lx\n", force_hpet_address);
+	return;
+}
+
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E6XX_CU,
+			 e6xx_force_enable_hpet);
+
+/*
  * HPET MSI on some boards (ATI SB700/SB800) has side effect on
  * floppy DMA. Disable HPET MSI on such platforms.
  * See erratum #27 (Misinterpreted MSI Requests May Result in
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6ed0bb7..aa0d390 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2860,6 +2860,7 @@
 #define PCI_DEVICE_ID_INTEL_82372FB_1	0x7601
 #define PCI_DEVICE_ID_INTEL_SCH_LPC	0x8119
 #define PCI_DEVICE_ID_INTEL_SCH_IDE	0x811a
+#define PCI_DEVICE_ID_INTEL_E6XX_CU	0x8183
 #define PCI_DEVICE_ID_INTEL_ITC_LPC	0x8186
 #define PCI_DEVICE_ID_INTEL_82454GX	0x84c4
 #define PCI_DEVICE_ID_INTEL_82450GX	0x84c5

Re: AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Thomas Gleixner]

On Tue, 9 Sep 2014, Eric Sesterhenn wrote:
> On 02/14/2014 07:28 PM, Conrad Kostecki wrote:
> This patch enables a quirk for the Soekris net6501 HPET if
> pciquirks=soekris_e6xx" is supplied at the kernel commandline,
> Without these patches the clocksource defaults to jiffies, which
> is unstable.
> 
> Signed-off-by: Eric Sesterhenn <eric.sesterhenn@lsexperts.de>
> 
> diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
> index ff898bb..7c3faf5 100644
> --- a/arch/x86/kernel/quirks.c
> +++ b/arch/x86/kernel/quirks.c
> @@ -6,6 +6,25 @@
> 
>  #include <asm/hpet.h>
> 
> +static int pciquirk_soekris;
> +
> +static int __init parse_pciquirks(char *str)
> +{
> +
> +	while (str) {
> +		char *next = strchr(str, ',');
> +
> +		if (next)
> +			*next++ = 0;
> +		if (!strncmp("soekris_e6xx", str, 12))
> +			pciquirk_soekris = 1;
> +		str = next;
> +	}
> +        return 1;
> +}
> +__setup("pciquirks=", parse_pciquirks);

Eew. No, we really can do without random new quirk interfaces.

>  #if defined(CONFIG_X86_IO_APIC) && defined(CONFIG_SMP) && defined(CONFIG_PCI)
> 
>  static void quirk_intel_irqbalance(struct pci_dev *dev)
> @@ -498,6 +517,28 @@ void force_hpet_resume(void)
>  }
> 
>  /*
> + * Soekris net6501, based on Atom E6xx series, does not have ACPI.
> + * HPET should be force enabled on such platforms.
> + */
> +static void e6xx_force_enable_hpet(struct pci_dev *dev)
> +{
> +	if (hpet_address || force_hpet_address)
> +		return;
> +
> +	if (pciquirk_soekris != 1)
> +		return;

Thinking more about it, this is really not necessary.

@hpa: You asked whether this might affect any other e6xx devices.

According to the atom e6xx-series datasheet the HPET is non optional
and always memory mapped to 0xfed00000. I don't see how that would
harm any machine which has the hpet proper advertised via ACPI.

Thanks,

	tglx

> +
> +	force_hpet_address = 0xFED00000;
> +	force_hpet_resume_type = NONE_FORCE_HPET_RESUME;
> +	dev_printk(KERN_DEBUG, &dev->dev, "Force enabled HPET at "
> +		"0x%lx\n", force_hpet_address);
> +	return;
> +}
> +
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E6XX_CU,
> +			 e6xx_force_enable_hpet);

Re: AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[H. Peter Anvin]

On 09/09/2014 07:54 AM, Thomas Gleixner wrote:
> 
> @hpa: You asked whether this might affect any other e6xx devices.
> 
> According to the atom e6xx-series datasheet the HPET is non optional
> and always memory mapped to 0xfed00000. I don't see how that would
> harm any machine which has the hpet proper advertised via ACPI.
> 

That seems straightforward then.

I still wish someone would take a cluebat to Soekris.  We keep hearing
crap like this about their firmware over and over and over again.  It
isn't like you can't get EDK2 or Coreboot and build a BIOS based mostly
on Open Source components these days... oh, wait.

	-hpa

Re: AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Thomas Gleixner]

On Tue, 9 Sep 2014, H. Peter Anvin wrote:

> On 09/09/2014 07:54 AM, Thomas Gleixner wrote:
> > 
> > @hpa: You asked whether this might affect any other e6xx devices.
> > 
> > According to the atom e6xx-series datasheet the HPET is non optional
> > and always memory mapped to 0xfed00000. I don't see how that would
> > harm any machine which has the hpet proper advertised via ACPI.
> > 
> 
> That seems straightforward then.
> 
> I still wish someone would take a cluebat to Soekris.  We keep hearing
> crap like this about their firmware over and over and over again.  It
> isn't like you can't get EDK2 or Coreboot and build a BIOS based mostly
> on Open Source components these days... oh, wait.

You can, but I have a non soekris e6xx platform with a BLDK based BIOS
which lacks ACPI and some other features....

Re: AW: AW: AW: [PATCH] x86: HPET force enable for Soekris net6501

[Eric Sesterhenn]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

hi,

On 09/09/2014 05:26 PM, H. Peter Anvin wrote:
> On 09/09/2014 07:54 AM, Thomas Gleixner wrote:
>>
>> @hpa: You asked whether this might affect any other e6xx devices.
>>
>> According to the atom e6xx-series datasheet the HPET is non optional
>> and always memory mapped to 0xfed00000. I don't see how that would
>> harm any machine which has the hpet proper advertised via ACPI.
>>
> 
> That seems straightforward then.

this means the original patch written by Conrad is going to be applied?
Is there anything we can do to help regarding this issue?

> I still wish someone would take a cluebat to Soekris.  We keep hearing
> crap like this about their firmware over and over and over again.  It
> isn't like you can't get EDK2 or Coreboot and build a BIOS based mostly
> on Open Source components these days... oh, wait.

I have send them another message regarding this issue, but so far
they did not respond. In the past their responsiveness also varied a lot
according to my collegue.


Regards, Eric

-- 
LSE Leading Security Experts GmbH, Postfach 100121, 64201 Darmstadt
Unternehmenssitz: Weiterstadt, Amtsgericht Darmstadt: HRB8649
Geschäftsführer: Oliver Michel, Sven Walther


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4011 bytes --]

Re: [PATCH] x86: HPET force enable for Soekris net6501

[Thomas Gleixner]

On Fri, 12 Sep 2014, Eric Sesterhenn wrote:
> On 09/09/2014 05:26 PM, H. Peter Anvin wrote:
> > On 09/09/2014 07:54 AM, Thomas Gleixner wrote:
> >>
> >> @hpa: You asked whether this might affect any other e6xx devices.
> >>
> >> According to the atom e6xx-series datasheet the HPET is non optional
> >> and always memory mapped to 0xfed00000. I don't see how that would
> >> harm any machine which has the hpet proper advertised via ACPI.
> >>
> > 
> > That seems straightforward then.
> 
> this means the original patch written by Conrad is going to be applied?
> Is there anything we can do to help regarding this issue?

Yes, it needs some massaging.

> Subject: [PATCH] x86: HPET force enable for Soekris net6501

This change is not soekris specific. It enables the force mechanism
for all e6xx based systems.

> Original patch by Peter Neubauer, slightly modified by me.
> -> http://www.mail-archive.com/soekris-tech@lists.soekris.com/msg06462.html

> Signed-off-by: Peter Neubauer <pneubauer@bluerwhite.org>

I can't see a SOB from Peter in his post on the soekris list, but he's
clearly the original author. So the patch is missing a From: .... line
at the top of the mail body.

> Signed-off-by: Conrad Kostecki <ck@conrad-kostecki.de>

--- a/arch/x86/kernel/quirks.c	2014-02-14 11:13:27.703432732 +0100
+++ b/arch/x86/kernel/quirks.c	2014-02-14 11:14:32.327496474 +0100
@@ -498,6 +498,25 @@ void force_hpet_resume(void)
 }
 
>  /*
> + * Soekris net6501, based on Atom E6xx series, does not have ACPI.
> + * HPET should be force enabled on such platforms.
> + */

Again this is not soekris specific. We rather want an explanation WHY
it is safe to do so, e.g. something like:

/*
 * According to datasheet e6xx systems have the HPET hardwired to
 * 0xfed00000
 */

That's the information we need and which avoids questions about the
correctness of the approach. Its clear that ACPI did not populate HPET
if hpet_address is 0.

> +static void e6xx_force_enable_hpet(struct pci_dev *dev)
> +{
> +	if (hpet_address || force_hpet_address)
> +		return;
> +
> +	force_hpet_address = 0xFED00000;
> +	force_hpet_resume_type = NONE_FORCE_HPET_RESUME;
> +	dev_printk(KERN_DEBUG, &dev->dev, "Force enabled HPET at "
> +		"0x%lx\n", force_hpet_address);
> +	return;
> +}
> +

Remove the new line please.

> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E6XX_CU,
> +			 e6xx_force_enable_hpet);

Thanks,

	tglx

[PATCH] x86: HPET force enable for e6xx based systems

[Eric Sesterhenn]

From: Peter Neubauer <pneubauer@bluerwhite.org>

as the Soekris net6501 and other e6xx based systems do not have
any ACPI implementation, HPET won't get enabled.
This patch enables HPET on such platforms.

[    0.430149] pci 0000:00:01.0: Force enabled HPET at 0xfed00000
[    0.644838] HPET: 3 timers in total, 0 timers will be used for per-cpu timer

Original patch by Peter Neubauer (http://www.mail-archive.com/soekris-tech@lists.soekris.com/msg06462.html)
slightly modified by Conrad Kostecki <ck@conrad-kostecki.de> and massaged
accoring to Thomas Gleixners <tglx@linutronix.de> by me.

Signed-off-by: Eric Sesterhenn <eric.sesterhenn@lsexperts.de>

---
I am not quite sure how to include Conrad in the tags and if the
Suggested-by tag would be the right way to do this, therefore I have
included him in the description.
The patch is against Linux current git.

diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index ff898bb..176a0f9 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -498,6 +498,24 @@ void force_hpet_resume(void)
 }

 /*
+ * According to the datasheet e6xx systems have the HPET hardwired to
+ * 0xfed00000
+ */
+static void e6xx_force_enable_hpet(struct pci_dev *dev)
+{
+	if (hpet_address || force_hpet_address)
+		return;
+
+	force_hpet_address = 0xFED00000;
+	force_hpet_resume_type = NONE_FORCE_HPET_RESUME;
+	dev_printk(KERN_DEBUG, &dev->dev, "Force enabled HPET at "
+		"0x%lx\n", force_hpet_address);
+	return;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E6XX_CU,
+			 e6xx_force_enable_hpet);
+
+/*
  * HPET MSI on some boards (ATI SB700/SB800) has side effect on
  * floppy DMA. Disable HPET MSI on such platforms.
  * See erratum #27 (Misinterpreted MSI Requests May Result in
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6ed0bb7..aa0d390 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2860,6 +2860,7 @@
 #define PCI_DEVICE_ID_INTEL_82372FB_1	0x7601
 #define PCI_DEVICE_ID_INTEL_SCH_LPC	0x8119
 #define PCI_DEVICE_ID_INTEL_SCH_IDE	0x811a
+#define PCI_DEVICE_ID_INTEL_E6XX_CU	0x8183
 #define PCI_DEVICE_ID_INTEL_ITC_LPC	0x8186
 #define PCI_DEVICE_ID_INTEL_82454GX	0x84c4
 #define PCI_DEVICE_ID_INTEL_82450GX	0x84c5

[tip:x86/platform] x86: HPET force enable for e6xx based systems

[tip-bot for Peter Neubauer]

Commit-ID:  2e151c70dfb0075ff83bec305c52a9da1ba49089
Gitweb:     http://git.kernel.org/tip/2e151c70dfb0075ff83bec305c52a9da1ba49089
Author:     Peter Neubauer <pneubauer@bluerwhite.org>
AuthorDate: Fri, 12 Sep 2014 13:06:13 +0200
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Mon, 15 Sep 2014 17:53:35 -0700

x86: HPET force enable for e6xx based systems

As the Soekris net6501 and other e6xx based systems do not have
any ACPI implementation, HPET won't get enabled.
This patch enables HPET on such platforms.

[    0.430149] pci 0000:00:01.0: Force enabled HPET at 0xfed00000
[    0.644838] HPET: 3 timers in total, 0 timers will be used for per-cpu timer

Original patch by Peter Neubauer (http://www.mail-archive.com/soekris-tech@lists.soekris.com/msg06462.html)
slightly modified by Conrad Kostecki <ck@conrad-kostecki.de> and massaged
accoring to Thomas Gleixners <tglx@linutronix.de> by me.

Suggested-by: Conrad Kostecki <ck@conrad-kostecki.de>
Signed-off-by: Eric Sesterhenn <eric.sesterhenn@lsexperts.de>
Cc: Peter Neubauer <pneubauer@bluerwhite.org>
Link: http://lkml.kernel.org/r/5412D3A5.2030909@lsexperts.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

---
 arch/x86/kernel/quirks.c | 18 ++++++++++++++++++
 include/linux/pci_ids.h  |  1 +
 2 files changed, 19 insertions(+)

diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index ff898bb..176a0f9 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -498,6 +498,24 @@ void force_hpet_resume(void)
 }
 
 /*
+ * According to the datasheet e6xx systems have the HPET hardwired to
+ * 0xfed00000
+ */
+static void e6xx_force_enable_hpet(struct pci_dev *dev)
+{
+	if (hpet_address || force_hpet_address)
+		return;
+
+	force_hpet_address = 0xFED00000;
+	force_hpet_resume_type = NONE_FORCE_HPET_RESUME;
+	dev_printk(KERN_DEBUG, &dev->dev, "Force enabled HPET at "
+		"0x%lx\n", force_hpet_address);
+	return;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E6XX_CU,
+			 e6xx_force_enable_hpet);
+
+/*
  * HPET MSI on some boards (ATI SB700/SB800) has side effect on
  * floppy DMA. Disable HPET MSI on such platforms.
  * See erratum #27 (Misinterpreted MSI Requests May Result in
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6ed0bb7..aa0d390 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2860,6 +2860,7 @@
 #define PCI_DEVICE_ID_INTEL_82372FB_1	0x7601
 #define PCI_DEVICE_ID_INTEL_SCH_LPC	0x8119
 #define PCI_DEVICE_ID_INTEL_SCH_IDE	0x811a
+#define PCI_DEVICE_ID_INTEL_E6XX_CU	0x8183
 #define PCI_DEVICE_ID_INTEL_ITC_LPC	0x8186
 #define PCI_DEVICE_ID_INTEL_82454GX	0x84c4
 #define PCI_DEVICE_ID_INTEL_82450GX	0x84c5