On Fri, Apr 6, 2018 at 7:47 AM, Alan Cox wrote:
>> But we don't have the full ACPI interpreter up in the early part of
>> the kernel. All these 'early' devices have their own setup/config
>> which is the source of the issue. Or maybe I am wrong about the full
>> interpreter and the early drivers a
On Thu, Mar 29, 2018 at 6:34 AM, Alan Cox wrote:
> On Mon, 26 Mar 2018 20:56:45 -0600
> Aaron Durbin wrote:
>
>> On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox
>> wrote:
>> >> Sadly, this situation
>> >> is not unique to this hardware. There is h
On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox wrote:
>> Sadly, this situation
>> is not unique to this hardware. There is hardware all over that does
>> not meet the current assumptions being made in the early uart drivers
>> within the kernel.
>
> Is there any fundamental reason you can't just embed
On Wed, Mar 14, 2018 at 10:38 AM, Andy Shevchenko
wrote:
> On Wed, Mar 14, 2018 at 6:29 PM, Daniel Kurtz wrote:
>> On Wed, Mar 14, 2018 at 4:54 AM Ricardo Ribalda Delgado <
>> ricardo.riba...@gmail.com> wrote:
>>> On Wed, Mar 14, 2018 at 1:36 AM, Daniel Kurtz
>> wrote:
>
>> In fact, the recommen
On Sat, Mar 3, 2018 at 8:56 AM, Andy Shevchenko
wrote:
> On Fri, Mar 2, 2018 at 8:35 PM, Daniel Kurtz wrote:
>> On Thu, Mar 1, 2018 at 1:02 PM Andy Shevchenko
>> wrote:
>>> On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz wrote:
>>> > On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko <
>> andy.shevch
On Sat, Mar 3, 2018 at 8:38 AM, Andy Shevchenko
wrote:
> On Thu, Mar 1, 2018 at 11:24 PM, Aaron Durbin wrote:
>> On Thu, Mar 1, 2018 at 1:02 PM, Andy Shevchenko
>> wrote:
>>> On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz wrote:
>>>> On Thu, Mar 1, 2018 at
On Thu, Mar 1, 2018 at 1:02 PM, Andy Shevchenko
wrote:
> On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz wrote:
>> On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko
>> wrote:
>
>> "earlycon simply does not utilize the information".
>>
>> earlycon parses iotype, mapbase and baud (from options). Howev
lags = dev->of_node ? 0 : IRQF_TRIGGER_FALLING;
> + irqflags = irq_get_trigger_type(client->irq);
> + if (!irqflags)
> + irqflags = IRQF_TRIGGER_FALLING;
>
> error = devm_request_threaded_irq(dev, client->irq, NULL, elan_isr,
> irqflags | IRQF_ONESHOT,
> --
> 2.14.2.822.g60be5d43e6-goog
Reviewed-by: Aaron Durbin
On 8/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 8 Aug 2007 16:17:19 -0700
> Aaron Durbin <[EMAIL PROTECTED]> wrote:
>
> > In setup_APIC_timer with the HPET in use, a condition can arise while
> > waiting for the next irq slice to expire on the HPET w
ignals the
end of the tick slice.
Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]>
---
This time w/ the 'Signed-off-by' line. I swear I am not trying to spam.
diff --git a/arch/x86_64/kernel/apic.c b/arch/x86_64/kernel/apic.c
index 900ff38..06797e2 100644
--- a/arch/x86_64/kerne
On 8/8/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Thursday 09 August 2007 01:17:19 Aaron Durbin wrote:
> > In setup_APIC_timer with the HPET in use, a condition can arise while
> > waiting for the next irq slice to expire on the HPET which will either
> > cause an
In setup_APIC_timer with the HPET in use, a condition can arise while
waiting for the next irq slice to expire on the HPET which will either
cause an NMI watchdog to fire or a 3 minute busy loop if the NMI
watchdog is disabled.
The HPET comparator and the counter keep incrementing during its norma
In setup_APIC_timer with the HPET in use, a condition can arise while
waiting for the next irq slice to expire on the HPET which will either
cause an NMI watchdog to fire or a 3 minute busy loop if the NMI
watchdog is disabled.
The HPET comparator and the counter keep incrementing during its norma
On 7/17/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Tuesday 17 July 2007 17:08:19 Aaron Durbin wrote:
> This is true if SMIs are still flowing, and the SMI handler correctly handles
> the reset properly. I have seen cases where the SMI handler is broken which
> causes the system
On 7/17/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Monday 16 July 2007 20:02:21 Aaron Durbin wrote:
>
> Make ACPI be the default reset method for x86_64. If the reset mechanism fails
> using ACPI, it will default to using the keyboard controller.
Again why?
You really can
On 7/17/07, Yinghai Lu <[EMAIL PROTECTED]> wrote:
On 7/17/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Monday 16 July 2007 20:00:19 Aaron Durbin wrote:
> >
> > Add the ability to reset the machine using the RESET_REG in ACPI's FADT
table.
>
> Wh
On 7/17/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Monday 16 July 2007 20:00:19 Aaron Durbin wrote:
>
> Add the ability to reset the machine using the RESET_REG in ACPI's FADT table.
Why? I had such a patch at some point as experiment, but it never
helped actually fix a bo
On 7/16/07, Shaohua Li <[EMAIL PROTECTED]> wrote:
On Tue, 2007-07-17 at 02:00 +0800, Aaron Durbin wrote:
>
> Add the ability to reset the machine using the RESET_REG in ACPI's
> FADT table.
We could have another command for 'reboot' kernel command line.
I di
On 7/16/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Mon, 2007-07-16 at 11:00 -0700, Aaron Durbin wrote:
> Add the ability to reset the machine using the RESET_REG in ACPI's FADT table.
>
> Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]>
> ---
>
> d
Make ACPI be the default reset method for x86_64. If the reset mechanism fails
using ACPI, it will default to using the keyboard controller.
Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]>
---
This patch relies on the ACPI reboot mechanism patch.
diff --git a/Documentation/x86_6
Add the ability to reboot an x86_64 based machine using the RESET_REG in the
FADT ACPI table.
Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]>
This patch relies on the ACPI reboot mechanism patch.
diff --git a/Documentation/x86_64/boot-options.txt
b/Documentation/x86_64/boot-optio
Add the ability to reset the machine using the RESET_REG in ACPI's FADT table.
Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]>
---
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index d4336f1..c9906a5 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@
On 7/6/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Friday 06 July 2007 00:27:24 Aaron Durbin wrote:
>
> Insert HPET resources after pci probing has been completed in order to avoid
> resource conflicts with PCI resource reservation. With this change the
> HPET firmware
enumeration cannot reserve the resources.
Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]>
---
arch/i386/kernel/acpi/boot.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/i386/kernel/acpi/boot.c b/arch/i386/kernel/acpi/boot.c
On 5/16/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Wed, 16 May 2007 09:09:11 -0700 Aaron Durbin <[EMAIL PROTECTED]> wrote:
> Strip __cpuinit[data] from Node <-> PXM routines and supporting data
structures.
> Also make pxm_to_node_map and node_to_pxm_map local
ured w/ CONFIG_HOTPLUG_CPU=n
- cat /sys/devices/system/node/node*/distance
This will cause an oops by calling into a freed memory section.
In particular, on x86_64, __node_distance calls node_to_pxm().
Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]>
---
diff --git a/drivers/acpi/numa.c b/drivers/acpi/
.
Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]>
---
Updated to reflect comments from [EMAIL PROTECTED]
diff --git a/arch/i386/pci/mmconfig-shared.c b/arch/i386/pci/mmconfig-shared.c
index 747d8c6..f5267c7 100644
--- a/arch/i386/pci/mmconfig-shared.c
+++ b/arch/i386/pci/mmconfig-shared.c
@@
.
Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]>
---
diff --git a/arch/i386/pci/mmconfig-shared.c b/arch/i386/pci/mmconfig-shared.c
index 747d8c6..c85a5f7 100644
--- a/arch/i386/pci/mmconfig-shared.c
+++ b/arch/i386/pci/mmconfig-shared.c
@@ -24,6 +24,9 @@ #define MMCONFIG_APER_MAX (256 * 1
28 matches
Mail list logo