[PATCH next 4/6] ARM: dts: dra7x-evm: switch to new cpsw switch drv
Switch all TI DRA7x boards to use new cpsw switch driver. Those boards
configured in dual_mac mode by default. Hence, dual_mac mode has been
preserved the same way between legacy and new driver it's safe to switch
drivers.
Signed-off-by: Grygorii Strashko
---
arch/arm/boot/dts/dra7-evm.dts | 13 ++---
arch/arm/boot/dts/dra71-evm.dts | 14 +++---
arch/arm/boot/dts/dra72-evm-common.dtsi | 4
arch/arm/boot/dts/dra72-evm-revc.dts| 14 +++---
arch/arm/boot/dts/dra72-evm.dts | 13 +
arch/arm/boot/dts/dra76-evm.dts | 14 ++
6 files changed, 35 insertions(+), 37 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index a952d934fcf2..051aac4e95b7 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -537,24 +537,23 @@
ti,no-idle-on-init;
};
-&mac {
+&mac_sw {
status = "okay";
- dual_emac;
};
-&cpsw_emac0 {
+&cpsw_port1 {
phy-handle = <ðphy0>;
phy-mode = "rgmii";
- dual_emac_res_vlan = <1>;
+ ti,dual-emac-pvid = <1>;
};
-&cpsw_emac1 {
+&cpsw_port2 {
phy-handle = <ðphy1>;
phy-mode = "rgmii";
- dual_emac_res_vlan = <2>;
+ ti,dual-emac-pvid = <2>;
};
-&davinci_mdio {
+&davinci_mdio_sw {
ethphy0: ethernet-phy@2 {
reg = <2>;
};
diff --git a/arch/arm/boot/dts/dra71-evm.dts b/arch/arm/boot/dts/dra71-evm.dts
index 10da51bee42f..cad58f733bd6 100644
--- a/arch/arm/boot/dts/dra71-evm.dts
+++ b/arch/arm/boot/dts/dra71-evm.dts
@@ -219,26 +219,26 @@
vqmmc-supply = <&evm_1v8_sw>;
};
-&mac {
+&mac_sw {
mode-gpios = <&pcf_gpio_21 4 GPIO_ACTIVE_LOW>,
<&pcf_hdmi 9 GPIO_ACTIVE_LOW>, /* P11 */
<&pcf_hdmi 10 GPIO_ACTIVE_LOW>;/* P12 */
- dual_emac;
+ status = "okay";
};
-&cpsw_emac0 {
+&cpsw_port1 {
phy-handle = <&dp83867_0>;
phy-mode = "rgmii-id";
- dual_emac_res_vlan = <1>;
+ ti,dual-emac-pvid = <1>;
};
-&cpsw_emac1 {
+&cpsw_port2 {
phy-handle = <&dp83867_1>;
phy-mode = "rgmii-id";
- dual_emac_res_vlan = <2>;
+ ti,dual-emac-pvid = <2>;
};
-&davinci_mdio {
+&davinci_mdio_sw {
dp83867_0: ethernet-phy@2 {
reg = <2>;
ti,rx-internal-delay = ;
diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi
b/arch/arm/boot/dts/dra72-evm-common.dtsi
index 9273a7d6fa29..8d0d960107fb 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -462,10 +462,6 @@
};
};
-&mac {
- status = "okay";
-};
-
&dcan1 {
status = "ok";
pinctrl-names = "default", "sleep", "active";
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts
b/arch/arm/boot/dts/dra72-evm-revc.dts
index 54dab0f212d1..f242b937f88c 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -77,26 +77,26 @@
interrupts = <30 IRQ_TYPE_EDGE_FALLING>;
};
-&mac {
+&mac_sw {
mode-gpios = <&pcf_gpio_21 4 GPIO_ACTIVE_LOW>,
<&pcf_hdmi 9 GPIO_ACTIVE_LOW>, /* P11 */
<&pcf_hdmi 10 GPIO_ACTIVE_LOW>;/* P12 */
- dual_emac;
+ status = "okay";
};
-&cpsw_emac0 {
+&cpsw_port1 {
phy-handle = <&dp83867_0>;
phy-mode = "rgmii-id";
- dual_emac_res_vlan = <1>;
+ ti,dual-emac-pvid = <1>;
};
-&cpsw_emac1 {
+&cpsw_port2 {
phy-handle = <&dp83867_1>;
phy-mode = "rgmii-id";
- dual_emac_res_vlan = <2>;
+ ti,dual-emac-pvid = <2>;
};
-&davinci_mdio {
+&davinci_mdio_sw {
dp83867_0: ethernet-phy@2 {
reg = <2>;
ti,rx-internal-delay = ;
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 6ea9936f7d9c..5f62f92eb96c 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -69,17 +69,22 @@
interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
};
-&mac {
- slaves = <1>;
+&mac_sw {
mode-gpios = <&pcf_gpio_21 4 GPIO_ACTIVE_HIGH>;
+ status = "okay";
};
-&cpsw_emac0 {
+&cpsw_port1 {
phy-handle = <ðphy0>;
phy-mode = "rgmii";
+ ti,dual-emac-pvid = <1>;
+};
+
+&cpsw_port2 {
+ status = "disabled";
};
-&davinci_mdio {
+&davinci_mdio_sw {
ethphy0: ethernet-phy@3 {
reg = <3>;
};
diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index 803981cc762e..34f655be4fb4 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -475,25 +475,23 @@
status = "disabled";
};
-&mac {
+&mac_sw {
status = "okay";
-
- dual_emac;
};
-&cpsw_emac0 {
+&cpsw_port1 {
phy-handle = <&dp83867_0>;
phy-mode = "rgmii-id";
- dual_emac_res_vlan = <1>;
+ ti,dual-emac-pvid = <1>;
[PATCH v4.14.y 3/3] vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
From: Alex Williamson
commit abafbc551fddede3e0a08dee1dcde08fc0eb8476 upstream.
Accessing the disabled memory space of a PCI device would typically
result in a master abort response on conventional PCI, or an
unsupported request on PCI express. The user would generally see
these as a -1 response for the read return data and the write would be
silently discarded, possibly with an uncorrected, non-fatal AER error
triggered on the host. Some systems however take it upon themselves
to bring down the entire system when they see something that might
indicate a loss of data, such as this discarded write to a disabled
memory space.
To avoid this, we want to try to block the user from accessing memory
spaces while they're disabled. We start with a semaphore around the
memory enable bit, where writers modify the memory enable state and
must be serialized, while readers make use of the memory region and
can access in parallel. Writers include both direct manipulation via
the command register, as well as any reset path where the internal
mechanics of the reset may both explicitly and implicitly disable
memory access, and manipulation of the MSI-X configuration, where the
MSI-X vector table resides in MMIO space of the device. Readers
include the read and write file ops to access the vfio device fd
offsets as well as memory mapped access. In the latter case, we make
use of our new vma list support to zap, or invalidate, those memory
mappings in order to force them to be faulted back in on access.
Our semaphore usage will stall user access to MMIO spaces across
internal operations like reset, but the user might experience new
behavior when trying to access the MMIO space while disabled via the
PCI command register. Access via read or write while disabled will
return -EIO and access via memory maps will result in a SIGBUS. This
is expected to be compatible with known use cases and potentially
provides better error handling capabilities than present in the
hardware, while avoiding the more readily accessible and severe
platform error responses that might otherwise occur.
Fixes: CVE-2020-12888
Reviewed-by: Peter Xu
Signed-off-by: Alex Williamson
[Ajay: Regenerated the patch for v4.14]
Signed-off-by: Ajay Kaher
---
drivers/vfio/pci/vfio_pci.c | 294 +++-
drivers/vfio/pci/vfio_pci_config.c | 36 -
drivers/vfio/pci/vfio_pci_intrs.c | 14 ++
drivers/vfio/pci/vfio_pci_private.h | 9 ++
drivers/vfio/pci/vfio_pci_rdwr.c| 29 +++-
5 files changed, 334 insertions(+), 48 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index af62be9..445ba0d 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "vfio_pci_private.h"
@@ -181,6 +182,7 @@ static void vfio_pci_probe_mmaps(struct vfio_pci_device
*vdev)
static void vfio_pci_try_bus_reset(struct vfio_pci_device *vdev);
static void vfio_pci_disable(struct vfio_pci_device *vdev);
+static int vfio_pci_try_zap_and_vma_lock_cb(struct pci_dev *pdev, void *data);
/*
* INTx masking requires the ability to disable INTx signaling via PCI_COMMAND
@@ -644,6 +646,12 @@ int vfio_pci_register_dev_region(struct vfio_pci_device
*vdev,
return 0;
}
+struct vfio_devices {
+ struct vfio_device **devices;
+ int cur_index;
+ int max_index;
+};
+
static long vfio_pci_ioctl(void *device_data,
unsigned int cmd, unsigned long arg)
{
@@ -717,7 +725,7 @@ static long vfio_pci_ioctl(void *device_data,
{
void __iomem *io;
size_t size;
- u16 orig_cmd;
+ u16 cmd;
info.offset = VFIO_PCI_INDEX_TO_OFFSET(info.index);
info.flags = 0;
@@ -737,10 +745,7 @@ static long vfio_pci_ioctl(void *device_data,
* Is it really there? Enable memory decode for
* implicit access in pci_map_rom().
*/
- pci_read_config_word(pdev, PCI_COMMAND, &orig_cmd);
- pci_write_config_word(pdev, PCI_COMMAND,
- orig_cmd | PCI_COMMAND_MEMORY);
-
+ cmd = vfio_pci_memory_lock_and_enable(vdev);
io = pci_map_rom(pdev, &size);
if (io) {
info.flags = VFIO_REGION_INFO_FLAG_READ;
@@ -748,8 +753,8 @@ static long vfio_pci_ioctl(void *device_data,
} else {
info.size = 0;
}
+ vfio_pci_memory_unlock_and_restore(vdev, cmd);
- pci_write_config_word(pdev, PCI_COMMAND, orig_cmd);
break;
}
case VFIO_PCI_VGA_REGI
[PATCH v4.14.y 1/3] vfio/type1: Support faulting PFNMAP vmas
From: Alex Williamson
commit 41311242221e3482b20bfed10fa4d9db98d87016 upstream.
With conversion to follow_pfn(), DMA mapping a PFNMAP range depends on
the range being faulted into the vma. Add support to manually provide
that, in the same way as done on KVM with hva_to_pfn_remapped().
Reviewed-by: Peter Xu
Signed-off-by: Alex Williamson
[Ajay: Regenerated the patch for v4.14]
Signed-off-by: Ajay Kaher
---
drivers/vfio/vfio_iommu_type1.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 35a3750..150be10 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -336,6 +336,32 @@ static int put_pfn(unsigned long pfn, int prot)
return 0;
}
+static int follow_fault_pfn(struct vm_area_struct *vma, struct mm_struct *mm,
+ unsigned long vaddr, unsigned long *pfn,
+ bool write_fault)
+{
+ int ret;
+
+ ret = follow_pfn(vma, vaddr, pfn);
+ if (ret) {
+ bool unlocked = false;
+
+ ret = fixup_user_fault(NULL, mm, vaddr,
+ FAULT_FLAG_REMOTE |
+ (write_fault ? FAULT_FLAG_WRITE : 0),
+ &unlocked);
+ if (unlocked)
+ return -EAGAIN;
+
+ if (ret)
+ return ret;
+
+ ret = follow_pfn(vma, vaddr, pfn);
+ }
+
+ return ret;
+}
+
static int vaddr_get_pfn(struct mm_struct *mm, unsigned long vaddr,
int prot, unsigned long *pfn)
{
@@ -375,12 +401,16 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
long vaddr,
down_read(&mm->mmap_sem);
+retry:
vma = find_vma_intersection(mm, vaddr, vaddr + 1);
if (vma && vma->vm_flags & VM_PFNMAP) {
- if (!follow_pfn(vma, vaddr, pfn) &&
- is_invalid_reserved_pfn(*pfn))
- ret = 0;
+ ret = follow_fault_pfn(vma, mm, vaddr, pfn, prot & IOMMU_WRITE);
+ if (ret == -EAGAIN)
+ goto retry;
+
+ if (!ret && !is_invalid_reserved_pfn(*pfn))
+ ret = -EFAULT;
}
up_read(&mm->mmap_sem);
--
2.7.4
[PATCH v4.14.y 0/3] vfio: Fix for CVE-2020-12888
CVE-2020-12888 Kernel: vfio: access to disabled MMIO space of some devices may lead to DoS scenario The VFIO modules allow users (guest VMs) to enable or disable access to the devices' MMIO memory address spaces. If a user attempts to access (read/write) the devices' MMIO address space when it is disabled, some h/w devices issue an interrupt to the CPU to indicate a fatal error condition, crashing the system. This flaw allows a guest user or process to crash the host system resulting in a denial of service. Patch 1/ is to force the user fault if PFNMAP vma might be DMA mapped before user access. Patch 2/ setup a vm_ops handler to support dynamic faulting instead of calling remap_pfn_range(). Also provides a list of vmas actively mapping the area which can later use to invalidate those mappings. Patch 3/ block the user from accessing memory spaces which is disabled by using new vma list support to zap, or invalidate, those memory mappings in order to force them to be faulted back in on access. Upstreamed patches link: https://lore.kernel.org/kvm/158871401328.15589.17598154478222071285.st...@gimli.home [PATCH v4.14.y 1/3]: Backporting of upsream commit 41311242221e: vfio/type1: Support faulting PFNMAP vmas [PATCH v4.14.y 2/3]: Backporting of upsream commit 11c4cd07ba11: vfio-pci: Fault mmaps to enable vma tracking [PATCH v4.14.y 3/3]: Backporting of upsream commit abafbc551fdd: vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
[PATCH next 1/6] ARM: dts: am5729: beagleboneai: switch to new cpsw switch drv
Switch BeagleBone AI to use new cpsw switch driver.
It has one Ext. port only and fits dual_mac mode with no issues.
Signed-off-by: Grygorii Strashko
---
arch/arm/boot/dts/am5729-beagleboneai.dts | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/am5729-beagleboneai.dts
b/arch/arm/boot/dts/am5729-beagleboneai.dts
index e9c7f44126e7..149cfafb90bf 100644
--- a/arch/arm/boot/dts/am5729-beagleboneai.dts
+++ b/arch/arm/boot/dts/am5729-beagleboneai.dts
@@ -488,25 +488,29 @@
status = "okay";
};
-&davinci_mdio {
+&davinci_mdio_sw {
reset-gpios = <&gpio2 23 GPIO_ACTIVE_LOW>;
reset-delay-us = <2>;
- phy0: ethernet-phy@1 {
+ phy0: ethernet-phy@4 {
reg = <4>;
eee-broken-100tx;
eee-broken-1000t;
};
};
-&mac {
- slaves = <1>;
+&mac_sw {
status = "okay";
};
-&cpsw_emac0 {
+&cpsw_port1 {
phy-handle = <&phy0>;
phy-mode = "rgmii-rxid";
+ ti,dual-emac-pvid = <1>;
+};
+
+&cpsw_port2 {
+ status = "disabled";
};
&ocp {
--
2.17.1
[PATCH next 0/6] ARM: dts: am57xx/dra7x: switch to new cpsw switch drv
Hi Tony,
Since Kernel v5.5 commits:
111cf1ab4da3 ("net: ethernet: ti: introduce cpsw switchdev based driver part 2
- switch")
ed3525eda4c4 ("net: ethernet: ti: introduce cpsw switchdev based driver part 1
- dual-emac")
the new CPSW driver with switchdev support has been introduced and one
am571x-idk board was converted to use it. And since that time (Nov 2019) no
significant issues were reported for the new CPSW driver.
Therefore it's time to switch all am57xx/dra7x boards to use new cpsw switch
driver. Those boards have 1 or 2 Ext. port wired and configured in dual_mac mode
by default. The dual_mac mode has been preserved the same way between
legacy and new driver it's safe to switch drivers.
Grygorii Strashko (6):
ARM: dts: am5729: beagleboneai: switch to new cpsw switch drv
ARM: dts: am57xx-idk: switch to new cpsw switch drv
ARM: dts: beagle-x15: switch to new cpsw switch drv
ARM: dts: dra7x-evm: switch to new cpsw switch drv
ARM: dts: am57xx-cl-som-am57x: switch to new cpsw switch drv
ARM: dts: dra7: drop legacy cpsw dt node
arch/arm/boot/dts/am571x-idk.dts | 27 --
arch/arm/boot/dts/am5729-beagleboneai.dts | 14 +++--
arch/arm/boot/dts/am572x-idk.dts | 5 --
arch/arm/boot/dts/am574x-idk.dts | 5 --
.../boot/dts/am57xx-beagle-x15-common.dtsi| 13 +++--
arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 13 +++--
arch/arm/boot/dts/am57xx-idk-common.dtsi | 14 +++--
arch/arm/boot/dts/dra7-evm.dts| 13 +++--
arch/arm/boot/dts/dra7-l4.dtsi| 54 ---
arch/arm/boot/dts/dra7.dtsi | 4 +-
arch/arm/boot/dts/dra71-evm.dts | 14 ++---
arch/arm/boot/dts/dra72-evm-common.dtsi | 4 --
arch/arm/boot/dts/dra72-evm-revc.dts | 14 ++---
arch/arm/boot/dts/dra72-evm.dts | 13 +++--
arch/arm/boot/dts/dra76-evm.dts | 14 +++--
15 files changed, 67 insertions(+), 154 deletions(-)
--
2.17.1
[PATCH v4.14.y 2/3] vfio-pci: Fault mmaps to enable vma tracking
From: Alex Williamson
commit 11c4cd07ba111a09f49625f9e4c851d83daf0a22 upstream.
Rather than calling remap_pfn_range() when a region is mmap'd, setup
a vm_ops handler to support dynamic faulting of the range on access.
This allows us to manage a list of vmas actively mapping the area that
we can later use to invalidate those mappings. The open callback
invalidates the vma range so that all tracking is inserted in the
fault handler and removed in the close handler.
Reviewed-by: Peter Xu
Signed-off-by: Alex Williamson
[Ajay: Regenerated the patch for v4.14]
Signed-off-by: Ajay Kaher
---
drivers/vfio/pci/vfio_pci.c | 75 -
drivers/vfio/pci/vfio_pci_private.h | 7
2 files changed, 80 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 550ab77..af62be9 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -1120,6 +1120,69 @@ static ssize_t vfio_pci_write(void *device_data, const
char __user *buf,
return vfio_pci_rw(device_data, (char __user *)buf, count, ppos, true);
}
+static int vfio_pci_add_vma(struct vfio_pci_device *vdev,
+ struct vm_area_struct *vma)
+{
+ struct vfio_pci_mmap_vma *mmap_vma;
+
+ mmap_vma = kmalloc(sizeof(*mmap_vma), GFP_KERNEL);
+ if (!mmap_vma)
+ return -ENOMEM;
+
+ mmap_vma->vma = vma;
+
+ mutex_lock(&vdev->vma_lock);
+ list_add(&mmap_vma->vma_next, &vdev->vma_list);
+ mutex_unlock(&vdev->vma_lock);
+
+ return 0;
+}
+
+/*
+ * Zap mmaps on open so that we can fault them in on access and therefore
+ * our vma_list only tracks mappings accessed since last zap.
+ */
+static void vfio_pci_mmap_open(struct vm_area_struct *vma)
+{
+ zap_vma_ptes(vma, vma->vm_start, vma->vm_end - vma->vm_start);
+}
+
+static void vfio_pci_mmap_close(struct vm_area_struct *vma)
+{
+ struct vfio_pci_device *vdev = vma->vm_private_data;
+ struct vfio_pci_mmap_vma *mmap_vma;
+
+ mutex_lock(&vdev->vma_lock);
+ list_for_each_entry(mmap_vma, &vdev->vma_list, vma_next) {
+ if (mmap_vma->vma == vma) {
+ list_del(&mmap_vma->vma_next);
+ kfree(mmap_vma);
+ break;
+ }
+ }
+ mutex_unlock(&vdev->vma_lock);
+}
+
+static int vfio_pci_mmap_fault(struct vm_area_struct *vma, struct vm_fault
*vmf)
+{
+ struct vfio_pci_device *vdev = vma->vm_private_data;
+
+ if (vfio_pci_add_vma(vdev, vma))
+ return VM_FAULT_OOM;
+
+ if (remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
+ vma->vm_end - vma->vm_start, vma->vm_page_prot))
+ return VM_FAULT_SIGBUS;
+
+ return VM_FAULT_NOPAGE;
+}
+
+static const struct vm_operations_struct vfio_pci_mmap_ops = {
+ .open = vfio_pci_mmap_open,
+ .close = vfio_pci_mmap_close,
+ .fault = vfio_pci_mmap_fault,
+};
+
static int vfio_pci_mmap(void *device_data, struct vm_area_struct *vma)
{
struct vfio_pci_device *vdev = device_data;
@@ -1185,8 +1248,14 @@ static int vfio_pci_mmap(void *device_data, struct
vm_area_struct *vma)
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
vma->vm_pgoff = (pci_resource_start(pdev, index) >> PAGE_SHIFT) + pgoff;
- return remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
- req_len, vma->vm_page_prot);
+ /*
+* See remap_pfn_range(), called from vfio_pci_fault() but we can't
+* change vm_flags within the fault handler. Set them now.
+*/
+ vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
+ vma->vm_ops = &vfio_pci_mmap_ops;
+
+ return 0;
}
static void vfio_pci_request(void *device_data, unsigned int count)
@@ -1244,6 +1313,8 @@ static int vfio_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
mutex_init(&vdev->igate);
spin_lock_init(&vdev->irqlock);
+ mutex_init(&vdev->vma_lock);
+ INIT_LIST_HEAD(&vdev->vma_list);
ret = vfio_add_group_dev(&pdev->dev, &vfio_pci_ops, vdev);
if (ret) {
vfio_iommu_group_put(group, &pdev->dev);
diff --git a/drivers/vfio/pci/vfio_pci_private.h
b/drivers/vfio/pci/vfio_pci_private.h
index f561ac1..4b78f12 100644
--- a/drivers/vfio/pci/vfio_pci_private.h
+++ b/drivers/vfio/pci/vfio_pci_private.h
@@ -63,6 +63,11 @@ struct vfio_pci_dummy_resource {
struct list_headres_next;
};
+struct vfio_pci_mmap_vma {
+ struct vm_area_struct *vma;
+ struct list_headvma_next;
+};
+
struct vfio_pci_device {
struct pci_dev *pdev;
void __iomem*barmap[PCI_STD_RESOURCE_END + 1];
@@ -95,6 +100,8 @@ struct vfio_pci_device {
struct eventfd_ctx *err_trigger;
struct eventfd_ctx *req_trigger;
s
Re: [PATCH v6 6/9] kernel: entry: Support Syscall User Dispatch for common syscall entry
On Mon, Sep 7, 2020 at 7:25 AM Christian Brauner wrote: > > On Mon, Sep 07, 2020 at 07:15:52AM -0700, Andy Lutomirski wrote: > > > > > > > On Sep 7, 2020, at 3:15 AM, Christian Brauner > > > wrote: > > > > > > On Fri, Sep 04, 2020 at 04:31:44PM -0400, Gabriel Krisman Bertazi wrote: > > >> Syscall User Dispatch (SUD) must take precedence over seccomp, since the > > >> use case is emulation (it can be invoked with a different ABI) such that > > >> seccomp filtering by syscall number doesn't make sense in the first > > >> place. In addition, either the syscall is dispatched back to userspace, > > >> in which case there is no resource for seccomp to protect, or the > > > > > > Tbh, I'm torn here. I'm not a super clever attacker but it feels to me > > > that this is still at least a clever way to circumvent a seccomp > > > sandbox. > > > If I'd be confined by a seccomp profile that would cause me to be > > > SIGKILLed when I try do open() I could prctl() myself to do user > > > dispatch to prevent that from happening, no? > > > > > > > Not really, I think. The idea is that you didn’t actually do open(). > > You did a SYSCALL instruction which meant something else, and the > > syscall dispatch correctly prevented the kernel from misinterpreting > > it as open(). > > Right, for the case where you're e.g. emulating windows syscalls that's > true. I was thinking when you're running natively on Linux: couldn't I > first load a seccomp profile "kill me if someone does an open()", then > I exec() the target binary and that binary is setup to do > prctl(USER_DISPATCH) first thing. I guess, it's ok because as far as I > had time to read it this is a nothing or all mechanism, i.e. _all_ > system calls are re-routed in contrast to e.g. seccomp where I could do > this per-syscall. So for user-dispatch it wouldn't make sense to use it > on Linux per se. Still makes me a little uneasy. :) There's an escape hatch, so processes using this can still make syscalls. Maybe think about it another way: a process using user dispatch should definitely *not* trigger seccomp user notifiers, errno returns, or ptrace events, since they'll all do the wrong thing. IMO RET_KILL is the same. Barring some very severe defect, there's no way a program can use user dispatch to escape seccomp -- a program could use user dispatch to allow them to do: mov $__NR_open, %rax syscall without dying despite the presence of a filter that would kill the process if it tried to do open(), but this doesn't bypass the filter at all. The process could just as easily have done: mov $__NR_open jmp magic_stub(%rip) without tripping the filter, since no system call actually happens here. --Andy
[PATCH] airo: switch from 'pci_' to 'dma_' API
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below and has been
hand modified to replace GFP_ with a correct flag.
It has been compile tested.
When memory is allocated in 'mpi_map_card()' GFP_KERNEL can be used because
this function is called from a probe or a module_init() function and no
spinlock is taken in the between.
The call chains are:
airo_init_module module_init function in 'airo.c'
or
airo_probe.probe function in 'airo_cs.c'
--> airo_config
followed in both cases by:
--> init_airo_card
--> _init_airo_card
--> mpi_map_card
@@
@@
-PCI_DMA_BIDIRECTIONAL
+DMA_BIDIRECTIONAL
@@
@@
-PCI_DMA_TODEVICE
+DMA_TO_DEVICE
@@
@@
-PCI_DMA_FROMDEVICE
+DMA_FROM_DEVICE
@@
@@
-PCI_DMA_NONE
+DMA_NONE
@@
expression e1, e2, e3;
@@
-pci_alloc_consistent(e1, e2, e3)
+dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
@@
expression e1, e2, e3;
@@
-pci_zalloc_consistent(e1, e2, e3)
+dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_single(e1, e2, e3, e4)
+dma_map_single(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_single(e1, e2, e3, e4)
+dma_unmap_single(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4, e5;
@@
-pci_map_page(e1, e2, e3, e4, e5)
+dma_map_page(&e1->dev, e2, e3, e4, e5)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_page(e1, e2, e3, e4)
+dma_unmap_page(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_sg(e1, e2, e3, e4)
+dma_map_sg(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_sg(e1, e2, e3, e4)
+dma_unmap_sg(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
+dma_sync_single_for_cpu(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_device(e1, e2, e3, e4)
+dma_sync_single_for_device(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
+dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_device(e1, e2, e3, e4)
+dma_sync_sg_for_device(&e1->dev, e2, e3, e4)
@@
expression e1, e2;
@@
-pci_dma_mapping_error(e1, e2)
+dma_mapping_error(&e1->dev, e2)
@@
expression e1, e2;
@@
-pci_set_dma_mask(e1, e2)
+dma_set_mask(&e1->dev, e2)
@@
expression e1, e2;
@@
-pci_set_consistent_dma_mask(e1, e2)
+dma_set_coherent_mask(&e1->dev, e2)
Signed-off-by: Christophe JAILLET
---
If needed, see post from Christoph Hellwig on the kernel-janitors ML:
https://marc.info/?l=kernel-janitors&m=158745678307186&w=4
---
drivers/net/wireless/cisco/airo.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/cisco/airo.c
b/drivers/net/wireless/cisco/airo.c
index dd78c415d6e7..87b9398b03fd 100644
--- a/drivers/net/wireless/cisco/airo.c
+++ b/drivers/net/wireless/cisco/airo.c
@@ -2430,8 +2430,8 @@ void stop_airo_card(struct net_device *dev, int freeres)
iounmap(ai->pcimem);
if (ai->pciaux)
iounmap(ai->pciaux);
- pci_free_consistent(ai->pci, PCI_SHARED_LEN,
- ai->shared, ai->shared_dma);
+ dma_free_coherent(&ai->pci->dev, PCI_SHARED_LEN,
+ ai->shared, ai->shared_dma);
}
}
crypto_free_sync_skcipher(ai->tfm);
@@ -2581,9 +2581,10 @@ static int mpi_map_card(struct airo_info *ai, struct
pci_dev *pci)
}
/* Reserve PKTSIZE for each fid and 2K for the Rids */
- ai->shared = pci_alloc_consistent(pci, PCI_SHARED_LEN, &ai->shared_dma);
+ ai->shared = dma_alloc_coherent(&pci->dev, PCI_SHARED_LEN,
+ &ai->shared_dma, GFP_KERNEL);
if (!ai->shared) {
- airo_print_err("", "Couldn't alloc_consistent %d",
+ airo_print_err("", "Couldn't alloc_coherent %d",
PCI_SHARED_LEN);
goto free_auxmap;
}
@@ -2643,7 +2644,8 @@ static int mpi_map_card(struct airo_info *ai, struct
pci_dev *pci)
return 0;
free_shared:
- pci_free_consistent(pci, PCI_SHARED_LEN, ai->shared, ai->shared_dma);
+ dma_free_coherent(&pci->dev, PCI_SHARED_LEN, ai->shared,
+ ai->shared_dma);
free_auxmap:
iounmap(ai->pciaux);
free_memmap:
@@ -2930,7 +2932,8 @@ static struct net_device *_init_airo_card(unsigned short
irq, int port,
unregister_netdev(dev);
err_out_map:
if (test_bit(FLAG_MPI,&ai->flags) && pci
Re: [PATCH -next] kdb: Use newer api for tasklist scanning
On Mon, 07 Sep 2020, Daniel Thompson wrote: No objections to the change but kdb doesn't use tsk->thread_group, it uses do_each_thread/while_each_thread. Can we change this to say that is osbsolete and racy to use while_each_thread() (that's pretty much what the description of the patch that introduced for_each_thread said)? Well while_each_thread() is just a loop around next_thread(), which uses tsk->thread_group. But sure, I can rephrase a v2 to say while_each_thread. Additionally the debug_core uses do_each_thread/while_each_thread. Presumably that would like to be changed as well? Are you referring to gdb_cmd_query()? Yeah, that's another one that can be replaced. Because we need not worry about races, it's rather simple to justify both replacements in the same patch, which I'll add to v2. Thanks, Davidlohr
Re: [PATCH V2 5/5] DO NOT MERGE: iommu: disable list appending in dma-iommu
On Mon, 7 Sep 2020 at 08:00, Christoph Hellwig wrote: > > On Thu, Sep 03, 2020 at 09:18:37PM +0100, Tom Murphy wrote: > > Disable combining sg segments in the dma-iommu api. > > Combining the sg segments exposes a bug in the intel i915 driver which > > causes visual artifacts and the screen to freeze. This is most likely > > because of how the i915 handles the returned list. It probably doesn't > > respect the returned value specifying the number of elements in the list > > and instead depends on the previous behaviour of the intel iommu driver > > which would return the same number of elements in the output list as in > > the input list. > > So what is the state of addressing this properly in i915? IF we can't I think this is the latest on addressing this issue: https://patchwork.kernel.org/cover/11306999/ tl;dr: some people seem to be looking at it but I'm not sure if it's being actively worked on > get it done ASAP I wonder if we need a runtime quirk to disable > merging instead of blocking this conversion.. Yeah we talked about passing an attr to map_sg to disable merging at the following microconfernce: https://linuxplumbersconf.org/event/7/contributions/846/ As far as I can remember everyone seemed happy with that solution. I won't be working on this though as I don't have any more time to dedicate to this. It seems Lu Baolu will take over this.
Re: [RFC PATCH] x86/mce: Make mce_rdmsrl() do a plain RDMSR only
On Sun, Sep 6, 2020 at 2:21 PM Borislav Petkov wrote:
>
> Hi,
>
> Ingo and I talked about this thing this morning and tglx has had it on
> his to-fix list too so here's a first attempt at it.
>
> Below is just a brain dump of what we talked about so let's start with
> it and see where it would take us.
>
> Thx.
>
> ---
>
> From: Borislav Petkov
>
> ... without any exception handling and tracing.
>
> If an exception needs to be handled while reading an MSR - which is in
> most of the cases caused by a #GP on a non-existent MSR - then this
> is most likely the incarnation of a BIOS or a hardware bug. Such bug
> violates the architectural guarantee that MSR banks are present with all
> MSRs belonging to them.
>
> The proper fix belongs in the hardware/firmware - not in the kernel.
>
> Handling exceptions while in #MC and while an NMI is being handled would
> cause the nasty NMI nesting issue because of the shortcoming of IRET
> of reenabling NMIs when executed. And the machine is in an #MC context
> already so be at its side.
>
> Tracing MSR accesses while in #MC is another no-no due to tracing being
> inherently a bad idea in atomic context:
>
> vmlinux.o: warning: objtool: do_machine_check()+0x4a: call to mce_rdmsrl()
> leaves .noinstr.text section
>
> so remove all that "additional" functionality from mce_rdmsrl() and
> concentrate on solely reading the MSRs.
>
> Signed-off-by: Borislav Petkov
> Cc: Ingo Molnar
> ---
> arch/x86/kernel/cpu/mce/core.c | 18 +++---
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
> index 0ba24dfffdb2..14ebdf3e22f3 100644
> --- a/arch/x86/kernel/cpu/mce/core.c
> +++ b/arch/x86/kernel/cpu/mce/core.c
> @@ -376,7 +376,7 @@ static int msr_to_offset(u32 msr)
> /* MSR access wrappers used for error injection */
> static u64 mce_rdmsrl(u32 msr)
> {
> - u64 v;
> + DECLARE_ARGS(val, low, high);
>
> if (__this_cpu_read(injectm.finished)) {
> int offset = msr_to_offset(msr);
> @@ -386,17 +386,13 @@ static u64 mce_rdmsrl(u32 msr)
> return *(u64 *)((char *)this_cpu_ptr(&injectm) + offset);
> }
>
> - if (rdmsrl_safe(msr, &v)) {
> - WARN_ONCE(1, "mce: Unable to read MSR 0x%x!\n", msr);
> - /*
> -* Return zero in case the access faulted. This should
> -* not happen normally but can happen if the CPU does
> -* something weird, or if the code is buggy.
> -*/
> - v = 0;
> - }
> + /*
> +* RDMSR on MCA MSRs should not fault. If they do, this is very much
> an
> +* architectural violation and needs to be reported to hw vendor.
> +*/
> + asm volatile("rdmsr" : EAX_EDX_RET(val, low, high) : "c" (msr));
I don't like this. Plain rdmsrl() will at least print a nice error if it fails.
Perhaps we should add a read_msr_panic() variant that panics on
failure? Or, if there is just this one case, then we can use
rdmsrl_safe() and print a nice error and panic on failure.
Re: [RFC PATCH v2 3/3] mm: make generic pXd_addr_end() macros inline functions
Hi,
Some style comments below.
On Mon, Sep 07, 2020 at 08:00:58PM +0200, Gerald Schaefer wrote:
> From: Alexander Gordeev
>
> Since pXd_addr_end() macros take pXd page-table entry as a
> parameter it makes sense to check the entry type on compile.
> Even though most archs do not make use of page-table entries
> in pXd_addr_end() calls, checking the type in traversal code
> paths could help to avoid subtle bugs.
>
> Signed-off-by: Alexander Gordeev
> Signed-off-by: Gerald Schaefer
> ---
> include/linux/pgtable.h | 36
> 1 file changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 67ebc22cf83d..d9e7d16c2263 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -656,31 +656,35 @@ static inline int arch_unmap_one(struct mm_struct *mm,
> */
>
> #ifndef pgd_addr_end
> -#define pgd_addr_end(pgd, addr, end) \
> -({ unsigned long __boundary = ((addr) + PGDIR_SIZE) & PGDIR_MASK; \
> - (__boundary - 1 < (end) - 1)? __boundary: (end);\
> -})
> +#define pgd_addr_end pgd_addr_end
> +static inline unsigned long pgd_addr_end(pgd_t pgd, unsigned long addr,
> unsigned long end)
> +{unsigned long __boundary = (addr + PGDIR_SIZE) & PGDIR_MASK;
The code should be on a separate line from the curly brace.
Besides, since this is not a macro anymore, I think it would be nicer to
use 'boundary' without underscores.
This applies to the changes below as well.
> + return (__boundary - 1 < end - 1) ? __boundary : end;
> +}
> #endif
>
> #ifndef p4d_addr_end
> -#define p4d_addr_end(p4d, addr, end) \
> -({ unsigned long __boundary = ((addr) + P4D_SIZE) & P4D_MASK; \
> - (__boundary - 1 < (end) - 1)? __boundary: (end);\
> -})
> +#define p4d_addr_end p4d_addr_end
> +static inline unsigned long p4d_addr_end(p4d_t p4d, unsigned long addr,
> unsigned long end)
> +{unsigned long __boundary = (addr + P4D_SIZE) & P4D_MASK;
> + return (__boundary - 1 < end - 1) ? __boundary : end;
> +}
> #endif
>
> #ifndef pud_addr_end
> -#define pud_addr_end(pud, addr, end) \
> -({ unsigned long __boundary = ((addr) + PUD_SIZE) & PUD_MASK; \
> - (__boundary - 1 < (end) - 1)? __boundary: (end);\
> -})
> +#define pud_addr_end pud_addr_end
> +static inline unsigned long pud_addr_end(pud_t pud, unsigned long addr,
> unsigned long end)
> +{unsigned long __boundary = (addr + PUD_SIZE) & PUD_MASK;
> + return (__boundary - 1 < end - 1) ? __boundary : end;
> +}
> #endif
>
> #ifndef pmd_addr_end
> -#define pmd_addr_end(pmd, addr, end) \
> -({ unsigned long __boundary = ((addr) + PMD_SIZE) & PMD_MASK; \
> - (__boundary - 1 < (end) - 1)? __boundary: (end);\
> -})
> +#define pmd_addr_end pmd_addr_end
> +static inline unsigned long pmd_addr_end(pmd_t pmd, unsigned long addr,
> unsigned long end)
> +{unsigned long __boundary = (addr + PMD_SIZE) & PMD_MASK;
> + return (__boundary - 1 < end - 1) ? __boundary : end;
> +}
> #endif
>
> /*
> --
> 2.17.1
>
--
Sincerely yours,
Mike.
Re: [PATCH] fs: align IOCB_* flags with RWF_* flags
On Mon, Aug 31, 2020 at 12:08:10PM -0600, Jens Axboe wrote: > We have a set of flags that are shared between the two and inherired > in kiocb_set_rw_flags(), but we check and set these individually. > Reorder the IOCB flags so that the bottom part of the space is synced > with the RWF flag space, and then we can do them all in one mask and > set operation. > > The only exception is RWF_SYNC, which needs to mark IOCB_SYNC and > IOCB_DSYNC. Do that one separately. > > This shaves 15 bytes of text from kiocb_set_rw_flags() for me. > > Signed-off-by: Jens Axboe Suggested-by: Matthew Wilcox (Oracle)
Re: [RFC PATCH v2 0/3] mm/gup: fix gup_fast with dynamic page table folding
On Mon, Sep 07, 2020 at 08:00:55PM +0200, Gerald Schaefer wrote: > This is v2 of an RFC previously discussed here: > https://lore.kernel.org/lkml/20200828140314.8556-1-gerald.schae...@linux.ibm.com/ > > Patch 1 is a fix for a regression in gup_fast on s390, after our conversion > to common gup_fast code. It will introduce special helper functions > pXd_addr_end_folded(), which have to be used in places where pagetable walk > is done w/o lock and with READ_ONCE, so currently only in gup_fast. > > Patch 2 is an attempt to make that more generic, i.e. change pXd_addr_end() > themselves by adding an extra pXd value parameter. That was suggested by > Jason during v1 discussion, because he is already thinking of some other > places where he might want to switch to the READ_ONCE logic for pagetable > walks. In general, that would be the cleanest / safest solution, but there > is some impact on other architectures and common code, hence the new and > greatly enlarged recipient list. > > Patch 3 is a "nice to have" add-on, which makes pXd_addr_end() inline > functions instead of #defines, so that we get some type checking for the > new pXd value parameter. > > Not sure about Fixes/stable tags for the generic solution. Only patch 1 > fixes a real bug on s390, and has Fixes/stable tags. Patches 2 + 3 might > still be nice to have in stable, to ease future backports, but I guess > "nice to have" does not really qualify for stable backports. I also think that adding pXd parameter to pXd_addr_end() is a cleaner way and with this patch 1 is not really required. I would even merge patches 2 and 3 into a single patch and use only it as the fix. [ /me apologises to stable@ team :-) ] > Changes in v2: > - Pick option 2 from v1 discussion (pXd_addr_end_folded helpers) > - Add patch 2 + 3 for more generic approach > > Alexander Gordeev (3): > mm/gup: fix gup_fast with dynamic page table folding > mm: make pXd_addr_end() functions page-table entry aware > mm: make generic pXd_addr_end() macros inline functions > > arch/arm/include/asm/pgtable-2level.h| 2 +- > arch/arm/mm/idmap.c | 6 ++-- > arch/arm/mm/mmu.c| 8 ++--- > arch/arm64/kernel/hibernate.c| 16 + > arch/arm64/kvm/mmu.c | 16 - > arch/arm64/mm/kasan_init.c | 8 ++--- > arch/arm64/mm/mmu.c | 25 +++--- > arch/powerpc/mm/book3s64/radix_pgtable.c | 7 ++-- > arch/powerpc/mm/hugetlbpage.c| 6 ++-- > arch/s390/include/asm/pgtable.h | 42 > arch/s390/mm/page-states.c | 8 ++--- > arch/s390/mm/pageattr.c | 8 ++--- > arch/s390/mm/vmem.c | 8 ++--- > arch/sparc/mm/hugetlbpage.c | 6 ++-- > arch/um/kernel/tlb.c | 8 ++--- > arch/x86/mm/init_64.c| 15 - > arch/x86/mm/kasan_init_64.c | 16 - > include/asm-generic/pgtable-nop4d.h | 2 +- > include/asm-generic/pgtable-nopmd.h | 2 +- > include/asm-generic/pgtable-nopud.h | 2 +- > include/linux/pgtable.h | 38 - > mm/gup.c | 8 ++--- > mm/ioremap.c | 8 ++--- > mm/kasan/init.c | 17 +- > mm/madvise.c | 4 +-- > mm/memory.c | 40 +++--- > mm/mlock.c | 18 +++--- > mm/mprotect.c| 8 ++--- > mm/pagewalk.c| 8 ++--- > mm/swapfile.c| 8 ++--- > mm/vmalloc.c | 16 - > 31 files changed, 219 insertions(+), 165 deletions(-) > > -- > 2.17.1 > -- Sincerely yours, Mike.
Re: [PATCHv3] selftests: rtnetlink: load fou module for kci_test_encap_fou() test
On Mon, 7 Sep 2020 11:50:10 +0800 Po-Hsu Lin wrote: > The kci_test_encap_fou() test from kci_test_encap() in rtnetlink.sh > needs the fou module to work. Otherwise it will fail with: > > $ ip netns exec "$testns" ip fou add port ipproto 47 > RTNETLINK answers: No such file or directory > Error talking to the kernel > > Add the CONFIG_NET_FOU into the config file as well. Which needs at > least to be set as a loadable module. > > Signed-off-by: Po-Hsu Lin > diff --git a/tools/testing/selftests/net/rtnetlink.sh > b/tools/testing/selftests/net/rtnetlink.sh > index 7c38a90..a711b3e 100755 > --- a/tools/testing/selftests/net/rtnetlink.sh > +++ b/tools/testing/selftests/net/rtnetlink.sh > @@ -520,6 +520,11 @@ kci_test_encap_fou() > return $ksft_skip > fi > > + if ! /sbin/modprobe -q -n fou; then > + echo "SKIP: module fou is not found" > + return $ksft_skip > + fi > + /sbin/modprobe -q fou > ip -netns "$testns" fou add port ipproto 47 2>/dev/null > if [ $? -ne 0 ];then > echo "FAIL: can't add fou port , skipping test" > @@ -540,6 +545,7 @@ kci_test_encap_fou() > return 1 > fi > > + /sbin/modprobe -q -r fou I think the common practice is to not remove the module at the end of the test. It may be used by something else than the test itself. > echo "PASS: fou" > } >
Re: [RFC PATCH] x86/mce: Make mce_rdmsrl() do a plain RDMSR only
On Sun, Sep 06, 2020 at 11:21:30PM +0200, Borislav Petkov wrote:
> Hi,
>
> Ingo and I talked about this thing this morning and tglx has had it on
> his to-fix list too so here's a first attempt at it.
>
> Below is just a brain dump of what we talked about so let's start with
> it and see where it would take us.
This very much looks to be the right thing to do. Returning "0" from
a failed RDMSR in MCE handling might be a much worse thing to do than
crashing. It papers over a serious error and the system might keep
running using corrupted data.
Digging into the history it seems that this rdmsrl_safe() was added for
a possible bug on a pentiumIII back in 2009 that was eventually closed
as "unreproducible".
Do we have three distinct classes of calls to RDMSR now?
1) This case. Architecture checks have been made. This call can't
fail. We are calling from a tricky state (on IST) so no tracing
allowed.
2) Normal case ... architecture checks have been done so shouldn't
fail. Safe state for tracing etc. Use rdmsrl().
3) Probe case. Architecture didn't provide definitive enumeration,
so we might take a #GP. Use the rdmsrl_safe().
> + /*
> + * RDMSR on MCA MSRs should not fault. If they do, this is very much an
> + * architectural violation and needs to be reported to hw vendor.
> + */
> + asm volatile("rdmsr" : EAX_EDX_RET(val, low, high) : "c" (msr));
If mce subsystem is the only instance of case "1", then this
inline is OK. If there are others then rather than inlining
the asm here, we should have some new rdmsrl_notrace() inline
function declared for all to use.
Needs a:
Fixes: 11868a2dc4f5 ("x86: mce: Use safer ways to access MCE registers")
since this is undoing an earlier change.
-Tony
Re: [PATCH v3 10/15] MIPS: generic: Increase NR_IRQS to 256
On Sun, Sep 06, 2020 at 09:29:30PM +0200, Paul Cercueil wrote: > 128 IRQs is not enough to support Ingenic SoCs. > > Signed-off-by: Paul Cercueil > --- > > Notes: > v2-v3: No change > > arch/mips/include/asm/mach-generic/irq.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/mips/include/asm/mach-generic/irq.h > b/arch/mips/include/asm/mach-generic/irq.h > index 72ac2c202c55..079889ced4f3 100644 > --- a/arch/mips/include/asm/mach-generic/irq.h > +++ b/arch/mips/include/asm/mach-generic/irq.h > @@ -9,7 +9,7 @@ > #define __ASM_MACH_GENERIC_IRQ_H > > #ifndef NR_IRQS > -#define NR_IRQS 128 > +#define NR_IRQS 256 > #endif this will increase NR_IRQS for all platforms, which don't override NR_IRQS in their mach-XXX directory. Size of the data segment increases by 18464 bytes for a 32bit kernel and 33792 for a 64bit kernel. I would take this change as this allows to remove a few more mach-*/irq.h files. And if a platform needs save every byte it finds, we can add a irq.h file for that. An even nicer way would be to make NR_IRQS selectable via Kconfig. Something like "select NR_IRQS 51" would be quite handy for that... Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
[PATCH 5/4] drivers core: Convert class uses of sprintf to sysfs_emit
Use the sysfs_emit API.
Signed-off-by: Joe Perches
---
drivers/base/devcoredump.c | 2 +-
drivers/base/firmware_loader/fallback.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c
index e42d0b514384..9243468e2c99 100644
--- a/drivers/base/devcoredump.c
+++ b/drivers/base/devcoredump.c
@@ -123,7 +123,7 @@ static int devcd_free(struct device *dev, void *data)
static ssize_t disabled_show(struct class *class, struct class_attribute *attr,
char *buf)
{
- return sprintf(buf, "%d\n", devcd_disabled);
+ return sysfs_emit(buf, "%d\n", devcd_disabled);
}
static ssize_t disabled_store(struct class *class, struct class_attribute
*attr,
diff --git a/drivers/base/firmware_loader/fallback.c
b/drivers/base/firmware_loader/fallback.c
index 7e9598a1577a..d60e6d8c967c 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -124,7 +124,7 @@ void kill_pending_fw_fallback_reqs(bool only_kill_custom)
static ssize_t timeout_show(struct class *class, struct class_attribute *attr,
char *buf)
{
- return sprintf(buf, "%d\n", __firmware_loading_timeout());
+ return sysfs_emit(buf, "%d\n", __firmware_loading_timeout());
}
/**
--
2.26.0
Re: [PATCH v2 3/3] drm: panel: add TDO tl070wsh30 panel driver
Hi Neil.
On Mon, Sep 07, 2020 at 01:10:27PM +0200, Neil Armstrong wrote:
> This adds support for the TDO TL070WSH30 TFT-LCD panel module.
> The panel has a 1024×600 resolution and uses 24 bit RGB per pixel.
> It provides a MIPI DSI interface to the host, a built-in LED backlight
> and touch controller.
Despite a nicely written driver I noticed a few things that needs to be
addressed.
Sam
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/panel/Kconfig| 11 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c | 256 +++
> 3 files changed, 268 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 8d97d07c5871..2d488a875b99 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -433,6 +433,17 @@ config DRM_PANEL_SONY_ACX565AKM
> Say Y here if you want to enable support for the Sony ACX565AKM
> 800x600 3.5" panel (found on the Nokia N900).
>
> +config DRM_PANEL_TDO_TL070WSH30
> + tristate "TDO TL070WSH30 DSI panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y here if you want to enable support for TDO TL070WSH30 TFT-LCD
> + panel module. The panel has a 1024×600 resolution and uses
> + 24 bit RGB per pixel. It provides a MIPI DSI interface to
> + the host, a built-in LED backlight and touch controller.
> +
> config DRM_PANEL_TPO_TD028TTEC1
> tristate "Toppoly (TPO) TD028TTEC1 panel driver"
> depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 15a4e7752951..35ee06a1b5c2 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -45,6 +45,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) +=
> panel-sitronix-st7703.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
> obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
> +obj-$(CONFIG_DRM_PANEL_TDO_TL070WSH30) += panel-tdo-tl070wsh30.o
> obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
> obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
> obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
> diff --git a/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c
> b/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c
> new file mode 100644
> index ..c7a6c2c42c52
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c
> @@ -0,0 +1,256 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 BayLibre, SAS
> + * Author: Neil Armstrong
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct tdo_tl070wsh30_panel {
> + struct drm_panel base;
> + struct mipi_dsi_device *link;
> +
> + struct regulator *supply;
> + struct gpio_desc *reset_gpio;
> +
> + bool prepared;
> +};
> +
> +static inline
> +struct tdo_tl070wsh30_panel *to_tdo_tl070wsh30_panel(struct drm_panel *panel)
> +{
> + return container_of(panel, struct tdo_tl070wsh30_panel, base);
> +}
bikeshedding - but my preference is to order the functions:
prepare
enable
disable
unprepare
As this is the natural order they are used.
Feel free to ignore!
> +
> +static int tdo_tl070wsh30_panel_unprepare(struct drm_panel *panel)
> +{
> + struct tdo_tl070wsh30_panel *tdo_tl070wsh30 =
> to_tdo_tl070wsh30_panel(panel);
> + int err;
> +
> + if (!tdo_tl070wsh30->prepared)
> + return 0;
> +
> + err = mipi_dsi_dcs_set_display_off(tdo_tl070wsh30->link);
> + if (err < 0)
> + dev_err(panel->dev, "failed to set display off: %d\n", err);
> +
> + usleep_range(1, 11000);
> +
> + err = mipi_dsi_dcs_enter_sleep_mode(tdo_tl070wsh30->link);
> + if (err < 0) {
> + dev_err(panel->dev, "failed to enter sleep mode: %d\n", err);
> + return err;
> + }
> +
> + usleep_range(1, 11000);
> +
> + tdo_tl070wsh30->prepared = false;
> +
> + return 0;
> +}
> +
> +static int tdo_tl070wsh30_panel_prepare(struct drm_panel *panel)
> +{
> + struct tdo_tl070wsh30_panel *tdo_tl070wsh30 =
> to_tdo_tl070wsh30_panel(panel);
> + int err;
> +
> + if (tdo_tl070wsh30->prepared)
> + return 0;
> +
> + err = mipi_dsi_dcs_exit_sleep_mode(tdo_tl070wsh30->link);
> + if (err < 0) {
> + dev_err(panel->dev, "failed to exit sleep mode: %d\n", err);
> + return err;
> + }
> +
> + msleep(200);
> +
> + err = mipi_dsi_dcs_set_display_on(tdo_tl070wsh30->link);
> + if (err < 0) {
> + dev_err(panel->dev, "failed to set display on: %d\n
Re: [PATCH] fs: align IOCB_* flags with RWF_* flags
On 8/31/20 12:08 PM, Jens Axboe wrote: > We have a set of flags that are shared between the two and inherired > in kiocb_set_rw_flags(), but we check and set these individually. > Reorder the IOCB flags so that the bottom part of the space is synced > with the RWF flag space, and then we can do them all in one mask and > set operation. > > The only exception is RWF_SYNC, which needs to mark IOCB_SYNC and > IOCB_DSYNC. Do that one separately. > > This shaves 15 bytes of text from kiocb_set_rw_flags() for me. Al, are you OK with me queueing this one up? I'm fine either way, obviously no dependencies for this one, just want to ensure it isn't dropped. -- Jens Axboe
Re: [PATCH -next] blktrace: make function blk_trace_bio_get_cgid() static
On 9/7/20 8:06 AM, Wang Hai wrote: > The sparse tool complains as follows: > > kernel/trace/blktrace.c:796:5: warning: > symbol 'blk_trace_bio_get_cgid' was not declared. Should it be static? > > This function is not used outside of blktrace.c, so this commit > marks it static. Applied, thanks. -- Jens Axboe
[PATCH v2] rtlwifi: switch from 'pci_' to 'dma_' API
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. The only file where some GFP_ flags are updated is 'pci.c'. When memory is allocated in '_rtl_pci_init_tx_ring()' and '_rtl_pci_init_rx_ring()' GFP_KERNEL can be used because both functions are called from a probe function and no spinlock is taken. The call chain is: rtl_pci_probe --> rtl_pci_init --> _rtl_pci_init_trx_ring --> _rtl_pci_init_rx_ring --> _rtl_pci_init_tx_ring @@ @@ -PCI_DMA_BIDIRECTIONAL +DMA_BIDIRECTIONAL @@ @@ -PCI_DMA_TODEVICE +DMA_TO_DEVICE @@ @@ -PCI_DMA_FROMDEVICE +DMA_FROM_DEVICE @@ @@ -PCI_DMA_NONE +DMA_NONE @@ expression e1, e2, e3; @@ -pci_alloc_consistent(e1, e2, e3) +dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ -pci_zalloc_consistent(e1, e2, e3) +dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ -pci_free_consistent(e1, e2, e3, e4) +dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ -pci_map_single(e1, e2, e3, e4) +dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ -pci_unmap_single(e1, e2, e3, e4) +dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ -pci_map_page(e1, e2, e3, e4, e5) +dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ -pci_unmap_page(e1, e2, e3, e4) +dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ -pci_map_sg(e1, e2, e3, e4) +dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ -pci_unmap_sg(e1, e2, e3, e4) +dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ -pci_dma_sync_single_for_cpu(e1, e2, e3, e4) +dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ -pci_dma_sync_single_for_device(e1, e2, e3, e4) +dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ -pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) +dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ -pci_dma_sync_sg_for_device(e1, e2, e3, e4) +dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ -pci_dma_mapping_error(e1, e2) +dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ -pci_set_dma_mask(e1, e2) +dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ -pci_set_consistent_dma_mask(e1, e2) +dma_set_coherent_mask(&e1->dev, e2) Signed-off-by: Christophe JAILLET --- If needed, see post from Christoph Hellwig on the kernel-janitors ML: https://marc.info/?l=kernel-janitors&m=158745678307186&w=4 V2: rebased on latest wireless-drivers-next because V1 does not apply cleanly anymore --- drivers/net/wireless/realtek/rtlwifi/pci.c| 116 +- .../wireless/realtek/rtlwifi/rtl8188ee/hw.c | 9 +- .../wireless/realtek/rtlwifi/rtl8188ee/trx.c | 13 +- .../wireless/realtek/rtlwifi/rtl8192ce/trx.c | 14 +-- .../wireless/realtek/rtlwifi/rtl8192de/trx.c | 12 +- .../wireless/realtek/rtlwifi/rtl8192ee/trx.c | 13 +- .../wireless/realtek/rtlwifi/rtl8192se/trx.c | 12 +- .../wireless/realtek/rtlwifi/rtl8723ae/trx.c | 14 +-- .../wireless/realtek/rtlwifi/rtl8723be/hw.c | 9 +- .../wireless/realtek/rtlwifi/rtl8723be/trx.c | 13 +- .../wireless/realtek/rtlwifi/rtl8821ae/hw.c | 9 +- .../wireless/realtek/rtlwifi/rtl8821ae/trx.c | 13 +- 12 files changed, 115 insertions(+), 132 deletions(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c index f1ae9c2bf0f5..d9f90e58 100644 --- a/drivers/net/wireless/realtek/rtlwifi/pci.c +++ b/drivers/net/wireless/realtek/rtlwifi/pci.c @@ -547,11 +547,10 @@ static void _rtl_pci_tx_isr(struct ieee80211_hw *hw, int prio) ring->idx = (ring->idx + 1) % ring->entries; skb = __skb_dequeue(&ring->queue); - pci_unmap_single(rtlpci->pdev, -rtlpriv->cfg->ops-> -get_desc(hw, (u8 *)entry, true, - HW_DESC_TXBUFF_ADDR), -skb->len, PCI_DMA_TODEVICE); + dma_unmap_single(&rtlpci->pdev->dev, +rtlpriv->cfg->ops->get_desc(hw, (u8 *)entry, + true, HW_DESC_TXBUFF_ADDR), +skb->len, DMA_TO_DEVICE); /* remove early mode header */ if (rtlpriv->rtlhal.earlymode_enable) @@ -646,10 +645,10 @@ static int _rtl_pci_init_one_rxdesc(struct ieee80211_hw *hw, remap: /* just set skb->cb to mapping addr for pci_unmap_single use */ *((dma_addr_t *)sk
Re: [PATCH v2 2/3] dt-bindings: display: panel: add TDO tl070wsh30 DSI panel bindings
Hi Neil.
On Mon, Sep 07, 2020 at 03:24:47PM +0200, Neil Armstrong wrote:
> Hi,
>
> On 07/09/2020 13:45, Sam Ravnborg wrote:
> > Hi Neil.
> >
> > On Mon, Sep 07, 2020 at 01:10:26PM +0200, Neil Armstrong wrote:
> >> This add the bindings for the 1024*600 tl070wsh30 DSI panel.
> >
> > The binding looks like a panel-simple-dsi.yaml candidate.
> > Only differen is enable-gpios versus reset-gpios
>
> This is the only difference, the panel only has a reset signal and no
> enable signal.
>
> But I can add a reset-gpios to panel-simple-dsi.yaml, would it be ok ?
Yes, that would be fine as long as it is not a required property.
It was a mistake we did not add it from the beginning.
There has been patches floating to add reset-gpios to panle.simple.c
that I rejected - this was also wrong.
Really simple and dumb panels has no reset but dsi panels that
panel-simple supports too has a reset.
Sam
>
> Neil
>
> >
> > Could you check if we can use panel-simple-dsi-yaml.
> >
> > Sam
> >
> >>
> >> Signed-off-by: Neil Armstrong
> >> ---
> >> .../display/panel/tdo,tl070wsh30.yaml | 58 +++
> >> 1 file changed, 58 insertions(+)
> >> create mode 100644
> >> Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
> >> b/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
> >> new file mode 100644
> >> index ..20f4fdedfcb0
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/panel/tdo,tl070wsh30.yaml
> >> @@ -0,0 +1,58 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> >> +# Copyright 2020 BayLibre, SAS
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/display/panel/tdo,tl070wsh30.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: TDO TL070WSH30 DSI panel
> >> +
> >> +maintainers:
> >> + - Neil Armstrong
> >> +
> >> +allOf:
> >> + - $ref: panel-common.yaml#
> >> +
> >> +properties:
> >> +
> >> + compatible:
> >> +enum:
> >> + - tdo,tl070wsh30
> >> +
> >> + reg:
> >> +maxItems: 1
> >> +description: DSI virtual channel
> >> +
> >> + backlight: true
> >> + reset-gpios: true
> >> + port: true
> >> + power-supply: true
> >> +
> >> +additionalProperties: false
> >> +
> >> +required:
> >> + - compatible
> >> + - power-supply
> >> + - reset-gpios
> >> + - port
> >> + - reg
> >> +
> >> +examples:
> >> + - |
> >> +dsi {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + panel@0 {
> >> +compatible = "tdo,tl070wsh30";
> >> +reg = <0>;
> >> +power-supply = <&vcc_lcd_reg>;
> >> +backlight = <&panel_backlight>;
> >> +reset-gpios = <&gpio_reset>;
> >> +
> >> +port {
> >> + panel: endpoint {
> >> +remote-endpoint = <&mipi_dsi_out>;
> >> + };
> >> +};
> >> + };
> >> +};
> >> --
> >> 2.22.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: watchdog: sp5100_tco support for AMD V/R/E series
On 9/7/20 8:46 AM, Jan Kiszka wrote: > On 07.09.20 17:31, Guenter Roeck wrote: >> On 9/7/20 4:20 AM, Jan Kiszka wrote: >>> Hi all, >>> >>> Arsalan reported that the upstream driver for sp5100_tco does not work >>> for embedded Ryzen. Meanwhile, I was able to confirm that on an R1505G: >>> >>> [ 11.607251] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver >>> [ 11.607337] sp5100-tco sp5100-tco: Using 0xfed80b00 for watchdog MMIO >>> address >>> [ 11.607344] sp5100-tco sp5100-tco: Watchdog hardware is disabled >>> >>> ..and fix it: >>> >>> diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c >>> index 85e9664318c9..5482154fde42 100644 >>> --- a/drivers/watchdog/sp5100_tco.c >>> +++ b/drivers/watchdog/sp5100_tco.c >>> @@ -193,7 +193,8 @@ static void tco_timer_enable(struct sp5100_tco *tco) >>> /* Set the Watchdog timer resolution to 1 sec and enable */ >>> sp5100_tco_update_pm_reg8(EFCH_PM_DECODEEN3, >>> ~EFCH_PM_WATCHDOG_DISABLE, >>> - EFCH_PM_DECODEEN_SECOND_RES); >>> + EFCH_PM_DECODEEN_SECOND_RES | >>> + EFCH_PM_DECODEEN_WDT_TMREN); >> >> Confusing. The register in question is a 32-bit register, but only a byte >> is written into it. Bit 24-25 are supposed to be the resolution, bit 25-26 >> set to 0 enable the watchdog. Bit 7 is supposed to enable MMIO decoding. >> This is from AMD Publication 52740. So something in the existing code >> is (or seems to be) wrong, but either case I don't see how setting bit 7 >> (or 31 ?) would enable the watchdog hardware. >> >> Hmm, I wrote that code. Guess I'll need to to spend some time figuring out >> what is going on. > > The logic came from [1] which inspired [2] - that's where I pointed out > the large overlap with the existing upstream driver. I would love to see > all that consolidated. > > BTW, the R1505G is family 0x17. Maybe something changed there, and that > bit 7 was just reserved/ignored so far. ENOSPECS > Thanks for the pointers. I think you are talking about bit 31. Bit 7 is and was WatchdogTmrEn, but that supposedly only enables watchdog timer memory access at 0xfeb0. From what I glance from the other drivers, the existing code is wrong. It should set the disable and resolution bits in register offset 3 (bit 24..27), not 0. In other words, EFCH_PM_DECODEEN3 should be defined as 0x03, not as 0x00. Which actually makes sense from the name. Playing with my hardware, turns out that setting bit 7 in EFCH_PM_DECODEEN (register offset 0) does indeed enable the watchdog. I'll need to check if it actually works. Either case, -ENOSPECS is really a problem here. Guenter > Jan > > [1] > https://git.yoctoproject.org/cgit/cgit.cgi/meta-amd/commit/meta-amd-bsp/recipes-kernel/amd-wdt/files/amd_wdt.c?id=cd760c9f04d276382a0f5156dabdb766594ace56 > [2] > https://github.com/siemens/efibootguard/commit/3a702aa96d193f26571ea4e70db29ef01a0d4d5f >
Re: [PATCH 2/2] clk: mediatek: Add MT8167 clock support
Hi Fabien,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on clk/clk-next rockchip/for-next soc/for-next
shawnguo/for-next v5.9-rc4 next-20200903]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Fabien-Parent/dt-bindings-clock-mediatek-add-bindings-for-MT8167-clocks/20200907-210215
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-randconfig-r025-20200907 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
ab68517e6b7e51b84c4b0e813a30258ec1ce5da5)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/clk/mediatek/clk-mt8167.c:419:27: warning: unused variable
>> 'axi_mfg_in_parents_e1' [-Wunused-const-variable]
static const char * const axi_mfg_in_parents_e1[] __initconst = {
^
warning: some functions compiled with BTI and some compiled without BTI
warning: not setting BTI in feature flags
1 warning generated.
#
https://github.com/0day-ci/linux/commit/a74658124a04b2423e4919643d37b4ef32bec7af
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Fabien-Parent/dt-bindings-clock-mediatek-add-bindings-for-MT8167-clocks/20200907-210215
git checkout a74658124a04b2423e4919643d37b4ef32bec7af
vim +/axi_mfg_in_parents_e1 +419 drivers/clk/mediatek/clk-mt8167.c
418
> 419 static const char * const axi_mfg_in_parents_e1[] __initconst = {
420 "clk26m_ck",
421 "gfmux_emi1x_sel",
422 "univpll_d24",
423 "mmpll380m"
424 };
425
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [Nouveau] pcieport 0000:00:01.0: PME: Spurious native interrupt (nvidia with nouveau and thunderbolt on thinkpad P73)
On Sun, Sep 6, 2020 at 8:52 PM Marc MERLIN wrote: > > Ok, I have an update to this problem. I added the nouveau list because > I can't quite tell if the issue is: > - the PCIe changes that went in 5.6 I think (or 5.5?), referenced below > > - a new issue with thunderbold on thinkpad P73, that seems to be > triggered if I have a USB-C yubikey in the port. With 5.7, my issues > went away if I removed the USB key during boot, showing an interaction > between nouveau and thunderbolt > > - changes in the nouveau driver. Mika told me the PCIe regression > "pcieport :00:01.0: PME: Spurious native interrupt!" is supposed > to be fixed in 5.8, but I still get a 4mn hang or so during boot and > with 5.8, removing the USB key, didn't help make the boot faster > that's the root port the GPU is attached to, no? I saw that message on the Thinkpad P1G2 when runtime resuming the Nvidia GPU, but it does seem to come from the root port. > I don't otherwise use the nvidia chip I so wish I didn't have, I only > use intel graphics on that laptop, but I must apparently use the nouveau > driver to manage the nouveau chip so that it's turned off and not > burning 60W doing nothing. > Well, you'd also need it when attaching external displays. > lspci is in the quoted message below, I won't copy it here again, but > here's the nvidia bit: > 01:00.0 VGA compatible controller: NVIDIA Corporation TU104GLM [Quadro RTX > 4000 Mobile / Max-Q] (rev a1) > 01:00.1 Audio device: NVIDIA Corporation TU104 HD Audio Controller (rev a1) > 01:00.2 USB controller: NVIDIA Corporation TU104 USB 3.1 Host Controller (rev > a1) > 01:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU104 USB Type-C > UCSI Controller (rev a1) > > Here are 5 boots, 4 on 5.8.5: > > dmesg.1_hang_but_no_warning.txt https://pastebin.com/Y5NaH08n > Boot hung for quite a while, but no clear output > > dmesg.2_pme_spurious.txt https://pastebin.com/dX19aCpj > [8.185808] nvidia-gpu :01:00.3: runtime IRQ mapping not provided by > arch > [8.185989] nvidia-gpu :01:00.3: enabling device ( -> 0002) > [8.188986] nvidia-gpu :01:00.3: enabling bus mastering > [ 11.936507] nvidia-gpu :01:00.3: PME# enabled > [ 11.975985] nvidia-gpu :01:00.3: PME# disabled > [ 11.976011] pcieport :00:01.0: PME: Spurious native interrupt! > > dmesg.3_usb_key_yanked.txt https://pastebin.com/m7QLnCZt > I yanked the USB key during boot, that seemed to help unlock things with > 5.7, but did not with 5.8. It's hung on a loop of: > [ 11.262854] nvidia-gpu :01:00.3: saving config space at offset 0x0 > (reading 0x1ad910de) > [ 11.262863] nvidia-gpu :01:00.3: saving config space at offset 0x4 > (reading 0x100406) > [ 11.262869] nvidia-gpu :01:00.3: saving config space at offset 0x8 > (reading 0xc8000a1) > [ 11.262874] nvidia-gpu :01:00.3: saving config space at offset 0xc > (reading 0x80) > [ 11.262880] nvidia-gpu :01:00.3: saving config space at offset 0x10 > (reading 0xce054000) > [ 11.262885] nvidia-gpu :01:00.3: saving config space at offset 0x14 > (reading 0x0) > [ 11.262890] nvidia-gpu :01:00.3: saving config space at offset 0x18 > (reading 0x0) > [ 11.262895] nvidia-gpu :01:00.3: saving config space at offset 0x1c > (reading 0x0) > [ 11.262900] nvidia-gpu :01:00.3: saving config space at offset 0x20 > (reading 0x0) > [ 11.262906] nvidia-gpu :01:00.3: saving config space at offset 0x24 > (reading 0x0) > [ 11.262911] nvidia-gpu :01:00.3: saving config space at offset 0x28 > (reading 0x0) > [ 11.262916] nvidia-gpu :01:00.3: saving config space at offset 0x2c > (reading 0x229b17aa) > [ 11.262921] nvidia-gpu :01:00.3: saving config space at offset 0x30 > (reading 0x0) > [ 11.262926] nvidia-gpu :01:00.3: saving config space at offset 0x34 > (reading 0x68) > [ 11.262931] nvidia-gpu :01:00.3: saving config space at offset 0x38 > (reading 0x0) > [ 11.262937] nvidia-gpu :01:00.3: saving config space at offset 0x3c > (reading 0x4ff) > [ 11.262985] nvidia-gpu :01:00.3: PME# enabled > [ 11.303060] nvidia-gpu :01:00.3: PME# disabled > mhh, interesting. I heard some random comments that the Nvidia USB-C/UCSI driver is a bit broken and can cause various issues. Mind blacklisting i2c-nvidia-gpu and typec_nvidia (and verify they don't get loaded) and see if that helps? > dmesg.4_5.5_boot_fine.txt https://pastebin.com/WXgQTUYP > reference boot with 4.5, it works fine, no issues > > dmesg.5_no_key_still_hang.txt https://pastebin.com/kcT8Ras0 > unfortunately, booting without the USB-C key in thunderbolt, did not > allow this boot to be faster, it looks different though: > [6.723454] pcieport :00:01.0: runtime IRQ mapping not provided by arch > [6.723598] pcieport :00:01.0: PME: Signaling with IRQ 122 > [6.724011] pcieport :00:01.0: saving config space at offset 0x0 > (reading 0x19018086) > [6.724016]
RE: [PATCH] PCI: hv: Fix hibernation in case interrupts are not re-created
> -Original Message-
> From: Dexuan Cui
> Sent: Friday, September 4, 2020 7:55 PM
> To: wei@kernel.org; KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger ;
> lorenzo.pieral...@arm.com; bhelg...@google.com; linux-hyp...@vger.kernel.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Michael Kelley
>
> Cc: Dexuan Cui ; Jake Oshins
> Subject: [PATCH] PCI: hv: Fix hibernation in case interrupts are not
> re-created
>
> Hyper-V doesn't trap and emulate the accesses to the MSI/MSI-X registers, and
> we
> must use hv_compose_msi_msg() to ask Hyper-V to create the IOMMU Interrupt
> Remapping Table Entries. This is not an issue for a lot of PCI device drivers
> (e.g.
> NVMe driver, Mellanox NIC drivers), which destroy and re-create the interrupts
> across hibernation, so
> hv_compose_msi_msg() is called automatically. However, some other PCI device
> drivers (e.g. the Nvidia driver) may not destroy and re-create the interrupts
> across
> hibernation, so hv_pci_resume() has to call hv_compose_msi_msg(), otherwise
> the
> PCI device drivers can no longer receive MSI/MSI-X interrupts after
> hibernation.
>
> Fixes: ac82fc832708 ("PCI: hv: Add hibernation support")
> Cc: Jake Oshins
> Signed-off-by: Dexuan Cui
> ---
> drivers/pci/controller/pci-hyperv.c | 44 +
> 1 file changed, 44 insertions(+)
>
> diff --git a/drivers/pci/controller/pci-hyperv.c
> b/drivers/pci/controller/pci-hyperv.c
> index fc4c3a15e570..abefff9a20e1 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -1211,6 +1211,21 @@ static void hv_irq_unmask(struct irq_data *data)
> pbus = pdev->bus;
> hbus = container_of(pbus->sysdata, struct hv_pcibus_device, sysdata);
>
> + if (hbus->state == hv_pcibus_removing) {
> + /*
> + * During hibernatin, when a CPU is offlined, the kernel tries
> + * to move the interrupt to the remaining CPUs that haven't
> + * been offlined yet. In this case, the below hv_do_hypercall()
> + * always fails since the vmbus channel has been closed, so we
> + * should not call the hypercall, but we still need
> + * pci_msi_unmask_irq() to reset the mask bit in desc->masked:
> + * see cpu_disable_common() -> fixup_irqs() ->
> + * irq_migrate_all_off_this_cpu() -> migrate_one_irq().
> + */
> + pci_msi_unmask_irq(data);
> + return;
> + }
> +
> spin_lock_irqsave(&hbus->retarget_msi_interrupt_lock, flags);
>
> params = &hbus->retarget_msi_interrupt_params;
> @@ -3372,6 +3387,33 @@ static int hv_pci_suspend(struct hv_device *hdev)
> return 0;
> }
>
> +static int hv_pci_restore_msi_msg(struct pci_dev *pdev, void *arg) {
> + struct msi_desc *entry;
> + struct irq_data *irq_data;
> +
> + for_each_pci_msi_entry(entry, pdev) {
> + irq_data = irq_get_irq_data(entry->irq);
> + if (WARN_ON_ONCE(!irq_data))
> + return -EINVAL;
> +
> + hv_compose_msi_msg(irq_data, &entry->msg);
> + }
> +
> + return 0;
> +}
> +
> +/*
> + * Upon resume, pci_restore_msi_state() -> ... ->
> +__pci_write_msi_msg()
> + * re-writes the MSI/MSI-X registers, but since Hyper-V doesn't trap
> +and
> + * emulate the accesses, we have to call hv_compose_msi_msg() to ask
> + * Hyper-V to re-create the IOMMU Interrupt Remapping Table Entries.
> + */
> +static void hv_pci_restore_msi_state(struct hv_pcibus_device *hbus) {
> + pci_walk_bus(hbus->pci_bus, hv_pci_restore_msi_msg, NULL); }
> +
> static int hv_pci_resume(struct hv_device *hdev) {
> struct hv_pcibus_device *hbus = hv_get_drvdata(hdev); @@ -3405,6
> +3447,8 @@ static int hv_pci_resume(struct hv_device *hdev)
>
> prepopulate_bars(hbus);
>
> + hv_pci_restore_msi_state(hbus);
> +
> hbus->state = hv_pcibus_installed;
> return 0;
> out:
> --
> 2.19.1
Reviewed-by: Jake Oshins (ja...@microsoft.com)
Re: [PATCH v16 00/20] iommu/arm-smmu + drm/msm: per-process GPU pgtables
On 2020-09-01 17:46, Rob Clark wrote: > From: Rob Clark > > NOTE: I have re-ordered the series, and propose that we could merge this >series in the following order: > > 1) 01-11 - merge via drm / msm-next > 2) 12-15 - merge via iommu, no dependency on msm-next pull req > 3) 16-18 - patch 16 has a dependency on 02 and 04, so it would >need to come post -rc1 or on following cycle, but I >think it would be unlikely to conflict with other >arm-smmu patches (other than Bjorn's smmu handover >series?) > 4) 19-20 - dt bits should be safe to land in any order without >breaking anything > > > > This series adds an Adreno SMMU implementation to arm-smmu to allow GPU > hardware > pagetable switching. > > The Adreno GPU has built in capabilities to switch the TTBR0 pagetable during > runtime to allow each individual instance or application to have its own > pagetable. In order to take advantage of the HW capabilities there are > certain > requirements needed of the SMMU hardware. > > This series adds support for an Adreno specific arm-smmu implementation. The > new > implementation 1) ensures that the GPU domain is always assigned context bank > 0, > 2) enables split pagetable support (TTBR1) so that the instance specific > pagetable can be swapped while the global memory remains in place and 3) > shares > the current pagetable configuration with the GPU driver to allow it to create > its own io-pgtable instances. > > The series then adds the drm/msm code to enable these features. For targets > that > support it allocate new pagetables using the io-pgtable configuration shared > by > the arm-smmu driver and swap them in during runtime. > > This version of the series merges the previous patchset(s) [1] and [2] > with the following improvements: > > v16: (Respin by Rob) >- Fix indentation >- Re-order series to split drm and iommu parts > v15: (Respin by Rob) >- Adjust dt bindings to keep SoC specific compatible (Doug) >- Add dts workaround for cheza fw limitation >- Add missing 'select IOMMU_IO_PGTABLE' (Guenter) > v14: (Respin by Rob) >- Minor update to 16/20 (only force ASID to zero in one place) >- Addition of sc7180 dtsi patch. > v13: (Respin by Rob) >- Switch to a private interface between adreno-smmu and GPU driver, > dropping the custom domain attr (Will Deacon) >- Rework the SCTLR.HUPCF patch to add new fields in smmu_domain->cfg > rather than adding new impl hook (Will Deacon) >- Drop for_each_cfg_sme() in favor of plain for() loop (Will Deacon) >- Fix context refcnt'ing issue which was causing problems with GPU > crash recover stress testing. >- Spiff up $debugfs/gem to show process information associated with > VMAs > v12: >- Nitpick cleanups in gpu/drm/msm/msm_iommu.c (Rob Clark) >- Reorg in gpu/drm/msm/msm_gpu.c (Rob Clark) >- Use the default asid for the context bank so that iommu_tlb_flush_all > works >- Flush the UCHE after a page switch >- Add the SCTLR.HUPCF patch at the end of the series > v11: >- Add implementation specific get_attr/set_attr functions (per Rob Clark) >- Fix context bank allocation (per Bjorn Andersson) > v10: >- arm-smmu: add implementation hook to allocate context banks >- arm-smmu: Match the GPU domain by stream ID instead of compatible string >- arm-smmu: Make DOMAIN_ATTR_PGTABLE_CFG bi-directional. The leaf driver > queries the configuration to create a pagetable and then sends the newly > created configuration back to the smmu-driver to enable TTBR0 >- drm/msm: Add context reference counting for submissions >- drm/msm: Use dummy functions to skip TLB operations on per-instance > pagetables > > [1] https://lists.linuxfoundation.org/pipermail/iommu/2020-June/045653.html > [2] https://lists.linuxfoundation.org/pipermail/iommu/2020-June/045659.html > > Jordan Crouse (12): >drm/msm: Add a context pointer to the submitqueue >drm/msm: Drop context arg to gpu->submit() >drm/msm: Set the global virtual address range from the IOMMU domain >drm/msm: Add support to create a local pagetable >drm/msm: Add support for private address space instances >drm/msm/a6xx: Add support for per-instance pagetables >iommu/arm-smmu: Pass io-pgtable config to implementation specific > function >iommu/arm-smmu: Add support for split pagetables >iommu/arm-smmu: Prepare for the adreno-smmu implementation >iommu/arm-smmu-qcom: Add implementation for the adreno GPU SMMU >dt-bindings: arm-smmu: Add compatible string for Adreno GPU SMMU >arm: dts: qcom: sm845: Set the compatible string for the GPU SMMU > > Rob Clark (8): >drm/msm: Remove dangling submitqueue references >drm/msm: Add private interface for adreno-smmu >drm/msm/gpu: Add dev_to_gpu() helper >drm/msm: Se
Re: [PATCH 3/8] asm-generic: fix unaligned access hamdling in raw_copy_{from, to}_user
> Re: [PATCH 3/8] asm-generic: fix unaligned access hamdling in raw_copy_{from,
> to}_user
nit: handling
--Sean
[PATCH 09/12] x86/platform/uv: Update UV5 MMR references in UV GRU
Make modifications to the GRU mappings to accommodate changes for UV5.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
arch/x86/kernel/apic/x2apic_uv_x.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -83,6 +83,9 @@ static unsigned long __init uv_early_rea
static inline bool is_GRU_range(u64 start, u64 end)
{
+ if (!gru_start_paddr)
+ return false;
+
return start >= gru_start_paddr && end <= gru_end_paddr;
}
@@ -914,13 +917,24 @@ static __init void map_high(char *id, un
static __init void map_gru_high(int max_pnode)
{
union uvh_rh_gam_gru_overlay_config_u gru;
- int shift = UVH_RH_GAM_GRU_OVERLAY_CONFIG_BASE_SHFT;
- unsigned long mask = UVH_RH_GAM_GRU_OVERLAY_CONFIG_BASE_MASK;
- unsigned long base;
+ unsigned long mask, base;
+ int shift;
+
+ if (UVH_RH_GAM_GRU_OVERLAY_CONFIG) {
+ gru.v = uv_read_local_mmr(UVH_RH_GAM_GRU_OVERLAY_CONFIG);
+ shift = UVH_RH_GAM_GRU_OVERLAY_CONFIG_BASE_SHFT;
+ mask = UVH_RH_GAM_GRU_OVERLAY_CONFIG_BASE_MASK;
+ } else if (UVH_RH10_GAM_GRU_OVERLAY_CONFIG) {
+ gru.v = uv_read_local_mmr(UVH_RH10_GAM_GRU_OVERLAY_CONFIG);
+ shift = UVH_RH10_GAM_GRU_OVERLAY_CONFIG_BASE_SHFT;
+ mask = UVH_RH10_GAM_GRU_OVERLAY_CONFIG_BASE_MASK;
+ } else {
+ pr_err("UV: GRU unavailable (no MMR)\n");
+ return;
+ }
- gru.v = uv_read_local_mmr(UVH_RH_GAM_GRU_OVERLAY_CONFIG);
if (!gru.s.enable) {
- pr_info("UV: GRU disabled\n");
+ pr_info("UV: GRU disabled (by BIOS)\n");
return;
}
@@ -1289,7 +1303,11 @@ static void __init uv_init_hub_info(stru
/* Show system specific info: */
pr_info("UV: N:%d M:%d m_shift:%d n_lshift:%d\n", hi->n_val, hi->m_val,
hi->m_shift, hi->n_lshift);
pr_info("UV: gpa_mask/shift:0x%lx/%d pnode_mask:0x%x apic_pns:%d\n",
hi->gpa_mask, hi->gpa_shift, hi->pnode_mask, hi->apic_pnode_shift);
- pr_info("UV: mmr_base/shift:0x%lx/%ld gru_base/shift:0x%lx/%ld\n",
hi->global_mmr_base, hi->global_mmr_shift, hi->global_gru_base,
hi->global_gru_shift);
+ pr_info("UV: mmr_base/shift:0x%lx/%ld\n", hi->global_mmr_base,
hi->global_mmr_shift);
+ if (hi->global_gru_base)
+ pr_info("UV: gru_base/shift:0x%lx/%ld\n",
+ hi->global_gru_base, hi->global_gru_shift);
+
pr_info("UV: gnode_upper:0x%lx gnode_extra:0x%x\n", hi->gnode_upper,
hi->gnode_extra);
}
[PATCH 00/12] x86/platform/uv: Updates for UV5
Subject: [PATCH 00/12] x86/platform/uv: Updates for UV5 Add changes needed for new UV5 UV architecture. Chief among the changes are 52 bits of physical memory address and 57 bits of virtual address space. 0001 Remove UV BAU TLB Shootdown Handler - removes BAU TLB code being replaced by BAU APIC driver 0002 Remove SCIR built in driver - removes System Controller (monitoring) code 0003 Update UV kernel modules - update loadable UV kernel modules prior to a clash of symbols (is_uv) produced by auto-generated UV5 uv_mmrs.h file 0004 Update UV MMRs for UV5 - update uv_mmrs.h file and fix resultant compiler errors 0005 Add UV5 direct references - add references to UV5 specific values 0006 Decode and Use Arch Type in UVsystab - add UV ArchType field to UVsystab to remove dependency on OEM_ID 0007 Update MMIOH references - display MMIOH mapping for each MMIOH region 0008 Adjust GAM MMR references - update GAM mapping for MMR accesses 0009 Update UV GRU references - update GRU mapping to include UV5 0010 Update Node Present Counting - UV5 changes method of counting nodes present 0011 Update UV5 TSC Checking - update TSC sync check of BIOS sync status 0012 Update for UV5 NMI MMR changes - update NMI handler
[PATCH 03/12] x86/platform/uv: Adjust references in UV kernel modules
There is a symbol clash from the auto-generated uv_mmrs.h file that
clashes with code in the UV kernel modules (is_uv() is the symbol).
Change those prior to the symbol clash so as to not cause a compile error.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
drivers/misc/sgi-xp/xp.h| 11 ++-
drivers/misc/sgi-xp/xp_main.c |7 ---
drivers/misc/sgi-xp/xp_uv.c |9 ++---
drivers/misc/sgi-xp/xpc_main.c |9 +
drivers/misc/sgi-xp/xpc_partition.c |5 +++--
drivers/misc/sgi-xp/xpnet.c |5 +++--
6 files changed, 27 insertions(+), 19 deletions(-)
--- linux.orig/drivers/misc/sgi-xp/xp.h
+++ linux/drivers/misc/sgi-xp/xp.h
@@ -3,7 +3,8 @@
* License. See the file "COPYING" in the main directory of this archive
* for more details.
*
- * Copyright (C) 2004-2008 Silicon Graphics, Inc. All rights reserved.
+ * Copyright (c) 2018-2020 Hewlett Packard Enterprise Development LP
+ * Copyright (c) 2008-2017 Silicon Graphics, Inc. All Rights Reserved.
*/
/*
@@ -17,11 +18,11 @@
#if defined CONFIG_X86_UV || defined CONFIG_IA64_SGI_UV
#include
-#define is_uv()is_uv_system()
+#define is_uv_sys()is_uv_system()
#endif
-#ifndef is_uv
-#define is_uv()0
+#ifndef is_uv_sys
+#define is_uv_sys()0
#endif
#ifdef USE_DBUG_ON
@@ -79,7 +80,7 @@
#define XPC_MSG_SIZE(_payload_size) \
ALIGN(XPC_MSG_HDR_MAX_SIZE + (_payload_size), \
- is_uv() ? 64 : 128)
+ is_uv_sys() ? 64 : 128)
/*
--- linux.orig/drivers/misc/sgi-xp/xp_main.c
+++ linux/drivers/misc/sgi-xp/xp_main.c
@@ -3,7 +3,8 @@
* License. See the file "COPYING" in the main directory of this archive
* for more details.
*
- * Copyright (c) 2004-2008 Silicon Graphics, Inc. All Rights Reserved.
+ * Copyright (c) 2018-2020 Hewlett Packard Enterprise Development LP
+ * Copyright (c) 2008-2017 Silicon Graphics, Inc. All Rights Reserved.
*/
/*
@@ -233,7 +234,7 @@ xp_init(void)
for (ch_number = 0; ch_number < XPC_MAX_NCHANNELS; ch_number++)
mutex_init(&xpc_registrations[ch_number].mutex);
- if (is_uv())
+ if (is_uv_sys())
ret = xp_init_uv();
else
ret = 0;
@@ -249,7 +250,7 @@ module_init(xp_init);
void __exit
xp_exit(void)
{
- if (is_uv())
+ if (is_uv_sys())
xp_exit_uv();
}
--- linux.orig/drivers/misc/sgi-xp/xp_uv.c
+++ linux/drivers/misc/sgi-xp/xp_uv.c
@@ -3,7 +3,8 @@
* License. See the file "COPYING" in the main directory of this archive
* for more details.
*
- * Copyright (c) 2008 Silicon Graphics, Inc. All Rights Reserved.
+ * Copyright (c) 2018-2020 Hewlett Packard Enterprise Development LP
+ * Copyright (c) 2008-2017 Silicon Graphics, Inc. All Rights Reserved.
*/
/*
@@ -148,7 +149,9 @@ xp_restrict_memprotect_uv(unsigned long
enum xp_retval
xp_init_uv(void)
{
- BUG_ON(!is_uv());
+ WARN_ON(!is_uv_sys());
+ if (!is_uv_sys())
+ return xpUnsupported;
xp_max_npartitions = XP_MAX_NPARTITIONS_UV;
#ifdef CONFIG_X86
@@ -168,5 +171,5 @@ xp_init_uv(void)
void
xp_exit_uv(void)
{
- BUG_ON(!is_uv());
+ WARN_ON(!is_uv_sys());
}
--- linux.orig/drivers/misc/sgi-xp/xpc_main.c
+++ linux/drivers/misc/sgi-xp/xpc_main.c
@@ -3,7 +3,8 @@
* License. See the file "COPYING" in the main directory of this archive
* for more details.
*
- * Copyright (c) 2004-2009 Silicon Graphics, Inc. All Rights Reserved.
+ * Copyright (c) 2018-2020 Hewlett Packard Enterprise Development LP
+ * Copyright (c) 2008-2017 Silicon Graphics, Inc. All Rights Reserved.
*/
/*
@@ -1043,7 +1044,7 @@ xpc_do_exit(enum xp_retval reason)
xpc_teardown_partitions();
- if (is_uv())
+ if (is_uv_sys())
xpc_exit_uv();
}
@@ -1226,7 +1227,7 @@ xpc_init(void)
dev_set_name(xpc_part, "part");
dev_set_name(xpc_chan, "chan");
- if (is_uv()) {
+ if (is_uv_sys()) {
ret = xpc_init_uv();
} else {
@@ -1312,7 +1313,7 @@ out_2:
xpc_teardown_partitions();
out_1:
- if (is_uv())
+ if (is_uv_sys())
xpc_exit_uv();
return ret;
}
--- linux.orig/drivers/misc/sgi-xp/xpc_partition.c
+++ linux/drivers/misc/sgi-xp/xpc_partition.c
@@ -3,7 +3,8 @@
* License. See the file "COPYING" in the main directory of this archive
* for more details.
*
- * Copyright (c) 2004-2008 Silicon Graphics, Inc. All Rights Reserved.
+ * Copyright (c) 2018-2020 Hewlett Packard Enterprise Development LP
+ * Copyright (c) 2008-2017 Silicon Graphics, Inc. All Rights Reserved.
*/
/*
@@ -433,7 +434,7 @@ xpc_discovery(void)
*/
region_size = xp_region_size;
- if (is_uv())
+ if (is_uv_sys())
max_r
[PATCH 07/12] x86/platform/uv: Update MMIOH references based on new UV5 MMRs.
Make modifications to the MMIOH mappings to accommodate changes for UV5.
Signed-off-by: Mike Travis
Reviewed-by: Steve Wahl
---
arch/x86/kernel/apic/x2apic_uv_x.c | 213 +
1 file changed, 144 insertions(+), 69 deletions(-)
--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -229,6 +229,13 @@ static void __init uv_tsc_check_sync(voi
mark_tsc_unstable("UV BIOS");
}
+/* Selector for (4|4A|5) structs */
+#define uvxy_field(sname, field, undef) ( \
+ is_uv(UV4A) ? sname.s4a.field : \
+ is_uv(UV4) ? sname.s4.field : \
+ is_uv(UV3) ? sname.s3.field : \
+ undef)
+
/* [Copied from arch/x86/kernel/cpu/topology.c:detect_extended_topology()] */
#define SMT_LEVEL 0 /* Leaf 0xb SMT level */
@@ -883,6 +890,7 @@ static __init void get_lowmem_redirect(u
}
enum map_type {map_wb, map_uc};
+static const char * const mt[] = { "WB", "UC" };
static __init void map_high(char *id, unsigned long base, int pshift, int
bshift, int max_pnode, enum map_type map_type)
{
@@ -894,11 +902,13 @@ static __init void map_high(char *id, un
pr_info("UV: Map %s_HI base address NULL\n", id);
return;
}
- pr_debug("UV: Map %s_HI 0x%lx - 0x%lx\n", id, paddr, paddr + bytes);
if (map_type == map_uc)
init_extra_mapping_uc(paddr, bytes);
else
init_extra_mapping_wb(paddr, bytes);
+
+ pr_info("UV: Map %s_HI 0x%lx - 0x%lx %s (%d segments)\n",
+ id, paddr, paddr + bytes, mt[map_type], max_pnode + 1);
}
static __init void map_gru_high(int max_pnode)
@@ -932,52 +942,73 @@ static __init void map_mmr_high(int max_
pr_info("UV: MMR disabled\n");
}
-/* UV3/4 have identical MMIOH overlay configs, UV4A is slightly different */
-static __init void map_mmioh_high_uv34(int index, int min_pnode, int max_pnode)
-{
- unsigned long overlay;
- unsigned long mmr;
- unsigned long base;
- unsigned long nasid_mask;
- unsigned long m_overlay;
- int i, n, shift, m_io, max_io;
- int nasid, lnasid, fi, li;
- char *id;
-
- if (index == 0) {
- id = "MMIOH0";
- m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0;
- overlay = uv_read_local_mmr(m_overlay);
- base = overlay & UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_BASE_MASK;
+/* Arch specific ENUM cases */
+enum mmioh_arch {
+ UV2_MMIOH = -1,
+ UVY_MMIOH0, UVY_MMIOH1,
+ UVX_MMIOH0, UVX_MMIOH1,
+};
+
+/* Calculate and Map MMIOH Regions */
+void __init calc_mmioh_map(enum mmioh_arch index, int min_pnode, int max_pnode,
+ int shift, unsigned long base, int m_io, int n_io)
+{
+ unsigned long mmr, nasid_mask;
+ int nasid, min_nasid, max_nasid, lnasid, mapped;
+ int i, fi, li, n, max_io;
+ char id[8];
+
+ /* One (UV2) mapping */
+ if (index == UV2_MMIOH) {
+ strncpy(id, "MMIOH", sizeof(id));
+ max_io = max_pnode;
+ mapped = 0;
+ goto map_exit;
+ }
+
+ /* small and large MMIOH mappings */
+ switch (index) {
+ case UVY_MMIOH0:
+ mmr = UVH_RH10_GAM_MMIOH_REDIRECT_CONFIG0;
+ nasid_mask = UVH_RH10_GAM_MMIOH_OVERLAY_CONFIG0_BASE_MASK;
+ n = UVH_RH10_GAM_MMIOH_REDIRECT_CONFIG0_DEPTH;
+ min_nasid = min_pnode;
+ max_nasid = max_pnode;
+ mapped = 1;
+ break;
+ case UVY_MMIOH1:
+ mmr = UVH_RH10_GAM_MMIOH_REDIRECT_CONFIG1;
+ nasid_mask = UVH_RH10_GAM_MMIOH_OVERLAY_CONFIG1_BASE_MASK;
+ n = UVH_RH10_GAM_MMIOH_REDIRECT_CONFIG1_DEPTH;
+ min_nasid = min_pnode;
+ max_nasid = max_pnode;
+ mapped = 1;
+ break;
+ case UVX_MMIOH0:
mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0;
- m_io = (overlay & UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_M_IO_MASK)
- >> UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_M_IO_SHFT;
- shift = UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_M_IO_SHFT;
+ nasid_mask = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_BASE_MASK;
n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_DEPTH;
- nasid_mask = UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG0_NASID_MASK;
- } else {
- id = "MMIOH1";
- m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1;
- overlay = uv_read_local_mmr(m_overlay);
- base = overlay & UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_BASE_MASK;
+ min_nasid = min_pnode * 2;
+ max_nasid = max_pnode * 2;
+ mapped = 1;
+ break;
+ case UVX_MMIOH1:
mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1;
- m_io = (overlay
[PATCH 02/12] x86/platform/uv: Remove SCIR MMR references for UVY systems.
UV class systems no longer use System Controller for monitoring of CPU
activity provided by this driver. Other methods have been developed
for BIOS and the management controller (BMC). This patch removes that
supporting code.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
---
arch/x86/include/asm/uv/uv_hub.h | 46 ++--
arch/x86/kernel/apic/x2apic_uv_x.c | 85 -
2 files changed, 7 insertions(+), 124 deletions(-)
--- linux.orig/arch/x86/include/asm/uv/uv_hub.h
+++ linux/arch/x86/include/asm/uv/uv_hub.h
@@ -5,7 +5,8 @@
*
* SGI UV architectural definitions
*
- * Copyright (C) 2007-2014 Silicon Graphics, Inc. All rights reserved.
+ * Copyright (C) 2018-2020 Hewlett Packard Enterprise Development LP
+ * Copyright (C) 2007-2017 Silicon Graphics, Inc. All rights reserved.
*/
#ifndef _ASM_X86_UV_UV_HUB_H
@@ -129,17 +130,6 @@
*/
#define UV_MAX_NASID_VALUE (UV_MAX_NUMALINK_BLADES * 2)
-/* System Controller Interface Reg info */
-struct uv_scir_s {
- struct timer_list timer;
- unsigned long offset;
- unsigned long last;
- unsigned long idle_on;
- unsigned long idle_off;
- unsigned char state;
- unsigned char enabled;
-};
-
/* GAM (globally addressed memory) range table */
struct uv_gam_range_s {
u32 limit; /* PA bits 56:26 (GAM_RANGE_SHFT) */
@@ -191,16 +181,13 @@ struct uv_hub_info_s {
struct uv_cpu_info_s {
void*p_uv_hub_info;
unsigned char blade_cpu_id;
- struct uv_scir_sscir;
+ void*reserved;
};
DECLARE_PER_CPU(struct uv_cpu_info_s, __uv_cpu_info);
#define uv_cpu_infothis_cpu_ptr(&__uv_cpu_info)
#define uv_cpu_info_per(cpu) (&per_cpu(__uv_cpu_info, cpu))
-#defineuv_scir_info(&uv_cpu_info->scir)
-#defineuv_cpu_scir_info(cpu) (&uv_cpu_info_per(cpu)->scir)
-
/* Node specific hub common info struct */
extern void **__uv_hub_info_list;
static inline struct uv_hub_info_s *uv_hub_info_list(int node)
@@ -297,9 +284,9 @@ union uvh_apicid {
#define UV3_GLOBAL_MMR32_SIZE (32UL * 1024 * 1024)
#define UV4_LOCAL_MMR_BASE 0xfa00UL
-#define UV4_GLOBAL_MMR32_BASE 0xfc00UL
+#define UV4_GLOBAL_MMR32_BASE 0
#define UV4_LOCAL_MMR_SIZE (32UL * 1024 * 1024)
-#define UV4_GLOBAL_MMR32_SIZE (16UL * 1024 * 1024)
+#define UV4_GLOBAL_MMR32_SIZE 0
#define UV_LOCAL_MMR_BASE ( \
is_uv2_hub() ? UV2_LOCAL_MMR_BASE : \
@@ -772,29 +759,6 @@ DECLARE_PER_CPU(struct uv_cpu_nmi_s, uv_
#defineUV_NMI_STATE_DUMP 2
#defineUV_NMI_STATE_DUMP_DONE 3
-/* Update SCIR state */
-static inline void uv_set_scir_bits(unsigned char value)
-{
- if (uv_scir_info->state != value) {
- uv_scir_info->state = value;
- uv_write_local_mmr8(uv_scir_info->offset, value);
- }
-}
-
-static inline unsigned long uv_scir_offset(int apicid)
-{
- return SCIR_LOCAL_MMR_BASE | (apicid & 0x3f);
-}
-
-static inline void uv_set_cpu_scir_bits(int cpu, unsigned char value)
-{
- if (uv_cpu_scir_info(cpu)->state != value) {
- uv_write_global_mmr8(uv_cpu_to_pnode(cpu),
- uv_cpu_scir_info(cpu)->offset, value);
- uv_cpu_scir_info(cpu)->state = value;
- }
-}
-
/*
* Get the minimum revision number of the hub chips within the partition.
* (See UVx_HUB_REVISION_BASE above for specific values.)
--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -5,7 +5,8 @@
*
* SGI UV APIC functions (note: not an Intel compatible APIC)
*
- * Copyright (C) 2007-2014 Silicon Graphics, Inc. All rights reserved.
+ * Copyright (C) 2018-2020 Hewlett Packard Enterprise Development LP
+ * Copyright (C) 2007-2017 Silicon Graphics, Inc. All rights reserved.
*/
#include
#include
@@ -909,85 +910,6 @@ static __init void uv_rtc_init(void)
}
}
-/*
- * percpu heartbeat timer
- */
-static void uv_heartbeat(struct timer_list *timer)
-{
- unsigned char bits = uv_scir_info->state;
-
- /* Flip heartbeat bit: */
- bits ^= SCIR_CPU_HEARTBEAT;
-
- /* Is this CPU idle? */
- if (idle_cpu(raw_smp_processor_id()))
- bits &= ~SCIR_CPU_ACTIVITY;
- else
- bits |= SCIR_CPU_ACTIVITY;
-
- /* Update system controller interface reg: */
- uv_set_scir_bits(bits);
-
- /* Enable next timer period: */
- mod_timer(timer, jiffies + SCIR_CPU_HB_INTERVAL);
-}
-
-static int uv_heartbeat_enable(unsigned int cpu)
-{
- while (!uv_cpu_scir_info(cpu)->enabled) {
- struct timer_list *timer = &uv_cpu_scir_info(cpu)->timer;
-
- uv_set_cpu_scir_bits(c
[PATCH 06/12] x86/platform/uv: Add and Decode Arch Type in UVsystab
A patch to add and process the UV Arch Type field in the UVsystab passed
from UV BIOS to the kernel. This allows the system to be recognized
without relying on the OEM_ID which OEMs want to change.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
arch/x86/include/asm/uv/bios.h | 17 +++-
arch/x86/kernel/apic/x2apic_uv_x.c | 135 +++--
arch/x86/platform/uv/bios_uv.c | 28 +--
3 files changed, 150 insertions(+), 30 deletions(-)
--- linux.orig/arch/x86/include/asm/uv/bios.h
+++ linux/arch/x86/include/asm/uv/bios.h
@@ -5,8 +5,9 @@
/*
* UV BIOS layer definitions.
*
- * Copyright (c) 2008-2009 Silicon Graphics, Inc. All Rights Reserved.
- * Copyright (c) Russ Anderson
+ * Copyright (C) 2018-2020 Hewlett Packard Enterprise Development LP
+ * Copyright (C) 2007-2017 Silicon Graphics, Inc. All rights reserved.
+ * Copyright (c) Russ Anderson
*/
#include
@@ -71,6 +72,11 @@ struct uv_gam_range_entry {
u32 limit; /* PA bits 56:26 (UV_GAM_RANGE_SHFT) */
};
+#defineUV_AT_SIZE 8 /* 7 character arch type + NULL char */
+struct uv_arch_type_entry {
+ chararchtype[UV_AT_SIZE];
+};
+
#defineUV_SYSTAB_SIG "UVST"
#defineUV_SYSTAB_VERSION_1 1 /* UV2/3 BIOS version */
#defineUV_SYSTAB_VERSION_UV4 0x400 /* UV4 BIOS base
version */
@@ -79,10 +85,14 @@ struct uv_gam_range_entry {
#defineUV_SYSTAB_VERSION_UV4_3 0x403 /* - GAM Range PXM
Value */
#defineUV_SYSTAB_VERSION_UV4_LATESTUV_SYSTAB_VERSION_UV4_3
+#defineUV_SYSTAB_VERSION_UV5 0x500 /* UV5 GAM base version
*/
+#defineUV_SYSTAB_VERSION_UV5_LATESTUV_SYSTAB_VERSION_UV5
+
#defineUV_SYSTAB_TYPE_UNUSED 0 /* End of table (offset
== 0) */
#defineUV_SYSTAB_TYPE_GAM_PARAMS 1 /* GAM PARAM
conversions */
#defineUV_SYSTAB_TYPE_GAM_RNG_TBL 2 /* GAM entry table */
-#defineUV_SYSTAB_TYPE_MAX 3
+#defineUV_SYSTAB_TYPE_ARCH_TYPE3 /* UV arch type */
+#defineUV_SYSTAB_TYPE_MAX 4
/*
* The UV system table describes specific firmware
@@ -133,6 +143,7 @@ extern s64 uv_bios_reserved_page_pa(u64,
extern int uv_bios_set_legacy_vga_target(bool decode, int domain, int bus);
extern int uv_bios_init(void);
+extern unsigned long get_uv_systab_phys(bool msg);
extern unsigned long sn_rtc_cycles_per_second;
extern int uv_type;
--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -32,7 +32,8 @@ static u64gru_start_paddr, gru_end_pa
static union uvh_apiciduvh_apicid;
static int uv_node_id;
-/* Unpack OEM/TABLE ID's to be NULL terminated strings */
+/* Unpack AT/OEM/TABLE ID's to be NULL terminated strings */
+static u8 uv_archtype[UV_AT_SIZE];
static u8 oem_id[ACPI_OEM_ID_SIZE + 1];
static u8 oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
@@ -287,20 +288,104 @@ static void __init uv_stringify(int len,
strncpy(to, from, len-1);
}
+/* Find UV arch type entry in UVsystab */
+static unsigned long __init early_find_archtype(struct uv_systab *st)
+{
+ int i;
+
+ for (i = 0; st->entry[i].type != UV_SYSTAB_TYPE_UNUSED; i++) {
+ unsigned long ptr = st->entry[i].offset;
+
+ if (!ptr)
+ continue;
+ ptr += (unsigned long)st;
+ if (st->entry[i].type == UV_SYSTAB_TYPE_ARCH_TYPE)
+ return ptr;
+ }
+ return 0;
+}
+
+/* Validate UV arch type field in UVsystab */
+static int __init decode_arch_type(unsigned long ptr)
+{
+ struct uv_arch_type_entry *uv_ate = (struct uv_arch_type_entry *)ptr;
+ int n = strlen(uv_ate->archtype);
+
+ if (n > 0 && n < sizeof(uv_ate->archtype)) {
+ pr_info("UV: UVarchtype received from BIOS\n");
+ uv_stringify(UV_AT_SIZE, uv_archtype, uv_ate->archtype);
+ return 1;
+ }
+ return 0;
+}
+
+/* Determine if UV arch type entry might exist in UVsystab */
+static int __init early_get_arch_type(void)
+{
+ unsigned long uvst_physaddr, uvst_size, ptr;
+ struct uv_systab *st;
+ u32 rev;
+ int ret;
+
+ uvst_physaddr = get_uv_systab_phys(0);
+ if (!uvst_physaddr)
+ return 0;
+
+ st = early_memremap_ro(uvst_physaddr, sizeof(struct uv_systab));
+ if (!st) {
+ pr_err("UV: Cannot access UVsystab, remap failed\n");
+ return 0;
+ }
+
+ rev = st->revision;
+ if (rev < UV_SYSTAB_VERSION_UV5) {
+ early_memunmap(st, sizeof(struct uv_systab));
+ return 0;
+ }
+
+ uvst_size = st->size;
+ early_memunmap(st, sizeof(struct uv_systab));
[RESEND PATCH v2] KVM: fix memory leak in kvm_io_bus_unregister_dev()
when kmalloc() fails in kvm_io_bus_unregister_dev(), before removing
the bus, we should iterate over all other devices linked to it and call
kvm_iodevice_destructor() for them
Fixes: 90db10434b16 ("KVM: kvm_io_bus_unregister_dev() should never fail")
Cc: sta...@vger.kernel.org
Reported-and-tested-by: syzbot+f196caa45793d6374...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=f196caa45793d6374707
Signed-off-by: Rustam Kovhaev
Reviewed-by: Vitaly Kuznetsov
---
v2:
- remove redundant whitespace
- remove goto statement and use if/else
- add Fixes tag
---
virt/kvm/kvm_main.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 67cd0b88a6b6..cf88233b819a 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -4332,7 +4332,7 @@ int kvm_io_bus_register_dev(struct kvm *kvm, enum kvm_bus
bus_idx, gpa_t addr,
void kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
struct kvm_io_device *dev)
{
- int i;
+ int i, j;
struct kvm_io_bus *new_bus, *bus;
bus = kvm_get_bus(kvm, bus_idx);
@@ -4349,17 +4349,20 @@ void kvm_io_bus_unregister_dev(struct kvm *kvm, enum
kvm_bus bus_idx,
new_bus = kmalloc(struct_size(bus, range, bus->dev_count - 1),
GFP_KERNEL_ACCOUNT);
- if (!new_bus) {
+ if (new_bus) {
+ memcpy(new_bus, bus, sizeof(*bus) + i * sizeof(struct
kvm_io_range));
+ new_bus->dev_count--;
+ memcpy(new_bus->range + i, bus->range + i + 1,
+ (new_bus->dev_count - i) * sizeof(struct kvm_io_range));
+ } else {
pr_err("kvm: failed to shrink bus, removing it completely\n");
- goto broken;
+ for (j = 0; j < bus->dev_count; j++) {
+ if (j == i)
+ continue;
+ kvm_iodevice_destructor(bus->range[j].dev);
+ }
}
- memcpy(new_bus, bus, sizeof(*bus) + i * sizeof(struct kvm_io_range));
- new_bus->dev_count--;
- memcpy(new_bus->range + i, bus->range + i + 1,
- (new_bus->dev_count - i) * sizeof(struct kvm_io_range));
-
-broken:
rcu_assign_pointer(kvm->buses[bus_idx], new_bus);
synchronize_srcu_expedited(&kvm->srcu);
kfree(bus);
--
2.28.0
[PATCH 05/12] x86/platform/uv: Add UV5 direct references
Add new references to UV5 (and UVY class) system MMR addresses and
fields primarily caused by the expansion from 46 to 52 bits of
physical memory address.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
arch/x86/include/asm/uv/uv_hub.h | 49 --
arch/x86/kernel/apic/x2apic_uv_x.c | 100 ++---
2 files changed, 105 insertions(+), 44 deletions(-)
--- linux.orig/arch/x86/include/asm/uv/uv_hub.h
+++ linux/arch/x86/include/asm/uv/uv_hub.h
@@ -161,6 +161,7 @@ struct uv_hub_info_s {
unsigned char gr_table_len;
unsigned char apic_pnode_shift;
unsigned char gpa_shift;
+ unsigned char nasid_shift;
unsigned char m_shift;
unsigned char n_lshift;
unsigned intgnode_extra;
@@ -227,6 +228,7 @@ static inline __init void uv_hub_type_se
#define UV3_HUB_REVISION_BASE 5
#define UV4_HUB_REVISION_BASE 7
#define UV4A_HUB_REVISION_BASE 8 /* UV4 (fixed) rev 2 */
+#define UV5_HUB_REVISION_BASE 9
static inline int is_uv(int uvmask) { return uv_hub_type() & uvmask; }
static inline int is_uv1_hub(void) { return 0; }
@@ -234,7 +236,7 @@ static inline int is_uv2_hub(void) { ret
static inline int is_uv3_hub(void) { return is_uv(UV3); }
static inline int is_uv4a_hub(void) { return is_uv(UV4A); }
static inline int is_uv4_hub(void) { return is_uv(UV4); }
-static inline int is_uv5_hub(void) { return 0; }
+static inline int is_uv5_hub(void) { return is_uv(UV5); }
/*
* UV4A is a revision of UV4. So on UV4A, both is_uv4_hub() and
@@ -247,7 +249,7 @@ static inline int is_uv5_hub(void) { ret
static inline int is_uvx_hub(void) { return is_uv(UVX); }
/* UVY class: UV5,..? */
-static inline int is_uvy_hub(void) { return 0; }
+static inline int is_uvy_hub(void) { return is_uv(UVY); }
/* Any UV Hubbed System */
static inline int is_uv_hub(void) { return is_uv(UV_ANY); }
@@ -272,9 +274,11 @@ union uvh_apicid {
* g - GNODE (full 15-bit global nasid, right shifted 1)
* p - PNODE (local part of nsids, right shifted 1)
*/
-#define UV_NASID_TO_PNODE(n) (((n) >> 1) & uv_hub_info->pnode_mask)
+#define UV_NASID_TO_PNODE(n) \
+ (((n) >> uv_hub_info->nasid_shift) & uv_hub_info->pnode_mask)
#define UV_PNODE_TO_GNODE(p) ((p) |uv_hub_info->gnode_extra)
-#define UV_PNODE_TO_NASID(p) (UV_PNODE_TO_GNODE(p) << 1)
+#define UV_PNODE_TO_NASID(p) \
+ (UV_PNODE_TO_GNODE(p) << uv_hub_info->nasid_shift)
#define UV2_LOCAL_MMR_BASE 0xfa00UL
#define UV2_GLOBAL_MMR32_BASE 0xfc00UL
@@ -291,25 +295,38 @@ union uvh_apicid {
#define UV4_LOCAL_MMR_SIZE (32UL * 1024 * 1024)
#define UV4_GLOBAL_MMR32_SIZE 0
+#define UV5_LOCAL_MMR_BASE 0xfa00UL
+#define UV5_GLOBAL_MMR32_BASE 0
+#define UV5_LOCAL_MMR_SIZE (32UL * 1024 * 1024)
+#define UV5_GLOBAL_MMR32_SIZE 0
+
#define UV_LOCAL_MMR_BASE ( \
- is_uv2_hub() ? UV2_LOCAL_MMR_BASE : \
- is_uv3_hub() ? UV3_LOCAL_MMR_BASE : \
- /*is_uv4_hub*/ UV4_LOCAL_MMR_BASE)
+ is_uv(UV2) ? UV2_LOCAL_MMR_BASE : \
+ is_uv(UV3) ? UV3_LOCAL_MMR_BASE : \
+ is_uv(UV4) ? UV4_LOCAL_MMR_BASE : \
+ is_uv(UV5) ? UV5_LOCAL_MMR_BASE : \
+ 0)
#define UV_GLOBAL_MMR32_BASE ( \
- is_uv2_hub() ? UV2_GLOBAL_MMR32_BASE : \
- is_uv3_hub() ? UV3_GLOBAL_MMR32_BASE : \
- /*is_uv4_hub*/ UV4_GLOBAL_MMR32_BASE)
+ is_uv(UV2) ? UV2_GLOBAL_MMR32_BASE : \
+ is_uv(UV3) ? UV3_GLOBAL_MMR32_BASE : \
+ is_uv(UV4) ? UV4_GLOBAL_MMR32_BASE : \
+ is_uv(UV5) ? UV5_GLOBAL_MMR32_BASE : \
+ 0)
#define UV_LOCAL_MMR_SIZE ( \
- is_uv2_hub() ? UV2_LOCAL_MMR_SIZE : \
- is_uv3_hub() ? UV3_LOCAL_MMR_SIZE : \
- /*is_uv4_hub*/ UV4_LOCAL_MMR_SIZE)
+ is_uv(UV2) ? UV2_LOCAL_MMR_SIZE : \
+ is_uv(UV3) ? UV3_LOCAL_MMR_SIZE : \
+ is_uv(UV4) ? UV4_LOCAL_MMR_SIZE : \
+
[PATCH 10/12] x86/platform/uv: Update Node Present Counting
The changes in the UV5 arch shrunk the NODE PRESENT table to just 2x64
entries (128 total) so are in to 64 bit MMRs instead of a depth of 64
bits in an array. Adjust references when counting up the nodes present.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
arch/x86/kernel/apic/x2apic_uv_x.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -1437,20 +1437,32 @@ static int __init decode_uv_systab(void)
/* Set up physical blade translations from UVH_NODE_PRESENT_TABLE */
static __init void boot_init_possible_blades(struct uv_hub_info_s *hub_info)
{
+ unsigned long np;
int i, uv_pb = 0;
- pr_info("UV: NODE_PRESENT_DEPTH = %d\n", UVH_NODE_PRESENT_TABLE_DEPTH);
- for (i = 0; i < UVH_NODE_PRESENT_TABLE_DEPTH; i++) {
- unsigned long np;
-
- np = uv_read_local_mmr(UVH_NODE_PRESENT_TABLE + i * 8);
- if (np)
+ if (UVH_NODE_PRESENT_TABLE) {
+ pr_info("UV: NODE_PRESENT_DEPTH = %d\n",
+ UVH_NODE_PRESENT_TABLE_DEPTH);
+ for (i = 0; i < UVH_NODE_PRESENT_TABLE_DEPTH; i++) {
+ np = uv_read_local_mmr(UVH_NODE_PRESENT_TABLE + i * 8);
pr_info("UV: NODE_PRESENT(%d) = 0x%016lx\n", i, np);
-
+ uv_pb += hweight64(np);
+ }
+ }
+ if (UVH_NODE_PRESENT_0) {
+ np = uv_read_local_mmr(UVH_NODE_PRESENT_0);
+ pr_info("UV: NODE_PRESENT_0 = 0x%016lx\n", np);
+ uv_pb += hweight64(np);
+ }
+ if (UVH_NODE_PRESENT_1) {
+ np = uv_read_local_mmr(UVH_NODE_PRESENT_1);
+ pr_info("UV: NODE_PRESENT_1 = 0x%016lx\n", np);
uv_pb += hweight64(np);
}
if (uv_possible_blades != uv_pb)
uv_possible_blades = uv_pb;
+
+ pr_info("UV: number nodes/possible blades %d\n", uv_pb);
}
static void __init build_socket_tables(void)
[PATCH 11/12] x86/platform/uv: Update UV5 TSC Checking
Update check of BIOS TSC sync status to include both possible "invalid"
states provided by newer UV5 BIOS.
Signed-off-by: Mike Travis
Reviewed-by: Steve Wahl
---
arch/x86/include/asm/uv/uv_hub.h |2 +-
arch/x86/kernel/apic/x2apic_uv_x.c | 24 ++--
2 files changed, 11 insertions(+), 15 deletions(-)
--- linux.orig/arch/x86/include/asm/uv/uv_hub.h
+++ linux/arch/x86/include/asm/uv/uv_hub.h
@@ -727,7 +727,7 @@ extern void uv_nmi_setup_hubless(void);
#define UVH_TSC_SYNC_SHIFT_UV2K16 /* UV2/3k have different bits */
#define UVH_TSC_SYNC_MASK 3 /* 0011 */
#define UVH_TSC_SYNC_VALID 3 /* 0011 */
-#define UVH_TSC_SYNC_INVALID 2 /* 0010 */
+#define UVH_TSC_SYNC_UNKNOWN 0 /* */
/* BMC sets a bit this MMR non-zero before sending an NMI */
#define UVH_NMI_MMRUVH_BIOS_KERNEL_MMR
--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -200,36 +200,32 @@ static void __init uv_tsc_check_sync(voi
int sync_state;
int mmr_shift;
char *state;
- bool valid;
- /* Accommodate different UV arch BIOSes */
+ /* Different returns from different UV BIOS versions */
mmr = uv_early_read_mmr(UVH_TSC_SYNC_MMR);
mmr_shift =
is_uv2_hub() ? UVH_TSC_SYNC_SHIFT_UV2K : UVH_TSC_SYNC_SHIFT;
sync_state = (mmr >> mmr_shift) & UVH_TSC_SYNC_MASK;
+ /* Check if TSC is valid for all sockets */
switch (sync_state) {
case UVH_TSC_SYNC_VALID:
state = "in sync";
- valid = true;
+ mark_tsc_async_resets("UV BIOS");
break;
- case UVH_TSC_SYNC_INVALID:
- state = "unstable";
- valid = false;
+ /* If BIOS state unknown, don't do anything */
+ case UVH_TSC_SYNC_UNKNOWN:
+ state = "unknown";
break;
+
+ /* Otherwise, BIOS indicates problem with TSC */
default:
- state = "unknown: assuming valid";
- valid = true;
+ state = "unstable";
+ mark_tsc_unstable("UV BIOS");
break;
}
pr_info("UV: TSC sync state from BIOS:0%d(%s)\n", sync_state, state);
-
- /* Mark flag that says TSC != 0 is valid for socket 0 */
- if (valid)
- mark_tsc_async_resets("UV BIOS");
- else
- mark_tsc_unstable("UV BIOS");
}
/* Selector for (4|4A|5) structs */
[PATCH 01/12] x86/platform/uv: Remove UV BAU TLB Shootdown Handler
The Broadcast Assist Unit (BAU) TLB shootdown handler is being rewritten
to become the UV BAU APIC driver. It is designed to speed up sending
IPI's to selective CPUs within the system. Remove the current TLB
shutdown handler (tlb_uv.c) file and a couple of kernel hooks in the
interim.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
---
arch/x86/include/asm/idtentry.h |4
arch/x86/include/asm/uv/uv.h |4
arch/x86/include/asm/uv/uv_bau.h | 755 --
arch/x86/kernel/idt.c|3
arch/x86/mm/tlb.c| 24
arch/x86/platform/uv/Makefile|2
arch/x86/platform/uv/tlb_uv.c| 2097 ---
7 files changed, 2 insertions(+), 2887 deletions(-)
--- linux.orig/arch/x86/include/asm/idtentry.h
+++ linux/arch/x86/include/asm/idtentry.h
@@ -595,10 +595,6 @@ DECLARE_IDTENTRY_SYSVEC(CALL_FUNCTION_VE
#endif
#ifdef CONFIG_X86_LOCAL_APIC
-# ifdef CONFIG_X86_UV
-DECLARE_IDTENTRY_SYSVEC(UV_BAU_MESSAGE,
sysvec_uv_bau_message);
-# endif
-
# ifdef CONFIG_X86_MCE_THRESHOLD
DECLARE_IDTENTRY_SYSVEC(THRESHOLD_APIC_VECTOR, sysvec_threshold);
# endif
--- linux.orig/arch/x86/include/asm/uv/uv.h
+++ linux/arch/x86/include/asm/uv/uv.h
@@ -35,10 +35,8 @@ extern int is_uv_hubbed(int uvtype);
extern void uv_cpu_init(void);
extern void uv_nmi_init(void);
extern void uv_system_init(void);
-extern const struct cpumask *uv_flush_tlb_others(const struct cpumask *cpumask,
-const struct flush_tlb_info
*info);
-#else /* X86_UV */
+#else /* !X86_UV */
static inline enum uv_system_type get_uv_system_type(void) { return UV_NONE; }
static inline bool is_early_uv_system(void){ return 0; }
--- linux.orig/arch/x86/include/asm/uv/uv_bau.h
+++ /dev/null
@@ -1,755 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * SGI UV Broadcast Assist Unit definitions
- *
- * Copyright (C) 2008-2011 Silicon Graphics, Inc. All rights reserved.
- */
-
-#ifndef _ASM_X86_UV_UV_BAU_H
-#define _ASM_X86_UV_UV_BAU_H
-
-#include
-#include
-
-#define BITSPERBYTE 8
-
-/*
- * Broadcast Assist Unit messaging structures
- *
- * Selective Broadcast activations are induced by software action
- * specifying a particular 8-descriptor "set" via a 6-bit index written
- * to an MMR.
- * Thus there are 64 unique 512-byte sets of SB descriptors - one set for
- * each 6-bit index value. These descriptor sets are mapped in sequence
- * starting with set 0 located at the address specified in the
- * BAU_SB_DESCRIPTOR_BASE register, set 1 is located at BASE + 512,
- * set 2 is at BASE + 2*512, set 3 at BASE + 3*512, and so on.
- *
- * We will use one set for sending BAU messages from each of the
- * cpu's on the uvhub.
- *
- * TLB shootdown will use the first of the 8 descriptors of each set.
- * Each of the descriptors is 64 bytes in size (8*64 = 512 bytes in a set).
- */
-
-#define MAX_CPUS_PER_UVHUB 128
-#define MAX_CPUS_PER_SOCKET64
-#define ADP_SZ 64 /* hardware-provided max. */
-#define UV_CPUS_PER_AS 32 /* hardware-provided max. */
-#define ITEMS_PER_DESC 8
-/* the 'throttle' to prevent the hardware stay-busy bug */
-#define MAX_BAU_CONCURRENT 3
-#define UV_ACT_STATUS_MASK 0x3
-#define UV_ACT_STATUS_SIZE 2
-#define UV_DISTRIBUTION_SIZE 256
-#define UV_SW_ACK_NPENDING 8
-#define UV_NET_ENDPOINT_INTD 0x28
-#define UV_PAYLOADQ_GNODE_SHIFT49
-#define UV_PTC_BASENAME"sgi_uv/ptc_statistics"
-#define UV_BAU_BASENAME"sgi_uv/bau_tunables"
-#define UV_BAU_TUNABLES_DIR"sgi_uv"
-#define UV_BAU_TUNABLES_FILE "bau_tunables"
-#define WHITESPACE " \t\n"
-#define cpubit_isset(cpu, bau_local_cpumask) \
- test_bit((cpu), (bau_local_cpumask).bits)
-
-/* [19:16] SOFT_ACK timeout period 19: 1 is urgency 7 17:16 1 is multiplier
*/
-/*
- * UV2: Bit 19 selects between
- * (0): 10 microsecond timebase and
- * (1): 80 microseconds
- * we're using 560us
- */
-#define UV_INTD_SOFT_ACK_TIMEOUT_PERIOD(15UL)
-/* assuming UV3 is the same */
-
-#define BAU_MISC_CONTROL_MULT_MASK 3
-
-#define UVH_AGING_PRESCALE_SEL 0x00b000UL
-/* [30:28] URGENCY_7 an index into a table of times */
-#define BAU_URGENCY_7_SHIFT28
-#define BAU_URGENCY_7_MASK 7
-
-#define UVH_TRANSACTION_TIMEOUT0x00b200UL
-/* [45:40] BAU - BAU transaction timeout select - a multiplier */
-#define BAU_TRANS_SHIFT40
-#define BAU_TRANS_MASK 0x3f
-
-/*
- * shorten some awkward names
- */
-#define AS_PUSH_SHIFT UVH_LB_BAU_SB_ACTIVATION_CONTROL_PUSH_
[PATCH 08/12] x86/platform/uv: Adjust GAM MMR references affected by UV5 updates
Make modifications to the GAM MMR mappings to accommodate changes for UV5.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
arch/x86/kernel/apic/x2apic_uv_x.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -932,12 +932,32 @@ static __init void map_gru_high(int max_
static __init void map_mmr_high(int max_pnode)
{
- union uvh_rh_gam_mmr_overlay_config_u mmr;
- int shift = UVH_RH_GAM_MMR_OVERLAY_CONFIG_BASE_SHFT;
+ unsigned long base;
+ int shift;
+ bool enable;
- mmr.v = uv_read_local_mmr(UVH_RH_GAM_MMR_OVERLAY_CONFIG);
- if (mmr.s.enable)
- map_high("MMR", mmr.s.base, shift, shift, max_pnode, map_uc);
+ if (UVH_RH10_GAM_MMR_OVERLAY_CONFIG) {
+ union uvh_rh10_gam_mmr_overlay_config_u mmr;
+
+ mmr.v = uv_read_local_mmr(UVH_RH10_GAM_MMR_OVERLAY_CONFIG);
+ enable = mmr.s.enable;
+ base = mmr.s.base;
+ shift = UVH_RH10_GAM_MMR_OVERLAY_CONFIG_BASE_SHFT;
+ } else if (UVH_RH_GAM_MMR_OVERLAY_CONFIG) {
+ union uvh_rh_gam_mmr_overlay_config_u mmr;
+
+ mmr.v = uv_read_local_mmr(UVH_RH_GAM_MMR_OVERLAY_CONFIG);
+ enable = mmr.s.enable;
+ base = mmr.s.base;
+ shift = UVH_RH_GAM_MMR_OVERLAY_CONFIG_BASE_SHFT;
+ } else {
+ pr_err("UV:%s:RH_GAM_MMR_OVERLAY_CONFIG MMR undefined?\n",
+ __func__);
+ return;
+ }
+
+ if (enable)
+ map_high("MMR", base, shift, shift, max_pnode, map_uc);
else
pr_info("UV: MMR disabled\n");
}
[PATCH 12/12] x86/platform/uv: Update for UV5 NMI MMR changes
The UV NMI MMR addresses and fields moved between UV4 and UV5
necessitating a rewrite of the UV NMI handler. Adjust references
to accommodate those changes.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Steve Wahl
---
arch/x86/include/asm/uv/uv_hub.h | 13 ---
arch/x86/platform/uv/uv_nmi.c| 65 +--
2 files changed, 55 insertions(+), 23 deletions(-)
--- linux.orig/arch/x86/include/asm/uv/uv_hub.h
+++ linux/arch/x86/include/asm/uv/uv_hub.h
@@ -735,19 +735,6 @@ extern void uv_nmi_setup_hubless(void);
#define UVH_NMI_MMR_SHIFT 63
#define UVH_NMI_MMR_TYPE "SCRATCH5"
-/* Newer SMM NMI handler, not present in all systems */
-#define UVH_NMI_MMRX UVH_EVENT_OCCURRED0
-#define UVH_NMI_MMRX_CLEAR UVH_EVENT_OCCURRED0_ALIAS
-#define UVH_NMI_MMRX_SHIFT UVH_EVENT_OCCURRED0_EXTIO_INT0_SHFT
-#define UVH_NMI_MMRX_TYPE "EXTIO_INT0"
-
-/* Non-zero indicates newer SMM NMI handler present */
-#define UVH_NMI_MMRX_SUPPORTED UVH_EXTIO_INT0_BROADCAST
-
-/* Indicates to BIOS that we want to use the newer SMM NMI handler */
-#define UVH_NMI_MMRX_REQ UVH_BIOS_KERNEL_MMR_ALIAS_2
-#define UVH_NMI_MMRX_REQ_SHIFT 62
-
struct uv_hub_nmi_s {
raw_spinlock_t nmi_lock;
atomic_tin_nmi; /* flag this node in UV NMI IRQ */
--- linux.orig/arch/x86/platform/uv/uv_nmi.c
+++ linux/arch/x86/platform/uv/uv_nmi.c
@@ -2,8 +2,9 @@
/*
* SGI NMI support routines
*
- * Copyright (c) 2009-2013 Silicon Graphics, Inc. All Rights Reserved.
- * Copyright (c) Mike Travis
+ * Copyright (C) 2018-2020 Hewlett Packard Enterprise Development LP
+ * Copyright (C) 2007-2017 Silicon Graphics, Inc. All rights reserved.
+ * Copyright (c) Mike Travis
*/
#include
@@ -54,6 +55,20 @@ static struct uv_hub_nmi_s **uv_hub_nmi_
DEFINE_PER_CPU(struct uv_cpu_nmi_s, uv_cpu_nmi);
+/* Newer SMM NMI handler, not present in all systems */
+static unsigned long uvh_nmi_mmrx; /* UVH_EVENT_OCCURRED0/1 */
+static unsigned long uvh_nmi_mmrx_clear; /* UVH_EVENT_OCCURRED0/1_ALIAS
*/
+static int uvh_nmi_mmrx_shift; /*
UVH_EVENT_OCCURRED0/1_EXTIO_INT0_SHFT */
+static int uvh_nmi_mmrx_mask; /*
UVH_EVENT_OCCURRED0/1_EXTIO_INT0_MASK */
+static char *uvh_nmi_mmrx_type;/* "EXTIO_INT0" */
+
+/* Non-zero indicates newer SMM NMI handler present */
+static unsigned long uvh_nmi_mmrx_supported; /* UVH_EXTIO_INT0_BROADCAST */
+
+/* Indicates to BIOS that we want to use the newer SMM NMI handler */
+static unsigned long uvh_nmi_mmrx_req; /* UVH_BIOS_KERNEL_MMR_ALIAS_2
*/
+static int uvh_nmi_mmrx_req_shift; /* 62 */
+
/* UV hubless values */
#define NMI_CONTROL_PORT 0x70
#define NMI_DUMMY_PORT 0x71
@@ -227,13 +242,43 @@ static inline bool uv_nmi_action_is(cons
/* Setup which NMI support is present in system */
static void uv_nmi_setup_mmrs(void)
{
- if (uv_read_local_mmr(UVH_NMI_MMRX_SUPPORTED)) {
- uv_write_local_mmr(UVH_NMI_MMRX_REQ,
- 1UL << UVH_NMI_MMRX_REQ_SHIFT);
- nmi_mmr = UVH_NMI_MMRX;
- nmi_mmr_clear = UVH_NMI_MMRX_CLEAR;
- nmi_mmr_pending = 1UL << UVH_NMI_MMRX_SHIFT;
- pr_info("UV: SMI NMI support: %s\n", UVH_NMI_MMRX_TYPE);
+ /* First determine arch specific MMRs to handshake with BIOS */
+ if (UVH_EVENT_OCCURRED0_EXTIO_INT0_MASK) {
+ uvh_nmi_mmrx = UVH_EVENT_OCCURRED0;
+ uvh_nmi_mmrx_clear = UVH_EVENT_OCCURRED0_ALIAS;
+ uvh_nmi_mmrx_shift = UVH_EVENT_OCCURRED0_EXTIO_INT0_SHFT;
+ uvh_nmi_mmrx_mask = UVH_EVENT_OCCURRED0_EXTIO_INT0_MASK;
+ uvh_nmi_mmrx_type = "OCRD0-EXTIO_INT0";
+
+ uvh_nmi_mmrx_supported = UVH_EXTIO_INT0_BROADCAST;
+ uvh_nmi_mmrx_req = UVH_BIOS_KERNEL_MMR_ALIAS_2;
+ uvh_nmi_mmrx_req_shift = 62;
+
+ } else if (UVH_EVENT_OCCURRED1_EXTIO_INT0_MASK) {
+ uvh_nmi_mmrx = UVH_EVENT_OCCURRED1;
+ uvh_nmi_mmrx_clear = UVH_EVENT_OCCURRED1_ALIAS;
+ uvh_nmi_mmrx_shift = UVH_EVENT_OCCURRED1_EXTIO_INT0_SHFT;
+ uvh_nmi_mmrx_mask = UVH_EVENT_OCCURRED1_EXTIO_INT0_MASK;
+ uvh_nmi_mmrx_type = "OCRD1-EXTIO_INT0";
+
+ uvh_nmi_mmrx_supported = UVH_EXTIO_INT0_BROADCAST;
+ uvh_nmi_mmrx_req = UVH_BIOS_KERNEL_MMR_ALIAS_2;
+ uvh_nmi_mmrx_req_shift = 62;
+
+ } else {
+ pr_err("UV:%s:cannot find EVENT_OCCURRED*_EXTIO_INT0\n",
+ __func__);
+ return;
+ }
+
+ /* Then find out if new NMI is supported */
+ if (likely(uv_read_local_mmr(uvh_nmi_mmrx_supported))) {
+ uv_write_local_mmr(uvh_nmi_mmrx_req,
+ 1UL << uvh_nmi_mmrx_req_shift);
+ nmi_
Re: [PATCH] arm64: dts: marvell: espressobin: Add ethernet switch aliases
> As a result of this cleanup should be binary DTB file for V7 with same > structure as DTB file without such cleanup patch, right? Should be. If need be, you can decompile the DTB back to a DTS and make sure it looks correct. Andrew
Re: [PATCH v3 0/8] iommu/arm-smmu: Support maintaining bootloader mappings
On 2020-09-04 16:55, Bjorn Andersson wrote: > Based on previous attempts and discussions this is the latest attempt at > inheriting stream mappings set up by the bootloader, for e.g. boot splash or > efifb. > > Per Will's request this builds on the work by Jordan and Rob for the Adreno > SMMU support. It applies cleanly ontop of v16 of their series, which can be > found at > https://lore.kernel.org/linux-arm-msm/20200901164707.2645413-1-robdcl...@gmail.com/ > > Bjorn Andersson (8): >iommu/arm-smmu: Refactor context bank allocation >iommu/arm-smmu: Delay modifying domain during init >iommu/arm-smmu: Consult context bank allocator for identify domains >iommu/arm-smmu-qcom: Emulate bypass by using context banks >iommu/arm-smmu-qcom: Consistently initialize stream mappings >iommu/arm-smmu: Add impl hook for inherit boot mappings >iommu/arm-smmu: Provide helper for allocating identity domain >iommu/arm-smmu-qcom: Setup identity domain for boot mappings > > drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 111 ++- > drivers/iommu/arm/arm-smmu/arm-smmu.c | 122 ++--- > drivers/iommu/arm/arm-smmu/arm-smmu.h | 14 ++- > 3 files changed, 205 insertions(+), 42 deletions(-) > Tested on the OnePlus 6 (SDM845), allows booting with display enabled.
Re: [PATCH 2/2] clk: mediatek: Add MT8167 clock support
Hi Fabien,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on clk/clk-next rockchip/for-next soc/for-next
shawnguo/for-next v5.9-rc4 next-20200903]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Fabien-Parent/dt-bindings-clock-mediatek-add-bindings-for-MT8167-clocks/20200907-210215
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-randconfig-r022-20200907 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
ab68517e6b7e51b84c4b0e813a30258ec1ce5da5)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/clk/mediatek/clk-mt8167.c:419:27: warning: unused variable
>> 'axi_mfg_in_parents_e1' [-Wunused-const-variable]
static const char * const axi_mfg_in_parents_e1[] __initconst = {
^
1 warning generated.
#
https://github.com/0day-ci/linux/commit/a74658124a04b2423e4919643d37b4ef32bec7af
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Fabien-Parent/dt-bindings-clock-mediatek-add-bindings-for-MT8167-clocks/20200907-210215
git checkout a74658124a04b2423e4919643d37b4ef32bec7af
vim +/axi_mfg_in_parents_e1 +419 drivers/clk/mediatek/clk-mt8167.c
418
> 419 static const char * const axi_mfg_in_parents_e1[] __initconst = {
420 "clk26m_ck",
421 "gfmux_emi1x_sel",
422 "univpll_d24",
423 "mmpll380m"
424 };
425
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH 02/11] ARM: dts: s3c6410: move fixed clocks under root node in Mini6410
The fixed clocks are kept under dedicated 'clocks' node but this causes
multiple dtschema warnings:
clocks: $nodename:0: 'clocks' does not match
'^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
clocks: #size-cells:0:0: 0 is not one of [1, 2]
clocks: oscillator@0:reg:0: [0] is too short
clocks: oscillator@1:reg:0: [1] is too short
clocks: 'ranges' is a required property
oscillator@0: 'reg' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s3c6410-mini6410.dts | 30 ++
1 file changed, 11 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/s3c6410-mini6410.dts
b/arch/arm/boot/dts/s3c6410-mini6410.dts
index 1aeac33b0d34..75067dbcf7e8 100644
--- a/arch/arm/boot/dts/s3c6410-mini6410.dts
+++ b/arch/arm/boot/dts/s3c6410-mini6410.dts
@@ -28,26 +28,18 @@
bootargs = "console=ttySAC0,115200n8 earlyprintk rootwait
root=/dev/mmcblk0p1";
};
- clocks {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
-
- fin_pll: oscillator@0 {
- compatible = "fixed-clock";
- reg = <0>;
- clock-frequency = <1200>;
- clock-output-names = "fin_pll";
- #clock-cells = <0>;
- };
+ fin_pll: oscillator-0 {
+ compatible = "fixed-clock";
+ clock-frequency = <1200>;
+ clock-output-names = "fin_pll";
+ #clock-cells = <0>;
+ };
- xusbxti: oscillator@1 {
- compatible = "fixed-clock";
- reg = <1>;
- clock-output-names = "xusbxti";
- clock-frequency = <4800>;
- #clock-cells = <0>;
- };
+ xusbxti: oscillator-1 {
+ compatible = "fixed-clock";
+ clock-output-names = "xusbxti";
+ clock-frequency = <4800>;
+ #clock-cells = <0>;
};
srom-cs1@1800 {
--
2.17.1
[PATCH 03/11] ARM: dts: s3c6410: move fixed clocks under root node in SMDK6410
The fixed clocks are kept under dedicated 'clocks' node but this causes
multiple dtschema warnings:
clocks: $nodename:0: 'clocks' does not match
'^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
clocks: #size-cells:0:0: 0 is not one of [1, 2]
clocks: oscillator@0:reg:0: [0] is too short
clocks: oscillator@1:reg:0: [1] is too short
clocks: 'ranges' is a required property
oscillator@0: 'reg' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s3c6410-smdk6410.dts | 30 ++
1 file changed, 11 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/s3c6410-smdk6410.dts
b/arch/arm/boot/dts/s3c6410-smdk6410.dts
index 96267f5f02a8..74379061a11a 100644
--- a/arch/arm/boot/dts/s3c6410-smdk6410.dts
+++ b/arch/arm/boot/dts/s3c6410-smdk6410.dts
@@ -28,26 +28,18 @@
bootargs = "console=ttySAC0,115200n8 earlyprintk rootwait
root=/dev/mmcblk0p1";
};
- clocks {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
-
- fin_pll: oscillator@0 {
- compatible = "fixed-clock";
- reg = <0>;
- clock-frequency = <1200>;
- clock-output-names = "fin_pll";
- #clock-cells = <0>;
- };
+ fin_pll: oscillator-0 {
+ compatible = "fixed-clock";
+ clock-frequency = <1200>;
+ clock-output-names = "fin_pll";
+ #clock-cells = <0>;
+ };
- xusbxti: oscillator@1 {
- compatible = "fixed-clock";
- reg = <1>;
- clock-output-names = "xusbxti";
- clock-frequency = <4800>;
- #clock-cells = <0>;
- };
+ xusbxti: oscillator-1 {
+ compatible = "fixed-clock";
+ clock-output-names = "xusbxti";
+ clock-frequency = <4800>;
+ #clock-cells = <0>;
};
srom-cs1@1800 {
--
2.17.1
[PATCH 09/11] ARM: dts: s3c24xx: align PWM/timer node name with dtschema
Although PWM is used on S3C24xx as clocksource/timer, the dtschema
expects the node to be named in certain format:
timer@5100: $nodename:0: 'timer@5100' does not match
'^pwm(@.*|-[0-9a-f])*$'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s3c24xx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/s3c24xx.dtsi b/arch/arm/boot/dts/s3c24xx.dtsi
index 80d4ce79be55..06f82c7e458e 100644
--- a/arch/arm/boot/dts/s3c24xx.dtsi
+++ b/arch/arm/boot/dts/s3c24xx.dtsi
@@ -39,7 +39,7 @@
};
};
- timer: timer@5100 {
+ timer: pwm@5100 {
compatible = "samsung,s3c2410-pwm";
reg = <0x5100 0x1000>;
interrupts = <0 0 10 3>, <0 0 11 3>, <0 0 12 3>, <0 0 13 3>, <0
0 14 3>;
--
2.17.1
[PATCH 07/11] ARM: dts: s3c24xx: fix number of PWM cells
The PWM has only three cells, not four, as pointed out by dtschema:
timer@5100: #pwm-cells:0:0: 3 was expected
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s3c24xx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/s3c24xx.dtsi b/arch/arm/boot/dts/s3c24xx.dtsi
index 6d8dd3cdd3c0..0d49d7680e72 100644
--- a/arch/arm/boot/dts/s3c24xx.dtsi
+++ b/arch/arm/boot/dts/s3c24xx.dtsi
@@ -43,7 +43,7 @@
compatible = "samsung,s3c2410-pwm";
reg = <0x5100 0x1000>;
interrupts = <0 0 10 3>, <0 0 11 3>, <0 0 12 3>, <0 0 13 3>, <0
0 14 3>;
- #pwm-cells = <4>;
+ #pwm-cells = <3>;
};
uart0: serial@5000 {
--
2.17.1
[PATCH 01/11] ARM: dts: s5pv210: Correct ethernet unit address in SMDKV210
The SROM bank 5 is at address 0xa800, just like the one put in "reg"
property of ethernet node. Fix the unit address of ethernet node.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s5pv210-smdkv210.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/s5pv210-smdkv210.dts
b/arch/arm/boot/dts/s5pv210-smdkv210.dts
index 1e1570d66d89..7459e41e8ef1 100644
--- a/arch/arm/boot/dts/s5pv210-smdkv210.dts
+++ b/arch/arm/boot/dts/s5pv210-smdkv210.dts
@@ -39,7 +39,7 @@
clock-frequency = <32768>;
};
- ethernet@1800 {
+ ethernet@a800 {
compatible = "davicom,dm9000";
reg = <0xA800 0x2 0xA802 0x2>;
interrupt-parent = <&gph1>;
--
2.17.1
[PATCH 00/11] ARM: dts: s3c: dtschema fixes
Hi, This is last serie of big dtschema cleanups for Samsung DTS. It fixes almost all dtschema violations, except: s3c6410-mini6410.dt.yaml: srom-cs1-bus@1800: ethernet@1800:reg:0: [402653184, 2, 402653188, 2] is too long which is similar to the case with SMDK5410 (Exynos5410). The patchset was not tested on HW. Best regards, Krzysztof Krzysztof Kozlowski (11): ARM: dts: s5pv210: Correct ethernet unit address in SMDKV210 ARM: dts: s3c6410: move fixed clocks under root node in Mini6410 ARM: dts: s3c6410: move fixed clocks under root node in SMDK6410 ARM: dts: s3c6410: align node SROM bus node name with dtschema in Mini6410 ARM: dts: s3c6410: align node SROM bus node name with dtschema in SMDK6410 ARM: dts: s3c6410: remove additional CPU compatible ARM: dts: s3c24xx: fix number of PWM cells ARM: dts: s3c24xx: override nods by label ARM: dts: s3c24xx: align PWM/timer node name with dtschema ARM: dts: s3c24xx: add address to CPU node ARM: dts: s3c24xx: move fixed clocks under root node in SMDK2416 arch/arm/boot/dts/s3c2416-smdk2416.dts | 17 ++-- arch/arm/boot/dts/s3c2416.dtsi | 111 + arch/arm/boot/dts/s3c24xx.dtsi | 24 +++--- arch/arm/boot/dts/s3c6410-mini6410.dts | 32 +++ arch/arm/boot/dts/s3c6410-smdk6410.dts | 32 +++ arch/arm/boot/dts/s3c64xx.dtsi | 2 +- arch/arm/boot/dts/s5pv210-smdkv210.dts | 2 +- 7 files changed, 101 insertions(+), 119 deletions(-) -- 2.17.1
[PATCH 06/11] ARM: dts: s3c6410: remove additional CPU compatible
Only the specific compatible (arm,arm1176jzf-s) is allowed by dtschema:
cpu@0: compatible: ['arm,arm1176jzf-s', 'arm,arm1176'] is too long
cpu@0: compatible: Additional items are not allowed ('arm,arm1176' was
unexpected)
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s3c64xx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/s3c64xx.dtsi b/arch/arm/boot/dts/s3c64xx.dtsi
index 2e611df37911..cb11a87dbc42 100644
--- a/arch/arm/boot/dts/s3c64xx.dtsi
+++ b/arch/arm/boot/dts/s3c64xx.dtsi
@@ -34,7 +34,7 @@
cpu@0 {
device_type = "cpu";
- compatible = "arm,arm1176jzf-s", "arm,arm1176";
+ compatible = "arm,arm1176jzf-s";
reg = <0x0>;
};
};
--
2.17.1
[PATCH 10/11] ARM: dts: s3c24xx: add address to CPU node
The CPU nodes should be described as children of "cpus" bus node with
appropriate "reg" properties:
cpus: '#address-cells' is a required property
cpus: '#size-cells' is a required property
cpu: 'device_type' is a required property
cpu: 'reg' is a required property
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s3c2416.dtsi | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/s3c2416.dtsi b/arch/arm/boot/dts/s3c2416.dtsi
index d1dec9f52f69..4f084f4fe44f 100644
--- a/arch/arm/boot/dts/s3c2416.dtsi
+++ b/arch/arm/boot/dts/s3c2416.dtsi
@@ -18,8 +18,13 @@
};
cpus {
- cpu {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
compatible = "arm,arm926ej-s";
+ reg = <0x0>;
};
};
--
2.17.1
[PATCH 05/11] ARM: dts: s3c6410: align node SROM bus node name with dtschema in SMDK6410
The SROM controller is modeled with a bus so align the device node name
with dtschema to fix warning:
srom-cs1@1800: $nodename:0: 'srom-cs1@1800'
does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s3c6410-smdk6410.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/s3c6410-smdk6410.dts
b/arch/arm/boot/dts/s3c6410-smdk6410.dts
index 74379061a11a..69c9ec4cf381 100644
--- a/arch/arm/boot/dts/s3c6410-smdk6410.dts
+++ b/arch/arm/boot/dts/s3c6410-smdk6410.dts
@@ -42,7 +42,7 @@
#clock-cells = <0>;
};
- srom-cs1@1800 {
+ srom-cs1-bus@1800 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.17.1
[PATCH 11/11] ARM: dts: s3c24xx: move fixed clocks under root node in SMDK2416
The fixed clocks are kept under dedicated 'clocks' node but this causes
multiple dtschema warnings:
clocks: $nodename:0: 'clocks' does not match
'^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
clocks: #size-cells:0:0: 0 is not one of [1, 2]
clocks: xti@0:reg:0: [0] is too short
clocks: 'ranges' is a required property
xti@0: 'reg' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s3c2416-smdk2416.dts | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/s3c2416-smdk2416.dts
b/arch/arm/boot/dts/s3c2416-smdk2416.dts
index 811bfdef4e9b..47626ede6fdd 100644
--- a/arch/arm/boot/dts/s3c2416-smdk2416.dts
+++ b/arch/arm/boot/dts/s3c2416-smdk2416.dts
@@ -17,18 +17,11 @@
reg = <0x3000 0x400>;
};
- clocks {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
-
- xti: xti@0 {
- compatible = "fixed-clock";
- reg = <0>;
- clock-frequency = <1200>;
- clock-output-names = "xti";
- #clock-cells = <0>;
- };
+ xti: clock-0 {
+ compatible = "fixed-clock";
+ clock-frequency = <1200>;
+ clock-output-names = "xti";
+ #clock-cells = <0>;
};
};
--
2.17.1
[PATCH 04/11] ARM: dts: s3c6410: align node SROM bus node name with dtschema in Mini6410
The SROM controller is modeled with a bus so align the device node name
with dtschema to fix warning:
srom-cs1@1800: $nodename:0: 'srom-cs1@1800'
does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s3c6410-mini6410.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/s3c6410-mini6410.dts
b/arch/arm/boot/dts/s3c6410-mini6410.dts
index 75067dbcf7e8..28b9ed94 100644
--- a/arch/arm/boot/dts/s3c6410-mini6410.dts
+++ b/arch/arm/boot/dts/s3c6410-mini6410.dts
@@ -42,7 +42,7 @@
#clock-cells = <0>;
};
- srom-cs1@1800 {
+ srom-cs1-bus@1800 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.17.1
[PATCH 08/11] ARM: dts: s3c24xx: override nods by label
Using full paths to extend or override a device tree node is error
prone. If there was a typo error, a new node will be created instead of
extending the existing node. This will lead to run-time errors that
could be hard to detect.
A mistyped label on the other hand, will cause a dtc compile error
(during build time).
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/s3c2416.dtsi | 104 -
arch/arm/boot/dts/s3c24xx.dtsi | 22 +++
2 files changed, 63 insertions(+), 63 deletions(-)
diff --git a/arch/arm/boot/dts/s3c2416.dtsi b/arch/arm/boot/dts/s3c2416.dtsi
index 6adf64ea3ff2..d1dec9f52f69 100644
--- a/arch/arm/boot/dts/s3c2416.dtsi
+++ b/arch/arm/boot/dts/s3c2416.dtsi
@@ -23,49 +23,12 @@
};
};
- interrupt-controller@4a00 {
- compatible = "samsung,s3c2416-irq";
- };
-
clocks: clock-controller@4c00 {
compatible = "samsung,s3c2416-clock";
reg = <0x4c00 0x40>;
#clock-cells = <1>;
};
- pinctrl@5600 {
- compatible = "samsung,s3c2416-pinctrl";
- };
-
- timer@5100 {
- clocks = <&clocks PCLK_PWM>;
- clock-names = "timers";
- };
-
- uart_0: serial@5000 {
- compatible = "samsung,s3c2440-uart";
- clock-names = "uart", "clk_uart_baud2",
- "clk_uart_baud3";
- clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>,
- <&clocks SCLK_UART>;
- };
-
- uart_1: serial@50004000 {
- compatible = "samsung,s3c2440-uart";
- clock-names = "uart", "clk_uart_baud2",
- "clk_uart_baud3";
- clocks = <&clocks PCLK_UART1>, <&clocks PCLK_UART1>,
- <&clocks SCLK_UART>;
- };
-
- uart_2: serial@50008000 {
- compatible = "samsung,s3c2440-uart";
- clock-names = "uart", "clk_uart_baud2",
- "clk_uart_baud3";
- clocks = <&clocks PCLK_UART2>, <&clocks PCLK_UART2>,
- <&clocks SCLK_UART>;
- };
-
uart_3: serial@5000c000 {
compatible = "samsung,s3c2440-uart";
reg = <0x5000C000 0x4000>;
@@ -98,22 +61,59 @@
<&clocks MUX_HSMMC1>;
status = "disabled";
};
+};
- watchdog: watchdog@5300 {
- interrupts = <1 9 27 3>;
- clocks = <&clocks PCLK_WDT>;
- clock-names = "watchdog";
- };
+&i2c {
+ compatible = "samsung,s3c2440-i2c";
+ clocks = <&clocks PCLK_I2C0>;
+ clock-names = "i2c";
+};
- rtc: rtc@5700 {
- compatible = "samsung,s3c2416-rtc";
- clocks = <&clocks PCLK_RTC>;
- clock-names = "rtc";
- };
+&intc {
+ compatible = "samsung,s3c2416-irq";
+};
- i2c@5400 {
- compatible = "samsung,s3c2440-i2c";
- clocks = <&clocks PCLK_I2C0>;
- clock-names = "i2c";
- };
+&pinctrl_0 {
+ compatible = "samsung,s3c2416-pinctrl";
+};
+
+&rtc {
+ compatible = "samsung,s3c2416-rtc";
+ clocks = <&clocks PCLK_RTC>;
+ clock-names = "rtc";
+};
+
+&timer {
+ clocks = <&clocks PCLK_PWM>;
+ clock-names = "timers";
+};
+
+&uart_0 {
+ compatible = "samsung,s3c2440-uart";
+ clock-names = "uart", "clk_uart_baud2",
+ "clk_uart_baud3";
+ clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>,
+ <&clocks SCLK_UART>;
+};
+
+&uart_1 {
+ compatible = "samsung,s3c2440-uart";
+ clock-names = "uart", "clk_uart_baud2",
+ "clk_uart_baud3";
+ clocks = <&clocks PCLK_UART1>, <&clocks PCLK_UART1>,
+ <&clocks SCLK_UART>;
+};
+
+&uart_2 {
+ compatible = "samsung,s3c2440-uart";
+ clock-names = "uart", "clk_uart_baud2",
+ "clk_uart_baud3";
+ clocks = <&clocks PCLK_UART2>, <&clocks PCLK_UART2>,
+ <&clocks SCLK_UART>;
+};
+
+&watchdog {
+ interrupts = <1 9 27 3>;
+ clocks = <&clocks PCLK_WDT>;
+ clock-names = "watchdog";
};
diff --git a/arch/arm/boot/dts/s3c24xx.dtsi b/arch/arm/boot/dts/s3c24xx.dtsi
index 0d49d7680e72..80d4ce79be55 100644
--- a/arch/arm/boot/dts/s3c24xx.dtsi
+++ b/arch/arm/boot/dts/s3c24xx.dtsi
@@ -13,12 +13,12 @@
aliases {
pinctrl0 = &pinctrl_0;
- serial0 = &uart0;
- serial1 = &uart1;
- serial2 = &uart2;
+ serial0 = &uart_0;
+ serial1 = &uart_1;
+ serial2 = &uart_2;
};
- intc:interrupt-controller@4a00 {
+ intc: interrupt-controller@4a00 {
5.9-rc4: modpost undefined symbols + relocation in read-only section `.head.text'
This is 5.9-rc4 git on a specific amd64 machine with Debian unstable and custom kernel config. 5.8 compiled and worked fine, I hav seen something like this with different 5.9-git commits. I made sure my binutils and gcc-10 are up to date in Debian unstable and retried with 5.9-rc4. Still I see the same during build (have not tried booting it more than once after a failed boot). This only happens on this specific computer and is reproducible after make clean, other tested machines with Debian unstable toolchain are fine. Kernel config is below. ... CC arch/x86/boot/cpu.o LDS arch/x86/boot/compressed/vmlinux.lds AS arch/x86/boot/compressed/kernel_info.o AS arch/x86/boot/compressed/head_64.o VOFFSET arch/x86/boot/compressed/../voffset.h CC arch/x86/boot/compressed/string.o CC arch/x86/boot/compressed/cmdline.o CC arch/x86/boot/compressed/error.o OBJCOPY arch/x86/boot/compressed/vmlinux.bin RELOCS arch/x86/boot/compressed/vmlinux.relocs HOSTCC arch/x86/boot/compressed/mkpiggy CC arch/x86/boot/compressed/cpuflags.o CC arch/x86/boot/compressed/early_serial_console.o CC arch/x86/boot/compressed/kaslr.o CC arch/x86/boot/compressed/kaslr_64.o AS arch/x86/boot/compressed/mem_encrypt.o CC arch/x86/boot/compressed/pgtable_64.o CC arch/x86/boot/compressed/acpi.o XZKERN arch/x86/boot/compressed/vmlinux.bin.xz ERROR: modpost: "irq_poll_init" [drivers/scsi/lpfc/lpfc.ko] undefined! ERROR: modpost: "irq_poll_sched" [drivers/scsi/lpfc/lpfc.ko] undefined! ERROR: modpost: "irq_poll_complete" [drivers/scsi/lpfc/lpfc.ko] undefined! CC arch/x86/boot/compressed/misc.o make[1]: *** [scripts/Makefile.modpost:111: Module.symvers] Error 1 make[1]: *** Deleting file 'Module.symvers' make: *** [Makefile:1392: modules] Error 2 make: *** Waiting for unfinished jobs MKPIGGY arch/x86/boot/compressed/piggy.S AS arch/x86/boot/compressed/piggy.o LD arch/x86/boot/compressed/vmlinux ld: arch/x86/boot/compressed/head_64.o: warning: relocation in read-only section `.head.text' ld: warning: creating DT_TEXTREL in a PIE ZOFFSET arch/x86/boot/zoffset.h OBJCOPY arch/x86/boot/vmlinux.bin AS arch/x86/boot/header.o LD arch/x86/boot/setup.elf OBJCOPY arch/x86/boot/setup.bin BUILD arch/x86/boot/bzImage Setup is 14396 bytes (padded to 14848 bytes). System is 4649 kB CRC 3b22552a Kernel: arch/x86/boot/bzImage is ready (#38) # # Automatically generated file; DO NOT EDIT. # Linux/x86 5.9.0-rc4 Kernel Configuration # CONFIG_CC_VERSION_TEXT="gcc (Debian 10.2.0-6) 10.2.0" CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=100200 CONFIG_LD_VERSION=23500 CONFIG_CLANG_VERSION=0 CONFIG_CC_CAN_LINK=y CONFIG_CC_CAN_LINK_STATIC=y CONFIG_CC_HAS_ASM_GOTO=y CONFIG_CC_HAS_ASM_INLINE=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_TABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_BUILD_SALT="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_HAVE_KERNEL_ZSTD=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set CONFIG_KERNEL_XZ=y # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set # CONFIG_KERNEL_ZSTD is not set CONFIG_DEFAULT_INIT="" CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y # CONFIG_WATCH_QUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y # CONFIG_USELIB is not set CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_MIGRATION=y CONFIG_GENERIC_IRQ_INJECTION=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_IRQ_MSI_IOMMU=y CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y CONFIG_GENERIC_IRQ_RESERVATION_MODE=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # CONFIG_GENERIC_IRQ_DEBUGFS is not set # end of IRQ subsystem CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_INIT=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_HAVE_POSIX_CPU_TIMERS_TASK_WORK=y CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # end of Timers subsystem CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # # CPU/Tas
Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips
On 9/7/2020 10:43 AM, Jim Quinlan wrote: On Mon, Sep 7, 2020 at 5:16 AM Lorenzo Pieralisi wrote: On Thu, Aug 27, 2020 at 09:29:59AM -0400, Jim Quinlan wrote: On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig wrote: On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote: Hi, On 8/24/2020 12:30 PM, Jim Quinlan wrote: Patchset Summary: Enhance a PCIe host controller driver. Because of its unusual design we are foced to change dev->dma_pfn_offset into a more general role allowing multiple offsets. See the 'v1' notes below for more info. We are version 11 and counting, and it is not clear to me whether there is any chance of getting these patches reviewed and hopefully merged for the 5.10 merge window. There are a lot of different files being touched, so what would be the ideal way of routing those changes towards inclusion? FYI, I offered to take the dma-mapping bits through the dma-mapping tree. I have a bit of a backlog, but plan to review and if Jim is ok with that apply the current version. Sounds good to me. Hi Jim, is the dependency now solved ? Should we review/take this series as is for v5.10 through the PCI tree ? Hello Lorenzo, We are still working out a regression with the DMA offset commit on the RaspberryPi. Nicolas has found the root cause and we are now devising a solution. Maybe we can parallelize the PCIe driver review while the DMA changes are being worked on in Christoph's branch. Lorenzo, are you fine with the PCIe changes proper? -- Florian
Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline
Hi Maxime, On Mon, 2020-09-07 at 18:22 +0200, Maxime Ripard wrote: > Hi, > > On Thu, Sep 03, 2020 at 10:00:32AM +0200, Maxime Ripard wrote: > > Hi everyone, > > > > Here's a (pretty long) series to introduce support in the VC4 DRM driver > > for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4). > > > > The main differences are that there's two HDMI controllers and that there's > > more pixelvalve now. Those pixelvalve come with a mux in the HVS that still > > have only 3 FIFOs. Both of those differences are breaking a bunch of > > expectations in the driver, so we first need a good bunch of cleanup and > > reworks to introduce support for the new controllers. > > > > Similarly, the HDMI controller has all its registers shuffled and split in > > multiple controllers now, so we need a bunch of changes to support this as > > well. > > > > Only the HDMI support is enabled for now (even though the DPI and DSI > > outputs have been tested too). > > I've applied the patches 1-79 to drm-misc. I guess the final DT patch > should go through the arm-soc tree? I'll take care of it tomorrow. Regards, Nicolas signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/3] net: ax88796c: ASIX AX88796C SPI Ethernet Adapter Driver
> > On Tue, Aug 25, 2020 at 07:03:09PM +0200, Łukasz Stelmach wrote:
> >> +++ b/drivers/net/ethernet/asix/ax88796c_ioctl.c
> >
> > This is an odd filename. The ioctl code is wrong anyway, but there is
> > a lot more than ioctl in here. I suggest you give it a new name.
> >
>
> Sure, any suggestions?
Sorry, i have forgotten what is actually contained. Does it even need
to be a separate file?
> >> +u8 ax88796c_check_power(struct ax88796c_device *ax_local)
> >
> > bool ?
>
> OK.
>
> It appears, however, that 0 means OK and 1 !OK. Do you think changing to
> TRUE and FALSE (or FALSE and TRUE) is required?
Or change the name, ax88796c_check_power_off()? I don't really care,
so long as it is logical and not surprising.
> >> + AX_READ_STATUS(&ax_local->ax_spi, &ax_status);
> >> + if (!(ax_status.status & AX_STATUS_READY)) {
> >> +
> >> + /* AX88796C in power saving mode */
> >> + AX_WAKEUP(&ax_local->ax_spi);
> >> +
> >> + /* Check status */
> >> + start_time = jiffies;
> >> + do {
> >> + if (time_after(jiffies, start_time + HZ/2)) {
> >> + netdev_err(ax_local->ndev,
> >> + "timeout waiting for wakeup"
> >> + " from power saving\n");
> >> + break;
> >> + }
> >> +
> >> + AX_READ_STATUS(&ax_local->ax_spi, &ax_status);
> >> +
> >> + } while (!(ax_status.status & AX_STATUS_READY));
> >
> > include/linux/iopoll.h
> >
>
> Done. The result seems only slightly more elegant since the generic
> read_poll_timeout() needs to be employed.
Often code like this has bugs in it, not correctly handling the
scheduler sleeping longer than expected. That is why i point people at
iopoll, no bugs, not elegance.
> The manufacturer says
>
> The AX88796C integrates on-chip Fast Ethernet MAC and PHY, […]
>
> There is a single integrated PHY in this chip and no possiblity to
> connect external one. Do you think it makes sense in such case to
> introduce the additional layer of abstraction?
Yes it does, because it then uses all the standard phylib code to
drive the PHY which many people understand, is well tested, etc. It
will make the MAC driver smaller and probably less buggy.
> >> +static char *macaddr;
> >> +module_param(macaddr, charp, 0);
> >> +MODULE_PARM_DESC(macaddr, "MAC address");
> >
> > No Module parameters. You can get the MAC address from DT.
>
> What about systems without DT? Not every bootloader is sophisicated
> enough to edit DT before starting kernel. AX88786C is a chip that can be
> used in a variety of systems and I'd like to avoid too strong
> assumptions.
There is also a standardised way to read it from ACPI. And you can set
it using ip link set. DaveM will likely NACK a module parameter.
> >> +MODULE_AUTHOR("ASIX");
> >
> > Do you expect ASIX to support this?
>
> No.
>
> > You probably want to put your name here.
>
> I don't want to be considered as the only author and as far as I can
> tell being mentioned as an author does not imply being a
> maintainer. Do you think two MODULE_AUTHOR()s be OK?
Can you have two? One with two names listed is O.K.
> >> +
> >> + phy_status = AX_READ(&ax_local->ax_spi, P0_PSCR);
> >> + if (phy_status & PSCR_PHYLINK) {
> >> +
> >> + ax_local->w_state = ax_nop;
> >> + time_to_chk = 0;
> >> +
> >> + } else if (!(phy_status & PSCR_PHYCOFF)) {
> >> + /* The ethernet cable has been plugged */
> >> + if (ax_local->w_state == chk_cable) {
> >> + if (netif_msg_timer(ax_local))
> >> + netdev_info(ndev, "Cable connected\n");
> >> +
> >> + ax_local->w_state = chk_link;
> >> + ax_local->w_ticks = 0;
> >> + } else {
> >> + if (netif_msg_timer(ax_local))
> >> + netdev_info(ndev, "Check media status\n");
> >> +
> >> + if (++ax_local->w_ticks == AX88796C_WATCHDOG_RESTART) {
> >> + if (netif_msg_timer(ax_local))
> >> + netdev_info(ndev, "Restart autoneg\n");
> >> + ax88796c_mdio_write(ndev,
> >> + ax_local->mii.phy_id, MII_BMCR,
> >> + (BMCR_SPEED100 | BMCR_ANENABLE |
> >> + BMCR_ANRESTART));
> >> +
> >> + if (netif_msg_hw(ax_local))
> >> + ax88796c_dump_phy_regs(ax_local);
> >> + ax_local->w_ticks = 0;
> >> + }
> >> + }
> >> + } else {
> >> + if (netif_msg_timer(ax_local))
> >> + netdev_info(ndev, "Check cable status\n");
> >> +
> >> + ax_local->w_state = chk_cable;
> >> + }
> >> +
> >> + ax88796c_set_power_saving(ax_local, ax_local->ps_level);
> >> +
> >>
Re: [PATCH] drm: mxsfb: check framebuffer pitch
On Mon, Sep 07, 2020 at 07:17:12PM +0300, Laurent Pinchart wrote:
> Hi Stefan,
>
> Thank you for the patch.
>
> On Mon, Sep 07, 2020 at 06:03:43PM +0200, Stefan Agner wrote:
> > The lcdif IP does not support a framebuffer pitch (stride) other than
> > the CRTC width. Check for equality and reject the state otherwise.
> >
> > This prevents a distorted picture when using 640x800 and running the
> > Mesa graphics stack. Mesa tires to use a cache aligned stride, which
>
> s/tires/tries/
>
> > leads at that particular resolution to width != stride. Currently
> > Mesa has no fallback behavior, but rejecting this configuration allows
> > userspace to handle the issue correctly.
>
> I'm increasingly impressed by how featureful this IP core is :-)
>
> > Signed-off-by: Stefan Agner
> > ---
> > drivers/gpu/drm/mxsfb/mxsfb_kms.c | 22 ++
> > 1 file changed, 18 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > index b721b8b262ce..79aa14027f91 100644
> > --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > @@ -403,14 +403,28 @@ static int mxsfb_plane_atomic_check(struct drm_plane
> > *plane,
> > {
> > struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev);
> > struct drm_crtc_state *crtc_state;
> > + unsigned int pitch;
> > + int ret;
> >
> > crtc_state = drm_atomic_get_new_crtc_state(plane_state->state,
> >&mxsfb->crtc);
> >
> > - return drm_atomic_helper_check_plane_state(plane_state, crtc_state,
> > - DRM_PLANE_HELPER_NO_SCALING,
> > - DRM_PLANE_HELPER_NO_SCALING,
> > - false, true);
> > + ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state,
> > + DRM_PLANE_HELPER_NO_SCALING,
> > + DRM_PLANE_HELPER_NO_SCALING,
> > + false, true);
> > + if (ret || !plane_state->visible)
>
> Would it be more explict to check for !plane_state->fb ? Otherwise I'll
> have to verify that !fb always implies !visible :-)
>
> > + return ret;
> > +
> > + pitch = crtc_state->mode.hdisplay *
> > + plane_state->fb->format->cpp[0];
>
> This holds on a single line.
>
> > + if (plane_state->fb->pitches[0] != pitch) {
> > + dev_err(plane->dev->dev,
> > + "Invalid pitch: fb and crtc widths must be the same");
>
> I'd turn this into a dev_dbg(), printing error messages to the kernel
> log in response to user-triggered conditions is a bit too verbose and
> could flood the log.
>
> Wouldn't it be best to catch this issue when creating the framebuffer ?
Yeah this should be verified at addfb time. We try to validate as early as
possible.
-Daniel
>
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > }
> >
> > static void mxsfb_plane_primary_atomic_update(struct drm_plane *plane,
>
> --
> Regards,
>
> Laurent Pinchart
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] fs/nsfs.c: fix ioctl support of compat processes
Hi,
On Fri, Jul 24, 2020 at 02:31:19PM -0500, Eric W. Biederman wrote:
> Michael,
>
> As the original author of NS_GET_OWNER_UID can you take a look at this?
This is a gentle reminder that my patch hasn't been applied,
the problem reported by Ákos Uzonyi hasn't been fixed,
and the example in ioctl_ns(2) manual page doesn't work
when e.g. it's compiled with -m32 on a 64-bit kernel.
> "Dmitry V. Levin" writes:
> > On Fri, Jul 24, 2020 at 11:20:26AM +0200, Arnd Bergmann wrote:
> >> On Fri, Jul 24, 2020 at 2:12 AM Dmitry V. Levin wrote:
> >> >
> >> > According to Documentation/driver-api/ioctl.rst, in order to support
> >> > 32-bit user space running on a 64-bit kernel, each subsystem or driver
> >> > that implements an ioctl callback handler must also implement the
> >> > corresponding compat_ioctl handler. The compat_ptr_ioctl() helper can
> >> > be used in place of a custom compat_ioctl file operation for drivers
> >> > that only take arguments that are pointers to compatible data
> >> > structures.
> >> >
> >> > In case of NS_* ioctls only NS_GET_OWNER_UID accepts an argument, and
> >> > this argument is a pointer to uid_t type, which is universally defined
> >> > to __kernel_uid32_t.
> >>
> >> This is potentially dangerous to rely on, as there are two parts that
> >> are mismatched:
> >>
> >> - user space does not see the kernel's uid_t definition, but has its own,
> >> which may be either the 16-bit or the 32-bit type. 32-bit uid_t was
> >> introduced with linux-2.3.39 in back in 2000. glibc was already
> >> using 32-bit uid_t at the time in user space, but uclibc only changed
> >> in 2003, and others may have been even later.
> >>
> >> - the ioctl command number is defined (incorrectly) as if there was no
> >> argument, so if there is any user space that happens to be built with
> >> a 16-bit uid_t, this does not get caught.
> >
> > Note that NS_GET_OWNER_UID is provided on 32-bit architectures, too, so
> > this 16-bit vs 32-bit uid_t issue was exposed to userspace long time ago
> > when NS_GET_OWNER_UID was introduced, and making NS_GET_OWNER_UID
> > available for compat processes won't make any difference, as the mismatch
> > is not between native and compat types, but rather between 16-bit and
> > 32-bit uid_t types.
> >
> > I agree it would be correct to define NS_GET_OWNER_UID as
> > _IOR(NSIO, 0x4, uid_t) instead of _IO(NSIO, 0x4), but nobody Cc'ed me
> > on this topic when NS_GET_OWNER_UID was discussed, and that ship has long
> > sailed.
> >
> >> > This change fixes compat strace --pidns-translation.
> >> >
> >> > Note: when backporting this patch to stable kernels, commit
> >> > "compat_ioctl: add compat_ptr_ioctl()" is needed as well.
> >> >
> >> > Reported-by: Ákos Uzonyi
> >> > Fixes: 6786741dbf99 ("nsfs: add ioctl to get an owning user namespace
> >> > for ns file descriptor")
> >> > Cc: sta...@vger.kernel.org # v4.9+
> >> > Signed-off-by: Dmitry V. Levin
> >> > ---
> >> > fs/nsfs.c | 1 +
> >> > 1 file changed, 1 insertion(+)
> >> >
> >> > diff --git a/fs/nsfs.c b/fs/nsfs.c
> >> > index 800c1d0eb0d0..a00236bffa2c 100644
> >> > --- a/fs/nsfs.c
> >> > +++ b/fs/nsfs.c
> >> > @@ -21,6 +21,7 @@ static long ns_ioctl(struct file *filp, unsigned int
> >> > ioctl,
> >> > static const struct file_operations ns_file_operations = {
> >> > .llseek = no_llseek,
> >> > .unlocked_ioctl = ns_ioctl,
> >> > + .compat_ioctl = compat_ptr_ioctl,
> >> > };
> >> >
> >> > static char *ns_dname(struct dentry *dentry, char *buffer, int buflen)
>
> Thank you,
> Eric
--
ldv
Re: [PATCH] gpu/drm: cleanup coding style a bit
On Mon, Sep 07, 2020 at 05:31:29AM -0700, Bernard Zhao wrote:
> Remove first assignment to info which is meaningless.
> Put the width and higth check first.
> This change is to make the code a bit readable.
>
> Signed-off-by: Bernard Zhao
Looks reasonable, thanks for your patch. Applied to drm-misc-next for
5.10.
-Daniel
> ---
> drivers/gpu/drm/drm_framebuffer.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index df656366a530..2f5b0c2bb0fe 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -176,8 +176,7 @@ static int framebuffer_check(struct drm_device *dev,
> int i;
>
> /* check if the format is supported at all */
> - info = __drm_format_info(r->pixel_format);
> - if (!info) {
> + if (!__drm_format_info(r->pixel_format)) {
> struct drm_format_name_buf format_name;
>
> DRM_DEBUG_KMS("bad framebuffer format %s\n",
> @@ -186,9 +185,6 @@ static int framebuffer_check(struct drm_device *dev,
> return -EINVAL;
> }
>
> - /* now let the driver pick its own format info */
> - info = drm_get_format_info(dev, r);
> -
> if (r->width == 0) {
> DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
> return -EINVAL;
> @@ -199,6 +195,9 @@ static int framebuffer_check(struct drm_device *dev,
> return -EINVAL;
> }
>
> + /* now let the driver pick its own format info */
> + info = drm_get_format_info(dev, r);
> +
> for (i = 0; i < info->num_planes; i++) {
> unsigned int width = fb_plane_width(r->width, info, i);
> unsigned int height = fb_plane_height(r->height, info, i);
> --
> 2.28.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH RFC 09/10] kfence, Documentation: add KFENCE documentation
On Mon, 7 Sep 2020 at 19:55, Andrey Konovalov wrote: > On Mon, Sep 7, 2020 at 6:33 PM Marco Elver wrote: [...] > > > > +Guarded allocations are set up based on the sample interval. After > > > > expiration > > > > +of the sample interval, a guarded allocation from the KFENCE object > > > > pool is > > > > +returned to the main allocator (SLAB or SLUB). > > > > > > Only for freed allocations, right? > > > > Which "freed allocation"? What this paragraph says is that after the > > sample interval elapsed, we'll return a KFENCE allocation on kmalloc. > > It doesn't yet talk about freeing. > > It says that an allocation is returned to the main allocator, and this > is what is usually described with the word "freed". Do you mean > something else here? Ah, I see what's goin on. So the "returned to the main allocator" is ambiguous here. I meant to say "returned" as in kfence gives sl[au]b a kfence object to return for the next kmalloc. I'll reword this as it seems the phrase is overloaded in this context already. [...] > > > > +Upon deallocation of a KFENCE object, the object's page is again > > > > protected and > > > > +the object is marked as freed. Any further access to the object causes > > > > a fault > > > > +and KFENCE reports a use-after-free access. Freed objects are inserted > > > > at the > > > > +tail of KFENCE's freelist, so that the least recently freed objects > > > > are reused > > > > +first, and the chances of detecting use-after-frees of recently freed > > > > objects > > > > +is increased. > > > > > > Seems really similar to KASAN's quarantine? Is the implementation much > > > different? > > > > It's a list, and we just insert at the tail. Why does it matter? > > If the implementation is similar, we can then reuse quarantine. But I > guess it's not. The concept is similar, but the implementations are very different. Both use a list (although KASAN quarantine seems to reimplement its own singly-linked list). We just rely on a standard doubly-linked list, without any of the delayed freeing logic of the KASAN quarantine as KFENCE objects just change state to "freed" until they're reused (freed kfence objects are just inserted at the tail, and the next object to be used for an allocation is at the head). Thanks, -- Marco
Re: [PATCH AUTOSEL 4.14 17/33] net: usb: qmi_wwan: add Telit 0x1050 composition
On Mon, Sep 07, 2020 at 11:36:37AM +0200, Kristian Evensen wrote:
Hi,
On Sat, Oct 26, 2019 at 3:27 PM Sasha Levin wrote:
From: Daniele Palmas
[ Upstream commit e0ae2c578d3909e60e9448207f5d83f785f1129f ]
This patch adds support for Telit FN980 0x1050 composition
0x1050: tty, adb, rmnet, tty, tty, tty, tty
Signed-off-by: Daniele Palmas
Acked-by: Bjørn Mork
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index e406a05e79dcd..57e9166b4bff3 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1252,6 +1252,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
{QMI_FIXED_INTF(0x2357, 0x9000, 4)},/* TP-LINK MA260 */
{QMI_QUIRK_SET_DTR(0x1bc7, 0x1040, 2)}, /* Telit LE922A */
+ {QMI_QUIRK_SET_DTR(0x1bc7, 0x1050, 2)}, /* Telit FN980 */
{QMI_FIXED_INTF(0x1bc7, 0x1100, 3)},/* Telit ME910 */
{QMI_FIXED_INTF(0x1bc7, 0x1101, 3)},/* Telit ME910 dual modem */
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)},/* Telit LE920 */
--
2.20.1
When testing the FN980 with kernel 4.14, I noticed that the qmi device
was not there. Checking the git log, I see that this patch was never
applied. The patch applies fine, so I guess it was just missed
somewhere. If it could be added to the next 4.14 release, it would be
much appreciated.
Interesting, yes - I'm not sure why it's missing. I'll queue it up.
--
Thanks,
Sasha
[tip:master] BUILD SUCCESS 7f6aae3e054f8d36ac90812db4ffd78796a487d1
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master branch HEAD: 7f6aae3e054f8d36ac90812db4ffd78796a487d1 Merge branch 'core/build' elapsed time: 721m configs tested: 111 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64 defconfig arm64allyesconfig arm allyesconfig arm allmodconfig nds32alldefconfig mipsworkpad_defconfig mips cu1000-neo_defconfig powerpc g5_defconfig mips ath25_defconfig sh rts7751r2d1_defconfig ia64 allmodconfig shedosk7760_defconfig arm collie_defconfig mips sb1250_swarm_defconfig arm omap2plus_defconfig nios2 3c120_defconfig sh apsh4a3a_defconfig m68k atari_defconfig powerpc pseries_defconfig arcnsimosci_defconfig sh landisk_defconfig powerpc wii_defconfig h8300h8300h-sim_defconfig xtensa defconfig h8300 defconfig armneponset_defconfig powerpc mpc885_ads_defconfig mips ip28_defconfig mipsomega2p_defconfig mips pnx8335_stb225_defconfig mips bigsur_defconfig m68k sun3_defconfig arm socfpga_defconfig openriscdefconfig alphaallyesconfig sh se7343_defconfig arm pxa168_defconfig sh ecovec24_defconfig mips ip27_defconfig powerpc pasemi_defconfig mips ath79_defconfig arm eseries_pxa_defconfig armmmp2_defconfig armmini2440_defconfig ia64 alldefconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390defconfig s390 allyesconfig parisc allyesconfig sparc defconfig i386defconfig i386 allyesconfig sparcallyesconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a006-20200907 x86_64 randconfig-a004-20200907 x86_64 randconfig-a003-20200907 x86_64 randconfig-a005-20200907 x86_64 randconfig-a001-20200907 x86_64 randconfig-a002-20200907 i386 randconfig-a004-20200907 i386 randconfig-a005-20200907 i386 randconfig-a006-20200907 i386 randconfig-a003-20200907 i386 randconfig-a001-20200907 i386 randconfig-a002-20200907 i386 randconfig-a016-20200907 i386 randconfig-a015-20200907 i386 randconfig-a011-20200907 i386 randconfig-a013-20200907 i386 randconfig-a014-20200907 i386 randconfig-a012-20200907 riscv allnoconfig riscv defconfig riscvallyesconfig riscvallmodconfig x86_64 rhel x86_64rhel-7.6-kselfte
Re: [PATCH 1/3] net: ax88796c: ASIX AX88796C SPI Ethernet Adapter Driver
It was <2020-08-26 śro 15:06>, when David Laight wrote: > From: Lukasz Stelmach >> Sent: 26 August 2020 15:59 >> >> It was <2020-08-25 wto 20:44>, when Krzysztof Kozlowski wrote: >> > On Tue, Aug 25, 2020 at 07:03:09PM +0200, Łukasz Stelmach wrote: >> >> ASIX AX88796[1] is a versatile ethernet adapter chip, that can be >> >> connected to a CPU with a 8/16-bit bus or with an SPI. This driver >> >> supports SPI connection. > ... >> >> +++ b/drivers/net/ethernet/asix/Kconfig >> >> @@ -0,0 +1,20 @@ >> >> +# >> >> +# Asix network device configuration >> >> +# >> >> + >> >> +config NET_VENDOR_ASIX >> >> + bool "Asix devices" >> >> + depends on SPI >> >> + help >> >> + If you have a network (Ethernet) interface based on a chip from ASIX, >> >> say Y >> > >> > Looks like too long, did it pass checkpatch? >> >> Yes? Let me try again. Yes, this one passed, but I missed a few other >> problems. Thank you. >> >> >> + >> >> +if NET_VENDOR_ASIX >> >> + >> >> +config SPI_AX88796C >> >> + tristate "Asix AX88796C-SPI support" >> >> + depends on SPI >> >> + depends on GPIOLIB >> >> + help >> >> + Say Y here if you intend to attach a Asix AX88796C as SPI mode >> >> + >> >> +endif # NET_VENDOR_ASIX > > There are plenty of other ethernet devices made by ASIX (eg USB ones) > that have nothing at all to do with this driver. > So those questions are too broad. > > The first one should probable be for ASIX SPI network devices. > On the other hand there is only one ASIX SPI network device and there are four other Non-PCI AX88* chips (and that is all I know about them). > (I can't imagine SPI being fast enough to be useful for ethernet...) Not for a file server, sure. It handles clock up to 40MHz and it's meant for systems that cannot handle more than a few MB/s anyway. -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics signature.asc Description: PGP signature
Re: [PATCH 0/9] ASoC: sun8i-codec driver cleanup
On Sun, 30 Aug 2020 22:48:43 -0500, Samuel Holland wrote: > Now that the fixes series is merged, here is a series of small cleanups > to the sun8i-codec driver. These help shorten the patch stack for the > next series, which will add support for the other two DAIs in this > codec: AIF2 and AIF3. > > Samuel Holland (9): > ASoC: sun8i-codec: Remove extraneous widgets > ASoC: sun8i-codec: Fix AIF1 MODCLK widget name > ASoC: sun8i-codec: Fix AIF1_ADCDAT_CTRL field names > ASoC: sun8i-codec: Fix AIF1_MXR_SRC field names > ASoC: sun8i-codec: Fix ADC_DIG_CTRL field name > ASoC: sun8i-codec: Fix field bit number indentation > ASoC: sun8i-codec: Sort masks in a consistent order > ASoC: sun8i-codec: Attach the bus clock to the regmap > ASoC: sun8i-codec: Manage module clock via DAPM > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/9] ASoC: sun8i-codec: Remove extraneous widgets commit: b8cbb1cab70342756725c1beded6b81031a95762 [2/9] ASoC: sun8i-codec: Fix AIF1 MODCLK widget name commit: 2455e37adef39bf7fd12df963b86fa7f313f1ad4 [3/9] ASoC: sun8i-codec: Fix AIF1_ADCDAT_CTRL field names commit: fa5c0ca1f90aaadb6539ec6c407221f2ab7b7608 [4/9] ASoC: sun8i-codec: Fix AIF1_MXR_SRC field names commit: 0ba95493023de45744962af41ef5ad90bad7d8bb [5/9] ASoC: sun8i-codec: Fix ADC_DIG_CTRL field name commit: 30aff91ec7840fb72daef7ce389a9414e5db4075 [6/9] ASoC: sun8i-codec: Fix field bit number indentation commit: fcb7b39ee3d877e4eb79fb2abf15644d1b36285c [7/9] ASoC: sun8i-codec: Sort masks in a consistent order commit: f30ef55c332935c1d7c5f4ae3d084bec8d05712e [8/9] ASoC: sun8i-codec: Attach the bus clock to the regmap commit: efb736fb9eceac6ce335bbaa3d788a05649160b5 [9/9] ASoC: sun8i-codec: Manage module clock via DAPM commit: 6b3bb3c82b94521d6d61c1bf7c766c8c3bddacf5 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] spi: qup: Allow for compile-testing on !ARM
On Fri, 4 Sep 2020 17:37:10 +0100, Alex Dewar wrote: > There seems no reason to restrict testing to ARM, so remove this > constraint to improve test coverage. > > Build-tested with allyesconfig on x86. Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [1/1] spi: qup: Allow for compile-testing on !ARM commit: 2abaad678575acd54e9939e1174becd82ecc884b All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v3 0/3] ASoC: Add sdw stream operations to dailink ops.
On Sat, 5 Sep 2020 02:28:51 +0800, Bard Liao wrote: > Sdw stream operation APIs can be called once per stream. Move these > operations to dailink ops. The linked series is "soundwire: Remove sdw > stream operations from Intel soundwire dai". > > Reviewed-by: Vinod Koul > > Changes in v3: > - s/ASOC/ASoC > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/3] ASoC: soc-dai: clarify return value for get_sdw_stream() commit: d20e834e13ce349c9b901b9dd8b7013e255083e8 [2/3] ASoC: Intel: sof_sdw: add dailink .trigger callback commit: ae3a3918edf57bde7651964be04d0807cccae8f2 [3/3] ASoC: Intel: sof_sdw: add dailink .prepare and .hw_free callback commit: 06998d49bcac8a9df3341db99c5f81ae4ef51c84 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] regulator: lochnagar: Add additional VDDCORE range
On Fri, 4 Sep 2020 13:25:06 +0100, Charles Keepax wrote: > In the case of an unrecognised mini-card the Lochnagar will not > initialise the VDDCORE voltage register leading to a value outside of the > current range. Add an additional range to cover these values, initially > this wasn't done since they are duplicates of the existing minimum > value. Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [1/1] regulator: lochnagar: Add additional VDDCORE range commit: 6dc9674d95b8a8a81b85a4bed77f86d1b039be10 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
[PATCH] net: sched: skip an unnecessay check
From: Tom Rix
Reviewing the error handling in tcf_action_init_1()
most of the early handling uses
err_out:
if (cookie) {
kfree(cookie->data);
kfree(cookie);
}
before cookie could ever be set.
So skip the unnecessay check.
Signed-off-by: Tom Rix
---
net/sched/act_api.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 063d8aaf2900..f64af9d9dfee 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -976,7 +976,7 @@ struct tc_action *tcf_action_init_1(struct net *net, struct
tcf_proto *tp,
#endif
NL_SET_ERR_MSG(extack, "Failed to load TC action module");
err = -ENOENT;
- goto err_out;
+ goto err_free;
}
/* backward compatibility for policer */
@@ -1013,11 +1013,12 @@ struct tc_action *tcf_action_init_1(struct net *net,
struct tcf_proto *tp,
err_mod:
module_put(a_o->owner);
-err_out:
+err_free:
if (cookie) {
kfree(cookie->data);
kfree(cookie);
}
+err_out:
return ERR_PTR(err);
}
--
2.18.1
[RFC PATCH v2 2/3] mm: make pXd_addr_end() functions page-table entry aware
From: Alexander Gordeev
Unlike all other page-table abstractions pXd_addr_end() do not take
into account a particular table entry in which context the functions
are called. On architectures with dynamic page-tables folding that
might lead to lack of necessary information that is difficult to
obtain other than from the table entry itself. That already led to
a subtle memory corruption issue on s390.
By letting pXd_addr_end() functions know about the page-table entry
we allow archs not only make extra checks, but also optimizations.
As result of this change the pXd_addr_end_folded() functions used
in gup_fast traversal code become unnecessary and get replaced with
universal pXd_addr_end() variants.
The arch-specific updates not only add dereferencing of page-table
entry pointers, but also small changes to the code flow to make those
dereferences possible, at least for x86 and powerpc. Also for arm64,
but in way that should not have any impact.
So, even though the dereferenced page-table entries are not used on
archs other than s390, and are optimized out by the compiler, there
is a small change in kernel size and this is what bloat-o-meter reports:
x86:
add/remove: 0/0 grow/shrink: 2/0 up/down: 10/0 (10)
Function old new delta
vmemmap_populate 587 592 +5
munlock_vma_pages_range 556 561 +5
Total: Before=15534694, After=15534704, chg +0.00%
powerpc:
add/remove: 0/0 grow/shrink: 1/0 up/down: 4/0 (4)
Function old new delta
.remove_pagetable 16481652 +4
Total: Before=21478240, After=21478244, chg +0.00%
arm64:
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Function old new delta
Total: Before=20240851, After=20240851, chg +0.00%
sparc:
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Function old new delta
Total: Before=4907262, After=4907262, chg +0.00%
Signed-off-by: Alexander Gordeev
Signed-off-by: Gerald Schaefer
---
arch/arm/include/asm/pgtable-2level.h| 2 +-
arch/arm/mm/idmap.c | 6 ++--
arch/arm/mm/mmu.c| 8 ++---
arch/arm64/kernel/hibernate.c| 16 ++
arch/arm64/kvm/mmu.c | 16 +-
arch/arm64/mm/kasan_init.c | 8 ++---
arch/arm64/mm/mmu.c | 25 +++
arch/powerpc/mm/book3s64/radix_pgtable.c | 7 ++---
arch/powerpc/mm/hugetlbpage.c| 6 ++--
arch/s390/include/asm/pgtable.h | 8 ++---
arch/s390/mm/page-states.c | 8 ++---
arch/s390/mm/pageattr.c | 8 ++---
arch/s390/mm/vmem.c | 8 ++---
arch/sparc/mm/hugetlbpage.c | 6 ++--
arch/um/kernel/tlb.c | 8 ++---
arch/x86/mm/init_64.c| 15 -
arch/x86/mm/kasan_init_64.c | 16 +-
include/asm-generic/pgtable-nop4d.h | 2 +-
include/asm-generic/pgtable-nopmd.h | 2 +-
include/asm-generic/pgtable-nopud.h | 2 +-
include/linux/pgtable.h | 26 ---
mm/gup.c | 8 ++---
mm/ioremap.c | 8 ++---
mm/kasan/init.c | 17 +-
mm/madvise.c | 4 +--
mm/memory.c | 40
mm/mlock.c | 18 ---
mm/mprotect.c| 8 ++---
mm/pagewalk.c| 8 ++---
mm/swapfile.c| 8 ++---
mm/vmalloc.c | 16 +-
31 files changed, 165 insertions(+), 173 deletions(-)
diff --git a/arch/arm/include/asm/pgtable-2level.h
b/arch/arm/include/asm/pgtable-2level.h
index 3502c2f746ca..5e6416b339f4 100644
--- a/arch/arm/include/asm/pgtable-2level.h
+++ b/arch/arm/include/asm/pgtable-2level.h
@@ -209,7 +209,7 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned long
addr)
} while (0)
/* we don't need complex calculations here as the pmd is folded into the pgd */
-#define pmd_addr_end(addr,end) (end)
+#define pmd_addr_end(pmd,addr,end) (end)
#define set_pte_ext(ptep,pte,ext) cpu_set_pte_ext(ptep,pte,ext)
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index 448e57c6f653..5437f943ca8b 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -46,7 +46,7 @@ static void idmap_add_pmd(pud_t *pud, unsigned long addr,
unsigned long end,
pmd = pmd_offset(pud, addr);
do {
- next = pmd_addr_end(addr, end);
+ next = pmd_addr_end(*pmd, addr, end);
*pmd = __pmd((addr & PMD_MASK) | prot);
flush_pmd_entry(pmd);
} while (pmd++, addr = next, addr != end);
@@
[RFC PATCH v2 0/3] mm/gup: fix gup_fast with dynamic page table folding
This is v2 of an RFC previously discussed here: https://lore.kernel.org/lkml/20200828140314.8556-1-gerald.schae...@linux.ibm.com/ Patch 1 is a fix for a regression in gup_fast on s390, after our conversion to common gup_fast code. It will introduce special helper functions pXd_addr_end_folded(), which have to be used in places where pagetable walk is done w/o lock and with READ_ONCE, so currently only in gup_fast. Patch 2 is an attempt to make that more generic, i.e. change pXd_addr_end() themselves by adding an extra pXd value parameter. That was suggested by Jason during v1 discussion, because he is already thinking of some other places where he might want to switch to the READ_ONCE logic for pagetable walks. In general, that would be the cleanest / safest solution, but there is some impact on other architectures and common code, hence the new and greatly enlarged recipient list. Patch 3 is a "nice to have" add-on, which makes pXd_addr_end() inline functions instead of #defines, so that we get some type checking for the new pXd value parameter. Not sure about Fixes/stable tags for the generic solution. Only patch 1 fixes a real bug on s390, and has Fixes/stable tags. Patches 2 + 3 might still be nice to have in stable, to ease future backports, but I guess "nice to have" does not really qualify for stable backports. Changes in v2: - Pick option 2 from v1 discussion (pXd_addr_end_folded helpers) - Add patch 2 + 3 for more generic approach Alexander Gordeev (3): mm/gup: fix gup_fast with dynamic page table folding mm: make pXd_addr_end() functions page-table entry aware mm: make generic pXd_addr_end() macros inline functions arch/arm/include/asm/pgtable-2level.h| 2 +- arch/arm/mm/idmap.c | 6 ++-- arch/arm/mm/mmu.c| 8 ++--- arch/arm64/kernel/hibernate.c| 16 + arch/arm64/kvm/mmu.c | 16 - arch/arm64/mm/kasan_init.c | 8 ++--- arch/arm64/mm/mmu.c | 25 +++--- arch/powerpc/mm/book3s64/radix_pgtable.c | 7 ++-- arch/powerpc/mm/hugetlbpage.c| 6 ++-- arch/s390/include/asm/pgtable.h | 42 arch/s390/mm/page-states.c | 8 ++--- arch/s390/mm/pageattr.c | 8 ++--- arch/s390/mm/vmem.c | 8 ++--- arch/sparc/mm/hugetlbpage.c | 6 ++-- arch/um/kernel/tlb.c | 8 ++--- arch/x86/mm/init_64.c| 15 - arch/x86/mm/kasan_init_64.c | 16 - include/asm-generic/pgtable-nop4d.h | 2 +- include/asm-generic/pgtable-nopmd.h | 2 +- include/asm-generic/pgtable-nopud.h | 2 +- include/linux/pgtable.h | 38 - mm/gup.c | 8 ++--- mm/ioremap.c | 8 ++--- mm/kasan/init.c | 17 +- mm/madvise.c | 4 +-- mm/memory.c | 40 +++--- mm/mlock.c | 18 +++--- mm/mprotect.c| 8 ++--- mm/pagewalk.c| 8 ++--- mm/swapfile.c| 8 ++--- mm/vmalloc.c | 16 - 31 files changed, 219 insertions(+), 165 deletions(-) -- 2.17.1
[RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding
From: Alexander Gordeev
Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast
code") introduced a subtle but severe bug on s390 with gup_fast, due to
dynamic page table folding.
The question "What would it require for the generic code to work for s390"
has already been discussed here
https://lkml.kernel.org/r/20190418100218.0a4afd51@mschwideX1
and ended with a promising approach here
https://lkml.kernel.org/r/20190419153307.4f2911b5@mschwideX1
which in the end unfortunately didn't quite work completely.
We tried to mimic static level folding by changing pgd_offset to always
calculate top level page table offset, and do nothing in folded pXd_offset.
What has been overlooked is that PxD_SIZE/MASK and thus pXd_addr_end do
not reflect this dynamic behaviour, and still act like static 5-level
page tables.
Here is an example of what happens with gup_fast on s390, for a task with
3-levels paging, crossing a 2 GB pud boundary:
// addr = 0x1007000, end = 0x10080001000
static int gup_pud_range(p4d_t p4d, unsigned long addr, unsigned long end,
unsigned int flags, struct page **pages, int *nr)
{
unsigned long next;
pud_t *pudp;
// pud_offset returns &p4d itself (a pointer to a value on stack)
pudp = pud_offset(&p4d, addr);
do {
// on second iteratation reading "random" stack value
pud_t pud = READ_ONCE(*pudp);
// next = 0x1008000, due to PUD_SIZE/MASK !=
PGDIR_SIZE/MASK on s390
next = pud_addr_end(addr, end);
...
} while (pudp++, addr = next, addr != end); // pudp++ iterating over
stack
return 1;
}
pud_addr_end = 0x1008000 is correct, but the previous pgd/p4d_addr_end
should also have returned that limit, instead of the 5-level static
pgd/p4d limits with PUD_SIZE/MASK != PGDIR_SIZE/MASK. Then the "end"
parameter for gup_pud_range would also have been 0x1008000, and we
would not iterate further in gup_pud_range, but rather go back and
(correctly) do it in gup_pgd_range.
So, for the second iteration in gup_pud_range, we will increase pudp,
which pointed to a stack value and not the real pud table. This new pudp
will then point to whatever lies behind the p4d stack value. In general,
this happens to be the previously read pgd, but it probably could also
be something different, depending on compiler decisions.
Most unfortunately, if it happens to be the pgd value, which is the
same as the p4d / pud due to folding, it is a valid and present entry.
So after the increment, we would still point to the same pud entry.
The addr however has been increased in the second iteration, so that we
now have different pmd/pte_index values, which will result in very wrong
behaviour for the remaining gup_pmd/pte_range calls. We will effectively
operate on an address minus 2 GB, due to missing pudp increase.
In the "good case", if nothing is mapped there, we will fall back to
the slow gup path. But if something is mapped there, and valid
for gup_fast, we will end up (silently) getting references on the wrong
pages and also add the wrong pages to the **pages result array. This
can cause data corruption.
Fix this by introducing new pXd_addr_end_folded helpers, which take an
additional pXd entry value parameter, that can be used on s390
to determine the correct page table level and return corresponding
end / boundary. With that, the pointer iteration will always
happen in gup_pgd_range for s390. No change for other architectures
introduced.
Fixes: 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast code")
Cc: # 5.2+
Reviewed-by: Gerald Schaefer
Signed-off-by: Alexander Gordeev
Signed-off-by: Gerald Schaefer
---
arch/s390/include/asm/pgtable.h | 42 +
include/linux/pgtable.h | 16 +
mm/gup.c| 8 +++
3 files changed, 62 insertions(+), 4 deletions(-)
diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 7eb01a5459cd..027206e4959d 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -512,6 +512,48 @@ static inline bool mm_pmd_folded(struct mm_struct *mm)
}
#define mm_pmd_folded(mm) mm_pmd_folded(mm)
+/*
+ * With dynamic page table levels on s390, the static pXd_addr_end() functions
+ * will not return corresponding dynamic boundaries. This is no problem as long
+ * as only pXd pointers are passed down during page table walk, because
+ * pXd_offset() will simply return the given pointer for folded levels, and the
+ * pointer iteration over a range simply happens at the correct page table
+ * level.
+ * It is however a problem with gup_fast, or other places walking the page
+ * tables w/o locks using READ_ONCE(), and passing down the pXd values instead
+ * of pointers. In this case, the pointer given to pXd_offset() is a pointer to
+ * a stack variable, which cannot be use
[RFC PATCH v2 3/3] mm: make generic pXd_addr_end() macros inline functions
From: Alexander Gordeev
Since pXd_addr_end() macros take pXd page-table entry as a
parameter it makes sense to check the entry type on compile.
Even though most archs do not make use of page-table entries
in pXd_addr_end() calls, checking the type in traversal code
paths could help to avoid subtle bugs.
Signed-off-by: Alexander Gordeev
Signed-off-by: Gerald Schaefer
---
include/linux/pgtable.h | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 67ebc22cf83d..d9e7d16c2263 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -656,31 +656,35 @@ static inline int arch_unmap_one(struct mm_struct *mm,
*/
#ifndef pgd_addr_end
-#define pgd_addr_end(pgd, addr, end) \
-({ unsigned long __boundary = ((addr) + PGDIR_SIZE) & PGDIR_MASK; \
- (__boundary - 1 < (end) - 1)? __boundary: (end);\
-})
+#define pgd_addr_end pgd_addr_end
+static inline unsigned long pgd_addr_end(pgd_t pgd, unsigned long addr,
unsigned long end)
+{ unsigned long __boundary = (addr + PGDIR_SIZE) & PGDIR_MASK;
+ return (__boundary - 1 < end - 1) ? __boundary : end;
+}
#endif
#ifndef p4d_addr_end
-#define p4d_addr_end(p4d, addr, end) \
-({ unsigned long __boundary = ((addr) + P4D_SIZE) & P4D_MASK; \
- (__boundary - 1 < (end) - 1)? __boundary: (end);\
-})
+#define p4d_addr_end p4d_addr_end
+static inline unsigned long p4d_addr_end(p4d_t p4d, unsigned long addr,
unsigned long end)
+{ unsigned long __boundary = (addr + P4D_SIZE) & P4D_MASK;
+ return (__boundary - 1 < end - 1) ? __boundary : end;
+}
#endif
#ifndef pud_addr_end
-#define pud_addr_end(pud, addr, end) \
-({ unsigned long __boundary = ((addr) + PUD_SIZE) & PUD_MASK; \
- (__boundary - 1 < (end) - 1)? __boundary: (end);\
-})
+#define pud_addr_end pud_addr_end
+static inline unsigned long pud_addr_end(pud_t pud, unsigned long addr,
unsigned long end)
+{ unsigned long __boundary = (addr + PUD_SIZE) & PUD_MASK;
+ return (__boundary - 1 < end - 1) ? __boundary : end;
+}
#endif
#ifndef pmd_addr_end
-#define pmd_addr_end(pmd, addr, end) \
-({ unsigned long __boundary = ((addr) + PMD_SIZE) & PMD_MASK; \
- (__boundary - 1 < (end) - 1)? __boundary: (end);\
-})
+#define pmd_addr_end pmd_addr_end
+static inline unsigned long pmd_addr_end(pmd_t pmd, unsigned long addr,
unsigned long end)
+{ unsigned long __boundary = (addr + PMD_SIZE) & PMD_MASK;
+ return (__boundary - 1 < end - 1) ? __boundary : end;
+}
#endif
/*
--
2.17.1
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On Mon, Sep 07, 2020 at 11:03:29AM +0200, Neil Armstrong wrote: > On 07/09/2020 10:44, Daniel Vetter wrote: > > On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote: > >> On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: > >>> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver > >>> 1.21a), with a custom > >>> glue managing the IP resets, clock and data input similar to the DW-HDMI > >>> Glue on other > >>> Amlogic SoCs. > >>> > >>> This adds support for the Glue managing the transceiver, mimicing the > >>> init flow provided > >>> by Amlogic to setup the ENCl encoder, the glue, the transceiver, the > >>> digital D-PHY and the > >>> Analog PHY in the proper way. > >>> > >>> The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 > >>> clock, which pixel clock > >>> is derived and feeds the ENCL encoder and the VIU pixel reader. > >>> > >>> An optional "MEAS" clock can be enabled to measure the delay between each > >>> vsync feeding the > >>> DW-MIPI-DSI transceiver. > >>> > >>> Signed-off-by: Neil Armstrong > >> > >> More dw-hdmi drivers which aren't bridges but components, and the thing is > >> still midlayer-y as heck :-/ > > > > *dw-dsi, but really they both work the same way and should both be fixed > > ... > > They are bridges but since they have platform-dependent code due to theirs's > generic IP > nature, they need to be intanciated by components to sync with the platform > code. Yeah that's how it currently works, but there's not much reason why it needs to work like that. That platform glue code can also be put behind the drm_bridge abstraction, and we could use the normal dt based bridge lookup like for everything else. Afaiui the only reason dw-* bridge drivers work like that is because for historical reasons we only had component.c at first, and none of the more fancy dynamic bridge lookup. So would be really good to switch this all over to a proper&clean bridge abstraction, and not leak everything around. I've typed up what I think should be the way forward a few times already, but thus far not even the todo.rst entry materialized: https://lore.kernel.org/dri-devel/20200430135841.GE10381@phenom.ffwll.local/ If everyone is always about "not in my patch series" it'll never happen. Cheers, Daniel > > Neil > > > > >> > >> Can we try to fix this? There's a ton of this going on, and the more we > >> add the old fashioned way the harder this gets to fix up for real. > >> -Daniel > >> > >>> --- > >>> drivers/gpu/drm/meson/Kconfig | 7 + > >>> drivers/gpu/drm/meson/Makefile| 1 + > >>> drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++ > >>> 3 files changed, 570 insertions(+) > >>> create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > >>> > >>> diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig > >>> index 9f9281dd49f8..385f6f23839b 100644 > >>> --- a/drivers/gpu/drm/meson/Kconfig > >>> +++ b/drivers/gpu/drm/meson/Kconfig > >>> @@ -16,3 +16,10 @@ config DRM_MESON_DW_HDMI > >>> default y if DRM_MESON > >>> select DRM_DW_HDMI > >>> imply DRM_DW_HDMI_I2S_AUDIO > >>> + > >>> +config DRM_MESON_DW_MIPI_DSI > >>> + tristate "MIPI DSI Synopsys Controller support for Amlogic Meson > >>> Display" > >>> + depends on DRM_MESON > >>> + default y if DRM_MESON > >>> + select DRM_DW_MIPI_DSI > >>> + select GENERIC_PHY_MIPI_DPHY > >>> diff --git a/drivers/gpu/drm/meson/Makefile > >>> b/drivers/gpu/drm/meson/Makefile > >>> index 28a519cdf66b..2cc870e91182 100644 > >>> --- a/drivers/gpu/drm/meson/Makefile > >>> +++ b/drivers/gpu/drm/meson/Makefile > >>> @@ -5,3 +5,4 @@ meson-drm-y += meson_rdma.o meson_osd_afbcd.o > >>> > >>> obj-$(CONFIG_DRM_MESON) += meson-drm.o > >>> obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o > >>> +obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o > >>> diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > >>> b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > >>> new file mode 100644 > >>> index ..bbe1294fce7c > >>> --- /dev/null > >>> +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c > >>> @@ -0,0 +1,562 @@ > >>> +// SPDX-License-Identifier: GPL-2.0-or-later > >>> +/* > >>> + * Copyright (C) 2016 BayLibre, SAS > >>> + * Author: Neil Armstrong > >>> + * Copyright (C) 2015 Amlogic, Inc. All rights reserved. > >>> + */ > >>> + > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> + > >>> +#include > >>> + > >>> +#include > >>> +#include > >>> + > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> + > >>> +#include "meson_drv.h" > >>> +#include "meson_dw_mipi_dsi.h" > >>> +#include "meson_registers.h" > >>> +#include "meson_venc.h" > >>> + > >>> +#define DRIVER_NAME "meson-dw-mipi-dsi" > >>> +#define DRIVER_DESC "Amlogic Meson MIPI-DSI DRM driver" > >>> + > >>> +/* MIPI DSI/VENC Color Format Def
Re: [PATCH net-next RFC v3 01/14] devlink: Add reload action option to devlink reload command
On Mon, 7 Sep 2020 16:46:01 +0300 Moshe Shemesh wrote: > > In that sense I don't like --live because it doesn't really say much. > > AFAIU it means 1) no link flap; 2) < 2 sec datapath downtime; 3) no > > configuration is lost in kernel or device (including netdev config, > > link config, flow rules, counters etc.). I was hoping at least the > > documentation in patch 14 would be more precise. > > Actually, while writing "no-reset" or "live-patching" I meant also no > downtime at all and nothing resets (config, rules ... anything), that > fits mlx5 live-patching. > > However, to make it more generic, I can allow few seconds downtime and > add similar constrains as you mentioned here to "no-reset". I will add > that to the documentation patch. Oh! If your device supports no downtime and packet loss at all that's great. You don't have to weaken the definition now, whoever needs a weaker definition can add a different constraint level later, no?
[PATCH 3/4] drivers core: Reindent a couple uses around sysfs_emit
Just a couple of whitespace realignment to open parenthesis for
multi-line statements.
Signed-off-by: Joe Perches
---
drivers/base/node.c| 4 ++--
drivers/base/power/sysfs.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 60abdb27137b..f10e8236aba8 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -386,9 +386,9 @@ static ssize_t node_read_meminfo(struct device *dev,
nid, K(i.freeram),
nid, K(i.totalram - i.freeram),
nid, K(node_page_state(pgdat, NR_ACTIVE_ANON) +
- node_page_state(pgdat, NR_ACTIVE_FILE)),
+ node_page_state(pgdat, NR_ACTIVE_FILE)),
nid, K(node_page_state(pgdat, NR_INACTIVE_ANON) +
- node_page_state(pgdat, NR_INACTIVE_FILE)),
+ node_page_state(pgdat, NR_INACTIVE_FILE)),
nid, K(node_page_state(pgdat, NR_ACTIVE_ANON)),
nid, K(node_page_state(pgdat, NR_INACTIVE_ANON)),
nid, K(node_page_state(pgdat, NR_ACTIVE_FILE)),
diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
index c3d303c4c9c2..eace289938e0 100644
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -102,7 +102,7 @@ static ssize_t control_show(struct device *dev, struct
device_attribute *attr,
char *buf)
{
return sysfs_emit(buf, "%s\n",
- dev->power.runtime_auto ? ctrl_auto : ctrl_on);
+ dev->power.runtime_auto ? ctrl_auto : ctrl_on);
}
static ssize_t control_store(struct device * dev, struct device_attribute
*attr,
--
2.26.0
[PATCH 2/4] drivers core: Remove strcat uses around sysfs_emit and neaten
strcat is no longer necessary for sysfs_emit and sysfs_emit_at uses.
Convert the strcat uses to sysfs_emit calls and neaten other block
uses of direct returns to use an intermediate const char *.
Signed-off-by: Joe Perches
---
drivers/base/cacheinfo.c | 26 ++---
drivers/base/core.c| 10
drivers/base/memory.c | 47 ++
drivers/base/power/sysfs.c | 23 +++
4 files changed, 59 insertions(+), 47 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 6a8c2b5881be..7b3608fb8700 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -404,17 +404,23 @@ static ssize_t type_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct cacheinfo *this_leaf = dev_get_drvdata(dev);
+ const char *type = NULL;
switch (this_leaf->type) {
case CACHE_TYPE_DATA:
- return sysfs_emit(buf, "Data\n");
+ type = "Data";
+ break;
case CACHE_TYPE_INST:
- return sysfs_emit(buf, "Instruction\n");
+ type = "Instruction";
+ break;
case CACHE_TYPE_UNIFIED:
- return sysfs_emit(buf, "Unified\n");
+ type = "Unified";
+ break;
default:
return -EINVAL;
}
+
+ return sysfs_emit(buf, "%s\n", type);
}
static ssize_t allocation_policy_show(struct device *dev,
@@ -422,15 +428,19 @@ static ssize_t allocation_policy_show(struct device *dev,
{
struct cacheinfo *this_leaf = dev_get_drvdata(dev);
unsigned int ci_attr = this_leaf->attributes;
- int n = 0;
+ const char *type = NULL;
if ((ci_attr & CACHE_READ_ALLOCATE) && (ci_attr & CACHE_WRITE_ALLOCATE))
- n = sysfs_emit(buf, "ReadWriteAllocate\n");
+ type = "ReadWriteAllocate";
else if (ci_attr & CACHE_READ_ALLOCATE)
- n = sysfs_emit(buf, "ReadAllocate\n");
+ type = "ReadAllocate";
else if (ci_attr & CACHE_WRITE_ALLOCATE)
- n = sysfs_emit(buf, "WriteAllocate\n");
- return n;
+ type = "WriteAllocate";
+
+ if (!type)
+ return 0;
+
+ return sysfs_emit(buf, "%s\n", type);
}
static ssize_t write_policy_show(struct device *dev,
diff --git a/drivers/base/core.c b/drivers/base/core.c
index fdadfa047968..2314a4e541b4 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -267,16 +267,16 @@ static ssize_t auto_remove_on_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct device_link *link = to_devlink(dev);
- char *str;
+ char *type;
if (link->flags & DL_FLAG_AUTOREMOVE_SUPPLIER)
- str = "supplier unbind";
+ type = "supplier unbind";
else if (link->flags & DL_FLAG_AUTOREMOVE_CONSUMER)
- str = "consumer unbind";
+ type = "consumer unbind";
else
- str = "never";
+ type = "never";
- return sysfs_emit(buf, "%s\n", str);
+ return sysfs_emit(buf, "%s\n", type);
}
static DEVICE_ATTR_RO(auto_remove_on);
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 2fdab1ea036b..b559f2b1d1ff 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -139,7 +139,7 @@ static ssize_t state_show(struct device *dev, struct
device_attribute *attr,
char *buf)
{
struct memory_block *mem = to_memory_block(dev);
- ssize_t len = 0;
+ const char *type;
/*
* We can probably put these states in a nice little array
@@ -147,22 +147,20 @@ static ssize_t state_show(struct device *dev, struct
device_attribute *attr,
*/
switch (mem->state) {
case MEM_ONLINE:
- len = sysfs_emit(buf, "online\n");
+ type = "online";
break;
case MEM_OFFLINE:
- len = sysfs_emit(buf, "offline\n");
+ type = "offline";
break;
case MEM_GOING_OFFLINE:
- len = sysfs_emit(buf, "going-offline\n");
+ type = "going-offline";
break;
default:
- len = sysfs_emit(buf, "ERROR-UNKNOWN-%ld\n",
-mem->state);
WARN_ON(1);
- break;
+ return sysfs_emit(buf, "ERROR-UNKNOWN-%ld\n", mem->state);
}
- return len;
+ return sysfs_emit(buf, "%s\n", type);
}
int memory_notify(unsigned long val, void *v)
@@ -307,17 +305,16 @@ static ssize_t phys_device_show(struct device *dev,
}
#ifdef CONFIG_MEMORY_HOTREMOVE
-static void print_allowed_zone(char *buf, int nid, unsigned long start_pfn,
- unsigned long nr_pages, int online_type,
-
[PATCH 1/4] drivers core: Use sysfs_emit and sysfs_emit_at for show(device *...) functions
Convert the various sprintf fmaily calls in sysfs device show functions
to sysfs_emit and sysfs_emit_at for PAGE_SIZE buffer safety.
Done with:
$ spatch -sp-file sysfs_emit_dev.cocci --in-place --max-width=80 .
And cocci script:
$ cat sysfs_emit_dev.cocci
@@
identifier d_show;
identifier dev, attr, buf;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
return
- sprintf(buf,
+ sysfs_emit(buf,
...);
...>
}
@@
identifier d_show;
identifier dev, attr, buf;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
return
- snprintf(buf, PAGE_SIZE,
+ sysfs_emit(buf,
...);
...>
}
@@
identifier d_show;
identifier dev, attr, buf;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
return
- scnprintf(buf, PAGE_SIZE,
+ sysfs_emit(buf,
...);
...>
}
@@
identifier d_show;
identifier dev, attr, buf;
expression chr;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
return
- strcpy(buf, chr);
+ sysfs_emit(buf, chr);
...>
}
@@
identifier d_show;
identifier dev, attr, buf;
identifier len;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
len =
- sprintf(buf,
+ sysfs_emit(buf,
...);
...>
return len;
}
@@
identifier d_show;
identifier dev, attr, buf;
identifier len;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
len =
- snprintf(buf, PAGE_SIZE,
+ sysfs_emit(buf,
...);
...>
return len;
}
@@
identifier d_show;
identifier dev, attr, buf;
identifier len;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
len =
- scnprintf(buf, PAGE_SIZE,
+ sysfs_emit(buf,
...);
...>
return len;
}
@@
identifier d_show;
identifier dev, attr, buf;
identifier len;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
<...
- len += scnprintf(buf + len, PAGE_SIZE - len,
+ len += sysfs_emit_at(buf, len,
...);
...>
return len;
}
@@
identifier d_show;
identifier dev, attr, buf;
expression chr;
@@
ssize_t d_show(struct device *dev, struct device_attribute *attr, char *buf)
{
...
- strcpy(buf, chr);
- return strlen(buf);
+ return sysfs_emit(buf, chr);
}
Signed-off-by: Joe Perches
---
drivers/base/arch_topology.c| 2 +-
drivers/base/cacheinfo.c| 18 -
drivers/base/core.c | 19 +-
drivers/base/cpu.c | 32
drivers/base/dd.c | 2 +-
drivers/base/firmware_loader/fallback.c | 2 +-
drivers/base/memory.c | 24 ++--
drivers/base/node.c | 28 +++---
drivers/base/platform.c | 4 +-
drivers/base/power/sysfs.c | 50 -
drivers/base/power/wakeup_stats.c | 12 +++---
drivers/base/soc.c | 10 ++---
12 files changed, 102 insertions(+), 101 deletions(-)
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index 75f72d684294..744d4618db33 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -71,7 +71,7 @@ static ssize_t cpu_capacity_show(struct device *dev,
{
struct cpu *cpu = container_of(dev, struct cpu, dev);
- return sprintf(buf, "%lu\n", topology_get_cpu_scale(cpu->dev.id));
+ return sysfs_emit(buf, "%lu\n", topology_get_cpu_scale(cpu->dev.id));
}
static void update_topology_flags_workfn(struct work_struct *work);
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 8d553c92cd32..6a8c2b5881be 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -377,7 +377,7 @@ static ssize_t size_show(struct device *dev,
{
struct cacheinfo *this_leaf = dev_get_drvdata(dev);
- return sprintf(buf, "%uK\n", this_leaf->size >> 10);
+ return sysfs_emit(buf, "%uK\n", this_leaf->size >> 10);
}
static ssize_t shared_cpumap_show_func(struct device *dev, bool list, char
*buf)
@@ -407,11 +407,11 @@ static ssize_t type_show(struct device *dev,
switch (this_leaf->type) {
case CACHE_TYPE_DATA:
- return sprintf(buf, "Data\n");
+ return sysfs_emit(buf, "Data\n");
case CACHE_TYPE_INST:
- return sprintf(buf, "Instruction\n");
+ return sysfs_emit(buf, "Instruction\n");
case CACHE_TYPE_UNIFIED:
- return sprintf(buf, "Unified\n");
+ return sysfs_emit(buf, "Unified\n");
default:
return -EINVA
[PATCH 4/4] drivers core: Miscellaneous changes for sysfs_emit
Change a few additional instances that could use sysfs_emit that
the coccinelle script could not convert.
Signed-off-by: Joe Perches
---
drivers/base/class.c| 2 +-
drivers/base/cpu.c | 18 +-
drivers/base/node.c | 15 +++
drivers/base/platform.c | 4 +---
4 files changed, 14 insertions(+), 25 deletions(-)
diff --git a/drivers/base/class.c b/drivers/base/class.c
index bcd410e6d70a..c3451481194e 100644
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -478,7 +478,7 @@ ssize_t show_class_attr_string(struct class *class,
struct class_attribute_string *cs;
cs = container_of(attr, struct class_attribute_string, attr);
- return snprintf(buf, PAGE_SIZE, "%s\n", cs->str);
+ return sysfs_emit(buf, "%s\n", cs->str);
}
EXPORT_SYMBOL_GPL(show_class_attr_string);
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 232f8146a8c4..d3dc48bf6b0f 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -241,30 +241,30 @@ unsigned int total_cpus;
static ssize_t print_cpus_offline(struct device *dev,
struct device_attribute *attr, char *buf)
{
- int n = 0, len = PAGE_SIZE-2;
+ int len = 0;
cpumask_var_t offline;
/* display offline cpus < nr_cpu_ids */
if (!alloc_cpumask_var(&offline, GFP_KERNEL))
return -ENOMEM;
cpumask_andnot(offline, cpu_possible_mask, cpu_online_mask);
- n = scnprintf(buf, len, "%*pbl", cpumask_pr_args(offline));
+ len += sysfs_emit_at(buf, len, "%*pbl", cpumask_pr_args(offline));
free_cpumask_var(offline);
/* display offline cpus >= nr_cpu_ids */
if (total_cpus && nr_cpu_ids < total_cpus) {
- if (n && n < len)
- buf[n++] = ',';
+ len += sysfs_emit_at(buf, len, "%s", ",");
if (nr_cpu_ids == total_cpus-1)
- n += scnprintf(&buf[n], len - n, "%u", nr_cpu_ids);
+ len += sysfs_emit_at(buf, len, "%u", nr_cpu_ids);
else
- n += scnprintf(&buf[n], len - n, "%u-%d",
- nr_cpu_ids, total_cpus-1);
+ len += sysfs_emit_at(buf, len, "%u-%d",
+nr_cpu_ids, total_cpus-1);
}
- n += scnprintf(&buf[n], len - n, "\n");
- return n;
+ len += sysfs_emit_at(buf, len, "%s", "\n");
+
+ return len;
}
static DEVICE_ATTR(offline, 0444, print_cpus_offline, NULL);
diff --git a/drivers/base/node.c b/drivers/base/node.c
index f10e8236aba8..e6092b81644d 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -945,17 +945,6 @@ void unregister_one_node(int nid)
* node states attributes
*/
-static ssize_t print_nodes_state(enum node_states state, char *buf)
-{
- int n;
-
- n = scnprintf(buf, PAGE_SIZE - 1, "%*pbl",
- nodemask_pr_args(&node_states[state]));
- buf[n++] = '\n';
- buf[n] = '\0';
- return n;
-}
-
struct node_attr {
struct device_attribute attr;
enum node_states state;
@@ -965,7 +954,9 @@ static ssize_t show_node_state(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct node_attr *na = container_of(attr, struct node_attr, attr);
- return print_nodes_state(na->state, buf);
+
+ return sysfs_emit(buf, "%*pbl\n",
+ nodemask_pr_args(&node_states[na->state]));
}
#define _NODE_ATTR(name, state) \
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 0e03168c657c..927047f9e6a4 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1023,9 +1023,7 @@ static ssize_t modalias_show(struct device *dev, struct
device_attribute *a,
if (len != -ENODEV)
return len;
- len = snprintf(buf, PAGE_SIZE, "platform:%s\n", pdev->name);
-
- return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
+ return sysfs_emit(buf, "platform:%s\n", pdev->name);
}
static DEVICE_ATTR_RO(modalias);
--
2.26.0
[PATCH 0/4] drivers core: Use sysfs_emit functions
This is a sample block of conversions for drivers/base from next-20200903. It requires the suggested patch that adds sysfs_emit pafunctions from https://lore.kernel.org/lkml/a9054fb521e65f2809671fa9c18e2453061e9d91.1598744610.git@perches.com/ Convert and neaten the various uses of sprintf family functions to sysfs_emit and sysfs_emit_at Joe Perches (4): drivers core: Use sysfs_emit and sysfs_emit_at for show(device *...) functions drivers core: Remove strcat uses around sysfs_emit and neaten drivers core: Reindent a couple uses around sysfs_emit drivers core: Miscellaneous changes for sysfs_emit drivers/base/arch_topology.c| 2 +- drivers/base/cacheinfo.c| 32 - drivers/base/class.c| 2 +- drivers/base/core.c | 27 ++- drivers/base/cpu.c | 50 ++-- drivers/base/dd.c | 2 +- drivers/base/firmware_loader/fallback.c | 2 +- drivers/base/memory.c | 59 +++ drivers/base/node.c | 47 -- drivers/base/platform.c | 8 ++-- drivers/base/power/sysfs.c | 63 + drivers/base/power/wakeup_stats.c | 12 ++--- drivers/base/soc.c | 10 ++-- 13 files changed, 159 insertions(+), 157 deletions(-) -- 2.26.0
Re: [PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.
On Mon, Sep 07, 2020 at 02:46:21PM +0530, Vaibhav Gupta wrote:
> On Mon, Sep 07, 2020 at 09:55:59AM +0200, Daniel Vetter wrote:
> > On Thu, Aug 06, 2020 at 12:52:54PM +0530, Vaibhav Gupta wrote:
> > > Linux Kernel Mentee: Remove Legacy Power Management.
> > >
> > > The original goal of the patch series is to upgrade the power management
> > > framework of radeonfb fbdev driver. This has been done by upgrading
> > > .suspend()
> > > and .resume() callbacks.
> > >
> > > The upgrade makes sure that the involvement of PCI Core does not change
> > > the
> > > order of operations executed in a driver. Thus, does not change its
> > > behavior.
> > >
> > > During this process, it was found that "#if defined(CONFIG_PM)" at line
> > > 1434 is
> > > redundant. This was introduced in the commit
> > > 42ddb453a0cd ("radeon: Conditionally compile PM code").
> >
> > I do wonder whether it wouldn't be better to just outright delete these,
> > we have the drm radeon driver for pretty much all the same hardware ...
> > -Daniel
> >
> Hello Daniel,
> I don't have any problem in either way. My priority is to get rid of the
> legacy .suspend and .resume pointers from "struct pci_driver" . Hence,
> modifying
> every driver that is using them.
Ok, also sounds like we can't just ditch it outright and merging your
patches makes sense.
Please note that Bart (he's usually picking up the fbdev patches) is on
vacations until next week, I guess he'll then go and vacuum up everything
for 5.10 as he usually does.
Cheers, Daniel
>
> Vaibhav Gupta
> > >
> > >
> > >
> > > Before 42ddb453a0cd:
> > > $ git show 65122f7e80b5:drivers/video/aty/radeon_pm.c | grep -n
> > > "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
> > >
> > > Based on output in terminal:
> > >
> > > 547:#ifdef CONFIG_PM
> > >|-- 959:#ifdef CONFIG_PPC_PMAC
> > >|-- 972:#endif
> > >|-- 1291:#ifdef CONFIG_PPC_OF
> > >|-- 1301:#endif /* CONFIG_PPC_OF */
> > >|-- 1943:#ifdef CONFIG_PPC_OF
> > >|-- 2206:#if 0 /* Not ready yet */
> > >|-- 2508:#endif /* 0 */
> > >|-- 2510:#endif /* CONFIG_PPC_OF */
> > >|-- 2648:#ifdef CONFIG_PPC_PMAC
> > >|-- 2654:#endif /* CONFIG_PPC_PMAC */
> > >|-- 2768:#ifdef CONFIG_PPC_PMAC
> > >|-- 2774:#endif /* CONFIG_PPC_PMAC */
> > >|-- 2791:#ifdef CONFIG_PPC_OF__disabled
> > >|-- 2801:#endif /* CONFIG_PPC_OF */
> > > 2803:#endif /* CONFIG_PM */
> > >
> > >
> > >
> > > After 42ddb453a0cd:
> > > $ git show 42ddb453a0cd:drivers/video/aty/radeon_pm.c | grep -n
> > > "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
> > >
> > > Based on output in terminal:
> > >
> > > 547:#ifdef CONFIG_PM
> > >|-- 959:#ifdef CONFIG_PPC_PMAC
> > >|-- 972:#endif
> > >|-- 1291:#ifdef CONFIG_PPC_OF
> > >|-- 1301:#endif /* CONFIG_PPC_OF */
> > >|-- 1430:#if defined(CONFIG_PM)
> > >|-- 1431:#if defined(CONFIG_X86) ||
> > > defined(CONFIG_PPC_PMAC)
> > >|-- 1944:#endif
> > >|-- 1946:#ifdef CONFIG_PPC_OF
> > >|-- 1947:#ifdef CONFIG_PPC_PMAC
> > >|-- 2208:#endif
> > >|-- 2209:#endif
> > >|-- 2211:#if 0 /* Not ready yet */
> > >|-- 2513:#endif /* 0 */
> > >|-- 2515:#endif /* CONFIG_PPC_OF */
> > >|-- 2653:#ifdef CONFIG_PPC_PMAC
> > >|-- 2659:#endif /* CONFIG_PPC_PMAC */
> > >|-- 2773:#ifdef CONFIG_PPC_PMAC
> > >|-- 2779:#endif /* CONFIG_PPC_PMAC */
> > >|-- 2796:#ifdef CONFIG_PPC_OF__disabled
> > >|-- 2806:#endif /* CONFIG_PPC_OF */
> > > 2808:#endif /* CONFIG_PM */
> > >
> > >
> > >
> > > This also affected the CONFIG_PPC_OF container (line 1943 at commit
> > > 65122f7e80b5)
> > >
> > > The patch-series fixes it along with PM upgrade.
> > >
> > > All patches are compile-tested only.
> > >
> > > Test tools:
> > > - Compiler: gcc (GCC) 10.1.0
> > > - allmodconfig build: make -j$(nproc) W=1 all
> > >
> > > Vaibhav Gupta (2):
> > > video: fbdev: aty: radeon_pm: remove redundant CONFIG_PM container
> > > fbdev: radeonfb:use generic power management
> > >
> > > drivers/video/fbdev/aty/radeon_base.c | 10 ---
> > > drivers/video/fbdev/aty/radeon_pm.c | 38 ---
> > > drivers/video/fbdev/aty/radeonfb.h| 3 +--
> > > 3 files changed, 35 insertions(+), 16 deletions(-)
> > >
> > > --
> > > 2.27.0
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.fre
[PATCH v3 2/5] PCI: aardvark: Check for errors from pci_bridge_emul_init() call
Function pci_bridge_emul_init() may fail so correctly check for errors.
Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config
space")
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
drivers/pci/controller/pci-aardvark.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/pci-aardvark.c
b/drivers/pci/controller/pci-aardvark.c
index 1c5f2fd47c51..2e2e2a2ff51d 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -607,7 +607,7 @@ static struct pci_bridge_emul_ops advk_pci_bridge_emul_ops
= {
* Initialize the configuration space of the PCI-to-PCI bridge
* associated with the given PCIe interface.
*/
-static void advk_sw_pci_bridge_init(struct advk_pcie *pcie)
+static int advk_sw_pci_bridge_init(struct advk_pcie *pcie)
{
struct pci_bridge_emul *bridge = &pcie->bridge;
@@ -633,8 +633,7 @@ static void advk_sw_pci_bridge_init(struct advk_pcie *pcie)
bridge->data = pcie;
bridge->ops = &advk_pci_bridge_emul_ops;
- pci_bridge_emul_init(bridge, 0);
-
+ return pci_bridge_emul_init(bridge, 0);
}
static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,
@@ -1167,7 +1166,11 @@ static int advk_pcie_probe(struct platform_device *pdev)
advk_pcie_setup_hw(pcie);
- advk_sw_pci_bridge_init(pcie);
+ ret = advk_sw_pci_bridge_init(pcie);
+ if (ret) {
+ dev_err(dev, "Failed to register emulated root PCI bridge\n");
+ return ret;
+ }
ret = advk_pcie_init_irq_domain(pcie);
if (ret) {
--
2.20.1
Re: [PATCH v3] perf: arm_dsu: Support DSU ACPI devices
[+ Suzuki as I'd like his Ack on this]
On Fri, Aug 14, 2020 at 05:39:40PM -0700, Tuan Phan wrote:
> Add support for probing device from ACPI node.
> Each DSU ACPI node and its associated cpus are inside a cluster node.
>
> Signed-off-by: Tuan Phan
> ---
> Changes in v3:
> - Based on the latest ARM ACPI binding at:
> https://developer.arm.com/documentation/den0093/c/
>
> Changes in v2:
> - Removed IRQF_SHARED.
> - Fixed ACPI runtime detection.
>
> drivers/perf/arm_dsu_pmu.c | 68
> --
> 1 file changed, 60 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/perf/arm_dsu_pmu.c b/drivers/perf/arm_dsu_pmu.c
> index 96ed93c..4be355d 100644
> --- a/drivers/perf/arm_dsu_pmu.c
> +++ b/drivers/perf/arm_dsu_pmu.c
> @@ -11,6 +11,7 @@
> #define DRVNAME PMUNAME "_pmu"
> #define pr_fmt(fmt) DRVNAME ": " fmt
>
> +#include
> #include
> #include
> #include
> @@ -603,18 +604,21 @@ static struct dsu_pmu *dsu_pmu_alloc(struct
> platform_device *pdev)
> }
>
> /**
> - * dsu_pmu_dt_get_cpus: Get the list of CPUs in the cluster.
> + * dsu_pmu_dt_get_cpus: Get the list of CPUs in the cluster
> + * from device tree.
> */
> -static int dsu_pmu_dt_get_cpus(struct device_node *dev, cpumask_t *mask)
> +static int dsu_pmu_dt_get_cpus(struct platform_device *pdev)
> {
> int i = 0, n, cpu;
> struct device_node *cpu_node;
> + struct dsu_pmu *dsu_pmu =
> + (struct dsu_pmu *) platform_get_drvdata(pdev);
>
> - n = of_count_phandle_with_args(dev, "cpus", NULL);
> + n = of_count_phandle_with_args(pdev->dev.of_node, "cpus", NULL);
> if (n <= 0)
> return -ENODEV;
> for (; i < n; i++) {
> - cpu_node = of_parse_phandle(dev, "cpus", i);
> + cpu_node = of_parse_phandle(pdev->dev.of_node, "cpus", i);
> if (!cpu_node)
> break;
> cpu = of_cpu_node_to_id(cpu_node);
> @@ -626,11 +630,51 @@ static int dsu_pmu_dt_get_cpus(struct device_node *dev,
> cpumask_t *mask)
>*/
> if (cpu < 0)
> continue;
> - cpumask_set_cpu(cpu, mask);
> + cpumask_set_cpu(cpu, &dsu_pmu->associated_cpus);
> }
> return 0;
> }
>
> +/**
> + * dsu_pmu_acpi_get_cpus: Get the list of CPUs in the cluster
> + * from ACPI.
> + */
> +static int dsu_pmu_acpi_get_cpus(struct platform_device *pdev)
> +{
> + int cpu;
> + struct dsu_pmu *dsu_pmu = (struct dsu_pmu *) platform_get_drvdata(pdev);
> +
> + /*
> + * A dsu pmu node is inside a cluster parent node along with cpu nodes.
> + * We need to find out all cpus that have the same parent with this pmu.
> + */
> + for_each_possible_cpu(cpu) {
> + struct acpi_device *acpi_dev =
> ACPI_COMPANION(get_cpu_device(cpu));
> +
> + if (acpi_dev &&
> + acpi_dev->parent == ACPI_COMPANION(&pdev->dev)->parent)
> + cpumask_set_cpu(cpu, &dsu_pmu->associated_cpus);
> + }
> +
> + return 0;
> +}
> +
> +static int dsu_pmu_platform_get_cpus(struct platform_device *pdev)
> +{
> + int ret = -ENOENT;
> + struct fwnode_handle *fwnode = dev_fwnode(&pdev->dev);
> +
> + if (IS_ERR_OR_NULL(fwnode))
> + return ret;
> +
> + if (is_of_node(fwnode))
> + ret = dsu_pmu_dt_get_cpus(pdev);
> + else if (is_acpi_device_node(fwnode))
> + ret = dsu_pmu_acpi_get_cpus(pdev);
> +
> + return ret;
> +}
> +
> /*
> * dsu_pmu_probe_pmu: Probe the PMU details on a CPU in the cluster.
> */
> @@ -683,7 +727,9 @@ static int dsu_pmu_device_probe(struct platform_device
> *pdev)
> if (IS_ERR(dsu_pmu))
> return PTR_ERR(dsu_pmu);
>
> - rc = dsu_pmu_dt_get_cpus(pdev->dev.of_node, &dsu_pmu->associated_cpus);
> + platform_set_drvdata(pdev, dsu_pmu);
Hmm, this is a bit nasty because we haven't finished initialising the
dsu_pmu yet. I think it would actually be cleaner if you kept:
static int dsu_pmu_dt_get_cpus(struct device_node *dev, cpumask_t *mask)
for the DT case and added:
static int dsu_pmu_acpi_get_cpus(struct device *dev, cpumask_t *mask)
for the ACPI case. I suppose the DT case could take the struct device * too
if you wanted the prototypes to be the same.
> + rc = dsu_pmu_platform_get_cpus(pdev);
> if (rc) {
> dev_warn(&pdev->dev, "Failed to parse the CPUs\n");
> return rc;
> @@ -705,7 +751,6 @@ static int dsu_pmu_device_probe(struct platform_device
> *pdev)
> }
>
> dsu_pmu->irq = irq;
> - platform_set_drvdata(pdev, dsu_pmu);
> rc = cpuhp_state_add_instance(dsu_pmu_cpuhp_state,
> &dsu_pmu->cpuhp_node);
> if (rc)
> @@ -752,11 +797,19 @@ static const struct of_device_id dsu_pmu_of_match[] = {
> { .compatible = "arm,dsu-pmu", },
> {},
> };
> +MOD
Re: [PATCH v2 0/5] PCIe aardvark controller improvements
On Monday 07 September 2020 10:40:32 Lorenzo Pieralisi wrote: > can you rebase it on top of v5.9-rc1 and resend, thanks. Done!
Re: [PATCH v2] sched/debug: Add new tracepoint to track cpu_capacity
On 09/02/20 09:54, Phil Auld wrote: > > > > I think this decoupling is not necessary. The natural place for those > > scheduler trace_event based on trace_points extension files is > > kernel/sched/ and here the internal sched.h can just be included. > > > > If someone really wants to build this as an out-of-tree module there is > > an easy way to make kernel/sched/sched.h visible. > > > > It's not so much that we really _want_ to do this in an external module. > But we aren't adding more trace events and my (limited) knowledge of > BPF let me to the conclusion that its raw tracepoint functionality > requires full events. I didn't see any other way to do it. I did have a patch that allowed that. It might be worth trying to upstream it. It just required a new macro which could be problematic. https://github.com/qais-yousef/linux/commit/fb9fea29edb8af327e6b2bf3bc41469a8e66df8b With the above I could attach using bpf::RAW_TRACEPOINT mechanism. Cheers -- Qais Yousef
[PATCH v3 3/5] PCI: pci-bridge-emul: Export API functions
It allows kernel modules which are not compiled into kernel image to use pci-bridge-emul API functions. Signed-off-by: Pali Rohár Reviewed-by: Marek Behún --- drivers/pci/pci-bridge-emul.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/pci/pci-bridge-emul.c b/drivers/pci/pci-bridge-emul.c index ccf26d12ec61..139869d50eb2 100644 --- a/drivers/pci/pci-bridge-emul.c +++ b/drivers/pci/pci-bridge-emul.c @@ -294,6 +294,7 @@ int pci_bridge_emul_init(struct pci_bridge_emul *bridge, return 0; } +EXPORT_SYMBOL_GPL(pci_bridge_emul_init); /* * Cleanup a pci_bridge_emul structure that was previously initialized @@ -305,6 +306,7 @@ void pci_bridge_emul_cleanup(struct pci_bridge_emul *bridge) kfree(bridge->pcie_cap_regs_behavior); kfree(bridge->pci_regs_behavior); } +EXPORT_SYMBOL_GPL(pci_bridge_emul_cleanup); /* * Should be called by the PCI controller driver when reading the PCI @@ -366,6 +368,7 @@ int pci_bridge_emul_conf_read(struct pci_bridge_emul *bridge, int where, return PCIBIOS_SUCCESSFUL; } +EXPORT_SYMBOL_GPL(pci_bridge_emul_conf_read); /* * Should be called by the PCI controller driver when writing the PCI @@ -430,3 +433,4 @@ int pci_bridge_emul_conf_write(struct pci_bridge_emul *bridge, int where, return PCIBIOS_SUCCESSFUL; } +EXPORT_SYMBOL_GPL(pci_bridge_emul_conf_write); -- 2.20.1
[PATCH v3 1/5] PCI: aardvark: Fix compilation on s390
Include linux/gpio/consumer.h instead of linux/gpio.h, as is said in the
latter file.
This was reported by kernel test bot when compiling for s390.
drivers/pci/controller/pci-aardvark.c:350:2: error: implicit declaration of
function 'gpiod_set_value_cansleep' [-Werror,-Wimplicit-function-declaration]
drivers/pci/controller/pci-aardvark.c:1074:21: error: implicit declaration of
function 'devm_gpiod_get_from_of_node' [-Werror,-Wimplicit-function-declaration]
drivers/pci/controller/pci-aardvark.c:1076:14: error: use of undeclared
identifier 'GPIOD_OUT_LOW'
Link: https://lore.kernel.org/r/20200628.lxtenqfl%25...@intel.com
Reported-by: kernel test robot
Fixes: 5169a9851da ("PCI: aardvark: Issue PERST via GPIO")
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
drivers/pci/controller/pci-aardvark.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-aardvark.c
b/drivers/pci/controller/pci-aardvark.c
index 1559f79e63b6..1c5f2fd47c51 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -9,7 +9,7 @@
*/
#include
-#include
+#include
#include
#include
#include
--
2.20.1
Re: [PATCH] x86/msr: do not warn on writes to OC_MAILBOX
On Mon, Sep 7, 2020 at 1:11 PM Borislav Petkov wrote: > > Hi, > > On Mon, Sep 07, 2020 at 12:46:35PM +0200, Jason A. Donenfeld wrote: > > Are you sure that intel-undervolt using OC_MAILBOX from userspace is > > actually a "misuse"? Should the kernel or kernel drivers actually be > > involved with the task of underclocking? This seems pretty squarely in > > the realm of "hobbyists poking and prodding at their CPUs" rather than > > something made for a kernel driver, right? > > The only thing I'm sure is that *if* it makes sense for any driver to > control something in the hardware over MSRs, it should *not* poke at > naked MSRs but use a proper interface. > > I'd leave it to the people who actually need this interface, to explain > why they do. > > > Also, what was the justification for whitelisting > > MSR_IA32_ENERGY_PERF_BIAS? > > That's: > > tools/power/x86/x86_energy_perf_policy/x86_energy_perf_policy.c > > Once that thing gets converted to a proper interface too, that MSR goes > off the allowlist too. Gotcha. So your perspective is that the goal is actually to have no list at all in the end, because all MSR writes should go through sysfs interfaces and such, always? I certainly like that goal -- it'd make a whole lot of CPU functionality a lot more discoverable and easier to tinker with. In practice, it seems like that's a hard goal to accomplish, with different MSRs having different semantics and meanings of different bit offsets, and a great deal of them aren't actually publicly documented by Intel. Were you hoping to just handle these piece by piece, and eventually Linux will have a decent compendium of MSRs? That sure would be nice. Is Intel on board with that plan? Jason
Re: [PATCH 10/23] gpio: mockup: fix resource leak in error path
On Fri, Sep 4, 2020 at 7:00 PM Andy Shevchenko wrote: > > On Fri, Sep 04, 2020 at 05:45:34PM +0200, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > If the module init function fails after creating the debugs directory, > > it's never removed. Add proper cleanup calls to avoid this resource > > leak. > > Does it fix existing bug? You mean - should it go into stable? The bug is quite unlikely but yeah, probably. Bart
[PATCH v3] dt-bindings: crypto: Specify that allwinner,sun8i-a33-crypto needs reset
When adding allwinner,sun8i-a33-crypto, I forgot to add that it needs reset.
Furthermore, there are no need to use items to list only one compatible
in compatible list.
Fixes: f81547ba7a98 ("dt-bindings: crypto: add new compatible for A33 SS")
Signed-off-by: Corentin Labbe
---
Change since v2:
- fixed enum syntax
Change since v1:
- use an enum for adding allwinner,sun8i-a33-crypto to "reset list"
.../bindings/crypto/allwinner,sun4i-a10-crypto.yaml| 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml
b/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml
index fc823572bcff..90c6d039b91b 100644
--- a/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml
+++ b/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml
@@ -23,8 +23,7 @@ properties:
- items:
- const: allwinner,sun7i-a20-crypto
- const: allwinner,sun4i-a10-crypto
- - items:
- - const: allwinner,sun8i-a33-crypto
+ - const: allwinner,sun8i-a33-crypto
reg:
maxItems: 1
@@ -59,7 +58,9 @@ if:
properties:
compatible:
contains:
-const: allwinner,sun6i-a31-crypto
+enum:
+ - allwinner,sun6i-a31-crypto
+ - allwinner,sun8i-a33-crypto
then:
required:
--
2.26.2
Re: [PATCH RFC 09/10] kfence, Documentation: add KFENCE documentation
On Mon, Sep 7, 2020 at 6:33 PM Marco Elver wrote: > > On Mon, 7 Sep 2020 at 17:34, Andrey Konovalov wrote: > > > > On Mon, Sep 7, 2020 at 3:41 PM Marco Elver wrote: > > > > > > Add KFENCE documentation in dev-tools/kfence.rst, and add to index. > > > > > > Co-developed-by: Alexander Potapenko > > > Signed-off-by: Alexander Potapenko > > > Signed-off-by: Marco Elver > > > --- > > > Documentation/dev-tools/index.rst | 1 + > > > Documentation/dev-tools/kfence.rst | 285 + > > > 2 files changed, 286 insertions(+) > > > create mode 100644 Documentation/dev-tools/kfence.rst > > > > > > diff --git a/Documentation/dev-tools/index.rst > > > b/Documentation/dev-tools/index.rst > > > index f7809c7b1ba9..1b1cf4f5c9d9 100644 > > > --- a/Documentation/dev-tools/index.rst > > > +++ b/Documentation/dev-tools/index.rst > > > @@ -22,6 +22,7 @@ whole; patches welcome! > > > ubsan > > > kmemleak > > > kcsan > > > + kfence > > > gdb-kernel-debugging > > > kgdb > > > kselftest > > > diff --git a/Documentation/dev-tools/kfence.rst > > > b/Documentation/dev-tools/kfence.rst > > > new file mode 100644 > > > index ..254f4f089104 > > > --- /dev/null > > > +++ b/Documentation/dev-tools/kfence.rst > > > @@ -0,0 +1,285 @@ > > > +.. SPDX-License-Identifier: GPL-2.0 > > > + > > > +Kernel Electric-Fence (KFENCE) > > > +== > > > + > > > +Kernel Electric-Fence (KFENCE) is a low-overhead sampling-based memory > > > safety > > > +error detector. KFENCE detects heap out-of-bounds access, > > > use-after-free, and > > > +invalid-free errors. > > > + > > > +KFENCE is designed to be enabled in production kernels, and has near zero > > > +performance overhead. Compared to KASAN, KFENCE trades performance for > > > +precision. The main motivation behind KFENCE's design, is that with > > > enough > > > +total uptime KFENCE will detect bugs in code paths not typically > > > exercised by > > > +non-production test workloads. One way to quickly achieve a large enough > > > total > > > +uptime is when the tool is deployed across a large fleet of machines. > > > + > > > +Usage > > > +- > > > + > > > +To enable KFENCE, configure the kernel with:: > > > + > > > +CONFIG_KFENCE=y > > > + > > > +KFENCE provides several other configuration options to customize > > > behaviour (see > > > +the respective help text in ``lib/Kconfig.kfence`` for more info). > > > + > > > +Tuning performance > > > +~~ > > > + > > > +The most important parameter is KFENCE's sample interval, which can be > > > set via > > > +the kernel boot parameter ``kfence.sample_interval`` in milliseconds. The > > > +sample interval determines the frequency with which heap allocations > > > will be > > > +guarded by KFENCE. The default is configurable via the Kconfig option > > > +``CONFIG_KFENCE_SAMPLE_INTERVAL``. Setting ``kfence.sample_interval=0`` > > > +disables KFENCE. > > > + > > > +With the Kconfig option ``CONFIG_KFENCE_NUM_OBJECTS`` (default 255), the > > > number > > > +of available guarded objects can be controlled. Each object requires 2 > > > pages, > > > +one for the object itself and the other one used as a guard page; object > > > pages > > > +are interleaved with guard pages, and every object page is therefore > > > surrounded > > > +by two guard pages. > > > + > > > +The total memory dedicated to the KFENCE memory pool can be computed as:: > > > + > > > +( #objects + 1 ) * 2 * PAGE_SIZE > > > + > > > +Using the default config, and assuming a page size of 4 KiB, results in > > > +dedicating 2 MiB to the KFENCE memory pool. > > > + > > > +Error reports > > > +~ > > > + > > > +A typical out-of-bounds access looks like this:: > > > + > > > +== > > > +BUG: KFENCE: out-of-bounds in test_out_of_bounds_read+0xa3/0x22b > > > + > > > +Out-of-bounds access at 0xb672efff (left of kfence-#17): > > > + test_out_of_bounds_read+0xa3/0x22b > > > + kunit_try_run_case+0x51/0x85 > > > + kunit_generic_run_threadfn_adapter+0x16/0x30 > > > + kthread+0x137/0x160 > > > + ret_from_fork+0x22/0x30 > > > + > > > +kfence-#17 [0xb672f000-0xb672f01f, size=32, > > > cache=kmalloc-32] allocated in: > > > > Does the user need to know that this is object #17? This doesn't seem > > like something that can be useful for anything. > > Some arguments for keeping it: > > - We need to write something like "left of ". And then we need > to say where is allocated. Giving objects names makes it > easier to understand the link between "left of " and the > stacktrace shown after " allocated in". We could make > just "object", but reading "left/right of object" and then "object > allocated in:" can be a little confusing. > > - We can look up the object via its number in the debugfs objects list > (/sys/kernel/debug/kfence/objects). For example
Re: [PATCH v2] sched/debug: Add new tracepoint to track cpu_capacity
On Mon, Sep 07, 2020 at 11:48:45AM +0100, Qais Yousef wrote: > IMHO the above is a hack. Out-of-tree modules should rely on public headers > and > exported functions only. What you propose means that people who want to use > these tracepoints in meaningful way must have a prebuilt kernel handy. Which > is > maybe true for us who work in the embedded world. But users who run normal > distro kernels (desktop/servers) will fail to build against But this isn't really aimed at regular users. We're aiming this at developers (IIUC) so I dont really see this as a problem. > FWIW, I did raise this concern with Peter in 2019 OSPM and he was okay with > the > exports as it's still not a contract and they can disappear anytime we want. > Migrating to using BTF is the right way forward IMO. I don't think what we > have > here is out-of-control yet. Though I agree they're annoying. Right, we're hiding behind the explicit lack of ABI for modules. Anyway, CTF/BTF/random other crap that isn't DWARFs should work fine to replace all this muck. Just no idea what the state of any of that is.
Re: [PATCH 15/23] gpio: mockup: use dynamic device IDs
On Fri, Sep 4, 2020 at 6:49 PM Andy Shevchenko wrote: > > On Fri, Sep 04, 2020 at 05:45:39PM +0200, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > We're currently creating chips at module init time only so using a > > static index for dummy devices is fine. We want to support dynamically > > created chips however so we need to switch to dynamic device IDs. > > It misses ida_destroy(). > No, we always call ida_free() for separate IDs when removing devices and we remove all devices at module exit so no need to call ida_destroy(). > What about XArray API? > Answered that somewhere - xarray is already used internally by IDA. Bart
[PATCH v3 0/5] PCIe aardvark controller improvements
Hi, we have some more improvements for PCIe aardvark controller (Armada 3720 SOC - EspressoBIN and Turris MOX). The main improvement is that with these patches the driver can be compiled as a module, and can be reloaded at runtime. Marek & Pali Changes in V3: * Rebased on top of the v5.9-rc1 release Changes in V2 for patch 4/5: * Protect pci_stop_root_bus() and pci_remove_root_bus() function calls by pci_lock_rescan_remove() and pci_unlock_rescan_remove() Pali Rohár (5): PCI: aardvark: Fix compilation on s390 PCI: aardvark: Check for errors from pci_bridge_emul_init() call PCI: pci-bridge-emul: Export API functions PCI: aardvark: Implement driver 'remove' function and allow to build it as module PCI: aardvark: Move PCIe reset card code to advk_pcie_train_link() drivers/pci/controller/Kconfig| 2 +- drivers/pci/controller/pci-aardvark.c | 104 -- drivers/pci/pci-bridge-emul.c | 4 + 3 files changed, 71 insertions(+), 39 deletions(-) -- 2.20.1
Re: [PATCH 16/23] gpio: mockup: refactor the module init function
On Fri, Sep 4, 2020 at 6:57 PM Andy Shevchenko wrote: > > On Fri, Sep 04, 2020 at 05:45:40PM +0200, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > This is in preparation for dynamically created chips. > > > > Let's split out the code that can be reused when creating chips at > > run-time. Let's also move the code preparing the device properties into > > a separate routine. This has the advantage of simplifying the error > > handling. > > Almost all contents of this patch should go to proposed helper as I mentioned > before. Will make this patch quite small and understandable. > Sorry, I'm not sure what you're referring to. Bart
