Add support for a new method for BIOS to provide the address and length
of the protected SMI communication buffer, via SMBIOS OEM strings.
Signed-off-by: Stuart Hayes
---
drivers/platform/x86/dcdbas.c | 43 ---
1 file changed, 30 insertions(+), 13 deletions
On 10/21/19 8:47 AM, Mika Westerberg wrote:
> On Thu, Oct 17, 2019 at 03:32:56PM -0400, Stuart Hayes wrote:
>> Some systems have in-band presence detection disabled for hot-plug PCI
>> slots, but do not report this in the slot capabilities 2 (SLTCAP2) register.
>> On th
On 10/21/19 8:41 AM, Mika Westerberg wrote:
> On Thu, Oct 17, 2019 at 03:32:55PM -0400, Stuart Hayes wrote:
>> From: Alexandru Gagniuc
>>
>> When inband presence is disabled, PDS may come up at any time, or not
>> at all. PDS being low may indicate that the card
after the device is enabled.
Signed-off-by: Alexandru Gagniuc
Signed-off-by: Stuart Hayes
---
v2:
replace while(true) loop with do...while
v3
remove unused variable declaration (pds)
modify text of warning message
drivers/pci/hotplug/pciehp_hpc.c | 19 +++
1 file change
From: Alexandru Gagniuc
The presence detect state (PDS) is normally a logical or of in-band and
out-of-band presence. As of PCIe 4.0, there is the option to disable
in-band presence so that the PDS bit always reflects the state of the
out-of-band presence.
The recommendation of the PCIe spec is
or disabling in-band presence
PCI: pciehp: Wait for PDS if in-band presence is disabled
Stuart Hayes (1):
PCI: pciehp: Add dmi table for in-band presence disabled
drivers/pci/hotplug/pciehp.h | 1 +
drivers/pci/hotplug/pciehp_hpc.c | 45 +++-
include/uapi/linu
device is connected.
Add a dmi table to flag these systems as having in-band presence disabled.
Signed-off-by: Stuart Hayes
---
drivers/pci/hotplug/pciehp_hpc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
patchwork.kernel.org/cover/10909167/
[v3,0/4] PCI: pciehp: Do not turn off slot if presence comes up after link
v2:
- modify loop in pcie_wait_for_presence to do..while
Alexandru Gagniuc (2):
PCI: pciehp: Add support for disabling in-band presence
PCI: pciehp: Wait for PDS if in-band presence
after the device is enabled.
Signed-off-by: Alexandru Gagniuc
Signed-off-by: Stuart Hayes
---
v2:
replace while(true) loop with do...while
drivers/pci/hotplug/pciehp_hpc.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/ho
device is connected.
Add a dmi table to flag these systems as having in-band presence disabled.
Signed-off-by: Stuart Hayes
---
drivers/pci/hotplug/pciehp_hpc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
From: Alexandru Gagniuc
The presence detect state (PDS) is normally a logical or of in-band and
out-of-band presence. As of PCIe 4.0, there is the option to disable
in-band presence so that the PDS bit always reflects the state of the
out-of-band presence.
The recommendation of the PCIe spec is
On Thu, Oct 10, 2019 at 12:40 AM Andy Shevchenko
wrote:
>
> On Thu, Oct 10, 2019 at 8:37 AM Andy Shevchenko
> wrote:
> > On Wed, Oct 9, 2019 at 11:05 PM Stuart Hayes
> > wrote:
>
> > > +static void pcie_wait_for_presence(struct pci_dev *pdev)
> >
after the device is enabled.
Signed-off-by: Alexandru Gagniuc
Signed-off-by: Stuart Hayes
---
drivers/pci/hotplug/pciehp_hpc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index dc109d521f30..1282641
device is connected.
Add a dmi table to flag these systems as having in-band presence disabled.
Signed-off-by: Stuart Hayes
---
drivers/pci/hotplug/pciehp_hpc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
From: Alexandru Gagniuc
The presence detect state (PDS) is normally a logical or of in-band and
out-of-band presence. As of PCIe 4.0, there is the option to disable
in-band presence so that the PDS bit always reflects the state of the
out-of-band presence.
The recommendation of the PCIe spec is
patchwork.kernel.org/cover/10909167/
[v3,0/4] PCI: pciehp: Do not turn off slot if presence comes up after link
Alexandru Gagniuc (2):
PCI: pciehp: Add support for disabling in-band presence
PCI: pciehp: Wait for PDS if in-band presence is disabled
Stuart Hayes (1):
PCI: pciehp: Add d
On Tue, Oct 1, 2019 at 11:13 PM Lukas Wunner wrote:
>
> On Tue, Oct 01, 2019 at 05:14:16PM -0400, Stuart Hayes wrote:
> > This patch set is based on a patch set [1] submitted many months ago by
> > Alexandru Gagniuc, who is no longer working on it.
> >
> > [1] http
On Tue, Oct 1, 2019 at 4:36 PM Alex G. wrote:
>
>
>
> On 10/1/19 4:14 PM, Stuart Hayes wrote:
> > Some systems have in-band presence detection disabled for hot-plug PCI
> > slots,
> > but do not report this in the slot capabilities 2 (SLTCAP2) register. On
> >
device is connected.
Add a dmi table to flag these systems as having in-band presence disabled.
Signed-off-by: Stuart Hayes
---
drivers/pci/hotplug/pciehp_hpc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
comes up after link
Stuart Hayes (3):
PCI: pciehp: Add support for disabling in-band presence
PCI: pciehp: Wait for PDS when in-band presence is disabled
PCI: pciehp: Add dmi table for systems with in-band presence disabled
drivers/pci/hotplug/pciehp.h | 1 +
drivers/pci/hotpl
abled.
Signed-off-by: Stuart Hayes
---
drivers/pci/hotplug/pciehp_hpc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index dc109d521f30..1282641c6458 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/dr
presence
whenever supported.
Signed-off-by: Stuart Hayes
---
drivers/pci/hotplug/pciehp.h | 1 +
drivers/pci/hotplug/pciehp_hpc.c | 9 -
include/uapi/linux/pci_regs.h| 2 ++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug
Tested on a Dell PowerEdge R7425 system on which this problem is easily
reproducible.
Tested-by: Stuart Hayes
Tested on a Dell PowerEdge R7425 system on which this problem is easily
reproducible.
Tested-by: Stuart Hayes
T))
> return -EINVAL; /* can't happen per definition */
>
> - spin_lock(&rbu_data.lock);
> rbu_data.image_update_buffer = image_update_buffer;
> rbu_data.image_update_buffer_size = size;
> rbu_data.bios_image_size = rbu_data.image_update_buffer_size;
>
Acked-by: Stuart Hayes
t; + return -EINVAL; /* can't happen per defintion */
> +
> + spin_lock(&rbu_data.lock);
> + rbu_data.image_update_buffer = image_update_buffer;
> + rbu_data.image_update_buffer_size = size;
> + rbu_data.bios_image_size = rbu_data.image_update_buffer_size;
> + rbu_data.image_update_ordernum = ordernum;
> + return 0;
> }
>
> static ssize_t read_packet_data(char *buffer, loff_t pos, size_t count)
>
Acked-by: Stuart Hayes
Move dcdbas to the more appropriate directory drivers/platform/x86.
Signed-off-by: Stuart Hayes
---
v2 changes:
- add commit message
drivers/firmware/Kconfig| 16
drivers/firmware/Makefile | 1 -
drivers/platform/x86/Kconfig
Move dell_rbu to the more appropriate directory drivers/platform/x86.
Signed-off-by: Stuart Hayes
---
v2 changes:
- add commit message
drivers/firmware/Kconfig | 12
drivers/firmware/Makefile | 1 -
drivers/platform/x86/Kconfig
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes
---
This patch has been discussed previously, see history at
https
Assign maintainer for dell_rbu driver, and reassign maintainer of dcdbas
from inactive maintainer (current maintainer is aware of this change--
see https://www.spinics.net/lists/platform-driver-x86/msg16336.html).
Signed-off-by: Stuart Hayes
Acked-by: Doug Warzecha
---
v2 changes:
- remove
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
This patch has been discussed
- remove extra whitespace in MAINTAINERS
- add acked-by from (previous) maintainer of dcdbas
Stuart Hayes (5):
firmware: dell_rbu: Make payload memory uncachable
firmware: dcdbas: Add support for WSMT ACPI table
firmware: dell_rbu: Move dell_rbu to drivers/platform/x86
firmware: dcdbas: Move
From: Stuart Hayes
Signed-off-by: Stuart Hayes
---
drivers/firmware/Kconfig | 12
drivers/firmware/Makefile | 1 -
drivers/platform/x86/Kconfig | 12
drivers/platform/x86/Makefile | 1
From: Stuart Hayes
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
This patch
From: Stuart Hayes
The dell_rbu and dcdbas drivers need some changes, and should be moved to
drivers/platform/x86. Additionally, dell_rbu needs a maintainer, and the
listed maintainer for dcdbas is inactive and needs to be changed.
Stuart Hayes (5):
firmware: dell_rbu: Make payload memory
From: Stuart Hayes
Assign maintainer for dell_rbu driver, and reassign maintainer of dcdbas
from inactive maintainer (current maintainer is aware of this change--
see https://www.spinics.net/lists/platform-driver-x86/msg16336.html).
Signed-off-by: Stuart Hayes
---
MAINTAINERS | 11
From: Stuart Hayes
The dell_rbu driver takes firmware update payloads and puts them in memory so
the system BIOS can find them after a reboot. This sometimes fails (though
rarely), because the memory containing the payload is in the CPU cache but
never gets written back to main memory before
From: Stuart Hayes
Signed-off-by: Stuart Hayes
---
drivers/firmware/Kconfig| 16
drivers/firmware/Makefile | 1 -
drivers/platform/x86/Kconfig| 16
drivers/platform/x86/Makefile | 1
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes
Reviewed-by: Takashi Iwai
Signed-off-by: Takashi Iwai
---
v2 Added include
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
v2 Bumped driver version to
On 7/2/2018 11:15 AM, mario.limoncie...@dell.com wrote:
>>
>>> I don't believe SMM communication ACPI table has ever been implemented by
>> Dell
>>> on server or client BIOS. I do agree this table describes the behavior
>>> that DCDBAS
>> driver
>>> has used since before even UEFI BIOS pretty
On 06/27/2018 06:52 PM, Andy Shevchenko wrote:
> On Fri, Jun 15, 2018 at 1:31 AM, Stuart Hayes
> wrote:
>> On 6/14/2018 12:25 PM, Andy Shevchenko wrote:
>>> On Thu, Jun 14, 2018 at 5:22 PM, Stuart Hayes
>>> wrote:
>>>> O
On 6/14/2018 12:26 PM, Andy Shevchenko wrote:
> On Thu, Jun 14, 2018 at 6:45 PM, Stuart Hayes
> wrote:
>>
>> If the WSMT ACPI table is present and indicates that a fixed communication
>> buffer should be used, use the firmware-specified buffer instead of
>> all
On 6/14/2018 12:25 PM, Andy Shevchenko wrote:
> On Thu, Jun 14, 2018 at 5:22 PM, Stuart Hayes
> wrote:
>> On 6/13/2018 3:54 AM, Andy Shevchenko wrote:
>
>>>> +* Provide physical address of command buffer field within
>>>> +
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
v2 Bumped driver version to
On 6/13/2018 3:54 AM, Andy Shevchenko wrote:
>> + /* Calling Interface SMI
>
> I suppose the style of the comments like
> /*
> * Calling ...
> ...
Yes... goof on my part. Thanks.
>> +*
>> +* Provide physical address of command buffer field within
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
v2 Bumped driver version to
On 6/8/2018 8:04 PM, Darren Hart wrote:
> On Thu, Jun 07, 2018 at 08:11:41PM +0300, Andy Shevchenko wrote:
>> On Thu, Jun 7, 2018 at 6:59 PM, Stuart Hayes
>> wrote:
>>> If the WSMT ACPI table is present and indicates that a fixed communication
>>> buffer
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
Tested-by: Mario Limonciello
Acked
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmare.
Signed-off-by: Stuart Hayes
---
v2 Bumped driver version to 5.6.0
On 4/18/2018 12:46 AM, Takashi Iwai wrote:
> From: Stuart Hayes
>
> The dell_rbu driver takes firmware update payloads and puts them in memory so
> the system BIOS can find them after a reboot. This sometimes fails (though
> rarely), because the memory containing the payloa
If the WSMT ACPI table is present and indicates that a fixed communication
buffer should be used, use the firmware-specified buffer instead of
allocating a buffer in memory for communications between the dcdbas driver
and firmware.
Signed-off-by: Stuart Hayes
Reviewed-by: Mario Limonciello
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes
---
v2 Added include, removed extra parentheses
v3 Corrected formatting and
On 4/4/2018 3:30 PM, Takashi Iwai wrote:
> On Wed, 28 Mar 2018 17:07:47 +0200,
> Stuart Hayes wrote:
>>
>> @@ -180,6 +181,12 @@ static int create_packet(void *data, size_t length)
>> invalid_addr_packet_array[idx++
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes
---
v2 Added include, removed extra parentheses
v3 Corrected formatting and
Please disregard this version. I'm sorry (and intensely embarrassed).
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes
---
v2 Added include, removed extra parentheses
This patch has no maintainer
ase drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Stuart-Hayes/dell_rbu-make-firmware-payload-memory-uncachable/20180323-094405
> config: i386-randconfig-x014-201811 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
>
(CPU
cache contents are lost on reboot).
With this patch, the payload memory will be changed to uncachable to ensure
that the payload is actually in main memory before the system is rebooted.
Signed-off-by: Stuart Hayes
---
Note that there is no maintainer for this driver, so I'd be gratef
ing, given that
scsi_eh_scmd_add() also uses the spinlock.
I tested your patch on my issue, and it did indeed fix my issue.
So you can add...
Tested-by: Stuart Hayes
Thanks
Stuart
On 11/21/2017 2:09 AM, Pavel Tikhomirov wrote:
> My patch should also fix your issue too, please see explanatio
Pavel,
It turns out that the error handler on our systems was not getting woken up for
a different reason... I submitted a patch earlier today that fixes the issue I
were seeing (I CCed you on the patch).
Before I got my hands on the failing system and was able to root cause it, I
was pretty s
When a command is added to the host's error handler command queue, there is a
chance that the error handler will not be woken up. This can happen when one
CPU is running scsi_eh_scmd_add() at the same time as another CPU is running
scsi_device_unbusy() for a different command on the same host.
Are there any issues with this patch
(https://patchwork.kernel.org/patch/9938919/) that Pavel Tikhomirov submitted
back in September? I am willing to help if there's anything I can do to help
get it accepted.
The failing case I'm working on involves lots of servers with disk read/write
activ
On 8/10/2017 9:46 AM, Ingo Molnar wrote:
>
> * Matt Fleming wrote:
>
>> On Wed, 02 Aug, at 11:41:38AM, Stuart Hayes wrote:
>>> (Resend because I mistyped the maintainer's email address the first time.)
>>>
>>> The kernel's EFI stub locates
820: update [mem 0x60ef4000-0x60f4cfff] usable ==> usable
...
PM: Registered nosave memory: [mem 0x-0x0fff]
PM: Registered nosave memory: [mem 0x000a-0x000f]
PM: Registered nosave memory: [mem 0x6cf6e000-0x6f3ccfff]
Signed-off-by: Stuart Hayes
---
Changes in V2:
Update th
] usable ==> usable
e820: update [mem 0x60f4d000-0x60fa5fff] usable ==> usable
e820: update [mem 0x60ef4000-0x60f4cfff] usable ==> usable
...
PM: Registered nosave memory: [mem 0x-0x0fff]
PM: Registered nosave memory: [mem 0x000a-0x000f]
PM: Registered nosave memory: [mem
820: update [mem 0x60ef4000-0x60f4cfff] usable ==> usable
...
PM: Registered nosave memory: [mem 0x-0x0fff]
PM: Registered nosave memory: [mem 0x000a-0x000f]
PM: Registered nosave memory: [mem 0x6cf6e000-0x6f3ccfff]
Signed-off-by: Stuart Hayes
---
--- linux-4.13-rc2/arch/x86
On 5/26/2016 11:38 AM, Stuart Hayes wrote:
Add the Microsoft _DSM command set to the white list of NVDIMM command sets.
This command set is documented at
https://msdn.microsoft.com/library/windows/hardware/mt604741.
Signed-off-by: Stuart Hayes
---
drivers/acpi/nfit.c| 9
Add the Microsoft _DSM command set to the white list of NVDIMM command sets.
This command set is documented at
https://msdn.microsoft.com/library/windows/hardware/mt604741.
Signed-off-by: Stuart Hayes
---
drivers/acpi/nfit.c| 9 ++---
drivers/acpi/nfit.h| 4
include
>>
>> Linux drivers no longer use MTRR so why is the cleanup needed, ie, what would
>> happen if the cleanup is just skipped in your case ?
>
> The infiniband & video drivers still use MTRR (or at least it was my
> understanding that they do). In any case, Stuart -- could you try booting
> with
of, say, 256GB, and ten variable
MTRRs (such as some recent Intel CPUs have), it is not possible to set up
the MTRRs to cover all of memory.
Signed-off-by: Stuart Hayes
---
--- linux-4.2-rc7/arch/x86/kernel/cpu/mtrr/cleanup.c.orig 2015-08-16
18:34:13.0 -0500
+++ linux-4.2-rc7/arch
On 7/8/2014 5:38 PM, H. Peter Anvin wrote:
> On 07/08/2014 03:34 PM, Stuart Hayes wrote:
>>
>> I haven't received any responses... is there a problem with the patch? Also
>> CCing a couple people.
>>
>
> I was on vacation last week and am still catch
On 7/2/2014 8:47 PM, Stuart Hayes wrote:
> A page fault can crash the kernel very early if an NX bit is set in a
> page table entry, if the CPU doesn't support NX (or if NX support is
> disabled in the CPU). Move the call to x86_configure_nx() earlier
> than parse_setup_data(),
n not mapping the pages at all.
Signed-off-by: Stuart Hayes
---
--- linux-3.16-rc3/arch/x86/mm/pageattr.c.orig 2014-07-02 12:04:49.244288159
-0400
+++ linux-3.16-rc3/arch/x86/mm/pageattr.c 2014-07-02 12:05:55.808290437
-0400
@@ -1862,10 +1862,7 @@ int kernel_map_pages_in_pgd(pgd_t
A page fault can crash the kernel very early if an NX bit is set in a
page table entry, if the CPU doesn't support NX (or if NX support is
disabled in the CPU). Move the call to x86_configure_nx() earlier
than parse_setup_data(), since that calls early_memremap().
Signed-off-by: Stuart
Commit-ID: 6c6c0d5a1c949d2e084706f9e5fb1fccc175b265
Gitweb: http://git.kernel.org/tip/6c6c0d5a1c949d2e084706f9e5fb1fccc175b265
Author: Stuart Hayes
AuthorDate: Tue, 29 Apr 2014 17:55:02 -0500
Committer: Thomas Gleixner
CommitDate: Wed, 30 Apr 2014 12:34:51 +0200
hrtimer: Prevent all
event device
interrupts occur and no timer expiration functions are run.
Signed-off-by: Stuart Hayes
---
--- linux-3.15-rc3/kernel_orig/hrtimer.c2014-04-29 13:10:58.087832963
-0400
+++ linux-3.15-rc3/kernel/hrtimer.c 2014-04-29 15:42:49.581084736 -0400
@@ -569,6 +569,15
Andi Kleen wrote:
> I personally wouldn't like doing this NX cleanup very late like you did but
> instead directly after the early NX setup.
I've thought about it more, and come up with another patch. All it does is
sets up the PTEs correctly from the beginning, breaking up large pages if
neces
78 matches
Mail list logo
