* Patch "Input: touchscreen - Fix backport of a02dcde595f7cbd240ccd64de96034ad91cffc40" has been added to the 5.4-stable tree
From: gregkh @ 2022-01-05 15:04 UTC (permalink / raw)
To: anders.roxell, gregkh, llvm, nathan, ndesaulniers, sashal; +Cc: stable-commits
In-Reply-To: <20220103192935.3438038-1-nathan@kernel.org>
This is a note to let you know that I've just added the patch titled
Input: touchscreen - Fix backport of a02dcde595f7cbd240ccd64de96034ad91cffc40
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
input-touchscreen-fix-backport-of-a02dcde595f7cbd240ccd64de96034ad91cffc40.patch
and it can be found in the queue-5.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From nathan@kernel.org Wed Jan 5 16:03:30 2022
From: Nathan Chancellor <nathan@kernel.org>
Date: Mon, 3 Jan 2022 12:29:35 -0700
Subject: Input: touchscreen - Fix backport of a02dcde595f7cbd240ccd64de96034ad91cffc40
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sasha Levin <sashal@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>, stable@vger.kernel.org, llvm@lists.linux.dev, Anders Roxell <anders.roxell@linaro.org>, Nathan Chancellor <nathan@kernel.org>
Message-ID: <20220103192935.3438038-1-nathan@kernel.org>
From: Nathan Chancellor <nathan@kernel.org>
Upstream commit a02dcde595f7 ("Input: touchscreen - avoid bitwise vs
logical OR warning") was applied as commit f6e9e7be9b80 ("Input:
touchscreen - avoid bitwise vs logical OR warning") in linux-5.4.y but
it did not properly account for commit d9265e8a878a ("Input:
of_touchscreen - add support for touchscreen-min-x|y"), which means the
warning mentioned in the commit message is not fully fixed:
drivers/input/touchscreen/of_touchscreen.c:78:17: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-x",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/input/touchscreen/of_touchscreen.c:78:17: note: cast one or both operands to int to silence this warning
drivers/input/touchscreen/of_touchscreen.c:92:17: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-y",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/input/touchscreen/of_touchscreen.c:92:17: note: cast one or both operands to int to silence this warning
2 warnings generated.
It seems like the 4.19 backport was applied to the 5.4 tree, which did
not have any conflicts so no issue was noticed at that point.
Fix up the backport to bring it more in line with the upstream version
so that there is no warning.
Fixes: f6e9e7be9b80 ("Input: touchscreen - avoid bitwise vs logical OR warning")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/touchscreen/of_touchscreen.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/input/touchscreen/of_touchscreen.c
+++ b/drivers/input/touchscreen/of_touchscreen.c
@@ -77,8 +77,8 @@ void touchscreen_parse_properties(struct
axis = multitouch ? ABS_MT_POSITION_X : ABS_X;
data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-x",
input_abs_get_min(input, axis),
- &minimum) |
- touchscreen_get_prop_u32(dev, "touchscreen-size-x",
+ &minimum);
+ data_present |= touchscreen_get_prop_u32(dev, "touchscreen-size-x",
input_abs_get_max(input,
axis) + 1,
&maximum);
@@ -91,8 +91,8 @@ void touchscreen_parse_properties(struct
axis = multitouch ? ABS_MT_POSITION_Y : ABS_Y;
data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-y",
input_abs_get_min(input, axis),
- &minimum) |
- touchscreen_get_prop_u32(dev, "touchscreen-size-y",
+ &minimum);
+ data_present |= touchscreen_get_prop_u32(dev, "touchscreen-size-y",
input_abs_get_max(input,
axis) + 1,
&maximum);
Patches currently in stable-queue which might be from nathan@kernel.org are
queue-5.4/input-touchscreen-fix-backport-of-a02dcde595f7cbd240ccd64de96034ad91cffc40.patch
^ permalink raw reply
* [PATCH 01/11] PCI: pci-bridge-emul: Re-arrange register tests
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
From: Russell King <rmk+kernel@armlinux.org.uk>
Re-arrange the tests for which sets of registers are being accessed so that
it is easier to add further regions later. No functional change.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
[pali: Fix reading old value in pci_bridge_emul_conf_write]
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/pci-bridge-emul.c | 61 ++++++++++++++++++-----------------
1 file changed, 31 insertions(+), 30 deletions(-)
diff --git a/drivers/pci/pci-bridge-emul.c b/drivers/pci/pci-bridge-emul.c
index 033bbeb99176..56b2cb741498 100644
--- a/drivers/pci/pci-bridge-emul.c
+++ b/drivers/pci/pci-bridge-emul.c
@@ -418,25 +418,25 @@ int pci_bridge_emul_conf_read(struct pci_bridge_emul *bridge, int where,
__le32 *cfgspace;
const struct pci_bridge_reg_behavior *behavior;
- if (bridge->has_pcie && reg >= PCI_CAP_PCIE_END) {
- *value = 0;
- return PCIBIOS_SUCCESSFUL;
- }
-
- if (!bridge->has_pcie && reg >= PCI_BRIDGE_CONF_END) {
+ if (reg < PCI_BRIDGE_CONF_END) {
+ /* Emulated PCI space */
+ read_op = bridge->ops->read_base;
+ cfgspace = (__le32 *) &bridge->conf;
+ behavior = bridge->pci_regs_behavior;
+ } else if (!bridge->has_pcie) {
+ /* PCIe space is not implemented, and no PCI capabilities */
*value = 0;
return PCIBIOS_SUCCESSFUL;
- }
-
- if (bridge->has_pcie && reg >= PCI_CAP_PCIE_START) {
+ } else if (reg < PCI_CAP_PCIE_END) {
+ /* Our emulated PCIe capability */
reg -= PCI_CAP_PCIE_START;
read_op = bridge->ops->read_pcie;
cfgspace = (__le32 *) &bridge->pcie_conf;
behavior = bridge->pcie_cap_regs_behavior;
} else {
- read_op = bridge->ops->read_base;
- cfgspace = (__le32 *) &bridge->conf;
- behavior = bridge->pci_regs_behavior;
+ /* Beyond our PCIe space */
+ *value = 0;
+ return PCIBIOS_SUCCESSFUL;
}
if (read_op)
@@ -480,11 +480,27 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where,
__le32 *cfgspace;
const struct pci_bridge_reg_behavior *behavior;
- if (bridge->has_pcie && reg >= PCI_CAP_PCIE_END)
- return PCIBIOS_SUCCESSFUL;
+ ret = pci_bridge_emul_conf_read(bridge, reg, 4, &old);
+ if (ret != PCIBIOS_SUCCESSFUL)
+ return ret;
- if (!bridge->has_pcie && reg >= PCI_BRIDGE_CONF_END)
+ if (reg < PCI_BRIDGE_CONF_END) {
+ /* Emulated PCI space */
+ write_op = bridge->ops->write_base;
+ cfgspace = (__le32 *) &bridge->conf;
+ behavior = bridge->pci_regs_behavior;
+ } else if (!bridge->has_pcie) {
+ /* PCIe space is not implemented, and no PCI capabilities */
return PCIBIOS_SUCCESSFUL;
+ } else if (reg < PCI_CAP_PCIE_END) {
+ /* Our emulated PCIe capability */
+ reg -= PCI_CAP_PCIE_START;
+ write_op = bridge->ops->write_pcie;
+ cfgspace = (__le32 *) &bridge->pcie_conf;
+ behavior = bridge->pcie_cap_regs_behavior;
+ } else {
+ return PCIBIOS_SUCCESSFUL;
+ }
shift = (where & 0x3) * 8;
@@ -497,21 +513,6 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where,
else
return PCIBIOS_BAD_REGISTER_NUMBER;
- ret = pci_bridge_emul_conf_read(bridge, reg, 4, &old);
- if (ret != PCIBIOS_SUCCESSFUL)
- return ret;
-
- if (bridge->has_pcie && reg >= PCI_CAP_PCIE_START) {
- reg -= PCI_CAP_PCIE_START;
- write_op = bridge->ops->write_pcie;
- cfgspace = (__le32 *) &bridge->pcie_conf;
- behavior = bridge->pcie_cap_regs_behavior;
- } else {
- write_op = bridge->ops->write_base;
- cfgspace = (__le32 *) &bridge->conf;
- behavior = bridge->pci_regs_behavior;
- }
-
/* Keep all bits, except the RW bits */
new = old & (~mask | ~behavior[reg / 4].rw);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 00/11] PCI: mvebu: subsystem ids, AER and INTx
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
This patch series extends pci-bridge-emul.c driver to emulate PCI Subsystem
Vendor ID capability and PCIe extended capabilities. And then implement
in pci-mvebu.c driver support for PCI Subsystem Vendor IDs, PCIe AER
registers, support for legacy INTx interrupts, configuration for X1/X4
mode and usage of new PCI child_ops API.
This patch series depends on other pci-mvebu and pci-bridge-emul patches from:
https://lore.kernel.org/linux-pci/20220104153529.31647-1-pali@kernel.org/
Pali Rohár (9):
PCI: pci-bridge-emul: Add support for PCI Bridge Subsystem Vendor ID
capability
dt-bindings: PCI: mvebu: Add num-lanes property
PCI: mvebu: Correctly configure x1/x4 mode
PCI: mvebu: Add support for PCI Bridge Subsystem Vendor ID on emulated
bridge
PCI: mvebu: Add support for Advanced Error Reporting registers on
emulated bridge
PCI: mvebu: Use child_ops API
dt-bindings: PCI: mvebu: Update information about intx interrupts
PCI: mvebu: Implement support for legacy INTx interrupts
ARM: dts: armada-385.dtsi: Add definitions for PCIe legacy INTx
interrupts
Russell King (2):
PCI: pci-bridge-emul: Re-arrange register tests
PCI: pci-bridge-emul: Add support for PCIe extended capabilities
.../devicetree/bindings/pci/mvebu-pci.txt | 16 +
arch/arm/boot/dts/armada-385.dtsi | 52 ++-
drivers/pci/controller/pci-mvebu.c | 352 +++++++++++++++---
drivers/pci/pci-bridge-emul.c | 167 ++++++---
drivers/pci/pci-bridge-emul.h | 17 +
5 files changed, 494 insertions(+), 110 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] softmmu: fix device deletion events with -device JSON syntax
From: Laurent Vivier @ 2022-01-05 15:00 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Kevin Wolf, Eduardo Habkost, Thomas Huth, Peter Krempa,
qemu-devel, Markus Armbruster, Paolo Bonzini, Eric Blake
In-Reply-To: <YdWxZ0DYZT0zDuWP@redhat.com>
On 05/01/2022 15:55, Daniel P. Berrangé wrote:
> On Wed, Jan 05, 2022 at 03:49:12PM +0100, Laurent Vivier wrote:
>> On 05/01/2022 13:38, Daniel P. Berrangé wrote:
>>> The -device JSON syntax impl leaks a reference on the created
>>> DeviceState instance. As a result when you hot-unplug the
>>> device, the device_finalize method won't be called and thus
>>> it will fail to emit the required DEVICE_DELETED event.
>>>
>>> A 'json-cli' feature was previously added against the
>>> 'device_add' QMP command QAPI schema to indicated to mgmt
>>> apps that -device supported JSON syntax. Given the hotplug
>>> bug that feature flag is no unusable for its purpose, so
>>
>> Not sure to understand: do you mean "now unusable"?
>
> An application wants to known whether QEMU can support JSON
> syntax with -device. If they look for the 'json-cli' feature
> as a witness, they'll end up using JSON with QEMU 6.2 which
> is giving them broken hotplug. This is unusable for any
> non-trivial use cases. So we need a new witness to indicate
> whether JSON is viable with -device, that only the newly
> fixed QEMU will report.
I understand that, my problem was with your sentence:
"Given the hotplug bug that feature flag is no unusable for its purpose"
Thanks,
Laurent
^ permalink raw reply
* [PATCH 03/11] PCI: pci-bridge-emul: Add support for PCI Bridge Subsystem Vendor ID capability
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
This is read-only capability in PCI config space. Put it between base PCI
capability and base PCI Express capability.
Driver just have to specify subsystem_vendor_id and subsystem_id fields in
emulated bridge structure and pci-bridge-emul takes care of correctly
compose PCI Bridge Subsystem Vendor ID capability.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/pci-bridge-emul.c | 69 +++++++++++++++++++++++++----------
drivers/pci/pci-bridge-emul.h | 2 +
2 files changed, 51 insertions(+), 20 deletions(-)
diff --git a/drivers/pci/pci-bridge-emul.c b/drivers/pci/pci-bridge-emul.c
index 9f4f173f0650..c84f423a5893 100644
--- a/drivers/pci/pci-bridge-emul.c
+++ b/drivers/pci/pci-bridge-emul.c
@@ -21,8 +21,11 @@
#include "pci-bridge-emul.h"
#define PCI_BRIDGE_CONF_END PCI_STD_HEADER_SIZEOF
+#define PCI_CAP_SSID_SIZEOF (PCI_SSVID_DEVICE_ID + 2)
+#define PCI_CAP_SSID_START PCI_BRIDGE_CONF_END
+#define PCI_CAP_SSID_END (PCI_CAP_SSID_START + PCI_CAP_SSID_SIZEOF)
#define PCI_CAP_PCIE_SIZEOF (PCI_EXP_SLTSTA2 + 2)
-#define PCI_CAP_PCIE_START PCI_BRIDGE_CONF_END
+#define PCI_CAP_PCIE_START PCI_CAP_SSID_END
#define PCI_CAP_PCIE_END (PCI_CAP_PCIE_START + PCI_CAP_PCIE_SIZEOF)
/**
@@ -315,6 +318,25 @@ struct pci_bridge_reg_behavior pcie_cap_regs_behavior[PCI_CAP_PCIE_SIZEOF / 4] =
},
};
+static pci_bridge_emul_read_status_t
+pci_bridge_emul_read_ssid(struct pci_bridge_emul *bridge, int reg, u32 *value)
+{
+ switch (reg) {
+ case PCI_CAP_LIST_ID:
+ *value = PCI_CAP_ID_SSVID |
+ (bridge->has_pcie ? (PCI_CAP_PCIE_START << 8) : 0);
+ return PCI_BRIDGE_EMUL_HANDLED;
+
+ case PCI_SSVID_VENDOR_ID:
+ *value = bridge->subsystem_vendor_id |
+ (bridge->subsystem_id << 16);
+ return PCI_BRIDGE_EMUL_HANDLED;
+
+ default:
+ return PCI_BRIDGE_EMUL_NOT_HANDLED;
+ }
+}
+
/*
* Initialize a pci_bridge_emul structure to represent a fake PCI
* bridge configuration space. The caller needs to have initialized
@@ -337,9 +359,17 @@ int pci_bridge_emul_init(struct pci_bridge_emul *bridge,
if (!bridge->pci_regs_behavior)
return -ENOMEM;
- if (bridge->has_pcie) {
+ if (bridge->subsystem_vendor_id)
+ bridge->conf.capabilities_pointer = PCI_CAP_SSID_START;
+ else if (bridge->has_pcie)
bridge->conf.capabilities_pointer = PCI_CAP_PCIE_START;
+ else
+ bridge->conf.capabilities_pointer = 0;
+
+ if (bridge->conf.capabilities_pointer)
bridge->conf.status |= cpu_to_le16(PCI_STATUS_CAP_LIST);
+
+ if (bridge->has_pcie) {
bridge->pcie_conf.cap_id = PCI_CAP_ID_EXP;
bridge->pcie_conf.cap |= cpu_to_le16(PCI_EXP_TYPE_ROOT_PORT << 4);
bridge->pcie_cap_regs_behavior =
@@ -423,26 +453,28 @@ int pci_bridge_emul_conf_read(struct pci_bridge_emul *bridge, int where,
read_op = bridge->ops->read_base;
cfgspace = (__le32 *) &bridge->conf;
behavior = bridge->pci_regs_behavior;
- } else if (!bridge->has_pcie) {
- /* PCIe space is not implemented, and no PCI capabilities */
- *value = 0;
- return PCIBIOS_SUCCESSFUL;
- } else if (reg < PCI_CAP_PCIE_END) {
+ } else if (reg >= PCI_CAP_SSID_START && reg < PCI_CAP_SSID_END && bridge->subsystem_vendor_id) {
+ /* Emulated PCI Bridge Subsystem Vendor ID capability */
+ reg -= PCI_CAP_SSID_START;
+ read_op = pci_bridge_emul_read_ssid;
+ cfgspace = NULL;
+ behavior = NULL;
+ } else if (reg >= PCI_CAP_PCIE_START && reg < PCI_CAP_PCIE_END && bridge->has_pcie) {
/* Our emulated PCIe capability */
reg -= PCI_CAP_PCIE_START;
read_op = bridge->ops->read_pcie;
cfgspace = (__le32 *) &bridge->pcie_conf;
behavior = bridge->pcie_cap_regs_behavior;
- } else if (reg < PCI_CFG_SPACE_SIZE) {
- /* Rest of PCI space not implemented */
- *value = 0;
- return PCIBIOS_SUCCESSFUL;
- } else {
+ } else if (reg >= PCI_CFG_SPACE_SIZE && bridge->has_pcie) {
/* PCIe extended capability space */
reg -= PCI_CFG_SPACE_SIZE;
read_op = bridge->ops->read_ext;
cfgspace = NULL;
behavior = NULL;
+ } else {
+ /* Not implemented */
+ *value = 0;
+ return PCIBIOS_SUCCESSFUL;
}
if (read_op)
@@ -500,24 +532,21 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where,
write_op = bridge->ops->write_base;
cfgspace = (__le32 *) &bridge->conf;
behavior = bridge->pci_regs_behavior;
- } else if (!bridge->has_pcie) {
- /* PCIe space is not implemented, and no PCI capabilities */
- return PCIBIOS_SUCCESSFUL;
- } else if (reg < PCI_CAP_PCIE_END) {
+ } else if (reg >= PCI_CAP_PCIE_START && reg < PCI_CAP_PCIE_END && bridge->has_pcie) {
/* Our emulated PCIe capability */
reg -= PCI_CAP_PCIE_START;
write_op = bridge->ops->write_pcie;
cfgspace = (__le32 *) &bridge->pcie_conf;
behavior = bridge->pcie_cap_regs_behavior;
- } else if (reg < PCI_CFG_SPACE_SIZE) {
- /* Rest of PCI space not implemented */
- return PCIBIOS_SUCCESSFUL;
- } else {
+ } else if (reg >= PCI_CFG_SPACE_SIZE && bridge->has_pcie) {
/* PCIe extended capability space */
reg -= PCI_CFG_SPACE_SIZE;
write_op = bridge->ops->write_ext;
cfgspace = NULL;
behavior = NULL;
+ } else {
+ /* Not implemented */
+ return PCIBIOS_SUCCESSFUL;
}
shift = (where & 0x3) * 8;
diff --git a/drivers/pci/pci-bridge-emul.h b/drivers/pci/pci-bridge-emul.h
index 6b5f75b2ad02..71392b67471d 100644
--- a/drivers/pci/pci-bridge-emul.h
+++ b/drivers/pci/pci-bridge-emul.h
@@ -132,6 +132,8 @@ struct pci_bridge_emul {
struct pci_bridge_reg_behavior *pcie_cap_regs_behavior;
void *data;
bool has_pcie;
+ u16 subsystem_vendor_id;
+ u16 subsystem_id;
};
enum {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 02/11] PCI: pci-bridge-emul: Add support for PCIe extended capabilities
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
From: Russell King <rmk+kernel@armlinux.org.uk>
Add support for PCIe extended capabilities, which we just redirect to the
emulating driver.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
[pali: Fix writing new value with W1C bits]
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/pci-bridge-emul.c | 77 +++++++++++++++++++++++------------
drivers/pci/pci-bridge-emul.h | 15 +++++++
2 files changed, 67 insertions(+), 25 deletions(-)
diff --git a/drivers/pci/pci-bridge-emul.c b/drivers/pci/pci-bridge-emul.c
index 56b2cb741498..9f4f173f0650 100644
--- a/drivers/pci/pci-bridge-emul.c
+++ b/drivers/pci/pci-bridge-emul.c
@@ -433,10 +433,16 @@ int pci_bridge_emul_conf_read(struct pci_bridge_emul *bridge, int where,
read_op = bridge->ops->read_pcie;
cfgspace = (__le32 *) &bridge->pcie_conf;
behavior = bridge->pcie_cap_regs_behavior;
- } else {
- /* Beyond our PCIe space */
+ } else if (reg < PCI_CFG_SPACE_SIZE) {
+ /* Rest of PCI space not implemented */
*value = 0;
return PCIBIOS_SUCCESSFUL;
+ } else {
+ /* PCIe extended capability space */
+ reg -= PCI_CFG_SPACE_SIZE;
+ read_op = bridge->ops->read_ext;
+ cfgspace = NULL;
+ behavior = NULL;
}
if (read_op)
@@ -444,15 +450,20 @@ int pci_bridge_emul_conf_read(struct pci_bridge_emul *bridge, int where,
else
ret = PCI_BRIDGE_EMUL_NOT_HANDLED;
- if (ret == PCI_BRIDGE_EMUL_NOT_HANDLED)
- *value = le32_to_cpu(cfgspace[reg / 4]);
+ if (ret == PCI_BRIDGE_EMUL_NOT_HANDLED) {
+ if (cfgspace)
+ *value = le32_to_cpu(cfgspace[reg / 4]);
+ else
+ *value = 0;
+ }
/*
* Make sure we never return any reserved bit with a value
* different from 0.
*/
- *value &= behavior[reg / 4].ro | behavior[reg / 4].rw |
- behavior[reg / 4].w1c;
+ if (behavior)
+ *value &= behavior[reg / 4].ro | behavior[reg / 4].rw |
+ behavior[reg / 4].w1c;
if (size == 1)
*value = (*value >> (8 * (where & 3))) & 0xff;
@@ -498,8 +509,15 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where,
write_op = bridge->ops->write_pcie;
cfgspace = (__le32 *) &bridge->pcie_conf;
behavior = bridge->pcie_cap_regs_behavior;
- } else {
+ } else if (reg < PCI_CFG_SPACE_SIZE) {
+ /* Rest of PCI space not implemented */
return PCIBIOS_SUCCESSFUL;
+ } else {
+ /* PCIe extended capability space */
+ reg -= PCI_CFG_SPACE_SIZE;
+ write_op = bridge->ops->write_ext;
+ cfgspace = NULL;
+ behavior = NULL;
}
shift = (where & 0x3) * 8;
@@ -513,29 +531,38 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where,
else
return PCIBIOS_BAD_REGISTER_NUMBER;
- /* Keep all bits, except the RW bits */
- new = old & (~mask | ~behavior[reg / 4].rw);
+ if (behavior) {
+ /* Keep all bits, except the RW bits */
+ new = old & (~mask | ~behavior[reg / 4].rw);
- /* Update the value of the RW bits */
- new |= (value << shift) & (behavior[reg / 4].rw & mask);
+ /* Update the value of the RW bits */
+ new |= (value << shift) & (behavior[reg / 4].rw & mask);
- /* Clear the W1C bits */
- new &= ~((value << shift) & (behavior[reg / 4].w1c & mask));
+ /* Clear the W1C bits */
+ new &= ~((value << shift) & (behavior[reg / 4].w1c & mask));
+ } else {
+ new = old & ~mask;
+ new |= (value << shift) & mask;
+ }
- /* Save the new value with the cleared W1C bits into the cfgspace */
- cfgspace[reg / 4] = cpu_to_le32(new);
+ if (cfgspace) {
+ /* Save the new value with the cleared W1C bits into the cfgspace */
+ cfgspace[reg / 4] = cpu_to_le32(new);
+ }
- /*
- * Clear the W1C bits not specified by the write mask, so that the
- * write_op() does not clear them.
- */
- new &= ~(behavior[reg / 4].w1c & ~mask);
+ if (behavior) {
+ /*
+ * Clear the W1C bits not specified by the write mask, so that the
+ * write_op() does not clear them.
+ */
+ new &= ~(behavior[reg / 4].w1c & ~mask);
- /*
- * Set the W1C bits specified by the write mask, so that write_op()
- * knows about that they are to be cleared.
- */
- new |= (value << shift) & (behavior[reg / 4].w1c & mask);
+ /*
+ * Set the W1C bits specified by the write mask, so that write_op()
+ * knows about that they are to be cleared.
+ */
+ new |= (value << shift) & (behavior[reg / 4].w1c & mask);
+ }
if (write_op)
write_op(bridge, reg, old, new, mask);
diff --git a/drivers/pci/pci-bridge-emul.h b/drivers/pci/pci-bridge-emul.h
index 4953274cac18..6b5f75b2ad02 100644
--- a/drivers/pci/pci-bridge-emul.h
+++ b/drivers/pci/pci-bridge-emul.h
@@ -90,6 +90,14 @@ struct pci_bridge_emul_ops {
*/
pci_bridge_emul_read_status_t (*read_pcie)(struct pci_bridge_emul *bridge,
int reg, u32 *value);
+
+ /*
+ * Same as ->read_base(), except it is for reading from the
+ * PCIe extended capability configuration space.
+ */
+ pci_bridge_emul_read_status_t (*read_ext)(struct pci_bridge_emul *bridge,
+ int reg, u32 *value);
+
/*
* Called when writing to the regular PCI bridge configuration
* space. old is the current value, new is the new value being
@@ -105,6 +113,13 @@ struct pci_bridge_emul_ops {
*/
void (*write_pcie)(struct pci_bridge_emul *bridge, int reg,
u32 old, u32 new, u32 mask);
+
+ /*
+ * Same as ->write_base(), except it is for writing from the
+ * PCIe extended capability configuration space.
+ */
+ void (*write_ext)(struct pci_bridge_emul *bridge, int reg,
+ u32 old, u32 new, u32 mask);
};
struct pci_bridge_reg_behavior;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [LTP] [PATCH v3 2/2] tst_af_alg: TCONF on ciphers disabled by FIPS
From: Eric Biggers @ 2022-01-05 15:04 UTC (permalink / raw)
To: Petr Vorel; +Cc: ltp
In-Reply-To: <20211222192604.16839-2-pvorel@suse.cz>
On Wed, Dec 22, 2021 at 08:26:04PM +0100, Petr Vorel wrote:
> Similar fix to 4fa302ef9d. It fixes:
>
> ./af_alg01
> tst_af_alg.c:84: TBROK: unexpected error binding AF_ALG socket to hash algorithm 'md5': ELIBBAD (80)
> become
> tst_fips.c:22: TINFO: FIPS: on
> tst_af_alg.c:111: TCONF: FIPS enabled => hash algorithm 'md5' disabled
> tst_fips.c:22: TINFO: FIPS: on
> tst_af_alg.c:111: TCONF: FIPS enabled => hash algorithm 'md5-generic' disabled
>
> ./af_alg02
> tst_af_alg.c:37: TBROK: unexpected error binding AF_ALG socket to skcipher algorithm 'salsa20': ELIBBAD (80)
> become
> tst_fips.c:22: TINFO: FIPS: on
> tst_af_alg.c:36: TCONF: FIPS enabled => skcipher algorithm 'salsa20' disabled
>
> ./af_alg04
> tst_af_alg.c:81: TBROK: unexpected error binding AF_ALG socket to hash algorithm 'vmac64(aes)': ELIBBAD (80)
> become
> tst_fips.c:22: TINFO: FIPS: on
> tst_af_alg.c:111: TCONF: FIPS enabled => hash algorithm 'vmac64(aes)' disabled
>
> Tested on Debian stable bullseye and SLES 15-SP4.
>
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
> NOTE: I asked Herbert Xu for confirmation that my code understanding is
> correct and ELIBBAD is expected for ciphers disabled by FIPS.
Can you link to the mailing list thread where it was established that ELIBBAD is
the "expected" behavior? Otherwise I guess this is fine.
Reviewed-by: Eric Biggers <ebiggers@google.com>
- Eric
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply
* Re: [PATCH 5.4] Input: touchscreen - Fix backport of a02dcde595f7cbd240ccd64de96034ad91cffc40
From: Greg Kroah-Hartman @ 2022-01-05 15:04 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Sasha Levin, Nick Desaulniers, stable, llvm, Anders Roxell
In-Reply-To: <20220103192935.3438038-1-nathan@kernel.org>
On Mon, Jan 03, 2022 at 12:29:35PM -0700, Nathan Chancellor wrote:
> Upstream commit a02dcde595f7 ("Input: touchscreen - avoid bitwise vs
> logical OR warning") was applied as commit f6e9e7be9b80 ("Input:
> touchscreen - avoid bitwise vs logical OR warning") in linux-5.4.y but
> it did not properly account for commit d9265e8a878a ("Input:
> of_touchscreen - add support for touchscreen-min-x|y"), which means the
> warning mentioned in the commit message is not fully fixed:
>
> drivers/input/touchscreen/of_touchscreen.c:78:17: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
> data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-x",
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/input/touchscreen/of_touchscreen.c:78:17: note: cast one or both operands to int to silence this warning
> drivers/input/touchscreen/of_touchscreen.c:92:17: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
> data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-y",
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/input/touchscreen/of_touchscreen.c:92:17: note: cast one or both operands to int to silence this warning
> 2 warnings generated.
>
> It seems like the 4.19 backport was applied to the 5.4 tree, which did
> not have any conflicts so no issue was noticed at that point.
>
> Fix up the backport to bring it more in line with the upstream version
> so that there is no warning.
>
> Fixes: f6e9e7be9b80 ("Input: touchscreen - avoid bitwise vs logical OR warning")
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
> drivers/input/touchscreen/of_touchscreen.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Now queued up,t hanks.
greg k-h
^ permalink raw reply
* Re: [PATCH 02/12] ceph: handle idmapped mounts in create_request_message()
From: Jeff Layton @ 2022-01-05 15:03 UTC (permalink / raw)
To: Christian Brauner
Cc: Christian Brauner, ceph-devel, Ilya Dryomov, Christoph Hellwig
In-Reply-To: <20220105141023.vrrbfhti5apdvkz7@wittgenstein>
On Wed, 2022-01-05 at 15:10 +0100, Christian Brauner wrote:
> On Tue, Jan 04, 2022 at 12:40:51PM -0500, Jeff Layton wrote:
> > On Tue, 2022-01-04 at 15:04 +0100, Christian Brauner wrote:
> > > From: Christian Brauner <christian.brauner@ubuntu.com>
> > >
> > > Inode operations that create a new filesystem object such as ->mknod,
> > > ->create, ->mkdir() and others don't take a {g,u}id argument explicitly.
> > > Instead the caller's fs{g,u}id is used for the {g,u}id of the new
> > > filesystem object.
> > >
> > > Cephfs mds creation request argument structures mirror this filesystem
> > > behavior. They don't encode a {g,u}id explicitly. Instead the caller's
> > > fs{g,u}id that is always sent as part of any mds request is used by the
> > > servers to set the {g,u}id of the new filesystem object.
> > >
> > > In order to ensure that the correct {g,u}id is used map the caller's
> > > fs{g,u}id for creation requests. This doesn't require complex changes.
> > > It suffices to pass in the relevant idmapping recorded in the request
> > > message. If this request message was triggered from an inode operation
> > > that creates filesystem objects it will have passed down the relevant
> > > idmaping. If this is a request message that was triggered from an inode
> > > operation that doens't need to take idmappings into account the initial
> > > idmapping is passed down which is an identity mapping and thus is
> > > guaranteed to leave the caller's fs{g,u}id unchanged.,u}id is sent.
> > >
> > > The last few weeks before Christmas 2021 I have spent time not just
> > > reading and poking the cephfs kernel code but also took a look at the
> > > ceph mds server userspace to ensure I didn't miss some subtlety.
> > >
> > > This made me aware of one complication to solve. All requests send the
> > > caller's fs{g,u}id over the wire. The caller's fs{g,u}id matters for the
> > > server in exactly two cases:
> > >
> > > 1. to set the ownership for creation requests
> > > 2. to determine whether this client is allowed access on this server
> > >
> > > Case 1. we already covered and explained. Case 2. is only relevant for
> > > servers where an explicit uid access restriction has been set. That is
> > > to say the mds server restricts access to requests coming from a
> > > specific uid. Servers without uid restrictions will grant access to
> > > requests from any uid by setting MDS_AUTH_UID_ANY.
> > >
> > > Case 2. introduces the complication because the caller's fs{g,u}id is
> > > not just used to record ownership but also serves as the {g,u}id used
> > > when checking access to the server.
> > >
> > > Consider a user mounting a cephfs client and creating an idmapped mount
> > > from it that maps files owned by uid 1000 to be owned uid 0:
> > >
> > > mount -t cephfs -o [...] /unmapped
> > > mount-idmapped --map-mount 1000:0:1 /idmapped
> > >
> > > That is to say if the mounted cephfs filesystem contains a file "file1"
> > > which is owned by uid 1000:
> > >
> > > - looking at it via /unmapped/file1 will report it as owned by uid 1000
> > > (One can think of this as the on-disk value.)
> > > - looking at it via /idmapped/file1 will report it as owned by uid 0
> > >
> > > Now, consider creating new files via the idmapped mount at /idmapped.
> > > When a caller with fs{g,u}id 1000 creates a file "file2" by going
> > > through the idmapped mount mounted at /idmapped it will create a file
> > > that is owned by uid 1000 on-disk, i.e.:
> > >
> > > - looking at it via /unmapped/file2 will report it as owned by uid 1000
> > > - looking at it via /idmapped/file2 will report it as owned by uid 0
> > >
> > > Now consider an mds server that has a uid access restriction set and
> > > only grants access to requests from uid 0.
> > >
> > > If the client sends a creation request for a file e.g. /idmapped/file2
> > > it will send the caller's fs{g,u}id idmapped according to the idmapped
> > > mount. So if the caller has fs{g,u}id 1000 it will be mapped to {g,u}id
> > > 0 in the idmapped mount and will be sent over the wire allowing the
> > > caller access to the mds server.
> > >
> > > However, if the caller is not issuing a creation request the caller's
> > > fs{g,u}id will be send without the mount's idmapping applied. So if the
> > > caller that just successfully created a new file on the restricted mds
> > > server sends a request as fs{g,u}id 1000 access will be refused. This
> > > however is inconsistent.
> > >
> >
> > IDGI, why would you send the fs{g,u}id without the mount's idmapping
> > applied in this case? ISTM that idmapping is wholly a client-side
> > feature, and that you should always map id's regardless of whether
> > you're creating or not.
>
> Since the idmapping is a property of the mount and not a property of the
> caller the caller's fs{g,u}id aren't mapped. What is mapped are the
> inode's i{g,u}id when accessed from a particular mount.
>
> The fs{g,u}id are only ever mapped when a new filesystem object is
> created. So if I have an idmapped mount that makes it so that files
> owned by 1000 on-disk appear to be owned by uid 0 then a user with uid 0
> creating a new file will create files with uid 1000 on-disk when going
> through that mount. For cephfs that'd be the uid we would be sending
> with creation requests as I've currently written it.
>
> So then when the user looks at the file it created it will see it as
> being owned by uid 0 from that idmapped mount (whereas on-disk it's
> 1000). But the user's fs{g,u}id isn't per se changed when going through
> that mount. So in my opinion I was thinking that the server with access
> permissions set would want to always check permissions on the users
> "raw" fs{g,u}id. That would mean I'd have to change the patch obviously.
> My suggestion was to send the {g,u}id the file will be created with
> separately. The alternative would be to not just pass the idmapping into
> the creation iop's but into all iops so that we can always map it for
> cephfs. But this would mean a lot of vfs changes for one filesystem. So
> if we could first explore alternatives approaches I'd be grateful.
>
You'll probably need to do this for NFS anyway, if you have plans in
that direction. Extending the protocol there will be much more
difficult. I think that approach sounds much cleaner overall.
> (I'll be traveling for the latter half of this week starting today at
> CET afternoon so apologies but I'll probably take some time to respond.)
Ok. I guess you can get away with this on a local fs because the backend
storage doesn't really care about uid/gids at all. The only permission
checking is done in the kernel and you (presumably) can just map the
inode's uid/gid prior to checking permissions.
I'm a little confused as to what you mean by "raw" id here. In your
earlier example with a mapping of 1000:0:1, which one is the raw id for
the actual user?
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* [PATCH v3] mm: shmem: implement POSIX_FADV_[WILL|DONT]NEED for shmem
From: Charan Teja Reddy @ 2022-01-05 15:03 UTC (permalink / raw)
To: hughd, akpm, willy, vbabka, rientjes, mhocko, surenb, shakeelb,
linux-mm
Cc: linux-kernel, Charan Teja Reddy, Charan Teja Reddy
From: Charan Teja Reddy <charante@codeaurora.org>
Currently fadvise(2) is supported only for the files that doesn't
associated with noop_backing_dev_info thus for the files, like shmem,
fadvise results into NOP. But then there is file_operations->fadvise()
that lets the file systems to implement their own fadvise
implementation. Use this support to implement some of the POSIX_FADV_XXX
functionality for shmem files.
This patch aims to implement POSIX_FADV_WILLNEED and POSIX_FADV_DONTNEED
advices to shmem files which can be helpful for the drivers who may want
to manage the shmem pages of the files that are created through
shmem_file_setup[_with_mnt](). An example usecase may be like, driver
can create the shmem file of the size equal to its requirements and
map the pages for DMA and then pass the fd to user. The user who knows
well about the usage of these pages can now decide when these pages are
not required push them to swap through DONTNEED thus free up memory well
in advance rather than relying on the reclaim and use WILLNEED when it
decide that they are useful in the near future. IOW, it lets the clients
to free up/read the memory when it wants to. Another usecase is that GEM
objets which are currenlty allocated and managed through shmem files can
use vfs_fadvise(DONT|WILLNEED) on shmem fd when the driver comes to
know(like through some hints from user space) that GEM objects are not
going to use/will need in the near future.
Some questions asked while reviewing this patch:
Q) Can the same thing be achieved with FD mapped to user and use
madvise?
A) All drivers are not mapping all the shmem fd's to user space and want
to manage them with in the kernel. Ex: shmem memory can be mapped to the
other subsystems and they fill in the data and then give it to other
subsystem for further processing, where, the user mapping is not at all
required. A simple example, memory that is given for gpu subsystem
which can be filled directly and give to display subsystem. And the
respective drivers know well about when to keep that memory in ram or
swap based on may be a user activity.
Q) Should we add the documentation section in Manual pages?
A) The man[1] pages for the fadvise() whatever says is also applicable
for shmem files. so couldn't feel it correct to add specific to shmem
files separately.
[1] https://linux.die.net/man/2/fadvise
Q) The proposed semantics of POSIX_FADV_DONTNEED is actually similar to
MADV_PAGEOUT and different from MADV_DONTNEED. This is a user facing API
and this difference will cause confusion?
A) man pages [1] says that "POSIX_FADV_DONTNEED attempts to free cached
pages associated with the specified region." This means on issuing this
FADV, it is expected to free the file cache pages. And it is
implementation defined If the dirty pages may be attempted to writeback.
And the unwritten dirty pages will not be freed. So, FADV_DONTNEED also
covers the semantics of MADV_PAGEOUT for file pages and there is no
purpose of PAGEOUT for file pages.
[1] https://man7.org/linux/man-pages/man2/posix_fadvise.2.html
Signed-off-by: Charan Teja Reddy <quic_charante@quicinc.com>
---
Changes in V3:
-- Considered THP pages while doing FADVISE_[DONT|WILL]NEED, identified by Matthew.
-- xarray used properly, as identified by Matthew.
-- Excluded mapped pages as it requires unmapping and the man pages of fadvise don't talk about them.
Changes in V2:
-- Rearranged the code to not to sleep with rcu_lock while using xas_() functionality.
-- Addressed the comments from Suren.
-- https://patchwork.kernel.org/project/linux-mm/patch/1638442253-1591-1-git-send-email-quic_charante@quicinc.com/
changes in V1:
-- Created the interface for fadvise(2) to work on shmem files.
-- https://patchwork.kernel.org/project/linux-mm/patch/1633701982-22302-1-git-send-email-charante@codeaurora.org/
mm/shmem.c | 172 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 172 insertions(+)
diff --git a/mm/shmem.c b/mm/shmem.c
index 18f93c2..35c3161 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -39,6 +39,8 @@
#include <linux/frontswap.h>
#include <linux/fs_parser.h>
#include <linux/swapfile.h>
+#include <linux/mm_inline.h>
+#include <linux/fadvise.h>
static struct vfsmount *shm_mnt;
@@ -2791,6 +2793,175 @@ static long shmem_fallocate(struct file *file, int mode, loff_t offset,
return error;
}
+static void shmem_isolate_pages_range(struct address_space *mapping, loff_t start,
+ loff_t end, struct list_head *list)
+{
+ XA_STATE(xas, &mapping->i_pages, start);
+ struct page *page;
+
+ rcu_read_lock();
+ xas_for_each(&xas, page, end) {
+ if (xas_retry(&xas, page))
+ continue;
+ if (xa_is_value(page))
+ continue;
+ if (!get_page_unless_zero(page))
+ continue;
+ if (isolate_lru_page(page))
+ continue;
+
+ list_add(&page->lru, list);
+ __mod_node_page_state(page_pgdat(page),
+ NR_ISOLATED_ANON + page_is_file_lru(page), compound_nr(page));
+ put_page(page);
+ if (need_resched()) {
+ xas_pause(&xas);
+ cond_resched_rcu();
+ }
+ }
+ rcu_read_unlock();
+}
+
+static int shmem_fadvise_dontneed(struct address_space *mapping, loff_t start,
+ loff_t end)
+{
+ int ret;
+ struct page *page;
+ LIST_HEAD(list);
+ struct writeback_control wbc = {
+ .sync_mode = WB_SYNC_NONE,
+ .nr_to_write = LONG_MAX,
+ .range_start = 0,
+ .range_end = LLONG_MAX,
+ .for_reclaim = 1,
+ };
+
+ if (!shmem_mapping(mapping))
+ return -EINVAL;
+
+ if (!total_swap_pages)
+ return 0;
+
+ lru_add_drain();
+ shmem_isolate_pages_range(mapping, start, end, &list);
+
+ while (!list_empty(&list)) {
+ page = lru_to_page(&list);
+ list_del(&page->lru);
+ if (page_mapped(page))
+ goto keep;
+ if (!trylock_page(page))
+ goto keep;
+ if (unlikely(PageTransHuge(page))) {
+ if (split_huge_page_to_list(page, &list))
+ goto keep;
+ }
+
+ clear_page_dirty_for_io(page);
+ SetPageReclaim(page);
+ ret = shmem_writepage(page, &wbc);
+ if (ret || PageWriteback(page)) {
+ if (ret)
+ unlock_page(page);
+ goto keep;
+ }
+
+ if (!PageWriteback(page))
+ ClearPageReclaim(page);
+
+ /*
+ * shmem_writepage() place the page in the swapcache.
+ * Delete the page from the swapcache and release the
+ * page.
+ */
+ __mod_node_page_state(page_pgdat(page),
+ NR_ISOLATED_ANON + page_is_file_lru(page), compound_nr(page));
+ lock_page(page);
+ delete_from_swap_cache(page);
+ unlock_page(page);
+ put_page(page);
+ continue;
+keep:
+ putback_lru_page(page);
+ __mod_node_page_state(page_pgdat(page),
+ NR_ISOLATED_ANON + page_is_file_lru(page), compound_nr(page));
+ }
+
+ return 0;
+}
+
+static int shmem_fadvise_willneed(struct address_space *mapping,
+ pgoff_t start, pgoff_t long end)
+{
+ XA_STATE(xas, &mapping->i_pages, start);
+ struct page *page;
+
+ rcu_read_lock();
+ xas_for_each(&xas, page, end) {
+ if (!xa_is_value(page))
+ continue;
+ xas_pause(&xas);
+ rcu_read_unlock();
+
+ page = shmem_read_mapping_page(mapping, xas.xa_index);
+ if (!IS_ERR(page))
+ put_page(page);
+
+ rcu_read_lock();
+ if (need_resched()) {
+ xas_pause(&xas);
+ cond_resched_rcu();
+ }
+ }
+ rcu_read_unlock();
+
+ return 0;
+}
+
+static int shmem_fadvise(struct file *file, loff_t offset, loff_t len, int advice)
+{
+ loff_t endbyte;
+ pgoff_t start_index;
+ pgoff_t end_index;
+ struct address_space *mapping;
+ int ret = 0;
+
+ mapping = file->f_mapping;
+ if (!mapping || len < 0)
+ return -EINVAL;
+
+ endbyte = (u64)offset + (u64)len;
+ if (!len || endbyte < len)
+ endbyte = -1;
+ else
+ endbyte--;
+
+
+ start_index = offset >> PAGE_SHIFT;
+ end_index = endbyte >> PAGE_SHIFT;
+ switch (advice) {
+ case POSIX_FADV_DONTNEED:
+ ret = shmem_fadvise_dontneed(mapping, start_index, end_index);
+ break;
+ case POSIX_FADV_WILLNEED:
+ ret = shmem_fadvise_willneed(mapping, start_index, end_index);
+ break;
+ case POSIX_FADV_NORMAL:
+ case POSIX_FADV_RANDOM:
+ case POSIX_FADV_SEQUENTIAL:
+ case POSIX_FADV_NOREUSE:
+ /*
+ * No bad return value, but ignore advice. May have to
+ * implement in future.
+ */
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
static int shmem_statfs(struct dentry *dentry, struct kstatfs *buf)
{
struct shmem_sb_info *sbinfo = SHMEM_SB(dentry->d_sb);
@@ -3777,6 +3948,7 @@ static const struct file_operations shmem_file_operations = {
.splice_write = iter_file_splice_write,
.fallocate = shmem_fallocate,
#endif
+ .fadvise = shmem_fadvise,
};
static const struct inode_operations shmem_inode_operations = {
--
2.7.4
^ permalink raw reply related
* [PATCH 11/11] ARM: dts: armada-385.dtsi: Add definitions for PCIe legacy INTx interrupts
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King,
Andrew Lunn, Gregory Clement
Cc: linux-pci, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
With this change legacy INTA, INTB, INTC and INTD interrupts are reported
separately and not mixed into one Linux virq source anymore.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
arch/arm/boot/dts/armada-385.dtsi | 52 ++++++++++++++++++++++++++-----
1 file changed, 44 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385.dtsi b/arch/arm/boot/dts/armada-385.dtsi
index f0022d10c715..83392b92dae2 100644
--- a/arch/arm/boot/dts/armada-385.dtsi
+++ b/arch/arm/boot/dts/armada-385.dtsi
@@ -69,16 +69,25 @@
reg = <0x0800 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
+ interrupt-names = "intx";
+ interrupts-extended = <&gic GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
#interrupt-cells = <1>;
ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0
0x81000000 0 0 0x81000000 0x1 0 1 0>;
bus-range = <0x00 0xff>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie1_intc 0>,
+ <0 0 0 2 &pcie1_intc 1>,
+ <0 0 0 3 &pcie1_intc 2>,
+ <0 0 0 4 &pcie1_intc 3>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <0>;
clocks = <&gateclk 8>;
status = "disabled";
+ pcie1_intc: interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
};
/* x1 port */
@@ -88,16 +97,25 @@
reg = <0x1000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
+ interrupt-names = "intx";
+ interrupts-extended = <&gic GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
#interrupt-cells = <1>;
ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
0x81000000 0 0 0x81000000 0x2 0 1 0>;
bus-range = <0x00 0xff>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie2_intc 0>,
+ <0 0 0 2 &pcie2_intc 1>,
+ <0 0 0 3 &pcie2_intc 2>,
+ <0 0 0 4 &pcie2_intc 3>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <0>;
clocks = <&gateclk 5>;
status = "disabled";
+ pcie2_intc: interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
};
/* x1 port */
@@ -107,16 +125,25 @@
reg = <0x1800 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
+ interrupt-names = "intx";
+ interrupts-extended = <&gic GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
#interrupt-cells = <1>;
ranges = <0x82000000 0 0 0x82000000 0x3 0 1 0
0x81000000 0 0 0x81000000 0x3 0 1 0>;
bus-range = <0x00 0xff>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie3_intc 0>,
+ <0 0 0 2 &pcie3_intc 1>,
+ <0 0 0 3 &pcie3_intc 2>,
+ <0 0 0 4 &pcie3_intc 3>;
marvell,pcie-port = <2>;
marvell,pcie-lane = <0>;
clocks = <&gateclk 6>;
status = "disabled";
+ pcie3_intc: interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
};
/*
@@ -129,16 +156,25 @@
reg = <0x2000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
+ interrupt-names = "intx";
+ interrupts-extended = <&gic GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
#interrupt-cells = <1>;
ranges = <0x82000000 0 0 0x82000000 0x4 0 1 0
0x81000000 0 0 0x81000000 0x4 0 1 0>;
bus-range = <0x00 0xff>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie4_intc 0>,
+ <0 0 0 2 &pcie4_intc 1>,
+ <0 0 0 3 &pcie4_intc 2>,
+ <0 0 0 4 &pcie4_intc 3>;
marvell,pcie-port = <3>;
marvell,pcie-lane = <0>;
clocks = <&gateclk 7>;
status = "disabled";
+ pcie4_intc: interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
};
};
};
--
2.20.1
^ permalink raw reply related
* Re: [LTP] [PATCH v3 1/2] tst_af_alg: Moving tst_res(TCONF) to tst_have_alg()
From: Eric Biggers @ 2022-01-05 15:03 UTC (permalink / raw)
To: Petr Vorel; +Cc: ltp
In-Reply-To: <20211222192604.16839-1-pvorel@suse.cz>
On Wed, Dec 22, 2021 at 08:26:03PM +0100, Petr Vorel wrote:
> + introduce tst_try_alg() for cases where tst_res(TCONF) cannot be used.
>
> It reduces duplicity for tst_have_alg() use.
>
> Suggested-by: Cyril Hrubis <chrubis@suse.cz>
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Eric Biggers <ebiggers@google.com>
- Eric
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply
* [PATCH 10/11] PCI: mvebu: Implement support for legacy INTx interrupts
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King,
Marc Zyngier
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
This adds support for legacy INTx interrupts received from other PCIe
devices and which are reported by a new INTx irq chip.
With this change, kernel can distinguish between INTA, INTB, INTC and INTD
interrupts.
Note that for this support, device tree files has to be properly adjusted
to provide "interrupts" or "interrupts-extended" property with intx
interrupt source, "interrupt-names" property with "intx" string and also
'interrupt-controller' subnode must be defined.
If device tree files do not provide these nodes then driver would work as
before.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 182 +++++++++++++++++++++++++++--
1 file changed, 174 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 1e90ab888075..04bcdd7b7a6d 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -54,9 +54,10 @@
PCIE_CONF_ADDR_EN)
#define PCIE_CONF_DATA_OFF 0x18fc
#define PCIE_INT_CAUSE_OFF 0x1900
+#define PCIE_INT_UNMASK_OFF 0x1910
+#define PCIE_INT_INTX(i) BIT(24+i)
#define PCIE_INT_PM_PME BIT(28)
-#define PCIE_MASK_OFF 0x1910
-#define PCIE_MASK_ENABLE_INTS 0x0f000000
+#define PCIE_INT_ALL_MASK GENMASK(31, 0)
#define PCIE_CTRL_OFF 0x1a00
#define PCIE_CTRL_X1_MODE 0x0001
#define PCIE_CTRL_RC_MODE BIT(1)
@@ -110,6 +111,10 @@ struct mvebu_pcie_port {
struct mvebu_pcie_window iowin;
u32 saved_pcie_stat;
struct resource regs;
+ struct irq_domain *intx_irq_domain;
+ struct irq_chip intx_irq_chip;
+ raw_spinlock_t irq_lock;
+ int intx_irq;
};
static inline void mvebu_writel(struct mvebu_pcie_port *port, u32 val, u32 reg)
@@ -235,7 +240,7 @@ static void mvebu_pcie_setup_wins(struct mvebu_pcie_port *port)
static void mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
{
- u32 ctrl, lnkcap, cmd, dev_rev, mask;
+ u32 ctrl, lnkcap, cmd, dev_rev, unmask;
/* Setup PCIe controller to Root Complex mode. */
ctrl = mvebu_readl(port, PCIE_CTRL_OFF);
@@ -288,10 +293,30 @@ static void mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
/* Point PCIe unit MBUS decode windows to DRAM space. */
mvebu_pcie_setup_wins(port);
- /* Enable interrupt lines A-D. */
- mask = mvebu_readl(port, PCIE_MASK_OFF);
- mask |= PCIE_MASK_ENABLE_INTS;
- mvebu_writel(port, mask, PCIE_MASK_OFF);
+ /* Mask all interrupt sources. */
+ mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_UNMASK_OFF);
+
+ /* Clear all interrupt causes. */
+ mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_CAUSE_OFF);
+
+ if (port->intx_irq <= 0) {
+ /*
+ * When neither "summary" interrupt, nor "intx" interrupt was
+ * specified in DT then unmask all legacy INTx interrupts as in
+ * this case driver does not provide a way for masking and
+ * unmasking of individual legacy INTx interrupts. In this case
+ * all interrupts, including legacy INTx are reported via one
+ * shared GIC source and therefore kernel cannot distinguish
+ * which individual legacy INTx was triggered. These interrupts
+ * are shared, so it should not cause any issue. Just
+ * performance penalty as every PCIe interrupt handler needs to
+ * be called when some interrupt is triggered.
+ */
+ unmask = mvebu_readl(port, PCIE_INT_UNMASK_OFF);
+ unmask |= PCIE_INT_INTX(0) | PCIE_INT_INTX(1) |
+ PCIE_INT_INTX(2) | PCIE_INT_INTX(3);
+ mvebu_writel(port, unmask, PCIE_INT_UNMASK_OFF);
+ }
}
static struct mvebu_pcie_port *mvebu_pcie_find_port(struct mvebu_pcie *pcie,
@@ -924,6 +949,109 @@ static struct pci_ops mvebu_pcie_ops = {
.write = mvebu_pcie_wr_conf,
};
+static void mvebu_pcie_intx_irq_mask(struct irq_data *d)
+{
+ struct mvebu_pcie_port *port = d->domain->host_data;
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ unsigned long flags;
+ u32 unmask;
+
+ raw_spin_lock_irqsave(&port->irq_lock, flags);
+ unmask = mvebu_readl(port, PCIE_INT_UNMASK_OFF);
+ unmask &= ~PCIE_INT_INTX(hwirq);
+ mvebu_writel(port, unmask, PCIE_INT_UNMASK_OFF);
+ raw_spin_unlock_irqrestore(&port->irq_lock, flags);
+}
+
+static void mvebu_pcie_intx_irq_unmask(struct irq_data *d)
+{
+ struct mvebu_pcie_port *port = d->domain->host_data;
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ unsigned long flags;
+ u32 unmask;
+
+ raw_spin_lock_irqsave(&port->irq_lock, flags);
+ unmask = mvebu_readl(port, PCIE_INT_UNMASK_OFF);
+ unmask |= PCIE_INT_INTX(hwirq);
+ mvebu_writel(port, unmask, PCIE_INT_UNMASK_OFF);
+ raw_spin_unlock_irqrestore(&port->irq_lock, flags);
+}
+
+static int mvebu_pcie_intx_irq_map(struct irq_domain *h,
+ unsigned int virq, irq_hw_number_t hwirq)
+{
+ struct mvebu_pcie_port *port = h->host_data;
+
+ irq_set_status_flags(virq, IRQ_LEVEL);
+ irq_set_chip_and_handler(virq, &port->intx_irq_chip, handle_level_irq);
+ irq_set_chip_data(virq, port);
+
+ return 0;
+}
+
+static const struct irq_domain_ops mvebu_pcie_intx_irq_domain_ops = {
+ .map = mvebu_pcie_intx_irq_map,
+ .xlate = irq_domain_xlate_onecell,
+};
+
+static int mvebu_pcie_init_irq_domain(struct mvebu_pcie_port *port)
+{
+ struct device *dev = &port->pcie->pdev->dev;
+ struct device_node *pcie_intc_node;
+
+ raw_spin_lock_init(&port->irq_lock);
+
+ port->intx_irq_chip.name = devm_kasprintf(dev, GFP_KERNEL,
+ "mvebu-%s-INTx",
+ port->name);
+ port->intx_irq_chip.irq_mask = mvebu_pcie_intx_irq_mask;
+ port->intx_irq_chip.irq_unmask = mvebu_pcie_intx_irq_unmask;
+
+ pcie_intc_node = of_get_next_child(port->dn, NULL);
+ if (!pcie_intc_node) {
+ dev_err(dev, "No PCIe Intc node found for %s\n", port->name);
+ return -ENODEV;
+ }
+
+ port->intx_irq_domain = irq_domain_add_linear(pcie_intc_node, PCI_NUM_INTX,
+ &mvebu_pcie_intx_irq_domain_ops,
+ port);
+ of_node_put(pcie_intc_node);
+ if (!port->intx_irq_domain) {
+ devm_kfree(dev, port->intx_irq_chip.name);
+ dev_err(dev, "Failed to get INTx IRQ domain for %s\n", port->name);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static void mvebu_pcie_irq_handler(struct irq_desc *desc)
+{
+ struct mvebu_pcie_port *port = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct device *dev = &port->pcie->pdev->dev;
+ u32 cause, unmask, status;
+ int i;
+
+ chained_irq_enter(chip, desc);
+
+ cause = mvebu_readl(port, PCIE_INT_CAUSE_OFF);
+ unmask = mvebu_readl(port, PCIE_INT_UNMASK_OFF);
+ status = cause & unmask;
+
+ /* Process legacy INTx interrupts */
+ for (i = 0; i < PCI_NUM_INTX; i++) {
+ if (!(status & PCIE_INT_INTX(i)))
+ continue;
+
+ if (generic_handle_domain_irq(port->intx_irq_domain, i) == -EINVAL)
+ dev_err_ratelimited(dev, "unexpected INT%c IRQ\n", (char)i+'A');
+ }
+
+ chained_irq_exit(chip, desc);
+}
+
static int mvebu_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
{
/* Interrupt support on mvebu emulated bridges is not implemented yet */
@@ -1121,6 +1249,16 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
port->io_attr = -1;
}
+ /*
+ * Old DT bindings do not contain "intx" interrupt
+ * so do not fail probing driver when interrupt does not exist.
+ */
+ port->intx_irq = of_irq_get_byname(child, "intx");
+ if (port->intx_irq == -EPROBE_DEFER) {
+ ret = port->intx_irq;
+ goto err;
+ }
+
reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, &flags);
if (reset_gpio == -EPROBE_DEFER) {
ret = reset_gpio;
@@ -1317,6 +1455,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
for (i = 0; i < pcie->nports; i++) {
struct mvebu_pcie_port *port = &pcie->ports[i];
+ int irq = port->intx_irq;
child = port->dn;
if (!child)
@@ -1344,6 +1483,22 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
continue;
}
+ if (irq > 0) {
+ ret = mvebu_pcie_init_irq_domain(port);
+ if (ret) {
+ dev_err(dev, "%s: cannot init irq domain\n",
+ port->name);
+ pci_bridge_emul_cleanup(&port->bridge);
+ devm_iounmap(dev, port->base);
+ port->base = NULL;
+ mvebu_pcie_powerdown(port);
+ continue;
+ }
+ irq_set_chained_handler_and_data(irq,
+ mvebu_pcie_irq_handler,
+ port);
+ }
+
/*
* PCIe topology exported by mvebu hw is quite complicated. In
* reality has something like N fully independent host bridges
@@ -1448,6 +1603,7 @@ static int mvebu_pcie_remove(struct platform_device *pdev)
for (i = 0; i < pcie->nports; i++) {
struct mvebu_pcie_port *port = &pcie->ports[i];
+ int irq = port->intx_irq;
if (!port->base)
continue;
@@ -1458,7 +1614,17 @@ static int mvebu_pcie_remove(struct platform_device *pdev)
mvebu_writel(port, cmd, PCIE_CMD_OFF);
/* Mask all interrupt sources. */
- mvebu_writel(port, 0, PCIE_MASK_OFF);
+ mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_UNMASK_OFF);
+
+ /* Clear all interrupt causes. */
+ mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_CAUSE_OFF);
+
+ /* Remove IRQ domains. */
+ if (port->intx_irq_domain)
+ irq_domain_remove(port->intx_irq_domain);
+
+ if (irq > 0)
+ irq_set_chained_handler_and_data(irq, NULL, NULL);
/* Free config space for emulated root bridge. */
pci_bridge_emul_cleanup(&port->bridge);
--
2.20.1
^ permalink raw reply related
* [PATCH 08/11] PCI: mvebu: Use child_ops API
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
Split struct pci_ops between ops and child_ops. Member ops is used for
accessing PCIe Root Ports via pci-bridge-emul.c driver and child_ops for
accessing real PCIe cards.
There is no need to mix these two struct pci_ops into one as PCI core code
already provides separate callbacks via bridge->ops and bridge->child_ops.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 82 ++++++++++++++++--------------
1 file changed, 44 insertions(+), 38 deletions(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 9ea2f6a7c2b0..1e90ab888075 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -294,11 +294,29 @@ static void mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
mvebu_writel(port, mask, PCIE_MASK_OFF);
}
-static int mvebu_pcie_hw_rd_conf(struct mvebu_pcie_port *port,
- struct pci_bus *bus,
- u32 devfn, int where, int size, u32 *val)
+static struct mvebu_pcie_port *mvebu_pcie_find_port(struct mvebu_pcie *pcie,
+ struct pci_bus *bus,
+ int devfn);
+
+static int mvebu_pcie_child_rd_conf(struct pci_bus *bus, u32 devfn, int where,
+ int size, u32 *val)
{
- void __iomem *conf_data = port->base + PCIE_CONF_DATA_OFF;
+ struct mvebu_pcie *pcie = bus->sysdata;
+ struct mvebu_pcie_port *port;
+ void __iomem *conf_data;
+
+ port = mvebu_pcie_find_port(pcie, bus, devfn);
+ if (!port) {
+ *val = 0xffffffff;
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ }
+
+ if (!mvebu_pcie_link_up(port)) {
+ *val = 0xffffffff;
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ }
+
+ conf_data = port->base + PCIE_CONF_DATA_OFF;
mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where),
PCIE_CONF_ADDR_OFF);
@@ -321,11 +339,21 @@ static int mvebu_pcie_hw_rd_conf(struct mvebu_pcie_port *port,
return PCIBIOS_SUCCESSFUL;
}
-static int mvebu_pcie_hw_wr_conf(struct mvebu_pcie_port *port,
- struct pci_bus *bus,
- u32 devfn, int where, int size, u32 val)
+static int mvebu_pcie_child_wr_conf(struct pci_bus *bus, u32 devfn,
+ int where, int size, u32 val)
{
- void __iomem *conf_data = port->base + PCIE_CONF_DATA_OFF;
+ struct mvebu_pcie *pcie = bus->sysdata;
+ struct mvebu_pcie_port *port;
+ void __iomem *conf_data;
+
+ port = mvebu_pcie_find_port(pcie, bus, devfn);
+ if (!port)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ if (!mvebu_pcie_link_up(port))
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ conf_data = port->base + PCIE_CONF_DATA_OFF;
mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where),
PCIE_CONF_ADDR_OFF);
@@ -347,6 +375,11 @@ static int mvebu_pcie_hw_wr_conf(struct mvebu_pcie_port *port,
return PCIBIOS_SUCCESSFUL;
}
+static struct pci_ops mvebu_pcie_child_ops = {
+ .read = mvebu_pcie_child_rd_conf,
+ .write = mvebu_pcie_child_wr_conf,
+};
+
/*
* Remove windows, starting from the largest ones to the smallest
* ones.
@@ -862,25 +895,12 @@ static int mvebu_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
{
struct mvebu_pcie *pcie = bus->sysdata;
struct mvebu_pcie_port *port;
- int ret;
port = mvebu_pcie_find_port(pcie, bus, devfn);
if (!port)
return PCIBIOS_DEVICE_NOT_FOUND;
- /* Access the emulated PCI-to-PCI bridge */
- if (bus->number == 0)
- return pci_bridge_emul_conf_write(&port->bridge, where,
- size, val);
-
- if (!mvebu_pcie_link_up(port))
- return PCIBIOS_DEVICE_NOT_FOUND;
-
- /* Access the real PCIe interface */
- ret = mvebu_pcie_hw_wr_conf(port, bus, devfn,
- where, size, val);
-
- return ret;
+ return pci_bridge_emul_conf_write(&port->bridge, where, size, val);
}
/* PCI configuration space read function */
@@ -889,7 +909,6 @@ static int mvebu_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
{
struct mvebu_pcie *pcie = bus->sysdata;
struct mvebu_pcie_port *port;
- int ret;
port = mvebu_pcie_find_port(pcie, bus, devfn);
if (!port) {
@@ -897,21 +916,7 @@ static int mvebu_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
return PCIBIOS_DEVICE_NOT_FOUND;
}
- /* Access the emulated PCI-to-PCI bridge */
- if (bus->number == 0)
- return pci_bridge_emul_conf_read(&port->bridge, where,
- size, val);
-
- if (!mvebu_pcie_link_up(port)) {
- *val = 0xffffffff;
- return PCIBIOS_DEVICE_NOT_FOUND;
- }
-
- /* Access the real PCIe interface */
- ret = mvebu_pcie_hw_rd_conf(port, bus, devfn,
- where, size, val);
-
- return ret;
+ return pci_bridge_emul_conf_read(&port->bridge, where, size, val);
}
static struct pci_ops mvebu_pcie_ops = {
@@ -1421,6 +1426,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
bridge->sysdata = pcie;
bridge->ops = &mvebu_pcie_ops;
+ bridge->child_ops = &mvebu_pcie_child_ops;
bridge->align_resource = mvebu_pcie_align_resource;
bridge->map_irq = mvebu_pcie_map_irq;
--
2.20.1
^ permalink raw reply related
* [PATCH 09/11] dt-bindings: PCI: mvebu: Update information about intx interrupts
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King,
Andrew Lunn, Gregory Clement
Cc: linux-pci, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
Signed-off-by: Pali Rohár <pali@kernel.org>
---
Documentation/devicetree/bindings/pci/mvebu-pci.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 24225852bce0..6d022a9d36ee 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -81,6 +81,11 @@ and the following optional properties:
- reset-gpios: optional GPIO to PERST#
- reset-delay-us: delay in us to wait after reset de-assertion, if not
specified will default to 100ms, as required by the PCIe specification.
+- interrupt-names: list of interrupt names, supported are:
+ - "intx" - interrupt line triggered by one of the legacy interrupt
+- interrupts or interrupts-extended: List of the interrupt sources which
+ corresponding to the "interrupt-names". If non-empty then also additional
+ 'interrupt-controller' subnode must be defined.
Example:
--
2.20.1
^ permalink raw reply related
* [PATCH 05/11] PCI: mvebu: Correctly configure x1/x4 mode
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
If x1/x4 mode is not set correctly then link with endpoint card is not
established.
Use DTS property 'num-lanes' to deteriminate x1/x4 mode.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index a075ba26cff1..0f2ec0a17874 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -93,6 +93,7 @@ struct mvebu_pcie_port {
void __iomem *base;
u32 port;
u32 lane;
+ bool is_x4;
int devfn;
unsigned int mem_target;
unsigned int mem_attr;
@@ -233,13 +234,25 @@ static void mvebu_pcie_setup_wins(struct mvebu_pcie_port *port)
static void mvebu_pcie_setup_hw(struct mvebu_pcie_port *port)
{
- u32 ctrl, cmd, dev_rev, mask;
+ u32 ctrl, lnkcap, cmd, dev_rev, mask;
/* Setup PCIe controller to Root Complex mode. */
ctrl = mvebu_readl(port, PCIE_CTRL_OFF);
ctrl |= PCIE_CTRL_RC_MODE;
mvebu_writel(port, ctrl, PCIE_CTRL_OFF);
+ /*
+ * Set Maximum Link Width to X1 or X4 in Root Port's PCIe Link
+ * Capability register. This register is defined by PCIe specification
+ * as read-only but this mvebu controller has it as read-write and must
+ * be set to number of SerDes PCIe lanes (1 or 4). If this register is
+ * not set correctly then link with endpoint card is not established.
+ */
+ lnkcap = mvebu_readl(port, PCIE_CAP_PCIEXP + PCI_EXP_LNKCAP);
+ lnkcap &= ~PCI_EXP_LNKCAP_MLW;
+ lnkcap |= (port->is_x4 ? 4 : 1) << 4;
+ mvebu_writel(port, lnkcap, PCIE_CAP_PCIEXP + PCI_EXP_LNKCAP);
+
/* Disable Root Bridge I/O space, memory space and bus mastering. */
cmd = mvebu_readl(port, PCIE_CMD_OFF);
cmd &= ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER);
@@ -986,6 +999,7 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
struct device *dev = &pcie->pdev->dev;
enum of_gpio_flags flags;
int reset_gpio, ret;
+ u32 num_lanes;
port->pcie = pcie;
@@ -998,6 +1012,9 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
if (of_property_read_u32(child, "marvell,pcie-lane", &port->lane))
port->lane = 0;
+ if (!of_property_read_u32(child, "num-lanes", &num_lanes) && num_lanes == 4)
+ port->is_x4 = true;
+
port->name = devm_kasprintf(dev, GFP_KERNEL, "pcie%d.%d", port->port,
port->lane);
if (!port->name) {
--
2.20.1
^ permalink raw reply related
* [PATCH 06/11] PCI: mvebu: Add support for PCI Bridge Subsystem Vendor ID on emulated bridge
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
Register with Subsystem Device/Vendor ID is at offset 0x2c. Export is via
emulated bridge.
After this change Subsystem ID is visible in lspci output at line:
Capabilities: [40] Subsystem
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 0f2ec0a17874..811af9e6ede5 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -32,6 +32,7 @@
#define PCIE_DEV_REV_OFF 0x0008
#define PCIE_BAR_LO_OFF(n) (0x0010 + ((n) << 3))
#define PCIE_BAR_HI_OFF(n) (0x0014 + ((n) << 3))
+#define PCIE_SSDEV_ID_OFF 0x002c
#define PCIE_CAP_PCIEXP 0x0060
#define PCIE_HEADER_LOG_4_OFF 0x0128
#define PCIE_BAR_CTRL_OFF(n) (0x1804 + (((n) - 1) * 4))
@@ -731,6 +732,7 @@ static int mvebu_pci_bridge_emul_init(struct mvebu_pcie_port *port)
struct pci_bridge_emul *bridge = &port->bridge;
u32 dev_id = mvebu_readl(port, PCIE_DEV_ID_OFF);
u32 dev_rev = mvebu_readl(port, PCIE_DEV_REV_OFF);
+ u32 ssdev_id = mvebu_readl(port, PCIE_SSDEV_ID_OFF);
u32 pcie_cap = mvebu_readl(port, PCIE_CAP_PCIEXP);
u8 pcie_cap_ver = ((pcie_cap >> 16) & PCI_EXP_FLAGS_VERS);
@@ -752,6 +754,8 @@ static int mvebu_pci_bridge_emul_init(struct mvebu_pcie_port *port)
*/
bridge->pcie_conf.cap = cpu_to_le16(pcie_cap_ver);
+ bridge->subsystem_vendor_id = ssdev_id & 0xffff;
+ bridge->subsystem_id = ssdev_id >> 16;
bridge->has_pcie = true;
bridge->data = port;
bridge->ops = &mvebu_pci_bridge_emul_ops;
--
2.20.1
^ permalink raw reply related
* [PATCH 07/11] PCI: mvebu: Add support for Advanced Error Reporting registers on emulated bridge
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
AER registers start at mvebu offset 0x0100. Registers PCI_ERR_ROOT_COMMAND,
PCI_ERR_ROOT_STATUS and PCI_ERR_ROOT_ERR_SRC are not supported on pre-XP
hardware and returns zeros.
Note that AER interrupt is not supported yet as mvebu emulated bridge does
not implement interrupts support at all yet.
Also remove custom macro PCIE_HEADER_LOG_4_OFF as it is unused and
correctly this register should be referenced via standard macros with
offset, e.g. as: PCIE_CAP_PCIERR_OFF + PCI_ERR_HEADER_LOG + 4.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/controller/pci-mvebu.c | 67 +++++++++++++++++++++++++++++-
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 811af9e6ede5..9ea2f6a7c2b0 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -34,7 +34,7 @@
#define PCIE_BAR_HI_OFF(n) (0x0014 + ((n) << 3))
#define PCIE_SSDEV_ID_OFF 0x002c
#define PCIE_CAP_PCIEXP 0x0060
-#define PCIE_HEADER_LOG_4_OFF 0x0128
+#define PCIE_CAP_PCIERR_OFF 0x0100
#define PCIE_BAR_CTRL_OFF(n) (0x1804 + (((n) - 1) * 4))
#define PCIE_WIN04_CTRL_OFF(n) (0x1820 + ((n) << 4))
#define PCIE_WIN04_BASE_OFF(n) (0x1824 + ((n) << 4))
@@ -603,6 +603,37 @@ mvebu_pci_bridge_emul_pcie_conf_read(struct pci_bridge_emul *bridge,
return PCI_BRIDGE_EMUL_HANDLED;
}
+static pci_bridge_emul_read_status_t
+mvebu_pci_bridge_emul_ext_conf_read(struct pci_bridge_emul *bridge,
+ int reg, u32 *value)
+{
+ struct mvebu_pcie_port *port = bridge->data;
+
+ switch (reg) {
+ case 0:
+ case PCI_ERR_UNCOR_STATUS:
+ case PCI_ERR_UNCOR_MASK:
+ case PCI_ERR_UNCOR_SEVER:
+ case PCI_ERR_COR_STATUS:
+ case PCI_ERR_COR_MASK:
+ case PCI_ERR_CAP:
+ case PCI_ERR_HEADER_LOG+0:
+ case PCI_ERR_HEADER_LOG+4:
+ case PCI_ERR_HEADER_LOG+8:
+ case PCI_ERR_HEADER_LOG+12:
+ case PCI_ERR_ROOT_COMMAND:
+ case PCI_ERR_ROOT_STATUS:
+ case PCI_ERR_ROOT_ERR_SRC:
+ *value = mvebu_readl(port, PCIE_CAP_PCIERR_OFF + reg);
+ break;
+
+ default:
+ return PCI_BRIDGE_EMUL_NOT_HANDLED;
+ }
+
+ return PCI_BRIDGE_EMUL_HANDLED;
+}
+
static void
mvebu_pci_bridge_emul_base_conf_write(struct pci_bridge_emul *bridge,
int reg, u32 old, u32 new, u32 mask)
@@ -715,11 +746,45 @@ mvebu_pci_bridge_emul_pcie_conf_write(struct pci_bridge_emul *bridge,
}
}
+static void
+mvebu_pci_bridge_emul_ext_conf_write(struct pci_bridge_emul *bridge,
+ int reg, u32 old, u32 new, u32 mask)
+{
+ struct mvebu_pcie_port *port = bridge->data;
+
+ switch (reg) {
+ /* These are W1C registers, so clear other bits */
+ case PCI_ERR_UNCOR_STATUS:
+ case PCI_ERR_COR_STATUS:
+ case PCI_ERR_ROOT_STATUS:
+ new &= mask;
+ fallthrough;
+
+ case PCI_ERR_UNCOR_MASK:
+ case PCI_ERR_UNCOR_SEVER:
+ case PCI_ERR_COR_MASK:
+ case PCI_ERR_CAP:
+ case PCI_ERR_HEADER_LOG+0:
+ case PCI_ERR_HEADER_LOG+4:
+ case PCI_ERR_HEADER_LOG+8:
+ case PCI_ERR_HEADER_LOG+12:
+ case PCI_ERR_ROOT_COMMAND:
+ case PCI_ERR_ROOT_ERR_SRC:
+ mvebu_writel(port, new, PCIE_CAP_PCIERR_OFF + reg);
+ break;
+
+ default:
+ break;
+ }
+}
+
static const struct pci_bridge_emul_ops mvebu_pci_bridge_emul_ops = {
.read_base = mvebu_pci_bridge_emul_base_conf_read,
.write_base = mvebu_pci_bridge_emul_base_conf_write,
.read_pcie = mvebu_pci_bridge_emul_pcie_conf_read,
.write_pcie = mvebu_pci_bridge_emul_pcie_conf_write,
+ .read_ext = mvebu_pci_bridge_emul_ext_conf_read,
+ .write_ext = mvebu_pci_bridge_emul_ext_conf_write,
};
/*
--
2.20.1
^ permalink raw reply related
* [PATCH 03/11] PCI: pci-bridge-emul: Add support for PCI Bridge Subsystem Vendor ID capability
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
This is read-only capability in PCI config space. Put it between base PCI
capability and base PCI Express capability.
Driver just have to specify subsystem_vendor_id and subsystem_id fields in
emulated bridge structure and pci-bridge-emul takes care of correctly
compose PCI Bridge Subsystem Vendor ID capability.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/pci-bridge-emul.c | 69 +++++++++++++++++++++++++----------
drivers/pci/pci-bridge-emul.h | 2 +
2 files changed, 51 insertions(+), 20 deletions(-)
diff --git a/drivers/pci/pci-bridge-emul.c b/drivers/pci/pci-bridge-emul.c
index 9f4f173f0650..c84f423a5893 100644
--- a/drivers/pci/pci-bridge-emul.c
+++ b/drivers/pci/pci-bridge-emul.c
@@ -21,8 +21,11 @@
#include "pci-bridge-emul.h"
#define PCI_BRIDGE_CONF_END PCI_STD_HEADER_SIZEOF
+#define PCI_CAP_SSID_SIZEOF (PCI_SSVID_DEVICE_ID + 2)
+#define PCI_CAP_SSID_START PCI_BRIDGE_CONF_END
+#define PCI_CAP_SSID_END (PCI_CAP_SSID_START + PCI_CAP_SSID_SIZEOF)
#define PCI_CAP_PCIE_SIZEOF (PCI_EXP_SLTSTA2 + 2)
-#define PCI_CAP_PCIE_START PCI_BRIDGE_CONF_END
+#define PCI_CAP_PCIE_START PCI_CAP_SSID_END
#define PCI_CAP_PCIE_END (PCI_CAP_PCIE_START + PCI_CAP_PCIE_SIZEOF)
/**
@@ -315,6 +318,25 @@ struct pci_bridge_reg_behavior pcie_cap_regs_behavior[PCI_CAP_PCIE_SIZEOF / 4] =
},
};
+static pci_bridge_emul_read_status_t
+pci_bridge_emul_read_ssid(struct pci_bridge_emul *bridge, int reg, u32 *value)
+{
+ switch (reg) {
+ case PCI_CAP_LIST_ID:
+ *value = PCI_CAP_ID_SSVID |
+ (bridge->has_pcie ? (PCI_CAP_PCIE_START << 8) : 0);
+ return PCI_BRIDGE_EMUL_HANDLED;
+
+ case PCI_SSVID_VENDOR_ID:
+ *value = bridge->subsystem_vendor_id |
+ (bridge->subsystem_id << 16);
+ return PCI_BRIDGE_EMUL_HANDLED;
+
+ default:
+ return PCI_BRIDGE_EMUL_NOT_HANDLED;
+ }
+}
+
/*
* Initialize a pci_bridge_emul structure to represent a fake PCI
* bridge configuration space. The caller needs to have initialized
@@ -337,9 +359,17 @@ int pci_bridge_emul_init(struct pci_bridge_emul *bridge,
if (!bridge->pci_regs_behavior)
return -ENOMEM;
- if (bridge->has_pcie) {
+ if (bridge->subsystem_vendor_id)
+ bridge->conf.capabilities_pointer = PCI_CAP_SSID_START;
+ else if (bridge->has_pcie)
bridge->conf.capabilities_pointer = PCI_CAP_PCIE_START;
+ else
+ bridge->conf.capabilities_pointer = 0;
+
+ if (bridge->conf.capabilities_pointer)
bridge->conf.status |= cpu_to_le16(PCI_STATUS_CAP_LIST);
+
+ if (bridge->has_pcie) {
bridge->pcie_conf.cap_id = PCI_CAP_ID_EXP;
bridge->pcie_conf.cap |= cpu_to_le16(PCI_EXP_TYPE_ROOT_PORT << 4);
bridge->pcie_cap_regs_behavior =
@@ -423,26 +453,28 @@ int pci_bridge_emul_conf_read(struct pci_bridge_emul *bridge, int where,
read_op = bridge->ops->read_base;
cfgspace = (__le32 *) &bridge->conf;
behavior = bridge->pci_regs_behavior;
- } else if (!bridge->has_pcie) {
- /* PCIe space is not implemented, and no PCI capabilities */
- *value = 0;
- return PCIBIOS_SUCCESSFUL;
- } else if (reg < PCI_CAP_PCIE_END) {
+ } else if (reg >= PCI_CAP_SSID_START && reg < PCI_CAP_SSID_END && bridge->subsystem_vendor_id) {
+ /* Emulated PCI Bridge Subsystem Vendor ID capability */
+ reg -= PCI_CAP_SSID_START;
+ read_op = pci_bridge_emul_read_ssid;
+ cfgspace = NULL;
+ behavior = NULL;
+ } else if (reg >= PCI_CAP_PCIE_START && reg < PCI_CAP_PCIE_END && bridge->has_pcie) {
/* Our emulated PCIe capability */
reg -= PCI_CAP_PCIE_START;
read_op = bridge->ops->read_pcie;
cfgspace = (__le32 *) &bridge->pcie_conf;
behavior = bridge->pcie_cap_regs_behavior;
- } else if (reg < PCI_CFG_SPACE_SIZE) {
- /* Rest of PCI space not implemented */
- *value = 0;
- return PCIBIOS_SUCCESSFUL;
- } else {
+ } else if (reg >= PCI_CFG_SPACE_SIZE && bridge->has_pcie) {
/* PCIe extended capability space */
reg -= PCI_CFG_SPACE_SIZE;
read_op = bridge->ops->read_ext;
cfgspace = NULL;
behavior = NULL;
+ } else {
+ /* Not implemented */
+ *value = 0;
+ return PCIBIOS_SUCCESSFUL;
}
if (read_op)
@@ -500,24 +532,21 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where,
write_op = bridge->ops->write_base;
cfgspace = (__le32 *) &bridge->conf;
behavior = bridge->pci_regs_behavior;
- } else if (!bridge->has_pcie) {
- /* PCIe space is not implemented, and no PCI capabilities */
- return PCIBIOS_SUCCESSFUL;
- } else if (reg < PCI_CAP_PCIE_END) {
+ } else if (reg >= PCI_CAP_PCIE_START && reg < PCI_CAP_PCIE_END && bridge->has_pcie) {
/* Our emulated PCIe capability */
reg -= PCI_CAP_PCIE_START;
write_op = bridge->ops->write_pcie;
cfgspace = (__le32 *) &bridge->pcie_conf;
behavior = bridge->pcie_cap_regs_behavior;
- } else if (reg < PCI_CFG_SPACE_SIZE) {
- /* Rest of PCI space not implemented */
- return PCIBIOS_SUCCESSFUL;
- } else {
+ } else if (reg >= PCI_CFG_SPACE_SIZE && bridge->has_pcie) {
/* PCIe extended capability space */
reg -= PCI_CFG_SPACE_SIZE;
write_op = bridge->ops->write_ext;
cfgspace = NULL;
behavior = NULL;
+ } else {
+ /* Not implemented */
+ return PCIBIOS_SUCCESSFUL;
}
shift = (where & 0x3) * 8;
diff --git a/drivers/pci/pci-bridge-emul.h b/drivers/pci/pci-bridge-emul.h
index 6b5f75b2ad02..71392b67471d 100644
--- a/drivers/pci/pci-bridge-emul.h
+++ b/drivers/pci/pci-bridge-emul.h
@@ -132,6 +132,8 @@ struct pci_bridge_emul {
struct pci_bridge_reg_behavior *pcie_cap_regs_behavior;
void *data;
bool has_pcie;
+ u16 subsystem_vendor_id;
+ u16 subsystem_id;
};
enum {
--
2.20.1
^ permalink raw reply related
* [PATCH 02/11] PCI: pci-bridge-emul: Add support for PCIe extended capabilities
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
From: Russell King <rmk+kernel@armlinux.org.uk>
Add support for PCIe extended capabilities, which we just redirect to the
emulating driver.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
[pali: Fix writing new value with W1C bits]
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/pci-bridge-emul.c | 77 +++++++++++++++++++++++------------
drivers/pci/pci-bridge-emul.h | 15 +++++++
2 files changed, 67 insertions(+), 25 deletions(-)
diff --git a/drivers/pci/pci-bridge-emul.c b/drivers/pci/pci-bridge-emul.c
index 56b2cb741498..9f4f173f0650 100644
--- a/drivers/pci/pci-bridge-emul.c
+++ b/drivers/pci/pci-bridge-emul.c
@@ -433,10 +433,16 @@ int pci_bridge_emul_conf_read(struct pci_bridge_emul *bridge, int where,
read_op = bridge->ops->read_pcie;
cfgspace = (__le32 *) &bridge->pcie_conf;
behavior = bridge->pcie_cap_regs_behavior;
- } else {
- /* Beyond our PCIe space */
+ } else if (reg < PCI_CFG_SPACE_SIZE) {
+ /* Rest of PCI space not implemented */
*value = 0;
return PCIBIOS_SUCCESSFUL;
+ } else {
+ /* PCIe extended capability space */
+ reg -= PCI_CFG_SPACE_SIZE;
+ read_op = bridge->ops->read_ext;
+ cfgspace = NULL;
+ behavior = NULL;
}
if (read_op)
@@ -444,15 +450,20 @@ int pci_bridge_emul_conf_read(struct pci_bridge_emul *bridge, int where,
else
ret = PCI_BRIDGE_EMUL_NOT_HANDLED;
- if (ret == PCI_BRIDGE_EMUL_NOT_HANDLED)
- *value = le32_to_cpu(cfgspace[reg / 4]);
+ if (ret == PCI_BRIDGE_EMUL_NOT_HANDLED) {
+ if (cfgspace)
+ *value = le32_to_cpu(cfgspace[reg / 4]);
+ else
+ *value = 0;
+ }
/*
* Make sure we never return any reserved bit with a value
* different from 0.
*/
- *value &= behavior[reg / 4].ro | behavior[reg / 4].rw |
- behavior[reg / 4].w1c;
+ if (behavior)
+ *value &= behavior[reg / 4].ro | behavior[reg / 4].rw |
+ behavior[reg / 4].w1c;
if (size == 1)
*value = (*value >> (8 * (where & 3))) & 0xff;
@@ -498,8 +509,15 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where,
write_op = bridge->ops->write_pcie;
cfgspace = (__le32 *) &bridge->pcie_conf;
behavior = bridge->pcie_cap_regs_behavior;
- } else {
+ } else if (reg < PCI_CFG_SPACE_SIZE) {
+ /* Rest of PCI space not implemented */
return PCIBIOS_SUCCESSFUL;
+ } else {
+ /* PCIe extended capability space */
+ reg -= PCI_CFG_SPACE_SIZE;
+ write_op = bridge->ops->write_ext;
+ cfgspace = NULL;
+ behavior = NULL;
}
shift = (where & 0x3) * 8;
@@ -513,29 +531,38 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where,
else
return PCIBIOS_BAD_REGISTER_NUMBER;
- /* Keep all bits, except the RW bits */
- new = old & (~mask | ~behavior[reg / 4].rw);
+ if (behavior) {
+ /* Keep all bits, except the RW bits */
+ new = old & (~mask | ~behavior[reg / 4].rw);
- /* Update the value of the RW bits */
- new |= (value << shift) & (behavior[reg / 4].rw & mask);
+ /* Update the value of the RW bits */
+ new |= (value << shift) & (behavior[reg / 4].rw & mask);
- /* Clear the W1C bits */
- new &= ~((value << shift) & (behavior[reg / 4].w1c & mask));
+ /* Clear the W1C bits */
+ new &= ~((value << shift) & (behavior[reg / 4].w1c & mask));
+ } else {
+ new = old & ~mask;
+ new |= (value << shift) & mask;
+ }
- /* Save the new value with the cleared W1C bits into the cfgspace */
- cfgspace[reg / 4] = cpu_to_le32(new);
+ if (cfgspace) {
+ /* Save the new value with the cleared W1C bits into the cfgspace */
+ cfgspace[reg / 4] = cpu_to_le32(new);
+ }
- /*
- * Clear the W1C bits not specified by the write mask, so that the
- * write_op() does not clear them.
- */
- new &= ~(behavior[reg / 4].w1c & ~mask);
+ if (behavior) {
+ /*
+ * Clear the W1C bits not specified by the write mask, so that the
+ * write_op() does not clear them.
+ */
+ new &= ~(behavior[reg / 4].w1c & ~mask);
- /*
- * Set the W1C bits specified by the write mask, so that write_op()
- * knows about that they are to be cleared.
- */
- new |= (value << shift) & (behavior[reg / 4].w1c & mask);
+ /*
+ * Set the W1C bits specified by the write mask, so that write_op()
+ * knows about that they are to be cleared.
+ */
+ new |= (value << shift) & (behavior[reg / 4].w1c & mask);
+ }
if (write_op)
write_op(bridge, reg, old, new, mask);
diff --git a/drivers/pci/pci-bridge-emul.h b/drivers/pci/pci-bridge-emul.h
index 4953274cac18..6b5f75b2ad02 100644
--- a/drivers/pci/pci-bridge-emul.h
+++ b/drivers/pci/pci-bridge-emul.h
@@ -90,6 +90,14 @@ struct pci_bridge_emul_ops {
*/
pci_bridge_emul_read_status_t (*read_pcie)(struct pci_bridge_emul *bridge,
int reg, u32 *value);
+
+ /*
+ * Same as ->read_base(), except it is for reading from the
+ * PCIe extended capability configuration space.
+ */
+ pci_bridge_emul_read_status_t (*read_ext)(struct pci_bridge_emul *bridge,
+ int reg, u32 *value);
+
/*
* Called when writing to the regular PCI bridge configuration
* space. old is the current value, new is the new value being
@@ -105,6 +113,13 @@ struct pci_bridge_emul_ops {
*/
void (*write_pcie)(struct pci_bridge_emul *bridge, int reg,
u32 old, u32 new, u32 mask);
+
+ /*
+ * Same as ->write_base(), except it is for writing from the
+ * PCIe extended capability configuration space.
+ */
+ void (*write_ext)(struct pci_bridge_emul *bridge, int reg,
+ u32 old, u32 new, u32 mask);
};
struct pci_bridge_reg_behavior;
--
2.20.1
^ permalink raw reply related
* [PATCH 00/11] PCI: mvebu: subsystem ids, AER and INTx
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
This patch series extends pci-bridge-emul.c driver to emulate PCI Subsystem
Vendor ID capability and PCIe extended capabilities. And then implement
in pci-mvebu.c driver support for PCI Subsystem Vendor IDs, PCIe AER
registers, support for legacy INTx interrupts, configuration for X1/X4
mode and usage of new PCI child_ops API.
This patch series depends on other pci-mvebu and pci-bridge-emul patches from:
https://lore.kernel.org/linux-pci/20220104153529.31647-1-pali@kernel.org/
Pali Rohár (9):
PCI: pci-bridge-emul: Add support for PCI Bridge Subsystem Vendor ID
capability
dt-bindings: PCI: mvebu: Add num-lanes property
PCI: mvebu: Correctly configure x1/x4 mode
PCI: mvebu: Add support for PCI Bridge Subsystem Vendor ID on emulated
bridge
PCI: mvebu: Add support for Advanced Error Reporting registers on
emulated bridge
PCI: mvebu: Use child_ops API
dt-bindings: PCI: mvebu: Update information about intx interrupts
PCI: mvebu: Implement support for legacy INTx interrupts
ARM: dts: armada-385.dtsi: Add definitions for PCIe legacy INTx
interrupts
Russell King (2):
PCI: pci-bridge-emul: Re-arrange register tests
PCI: pci-bridge-emul: Add support for PCIe extended capabilities
.../devicetree/bindings/pci/mvebu-pci.txt | 16 +
arch/arm/boot/dts/armada-385.dtsi | 52 ++-
drivers/pci/controller/pci-mvebu.c | 352 +++++++++++++++---
drivers/pci/pci-bridge-emul.c | 167 ++++++---
drivers/pci/pci-bridge-emul.h | 17 +
5 files changed, 494 insertions(+), 110 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH 04/11] dt-bindings: PCI: mvebu: Add num-lanes property
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King,
Andrew Lunn, Gregory Clement
Cc: linux-pci, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
Controller driver needs to correctly configure PCIe link if it contains 1
or 4 SerDes PCIe lanes. Therefore add a new 'num-lanes' DT property for
mvebu PCIe controller. Property 'num-lanes' seems to be de-facto standard
way how number of lanes is specified in other PCIe controllers.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
Documentation/devicetree/bindings/pci/mvebu-pci.txt | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 6173af6885f8..24225852bce0 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -77,6 +77,7 @@ and the following optional properties:
- marvell,pcie-lane: the physical PCIe lane number, for ports having
multiple lanes. If this property is not found, we assume that the
value is 0.
+- num-lanes: number of SerDes PCIe lanes for this link (1 or 4)
- reset-gpios: optional GPIO to PERST#
- reset-delay-us: delay in us to wait after reset de-assertion, if not
specified will default to 100ms, as required by the PCIe specification.
@@ -141,6 +142,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 58>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <0>;
+ num-lanes = <1>;
/* low-active PERST# reset on GPIO 25 */
reset-gpios = <&gpio0 25 1>;
/* wait 20ms for device settle after reset deassertion */
@@ -161,6 +163,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 59>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <1>;
+ num-lanes = <1>;
clocks = <&gateclk 6>;
};
@@ -177,6 +180,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 60>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <2>;
+ num-lanes = <1>;
clocks = <&gateclk 7>;
};
@@ -193,6 +197,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 61>;
marvell,pcie-port = <0>;
marvell,pcie-lane = <3>;
+ num-lanes = <1>;
clocks = <&gateclk 8>;
};
@@ -209,6 +214,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 62>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <0>;
+ num-lanes = <1>;
clocks = <&gateclk 9>;
};
@@ -225,6 +231,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 63>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <1>;
+ num-lanes = <1>;
clocks = <&gateclk 10>;
};
@@ -241,6 +248,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 64>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <2>;
+ num-lanes = <1>;
clocks = <&gateclk 11>;
};
@@ -257,6 +265,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 65>;
marvell,pcie-port = <1>;
marvell,pcie-lane = <3>;
+ num-lanes = <1>;
clocks = <&gateclk 12>;
};
@@ -273,6 +282,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 99>;
marvell,pcie-port = <2>;
marvell,pcie-lane = <0>;
+ num-lanes = <1>;
clocks = <&gateclk 26>;
};
@@ -289,6 +299,7 @@ pcie-controller {
interrupt-map = <0 0 0 0 &mpic 103>;
marvell,pcie-port = <3>;
marvell,pcie-lane = <0>;
+ num-lanes = <1>;
clocks = <&gateclk 27>;
};
};
--
2.20.1
^ permalink raw reply related
* [PATCH 01/11] PCI: pci-bridge-emul: Re-arrange register tests
From: Pali Rohár @ 2022-01-05 15:02 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring, Thomas Petazzoni,
Krzysztof Wilczyński, Marek Behún, Russell King
Cc: linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20220105150239.9628-1-pali@kernel.org>
From: Russell King <rmk+kernel@armlinux.org.uk>
Re-arrange the tests for which sets of registers are being accessed so that
it is easier to add further regions later. No functional change.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
[pali: Fix reading old value in pci_bridge_emul_conf_write]
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/pci/pci-bridge-emul.c | 61 ++++++++++++++++++-----------------
1 file changed, 31 insertions(+), 30 deletions(-)
diff --git a/drivers/pci/pci-bridge-emul.c b/drivers/pci/pci-bridge-emul.c
index 033bbeb99176..56b2cb741498 100644
--- a/drivers/pci/pci-bridge-emul.c
+++ b/drivers/pci/pci-bridge-emul.c
@@ -418,25 +418,25 @@ int pci_bridge_emul_conf_read(struct pci_bridge_emul *bridge, int where,
__le32 *cfgspace;
const struct pci_bridge_reg_behavior *behavior;
- if (bridge->has_pcie && reg >= PCI_CAP_PCIE_END) {
- *value = 0;
- return PCIBIOS_SUCCESSFUL;
- }
-
- if (!bridge->has_pcie && reg >= PCI_BRIDGE_CONF_END) {
+ if (reg < PCI_BRIDGE_CONF_END) {
+ /* Emulated PCI space */
+ read_op = bridge->ops->read_base;
+ cfgspace = (__le32 *) &bridge->conf;
+ behavior = bridge->pci_regs_behavior;
+ } else if (!bridge->has_pcie) {
+ /* PCIe space is not implemented, and no PCI capabilities */
*value = 0;
return PCIBIOS_SUCCESSFUL;
- }
-
- if (bridge->has_pcie && reg >= PCI_CAP_PCIE_START) {
+ } else if (reg < PCI_CAP_PCIE_END) {
+ /* Our emulated PCIe capability */
reg -= PCI_CAP_PCIE_START;
read_op = bridge->ops->read_pcie;
cfgspace = (__le32 *) &bridge->pcie_conf;
behavior = bridge->pcie_cap_regs_behavior;
} else {
- read_op = bridge->ops->read_base;
- cfgspace = (__le32 *) &bridge->conf;
- behavior = bridge->pci_regs_behavior;
+ /* Beyond our PCIe space */
+ *value = 0;
+ return PCIBIOS_SUCCESSFUL;
}
if (read_op)
@@ -480,11 +480,27 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where,
__le32 *cfgspace;
const struct pci_bridge_reg_behavior *behavior;
- if (bridge->has_pcie && reg >= PCI_CAP_PCIE_END)
- return PCIBIOS_SUCCESSFUL;
+ ret = pci_bridge_emul_conf_read(bridge, reg, 4, &old);
+ if (ret != PCIBIOS_SUCCESSFUL)
+ return ret;
- if (!bridge->has_pcie && reg >= PCI_BRIDGE_CONF_END)
+ if (reg < PCI_BRIDGE_CONF_END) {
+ /* Emulated PCI space */
+ write_op = bridge->ops->write_base;
+ cfgspace = (__le32 *) &bridge->conf;
+ behavior = bridge->pci_regs_behavior;
+ } else if (!bridge->has_pcie) {
+ /* PCIe space is not implemented, and no PCI capabilities */
return PCIBIOS_SUCCESSFUL;
+ } else if (reg < PCI_CAP_PCIE_END) {
+ /* Our emulated PCIe capability */
+ reg -= PCI_CAP_PCIE_START;
+ write_op = bridge->ops->write_pcie;
+ cfgspace = (__le32 *) &bridge->pcie_conf;
+ behavior = bridge->pcie_cap_regs_behavior;
+ } else {
+ return PCIBIOS_SUCCESSFUL;
+ }
shift = (where & 0x3) * 8;
@@ -497,21 +513,6 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where,
else
return PCIBIOS_BAD_REGISTER_NUMBER;
- ret = pci_bridge_emul_conf_read(bridge, reg, 4, &old);
- if (ret != PCIBIOS_SUCCESSFUL)
- return ret;
-
- if (bridge->has_pcie && reg >= PCI_CAP_PCIE_START) {
- reg -= PCI_CAP_PCIE_START;
- write_op = bridge->ops->write_pcie;
- cfgspace = (__le32 *) &bridge->pcie_conf;
- behavior = bridge->pcie_cap_regs_behavior;
- } else {
- write_op = bridge->ops->write_base;
- cfgspace = (__le32 *) &bridge->conf;
- behavior = bridge->pci_regs_behavior;
- }
-
/* Keep all bits, except the RW bits */
new = old & (~mask | ~behavior[reg / 4].rw);
--
2.20.1
^ permalink raw reply related
* Re: Backport request: commit 0dc54bd4d6e0 ("fscache_cookie_enabled: check cookie is valid before accessing it")
From: Jeffrey E Altman @ 2022-01-05 15:00 UTC (permalink / raw)
To: Greg KH (greg@kroah.com); +Cc: stable, linux-afs
In-Reply-To: <YdWyJuRus3zknfak@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 473 bytes --]
On 1/5/2022 9:58 AM, Greg KH (greg@kroah.com) wrote:
> On Tue, Jan 04, 2022 at 05:29:34PM -0500, Jeffrey E Altman wrote:
>> Please backport commit 0dc54bd4d6e03be1f0b678c4297170b79f1a44ab
>> ("fscache_cookie_enabled: check cookie is valid before accessing it") to
>> the 5.13, 5.14, and 5.15 kernel series.
> Only 5.15 is still alive, see the front page of kernel.org to see the
> active kernel verisons.
Got it. Thank you for the prompt response.
Thank you.
Jeffrey
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4033 bytes --]
^ permalink raw reply
* Re: [PATCH] RDMA: null pointer in __ib_umem_release causes kernel panic
From: Trond Myklebust @ 2022-01-05 15:02 UTC (permalink / raw)
To: jgg@nvidia.com, trondmy@kernel.org
Cc: linux-nfs@vger.kernel.org, linux-rdma@vger.kernel.org
In-Reply-To: <20220105143705.GS2328285@nvidia.com>
On Wed, 2022-01-05 at 10:37 -0400, Jason Gunthorpe wrote:
> On Wed, Jan 05, 2022 at 09:18:41AM -0500, trondmy@kernel.org wrote:
> > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> >
> > When doing RPC/RDMA, we're seeing a kernel panic when
> > __ib_umem_release()
> > iterates over the scatter gather list and hits NULL pages.
> >
> > It turns out that commit 79fbd3e1241c ended up changing the
> > iteration
> > from being over only the mapped entries to being over the original
> > list
> > size.
>
> You mean this?
>
> - for_each_sg(umem->sg_head.sgl, sg, umem->sg_nents, i)
> + for_each_sgtable_sg(&umem->sgt_append.sgt, sg, i)
>
> I don't see what changed there? The invarient should be that
>
> umem->sg_nents == sgt->orig_nents
>
> > @@ -55,7 +55,7 @@ static void __ib_umem_release(struct ib_device
> > *dev, struct ib_umem *umem, int d
> > ib_dma_unmap_sgtable_attrs(dev, &umem-
> > >sgt_append.sgt,
> > DMA_BIDIRECTIONAL, 0);
> >
> > - for_each_sgtable_sg(&umem->sgt_append.sgt, sg, i)
> > + for_each_sgtable_dma_sg(&umem->sgt_append.sgt, sg, i)
> > unpin_user_page_range_dirty_lock(sg_page(sg),
>
> Calling sg_page() from under a dma_sg iterator is unconditionally
> wrong..
>
> More likely your case is something has gone wrong when the sgtable
> was
> created and it has the wrong value in orig_nents..
Can you define "wrong value" in this case? Chuck's RPC/RDMA code
appears to call ib_alloc_mr() with an 'expected maximum number of
entries' (depth) in net/sunrpc/xprtrdma/frwr_ops.c:frwr_mr_init().
It then fills that table with a set of n <= depth pages in
net/sunrpc/xprtrdma/frwr_ops.c:frwr_map() and calls ib_dma_map_sg() to
map them, and then adjusts the sgtable with a call to ib_map_mr_sg().
What part of that sequence of operations is incorrect?
>
> Jason
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.