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
event device
interrupts occur and no timer expiration functions are run.
Signed-off-by: Stuart Hayes stuart.w.ha...@gmail.com
---
--- 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
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 catching up.
It would also help if you describe the real
not mapping the pages at all.
Signed-off-by: Stuart Hayes stuart.w.ha...@gmail.com
---
--- 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
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(), since that calls
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 Hayes
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 <stuart.w.ha...@gmail.com>
---
--- linux-4.2-rc7/arch/x86/kernel/cpu/mtrr/cleanup.c.orig 2015-08-16
18:34:13.0
>>
>> 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
>
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 <stuart.w.ha...@gmail.com>
---
driver
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 <stuart.w.ha...@gmail.com>
---
drivers/acpi/nfit.c| 9 ++---
drivers/acpi/
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 <stuart.w.ha...@gmail.com>
On 8/10/2017 9:46 AM, Ingo Molnar wrote:
>
> * Matt Fleming <m...@codeblueprint.co.uk> 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 ker
=> 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 0x6cf6e00
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 <stuart.w.ha...@gmail.com
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.
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
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 <stuart.w.ha...@gmail.com>
Thanks
Stuart
On 11/21/2017 2:09 AM, Pavel Tikhomirov wrote:
> My patch should also fix your issue to
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
On 4/18/2018 12:46 AM, Takashi Iwai wrote:
> From: Stuart Hayes <stuart.w.ha...@gmail.com>
>
> 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
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 <stuart.w.ha...@gmail.com>
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
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
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
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
>>>> +
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
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
>>
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
(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
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 <stuart.w.ha...@gmail.com>
---
v2 Added include, removed extra parenthe
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 <stuart.w.ha...@gmail.com>
Re
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 <stuart.w.ha...@gmail.com>
---
v2 Added include, removed extra paren
(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 <stuart.w.ha...@gmail.com>
---
v2 Added include, removed extra parenthe
(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 <stuart.w.ha...@gmail.com>
---
Note that there is no main
please 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
>
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
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
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
- 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
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
(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
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
Signed-off-by: Stuart Hayes
---
drivers/firmware/Kconfig| 16
drivers/firmware/Makefile | 1 -
drivers/platform/x86/Kconfig| 16
drivers/platform/x86/Makefile | 1
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
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
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 catching u
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 *pgd
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(), sinc
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 Hayes
(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
Please disregard this version. I'm sorry (and intensely embarrassed).
please 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
---
v2 Added include, removed extra parentheses
v3 Corrected formatting
(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 grateful
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
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
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 the
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 and co
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.
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
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/boot
=> 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 0x6cf6e00
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
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
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 explanation in re
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
.
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/drivers
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
a
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
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
> >
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
a
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
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
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 changed, 19
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
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
a
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
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..1282641c6458
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)
> >
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
a
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
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/hotplug
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
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 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
>>
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
>>>> +
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 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
1 - 100 of 130 matches
Mail list logo
