the Tx FIFO 3/4 empty interrupt to
replenish the FIFO on large SPI bursts. This requires more care in
when the interrupt is left enabled, as this interrupt will continually
trigger when the FIFO is less than 1/4 full, even though we
acknowledge it.
Signed-off-by: Alexandru Gagniuc mr.nuke...@gmail.com
as in vsc824x_config_init().
Tested on custom board with AM3352 SOC and VSC801 PHY.
Signed-off-by: Alexandru Gagniuc <ale...@adaptrum.com>
---
Changes since v1:
* Added comment detailing applicability to different RGMII interfaces.
drivers/net/phy/vitesse.c | 34 +-
as in vsc824x_config_init().
Tested on custom board with AM3352 SOC and VSC801 PHY.
Signed-off-by: Alexandru Gagniuc <ale...@adaptrum.com>
---
drivers/net/phy/vitesse.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/vitesse.c b/drivers/n
the Tx FIFO 3/4 empty interrupt to
replenish the FIFO on large SPI bursts. This requires more care in
when the interrupt is left enabled, as this interrupt will continually
trigger when the FIFO is less than 1/4 full, even though we
acknowledge it.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.
were told this will all be handled with DMA.
A week or so ago, we were told this will all be handled with DMA.
See the pattern?
When DMA finally takes over, this fallback path is not mutually exclusive.
Changes since V6:
Rebased to make sure it applies on top of 4.9-rc.
Also tested on actual hardware.
ternal delay")
Signed-off-by: Alexandru Gagniuc <ale...@adaptrum.com>
---
drivers/net/ethernet/ti/cpsw-phy-sel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c
b/drivers/net/ethernet/ti/cpsw-phy-sel.c
index ba1e45f..1801364 100644
--- a/dr
ation marks clearing this bit as "reserved",
however, according to TI, support for delaying the clock does exist in
the MAC, although it is not officially supported.
We tested this on a board with an RGMII to RGMII link that will not
work unless this bit is cleared.
Signed-off-by: Alexandr
Hi Marek,
Me again!
On 07/29/2017 02:34 AM, Marek Vasut wrote:
On 07/29/2017 12:07 AM, Alexandru Gagniuc wrote:
+static void aspi_drain_fifo(struct anarion_qspi *aspi, uint8_t *buf, size_t
len)
+{
+ uint32_t data;
Is this stuff below something like ioread32_rep() ?
[snip
On 07/29/2017 02:34 AM, Marek Vasut wrote:
On 07/29/2017 12:07 AM, Alexandru Gagniuc wrote:
Add support for the QSPI controller found in Adaptrum Anarion SOCs.
This controller is designed specifically to handle SPI NOR chips, and
the driver is modeled as such.
Because the system is emulated
Hi Phillip,
On 08/11/2017 06:06 AM, Philipp Zabel wrote:
[snip]
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 52d5251660b9b..f7ba01a71daee 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -68,6 +68,16 @@ config RESET_PISTACHIO
help
This
Hi Philipp,
On 08/11/2017 06:06 AM, Philipp Zabel wrote:
[snip]
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 52d5251660b9b..f7ba01a71daee 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -68,6 +68,16 @@ config RESET_PISTACHIO
help
This
Hi Phillip,
On 08/11/2017 06:06 AM, Philipp Zabel wrote:
[snip]
@@ -113,8 +137,33 @@ static int reset_simple_probe(struct platform_device *pdev)
data->rcdev.ops = _simple_ops;
data->rcdev.of_node = dev->of_node;
- if (devdata)
+ if (devdata == _simple_socfpga) {
.com>
Cc: Alexandru Gagniuc <ale...@adaptrum.com>
Tested-by: Alexandru Gagniuc <ale...@adaptrum.com>
---
arch/arc/kernel/intc-arcv2.c | 3 +++
arch/arc/kernel/intc-compact.c | 14 +-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arc/kernel/intc-ar
Hi,
I was looking at implementing a reset driver for our in-house SoC. It's
essentially a long bitfield, each bit controlling one sort of reset.
That seems to be surprisingly common. I've identified the following
drivers which control a very similar reset:
* reset-zynq
* reset-zx2967
*
Add devicetree binding documentation for the Anarion QSPI controller.
Signed-off-by: Alexandru Gagniuc <ale...@adaptrum.com>
---
.../devicetree/bindings/mtd/anarion-quadspi.txt| 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bi
are implemented at
this time.
Signed-off-by: Alexandru Gagniuc <ale...@adaptrum.com>
---
Changes since v1:
* Moved documentation for bindings to separate patch
* Removed idiotic dev_err() message
* Changed bit macros to use BIT(n) instead of (1 << n)
* Fixed alphabetical orderin
and interrupt mapping established.
Signed-off-by: Alexandru Gagniuc <ale...@adaptrum.com>
---
Changes since v1:
* None
arch/arc/Kconfig | 1 +
arch/arc/Makefile| 1 +
arch/arc/plat-anarion/Kconfig| 10 ++
arch/arc/plat-anarion/Makefile
Signed-off-by: Alexandru Gagniuc <ale...@adaptrum.com>
---
Changes since v1:
* Updated CPU core clock to 24 MHz to match HW changes.
arch/arc/boot/dts/adaptrum_anarion.dtsi | 108
arch/arc/boot/dts/adaptrum_anarion_fpga.dts | 49 +
2 files c
are implemented at
this time.
Signed-off-by: Alexandru Gagniuc <ale...@adaptrum.com>
---
.../devicetree/bindings/mtd/anarion-quadspi.txt| 22 +
drivers/mtd/spi-nor/Kconfig| 7 +
drivers/mtd/spi-nor/Makefile | 1 +
drivers/mtd/spi-nor/a
it's much more intuitive to include this in the
glue layer instead.
At this time only RGMII is supported, because it is the only mode
which has been validated hardware-wise.
Signed-off-by: Alexandru Gagniuc <ale...@adaptrum.com>
---
.../devicetree/bindings/net/anarion-gmac.txt | 25 +
Signed-off-by: Alexandru Gagniuc <ale...@adaptrum.com>
---
arch/arc/boot/dts/adaptrum_anarion.dtsi | 107
arch/arc/boot/dts/adaptrum_anarion_fpga.dts | 49 +
2 files changed, 156 insertions(+)
create mode 100644 arch/arc/bo
speed measurements with the CPU clock at 12 MHz.
Once the silicon arrives, I'll look at the performance aspect and
other aspects that we simply can't support on an FPGA.
Alex
Alexandru Gagniuc (5):
of: Add vendor prefix for Adaptrum, Inc.
ARC: [plat-anarion] Add early boot workarounds
Signed-off-by: Alexandru Gagniuc <ale...@adaptrum.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index da
and interrupt mapping established.
Signed-off-by: Alexandru Gagniuc <ale...@adaptrum.com>
---
arch/arc/Kconfig | 1 +
arch/arc/Makefile| 1 +
arch/arc/plat-anarion/Kconfig| 10 ++
arch/arc/plat-anarion/Makefile | 7 +++
arch/arc/plat-a
On 07/31/2017 02:33 PM, Marek Vasut wrote:
On 07/31/2017 07:17 PM, Alexandru Gagniuc wrote:
Hi Marek,
Thank you again for your feedback. I've applied a majority of your
suggestions, and I am very happy with the result. I should have v2
posted within a day or so.
[snip]
+/*
+ * This mask
On 07/31/2017 03:43 PM, Marek Vasut wrote:
On 08/01/2017 12:20 AM, Alexandru Gagniuc wrote:
On 07/31/2017 02:33 PM, Marek Vasut wrote:
On 07/31/2017 07:17 PM, Alexandru Gagniuc wrote:
+struct anarion_qspi {
+structspi_nor nor;
+structdevice *dev;
+uintptr_t
On 08/16/2017 02:46 AM, Philipp Zabel wrote:
The reset-simple driver can be used without changes.
Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
Reviewed-by: Alexandru Gagniuc <ale...@adaptrum.com>
---
drivers/reset/Kconfig| 11 ++---
drivers/reset/Makefile
On 08/16/2017 01:52 PM, Andreas Färber wrote:
Am 16.08.2017 um 22:50 schrieb Alexandru Gagniuc:
On 08/16/2017 02:46 AM, Philipp Zabel wrote:
The reset-simple driver can be used without changes.
Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
Reviewed-by: Alexandru Gagniu
. The separate sunxi driver still remains to
register the early reset controllers, but it reuses the reset-simple
ops.
The following patches will replace compatible reset drivers with
reset-simple, extending it where necessary.
Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
Reviewed-by: Ale
Hi Phillip,
On 08/16/2017 02:46 AM, Philipp Zabel wrote:
[snip]
@@ -118,8 +151,23 @@ static int reset_simple_probe(struct platform_device *pdev)
data->rcdev.ops = _simple_ops;
data->rcdev.of_node = dev->of_node;
- if (devdata)
+ if (devdata) {
+ u32
On 08/16/2017 02:47 AM, Philipp Zabel wrote:
Read back the register after setting or clearing a reset bit to make
sure that the changes are applied to the reset controller hardware.
Theoretically, this avoids the write to stay stuck in a store buffer
Is there hardware where this has been
On 08/16/2017 02:47 AM, Philipp Zabel wrote:
The reset-simple driver can be used without changes.
Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
Reviewed-by: Alexandru Gagniuc <ale...@adaptrum.com>
---
MAINTAINERS | 1 -
drivers/reset/Kconfig
is on fire,
and they are not severe enough that we need to panic(). Instead of
relying on crackmonkey firmware, evaluate the error severity based on
what caused the error (GHES subsections).
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/
ghes_severity() is a misnomer in this case, as it implies the severity
of the entire GHES structure. Instead, it maps one CPER value to a
GHES_SEV* value. ghes_cper_severity() is clearer.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/apei/ghes.
AER handler is split into NMI and non-NMI portions
- ghes_notify_nmi() does not panic on deferrable errors
- The handlers are put in a mapping and given a common call signature
Alexandru Gagniuc (2):
acpi: apei: Rename ghes_severity() to ghes_cper_severity()
acpi: apei: Do not panic() on PCIe
-ENODEV' vs 'goto out', where 'result' happens to be -ENODEV
CC: Keith Busch <keith.bu...@intel.com>
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/nvme/host/pci.c | 42 --
1 file changed, 24 insertions(+), 18 deletions(-)
ghes_severity() is a misnomer in this case, as it implies the severity
of the entire GHES structure. Instead, it maps one CPER value to a
GHES_SEV* value. ghes_cper_severity() is clearer.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/apei/ghes.
:
- Due to popular request, the panic() is left in the NMI handler
- GHES AER handler is split into NMI and non-NMI portions
- ghes_notify_nmi() does not panic on deferrable errors
- The handlers are put in a mapping and given a common call signature
Alexandru Gagniuc (2):
acpi: apei: Rename
is on fire,
and they are not severe enough to justify a panic(). Do not blindly
rely on firmware to evaluate the severity for us. Instead, look at
the error severity based on what caused the error (GHES subsections).
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/
o identify the source
of the error, the original panic() behavior is maintained.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/apei/ghes.c | 43 +--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/apei/
ghes_severity() is a misnomer in this case, as it implies the severity
of the entire GHES structure. Instead, it maps one CPER value to one
GHES_SEV* value. ghes_cper_severity() is clearer.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/apei/ghes.
not panic on deferrable errors
- The handlers are put in a mapping and given a common call signature
Alexandru Gagniuc (3):
acpi: apei: Rename GHES_SEV_PANIC to GHES_SEV_FATAL
acpi: apei: Rename ghes_severity() to ghes_cper_severity()
acpi: apei: Do not panic() on PCIe errors reported th
because it implies a policy to crash the
system on fatal errors. Drop this questionable policy, and rename the
enum to 'GHES_SEV_FATAL' to better convey the meaning.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
arch/x86/kernel/cpu/mcheck/mce-apei.c | 2 +-
drivers/acpi/apei/
BIOSes to think that something
bad happened, and print ominous messages on next boot. To prevent this,
tidy up the AER status bits before releasing containment.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/pci/pcie/dpc.c | 4
1 file changed, 4 insertions(+)
diff
is happens because aer_acpi_firmware_first() doesn't take
'pcie_ports' into account. This is wrong. DPC uses the same logic when
it decides whether to load or not, so fixing this also fixes DPC not
loading.
Signed-off-by: Alexandru Gagniuc
---
drivers/pci/pcie/aer/aerdrv_acpi.c | 4 +++-
1 file
to detect this is with pcie_print_link_status(),
since the bottleneck is usually the link that is downtrained. It's not
a perfect solution, but it works extremely well in most cases.
Signed-off-by: Alexandru Gagniuc
---
Changes since v3:
- Remove extra newline and parentheses.
- Make sure v4.18-rc1
is happens because aer_acpi_firmware_first() doesn't take
'pcie_ports' into account. This is wrong. DPC uses the same logic when
it decides whether to load or not, so fixing this also fixes DPC not
loading.
Signed-off-by: Alexandru Gagniuc
---
drivers/pci/pcie/aer.c | 5 -
1 file changed, 4
to detect this is with pcie_print_link_status(),
since the bottleneck is usually the link that is downtrained. It's not
a perfect solution, but it works extremely well in most cases.
Signed-off-by: Alexandru Gagniuc
---
drivers/pci/probe.c | 22 ++
1 file changed, 22 insertions
for such conditions on device probe, and print an
appropriate message.
Signed-off-by: Alexandru Gagniuc
---
drivers/pci/probe.c | 78 +++
include/uapi/linux/pci_regs.h | 1 +
2 files changed, 79 insertions(+)
diff --git a/drivers/pci/probe.c b/drivers/pci
ser_" functions on the in-kernel
pci_read/write_config*().
Signed-off-by: Alexandru Gagniuc
---
drivers/pci/access.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index a3ad2fe185b9..6db2a8713c85 100644
--- a/driver
to detect this is with pcie_print_link_status(),
since the bottleneck is usually the link that is downtrained. It's not
a perfect solution, but it works extremely well in most cases.
Signed-off-by: Alexandru Gagniuc
---
Changes since v2:
- Check dev->is_virtfn flag
Changes since v1:
-
is happens because aer_acpi_firmware_first() doesn't take
'pcie_ports' into account. This is wrong. DPC uses the same logic when
it decides whether to load or not, so fixing this also fixes DPC not
loading.
Signed-off-by: Alexandru Gagniuc
---
drivers/pci/pcie/aer.c | 9 ++---
1 file
ghes_severity() is a misnomer in this case, as it implies the severity
of the entire GHES structure. Instead, it maps one CPER value to a
monotonically increasing number. ghes_cper_severity() is clearer.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/apei/ghes.
The use of the 'ghes' argument was removed in a previous commit, but
function signature was not updated to reflect this.
Fixes: 0fe5f281f749 ("EDAC, ghes: Model a single, logical memory controller")
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi
is on fire,
and they are not severe enough that we need to panic(). Instead of
relying on crackmonkey firmware, evaluate the error severity based on
what caused the error (GHES subsections).
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/
On errors reported from CPER, cper_print_bits() was used to log the
AER bits. This resulted in hard-to-understand messages, without a
prefix. Instead use __aer_print_error() for both native AER and CPER
to provide a more consistent log format.
Signed-off-by: Alexandru Gagniuc <mr.n
is happens because aer_acpi_firmware_first() doesn't take
'pcie_ports' into account. This is wrong. DPC uses the same logic when
it decides whether to load or not, so fixing this also fixes DPC not
loading.
Signed-off-by: Alexandru Gagniuc
---
drivers/pci/pcie/aer.c | 6 ++
1 file changed, 6
in the first place eliminates the problem.
Signed-off-by: Alexandru Gagniuc
---
There's another patch by Lukas Wunner that is needed (not yet published)
in order to fully block IO on SURPRISE!!! removal. The existing code only
sets the PCI_DEV_DISCONNECTED bit in an unreasonably narrow set
significance, since I can't
reasonably demonstrate this race in the lab.
On a side-note, pcie_aer_is_kernel_first() is created to alleviate the
need for two checks: aer_cap and get_firmware_first().
Signed-off-by: Alexandru Gagniuc
---
Changes since v2:
- Added missing negation
This device has the same issues as the HP x360 wrt the MUTE LED and
the front speakers not working. This patch fixes the MUTE LED issue,
but doesn't touch the HDA verbs. The fix for the x360 does not work
on the Spectre.
Signed-off-by: Alexandru Gagniuc
---
sound/pci/hda/patch_realtek.c | 1
, as it is not easy to
reasonably demonstrate it in testing.
Signed-off-by: Alexandru Gagniuc
---
drivers/pci/pcie/aer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index a2e88386af28..18037a2a8231 100644
--- a/drivers/pci/pcie/aer.c
+++ b
to detect this is with pcie_print_link_status(),
since the bottleneck is usually the link that is downtrained. It's not
a perfect solution, but it works extremely well in most cases.
Signed-off-by: Alexandru Gagniuc
---
For the sake of review, I've created a __pcie_print_link_status() which
takes
significance, since I can't
reasonably demonstrate this race in the lab.
On a side-note, pcie_aer_is_kernel_first() is created to alleviate the
need for two checks: aer_cap and get_firmware_first().
Signed-off-by: Alexandru Gagniuc
---
drivers/pci/pcie/aer.c | 17 ++---
1 file changed, 10
significance, since I can't
reasonably demonstrate this race in the lab.
On a side-note, pcie_aer_is_kernel_first() is created to alleviate the
need for two checks: aer_cap and get_firmware_first().
Signed-off-by: Alexandru Gagniuc
---
drivers/pci/pcie/aer.c | 17 ++---
1 file changed, 10
not fatal to the system. When there
is a disagreement with firmware about the handleability of an error,
print a warning message.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/apei/ghes.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/d
enough information to invoke the full AER handler later down
the road, and tells ghes_notify_nmi that "It's all cool".
ghes_notify_nmi() then gets calmed down a little, and doesn't panic().
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/apei/ghes.c | 4
I portions
- ghes_notify_nmi() does not panic on deferrable errors
- The handlers are put in a mapping and given a common call signature
Alexandru Gagniuc (4):
EDAC, GHES: Remove unused argument to ghes_edac_report_mem_error
acpi: apei: Split GHES handlers outside of ghes_do_proc
acpi: apei: Do not pa
Use a mapping from CPER UUID to get the correct handler for a given
GHES error. This is in preparation of splitting some handlers into
irq safe and regular parts.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/apei/ghes.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/apei/ghes.c | 2 +-
drivers/edac/ghes_edac.c | 3 +--
include/acpi/ghes.h | 5 ++---
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 1efefe
On errors reported from CPER, cper_print_bits() was used to log the
AER bits. This resulted in hard-to-understand messages, without a
prefix. Instead use __aer_print_error() for both native AER and CPER
to provide a more consistent log format.
Signed-off-by: Alexandru Gagniuc <mr.n
Move ghes_print_queued_estatus() above ghes_proc_in_irq(). In a
subsequent patch, the NMI handler will be updated, and the print
functionality will be used in ghes_proc_in_irq.
This simply makes the subsequent diff look sane.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
d
not fatal to the system. When there
is a disagreement with firmware about the handleability of an error,
print a warning message.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/apei/ghes.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/acpi/apei/ghes.
perform proper error handling when possible. It is not to make FFS a first
class citizen in error handling.
Alexandru Gagniuc (4):
acpi: apei: Return severity of GHES messages after handling
acpi: apei: Swap ghes_print_queued_estatus and ghes_proc_in_irq
acpi: apei: Do not panic() in NMI beca
pass fatal errors down to IRQ
context to see if they can be resolved.
With these change, PCIe error are handled by AER. Other far less
common errors, such as machine check exceptions, still cause a panic()
in their respective handlers.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
-
ror, while
marking handled errors as corrected.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/apei/ghes.c | 35 +--
1 file changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
in
is on fire,
and they are not severe enough that we need to panic(). Instead of
relying on crackmonkey firmware, evaluate the error severity based on
what caused the error (GHES subsections).
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/
The use of the 'ghes' argument was removed in a previous commit, but
function signature was not updated to reflect this.
Fixes: 0fe5f281f749 ("EDAC, ghes: Model a single, logical memory controller")
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi
not panic on deferrable errors
- The handlers are put in a mapping and given a common call signature
Alexandru Gagniuc (3):
EDAC, GHES: Remove unused argument to ghes_edac_report_mem_error
acpi: apei: Do not panic() on PCIe errors reported through GHES
acpi: apei: Warn when GHES marks correcta
not fatal to the system. When there
is a disagreement with firmware about the handleability of an error,
print a warning message.
Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
---
drivers/acpi/apei/ghes.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/acpi/apei/
This is now done by the PCI core to warn of sub-optimal bandwidth.
Signed-off-by: Alexandru Gagniuc
---
drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c
b/drivers/net/ethernet
This is now done by the PCI core to warn of sub-optimal bandwidth.
Signed-off-by: Alexandru Gagniuc
---
drivers/net/ethernet/mellanox/mlx5/core/main.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c
b/drivers/net/ethernet/mellanox/mlx5/core
, and rescan the bandwidth, looking for the weakest point. This
is the same logic used in probe().
Signed-off-by: Alexandru Gagniuc
---
Changes since v1:
* Layer on top of the pcie port service drivers, instead of hotplug service.
This patch needs to be applied on top of:
PCI: Add missing
This files makes use of definitions provided in . This
only compiles when is included beforehand, and creates
a nasty include dependency. Instead, just include the correct file.
Signed-off-by: Alexandru Gagniuc
---
drivers/pci/pci.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers
, and rescan the bandwidth, looking for the weakest point. This
is the same logic used in probe().
Signed-off-by: Alexandru Gagniuc
---
drivers/pci/hotplug/pciehp_hpc.c | 35 +++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/hotplug
.
Not triggering the IO in the first place greatly reduces the
possibility of the problem occurring.
Signed-off-by: Alexandru Gagniuc
---
drivers/pci/msi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index f2ef896464b3..f31058fd2260 100644
--- a/drivers
the Tx FIFO 3/4 empty interrupt to
replenish the FIFO on large SPI bursts. This requires more care in
when the interrupt is left enabled, as this interrupt will continually
trigger when the FIFO is less than 1/4 full, even though we
acknowledge it.
Signed-off-by: Alexandru Gagniuc
Acked-by: Maxime
AER handler is split into NMI and non-NMI portions
- ghes_notify_nmi() does not panic on deferrable errors
- The handlers are put in a mapping and given a common call signature
Alexandru Gagniuc (2):
acpi: apei: Rename ghes_severity() to ghes_cper_severity()
acpi: apei: Do not panic() on PCIe
ghes_severity() is a misnomer in this case, as it implies the severity
of the entire GHES structure. Instead, it maps one CPER value to a
GHES_SEV* value. ghes_cper_severity() is clearer.
Signed-off-by: Alexandru Gagniuc
---
drivers/acpi/apei/ghes.c | 17 -
1 file changed, 8
is on fire,
and they are not severe enough that we need to panic(). Instead of
relying on crackmonkey firmware, evaluate the error severity based on
what caused the error (GHES subsections).
Signed-off-by: Alexandru Gagniuc
---
drivers/acpi/apei/ghes.c | 48 +
On errors reported from CPER, cper_print_bits() was used to log the
AER bits. This resulted in hard-to-understand messages, without a
prefix. Instead use __aer_print_error() for both native AER and CPER
to provide a more consistent log format.
Signed-off-by: Alexandru Gagniuc
---
Changes since
The use of the 'ghes' argument was removed in a previous commit, but
function signature was not updated to reflect this.
Fixes: 0fe5f281f749 ("EDAC, ghes: Model a single, logical memory controller")
Signed-off-by: Alexandru Gagniuc
---
drivers/acpi/apei/ghes.c | 2 +-
drivers/edac/g
ghes_severity() is a misnomer in this case, as it implies the severity
of the entire GHES structure. Instead, it maps one CPER value to a
monotonically increasing number. ghes_cper_severity() is clearer.
Signed-off-by: Alexandru Gagniuc
---
drivers/acpi/apei/ghes.c | 17 -
1
is on fire,
and they are not severe enough that we need to panic(). Instead of
relying on crackmonkey firmware, evaluate the error severity based on
what caused the error (GHES subsections).
Signed-off-by: Alexandru Gagniuc
---
drivers/acpi/apei/ghes.c | 45 ++
not panic on deferrable errors
- The handlers are put in a mapping and given a common call signature
Alexandru Gagniuc (3):
EDAC, GHES: Remove unused argument to ghes_edac_report_mem_error
acpi: apei: Do not panic() on PCIe errors reported through GHES
acpi: apei: Warn when GHES marks correcta
not fatal to the system. When there
is a disagreement with firmware about the handleability of an error,
print a warning message.
Signed-off-by: Alexandru Gagniuc
---
drivers/acpi/apei/ghes.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/gh
The use of the 'ghes' argument was removed in a previous commit, but
function signature was not updated to reflect this.
Fixes: 0fe5f281f749 ("EDAC, ghes: Model a single, logical memory controller")
Signed-off-by: Alexandru Gagniuc
---
drivers/acpi/apei/ghes.c | 2 +-
drivers/edac/g
is on fire,
and they are not severe enough that we need to panic(). Instead of
relying on crackmonkey firmware, evaluate the error severity based on
what caused the error (GHES subsections).
Signed-off-by: Alexandru Gagniuc
---
drivers/acpi/apei/ghes.c | 48 +
-ENODEV' vs 'goto out', where 'result' happens to be -ENODEV
CC: Keith Busch
Signed-off-by: Alexandru Gagniuc
---
drivers/nvme/host/pci.c | 42 --
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
BIOSes to think that something
bad happened, and print ominous messages on next boot. To prevent this,
tidy up the AER status bits before releasing containment.
Signed-off-by: Alexandru Gagniuc
---
drivers/pci/pcie/dpc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/pci/pcie
:
- Due to popular request, the panic() is left in the NMI handler
- GHES AER handler is split into NMI and non-NMI portions
- ghes_notify_nmi() does not panic on deferrable errors
- The handlers are put in a mapping and given a common call signature
Alexandru Gagniuc (2):
acpi: apei: Rename
1 - 100 of 202 matches
Mail list logo
