Re: [PATCH] staging: rtl8192u: minor coding style fix
On Thu, Feb 25, 2021 at 10:03:51AM +, Lee Gibson wrote:
> Fixes this checkpatch warning
> WARNING: Comparisons should place the constant on the right side of the test
>
> Signed-off-by: Lee Gibson
> ---
> drivers/staging/rtl8192u/r8192U_wx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8192u/r8192U_wx.c
> b/drivers/staging/rtl8192u/r8192U_wx.c
> index d853586705fc..175bb8b15389 100644
> --- a/drivers/staging/rtl8192u/r8192U_wx.c
> +++ b/drivers/staging/rtl8192u/r8192U_wx.c
> @@ -726,7 +726,7 @@ static int r8192_wx_set_enc_ext(struct net_device *dev,
> idx--;
> group = ext->ext_flags & IW_ENCODE_EXT_GROUP_KEY;
>
> - if ((!group) || (IW_MODE_ADHOC == ieee->iw_mode) || (alg ==
> KEY_TYPE_WEP40)) {
> + if ((!group) || (ieee->iw_mode == IW_MODE_ADHOC) || (alg ==
> KEY_TYPE_WEP40)) {
> if ((ext->key_len == 13) && (alg == KEY_TYPE_WEP40))
> alg = KEY_TYPE_WEP104;
> ieee->pairwise_key_type = alg;
> --
> 2.25.1
Someone already sent this same fix in before you did, sorry.
greg k-h
[PATCH] RDMA/siw: Fix missing check in siw_get_hdr
We should also check the range of opcode after calling
__rdmap_get_opcode() in the else branch to prevent potential
overflow.
Fixes: 8b6a361b8c482 ("rdma/siw: receive path")
Signed-off-by: Dinghao Liu
---
drivers/infiniband/sw/siw/siw_qp_rx.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/infiniband/sw/siw/siw_qp_rx.c
b/drivers/infiniband/sw/siw/siw_qp_rx.c
index 60116f20653c..301e7fe2c61a 100644
--- a/drivers/infiniband/sw/siw/siw_qp_rx.c
+++ b/drivers/infiniband/sw/siw/siw_qp_rx.c
@@ -1072,6 +1072,16 @@ static int siw_get_hdr(struct siw_rx_stream *srx)
siw_dbg_qp(rx_qp(srx), "new header, opcode %u\n", opcode);
} else {
opcode = __rdmap_get_opcode(c_hdr);
+
+ if (opcode > RDMAP_TERMINATE) {
+ pr_warn("siw: received unknown packet type %u\n",
+ opcode);
+
+ siw_init_terminate(rx_qp(srx), TERM_ERROR_LAYER_RDMAP,
+ RDMAP_ETYPE_REMOTE_OPERATION,
+ RDMAP_ECODE_OPCODE, 0);
+ return -EINVAL;
+ }
}
set_rx_fpdu_context(qp, opcode);
frx = qp->rx_fpdu;
--
2.17.1
Re: [PATCH 0/3] drm/ttm: constify static vm_operations_structs
Am 23.02.21 um 18:31 schrieb Alex Deucher: On Wed, Feb 10, 2021 at 8:14 AM Daniel Vetter wrote: On Wed, Feb 10, 2021 at 08:45:56AM +0100, Christian König wrote: Reviewed-by: Christian König for the series. Smash it into -misc? @Christian Koenig did these ever land? I don't see them in drm-misc. I've just pushed them to drm-misc-next. Sorry for the delay, totally forgot about them. Christian. Alex -Daniel Am 10.02.21 um 00:48 schrieb Rikard Falkeborn: Constify a few static vm_operations_struct that are never modified. Their only usage is to assign their address to the vm_ops field in the vm_area_struct, which is a pointer to const vm_operations_struct. Make them const to allow the compiler to put them in read-only memory. With this series applied, all static struct vm_operations_struct in the kernel tree are const. Rikard Falkeborn (3): drm/amdgpu/ttm: constify static vm_operations_struct drm/radeon/ttm: constify static vm_operations_struct drm/nouveau/ttm: constify static vm_operations_struct drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +- drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7C9d730e56efe54d3215ee08d8d820d642%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637496982837619645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=b4UU8bzeX%2Ba1VfObe8mta7fwtjVv%2F1wo4%2FPVuGZFW8Q%3Dreserved=0 ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=04%7C01%7Cchristian.koenig%40amd.com%7C9d730e56efe54d3215ee08d8d820d642%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637496982837629638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=RKJh6p%2BTxaD0lH6M%2B0s3nah3tBatRFqoTvy3Mh7Lz5M%3Dreserved=0
[PATCH] KVM: Documentation: rectify rst markup in kvm_run->flags
Commit c32b1b896d2a ("KVM: X86: Add the Document for
KVM_CAP_X86_BUS_LOCK_EXIT") added a new flag in kvm_run->flags
documentation, and caused warning in make htmldocs:
Documentation/virt/kvm/api.rst:5004: WARNING: Unexpected indentation
Documentation/virt/kvm/api.rst:5004: WARNING: Inline emphasis start-string
without end-string
Fix this rst markup issue.
Signed-off-by: Chenyi Qiang
---
Documentation/virt/kvm/api.rst | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index aed52b0fc16e..0717bf523034 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -5000,7 +5000,8 @@ local APIC is not used.
__u16 flags;
More architecture-specific flags detailing state of the VCPU that may
-affect the device's behavior. Current defined flags:
+affect the device's behavior. Current defined flags::
+
/* x86, set if the VCPU is in system management mode */
#define KVM_RUN_X86_SMM (1 << 0)
/* x86, set if bus lock detected in VM */
--
2.17.1
Re: [PATCH 8/9] arm64: dts: qcom: sc7280: Add AOSS QMP node
On 2021-02-26 01:11, Stephen Boyd wrote:
Quoting Sai Prakash Ranjan (2021-02-25 01:30:24)
Add a DT node for the AOSS QMP on SC7280 SoC.
Signed-off-by: Sai Prakash Ranjan
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 65c1e0f2fb56..cbd567ccc04e 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
/ {
@@ -368,6 +369,19 @@ pdc: interrupt-controller@b22 {
interrupt-controller;
};
+ aoss_qmp: qmp@c30 {
power-domain-controller@c30? power-controller@c30?
Its an AOSS message RAM and all other SM* SoCs have as qmp@
and the dt binding as well, I see only SM8150 with power-controller,
that should probably be fixed?
+ compatible = "qcom,sc7280-aoss-qmp";
+ reg = <0 0x0c30 0 0x10>;
+ interrupts-extended = < IPCC_CLIENT_AOP
+
IPCC_MPROC_SIGNAL_GLINK_QMP
+
IRQ_TYPE_EDGE_RISING>;
+ mboxes = < IPCC_CLIENT_AOP
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ #clock-cells = <0>;
+ #power-domain-cells = <1>;
+ };
+
spmi_bus: qcom,spmi@c44 {
Ick, should be spmi@
Not introduced by this patch but I'll pass on the comment.
compatible = "qcom,spmi-pmic-arb";
reg = <0 0x0c44 0 0x1100>,
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] radeon: ERROR: space prohibited before that ','
Well coding style clean ups are usually welcome, but not necessarily one
by one.
We can probably merge this if you clean up all checkpatch.pl warnings in
the whole file.
Christian.
Am 26.02.21 um 07:05 schrieb wangjingyu:
drm_property_create_range(rdev->ddev, 0 , "coherent", 0, 1);
Signed-off-by: wangjingyu
---
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 3a6fedad002d..439d1b3e87d8 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1396,7 +1396,7 @@ static int radeon_modeset_create_props(struct
radeon_device *rdev)
if (rdev->is_atom_bios) {
rdev->mode_info.coherent_mode_property =
- drm_property_create_range(rdev->ddev, 0 , "coherent",
0, 1);
+ drm_property_create_range(rdev->ddev, 0, "coherent", 0,
1);
if (!rdev->mode_info.coherent_mode_property)
return -ENOMEM;
}
Re: [PATCH] linux/compiler-clang.h: define HAVE_BUILTIN_BSWAP*
On Thu, Feb 25, 2021 at 05:45:09PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Fixes: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
> exclusive")
> Signed-off-by: Arnd Bergmann
> ---
> include/linux/compiler-clang.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index 6478bff6fcc2..bbfa9ff6a2ec 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -33,6 +33,16 @@
> #define __no_sanitize_thread
> #endif
>
> +/*
> + * sparse (__CHECKER__) pretends to be gcc, but can't do constant
> + * folding in __builtin_bswap*() (yet), so don't set these for it.
> + */
This is not true anymore since 2017. Also, a much recent version of
Sparse is needed for _Generic(), for example).
Can you remove the comment and the test for __CHECKER__?
Best regards,
-- Luc
[PATCH] Input: elan_i2c - Reduce the resume time for new devices
Remove elan_initilize() function at resume state,
for Voxel, Delbin, Magple, Bobba and new devices.
Signed-off-by: Jingle Wu
---
drivers/input/mouse/elan_i2c.h | 5 +++
drivers/input/mouse/elan_i2c_core.c | 57 +++--
2 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/drivers/input/mouse/elan_i2c.h b/drivers/input/mouse/elan_i2c.h
index d5f9cd76eefb..16b795524179 100644
--- a/drivers/input/mouse/elan_i2c.h
+++ b/drivers/input/mouse/elan_i2c.h
@@ -45,6 +45,11 @@
#define ETP_FW_PAGE_SIZE_512 512
#define ETP_FW_SIGNATURE_SIZE 6
+#define ETP_PRODUCT_ID_DELBIN 0x00C2
+#define ETP_PRODUCT_ID_VOXEL 0x00BF
+#define ETP_PRODUCT_ID_MAGPIE 0x0120
+#define ETP_PRODUCT_ID_BOBBA0x0121
+
struct i2c_client;
struct completion;
diff --git a/drivers/input/mouse/elan_i2c_core.c
b/drivers/input/mouse/elan_i2c_core.c
index 0f46e2f6c9e8..e75bbaeaf068 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -55,6 +55,9 @@
#define ETP_MK_DATA_OFFSET 33 /* For high precision reports */
#define ETP_MAX_REPORT_LEN 39
+/* quirks to control the device */
+#define ETP_QUIRK_SET_QUICK_WAKEUP_DEV BIT(0)
+
/* The main device structure */
struct elan_tp_data {
struct i2c_client *client;
@@ -99,8 +102,50 @@ struct elan_tp_data {
boolbaseline_ready;
u8 clickpad;
boolmiddle_button;
+
+ unsigned long quirks; /* Various quirks */
+};
+
+
+static const struct elan_i2c_quirks {
+ __u16 ic_type;
+ __u16 product_id;
+ __u32 quirks;
+} elan_i2c_quirks[] = {
+ { 0x0D, ETP_PRODUCT_ID_DELBIN,
+ ETP_QUIRK_SET_QUICK_WAKEUP_DEV },
+ { 0x10, ETP_PRODUCT_ID_VOXEL,
+ ETP_QUIRK_SET_QUICK_WAKEUP_DEV },
+ { 0x14, ETP_PRODUCT_ID_MAGPIE,
+ ETP_QUIRK_SET_QUICK_WAKEUP_DEV },
+ { 0x14, ETP_PRODUCT_ID_BOBBA,
+ ETP_QUIRK_SET_QUICK_WAKEUP_DEV },
+ { 0, 0 }
};
+/*
+ * elan_i2c_lookup_quirk: return any quirks associated with a elan i2c device
+ * @ic_type: the 16-bit ic type
+ * @product_id: the 16-bit product ID
+ *
+ * Returns: a u32 quirks value.
+ */
+static u32 elan_i2c_lookup_quirk(const u16 ic_type, const u16 product_id)
+{
+ u32 quirks = 0;
+ int n;
+
+ for (n = 0; elan_i2c_quirks[n].ic_type; n++)
+ if (elan_i2c_quirks[n].ic_type == ic_type &&
+ (elan_i2c_quirks[n].product_id == product_id))
+ quirks = elan_i2c_quirks[n].quirks;
+
+ if ((ic_type >= 0x0D) && (product_id >= 0x123))
+ quirks |= ETP_QUIRK_SET_QUICK_WAKEUP_DEV;
+
+ return quirks;
+}
+
static int elan_get_fwinfo(u16 ic_type, u8 iap_version, u16 *validpage_count,
u32 *signature_address, u16 *page_size)
{
@@ -273,10 +318,12 @@ static int __elan_initialize(struct elan_tp_data *data)
bool woken_up = false;
int error;
- error = data->ops->initialize(client);
- if (error) {
- dev_err(>dev, "device initialize failed: %d\n", error);
- return error;
+ if (!(data->quirks & ETP_QUIRK_SET_QUICK_WAKEUP_DEV)) {
+ error = data->ops->initialize(client);
+ if (error) {
+ dev_err(>dev, "device initialize failed: %d\n",
error);
+ return error;
+ }
}
error = elan_query_product(data);
@@ -366,6 +413,8 @@ static int elan_query_device_info(struct elan_tp_data *data)
if (error)
return error;
+ data->quirks = elan_i2c_lookup_quirk(data->ic_type, data->product_id);
+
error = elan_get_fwinfo(data->ic_type, data->iap_version,
>fw_validpage_count,
>fw_signature_address,
--
2.17.1
[PATCH net] net: phy: fix save wrong speed and duplex problem if autoneg is on
From: Guangbin Huang
If phy uses generic driver and autoneg is on, enter command
"ethtool -s eth0 speed 50" will not change phy speed actually, but
command "ethtool eth0" shows speed is 50Mb/s because phydev->speed
has been set to 50 and no update later.
And duplex setting has same problem too.
However, if autoneg is on, phy only changes speed and duplex according to
phydev->advertising, but not phydev->speed and phydev->duplex. So in this
case, phydev->speed and phydev->duplex don't need to be set in function
phy_ethtool_ksettings_set() if autoneg is on.
Signed-off-by: Guangbin Huang
Signed-off-by: Huazhong Tan
---
drivers/net/phy/phy.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 1be07e4..fc2e7cb 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -276,14 +276,16 @@ int phy_ethtool_ksettings_set(struct phy_device *phydev,
phydev->autoneg = autoneg;
- phydev->speed = speed;
+ if (autoneg == AUTONEG_DISABLE) {
+ phydev->speed = speed;
+ phydev->duplex = duplex;
+ }
linkmode_copy(phydev->advertising, advertising);
linkmode_mod_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
phydev->advertising, autoneg == AUTONEG_ENABLE);
- phydev->duplex = duplex;
phydev->master_slave_set = cmd->base.master_slave_cfg;
phydev->mdix_ctrl = cmd->base.eth_tp_mdix_ctrl;
--
2.7.4
Re: general protection fault in kvm_hv_irq_routing_update
On Fri, 26 Feb 2021 at 15:01, syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:a99163e9 Merge tag 'devicetree-for-5.12' of git://git.kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=12d72682d0
> kernel config: https://syzkaller.appspot.com/x/.config?x=7a875029a795d230
> dashboard link: https://syzkaller.appspot.com/bug?extid=6987f3b2dbd9eda95f12
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12faef12d0
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=163342ccd0
>
> The issue was bisected to:
>
> commit 8f014550dfb114cc7f42a517d20d2cf887a0b771
> Author: Vitaly Kuznetsov
> Date: Tue Jan 26 13:48:14 2021 +
>
> KVM: x86: hyper-v: Make Hyper-V emulation enablement conditional
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10df16a8d0
> final oops: https://syzkaller.appspot.com/x/report.txt?x=12df16a8d0
> console output: https://syzkaller.appspot.com/x/log.txt?x=14df16a8d0
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+6987f3b2dbd9eda95...@syzkaller.appspotmail.com
> Fixes: 8f014550dfb1 ("KVM: x86: hyper-v: Make Hyper-V emulation enablement
> conditional")
>
> L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and
> https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for
> details.
> general protection fault, probably for non-canonical address
> 0xdc28: [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0140-0x0147]
> CPU: 1 PID: 8370 Comm: syz-executor859 Not tainted 5.11.0-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:synic_get arch/x86/kvm/hyperv.c:165 [inline]
> RIP: 0010:kvm_hv_set_sint_gsi arch/x86/kvm/hyperv.c:475 [inline]
> RIP: 0010:kvm_hv_irq_routing_update+0x230/0x460 arch/x86/kvm/hyperv.c:498
> Code: 80 19 00 00 48 89 f8 48 c1 e8 03 80 3c 28 00 0f 85 ff 01 00 00 4d 8b ad
> 80 19 00 00 49 8d bd 40 01 00 00 48 89 f8 48 c1 e8 03 <0f> b6 04 28 84 c0 74
> 06 0f 8e d2 01 00 00 45 0f b6 bd 40 01 00 00
> RSP: 0018:c90001b3fac0 EFLAGS: 00010206
> RAX: 0028 RBX: 888012df5900 RCX:
> RDX: 888022193780 RSI: 81174d43 RDI: 0140
> RBP: dc00 R08: R09: c900018819eb
> R10: 81170f3e R11: R12:
> R13: R14: R15: 0001
> FS: 00a73300() GS:8880b9d0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 557e8c876888 CR3: 13c0b000 CR4: 001526e0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0400
> Call Trace:
> kvm_set_irq_routing+0x69b/0x940 arch/x86/kvm/../../../virt/kvm/irqchip.c:223
> kvm_vm_ioctl+0x12d0/0x2800 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3959
> vfs_ioctl fs/ioctl.c:48 [inline]
> __do_sys_ioctl fs/ioctl.c:753 [inline]
> __se_sys_ioctl fs/ioctl.c:739 [inline]
> __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x43ef29
> Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48
> 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73
> 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:7ffe391eb808 EFLAGS: 0246 ORIG_RAX: 0010
> RAX: ffda RBX: 00400488 RCX: 0043ef29
> RDX: 2140 RSI: 4008ae6a RDI: 0004
> RBP: 00402f10 R08: 00400488 R09: 00400488
> R10: 00400488 R11: 0246 R12: 00402fa0
> R13: R14: 004ac018 R15: 00400488
> Modules linked in:
> ---[ end trace 2aa75ec1dd148710 ]---
> RIP: 0010:synic_get arch/x86/kvm/hyperv.c:165 [inline]
Missing check to_hv_vcpu(vcpu) in synic_get(), I will fix it.
> RIP: 0010:kvm_hv_set_sint_gsi arch/x86/kvm/hyperv.c:475 [inline]
> RIP: 0010:kvm_hv_irq_routing_update+0x230/0x460 arch/x86/kvm/hyperv.c:498
> Code: 80 19 00 00 48 89 f8 48 c1 e8 03 80 3c 28 00 0f 85 ff 01 00 00 4d 8b ad
> 80 19 00 00 49 8d bd 40 01 00 00 48 89 f8 48 c1 e8 03 <0f> b6 04 28 84 c0 74
> 06 0f 8e d2 01 00 00 45 0f b6 bd 40 01 00 00
> RSP: 0018:c90001b3fac0 EFLAGS: 00010206
> RAX: 0028 RBX: 888012df5900 RCX:
> RDX: 888022193780 RSI: 81174d43 RDI: 0140
> RBP: dc00 R08: R09: c900018819eb
> R10: 81170f3e R11: R12:
> R13: R14: R15: 0001
> FS: 00a73300() GS:8880b9d0()
[PATCH v25 3/4] scsi: ufs: Prepare HPB read for cached sub-region
This patch changes the read I/O to the HPB read I/O.
If the logical address of the read I/O belongs to active sub-region, the
HPB driver modifies the read I/O command to HPB read. It modifies the UPIU
command of UFS instead of modifying the existing SCSI command.
In the HPB version 1.0, the maximum read I/O size that can be converted to
HPB read is 4KB.
The dirty map of the active sub-region prevents an incorrect HPB read that
has stale physical page number which is updated by previous write I/O.
Reviewed-by: Can Guo
Reviewed-by: Bart Van Assche
Acked-by: Avri Altman
Tested-by: Bean Huo
Signed-off-by: Daejun Park
---
drivers/scsi/ufs/ufshcd.c | 2 +
drivers/scsi/ufs/ufshpb.c | 253 +-
drivers/scsi/ufs/ufshpb.h | 2 +
3 files changed, 254 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 5852ff44c3cc..851c01a26207 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2656,6 +2656,8 @@ static int ufshcd_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *cmd)
lrbp->req_abort_skip = false;
+ ufshpb_prep(hba, lrbp);
+
ufshcd_comp_scsi_upiu(hba, lrbp);
err = ufshcd_map_sg(hba, lrbp);
diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index 8abadb0e010a..c75a6816a03f 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -46,6 +46,29 @@ static void ufshpb_set_state(struct ufshpb_lu *hpb, int
state)
atomic_set(>hpb_state, state);
}
+static int ufshpb_is_valid_srgn(struct ufshpb_region *rgn,
+ struct ufshpb_subregion *srgn)
+{
+ return rgn->rgn_state != HPB_RGN_INACTIVE &&
+ srgn->srgn_state == HPB_SRGN_VALID;
+}
+
+static bool ufshpb_is_read_cmd(struct scsi_cmnd *cmd)
+{
+ return req_op(cmd->request) == REQ_OP_READ;
+}
+
+static bool ufshpb_is_write_or_discard_cmd(struct scsi_cmnd *cmd)
+{
+ return op_is_write(req_op(cmd->request)) ||
+ op_is_discard(req_op(cmd->request));
+}
+
+static bool ufshpb_is_support_chunk(int transfer_len)
+{
+ return transfer_len <= HPB_MULTI_CHUNK_HIGH;
+}
+
static bool ufshpb_is_general_lun(int lun)
{
return lun < UFS_UPIU_MAX_UNIT_NUM_ID;
@@ -80,8 +103,8 @@ static void ufshpb_kick_map_work(struct ufshpb_lu *hpb)
}
static bool ufshpb_is_hpb_rsp_valid(struct ufs_hba *hba,
-struct ufshcd_lrb *lrbp,
-struct utp_hpb_rsp *rsp_field)
+ struct ufshcd_lrb *lrbp,
+ struct utp_hpb_rsp *rsp_field)
{
/* Check HPB_UPDATE_ALERT */
if (!(lrbp->ucd_rsp_ptr->header.dword_2 &
@@ -107,6 +130,230 @@ static bool ufshpb_is_hpb_rsp_valid(struct ufs_hba *hba,
return true;
}
+static void ufshpb_set_ppn_dirty(struct ufshpb_lu *hpb, int rgn_idx,
+int srgn_idx, int srgn_offset, int cnt)
+{
+ struct ufshpb_region *rgn;
+ struct ufshpb_subregion *srgn;
+ int set_bit_len;
+ int bitmap_len;
+
+next_srgn:
+ rgn = hpb->rgn_tbl + rgn_idx;
+ srgn = rgn->srgn_tbl + srgn_idx;
+
+ if (likely(!srgn->is_last))
+ bitmap_len = hpb->entries_per_srgn;
+ else
+ bitmap_len = hpb->last_srgn_entries;
+
+ if ((srgn_offset + cnt) > bitmap_len)
+ set_bit_len = bitmap_len - srgn_offset;
+ else
+ set_bit_len = cnt;
+
+ if (rgn->rgn_state != HPB_RGN_INACTIVE &&
+ srgn->srgn_state == HPB_SRGN_VALID)
+ bitmap_set(srgn->mctx->ppn_dirty, srgn_offset, set_bit_len);
+
+ srgn_offset = 0;
+ if (++srgn_idx == hpb->srgns_per_rgn) {
+ srgn_idx = 0;
+ rgn_idx++;
+ }
+
+ cnt -= set_bit_len;
+ if (cnt > 0)
+ goto next_srgn;
+}
+
+static bool ufshpb_test_ppn_dirty(struct ufshpb_lu *hpb, int rgn_idx,
+ int srgn_idx, int srgn_offset, int cnt)
+{
+ struct ufshpb_region *rgn;
+ struct ufshpb_subregion *srgn;
+ int bitmap_len;
+ int bit_len;
+
+next_srgn:
+ rgn = hpb->rgn_tbl + rgn_idx;
+ srgn = rgn->srgn_tbl + srgn_idx;
+
+ if (likely(!srgn->is_last))
+ bitmap_len = hpb->entries_per_srgn;
+ else
+ bitmap_len = hpb->last_srgn_entries;
+
+ if (!ufshpb_is_valid_srgn(rgn, srgn))
+ return true;
+
+ /*
+* If the region state is active, mctx must be allocated.
+* In this case, check whether the region is evicted or
+* mctx allcation fail.
+*/
+ if (unlikely(!srgn->mctx)) {
+ dev_err(>sdev_ufs_lu->sdev_dev,
+ "no mctx in region %d subregion %d.\n",
+ srgn->rgn_idx, srgn->srgn_idx);
+ return true;
+ }
[PATCH v25 4/4] scsi: ufs: Add HPB 2.0 support
This patch supports the HPB 2.0. The HPB 2.0 supports read of varying sizes from 4KB to 512KB. In the case of Read (<= 32KB) is supported as single HPB read. In the case of Read (36KB ~ 512KB) is supported by as a combination of write buffer command and HPB read command to deliver more PPN. The write buffer commands may not be issued immediately due to busy tags. To use HPB read more aggressively, the driver can requeue the write buffer command. The requeue threshold is implemented as timeout and can be modified with requeue_timeout_ms entry in sysfs. Signed-off-by: Daejun Park --- Documentation/ABI/testing/sysfs-driver-ufs | 35 +- drivers/scsi/ufs/ufs-sysfs.c | 2 + drivers/scsi/ufs/ufs.h | 3 +- drivers/scsi/ufs/ufshcd.c | 22 +- drivers/scsi/ufs/ufshcd.h | 7 + drivers/scsi/ufs/ufshpb.c | 624 +++-- drivers/scsi/ufs/ufshpb.h | 67 ++- 7 files changed, 681 insertions(+), 79 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index bf5cb8846de1..0017eaf89cbe 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -1253,14 +1253,14 @@ Description:This entry shows the number of HPB pinned regions assigned to The file is read only. -What: /sys/class/scsi_device/*/device/hpb_sysfs/hit_cnt +What: /sys/class/scsi_device/*/device/hpb_stat_sysfs/hit_cnt Date: February 2021 Contact: Daejun Park Description: This entry shows the number of reads that changed to HPB read. The file is read only. -What: /sys/class/scsi_device/*/device/hpb_sysfs/miss_cnt +What: /sys/class/scsi_device/*/device/hpb_stat_sysfs/miss_cnt Date: February 2021 Contact: Daejun Park Description: This entry shows the number of reads that cannot be changed to @@ -1268,7 +1268,7 @@ Description: This entry shows the number of reads that cannot be changed to The file is read only. -What: /sys/class/scsi_device/*/device/hpb_sysfs/rb_noti_cnt +What: /sys/class/scsi_device/*/device/hpb_stat_sysfs/rb_noti_cnt Date: February 2021 Contact: Daejun Park Description: This entry shows the number of response UPIUs that has @@ -1276,7 +1276,7 @@ Description: This entry shows the number of response UPIUs that has The file is read only. -What: /sys/class/scsi_device/*/device/hpb_sysfs/rb_active_cnt +What: /sys/class/scsi_device/*/device/hpb_stat_sysfs/rb_active_cnt Date: February 2021 Contact: Daejun Park Description: This entry shows the number of active sub-regions recommended by @@ -1284,7 +1284,7 @@ Description: This entry shows the number of active sub-regions recommended by The file is read only. -What: /sys/class/scsi_device/*/device/hpb_sysfs/rb_inactive_cnt +What: /sys/class/scsi_device/*/device/hpb_stat_sysfs/rb_inactive_cnt Date: February 2021 Contact: Daejun Park Description: This entry shows the number of inactive regions recommended by @@ -1292,10 +1292,33 @@ Description:This entry shows the number of inactive regions recommended by The file is read only. -What: /sys/class/scsi_device/*/device/hpb_sysfs/map_req_cnt +What: /sys/class/scsi_device/*/device/hpb_stat_sysfs/map_req_cnt Date: February 2021 Contact: Daejun Park Description: This entry shows the number of read buffer commands for activating sub-regions recommended by response UPIUs. The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/requeue_timeout_ms +Date: February 2021 +Contact: Daejun Park +Description: This entry shows the requeue timeout threshold for write buffer + command in ms. This value can be changed by writing proper integer to + this entry. + +What: /sys/bus/platform/drivers/ufshcd/*/attributes/max_data_size_hpb_single_cmd +Date: February 2021 +Contact: Daejun Park +Description: This entry shows the maximum HPB data size for using single HPB + command. + + === + 00h 4KB + 01h 8KB + 02h 12KB + ... + FFh 1024KB + === + + The file is read only. diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c index 2546e7a1ac4f..00fb519406cf 100644 --- a/drivers/scsi/ufs/ufs-sysfs.c +++ b/drivers/scsi/ufs/ufs-sysfs.c @@ -841,6 +841,7 @@ out: \ static DEVICE_ATTR_RO(_name)
Re: [PATCH] dma-buf: heaps: Set VM_PFNMAP in mmap for system and cma heaps
On Fri, Feb 26, 2021 at 5:09 AM John Stultz wrote: > > Per discussion and patches here: > > https://lore.kernel.org/dri-devel/20210223105951.912577-1-daniel.vet...@ffwll.ch/ > > Daniel is planning on making VM_PFNMAP required on dmabufs. > > Thus to avoid the warn_on noise, set the VM_PFNMAP in the > system and cma heap's mmap handler. > > Cc: Daniel Vetter > Cc: Jason Gunthorpe > Cc: Christian Koenig > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Chris Goldsworthy > Cc: Laura Abbott > Cc: Brian Starkey > Cc: Hridya Valsaraju > Cc: Suren Baghdasaryan > Cc: Sandeep Patil > Cc: Daniel Mentz > Cc: Ørjan Eide > Cc: Robin Murphy > Cc: Ezequiel Garcia > Cc: Simon Ser > Cc: James Jones > Cc: linux-me...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: John Stultz System heap uses remap_pfn_range so looks fine, but cma heap inserts pages, and that's not fine for VM_PFNMAP. You need to use vm_insert_pfn or remap_pfn_range or one of the related pfn mapping functions for that too. I think this should splat when you run it. Also note that remap_pfn_range updates the vma flags already correctly for you, so you probably don't want to do that. Also given that both deal with struct page there's a ton of divergence between these two that doesn't make much sense. Maybe could even share the code fully, aside from how you allocate the struct pages. -Daniel > --- > drivers/dma-buf/heaps/cma_heap.c| 1 + > drivers/dma-buf/heaps/system_heap.c | 4 +++- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/heaps/cma_heap.c > b/drivers/dma-buf/heaps/cma_heap.c > index 364fc2f3e499..34bc3987f942 100644 > --- a/drivers/dma-buf/heaps/cma_heap.c > +++ b/drivers/dma-buf/heaps/cma_heap.c > @@ -185,6 +185,7 @@ static int cma_heap_mmap(struct dma_buf *dmabuf, struct > vm_area_struct *vma) > > vma->vm_ops = _heap_vm_ops; > vma->vm_private_data = buffer; > + vma->vm_flags |= VM_PFNMAP; > > return 0; > } > diff --git a/drivers/dma-buf/heaps/system_heap.c > b/drivers/dma-buf/heaps/system_heap.c > index 3548b20cb98c..8995e3cbfcaf 100644 > --- a/drivers/dma-buf/heaps/system_heap.c > +++ b/drivers/dma-buf/heaps/system_heap.c > @@ -228,8 +228,10 @@ static int system_heap_mmap(struct dma_buf *dmabuf, > struct vm_area_struct *vma) > return ret; > addr += PAGE_SIZE; > if (addr >= vma->vm_end) > - return 0; > + break; > } > + > + vma->vm_flags |= VM_PFNMAP; > return 0; > } > > -- > 2.25.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v25 2/4] scsi: ufs: L2P map management for HPB read
This is a patch for managing L2P map in HPB module.
The HPB divides logical addresses into several regions. A region consists
of several sub-regions. The sub-region is a basic unit where L2P mapping is
managed. The driver loads L2P mapping data of each sub-region. The loaded
sub-region is called active-state. The HPB driver unloads L2P mapping data
as region unit. The unloaded region is called inactive-state.
Sub-region/region candidates to be loaded and unloaded are delivered from
the UFS device. The UFS device delivers the recommended active sub-region
and inactivate region to the driver using sensedata.
The HPB module performs L2P mapping management on the host through the
delivered information.
A pinned region is a pre-set regions on the UFS device that is always
activate-state.
The data structure for map data request and L2P map uses mempool API,
minimizing allocation overhead while avoiding static allocation.
The mininum size of the memory pool used in the HPB is implemented
as a module parameter, so that it can be configurable by the user.
To gurantee a minimum memory pool size of 4MB: ufshpb_host_map_kbytes=4096
The map_work manages active/inactive by 2 "to-do" lists.
Each hpb lun maintains 2 "to-do" lists:
hpb->lh_inact_rgn - regions to be inactivated, and
hpb->lh_act_srgn - subregions to be activated
Those lists are maintained on IO completion.
Reviewed-by: Bart Van Assche
Reviewed-by: Can Guo
Acked-by: Avri Altman
Tested-by: Bean Huo
Signed-off-by: Daejun Park
---
drivers/scsi/ufs/ufs.h| 36 ++
drivers/scsi/ufs/ufshcd.c |4 +
drivers/scsi/ufs/ufshpb.c | 1091 -
drivers/scsi/ufs/ufshpb.h | 65 +++
4 files changed, 1181 insertions(+), 15 deletions(-)
diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index 65563635e20e..957763db1006 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -472,6 +472,41 @@ struct utp_cmd_rsp {
u8 sense_data[UFS_SENSE_SIZE];
};
+struct ufshpb_active_field {
+ __be16 active_rgn;
+ __be16 active_srgn;
+};
+#define HPB_ACT_FIELD_SIZE 4
+
+/**
+ * struct utp_hpb_rsp - Response UPIU structure
+ * @residual_transfer_count: Residual transfer count DW-3
+ * @reserved1: Reserved double words DW-4 to DW-7
+ * @sense_data_len: Sense data length DW-8 U16
+ * @desc_type: Descriptor type of sense data
+ * @additional_len: Additional length of sense data
+ * @hpb_op: HPB operation type
+ * @lun: LUN of response UPIU
+ * @active_rgn_cnt: Active region count
+ * @inactive_rgn_cnt: Inactive region count
+ * @hpb_active_field: Recommended to read HPB region and subregion
+ * @hpb_inactive_field: To be inactivated HPB region and subregion
+ */
+struct utp_hpb_rsp {
+ __be32 residual_transfer_count;
+ __be32 reserved1[4];
+ __be16 sense_data_len;
+ u8 desc_type;
+ u8 additional_len;
+ u8 hpb_op;
+ u8 lun;
+ u8 active_rgn_cnt;
+ u8 inactive_rgn_cnt;
+ struct ufshpb_active_field hpb_active_field[2];
+ __be16 hpb_inactive_field[2];
+};
+#define UTP_HPB_RSP_SIZE 40
+
/**
* struct utp_upiu_rsp - general upiu response structure
* @header: UPIU header structure DW-0 to DW-2
@@ -482,6 +517,7 @@ struct utp_upiu_rsp {
struct utp_upiu_header header;
union {
struct utp_cmd_rsp sr;
+ struct utp_hpb_rsp hr;
struct utp_upiu_query qr;
};
};
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 49b3d5d24fa6..5852ff44c3cc 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5021,6 +5021,9 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct
ufshcd_lrb *lrbp)
*/
pm_runtime_get_noresume(hba->dev);
}
+
+ if (scsi_status == SAM_STAT_GOOD)
+ ufshpb_rsp_upiu(hba, lrbp);
break;
case UPIU_TRANSACTION_REJECT_UPIU:
/* TODO: handle Reject UPIU Response */
@@ -9221,6 +9224,7 @@ EXPORT_SYMBOL(ufshcd_shutdown);
void ufshcd_remove(struct ufs_hba *hba)
{
ufs_bsg_remove(hba);
+ ufshpb_remove(hba);
ufs_sysfs_remove_nodes(hba->dev);
blk_cleanup_queue(hba->tmf_queue);
blk_mq_free_tag_set(>tmf_tag_set);
diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index 1a72f6541510..8abadb0e010a 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -16,6 +16,16 @@
#include "ufshpb.h"
#include "../sd.h"
+/* memory management */
+static struct kmem_cache *ufshpb_mctx_cache;
+static mempool_t *ufshpb_mctx_pool;
+static mempool_t *ufshpb_page_pool;
+/* A cache size of 2MB can cache ppn in the 1GB range. */
+static unsigned int ufshpb_host_map_kbytes = 2048;
+static int tot_active_srgn_pages;
+
+static struct workqueue_struct *ufshpb_wq;
+
bool
[PATCH v25 1/4] scsi: ufs: Introduce HPB feature
This is a patch for the HPB initialization and adds HPB function calls to UFS core driver. NAND flash-based storage devices, including UFS, have mechanisms to translate logical addresses of IO requests to the corresponding physical addresses of the flash storage. In UFS, Logical-address-to-Physical-address (L2P) map data, which is required to identify the physical address for the requested IOs, can only be partially stored in SRAM from NAND flash. Due to this partial loading, accessing the flash address area where the L2P information for that address is not loaded in the SRAM can result in serious performance degradation. The basic concept of HPB is to cache L2P mapping entries in host system memory so that both physical block address (PBA) and logical block address (LBA) can be delivered in HPB read command. The HPB READ command allows to read data faster than a read command in UFS since it provides the physical address (HPB Entry) of the desired logical block in addition to its logical address. The UFS device can access the physical block in NAND directly without searching and uploading L2P mapping table. This improves read performance because the NAND read operation for uploading L2P mapping table is removed. In HPB initialization, the host checks if the UFS device supports HPB feature and retrieves related device capabilities. Then, some HPB parameters are configured in the device. We measured the total start-up time of popular applications and observed the difference by enabling the HPB. Popular applications are 12 game apps and 24 non-game apps. Each target applications were launched in order. The cycle consists of running 36 applications in sequence. We repeated the cycle for observing performance improvement by L2P mapping cache hit in HPB. The Following is experiment environment: - kernel version: 4.4.0 - RAM: 8GB - UFS 2.1 (64GB) Result: +---+--+--+---+ | cycle | baseline | with HPB | diff | +---+--+--+---+ | 1 | 272.4| 264.9| -7.5 | | 2 | 250.4| 248.2| -2.2 | | 3 | 226.2| 215.6| -10.6 | | 4 | 230.6| 214.8| -15.8 | | 5 | 232.0| 218.1| -13.9 | | 6 | 231.9| 212.6| -19.3 | +---+--+--+---+ We also measured HPB performance using iozone. Here is my iozone script: iozone -r 4k -+n -i2 -ecI -t 16 -l 16 -u 16 -s $IO_RANGE/16 -F mnt/tmp_1 mnt/tmp_2 mnt/tmp_3 mnt/tmp_4 mnt/tmp_5 mnt/tmp_6 mnt/tmp_7 mnt/tmp_8 mnt/tmp_9 mnt/tmp_10 mnt/tmp_11 mnt/tmp_12 mnt/tmp_13 mnt/tmp_14 mnt/tmp_15 mnt/tmp_16 Result: +--++-+ | IO range | HPB on | HPB off | +--++-+ | 1 GB | 294.8 | 300.87 | | 4 GB | 293.51 | 179.35 | | 8 GB | 294.85 | 162.52 | | 16 GB | 293.45 | 156.26 | | 32 GB | 277.4 | 153.25 | +--++-+ Reviewed-by: Bart Van Assche Reviewed-by: Can Guo Acked-by: Avri Altman Tested-by: Bean Huo Reported-by: kernel test robot Signed-off-by: Daejun Park --- Documentation/ABI/testing/sysfs-driver-ufs | 127 + drivers/scsi/ufs/Kconfig | 9 + drivers/scsi/ufs/Makefile | 1 + drivers/scsi/ufs/ufs-sysfs.c | 18 + drivers/scsi/ufs/ufs.h | 15 + drivers/scsi/ufs/ufshcd.c | 49 ++ drivers/scsi/ufs/ufshcd.h | 22 + drivers/scsi/ufs/ufshpb.c | 569 + drivers/scsi/ufs/ufshpb.h | 166 ++ 9 files changed, 976 insertions(+) create mode 100644 drivers/scsi/ufs/ufshpb.c create mode 100644 drivers/scsi/ufs/ufshpb.h diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index d1bc23cb6a9d..bf5cb8846de1 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -1172,3 +1172,130 @@ Description:This node is used to set or display whether UFS WriteBooster is (if the platform supports UFSHCD_CAP_CLK_SCALING). For a platform that doesn't support UFSHCD_CAP_CLK_SCALING, we can disable/enable WriteBooster through this sysfs node. + +What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_version +Date: February 2021 +Contact: Daejun Park +Description: This entry shows the HPB specification version. + The full information about the descriptor could be found at UFS + HPB (Host Performance Booster) Extension specifications. + Example: version 1.2.3 = 0123h + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_control +Date: February 2021 +Contact: Daejun Park +Description: This entry shows an indication of the HPB control mode. + 00h: Host control mode + 01h: Device control mode + +
Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)
On Fri, 2021-02-19 at 00:12 -0800, Jose R Rodriguez wrote: > On Tue, 2021-02-16 at 21:02 +0100, Edward Shishkin wrote: > > > > > > On 02/16/2021 04:56 PM, Jose R Rodriguez wrote: > > > On Mon, 2021-02-08 at 17:03 +0100, Edward Shishkin wrote: > > > > On 02/08/2021 01:54 PM, Metztli Information Technology wrote: > > > > > On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin < > > > > > edward.shish...@gmail.com> wrote: > > > > > > > > > > > > On 12/23/2020 05:01 PM, Metztli Information Technology wrote: > > > > > > > Niltze [Ð—Ð´Ñ€Ð°Ð²Ñ Ñ‚Ð²ÑƒÐ¹Ñ‚Ðµ : Hello], Ed- > > > > > > > > > > > > > > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as > > > > > > > usual -- to generate a kernel component for my Debian-Installer > > > > > > > (d-i). > > > > > > > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5- > > > > > > > unstable. > > > > > > > > > > > > > > Once I built the proper reiser4progs-2.0.4.tar.gz and generated > > > > > > > one set of components for d-i I built the d-i image. > > > > > > > > > > > > > > Fact is, the installer throws an error in *both* bare metal and > > > > > > > VirtualBox 6.1.16: > > > > > > > ... > > > > > > > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap- > > > > > > > base' selected > > > > > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap -- > > > > > > > components=main --debian-installer --resolve-deps -- > > > > > > > keyring=/usr/share/keyrings/archive.gpg buster /target > > > > > > > http://deb.debian.org/debian/ > > > > > > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: > > > > > > > /target/test-exec: Invalid argument > > > > > > > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not > > > > > > > supported for file /test-exec (pid: 10077 comm: debootstrap) > > > > > > > Dec 22 20:19:56 debootstrap: E: NOEXEC > > > > > > > Dec 22 20:19:56 debootstrap: EF: Cannot install into target > > > > > > > '/target' mounted with noexec or nodev > > > > > > > Dec 22 20:20:12 base-installer: error: exiting on error base- > > > > > > > installer/debootstrap-failed > > > > > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring > > > > > > > 'bootstrap-base' failed with error code 1 > > > > > > > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item > > > > > > > 'bootstrap-base' failed. > > > > > > > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the > > > > > > > package description for brltty-udeb > > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > Apparently, d-i [Debian-installer] complains about being unable > > > > > > > to set the test file executable and causes the error when 1 is > > > > > > > returned. > > > > > > > Notwithstanding, I manually verified that I am able to touch a > > > > > > > file and set it +x executable. > > > > > > > > > > > > > > Furthermore, tricking the function return value to 0 I am able > > > > > > > to make d-i continue with the latest SFRN5 installation (see > > > > > > > [*trick*] below); yet, subsequently halts again with > > > > > > > an apparently related error --can not proceed any further. > > > > > > > > > > > > > > Digging deeper with dmesg, we can see that apparently it is the > > > > > > > kernel which cannot 'read' properly. Please find a partial > > > > > > > dmesg log with relevant output > > > > > > > from an attempt on my physical development machine. > > > > > > > ... > > > > > > > [ 508.614488] Loading Reiser4 (Software Framework Release: > > > > > > > 5.1.3). See reiser4.wiki.kernel.org for a description of > > > > > > > Reiser4. > > > > > > > [ 508.661951] SGI XFS with ACLs, security attributes, > > > > > > > realtime, quota, no debug enabled > > > > > > > [ 509.326270] device-mapper: uevent: version 1.0.3 > > > > > > > [ 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) > > > > > > > initialised: dm-de...@redhat.com > > > > > > > [ 509.902828] sda: sda1 sda2 sda3 sda4 sda5 sda6 > > > > > > > [ 509.915300] sdb: sdb1 sdb2 sdb3 > > > > > > > [ 511.973360] sdb: sdb1 sdb2 sdb3 > > > > > > > [ 627.525371] Adding 9765884k swap on /dev/sda3. Priority:-2 > > > > > > > extents:1 across:9765884k FS > > > > > > > [ 636.240812] reiser4[mount(9430)]: reiser4_register_subvol > > > > > > > (fs/reiser4/init_volume.c:222)[edward-1932]: > > > > > > > [ 636.240812] NOTICE: brick /dev/sda6 has been registered > > > > > > > [ 636.243003] reiser4 (sda6): found disk format 5.1.3. > > > > > > > [ 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction > > > > > > > Model. > > > > > > > [ 643.759980] reiser4: brick /dev/sda6 activated > > > > > > > [ 643.788537] EXT4-fs (sda1): mounting ext2 file system using > > > > > > > the ext4 subsystem > > > > > > > [ 643.813474] EXT4-fs (sda1): mounted filesystem without > > > > > > > journal. Opts: (null) > > > > > > > [ 643.813488] ext2 filesystem being mounted at /target/boot > > > > > > > supports timestamps until 2038 (0x7fff) > > > > > > > [ 648.168730] kernel
Re: [PATCH v14 02/11] x86: kdump: make the lower bound of crash kernel reservation consistent
On 2021/2/25 23:44, Baoquan He wrote:
> On 02/25/21 at 02:42pm, Catalin Marinas wrote:
>> On Thu, Feb 25, 2021 at 03:08:46PM +0800, Baoquan He wrote:
>>> On 02/24/21 at 02:35pm, Catalin Marinas wrote:
On Sat, Jan 30, 2021 at 03:10:16PM +0800, Chen Zhou wrote:
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index da769845597d..27470479e4a3 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -439,7 +439,8 @@ static int __init reserve_crashkernel_low(void)
> return 0;
> }
>
> - low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0,
> CRASH_ADDR_LOW_MAX);
> + low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, CRASH_ALIGN,
> + CRASH_ADDR_LOW_MAX);
> if (!low_base) {
> pr_err("Cannot reserve %ldMB crashkernel low memory, please try
> smaller size.\n",
> (unsigned long)(low_size >> 20));
Is there any reason why the lower bound can't be 0 in all low cases
here? (Sorry if it's been already discussed, I lost track)
>>> Seems like a good question.
>>>
>>> This reserve_crashkernel_low(), paired with reserve_crashkernel_high(), is
>>> used to reserve memory under 4G so that kdump kernel owns memory for dma
>>> buffer allocation. In that case, kernel usually is loaded in high
>>> memory. In x86_64, kernel loading need be aligned to 16M because of
>>> CONFIG_PHYSICAL_START, please see commit 32105f7fd8faa7b ("x86: find
>>> offset for crashkernel reservation automatically"). But for crashkernel
>>> low memory, there seems to be no reason to ask for 16M alignment, if
>>> it's taken as dma buffer memory.
>>>
>>> So we can make a different alignment for low memory only, e.g 2M. But
>>> 16M alignment consistent with crashkernel,high is also fine to me. The
>>> only affect is smaller alignment can increase the possibility of
>>> crashkernel low reservation.
>> I don't mind the 16M alignment in both low and high base. But is there
>> any reason that the lower bound (third argument) cannot be 0 in both
>> reserve_crashkernel() (the low attempt) and reserve_crashkernel_low()
>> cases? The comment in reserve_crashkernel() only talks about the 4G
>> upper bound but not why we need a 16M lower bound.
> Ah, sorry, I must have mixed this one with the alignment of fixed
> memory region reservation in patch 1 when considering comments.
>
> Hmm, in x86 we always have memory reserved in low 1M, lower bound
> being 0 or 16M (kernel alignment) doesn't make difference on crashkernel
> low reservation. But for crashkernel reservation, the reason should be
> kernel loading alignment being 16M, please see commit 32105f7fd8faa7b
> ("x86: find offset for crashkernel reservation automatically").
Sorry, i didn't mention in the commit message about this.
We discussed about this and the CRASH_ALIGN sounds better, so just use
CRASH_ALIGN.
https://lkml.org/lkml/2020/9/4/82
Thanks,
Chen Zhou
>
> So, for crashkernel low, keeping lower bound as 0 looks good to me, the
> only reason is just as patch log tells. And it can skip the unnecessary
> memblock searching under 16M since it will always fail, even though it
> won't matter much. Or changing it to CRASH_ALIGN as this patch is doing,
> and adding code comment, is also fine to me.
>
> Thanks
> Baoquan
>
> .
>
[PATCH v25 0/4] scsi: ufs: Add Host Performance Booster Support
Changelog: v24 -> v25 1. Change write buffer API for unmap region. 2. Add checking hpb_enable for avoiding unnecessary memory allocation. 3. Change pr_info to dev_info. 4. Change default requeue timeout value for HPB read. 5. Fix wrong offset manipulation on ufshpb_prep_entry. v23 -> v24 1. Fix build error reported by kernel test robot. v22 -> v23 1. Add support compatibility of HPB 1.0. 2. Fix read id for single HPB read command. 3. Fix number of pre-allocated requests for write buffer. 4. Add fast path for response UPIU that has same LUN in sense data. 5. Remove WARN_ON for preventing kernel crash. 7. Fix wrong argument for read buffer command. v21 -> v22 1. Add support processing response UPIU in suspend state. 2. Add support HPB hint from other LU. 3. Add sending write buffer with 0x03 after HPB init. v20 -> v21 1. Add bMAX_DATA_SIZE_FOR_HPB_SINGLE_CMD attr. and fHPBen flag support. v19 -> v20 1. Add documentation for sysfs entries of hpb->stat. 2. Fix read buffer command for under-sized sub-region. 3. Fix wrong condition checking for kick map work. 4. Delete redundant response UPIU checking. 5. Add LUN checking in response UPIU. 6. Fix possible deadlock problem due to runtime PM. 7. Add instant changing of sub-region state from response UPIU. 8. Fix endian problem in prefetched PPN. 9. Add JESD220-3A (HPB v2.0) support. v18 -> 19 1. Fix null pointer error when printing sysfs from non-HPB LU. 2. Apply HPB read opcode in lrbp->cmd->cmnd (from Can Guo's review). 3. Rebase the patch on 5.12/scsi-queue. v17 -> v18 Fix build error which reported by kernel test robot. v16 -> v17 1. Rename hpb_state_lock to rgn_state_lock and move it to corresponding patch. 2. Remove redundant information messages. v15 -> v16 1. Add missed sysfs ABI documentation. v14 -> v15 1. Remove duplicated sysfs ABI entries in documentation. 2. Add experiment result of HPB performance testing with iozone. v13 -> v14 1. Cleanup codes by commentted in Greg's review. 2. Add documentation for sysfs entries (from Greg's review). 3. Add experiment result of HPB performance testing. v12 -> v13 1. Cleanup codes by comments from Can Guo. 2. Add HPB related descriptor/flag/attributes in sysfs. 3. Change base commit from 5.10/scsi-queue to 5.11/scsi-queue. v11 -> v12 1. Fixed to return error value when HPB fails to initialize pinned active region. 2. Fixed to disable HPB feature if HPB fails to allocate essential memory and workqueue. 3. Fixed to change proper sub-region state when region is already evicted. v10 -> v11 Add a newline at end the last line on Kconfig file. v9 -> v10 1. Fixed 64-bit division error 2. Fixed problems commentted in Bart's review. v8 -> v9 1. Change sysfs initialization. 2. Change reading descriptor during HPB initialization 3. Fixed problems commentted in Bart's review. 4. Change base commit from 5.9/scsi-queue to 5.10/scsi-queue. v7 -> v8 Remove wrongly added tags. v6 -> v7 1. Remove UFS feature layer. 2. Cleanup for sparse error. v5 -> v6 Change base commit to b53293fa662e28ae0cdd40828dc641c09f133405 v4 -> v5 Delete unused macro define. v3 -> v4 1. Cleanup. v2 -> v3 1. Add checking input module parameter value. 2. Change base commit from 5.8/scsi-queue to 5.9/scsi-queue. 3. Cleanup for unused variables and label. v1 -> v2 1. Change the full boilerplate text to SPDX style. 2. Adopt dynamic allocation for sub-region data structure. 3. Cleanup. NAND flash memory-based storage devices use Flash Translation Layer (FTL) to translate logical addresses of I/O requests to corresponding flash memory addresses. Mobile storage devices typically have RAM with constrained size, thus lack in memory to keep the whole mapping table. Therefore, mapping tables are partially retrieved from NAND flash on demand, causing random-read performance degradation. To improve random read performance, JESD220-3 (HPB v1.0) proposes HPB (Host Performance Booster) which uses host system memory as a cache for the FTL mapping table. By using HPB, FTL data can be read from host memory faster than from NAND flash memory. The current version only supports the DCM (device control mode). This patch consists of 3 parts to support HPB feature. 1) HPB probe and initialization process 2) READ -> HPB READ using cached map information 3) L2P (logical to physical) map management In the HPB probe and init process, the device information of the UFS is queried. After checking supported features, the data structure for the HPB is initialized according to the device information. A read I/O in the active sub-region where the map is cached is changed to HPB READ by the HPB. The HPB manages the L2P map using information received from the device. For active sub-region, the HPB caches through ufshpb_map request. For the in-active region, the HPB discards the L2P map. When a write I/O occurs in an active sub-region area, associated dirty bitmap checked as dirty for preventing stale read. HPB is shown to have a performance improvement of 58 -
Re: [PATCH] kgdb: Fix to kill breakpoints on initmem after boot
On Fri, Feb 26, 2021 at 12:32:07PM +0530, Sumit Garg wrote: > + stable ML > > On Thu, 25 Feb 2021 at 21:26, Daniel Thompson > wrote: > > > > On Wed, Feb 24, 2021 at 01:46:52PM +0530, Sumit Garg wrote: > > > Currently breakpoints in kernel .init.text section are not handled > > > correctly while allowing to remove them even after corresponding pages > > > have been freed. > > > > > > Fix it via killing .init.text section breakpoints just prior to initmem > > > pages being freed. > > > > > > Suggested-by: Doug Anderson > > > Signed-off-by: Sumit Garg > > > > I saw Andrew has picked this one up. That's ok for me: > > Acked-by: Daniel Thompson > > > > I already enriched kgdbtest to cover this (and they pass) so I guess > > this is also: > > Tested-by: Daniel Thompson > > > > Thanks Daniel. > > > BTW this is not Cc:ed to stable and I do wonder if it crosses the > > threshold to be considered a fix rather than a feature. Normally I > > consider adding safety rails for kgdb to be a new feature but, in this > > case, the problem would easily ensnare an inexperienced developer who is > > doing nothing more than debugging their own driver (assuming they > > correctly marked their probe function as .init) so I think this weighs > > in favour of being a fix. > > > > Makes sense, Cc:ed stable. This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
Re: [PATCH] doc: memcontrol: add description for oom_kill
On Thu 25-02-21 18:12:54, Yang Shi wrote: > When debugging an oom issue, I found the oom_kill counter of memcg is > confusing. At the first glance without checking document, I thought it > just counts for memcg oom, but it turns out it counts both global and > memcg oom. Yes, this is the case indeed. The point of the counter was to count oom victims from the memcg rather than matching that to the source of the oom. Rememeber that this could have been a memcg oom up in the hierarchy as well. Counting victims on the oom origin could be equally confusing because in many cases there would be no victim counted for the above mentioned memcg ooms. > The cgroup v2 documents it, but the description is missed for cgroup v1. > > Signed-off-by: Yang Shi Acked-by: Michal Hocko > --- > Documentation/admin-guide/cgroup-v1/memory.rst | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst > b/Documentation/admin-guide/cgroup-v1/memory.rst > index 0936412e044e..44d5429636e2 100644 > --- a/Documentation/admin-guide/cgroup-v1/memory.rst > +++ b/Documentation/admin-guide/cgroup-v1/memory.rst > @@ -851,6 +851,9 @@ At reading, current status of OOM is shown. > (if 1, oom-killer is disabled) > - under_oom0 or 1 > (if 1, the memory cgroup is under OOM, tasks may be stopped.) > +- oom_kill integer counter > + The number of processes belonging to this cgroup killed by any > + kind of OOM killer. > > 11. Memory Pressure > === > -- > 2.26.2 > -- Michal Hocko SUSE Labs
AW: [PATCH net] net: hsr: add support for EntryForgetTime
On Thu, Feb 25, 2021 at 6:49 PM Jakub Kicinski wrote:
>
> On Wed, 24 Feb 2021 14:55:17 +0100 Andrew Lunn wrote:
> > On Wed, Feb 24, 2021 at 10:46:49AM +0100, Marco Wenzel wrote:
> > > In IEC 62439-3 EntryForgetTime is defined with a value of 400 ms.
> > > When a node does not send any frame within this time, the sequence
> > > number check for can be ignored. This solves communication issues
> > > with Cisco IE 2000 in Redbox mode.
> > >
> > > Fixes: f421436a591d ("net/hsr: Add support for the High-availability
> > > Seamless Redundancy protocol (HSRv0)")
> > > Signed-off-by: Marco Wenzel
> > > Reviewed-by: George McCollister
> > > Tested-by: George McCollister
> >
> > Reviewed-by: Andrew Lunn
>
> Applied, thanks!
Thank you all for supporting me during the submission of my first kernel patch!
Best regards,
Marco
Re: [PATCH] kdb: Get rid of custom debug heap allocator
On Thu, 25 Feb 2021 at 17:49, Daniel Thompson
wrote:
>
> On Thu, Feb 25, 2021 at 04:52:58PM +0530, Sumit Garg wrote:
> > Currently the only user for debug heap is kdbnearsym() which can be
> > modified to rather ask the caller to supply a buffer for symbol name.
> > So do that and modify kdbnearsym() callers to pass a symbol name buffer
> > allocated from stack and hence remove custom debug heap allocator.
>
> Is it really a good idea to increase stack usage this much? I thought
> several architectures will take the debug exception on existing stacks
> (and that these can nest with other exceptions).
>
> The reason I'm concerned is that AFAICT the *purpose* of the current
> heap is to minimise stack usage... and that this has the effect of
> improving debugger robustness when we take exceptions on small shared
> stacks.
>
> The reason I called the heap redundant is that currently it also allows
> us to have nested calls to kdbnearsym() whilst not consuming stack. In
> this case, when I say nested I mean new calls to kdbnearsym() before the
> previous caller has consumed the output rather than truely recursive
> calls.
>
> This is why I think the heap is pointless. In "normal" usage I don't
> think there will never be a nested call to kdbnearsym() so I think a
> single static buffer will suffice.
>
> Technically speaking there is one way that kdbnearsym() can nest but I
> think it is OK for that to be considered out-of-scope.
>
> To explain...
>
> It can nest is if we recursively enter the debugger! Recursive entry
> should never happen, is pretty much untestable and, even if we tested
> it, it is not a bug for an architeture to choose not to support it.
> Nevertheless kgdb/kdb does include logic to handle this if an
> architecture does make it as far are executing the trap. Note that
> even if the architecture does somehow land in the debug trap there's
> a strong chance the system is is too broken to resume (since we just
> took an impossible trap). Therefore kdb will inhibit resume unless the
> operator admits what they are doing won't work before trying to do it.
>
> Therefore I think it is ok for namebuf to be statically allocated and
> the only thing we need do for stability is ensure that kdbnearsym()
> guarantees that namebuf[sizeof(namebuf)-1] == '\0' regardless of the
> symbol length. Thus if by some miracle the system can resume after the
> user has ignored the warning then kdb can't take a bad memory access
> when it tries to print an overwritten symbol name. They see a few
> garbage characters... but since they just told us to do something
> crazy they should be expecting that.
>
Thanks for the detailed explanation. I see the reasoning to not use
stack and it does sound reasonable to use statically allocated namebuf
with a stability guarantee.
>
> Daniel.
>
>
> PS The code to guarantee that if we read past the end of the string
>we will still see a '\'0' before making an invalid memory access
>should be well commented though... because its pretty nasty.
>
Sure, I will add a proper comment.
-Sumit
>
> >
> > This change has been tested using kgdbtest on arm64 which doesn't show
> > any regressions.
> >
> > Suggested-by: Daniel Thompson
> > Signed-off-by: Sumit Garg
> > ---
> > kernel/debug/kdb/kdb_debugger.c | 1 -
> > kernel/debug/kdb/kdb_main.c | 6 +-
> > kernel/debug/kdb/kdb_private.h | 7 +-
> > kernel/debug/kdb/kdb_support.c | 294 +---
> > 4 files changed, 11 insertions(+), 297 deletions(-)
> >
> > diff --git a/kernel/debug/kdb/kdb_debugger.c
> > b/kernel/debug/kdb/kdb_debugger.c
> > index 0220afda3200..e91fc3e4edd5 100644
> > --- a/kernel/debug/kdb/kdb_debugger.c
> > +++ b/kernel/debug/kdb/kdb_debugger.c
> > @@ -140,7 +140,6 @@ int kdb_stub(struct kgdb_state *ks)
> >*/
> > kdb_common_deinit_state();
> > KDB_STATE_CLEAR(PAGER);
> > - kdbnearsym_cleanup();
> > if (error == KDB_CMD_KGDB) {
> > if (KDB_STATE(DOING_KGDB))
> > KDB_STATE_CLEAR(DOING_KGDB);
> > diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
> > index 9d69169582c6..ca525a3e0032 100644
> > --- a/kernel/debug/kdb/kdb_main.c
> > +++ b/kernel/debug/kdb/kdb_main.c
> > @@ -526,6 +526,7 @@ int kdbgetaddrarg(int argc, const char **argv, int
> > *nextarg,
> > char symbol = '\0';
> > char *cp;
> > kdb_symtab_t symtab;
> > + char namebuf[KSYM_NAME_LEN];
> >
> > /*
> >* If the enable flags prohibit both arbitrary memory access
> > @@ -585,7 +586,7 @@ int kdbgetaddrarg(int argc, const char **argv, int
> > *nextarg,
> > }
> >
> > if (!found)
> > - found = kdbnearsym(addr, );
> > + found = kdbnearsym(addr, , namebuf);
> >
> > (*nextarg)++;
> >
> > @@ -1503,6 +1504,7 @@ static void kdb_md_line(const char *fmtstr, unsigned
> > long addr,
> > int i;
> > int j;
> > unsigned long word;
> > + char
Re: [PATCH v2 1/1] net: fec: ptp: avoid register access when ipg clock is disabled
Hi all,
Am Do., 25. Feb. 2021 um 22:15 Uhr schrieb Heiko Thiery
:
>
> When accessing the timecounter register on an i.MX8MQ the kernel hangs.
> This is only the case when the interface is down. This can be reproduced
> by reading with 'phc_ctrl eth0 get'.
>
> Like described in the change in 91c0d987a9788dcc5fe26baafd73bf9242b68900
> the igp clock is disabled when the interface is down and leads to a
> system hang.
>
> So we check if the ptp clock status before reading the timecounter
> register.
>
> Signed-off-by: Heiko Thiery
Sorry for the noise. But just realized that I sent a v3 version of the
patch but forgot to update the subject line (still v2). Should I
resend it with the correct subject?
> ---
> v2:
> - add mutex (thanks to Richard)
>
> v3:
> I did a mistake and did not test properly
> - add parenteses
> - fix the used variable
>
> drivers/net/ethernet/freescale/fec_ptp.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/ethernet/freescale/fec_ptp.c
> b/drivers/net/ethernet/freescale/fec_ptp.c
> index 2e344aada4c6..1753807cbf97 100644
> --- a/drivers/net/ethernet/freescale/fec_ptp.c
> +++ b/drivers/net/ethernet/freescale/fec_ptp.c
> @@ -377,9 +377,16 @@ static int fec_ptp_gettime(struct ptp_clock_info *ptp,
> struct timespec64 *ts)
> u64 ns;
> unsigned long flags;
>
> + mutex_lock(>ptp_clk_mutex);
> + /* Check the ptp clock */
> + if (!adapter->ptp_clk_on) {
> + mutex_unlock(>ptp_clk_mutex);
> + return -EINVAL;
> + }
> spin_lock_irqsave(>tmreg_lock, flags);
> ns = timecounter_read(>tc);
> spin_unlock_irqrestore(>tmreg_lock, flags);
> + mutex_unlock(>ptp_clk_mutex);
>
> *ts = ns_to_timespec64(ns);
>
> --
> 2.30.0
>
Re: [PATCH v2] sched/pelt: Fix task util_est update filtering
On Thu, 25 Feb 2021 at 17:58, Vincent Donnefort
wrote:
>
> Being called for each dequeue, util_est reduces the number of its updates
> by filtering out when the EWMA signal is different from the task util_avg
> by less than 1%. It is a problem for a sudden util_avg ramp-up. Due to the
> decay from a previous high util_avg, EWMA might now be close enough to
> the new util_avg. No update would then happen while it would leave
> ue.enqueued with an out-of-date value.
>
> Taking into consideration the two util_est members, EWMA and enqueued for
> the filtering, ensures, for both, an up-to-date value.
>
> This is for now an issue only for the trace probe that might return the
> stale value. Functional-wise, it isn't a problem, as the value is always
> accessed through max(enqueued, ewma).
>
> This problem has been observed using LISA's UtilConvergence:test_means on
> the sd845c board.
>
> No regression observed with Hackbench on sd845c and Perf-bench sched pipe
> on hikey/hikey960.
>
> Signed-off-by: Vincent Donnefort
> Reviewed-by: Dietmar Eggemann
Reviewed-by: Vincent Guittot
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 9e4104ae39ae..214e02862994 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3966,24 +3966,27 @@ static inline void util_est_dequeue(struct cfs_rq
> *cfs_rq,
> trace_sched_util_est_cfs_tp(cfs_rq);
> }
>
> +#define UTIL_EST_MARGIN (SCHED_CAPACITY_SCALE / 100)
> +
> /*
> - * Check if a (signed) value is within a specified (unsigned) margin,
> + * Check if a (signed) value is within the (unsigned) util_est margin,
> * based on the observation that:
> *
> * abs(x) < y := (unsigned)(x + y - 1) < (2 * y - 1)
> *
> - * NOTE: this only works when value + maring < INT_MAX.
> + * NOTE: this only works when value + UTIL_EST_MARGIN < INT_MAX.
> */
> -static inline bool within_margin(int value, int margin)
> +static inline bool util_est_within_margin(int value)
> {
> - return ((unsigned int)(value + margin - 1) < (2 * margin - 1));
> + return ((unsigned int)(value + UTIL_EST_MARGIN - 1) <
> + (2 * UTIL_EST_MARGIN - 1));
> }
>
> static inline void util_est_update(struct cfs_rq *cfs_rq,
>struct task_struct *p,
>bool task_sleep)
> {
> - long last_ewma_diff;
> + long last_ewma_diff, last_enqueued_diff;
> struct util_est ue;
>
> if (!sched_feat(UTIL_EST))
> @@ -4004,6 +4007,8 @@ static inline void util_est_update(struct cfs_rq
> *cfs_rq,
> if (ue.enqueued & UTIL_AVG_UNCHANGED)
> return;
>
> + last_enqueued_diff = ue.enqueued;
> +
> /*
> * Reset EWMA on utilization increases, the moving average is used
> only
> * to smooth utilization decreases.
> @@ -4017,12 +4022,17 @@ static inline void util_est_update(struct cfs_rq
> *cfs_rq,
> }
>
> /*
> -* Skip update of task's estimated utilization when its EWMA is
> +* Skip update of task's estimated utilization when its members are
> * already ~1% close to its last activation value.
> */
> last_ewma_diff = ue.enqueued - ue.ewma;
> - if (within_margin(last_ewma_diff, (SCHED_CAPACITY_SCALE / 100)))
> + last_enqueued_diff -= ue.enqueued;
> + if (util_est_within_margin(last_ewma_diff)) {
> + if (!util_est_within_margin(last_enqueued_diff))
> + goto done;
> +
> return;
> + }
>
> /*
> * To avoid overestimation of actual task utilization, skip updates if
> --
> 2.25.1
>
[PATCH v3 8/8] nouveau/svm: Implement atomic SVM access
Some NVIDIA GPUs do not support direct atomic access to system memory
via PCIe. Instead this must be emulated by granting the GPU exclusive
access to the memory. This is achieved by replacing CPU page table
entries with special swap entries that fault on userspace access.
The driver then grants the GPU permission to update the page undergoing
atomic access via the GPU page tables. When CPU access to the page is
required a CPU fault is raised which calls into the device driver via
MMU notifiers to revoke the atomic access. The original page table
entries are then restored allowing CPU access to proceed.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 +
drivers/gpu/drm/nouveau/nouveau_svm.c | 88 ---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 +
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 6 ++
4 files changed, 83 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
index d6dd40f21eed..9c7ff56831c5 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
@@ -77,6 +77,7 @@ struct nvif_vmm_pfnmap_v0 {
#define NVIF_VMM_PFNMAP_V0_APER 0x00f0ULL
#define NVIF_VMM_PFNMAP_V0_HOST 0xULL
#define NVIF_VMM_PFNMAP_V0_VRAM 0x0010ULL
+#define NVIF_VMM_PFNMAP_V0_A 0x0004ULL
#define NVIF_VMM_PFNMAP_V0_W 0x0002ULL
#define NVIF_VMM_PFNMAP_V0_V 0x0001ULL
#define NVIF_VMM_PFNMAP_V0_NONE 0xULL
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index cd7b47c946cf..630c4a7bcb55 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
struct nouveau_svm {
struct nouveau_drm *drm;
@@ -421,9 +422,9 @@ nouveau_svm_fault_cmp(const void *a, const void *b)
return ret;
if ((ret = (s64)fa->addr - fb->addr))
return ret;
- /*XXX: atomic? */
- return (fa->access == 0 || fa->access == 3) -
- (fb->access == 0 || fb->access == 3);
+ /* Atomic access (2) has highest priority */
+ return (-1*(fa->access == 2) + (fa->access == 0 || fa->access == 3)) -
+ (-1*(fb->access == 2) + (fb->access == 0 || fb->access == 3));
}
static void
@@ -555,10 +556,58 @@ static void nouveau_hmm_convert_pfn(struct nouveau_drm
*drm,
args->p.phys[0] |= NVIF_VMM_PFNMAP_V0_W;
}
+static int nouveau_atomic_range_fault(struct nouveau_svmm *svmm,
+ struct nouveau_drm *drm,
+ struct nouveau_pfnmap_args *args, u32 size,
+ unsigned long hmm_flags, struct mm_struct *mm)
+{
+ struct page *page;
+ unsigned long start = args->p.addr;
+ struct vm_area_struct *vma;
+ int ret = 0;
+
+ mmap_read_lock(mm);
+ vma = find_vma_intersection(mm, start, start + size);
+ if (!vma || !(vma->vm_flags & VM_WRITE)) {
+ ret = -EPERM;
+ goto out;
+ }
+
+ make_device_exclusive_range(mm, start, start + PAGE_SIZE, );
+ if (!page) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ /* Map the page on the GPU. */
+ args->p.page = 12;
+ args->p.size = PAGE_SIZE;
+ args->p.addr = start;
+ args->p.phys[0] = page_to_phys(page) |
+ NVIF_VMM_PFNMAP_V0_V |
+ NVIF_VMM_PFNMAP_V0_W |
+ NVIF_VMM_PFNMAP_V0_A |
+ NVIF_VMM_PFNMAP_V0_HOST;
+
+ mutex_lock(>mutex);
+ svmm->vmm->vmm.object.client->super = true;
+ ret = nvif_object_ioctl(>vmm->vmm.object, args, size, NULL);
+ svmm->vmm->vmm.object.client->super = false;
+ mutex_unlock(>mutex);
+
+ set_page_dirty(page);
+ unlock_page(page);
+ put_page(page);
+
+out:
+ mmap_read_unlock(mm);
+ return ret;
+}
+
static int nouveau_range_fault(struct nouveau_svmm *svmm,
struct nouveau_drm *drm,
struct nouveau_pfnmap_args *args, u32 size,
- unsigned long hmm_flags,
+ unsigned long hmm_flags, int atomic,
struct svm_notifier *notifier)
{
unsigned long timeout =
@@ -608,12 +657,18 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
break;
}
- nouveau_hmm_convert_pfn(drm, , args);
+ if (atomic) {
+ mutex_unlock(>mutex);
+ ret = nouveau_atomic_range_fault(svmm,
[PATCH v3 5/8] mm: Device exclusive memory access
Some devices require exclusive write access to shared virtual
memory (SVM) ranges to perform atomic operations on that memory. This
requires CPU page tables to be updated to deny access whilst atomic
operations are occurring.
In order to do this introduce a new swap entry
type (SWP_DEVICE_EXCLUSIVE). When a SVM range needs to be marked for
exclusive access by a device all page table mappings for the particular
range are replaced with device exclusive swap entries. This causes any
CPU access to the page to result in a fault.
Faults are resovled by replacing the faulting entry with the original
mapping. This results in MMU notifiers being called which a driver uses
to update access permissions such as revoking atomic access. After
notifiers have been called the device will no longer have exclusive
access to the region.
Signed-off-by: Alistair Popple
---
Documentation/vm/hmm.rst | 15
include/linux/rmap.h | 3 +
include/linux/swap.h | 4 +-
include/linux/swapops.h | 44 ++-
mm/hmm.c | 5 ++
mm/memory.c | 108 +-
mm/mprotect.c| 8 ++
mm/page_vma_mapped.c | 9 ++-
mm/rmap.c| 163 +++
9 files changed, 352 insertions(+), 7 deletions(-)
diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index 09e28507f5b2..f526ac4d8798 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -405,6 +405,21 @@ between device driver specific code and shared common code:
The lock can now be released.
+Exclusive access memory
+===
+
+Not all devices support atomic access to system memory. To support atomic
+operations to a shared virtual memory page such a device needs access to that
+page which is exclusive of any userspace access from the CPU. The
+``make_device_exclusive_range()`` function can be used to make a memory range
+inaccessible from userspace.
+
+This replaces all mappings for pages in the given range with special swap
+entries. Any attempt to access the swap entry results in a fault which is
+resovled by replacing the entry with the original mapping. A driver gets
+notified that the mapping has been changed by MMU notifiers, after which point
+it will no longer have exclusive access to the page.
+
Memory cgroup (memcg) and rss accounting
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 77fa17de51d7..dad4014fda42 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -193,6 +193,9 @@ int page_referenced(struct page *, int is_locked,
bool try_to_migrate(struct page *page, enum ttu_flags flags);
bool try_to_unmap(struct page *, enum ttu_flags flags);
+int make_device_exclusive_range(struct mm_struct *mm, unsigned long start,
+ unsigned long end, struct page **pages);
+
/* Avoid racy checks */
#define PVMW_SYNC (1 << 0)
/* Look for migarion entries rather than present PTEs */
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 729c44e7c270..d83bcca0d14d 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -63,9 +63,11 @@ static inline int current_is_kswapd(void)
* to a special SWP_DEVICE_* entry.
*/
#ifdef CONFIG_DEVICE_PRIVATE
-#define SWP_DEVICE_NUM 2
+#define SWP_DEVICE_NUM 4
#define SWP_DEVICE_WRITE (MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM)
#define SWP_DEVICE_READ (MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM+1)
+#define SWP_DEVICE_EXCLUSIVE_WRITE
(MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM+2)
+#define SWP_DEVICE_EXCLUSIVE_READ
(MAX_SWAPFILES+SWP_HWPOISON_NUM+SWP_MIGRATION_NUM+3)
#else
#define SWP_DEVICE_NUM 0
#endif
diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index 256b9683b262..c17062dabaa1 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -120,6 +120,27 @@ static inline bool
is_writable_device_private_entry(swp_entry_t entry)
{
return unlikely(swp_type(entry) == SWP_DEVICE_WRITE);
}
+
+static inline swp_entry_t make_readable_device_exclusive_entry(pgoff_t offset)
+{
+ return swp_entry(SWP_DEVICE_EXCLUSIVE_READ, offset);
+}
+
+static inline swp_entry_t make_writable_device_exclusive_entry(pgoff_t offset)
+{
+ return swp_entry(SWP_DEVICE_EXCLUSIVE_WRITE, offset);
+}
+
+static inline bool is_device_exclusive_entry(swp_entry_t entry)
+{
+ return swp_type(entry) == SWP_DEVICE_EXCLUSIVE_READ ||
+ swp_type(entry) == SWP_DEVICE_EXCLUSIVE_WRITE;
+}
+
+static inline bool is_writable_device_exclusive_entry(swp_entry_t entry)
+{
+ return unlikely(swp_type(entry) == SWP_DEVICE_EXCLUSIVE_WRITE);
+}
#else /* CONFIG_DEVICE_PRIVATE */
static inline swp_entry_t make_readable_device_private_entry(pgoff_t offset)
{
@@ -140,6 +161,26 @@ static inline bool
is_writable_device_private_entry(swp_entry_t entry)
{
return false;
}
+
+static inline swp_entry_t
[PATCH v3 7/8] nouveau/svm: Refactor nouveau_range_fault
Call mmu_interval_notifier_insert() as part of nouveau_range_fault().
This doesn't introduce any functional change but makes it easier for a
subsequent patch to alter the behaviour of nouveau_range_fault() to
support GPU atomic operations.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 34 ---
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index f18bd53da052..cd7b47c946cf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -567,18 +567,27 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
unsigned long hmm_pfns[1];
struct hmm_range range = {
.notifier = >notifier,
- .start = notifier->notifier.interval_tree.start,
- .end = notifier->notifier.interval_tree.last + 1,
.default_flags = hmm_flags,
.hmm_pfns = hmm_pfns,
.dev_private_owner = drm->dev,
};
- struct mm_struct *mm = notifier->notifier.mm;
+ struct mm_struct *mm = svmm->notifier.mm;
int ret;
+ ret = mmu_interval_notifier_insert(>notifier, mm,
+ args->p.addr, args->p.size,
+ _svm_mni_ops);
+ if (ret)
+ return ret;
+
+ range.start = notifier->notifier.interval_tree.start;
+ range.end = notifier->notifier.interval_tree.last + 1;
+
while (true) {
- if (time_after(jiffies, timeout))
- return -EBUSY;
+ if (time_after(jiffies, timeout)) {
+ ret = -EBUSY;
+ goto out;
+ }
range.notifier_seq = mmu_interval_read_begin(range.notifier);
mmap_read_lock(mm);
@@ -587,7 +596,7 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
if (ret) {
if (ret == -EBUSY)
continue;
- return ret;
+ goto out;
}
mutex_lock(>mutex);
@@ -606,6 +615,9 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
svmm->vmm->vmm.object.client->super = false;
mutex_unlock(>mutex);
+out:
+ mmu_interval_notifier_remove(>notifier);
+
return ret;
}
@@ -727,14 +739,8 @@ nouveau_svm_fault(struct nvif_notify *notify)
}
notifier.svmm = svmm;
- ret = mmu_interval_notifier_insert(, mm,
- args.i.p.addr, args.i.p.size,
- _svm_mni_ops);
- if (!ret) {
- ret = nouveau_range_fault(svmm, svm->drm, ,
- sizeof(args), hmm_flags, );
- mmu_interval_notifier_remove();
- }
+ ret = nouveau_range_fault(svmm, svm->drm, ,
+ sizeof(args), hmm_flags, );
mmput(mm);
limit = args.i.p.addr + args.i.p.size;
--
2.20.1
[PATCH v3 6/8] mm: Selftests for exclusive device memory
Adds some selftests for exclusive device memory.
Signed-off-by: Alistair Popple
---
lib/test_hmm.c | 124 ++
lib/test_hmm_uapi.h| 2 +
tools/testing/selftests/vm/hmm-tests.c | 219 +
3 files changed, 345 insertions(+)
diff --git a/lib/test_hmm.c b/lib/test_hmm.c
index 80a78877bd93..699b35e248f7 100644
--- a/lib/test_hmm.c
+++ b/lib/test_hmm.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "test_hmm_uapi.h"
@@ -46,6 +47,7 @@ struct dmirror_bounce {
unsigned long cpages;
};
+#define DPT_XA_TAG_ATOMIC 1UL
#define DPT_XA_TAG_WRITE 3UL
/*
@@ -619,6 +621,54 @@ static void dmirror_migrate_alloc_and_copy(struct
migrate_vma *args,
}
}
+static int dmirror_check_atomic(struct dmirror *dmirror, unsigned long start,
+unsigned long end)
+{
+ unsigned long pfn;
+
+ for (pfn = start >> PAGE_SHIFT; pfn < (end >> PAGE_SHIFT); pfn++) {
+ void *entry;
+ struct page *page;
+
+ entry = xa_load(>pt, pfn);
+ page = xa_untag_pointer(entry);
+ if (xa_pointer_tag(entry) == DPT_XA_TAG_ATOMIC)
+ return -EPERM;
+ }
+
+ return 0;
+}
+
+static int dmirror_atomic_map(unsigned long start, unsigned long end,
+ struct page **pages, struct dmirror *dmirror)
+{
+ unsigned long pfn, mapped = 0;
+ int i;
+
+ /* Map the migrated pages into the device's page tables. */
+ mutex_lock(>mutex);
+
+ for (i = 0, pfn = start >> PAGE_SHIFT; pfn < (end >> PAGE_SHIFT);
pfn++, i++) {
+ void *entry;
+
+ if (!pages[i])
+ continue;
+
+ entry = pages[i];
+ entry = xa_tag_pointer(entry, DPT_XA_TAG_ATOMIC);
+ entry = xa_store(>pt, pfn, entry, GFP_ATOMIC);
+ if (xa_is_err(entry)) {
+ mutex_unlock(>mutex);
+ return xa_err(entry);
+ }
+
+ mapped++;
+ }
+
+ mutex_unlock(>mutex);
+ return mapped;
+}
+
static int dmirror_migrate_finalize_and_map(struct migrate_vma *args,
struct dmirror *dmirror)
{
@@ -661,6 +711,71 @@ static int dmirror_migrate_finalize_and_map(struct
migrate_vma *args,
return 0;
}
+static int dmirror_exclusive(struct dmirror *dmirror,
+struct hmm_dmirror_cmd *cmd)
+{
+ unsigned long start, end, addr;
+ unsigned long size = cmd->npages << PAGE_SHIFT;
+ struct mm_struct *mm = dmirror->notifier.mm;
+ struct page *pages[64];
+ struct dmirror_bounce bounce;
+ unsigned long next;
+ int ret;
+
+ start = cmd->addr;
+ end = start + size;
+ if (end < start)
+ return -EINVAL;
+
+ /* Since the mm is for the mirrored process, get a reference first. */
+ if (!mmget_not_zero(mm))
+ return -EINVAL;
+
+ mmap_read_lock(mm);
+ for (addr = start; addr < end; addr = next) {
+ int i, mapped;
+
+ if (end < addr + (64 << PAGE_SHIFT))
+ next = end;
+ else
+ next = addr + (64 << PAGE_SHIFT);
+
+ ret = make_device_exclusive_range(mm, addr, next, pages);
+ mapped = dmirror_atomic_map(addr, next, pages, dmirror);
+ for (i = 0; i < ret; i++) {
+ if (pages[i]) {
+ unlock_page(pages[i]);
+ put_page(pages[i]);
+ }
+ }
+
+ if (addr + (mapped << PAGE_SHIFT) < next) {
+ mmap_read_unlock(mm);
+ mmput(mm);
+ return -EBUSY;
+ }
+ }
+ mmap_read_unlock(mm);
+ mmput(mm);
+
+ /* Return the migrated data for verification. */
+ ret = dmirror_bounce_init(, start, size);
+ if (ret)
+ return ret;
+ mutex_lock(>mutex);
+ ret = dmirror_do_read(dmirror, start, end, );
+ mutex_unlock(>mutex);
+ if (ret == 0) {
+ if (copy_to_user(u64_to_user_ptr(cmd->ptr), bounce.ptr,
+bounce.size))
+ ret = -EFAULT;
+ }
+
+ cmd->cpages = bounce.cpages;
+ dmirror_bounce_fini();
+ return ret;
+}
+
static int dmirror_migrate(struct dmirror *dmirror,
struct hmm_dmirror_cmd *cmd)
{
@@ -949,6 +1064,15 @@ static long dmirror_fops_unlocked_ioctl(struct file *filp,
ret = dmirror_migrate(dmirror, );
break;
+ case HMM_DMIRROR_EXCLUSIVE:
+ ret = dmirror_exclusive(dmirror, );
+ break;
+
+ case
[PATCH v3 4/8] mm/rmap: Split migration into its own function
Migration is currently implemented as a mode of operation for
try_to_unmap_one() generally specified by passing the TTU_MIGRATION flag
or in the case of splitting a huge anonymous page TTU_SPLIT_FREEZE.
However it does not have much in common with the rest of the unmap
functionality of try_to_unmap_one() and thus splitting it into a
separate function reduces the complexity of try_to_unmap_one() making it
more readable.
Several simplifications can also be made in try_to_migrate_one() based
on the following observations:
- All users of TTU_MIGRATION also set TTU_IGNORE_MLOCK.
- No users of TTU_MIGRATION ever set TTU_IGNORE_HWPOISON.
- No users of TTU_MIGRATION ever set TTU_BATCH_FLUSH.
TTU_SPLIT_FREEZE is a special case of migration used when splitting an
anonymous page. This is most easily dealt with by calling the correct
function from unmap_page() in mm/huge_memory.c - either
try_to_migrate() for PageAnon or try_to_unmap().
Signed-off-by: Alistair Popple
---
include/linux/rmap.h | 4 +-
mm/huge_memory.c | 10 +-
mm/migrate.c | 9 +-
mm/rmap.c| 352 +++
4 files changed, 269 insertions(+), 106 deletions(-)
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 7f1ee411bd7b..77fa17de51d7 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -86,8 +86,6 @@ struct anon_vma_chain {
};
enum ttu_flags {
- TTU_MIGRATION = 0x1, /* migration mode */
-
TTU_SPLIT_HUGE_PMD = 0x4, /* split huge PMD if any */
TTU_IGNORE_MLOCK= 0x8, /* ignore mlock */
TTU_IGNORE_HWPOISON = 0x20, /* corrupted page is recoverable */
@@ -96,7 +94,6 @@ enum ttu_flags {
* do a final flush if necessary */
TTU_RMAP_LOCKED = 0x80, /* do not grab rmap lock:
* caller holds it */
- TTU_SPLIT_FREEZE= 0x100,/* freeze pte under
splitting thp */
};
#ifdef CONFIG_MMU
@@ -193,6 +190,7 @@ static inline void page_dup_rmap(struct page *page, bool
compound)
int page_referenced(struct page *, int is_locked,
struct mem_cgroup *memcg, unsigned long *vm_flags);
+bool try_to_migrate(struct page *page, enum ttu_flags flags);
bool try_to_unmap(struct page *, enum ttu_flags flags);
/* Avoid racy checks */
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index d00b93dc2d9e..357052a4567b 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2351,16 +2351,16 @@ void vma_adjust_trans_huge(struct vm_area_struct *vma,
static void unmap_page(struct page *page)
{
- enum ttu_flags ttu_flags = TTU_IGNORE_MLOCK |
- TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
+ enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
bool unmap_success;
VM_BUG_ON_PAGE(!PageHead(page), page);
if (PageAnon(page))
- ttu_flags |= TTU_SPLIT_FREEZE;
-
- unmap_success = try_to_unmap(page, ttu_flags);
+ unmap_success = try_to_migrate(page, ttu_flags);
+ else
+ unmap_success = try_to_unmap(page, ttu_flags |
+ TTU_IGNORE_MLOCK);
VM_BUG_ON_PAGE(!unmap_success, page);
}
diff --git a/mm/migrate.c b/mm/migrate.c
index 3033cc42892a..c677028ebe26 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1124,7 +1124,7 @@ static int __unmap_and_move(struct page *page, struct
page *newpage,
/* Establish migration ptes */
VM_BUG_ON_PAGE(PageAnon(page) && !PageKsm(page) && !anon_vma,
page);
- try_to_unmap(page, TTU_MIGRATION|TTU_IGNORE_MLOCK);
+ try_to_migrate(page, 0);
page_was_mapped = 1;
}
@@ -1326,7 +1326,7 @@ static int unmap_and_move_huge_page(new_page_t
get_new_page,
if (page_mapped(hpage)) {
bool mapping_locked = false;
- enum ttu_flags ttu = TTU_MIGRATION|TTU_IGNORE_MLOCK;
+ enum ttu_flags ttu = 0;
if (!PageAnon(hpage)) {
/*
@@ -1343,7 +1343,7 @@ static int unmap_and_move_huge_page(new_page_t
get_new_page,
ttu |= TTU_RMAP_LOCKED;
}
- try_to_unmap(hpage, ttu);
+ try_to_migrate(hpage, ttu);
page_was_mapped = 1;
if (mapping_locked)
@@ -2750,7 +2750,6 @@ static void migrate_vma_prepare(struct migrate_vma
*migrate)
*/
static void migrate_vma_unmap(struct migrate_vma *migrate)
{
- int flags = TTU_MIGRATION | TTU_IGNORE_MLOCK;
const unsigned long npages = migrate->npages;
const unsigned long start = migrate->start;
unsigned long addr, i, restore = 0;
@@ -2762,7 +2761,7 @@ static void migrate_vma_unmap(struct migrate_vma *migrate)
continue;
[PATCH v3 1/8] mm: Remove special swap entry functions
Remove the migration and device private entry_to_page() and
entry_to_pfn() inline functions and instead open code them directly.
This results in shorter code which is easier to understand.
Signed-off-by: Alistair Popple
---
arch/s390/mm/pgtable.c | 2 +-
fs/proc/task_mmu.c | 23 +++
include/linux/swap.h| 4 ++--
include/linux/swapops.h | 51 -
mm/hmm.c| 5 ++--
mm/memcontrol.c | 2 +-
mm/memory.c | 10
mm/migrate.c| 6 ++---
mm/page_vma_mapped.c| 6 ++---
9 files changed, 30 insertions(+), 79 deletions(-)
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 18205f851c24..25c28d28ff61 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -691,7 +691,7 @@ static void ptep_zap_swap_entry(struct mm_struct *mm,
swp_entry_t entry)
if (!non_swap_entry(entry))
dec_mm_counter(mm, MM_SWAPENTS);
else if (is_migration_entry(entry)) {
- struct page *page = migration_entry_to_page(entry);
+ struct page *page = pfn_to_page(swp_offset(entry));
dec_mm_counter(mm, mm_counter(page));
}
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 602e3a52884d..ee9686f96a41 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -514,10 +514,8 @@ static void smaps_pte_entry(pte_t *pte, unsigned long addr,
} else {
mss->swap_pss += (u64)PAGE_SIZE << PSS_SHIFT;
}
- } else if (is_migration_entry(swpent))
- page = migration_entry_to_page(swpent);
- else if (is_device_private_entry(swpent))
- page = device_private_entry_to_page(swpent);
+ } else if (is_special_entry(swpent))
+ page = pfn_to_page(swp_offset(swpent));
} else if (unlikely(IS_ENABLED(CONFIG_SHMEM) && mss->check_shmem_swap
&& pte_none(*pte))) {
page = xa_load(>vm_file->f_mapping->i_pages,
@@ -549,7 +547,7 @@ static void smaps_pmd_entry(pmd_t *pmd, unsigned long addr,
swp_entry_t entry = pmd_to_swp_entry(*pmd);
if (is_migration_entry(entry))
- page = migration_entry_to_page(entry);
+ page = pfn_to_page(swp_offset(entry));
}
if (IS_ERR_OR_NULL(page))
return;
@@ -691,10 +689,8 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long
hmask,
} else if (is_swap_pte(*pte)) {
swp_entry_t swpent = pte_to_swp_entry(*pte);
- if (is_migration_entry(swpent))
- page = migration_entry_to_page(swpent);
- else if (is_device_private_entry(swpent))
- page = device_private_entry_to_page(swpent);
+ if (is_special_entry(swpent))
+ page = pfn_to_page(swp_offset(swpent));
}
if (page) {
int mapcount = page_mapcount(page);
@@ -1382,11 +1378,8 @@ static pagemap_entry_t pte_to_pagemap_entry(struct
pagemapread *pm,
frame = swp_type(entry) |
(swp_offset(entry) << MAX_SWAPFILES_SHIFT);
flags |= PM_SWAP;
- if (is_migration_entry(entry))
- page = migration_entry_to_page(entry);
-
- if (is_device_private_entry(entry))
- page = device_private_entry_to_page(entry);
+ if (is_special_entry(entry))
+ page = pfn_to_page(swp_offset(entry));
}
if (page && !PageAnon(page))
@@ -1443,7 +1436,7 @@ static int pagemap_pmd_range(pmd_t *pmdp, unsigned long
addr, unsigned long end,
if (pmd_swp_soft_dirty(pmd))
flags |= PM_SOFT_DIRTY;
VM_BUG_ON(!is_pmd_migration_entry(pmd));
- page = migration_entry_to_page(entry);
+ page = pfn_to_page(swp_offset(entry));
}
#endif
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 596bc2f4d9b0..729c44e7c270 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -519,8 +519,8 @@ static inline void show_swap_cache_info(void)
{
}
-#define free_swap_and_cache(e) ({(is_migration_entry(e) ||
is_device_private_entry(e));})
-#define swapcache_prepare(e) ({(is_migration_entry(e) ||
is_device_private_entry(e));})
+#define free_swap_and_cache(e) is_special_entry(e)
+#define swapcache_prepare(e) is_special_entry(e)
static inline int add_swap_count_continuation(swp_entry_t swp, gfp_t gfp_mask)
{
diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index d9b7c9132c2f..80cfa3985045 100644
--- a/include/linux/swapops.h
+++
[PATCH v3 2/8] mm/swapops: Rework swap entry manipulation code
Both migration and device private pages use special swap entries which
are manipluated by a range of inline functions. The arguments to these
are somewhat inconsitent so rework them to remove flag type arguments
and to make the arguments similar for both a read and write entry
creation.
Signed-off-by: Alistair Popple
---
include/linux/swapops.h | 56 ++---
mm/debug_vm_pgtable.c | 12 -
mm/hmm.c| 2 +-
mm/huge_memory.c| 26 +--
mm/hugetlb.c| 10 +---
mm/memory.c | 10 +---
mm/migrate.c| 26 ++-
mm/mprotect.c | 10 +---
mm/rmap.c | 10 +---
9 files changed, 100 insertions(+), 62 deletions(-)
diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index 80cfa3985045..256b9683b262 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -100,35 +100,35 @@ static inline void *swp_to_radix_entry(swp_entry_t entry)
}
#if IS_ENABLED(CONFIG_DEVICE_PRIVATE)
-static inline swp_entry_t make_device_private_entry(struct page *page, bool
write)
+static inline swp_entry_t make_readable_device_private_entry(pgoff_t offset)
{
- return swp_entry(write ? SWP_DEVICE_WRITE : SWP_DEVICE_READ,
-page_to_pfn(page));
+ return swp_entry(SWP_DEVICE_READ, offset);
}
-static inline bool is_device_private_entry(swp_entry_t entry)
+static inline swp_entry_t make_writable_device_private_entry(pgoff_t offset)
{
- int type = swp_type(entry);
- return type == SWP_DEVICE_READ || type == SWP_DEVICE_WRITE;
+ return swp_entry(SWP_DEVICE_WRITE, offset);
}
-static inline void make_device_private_entry_read(swp_entry_t *entry)
+static inline bool is_device_private_entry(swp_entry_t entry)
{
- *entry = swp_entry(SWP_DEVICE_READ, swp_offset(*entry));
+ int type = swp_type(entry);
+ return type == SWP_DEVICE_READ || type == SWP_DEVICE_WRITE;
}
-static inline bool is_write_device_private_entry(swp_entry_t entry)
+static inline bool is_writable_device_private_entry(swp_entry_t entry)
{
return unlikely(swp_type(entry) == SWP_DEVICE_WRITE);
}
#else /* CONFIG_DEVICE_PRIVATE */
-static inline swp_entry_t make_device_private_entry(struct page *page, bool
write)
+static inline swp_entry_t make_readable_device_private_entry(pgoff_t offset)
{
return swp_entry(0, 0);
}
-static inline void make_device_private_entry_read(swp_entry_t *entry)
+static inline swp_entry_t make_writable_device_private_entry(pgoff_t offset)
{
+ return swp_entry(0, 0);
}
static inline bool is_device_private_entry(swp_entry_t entry)
@@ -136,35 +136,32 @@ static inline bool is_device_private_entry(swp_entry_t
entry)
return false;
}
-static inline bool is_write_device_private_entry(swp_entry_t entry)
+static inline bool is_writable_device_private_entry(swp_entry_t entry)
{
return false;
}
#endif /* CONFIG_DEVICE_PRIVATE */
#ifdef CONFIG_MIGRATION
-static inline swp_entry_t make_migration_entry(struct page *page, int write)
-{
- BUG_ON(!PageLocked(compound_head(page)));
-
- return swp_entry(write ? SWP_MIGRATION_WRITE : SWP_MIGRATION_READ,
- page_to_pfn(page));
-}
-
static inline int is_migration_entry(swp_entry_t entry)
{
return unlikely(swp_type(entry) == SWP_MIGRATION_READ ||
swp_type(entry) == SWP_MIGRATION_WRITE);
}
-static inline int is_write_migration_entry(swp_entry_t entry)
+static inline int is_writable_migration_entry(swp_entry_t entry)
{
return unlikely(swp_type(entry) == SWP_MIGRATION_WRITE);
}
-static inline void make_migration_entry_read(swp_entry_t *entry)
+static inline swp_entry_t make_readable_migration_entry(pgoff_t offset)
{
- *entry = swp_entry(SWP_MIGRATION_READ, swp_offset(*entry));
+ return swp_entry(SWP_MIGRATION_READ, offset);
+}
+
+static inline swp_entry_t make_writable_migration_entry(pgoff_t offset)
+{
+ return swp_entry(SWP_MIGRATION_WRITE, offset);
}
extern void __migration_entry_wait(struct mm_struct *mm, pte_t *ptep,
@@ -174,21 +171,28 @@ extern void migration_entry_wait(struct mm_struct *mm,
pmd_t *pmd,
extern void migration_entry_wait_huge(struct vm_area_struct *vma,
struct mm_struct *mm, pte_t *pte);
#else
+static inline swp_entry_t make_readable_migration_entry(pgoff_t offset)
+{
+ return swp_entry(0, 0);
+}
+
+static inline swp_entry_t make_writable_migration_entry(pgoff_t offset)
+{
+ return swp_entry(0, 0);
+}
-#define make_migration_entry(page, write) swp_entry(0, 0)
static inline int is_migration_entry(swp_entry_t swp)
{
return 0;
}
-static inline void make_migration_entry_read(swp_entry_t *entryp) { }
static inline void __migration_entry_wait(struct mm_struct *mm, pte_t *ptep,
spinlock_t *ptl) { }
static inline
[PATCH v3 3/8] mm/rmap: Split try_to_munlock from try_to_unmap
The behaviour of try_to_unmap_one() is difficult to follow because it
performs different operations based on a fairly large set of flags used
in different combinations.
TTU_MUNLOCK is one such flag. However it is exclusively used by
try_to_munlock() which specifies no other flags. Therefore rather than
overload try_to_unmap_one() with unrelated behaviour split this out into
it's own function and remove the flag.
Signed-off-by: Alistair Popple
---
Given the comments on not needing to hold mmap_lock it was not 100% clear
to me if it is safe to check vma->vma_flags & VM_LOCKED and if re-checking
under the ptl was significant. I left the extra check in case it was, but
it seems one of the checks is redunant as either the first check is racey
or the second check is unneccsary.
---
include/linux/rmap.h | 1 -
mm/rmap.c| 47
2 files changed, 39 insertions(+), 9 deletions(-)
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 70085ca1a3fc..7f1ee411bd7b 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -87,7 +87,6 @@ struct anon_vma_chain {
enum ttu_flags {
TTU_MIGRATION = 0x1, /* migration mode */
- TTU_MUNLOCK = 0x2, /* munlock mode */
TTU_SPLIT_HUGE_PMD = 0x4, /* split huge PMD if any */
TTU_IGNORE_MLOCK= 0x8, /* ignore mlock */
diff --git a/mm/rmap.c b/mm/rmap.c
index ef9ef2694c58..850eecdd866a 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1391,10 +1391,6 @@ static bool try_to_unmap_one(struct page *page, struct
vm_area_struct *vma,
struct mmu_notifier_range range;
enum ttu_flags flags = (enum ttu_flags)(long)arg;
- /* munlock has nothing to gain from examining un-locked vmas */
- if ((flags & TTU_MUNLOCK) && !(vma->vm_flags & VM_LOCKED))
- return true;
-
if (IS_ENABLED(CONFIG_MIGRATION) && (flags & TTU_MIGRATION) &&
is_zone_device_page(page) && !is_device_private_page(page))
return true;
@@ -1455,8 +1451,6 @@ static bool try_to_unmap_one(struct page *page, struct
vm_area_struct *vma,
page_vma_mapped_walk_done();
break;
}
- if (flags & TTU_MUNLOCK)
- continue;
}
/* Unexpected PMD-mapped THP? */
@@ -1775,6 +1769,44 @@ static int page_not_mapped(struct page *page)
return !page_mapped(page);
};
+static bool try_to_munlock_one(struct page *page, struct vm_area_struct *vma,
+unsigned long address, void *arg)
+{
+ struct page_vma_mapped_walk pvmw = {
+ .page = page,
+ .vma = vma,
+ .address = address,
+ };
+ bool ret = true;
+
+ /* munlock has nothing to gain from examining un-locked vmas */
+ if (!(vma->vm_flags & VM_LOCKED))
+ return true;
+
+ while (page_vma_mapped_walk()) {
+ /*
+* If the page is mlock()d, we cannot swap it out.
+* If it's recently referenced (perhaps page_referenced
+* skipped over this mm) then we should reactivate it.
+*/
+ if (vma->vm_flags & VM_LOCKED) {
+ /* PTE-mapped THP are never mlocked */
+ if (!PageTransCompound(page)) {
+ /*
+* Holding pte lock, we do *not* need
+* mmap_lock here
+*/
+ mlock_vma_page(page);
+ }
+ ret = false;
+ page_vma_mapped_walk_done();
+ break;
+ }
+ }
+
+ return ret;
+}
+
/**
* try_to_munlock - try to munlock a page
* @page: the page to be munlocked
@@ -1787,8 +1819,7 @@ static int page_not_mapped(struct page *page)
void try_to_munlock(struct page *page)
{
struct rmap_walk_control rwc = {
- .rmap_one = try_to_unmap_one,
- .arg = (void *)TTU_MUNLOCK,
+ .rmap_one = try_to_munlock_one,
.done = page_not_mapped,
.anon_lock = page_lock_anon_vma_read,
--
2.20.1
[PATCH v3 0/8] Add support for SVM atomics in Nouveau
This is the third version of a series to add support to Nouveau for atomic memory operations on OpenCL shared virtual memory (SVM) regions. This is achieved using the atomic PTE bits on the GPU to only permit atomic operations to system memory when a page is not mapped in userspace on the CPU. The previous version of this series used an unmap and pin page migration, however this resulted in problems with ZONE_MOVABLE and other issues so this series uses a different approach. Instead exclusive device access is implemented by adding a new swap entry type (SWAP_DEVICE_EXCLUSIVE) which is similar to a migration entry. The main difference is that on fault the original entry is immediately restored by the fault handler instead of waiting. Restoring the entry triggers calls to MMU notifers which allows a device driver to revoke the atomic access permission from the GPU prior to the CPU finalising the entry. Patches 1 & 2 are new for v3 and refactor the existing migration and device private entry functions. Patches 3 & 4 rework try_to_unmap_one() by splitting out unrelated functionality into separate functions - try_to_migrate_one() and try_to_munlock_one(). These should not change any functionality, but any help testing would be much appreciated as I have not been able to test every single usage of try_to_unmap_one(). Patch 5 contains the bulk of the implementation for device exclusive memory. Patch 6 contains some additions to the HMM selftests to ensure everything works as expected and has not changed significantly since v2. Patch 7 was posted previously and has not changed. Patch 8 was posted for v2 and has not changed significantly. This has been tested using the latest upstream Mesa userspace with a simple OpenCL test program which checks the results of atomic GPU operations on a SVM buffer whilst also writing to the same buffer from the CPU. v3: * Refactored some existing functionality. * Switched to using get_user_pages_remote() instead of open-coding it. * Moved code out of hmm. v2: * Changed implementation to use special swap entries instead of device private pages. Alistair Popple (8): mm: Remove special swap entry functions mm/swapops: Rework swap entry manipulation code mm/rmap: Split try_to_munlock from try_to_unmap mm/rmap: Split migration into its own function mm: Device exclusive memory access mm: Selftests for exclusive device memory nouveau/svm: Refactor nouveau_range_fault nouveau/svm: Implement atomic SVM access Documentation/vm/hmm.rst | 15 + arch/s390/mm/pgtable.c| 2 +- drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 + drivers/gpu/drm/nouveau/nouveau_svm.c | 120 +++- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 + .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 6 + fs/proc/task_mmu.c| 23 +- include/linux/rmap.h | 8 +- include/linux/swap.h | 8 +- include/linux/swapops.h | 105 ++-- lib/test_hmm.c| 124 lib/test_hmm_uapi.h | 2 + mm/debug_vm_pgtable.c | 12 +- mm/hmm.c | 12 +- mm/huge_memory.c | 36 +- mm/hugetlb.c | 10 +- mm/memcontrol.c | 2 +- mm/memory.c | 128 +++- mm/migrate.c | 41 +- mm/mprotect.c | 18 +- mm/page_vma_mapped.c | 15 +- mm/rmap.c | 558 +++--- tools/testing/selftests/vm/hmm-tests.c| 219 +++ 23 files changed, 1207 insertions(+), 259 deletions(-) -- 2.20.1
[PATCH] block: fix argument order for capacity change info print
From: Klaus Jensen
Swap "before" and "after" capacities in the info print in
set_capacity_and_notify.
Signed-off-by: Klaus Jensen
---
block/genhd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/genhd.c b/block/genhd.c
index 304f8dcc9a9b..de8ecc402f69 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -73,7 +73,7 @@ bool set_capacity_and_notify(struct gendisk *disk, sector_t
size)
return false;
pr_info("%s: detected capacity change from %lld to %lld\n",
- disk->disk_name, size, capacity);
+ disk->disk_name, capacity, size);
/*
* Historically we did not send a uevent for changes to/from an empty
--
2.30.1
Re: [PATCH 3/3] PCI: Convert rtw88 power cycle quirk to shutdown quirk
Kai-Heng Feng writes: > Now we have a generic D3 shutdown quirk, so convert the original > approach to a PCI quirk. > > Signed-off-by: Kai-Heng Feng > --- > drivers/net/wireless/realtek/rtw88/pci.c | 2 -- > drivers/pci/quirks.c | 6 ++ > 2 files changed, 6 insertions(+), 2 deletions(-) It would have been nice to CC linux-wireless also on patches 1-2. I only saw patch 3 and had to search the rest of patches from lkml. I assume this goes via the PCI tree so: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH] init/init_task.c spaces required around that '='
Ensure checkpatch compliance
Signed-off-by: wangjingyu
---
init/init_task.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/init/init_task.c b/init/init_task.c
index 15f6eb93a04f..0f995118c6c0 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -81,7 +81,7 @@ struct task_struct init_task
.policy = SCHED_NORMAL,
.cpus_ptr = _task.cpus_mask,
.cpus_mask = CPU_MASK_ALL,
- .nr_cpus_allowed= NR_CPUS,
+ .nr_cpus_allowed = NR_CPUS,
.mm = NULL,
.active_mm = _mm,
.restart_block = {
--
2.11.0
Re: [PATCH RFC] MIPS: Remove detect_memory_region()
On 02/26/2021 02:52 PM, Jiaxun Yang wrote:
在 2021/2/26 上午9:37, Jinyang He 写道:
On 02/24/2021 11:40 PM, Jiaxun Yang wrote:
On Wed, Feb 24, 2021, at 9:02 PM, Jinyang He wrote:
detect_memory_region() was committed by Commit 4d9f77d25268 ("MIPS:
add
detect_memory_region()"). Then it was equipped by Commit dd63b00804a5
("MIPS: ralink: make use of the new memory detection code") and
Commit 9b75733b7b5e ("MIPS: ath79: make use of the new memory
detection
code"). Its code is based on early ath79 platform code.
What puzzles me is that how memcmp() detect the memory region. If
`break`
was touched, the function could make sense. That means memcmp() should
return zero. Otherwise, the loop will be end by size > sz_max.
I have tested detect_memory_region() on Loongson64 3A3000. On our
design,
kseg0 low 256MB maps real memory and kseg0 high 256MB maps IO/PCI. The
function runs and last stopped on kseg1 where is uncached. In this
process
memcmp also returned non-zero when detected kseg0 high 256MB. Then
I did
another thing. memcpy first and test memcmp then (after &_end). It
works
well on 3A3000 but badly on 3A4000. Maybe because kseg0 high 256MB
maps
IO/PCI and it is dangerous to write like write memory.
At last, read memory from where is not memory region may always
return 0.
(Or trigger exception.) This function have been used several years and
seems no error occur. Maybe it's a fallback way.
That is not true for other platforms like ath79 or mtk.
They'll wrap around or return 0x for out of boundary accessing.
Loongson does not apply to this case as it have special "Address
Window"
design to accurately describe address regions.
Any access beyond described windows will be handled by MC and return
0 or random stuff.
Again, please don't make changes because you can.
Thanks.
- Jiaxun
Hi, Jiaxun,
Thank you for answering this puzzle for me in detail.
Assume that the machine has 8MB real memory and dm address is (base +
3M).
When size = 8MB, there will be a phenomenon of `wrap around`, the actual
content of (dm + 8M + 3M) is content of (dm + 3M), so it will trigger
`break`, right? At this time, the kernel will add 8M to the memory.
Hi Jingyang,
How can you boot kernel with 8M memory in present days ;-)
(Ohh with respect to Nintendo64 developer who had proven it's possible)
For what I can say, detect_memory_region exists because many devices
doesn't have a way to pass memory size information from bootloader to
kernel. Or their bootloader even don't care about memory size.
Kernel needs it to get memory size correctly. Although it seems fragile.
That's life, we must accept imperfect past and don't repeat it in future.
Thanks.
- Jiaxun
That's just a assume. Because it looks fresh to me.
Thank you very much. :-D
Thanks,
Jinyang
Re: [PATCH 4/4] kbuild: re-implement CONFIG_TRIM_UNUSED_KSYMS to make it work in one-pass
On Fri, Feb 26, 2021 at 6:20 AM Sami Tolvanen wrote: > > Hi Masahiro, > > On Thu, Feb 25, 2021 at 12:07 PM Masahiro Yamada wrote: > > > > On Fri, Feb 26, 2021 at 3:47 AM kernel test robot wrote: > > > > > > Hi Masahiro, > > > > > > I love your patch! Perhaps something to improve: > > > > > > [auto build test WARNING on linus/master] > > > [also build test WARNING on next-20210225] > > > [cannot apply to kbuild/for-next asm-generic/master arm64/for-next/core > > > m68k/for-next openrisc/for-next hp-parisc/for-next arc/for-next > > > uclinux-h8/h8300-next nios2/for-linus v5.11] > > > [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/Masahiro-Yamada/kbuild-build-speed-improvment-of-CONFIG_TRIM_UNUSED_KSYMS/20210226-000929 > > > base: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > > 29c395c77a9a514c5857c45ceae2665e9bd99ac7 > > > config: powerpc-mpc8313_rdb_defconfig (attached as .config) > > > compiler: powerpc-linux-gcc (GCC) 9.3.0 > > > 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 > > > # > > > https://github.com/0day-ci/linux/commit/014940331790a8cd9bee92c7201494ec3217201e > > > git remote add linux-review https://github.com/0day-ci/linux > > > git fetch --no-tags linux-review > > > Masahiro-Yamada/kbuild-build-speed-improvment-of-CONFIG_TRIM_UNUSED_KSYMS/20210226-000929 > > > git checkout 014940331790a8cd9bee92c7201494ec3217201e > > > # save the attached .config to linux build tree > > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > > > ARCH=powerpc > > > > > > If you fix the issue, kindly add following tag as appropriate > > > Reported-by: kernel test robot > > > > > > All warnings (new ones prefixed by >>): > > > > > > >> scripts/module.lds.S:7:5: warning: "CONFIG_TRIM_UNUSED_KSYMS" is not > > > >> defined, evaluates to 0 [-Wundef] > > > > Thanks. This should be #ifdef, of course. > > I applied this series and changed these from #if to #ifdef, but I > still see the following build error with TRIM_UNUSED_KSYMS + > OF_UNITTEST: > > In file included from drivers/of/unittest-data/testcases.dtb.S:1: > ../include/asm-generic/vmlinux.lds.h:54:10: fatal error: > 'generated/keep-ksyms.h' file not found > #include > ^~~~ > 1 error generated. > > This is with x86_64_defconfig and scripts/config -e OF -e OF_UNITTEST > -e TRIM_UNUSED_KSYMS. > > Sami Thanks. I will fix it. I will come back with v2 probably after v5.12-rc1 is tagged. -- Best Regards Masahiro Yamada
[PATCH v2 10/10] ARM: dts: stm32: Add Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit
Engicam EDIMM2.2 Starter Kit is an EDIMM 2.2 Form Factor Capacitive
Evaluation Board.
Genaral features:
- LCD 7" C.Touch
- microSD slot
- Ethernet 1Gb
- Wifi/BT
- 2x LVDS Full HD interfaces
- 3x USB 2.0
- 1x USB 3.0
- HDMI Out
- Mini PCIe
- MIPI CSI
- 2x CAN
- Audio Out
i.Core STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam.
i.Core STM32MP1 needs to mount on top of this Evaluation board for
creating complete i.Core STM32MP1 EDIMM2.2 Starter Kit.
Add support for it.
Signed-off-by: Jagan Teki
---
Changes for v2:
- new patch
arch/arm/boot/dts/Makefile| 1 +
.../stm32mp157a-icore-stm32mp1-edimm2.2.dts | 47 +++
2 files changed, 48 insertions(+)
create mode 100644 arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 6dc39bddaf7e..e86c46d7ca66 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1074,6 +1074,7 @@ dtb-$(CONFIG_ARCH_STM32) += \
stm32mp157a-microgea-stm32mp1-microdev2.0.dtb \
stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dtb \
stm32mp157a-icore-stm32mp1-ctouch2.dtb \
+ stm32mp157a-icore-stm32mp1-edimm2.2.dtb \
stm32mp157a-stinger96.dtb \
stm32mp157c-dhcom-pdk2.dtb \
stm32mp157c-dhcom-picoitx.dtb \
diff --git a/arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts
b/arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts
new file mode 100644
index ..ec9f1d1cd50f
--- /dev/null
+++ b/arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (c) STMicroelectronics 2019 - All Rights Reserved
+ * Copyright (c) 2020 Engicam srl
+ * Copyright (c) 2020 Amarula Solutons(India)
+ */
+
+/dts-v1/;
+#include "stm32mp157.dtsi"
+#include "stm32mp157a-icore-stm32mp1.dtsi"
+#include "stm32mp15-pinctrl.dtsi"
+#include "stm32mp15xxaa-pinctrl.dtsi"
+#include
+
+/ {
+ model = "Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit";
+ compatible = "engicam,icore-stm32mp1-edimm2.2",
+"engicam,icore-stm32mp1", "st,stm32mp157";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+ {
+ bus-width = <4>;
+ disable-wp;
+ pinctrl-names = "default", "opendrain", "sleep";
+ pinctrl-0 = <_b4_pins_a>;
+ pinctrl-1 = <_b4_od_pins_a>;
+ pinctrl-2 = <_b4_sleep_pins_a>;
+ st,neg-edge;
+ vmmc-supply = <>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default", "sleep", "idle";
+ pinctrl-0 = <_pins_a>;
+ pinctrl-1 = <_sleep_pins_a>;
+ pinctrl-2 = <_idle_pins_a>;
+ status = "okay";
+};
--
2.25.1
[PATCH v2 06/10] dt-bindings: arm: stm32: Add Engicam i.Core STM32MP1 C.TOUCH 2.0
i.Core STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam. C.TOUCH 2.0 is a general purpose carrier board with capacitive touch interface support. i.Core STM32MP1 needs to mount on top of this Carrier board for creating complete i.Core STM32MP1 C.TOUCH 2.0 board. Add bindings for it. Signed-off-by: Jagan Teki --- Changes for v2: - new patch Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 255d3ba50c63..3e45516403ce 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -65,6 +65,12 @@ properties: - const: st,stm32mp157c-ed1 - const: st,stm32mp157 + - description: Engicam i.Core STM32MP1 SoM based Boards +items: + - const: engicam,icore-stm32mp1-ctouch2# STM32MP1 Engicam i.Core STM32MP1 C.TOUCH 2.0 + - const: engicam,icore-stm32mp1# STM32MP1 Engicam i.Core STM32MP1 SoM + - const: st,stm32mp157 + - description: Engicam MicroGEA STM32MP1 SoM based Boards items: - enum: -- 2.25.1
[PATCH v2 03/10] ARM: dts: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 board
MicroDev 2.0 is a general purpose miniature carrier board with CAN,
LTE and LVDS panel interfaces.
Genaral features:
- Ethernet 10/100
- USB Type A
- Audio Out
- microSD
- LVDS panel connector
- Wifi/BT (option)
- UMTS LTE with sim connector (option)
MicroGEA STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam.
MicroGEA STM32MP1 needs to mount on top of this MicroDev 2.0 board
for creating complete MicroGEA STM32MP1 MicroDev 2.0 Carrier board.
Add support for it.
Signed-off-by: Matteo Lisi
Signed-off-by: Francesco Utel
Signed-off-by: Mirko Ardinghi
Signed-off-by: Jagan Teki
---
Changes for v2:
- don't create carrier board dtsi, add it in final dts.
arch/arm/boot/dts/Makefile| 1 +
...32mp157a-microgea-stm32mp1-microdev2.0.dts | 55 +++
2 files changed, 56 insertions(+)
create mode 100644
arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9f9f3e49132a..b4a9cd071f99 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1071,6 +1071,7 @@ dtb-$(CONFIG_ARCH_STM32) += \
stm32mp157a-dhcor-avenger96.dtb \
stm32mp157a-dk1.dtb \
stm32mp157a-iot-box.dtb \
+ stm32mp157a-microgea-stm32mp1-microdev2.0.dtb \
stm32mp157a-stinger96.dtb \
stm32mp157c-dhcom-pdk2.dtb \
stm32mp157c-dhcom-picoitx.dtb \
diff --git a/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dts
b/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dts
new file mode 100644
index ..7a75868164dc
--- /dev/null
+++ b/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dts
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (c) STMicroelectronics 2019 - All Rights Reserved
+ * Copyright (c) 2020 Engicam srl
+ * Copyright (c) 2020 Amarula Solutons(India)
+ */
+
+/dts-v1/;
+#include "stm32mp157.dtsi"
+#include "stm32mp157a-microgea-stm32mp1.dtsi"
+#include "stm32mp15-pinctrl.dtsi"
+#include "stm32mp15xxaa-pinctrl.dtsi"
+#include
+
+/ {
+ model = "Engicam MicroGEA STM32MP1 MicroDev 2.0 Carrier Board";
+ compatible = "engicam,microgea-stm32mp1-microdev2.0",
+"engicam,microgea-stm32mp1", "st,stm32mp157";
+
+ aliases {
+ serial0 =
+ serial1 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+ {
+ bus-width = <4>;
+ disable-wp;
+ pinctrl-names = "default", "opendrain", "sleep";
+ pinctrl-0 = <_b4_pins_a>;
+ pinctrl-1 = <_b4_od_pins_a>;
+ pinctrl-2 = <_b4_sleep_pins_a>;
+ st,neg-edge;
+ vmmc-supply = <>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default", "sleep", "idle";
+ pinctrl-0 = <_pins_a>;
+ pinctrl-1 = <_sleep_pins_a>;
+ pinctrl-2 = <_idle_pins_a>;
+ status = "okay";
+};
+
+/* J31: RS323 */
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>;
+ status = "okay";
+};
--
2.25.1
[PATCH v2 04/10] dt-bindings: arm: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 7" OF
MicroGEA STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam. MicroDev 2.0 is a general purpose miniature carrier board with CAN, LTE and LVDS panel interfaces. 7" OF is a capacitive touch 7" Open Frame panel solutions. MicroGEA STM32MP1 needs to mount on top of MicroDev 2.0 board with pluged 7" OF for creating complete MicroGEA STM32MP1 MicroDev 2.0 7" Open Frame Solution board. Add bindings for it. Acked-by: Rob Herring Signed-off-by: Jagan Teki --- Changes for v2: - collect a-b Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 56b7e0b800b3..255d3ba50c63 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -67,7 +67,9 @@ properties: - description: Engicam MicroGEA STM32MP1 SoM based Boards items: - - const: engicam,microgea-stm32mp1-microdev2.0 + - enum: + - engicam,microgea-stm32mp1-microdev2.0 + - engicam,microgea-stm32mp1-microdev2.0-of7 - const: engicam,microgea-stm32mp1 - const: st,stm32mp157 -- 2.25.1
[PATCH v2 09/10] dt-bindings: arm: stm32: Add Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit
i.Core STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam. EDIMM2.2 Starter Kit is an EDIMM 2.2 Form Factor Capacitive Evaluation Board from Engicam. i.Core STM32MP1 needs to mount on top of this Evaluation board for creating complete i.Core STM32MP1 EDIMM2.2 Starter Kit. Add bindings for it. Signed-off-by: Jagan Teki --- Changes for v2: - new patch Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index 3e45516403ce..01f595b8ae1b 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -67,7 +67,9 @@ properties: - description: Engicam i.Core STM32MP1 SoM based Boards items: - - const: engicam,icore-stm32mp1-ctouch2# STM32MP1 Engicam i.Core STM32MP1 C.TOUCH 2.0 + - enum: + - engicam,icore-stm32mp1-ctouch2 # STM32MP1 Engicam i.Core STM32MP1 C.TOUCH 2.0 + - engicam,icore-stm32mp1-edimm2.2 # STM32MP1 Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit - const: engicam,icore-stm32mp1# STM32MP1 Engicam i.Core STM32MP1 SoM - const: st,stm32mp157 -- 2.25.1
[PATCH v2 05/10] ARM: dts: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 7" OF
7" OF is a capacitive touch 7" Open Frame panel solutions with
- 7" AUO B101AW03 LVDS panel
- EDT, FT5526 Touch
MicroGEA STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam.
MicroDev 2.0 is a general purpose miniature carrier board with CAN,
LTE and LVDS panel interfaces.
MicroGEA STM32MP1 needs to mount on top of MicroDev 2.0 board with
pluged 7" OF for creating complete MicroGEA STM32MP1 MicroDev 2.0
7" Open Frame Solution board.
Add support for it.
Signed-off-by: Matteo Lisi
Signed-off-by: Francesco Utel
Signed-off-by: Mirko Ardinghi
Signed-off-by: Jagan Teki
---
Changes for v2:
- don't create carrier board dtsi, add it in final dts.
arch/arm/boot/dts/Makefile| 1 +
...157a-microgea-stm32mp1-microdev2.0-of7.dts | 154 ++
2 files changed, 155 insertions(+)
create mode 100644
arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b4a9cd071f99..1332622a3f9f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1072,6 +1072,7 @@ dtb-$(CONFIG_ARCH_STM32) += \
stm32mp157a-dk1.dtb \
stm32mp157a-iot-box.dtb \
stm32mp157a-microgea-stm32mp1-microdev2.0.dtb \
+ stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dtb \
stm32mp157a-stinger96.dtb \
stm32mp157c-dhcom-pdk2.dtb \
stm32mp157c-dhcom-picoitx.dtb \
diff --git
a/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
b/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
new file mode 100644
index ..674b2d330dc4
--- /dev/null
+++ b/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (c) STMicroelectronics 2019 - All Rights Reserved
+ * Copyright (c) 2020 Engicam srl
+ * Copyright (c) 2020 Amarula Solutons(India)
+ */
+
+/dts-v1/;
+#include "stm32mp157.dtsi"
+#include "stm32mp157a-microgea-stm32mp1.dtsi"
+#include "stm32mp15-pinctrl.dtsi"
+#include "stm32mp15xxaa-pinctrl.dtsi"
+#include
+
+/ {
+ model = "Engicam MicroGEA STM32MP1 MicroDev 2.0 7\" Open Frame";
+ compatible = "engicam,microgea-stm32mp1-microdev2.0-of7",
+"engicam,microgea-stm32mp1", "st,stm32mp157";
+
+ aliases {
+ serial0 =
+ serial1 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ backlight: backlight {
+ compatible = "gpio-backlight";
+ gpios = < 13 GPIO_ACTIVE_HIGH>;
+ default-on;
+ };
+
+ lcd_3v3: regulator-lcd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = < 10 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ power-supply = <_pwr>;
+ };
+
+ panel_pwr: regulator-panel-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "panel_pwr";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = < 10 GPIO_ACTIVE_HIGH>;
+ regulator-always-on;
+ };
+
+ panel {
+ compatible = "auo,b101aw03";
+ backlight = <>;
+ enable-gpios = < 2 GPIO_ACTIVE_HIGH>;
+ power-supply = <_3v3>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_ep0_out>;
+ };
+ };
+ };
+};
+
+ {
+ i2c-scl-falling-time-ns = <20>;
+ i2c-scl-rising-time-ns = <185>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <_pins_a>;
+ pinctrl-1 = <_sleep_pins_a>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+
+ port {
+ ltdc_ep0_out: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_in>;
+ };
+ };
+};
+
+ {
+ ltdc_pins: ltdc {
+ pins {
+ pinmux = , /* LTDC_B2 */
+, /* LTDC_R6 */
+, /* LTDC_R5 */
+, /* LTDC_B3 */
+, /* LTDC_B0 */
+, /* LTDC_G0 */
+, /* LTDC_G1 */
+, /* LTDC_DE */
+, /* LTDC_R7 */
+, /* LTDC_CLK */
+, /* LTDC_B1 */
+, /* LTDC_R0 */
+, /* LTDC_R1
[PATCH v2 01/10] dt-bindings: arm: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0
MicroGEA STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam. MicroDev 2.0 is a general purpose miniature carrier board with CAN, LTE and LVDS panel interfaces. MicroGEA STM32MP1 needs to mount on top of this MicroDev 2.0 board for creating complete MicroGEA STM32MP1 MicroDev 2.0 Carrier board. Add bindings for it. Signed-off-by: Jagan Teki --- Changes for v2: - none Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index e7525a3395e5..56b7e0b800b3 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -64,6 +64,13 @@ properties: - const: st,stm32mp157c-ev1 - const: st,stm32mp157c-ed1 - const: st,stm32mp157 + + - description: Engicam MicroGEA STM32MP1 SoM based Boards +items: + - const: engicam,microgea-stm32mp1-microdev2.0 + - const: engicam,microgea-stm32mp1 + - const: st,stm32mp157 + - description: Octavo OSD32MP15x System-in-Package based boards items: - enum: -- 2.25.1
[PATCH v2 08/10] ARM: dts: stm32: Add Engicam i.Core STM32MP1 C.TOUCH 2.0
Engicam C.TOUCH 2.0 is an EDIMM compliant general purpose Carrier
board.
Genaral features:
- Ethernet 10/100
- Wifi/BT
- USB Type A/OTG
- Audio Out
- CAN
- LVDS panel connector
i.Core STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam.
i.Core STM32MP1 needs to mount on top of this Carrier board for
creating complete i.Core STM32MP1 C.TOUCH 2.0 board.
Add support for it.
Signed-off-by: Jagan Teki
---
Changes for v2:
- new patch
arch/arm/boot/dts/Makefile| 1 +
.../stm32mp157a-icore-stm32mp1-ctouch2.dts| 47 +++
2 files changed, 48 insertions(+)
create mode 100644 arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 1332622a3f9f..6dc39bddaf7e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1073,6 +1073,7 @@ dtb-$(CONFIG_ARCH_STM32) += \
stm32mp157a-iot-box.dtb \
stm32mp157a-microgea-stm32mp1-microdev2.0.dtb \
stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dtb \
+ stm32mp157a-icore-stm32mp1-ctouch2.dtb \
stm32mp157a-stinger96.dtb \
stm32mp157c-dhcom-pdk2.dtb \
stm32mp157c-dhcom-picoitx.dtb \
diff --git a/arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts
b/arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts
new file mode 100644
index ..d3058a036c74
--- /dev/null
+++ b/arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (c) STMicroelectronics 2019 - All Rights Reserved
+ * Copyright (c) 2020 Engicam srl
+ * Copyright (c) 2020 Amarula Solutons(India)
+ */
+
+/dts-v1/;
+#include "stm32mp157.dtsi"
+#include "stm32mp157a-icore-stm32mp1.dtsi"
+#include "stm32mp15-pinctrl.dtsi"
+#include "stm32mp15xxaa-pinctrl.dtsi"
+#include
+
+/ {
+ model = "Engicam i.Core STM32MP1 C.TOUCH 2.0";
+ compatible = "engicam,icore-stm32mp1-ctouch2",
+"engicam,icore-stm32mp1", "st,stm32mp157";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+ {
+ bus-width = <4>;
+ disable-wp;
+ pinctrl-names = "default", "opendrain", "sleep";
+ pinctrl-0 = <_b4_pins_a>;
+ pinctrl-1 = <_b4_od_pins_a>;
+ pinctrl-2 = <_b4_sleep_pins_a>;
+ st,neg-edge;
+ vmmc-supply = <>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default", "sleep", "idle";
+ pinctrl-0 = <_pins_a>;
+ pinctrl-1 = <_sleep_pins_a>;
+ pinctrl-2 = <_idle_pins_a>;
+ status = "okay";
+};
--
2.25.1
[PATCH v2 00/10] ARM: dts: stm32: Add Engicam STM32MP1 SoM
This is the initial series to support Engicam MicroGEA STM32MP1 and i.Core STM32MP1 SoM and it's associated carrier board dts(i) support. Changes for v2: - fixed v1 comments - add i.Core STM32MP1 SoM Jagan Teki (10): dt-bindings: arm: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 ARM: dts: stm32: Add Engicam MicroGEA STM32MP1 SoM ARM: dts: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 board dt-bindings: arm: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 7" OF ARM: dts: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 7" OF dt-bindings: arm: stm32: Add Engicam i.Core STM32MP1 C.TOUCH 2.0 ARM: dts: stm32: Add Engicam i.Core STM32MP1 SoM ARM: dts: stm32: Add Engicam i.Core STM32MP1 C.TOUCH 2.0 dt-bindings: arm: stm32: Add Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit ARM: dts: stm32: Add Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit .../devicetree/bindings/arm/stm32/stm32.yaml | 17 ++ arch/arm/boot/dts/Makefile| 4 + .../stm32mp157a-icore-stm32mp1-ctouch2.dts| 47 + .../stm32mp157a-icore-stm32mp1-edimm2.2.dts | 47 + .../boot/dts/stm32mp157a-icore-stm32mp1.dtsi | 195 ++ ...157a-microgea-stm32mp1-microdev2.0-of7.dts | 154 ++ ...32mp157a-microgea-stm32mp1-microdev2.0.dts | 55 + .../dts/stm32mp157a-microgea-stm32mp1.dtsi| 147 + 8 files changed, 666 insertions(+) create mode 100644 arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts create mode 100644 arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts create mode 100644 arch/arm/boot/dts/stm32mp157a-icore-stm32mp1.dtsi create mode 100644 arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts create mode 100644 arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dts create mode 100644 arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1.dtsi -- 2.25.1
[PATCH v2 07/10] ARM: dts: stm32: Add Engicam i.Core STM32MP1 SoM
i.Core STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam.
General features:
- STM32MP157A
- Up to 1GB DDR3L
- 4GB eMMC
- 10/100 Ethernet
- USB 2.0 Host/OTG
- I2S
- MIPI DSI to LVDS
- rest of STM32MP157A features
i.Core STM32MP1 needs to mount on top of Engicam baseboards
for creating complete platform solutions.
Add support for it.
Signed-off-by: Jagan Teki
---
Changes for v2:
- new patch
.../boot/dts/stm32mp157a-icore-stm32mp1.dtsi | 195 ++
1 file changed, 195 insertions(+)
create mode 100644 arch/arm/boot/dts/stm32mp157a-icore-stm32mp1.dtsi
diff --git a/arch/arm/boot/dts/stm32mp157a-icore-stm32mp1.dtsi
b/arch/arm/boot/dts/stm32mp157a-icore-stm32mp1.dtsi
new file mode 100644
index ..c8e4b68c5661
--- /dev/null
+++ b/arch/arm/boot/dts/stm32mp157a-icore-stm32mp1.dtsi
@@ -0,0 +1,195 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (c) STMicroelectronics 2019 - All Rights Reserved
+ * Copyright (c) 2020 Engicam srl
+ * Copyright (c) 2020 Amarula Solutons(India)
+ */
+
+/ {
+ compatible = "engicam,icore-stm32mp1", "st,stm32mp157";
+
+ memory@c000 {
+ reg = <0xc000 0x2000>;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ mcuram2: mcuram2@1000 {
+ compatible = "shared-dma-pool";
+ reg = <0x1000 0x4>;
+ no-map;
+ };
+
+ vdev0vring0: vdev0vring0@1004 {
+ compatible = "shared-dma-pool";
+ reg = <0x1004 0x1000>;
+ no-map;
+ };
+
+ vdev0vring1: vdev0vring1@10041000 {
+ compatible = "shared-dma-pool";
+ reg = <0x10041000 0x1000>;
+ no-map;
+ };
+
+ vdev0buffer: vdev0buffer@10042000 {
+ compatible = "shared-dma-pool";
+ reg = <0x10042000 0x4000>;
+ no-map;
+ };
+
+ mcuram: mcuram@3000 {
+ compatible = "shared-dma-pool";
+ reg = <0x3000 0x4>;
+ no-map;
+ };
+
+ retram: retram@3800 {
+ compatible = "shared-dma-pool";
+ reg = <0x3800 0x1>;
+ no-map;
+ };
+ };
+
+ vddcore: regulator-vddcore {
+ compatible = "regulator-fixed";
+ regulator-name = "vddcore";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ regulator-always-on;
+ };
+
+ vdd: regulator-vdd {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ vdd_usb: regulator-vdd-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_usb";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ vdda: regulator-vdda {
+ compatible = "regulator-fixed";
+ regulator-name = "vdda";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ vdd_ddr: regulator-vdd-ddr {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_ddr";
+ regulator-min-microvolt = <135>;
+ regulator-max-microvolt = <135>;
+ regulator-always-on;
+ };
+
+ vtt_ddr: regulator-vtt-ddr {
+ compatible = "regulator-fixed";
+ regulator-name = "vtt_ddr";
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <675000>;
+ regulator-always-on;
+ vin-supply = <>;
+ };
+
+ vref_ddr: regulator-vref-ddr {
+ compatible = "regulator-fixed";
+ regulator-name = "vref_ddr";
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <675000>;
+ regulator-always-on;
+ vin-supply = <>;
+ };
+
+ vdd_sd: regulator-vdd-sd {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_sd";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ v3v3: regulator-v3v3 {
+ compatible = "regulator-fixed";
+
[PATCH v2 02/10] ARM: dts: stm32: Add Engicam MicroGEA STM32MP1 SoM
MicroGEA STM32MP1 is an EDIMM SoM based on STM32MP157A from Engicam.
General features:
- STM32MP157AAC
- Up to 1GB DDR3L-800
- 512MB Nand flash
- I2S
MicroGEA STM32MP1 needs to mount on top of Engicam MicroDev carrier
boards for creating complete platform solutions.
Add support for it.
Signed-off-by: Matteo Lisi
Signed-off-by: Francesco Utel
Signed-off-by: Mirko Ardinghi
Signed-off-by: Jagan Teki
---
Changes for v2:
- none
.../dts/stm32mp157a-microgea-stm32mp1.dtsi| 147 ++
1 file changed, 147 insertions(+)
create mode 100644 arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1.dtsi
diff --git a/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1.dtsi
b/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1.dtsi
new file mode 100644
index ..97d569107bfe
--- /dev/null
+++ b/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1.dtsi
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (c) STMicroelectronics 2019 - All Rights Reserved
+ * Copyright (c) 2020 Engicam srl
+ * Copyright (c) 2020 Amarula Solutons(India)
+ */
+
+/ {
+ compatible = "engicam,microgea-stm32mp1", "st,stm32mp157";
+
+ memory@c000 {
+ reg = <0xc000 0x1000>;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ mcuram2: mcuram2@1000 {
+ compatible = "shared-dma-pool";
+ reg = <0x1000 0x4>;
+ no-map;
+ };
+
+ vdev0vring0: vdev0vring0@1004 {
+ compatible = "shared-dma-pool";
+ reg = <0x1004 0x1000>;
+ no-map;
+ };
+
+ vdev0vring1: vdev0vring1@10041000 {
+ compatible = "shared-dma-pool";
+ reg = <0x10041000 0x1000>;
+ no-map;
+ };
+
+ vdev0buffer: vdev0buffer@10042000 {
+ compatible = "shared-dma-pool";
+ reg = <0x10042000 0x4000>;
+ no-map;
+ };
+
+ mcuram: mcuram@3000 {
+ compatible = "shared-dma-pool";
+ reg = <0x3000 0x4>;
+ no-map;
+ };
+
+ retram: retram@3800 {
+ compatible = "shared-dma-pool";
+ reg = <0x3800 0x1>;
+ no-map;
+ };
+ };
+
+ vin: regulator-vin {
+ compatible = "regulator-fixed";
+ regulator-name = "vin";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ };
+
+ vddcore: regulator-vddcore {
+ compatible = "regulator-fixed";
+ regulator-name = "vddcore";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ regulator-always-on;
+ vin-supply = <>;
+ };
+
+ vdd: regulator-vdd {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ vin-supply = <>;
+ };
+
+ vddq_ddr: regulator-vddq-ddr {
+ compatible = "regulator-fixed";
+ regulator-name = "vddq_ddr";
+ regulator-min-microvolt = <135>;
+ regulator-max-microvolt = <135>;
+ regulator-always-on;
+ vin-supply = <>;
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <_pins_a>;
+ pinctrl-1 = <_sleep_pins_a>;
+ status = "okay";
+
+ nand-controller@4,0 {
+ status = "okay";
+
+ nand@0 {
+ reg = <0>;
+ nand-on-flash-bbt;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+{
+ timeout-sec = <32>;
+ status = "okay";
+};
+
+_rproc{
+ memory-region = <>, <>, <>, <>,
+ <>, <>;
+ mboxes = < 0>, < 1>, < 2>;
+ mbox-names = "vq0", "vq1", "shutdown";
+ interrupt-parent = <>;
+ interrupts = <68 1>;
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+{
+ status = "okay";
+};
+
+ {
+ regulator-min-microvolt = <250>;
+ regulator-max-microvolt = <250>;
+ vdda-supply = <>;
+ status = "okay";
+};
--
2.25.1
Re: [PATCH] kgdb: Fix to kill breakpoints on initmem after boot
+ stable ML
On Thu, 25 Feb 2021 at 21:26, Daniel Thompson
wrote:
>
> On Wed, Feb 24, 2021 at 01:46:52PM +0530, Sumit Garg wrote:
> > Currently breakpoints in kernel .init.text section are not handled
> > correctly while allowing to remove them even after corresponding pages
> > have been freed.
> >
> > Fix it via killing .init.text section breakpoints just prior to initmem
> > pages being freed.
> >
> > Suggested-by: Doug Anderson
> > Signed-off-by: Sumit Garg
>
> I saw Andrew has picked this one up. That's ok for me:
> Acked-by: Daniel Thompson
>
> I already enriched kgdbtest to cover this (and they pass) so I guess
> this is also:
> Tested-by: Daniel Thompson
>
Thanks Daniel.
> BTW this is not Cc:ed to stable and I do wonder if it crosses the
> threshold to be considered a fix rather than a feature. Normally I
> consider adding safety rails for kgdb to be a new feature but, in this
> case, the problem would easily ensnare an inexperienced developer who is
> doing nothing more than debugging their own driver (assuming they
> correctly marked their probe function as .init) so I think this weighs
> in favour of being a fix.
>
Makes sense, Cc:ed stable.
-Sumit
>
> Daniel.
>
>
> > ---
> > include/linux/kgdb.h | 2 ++
> > init/main.c | 1 +
> > kernel/debug/debug_core.c | 11 +++
> > 3 files changed, 14 insertions(+)
> >
> > diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
> > index 57b8885708e5..3aa503ef06fc 100644
> > --- a/include/linux/kgdb.h
> > +++ b/include/linux/kgdb.h
> > @@ -361,9 +361,11 @@ extern atomic_t kgdb_active;
> > extern bool dbg_is_early;
> > extern void __init dbg_late_init(void);
> > extern void kgdb_panic(const char *msg);
> > +extern void kgdb_free_init_mem(void);
> > #else /* ! CONFIG_KGDB */
> > #define in_dbg_master() (0)
> > #define dbg_late_init()
> > static inline void kgdb_panic(const char *msg) {}
> > +static inline void kgdb_free_init_mem(void) { }
> > #endif /* ! CONFIG_KGDB */
> > #endif /* _KGDB_H_ */
> > diff --git a/init/main.c b/init/main.c
> > index c68d784376ca..a446ca3d334e 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -1417,6 +1417,7 @@ static int __ref kernel_init(void *unused)
> > async_synchronize_full();
> > kprobe_free_init_mem();
> > ftrace_free_init_mem();
> > + kgdb_free_init_mem();
> > free_initmem();
> > mark_readonly();
> >
> > diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
> > index 229dd119f430..319381e95d1d 100644
> > --- a/kernel/debug/debug_core.c
> > +++ b/kernel/debug/debug_core.c
> > @@ -465,6 +465,17 @@ int dbg_remove_all_break(void)
> > return 0;
> > }
> >
> > +void kgdb_free_init_mem(void)
> > +{
> > + int i;
> > +
> > + /* Clear init memory breakpoints. */
> > + for (i = 0; i < KGDB_MAX_BREAKPOINTS; i++) {
> > + if (init_section_contains((void *)kgdb_break[i].bpt_addr, 0))
> > + kgdb_break[i].state = BP_UNDEFINED;
> > + }
> > +}
> > +
> > #ifdef CONFIG_KGDB_KDB
> > void kdb_dump_stack_on_cpu(int cpu)
> > {
> > --
> > 2.25.1
Re: [PATCH 3/7] regulator: qcom-rpmh: Correct the pmic5_hfsmps515 buck
Hi,
On 2021-02-25 16:39, Dmitry Baryshkov wrote:
On 24/02/2021 11:33, satya priya wrote:
Correct the REGULATOR_LINEAR_RANGE and n_voltges for
pmic5_hfsmps515 buck.
Signed-off-by: satya priya
---
drivers/regulator/qcom-rpmh-regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/qcom-rpmh-regulator.c
b/drivers/regulator/qcom-rpmh-regulator.c
index 79a554f..36542c3 100644
--- a/drivers/regulator/qcom-rpmh-regulator.c
+++ b/drivers/regulator/qcom-rpmh-regulator.c
@@ -726,8 +726,8 @@ static const struct rpmh_vreg_hw_data
pmic5_ftsmps510 = {
static const struct rpmh_vreg_hw_data pmic5_hfsmps515 = {
.regulator_type = VRM,
.ops = _regulator_vrm_ops,
- .voltage_range = REGULATOR_LINEAR_RANGE(280, 0, 4, 16000),
- .n_voltages = 5,
+ .voltage_range = REGULATOR_LINEAR_RANGE(32, 0, 235, 16000),
+ .n_voltages = 236,
I've checked the docs for pm8009, the chip which also uses hfsmps515
regulators. The pdf clearly states that the 'Output voltage operating
range' is from 2.8 V to 2.85 V.
So we'd probably need to define different versions of HFS515 regulator
data (like I had to create for pm8009-1).
The min-max voltages for S1C (PM8350c) regulator are 219-221uV
for sc7280(kodiak), so we had to modify this buck to support this
regulator.
AFAIK, this struct defines the HW constraints of a regulator, but the
platform specific min-max values can be controlled from DT files. So,
can't we modify it like above instead of adding a new definition? the
new min_uV value (32000) is anyway not exceeding the old value (280)
right? please correct me if wrong.
.pmic_mode_map = pmic_mode_map_pmic5_smps,
.of_map_mode = rpmh_regulator_pmic4_smps_of_map_mode,
};
Thanks,
Satya Priya
Re: [PATCH v5 2/2] counter: add IRQ or GPIO based event counter
On Fri, Feb 26, 2021 at 07:46:01AM +0100, Oleksij Rempel wrote: > On Wed, Feb 24, 2021 at 05:20:21PM +0900, William Breathitt Gray wrote: > > On Wed, Feb 24, 2021 at 05:11:03PM +0900, William Breathitt Gray wrote: > > > On Wed, Feb 24, 2021 at 08:35:06AM +0100, Oleksij Rempel wrote: > > > > On Wed, Feb 24, 2021 at 11:34:06AM +0900, William Breathitt Gray wrote: > > > > > Alternatively, we can take a more generic approach: ignore the GPIO > > > > > names and focus solely on the IRQ lines; because the GPIO lines will > > > > > always be tied to respective IRQ lines here, using the IRQ as the > > > > > basis > > > > > of the name should always be valid. The "name" member of the struct > > > > > irq_chip can work for this. I haven't tested this, but I think > > > > > something > > > > > like this would work: > > > > > > > > > > cnt_signals[0].name = irq_get_chip(priv->irq)->name; > > > > > > > > ok, i'll take a look at it. > > > > > > If that doesn't work, then use devm_kasprintf() to generate the name > > > based on the IRQ line number. The idea here is that the user should be > > > able to identify that the Signal component for this Count is the > > > respective IRQ. > > > > > > William Breathitt Gray > > > > I realized that these irq_chip names are often just the device name > > which isn't very useful either. :-( > > > > In that case, I suppose we really are just left with generating the name > > based on the IRQ line number then. This should be fine then: > > > > cnt_signals[0].name = devm_kasprintf(dev, GFP_KERNEL, "IRQ %d", > > priv->irq); > > if (!cnt_signals[0].name) > > return -ENOMEM; > > > > I think this would make it clear to the user that this Signal is the > > respective IRQ (whether sourced from GPIO or not). > > ack, with one correction. cnt_signals should be allocated, otherwise > this value will be set per driver not per device. > > Regards, > Oleksij > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | Yes you're right, cnt_signals will need to be allocated then because these will be different per device. Thanks, William Breathitt Gray signature.asc Description: PGP signature
general protection fault in kvm_hv_irq_routing_update
Hello,
syzbot found the following issue on:
HEAD commit:a99163e9 Merge tag 'devicetree-for-5.12' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12d72682d0
kernel config: https://syzkaller.appspot.com/x/.config?x=7a875029a795d230
dashboard link: https://syzkaller.appspot.com/bug?extid=6987f3b2dbd9eda95f12
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12faef12d0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=163342ccd0
The issue was bisected to:
commit 8f014550dfb114cc7f42a517d20d2cf887a0b771
Author: Vitaly Kuznetsov
Date: Tue Jan 26 13:48:14 2021 +
KVM: x86: hyper-v: Make Hyper-V emulation enablement conditional
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10df16a8d0
final oops: https://syzkaller.appspot.com/x/report.txt?x=12df16a8d0
console output: https://syzkaller.appspot.com/x/log.txt?x=14df16a8d0
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+6987f3b2dbd9eda95...@syzkaller.appspotmail.com
Fixes: 8f014550dfb1 ("KVM: x86: hyper-v: Make Hyper-V emulation enablement
conditional")
L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for
details.
general protection fault, probably for non-canonical address
0xdc28: [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0140-0x0147]
CPU: 1 PID: 8370 Comm: syz-executor859 Not tainted 5.11.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:synic_get arch/x86/kvm/hyperv.c:165 [inline]
RIP: 0010:kvm_hv_set_sint_gsi arch/x86/kvm/hyperv.c:475 [inline]
RIP: 0010:kvm_hv_irq_routing_update+0x230/0x460 arch/x86/kvm/hyperv.c:498
Code: 80 19 00 00 48 89 f8 48 c1 e8 03 80 3c 28 00 0f 85 ff 01 00 00 4d 8b ad
80 19 00 00 49 8d bd 40 01 00 00 48 89 f8 48 c1 e8 03 <0f> b6 04 28 84 c0 74 06
0f 8e d2 01 00 00 45 0f b6 bd 40 01 00 00
RSP: 0018:c90001b3fac0 EFLAGS: 00010206
RAX: 0028 RBX: 888012df5900 RCX:
RDX: 888022193780 RSI: 81174d43 RDI: 0140
RBP: dc00 R08: R09: c900018819eb
R10: 81170f3e R11: R12:
R13: R14: R15: 0001
FS: 00a73300() GS:8880b9d0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 557e8c876888 CR3: 13c0b000 CR4: 001526e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
kvm_set_irq_routing+0x69b/0x940 arch/x86/kvm/../../../virt/kvm/irqchip.c:223
kvm_vm_ioctl+0x12d0/0x2800 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3959
vfs_ioctl fs/ioctl.c:48 [inline]
__do_sys_ioctl fs/ioctl.c:753 [inline]
__se_sys_ioctl fs/ioctl.c:739 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x43ef29
Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01
c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:7ffe391eb808 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 00400488 RCX: 0043ef29
RDX: 2140 RSI: 4008ae6a RDI: 0004
RBP: 00402f10 R08: 00400488 R09: 00400488
R10: 00400488 R11: 0246 R12: 00402fa0
R13: R14: 004ac018 R15: 00400488
Modules linked in:
---[ end trace 2aa75ec1dd148710 ]---
RIP: 0010:synic_get arch/x86/kvm/hyperv.c:165 [inline]
RIP: 0010:kvm_hv_set_sint_gsi arch/x86/kvm/hyperv.c:475 [inline]
RIP: 0010:kvm_hv_irq_routing_update+0x230/0x460 arch/x86/kvm/hyperv.c:498
Code: 80 19 00 00 48 89 f8 48 c1 e8 03 80 3c 28 00 0f 85 ff 01 00 00 4d 8b ad
80 19 00 00 49 8d bd 40 01 00 00 48 89 f8 48 c1 e8 03 <0f> b6 04 28 84 c0 74 06
0f 8e d2 01 00 00 45 0f b6 bd 40 01 00 00
RSP: 0018:c90001b3fac0 EFLAGS: 00010206
RAX: 0028 RBX: 888012df5900 RCX:
RDX: 888022193780 RSI: 81174d43 RDI: 0140
RBP: dc00 R08: R09: c900018819eb
R10: 81170f3e R11: R12:
R13: R14: R15: 0001
FS: 00a73300() GS:8880b9d0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 557e8c876888 CR3: 13c0b000 CR4: 001526e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
---
This
Re: [PATCH 5.10 00/23] 5.10.19-rc1 review
On Thu, 25 Feb 2021 at 15:24, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.10.19 release. > There are 23 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat, 27 Feb 2021 09:25:06 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.19-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.10.19-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.10.y git commit: 6ffb943c0e01d843a06842f9a7bcfc008e10a6d2 git describe: v5.10.18-24-g6ffb943c0e01 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.18-24-g6ffb943c0e01 No regressions (compared to build v5.10.18) No fixes (compared to build v5.10.18) Ran 50352 total tests in the following environments and test suites. Environments -- - arc - arm - arm64 - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - mips - nxp-ls2088 - nxp-ls2088-64k_page_size - parisc - powerpc - qemu-arm-clang - qemu-arm64-clang - qemu-arm64-kasan - qemu-x86_64-clang - qemu-x86_64-kasan - qemu-x86_64-kcsan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - riscv - s390 - sh - sparc - x15 - x86 - x86-kasan - x86_64 Test Suites --- * build * linux-log-parser * install-android-platform-tools-r2600 * kselftest-android * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-efivarfs * kselftest-filesystems * kselftest-firmware * kselftest-fpu * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-livepatch * kselftest-ptrace * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * fwts * kselftest- * kselftest-kvm * kselftest-lib * kselftest-membarrier * kselftest-memfd * kselftest-memory-hotplug * kselftest-mincore * kselftest-mount * kselftest-mqueue * kselftest-net * kselftest-netfilter * kselftest-nsfs * kselftest-openat2 * kselftest-pid_namespace * kselftest-pidfd * kselftest-proc * kselftest-pstore * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-tc-testing * ltp-dio-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-mm-tests * network-basic-tests * perf * kselftest-bpf * kselftest-kexec * kselftest-lkdtm * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-vm * kselftest-x86 * kselftest-zram * ltp-controllers-tests * ltp-open-posix-tests * v4l2-compliance * kvm-unit-tests * kunit * rcutorture * ssuite -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] kgdb: Fix to kill breakpoints on initmem after boot
On Wed, 24 Feb 2021 at 23:50, Andrew Morton wrote: > > On Wed, 24 Feb 2021 10:09:25 -0800 Doug Anderson > wrote: > > > On Wed, Feb 24, 2021 at 12:17 AM Sumit Garg wrote: > > > > > > Currently breakpoints in kernel .init.text section are not handled > > > correctly while allowing to remove them even after corresponding pages > > > have been freed. > > > > > > Fix it via killing .init.text section breakpoints just prior to initmem > > > pages being freed. > > > > It might be worth it to mention that HW breakpoints aren't handled by > > this patch but it's probably not such a big deal. > > I added that to the changelog, thanks. > Thanks Andrew for picking this up. -Sumit > I'll take your response to be the coveted acked-by :)
Re: [PATCH] kgdb: Fix to kill breakpoints on initmem after boot
On Wed, 24 Feb 2021 at 23:39, Doug Anderson wrote:
>
> Hi,
>
> On Wed, Feb 24, 2021 at 12:17 AM Sumit Garg wrote:
> >
> > Currently breakpoints in kernel .init.text section are not handled
> > correctly while allowing to remove them even after corresponding pages
> > have been freed.
> >
> > Fix it via killing .init.text section breakpoints just prior to initmem
> > pages being freed.
>
> It might be worth it to mention that HW breakpoints aren't handled by
> this patch but it's probably not such a big deal.
>
>
> > Suggested-by: Doug Anderson
> > Signed-off-by: Sumit Garg
> > ---
> > include/linux/kgdb.h | 2 ++
> > init/main.c | 1 +
> > kernel/debug/debug_core.c | 11 +++
> > 3 files changed, 14 insertions(+)
> >
> > diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
> > index 57b8885708e5..3aa503ef06fc 100644
> > --- a/include/linux/kgdb.h
> > +++ b/include/linux/kgdb.h
> > @@ -361,9 +361,11 @@ extern atomic_tkgdb_active;
> > extern bool dbg_is_early;
> > extern void __init dbg_late_init(void);
> > extern void kgdb_panic(const char *msg);
> > +extern void kgdb_free_init_mem(void);
> > #else /* ! CONFIG_KGDB */
> > #define in_dbg_master() (0)
> > #define dbg_late_init()
> > static inline void kgdb_panic(const char *msg) {}
> > +static inline void kgdb_free_init_mem(void) { }
> > #endif /* ! CONFIG_KGDB */
> > #endif /* _KGDB_H_ */
> > diff --git a/init/main.c b/init/main.c
> > index c68d784376ca..a446ca3d334e 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -1417,6 +1417,7 @@ static int __ref kernel_init(void *unused)
> > async_synchronize_full();
> > kprobe_free_init_mem();
> > ftrace_free_init_mem();
> > + kgdb_free_init_mem();
> > free_initmem();
> > mark_readonly();
> >
> > diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
> > index 229dd119f430..319381e95d1d 100644
> > --- a/kernel/debug/debug_core.c
> > +++ b/kernel/debug/debug_core.c
> > @@ -465,6 +465,17 @@ int dbg_remove_all_break(void)
> > return 0;
> > }
> >
> > +void kgdb_free_init_mem(void)
> > +{
> > + int i;
> > +
> > + /* Clear init memory breakpoints. */
> > + for (i = 0; i < KGDB_MAX_BREAKPOINTS; i++) {
> > + if (init_section_contains((void *)kgdb_break[i].bpt_addr,
> > 0))
>
> A nit, but instead of 0 should this be passing "BREAK_INSTR_SIZE" ?
>
> Also: even if memory is about to get freed it still seems like it'd be
> wise to call this:
>
> kgdb_arch_remove_breakpoint(_break[i]);
>
> It looks like it shouldn't matter today but just in case an
> architecture decides to do something fancy in the future it might not
> hurt to tell it that the breakpoint is going away.
>
>
> Everything here is pretty nitty, though. This looks good to me now.
>
> Reviewed-by: Douglas Anderson
Thanks Doug for your review.
-Sumit
Re: [PATCH RFC] MIPS: Remove detect_memory_region()
在 2021/2/26 上午9:37, Jinyang He 写道:
On 02/24/2021 11:40 PM, Jiaxun Yang wrote:
On Wed, Feb 24, 2021, at 9:02 PM, Jinyang He wrote:
detect_memory_region() was committed by Commit 4d9f77d25268 ("MIPS: add
detect_memory_region()"). Then it was equipped by Commit dd63b00804a5
("MIPS: ralink: make use of the new memory detection code") and
Commit 9b75733b7b5e ("MIPS: ath79: make use of the new memory detection
code"). Its code is based on early ath79 platform code.
What puzzles me is that how memcmp() detect the memory region. If
`break`
was touched, the function could make sense. That means memcmp() should
return zero. Otherwise, the loop will be end by size > sz_max.
I have tested detect_memory_region() on Loongson64 3A3000. On our
design,
kseg0 low 256MB maps real memory and kseg0 high 256MB maps IO/PCI. The
function runs and last stopped on kseg1 where is uncached. In this
process
memcmp also returned non-zero when detected kseg0 high 256MB. Then I
did
another thing. memcpy first and test memcmp then (after &_end). It
works
well on 3A3000 but badly on 3A4000. Maybe because kseg0 high 256MB maps
IO/PCI and it is dangerous to write like write memory.
At last, read memory from where is not memory region may always
return 0.
(Or trigger exception.) This function have been used several years and
seems no error occur. Maybe it's a fallback way.
That is not true for other platforms like ath79 or mtk.
They'll wrap around or return 0x for out of boundary accessing.
Loongson does not apply to this case as it have special "Address Window"
design to accurately describe address regions.
Any access beyond described windows will be handled by MC and return
0 or random stuff.
Again, please don't make changes because you can.
Thanks.
- Jiaxun
Hi, Jiaxun,
Thank you for answering this puzzle for me in detail.
Assume that the machine has 8MB real memory and dm address is (base +
3M).
When size = 8MB, there will be a phenomenon of `wrap around`, the actual
content of (dm + 8M + 3M) is content of (dm + 3M), so it will trigger
`break`, right? At this time, the kernel will add 8M to the memory.
Hi Jingyang,
How can you boot kernel with 8M memory in present days ;-)
(Ohh with respect to Nintendo64 developer who had proven it's possible)
For what I can say, detect_memory_region exists because many devices
doesn't have a way to pass memory size information from bootloader to
kernel. Or their bootloader even don't care about memory size.
Kernel needs it to get memory size correctly. Although it seems fragile.
That's life, we must accept imperfect past and don't repeat it in future.
Thanks.
- Jiaxun
Thanks,
Jinyang
[PATCH v3] fs/locks: print full locks information
Commit fd7732e033e3 ("fs/locks: create a tree of dependent requests.")
has put blocked locks into a tree.
So, with a for loop, we can't check all locks information.
To solve this problem, we should traverse the tree.
Signed-off-by: Luo Longjun
---
fs/locks.c | 65 ++
1 file changed, 56 insertions(+), 9 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 99ca97e81b7a..ecaecd1f1b58 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -2828,7 +2828,7 @@ struct locks_iterator {
};
static void lock_get_status(struct seq_file *f, struct file_lock *fl,
- loff_t id, char *pfx)
+ loff_t id, char *pfx, int repeat)
{
struct inode *inode = NULL;
unsigned int fl_pid;
@@ -2844,7 +2844,11 @@ static void lock_get_status(struct seq_file *f, struct
file_lock *fl,
if (fl->fl_file != NULL)
inode = locks_inode(fl->fl_file);
- seq_printf(f, "%lld:%s ", id, pfx);
+ seq_printf(f, "%lld: ", id);
+
+ if (repeat)
+ seq_printf(f, "%*s", repeat - 1 + (int)strlen(pfx), pfx);
+
if (IS_POSIX(fl)) {
if (fl->fl_flags & FL_ACCESS)
seq_puts(f, "ACCESS");
@@ -2906,21 +2910,64 @@ static void lock_get_status(struct seq_file *f, struct
file_lock *fl,
}
}
+static struct file_lock *get_next_blocked_member(struct file_lock *node)
+{
+ struct file_lock *tmp;
+
+ /* NULL node or root node */
+ if (node == NULL || node->fl_blocker == NULL)
+ return NULL;
+
+ /* Next member in the linked list could be itself */
+ tmp = list_next_entry(node, fl_blocked_member);
+ if (list_entry_is_head(tmp, >fl_blocker->fl_blocked_requests,
fl_blocked_member)
+ || tmp == node) {
+ return NULL;
+ }
+
+ return tmp;
+}
+
static int locks_show(struct seq_file *f, void *v)
{
struct locks_iterator *iter = f->private;
- struct file_lock *fl, *bfl;
+ struct file_lock *cur, *tmp;
struct pid_namespace *proc_pidns =
proc_pid_ns(file_inode(f->file)->i_sb);
+ int level = 0;
- fl = hlist_entry(v, struct file_lock, fl_link);
+ cur = hlist_entry(v, struct file_lock, fl_link);
- if (locks_translate_pid(fl, proc_pidns) == 0)
+ if (locks_translate_pid(cur, proc_pidns) == 0)
return 0;
- lock_get_status(f, fl, iter->li_pos, "");
+ /* View this crossed linked list as a binary tree, the first member of
fl_blocked_requests
+* is the left child of current node, the next silibing in
fl_blocked_member is the
+* right child, we can alse get the parent of current node from
fl_blocker, so this
+* question becomes traversal of a binary tree
+*/
+ while (cur != NULL) {
+ if (level)
+ lock_get_status(f, cur, iter->li_pos, "-> ", level);
+ else
+ lock_get_status(f, cur, iter->li_pos, "", level);
- list_for_each_entry(bfl, >fl_blocked_requests, fl_blocked_member)
- lock_get_status(f, bfl, iter->li_pos, " ->");
+ if (!list_empty(>fl_blocked_requests)) {
+ /* Turn left */
+ cur =
list_first_entry_or_null(>fl_blocked_requests,
+ struct file_lock, fl_blocked_member);
+ level++;
+ } else {
+ /* Turn right */
+ tmp = get_next_blocked_member(cur);
+ /* Fall back to parent node */
+ while (tmp == NULL && cur->fl_blocker != NULL) {
+ cur = cur->fl_blocker;
+ level--;
+ tmp = get_next_blocked_member(cur);
+ }
+ cur = tmp;
+ }
+ }
return 0;
}
@@ -2941,7 +2988,7 @@ static void __show_fd_locks(struct seq_file *f,
(*id)++;
seq_puts(f, "lock:\t");
- lock_get_status(f, fl, *id, "");
+ lock_get_status(f, fl, *id, "", 0);
}
}
--
2.17.1
Re: [PATCH v3 1/2] dt-bindings: iommu: add bindings for sprd iommu
On Tue, 16 Feb 2021 at 23:10, Robin Murphy wrote:
>
> On 2021-02-10 19:21, Rob Herring wrote:
> > On Fri, Feb 5, 2021 at 1:21 AM Chunyan Zhang wrote:
> >>
> >> Hi Rob,
> >>
> >> On Fri, 5 Feb 2021 at 07:25, Rob Herring wrote:
> >>>
> >>> On Wed, Feb 03, 2021 at 05:07:26PM +0800, Chunyan Zhang wrote:
> From: Chunyan Zhang
>
> This iommu module can be used by Unisoc's multimedia devices, such as
> display, Image codec(jpeg) and a few signal processors, including
> VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor),
> etc.
>
> Signed-off-by: Chunyan Zhang
> ---
> .../devicetree/bindings/iommu/sprd,iommu.yaml | 72 +++
> 1 file changed, 72 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
>
> diff --git a/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> new file mode 100644
> index ..4fc99e81fa66
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright 2020 Unisoc Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iommu/sprd,iommu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Unisoc IOMMU and Multi-media MMU
> +
> +maintainers:
> + - Chunyan Zhang
> +
> +properties:
> + compatible:
> +enum:
> + - sprd,iommu-v1
> +
> + "#iommu-cells":
> +const: 0
> +description:
> + Unisoc IOMMUs are all single-master IOMMU devices, therefore no
> + additional information needs to associate with its master device.
> + Please refer to the generic bindings document for more details,
> + Documentation/devicetree/bindings/iommu/iommu.txt
> +
> + reg:
> +maxItems: 1
> +description:
> + Not required if 'sprd,iommu-regs' is defined.
> +
> + clocks:
> +description:
> + Reference to a gate clock phandle, since access to some of IOMMUs
> are
> + controlled by gate clock, but this is not required.
> +
> + sprd,iommu-regs:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +description:
> + Reference to a syscon phandle plus 1 cell, the syscon defines the
> + register range used by the iommu and the media device, the cell
> + defines the offset for iommu registers. Since iommu module shares
> + the same register range with the media device which uses it.
> +
> +required:
> + - compatible
> + - "#iommu-cells"
>
> OK, so apparently the hardware is not quite as trivial as my initial
> impression, and you should have interrupts as well.
Ok, I will have a look.
>
> +
> +oneOf:
> + - required:
> + - reg
> + - required:
> + - sprd,iommu-regs
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +iommu_disp: iommu-disp {
> + compatible = "sprd,iommu-v1";
> + sprd,iommu-regs = <_regs 0x800>;
> >>>
> >>> If the IOMMU is contained within another device, then it should just be
> >>> a child node of that device.
> >>
> >> Yes, actually IOMMU can be seen as a child of multimedia devices, I
> >> considered moving IOMMU under into multimedia device node, but
> >> multimedia devices need IOMMU when probe[1], so I dropped that idea.
> >
> > Don't design your binding around working-around linux issues.
>
> Having stumbled across the DRM driver patches the other day, I now see
> where this is coming from, and it's even worse than that - this whole
> binding seems to be largely working around bad driver design.
>
I guess you mean bad h/w design (not bad driver design)?
Having this syscon node just because I don't want a same register
range to be mapped to multiple virtual address ranges, and that's the
case for many media devices and their IOMMUs. If this issue exsists
for one device only, I can even endure, but that's not unfortunately.
But anyway, as you all think this is not a good way, I will change to
use reg property.
> >> And they share the same register base, e.g.
> >>
> >> + mm {
> >> + compatible = "simple-bus";
> >> + #address-cells = <2>;
> >> + #size-cells = <2>;
> >> + ranges;
> >> +
> >> + dpu_regs: syscon@6300 {
> >
> > Drop this node.
> >
> >> + compatible = "sprd,sc9863a-dpuregs",
> >> "syscon";
> >> + reg = <0 0x6300 0 0x1000>;
> >> + };
> >> +
> >> +
Re: [PATCH v5 2/2] counter: add IRQ or GPIO based event counter
On Wed, Feb 24, 2021 at 05:20:21PM +0900, William Breathitt Gray wrote: > On Wed, Feb 24, 2021 at 05:11:03PM +0900, William Breathitt Gray wrote: > > On Wed, Feb 24, 2021 at 08:35:06AM +0100, Oleksij Rempel wrote: > > > On Wed, Feb 24, 2021 at 11:34:06AM +0900, William Breathitt Gray wrote: > > > > Alternatively, we can take a more generic approach: ignore the GPIO > > > > names and focus solely on the IRQ lines; because the GPIO lines will > > > > always be tied to respective IRQ lines here, using the IRQ as the basis > > > > of the name should always be valid. The "name" member of the struct > > > > irq_chip can work for this. I haven't tested this, but I think something > > > > like this would work: > > > > > > > > cnt_signals[0].name = irq_get_chip(priv->irq)->name; > > > > > > ok, i'll take a look at it. > > > > If that doesn't work, then use devm_kasprintf() to generate the name > > based on the IRQ line number. The idea here is that the user should be > > able to identify that the Signal component for this Count is the > > respective IRQ. > > > > William Breathitt Gray > > I realized that these irq_chip names are often just the device name > which isn't very useful either. :-( > > In that case, I suppose we really are just left with generating the name > based on the IRQ line number then. This should be fine then: > > cnt_signals[0].name = devm_kasprintf(dev, GFP_KERNEL, "IRQ %d", >priv->irq); > if (!cnt_signals[0].name) > return -ENOMEM; > > I think this would make it clear to the user that this Signal is the > respective IRQ (whether sourced from GPIO or not). ack, with one correction. cnt_signals should be allocated, otherwise this value will be set per driver not per device. Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v14 01/11] x86: kdump: replace the hard-coded alignment with macro CRASH_ALIGN
On 2021/2/25 15:25, Baoquan He wrote:
> On 02/24/21 at 02:19pm, Catalin Marinas wrote:
>> On Sat, Jan 30, 2021 at 03:10:15PM +0800, Chen Zhou wrote:
>>> Move CRASH_ALIGN to header asm/kexec.h for later use. Besides, the
>>> alignment of crash kernel regions in x86 is 16M(CRASH_ALIGN), but
>>> function reserve_crashkernel() also used 1M alignment. So just
>>> replace hard-coded alignment 1M with macro CRASH_ALIGN.
>> [...]
>>> @@ -510,7 +507,7 @@ static void __init reserve_crashkernel(void)
>>> } else {
>>> unsigned long long start;
>>>
>>> - start = memblock_phys_alloc_range(crash_size, SZ_1M, crash_base,
>>> + start = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
>>> crash_base,
>>> crash_base + crash_size);
>>> if (start != crash_base) {
>>> pr_info("crashkernel reservation failed - memory is in
>>> use.\n");
>> There is a small functional change here for x86. Prior to this patch,
>> crash_base passed by the user on the command line is allowed to be 1MB
>> aligned. With this patch, such reservation will fail.
>>
>> Is the current behaviour a bug in the current x86 code or it does allow
>> 1MB-aligned reservations?
> Hmm, you are right. Here we should keep 1MB alignment as is because
> users specify the address and size, their intention should be respected.
> The 1MB alignment for fixed memory region reservation was introduced in
> below commit, but it doesn't tell what is Eric's request at that time, I
> guess it meant respecting users' specifying.
I think we could make the alignment unified. Why is the alignment system
reserved and
user specified different? Besides, there is no document about the 1MB alignment.
How about adding the alignment size(16MB) in doc if user specified start
address as arm64 does.
Thanks,
Chen Zhou
>
> commit 44280733e71ad15377735b42d8538c109c94d7e3
> Author: Yinghai Lu
> Date: Sun Nov 22 17:18:49 2009 -0800
>
> x86: Change crash kernel to reserve via reserve_early()
>
> use find_e820_area()/reserve_early() instead.
>
> -v2: address Eric's request, to restore original semantics.
> will fail, if the provided address can not be used.
>
> .
>
Re: [PATCH 5.10 00/23] 5.10.19-rc1 review
Hi Greg, On 2021/2/25 17:53, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.10.19 release. There are 23 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat, 27 Feb 2021 09:25:06 +. Anything received after that time might be too late. It takes longer time to set up our test farm than I expected, for now we can run test on x86 for stable 5.10, test for ARM64 server and other stable kernels (4.19 and 5.4) is in progress (needs more machines and a rack in the data center), please give us a bit more time to get things ready. Here is the test results for x86, compiled and booted OK, also no regressions for the functional test [1] (the failed ones are the mismatch of the testcase and the test environment, not the kernel failures), Tested-by: Hulk Robot Thanks Hanjun [1]: Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Branch: linux-5.10.y Arch: x86 Version: 5.10.19-rc1+ Commit: 6ffb943c0e01d843a06842f9a7bcfc008e10a6d2 Compiler: gcc version 8.3.1 (GCC) Testcase Result Summary: total_num: 4739 succeed_num: 4732 failed_num: 7 timeout_num: 0 Testsuites List: autotest crackerjack kernel_selftests ltp-aiodio ltp-aio-stress ltp-controllers ltp-openposix ltp-can ltp-cap_bounds ltp-commands ltp-connectors ltp-containers ltp-cpuhotplug ltp-crashme ltp-crypto ltp-cve ltp-dio ltp-dma_thread_diotest ltp-fcntl-locktests ltp-filecaps ltp-fs ltp-fs_bind ltp-fs_perms_simple ltp-fs_readonly ltp-fsx ltp-hugetlb ltp-hyperthreading ltp-ima ltp-input ltp-io ltp-io_cd ltp-io_floppy ltp-ipc ltp-kernel_misc ltp-fsstress ltp-fsx-linux ltp-math ltp-mm ltp-nptl ltp-numa ltp-power_management_tests ltp-power_management_tests_exclusive ltp-pty ltp-sched ltp-scsi_debug ltp-securebits ltp-smack ltp-smoketest ltp-syscalls ltp-tracing ltp-uevent ltp-realtime memory_ksm security_audit
Re: [PATCH v8 1/1] mm/page_alloc.c: refactor initialization of struct page for holes in memory layout
On Fri, Feb 26, 2021 at 12:43:51AM +0200, Mike Rapoport wrote:
> From: Mike Rapoport
>
> There could be struct pages that are not backed by actual physical memory.
> This can happen when the actual memory bank is not a multiple of
> SECTION_SIZE or when an architecture does not register memory holes
> reserved by the firmware as memblock.memory.
>
> Such pages are currently initialized using init_unavailable_mem() function
> that iterates through PFNs in holes in memblock.memory and if there is a
> struct page corresponding to a PFN, the fields of this page are set to
> default values and it is marked as Reserved.
>
> init_unavailable_mem() does not take into account zone and node the page
> belongs to and sets both zone and node links in struct page to zero.
>
> Before commit 73a6e474cb37 ("mm: memmap_init: iterate over memblock regions
> rather that check each PFN") the holes inside a zone were re-initialized
> during memmap_init() and got their zone/node links right. However, after
> that commit nothing updates the struct pages representing such holes.
>
> On a system that has firmware reserved holes in a zone above ZONE_DMA, for
> instance in a configuration below:
>
> # grep -A1 E820 /proc/iomem
> 7a17b000-7a216fff : Unknown E820 type
> 7a217000-7bff : System RAM
>
> unset zone link in struct page will trigger
>
> VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page), pfn), page);
>
> in set_pfnblock_flags_mask() when called with a struct page from a range
> other than E820_TYPE_RAM because there are pages in the range of ZONE_DMA32
> but the unset zone link in struct page makes them appear as a part of
> ZONE_DMA.
>
> Interleave initialization of the unavailable pages with the normal
> initialization of memory map, so that zone and node information will be
> properly set on struct pages that are not backed by the actual memory.
>
> With this change the pages for holes inside a zone will get proper
> zone/node links and the pages that are not spanned by any node will get
> links to the adjacent zone/node. The holes between nodes will be prepended
> to the zone/node above the hole and the trailing pages in the last section
> that will be appended to the zone/node below.
>
> Fixes: 73a6e474cb37 ("mm: memmap_init: iterate over memblock regions rather
> that check each PFN")
> Signed-off-by: Mike Rapoport
> Reported-by: Qian Cai
> Reported-by: Andrea Arcangeli
> Reviewed-by: Baoquan He
> Acked-by: Vlastimil Babka
> ---
> mm/page_alloc.c | 158 +++-
> 1 file changed, 75 insertions(+), 83 deletions(-)
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Re: [PATCH V1 2/2] backlight: qcom-wled: Correct the sync_toggle sequence
On 2021-02-24 16:56, Daniel Thompson wrote: On Wed, Feb 24, 2021 at 09:20:48AM +0530, Kiran Gunda wrote: Currently the FSC SYNC_BIT and MOD_SYNC_BIT are toggled from 1 to 0 to update the FSC and brightenss settings. Change this sequence form 0 to 1 as per the hardware team recommendation to update the FSC and brightness correctly. Again... this patch description feels somewhat rushed. A patch description is there to support code reviewer and to go on the version history to assist with future maintainance. They matter! Anyhow I don't recognise the "from 1 to 0" in the code since both before an after the change it goes "from 0 to 1" and "from 1 to 0" but in a different order. Doesn't the code actually currently implement "set then clear"? If so then, likewise the new code is adopting "clear then set". I would have used "set" and "clear" instead of "0" and "1". Yes. The current code implementation is "set" all SYN bits and then "clear" all SYNC bits. The new code is modified to change the sequence from "clear" first and then "set" to ensure both FSC and brightness are updated. As with patch 1, the sync bits modified by wled3_sync_toggle singular or plural? It is plural. We have to "clear" and "set" all sync bits. Finally a description that is more sympathetic to the reviewer would be welcome. For example the following (if my guess is right and it is true) makes things much easier for the reviewer: Sure. I will update the documentation and patch description clearly. "The sync takes place during a 0 to 1 transition of the sync bits so the hardware team recommends a clear-then-set approach in order to guarantee such a transition regardless of the previous register state". Daniel. Signed-off-by: Kiran Gunda --- drivers/video/backlight/qcom-wled.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c index aef52b9..19f83ac 100644 --- a/drivers/video/backlight/qcom-wled.c +++ b/drivers/video/backlight/qcom-wled.c @@ -337,13 +337,13 @@ static int wled3_sync_toggle(struct wled *wled) rc = regmap_update_bits(wled->regmap, wled->ctrl_addr + WLED3_SINK_REG_SYNC, - mask, mask); + mask, WLED3_SINK_REG_SYNC_CLEAR); if (rc < 0) return rc; rc = regmap_update_bits(wled->regmap, wled->ctrl_addr + WLED3_SINK_REG_SYNC, - mask, WLED3_SINK_REG_SYNC_CLEAR); + mask, mask); return rc; } @@ -353,17 +353,17 @@ static int wled5_mod_sync_toggle(struct wled *wled) int rc; u8 val; - val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT : -WLED5_SINK_REG_SYNC_MOD_B_BIT; rc = regmap_update_bits(wled->regmap, wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT, - WLED5_SINK_REG_SYNC_MASK, val); + WLED5_SINK_REG_SYNC_MASK, 0); if (rc < 0) return rc; + val = (wled->cfg.mod_sel == MOD_A) ? WLED5_SINK_REG_SYNC_MOD_A_BIT : +WLED5_SINK_REG_SYNC_MOD_B_BIT; return regmap_update_bits(wled->regmap, wled->sink_addr + WLED5_SINK_REG_MOD_SYNC_BIT, - WLED5_SINK_REG_SYNC_MASK, 0); + WLED5_SINK_REG_SYNC_MASK, val); } static int wled_ovp_fault_status(struct wled *wled, bool *fault_set) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v11 0/2] UIO support for dfl devices
On Fri, Feb 26, 2021 at 09:22:37AM +0800, Xu Yilun wrote: > On Mon, Feb 22, 2021 at 10:56:45AM -0800, Tom Rix wrote: > > Yilun, > > > > Is there anything outstanding or remaining to be done ? > > Sorry for late reply. No, this is my lastest version now. > > > Hi Greg: > > Do you have some comments on this patchset? It's the middle of the merge window, I can't accept anything right now... But this doesn't even look like it is in my "to review" queue anymore, which means that there must have been a lot of discussion on it and others asking for changes, so why not work on that right now while you can and resubmit it when you have done that? No need to ever wait on me for fixing things up. greg k-h
[PATCH for Dwaipayan] MAINTAINERS: clarify responsibility for checkpatch documentation
As discussed, Dwaipayan and Lukas take the responsibility for maintaining the checkpatch documentation that is currently being built up. To be sure that the checkpatch maintainers and the corresponding documentation maintainers can keep the content synchronized, add them as reviewers to the counterpart. Link: https://lore.kernel.org/lkml/bcee822d1934772f47702ee257bc735c8f467088.ca...@perches.com/ Signed-off-by: Lukas Bulwahn --- applies cleanly on next-20210226 Dwaipayan, you probably want to add this patch to your patch series for checkpatch documentation. Feel free to add your Signed-off-by tag just following mine. MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 16ada1a4b751..6b48b79ba284 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4181,9 +4181,18 @@ X: drivers/char/tpm/ CHECKPATCH M: Andy Whitcroft M: Joe Perches +R: Dwaipayan Ray +R: Lukas Bulwahn S: Maintained F: scripts/checkpatch.pl +CHECKPATCH DOCUMENTATION +M: Dwaipayan Ray +M: Lukas Bulwahn +R: Joe Perches +S: Maintained +F: Documentation/dev-tools/checkpatch.rst + CHINESE DOCUMENTATION M: Harry Wei M: Alex Shi -- 2.17.1
[PATCH] kbuild: do not include include/config/auto.conf from adjust_autoksyms.sh
Commit cd195bc4775a ("kbuild: split adjust_autoksyms.sh in two parts")
split out the code that needs include/config/auto.conf.
This script no longer needs to include include/config/auto.conf.
Fixes: cd195bc4775a ("kbuild: split adjust_autoksyms.sh in two parts")
Signed-off-by: Masahiro Yamada
---
scripts/adjust_autoksyms.sh | 3 ---
1 file changed, 3 deletions(-)
diff --git a/scripts/adjust_autoksyms.sh b/scripts/adjust_autoksyms.sh
index 2b366d945ccb..d8f6f9c63043 100755
--- a/scripts/adjust_autoksyms.sh
+++ b/scripts/adjust_autoksyms.sh
@@ -34,9 +34,6 @@ case "$KBUILD_VERBOSE" in
;;
esac
-# We need access to CONFIG_ symbols
-. include/config/auto.conf
-
# Generate a new symbol list file
$CONFIG_SHELL $srctree/scripts/gen_autoksyms.sh "$new_ksyms_file"
--
2.27.0
Re: [PATCH v4] i2c: virtio: add a virtio i2c frontend driver
On 2021/2/26 12:21, Viresh Kumar wrote: On 26-02-21, 10:46, Jie Deng wrote: This v4 was the old version before the specification was acked by the virtio tc. Following is the latest specification. https://raw.githubusercontent.com/oasis-tcs/virtio-spec/master/virtio-i2c.tex I will send the v5 since the host/guest ABI changes. Okay, now it makes some sense :) I am interested in this stuff, if possible please keep me Cc'd for following versions, thanks. Sure. I will add you to the Cc list.
Re: [PATCH v4 17/19] coresight: core: Add support for dedicated percpu sinks
Hi Suzuki,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on next-20210226]
[cannot apply to kvmarm/next arm64/for-next/core tip/perf/core v5.11]
[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/Suzuki-K-Poulose/arm64-coresight-Add-support-for-ETE-and-TRBE/20210226-035447
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
6fbd6cf85a3be127454a1ad58525a3adcf8612ab
config: arm-randconfig-r024-20210225 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
a921aaf789912d981cbb2036bdc91ad7289e1523)
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 arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
#
https://github.com/0day-ci/linux/commit/c37564326cdf11e0839eae06c1bfead47d3e5775
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Suzuki-K-Poulose/arm64-coresight-Add-support-for-ETE-and-TRBE/20210226-035447
git checkout c37564326cdf11e0839eae06c1bfead47d3e5775
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/hwtracing/coresight/coresight-core.c:800:6: error: implicit
>> declaration of function 'coresight_is_percpu_source'
>> [-Werror,-Wimplicit-function-declaration]
if (coresight_is_percpu_source(csdev) &&
coresight_is_percpu_sink(sink) &&
^
>> drivers/hwtracing/coresight/coresight-core.c:800:43: error: implicit
>> declaration of function 'coresight_is_percpu_sink'
>> [-Werror,-Wimplicit-function-declaration]
if (coresight_is_percpu_source(csdev) &&
coresight_is_percpu_sink(sink) &&
^
drivers/hwtracing/coresight/coresight-core.c:1024:7: error: implicit
declaration of function 'coresight_is_percpu_source'
[-Werror,-Wimplicit-function-declaration]
if (coresight_is_percpu_source(csdev))
^
3 errors generated.
vim +/coresight_is_percpu_source +800
drivers/hwtracing/coresight/coresight-core.c
775
776 /**
777 * _coresight_build_path - recursively build a path from a @csdev to a
sink.
778 * @csdev: The device to start from.
779 * @sink: The final sink we want in this path.
780 * @path: The list to add devices to.
781 *
782 * The tree of Coresight device is traversed until an activated sink is
783 * found. From there the sink is added to the list along with all the
784 * devices that led to that point - the end result is a list from source
785 * to sink. In that list the source is the first device and the sink the
786 * last one.
787 */
788 static int _coresight_build_path(struct coresight_device *csdev,
789 struct coresight_device *sink,
790 struct list_head *path)
791 {
792 int i, ret;
793 bool found = false;
794 struct coresight_node *node;
795
796 /* An activated sink has been found. Enqueue the element */
797 if (csdev == sink)
798 goto out;
799
> 800 if (coresight_is_percpu_source(csdev) &&
> coresight_is_percpu_sink(sink) &&
801 sink == per_cpu(csdev_sink,
source_ops(csdev)->cpu_id(csdev))) {
802 if (_coresight_build_path(sink, sink, path) == 0) {
803 found = true;
804 goto out;
805 }
806 }
807
808 /* Not a sink - recursively explore each port found on this
element */
809 for (i = 0; i < csdev->pdata->nr_outport; i++) {
810 struct coresight_device *child_dev;
811
812 child_dev = csdev->pdata->conns[i].child_dev;
813 if (child_dev &&
814 _coresight_build_path(child_dev, sink, path) == 0) {
815 found = true;
816 break;
817 }
818 }
819
820 if (!found)
821 return -ENODEV;
822
823 out:
824 /*
825
[PATCH net] net: dsa: mt7530: don't build GPIO support if !GPIOLIB
The new GPIO support may be optional at runtime, but it requires
building against gpiolib:
ERROR: modpost: "gpiochip_get_data" [drivers/net/dsa/mt7530.ko]
undefined!
ERROR: modpost: "devm_gpiochip_add_data_with_key"
[drivers/net/dsa/mt7530.ko] undefined!
Add #ifdef to exclude GPIO support if GPIOLIB is not enabled.
Fixes: 429a0edeefd8 ("net: dsa: mt7530: MT7530 optional GPIO support")
Reported-by: Arnd Bergmann
Signed-off-by: DENG Qingfang
---
drivers/net/dsa/mt7530.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index c17de2bcf2fe..f06f5fa2f898 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1624,6 +1624,7 @@ mtk_get_tag_protocol(struct dsa_switch *ds, int port,
}
}
+#ifdef CONFIG_GPIOLIB
static inline u32
mt7530_gpio_to_bit(unsigned int offset)
{
@@ -1726,6 +1727,7 @@ mt7530_setup_gpio(struct mt7530_priv *priv)
return devm_gpiochip_add_data(dev, gc, priv);
}
+#endif /* CONFIG_GPIOLIB */
static int
mt7530_setup(struct dsa_switch *ds)
@@ -1868,11 +1870,13 @@ mt7530_setup(struct dsa_switch *ds)
}
}
+#ifdef CONFIG_GPIOLIB
if (of_property_read_bool(priv->dev->of_node, "gpio-controller")) {
ret = mt7530_setup_gpio(priv);
if (ret)
return ret;
}
+#endif /* CONFIG_GPIOLIB */
mt7530_setup_port5(ds, interface);
--
2.25.1
Re: [PATCH V1 1/2] backlight: qcom-wled: Fix FSC update issue for WLED5
On 2021-02-24 16:45, Daniel Thompson wrote:
On Wed, Feb 24, 2021 at 09:20:47AM +0530, Kiran Gunda wrote:
Currently, for WLED5, after FSC register update MOD_SYNC_BIT
is toggled instead of SYNC_BIT. MOD_SYNC_BIT has to be toggled
after the brightness update and SYNC_BIT has to be toggled after
FSC update for WLED5. Fix it.
Code looks fine but the description is a difficult to read (which makes
mining the history difficult).
Basically the descriptions here are very hard to read without the
context in PATCH 0/2. Since PATCH 0/2 won't enter the version history
that means these descriptions need to integrate some of the text from
what is currently PATCH 0/2.
I would expect this to be more like. It is basically joining together
text from PATCH 0 and PATCH 1 (I also switched to plural form for SYNC
bits... the code in the driver has mask generation based on the number
of strings, is that right?):
Sorry for the trouble. Yes, you are correct. The mask generation is
based on the number of strings defined in the device tree and only those
strings are enabled. However, there is no issue if the SYNC bits of all
the strings are cleared/set. The SYNC takes place only for enabled
strings.
~~~
Currently, for WLED5, the FSC (Full scale current) setting is not
updated properly due to driver toggling the wrong register after an FSC
update.
On WLED5 we should only toggle the MOD_SYNC bit after a brightness
update. For an FSC update we need to toggle the SYNC bits instead.
Fix it by adopting the common wled3_sync_toggle() for WLED5 and
introducing new code to the brightness update path to
compensate.
~~~
I will update the Documentation/patch description clearly
as suggested.
Daniel.
Signed-off-by: Kiran Gunda
---
drivers/video/backlight/qcom-wled.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index 3bc7800..aef52b9 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -348,7 +348,7 @@ static int wled3_sync_toggle(struct wled *wled)
return rc;
}
-static int wled5_sync_toggle(struct wled *wled)
+static int wled5_mod_sync_toggle(struct wled *wled)
{
int rc;
u8 val;
@@ -445,10 +445,23 @@ static int wled_update_status(struct
backlight_device *bl)
goto unlock_mutex;
}
- rc = wled->wled_sync_toggle(wled);
- if (rc < 0) {
- dev_err(wled->dev, "wled sync failed rc:%d\n", rc);
- goto unlock_mutex;
+ if (wled->version < 5) {
+ rc = wled->wled_sync_toggle(wled);
+ if (rc < 0) {
+ dev_err(wled->dev, "wled sync failed rc:%d\n",
rc);
+ goto unlock_mutex;
+ }
+ } else {
+ /*
+* For WLED5 toggling the MOD_SYNC_BIT updates the
+* brightness
+*/
+ rc = wled5_mod_sync_toggle(wled);
+ if (rc < 0) {
+ dev_err(wled->dev, "wled mod sync failed
rc:%d\n",
+ rc);
+ goto unlock_mutex;
+ }
}
}
@@ -1459,7 +1472,7 @@ static int wled_configure(struct wled *wled)
size = ARRAY_SIZE(wled5_opts);
*cfg = wled5_config_defaults;
wled->wled_set_brightness = wled5_set_brightness;
- wled->wled_sync_toggle = wled5_sync_toggle;
+ wled->wled_sync_toggle = wled3_sync_toggle;
wled->wled_cabc_config = wled5_cabc_config;
wled->wled_ovp_delay = wled5_ovp_delay;
wled->wled_auto_detection_required =
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
Re: [PATCH] virt: acrn: add hotplug_cpu dependency
On Fri 26.Feb'21 at 7:25:18 +0100, Greg Kroah-Hartman wrote: On Fri, Feb 26, 2021 at 09:38:07AM +0800, Shuo A Liu wrote: Hi Arnd, There is already a patchset for this build issue. Please refer to https://lore.kernel.org/lkml/20210221134339.57851-1-shuo.a@intel.com/. Hi Greg, Would you like accept that patchset in you tree? I can't take anything new in my tree until 5.12-rc1 is out. When that happens I will go through everything submitted to me and merge fixes like this one and get them sent to Linus in a week or so. OK. Thanks for the information. Thanks shuo
[PATCH v2] kbuild: fix UNUSED_KSYMS_WHITELIST for Clang LTO
Commit fbe078d397b4 ("kbuild: lto: add a default list of used symbols")
does not work as expected if the .config file has already specified
CONFIG_UNUSED_KSYMS_WHITELIST="my/own/white/list" before enabling
CONFIG_LTO_CLANG.
So, the user-supplied whitelist and LTO-specific white list must be
independent of each other.
I refactored the shell script so CONFIG_MODVERSIONS and CONFIG_CLANG_LTO
handle whitelists in the same way.
Fixes: fbe078d397b4 ("kbuild: lto: add a default list of used symbols")
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Rebase on top of Arnd's patch:
https://lore.kernel.org/lkml/20210225143456.3829513-1-a...@kernel.org/
init/Kconfig| 1 -
scripts/gen_autoksyms.sh| 35 -
scripts/lto-used-symbollist.txt | 6 --
3 files changed, 26 insertions(+), 16 deletions(-)
delete mode 100644 scripts/lto-used-symbollist.txt
diff --git a/init/Kconfig b/init/Kconfig
index 719871f8727c..64c32300d1b4 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2283,7 +2283,6 @@ config TRIM_UNUSED_KSYMS
config UNUSED_KSYMS_WHITELIST
string "Whitelist of symbols to keep in ksymtab"
depends on TRIM_UNUSED_KSYMS
- default "scripts/lto-used-symbollist.txt" if LTO_CLANG
help
By default, all unused exported symbols will be un-exported from the
build when TRIM_UNUSED_KSYMS is selected.
diff --git a/scripts/gen_autoksyms.sh b/scripts/gen_autoksyms.sh
index d54dfba15bf2..da320151e7c3 100755
--- a/scripts/gen_autoksyms.sh
+++ b/scripts/gen_autoksyms.sh
@@ -19,7 +19,26 @@ esac
# We need access to CONFIG_ symbols
. include/config/auto.conf
-ksym_wl=/dev/null
+needed_symbols=
+
+# Special case for modversions (see modpost.c)
+if [ -n "$CONFIG_MODVERSIONS" ]; then
+ needed_symbols="$needed_symbols module_layout"
+fi
+
+# With CONFIG_LTO_CLANG, LLVM bitcode has not yet been compiled into a binary
+# when the .mod files are generated, which means they don't yet contain
+# references to certain symbols that will be present in the final binaries.
+if [ -n "$CONFIG_LTO_CLANG" ]; then
+ # intrinsic functions
+ needed_symbols="$needed_symbols memcpy memmove memset"
+ # ftrace
+ needed_symbols="$needed_symbols _mcount"
+ # stack protector symbols
+ needed_symbols="$needed_symbols __stack_chk_fail __stack_chk_guard"
+fi
+
+ksym_wl=
if [ -n "$CONFIG_UNUSED_KSYMS_WHITELIST" ]; then
# Use 'eval' to expand the whitelist path and check if it is relative
eval ksym_wl="$CONFIG_UNUSED_KSYMS_WHITELIST"
@@ -40,16 +59,14 @@ cat > "$output_file" << EOT
EOT
[ -f modules.order ] && modlist=modules.order || modlist=/dev/null
-sed 's/ko$/mod/' $modlist |
-xargs -n1 sed -n -e '2{s/ /\n/g;/^$/!p;}' -- |
-cat - "$ksym_wl" |
+
+{
+ sed 's/ko$/mod/' $modlist | xargs -n1 sed -n -e '2p'
+ echo "$needed_symbols"
+ [ -n "$ksym_wl" ] && cat "$ksym_wl"
+} | sed -e 's/ /\n/g' | sed -n -e '/^$/!p' |
# Remove the dot prefix for ppc64; symbol names with a dot (.) hold entry
# point addresses.
sed -e 's/^\.//' |
sort -u |
sed -e 's/\(.*\)/#define __KSYM_\1 1/' >> "$output_file"
-
-# Special case for modversions (see modpost.c)
-if [ -n "$CONFIG_MODVERSIONS" ]; then
- echo "#define __KSYM_module_layout 1" >> "$output_file"
-fi
diff --git a/scripts/lto-used-symbollist.txt b/scripts/lto-used-symbollist.txt
deleted file mode 100644
index 406ada65e926..
--- a/scripts/lto-used-symbollist.txt
+++ /dev/null
@@ -1,6 +0,0 @@
-memcpy
-memmove
-memset
-_mcount
-__stack_chk_fail
-__stack_chk_guard
--
2.27.0
Re: [PATCH v4 13/19] coresight: ete: Add support for ETE sysreg access
Hi Suzuki,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on next-20210226]
[cannot apply to kvmarm/next arm64/for-next/core tip/perf/core v5.11]
[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/Suzuki-K-Poulose/arm64-coresight-Add-support-for-ETE-and-TRBE/20210226-035447
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
6fbd6cf85a3be127454a1ad58525a3adcf8612ab
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
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
#
https://github.com/0day-ci/linux/commit/66c402c1fecfcacd92971f7c4ef6ee17f8243745
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Suzuki-K-Poulose/arm64-coresight-Add-support-for-ETE-and-TRBE/20210226-035447
git checkout 66c402c1fecfcacd92971f7c4ef6ee17f8243745
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 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/hwtracing/coresight/coresight-etm4x-core.c:118:5: warning: no
>> previous prototype for 'ete_sysreg_read' [-Wmissing-prototypes]
118 | u64 ete_sysreg_read(u32 offset, bool _relaxed, bool _64bit)
| ^~~
>> drivers/hwtracing/coresight/coresight-etm4x-core.c:135:6: warning: no
>> previous prototype for 'ete_sysreg_write' [-Wmissing-prototypes]
135 | void ete_sysreg_write(u64 val, u32 offset, bool _relaxed, bool
_64bit)
| ^~~~
vim +/ete_sysreg_read +118 drivers/hwtracing/coresight/coresight-etm4x-core.c
117
> 118 u64 ete_sysreg_read(u32 offset, bool _relaxed, bool _64bit)
119 {
120 u64 res = 0;
121
122 switch (offset) {
123 ETE_READ_CASES(res)
124 default :
125 pr_warn_ratelimited("ete: trying to read unsupported
register @%x\n",
126 offset);
127 }
128
129 if (!_relaxed)
130 __iormb(res); /* Imitate the !relaxed I/O helpers */
131
132 return res;
133 }
134
> 135 void ete_sysreg_write(u64 val, u32 offset, bool _relaxed, bool _64bit)
136 {
137 if (!_relaxed)
138 __iowmb(); /* Imitate the !relaxed I/O helpers */
139 if (!_64bit)
140 val &= GENMASK(31, 0);
141
142 switch (offset) {
143 ETE_WRITE_CASES(val)
144 default :
145 pr_warn_ratelimited("ete: trying to write to
unsupported register @%x\n",
146 offset);
147 }
148 }
149
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] PM: AVS: Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE
On 16:48-20210224, Yang Li wrote: > Fix the following coccicheck warning: > ./drivers/soc/ti/smartreflex.c:820:0-23: WARNING: pm_sr_fops should be > defined with DEFINE_DEBUGFS_ATTRIBUTE > > Reported-by: Abaci Robot > Signed-off-by: Yang Li > --- > drivers/soc/ti/smartreflex.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/soc/ti/smartreflex.c b/drivers/soc/ti/smartreflex.c > index 5376f3d..b3c7460 100644 > --- a/drivers/soc/ti/smartreflex.c > +++ b/drivers/soc/ti/smartreflex.c > @@ -817,7 +817,7 @@ static int omap_sr_autocomp_store(void *data, u64 val) > return 0; > } > > -DEFINE_SIMPLE_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show, > +DEFINE_DEBUGFS_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show, > omap_sr_autocomp_store, "%llu\n"); > > static int omap_sr_probe(struct platform_device *pdev) > -- > 1.8.3.1 > LGTM. Reviewed-by: Nishanth Menon Though $subject might be soc: ti: smartreflex after the relocation to maintain consistency.. Upto santosh if he might want to locally change on applying the patch.. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[GIT PULL] CIFS/SMB3 Fixes
Please pull the following changes since commit f40ddce88593482919761f74910f42f4b84c004b: Linux 5.11 (2021-02-14 14:32:24 -0800) are available in the Git repository at: git://git.samba.org/sfrench/cifs-2.6.git tags/5.12-smb3-part1 for you to fetch changes up to 8369dfd7841e70711c53a065ffb8029f24520200: cifs: update internal version number (2021-02-25 19:08:11 -0600) cifs/smb3 fixes: - improvements to mode bit conversion, chmod and chown when using cifsacl mount option - two new mount options for controlling attribute caching - improvements to crediting and reconnect, improved debugging - reconnect fix - add SMB3.1.1 dialect to default dialects for vers=3 Still working on a security fix and some multichannel fixes which are not included in this pull request Test results: http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/513 David Howells (1): cifs: use discard iterator to discard unneeded network data more efficiently Paulo Alcantara (4): cifs: fix nodfs mount option cifs: fix DFS failover cifs: check all path components in resolved dfs target cifs: introduce helper for finding referral server to improve DFS target resolution Rohith Surabattula (1): TCON Reconnect during STATUS_NETWORK_NAME_DELETED Ronnie Sahlberg (1): cifs: fix handling of escaped ',' in the password mount argument Shyam Prasad N (8): cifs: New optype for session operations. cifs: Fix in error types returned for out-of-credit situations. cifs: Identify a connection by a conn_id. cifs: Reformat DebugData and index connections by conn_id. cifs: Fix cifsacl ACE mask for group and others. cifs: Retain old ACEs when converting between mode bits and ACL. cifs: Change SIDs in ACEs while transferring file ownership. cifs: If a corrupted DACL is returned by the server, bail out. Steve French (11): smb3: negotiate current dialect (SMB3.1.1) when version 3 or greater requested cifs: fix trivial typo cifs: documentation cleanup cifs: change confusing field serverName (to ip_addr) cifs: clarify hostname vs ip address in /proc/fs/cifs/DebugData cifs: cleanup a few le16 vs. le32 uses in cifsacl.c cifs: minor simplification to smb2_is_network_name_deleted cifs: Add new mount parameter "acdirmax" to allow caching directory metadata cifs: convert revalidate of directories to using directory metadata cache timeout cifs: Add new parameter "acregmax" for distinct file and directory metadata timeout cifs: update internal version number YueHaibing (1): cifs: Fix inconsistent IS_ERR and PTR_ERR Documentation/admin-guide/cifs/authors.rst | 6 +- Documentation/admin-guide/cifs/changes.rst | 5 +- Documentation/admin-guide/cifs/introduction.rst | 30 +- Documentation/admin-guide/cifs/todo.rst | 34 ++- Documentation/admin-guide/cifs/usage.rst| 2 +- fs/cifs/cifs_debug.c| 121 fs/cifs/cifs_swn.c | 2 +- fs/cifs/cifsacl.c | 379 +++- fs/cifs/cifsacl.h | 4 +- fs/cifs/cifsencrypt.c | 6 +- fs/cifs/cifsfs.c| 15 +- fs/cifs/cifsfs.h| 2 +- fs/cifs/cifsglob.h | 11 +- fs/cifs/cifsproto.h | 2 + fs/cifs/cifssmb.c | 6 +- fs/cifs/connect.c | 301 ++- fs/cifs/dfs_cache.c | 33 ++- fs/cifs/file.c | 2 +- fs/cifs/fs_context.c| 75 +++-- fs/cifs/fs_context.h| 6 +- fs/cifs/inode.c | 23 +- fs/cifs/sess.c | 2 +- fs/cifs/smb2ops.c | 109 +-- fs/cifs/smb2pdu.c | 22 +- fs/cifs/trace.h | 36 ++- fs/cifs/transport.c | 63 ++-- 26 files changed, 883 insertions(+), 414 deletions(-) -- Thanks, Steve
Re: [PATCH] virt: acrn: add hotplug_cpu dependency
On Fri, Feb 26, 2021 at 09:38:07AM +0800, Shuo A Liu wrote: > Hi Arnd, > > There is already a patchset for this build issue. Please refer to > https://lore.kernel.org/lkml/20210221134339.57851-1-shuo.a@intel.com/. > > Hi Greg, Would you like accept that patchset in you tree? I can't take anything new in my tree until 5.12-rc1 is out. When that happens I will go through everything submitted to me and merge fixes like this one and get them sent to Linus in a week or so. thanks, greg k-h
Re: [PATCH 2/2] Documentation: features: refresh feature list
Thx Arnd,
I'm very glad to see C-SKY & RISC-V features updated.
Signed-off-by: Guo Ren
On Thu, Feb 25, 2021 at 10:29 PM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> Run the update script to document the recent feature additions
> on riscv, mips and csky.
>
> Fixes: c109f42450ec ("csky: Add kmemleak support")
> Fixes: 8b3165e54566 ("MIPS: Enable GCOV")
> Fixes: 1ddc96bd42da ("MIPS: kernel: Support extracting off-line stack traces
> from user-space with perf")
> Fixes: 74784081aac8 ("riscv: Add uprobes supported")
> Fixes: 829adda597fe ("riscv: Add KPROBES_ON_FTRACE supported")
> Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported")
> Fixes: dcdc7a53a890 ("RISC-V: Implement ptrace regs and stack API")
> Signed-off-by: Arnd Bergmann
> ---
> Documentation/features/debug/gcov-profile-all/arch-support.txt | 2 +-
> Documentation/features/debug/kmemleak/arch-support.txt | 2 +-
> Documentation/features/debug/kprobes-on-ftrace/arch-support.txt | 2 +-
> Documentation/features/debug/kprobes/arch-support.txt | 2 +-
> Documentation/features/debug/kretprobes/arch-support.txt| 2 +-
> Documentation/features/debug/uprobes/arch-support.txt | 2 +-
> Documentation/features/perf/kprobes-event/arch-support.txt | 2 +-
> Documentation/features/perf/perf-regs/arch-support.txt | 2 +-
> Documentation/features/perf/perf-stackdump/arch-support.txt | 2 +-
> Documentation/features/sched/numa-balancing/arch-support.txt| 2 +-
> 10 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/features/debug/gcov-profile-all/arch-support.txt
> b/Documentation/features/debug/gcov-profile-all/arch-support.txt
> index 416c70345946..b39c1a5de3f3 100644
> --- a/Documentation/features/debug/gcov-profile-all/arch-support.txt
> +++ b/Documentation/features/debug/gcov-profile-all/arch-support.txt
> @@ -16,7 +16,7 @@
> |ia64: | TODO |
> |m68k: | TODO |
> | microblaze: | ok |
> -|mips: | TODO |
> +|mips: | ok |
> | nds32: | TODO |
> | nios2: | TODO |
> |openrisc: | TODO |
> diff --git a/Documentation/features/debug/kmemleak/arch-support.txt
> b/Documentation/features/debug/kmemleak/arch-support.txt
> index 915185634611..e9ac415f8aec 100644
> --- a/Documentation/features/debug/kmemleak/arch-support.txt
> +++ b/Documentation/features/debug/kmemleak/arch-support.txt
> @@ -10,7 +10,7 @@
> | arc: | ok |
> | arm: | ok |
> | arm64: | ok |
> -|csky: | TODO |
> +|csky: | ok |
> | h8300: | TODO |
> | hexagon: | TODO |
> |ia64: | TODO |
> diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> index aade7816cb87..96156e8802a7 100644
> --- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> +++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> @@ -22,7 +22,7 @@
> |openrisc: | TODO |
> | parisc: | ok |
> | powerpc: | ok |
> -| riscv: | TODO |
> +| riscv: | ok |
> |s390: | ok |
> | sh: | TODO |
> | sparc: | TODO |
> diff --git a/Documentation/features/debug/kprobes/arch-support.txt
> b/Documentation/features/debug/kprobes/arch-support.txt
> index 4b663c124d1c..ee95ed61909a 100644
> --- a/Documentation/features/debug/kprobes/arch-support.txt
> +++ b/Documentation/features/debug/kprobes/arch-support.txt
> @@ -22,7 +22,7 @@
> |openrisc: | TODO |
> | parisc: | ok |
> | powerpc: | ok |
> -| riscv: | TODO |
> +| riscv: | ok |
> |s390: | ok |
> | sh: | ok |
> | sparc: | ok |
> diff --git a/Documentation/features/debug/kretprobes/arch-support.txt
> b/Documentation/features/debug/kretprobes/arch-support.txt
> index 5449bb808442..612cb97d47b8 100644
> --- a/Documentation/features/debug/kretprobes/arch-support.txt
> +++ b/Documentation/features/debug/kretprobes/arch-support.txt
> @@ -22,7 +22,7 @@
> |openrisc: | TODO |
> | parisc: | ok |
> | powerpc: | ok |
> -| riscv: | TODO |
> +| riscv: | ok |
> |s390: | ok |
> | sh: | ok |
> | sparc: | ok |
> diff --git a/Documentation/features/debug/uprobes/arch-support.txt
> b/Documentation/features/debug/uprobes/arch-support.txt
> index 2820177787e1..8bd5548a4485 100644
> --- a/Documentation/features/debug/uprobes/arch-support.txt
> +++ b/Documentation/features/debug/uprobes/arch-support.txt
> @@ -22,7 +22,7 @@
> |openrisc: | TODO |
> | parisc: | TODO |
> | powerpc: | ok |
> -| riscv: | TODO |
> +| riscv: | ok |
> |s390: | ok |
> | sh: | TODO |
> |
[PATCH v2 1/1] KVM: x86: remove misplaced comment on active_mmu_pages
The 'mmu_page_hash' is used as hash table while 'active_mmu_pages' is a
list. Remove the misplaced comment as it's mostly stating the obvious
anyways.
Signed-off-by: Dongli Zhang
Reviewed-by: Sean Christopherson
---
Changed since v1:
- change 'incorrect' to 'misplaced'
arch/x86/include/asm/kvm_host.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 84499aad01a4..318242512407 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -937,9 +937,6 @@ struct kvm_arch {
unsigned int indirect_shadow_pages;
u8 mmu_valid_gen;
struct hlist_head mmu_page_hash[KVM_NUM_MMU_PAGES];
- /*
-* Hash table of struct kvm_mmu_page.
-*/
struct list_head active_mmu_pages;
struct list_head zapped_obsolete_pages;
struct list_head lpage_disallowed_mmu_pages;
--
2.17.1
Re: [PATCH v8 1/1] mm/page_alloc.c: refactor initialization of struct page for holes in memory layout
On Thu, Feb 25, 2021 at 04:08:51PM -0800, Andrew Morton wrote:
> On Fri, 26 Feb 2021 00:43:51 +0200 Mike Rapoport wrote:
>
> > From: Mike Rapoport
>
> > void __meminit __weak memmap_init_zone(struct zone *zone)
> > {
> > unsigned long zone_start_pfn = zone->zone_start_pfn;
> > unsigned long zone_end_pfn = zone_start_pfn + zone->spanned_pages;
> > int i, nid = zone_to_nid(zone), zone_id = zone_idx(zone);
> > + static unsigned long hole_pfn = 0;
>
> static implies that pgdat->node_zones[] is alwyas sorted in ascending
> pfn order. Always true?
Yes.
--
Sincerely yours,
Mike.
Re: [PATCH] riscv: Add KASAN_VMALLOC support
Hi Palmer,
Le 2/26/21 à 12:32 AM, Palmer Dabbelt a écrit :
On Wed, 24 Feb 2021 23:48:13 PST (-0800), a...@ghiti.fr wrote:
Le 2/25/21 à 2:42 AM, Alexandre Ghiti a écrit :
Populate the top-level of the kernel page table to implement
KASAN_VMALLOC,
lower levels are filled dynamically upon memory allocation at runtime.
Co-developed-by: Nylon Chen
Signed-off-by: Nylon Chen
Co-developed-by: Nick Hu
Signed-off-by: Nick Hu
Signed-off-by: Alexandre Ghiti
---
arch/riscv/Kconfig | 1 +
arch/riscv/mm/kasan_init.c | 35 ++-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 8eadd1cbd524..3832a537c5d6 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -57,6 +57,7 @@ config RISCV
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE
select HAVE_ARCH_KASAN if MMU && 64BIT
+ select HAVE_ARCH_KASAN_VMALLOC if MMU && 64BIT
select HAVE_ARCH_KGDB
select HAVE_ARCH_KGDB_QXFER_PKT
select HAVE_ARCH_MMAP_RND_BITS if MMU
diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index 719b6e4d6075..171569df4334 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -142,6 +142,31 @@ static void __init kasan_populate(void *start,
void *end)
memset(start, KASAN_SHADOW_INIT, end - start);
}
+void __init kasan_shallow_populate_pgd(unsigned long vaddr, unsigned
long end)
+{
+ unsigned long next;
+ void *p;
+ pgd_t *pgd_k = pgd_offset_k(vaddr);
+
+ do {
+ next = pgd_addr_end(vaddr, end);
+ if (pgd_page_vaddr(*pgd_k) == (unsigned
long)lm_alias(kasan_early_shadow_pmd)) {
+ p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+ set_pgd(pgd_k, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
+ }
+ } while (pgd_k++, vaddr = next, vaddr != end);
+}
+
+void __init kasan_shallow_populate(void *start, void *end)
+{
+ unsigned long vaddr = (unsigned long)start & PAGE_MASK;
+ unsigned long vend = PAGE_ALIGN((unsigned long)end);
+
+ kasan_shallow_populate_pgd(vaddr, vend);
+
+ local_flush_tlb_all();
+}
+
void __init kasan_init(void)
{
phys_addr_t _start, _end;
@@ -149,7 +174,15 @@ void __init kasan_init(void)
kasan_populate_early_shadow((void *)KASAN_SHADOW_START,
(void *)kasan_mem_to_shadow((void *)
- VMALLOC_END));
+ VMEMMAP_END));
+ if (IS_ENABLED(CONFIG_KASAN_VMALLOC))
+ kasan_shallow_populate(
+ (void *)kasan_mem_to_shadow((void *)VMALLOC_START),
+ (void *)kasan_mem_to_shadow((void *)VMALLOC_END));
+ else
+ kasan_populate_early_shadow(
+ (void *)kasan_mem_to_shadow((void *)VMALLOC_START),
+ (void *)kasan_mem_to_shadow((void *)VMALLOC_END));
for_each_mem_range(i, &_start, &_end) {
void *start = (void *)_start;
Palmer, this commit should replace (if everyone agrees) Nylon and Nick's
Commit e178d670f251 ("riscv/kasan: add KASAN_VMALLOC support") that is
already in for-next.
Sorry, but it's way too late to be rebasing things. I can get trying to
have
the history clean, but in this case we're better off having this as an
explicit
fix patch -- changing hashes this late in the process messes with all the
testing.
I'm not sure what the issue actually is, so it'd be great if you could
send the
fix patch. If not then LMK and I'll try to figure out what's going on.
Either
way, having the fix will make sure this gets tested properly as whatever's
going on isn't failing for me.
Nylon's patch is functional as is, but as I mentioned here
https://patchwork.kernel.org/project/linux-riscv/patch/20210116055836.22366-2-nyl...@andestech.com/,
it does unnecessary things (like trying to walk a user page table that
does not exist at this point in the boot process).
Anyway, I will send another patch rebased on top of Nylon's.
Thanks,
Alex
___
linux-riscv mailing list
linux-ri...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH v3 1/2] dt-bindings: iommu: add bindings for sprd iommu
On Thu, 11 Feb 2021 at 03:21, Rob Herring wrote:
>
> On Fri, Feb 5, 2021 at 1:21 AM Chunyan Zhang wrote:
> >
> > Hi Rob,
> >
> > On Fri, 5 Feb 2021 at 07:25, Rob Herring wrote:
> > >
> > > On Wed, Feb 03, 2021 at 05:07:26PM +0800, Chunyan Zhang wrote:
> > > > From: Chunyan Zhang
> > > >
> > > > This iommu module can be used by Unisoc's multimedia devices, such as
> > > > display, Image codec(jpeg) and a few signal processors, including
> > > > VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor),
> > > > etc.
> > > >
> > > > Signed-off-by: Chunyan Zhang
> > > > ---
> > > > .../devicetree/bindings/iommu/sprd,iommu.yaml | 72 +++
> > > > 1 file changed, 72 insertions(+)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > > > b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > > > new file mode 100644
> > > > index ..4fc99e81fa66
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
> > > > @@ -0,0 +1,72 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +# Copyright 2020 Unisoc Inc.
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/iommu/sprd,iommu.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Unisoc IOMMU and Multi-media MMU
> > > > +
> > > > +maintainers:
> > > > + - Chunyan Zhang
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > +enum:
> > > > + - sprd,iommu-v1
> > > > +
> > > > + "#iommu-cells":
> > > > +const: 0
> > > > +description:
> > > > + Unisoc IOMMUs are all single-master IOMMU devices, therefore no
> > > > + additional information needs to associate with its master device.
> > > > + Please refer to the generic bindings document for more details,
> > > > + Documentation/devicetree/bindings/iommu/iommu.txt
> > > > +
> > > > + reg:
> > > > +maxItems: 1
> > > > +description:
> > > > + Not required if 'sprd,iommu-regs' is defined.
> > > > +
> > > > + clocks:
> > > > +description:
> > > > + Reference to a gate clock phandle, since access to some of
> > > > IOMMUs are
> > > > + controlled by gate clock, but this is not required.
> > > > +
> > > > + sprd,iommu-regs:
> > > > +$ref: /schemas/types.yaml#/definitions/phandle-array
> > > > +description:
> > > > + Reference to a syscon phandle plus 1 cell, the syscon defines the
> > > > + register range used by the iommu and the media device, the cell
> > > > + defines the offset for iommu registers. Since iommu module shares
> > > > + the same register range with the media device which uses it.
> > > > +
> > > > +required:
> > > > + - compatible
> > > > + - "#iommu-cells"
> > > > +
> > > > +oneOf:
> > > > + - required:
> > > > + - reg
> > > > + - required:
> > > > + - sprd,iommu-regs
> > > > +
> > > > +additionalProperties: false
> > > > +
> > > > +examples:
> > > > + - |
> > > > +iommu_disp: iommu-disp {
> > > > + compatible = "sprd,iommu-v1";
> > > > + sprd,iommu-regs = <_regs 0x800>;
> > >
> > > If the IOMMU is contained within another device, then it should just be
> > > a child node of that device.
> >
> > Yes, actually IOMMU can be seen as a child of multimedia devices, I
> > considered moving IOMMU under into multimedia device node, but
> > multimedia devices need IOMMU when probe[1], so I dropped that idea.
>
> Don't design your binding around working-around linux issues.
>
> > And they share the same register base, e.g.
> >
> > + mm {
> > + compatible = "simple-bus";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + dpu_regs: syscon@6300 {
>
> Drop this node.
>
> > + compatible = "sprd,sc9863a-dpuregs",
> > "syscon";
> > + reg = <0 0x6300 0 0x1000>;
> > + };
> > +
> > + dpu: dpu@6300 {
> > + compatible = "sprd,sharkl3-dpu";
> > + sprd,disp-regs = <_regs>;
>
> reg = <0 0x6300 0 0x800>;
>
> > + iommus = <_dispc>;
> > + };
> > +
> > + iommu_dispc: iommu@6300 {
> > + compatible = "sprd,iommu-v1";
> > + sprd,iommu-regs = <_regs 0x800>;
>
> reg = <0 0x63000800 0 0x800>;
Alright, considering you deprecate using syscon to map registers here,
I will drop that.
But that would cause the same physical address to be mapped two times at least.
And this is not a single case, since there are a few media devices and
their IOMMUs which
Re: [PATCH v2 3/9] devfreq: Use HZ macros
On 21. 2. 24. 오후 11:42, Daniel Lezcano wrote: HZ unit conversion macros are available in units.h, use them and remove the duplicate definition. Signed-off-by: Daniel Lezcano Reviewed-by: Christian Eggers Acked-by: Chanwoo Choi --- drivers/devfreq/devfreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index bf3047896e41..b6d63f02d293 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -26,6 +26,7 @@ #include #include #include +#include #include "governor.h" #define CREATE_TRACE_POINTS @@ -33,7 +34,6 @@ #define IS_SUPPORTED_FLAG(f, name) ((f & DEVFREQ_GOV_FLAG_##name) ? true : false) #define IS_SUPPORTED_ATTR(f, name) ((f & DEVFREQ_GOV_ATTR_##name) ? true : false) -#define HZ_PER_KHZ 1000 static struct class *devfreq_class; static struct dentry *devfreq_debugfs; I changed the patch title with 'PM /' prefix as following in order to keep the consistent patch style if there are no any special objection. - PM / devfreq: Use HZ macros Applied it. Thanks, Chanwoo Choi
[PATCH] radeon: ERROR: space prohibited before that ','
drm_property_create_range(rdev->ddev, 0 , "coherent", 0, 1);
Signed-off-by: wangjingyu
---
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 3a6fedad002d..439d1b3e87d8 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1396,7 +1396,7 @@ static int radeon_modeset_create_props(struct
radeon_device *rdev)
if (rdev->is_atom_bios) {
rdev->mode_info.coherent_mode_property =
- drm_property_create_range(rdev->ddev, 0 , "coherent",
0, 1);
+ drm_property_create_range(rdev->ddev, 0, "coherent", 0,
1);
if (!rdev->mode_info.coherent_mode_property)
return -ENOMEM;
}
--
2.11.0
Re: [PATCH] ASoC: simple-card: Add dummy dai support simple sound card
On Thu, Feb 25, 2021 at 9:17 PM Mark Brown wrote: > > On Thu, Feb 25, 2021 at 08:08:32PM +0800, Shengjiu Wang wrote: > > > If sound card doesn't need specific codec device, just > > dummy codec is enough, then we can link the dummy component > > directly. > > This is a big red flag - what circumstances are these? If it's a simple > CODEC with no control then the general approach is to provide a driver > which announces the capabilities of the CODEC and can be bound to as > normal, the dummy component should never actively be used. For the DMIC, SPDIF, HDMI ARC device or other similar device that there is no codec connected, then dummy codec is just used for registering the sound card. best regards wang shengjiu
Re: [PATCH] extcon: Fix error handling in extcon_dev_register
Hi,
On 21. 1. 19. 오후 5:10, Dinghao Liu wrote:
When devm_kcalloc() fails, we should execute device_unregister()
to unregister edev->dev from system.
Fixes: 046050f6e623e ("extcon: Update the prototype of extcon_register_notifier()
with enum extcon")
Signed-off-by: Dinghao Liu
---
drivers/extcon/extcon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 0a6438cbb3f3..e7a9561a826d 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1241,6 +1241,7 @@ int extcon_dev_register(struct extcon_dev *edev)
sizeof(*edev->nh), GFP_KERNEL);
if (!edev->nh) {
ret = -ENOMEM;
+ device_unregister(>dev);
goto err_dev;
}
Thanks for fixup. Applied it.
Thanks,
Chanwoo Choi
Re: [PATCH v7 0/2] checkpatch: add verbose mode
On Thu, Feb 25, 2021 at 7:08 PM Dwaipayan Ray wrote: > > On Thu, Feb 25, 2021 at 11:03 PM Joe Perches wrote: > > > > On Mon, 2021-02-22 at 13:22 +0530, Dwaipayan Ray wrote: > > > Add a new verbose mode to checkpatch. The verbose test > > > descriptions are read from the checkpatch documentation > > > file at `Documentation/dev-tools/checkpatch.rst`. > > > > > > The verbose mode is optional and can be enabled by the > > > flag -v or --verbose. > > > > > > The documentation file is only parsed by checkpatch.pl > > > if the verbose mode is enabled. The verbose mode can > > > not be used together with the --terse option. > > > > I don't have any real objection to this patch set, but as this > > might be added to the Documentation tree and in .rst format, > > perhaps Jonathan Corbet and/or Mauro Carvalho Chehab might have > > some opinion. > > > > Also I do not want to be a maintainer of this .rst file and > > likely neither Jon nor Mauro would either. Perhaps you? > > > > I could take it up if everybody is okay with it! > And as I set Dwaipayan on this task on documenting checkpatch, I will assist in maintaining this file as well. I will also pull some strings to increase chances that Dwaipayan becomes a longer-term member in this community and on this maintainer task. > > Ideally, the patch order would be reversed so the .rst file > > is added first, then checkpatch updated to use it. > > > > Sure, if Jonathan or Mauro has no objections to it, I will be happy > to resend it so that it can be picked up properly. > > > And _a lot_ more types and descriptive content should be added. > > Yes that's for sure. If this makes it I will try to get all of the > other types in. I agree as well, probably a critical mass for inclusion is that we have at least 25% (so roughly 50 rules) documented. > And if Lukas agrees, a little help from my fellow kernel mentees will > be nice as well! > Completely agree. I will recruit new mentees and go through the exercises with them, until they are ready to send proper patches to checkpatch.rst. As the designated maintainer of that file, you will be busy reviewing, consolidating that content and pushing back if it is not good enough for inclusion (so just as in the typical "good cop-bad cop" game: I will motivate and help them to submit, you make sure you get good content). Lukas
Re: [RFC PATCH v2 3/7] KVM: selftests: Make a generic helper to get vm guest mode strings
On 2021/2/25 13:59, Yanan Wang wrote:
For generality and conciseness, make an API which can be used in all
kvm libs and selftests to get vm guest mode strings. And the index i
is checked in the API in case of possiable faults.
Signed-off-by: Yanan Wang
And here too, will include Suggested-by: Sean Christopherson
.
---
.../testing/selftests/kvm/include/kvm_util.h | 4 +--
tools/testing/selftests/kvm/lib/kvm_util.c| 29 ---
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/tools/testing/selftests/kvm/include/kvm_util.h
b/tools/testing/selftests/kvm/include/kvm_util.h
index 2d7eb6989e83..f52a7492f47f 100644
--- a/tools/testing/selftests/kvm/include/kvm_util.h
+++ b/tools/testing/selftests/kvm/include/kvm_util.h
@@ -68,9 +68,6 @@ enum vm_guest_mode {
#define MIN_PAGE_SIZE (1U << MIN_PAGE_SHIFT)
#define PTES_PER_MIN_PAGE ptes_per_page(MIN_PAGE_SIZE)
-#define vm_guest_mode_string(m) vm_guest_mode_string[m]
-extern const char * const vm_guest_mode_string[];
-
struct vm_guest_mode_params {
unsigned int pa_bits;
unsigned int va_bits;
@@ -84,6 +81,7 @@ int vm_enable_cap(struct kvm_vm *vm, struct kvm_enable_cap
*cap);
int vcpu_enable_cap(struct kvm_vm *vm, uint32_t vcpu_id,
struct kvm_enable_cap *cap);
void vm_enable_dirty_ring(struct kvm_vm *vm, uint32_t ring_size);
+const char *vm_guest_mode_string(uint32_t i);
struct kvm_vm *vm_create(enum vm_guest_mode mode, uint64_t phy_pages, int perm);
void kvm_vm_free(struct kvm_vm *vmp);
diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c
b/tools/testing/selftests/kvm/lib/kvm_util.c
index d787cb802b4a..cc22c4ab7d67 100644
--- a/tools/testing/selftests/kvm/lib/kvm_util.c
+++ b/tools/testing/selftests/kvm/lib/kvm_util.c
@@ -141,17 +141,24 @@ static void vm_open(struct kvm_vm *vm, int perm)
"rc: %i errno: %i", vm->fd, errno);
}
-const char * const vm_guest_mode_string[] = {
- "PA-bits:52, VA-bits:48, 4K pages",
- "PA-bits:52, VA-bits:48, 64K pages",
- "PA-bits:48, VA-bits:48, 4K pages",
- "PA-bits:48, VA-bits:48, 64K pages",
- "PA-bits:40, VA-bits:48, 4K pages",
- "PA-bits:40, VA-bits:48, 64K pages",
- "PA-bits:ANY, VA-bits:48, 4K pages",
-};
-_Static_assert(sizeof(vm_guest_mode_string)/sizeof(char *) == NUM_VM_MODES,
- "Missing new mode strings?");
+const char *vm_guest_mode_string(uint32_t i)
+{
+ static const char * const strings[] = {
+ [VM_MODE_P52V48_4K] = "PA-bits:52, VA-bits:48, 4K pages",
+ [VM_MODE_P52V48_64K]= "PA-bits:52, VA-bits:48, 64K pages",
+ [VM_MODE_P48V48_4K] = "PA-bits:48, VA-bits:48, 4K pages",
+ [VM_MODE_P48V48_64K]= "PA-bits:48, VA-bits:48, 64K pages",
+ [VM_MODE_P40V48_4K] = "PA-bits:40, VA-bits:48, 4K pages",
+ [VM_MODE_P40V48_64K]= "PA-bits:40, VA-bits:48, 64K pages",
+ [VM_MODE_PXXV48_4K] = "PA-bits:ANY, VA-bits:48, 4K pages",
+ };
+ _Static_assert(sizeof(strings)/sizeof(char *) == NUM_VM_MODES,
+ "Missing new mode strings?");
+
+ TEST_ASSERT(i < NUM_VM_MODES, "Guest mode ID %d too big", i);
+
+ return strings[i];
+}
const struct vm_guest_mode_params vm_guest_mode_params[] = {
{ 52, 48, 0x1000, 12 },
Re: [PATCH 2/2] usb-storage: revert from scsi_add_host_with_dma() to scsi_add_host()
On Thu, Feb 25, 2021 at 11:35:57AM -0500, Alan Stern wrote: > This thread seems to have fallen through the cracks. Maybe now would be > a good time to address the problem (since we originally planned to fix > it in 5.11!). > > The questions listed below are pretty self-contained, although the rest > of the discussion isn't. But I never received any answers. usb-storage must use scsi_add_host_with_dma to use the right device for DMA mapping and parameters. The calls to set the DMA options on the device are needed so that IOMMU merging doesn't change the imposed requirements. If these requirements slow you down you need to relax them, as apparently the hardware is able to handle bigger limits.
[GIT PULL] pcmcia updates for v5.12
Linus, A lone PCMCIA change since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62: Linux 5.11-rc2 (2021-01-03 15:55:30 -0800) is available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git pcmcia-next for you to fetch changes up to 4ce6b242b78d355ba899f1b16c6bfcd43df155a0: pcmcia: Switch to using the new API kobj_to_dev() (2021-01-04 08:16:00 +0100) The patch contained in this pull request improves the use of the kobj API in the core of the Linux PCMCIA subsystem. Thanks, Dominik Tian Tao (1): pcmcia: Switch to using the new API kobj_to_dev() drivers/pcmcia/cistpl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Re: [RFC PATCH v2 6/7] KVM: selftests: Adapt vm_userspace_mem_region_add to new helpers
On 2021/2/26 7:44, Ben Gardon wrote:
On Wed, Feb 24, 2021 at 10:03 PM Yanan Wang wrote:
With VM_MEM_SRC_ANONYMOUS_THP specified in vm_userspace_mem_region_add(),
we have to get the transparent hugepage size for HVA alignment. With the
new helpers, we can use get_backing_src_pagesz() to check whether THP is
configured and then get the exact configured hugepage size.
As different architectures may have different THP page sizes configured,
this can get the accurate THP page sizes on any platform.
Signed-off-by: Yanan Wang
---
tools/testing/selftests/kvm/lib/kvm_util.c | 27 +++---
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c
b/tools/testing/selftests/kvm/lib/kvm_util.c
index b91c8e3a7ee1..0105fbfed036 100644
--- a/tools/testing/selftests/kvm/lib/kvm_util.c
+++ b/tools/testing/selftests/kvm/lib/kvm_util.c
@@ -18,7 +18,6 @@
#include
#include
-#define KVM_UTIL_PGS_PER_HUGEPG 512
#define KVM_UTIL_MIN_PFN 2
/* Aligns x up to the next multiple of size. Size must be a power of 2. */
@@ -686,7 +685,7 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,
{
int ret;
struct userspace_mem_region *region;
- size_t huge_page_size = KVM_UTIL_PGS_PER_HUGEPG * vm->page_size;
+ size_t backing_src_pagesz = get_backing_src_pagesz(src_type);
size_t alignment;
TEST_ASSERT(vm_adjust_num_guest_pages(vm->mode, npages) == npages,
@@ -748,7 +747,7 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,
#endif
if (src_type == VM_MEM_SRC_ANONYMOUS_THP)
- alignment = max(huge_page_size, alignment);
+ alignment = max(backing_src_pagesz, alignment);
/* Add enough memory to align up if necessary */
if (alignment > 1)
@@ -767,22 +766,12 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,
region->host_mem = align(region->mmap_start, alignment);
/* As needed perform madvise */
- if (src_type == VM_MEM_SRC_ANONYMOUS || src_type ==
VM_MEM_SRC_ANONYMOUS_THP) {
- struct stat statbuf;
-
- ret = stat("/sys/kernel/mm/transparent_hugepage", );
- TEST_ASSERT(ret == 0 || (ret == -1 && errno == ENOENT),
- "stat /sys/kernel/mm/transparent_hugepage");
-
- TEST_ASSERT(ret == 0 || src_type != VM_MEM_SRC_ANONYMOUS_THP,
- "VM_MEM_SRC_ANONYMOUS_THP requires THP to be configured
in the host kernel");
-
- if (ret == 0) {
- ret = madvise(region->host_mem, npages * vm->page_size,
- src_type == VM_MEM_SRC_ANONYMOUS ?
MADV_NOHUGEPAGE : MADV_HUGEPAGE);
- TEST_ASSERT(ret == 0, "madvise failed, addr: %p length:
0x%lx src_type: %x",
- region->host_mem, npages * vm->page_size,
src_type);
- }
+ if (src_type <= VM_MEM_SRC_ANONYMOUS_THP && thp_configured()) {
This check relies on an unstated property of the backing src type
enums where VM_MEM_SRC_ANONYMOUS and VM_MEM_SRC_ANONYMOUS_THP are
declared first.
It would probably be more readable for folks if the check was explicit:
if ((src_type == VM_MEM_SRC_ANONYMOUS || src_type ==
VM_MEM_SRC_ANONYMOUS_THP) && thp_configured()) {
Yes, this makes sense, I will fix it.
Thanks,
Yanan
+ ret = madvise(region->host_mem, npages * vm->page_size,
+ src_type == VM_MEM_SRC_ANONYMOUS ?
MADV_NOHUGEPAGE : MADV_HUGEPAGE);
+ TEST_ASSERT(ret == 0, "madvise failed, addr: %p length: 0x%lx
src_type: %s",
+ region->host_mem, npages * vm->page_size,
+ vm_mem_backing_src_alias(src_type)->name);
}
region->unused_phy_pages = sparsebit_alloc();
--
2.19.1
.
Re: [RFC PATCH 10/10] vfio/type1: Register device notifier
On Mon, Feb 22, 2021 at 01:55:23PM -0400, Jason Gunthorpe wrote: > > +static bool strict_mmio_maps = true; > > +module_param_named(strict_mmio_maps, strict_mmio_maps, bool, 0644); > > +MODULE_PARM_DESC(strict_mmio_maps, > > +"Restrict to safe DMA mappings of device memory (true)."); > > I think this should be a kconfig, historically we've required kconfig > to opt-in to unsafe things that could violate kernel security. Someone > building a secure boot trusted kernel system should not have an > options for userspace to just turn off protections. Agreed, but I'd go one step further: Why should we allow the unsafe mode at all?
Re: [RFC PATCH v2 5/7] KVM: selftests: List all hugetlb src types specified with page sizes
On 2021/2/26 7:42, Ben Gardon wrote:
On Wed, Feb 24, 2021 at 10:03 PM Yanan Wang wrote:
With VM_MEM_SRC_ANONYMOUS_HUGETLB, we currently can only use system
default hugetlb pages to back the testing guest memory. In order to
add flexibility, now list all the known hugetlb backing src types with
different page sizes, so that we can specify use of hugetlb pages of the
exact granularity that we want. And as all the known hugetlb page sizes
are listed, it's appropriate for all architectures.
Besides, the helper get_backing_src_pagesz() is added to get the
granularity of different backing src types(anonumous, thp, hugetlb).
Signed-off-by: Yanan Wang
---
.../testing/selftests/kvm/include/test_util.h | 19 ++-
tools/testing/selftests/kvm/lib/kvm_util.c| 2 +-
tools/testing/selftests/kvm/lib/test_util.c | 56 +++
3 files changed, 63 insertions(+), 14 deletions(-)
diff --git a/tools/testing/selftests/kvm/include/test_util.h
b/tools/testing/selftests/kvm/include/test_util.h
index ef24c76ba89a..be5d08bcdca7 100644
--- a/tools/testing/selftests/kvm/include/test_util.h
+++ b/tools/testing/selftests/kvm/include/test_util.h
@@ -70,16 +70,31 @@ struct timespec timespec_div(struct timespec ts, int
divisor);
enum vm_mem_backing_src_type {
VM_MEM_SRC_ANONYMOUS,
VM_MEM_SRC_ANONYMOUS_THP,
- VM_MEM_SRC_ANONYMOUS_HUGETLB,
+ VM_MEM_SRC_ANONYMOUS_HUGETLB_16KB,
+ VM_MEM_SRC_ANONYMOUS_HUGETLB_64KB,
+ VM_MEM_SRC_ANONYMOUS_HUGETLB_512KB,
+ VM_MEM_SRC_ANONYMOUS_HUGETLB_1MB,
+ VM_MEM_SRC_ANONYMOUS_HUGETLB_2MB,
+ VM_MEM_SRC_ANONYMOUS_HUGETLB_8MB,
+ VM_MEM_SRC_ANONYMOUS_HUGETLB_16MB,
+ VM_MEM_SRC_ANONYMOUS_HUGETLB_32MB,
+ VM_MEM_SRC_ANONYMOUS_HUGETLB_256MB,
+ VM_MEM_SRC_ANONYMOUS_HUGETLB_512MB,
+ VM_MEM_SRC_ANONYMOUS_HUGETLB_1GB,
+ VM_MEM_SRC_ANONYMOUS_HUGETLB_2GB,
+ VM_MEM_SRC_ANONYMOUS_HUGETLB_16GB,
+ NUM_SRC_TYPES,
};
struct vm_mem_backing_src_alias {
const char *name;
- enum vm_mem_backing_src_type type;
+ uint32_t flag;
};
bool thp_configured(void);
size_t get_trans_hugepagesz(void);
+const struct vm_mem_backing_src_alias *vm_mem_backing_src_alias(uint32_t i);
+size_t get_backing_src_pagesz(uint32_t i);
void backing_src_help(void);
enum vm_mem_backing_src_type parse_backing_src_type(const char *type_name);
diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c
b/tools/testing/selftests/kvm/lib/kvm_util.c
index cc22c4ab7d67..b91c8e3a7ee1 100644
--- a/tools/testing/selftests/kvm/lib/kvm_util.c
+++ b/tools/testing/selftests/kvm/lib/kvm_util.c
@@ -757,7 +757,7 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,
region->mmap_start = mmap(NULL, region->mmap_size,
PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS
- | (src_type == VM_MEM_SRC_ANONYMOUS_HUGETLB ?
MAP_HUGETLB : 0),
+ | vm_mem_backing_src_alias(src_type)->flag,
-1, 0);
TEST_ASSERT(region->mmap_start != MAP_FAILED,
"test_malloc failed, mmap_start: %p errno: %i",
diff --git a/tools/testing/selftests/kvm/lib/test_util.c
b/tools/testing/selftests/kvm/lib/test_util.c
index f2d133f76c67..6780aa058f35 100644
--- a/tools/testing/selftests/kvm/lib/test_util.c
+++ b/tools/testing/selftests/kvm/lib/test_util.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "linux/kernel.h"
#include "test_util.h"
@@ -112,12 +113,6 @@ void print_skip(const char *fmt, ...)
puts(", skipping test");
}
-const struct vm_mem_backing_src_alias backing_src_aliases[] = {
- {"anonymous", VM_MEM_SRC_ANONYMOUS,},
- {"anonymous_thp", VM_MEM_SRC_ANONYMOUS_THP,},
- {"anonymous_hugetlb", VM_MEM_SRC_ANONYMOUS_HUGETLB,},
-};
-
bool thp_configured(void)
{
int ret;
@@ -153,22 +148,61 @@ size_t get_trans_hugepagesz(void)
return size;
}
+const struct vm_mem_backing_src_alias *vm_mem_backing_src_alias(uint32_t i)
+{
+ static const struct vm_mem_backing_src_alias aliases[] = {
+ { "anonymous", 0},
+ { "anonymous_thp", 0},
+ { "anonymous_hugetlb_16kb", MAP_HUGETLB | MAP_HUGE_16KB },
+ { "anonymous_hugetlb_64kb", MAP_HUGETLB | MAP_HUGE_64KB },
+ { "anonymous_hugetlb_512kb", MAP_HUGETLB | MAP_HUGE_512KB },
+ { "anonymous_hugetlb_1mb", MAP_HUGETLB | MAP_HUGE_1MB },
+ { "anonymous_hugetlb_2mb", MAP_HUGETLB | MAP_HUGE_2MB },
+ { "anonymous_hugetlb_8mb", MAP_HUGETLB | MAP_HUGE_8MB },
+ { "anonymous_hugetlb_16mb", MAP_HUGETLB | MAP_HUGE_16MB },
+ { "anonymous_hugetlb_32mb", MAP_HUGETLB | MAP_HUGE_32MB },
+
Re: [PATCH 1/1] KVM: x86: remove incorrect comment on active_mmu_pages
On 2/25/21 4:44 PM, Sean Christopherson wrote:
> On Tue, Feb 23, 2021, Dongli Zhang wrote:
>> The 'mmu_page_hash' is used as hash table while 'active_mmu_pages' is a
>> list. This patch removes the incorrect comment on active_mmu_pages.
>
> Maybe change the last sentence to "Remove the misplaced comment, it's mostly
> stating the obvious anyways." It's more misplaced than flat out incorrect,
> e.g.
> the alternative would be to hoist the comment above mmu_page_hash. I like
> removing it though, IMO mmu_page_hash is the most obvious name out of the
> various structures that track shadow pages.
Thank you very much!
I will change the last sentence and send v2 with your Reviewed-by.
Dongli Zhang
>
> With that tweak:
>
> Reviewed-by: Sean Christopherson
>
>
>> Signed-off-by: Dongli Zhang
>> ---
>> arch/x86/include/asm/kvm_host.h | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/kvm_host.h
>> b/arch/x86/include/asm/kvm_host.h
>> index 84499aad01a4..318242512407 100644
>> --- a/arch/x86/include/asm/kvm_host.h
>> +++ b/arch/x86/include/asm/kvm_host.h
>> @@ -937,9 +937,6 @@ struct kvm_arch {
>> unsigned int indirect_shadow_pages;
>> u8 mmu_valid_gen;
>> struct hlist_head mmu_page_hash[KVM_NUM_MMU_PAGES];
>> -/*
>> - * Hash table of struct kvm_mmu_page.
>> - */
>> struct list_head active_mmu_pages;
>> struct list_head zapped_obsolete_pages;
>> struct list_head lpage_disallowed_mmu_pages;
>> --
>> 2.17.1
>>
Re: [RFC PATCH 01/10] vfio: Create vfio_fs_type with inode per device
On Mon, Feb 22, 2021 at 09:50:35AM -0700, Alex Williamson wrote: > By linking all the device fds we provide to userspace to an > address space through a new pseudo fs, we can use tools like > unmap_mapping_range() to zap all vmas associated with a device. > > Suggested-by: Jason Gunthorpe > Signed-off-by: Alex Williamson Adding Al: I hate how we're are growing these tiny file systems just to allocate an anonymous inode all over. Shouldn't we allow to enhance fs/anon_inodes.c to add a new API to allocate a new specific inode from anon_inodefs instead?
Re: [PATCH 2/2] Documentation: features: refresh feature list
On Thu, 25 Feb 2021 06:27:18 PST (-0800), a...@kernel.org wrote:
From: Arnd Bergmann
Run the update script to document the recent feature additions
on riscv, mips and csky.
Fixes: c109f42450ec ("csky: Add kmemleak support")
Fixes: 8b3165e54566 ("MIPS: Enable GCOV")
Fixes: 1ddc96bd42da ("MIPS: kernel: Support extracting off-line stack traces from
user-space with perf")
Fixes: 74784081aac8 ("riscv: Add uprobes supported")
Fixes: 829adda597fe ("riscv: Add KPROBES_ON_FTRACE supported")
Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported")
Fixes: dcdc7a53a890 ("RISC-V: Implement ptrace regs and stack API")
For the RISC-V stuff
Reviewed-by: Palmer Dabbelt
Acked-by: Palmer Dabbelt
Thanks!
Signed-off-by: Arnd Bergmann
---
Documentation/features/debug/gcov-profile-all/arch-support.txt | 2 +-
Documentation/features/debug/kmemleak/arch-support.txt | 2 +-
Documentation/features/debug/kprobes-on-ftrace/arch-support.txt | 2 +-
Documentation/features/debug/kprobes/arch-support.txt | 2 +-
Documentation/features/debug/kretprobes/arch-support.txt| 2 +-
Documentation/features/debug/uprobes/arch-support.txt | 2 +-
Documentation/features/perf/kprobes-event/arch-support.txt | 2 +-
Documentation/features/perf/perf-regs/arch-support.txt | 2 +-
Documentation/features/perf/perf-stackdump/arch-support.txt | 2 +-
Documentation/features/sched/numa-balancing/arch-support.txt| 2 +-
10 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/features/debug/gcov-profile-all/arch-support.txt
b/Documentation/features/debug/gcov-profile-all/arch-support.txt
index 416c70345946..b39c1a5de3f3 100644
--- a/Documentation/features/debug/gcov-profile-all/arch-support.txt
+++ b/Documentation/features/debug/gcov-profile-all/arch-support.txt
@@ -16,7 +16,7 @@
|ia64: | TODO |
|m68k: | TODO |
| microblaze: | ok |
-|mips: | TODO |
+|mips: | ok |
| nds32: | TODO |
| nios2: | TODO |
|openrisc: | TODO |
diff --git a/Documentation/features/debug/kmemleak/arch-support.txt
b/Documentation/features/debug/kmemleak/arch-support.txt
index 915185634611..e9ac415f8aec 100644
--- a/Documentation/features/debug/kmemleak/arch-support.txt
+++ b/Documentation/features/debug/kmemleak/arch-support.txt
@@ -10,7 +10,7 @@
| arc: | ok |
| arm: | ok |
| arm64: | ok |
-|csky: | TODO |
+|csky: | ok |
| h8300: | TODO |
| hexagon: | TODO |
|ia64: | TODO |
diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
index aade7816cb87..96156e8802a7 100644
--- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
+++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
@@ -22,7 +22,7 @@
|openrisc: | TODO |
| parisc: | ok |
| powerpc: | ok |
-| riscv: | TODO |
+| riscv: | ok |
|s390: | ok |
| sh: | TODO |
| sparc: | TODO |
diff --git a/Documentation/features/debug/kprobes/arch-support.txt
b/Documentation/features/debug/kprobes/arch-support.txt
index 4b663c124d1c..ee95ed61909a 100644
--- a/Documentation/features/debug/kprobes/arch-support.txt
+++ b/Documentation/features/debug/kprobes/arch-support.txt
@@ -22,7 +22,7 @@
|openrisc: | TODO |
| parisc: | ok |
| powerpc: | ok |
-| riscv: | TODO |
+| riscv: | ok |
|s390: | ok |
| sh: | ok |
| sparc: | ok |
diff --git a/Documentation/features/debug/kretprobes/arch-support.txt
b/Documentation/features/debug/kretprobes/arch-support.txt
index 5449bb808442..612cb97d47b8 100644
--- a/Documentation/features/debug/kretprobes/arch-support.txt
+++ b/Documentation/features/debug/kretprobes/arch-support.txt
@@ -22,7 +22,7 @@
|openrisc: | TODO |
| parisc: | ok |
| powerpc: | ok |
-| riscv: | TODO |
+| riscv: | ok |
|s390: | ok |
| sh: | ok |
| sparc: | ok |
diff --git a/Documentation/features/debug/uprobes/arch-support.txt
b/Documentation/features/debug/uprobes/arch-support.txt
index 2820177787e1..8bd5548a4485 100644
--- a/Documentation/features/debug/uprobes/arch-support.txt
+++ b/Documentation/features/debug/uprobes/arch-support.txt
@@ -22,7 +22,7 @@
|openrisc: | TODO |
| parisc: | TODO |
| powerpc: | ok |
-| riscv: | TODO |
+| riscv: | ok |
|s390: | ok |
| sh: | TODO |
| sparc: | ok |
diff --git a/Documentation/features/perf/kprobes-event/arch-support.txt
b/Documentation/features/perf/kprobes-event/arch-support.txt
index 75739a0007e0..78f3fe080f0e 100644
---
Re: [PATCH] [perf] powerpc: Remove unsupported metrics
On 2/24/21 11:44 PM, Paul A. Clarke wrote:
> Several metrics are defined based on unsupported / non-existent
> events, and silently discarded. Remove them for good code hygiene
> and to avoid confusion.
>
Hi Paul,
Thanks for the patch. Changes looks good to me.
Reviewed-by: Kajol Jain
Thanks,
Kajol Jain
> Signed-off-by: Paul A. Clarke
> ---
> .../arch/powerpc/power9/metrics.json | 132 --
> 1 file changed, 132 deletions(-)
>
> diff --git a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
> b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
> index f8784c608479..140402d2855f 100644
> --- a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
> +++ b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
> @@ -1209,156 +1209,24 @@
> "MetricGroup": "instruction_stats_percent_per_ref",
> "MetricName": "inst_from_rmem_percent"
> },
> -{
> -"BriefDescription": "%L2 Modified CO Cache read Utilization (4 pclks
> per disp attempt)",
> -"MetricExpr": "((PM_L2_CASTOUT_MOD/2)*4)/ PM_RUN_CYC * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_co_m_rd_util"
> -},
> -{
> -"BriefDescription": "L2 dcache invalidates per run inst (per core)",
> -"MetricExpr": "(PM_L2_DC_INV / 2) / PM_RUN_INST_CMPL * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_dc_inv_rate_percent"
> -},
> {
> "BriefDescription": "Demand load misses as a % of L2 LD dispatches
> (per thread)",
> "MetricExpr": "PM_L1_DCACHE_RELOAD_VALID / (PM_L2_LD / 2) * 100",
> "MetricGroup": "l2_stats",
> "MetricName": "l2_dem_ld_disp_percent"
> },
> -{
> -"BriefDescription": "L2 Icache invalidates per run inst (per core)",
> -"MetricExpr": "(PM_L2_IC_INV / 2) / PM_RUN_INST_CMPL * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_ic_inv_rate_percent"
> -},
> -{
> -"BriefDescription": "L2 Inst misses as a % of total L2 Inst
> dispatches (per thread)",
> -"MetricExpr": "PM_L2_INST_MISS / PM_L2_INST * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_inst_miss_ratio_percent"
> -},
> -{
> -"BriefDescription": "Average number of cycles between L2 Load hits",
> -"MetricExpr": "(PM_L2_LD_HIT / PM_RUN_CYC) / 2",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_ld_hit_frequency"
> -},
> -{
> -"BriefDescription": "Average number of cycles between L2 Load
> misses",
> -"MetricExpr": "(PM_L2_LD_MISS / PM_RUN_CYC) / 2",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_ld_miss_frequency"
> -},
> -{
> -"BriefDescription": "L2 Load misses as a % of total L2 Load
> dispatches (per thread)",
> -"MetricExpr": "PM_L2_LD_MISS / PM_L2_LD * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_ld_miss_ratio_percent"
> -},
> -{
> -"BriefDescription": "% L2 load disp attempts Cache read Utilization
> (4 pclks per disp attempt)",
> -"MetricExpr": "((PM_L2_RCLD_DISP/2)*4)/ PM_RUN_CYC * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_ld_rd_util"
> -},
> -{
> -"BriefDescription": "L2 load misses that require a cache write (4
> pclks per disp attempt) % of pclks",
> -"MetricExpr": "((( PM_L2_LD_DISP - PM_L2_LD_HIT)/2)*4)/ PM_RUN_CYC *
> 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_ldmiss_wr_util"
> -},
> -{
> -"BriefDescription": "L2 local pump prediction success",
> -"MetricExpr": "PM_L2_LOC_GUESS_CORRECT / (PM_L2_LOC_GUESS_CORRECT +
> PM_L2_LOC_GUESS_WRONG) * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_local_pred_correct_percent"
> -},
> -{
> -"BriefDescription": "L2 COs that were in M,Me,Mu state as a % of all
> L2 COs",
> -"MetricExpr": "PM_L2_CASTOUT_MOD / (PM_L2_CASTOUT_MOD +
> PM_L2_CASTOUT_SHR) * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_mod_co_percent"
> -},
> -{
> -"BriefDescription": "% of L2 Load RC dispatch atampts that failed
> because of address collisions and cclass conflicts",
> -"MetricExpr": "(PM_L2_RCLD_DISP_FAIL_ADDR )/ PM_L2_RCLD_DISP * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_rc_ld_disp_addr_fail_percent"
> -},
> -{
> -"BriefDescription": "% of L2 Load RC dispatch attempts that failed",
> -"MetricExpr": "(PM_L2_RCLD_DISP_FAIL_ADDR +
> PM_L2_RCLD_DISP_FAIL_OTHER)/ PM_L2_RCLD_DISP * 100",
> -"MetricGroup": "l2_stats",
> -"MetricName": "l2_rc_ld_disp_fail_percent"
> -},
> -{
> -"BriefDescription": "% of L2 Store RC dispatch atampts that failed
> because of address collisions and cclass conflicts",
> -"MetricExpr":
Re: [PATCH] riscv: Add KASAN_VMALLOC support
On Wed, 24 Feb 2021 23:48:13 PST (-0800), a...@ghiti.fr wrote:
Le 2/25/21 à 2:42 AM, Alexandre Ghiti a écrit :
Populate the top-level of the kernel page table to implement KASAN_VMALLOC,
lower levels are filled dynamically upon memory allocation at runtime.
Co-developed-by: Nylon Chen
Signed-off-by: Nylon Chen
Co-developed-by: Nick Hu
Signed-off-by: Nick Hu
Signed-off-by: Alexandre Ghiti
---
arch/riscv/Kconfig | 1 +
arch/riscv/mm/kasan_init.c | 35 ++-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 8eadd1cbd524..3832a537c5d6 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -57,6 +57,7 @@ config RISCV
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE
select HAVE_ARCH_KASAN if MMU && 64BIT
+ select HAVE_ARCH_KASAN_VMALLOC if MMU && 64BIT
select HAVE_ARCH_KGDB
select HAVE_ARCH_KGDB_QXFER_PKT
select HAVE_ARCH_MMAP_RND_BITS if MMU
diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index 719b6e4d6075..171569df4334 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -142,6 +142,31 @@ static void __init kasan_populate(void *start, void *end)
memset(start, KASAN_SHADOW_INIT, end - start);
}
+void __init kasan_shallow_populate_pgd(unsigned long vaddr, unsigned long end)
+{
+ unsigned long next;
+ void *p;
+ pgd_t *pgd_k = pgd_offset_k(vaddr);
+
+ do {
+ next = pgd_addr_end(vaddr, end);
+ if (pgd_page_vaddr(*pgd_k) == (unsigned
long)lm_alias(kasan_early_shadow_pmd)) {
+ p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+ set_pgd(pgd_k, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
+ }
+ } while (pgd_k++, vaddr = next, vaddr != end);
+}
+
+void __init kasan_shallow_populate(void *start, void *end)
+{
+ unsigned long vaddr = (unsigned long)start & PAGE_MASK;
+ unsigned long vend = PAGE_ALIGN((unsigned long)end);
+
+ kasan_shallow_populate_pgd(vaddr, vend);
+
+ local_flush_tlb_all();
+}
+
void __init kasan_init(void)
{
phys_addr_t _start, _end;
@@ -149,7 +174,15 @@ void __init kasan_init(void)
kasan_populate_early_shadow((void *)KASAN_SHADOW_START,
(void *)kasan_mem_to_shadow((void *)
- VMALLOC_END));
+ VMEMMAP_END));
+ if (IS_ENABLED(CONFIG_KASAN_VMALLOC))
+ kasan_shallow_populate(
+ (void *)kasan_mem_to_shadow((void *)VMALLOC_START),
+ (void *)kasan_mem_to_shadow((void *)VMALLOC_END));
+ else
+ kasan_populate_early_shadow(
+ (void *)kasan_mem_to_shadow((void *)VMALLOC_START),
+ (void *)kasan_mem_to_shadow((void *)VMALLOC_END));
for_each_mem_range(i, &_start, &_end) {
void *start = (void *)_start;
Palmer, this commit should replace (if everyone agrees) Nylon and Nick's
Commit e178d670f251 ("riscv/kasan: add KASAN_VMALLOC support") that is
already in for-next.
Sorry, but it's way too late to be rebasing things. I can get trying to have
the history clean, but in this case we're better off having this as an explicit
fix patch -- changing hashes this late in the process messes with all the
testing.
I'm not sure what the issue actually is, so it'd be great if you could send the
fix patch. If not then LMK and I'll try to figure out what's going on. Either
way, having the fix will make sure this gets tested properly as whatever's
going on isn't failing for me.
Re: [RFC PATCH 0/6] [RFC] Faultable tracepoints (v2)
On Thu, Feb 25, 2021 at 9:15 AM Mathieu Desnoyers wrote: > > - On Feb 24, 2021, at 11:22 AM, Michael Jeanson mjean...@efficios.com > wrote: > > > [ Adding Mathieu Desnoyers in CC ] > > > > On 2021-02-23 21 h 16, Steven Rostedt wrote: > >> On Thu, 18 Feb 2021 17:21:19 -0500 > >> Michael Jeanson wrote: > >> > >>> This series only implements the tracepoint infrastructure required to > >>> allow tracers to handle page faults. Modifying each tracer to handle > >>> those page faults would be a next step after we all agree on this piece > >>> of instrumentation infrastructure. > >> > >> I started taking a quick look at this, and came up with the question: how > >> do you allow preemption when dealing with per-cpu buffers or storage to > >> record the data? > >> > >> That is, perf, bpf and ftrace are all using some kind of per-cpu data, and > >> this is the reason for the need to disable preemption. What's the solution > >> that LTTng is using for this? I know it has a per cpu buffers too, but does > >> it have some kind of "per task" buffer that is being used to extract the > >> data that can fault? > > As a prototype solution, what I've done currently is to copy the user-space > data into a kmalloc'd buffer in a preparation step before disabling preemption > and copying data over into the per-cpu buffers. It works, but I think we > should > be able to do it without the needless copy. > > What I have in mind as an efficient solution (not implemented yet) for the > LTTng > kernel tracer goes as follows: > > #define COMMIT_LOCAL 0 > #define COMMIT_REMOTE 1 > > - faultable probe is called from system call tracepoint [ > preemption/blocking/migration is allowed ] label: restart: > - probe code calculate the length which needs to be reserved to store the > event > (e.g. user strlen), Does "user strlen" makes the content fault in? Is it possible to make the sleepable faulting only happen here between "restart" and the following "preempt disable"? The code here should do a prefetch operation like "user strlen". And we can keep preemption disabled when copying the data. If there is a fault while copying, then we can restart from the label "restart". Very immature thought. Thanks Lai > > - preempt disable -> [ preemption/blocking/migration is not allowed from > here ] > - reserve_cpu = smp_processor_id() > - reserve space in the ring buffer for reserve_cpu > [ from that point on, we have _exclusive_ access to write into the ring > buffer "slot" > from any cpu until we commit. ] > - preempt enable -> [ preemption/blocking/migration is allowed from here ] > > - copy data from user-space to the ring buffer "slot", > > - preempt disable -> [ preemption/blocking/migration is not allowed from > here ] > commit_cpu = smp_processor_id() > if (commit_cpu == reserve_cpu) >use local_add to increment the > buf[commit_cpu].subbuffer[current].commit_count[COMMIT_LOCAL] > else >use atomic_add to increment the > buf[commit_cpu].subbuffer[current].commit_count[COMMIT_REMOTE] > - preempt enable -> [ preemption/blocking/migration is allowed from here ] > > Given that lttng uses per-buffer/per-sub-buffer commit counters as simple > free-running > accumulators, the trick here is to use two commit counters rather than single > one for each > sub-buffer. Whenever we need to read a commit count value, we always sum the > total of the > LOCAL and REMOTE counter. > > This allows dealing with migration between reserve and commit without > requiring the overhead > of an atomic operation on the fast-path (LOCAL case). > > I had to design this kind of dual-counter trick in the context of user-space > use of restartable > sequences. It looks like it may have a role to play in the kernel as well. :) > > Or am I missing something important that would not survive real-life ? > > Thanks, > > Mathieu > > -- > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com
Re: [RFC PATCH 0/5] Flexible sysclk/pll configuration
On 2/25/2021 11:35 PM, Sameer Pujar wrote: This series attempts to add flexible system clock (sysclk) and pll configuration for the DAI controller from simple card or audio graph card. Sysclk configuration Motivation: --- The problem this tries to address is, some Codecs may have multiple clocks and multiple sources for its sysclk. For example sysclk may depend on MCLK provided by SoC or it may used an internal pll. The simple card or audio graph card driver is generic and can be used on multiple platforms. So if a platform using this driver needs a generic configuration, then the Codec specific stuff cannot be hardcoded in the driver. Hence it would be better if the info is driven from DT, especially from a Codec DAI or endpoint subnode. Solution: - "system-clock-id" and "system-clock-source" DT properties can be exposed for a flexible sysclk configuration. These properties go into a Codec DAI or endpoint subnode. Please note that other sysclk related properties like "system-clock-frequency" and "system-clock-direction-out" are already present. Currently snd_soc_dai_set_sysclk() does not have an argument for source. This series adds this additional field and updates all the required drivers. This is needed because ideally sysclk "clk_id" and "source" fields are different. Some drivers are making use of "clk_id" field to program source information. **May be this needs to be corrected going ahead** Pll configuration = Motivation: --- Similar to sysclk configuration, pll configuration also needs little more flexibility. If a Codec has internal pll and it can be sourced from multiple clocks a specific configuration may be required for a given platform. Some of the cases are: - MCLK (supplied by SoC) --> Codec pll -> Codec sysclk - SoC I2S bit clock (BCLK) --> Codec pll -> Codec sysclk Solution: - Approach is similar to what is done for extending sysclk flexibility. Following DT properties are added to address the same. "pll-id" "pll-source" "pll-input-reference" "pll-output-reference" "pll-input-frequency" "pll-output-frequency" All these are optional properties. Simple card or audio graph card drivers can use above info and call snd_soc_dai_set_pll() for necessary configuration. Sameer Pujar (5): ASoC: soc-component: Fix return value of snd_soc_component_set_pll() ASoC: soc-dai: Add sysclk source to snd_soc_dai_set_sysclk() ASoC: audio-graph-card: Add bindings for sysclk and pll ASoC: simple-card-utils: Parse sysclk id and source ASoC: simple-card-utils: Support pll configuration .../bindings/sound/audio-graph-port.yaml | 71 + include/sound/simple_card_utils.h | 35 + include/sound/soc-dai.h| 4 +- sound/soc/amd/acp-da7219-max98357a.c | 2 +- sound/soc/amd/acp-rt5645.c | 2 +- sound/soc/amd/acp3x-rt5682-max9836.c | 4 +- sound/soc/atmel/atmel_wm8904.c | 2 +- sound/soc/atmel/mchp-i2s-mcc.c | 2 +- [...] sound/soc/ti/omap-mcbsp.c | 2 +- sound/soc/ti/omap3pandora.c| 4 +- sound/soc/ti/rx51.c| 2 +- sound/soc/uniphier/aio-cpu.c | 4 +- sound/soc/ux500/ux500_msp_dai.c| 2 +- 271 files changed, 639 insertions(+), 389 deletions(-) Looks like I missed some files to update which make use of snd_soc_dai_set_sysclk(). I will try to fix that. Meanwhile please review if the idea is right here.
