Re: [PATCH 2/5] nvme-pci: Add a blank line after declarations
Reviewed-by: Sagi Grimberg
Re: [PATCH 1/5] nvme-pci: Fix some comments issues
Reviewed-by: Sagi Grimberg
[PULL REQUEST] i2c for 5.8
Linus, I2C has some usual driver fixes and documentation updates. Please pull. Thanks, Wolfram The following changes since commit 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68: Linux 5.8-rc3 (2020-06-28 15:00:24 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current for you to fetch changes up to 597911287fcd13c3a4b4aa3e0a52b33d431e0a8e: i2c: mlxcpld: check correct size of maximum RECV_LEN packet (2020-07-04 08:20:38 +0200) Andy Shevchenko (1): i2c: eg20t: Load module automatically if ID matches Chris Packham (1): i2c: algo-pca: Add 0x78 as SCL stuck low status for PCA9665 Ricardo Ribalda (1): i2c: designware: platdrv: Set class based on DMI Wolfram Sang (3): i2c: slave-eeprom: update documentation i2c: add Kconfig help text for slave mode i2c: mlxcpld: check correct size of maximum RECV_LEN packet with much appreciated quality assurance from Andy Shevchenko (2): (Rev.) i2c: designware: platdrv: Set class based on DMI (Rev.) i2c: algo-pca: Add 0x78 as SCL stuck low status for PCA9665 Geert Uytterhoeven (1): (Rev.) i2c: add Kconfig help text for slave mode Luca Ceresoli (1): (Rev.) i2c: slave-eeprom: update documentation Michael Shych (2): (Rev.) i2c: mlxcpld: check correct size of maximum RECV_LEN packet (Test) i2c: mlxcpld: check correct size of maximum RECV_LEN packet Niklas Söderlund (2): (Rev.) i2c: add Kconfig help text for slave mode (Rev.) i2c: slave-eeprom: update documentation Documentation/i2c/slave-eeprom-backend.rst | 22 +- drivers/i2c/Kconfig | 7 +++ drivers/i2c/algos/i2c-algo-pca.c| 3 ++- drivers/i2c/busses/i2c-designware-platdrv.c | 15 ++- drivers/i2c/busses/i2c-eg20t.c | 1 + drivers/i2c/busses/i2c-mlxcpld.c| 4 ++-- 6 files changed, 43 insertions(+), 9 deletions(-) signature.asc Description: PGP signature
Re: [PATCH 3/3] selftests: add readfile(2) selftests
On Sat, Jul 04, 2020 at 08:38:26PM +0200, Geert Uytterhoeven wrote:
> Hi Greg,
>
> On Sat, Jul 4, 2020 at 4:05 PM Greg Kroah-Hartman
> wrote:
> > Test the functionality of readfile(2) in various ways.
> >
> > Also provide a simple speed test program to benchmark using readfile()
> > instead of using open()/read()/close().
> >
> > Signed-off-by: Greg Kroah-Hartman
>
> Any benchmark results to share?
Yes, the readfile_speed.c file will show you that on your machine, I'll
post the results of that for two of my machines when I send the next
version of this patch series.
>
> > --- /dev/null
> > +++ b/tools/testing/selftests/readfile/readfile.c
>
> > +static void readfile(const char *filename)
> > +{
> > +// int root_fd;
>
> ???
Ugh, sorry about that, I obviously didn't clean up my last tests from
this file, thanks for catching that.
I should add more tests to validate the flag handling as well, will do
all of that for the next version, thanks for noticing this.
greg k-h
Re: [PATCH] riscv: Add STACKPROTECTOR supported
On Sun, Jul 05, 2020 at 06:24:15AM +, guo...@kernel.org wrote:
> From: Guo Ren
>
> The -fstack-protector & -fstack-protector-strong features are from
> gcc. The patch only add basic kernel support to stack-protector
> feature and some arch could have its own solution such as
> ARM64_PTR_AUTH.
>
> After enabling STACKPROTECTOR and STACKPROTECTOR_STRONG, the .text
> size is expanded from 0x7de066 to 0x81fb32 (only 5%) to add canary
> checking code.
>
> Signed-off-by: Guo Ren
> Cc: Paul Walmsley
> Cc: Palmer Dabbelt
> Cc: Albert Ou
> Cc: Masami Hiramatsu
> Cc: Björn Töpel
> Cc: Greentime Hu
> Cc: Atish Patra
> ---
> arch/riscv/Kconfig | 1 +
> arch/riscv/include/asm/stackprotector.h | 29 +
> arch/riscv/kernel/process.c | 6 ++
> 3 files changed, 36 insertions(+)
> create mode 100644 arch/riscv/include/asm/stackprotector.h
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index f927a91..4b0e308 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -63,6 +63,7 @@ config RISCV
> select HAVE_PERF_EVENTS
> select HAVE_PERF_REGS
> select HAVE_PERF_USER_STACK_DUMP
> + select HAVE_STACKPROTECTOR
> select HAVE_SYSCALL_TRACEPOINTS
> select IRQ_DOMAIN
> select MODULES_USE_ELF_RELA if MODULES
> diff --git a/arch/riscv/include/asm/stackprotector.h
> b/arch/riscv/include/asm/stackprotector.h
> new file mode 100644
> index ..5962f88
> --- /dev/null
> +++ b/arch/riscv/include/asm/stackprotector.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef _ASM_RISCV_STACKPROTECTOR_H
> +#define _ASM_RISCV_STACKPROTECTOR_H
> +
> +#include
> +#include
> +
> +extern unsigned long __stack_chk_guard;
> +
> +/*
> + * Initialize the stackprotector canary value.
> + *
> + * NOTE: this must only be called from functions that never return,
> + * and it must always be inlined.
> + */
> +static __always_inline void boot_init_stack_canary(void)
> +{
> + unsigned long canary;
> +
> + /* Try to get a semi random initial value. */
> + get_random_bytes(&canary, sizeof(canary));
> + canary ^= LINUX_VERSION_CODE;
> + canary &= CANARY_MASK;
Does riscv have any kind of instruction counters or other trivial timers
that could be mixed in here? (e.g. x86's TSC)
> +
> + current->stack_canary = canary;
> + __stack_chk_guard = current->stack_canary;
What's needed for riscv to support a per-task canary? (e.g. x86's TLS or
arm64's register-specific methods)
> +}
> +#endif /* _ASM_RISCV_STACKPROTECTOR_H */
> diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
> index 824d117..6548929 100644
> --- a/arch/riscv/kernel/process.c
> +++ b/arch/riscv/kernel/process.c
> @@ -24,6 +24,12 @@
>
> register unsigned long gp_in_global __asm__("gp");
>
> +#ifdef CONFIG_STACKPROTECTOR
> +#include
> +unsigned long __stack_chk_guard __read_mostly;
> +EXPORT_SYMBOL(__stack_chk_guard);
> +#endif
> +
> extern asmlinkage void ret_from_fork(void);
> extern asmlinkage void ret_from_kernel_thread(void);
>
> --
> 2.7.4
>
But yes, as a starting point, better to have a single per-boot global
canary than none at all. :)
Reviewed-by: Kees Cook
--
Kees Cook
[PATCH v2 4/8] soc: mediatek: cmdq: add read_s function
Add read_s function in cmdq helper functions which support read value from
register or dma physical address into gce internal register.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 15 +++
include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
include/linux/soc/mediatek/mtk-cmdq.h| 12
3 files changed, 28 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 550e9e7e3ff2..ed9f5e63c195 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -227,6 +227,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
}
EXPORT_SYMBOL(cmdq_pkt_write_mask);
+int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx, u16 addr_low,
+ u16 reg_idx)
+{
+ struct cmdq_instruction inst = {};
+
+ inst.op = CMDQ_CODE_READ_S;
+ inst.dst_t = CMDQ_REG_TYPE;
+ inst.sop = high_addr_reg_idx;
+ inst.reg_dst = reg_idx;
+ inst.src_reg = addr_low;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_read_s);
+
int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
u16 addr_low, u16 src_reg_idx)
{
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 90d1d8e64412..efbd8a9eb2d1 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -60,6 +60,7 @@ enum cmdq_code {
CMDQ_CODE_JUMP = 0x10,
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
+ CMDQ_CODE_READ_S = 0x80,
CMDQ_CODE_WRITE_S = 0x90,
CMDQ_CODE_WRITE_S_MASK = 0x91,
CMDQ_CODE_LOGIC = 0xa0,
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 53230341bf94..cd7ec714344e 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -104,6 +104,18 @@ struct cmdq_client *cmdq_mbox_create(struct device *dev,
int index,
int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask);
+/*
+ * cmdq_pkt_read_s() - append read_s command to the CMDQ packet
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @reg_idx: the CMDQ internal register ID to cache read data
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx, u16 addr_low,
+ u16 reg_idx);
+
/**
* cmdq_pkt_write_s() - append write_s command to the CMDQ packet
* @pkt: the CMDQ packet
--
1.7.9.5
Subject: [PATCH v1 0/8] support cmdq helper function on mt6779 platform
This patch support more gce helper function on mt6779 platform. depends on patch: support gce on mt6779 platform and depends on following applied patches soc: mediatek: cmdq: add set event function soc: mediatek: cmdq: export finalize function soc: mediatek: cmdq: add assign function Change since v1: - Rename cmdq_mbox_shift() to cmdq_get_shift_pa(). Dennis YC Hsieh (8): soc: mediatek: cmdq: add address shift in jump soc: mediatek: cmdq: add write_s function soc: mediatek: cmdq: add write_s_mask function soc: mediatek: cmdq: add read_s function soc: mediatek: cmdq: add write_s value function soc: mediatek: cmdq: add write_s_mask value function soc: mediatek: cmdq: add jump function soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +- drivers/soc/mediatek/mtk-cmdq-helper.c | 113 ++- include/linux/mailbox/mtk-cmdq-mailbox.h | 6 +- include/linux/soc/mediatek/mtk-cmdq.h| 93 ++- 4 files changed, 206 insertions(+), 8 deletions(-) -- 2.18.0
[PATCH v2 3/8] soc: mediatek: cmdq: add write_s_mask function
add write_s_mask function in cmdq helper functions which
writes value contains in internal register to address
with mask and large dma access support.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 23 +++
include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
include/linux/soc/mediatek/mtk-cmdq.h| 18 ++
3 files changed, 42 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 880349b3f16c..550e9e7e3ff2 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -242,6 +242,29 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16
high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s);
+int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+ u16 addr_low, u16 src_reg_idx, u32 mask)
+{
+ struct cmdq_instruction inst = {};
+ int err;
+
+ inst.op = CMDQ_CODE_MASK;
+ inst.mask = ~mask;
+ err = cmdq_pkt_append_command(pkt, inst);
+ if (err < 0)
+ return err;
+
+ inst.mask = 0;
+ inst.op = CMDQ_CODE_WRITE_S_MASK;
+ inst.src_t = CMDQ_REG_TYPE;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.src_reg = src_reg_idx;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_mask);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 1f76cfedb16d..90d1d8e64412 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -61,6 +61,7 @@ enum cmdq_code {
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
CMDQ_CODE_WRITE_S = 0x90,
+ CMDQ_CODE_WRITE_S_MASK = 0x91,
CMDQ_CODE_LOGIC = 0xa0,
};
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 9b0c57a0063d..53230341bf94 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -122,6 +122,24 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16
high_addr_reg_idx,
u16 addr_low, u16 src_reg_idx);
/**
+ * cmdq_pkt_write_s_mask() - append write_s with mask command to the CMDQ
packet
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @src_reg_idx: the CMDQ internal register ID which cache source value
+ * @mask: the specified target address mask, use U32_MAX if no need
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ * Support write value to physical address without subsys. Use CMDQ_ADDR_HIGH()
+ * to get high address and call cmdq_pkt_assign() to assign value into internal
+ * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low parameter when
+ * call to this function.
+ */
+int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+ u16 addr_low, u16 src_reg_idx, u32 mask);
+
+/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
* @event: the desired event type to "wait and CLEAR"
--
1.7.9.5
[PATCH v2 5/8] soc: mediatek: cmdq: add write_s value function
add write_s function in cmdq helper functions which
writes a constant value to address with large dma
access support.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 14 ++
include/linux/soc/mediatek/mtk-cmdq.h | 13 +
2 files changed, 27 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index ed9f5e63c195..4e86b65815fc 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -280,6 +280,20 @@ int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16
high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s_mask);
+int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value)
+{
+ struct cmdq_instruction inst = {};
+
+ inst.op = CMDQ_CODE_WRITE_S;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.value = value;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_value);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index cd7ec714344e..ae73e10da274 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -152,6 +152,19 @@ int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16
high_addr_reg_idx,
u16 addr_low, u16 src_reg_idx, u32 mask);
/**
+ * cmdq_pkt_write_s_value() - append write_s command to the CMDQ packet which
+ * write value to a physical address
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @value: the specified target value
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value);
+
+/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
* @event: the desired event type to "wait and CLEAR"
--
1.7.9.5
[PATCH v2 1/8] soc: mediatek: cmdq: add address shift in jump
Add address shift when compose jump instruction to compatible with 35bit format. Signed-off-by: Dennis YC Hsieh --- drivers/soc/mediatek/mtk-cmdq-helper.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c index dc644cfb6419..9faf78fbed3a 100644 --- a/drivers/soc/mediatek/mtk-cmdq-helper.c +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c @@ -329,7 +329,8 @@ int cmdq_pkt_finalize(struct cmdq_pkt *pkt) /* JUMP to end */ inst.op = CMDQ_CODE_JUMP; - inst.value = CMDQ_JUMP_PASS; + inst.value = CMDQ_JUMP_PASS >> + cmdq_get_shift_pa(((struct cmdq_client *)pkt->cl)->chan); err = cmdq_pkt_append_command(pkt, inst); return err; -- 1.7.9.5
[PATCH v2 7/8] soc: mediatek: cmdq: add jump function
Add jump function so that client can jump to any address which
contains instruction.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 13 +
include/linux/soc/mediatek/mtk-cmdq.h | 11 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index b6e25f216605..d55dc3296105 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -13,6 +13,7 @@
#define CMDQ_POLL_ENABLE_MASK BIT(0)
#define CMDQ_EOC_IRQ_ENBIT(0)
#define CMDQ_REG_TYPE 1
+#define CMDQ_JUMP_RELATIVE 1
struct cmdq_instruction {
union {
@@ -407,6 +408,18 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32
value)
}
EXPORT_SYMBOL(cmdq_pkt_assign);
+int cmdq_pkt_jump(struct cmdq_pkt *pkt, dma_addr_t addr)
+{
+ struct cmdq_instruction inst = {};
+
+ inst.op = CMDQ_CODE_JUMP;
+ inst.offset = CMDQ_JUMP_RELATIVE;
+ inst.value = addr >>
+ cmdq_get_shift_pa(((struct cmdq_client *)pkt->cl)->chan);
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_jump);
+
int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index d9390d76ee14..34354e952f60 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -253,6 +253,17 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
/**
+ * cmdq_pkt_jump() - Append jump command to the CMDQ packet, ask GCE
+ * to execute an instruction that change current thread PC to
+ * a physical address which should contains more instruction.
+ * @pkt:the CMDQ packet
+ * @addr: physical address of target instruction buffer
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_jump(struct cmdq_pkt *pkt, dma_addr_t addr);
+
+/**
* cmdq_pkt_finalize() - Append EOC and jump command to pkt.
* @pkt: the CMDQ packet
*
--
1.7.9.5
[PATCH v2 2/8] soc: mediatek: cmdq: add write_s function
add write_s function in cmdq helper functions which
writes value contains in internal register to address
with large dma access support.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 19 +++
include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
include/linux/soc/mediatek/mtk-cmdq.h| 19 +++
3 files changed, 39 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 9faf78fbed3a..880349b3f16c 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -18,6 +18,10 @@ struct cmdq_instruction {
union {
u32 value;
u32 mask;
+ struct {
+ u16 arg_c;
+ u16 src_reg;
+ };
};
union {
u16 offset;
@@ -223,6 +227,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
}
EXPORT_SYMBOL(cmdq_pkt_write_mask);
+int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+u16 addr_low, u16 src_reg_idx)
+{
+ struct cmdq_instruction inst = {};
+
+ inst.op = CMDQ_CODE_WRITE_S;
+ inst.src_t = CMDQ_REG_TYPE;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.src_reg = src_reg_idx;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 05eea1aef5aa..1f76cfedb16d 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -60,6 +60,7 @@ enum cmdq_code {
CMDQ_CODE_JUMP = 0x10,
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
+ CMDQ_CODE_WRITE_S = 0x90,
CMDQ_CODE_LOGIC = 0xa0,
};
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 2249ecaf77e4..9b0c57a0063d 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -12,6 +12,8 @@
#include
#define CMDQ_NO_TIMEOUT0xu
+#define CMDQ_ADDR_HIGH(addr) ((u32)(((addr) >> 16) & GENMASK(31, 0)))
+#define CMDQ_ADDR_LOW(addr)((u16)(addr) | BIT(1))
struct cmdq_pkt;
@@ -103,6 +105,23 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask);
/**
+ * cmdq_pkt_write_s() - append write_s command to the CMDQ packet
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @src_reg_idx: the CMDQ internal register ID which cache source value
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ * Support write value to physical address without subsys. Use CMDQ_ADDR_HIGH()
+ * to get high address and call cmdq_pkt_assign() to assign value into internal
+ * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low parameter when
+ * call to this function.
+ */
+int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+u16 addr_low, u16 src_reg_idx);
+
+/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
* @event: the desired event type to "wait and CLEAR"
--
1.7.9.5
[PATCH v2 8/8] soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api
Add clear parameter to let client decide if
event should be clear to 0 after GCE receive it.
Fixes: 2f965be7f9008 ("drm/mediatek: apply CMDQ control flow")
Signed-off-by: Dennis YC Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c |2 +-
drivers/soc/mediatek/mtk-cmdq-helper.c |5 +++--
include/linux/mailbox/mtk-cmdq-mailbox.h |3 +--
include/linux/soc/mediatek/mtk-cmdq.h|5 +++--
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index ec6c9ffbf35e..ba6cf956b239 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -490,7 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc
*mtk_crtc)
mbox_flush(mtk_crtc->cmdq_client->chan, 2000);
cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
- cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
+ cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
mtk_crtc_ddp_config(crtc, cmdq_handle);
cmdq_pkt_finalize(cmdq_handle);
cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index d55dc3296105..505651b0d715 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -316,15 +316,16 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8
high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear)
{
struct cmdq_instruction inst = { {0} };
+ u32 clear_option = clear ? CMDQ_WFE_UPDATE : 0;
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
inst.op = CMDQ_CODE_WFE;
- inst.value = CMDQ_WFE_OPTION;
+ inst.value = CMDQ_WFE_OPTION | clear_option;
inst.event = event;
return cmdq_pkt_append_command(pkt, inst);
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index efbd8a9eb2d1..d5a983d65f05 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -28,8 +28,7 @@
* bit 16-27: update value
* bit 31: 1 - update, 0 - no update
*/
-#define CMDQ_WFE_OPTION(CMDQ_WFE_UPDATE |
CMDQ_WFE_WAIT | \
- CMDQ_WFE_WAIT_VALUE)
+#define CMDQ_WFE_OPTION(CMDQ_WFE_WAIT |
CMDQ_WFE_WAIT_VALUE)
/** cmdq event maximum */
#define CMDQ_MAX_EVENT 0x3ff
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 34354e952f60..960704d75994 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -182,11 +182,12 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8
high_addr_reg_idx,
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
- * @event: the desired event type to "wait and CLEAR"
+ * @event: the desired event type to wait
+ * @clear: clear event or not after event arrive
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear);
/**
* cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
--
1.7.9.5
[PATCH v2 6/8] soc: mediatek: cmdq: add write_s_mask value function
add write_s_mask_value function in cmdq helper functions which
writes a constant value to address with mask and large dma
access support.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 21 +
include/linux/soc/mediatek/mtk-cmdq.h | 15 +++
2 files changed, 36 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 4e86b65815fc..b6e25f216605 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -294,6 +294,27 @@ int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8
high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s_value);
+int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value, u32 mask)
+{
+ struct cmdq_instruction inst = {};
+ int err;
+
+ inst.op = CMDQ_CODE_MASK;
+ inst.mask = ~mask;
+ err = cmdq_pkt_append_command(pkt, inst);
+ if (err < 0)
+ return err;
+
+ inst.op = CMDQ_CODE_WRITE_S_MASK;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.value = value;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index ae73e10da274..d9390d76ee14 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -165,6 +165,21 @@ int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8
high_addr_reg_idx,
u16 addr_low, u32 value);
/**
+ * cmdq_pkt_write_s_mask_value() - append write_s command with mask to the CMDQ
+ *packet which write value to a physical
+ *address
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @value: the specified target value
+ * @mask: the specified target mask
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value, u32 mask);
+
+/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
* @event: the desired event type to "wait and CLEAR"
--
1.7.9.5
Re: [PATCH v5 0/6] arm64: add the time namespace support
On Wed, Jun 24, 2020 at 01:33:15AM -0700, Andrei Vagin wrote: > Allocate the time namespace page among VVAR pages and add the logic > to handle faults on VVAR properly. > > If a task belongs to a time namespace then the VVAR page which contains > the system wide VDSO data is replaced with a namespace specific page > which has the same layout as the VVAR page. That page has vdso_data->seq > set to 1 to enforce the slow path and vdso_data->clock_mode set to > VCLOCK_TIMENS to enforce the time namespace handling path. > > The extra check in the case that vdso_data->seq is odd, e.g. a concurrent > update of the VDSO data is in progress, is not really affecting regular > tasks which are not part of a time namespace as the task is spin waiting > for the update to finish and vdso_data->seq to become even again. > > If a time namespace task hits that code path, it invokes the corresponding > time getter function which retrieves the real VVAR page, reads host time > and then adds the offset for the requested clock which is stored in the > special VVAR page. > > v2: Code cleanups suggested by Vincenzo. > v3: add a comment in __arch_get_timens_vdso_data. > v4: - fix an issue reported by the lkp robot. > - vvar has the same size with/without CONFIG_TIME_NAMESPACE, but the > timens page isn't allocated on !CONFIG_TIME_NAMESPACE. This > simplifies criu/vdso migration between different kernel configs. > v5: - Code cleanups suggested by Mark Rutland. > - In vdso_join_timens, mmap_write_lock is downgraded to > mmap_read_lock. The VMA list isn't changed there, zap_page_range > doesn't require mmap_write_lock. > > Reviewed-by: Vincenzo Frascino > Reviewed-by: Dmitry Safonov Hello Will and Catalin, Have you had a chance to look at this patch set? I think it is ready to be merged. Let me know if you have any questions. Thanks, Andrei
[PATCH v8 2/4] mailbox: cmdq: variablize address shift in platform
Some gce hardware shift pc and end address in register to support
large dram addressing.
Implement gce address shift when write or read pc and end register.
And add shift bit in platform definition.
Signed-off-by: Dennis YC Hsieh
---
drivers/mailbox/mtk-cmdq-mailbox.c | 57 +++---
include/linux/mailbox/mtk-cmdq-mailbox.h |2 ++
2 files changed, 46 insertions(+), 13 deletions(-)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers/mailbox/mtk-cmdq-mailbox.c
index b24822ad8409..49d9264145aa 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -75,8 +75,22 @@ struct cmdq {
struct cmdq_thread *thread;
struct clk *clock;
boolsuspended;
+ u8 shift_pa;
};
+struct gce_plat {
+ u32 thread_nr;
+ u8 shift;
+};
+
+u8 cmdq_get_shift_pa(struct mbox_chan *chan)
+{
+ struct cmdq *cmdq = container_of(chan->mbox, struct cmdq, mbox);
+
+ return cmdq->shift_pa;
+}
+EXPORT_SYMBOL(cmdq_get_shift_pa);
+
static int cmdq_thread_suspend(struct cmdq *cmdq, struct cmdq_thread *thread)
{
u32 status;
@@ -183,13 +197,15 @@ static void cmdq_task_handle_error(struct cmdq_task *task)
{
struct cmdq_thread *thread = task->thread;
struct cmdq_task *next_task;
+ struct cmdq *cmdq = task->cmdq;
- dev_err(task->cmdq->mbox.dev, "task 0x%p error\n", task);
- WARN_ON(cmdq_thread_suspend(task->cmdq, thread) < 0);
+ dev_err(cmdq->mbox.dev, "task 0x%p error\n", task);
+ WARN_ON(cmdq_thread_suspend(cmdq, thread) < 0);
next_task = list_first_entry_or_null(&thread->task_busy_list,
struct cmdq_task, list_entry);
if (next_task)
- writel(next_task->pa_base, thread->base + CMDQ_THR_CURR_ADDR);
+ writel(next_task->pa_base >> cmdq->shift_pa,
+ thread->base + CMDQ_THR_CURR_ADDR);
cmdq_thread_resume(thread);
}
@@ -219,7 +235,7 @@ static void cmdq_thread_irq_handler(struct cmdq *cmdq,
else
return;
- curr_pa = readl(thread->base + CMDQ_THR_CURR_ADDR);
+ curr_pa = readl(thread->base + CMDQ_THR_CURR_ADDR) << cmdq->shift_pa;
list_for_each_entry_safe(task, tmp, &thread->task_busy_list,
list_entry) {
@@ -335,27 +351,31 @@ static int cmdq_mbox_send_data(struct mbox_chan *chan,
void *data)
WARN_ON(clk_enable(cmdq->clock) < 0);
WARN_ON(cmdq_thread_reset(cmdq, thread) < 0);
- writel(task->pa_base, thread->base + CMDQ_THR_CURR_ADDR);
- writel(task->pa_base + pkt->cmd_buf_size,
+ writel(task->pa_base >> cmdq->shift_pa,
+ thread->base + CMDQ_THR_CURR_ADDR);
+ writel((task->pa_base + pkt->cmd_buf_size) >> cmdq->shift_pa,
thread->base + CMDQ_THR_END_ADDR);
+
writel(thread->priority, thread->base + CMDQ_THR_PRIORITY);
writel(CMDQ_THR_IRQ_EN, thread->base + CMDQ_THR_IRQ_ENABLE);
writel(CMDQ_THR_ENABLED, thread->base + CMDQ_THR_ENABLE_TASK);
} else {
WARN_ON(cmdq_thread_suspend(cmdq, thread) < 0);
- curr_pa = readl(thread->base + CMDQ_THR_CURR_ADDR);
- end_pa = readl(thread->base + CMDQ_THR_END_ADDR);
+ curr_pa = readl(thread->base + CMDQ_THR_CURR_ADDR) <<
+ cmdq->shift_pa;
+ end_pa = readl(thread->base + CMDQ_THR_END_ADDR) <<
+ cmdq->shift_pa;
/* check boundary */
if (curr_pa == end_pa - CMDQ_INST_SIZE ||
curr_pa == end_pa) {
/* set to this task directly */
- writel(task->pa_base,
+ writel(task->pa_base >> cmdq->shift_pa,
thread->base + CMDQ_THR_CURR_ADDR);
} else {
cmdq_task_insert_into_thread(task);
smp_mb(); /* modify jump before enable thread */
}
- writel(task->pa_base + pkt->cmd_buf_size,
+ writel((task->pa_base + pkt->cmd_buf_size) >> cmdq->shift_pa,
thread->base + CMDQ_THR_END_ADDR);
cmdq_thread_resume(thread);
}
@@ -453,6 +473,7 @@ static int cmdq_probe(struct platform_device *pdev)
struct resource *res;
struct cmdq *cmdq;
int err, i;
+ struct gce_plat *plat_data;
cmdq = devm_kzalloc(dev, sizeof(*cmdq), GFP_KERNEL);
if (!cmdq)
@@ -471,7 +492,14 @@ static int cmdq_probe(struct platform_device *pdev)
return -EINVAL;
}
- cmdq->thread_nr = (u32)(unsigned long)of_device_get_match_data(dev);
+ plat_data = (struct gce_plat *)of_device_get_match_data(dev);
+
[PATCH v8 0/4] support gce on mt6779 platform
This patch support gce on mt6779 platform. Change since v7: - Rename cmdq_mbox_shift() to cmdq_get_shift_pa(). Change since v6: - Separate all helper function to another patchset. Change since v5: - spearate address shift code in client helper and mailbox controller - separate write_s/write_s_mask and write_s_value/write_s_mask_value so that client can decide use mask or not - fix typo in header [... snip ...] Dennis YC Hsieh (4): dt-binding: gce: add gce header file for mt6779 mailbox: cmdq: variablize address shift in platform mailbox: cmdq: support mt6779 gce platform definition mailbox: mediatek: cmdq: clear task in channel before shutdown .../devicetree/bindings/mailbox/mtk-gce.txt | 8 +- drivers/mailbox/mtk-cmdq-mailbox.c| 97 +++- include/dt-bindings/gce/mt6779-gce.h | 222 ++ include/linux/mailbox/mtk-cmdq-mailbox.h | 2 + 4 files changed, 313 insertions(+), 16 deletions(-) create mode 100644 include/dt-bindings/gce/mt6779-gce.h -- 2.18.0
[PATCH v8 3/4] mailbox: cmdq: support mt6779 gce platform definition
Add gce v4 hardware support with different thread number and shift.
Signed-off-by: Dennis YC Hsieh
Reviewed-by: CK Hu
Reviewed-by: Matthias Brugger
Reviewed-by: Bibby Hsieh
---
drivers/mailbox/mtk-cmdq-mailbox.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers/mailbox/mtk-cmdq-mailbox.c
index 49d9264145aa..08bd4f1eb469 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -564,10 +564,12 @@ static int cmdq_probe(struct platform_device *pdev)
static const struct gce_plat gce_plat_v2 = {.thread_nr = 16};
static const struct gce_plat gce_plat_v3 = {.thread_nr = 24};
+static const struct gce_plat gce_plat_v4 = {.thread_nr = 24, .shift = 3};
static const struct of_device_id cmdq_of_ids[] = {
{.compatible = "mediatek,mt8173-gce", .data = (void *)&gce_plat_v2},
{.compatible = "mediatek,mt8183-gce", .data = (void *)&gce_plat_v3},
+ {.compatible = "mediatek,mt6779-gce", .data = (void *)&gce_plat_v4},
{}
};
--
1.7.9.5
[PATCH v8 1/4] dt-binding: gce: add gce header file for mt6779
Add documentation for the mt6779 gce. Add gce header file defined the gce hardware event, subsys number and constant for mt6779. Signed-off-by: Dennis YC Hsieh Reviewed-by: Rob Herring Reviewed-by: CK Hu Reviewed-by: Bibby Hsieh --- .../devicetree/bindings/mailbox/mtk-gce.txt|8 +- include/dt-bindings/gce/mt6779-gce.h | 222 2 files changed, 227 insertions(+), 3 deletions(-) create mode 100644 include/dt-bindings/gce/mt6779-gce.h diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index 0b5b2a6bcc48..cf48cd806e00 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -9,7 +9,8 @@ CMDQ driver uses mailbox framework for communication. Please refer to mailbox.txt for generic information about mailbox device-tree bindings. Required properties: -- compatible: can be "mediatek,mt8173-gce" or "mediatek,mt8183-gce" +- compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce" or + "mediatek,mt6779-gce". - reg: Address range of the GCE unit - interrupts: The interrupt signal from the GCE block - clock: Clocks according to the common clock binding @@ -34,8 +35,9 @@ Optional properties for a client device: start_offset: the start offset of register address that GCE can access. size: the total size of register address that GCE can access. -Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h' -or 'dt-binding/gce/mt8183-gce.h'. Such as sub-system ids, thread priority, event ids. +Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h', +'dt-binding/gce/mt8183-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. Such as +sub-system ids, thread priority, event ids. Example: diff --git a/include/dt-bindings/gce/mt6779-gce.h b/include/dt-bindings/gce/mt6779-gce.h new file mode 100644 index ..06101316ace4 --- /dev/null +++ b/include/dt-bindings/gce/mt6779-gce.h @@ -0,0 +1,222 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2019 MediaTek Inc. + * Author: Dennis-YC Hsieh + */ + +#ifndef _DT_BINDINGS_GCE_MT6779_H +#define _DT_BINDINGS_GCE_MT6779_H + +#define CMDQ_NO_TIMEOUT0x + +/* GCE HW thread priority */ +#define CMDQ_THR_PRIO_LOWEST 0 +#define CMDQ_THR_PRIO_11 +#define CMDQ_THR_PRIO_22 +#define CMDQ_THR_PRIO_33 +#define CMDQ_THR_PRIO_44 +#define CMDQ_THR_PRIO_55 +#define CMDQ_THR_PRIO_66 +#define CMDQ_THR_PRIO_HIGHEST 7 + +/* GCE subsys table */ +#define SUBSYS_13000 +#define SUBSYS_14001 +#define SUBSYS_14012 +#define SUBSYS_14023 +#define SUBSYS_15024 +#define SUBSYS_18805 +#define SUBSYS_18816 +#define SUBSYS_18827 +#define SUBSYS_18838 +#define SUBSYS_18849 +#define SUBSYS_100010 +#define SUBSYS_100111 +#define SUBSYS_100212 +#define SUBSYS_100313 +#define SUBSYS_100414 +#define SUBSYS_100515 +#define SUBSYS_102016 +#define SUBSYS_102817 +#define SUBSYS_170018 +#define SUBSYS_170119 +#define SUBSYS_170220 +#define SUBSYS_170321 +#define SUBSYS_180022 +#define SUBSYS_180123 +#define SUBSYS_180224 +#define SUBSYS_180425 +#define SUBSYS_180526 +#define SUBSYS_180827 +#define SUBSYS_180a28 +#define SUBSYS_180b29 +#define CMDQ_SUBSYS_OFF32 + +/* GCE hardware events */ +#define CMDQ_EVENT_DISP_RDMA0_SOF 0 +#define CMDQ_EVENT_DISP_RDMA1_SOF 1 +#define CMDQ_EVENT_MDP_RDMA0_SOF 2 +#define CMDQ_EVENT_MDP_RDMA1_SOF 3 +#define CMDQ_EVENT_MDP_RSZ0_SOF4 +#define CMDQ_EVENT_MDP_RSZ1_SOF5 +#define CMDQ_EVENT_MDP_TDSHP_SOF 6 +#define CMDQ_EVENT_MDP_WROT0_SOF 7 +#define CMDQ_EVENT_MDP_WROT1_SOF 8 +#define CMDQ_EVENT_DISP_OVL0_SOF 9 +#define CMDQ_EVENT_DISP_2L_OVL0_SOF10 +#define CMDQ_EVENT_DISP_2L_OVL1_SOF11 +#define CMDQ_EVENT_DISP_WDMA0_SOF 12 +#define CMDQ_EVENT_DISP_COLOR0_SOF 13 +#define CMDQ_EVENT_DISP_CCORR0_SOF 14 +#define CMDQ_EVENT_DISP_AAL0_SOF 15 +#define CMDQ_EVENT_DISP_GAMMA0_SOF 16 +#define CMDQ_EVENT_DISP_DITHER0_SOF17 +#define CMDQ_EVENT_DISP_PWM0_SOF
[PATCH v8 4/4] mailbox: mediatek: cmdq: clear task in channel before shutdown
Do success callback in channel when shutdown. For those task not finish,
callback with error code thus client has chance to cleanup or reset.
Signed-off-by: Dennis YC Hsieh
Reviewed-by: CK Hu
Reviewed-by: Bibby Hsieh
---
drivers/mailbox/mtk-cmdq-mailbox.c | 38
1 file changed, 38 insertions(+)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers/mailbox/mtk-cmdq-mailbox.c
index 08bd4f1eb469..484d4438cd83 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -349,6 +349,12 @@ static int cmdq_mbox_send_data(struct mbox_chan *chan,
void *data)
if (list_empty(&thread->task_busy_list)) {
WARN_ON(clk_enable(cmdq->clock) < 0);
+ /*
+* The thread reset will clear thread related register to 0,
+* including pc, end, priority, irq, suspend and enable. Thus
+* set CMDQ_THR_ENABLED to CMDQ_THR_ENABLE_TASK will enable
+* thread and make it running.
+*/
WARN_ON(cmdq_thread_reset(cmdq, thread) < 0);
writel(task->pa_base >> cmdq->shift_pa,
@@ -391,6 +397,38 @@ static int cmdq_mbox_startup(struct mbox_chan *chan)
static void cmdq_mbox_shutdown(struct mbox_chan *chan)
{
+ struct cmdq_thread *thread = (struct cmdq_thread *)chan->con_priv;
+ struct cmdq *cmdq = dev_get_drvdata(chan->mbox->dev);
+ struct cmdq_task *task, *tmp;
+ unsigned long flags;
+
+ spin_lock_irqsave(&thread->chan->lock, flags);
+ if (list_empty(&thread->task_busy_list))
+ goto done;
+
+ WARN_ON(cmdq_thread_suspend(cmdq, thread) < 0);
+
+ /* make sure executed tasks have success callback */
+ cmdq_thread_irq_handler(cmdq, thread);
+ if (list_empty(&thread->task_busy_list))
+ goto done;
+
+ list_for_each_entry_safe(task, tmp, &thread->task_busy_list,
+list_entry) {
+ cmdq_task_exec_done(task, CMDQ_CB_ERROR);
+ kfree(task);
+ }
+
+ cmdq_thread_disable(cmdq, thread);
+ clk_disable(cmdq->clock);
+done:
+ /*
+* The thread->task_busy_list empty means thread already disable. The
+* cmdq_mbox_send_data() always reset thread which clear disable and
+* suspend statue when first pkt send to channel, so there is no need
+* to do any operation here, only unlock and leave.
+*/
+ spin_unlock_irqrestore(&thread->chan->lock, flags);
}
static int cmdq_mbox_flush(struct mbox_chan *chan, unsigned long timeout)
--
1.7.9.5
Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
On Jul 4, 2020, at 8:46 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
>
> On Sun, Jul 5, 2020 at 4:16 AM Matthew Wilcox wrote:
>>
>> On Sun, Jul 05, 2020 at 04:06:22AM +0200, Jan Ziak wrote:
>>> Hello
>>>
>>> At first, I thought that the proposed system call is capable of
>>> reading *multiple* small files using a single system call - which
>>> would help increase HDD/SSD queue utilization and increase IOPS (I/O
>>> operations per second) - but that isn't the case and the proposed
>>> system call can read just a single file.
>>>
>>> Without the ability to read multiple small files using a single system
>>> call, it is impossible to increase IOPS (unless an application is
>>> using multiple reader threads or somehow instructs the kernel to
>>> prefetch multiple files into memory).
>>
>> What API would you use for this?
>>
>> ssize_t readfiles(int dfd, char **files, void **bufs, size_t *lens);
>>
>> I pretty much hate this interface, so I hope you have something better
>> in mind.
>
> I am proposing the following:
>
> struct readfile_t {
> int dirfd;
> const char *pathname;
> void *buf;
> size_t count;
> int flags;
> ssize_t retval; // set by kernel
> int reserved; // not used by kernel
> };
If you are going to pass a struct from userspace to the kernel, it
should not mix int and pointer types (which may be 64-bit values,
so that there are not structure packing issues, like:
struct readfile {
int dirfd;
int flags;
const char *pathname;
void*buf;
size_t count;
ssize_t retval;
};
It would be better if "retval" was returned in "count", so that
the structure fits nicely into 32 bytes on a 64-bit system, instead
of being 40 bytes per entry, which adds up over many entries, like.
struct readfile {
int dirfd;
int flags;
const char *pathname;
void*buf;
ssize_t count; /* input: bytes requested, output: bytes read or -errno
*/
};
However, there is still an issue with passing pointers from userspace,
since they may be 32-bit userspace pointers on a 64-bit kernel.
> int readfiles(struct readfile_t *requests, size_t count);
It's not clear why count is a "size_t" since it is not a size.
An unsigned int is fine here, since it should never be negative.
> Returns zero if all requests succeeded, otherwise the returned value
> is non-zero (glibc wrapper: -1) and user-space is expected to check
> which requests have succeeded and which have failed. retval in
> readfile_t is set to what the single-file readfile syscall would
> return if it was called with the contents of the corresponding
> readfile_t struct.
>
> The glibc library wrapper of this system call is expected to store the
> errno in the "reserved" field. Thus, a programmer using glibc sees:
>
> struct readfile_t {
> int dirfd;
> const char *pathname;
> void *buf;
> size_t count;
> int flags;
> ssize_t retval; // set by glibc (-1 on error)
> int errno; // set by glibc if retval is -1
> };
Why not just return the errno directly in "retval", or in "count" as
proposed? That avoids further bloating the structure by another field.
> retval and errno in glibc's readfile_t are set to what the single-file
> glibc readfile would return (retval) and set (errno) if it was called
> with the contents of the corresponding readfile_t struct. In case of
> an error, glibc will pick one readfile_t which failed (such as: the
> 1st failed one) and use it to set glibc's errno.
Cheers, Andreas
signature.asc
Description: Message signed with OpenPGP
Hello
Good day I have a confidential business transaction I would like to discuss with you. Contact me on schs...@yandex.com for details.
[PATCH] riscv: Add STACKPROTECTOR supported
From: Guo Ren
The -fstack-protector & -fstack-protector-strong features are from
gcc. The patch only add basic kernel support to stack-protector
feature and some arch could have its own solution such as
ARM64_PTR_AUTH.
After enabling STACKPROTECTOR and STACKPROTECTOR_STRONG, the .text
size is expanded from 0x7de066 to 0x81fb32 (only 5%) to add canary
checking code.
Signed-off-by: Guo Ren
Cc: Paul Walmsley
Cc: Palmer Dabbelt
Cc: Albert Ou
Cc: Masami Hiramatsu
Cc: Björn Töpel
Cc: Greentime Hu
Cc: Atish Patra
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/stackprotector.h | 29 +
arch/riscv/kernel/process.c | 6 ++
3 files changed, 36 insertions(+)
create mode 100644 arch/riscv/include/asm/stackprotector.h
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index f927a91..4b0e308 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -63,6 +63,7 @@ config RISCV
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
+ select HAVE_STACKPROTECTOR
select HAVE_SYSCALL_TRACEPOINTS
select IRQ_DOMAIN
select MODULES_USE_ELF_RELA if MODULES
diff --git a/arch/riscv/include/asm/stackprotector.h
b/arch/riscv/include/asm/stackprotector.h
new file mode 100644
index ..5962f88
--- /dev/null
+++ b/arch/riscv/include/asm/stackprotector.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_RISCV_STACKPROTECTOR_H
+#define _ASM_RISCV_STACKPROTECTOR_H
+
+#include
+#include
+
+extern unsigned long __stack_chk_guard;
+
+/*
+ * Initialize the stackprotector canary value.
+ *
+ * NOTE: this must only be called from functions that never return,
+ * and it must always be inlined.
+ */
+static __always_inline void boot_init_stack_canary(void)
+{
+ unsigned long canary;
+
+ /* Try to get a semi random initial value. */
+ get_random_bytes(&canary, sizeof(canary));
+ canary ^= LINUX_VERSION_CODE;
+ canary &= CANARY_MASK;
+
+ current->stack_canary = canary;
+ __stack_chk_guard = current->stack_canary;
+}
+#endif /* _ASM_RISCV_STACKPROTECTOR_H */
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index 824d117..6548929 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -24,6 +24,12 @@
register unsigned long gp_in_global __asm__("gp");
+#ifdef CONFIG_STACKPROTECTOR
+#include
+unsigned long __stack_chk_guard __read_mostly;
+EXPORT_SYMBOL(__stack_chk_guard);
+#endif
+
extern asmlinkage void ret_from_fork(void);
extern asmlinkage void ret_from_kernel_thread(void);
--
2.7.4
[PATCH for-next/seccomp 0/3] Check ENOSYS under tracing
Hi, This expands the seccomp selftest to poke a architectural behavior corner that Keno Fischer noticed[1]. In the process, I took the opportunity to do the kselftest harness variant refactoring I'd been meaning to do, which made adding this test much nicer. I'd prefer this went via the seccomp tree, as it builds on top of the other recent seccomp feature addition tests. Testing and reviews are welcome! :) Thanks, -Kees [1] https://lore.kernel.org/lkml/cabv8krxa9mxpzwtyrjbafoffewhabhddipccgk-lqjo+zyu...@mail.gmail.com Kees Cook (3): selftests/harness: Clean up kern-doc for fixtures selftests/seccomp: Refactor to use fixture variants selftests/seccomp: Check ENOSYS under tracing tools/testing/selftests/kselftest_harness.h | 15 +- tools/testing/selftests/seccomp/seccomp_bpf.c | 217 ++ 2 files changed, 72 insertions(+), 160 deletions(-) -- 2.25.1
[PATCH 1/3] selftests/harness: Clean up kern-doc for fixtures
The FIXTURE*() macro kern-doc examples had the wrong names for the C code
examples associated with them. Fix those and clarify that FIXTURE_DATA()
usage should be avoided.
Cc: Shuah Khan
Cc: Jakub Kicinski
Fixes: 74bc7c97fa88 ("kselftest: add fixture variants")
Signed-off-by: Kees Cook
---
tools/testing/selftests/kselftest_harness.h | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/tools/testing/selftests/kselftest_harness.h
b/tools/testing/selftests/kselftest_harness.h
index c9f03ef93338..7f32a7099a81 100644
--- a/tools/testing/selftests/kselftest_harness.h
+++ b/tools/testing/selftests/kselftest_harness.h
@@ -195,8 +195,9 @@
*
* .. code-block:: c
*
- * FIXTURE_DATA(datatype name)
+ * FIXTURE_DATA(datatype_name)
*
+ * Almost always, you want just FIXTURE() instead (see below).
* This call may be used when the type of the fixture data
* is needed. In general, this should not be needed unless
* the *self* is being passed to a helper directly.
@@ -211,7 +212,7 @@
*
* .. code-block:: c
*
- * FIXTURE(datatype name) {
+ * FIXTURE(fixture_name) {
* type property1;
* ...
* };
@@ -238,7 +239,7 @@
*
* .. code-block:: c
*
- * FIXTURE_SETUP(fixture name) { implementation }
+ * FIXTURE_SETUP(fixture_name) { implementation }
*
* Populates the required "setup" function for a fixture. An instance of the
* datatype defined with FIXTURE_DATA() will be exposed as *self* for the
@@ -264,7 +265,7 @@
*
* .. code-block:: c
*
- * FIXTURE_TEARDOWN(fixture name) { implementation }
+ * FIXTURE_TEARDOWN(fixture_name) { implementation }
*
* Populates the required "teardown" function for a fixture. An instance of
the
* datatype defined with FIXTURE_DATA() will be exposed as *self* for the
@@ -285,7 +286,7 @@
*
* .. code-block:: c
*
- * FIXTURE_VARIANT(datatype name) {
+ * FIXTURE_VARIANT(fixture_name) {
* type property1;
* ...
* };
@@ -305,8 +306,8 @@
*
* .. code-block:: c
*
- * FIXTURE_ADD(datatype name) {
- * .property1 = val1;
+ * FIXTURE_VARIANT_ADD(fixture_name, variant_name) {
+ * .property1 = val1,
* ...
* };
*
--
2.25.1
[PATCH 3/3] selftests/seccomp: Check ENOSYS under tracing
There should be no difference between -1 and other negative syscalls
while tracing.
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Will Deacon
Cc: Keno Fischer
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 26 +++
1 file changed, 26 insertions(+)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
b/tools/testing/selftests/seccomp/seccomp_bpf.c
index 966dec340ea8..bf6aa06c435c 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -1973,6 +1973,32 @@ FIXTURE_TEARDOWN(TRACE_syscall)
teardown_trace_fixture(_metadata, self->tracer);
}
+TEST(negative_ENOSYS)
+{
+ /* Untraced negative syscalls should return ENOSYS. */
+ errno = 0;
+ EXPECT_EQ(-1, syscall(-1));
+ EXPECT_EQ(errno, ENOSYS);
+ errno = 0;
+ EXPECT_EQ(-1, syscall(-101));
+ EXPECT_EQ(errno, ENOSYS);
+}
+
+TEST_F(TRACE_syscall, negative_ENOSYS)
+{
+ /*
+* There should be no difference between an "internal" skip
+* and userspace asking for syscall "-1".
+*/
+ errno = 0;
+ EXPECT_EQ(-1, syscall(-1));
+ EXPECT_EQ(errno, ENOSYS);
+ /* And no difference for "still not valid but not -1". */
+ errno = 0;
+ EXPECT_EQ(-1, syscall(-101));
+ EXPECT_EQ(errno, ENOSYS);
+}
+
TEST_F(TRACE_syscall, syscall_allowed)
{
/* getppid works as expected (no changes). */
--
2.25.1
[PATCH 2/3] selftests/seccomp: Refactor to use fixture variants
Now that the selftest harness has variants, use them to eliminate a
bunch of copy/paste duplication.
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Jakub Kicinski
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 199 --
1 file changed, 42 insertions(+), 157 deletions(-)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
b/tools/testing/selftests/seccomp/seccomp_bpf.c
index 6439c031a85d..966dec340ea8 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -1541,6 +1541,7 @@ pid_t setup_trace_fixture(struct __test_metadata
*_metadata,
return tracer_pid;
}
+
void teardown_trace_fixture(struct __test_metadata *_metadata,
pid_t tracer)
{
@@ -1820,7 +1821,7 @@ void change_syscall(struct __test_metadata *_metadata,
EXPECT_EQ(0, ret);
}
-void tracer_syscall(struct __test_metadata *_metadata, pid_t tracee,
+void tracer_seccomp(struct __test_metadata *_metadata, pid_t tracee,
int status, void *args)
{
int ret;
@@ -1897,6 +1898,24 @@ FIXTURE(TRACE_syscall) {
pid_t tracer, mytid, mypid, parent;
};
+FIXTURE_VARIANT(TRACE_syscall) {
+ /*
+* All of the SECCOMP_RET_TRACE behaviors can be tested with either
+* SECCOMP_RET_TRACE+PTRACE_CONT or plain ptrace()+PTRACE_SYSCALL.
+* This indicates if we should use SECCOMP_RET_TRACE (false), or
+* ptrace (true).
+*/
+ bool use_ptrace;
+};
+
+FIXTURE_VARIANT_ADD(TRACE_syscall, ptrace) {
+ .use_ptrace = true,
+};
+
+FIXTURE_VARIANT_ADD(TRACE_syscall, seccomp) {
+ .use_ptrace = false,
+};
+
FIXTURE_SETUP(TRACE_syscall)
{
struct sock_filter filter[] = {
@@ -1912,12 +1931,11 @@ FIXTURE_SETUP(TRACE_syscall)
BPF_STMT(BPF_RET|BPF_K, SECCOMP_RET_TRACE | 0x1005),
BPF_STMT(BPF_RET|BPF_K, SECCOMP_RET_ALLOW),
};
-
- memset(&self->prog, 0, sizeof(self->prog));
- self->prog.filter = malloc(sizeof(filter));
- ASSERT_NE(NULL, self->prog.filter);
- memcpy(self->prog.filter, filter, sizeof(filter));
- self->prog.len = (unsigned short)ARRAY_SIZE(filter);
+ struct sock_fprog prog = {
+ .len = (unsigned short)ARRAY_SIZE(filter),
+ .filter = filter,
+ };
+ long ret;
/* Prepare some testable syscall results. */
self->mytid = syscall(__NR_gettid);
@@ -1935,60 +1953,28 @@ FIXTURE_SETUP(TRACE_syscall)
ASSERT_NE(self->parent, self->mypid);
/* Launch tracer. */
- self->tracer = setup_trace_fixture(_metadata, tracer_syscall, NULL,
- false);
-}
-
-FIXTURE_TEARDOWN(TRACE_syscall)
-{
- teardown_trace_fixture(_metadata, self->tracer);
- if (self->prog.filter)
- free(self->prog.filter);
-}
+ self->tracer = setup_trace_fixture(_metadata,
+ variant->use_ptrace ? tracer_ptrace
+ : tracer_seccomp,
+ NULL, variant->use_ptrace);
-TEST_F(TRACE_syscall, ptrace_syscall_redirected)
-{
- /* Swap SECCOMP_RET_TRACE tracer for PTRACE_SYSCALL tracer. */
- teardown_trace_fixture(_metadata, self->tracer);
- self->tracer = setup_trace_fixture(_metadata, tracer_ptrace, NULL,
- true);
-
- /* Tracer will redirect getpid to getppid. */
- EXPECT_NE(self->mypid, syscall(__NR_getpid));
-}
+ ret = prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
+ ASSERT_EQ(0, ret);
-TEST_F(TRACE_syscall, ptrace_syscall_errno)
-{
- /* Swap SECCOMP_RET_TRACE tracer for PTRACE_SYSCALL tracer. */
- teardown_trace_fixture(_metadata, self->tracer);
- self->tracer = setup_trace_fixture(_metadata, tracer_ptrace, NULL,
- true);
+ if (variant->use_ptrace)
+ return;
- /* Tracer should skip the open syscall, resulting in ESRCH. */
- EXPECT_SYSCALL_RETURN(-ESRCH, syscall(__NR_openat));
+ ret = prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog, 0, 0);
+ ASSERT_EQ(0, ret);
}
-TEST_F(TRACE_syscall, ptrace_syscall_faked)
+FIXTURE_TEARDOWN(TRACE_syscall)
{
- /* Swap SECCOMP_RET_TRACE tracer for PTRACE_SYSCALL tracer. */
teardown_trace_fixture(_metadata, self->tracer);
- self->tracer = setup_trace_fixture(_metadata, tracer_ptrace, NULL,
- true);
-
- /* Tracer should skip the gettid syscall, resulting fake pid. */
- EXPECT_SYSCALL_RETURN(45000, syscall(__NR_gettid));
}
TEST_F(TRACE_syscall, syscall_allowed)
{
- long ret;
-
- ret = prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
- ASSERT_EQ(0, ret);
-
- ret = prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &self->prog
Re: [PATCH V6] serial: msm_geni_serial_console : Add Earlycon support
Hi Akash,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tty/tty-testing]
[also build test WARNING on usb/usb-testing v5.8-rc3 next-20200703]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Akash-Asthana/serial-msm_geni_serial_console-Add-Earlycon-support/20200622-181041
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
tty-testing
config: m68k-randconfig-r003-20200705 (attached as .config)
compiler: m68k-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
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/tty/serial/msm_geni_serial_console.c: In function
'msm_geni_serial_earlycon_setup':
>> drivers/tty/serial/msm_geni_serial_console.c:400:6: warning: variable
>> 'rx_stale' set but not used [-Wunused-but-set-variable]
400 | u32 rx_stale = 0;
| ^~~~
>> drivers/tty/serial/msm_geni_serial_console.c:398:6: warning: variable
>> 'rx_parity_cfg' set but not used [-Wunused-but-set-variable]
398 | u32 rx_parity_cfg = 0;
| ^
>> drivers/tty/serial/msm_geni_serial_console.c:397:6: warning: variable
>> 'rx_trans_cfg' set but not used [-Wunused-but-set-variable]
397 | u32 rx_trans_cfg = 0;
| ^~~~
vim +/rx_stale +400 drivers/tty/serial/msm_geni_serial_console.c
388
389 static int __init
390 msm_geni_serial_earlycon_setup(struct earlycon_device *dev,
391 const char *opt)
392 {
393 struct uart_port *uport = &dev->port;
394 int ret = 0;
395 u32 tx_trans_cfg = 0;
396 u32 tx_parity_cfg = 0;
> 397 u32 rx_trans_cfg = 0;
> 398 u32 rx_parity_cfg = 0;
399 u32 stop_bit = 0;
> 400 u32 rx_stale = 0;
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH v2] phy: samsung: Use readl_poll_timeout function
User readl_poll_timeout function instead of open
coded handling in crport_handshake function.
Fixes: d8c80bb3b55b ("phy: exynos5-usbdrd: Calibrate LOS levels for
exynos5420/5800")
Signed-off-by: Anand Moon
---
Changes v2:
--used the default timeout values.
--Added missing Fixed tags.
---
drivers/phy/samsung/phy-exynos5-usbdrd.c | 37 +---
1 file changed, 13 insertions(+), 24 deletions(-)
diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c
b/drivers/phy/samsung/phy-exynos5-usbdrd.c
index e510732afb8b..c97f5fb6a9a0 100644
--- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
+++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -556,40 +557,28 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
u32 val, u32 cmd)
{
- u32 usec = 100;
+ u32 timeout_us = 100, sleep_us = 1;
unsigned int result;
+ int err;
writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
- do {
- result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
- if (result & PHYREG1_CR_ACK)
- break;
-
- udelay(1);
- } while (usec-- > 0);
-
- if (!usec) {
- dev_err(phy_drd->dev,
- "CRPORT handshake timeout1 (0x%08x)\n", val);
+ err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
+ result, (result & PHYREG1_CR_ACK), sleep_us,
timeout_us);
+ if (err) {
+ dev_err(phy_drd->dev, "CRPORT handshake timeout1 (0x%08x)\n",
val);
return -ETIME;
}
- usec = 100;
+ timeout_us = 100;
+ sleep_us = 1;
writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
- do {
- result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
- if (!(result & PHYREG1_CR_ACK))
- break;
-
- udelay(1);
- } while (usec-- > 0);
-
- if (!usec) {
- dev_err(phy_drd->dev,
- "CRPORT handshake timeout2 (0x%08x)\n", val);
+ err = readl_poll_timeout(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1,
+ result, !(result & PHYREG1_CR_ACK), sleep_us,
timeout_us);
+ if (err) {
+ dev_err(phy_drd->dev, "CRPORT handshake timeout2 (0x%08x)\n",
val);
return -ETIME;
}
--
2.27.0
Re: [PATCH v3 3/4] thermal: core: genetlink support for events/cmd/sampling
On Fri, 2020-07-03 at 10:53 +0200, Daniel Lezcano wrote:
> Initially the thermal framework had a very simple notification
> mechanism to send generic netlink messages to the userspace.
>
> The notification function was never called from anywhere and the
> corresponding dead code was removed. It was probably a first attempt
> to introduce the netlink notification.
>
> At LPC2018, the presentation "Linux thermal: User kernel interface",
> proposed to create the notifications to the userspace via a kfifo.
>
> The advantage of the kfifo is the performance. It is usually used
> from
> a 1:1 communication channel where a driver captures data and sends it
> as fast as possible to a userspace process.
>
> The drawback is that only one process uses the notification channel
> exclusively, thus no other process is allowed to use the channel to
> get temperature or notifications.
>
> This patch defines a generic netlink API to discover the current
> thermal setup and adds event notifications as well as temperature
> sampling. As any genetlink protocol, it can evolve and the versioning
> allows to keep the backward compatibility.
>
> In order to prevent the user from getting flooded with data on a
> single channel, there are two multicast channels, one for the
> temperature sampling when the thermal zone is updated and another one
> for the events, so the user can get the events only without the
> thermal zone temperature sampling.
>
> Also, a list of commands to discover the thermal setup is added and
> can be extended when needed.
>
> Signed-off-by: Daniel Lezcano
> ---
> v3:
> - Fixed changelog from Amit Kucheria suggestions
> - Prefixed fields in the parameter structure (trip_*, cdev_*)
> - Fixed leading whitespaces errors
> - Replaced id by trip_id
> - s/THERMAL_GENL_CMD_TZ_GET/THERMAL_GENL_CMD_TZ_GET_ID/
> - Added the cdev max state in the cdev change event
> - Removed min state
> - Fixed checkpatch warnings
> ---
> ---
> drivers/thermal/Makefile | 2 +-
> drivers/thermal/thermal_core.h| 18 +
> drivers/thermal/thermal_netlink.c | 650
> ++
> include/linux/thermal.h | 17 -
> include/uapi/linux/thermal.h | 90 -
> 5 files changed, 742 insertions(+), 35 deletions(-)
> create mode 100644 drivers/thermal/thermal_netlink.c
>
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 0c8b84a09b9a..1bbf0805fb04 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -5,7 +5,7 @@
>
> obj-$(CONFIG_THERMAL)+= thermal_sys.o
> thermal_sys-y+= thermal_core.o
> thermal_sysfs.o \
> - thermal_helpers.o
> + thermal_helpers.o
> thermal_netlink.o
>
> # interface to/from other layers providing sensors
> thermal_sys-$(CONFIG_THERMAL_HWMON) += thermal_hwmon.o
> diff --git a/drivers/thermal/thermal_core.h
> b/drivers/thermal/thermal_core.h
> index 4f8389efaa62..12bca87fb709 100644
> --- a/drivers/thermal/thermal_core.h
> +++ b/drivers/thermal/thermal_core.h
> @@ -52,6 +52,24 @@ int for_each_thermal_governor(int (*cb)(struct
> thermal_governor *, void *),
>
> struct thermal_zone_device *thermal_zone_get_by_id(int id);
>
> +/* Netlink notification function */
> +int thermal_notify_tz_create(int tz_id, const char *name);
> +int thermal_notify_tz_delete(int tz_id);
> +int thermal_notify_tz_enable(int tz_id);
> +int thermal_notify_tz_disable(int tz_id);
> +int thermal_notify_tz_trip_down(int tz_id, int id);
> +int thermal_notify_tz_trip_up(int tz_id, int id);
> +int thermal_notify_tz_trip_delete(int tz_id, int id);
> +int thermal_notify_tz_trip_add(int tz_id, int id, int type,
> +int temp, int hyst);
> +int thermal_notify_tz_trip_change(int tz_id, int id, int type,
> + int temp, int hyst);
> +int thermal_notify_cdev_update(int cdev_id, int state);
> +int thermal_notify_cdev_add(int cdev_id, const char *name, int
> max_state);
> +int thermal_notify_cdev_delete(int cdev_id);
> +int thermal_notify_tz_gov_change(int tz_id, const char *name);
> +int thermal_genl_sampling_temp(int id, int temp);
> +
> struct thermal_attr {
> struct device_attribute attr;
> char name[THERMAL_NAME_LENGTH];
> diff --git a/drivers/thermal/thermal_netlink.c
> b/drivers/thermal/thermal_netlink.c
> new file mode 100644
> index ..d3c48bbcd269
> --- /dev/null
> +++ b/drivers/thermal/thermal_netlink.c
> @@ -0,0 +1,650 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2020 Linaro Limited
> + *
> + * Author: Daniel Lezcano
> + *
> + * Generic netlink for thermal management framework
> + */
> +#include
> +#include
> +#include
> +#include
> +
> +#include "thermal_core.h"
> +
> +static const struct genl_multicast_group thermal_genl_mcgrps[] = {
> + { .name = THERMAL_GENL_SAMPLING
Re: [PATCH v3 1/3] Correct asm VMXOFF side effects
On 7/4/20 1:38 PM, David P. Reed wrote:
> Tell gcc that VMXOFF instruction clobbers condition codes
> and memory when executed.
> Also, correct original comments to remove kernel-doc syntax
> per Randy Dunlap's request.
Looks good. Thanks. For the comment changes:
Acked-by: Randy Dunlap
> Suggested-by: Randy Dunlap
> Signed-off-by: David P. Reed
> ---
> arch/x86/include/asm/virtext.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/include/asm/virtext.h b/arch/x86/include/asm/virtext.h
> index 9aad0e0876fb..0ede8d04535a 100644
> --- a/arch/x86/include/asm/virtext.h
> +++ b/arch/x86/include/asm/virtext.h
> @@ -30,7 +30,7 @@ static inline int cpu_has_vmx(void)
> }
>
>
> -/** Disable VMX on the current CPU
> +/* Disable VMX on the current CPU
> *
> * vmxoff causes a undefined-opcode exception if vmxon was not run
> * on the CPU previously. Only call this function if you know VMX
> @@ -38,7 +38,7 @@ static inline int cpu_has_vmx(void)
> */
> static inline void cpu_vmxoff(void)
> {
> - asm volatile ("vmxoff");
> + asm volatile ("vmxoff" ::: "cc", "memory");
> cr4_clear_bits(X86_CR4_VMXE);
> }
>
> @@ -47,7 +47,7 @@ static inline int cpu_vmx_enabled(void)
> return __read_cr4() & X86_CR4_VMXE;
> }
>
> -/** Disable VMX if it is enabled on the current CPU
> +/* Disable VMX if it is enabled on the current CPU
> *
> * You shouldn't call this if cpu_has_vmx() returns 0.
> */
> @@ -57,7 +57,7 @@ static inline void __cpu_emergency_vmxoff(void)
> cpu_vmxoff();
> }
>
> -/** Disable VMX if it is supported and enabled on the current CPU
> +/* Disable VMX if it is supported and enabled on the current CPU
> */
> static inline void cpu_emergency_vmxoff(void)
> {
>
--
~Randy
Re: [PATCH v2 0/8] selftests/harness: Switch to TAP output
On Mon, Jun 22, 2020 at 11:16:43AM -0700, Kees Cook wrote: > Hi, > > v2: > - switch harness from XFAIL to SKIP > - pass skip reason from test into TAP output > - add acks/reviews > v1: > https://lore.kernel.org/lkml/20200611224028.3275174-1-keesc...@chromium.org/ > > > I finally got around to converting the kselftest_harness.h API to actually > use the kselftest.h API so all the tools using it can actually report > TAP correctly. As part of this, there are a bunch of related cleanups, > API updates, and additions. Friendly ping -- I'd love to get this landed for -next, it makes doing seccomp testing much nicer. :) Thanks! -Kees > > Thanks! > > -Kees > > Kees Cook (8): > selftests/clone3: Reorder reporting output > selftests: Remove unneeded selftest API headers > selftests/binderfs: Fix harness API usage > selftests: Add header documentation and helpers > selftests/harness: Switch to TAP output > selftests/harness: Refactor XFAIL into SKIP > selftests/harness: Display signed values correctly > selftests/harness: Report skip reason > > tools/testing/selftests/clone3/clone3.c | 2 +- > .../selftests/clone3/clone3_clear_sighand.c | 3 +- > .../testing/selftests/clone3/clone3_set_tid.c | 2 +- > .../filesystems/binderfs/binderfs_test.c | 284 +- > tools/testing/selftests/kselftest.h | 78 - > tools/testing/selftests/kselftest_harness.h | 169 --- > .../pid_namespace/regression_enomem.c | 1 - > .../selftests/pidfd/pidfd_getfd_test.c| 1 - > .../selftests/pidfd/pidfd_setns_test.c| 1 - > tools/testing/selftests/seccomp/seccomp_bpf.c | 8 +- > .../selftests/uevent/uevent_filtering.c | 1 - > 11 files changed, 356 insertions(+), 194 deletions(-) > > -- > 2.25.1 > -- Kees Cook
Re: [PATCH 2/2] perf tools: Fix record failure when mixed with ARM SPE event
On Fri, Jul 03, 2020 at 12:06:15PM +0800, liwei (GF) wrote: [...] Thanks for Mathieu's looping and agreed with his comments. > > Last but not least do you know where the memory allocated for array > > arm_spe_pmus > > is released? If you can't find it either then we have a memory leak and it > > would be nice to have that fixed. > > Yes, we have a memory leak here indeed, i forgot to free it in this function. > As 'arm_spe_pmus' is defined as static, i think the author meant to assign it > only at the first call, > but this function is only called once when we executing 'record', should i go > on fixing it > or just drop the patch 1? I personally think patch 1 is reasonable. So for fixing memory leak, I did a quick check, it's good to release the array "arm_spe_pmus" in the function auxtrace_record__init(), since the array is only used in this function. Thanks, Leo
Re: [PATCH 1/2] perf tools: ARM SPE code cleanup
Hi Wei,
On Tue, Jun 23, 2020 at 08:31:40PM +0800, Wei Li wrote:
> Remove the useless check code to make it clear.
>
> Signed-off-by: Wei Li
> ---
> tools/perf/arch/arm/util/auxtrace.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/arch/arm/util/auxtrace.c
> b/tools/perf/arch/arm/util/auxtrace.c
> index 0a6e75b8777a..62b7b03d691a 100644
> --- a/tools/perf/arch/arm/util/auxtrace.c
> +++ b/tools/perf/arch/arm/util/auxtrace.c
> @@ -57,7 +57,7 @@ struct auxtrace_record
> struct evsel *evsel;
> bool found_etm = false;
> bool found_spe = false;
> - static struct perf_pmu **arm_spe_pmus = NULL;
> + static struct perf_pmu **arm_spe_pmus;
Here the 'static' should be removed as well.
Just for more complete background info, IIUC, at the beginning to
enable SPE's PMU event, since SPE is micro-architecture dependent
(though it's defined in ARMv8-ARM, but it might be different for
different ARM micro-architectures). So this is why here it uses
'static' for varaible "arm_spe_pmus", it wants to initialize the
variable with finding all SPE PMU structure at the first time when
invoke the function auxtrace_record__init(), and afterwards we can
reuse the variable "arm_spe_pmus" and without calling
find_all_arm_spe_pmus() anymore.
So I struggled to figure out what's good thing to do with multiple SPE
PMU events, and your change is good thing to me. The reason is:
- Firstly, the function auxtrace_record__init() will be invoked only
once, the variable "arm_spe_pmus" will not be used afterwards, thus
we don't need to check "arm_spe_pmus" is NULL or not;
- Another reason is, even though SPE is micro-architecture dependent,
but so far it only supports "statistical-profiling-extension-v1" and
we have no chance to use multiple SPE's PMU events in Perf command.
So after removing 'static' for varaible "arm_spe_pmus":
Reviewed-by: Leo Yan
P.s. Sorry if it's my reason that James Clark's patch [1] has not been
merged in the mainline kernel and introduced duplicate efforts at here.
James's patch used similiar method to resolve this same issue.
[1] https://lkml.org/lkml/2019/12/20/293
> static int nr_spes = 0;
> int i = 0;
>
> @@ -65,9 +65,7 @@ struct auxtrace_record
> return NULL;
>
> cs_etm_pmu = perf_pmu__find(CORESIGHT_ETM_PMU_NAME);
> -
> - if (!arm_spe_pmus)
> - arm_spe_pmus = find_all_arm_spe_pmus(&nr_spes, err);
> + arm_spe_pmus = find_all_arm_spe_pmus(&nr_spes, err);
>
> evlist__for_each_entry(evlist, evsel) {
> if (cs_etm_pmu &&
> --
> 2.17.1
>
Re: ptrace: seccomp: Return value when the call was already invalid
On Sat, Jul 04, 2020 at 01:33:56PM +0100, Will Deacon wrote:
> On Fri, Jul 03, 2020 at 08:52:05AM -0700, Kees Cook wrote:
> > On Fri, Jul 03, 2020 at 04:44:27PM +0100, Will Deacon wrote:
> > > On Fri, Jul 03, 2020 at 08:17:19AM -0700, Kees Cook wrote:
> > > > On Fri, Jul 03, 2020 at 09:39:14AM +0100, Will Deacon wrote:
> > > > > diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
> > > > > index 5f5b868292f5..a13661f44818 100644
> > > > > --- a/arch/arm64/kernel/syscall.c
> > > > > +++ b/arch/arm64/kernel/syscall.c
> > > > > @@ -121,12 +121,10 @@ static void el0_svc_common(struct pt_regs
> > > > > *regs, int scno, int sc_nr,
> > > > > user_exit();
> > > > >
> > > > > if (has_syscall_work(flags)) {
> > > > > - /* set default errno for user-issued syscall(-1) */
> > > > > - if (scno == NO_SYSCALL)
> > > > > - regs->regs[0] = -ENOSYS;
> > > > > - scno = syscall_trace_enter(regs);
> > > > > - if (scno == NO_SYSCALL)
> > > > > + if (syscall_trace_enter(regs))
> > > > > goto trace_exit;
> > > > > +
> > > > > + scno = regs->syscallno;
> > > > > }
> > > > >
> > > > > invoke_syscall(regs, scno, sc_nr, syscall_table);
> > > >
> > > > What effect do either of these patches have on the existing seccomp
> > > > selftests: tools/testing/selftests/seccomp/seccomp_bpf ?
> > >
> > > Tests! Thanks, I'll have a look.
> >
> > Thanks!
> >
> > (And either way, that this behavioral difference went unnoticed means we
> > need to add a test to the selftests for this patch.)
>
> Unsurprisingly, I don't think the tests go near this. I get 75/77 passes
> on arm64 defconfig with or without these changes.
(What doesn't pass for you? I tried to go find kernelci.org test output,
but it doesn't appear to actually run selftests yet?)
Anyway, good that the test output doesn't change, bad that seccomp has
missed a corner of this architecture interface. (i.e. the entire
TRACE_syscall fixture is dedicated to exercising the changing/skipping
interface, but I see now that it doesn't at all exercise any area of
ENOSYS results.)
> We could add a test, but then we'd have to agree on what it's supposed to
> be doing ;)
Well, if you look at change_syscall() in seccomp_bpf.c (once you stop
screaming) you'll likely share my desire to have more things that are
common across architectures. ;) So, to that end, yes, please, let's
define what we'd like to see, and then build out the (likely wildly
different per-architecture expectations). If I read this thread
correctly, we need to test:
syscall(-1), direct, returns ENOSYS
syscall(-10), direct, returns ENOSYS
syscall(-1), SECCOMP_RET_TRACE+PTRACE_CONT, returns ENOSYS
syscall(-10), SECCOMP_RET_TRACE+PTRACE_CONT, returns ENOSYS
syscall(-1), ptrace+PTRACE_SYSCALL, returns ENOSYS
syscall(-10), ptrace+PTRACE_SYSCALL, returns ENOSYS
do we need to double-check that registers before/after are otherwise
unchanged too? (I *think* just looking at syscall return should be
sufficient to catch the visible results.)
--
Kees Cook
Re: [PATCH] CodingStyle: Inclusive Terminology
On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote: > +Non-inclusive terminology has that same distracting effect which is why > +it is a style issue for Linux, it injures developer efficiency. I'm personally thinking that for a non-native speaker it's already difficult to find the best term to describe something, but having to apply an extra level of filtering on the found words to figure whether they are allowed by the language police is even more difficult. *This* injures developers efficiency. What could improve developers efficiency is to take care of removing *all* idiomatic or cultural words then. For example I've been participating to projects using the term "blueprint", I didn't understand what that meant. It was once explained to me and given that it had no logical reason for being called this way, I now forgot. If we follow your reasoning, Such words should be banned for exactly the same reasons. Same for colors that probably don't mean anything to those born blind. For example if in my local culture we eat tomatoes at starters and apples for dessert, it could be convenient for me to use "tomato" and "apple" as list elements to name the pointers leading to the beginning and the end of the list, and it might sound obvious to many people, but not at all for many others. Maybe instead of providing an explicit list of a few words it should simply say that terms that take their roots in the non-technical world and whose meaning can only be understood based on history or local culture ought to be avoided, because *that* actually is the real root cause of the problem you're trying to address. Willy
高卒採用オンライン講座 〜高校訪問の重要性〜
いつもお世話になります。 この度は、高卒採用において効果の高い “高校訪問”についてのセミナーをご案内申し上げます。 〜オンライン開催のためご自宅や職場で視聴可能です〜 21年高卒採用に向けて、求人票の作成が終わり これからの時期に大切なのが“高校訪問”です。 進路指導の先生の手元には、膨大な求人票が届きます。 自社の求人票は、その中から生徒に紹介してもらえているでしょうか。 せっかく作った求人票も、見てもらえなければ意味もありません。 そうならないためにも“高校訪問”が大きな効果を発揮します。 しかしいざ訪問となると、タイミングや準備、 何をどう伝えるか、等々ポイントが多くあります。 そこで本講座では、2000社を超える企業へのアドバイス経験を元に 「15%以上を職場見学に繋げる」高校訪問の仕方をご紹介します。 ■ 詳細・申込 https://hr-saiyo.work/200709/ ■ 求人票が見られているか不安だ、高校訪問をしようにも どう動いたら良いかわからないといった悩みをお持ちの 企業様は、是非ともご参加ください。 オンライン開催 “高校訪問”の重要性と実施のポイント 〜15%を職場見学につなげる方法〜 日程：7月9日 時間：11:00〜11:45 会場：オンライン開催(ご自宅や職場で視聴可能) ■ 詳細・申込 https://hr-saiyo.work/200709/ ■ 本メールのご不要な方には大変ご迷惑をおかけいたしました。 配信停止ご希望の方は、お手数ですが「配信不要」と ご返信いただくか、下記アドレスよりお手続き願います。 https://form9dm.site/kaijo/ ジョブドラフトセミナー運営室(株式会社ジンジブ) 住所：東京都港区浜松町2丁目7-19 KDX浜松町ビル5階 TEL：03-5777-2679 Mail：i...@hr-service.work
Re: [mm] 4e2c82a409: ltp.overcommit_memory01.fail
On Thu, Jul 02, 2020 at 03:12:30PM +0800, Feng Tang wrote:
> > <<>>
> > tag=overcommit_memory01 stime=1593425044
> > cmdline="overcommit_memory"
> > contacts=""
> > analysis=exit
> > <<>>
> > tst_test.c:1247: INFO: Timeout per run is 0h 05m 00s
> > overcommit_memory.c:116: INFO: MemTotal is 16394252 kB
> > overcommit_memory.c:118: INFO: SwapTotal is 268435452 kB
> > overcommit_memory.c:122: INFO: CommitLimit is 276632576 kB
> > mem.c:817: INFO: set overcommit_ratio to 50
> > mem.c:817: INFO: set overcommit_memory to 2
> > overcommit_memory.c:187: INFO: malloc 551061440 kB failed
> > overcommit_memory.c:208: PASS: alloc failed as expected
> > overcommit_memory.c:183: INFO: malloc 276632576 kB successfully
> > overcommit_memory.c:210: FAIL: alloc passed, expected to fail
>
> Thanks for the report!
>
> I took a rough look, and it all happens after changing the
> overcommit policy from a looser one to OVERCOMMIT_NEVER. I suspect
> it is due to the same cause as the previous warning message reported
> by Qian Cai https://lore.kernel.org/lkml/20200526181459.gd...@lca.pw/
>
> Will further check it.
I did reproduce the problem, and from the debugging, this should
be the same root cause as
https://lore.kernel.org/lkml/20200526181459.gd...@lca.pw/
that loosing the batch cause some accuracy problem, and the solution of
adding some sync is still needed, which is dicussed in
First thing I tried a simple patch of using percpucounter_sum_read, and
the problem can't be reproduced:
--- a/mm/util.c
+++ b/mm/util.c
@@ -845,7 +845,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages,
int cap_sys_admin)
allowed -= min_t(long, mm->total_vm / 32, reserve);
}
- if (percpu_counter_read_positive(&vm_committed_as) < allowed)
+ if (percpu_counter_sum(&vm_committed_as) < allowed)
return 0;
error:
vm_unacct_memory(pages);
Then, I tried the sync patch we've discussed one month ago
https://lore.kernel.org/lkml/20200529154315.gi93...@shbuild999.sh.intel.com/
with it, I run the case 200 times and the problem was not reproduced,
can we consider taking this patch?
Thanks,
Feng
diff --git a/include/linux/percpu_counter.h b/include/linux/percpu_counter.h
index 0a4f54d..01861ee 100644
--- a/include/linux/percpu_counter.h
+++ b/include/linux/percpu_counter.h
@@ -44,6 +44,7 @@ void percpu_counter_add_batch(struct percpu_counter *fbc, s64
amount,
s32 batch);
s64 __percpu_counter_sum(struct percpu_counter *fbc);
int __percpu_counter_compare(struct percpu_counter *fbc, s64 rhs, s32 batch);
+void percpu_counter_sync(struct percpu_counter *fbc);
static inline int percpu_counter_compare(struct percpu_counter *fbc, s64 rhs)
{
@@ -172,6 +173,9 @@ static inline bool percpu_counter_initialized(struct
percpu_counter *fbc)
return true;
}
+static inline void percpu_counter_sync(struct percpu_counter *fbc)
+{
+}
#endif /* CONFIG_SMP */
static inline void percpu_counter_inc(struct percpu_counter *fbc)
diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c
index a66595b..d025137 100644
--- a/lib/percpu_counter.c
+++ b/lib/percpu_counter.c
@@ -98,6 +98,20 @@ void percpu_counter_add_batch(struct percpu_counter *fbc,
s64 amount, s32 batch)
}
EXPORT_SYMBOL(percpu_counter_add_batch);
+void percpu_counter_sync(struct percpu_counter *fbc)
+{
+ unsigned long flags;
+ s64 count;
+
+ raw_spin_lock_irqsave(&fbc->lock, flags);
+ count = __this_cpu_read(*fbc->counters);
+ fbc->count += count;
+ __this_cpu_sub(*fbc->counters, count);
+ raw_spin_unlock_irqrestore(&fbc->lock, flags);
+}
+EXPORT_SYMBOL(percpu_counter_sync);
+
+
/*
* Add up all the per-cpu counts, return the result. This is a more accurate
* but much slower version of percpu_counter_read_positive()
diff --git a/mm/util.c b/mm/util.c
index 98813da..8b9664e 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -746,14 +746,23 @@ int overcommit_ratio_handler(struct ctl_table *table, int
write, void *buffer,
return ret;
}
+static void sync_overcommit_as(struct work_struct *dummy)
+{
+ percpu_counter_sync(&vm_committed_as);
+}
+
int overcommit_policy_handler(struct ctl_table *table, int write, void *buffer,
size_t *lenp, loff_t *ppos)
{
int ret;
ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
- if (ret == 0 && write)
+ if (ret == 0 && write) {
+ if (sysctl_overcommit_memory == OVERCOMMIT_NEVER)
+ schedule_on_each_cpu(sync_overcommit_as);
+
mm_compute_batch();
+ }
pr_info("ocommit=%lld, real=%lld policy[%d] ratio=%d\n\n\n",
percpu_counter_read_positive(&vm_committed_as),
drivers/net/ethernet/intel/ice/ice_flex_pipe.c:2826:44: sparse: sparse: non size-preserving pointer to integer cast
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 35e884f89df4c48566d745dc5a97a0d058d04263
commit: 148beb612031255156d68b342170140524afb36e ice: Initialize Flow Director
resources
date: 6 weeks ago
config: i386-randconfig-s001-20200705 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-3-gfa153962-dirty
git checkout 148beb612031255156d68b342170140524afb36e
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/intel/ice/ice_flex_pipe.c:2826:44: sparse: sparse: non
>> size-preserving pointer to integer cast
--
>> drivers/net/ethernet/intel/ice/ice_flow.c:832:20: sparse: sparse: non
>> size-preserving pointer to integer cast
>> drivers/net/ethernet/intel/ice/ice_flow.c:860:17: sparse: sparse: non
>> size-preserving integer to pointer cast
vim +2826 drivers/net/ethernet/intel/ice/ice_flex_pipe.c
2810
2811 /**
2812 * ice_free_flow_profs - free flow profile entries
2813 * @hw: pointer to the hardware structure
2814 * @blk_idx: HW block index
2815 */
2816 static void ice_free_flow_profs(struct ice_hw *hw, u8 blk_idx)
2817 {
2818 struct ice_flow_prof *p, *tmp;
2819
2820 mutex_lock(&hw->fl_profs_locks[blk_idx]);
2821 list_for_each_entry_safe(p, tmp, &hw->fl_profs[blk_idx],
l_entry) {
2822 struct ice_flow_entry *e, *t;
2823
2824 list_for_each_entry_safe(e, t, &p->entries, l_entry)
2825 ice_flow_rem_entry(hw, (enum ice_block)blk_idx,
> 2826 ICE_FLOW_ENTRY_HNDL(e));
2827
2828 list_del(&p->l_entry);
2829 devm_kfree(ice_hw_to_dev(hw), p);
2830 }
2831 mutex_unlock(&hw->fl_profs_locks[blk_idx]);
2832
2833 /* if driver is in reset and tables are being cleared
2834 * re-initialize the flow profile list heads
2835 */
2836 INIT_LIST_HEAD(&hw->fl_profs[blk_idx]);
2837 }
2838
---
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 0/3] readfile(2): a new syscall to make open/read/close faster
On Sun, Jul 5, 2020 at 5:27 AM Matthew Wilcox wrote: > > On Sun, Jul 05, 2020 at 05:18:58AM +0200, Jan Ziak wrote: > > On Sun, Jul 5, 2020 at 5:12 AM Matthew Wilcox wrote: > > > > > > You should probably take a look at io_uring. That has the level of > > > complexity of this proposal and supports open/read/close along with many > > > other opcodes. > > > > Then glibc can implement readfile using io_uring and there is no need > > for a new single-file readfile syscall. > > It could, sure. But there's also a value in having a simple interface > to accomplish a simple task. Your proposed API added a very complex > interface to satisfy needs that clearly aren't part of the problem space > that Greg is looking to address. I believe that we should look at the single-file readfile syscall from a performance viewpoint. If an application is expecting to read a couple of small/medium-size files per second, then neither readfile nor readfiles makes sense in terms of improving performance. The benefits start to show up only in case an application is expecting to read at least a hundred of files per second. The "per second" part is important, it cannot be left out. Because readfile only improves performance for many-file reads, the syscall that applications performing many-file reads actually want is the multi-file version, not the single-file version. I am not sure I understand why you think that a pointer to an array of readfile_t structures is very complex. If it was very complex then it would be a deep tree or a large graph.
[PATCH v2 0/2] shtc1: add support for device tree bindings
Add support for DTS bindings to the shtc driver The patches add the compatible table and of_property_read_bool to the shtc1.c. Newly created Yaml document has been released to the Documentation/devicetree/hwmon/sensirion,shtc1.yaml Signed-off-by: Chris Ruehl --- Version 2 remove the #ifdef CONFIG_OF ignore platform data if dev->of_node is valid use boolean only therefor use sensirion,low_precise to fit the logic add missing driver.of_match_table entry Version 1 initial version
[PATCH v2 1/2] hwmon: shtc1: add support for device tree bindings
Add support for DTS bindings for the sensirion shtc1,shtw1 and shtc3.
Signed-off-by: Chris Ruehl
---
drivers/hwmon/shtc1.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/shtc1.c b/drivers/hwmon/shtc1.c
index a0078ccede03..61e9275eb666 100644
--- a/drivers/hwmon/shtc1.c
+++ b/drivers/hwmon/shtc1.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
/* commands (high precision mode) */
static const unsigned char shtc1_cmd_measure_blocking_hpm[]= { 0x7C, 0xA2
};
@@ -196,6 +197,7 @@ static int shtc1_probe(struct i2c_client *client,
enum shtcx_chips chip = id->driver_data;
struct i2c_adapter *adap = client->adapter;
struct device *dev = &client->dev;
+ struct device_node *np = dev->of_node;
if (!i2c_check_functionality(adap, I2C_FUNC_I2C)) {
dev_err(dev, "plain i2c transactions not supported\n");
@@ -233,8 +235,13 @@ static int shtc1_probe(struct i2c_client *client,
data->client = client;
data->chip = chip;
- if (client->dev.platform_data)
+ if (np) {
+ data->setup.blocking_io = of_property_read_bool(np,
"sensirion,blocking_io");
+ data->setup.high_precision = of_property_read_bool(np,
"sensicon,low_precision");
+ }
+ else if (client->dev.platform_data)
data->setup = *(struct shtc1_platform_data *)dev->platform_data;
+
shtc1_select_command(data);
mutex_init(&data->update_lock);
@@ -257,8 +264,19 @@ static const struct i2c_device_id shtc1_id[] = {
};
MODULE_DEVICE_TABLE(i2c, shtc1_id);
+static const struct of_device_id shtc1_of_match[] = {
+ { .compatible = "sensirion,shtc1" },
+ { .compatible = "sensirion,shtw1" },
+ { .compatible = "sensirion,shtc3" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, shtc1_of_match);
+
static struct i2c_driver shtc1_i2c_driver = {
- .driver.name = "shtc1",
+ .driver = {
+ .name = "shtc1",
+ .of_match_table = shtc1_of_match,
+ },
.probe= shtc1_probe,
.id_table = shtc1_id,
};
--
2.20.1
[PATCH v2 2/2] devicetree: hwmon: shtc1: Add sensirion,shtc1.yaml
Add documentation for the newly added DTS support in the shtc1 driver.
To align with the drivers logic to have high precision by default
a boolean sensirion,low_precision is used to switch to low precision.
Signed-off-by: Chris Ruehl
---
.../bindings/hwmon/sensirion,shtc1.yaml | 53 +++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
new file mode 100644
index ..bcccdcadd86b
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/sensirion,shtc1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sensirion SHTC1 Humidity and Temperature Sensor IC
+
+maintainers:
+ - jdelv...@suse.com
+
+description: |
+ The SHTC1, SHTW1 and SHTC3 are digital humidity and temperature sensor
+ designed especially for battery-driven high-volume consumer electronics
+ applications.
+ For further information refere to Documentation/hwmon/shtc1.rst
+
+ This binding document describes the binding for the hardware monitor
+ portion of the driver.
+
+properties:
+ compatible:
+enum:
+ - sensirion,shtc1
+ - sensirion,shtw1
+ - sensirion,shtc3
+
+ reg: I2C address 0x70
+
+Optional properties:
+ sensirion,blocking_io: |
+bool, if set the i2c bus hold until measure finished
+ sensirion,low_precision: |
+bool, if set aquire data with low precision (not recommend)
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+Example:
+ &i2c1 {
+status = "okay";
+clock-frequency = <40>;
+
+shtc3@70 {
+ compatible = "sensirion,shtc3";
+ reg = <0x70>
+ sensirion,blocking_io;
+ status = "okay";
+};
+ };
--
2.20.1
Re: [PATCH 1/1] iommu/arm-smmu: Implement qcom,skip-init
On Sat 04 Jul 06:09 PDT 2020, Will Deacon wrote:
> [Adding Bjorn, Jordan and John because I really don't want a bunch of
> different ways to tell the driver that the firmware is screwing things up]
>
Thanks Will.
> On Sat, Jul 04, 2020 at 02:28:09PM +0200, Konrad Dybcio wrote:
> > This adds the downstream property required to support
> > SMMUs on SDM630 and other platforms (the need for it
> > most likely depends on firmware configuration).
> >
> > Signed-off-by: Konrad Dybcio
> > ---
> > .../devicetree/bindings/iommu/arm,smmu.yaml | 10 ++
> > drivers/iommu/arm-smmu.c | 15 +--
> > 2 files changed, 19 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> > b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> > index d7ceb4c34423..9abd6d41a32c 100644
> > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> > @@ -102,6 +102,16 @@ properties:
> >access to SMMU configuration registers. In this case non-secure
> > aliases of
> >secure registers have to be used during SMMU configuration.
> >
> > + qcom,skip-init:
> > +description: |
> > + Disable resetting configuration for all context banks
> > + during device reset. This is useful for targets where
> > + some context banks are dedicated to other execution
> > + environments outside of Linux and those other EEs are
> > + programming their own stream match tables, SCTLR, etc.
> > + Without setting this option we will trample on their
> > + configuration.
>
> It would probably be better to know _which_ context banks we shouldn't
> touch, no? Otherwise what happens to the others?
>
>From my investigations of the issue of maintaining the boot display
through the initialization of arm-smmu I assume the reason for skipping
this step don't want to flush out the SMR, S2CR and context bank
initialization because it would disrupt the display hardware's access to
memory.
And in itself I believe that this is quite certainly going to work -
until you start attaching devices. Because in itself this does nothing
to ensure that the driver won't overwrite stream mapping or context bank
configuration as devices are attached.
So on e.g. SDM845 we need to ensure that the driver doesn't stomp over
the display mapping left by the bootloader.
Further more, on platforms such as QCS405 (which are derived from
platforms supported by qcom_iommu today), the stream mapping registers
(SMR and S2CR) are write ignore, which means that without knowledge
about the existing mappings the hardware and driver will be out of sync.
NB. Compared to the platforms that is supported by qcom_iommu, the
stream mapping registers are readable on these newer platforms, while on
e.g. MSM8916 we get an access violation by attempting to read SMR/S2CR.
> > +
> >stream-match-mask:
> > $ref: /schemas/types.yaml#/definitions/uint32
> > description: |
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > index 243bc4cb2705..a5c623d4caf9 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.c
> > @@ -1655,13 +1655,16 @@ static void arm_smmu_device_reset(struct
> > arm_smmu_device *smmu)
> > * Reset stream mapping groups: Initial values mark all SMRn as
> > * invalid and all S2CRn as bypass unless overridden.
> > */
> > - for (i = 0; i < smmu->num_mapping_groups; ++i)
> > - arm_smmu_write_sme(smmu, i);
> >
> > - /* Make sure all context banks are disabled and clear CB_FSR */
> > - for (i = 0; i < smmu->num_context_banks; ++i) {
> > - arm_smmu_write_context_bank(smmu, i);
> > - arm_smmu_cb_write(smmu, i, ARM_SMMU_CB_FSR, ARM_SMMU_FSR_FAULT);
> > + if (!of_find_property(smmu->dev->of_node, "qcom,skip-init", NULL)) {
> > + for (i = 0; i < smmu->num_mapping_groups; ++i)
> > + arm_smmu_write_sme(smmu, i);
> > +
> > + /* Make sure all context banks are disabled and clear CB_FSR */
> > + for (i = 0; i < smmu->num_context_banks; ++i) {
> > + arm_smmu_write_context_bank(smmu, i);
> > + arm_smmu_cb_write(smmu, i, ARM_SMMU_CB_FSR,
> > ARM_SMMU_FSR_FAULT);
> > + }
> > }
>
> Do we not need to worry about the SMRs as well?
>
I don't think we should skip the actual initialization, because to avoid
strange side effects we need to ensure that the driver and hardware are
in sync (either for specific streams/banks or for all of them).
I've continued my work on supporting boot display on e.g. SDM845, based
on Thierry's patches, but still have some unresolved corner cases to
fully resolve - e.g. how to ensure that the display hardware's stream
mapping survives the probe deferral of the display driver. Hopefully I
will be able to post something in a few days.
That said,
Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
On Sun, Jul 05, 2020 at 05:18:58AM +0200, Jan Ziak wrote: > On Sun, Jul 5, 2020 at 5:12 AM Matthew Wilcox wrote: > > > > You should probably take a look at io_uring. That has the level of > > complexity of this proposal and supports open/read/close along with many > > other opcodes. > > Then glibc can implement readfile using io_uring and there is no need > for a new single-file readfile syscall. It could, sure. But there's also a value in having a simple interface to accomplish a simple task. Your proposed API added a very complex interface to satisfy needs that clearly aren't part of the problem space that Greg is looking to address.
Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology
Hi Dave, On Sun, 5 Jul 2020 12:56:23 +1000 Dave Airlie wrote: > > Sorry I misdirected what you said a bit, and I did misinterpret as > Australia also has it's own indigenous slavery issues, (and non-indigenous :-() > I was trying to stop the "white slavery" is a thing crew from turning > up on this. > > Apologies for accidentally implying something what you hadn't said. Sure No worries, mate :-) -- Cheers, Stephen Rothwell pgp9iVXH1cll9.pgp Description: OpenPGP digital signature
Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology
On Sun, 2020-07-05 at 12:56 +1000, Dave Airlie wrote: > On Sun, 5 Jul 2020 at 12:12, Stephen Rothwell > wrote: [...] > > > As for the non-black slavery, others have never pointed this out > > > > (I did not say "non-black") > > > > Sorry I misdirected what you said a bit, and I did misinterpret as > Australia also has it's own indigenous slavery issues, > > I was trying to stop the "white slavery" is a thing crew from turning > up on this. > > Apologies for accidentally implying something what you hadn't said. Not at all, thank you; you just gave a precise illustration of my point: putting statements like this in the kernel acts as a magnet for this type of disagreement ... and not just from honourable people. Developers can honestly disagree about this sort of thing, while supporting the aim of using inclusive language. That's why this file shouldn't be in the kernel tree. James
Re: [mm] 4e2c82a409: ltp.overcommit_memory01.fail
On Thu, Jul 02, 2020 at 03:12:30PM +0800, Feng Tang wrote:
> Hi,
>
> On Thu, Jul 02, 2020 at 02:32:01PM +0800, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: 4e2c82a40911c19419349918e675aa202b113b4d ("[PATCH v5 3/3] mm:
> > adjust vm_committed_as_batch according to vm overcommit policy")
> > url:
> > https://github.com/0day-ci/linux/commits/Feng-Tang/make-vm_committed_as_batch-aware-of-vm-overcommit-policy/20200621-153906
> >
> >
> > in testcase: ltp
> > with following parameters:
> >
> > disk: 1HDD
> > test: mm-01
> >
> > test-description: The LTP testsuite contains a collection of tools for
> > testing the Linux kernel and related features.
> > test-url: http://linux-test-project.github.io/
> >
> >
> > on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m
> > 16G
> >
> > caused below changes (please refer to attached dmesg/kmsg for entire
> > log/backtrace):
> >
> >
> >
> >
> > If you fix the issue, kindly add following tag
> > Reported-by: kernel test robot
> >
> >
> >
> > <<>>
> > tag=overcommit_memory01 stime=1593425044
> > cmdline="overcommit_memory"
> > contacts=""
> > analysis=exit
> > <<>>
> > tst_test.c:1247: INFO: Timeout per run is 0h 05m 00s
> > overcommit_memory.c:116: INFO: MemTotal is 16394252 kB
> > overcommit_memory.c:118: INFO: SwapTotal is 268435452 kB
> > overcommit_memory.c:122: INFO: CommitLimit is 276632576 kB
> > mem.c:817: INFO: set overcommit_ratio to 50
> > mem.c:817: INFO: set overcommit_memory to 2
> > overcommit_memory.c:187: INFO: malloc 551061440 kB failed
> > overcommit_memory.c:208: PASS: alloc failed as expected
> > overcommit_memory.c:183: INFO: malloc 276632576 kB successfully
> > overcommit_memory.c:210: FAIL: alloc passed, expected to fail
>
> Thanks for the report!
>
> I took a rough look, and it all happens after changing the
> overcommit policy from a looser one to OVERCOMMIT_NEVER. I suspect
> it is due to the same cause as the previous warning message reported
> by Qian Cai https://lore.kernel.org/lkml/20200526181459.gd...@lca.pw/
Hmm, the LTP test [1] looks like a faithful implementation of
Documentation/vm/overcommit-accounting.rst which is now failing because
of this patchset.
Also, It was a mistake to merge c571686a92ff ("mm/util.c: remove the
VM_WARN_ONCE for vm_committed_as underflow check") separately (I am
taking a blame to ACK it separately and I forgot to run those tests to
double-check earlier) which is now making me wonder that VM_WARN_ONCE is
actually legitimate to catch the sign of brokenness in the first place.
[1]
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/tunable/overcommit_memory.c
>
> Will further check it.
>
> Thanks,
> Feng
>
> > overcommit_memory.c:183: INFO: malloc 137765294 kB successfully
> > overcommit_memory.c:202: PASS: alloc passed as expected
> > mem.c:817: INFO: set overcommit_memory to 0
> > overcommit_memory.c:183: INFO: malloc 140770308 kB successfully
> > overcommit_memory.c:202: PASS: alloc passed as expected
> > overcommit_memory.c:187: INFO: malloc 569659408 kB failed
> > overcommit_memory.c:208: PASS: alloc failed as expected
> > mem.c:817: INFO: set overcommit_memory to 1
> > overcommit_memory.c:183: INFO: malloc 142414852 kB successfully
> > overcommit_memory.c:202: PASS: alloc passed as expected
> > overcommit_memory.c:183: INFO: malloc 284829704 kB successfully
> > overcommit_memory.c:202: PASS: alloc passed as expected
> > overcommit_memory.c:183: INFO: malloc 569659408 kB successfully
> > overcommit_memory.c:202: PASS: alloc passed as expected
> > mem.c:817: INFO: set overcommit_memory to 0
> > mem.c:817: INFO: set overcommit_ratio to 50
> >
> > Summary:
> > passed 7
> > failed 1
> > skipped 0
> > warnings 0
> > <<>>
> > initiation_status="ok"
> > duration=0 termination_type=exited termination_id=1 corefile=no
> > cutime=0 cstime=1
> > <<>>
> > <<>>
> > tag=overcommit_memory02 stime=1593425044
> > cmdline="overcommit_memory -R 0"
> > contacts=""
> > analysis=exit
> > <<>>
> > tst_test.c:1247: INFO: Timeout per run is 0h 05m 00s
> > overcommit_memory.c:116: INFO: MemTotal is 16394252 kB
> > overcommit_memory.c:118: INFO: SwapTotal is 268435452 kB
> > overcommit_memory.c:122: INFO: CommitLimit is 276632576 kB
> > mem.c:817: INFO: set overcommit_ratio to 0
> > mem.c:817: INFO: set overcommit_memory to 2
> > overcommit_memory.c:187: INFO: malloc 534667184 kB failed
> > overcommit_memory.c:208: PASS: alloc failed as expected
> > overcommit_memory.c:183: INFO: malloc 268435452 kB successfully
> > overcommit_memory.c:210: FAIL: alloc passed, expected to fail
> > overcommit_memory.c:183: INFO: malloc 133666730 kB successfully
> > overcommit_memory.c:202: PASS: alloc passed as expected
> > mem.c:817: INFO: set overcommit_memory to 0
> > overcommit_memory.c:183: INFO: malloc 140770304 kB successfully
> > overcommit_memory.c:202: PASS: alloc passed as expec
Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
On Sun, Jul 5, 2020 at 5:12 AM Matthew Wilcox wrote: > > You should probably take a look at io_uring. That has the level of > complexity of this proposal and supports open/read/close along with many > other opcodes. Then glibc can implement readfile using io_uring and there is no need for a new single-file readfile syscall.
[PATCH] ARM: dts: vf610-zii-ssmb-dtu: Pass "no-sdio"/"no-sd" properties
esdhc0 is connected to an eMMC, so it is safe to pass the "no-sdio"/"no-sd" properties. esdhc1 is wired to a standard SD socket, so pass the "no-sdio" property. Signed-off-by: Chris Healy --- arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts index 0bb3dcff0b79..7d4ddfb6b5b5 100644 --- a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts +++ b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts @@ -81,6 +81,8 @@ non-removable; no-1-8-v; keep-power-in-suspend; +no-sdio; +no-sd; status = "okay"; }; @@ -88,6 +90,7 @@ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_esdhc1>; bus-width = <4>; +no-sdio; status = "okay"; }; -- 2.21.3
drivers/soc/qcom/smd-rpm.c:177:47: sparse: sparse: incorrect type in argument 2 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 35e884f89df4c48566d745dc5a97a0d058d04263
commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to
define address spaces
date: 2 weeks ago
config: ia64-randconfig-s031-20200705 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-3-gfa153962-dirty
git checkout 670d0a4b10704667765f7d18f7592993d02783aa
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=ia64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/soc/qcom/smd-rpm.c:177:47: sparse: sparse: incorrect type in
>> argument 2 (different address spaces) @@ expected void const volatile
>> [noderef] __iomem *src @@ got unsigned char const * @@
>> drivers/soc/qcom/smd-rpm.c:177:47: sparse: expected void const volatile
>> [noderef] __iomem *src
drivers/soc/qcom/smd-rpm.c:177:47: sparse: got unsigned char const *
vim +177 drivers/soc/qcom/smd-rpm.c
936f14cf4e6716 Bjorn Andersson 2015-07-27 146
5052de8deff561 Bjorn Andersson 2017-03-27 147 static int
qcom_smd_rpm_callback(struct rpmsg_device *rpdev,
5052de8deff561 Bjorn Andersson 2017-03-27 148
void *data,
5052de8deff561 Bjorn Andersson 2017-03-27 149
int count,
5052de8deff561 Bjorn Andersson 2017-03-27 150
void *priv,
5052de8deff561 Bjorn Andersson 2017-03-27 151
u32 addr)
936f14cf4e6716 Bjorn Andersson 2015-07-27 152 {
936f14cf4e6716 Bjorn Andersson 2015-07-27 153 const struct
qcom_rpm_header *hdr = data;
30b7ea5eda0afb Stephen Boyd2015-09-02 154 size_t hdr_length =
le32_to_cpu(hdr->length);
936f14cf4e6716 Bjorn Andersson 2015-07-27 155 const struct
qcom_rpm_message *msg;
5052de8deff561 Bjorn Andersson 2017-03-27 156 struct qcom_smd_rpm
*rpm = dev_get_drvdata(&rpdev->dev);
936f14cf4e6716 Bjorn Andersson 2015-07-27 157 const u8 *buf = data +
sizeof(struct qcom_rpm_header);
30b7ea5eda0afb Stephen Boyd2015-09-02 158 const u8 *end = buf +
hdr_length;
936f14cf4e6716 Bjorn Andersson 2015-07-27 159 char msgbuf[32];
936f14cf4e6716 Bjorn Andersson 2015-07-27 160 int status = 0;
30b7ea5eda0afb Stephen Boyd2015-09-02 161 u32 len, msg_length;
936f14cf4e6716 Bjorn Andersson 2015-07-27 162
30b7ea5eda0afb Stephen Boyd2015-09-02 163 if
(le32_to_cpu(hdr->service_type) != RPM_SERVICE_TYPE_REQUEST ||
30b7ea5eda0afb Stephen Boyd2015-09-02 164 hdr_length <
sizeof(struct qcom_rpm_message)) {
b853cb9628bfbc Bjorn Andersson 2016-03-28 165
dev_err(rpm->dev, "invalid request\n");
936f14cf4e6716 Bjorn Andersson 2015-07-27 166 return 0;
936f14cf4e6716 Bjorn Andersson 2015-07-27 167 }
936f14cf4e6716 Bjorn Andersson 2015-07-27 168
936f14cf4e6716 Bjorn Andersson 2015-07-27 169 while (buf < end) {
936f14cf4e6716 Bjorn Andersson 2015-07-27 170 msg = (struct
qcom_rpm_message *)buf;
30b7ea5eda0afb Stephen Boyd2015-09-02 171 msg_length =
le32_to_cpu(msg->length);
30b7ea5eda0afb Stephen Boyd2015-09-02 172 switch
(le32_to_cpu(msg->msg_type)) {
936f14cf4e6716 Bjorn Andersson 2015-07-27 173 case
RPM_MSG_TYPE_MSG_ID:
936f14cf4e6716 Bjorn Andersson 2015-07-27 174 break;
936f14cf4e6716 Bjorn Andersson 2015-07-27 175 case
RPM_MSG_TYPE_ERR:
30b7ea5eda0afb Stephen Boyd2015-09-02 176 len =
min_t(u32, ALIGN(msg_length, 4), sizeof(msgbuf));
936f14cf4e6716 Bjorn Andersson 2015-07-27 @177
memcpy_fromio(msgbuf, msg->message, len);
936f14cf4e6716 Bjorn Andersson 2015-07-27 178
msgbuf[len - 1] = 0;
936f14cf4e6716 Bjorn Andersson 2015-07-27 179
936f14cf4e6716 Bjorn Andersson 2015-07-27 180 if
(!strcmp(msgbuf, "resource does not exist"))
936f14cf4e6716 Bjorn Andersson 2015-07-27 181
status = -ENXIO;
936f14cf4e6716 Bjorn Andersson 2015-07-27 182 else
936f14cf4e6716 Bjorn Andersson 2015-07-27 183
status = -EINVAL;
936f14cf4e6716 Bjorn Andersson 2015-07-27 184 break;
936f14cf4e6716 Bjorn Andersson 2015-07-27 185 }
936f14cf4e6716 Bjorn Andersson 2015-0
Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
On Sun, Jul 05, 2020 at 04:46:04AM +0200, Jan Ziak wrote:
> On Sun, Jul 5, 2020 at 4:16 AM Matthew Wilcox wrote:
> >
> > On Sun, Jul 05, 2020 at 04:06:22AM +0200, Jan Ziak wrote:
> > > Hello
> > >
> > > At first, I thought that the proposed system call is capable of
> > > reading *multiple* small files using a single system call - which
> > > would help increase HDD/SSD queue utilization and increase IOPS (I/O
> > > operations per second) - but that isn't the case and the proposed
> > > system call can read just a single file.
> > >
> > > Without the ability to read multiple small files using a single system
> > > call, it is impossible to increase IOPS (unless an application is
> > > using multiple reader threads or somehow instructs the kernel to
> > > prefetch multiple files into memory).
> >
> > What API would you use for this?
> >
> > ssize_t readfiles(int dfd, char **files, void **bufs, size_t *lens);
> >
> > I pretty much hate this interface, so I hope you have something better
> > in mind.
>
> I am proposing the following:
>
> struct readfile_t {
> int dirfd;
> const char *pathname;
> void *buf;
> size_t count;
> int flags;
> ssize_t retval; // set by kernel
> int reserved; // not used by kernel
> };
>
> int readfiles(struct readfile_t *requests, size_t count);
>
> Returns zero if all requests succeeded, otherwise the returned value
> is non-zero (glibc wrapper: -1) and user-space is expected to check
> which requests have succeeded and which have failed. retval in
> readfile_t is set to what the single-file readfile syscall would
> return if it was called with the contents of the corresponding
> readfile_t struct.
You should probably take a look at io_uring. That has the level of
complexity of this proposal and supports open/read/close along with many
other opcodes.
Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology
On Sun, 5 Jul 2020 at 12:12, Stephen Rothwell wrote: > > Hi Dave, > > On Sun, 5 Jul 2020 09:34:57 +1000 Dave Airlie wrote: > > > > On Sun, 5 Jul 2020 at 06:45, Stephen Rothwell wrote: > > > > > > On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams > > > wrote: > > > > > > > > +The Linux kernel is a global software project, and in 2020 there was a > > > > +global reckoning on race relations that caused many organizations to > > > > +re-evaluate their policies and practices relative to the inclusion of > > > > +people of African descent. This document describes why the 'Naming' > > > > > > I feel a need to point out that racial issues are wider than just > > > people of African descent ... Also, others have pointed out that > > > slavery is not just restricted to those of African descent. > > > > The racial issues are wider than that, and even wider again I'm sure, > > but in 2020 this is as good a place to start as any, and the trigger > > as that sentence says was in 2020, there was a reckoning about it > > mainly due to people of African descent. That trigger has had flow on > > effects in other countries, but I'm not sure that sentence in any way > > diminishes that, it's merely an introduction to why this change is > > happening now. > > And reading it again in the (actual) light of day, I see you are right > and I misinterpreted this. > > > As for the non-black slavery, others have never pointed this out > > (I did not say "non-black") > Sorry I misdirected what you said a bit, and I did misinterpret as Australia also has it's own indigenous slavery issues, I was trying to stop the "white slavery" is a thing crew from turning up on this. Apologies for accidentally implying something what you hadn't said. Dave.
Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology
On Sun, 5 Jul 2020 at 10:10, Matthew Wilcox wrote: > > Erm, red-black trees don't have a derivation from gambling terminology > either. The wikipedia article says: > > In a 1978 paper, "A Dichromatic Framework for Balanced Trees",[6] Leonidas J. > Guibas and Robert Sedgewick derived the red-black tree from the symmetric > binary B-tree.[7] The color "red" was chosen because it was the best-looking > color produced by the color laser printer available to the authors while > working at Xerox PARC.[8] Another response from Guibas states that it was > because of the red and black pens available to them to draw the trees.[9] > > Left-right tree makes no sense. It doesn't distinguish the rbtree from its > predecessor the avl tree. I don't think it's helpful to rename a standard > piece of computing terminology unless it's actually hurting us to have it. > Obviously if it were called a "master-slave" tree, I would be in favour of > renaming it. As I said "it means nothing if you've never interacted with gambling culture," red black in the context of the trees as zero meaning other than as a name to find it on the internet, Search for that name enough and you will undoubtedly be getting ads for online roulette sites within hours, if you have a problem gambling past, this might not be the desired effect you'd want. The reasons something was named a particular thing can and will be different from what a societal context for them means now, and I believe it's more important to worry about current societal contexts than legacy historical namings. I'm not seriously suggesting we rename red-black trees, but if someone who had a problematic gambling background had issues with them I'd definitely be open for considering it. Dave.
Re: [PATCH] readfile.2: new page describing readfile(2)
On 7/4/20 4:02 PM, Greg Kroah-Hartman wrote: > readfile(2) is a new syscall to remove the need to do the > open/read/close dance for small virtual files in places like procfs or > sysfs. > > Signed-off-by: Greg Kroah-Hartman > --- > > This patch is for the man-pages project, not the kernel source tree > > man2/readfile.2 | 159 > 1 file changed, 159 insertions(+) > create mode 100644 man2/readfile.2 > > diff --git a/man2/readfile.2 b/man2/readfile.2 > new file mode 100644 > index ..449e722c3442 > --- /dev/null > +++ b/man2/readfile.2 > @@ -0,0 +1,159 @@ > +.\" This manpage is Copyright (C) 2020 Greg Kroah-Hartman; > +.\" and Copyright (C) 2020 The Linux Foundation > +.\" > +.\" %%%LICENSE_START(VERBATIM) > +.\" Permission is granted to make and distribute verbatim copies of this > +.\" manual provided the copyright notice and this permission notice are > +.\" preserved on all copies. > +.\" > +.\" Permission is granted to copy and distribute modified versions of this > +.\" manual under the conditions for verbatim copying, provided that the > +.\" entire resulting derived work is distributed under the terms of a > +.\" permission notice identical to this one. > +.\" > +.\" Since the Linux kernel and libraries are constantly changing, this > +.\" manual page may be incorrect or out-of-date. The author(s) assume no > +.\" responsibility for errors or omissions, or for damages resulting from > +.\" the use of the information contained herein. The author(s) may not > +.\" have taken the same level of care in the production of this manual, > +.\" which is licensed free of charge, as they might when working > +.\" professionally. > +.\" > +.\" Formatted or processed versions of this manual, if unaccompanied by > +.\" the source, must acknowledge the copyright and authors of this work. > +.\" %%%LICENSE_END > +.\" > +.TH READFILE 2 2020-07-04 "Linux" "Linux Programmer's Manual" > +.SH NAME > +readfile \- read a file into a buffer > +.SH SYNOPSIS > +.nf > +.B #include > +.PP > +.BI "ssize_t readfile(int " dirfd ", const char *" pathname ", void *" buf \ > +", size_t " count ", int " flags ); > +.fi > +.SH DESCRIPTION > +.BR readfile () > +attempts to open the file specified by > +.IR pathname > +and to read up to > +.I count > +bytes from the file into the buffer starting at > +.IR buf . > +It is to be a shortcut of doing the sequence of Just my personal preference for concise language: It replaces the sequence of > +.BR open () > +and then %s/and then /, / > +.BR read () > +and then %s/and then/, and/ > +.BR close () > +for small files that are read frequently, such as those in ". It reduces system call overheads especially for small files, like those in" readfile() makes sense even if each individual file is only read once, not frequently. Below you describe that file up to 2GiB can be read. So readfile() seems to be a shortcut for larger files too. > +.B procfs > +or > +.BR sysfs . Executing readfile() generates the same file notification events as said individual calls (cf. fanotify.7, inotify.7). > +.PP > +If the size of file is smaller than the value provided in > +.I count > +then the whole file will be copied into > +.IR buf . > +.PP > +If the file is larger than the value provided in > +.I count > +then only > +.I count > +number of bytes will be copied into > +.IR buf . > +.PP > +The argument > +.I flags > +may contain one of the following > +.IR "access modes" : > +.BR O_NOFOLLOW ", or " O_NOATIME . > +.PP > +If the pathname given in > +.I pathname > +is relative, then it is interpreted relative to the directory > +referred to by the file descriptor > +.IR dirfd . > +.PP > +If > +.I pathname > +is relative and > +.I dirfd > +is the special value > +.BR AT_FDCWD , > +then > +.I pathname > +is interpreted relative to the current working > +directory of the calling process (like > +.BR openat ()). > +.PP > +If > +.I pathname > +is absolute, then > +.I dirfd > +is ignored. readfile() blocks until either the whole file has been read, the buffer is completely filled, or the system specific limit (see below) has been reached. > +.SH RETURN VALUE > +On success, the number of bytes read is returned. > +It is not an error if this number is smaller than the number of bytes > +requested; this can happen if the file is smaller than the number of > +bytes requested. "It is not an error ..." is very vague. Are there any other cases where a file is only partially read and the number of bytes returned is less then the minimum of buffer size and file size? How would I discover truncation? Or can I rely on the call returning either an error or said minimum number of bytes? In the latter case: "When reading from a block device this always equals the minimum of the buffer size specified by 'count', the file size, and the system specific limit for read.2 calls (see below)." > +.PP > +On error, \-1 is returned, and > +.I errno > +is set app
[PATCH] HID: logitech: Use HIDPP_RECEIVER_INDEX instead of 0xff
Some parts of hid-logitech-dj explicitly referred to 0xff for the
receiver index. This patch changes those references to the
HIDPP_RECEIVER_INDEX definition.
Signed-off-by: Mazin Rezk
---
drivers/hid/hid-logitech-dj.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 48dff5d6b605..a78c13cc9f47 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -1153,7 +1153,7 @@ static int logi_dj_recv_query_paired_devices(struct
dj_receiver_dev *djrcv_dev)
if (!dj_report)
return -ENOMEM;
dj_report->report_id = REPORT_ID_DJ_SHORT;
- dj_report->device_index = 0xFF;
+ dj_report->device_index = HIDPP_RECEIVER_INDEX;
dj_report->report_type = REPORT_TYPE_CMD_GET_PAIRED_DEVICES;
retval = logi_dj_recv_send_report(djrcv_dev, dj_report);
kfree(dj_report);
@@ -1175,7 +1175,7 @@ static int logi_dj_recv_switch_to_dj_mode(struct
dj_receiver_dev *djrcv_dev,
if (djrcv_dev->type == recvr_type_dj) {
dj_report->report_id = REPORT_ID_DJ_SHORT;
- dj_report->device_index = 0xFF;
+ dj_report->device_index = HIDPP_RECEIVER_INDEX;
dj_report->report_type = REPORT_TYPE_CMD_SWITCH;
dj_report->report_params[CMD_SWITCH_PARAM_DEVBITFIELD] = 0x3F;
dj_report->report_params[CMD_SWITCH_PARAM_TIMEOUT_SECONDS] =
@@ -1204,7 +1204,7 @@ static int logi_dj_recv_switch_to_dj_mode(struct
dj_receiver_dev *djrcv_dev,
memset(buf, 0, HIDPP_REPORT_SHORT_LENGTH);
buf[0] = REPORT_ID_HIDPP_SHORT;
- buf[1] = 0xFF;
+ buf[1] = HIDPP_RECEIVER_INDEX;
buf[2] = 0x80;
buf[3] = 0x00;
buf[4] = 0x00;
--
2.27.0
Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
On Sun, Jul 5, 2020 at 4:16 AM Matthew Wilcox wrote:
>
> On Sun, Jul 05, 2020 at 04:06:22AM +0200, Jan Ziak wrote:
> > Hello
> >
> > At first, I thought that the proposed system call is capable of
> > reading *multiple* small files using a single system call - which
> > would help increase HDD/SSD queue utilization and increase IOPS (I/O
> > operations per second) - but that isn't the case and the proposed
> > system call can read just a single file.
> >
> > Without the ability to read multiple small files using a single system
> > call, it is impossible to increase IOPS (unless an application is
> > using multiple reader threads or somehow instructs the kernel to
> > prefetch multiple files into memory).
>
> What API would you use for this?
>
> ssize_t readfiles(int dfd, char **files, void **bufs, size_t *lens);
>
> I pretty much hate this interface, so I hope you have something better
> in mind.
I am proposing the following:
struct readfile_t {
int dirfd;
const char *pathname;
void *buf;
size_t count;
int flags;
ssize_t retval; // set by kernel
int reserved; // not used by kernel
};
int readfiles(struct readfile_t *requests, size_t count);
Returns zero if all requests succeeded, otherwise the returned value
is non-zero (glibc wrapper: -1) and user-space is expected to check
which requests have succeeded and which have failed. retval in
readfile_t is set to what the single-file readfile syscall would
return if it was called with the contents of the corresponding
readfile_t struct.
The glibc library wrapper of this system call is expected to store the
errno in the "reserved" field. Thus, a programmer using glibc sees:
struct readfile_t {
int dirfd;
const char *pathname;
void *buf;
size_t count;
int flags;
ssize_t retval; // set by glibc (-1 on error)
int errno; // set by glibc if retval is -1
};
retval and errno in glibc's readfile_t are set to what the single-file
glibc readfile would return (retval) and set (errno) if it was called
with the contents of the corresponding readfile_t struct. In case of
an error, glibc will pick one readfile_t which failed (such as: the
1st failed one) and use it to set glibc's errno.
Re: [Tech-board-discuss] [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology
On 7/4/20 6:10 PM, Kees Cook wrote: > On Sat, Jul 04, 2020 at 08:10:33PM -0400, Matthew Wilcox wrote: >> Left-right tree makes no sense. It doesn't distinguish the rbtree from its >> predecessor the avl tree. I don't think it's helpful to rename a standard >> piece of computing terminology unless it's actually hurting us to have it. >> Obviously if it were called a "master-slave" tree, I would be in favour of >> renaming it. > > (No one has suggested renaming red/black trees, so I think the > slippery-slope argument can be set aside here.) Did you read this message? https://lore.kernel.org/ksummit-discuss/CAPM=9ty0til_qm_ufv0s0vtarkz_f-anngc+amdm5ljgaha...@mail.gmail.com/ > As for the actual proposal on white/black-list, I've always been annoyed > by the poor description it provides (and I get to see it A LOT being > the seccomp maintainer). I welcome allow/deny-list (though the change is > not new for seccomp -- the man pages were updated last year (thanks > mkerrisk). :) > -- ~Randy
Re: [PATCH] kbuild: Allow Clang global merging if !MODULES
Hi Danny, On Thu, Jul 02, 2020 at 04:39:29PM -0700, Danny Lin wrote: > The old reasoning for disabling Clang's global merging optimization is > that it breaks modpost by coalescing many symbols into _MergedGlobals. > However, modpost is only used in builds with dynamic modules; > vmlinux.symvers is still created during standalone builds, but it's > effectively just an empty dummy file. > > Enabling the optimization whenever possible allows us to reap the > benefits of reduced register pressure when many global variables are > used in the same function. Have you run into any place within the kernel that this is the case or this more of a "could help if this ever happens" type of deal? > An x86 defconfig kernel built with this optimization boots fine in qemu, > and a downstream 4.14 kernel has been used on arm64 for nearly a year > without any issues caused by this optimization. If I am reading LLVM's source correctly, this option only seems relevant for ARM and AArch64? $ rg --no-heading createGlobalMergePass llvm/lib/CodeGen/GlobalMerge.cpp:679:Pass *llvm::createGlobalMergePass(const TargetMachine *TM, unsigned Offset, llvm/lib/Target/AArch64/AArch64TargetMachine.cpp:524: addPass(createGlobalMergePass(TM, 4095, OnlyOptimizeForSize, llvm/lib/Target/ARM/ARMTargetMachine.cpp:456: addPass(createGlobalMergePass(TM, 127, OnlyOptimizeForSize, llvm/include/llvm/CodeGen/Passes.h:419: Pass *createGlobalMergePass(const TargetMachine *TM, unsigned MaximalOffset, Otherwise, I think this is probably okay. According to [1], when the optimization level is less than -O3, we get a less aggressive version of this optimization level, which is good for code size: https://github.com/llvm/llvm-project/commit/8207641251706ea808df6d2a1ea8f87b8ee04c6d However, we do potentially get merging of extern globals if we do not specify -mglobal-merge (if I am reading the source correctly), which this commit claims might hurt performance? Not sure if there is any way to test or verify that? https://github.com/llvm/llvm-project/commit/de73404b8c4332190750537eb93ce0d5b6451300 > Signed-off-by: Danny Lin > --- > Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Makefile b/Makefile > index a60c98519c37..f04c3639cf61 100644 > --- a/Makefile > +++ b/Makefile > @@ -772,10 +772,13 @@ ifdef CONFIG_CC_IS_CLANG > KBUILD_CPPFLAGS += -Qunused-arguments > KBUILD_CFLAGS += -Wno-format-invalid-specifier > KBUILD_CFLAGS += -Wno-gnu > + > +ifdef CONFIG_MODULES > # CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as > the > # source of a reference will be _MergedGlobals and not on of the whitelisted > names. > # See modpost pattern 2 > KBUILD_CFLAGS += -mno-global-merge > +endif > else > > # These warnings generated too much noise in a regular build. > -- > 2.27.0 > Cheers, Nathan
Re: [PATCH 2/2] devicetree: hwmon: shtc1: Add sensirion,shtc1.yaml
On 7/4/20 5:30 PM, Chris Ruehl wrote: > Hi Guenter, > > On 3/7/2020 1:49 pm, Guenter Roeck wrote: >> On 7/2/20 8:48 PM, Chris Ruehl wrote: >>> Add documentation for the newly added DTS support in the shtc1 driver. >>> >>> Signed-off-by: Chris Ruehl >>> --- >>> .../bindings/hwmon/sensirion,shtc1.yaml | 53 +++ >>> 1 file changed, 53 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml >>> b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml >>> new file mode 100644 >>> index ..e3e292bc6d7d >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml >>> @@ -0,0 +1,53 @@ >>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/hwmon/sensirion,shtc1.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Sensirion SHTC1 Humidity and Temperature Sensor IC >>> + >>> +maintainers: >>> + - jdelv...@suse.com >>> + >>> +description: | >>> + The SHTC1, SHTW1 and SHTC3 are digital humidity and temperature sensor >>> + designed especially for battery-driven high-volume consumer electronics >>> + applications. >>> + For further information refere to Documentation/hwmon/shtc1.rst >>> + >>> + This binding document describes the binding for the hardware monitor >>> + portion of the driver. >>> + >>> +properties: >>> + compatible: >>> + enum: >>> + - sensirion,shtc1 >>> + - sensirion,shtw1 >>> + - sensirion,shtc3 >>> + >>> + reg: I2C address 0x70 >>> + >>> +Optional properties: >>> + sensirion,blocking_io: | >>> + u8, if > 0 the i2c bus hold until measure finished (default 0) >>> + sensirion,high_precision: | >>> + u8, if > 0 aquire data with high precision (default 1) >>> + >> Why u8 and not boolean ? >> >> Guenter > The author of the driver make high_precision default (recommend) in the code, > if I use boolean, then the device tree _must_ have have the > sensirion,high_precision set > or I need to do the opposite and define sensirion,low_precision. > (blocking_io = false default, high_precision = true default) > > that's the reason I was thinking use a u8 and test with of_property_read_bool > to check > the presence of it and set it if value > 0. > Devicetree properties are supposed to be independent from actual implementations. Declaring "we must do so because of an existing implementation" would set a really bad precedence - everyone could use that later on to push through arbitrary sets of devicetree properties. On top of that, this is supposed to be a new set of bindings, with no one using it today. Any argument along the line of "must have" seems irrelevant, since there is no real concern about devicetree backwards compatibility. And on top of all that, I find the currently suggested code really awkward and convoluted. With that in mind, I personally would neither accept your argument nor your code. If you object to defining sensirion,high_precision as boolean, and at the same time object to defining sensirion,low_precision as well, I'd say, fine, then let's stick with what we have today. Anyway, I'll follow Rob's guidance. Guenter
drivers/mtd/nand/raw/xway_nand.c:227:30: error: 'mtd' undeclared
Hi Miquel,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 35e884f89df4c48566d745dc5a97a0d058d04263
commit: 9fdd78f7bcda3e6a9f53c355529b3bf037c0e24f mtd: rawnand: xway: Stop using
nand_release()
date: 5 weeks ago
config: mips-xway_defconfig (attached as .config)
compiler: mips-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
git checkout 9fdd78f7bcda3e6a9f53c355529b3bf037c0e24f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/mtd/nand/raw/xway_nand.c: In function 'xway_nand_remove':
>> drivers/mtd/nand/raw/xway_nand.c:227:30: error: 'mtd' undeclared (first use
>> in this function)
227 | ret = mtd_device_unregister(mtd);
| ^~~
drivers/mtd/nand/raw/xway_nand.c:227:30: note: each undeclared identifier is
reported only once for each function it appears in
vim +/mtd +227 drivers/mtd/nand/raw/xway_nand.c
217
218 /*
219 * Remove a NAND device.
220 */
221 static int xway_nand_remove(struct platform_device *pdev)
222 {
223 struct xway_nand_data *data = platform_get_drvdata(pdev);
224 struct nand_chip *chip = &data->chip;
225 int ret;
226
> 227 ret = mtd_device_unregister(mtd);
228 WARN_ON(ret);
229 nand_cleanup(chip);
230
231 return 0;
232 }
233
---
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 0/3] readfile(2): a new syscall to make open/read/close faster
On Sun, Jul 05, 2020 at 04:06:22AM +0200, Jan Ziak wrote: > Hello > > At first, I thought that the proposed system call is capable of > reading *multiple* small files using a single system call - which > would help increase HDD/SSD queue utilization and increase IOPS (I/O > operations per second) - but that isn't the case and the proposed > system call can read just a single file. > > Without the ability to read multiple small files using a single system > call, it is impossible to increase IOPS (unless an application is > using multiple reader threads or somehow instructs the kernel to > prefetch multiple files into memory). What API would you use for this? ssize_t readfiles(int dfd, char **files, void **bufs, size_t *lens); I pretty much hate this interface, so I hope you have something better in mind.
Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology
Hi Dave, On Sun, 5 Jul 2020 09:34:57 +1000 Dave Airlie wrote: > > On Sun, 5 Jul 2020 at 06:45, Stephen Rothwell wrote: > > > > On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams > > wrote: > > > > > > +The Linux kernel is a global software project, and in 2020 there was a > > > +global reckoning on race relations that caused many organizations to > > > +re-evaluate their policies and practices relative to the inclusion of > > > +people of African descent. This document describes why the 'Naming' > > > > I feel a need to point out that racial issues are wider than just > > people of African descent ... Also, others have pointed out that > > slavery is not just restricted to those of African descent. > > The racial issues are wider than that, and even wider again I'm sure, > but in 2020 this is as good a place to start as any, and the trigger > as that sentence says was in 2020, there was a reckoning about it > mainly due to people of African descent. That trigger has had flow on > effects in other countries, but I'm not sure that sentence in any way > diminishes that, it's merely an introduction to why this change is > happening now. And reading it again in the (actual) light of day, I see you are right and I misinterpreted this. > As for the non-black slavery, others have never pointed this out (I did not say "non-black") > before in 30 years of master/slave terminology? surely if white > slavery was as big a problem, they be as supportive of this, even more (nor did I say "white slavery") > so. It speaks volumes that I've never heard white slavery as a problem > once in 30 years, but now I'm hearing about it a few times, and > somehow as an excuse not to support this. I was merely referring to some of the posts in the us...@linux.kernel.org mailing list. Also, I made no statement about my support (or otherwise) for any of this. -- Cheers, Stephen Rothwell pgpq0Xsz_EX5d.pgp Description: OpenPGP digital signature
Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
Hello At first, I thought that the proposed system call is capable of reading *multiple* small files using a single system call - which would help increase HDD/SSD queue utilization and increase IOPS (I/O operations per second) - but that isn't the case and the proposed system call can read just a single file. Without the ability to read multiple small files using a single system call, it is impossible to increase IOPS (unless an application is using multiple reader threads or somehow instructs the kernel to prefetch multiple files into memory). While you are at it, why not also add a readfiles system call to read multiple, presumably small, files? The initial unoptimized implementation of readfiles syscall can simply call readfile sequentially. Sincerely Jan (atomsymbol)
Re: [PATCH 4.19 114/131] ocfs2: avoid inode removal while nfsd is accessing it
On 7/2/20 3:24 PM, Linus Torvalds wrote:
On Thu, Jul 2, 2020 at 2:17 PM Pavel Machek wrote:
commit 4cd9973f9ff69e37dd0ba2bd6e6423f8179c329a upstream.
Patch series "ocfs2: fix nfsd over ocfs2 issues", v2.
This causes locking imbalance:
This sems to be true upstream too.
When ocfs2_nfs_sync_lock() returns error, caller can not know if the
lock was taken or not.
Right you are.
And your patch looks sane:
diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index c141b06811a6..8149fb6f1f0d 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -2867,9 +2867,15 @@ int ocfs2_nfs_sync_lock(struct ocfs2_super *osb, int ex)
status = ocfs2_cluster_lock(osb, lockres, ex ? LKM_EXMODE : LKM_PRMODE,
0, 0);
- if (status < 0)
+ if (status < 0) {
mlog(ML_ERROR, "lock on nfs sync lock failed %d\n", status);
+ if (ex)
+ up_write(&osb->nfs_sync_rwlock);
+ else
+ up_read(&osb->nfs_sync_rwlock);
+ }
+
return status;
}
although the whole thing looks messy.
If the issue is a lifetime thing (like that commit says), the proper
model isn't a lock, but a refcount.
Oh well. Junxiao?
There is a block number embedded in nfs file handle, to verify it's an
inode, need acquire this nfs_sync_lock global lock to avoid any inode
removed from local node and other nodes in the cluster, before this
verify done, seemed no way to use a refcount.
Thanks,
Junxiao.
Linus
Re: Are there some potentially serious problems that I should be aware of if I totally disable the CONFIG_ACPI option on the X86_64 platform?
I see. Thank you . Pavel Machek 于2020年7月5日周日 上午4:09写道： > > On Sat 2020-07-04 21:34:36, 孙世龙 sunshilong wrote: > > Thank you for taking the time to respond to me. > > > > >These machines are still mostly IBM-PC compatible, so it is likely to > > >somehow work. You'll likely get worse power and thermal > > >management. Try it. > > It's an industrial personal computer with an Intel processor. > > What I am worried about is that it may damage the hardware. > > I'd simply try it. Risk is really quite low... > > If in doubt, you could ask vendor. > > But you will not get definitive answers on the mailing list... > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH 3/3] selftests: add readfile(2) selftests
On 7/4/20 4:02 PM, Greg Kroah-Hartman wrote:
> Test the functionality of readfile(2) in various ways.
Hello Greg,
I expect readfile() to generate fanotify events FAN_OPEN_PERM, FAN_OPEN,
FAN_ACCESS_PERM, FAN_ACCESS, FAN_CLOSE_NOWRITE in this sequence.
Looking at patch 1/3 you took care of notifications. Would this deserve
testing here?
Best regards
Heinrich
>
> Also provide a simple speed test program to benchmark using readfile()
> instead of using open()/read()/close().
>
> Signed-off-by: Greg Kroah-Hartman
> ---
> tools/testing/selftests/Makefile | 1 +
> tools/testing/selftests/readfile/.gitignore | 3 +
> tools/testing/selftests/readfile/Makefile | 7 +
> tools/testing/selftests/readfile/readfile.c | 285 +
> .../selftests/readfile/readfile_speed.c | 301 ++
> 5 files changed, 597 insertions(+)
> create mode 100644 tools/testing/selftests/readfile/.gitignore
> create mode 100644 tools/testing/selftests/readfile/Makefile
> create mode 100644 tools/testing/selftests/readfile/readfile.c
> create mode 100644 tools/testing/selftests/readfile/readfile_speed.c
>
> diff --git a/tools/testing/selftests/Makefile
> b/tools/testing/selftests/Makefile
> index 1195bd85af38..82359233b945 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -46,6 +46,7 @@ TARGETS += ptrace
> TARGETS += openat2
> TARGETS += rseq
> TARGETS += rtc
> +TARGETS += readfile
> TARGETS += seccomp
> TARGETS += sigaltstack
> TARGETS += size
> diff --git a/tools/testing/selftests/readfile/.gitignore
> b/tools/testing/selftests/readfile/.gitignore
> new file mode 100644
> index ..f0e758d437e4
> --- /dev/null
> +++ b/tools/testing/selftests/readfile/.gitignore
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +readfile
> +readfile_speed
> diff --git a/tools/testing/selftests/readfile/Makefile
> b/tools/testing/selftests/readfile/Makefile
> new file mode 100644
> index ..1bf1bdec40f8
> --- /dev/null
> +++ b/tools/testing/selftests/readfile/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +CFLAGS += -g -I../../../../usr/include/
> +CFLAGS += -O2 -Wl,-no-as-needed -Wall
> +
> +TEST_GEN_PROGS := readfile readfile_speed
> +
> +include ../lib.mk
> diff --git a/tools/testing/selftests/readfile/readfile.c
> b/tools/testing/selftests/readfile/readfile.c
> new file mode 100644
> index ..f0736c6dfa69
> --- /dev/null
> +++ b/tools/testing/selftests/readfile/readfile.c
> @@ -0,0 +1,285 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Greg Kroah-Hartman
> + * Copyright (c) 2020 The Linux Foundation
> + *
> + * Test the readfile() syscall in various ways.
> + */
> +#define _GNU_SOURCE
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "../kselftest.h"
> +
> +//#ifndef __NR_readfile
> +//#define __NR_readfile -1
> +//#endif
> +
> +#define __NR_readfile440
> +
> +#define TEST_FILE1 "/sys/devices/system/cpu/vulnerabilities/meltdown"
> +#define TEST_FILE2 "/sys/devices/system/cpu/vulnerabilities/spectre_v1"
> +#define TEST_FILE4 "/sys/kernel/debug/usb/devices"
> +
> +static int sys_readfile(int fd, const char *filename, unsigned char *buffer,
> + size_t bufsize, int flags)
> +{
> + return syscall(__NR_readfile, fd, filename, buffer, bufsize, flags);
> +}
> +
> +/*
> + * Test that readfile() is even in the running kernel or not.
> + */
> +static void test_readfile_supported(void)
> +{
> + const char *proc_map = "/proc/self/maps";
> + unsigned char buffer[10];
> + int retval;
> +
> + if (__NR_readfile < 0)
> + ksft_exit_skip("readfile() syscall is not defined for the
> kernel this test was built against\n");
> +
> + /*
> + * Do a simple test to see if the syscall really is present in the
> + * running kernel
> + */
> + retval = sys_readfile(0, proc_map, &buffer[0], sizeof(buffer), 0);
> + if (retval == -1)
> + ksft_exit_skip("readfile() syscall not present on running
> kernel\n");
> +
> + ksft_test_result_pass("readfile() syscall present\n");
> +}
> +
> +/*
> + * Open all files in a specific sysfs directory and read from them
> + *
> + * This tests the "openat" type functionality of opening all files relative
> to a
> + * directory. We don't care at the moment about the contents.
> + */
> +static void test_sysfs_files(void)
> +{
> + static unsigned char buffer[8000];
> + const char *sysfs_dir = "/sys/devices/system/cpu/vulnerabilities/";
> + struct dirent *dirent;
> + DIR *vuln_sysfs_dir;
> + int sysfs_fd;
> + int retval;
> +
> + sysfs_fd = open(sysfs_dir, O_PATH | O_DIRECTORY);
> + if (sysfs_fd == -1) {
> + ksft_test_result_skip("unable to open %s directory\n",
> + sysfs_dir);
> +
[PATCH] ARM: dts: vfxxx: Add node for CAAM
Add node for CAAM device in NXP Vybrid SoC.
Signed-off-by: Andrey Smirnov
Signed-off-by: Chris Healy
---
arch/arm/boot/dts/vfxxx.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 2d547e7b21ad..0fe03aa0367f 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -729,6 +729,28 @@
dma-names = "rx","tx";
status = "disabled";
};
+
+crypto: crypto@400f {
+compatible = "fsl,sec-v4.0";
+#address-cells = <1>;
+#size-cells = <1>;
+reg = <0x400f 0x9000>;
+ranges = <0 0x400f 0x9000>;
+clocks = <&clks VF610_CLK_CAAM>;
+clock-names = "ipg";
+
+sec_jr0: jr0@1000 {
+compatible = "fsl,sec-v4.0-job-ring";
+reg = <0x1000 0x1000>;
+interrupts = <102 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+sec_jr1: jr1@2000 {
+compatible = "fsl,sec-v4.0-job-ring";
+reg = <0x2000 0x1000>;
+interrupts = <102 IRQ_TYPE_LEVEL_HIGH>;
+};
+};
};
};
};
--
2.21.3
RE: [PATCH] arm64: dts: exynos: Add minimal bootargs
Hi Krzysztof,
> > > @@ -24,6 +24,7 @@
> > >
> > > chosen {
> > > stdout-path = &serial_2;
> > > + bootargs = "earlycon=exynos4210,0x14c3
> > > console=ttySAC0,115200n8";
>
> Hi,
>
> The console is already chosen by stdout-path and earlycon would use it as
> well,
> so no need for the address. It should be just "earlycon" if you want to
> enable it
> unconditionally.
>
Indeed only "earlycon" will do here. Thanks for point this out.
> Also, why did you use different serial for console?
>
Once UART driver gets probed then console changes to ttySAC0. In case I am
using stdout-path only,
after bootconsole is disabled, kernel logs re-start printing from beginning
(which might be expected behaviour?)
[0.012416] printk: console [tty0] enabled
[0.016491] printk: bootconsole [exynos4210] disabled
[0.00] Booting Linux on physical CPU 0x00 [0x410fd032]
[0.00] Linux version 5.8.0-rc3-next-20200703-8-g4af626444f4a-dirty
(alim@alim) (aarch64-linux-gnu-gcc (Linaro GCC 7.4-2019.02) 7.4.1 20181213 [l0
[0.00] Machine model: Samsung Exynos7 Espresso board based on Exynos7
> However the question is, are you sure you want earlycon on every, including
> successful boot? On most of the boards we do not enable by default. If
> developer needs, he can choose it for example via U-Boot "setenv opts
> earlycon".
>
Using U-Boot is not the case always, any bootload can be used to boot the
Linux, currently I am Coreboot.
And 'earlycon' is not setup by default.
As Espresson board is development board, IMO it is ok to keep it enable all the
time, this helps in quickly knowing what going on incase boot fails early.
Let me know if it is ok to keep " console=ttySAC0,115200n8" or shell I just
re-spin with only 'earlycon'? or any other suggestion?
Thanks!
> However it's a development kit so it could be enabled on default...
>
> Best regards,
> Krzysztof
>
> > > };
> > >
> > > memory@4000 {
> > >
> > > base-commit: 9e50b94b3eb0d859a2586b5a40d7fd6e5afd9210
> > > --
> > > 2.17.1
> >
> >
Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology
On Sun, Jul 05, 2020 at 09:39:29AM +1000, Dave Airlie wrote: > I don't totally agree on that, because like the CoC discussion, people > need concrete examples. People need reasons, saying simply "be > inclusive" doesn't work. > > You say "be inclusive" people don't think about it, they just go "I'm > inclusive" and proceed, never questioning what it means to be > inclusive, they normalise inclusivity to their self image and within > their lives where they might never confront anything like this. > > I don't doubt we get the American/Ottoman/Barbery coast people and the > correct answer to those people is to tell them to examine why they > suddenly care about Barbery slavery now when they have never even > heard or worried about it before. Why haven't they submitted patches > removing slavery terminology from the kernel before? Right; this part of the patch provides a temporal explanation for "but why now?" and acts as an internal reference, instead of pointing to external[1] sources, which lack the Linux-specific contextualization. Additionally, I think it provides rebuttals to many of the specious arguments against inclusive terminology (and it could perhaps gain more, as we've already seen in this thread, against slippery slope arguments). It also attempts to acknowledge what this change in the kernel processes provides to the world in general: it's a fairly local change to make our development community less disruptive to those that would seek to join it -- it does not, and cannot, solve global racism (though that would be nice). [1] https://tools.ietf.org/id/draft-knodel-terminology-01.html -- Kees Cook
drivers/bluetooth/hci_qca.c:1692:35: warning: unused variable 'qca_soc_data_wcn3990'
Hi Rocky,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 35e884f89df4c48566d745dc5a97a0d058d04263
commit: e5d6468fe9d8dced9af0c548a359a7dbeb31c931 Bluetooth: hci_qca: Add
support for Qualcomm Bluetooth SoC QCA6390
date: 3 months ago
config: x86_64-randconfig-a001-20200705 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
e359ab1eca5727ce4c688bb49323b8a09478d61c)
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 x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout e5d6468fe9d8dced9af0c548a359a7dbeb31c931
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/bluetooth/hci_qca.c:1692:35: warning: unused variable
>> 'qca_soc_data_wcn3990' [-Wunused-const-variable]
static const struct qca_vreg_data qca_soc_data_wcn3990 = {
^
>> drivers/bluetooth/hci_qca.c:1703:35: warning: unused variable
>> 'qca_soc_data_wcn3991' [-Wunused-const-variable]
static const struct qca_vreg_data qca_soc_data_wcn3991 = {
^
>> drivers/bluetooth/hci_qca.c:1714:35: warning: unused variable
>> 'qca_soc_data_wcn3998' [-Wunused-const-variable]
static const struct qca_vreg_data qca_soc_data_wcn3998 = {
^
3 warnings generated.
vim +/qca_soc_data_wcn3990 +1692 drivers/bluetooth/hci_qca.c
0ff252c1976da5 Ben Young Tae Kim 2015-08-10 1691
523760b7ff8871 Harish Bandi 2019-04-26 @1692 static const struct
qca_vreg_data qca_soc_data_wcn3990 = {
fa9ad876b8e0eb Balakrishna Godavarthi 2018-08-03 1693 .soc_type =
QCA_WCN3990,
fa9ad876b8e0eb Balakrishna Godavarthi 2018-08-03 1694 .vregs =
(struct qca_vreg []) {
f2edd66e515b99 Bjorn Andersson2019-10-17 1695 {
"vddio", 15000 },
f2edd66e515b99 Bjorn Andersson2019-10-17 1696 {
"vddxo", 8 },
f2edd66e515b99 Bjorn Andersson2019-10-17 1697 {
"vddrf", 30 },
f2edd66e515b99 Bjorn Andersson2019-10-17 1698 {
"vddch0", 45 },
fa9ad876b8e0eb Balakrishna Godavarthi 2018-08-03 1699 },
fa9ad876b8e0eb Balakrishna Godavarthi 2018-08-03 1700 .num_vregs = 4,
fa9ad876b8e0eb Balakrishna Godavarthi 2018-08-03 1701 };
fa9ad876b8e0eb Balakrishna Godavarthi 2018-08-03 1702
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06 @1703 static const struct
qca_vreg_data qca_soc_data_wcn3991 = {
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06 1704 .soc_type =
QCA_WCN3991,
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06 1705 .vregs =
(struct qca_vreg []) {
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06 1706 {
"vddio", 15000 },
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06 1707 {
"vddxo", 8 },
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06 1708 {
"vddrf", 30 },
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06 1709 {
"vddch0", 45 },
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06 1710 },
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06 1711 .num_vregs = 4,
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06 1712 };
7d250a062f75e6 Balakrishna Godavarthi 2019-11-06 1713
523760b7ff8871 Harish Bandi 2019-04-26 @1714 static const struct
qca_vreg_data qca_soc_data_wcn3998 = {
523760b7ff8871 Harish Bandi 2019-04-26 1715 .soc_type =
QCA_WCN3998,
523760b7ff8871 Harish Bandi 2019-04-26 1716 .vregs =
(struct qca_vreg []) {
f2edd66e515b99 Bjorn Andersson2019-10-17 1717 {
"vddio", 1 },
f2edd66e515b99 Bjorn Andersson2019-10-17 1718 {
"vddxo", 8 },
f2edd66e515b99 Bjorn Andersson2019-10-17 1719 {
"vddrf", 30 },
f2edd66e515b99 Bjorn Andersson2019-10-17 1720 {
"vddch0", 45 },
523760b7ff8871 Harish Bandi 2019-04-26 1721 },
523760b7ff8871 Harish Bandi 2019-04-26 1722 .num_vregs = 4,
523760b7ff8871 Harish Bandi 2019-04-26 1723 };
523760b7ff8871 Harish Bandi 2019-04-26 1724
:: The code at line 1692 was first introduced by commit
:: 523760b7ff8871281aaedc44c305926469ab47f8 Bluetooth: hci_qca: Added
support for WCN3998
:: TO: Harish Bandi
:: CC: Marcel Holtmann
---
0-DAY CI Kernel Test Service, Intel
[PATCH] ARM64: dts: update MDIO speed and preamble for zii-ultra device
Update MDIO configuration with zii-ultra device to fully utilize
MDIO endpoint capabilities. Device supports 12.5MHz clock and
doesn't require MDIO preamble.
Signed-off-by: Chris Healy
---
arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
index 6a55165bd76a..98aa67a4c040 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
@@ -132,6 +132,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;
switch: switch@0 {
compatible = "marvell,mv88e6085";
--
2.21.3
Re: [Tech-board-discuss] [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology
On Sat, Jul 04, 2020 at 08:10:33PM -0400, Matthew Wilcox wrote: > Left-right tree makes no sense. It doesn't distinguish the rbtree from its > predecessor the avl tree. I don't think it's helpful to rename a standard > piece of computing terminology unless it's actually hurting us to have it. > Obviously if it were called a "master-slave" tree, I would be in favour of > renaming it. (No one has suggested renaming red/black trees, so I think the slippery-slope argument can be set aside here.) As for the actual proposal on white/black-list, I've always been annoyed by the poor description it provides (and I get to see it A LOT being the seccomp maintainer). I welcome allow/deny-list (though the change is not new for seccomp -- the man pages were updated last year (thanks mkerrisk). :) -- Kees Cook
Re: [PATCH v2 0/2] qlogic: use generic power management
From: Vaibhav Gupta Date: Thu, 2 Jul 2020 22:31:41 +0530 > Linux Kernel Mentee: Remove Legacy Power Management. > > The purpose of this patch series is to remove legacy power management > callbacks > from qlogic ethernet drivers. > > The callbacks performing suspend() and resume() operations are still calling > pci_save_state(), pci_set_power_state(), etc. and handling the power > management > themselves, which is not recommended. > > The conversion requires the removal of the those function calls and change the > callback definition accordingly and make use of dev_pm_ops structure. > > All patches are compile-tested only. > > V2: Fix unused variable warning in v1. Series applied.
[PATCH] ARM: dts: update MDIO speed and preamble for zii devices
Update MDIO configuration with zii devices to fully utilize
MDIO endpoint capabilities. All devices support 12.5MHz clock and
don't require MDIO preamble.
Signed-off-by: Chris Healy
---
arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 2 ++
arch/arm/boot/dts/vf610-zii-cfu1.dts | 2 ++
arch/arm/boot/dts/vf610-zii-dev.dtsi | 2 ++
arch/arm/boot/dts/vf610-zii-spb4.dts | 2 ++
arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts | 2 ++
arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts | 2 ++
6 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
index 20350e803377..58cc421042e1 100644
--- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
@@ -720,6 +720,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;
switch: switch@0 {
compatible = "marvell,mv88e6085";
diff --git a/arch/arm/boot/dts/vf610-zii-cfu1.dts
b/arch/arm/boot/dts/vf610-zii-cfu1.dts
index ce1920c052fc..c27cacbe6a73 100644
--- a/arch/arm/boot/dts/vf610-zii-cfu1.dts
+++ b/arch/arm/boot/dts/vf610-zii-cfu1.dts
@@ -159,6 +159,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;
switch0: switch0@0 {
compatible = "marvell,mv88e6085";
diff --git a/arch/arm/boot/dts/vf610-zii-dev.dtsi
b/arch/arm/boot/dts/vf610-zii-dev.dtsi
index 95d0060fb56c..9694d3b53607 100644
--- a/arch/arm/boot/dts/vf610-zii-dev.dtsi
+++ b/arch/arm/boot/dts/vf610-zii-dev.dtsi
@@ -138,6 +138,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;
};
};
diff --git a/arch/arm/boot/dts/vf610-zii-spb4.dts
b/arch/arm/boot/dts/vf610-zii-spb4.dts
index 55b4201e27f6..d2ad07ed5318 100644
--- a/arch/arm/boot/dts/vf610-zii-spb4.dts
+++ b/arch/arm/boot/dts/vf610-zii-spb4.dts
@@ -120,6 +120,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;
switch0: switch0@0 {
compatible = "marvell,mv88e6190";
diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
index a6c22a79779e..0bb3dcff0b79 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-dtu.dts
@@ -106,6 +106,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;
switch0: switch0@0 {
compatible = "marvell,mv88e6190";
diff --git a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
index 3d05c894bdc0..e12e11805b71 100644
--- a/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
+++ b/arch/arm/boot/dts/vf610-zii-ssmb-spu3.dts
@@ -134,6 +134,8 @@
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
+suppress-preamble = <1>;
+clock-frequency = <1250>;
switch0: switch0@0 {
compatible = "marvell,mv88e6190";
--
2.21.3
Re: [PATCH net-next v2 1/2] net: dsa: microchip: split adjust_link() in phylink_mac_link_{up|down}()
From: Codrin Ciubotariu Date: Thu, 2 Jul 2020 18:17:23 +0300 > The DSA subsystem moved to phylink and adjust_link() became deprecated in > the process. This patch removes adjust_link from the KSZ DSA switches and > adds phylink_mac_link_up() and phylink_mac_link_down(). > > Signed-off-by: Codrin Ciubotariu > Reviewed-by: Russell King Applied.
Re: [PATCH net-next v2 2/2] net: dsa: microchip: remove unused private members
From: Codrin Ciubotariu Date: Thu, 2 Jul 2020 18:17:24 +0300 > Private structure members live_ports, on_ports, rx_ports, tx_ports are > initialized but not used anywhere. Let's remove them. > > Suggested-by: Russell King > Signed-off-by: Codrin Ciubotariu Applied.
Re: [PATCH net] hinic: fix sending mailbox timeout in aeq event work
From: Luo bin Date: Sat, 4 Jul 2020 15:32:43 +0800 > When sending mailbox in the work of aeq event, another aeq event > will be triggered. because the last aeq work is not exited and only > one work can be excuted simultaneously in the same workqueue, mailbox > sending function will return failure of timeout. We create and use > another workqueue to fix this. > > Signed-off-by: Luo bin Applied, thanks.
Re: [PATCH] drivers/net/wan/lapbether: Fixed the value of hard_header_len
From: Xie He Date: Fri, 3 Jul 2020 22:12:46 -0700 > When transmitting data from upper layers or from AF_PACKET sockets, > this driver will first remove a pseudo header of 1 byte, > then the lapb module will prepend the LAPB header of 2 or 3 bytes, > then this driver will prepend a length field of 2 bytes, > then the underlying Ethernet device will prepend its own header. Please add something like this above text to a comment: > @@ -324,6 +323,8 @@ static int lapbeth_new_device(struct net_device *dev) > if (!ndev) > goto out; > > + ndev->hard_header_len = -1 + 3 + 2 + dev->hard_header_len; > + Above this new line so that someone reading the code can understand these magic numbers and what they mean. Thank you.
drivers/mtd/nand/raw/sh_flctl.c:510:24: sparse: sparse: incorrect type in argument 1 (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 35e884f89df4c48566d745dc5a97a0d058d04263 commit: 05933aac7b11911955de307a329dc2a7a14b7bd0 ia64: remove now unused machvec indirections date: 11 months ago config: ia64-randconfig-s031-20200705 (attached as .config) compiler: ia64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-3-gfa153962-dirty git checkout 05933aac7b11911955de307a329dc2a7a14b7bd0 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=ia64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/mtd/nand/raw/sh_flctl.c:456:16: sparse: sparse: cast to restricted __le32 drivers/mtd/nand/raw/sh_flctl.c:479:26: sparse: sparse: cast to restricted __be32 drivers/mtd/nand/raw/sh_flctl.c:479:26: sparse: sparse: cast to restricted __be32 drivers/mtd/nand/raw/sh_flctl.c:479:26: sparse: sparse: cast to restricted __be32 drivers/mtd/nand/raw/sh_flctl.c:479:26: sparse: sparse: cast to restricted __be32 drivers/mtd/nand/raw/sh_flctl.c:479:26: sparse: sparse: cast to restricted __be32 drivers/mtd/nand/raw/sh_flctl.c:479:26: sparse: sparse: cast to restricted __be32 drivers/mtd/nand/raw/sh_flctl.c:494:38: sparse: sparse: cast to restricted __be32 drivers/mtd/nand/raw/sh_flctl.c:494:38: sparse: sparse: cast to restricted __be32 drivers/mtd/nand/raw/sh_flctl.c:494:38: sparse: sparse: cast to restricted __be32 drivers/mtd/nand/raw/sh_flctl.c:494:38: sparse: sparse: cast to restricted __be32 drivers/mtd/nand/raw/sh_flctl.c:494:38: sparse: sparse: cast to restricted __be32 drivers/mtd/nand/raw/sh_flctl.c:494:38: sparse: sparse: cast to restricted __be32 >> drivers/mtd/nand/raw/sh_flctl.c:510:24: sparse: sparse: incorrect type in >> argument 1 (different base types) @@ expected unsigned int [usertype] >> value @@ got restricted __be32 [usertype] @@ >> drivers/mtd/nand/raw/sh_flctl.c:510:24: sparse: expected unsigned int >> [usertype] value drivers/mtd/nand/raw/sh_flctl.c:510:24: sparse: got restricted __be32 [usertype] drivers/mtd/nand/raw/sh_flctl.c:523:24: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned long @@ got restricted __be32 [usertype] @@ drivers/mtd/nand/raw/sh_flctl.c:523:24: sparse: expected unsigned long drivers/mtd/nand/raw/sh_flctl.c:523:24: sparse: got restricted __be32 [usertype] include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype] include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype] include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype] include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype] include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] value @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] value include/asm-generic/io.h:225
Re: [PATCH 0/7] Documentation: networking: eliminate doubled words
From: Randy Dunlap Date: Fri, 3 Jul 2020 15:41:08 -0700 > Drop all duplicated words in Documentation/networking/ files. Series applied, thanks Randy.
Re: [PATCH 1/2] hwmon: shtc1: add support for device tree bindings
Hi Guenter,
On 3/7/2020 1:48 pm, Guenter Roeck wrote:
On 7/2/20 8:48 PM, Chris Ruehl wrote:
Add support for DTS bindings to the shtc driver, use CONFIG_OF
to compile in the code if needed.
Ah, here it is. The introducing patch should say something like "[PATCH 0/2]".
Signed-off-by: Chris Ruehl
---
drivers/hwmon/shtc1.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/hwmon/shtc1.c b/drivers/hwmon/shtc1.c
index a0078ccede03..3bcabc1cbce8 100644
--- a/drivers/hwmon/shtc1.c
+++ b/drivers/hwmon/shtc1.c
@@ -14,6 +14,9 @@
#include
#include
#include
+#ifdef CONFIG_OF
No. Please no conditional includes.
OK, will be fixed and same for below.
+#include
+#endif
/* commands (high precision mode) */
static const unsigned char shtc1_cmd_measure_blocking_hpm[]= { 0x7C, 0xA2
};
@@ -196,6 +199,10 @@ static int shtc1_probe(struct i2c_client *client,
enum shtcx_chips chip = id->driver_data;
struct i2c_adapter *adap = client->adapter;
struct device *dev = &client->dev;
+#ifdef CONFIG_OF
+ struct device_node *np = dev->of_node;
+ u8 value;
+#endif
if (!i2c_check_functionality(adap, I2C_FUNC_I2C)) {
dev_err(dev, "plain i2c transactions not supported\n");
@@ -235,6 +242,20 @@ static int shtc1_probe(struct i2c_client *client,
if (client->dev.platform_data)
data->setup = *(struct shtc1_platform_data *)dev->platform_data;
+
+#ifdef CONFIG_OF
Unnecessary ifdef. Selection of devicetree data or not can be made
based on np != NULL. Also, if devictree data is available, platform
data should be ignored to avoid confusion.
Ok, I wasn't aware this rule. Will change it.
+ if (np) {
+ if (of_property_read_bool(np, "sensirion,blocking_io")) {
+ of_property_read_u8(np, "sensirion,blocking_io",
&value);
+ data->setup.blocking_io = (value > 0) ? true : false;
+ }
Why this complexity, and why not just make the property a boolean ?
+ if (of_property_read_bool(np, "sensicon,high_precision")) {
+ of_property_read_u8(np, "sensirion,high_precision",
&value);
+ data->setup.high_precision = (value > 0) ? true : false;
"sensicon,high_precision" should also be a boolean.
+ }
+ }
+#endif
+
shtc1_select_command(data);
mutex_init(&data->update_lock);
@@ -257,6 +278,15 @@ static const struct i2c_device_id shtc1_id[] = {
};
MODULE_DEVICE_TABLE(i2c, shtc1_id);
+#ifdef CONFIG_OF
+static const struct of_device_id shtc1_of_match[] = {
+ { .compatible = "sensirion,shtc1" },
+ { .compatible = "sensirion,shtw1" },
+ { .compatible = "sensirion,shtc3" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, shtc1_of_match);
+#endif
static struct i2c_driver shtc1_i2c_driver = {
.driver.name = "shtc1",
.probe= shtc1_probe,
Not sure how this works without setting of_match_table. I guess it just works
accidentally because .id_table also provides a devicetree match. Still,
of_match_table should be set.
Thanks, I will take care of this in the v2 version.
Guenter
Re: [PATCH] CodingStyle: Inclusive Terminology
On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote: > Recent events have prompted a Linux position statement on inclusive > terminology. Given that Linux maintains a coding-style and its own > idiomatic set of terminology here is a proposal to answer the call to > replace non-inclusive terminology. > > Cc: Jonathan Corbet > Cc: Kees Cook > Signed-off-by: Chris Mason > Signed-off-by: Greg Kroah-Hartman > Signed-off-by: Dan Williams (nit: isn't this a Co-developed-by chain, not a SoB chain?) Acked-by: Kees Cook Comments below... > --- > Documentation/process/coding-style.rst | 12 > Documentation/process/inclusive-terminology.rst | 64 > +++ > Documentation/process/index.rst |1 > 3 files changed, 77 insertions(+) > create mode 100644 Documentation/process/inclusive-terminology.rst > > diff --git a/Documentation/process/coding-style.rst > b/Documentation/process/coding-style.rst > index 2657a55c6f12..4b15ab671089 100644 > --- a/Documentation/process/coding-style.rst > +++ b/Documentation/process/coding-style.rst > @@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, > you have another > problem, which is called the function-growth-hormone-imbalance syndrome. > See chapter 6 (Functions). > > +For symbol names, avoid introducing new usage of the words 'slave' and > +'blacklist'. Recommended replacements for 'slave' are: 'secondary', > +'subordinate', 'replica', 'responder', 'follower', 'proxy', or > +'performer'. Recommended replacements for blacklist are: 'blocklist' or > +'denylist'. Keeping "master" in a "master/slave" pairing (i.e. replacing only "slave") seems incomplete to me. If "master" is paired with "slave", it should be replaced too. Potential examples: 'primary', 'leader', 'principle', 'controller', 'sender', 'initial'. Similarly, for "whitelist/blacklist", "whitelist" needs to replaced when "blacklist" has been. For example, seccomp documentation[1] uses "allow-list" and "deny-list". [1] https://man7.org/linux/man-pages/man2/seccomp.2.html > +Exceptions for introducing new usage is to maintain a userspace ABI, or and API? > +when updating code for an existing (as of 2020) hardware or protocol > +specification that mandates those terms. For new specifications consider > +translating specification usage of the terminology to the kernel coding > +standard where possible. See :ref:`process/inclusive-terminology.rst > +` for details. Let's add: Where possible, old instances of this language should be replaced when it is not tied to external specifications nor userspace ABI/API. > > 5) Typedefs > --- > diff --git a/Documentation/process/inclusive-terminology.rst > b/Documentation/process/inclusive-terminology.rst > new file mode 100644 > index ..a8eb26690eb4 > --- /dev/null > +++ b/Documentation/process/inclusive-terminology.rst > @@ -0,0 +1,64 @@ > +.. _inclusiveterminology: > + > +Linux kernel inclusive terminology > +== > + > +The Linux kernel is a global software project, and in 2020 there was a > +global reckoning on race relations that caused many organizations to > +re-evaluate their policies and practices relative to the inclusion of > +people of African descent. This document describes why the 'Naming' > +section in :ref:`process/coding-style.rst ` recommends > +avoiding usage of 'slave' and 'blacklist' in new additions to the Linux > +kernel. ... usage of 'master/slave', 'slave', 'whitelist/blacklist', and 'blacklist' in the Linux kernel. > + > +On the triviality of replacing words > + > + > +The African slave trade was a brutal system of human misery deployed at > +global scale. Some word choice decisions in a modern software project > +does next to nothing to compensate for that legacy. So why put any > +effort into something so trivial in comparison? Because the goal is not > +to repair, or erase the past. The goal is to maximize availability and > +efficiency of the global developer community to participate in the Linux > +kernel development process. > + > +Word choice and developer efficiency > + > + > +Why does any software project go through the trouble of developing a > +document like :ref:`process/coding-style.rst `? It does so > +because a common coding style maximizes the efficiency of both > +maintainers and developers. Developers learn common design patterns and > +idiomatic expressions while maintainers can spot deviations from those > +norms. Even non-compliant whitespace is considered a leading indicator > +to deeper problems in a patchset. Coding style violations are known to > +take a maintainer "out of the zone" of reviewing code. Maintainers are > +also sensitive to word choice across specifications and often choose to > +deploy Linux terminology to replace non-idiomatic word-choice in a > +specification. > + > +Non-inclus
Re: [PATCH 2/2] devicetree: hwmon: shtc1: Add sensirion,shtc1.yaml
Hi Guenter,
On 3/7/2020 1:49 pm, Guenter Roeck wrote:
On 7/2/20 8:48 PM, Chris Ruehl wrote:
Add documentation for the newly added DTS support in the shtc1 driver.
Signed-off-by: Chris Ruehl
---
.../bindings/hwmon/sensirion,shtc1.yaml | 53 +++
1 file changed, 53 insertions(+)
create mode 100644
Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
new file mode 100644
index ..e3e292bc6d7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/sensirion,shtc1.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/sensirion,shtc1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sensirion SHTC1 Humidity and Temperature Sensor IC
+
+maintainers:
+ - jdelv...@suse.com
+
+description: |
+ The SHTC1, SHTW1 and SHTC3 are digital humidity and temperature sensor
+ designed especially for battery-driven high-volume consumer electronics
+ applications.
+ For further information refere to Documentation/hwmon/shtc1.rst
+
+ This binding document describes the binding for the hardware monitor
+ portion of the driver.
+
+properties:
+ compatible:
+enum:
+ - sensirion,shtc1
+ - sensirion,shtw1
+ - sensirion,shtc3
+
+ reg: I2C address 0x70
+
+Optional properties:
+ sensirion,blocking_io: |
+u8, if > 0 the i2c bus hold until measure finished (default 0)
+ sensirion,high_precision: |
+u8, if > 0 aquire data with high precision (default 1)
+
Why u8 and not boolean ?
Guenter
The author of the driver make high_precision default (recommend) in the code,
if I use boolean, then the device tree _must_ have have the
sensirion,high_precision set
or I need to do the opposite and define sensirion,low_precision.
(blocking_io = false default, high_precision = true default)
that's the reason I was thinking use a u8 and test with of_property_read_bool to
check
the presence of it and set it if value > 0.
Chris.
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+Example:
+ &i2c1 {
+status = "okay";
+clock-frequency = <40>;
+
+shtc3@70 {
+ compatible = "sensirion,shtc3";
+ reg = <0x70>
+ sensirion,blocking_io = <1>;
+ status = "okay";
+};
+ };
--
GTSYS Limited RFID Technology
9/F, Unit E, R07, Kwai Shing Industrial Building Phase 2,
42-46 Tai Lin Pai Road, Kwai Chung, N.T., Hong Kong
Tel (852) 9079 9521
Disclaimer: https://www.gtsys.com.hk/email/classified.html
fast binary calculator
ey
Ive made a program, that uses bit flips to quickly represent binary numbers
for instance, if i use a 128bit number than the algorithm uses
128+128+128 (and not 128*128)
for each bit.
Basically, it assigns slots to bits, so for instance
pos 1 pos 2 pos 3
0 0 0
1 1 1
so that reduces the time it takes to scan them. I also use bit flips to
change the bit on a particular slot.
i wrote both c and java files.
later
Here is the code in c
#include
char flipBit(char c);
char flipBit(char c) {
if (c == '0')
return '1';
else
return '0';
}
int main() {
char binaryNumber[] = { '0','0','0','0',0 };
int slot1,slot2,slot3,slot4;
for (slot1=0 ; slot1 < 2 ; slot1++) {
printf("\n%s",binaryNumber);
for (slot2 =1 ; slot2 < 2 ; slot2++) {
binaryNumber[slot2] =
flipBit(binaryNumber[slot2]);
printf("\n%s",binaryNumber);
for (slot3=2 ; slot3 < 3 ; slot3++) {
binaryNumber[slot3] =
flipBit(binaryNumber[slot3]);
printf("\n%s",binaryNumber);
for (slot4=3 ; slot4 < 4 ; slot4++) {
binaryNumber[slot4] =
flipBit(binaryNumber[slot4]);
printf("\n%s",binaryNumber);
}
}
}
binaryNumber[slot1] =
flipBit(binaryNumber[slot1]);
printf("\n");
}
}
--
André Albergaria Coelho
andrealberga...@gmail.com
#include
char flipBit(char c);
char flipBit(char c) {
if (c == '0')
return '1';
else
return '0';
}
int main() {
char binaryNumber[] = { '0','0','0','0',0 };
int slot1,slot2,slot3,slot4;
for (slot1=0 ; slot1 < 2 ; slot1++) {
printf("\n%s",binaryNumber);
for (slot2 =1 ; slot2 < 2 ; slot2++) {
binaryNumber[slot2] = flipBit(binaryNumber[slot2]);
printf("\n%s",binaryNumber);
for (slot3=2 ; slot3 < 3 ; slot3++) {
binaryNumber[slot3] = flipBit(binaryNumber[slot3]);
printf("\n%s",binaryNumber);
for (slot4=3 ; slot4 < 4 ; slot4++) {
binaryNumber[slot4] = flipBit(binaryNumber[slot4]);
printf("\n%s",binaryNumber);
}
}
}
binaryNumber[slot1] = flipBit(binaryNumber[slot1]);
printf("\n");
}
}
import java.io.UnsupportedEncodingException;
import java.util.Arrays;
public class binPath {
// ao inves de se usar o numero , usas a posicao dele na posicao do numero (na array)
// ao inves de se usar o sistema de numeros (cada posicao ocupa um elemento vezes a base)
public static void main(String[] args) {
byte[] plaintext = {0,0,0,1,1,1,0,1};
// prints bits and positions
/*byte[] b = {0,0,0,0,0,0,0,0};
byte[] b2 = {1,1,1,1,1,1,1,1};
for (int pos=0; pos < 8; pos++) {
System.out.println("position "+pos+" "+b[pos]);
System.out.println("position "+pos+" "+b2[pos]);
}
*/
byte[] t = { 0,0,0,0 };
for (int slot1 = 0 ; slot1 < 2 ; slot1++) {
System.out.println();
System.out.print(Arrays.toString(t));
for (int slot2 = 1; slot2 < 2 ; slot2++) {
t[slot2] = bitFlip(t[slot2]);
System.out.println();
System.out.print(Arrays.toString(t));
for (int slot3 = 2; slot3 < 3 ; slot3++) {
t[slot3] = bitFlip(t[slot3]);
System.out.println();
System.out.print(Arrays.toString(t));
for (int slot4=3; slot4 < 4 ; slot4++) {
t[slot4] = bitFlip(t[slot4]);
System.out.println();
System.out.print(Arrays.toString(t));
}
}
}
t[slot1] = bitFlip(t[slot1]);
}
}
// Flips bits
public static byte bitFlip(byte b) {
if (b == 0)
return 1;
else
return 0;
}
}
Re: [PATCH] sched: Better document ttwu()
On 03/07/20 14:32, Peter Zijlstra wrote:
> Dave hit the problem fixed by commit:
>
> b6e13e85829f ("sched/core: Fix ttwu() race")
>
> and failed to understand much of the code involved. Per his request a
> few comments to (hopefully) clarify things.
>
> Requested-by: Dave Chinner
> Signed-off-by: Peter Zijlstra (Intel)
Small extra comment below, otherwise FWIW:
Reviewed-by: Valentin Schneider
> +++ b/kernel/sched/core.c
> @@ -79,6 +79,100 @@ __read_mostly int scheduler_running;
> */
> int sysctl_sched_rt_runtime = 95;
>
> +
> +/*
> + * Serialization rules:
> + *
> + * Lock order:
> + *
> + * p->pi_lock
> + * rq->lock
> + * hrtimer_cpu_base->lock (hrtimer_start() for bandwidth controls)
> + *
> + * rq1->lock
> + *rq2->lock where: rq1 < rq2
> + *
> + * Regular state:
> + *
> + * Normal scheduling state is serialized by rq->lock. __schedule() takes the
> + * local CPU's rq->lock, it optionally removes the task from the runqueue and
> + * always looks at the local rq data structures to find the most elegible
> task
> + * to run next.
> + *
> + * Task enqueue is also under rq->lock, possibly taken from another CPU.
> + * Wakeups from another LLC domain might use an IPI to transfer the enqueue
> to
> + * the local CPU to avoid bouncing the runqueue state around [ see
> + * ttwu_queue_wakelist() ]
> + *
> + * Task wakeup, specifically wakeups that involve migration, are horribly
> + * complicated to avoid having to take two rq->locks.
> + *
> + * Special state:
> + *
> + * System-calls and anything external will use task_rq_lock() which acquires
> + * both p->pi_lock and rq->lock. As a consequence the state they change is
> + * stable while holding either lock:
> + *
> + * - sched_setaffinity()/
> + *set_cpus_allowed_ptr():p->cpus_ptr, p->nr_cpus_allowed
> + * - set_user_nice(): p->se.load, p->*prio
> + * - __sched_setscheduler():p->sched_class, p->policy, p->*prio,
> + * p->se.load, p->rt_priority,
> + * p->dl.dl_{runtime, deadline, period, flags, bw,
> density}
Uclamp stuff can also get updated in __sched_setscheduler(); see
__setscheduler_uclamp(). It's only p->uclamp_req AFAICT, but I don't think
there's harm in just saying p->uclamp*.
> + * - sched_setnuma(): p->numa_preferred_nid
> + * - sched_move_task()/
> + *cpu_cgroup_fork(): p->sched_task_group
> + * - uclamp_update_active() p->uclamp*
> + *
Re: [RESEND PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
Hi, Enric:
Enric Balletbo i Serra 於 2020年6月16日 週二 上午4:31寫道：
>
> Use the drm_bridge_connector helper to create a connector for pipelines
> that use drm_bridge. This allows splitting connector operations across
> multiple bridges when necessary, instead of having the last bridge in
> the chain creating the connector and handling all connector operations
> internally.
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Signed-off-by: Enric Balletbo i Serra
> Acked-by: Sam Ravnborg
> ---
>
> Changes in v4: None
> Changes in v3:
> - Move the bridge.type line to the patch that adds drm_bridge support.
> (Laurent Pinchart)
>
> Changes in v2: None
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 4f3bd095c1eee..471fcafdf3488 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -17,6 +17,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -183,6 +184,7 @@ struct mtk_dsi {
> struct drm_encoder encoder;
> struct drm_bridge bridge;
> struct drm_bridge *next_bridge;
> + struct drm_connector *connector;
> struct phy *phy;
>
> void __iomem *regs;
> @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm,
> struct mtk_dsi *dsi)
> */
> dsi->encoder.possible_crtcs = 1;
>
> - ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
> + ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> if (ret)
> goto err_cleanup_encoder;
>
> + dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
> + if (IS_ERR(dsi->connector)) {
> + DRM_ERROR("Unable to create bridge connector\n");
> + ret = PTR_ERR(dsi->connector);
> + goto err_cleanup_encoder;
> + }
> + drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
> +
> return 0;
>
> err_cleanup_encoder:
> --
> 2.27.0
>
Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology
On Sun, 2020-07-05 at 09:39 +1000, Dave Airlie wrote: > Why haven't they submitted patches > removing slavery terminology from the kernel before? Because inhuman devices in a master/slave hierarchy isn't anything like chattel slavery? Blacklist/whitelist has nothing to do with skin color? Are red-black trees next?
Re: [RESEND PATCH v4 6/7] drm/mediatek: mtk_dsi: Use the drm_panel_bridge API
Hi, Enric:
Enric Balletbo i Serra 於 2020年6月16日 週二 上午4:31寫道：
>
> Replace the manual panel handling code by a drm_panel_bridge. This
> simplifies the driver and allows all components in the display pipeline
> to be treated as bridges, paving the way to generic connector handling.
>
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Laurent Pinchart
> Acked-by: Sam Ravnborg
> Reviewed-by: Chun-Kuang Hu
> ---
>
> Changes in v4: None
> Changes in v3:
> - Use next_bridge field to store the panel bridge. (Laurent Pinchart)
> - Add the bridge.type field. (Laurent Pinchart)
> - This patch requires https://lkml.org/lkml/2020/4/16/2080 to work
> properly.
>
> Changes in v2:
> - Do not set connector_type for panel here. (Sam Ravnborg)
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 173 +++--
> 1 file changed, 14 insertions(+), 159 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index e02d16a086ac0..4f3bd095c1eee 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -182,8 +182,6 @@ struct mtk_dsi {
> struct mipi_dsi_host host;
> struct drm_encoder encoder;
> struct drm_bridge bridge;
> - struct drm_connector conn;
> - struct drm_panel *panel;
> struct drm_bridge *next_bridge;
> struct phy *phy;
>
> @@ -212,11 +210,6 @@ static inline struct mtk_dsi *bridge_to_dsi(struct
> drm_bridge *b)
> return container_of(b, struct mtk_dsi, bridge);
> }
>
> -static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
> -{
> - return container_of(c, struct mtk_dsi, conn);
> -}
> -
> static inline struct mtk_dsi *host_to_dsi(struct mipi_dsi_host *h)
> {
> return container_of(h, struct mtk_dsi, host);
> @@ -682,16 +675,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> mtk_dsi_lane0_ulp_mode_leave(dsi);
> mtk_dsi_clk_hs_mode(dsi, 0);
>
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to prepare the panel\n");
> - goto err_disable_digital_clk;
> - }
> - }
> -
> return 0;
> -err_disable_digital_clk:
> - clk_disable_unprepare(dsi->digital_clk);
> err_disable_engine_clk:
> clk_disable_unprepare(dsi->engine_clk);
> err_phy_power_off:
> @@ -718,15 +702,7 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> */
> mtk_dsi_stop(dsi);
>
> - if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
> - if (dsi->panel) {
> - if (drm_panel_unprepare(dsi->panel)) {
> - DRM_ERROR("failed to unprepare the panel\n");
> - return;
> - }
> - }
> - }
> -
> + mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
> mtk_dsi_reset_engine(dsi);
> mtk_dsi_lane0_ulp_mode_enter(dsi);
> mtk_dsi_clk_ulp_mode_enter(dsi);
> @@ -757,19 +733,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>
> mtk_dsi_start(dsi);
>
> - if (dsi->panel) {
> - if (drm_panel_enable(dsi->panel)) {
> - DRM_ERROR("failed to enable the panel\n");
> - goto err_dsi_power_off;
> - }
> - }
> -
> dsi->enabled = true;
> -
> - return;
> -err_dsi_power_off:
> - mtk_dsi_stop(dsi);
> - mtk_dsi_poweroff(dsi);
> }
>
> static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> @@ -777,34 +741,19 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> if (!dsi->enabled)
> return;
>
> - if (dsi->panel) {
> - if (drm_panel_disable(dsi->panel)) {
> - DRM_ERROR("failed to disable the panel\n");
> - return;
> - }
> - }
> -
> mtk_dsi_poweroff(dsi);
>
> dsi->enabled = false;
> }
>
> -static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
> *dsi);
> -static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
> -
> static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
> enum drm_bridge_attach_flags flags)
> {
> struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> - return mtk_dsi_create_conn_enc(bridge->dev, dsi);
> -}
> -
> -static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
> -{
> - struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> -
> - mtk_dsi_destroy_conn_enc(dsi);
> + /* Attach the panel or bridge to the dsi bridge */
> + return drm_bridge_attach(bridge->encoder, dsi->next_bridge,
> +
Re: [PATCH 0/2] genirq: Kill preflow handlers
Hi Marc, On 04/07/20 10:48, Marc Zyngier wrote: > Hi Valentin, > > On 2020-07-03 16:56, Valentin Schneider wrote: >> Hi, >> >> while strolling around the different flow handlers, I tried to make >> sense of >> what preflow_handler() was about. Turns out no one uses those anymore, >> but the >> genirq support has remained in place. > > If we needed to reintroduce some form of preflow handler, we'd try and > do it using hierarchical irqchips, if at all possible. Right, that does sound like the most sensible approach. If I got my history right, the preflow handlers saw the light of day before hierarchical domains did, which I suppose is a reason why it wasn't done that way back then. > >> >> Unless we can see another user of those in the near future, this seems >> like as >> good a time as any for a little housecleaning. >> >> - Patch 1 simply deselects the (unexploited) preflow Kconfig for >> sparc64 >> - Patch 2 is the actual cleanup >> >> Cheers, >> Valentin >> >> Valentin Schneider (2): >> sparc64: Deselect IRQ_PREFLOW_FASTEOI >> genirq: Remove preflow handler support >> >> arch/sparc/Kconfig | 1 - >> include/linux/irqdesc.h| 15 --- >> include/linux/irqhandler.h | 1 - >> kernel/irq/Kconfig | 4 >> kernel/irq/chip.c | 13 - >> 5 files changed, 34 deletions(-) > > For the whole series, and assuming that there is no regression > (can't imagine any for unused code): > > Reviewed-by: Marc Zyngier > Thanks! > Thanks, > > M.
Re: [RESEND PATCH v4 5/7] drm/mediatek: mtk_dsi: Use simple encoder
Hi, Enric:
Enric Balletbo i Serra 於 2020年6月16日 週二 上午4:31寫道：
>
> The mtk_dsi driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Laurent Pinchart
> Acked-by: Sam Ravnborg
> Reviewed-by: Chun-Kuang Hu
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 13 ++---
> 1 file changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 759a5b37fb4d2..e02d16a086ac0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -789,15 +789,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> dsi->enabled = false;
> }
>
> -static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> -static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
> - .destroy = mtk_dsi_encoder_destroy,
> -};
> -
> static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
> *dsi);
> static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
>
> @@ -1127,8 +1118,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm,
> struct mtk_dsi *dsi)
> {
> int ret;
>
> - ret = drm_encoder_init(drm, &dsi->encoder, &mtk_dsi_encoder_funcs,
> - DRM_MODE_ENCODER_DSI, NULL);
> + ret = drm_simple_encoder_init(drm, &dsi->encoder,
> + DRM_MODE_ENCODER_DSI);
> if (ret) {
> DRM_ERROR("Failed to encoder init to drm\n");
> return ret;
> --
> 2.27.0
>
Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology
On Sun, 5 Jul 2020 at 06:19, Dan Williams wrote: > > Recent events have prompted a Linux position statement on inclusive > terminology. Given that Linux maintains a coding-style and its own > idiomatic set of terminology here is a proposal to answer the call to > replace non-inclusive terminology. > > Cc: Jonathan Corbet > Cc: Kees Cook > Signed-off-by: Chris Mason > Signed-off-by: Greg Kroah-Hartman > Signed-off-by: Dan Williams I'm sure the language could be fine tuned, but the intent is something I support. Acked-by: Dave Airlie > --- > Documentation/process/coding-style.rst | 12 > Documentation/process/inclusive-terminology.rst | 64 > +++ > Documentation/process/index.rst |1 > 3 files changed, 77 insertions(+) > create mode 100644 Documentation/process/inclusive-terminology.rst > > diff --git a/Documentation/process/coding-style.rst > b/Documentation/process/coding-style.rst > index 2657a55c6f12..4b15ab671089 100644 > --- a/Documentation/process/coding-style.rst > +++ b/Documentation/process/coding-style.rst > @@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, > you have another > problem, which is called the function-growth-hormone-imbalance syndrome. > See chapter 6 (Functions). > > +For symbol names, avoid introducing new usage of the words 'slave' and > +'blacklist'. Recommended replacements for 'slave' are: 'secondary', > +'subordinate', 'replica', 'responder', 'follower', 'proxy', or > +'performer'. Recommended replacements for blacklist are: 'blocklist' or > +'denylist'. > + > +Exceptions for introducing new usage is to maintain a userspace ABI, or > +when updating code for an existing (as of 2020) hardware or protocol > +specification that mandates those terms. For new specifications consider > +translating specification usage of the terminology to the kernel coding > +standard where possible. See :ref:`process/inclusive-terminology.rst > +` for details. > > 5) Typedefs > --- > diff --git a/Documentation/process/inclusive-terminology.rst > b/Documentation/process/inclusive-terminology.rst > new file mode 100644 > index ..a8eb26690eb4 > --- /dev/null > +++ b/Documentation/process/inclusive-terminology.rst > @@ -0,0 +1,64 @@ > +.. _inclusiveterminology: > + > +Linux kernel inclusive terminology > +== > + > +The Linux kernel is a global software project, and in 2020 there was a > +global reckoning on race relations that caused many organizations to > +re-evaluate their policies and practices relative to the inclusion of > +people of African descent. This document describes why the 'Naming' > +section in :ref:`process/coding-style.rst ` recommends > +avoiding usage of 'slave' and 'blacklist' in new additions to the Linux > +kernel. > + > +On the triviality of replacing words > + > + > +The African slave trade was a brutal system of human misery deployed at > +global scale. Some word choice decisions in a modern software project > +does next to nothing to compensate for that legacy. So why put any > +effort into something so trivial in comparison? Because the goal is not > +to repair, or erase the past. The goal is to maximize availability and > +efficiency of the global developer community to participate in the Linux > +kernel development process. > + > +Word choice and developer efficiency > + > + > +Why does any software project go through the trouble of developing a > +document like :ref:`process/coding-style.rst `? It does so > +because a common coding style maximizes the efficiency of both > +maintainers and developers. Developers learn common design patterns and > +idiomatic expressions while maintainers can spot deviations from those > +norms. Even non-compliant whitespace is considered a leading indicator > +to deeper problems in a patchset. Coding style violations are known to > +take a maintainer "out of the zone" of reviewing code. Maintainers are > +also sensitive to word choice across specifications and often choose to > +deploy Linux terminology to replace non-idiomatic word-choice in a > +specification. > + > +Non-inclusive terminology has that same distracting effect which is why > +it is a style issue for Linux, it injures developer efficiency. > + > +Of course it is around this point someone jumps in with an etymological > +argument about why people should not be offended. Etymological arguments > +do not scale. The scope and pace of Linux to reach new developers > +exceeds the ability of historical terminology defenders to describe "no, > +not that connotation". The revelation of 2020 was that black voices were > +heard on a global scale and the Linux kernel project has done its small > +part to answer that call as it wants black voices, among all voices, in > +its developer community. > + > +Really, 'blacklist' too? > + > + > +W
Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology
'. Colors to represent a policy requires an indirection. The > > how about: > Using colors to represent a policy requires an indirection. I'd totally submit that red/black trees while in no way racist, are a horrible indirection, as it means nothing if you've never interacted with gambling culture, (and maybe James Bond movies). left/right trees make naturally more sense and translate into more languages, so yes I think removal of color naming is a good thing even for non-racist reasonings. Dave.
Re: [Ksummit-discuss] [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology
On Sun, 5 Jul 2020 at 07:25, James Bottomley wrote: > > On Sat, 2020-07-04 at 13:02 -0700, Dan Williams wrote: > [...] > > diff --git a/Documentation/process/inclusive-terminology.rst > > b/Documentation/process/inclusive-terminology.rst > > new file mode 100644 > > index ..a8eb26690eb4 > > --- /dev/null > > +++ b/Documentation/process/inclusive-terminology.rst > > Could we just lose this entire document? The one thing we should learn > from recent history is that we really want prevent people distracting > from the good inclusive (and technically more accurate) terminology > will do. One way the detractors do this by engaging in ultimately > pointless arguments about historical accuracy of supporting statements. > By making pejorative statements about history (which are open to > challenge on several fronts), this document acts as a magnet for such > attention. Simply leave it out and the detractors will have nothing to > attack except the bald statement of desiring more inclusive language. > I'd much rather defend why we want inclusive and more descriptive > language than get into a pointless argument over whether the Ottoman > slave trade was more or less evil than the American one. I don't totally agree on that, because like the CoC discussion, people need concrete examples. People need reasons, saying simply "be inclusive" doesn't work. You say "be inclusive" people don't think about it, they just go "I'm inclusive" and proceed, never questioning what it means to be inclusive, they normalise inclusivity to their self image and within their lives where they might never confront anything like this. I don't doubt we get the American/Ottoman/Barbery coast people and the correct answer to those people is to tell them to examine why they suddenly care about Barbery slavery now when they have never even heard or worried about it before. Why haven't they submitted patches removing slavery terminology from the kernel before? Dave.
Re: [Ksummit-discuss] [PATCH] CodingStyle: Inclusive Terminology
On Sun, 5 Jul 2020 at 06:45, Stephen Rothwell wrote: > > Hi Dan, > > On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams > wrote: > > > > +Linux kernel inclusive terminology > > +== > > + > > +The Linux kernel is a global software project, and in 2020 there was a > > +global reckoning on race relations that caused many organizations to > > +re-evaluate their policies and practices relative to the inclusion of > > +people of African descent. This document describes why the 'Naming' > > I feel a need to point out that racial issues are wider than just > people of African descent ... Also, others have pointed out that > slavery is not just restricted to those of African descent. The racial issues are wider than that, and even wider again I'm sure, but in 2020 this is as good a place to start as any, and the trigger as that sentence says was in 2020, there was a reckoning about it mainly due to people of African descent. That trigger has had flow on effects in other countries, but I'm not sure that sentence in any way diminishes that, it's merely an introduction to why this change is happening now. As for the non-black slavery, others have never pointed this out before in 30 years of master/slave terminology? surely if white slavery was as big a problem, they be as supportive of this, even more so. It speaks volumes that I've never heard white slavery as a problem once in 30 years, but now I'm hearing about it a few times, and somehow as an excuse not to support this. Dave.
Re: [RESEND PATCH v4 4/7] drm/mediatek: mtk_dsi: Convert to bridge driver
Hi, Enric:
Enric Balletbo i Serra 於 2020年6月16日 週二 上午4:31寫道：
>
> Convert mtk_dsi to a bridge driver with built-in encoder support for
> compatibility with existing component drivers.
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Signed-off-by: Enric Balletbo i Serra
> Acked-by: Sam Ravnborg
> Reviewed-by: Chun-Kuang Hu
> ---
>
> Changes in v4:
> - Remove double call to drm_encoder_init(). (Chun-Kuang Hu)
> - Cleanup the encoder in mtk_dsi_unbind(). (Chun-Kuang Hu)
>
> Changes in v3:
> - Add the bridge.type. (Laurent Pinchart)
>
> Changes in v2: None
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 117 +++--
> 1 file changed, 79 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 208f49bf14a01..759a5b37fb4d2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -181,6 +181,7 @@ struct mtk_dsi {
> struct device *dev;
> struct mipi_dsi_host host;
> struct drm_encoder encoder;
> + struct drm_bridge bridge;
> struct drm_connector conn;
> struct drm_panel *panel;
> struct drm_bridge *next_bridge;
> @@ -206,9 +207,9 @@ struct mtk_dsi {
> const struct mtk_dsi_driver_data *driver_data;
> };
>
> -static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
> +static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
> {
> - return container_of(e, struct mtk_dsi, encoder);
> + return container_of(b, struct mtk_dsi, bridge);
> }
>
> static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
> @@ -788,32 +789,52 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> dsi->enabled = false;
> }
>
> -static bool mtk_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
> - const struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> +static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
> {
> - return true;
> + drm_encoder_cleanup(encoder);
> }
>
> -static void mtk_dsi_encoder_mode_set(struct drm_encoder *encoder,
> -struct drm_display_mode *mode,
> -struct drm_display_mode *adjusted)
> +static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
> + .destroy = mtk_dsi_encoder_destroy,
> +};
> +
> +static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
> *dsi);
> +static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
> +
> +static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
> +enum drm_bridge_attach_flags flags)
> +{
> + struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> +
> + return mtk_dsi_create_conn_enc(bridge->dev, dsi);
> +}
> +
> +static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
> {
> - struct mtk_dsi *dsi = encoder_to_dsi(encoder);
> + struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> +
> + mtk_dsi_destroy_conn_enc(dsi);
> +}
> +
> +static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode,
> + const struct drm_display_mode *adjusted)
> +{
> + struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> drm_display_mode_to_videomode(adjusted, &dsi->vm);
> }
>
> -static void mtk_dsi_encoder_disable(struct drm_encoder *encoder)
> +static void mtk_dsi_bridge_disable(struct drm_bridge *bridge)
> {
> - struct mtk_dsi *dsi = encoder_to_dsi(encoder);
> + struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> mtk_output_dsi_disable(dsi);
> }
>
> -static void mtk_dsi_encoder_enable(struct drm_encoder *encoder)
> +static void mtk_dsi_bridge_enable(struct drm_bridge *bridge)
> {
> - struct mtk_dsi *dsi = encoder_to_dsi(encoder);
> + struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> mtk_output_dsi_enable(dsi);
> }
> @@ -825,11 +846,12 @@ static int mtk_dsi_connector_get_modes(struct
> drm_connector *connector)
> return drm_panel_get_modes(dsi->panel, connector);
> }
>
> -static const struct drm_encoder_helper_funcs mtk_dsi_encoder_helper_funcs = {
> - .mode_fixup = mtk_dsi_encoder_mode_fixup,
> - .mode_set = mtk_dsi_encoder_mode_set,
> - .disable = mtk_dsi_encoder_disable,
> - .enable = mtk_dsi_encoder_enable,
> +static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
> + .attach = mtk_dsi_bridge_attach,
> + .detach = mtk_dsi_bridge_detach,
> + .disable = mtk_dsi_bridge_disable,
> + .enable = mtk_dsi_bridge_enable,
> + .mode_set = mtk_dsi_bridge_mode_set,
> };
>
> static const struct drm_connector_funcs mtk_dsi_connector_fun
INFO: task hung in lru_add_drain_all
Hello,
syzbot found the following crash on:
HEAD commit:c28e58ee Add linux-next specific files for 20200629
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1400ab3710
kernel config: https://syzkaller.appspot.com/x/.config?x=dcd26bbca17dd1db
dashboard link: https://syzkaller.appspot.com/bug?extid=1053252c4289b5f73548
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11c75c8310
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11fd99e310
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1053252c4289b5f73...@syzkaller.appspotmail.com
INFO: task khugepaged:1160 blocked for more than 143 seconds.
Not tainted 5.8.0-rc3-next-20200629-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
khugepaged D28584 1160 2 0x4000
Call Trace:
context_switch kernel/sched/core.c:3445 [inline]
__schedule+0x8b4/0x1e80 kernel/sched/core.c:4169
schedule+0xd0/0x2a0 kernel/sched/core.c:4244
schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1873
do_wait_for_common kernel/sched/completion.c:85 [inline]
__wait_for_common kernel/sched/completion.c:106 [inline]
wait_for_common kernel/sched/completion.c:117 [inline]
wait_for_completion+0x163/0x260 kernel/sched/completion.c:138
__flush_work+0x51f/0xab0 kernel/workqueue.c:3046
lru_add_drain_all+0x3ca/0x590 mm/swap.c:808
khugepaged_do_scan mm/khugepaged.c:2177 [inline]
khugepaged+0x10b/0x5a10 mm/khugepaged.c:2238
kthread+0x3b5/0x4a0 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Showing all locks held in the system:
6 locks held by kworker/0:0/5:
1 lock held by khungtaskd/1150:
#0: 89bc3000 (rcu_read_lock){}-{1:2}, at:
debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:5779
1 lock held by khugepaged/1160:
#0: 89c48448 (lock#4){+.+.}-{3:3}, at: lru_add_drain_all+0x59/0x590
mm/swap.c:779
1 lock held by in:imklog/6654:
#0: 8880935425f0 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100
fs/file.c:928
=
NMI backtrace for cpu 1
CPU: 1 PID: 1150 Comm: khungtaskd Not tainted 5.8.0-rc3-next-20200629-syzkaller
#0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x18f/0x20d lib/dump_stack.c:118
nmi_cpu_backtrace.cold+0x70/0xb1 lib/nmi_backtrace.c:101
nmi_trigger_cpumask_backtrace+0x1b3/0x223 lib/nmi_backtrace.c:62
trigger_all_cpu_backtrace include/linux/nmi.h:147 [inline]
check_hung_uninterruptible_tasks kernel/hung_task.c:253 [inline]
watchdog+0xd89/0xf30 kernel/hung_task.c:339
kthread+0x3b5/0x4a0 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.8.0-rc3-next-20200629-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:hid_apply_multiplier drivers/hid/hid-core.c:1106 [inline]
RIP: 0010:hid_setup_resolution_multiplier+0x3a3/0x9b0
drivers/hid/hid-core.c:1163
Code: b6 14 38 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 df 04 00 00
45 8b 74 24 04 bf 02 00 00 00 44 89 f6 e8 6d 62 90 fb <41> 83 fe 02 0f 85 74 ff
ff ff 4c 89 24 24 e8 da 65 90 fb 49 8d 7d
RSP: 0018:c9cbec18 EFLAGS: 0293
RAX: RBX: RCX: 85e38373
RDX: RSI: 8880a9598140 RDI: 0005
RBP: 88809f43e800 R08: 0001 R09: c900015ee0cc
R10: 0002 R11: R12: 88809f43e800
R13: 88808580 R14: R15: dc00
FS: () GS:8880ae60() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 55726aabf328 CR3: a0102000 CR4: 001506f0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
hid_open_report+0x438/0x640 drivers/hid/hid-core.c:1274
hid_parse include/linux/hid.h:1017 [inline]
ms_probe+0x12d/0x4b0 drivers/hid/hid-microsoft.c:388
hid_device_probe+0x2bd/0x3f0 drivers/hid/hid-core.c:2263
really_probe+0x282/0x8a0 drivers/base/dd.c:525
driver_probe_device+0xfe/0x1d0 drivers/base/dd.c:701
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:807
bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431
__device_attach+0x28d/0x3f0 drivers/base/dd.c:873
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
device_add+0xacf/0x1b00 drivers/base/core.c:2680
hid_add_device+0x344/0x9b0 drivers/hid/hid-core.c:2419
usbhid_probe+0xac8/0xff0 drivers/hid/usbhid/hid-core.c:1412
usb_probe_interface+0x2f7/0x780 drivers/usb/core/driver.c:374
really_probe+0x282/0x8a0
Re: [RESEND PATCH v4 3/7] drm/mediatek: mtk_dsi: Rename bridge to next_bridge
Hi, Enric:
Enric Balletbo i Serra 於 2020年6月16日 週二 上午4:31寫道：
>
> This is really a cosmetic change just to make a bit more readable the
> code after convert the driver to drm_bridge. The bridge variable name
> will be used by the encoder drm_bridge, and the chained bridge will be
> named next_bridge.
>
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Laurent Pinchart
> Acked-by: Sam Ravnborg
> Reviewed-by: Chun-Kuang Hu
> ---
>
> Changes in v4: None
> Changes in v3:
> - Replace s/bridge/next bridge/ for comment. (Laurent Pinchart)
>
> Changes in v2: None
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 270bf22c98feb..208f49bf14a01 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -183,7 +183,7 @@ struct mtk_dsi {
> struct drm_encoder encoder;
> struct drm_connector conn;
> struct drm_panel *panel;
> - struct drm_bridge *bridge;
> + struct drm_bridge *next_bridge;
> struct phy *phy;
>
> void __iomem *regs;
> @@ -894,9 +894,10 @@ static int mtk_dsi_create_conn_enc(struct drm_device
> *drm, struct mtk_dsi *dsi)
> */
> dsi->encoder.possible_crtcs = 1;
>
> - /* If there's a bridge, attach to it and let it create the connector
> */
> - if (dsi->bridge) {
> - ret = drm_bridge_attach(&dsi->encoder, dsi->bridge, NULL, 0);
> + /* If there's a next bridge, attach to it and let it create the
> connector */
> + if (dsi->next_bridge) {
> + ret = drm_bridge_attach(&dsi->encoder, dsi->next_bridge, NULL,
> + 0);
> if (ret) {
> DRM_ERROR("Failed to attach bridge to drm\n");
> goto err_encoder_cleanup;
> @@ -1177,7 +1178,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
> }
>
> ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
> - &dsi->panel, &dsi->bridge);
> + &dsi->panel, &dsi->next_bridge);
> if (ret)
> goto err_unregister_host;
>
> --
> 2.27.0
>
Re: [PATCH v2] Replace HTTP links with HTTPS ones: Documentation/devicetree/bindings/iio
On Sat, Jul 4, 2020 at 12:34 PM Alexander A. Klimov wrote: > > Rationale: > Reduces attack surface on kernel devs opening the links for MITM > as HTTPS traffic is much harder to manipulate. > With regards to the drivers that I've authored the changes look good to me. Reviewed-by: Matt Ranostay > Deterministic algorithm: > For each file: > If not .svg: > For each line: > If doesn't contain `\bxmlns\b`: > For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: > If both the HTTP and HTTPS versions > return 200 OK and serve the same content: > Replace HTTP with HTTPS. > > Signed-off-by: Alexander A. Klimov > --- > Changes in v2: > Addressed > https://lore.kernel.org/linux-iio/20200704173459.78ceec60@archlinux/ > > Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml | 4 ++-- > Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt | 2 +- > Documentation/devicetree/bindings/iio/iio-bindings.txt| 2 +- > Documentation/devicetree/bindings/iio/light/apds9300.txt | 2 +- > Documentation/devicetree/bindings/iio/light/apds9960.txt | 2 +- > Documentation/devicetree/bindings/iio/light/opt3001.txt | 2 +- > Documentation/devicetree/bindings/iio/light/vl6180.txt| 2 +- > .../devicetree/bindings/iio/potentiometer/mcp41010.txt| 2 +- > .../devicetree/bindings/iio/potentiostat/lmp91000.txt | 4 ++-- > .../devicetree/bindings/iio/pressure/asc,dlhl60d.yaml | 2 +- > .../devicetree/bindings/iio/proximity/devantech-srf04.yaml| 4 ++-- > 11 files changed, 14 insertions(+), 14 deletions(-) > > diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > index d124eba1ce54..fd4eaa3d0ab4 100644 > --- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml > @@ -12,8 +12,8 @@ maintainers: > description: | >Analog Devices ADXL345/ADXL375 3-Axis Digital Accelerometers that supports >both I2C & SPI interfaces. > -http://www.analog.com/en/products/mems/accelerometers/adxl345.html > - > http://www.analog.com/en/products/sensors-mems/accelerometers/adxl375.html > +https://www.analog.com/en/products/mems/accelerometers/adxl345.html > + > https://www.analog.com/en/products/sensors-mems/accelerometers/adxl375.html > > properties: >compatible: > diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt > b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt > index 639c94ed83e9..17af395b99d9 100644 > --- a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt > +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt > @@ -6,7 +6,7 @@ Is is programmable through an SPI interface. > > The internal DACs are loaded when the LOADDACS pin is pulled down. > > -http://www.ti.com/lit/ds/sbas106/sbas106.pdf > +https://www.ti.com/lit/ds/sbas106/sbas106.pdf > > Required Properties: > - compatible: Should be one of: > diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt > b/Documentation/devicetree/bindings/iio/iio-bindings.txt > index af33267727f4..aa63cac7323e 100644 > --- a/Documentation/devicetree/bindings/iio/iio-bindings.txt > +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt > @@ -9,7 +9,7 @@ specifier is an array of one or more cells identifying the IIO > output on a device. The length of an IIO specifier is defined by the > value of a #io-channel-cells property in the IIO provider node. > > -[1] http://marc.info/?l=linux-iio&m=135902119507483&w=2 > +[1] https://marc.info/?l=linux-iio&m=135902119507483&w=2 > > ==IIO providers== > > diff --git a/Documentation/devicetree/bindings/iio/light/apds9300.txt > b/Documentation/devicetree/bindings/iio/light/apds9300.txt > index aa199e09a493..3aa6db3ee99d 100644 > --- a/Documentation/devicetree/bindings/iio/light/apds9300.txt > +++ b/Documentation/devicetree/bindings/iio/light/apds9300.txt > @@ -1,6 +1,6 @@ > * Avago APDS9300 ambient light sensor > > -http://www.avagotech.com/docs/AV02-1077EN > +https://www.avagotech.com/docs/AV02-1077EN > > Required properties: > > diff --git a/Documentation/devicetree/bindings/iio/light/apds9960.txt > b/Documentation/devicetree/bindings/iio/light/apds9960.txt > index 3af325ad194b..c53ddb81c4aa 100644 > --- a/Documentation/devicetree/bindings/iio/light/apds9960.txt > +++ b/Documentation/devicetree/bindings/iio/light/apds9960.txt > @@ -1,6 +1,6 @@ > * Avago APDS9960 gesture/RGB/ALS/proximity sensor > > -http://www.avagotech.com/docs/AV02-4191EN > +https://www.avagotech.com/docs/AV02-4191EN > > Required properties: > > diff --git a/Documentation/devicetree/bindings/iio/light/opt3001.txt > b/Documentation/devicetree/bindings/iio/light/opt3001.txt > index 47b13eb8f4ec..9e6f2998e751 100644 > --- a/Documentation/devicetree/bindings/iio/light/opt3001.txt > +++ b/Documentation/devicetree/bindings/iio
Re: [PATCH] drm/mediatek: mtk_hdmi: Remove debug messages for function calls
Hi, Enric:
Chun-Kuang Hu 於 2020年5月19日 週二 下午11:13寫道：
>
> Hi, Enric:
>
> Enric Balletbo i Serra 於 2020年5月19日 週二
> 下午5:41寫道：
> >
> > Equivalent information can be nowadays obtained using function tracer
> >
>
> Reviewed-by: Chun-Kuang Hu
Applied to mediatek-drm-fixes [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-fixes
Regards,
Chun-Kuang.
>
> > Signed-off-by: Enric Balletbo i Serra
> > ---
> >
> > drivers/gpu/drm/mediatek/mtk_hdmi.c| 12 +---
> > drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 4
> > 2 files changed, 1 insertion(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > index b0555a7cb3b4..172d67294435 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > @@ -1634,8 +1634,6 @@ static int mtk_hdmi_audio_startup(struct device *dev,
> > void *data)
> > {
> > struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
> >
> > - dev_dbg(dev, "%s\n", __func__);
> > -
> > mtk_hdmi_audio_enable(hdmi);
> >
> > return 0;
> > @@ -1645,8 +1643,6 @@ static void mtk_hdmi_audio_shutdown(struct device
> > *dev, void *data)
> > {
> > struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
> >
> > - dev_dbg(dev, "%s\n", __func__);
> > -
> > mtk_hdmi_audio_disable(hdmi);
> > }
> >
> > @@ -1655,8 +1651,6 @@ mtk_hdmi_audio_digital_mute(struct device *dev, void
> > *data, bool enable)
> > {
> > struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
> >
> > - dev_dbg(dev, "%s(%d)\n", __func__, enable);
> > -
> > if (enable)
> > mtk_hdmi_hw_aud_mute(hdmi);
> > else
> > @@ -1669,8 +1663,6 @@ static int mtk_hdmi_audio_get_eld(struct device *dev,
> > void *data, uint8_t *buf,
> > {
> > struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
> >
> > - dev_dbg(dev, "%s\n", __func__);
> > -
> > memcpy(buf, hdmi->conn.eld, min(sizeof(hdmi->conn.eld), len));
> >
> > return 0;
> > @@ -1770,7 +1762,6 @@ static int mtk_drm_hdmi_probe(struct platform_device
> > *pdev)
> > goto err_bridge_remove;
> > }
> >
> > - dev_dbg(dev, "mediatek hdmi probe success\n");
> > return 0;
> >
> > err_bridge_remove:
> > @@ -1793,7 +1784,7 @@ static int mtk_hdmi_suspend(struct device *dev)
> > struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
> >
> > mtk_hdmi_clk_disable_audio(hdmi);
> > - dev_dbg(dev, "hdmi suspend success!\n");
> > +
> > return 0;
> > }
> >
> > @@ -1808,7 +1799,6 @@ static int mtk_hdmi_resume(struct device *dev)
> > return ret;
> > }
> >
> > - dev_dbg(dev, "hdmi resume success!\n");
> > return 0;
> > }
> > #endif
> > diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > index b55f51675205..1c3575372230 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > @@ -159,8 +159,6 @@ static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
> > {
> > struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> >
> > - dev_dbg(hdmi_phy->dev, "%s\n", __func__);
> > -
> > mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON1, RG_HDMITX_PLL_AUTOK_EN);
> > mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_PLL_POSDIV);
> > mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3, RG_HDMITX_MHLCK_EN);
> > @@ -178,8 +176,6 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
> > {
> > struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> >
> > - dev_dbg(hdmi_phy->dev, "%s\n", __func__);
> > -
> > mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON1,
> > RG_HDMITX_PLL_TXDIV_EN);
> > mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON1,
> > RG_HDMITX_PLL_BIAS_LPF_EN);
> > usleep_range(100, 150);
> > --
> > 2.26.2
> >
