[RESEND][PATCH] ima: Set and clear FMODE_CAN_READ in ima_calc_file_hash()
Commit a1f9b1c0439db ("integrity/ima: switch to using __kernel_read")
replaced the __vfs_read() call in integrity_kernel_read() with
__kernel_read(), a new helper introduced by commit 61a707c543e2a ("fs: add
a __kernel_read helper").
Since the new helper requires that also the FMODE_CAN_READ flag is set in
file->f_mode, this patch saves the original f_mode and sets the flag if the
the file descriptor has the necessary file operation. Lastly, it restores
the original f_mode at the end of ima_calc_file_hash().
Cc: sta...@vger.kernel.org # 5.8.x
Fixes: a1f9b1c0439db ("integrity/ima: switch to using __kernel_read")
Signed-off-by: Roberto Sassu
---
security/integrity/ima/ima_crypto.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/security/integrity/ima/ima_crypto.c
b/security/integrity/ima/ima_crypto.c
index 21989fa0c107..22ed86a0c964 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -537,6 +537,7 @@ int ima_calc_file_hash(struct file *file, struct
ima_digest_data *hash)
loff_t i_size;
int rc;
struct file *f = file;
+ fmode_t saved_mode;
bool new_file_instance = false, modified_mode = false;
/*
@@ -550,7 +551,7 @@ int ima_calc_file_hash(struct file *file, struct
ima_digest_data *hash)
}
/* Open a new file instance in O_RDONLY if we cannot read */
- if (!(file->f_mode & FMODE_READ)) {
+ if (!(file->f_mode & FMODE_READ) || !(file->f_mode & FMODE_CAN_READ)) {
int flags = file->f_flags & ~(O_WRONLY | O_APPEND |
O_TRUNC | O_CREAT | O_NOCTTY | O_EXCL);
flags |= O_RDONLY;
@@ -562,7 +563,10 @@ int ima_calc_file_hash(struct file *file, struct
ima_digest_data *hash)
*/
pr_info_ratelimited("Unable to reopen file for
reading.\n");
f = file;
+ saved_mode = f->f_mode;
f->f_mode |= FMODE_READ;
+ if (likely(file->f_op->read || file->f_op->read_iter))
+ f->f_mode |= FMODE_CAN_READ;
modified_mode = true;
} else {
new_file_instance = true;
@@ -582,7 +586,7 @@ int ima_calc_file_hash(struct file *file, struct
ima_digest_data *hash)
if (new_file_instance)
fput(f);
else if (modified_mode)
- f->f_mode &= ~FMODE_READ;
+ f->f_mode = saved_mode;
return rc;
}
--
2.27.GIT
lib/crypto/blake2s-selftest.c:566:13: warning: no previous prototype for 'blake2s_selftest'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 585e5b17b92dead8a3aca4e3c9876fbca5f7e0ba commit: 66d7fb94e4ffe5acc589e0b2b4710aecc1f07a28 crypto: blake2s - generic C library implementation and selftest date: 12 months ago config: parisc-randconfig-r003-20201113 (attached as .config) compiler: hppa-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=66d7fb94e4ffe5acc589e0b2b4710aecc1f07a28 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 66d7fb94e4ffe5acc589e0b2b4710aecc1f07a28 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=parisc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> lib/crypto/blake2s-selftest.c:566:13: warning: no previous prototype for >> 'blake2s_selftest' [-Wmissing-prototypes] 566 | bool __init blake2s_selftest(void) | ^~~~ vim +/blake2s_selftest +566 lib/crypto/blake2s-selftest.c 565 > 566 bool __init blake2s_selftest(void) --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH] rtc: snvs: Remove NULL pointer check before clk_*
Because clk_* already checked NULL clock parameter,
so the additional checks are unnecessary, just remove them.
Signed-off-by: Xu Wang
---
drivers/rtc/rtc-snvs.c | 67 +++---
1 file changed, 24 insertions(+), 43 deletions(-)
diff --git a/drivers/rtc/rtc-snvs.c b/drivers/rtc/rtc-snvs.c
index 0263d996b8a8..a7d39a49b748 100644
--- a/drivers/rtc/rtc-snvs.c
+++ b/drivers/rtc/rtc-snvs.c
@@ -151,17 +151,14 @@ static int snvs_rtc_read_time(struct device *dev, struct
rtc_time *tm)
unsigned long time;
int ret;
- if (data->clk) {
- ret = clk_enable(data->clk);
- if (ret)
- return ret;
- }
+ ret = clk_enable(data->clk);
+ if (ret)
+ return ret;
time = rtc_read_lp_counter(data);
rtc_time64_to_tm(time, tm);
- if (data->clk)
- clk_disable(data->clk);
+ clk_disable(data->clk);
return 0;
}
@@ -172,11 +169,9 @@ static int snvs_rtc_set_time(struct device *dev, struct
rtc_time *tm)
unsigned long time = rtc_tm_to_time64(tm);
int ret;
- if (data->clk) {
- ret = clk_enable(data->clk);
- if (ret)
- return ret;
- }
+ ret = clk_enable(data->clk);
+ if (ret)
+ return ret;
/* Disable RTC first */
ret = snvs_rtc_enable(data, false);
@@ -190,8 +185,7 @@ static int snvs_rtc_set_time(struct device *dev, struct
rtc_time *tm)
/* Enable RTC again */
ret = snvs_rtc_enable(data, true);
- if (data->clk)
- clk_disable(data->clk);
+ clk_disable(data->clk);
return ret;
}
@@ -202,11 +196,9 @@ static int snvs_rtc_read_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
u32 lptar, lpsr;
int ret;
- if (data->clk) {
- ret = clk_enable(data->clk);
- if (ret)
- return ret;
- }
+ ret = clk_enable(data->clk);
+ if (ret)
+ return ret;
regmap_read(data->regmap, data->offset + SNVS_LPTAR, &lptar);
rtc_time64_to_tm(lptar, &alrm->time);
@@ -214,8 +206,7 @@ static int snvs_rtc_read_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
regmap_read(data->regmap, data->offset + SNVS_LPSR, &lpsr);
alrm->pending = (lpsr & SNVS_LPSR_LPTA) ? 1 : 0;
- if (data->clk)
- clk_disable(data->clk);
+ clk_disable(data->clk);
return 0;
}
@@ -225,11 +216,9 @@ static int snvs_rtc_alarm_irq_enable(struct device *dev,
unsigned int enable)
struct snvs_rtc_data *data = dev_get_drvdata(dev);
int ret;
- if (data->clk) {
- ret = clk_enable(data->clk);
- if (ret)
- return ret;
- }
+ ret = clk_enable(data->clk);
+ if (ret)
+ return ret;
regmap_update_bits(data->regmap, data->offset + SNVS_LPCR,
(SNVS_LPCR_LPTA_EN | SNVS_LPCR_LPWUI_EN),
@@ -237,8 +226,7 @@ static int snvs_rtc_alarm_irq_enable(struct device *dev,
unsigned int enable)
ret = rtc_write_sync_lp(data);
- if (data->clk)
- clk_disable(data->clk);
+ clk_disable(data->clk);
return ret;
}
@@ -249,11 +237,9 @@ static int snvs_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
unsigned long time = rtc_tm_to_time64(&alrm->time);
int ret;
- if (data->clk) {
- ret = clk_enable(data->clk);
- if (ret)
- return ret;
- }
+ ret = clk_enable(data->clk);
+ if (ret)
+ return ret;
regmap_update_bits(data->regmap, data->offset + SNVS_LPCR,
SNVS_LPCR_LPTA_EN, 0);
ret = rtc_write_sync_lp(data);
@@ -264,8 +250,7 @@ static int snvs_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
/* Clear alarm interrupt status bit */
regmap_write(data->regmap, data->offset + SNVS_LPSR, SNVS_LPSR_LPTA);
- if (data->clk)
- clk_disable(data->clk);
+ clk_disable(data->clk);
return snvs_rtc_alarm_irq_enable(dev, alrm->enabled);
}
@@ -285,8 +270,7 @@ static irqreturn_t snvs_rtc_irq_handler(int irq, void
*dev_id)
u32 lpsr;
u32 events = 0;
- if (data->clk)
- clk_enable(data->clk);
+ clk_enable(data->clk);
regmap_read(data->regmap, data->offset + SNVS_LPSR, &lpsr);
@@ -302,8 +286,7 @@ static irqreturn_t snvs_rtc_irq_handler(int irq, void
*dev_id)
/* clear interrupt status */
regmap_write(data->regmap, data->offset + SNVS_LPSR, lpsr);
- if (data->clk)
- clk_disable(data->clk);
+ clk_disable(data->clk);
return events ? IRQ_HANDLED : IRQ_NONE;
}
@@ -316,8 +299,7 @@ static const struct regmap_config snvs_rtc_config = {
static voi
Re: [PATCH] clk-si5341: Support NVM programming through sysfs
Quoting Mike Looijmans (2020-11-05 01:06:54) > On 05-11-2020 02:48, Stephen Boyd wrote: > > Quoting Mike Looijmans (2020-11-03 06:17:41) > >> Export an attribute program_nvm_bank that when read reports the current > >> bank value. To program the chip's current state into NVM, write the > >> magic value 0xC7 into this attribute. > >> > >> Signed-off-by: Mike Looijmans > >> --- > > > > Any chance this can be done through the nvmem framework? > > This part doesn't fit. The purpose is to store the current state of the clock > chip into its non-volatile storage so it boots up with that configuration the > next POR. Main use case is that some vendors initialize PLLs only in a > bootloader and thus need the clock running at boot. Or it might just be to > save on that 300ms initialization time. Can these details be put in the commit text? It would go a long way towards helping reviewers understand the motivation if it is to speed up boot and stash away clk configuration across resets. Why is userspace involved? Why can't the driver write to the non-volatile storage with shutdown or reboot driver hooks instead of implementing a bespoke sysfs ABI? > > Having said that, the clock chip does have some "scratch" areas that'd be > useful as NVMEM storage. That'd be for a separate patch. > > For this device to be NVMEM compatible, nvmem would need to have a sort of > transaction model, where you write several values and then "commit" them all > to NVM in one call. The nvmem framework wasn't intended for that I think. I suppose patches could be written to support that if desired.
Re: [PATCH 06/19] elf/vdso: Reuse arch_setup_additional_pages() parameters
Hi Dmitry,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on c34f157421f6905e6b4a79a312e9175dce2bc607]
url:
https://github.com/0day-ci/linux/commits/Dmitry-Safonov/Add-generic-user_landing-tracking/20201109-090354
base:c34f157421f6905e6b4a79a312e9175dce2bc607
config: riscv-allmodconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/04586680978b048abe74dd892c5b1fcde7c486a3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Dmitry-Safonov/Add-generic-user_landing-tracking/20201109-090354
git checkout 04586680978b048abe74dd892c5b1fcde7c486a3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from include/linux/elf.h:6,
from arch/riscv/kernel/vdso.c:9:
arch/riscv/include/asm/elf.h:8: error: unterminated #ifndef
8 | #ifndef _ASM_RISCV_ELF_H
|
arch/riscv/kernel/vdso.c: In function 'arch_setup_additional_pages':
>> arch/riscv/kernel/vdso.c:62:27: warning: variable 'vvar_base' set but not
>> used [-Wunused-but-set-variable]
62 | unsigned long vdso_base, vvar_base, vdso_len;
| ^
vim +/vvar_base +62 arch/riscv/kernel/vdso.c
> 9 #include
10 #include
11 #include
12 #include
13 #include
14 #include
15 #ifdef GENERIC_TIME_VSYSCALL
16 #include
17 #else
18 #include
19 #endif
20
21 extern char vdso_start[], vdso_end[];
22
23 static unsigned int vdso_pages;
24 static struct page **vdso_pagelist;
25
26 /*
27 * The vDSO data page.
28 */
29 static union {
30 struct vdso_datadata;
31 u8 page[PAGE_SIZE];
32 } vdso_data_store __page_aligned_data;
33 struct vdso_data *vdso_data = &vdso_data_store.data;
34
35 static int __init vdso_init(void)
36 {
37 unsigned int i;
38
39 vdso_pages = (vdso_end - vdso_start) >> PAGE_SHIFT;
40 vdso_pagelist =
41 kcalloc(vdso_pages + 1, sizeof(struct page *),
GFP_KERNEL);
42 if (unlikely(vdso_pagelist == NULL)) {
43 pr_err("vdso: pagelist allocation failed\n");
44 return -ENOMEM;
45 }
46
47 for (i = 0; i < vdso_pages; i++) {
48 struct page *pg;
49
50 pg = virt_to_page(vdso_start + (i << PAGE_SHIFT));
51 vdso_pagelist[i] = pg;
52 }
53 vdso_pagelist[i] = virt_to_page(vdso_data);
54
55 return 0;
56 }
57 arch_initcall(vdso_init);
58
59 int arch_setup_additional_pages(unsigned long *sysinfo_ehdr)
60 {
61 struct mm_struct *mm = current->mm;
> 62 unsigned long vdso_base, vvar_base, vdso_len;
63 int ret;
64
65 vdso_len = (vdso_pages + 1) << PAGE_SHIFT;
66
67 mmap_write_lock(mm);
68 vdso_base = get_unmapped_area(NULL, 0, vdso_len, 0, 0);
69 if (IS_ERR_VALUE(vdso_base)) {
70 ret = vdso_base;
71 goto end;
72 }
73
74 /*
75 * Put vDSO base into mm struct. We need to do this before
calling
76 * install_special_mapping or the perf counter mmap tracking
code
77 * will fail to recognise it as a vDSO (since arch_vma_name
fails).
78 */
79 mm->context.vdso = (void *)vdso_base;
80
81 ret =
82 install_special_mapping(mm, vdso_base, vdso_pages <<
PAGE_SHIFT,
83 (VM_READ | VM_EXEC | VM_MAYREAD | VM_MAYWRITE |
VM_MAYEXEC),
84 vdso_pagelist);
85
86 if (unlikely(ret)) {
87 mm->context.vdso = NULL;
88 goto end;
89 }
90
91 vvar_base = vdso_base + (vdso_pages << PAGE_SHIFT);
92 ret = install_special_mapping(mm, vdso_base, PAGE_SIZE,
93 (VM_READ | VM_MAYREAD), &vdso_pagelist[vdso_pages]);
94
95 if (unlikely(ret))
96 mm->context.vdso = NULL;
97 else
98 *sysinfo_ehdr = vdso_base;
99 end:
100 mmap_write_unlock(mm);
101 retur
Re: [PATCH v5 5/5] objtool: Rework header include paths
On Fri, Nov 13, 2020 at 12:03:32AM +0100, Vasily Gorbik wrote: > Currently objtool headers are being included either by their base name > or included via ../ from a parent directory. In case of a base name usage: > > #include "warn.h" > #include "arch_elf.h" > > it does not make it apparent from which directory the file comes from. > To make it slightly better, and actually to avoid name clashes some arch > specific files have "arch_" suffix. And files from an arch folder have > to revert to including via ../ e.g: > #include "../../elf.h" > > With additional architectures support and the code base growth there is > a need for clearer headers naming scheme for multiple reasons: > 1. to make it instantly obvious where these files come from (objtool >itself / objtool arch|generic folders / some other external files), > 2. to avoid name clashes of objtool arch specific headers, potential >obtool arch generic headers and the system header files (there is >/usr/include/elf.h already), > 3. to avoid ../ includes and improve code readability. > 4. to give a warm fuzzy feeling to developers who are mostly kernel >developers and are accustomed to linux kernel headers arranging >scheme. > > Doesn't this make it instantly obvious where are these files come from? > > #include > #include > > And doesn't it look nicer to avoid ugly ../ includes? Which also > guarantees this is elf.h from the objtool and not /usr/include/elf.h. > > #include > > This patch defines and implements new objtool headers arranging > scheme. Which is: > - all generic headers go to include/objtool (similar to include/linux) > - all arch headers go to arch/$(SRCARCH)/include/arch (to get arch > prefix). This is similar to linux arch specific "asm/*" headers but we > are not abusing "asm" name and calling it what it is. This also helps > to prevent name clashes (arch is not used in system headers or kernel > exports). > > To bring objtool to this state the following things are done: > 1. current top level tools/objtool/ headers are moved into >include/objtool/ subdirectory, > 2. arch specific headers, currently only arch/x86/include/ are moved into >arch/x86/include/arch/ and were stripped of "arch_" suffix, > 3. new -I$(srctree)/tools/objtool/include include path to make >includes like possible, > 4. rewriting file includes, > 5. make git not to ignore include/objtool/ subdirectory. > > Signed-off-by: Vasily Gorbik Nice! For the whole series: Acked-by: Peter Zijlstra (Intel)
Re: [PATCH 0/3 v6] ftrace: Add access to function arguments for all callbacks
On Thu, Nov 12, 2020 at 09:01:42PM -0500, Steven Rostedt wrote: > Steven Rostedt (VMware) (3): > ftrace: Have the callbacks receive a struct ftrace_regs instead of > pt_regs > ftrace/x86: Allow for arguments to be passed in to ftrace_regs by > default > livepatch: Use the default ftrace_ops instead of REGS when ARGS is > available Acked-by: Peter Zijlstra (Intel)
Re: [PATCH] ACPICA: fix -Wfallthrough
On Thu, Nov 12, 2020 at 10:49 PM Moore, Robert wrote: > > 1>c:\acpica\source\components\utilities\utdelete.c(270): warning C4013: > '__attribute__' undefined; assuming extern returning int > 1>c:\acpica\source\components\utilities\utdelete.c(270): error C2065: > '__fallthrough__': undeclared identifier > 1>c:\acpica\source\components\utilities\utdelete.c(272): error C2143: syntax > error: missing ';' before 'case' Can you share a minimized sample with the `cl` version and command-line options? Cheers, Miguel
Re: [PATCH] perf vendor events: Update Skylake client events to v50
Hi Andi, Ian,
On 11/6/2020 12:21 PM, Namhyung Kim wrote:
On Fri, Nov 6, 2020 at 12:12 PM Jin, Yao wrote:
Hi Namhyung,
On 11/6/2020 11:00 AM, Namhyung Kim wrote:
Hi,
On Wed, Nov 04, 2020 at 09:51:02AM +0800, Jin Yao wrote:
- Update Skylake events to v50.
- Update Skylake JSON metrics from TMAM 4.0.
- Fix the issue in DRAM_Parallel_Reads
- Fix the perf test warning
Before:
root@kbl-ppc:~# perf stat -M DRAM_Parallel_Reads -- sleep 1
event syntax error:
'{arb/event=0x80,umask=0x2/,arb/event=0x80,umask=0x2,thresh=1/}:W'
\___ unknown term 'thresh' for pmu 'uncore_arb'
valid terms:
event,edge,inv,umask,cmask,config,config1,config2,name,period,percore
Initial error:
event syntax error: '..umask=0x2/,arb/event=0x80,umask=0x2,thresh=1/}:W'
\___ Cannot find PMU `arb'. Missing kernel
support?
root@kbl-ppc:~# perf test metrics
10: PMU events :
10.3: Parsing of PMU event table metrics : Skip (some metrics
failed)
10.4: Parsing of PMU event table metrics with fake PMUs: Ok
67: Parse and process metrics : Ok
After:
root@kbl-ppc:~# perf stat -M MEM_Parallel_Reads -- sleep 1
Performance counter stats for 'system wide':
4,951,646 arb/event=0x80,umask=0x2/ #26.30
MEM_Parallel_Reads (50.04%)
188,251 arb/event=0x80,umask=0x2,cmask=1/
(49.96%)
1.000867010 seconds time elapsed
root@kbl-ppc:~# perf test metrics
10: PMU events :
10.3: Parsing of PMU event table metrics : Ok
10.4: Parsing of PMU event table metrics with fake PMUs: Ok
67: Parse and process metrics : Ok
Signed-off-by: Jin Yao
It seems not applied to acme/perf/core cleanly.
Thanks,
Namhyung
It seems the patch mail is truncated. :(
I attach the patch file in the mail. Sorry for inconvenience.
I've checked it fixed the perf test on my laptop (skylake).
Tested-by: Namhyung Kim
Thanks,
Namhyung
Can I get ACK for this patch?
It's mainly for fixing the perf-test issue and MEM_Parallel_Reads issue.
Thanks
Jin Yao
Re: [PATCH v2] clk: mediatek: fix mtk_clk_register_mux() as static function
"Fix" is a little strong. Maybe the subject should just be "Make
mtk_clk_register_mux() a static function".
Quoting Weiyi Lu (2020-11-10 18:33:56)
> mtk_clk_register_mux() should be a static function
>
> Fixes: a3ae549917f16 ("clk: mediatek: Add new clkmux register API")
[PATCH] dmaengine: ioatdma: remove unused function missed during dma_v2 removal
Commit 7f832645d0e5 ("dmaengine: ioatdma: remove ioatdma v2 registration")
missed to remove dca2_tag_map_valid() during its removal. Hence, since
then, dca2_tag_map_valid() is unused and make CC=clang W=1 warns:
drivers/dma/ioat/dca.c:44:19:
warning: unused function 'dca2_tag_map_valid' [-Wunused-function]
So, remove this unused function and get rid of a -Wused-function warning.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on current master and next-20201112
Maciej, please ack.
Vinod, Dan, please pick this minor non-urgent clean-up patch.
drivers/dma/ioat/dca.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/dma/ioat/dca.c b/drivers/dma/ioat/dca.c
index 0be385587c4c..289c59ed74b9 100644
--- a/drivers/dma/ioat/dca.c
+++ b/drivers/dma/ioat/dca.c
@@ -40,16 +40,6 @@
#define DCA2_TAG_MAP_BYTE3 0x82
#define DCA2_TAG_MAP_BYTE4 0x82
-/* verify if tag map matches expected values */
-static inline int dca2_tag_map_valid(u8 *tag_map)
-{
- return ((tag_map[0] == DCA2_TAG_MAP_BYTE0) &&
- (tag_map[1] == DCA2_TAG_MAP_BYTE1) &&
- (tag_map[2] == DCA2_TAG_MAP_BYTE2) &&
- (tag_map[3] == DCA2_TAG_MAP_BYTE3) &&
- (tag_map[4] == DCA2_TAG_MAP_BYTE4));
-}
-
/*
* "Legacy" DCA systems do not implement the DCA register set in the
* I/OAT device. Software needs direct support for their tag mappings.
--
2.17.1
Re: [PATCH] ACPICA: fix -Wfallthrough
On Fri, Nov 13, 2020 at 1:09 AM Nick Desaulniers wrote: > > Thank you for the explicit diagnostics observed. Something fishy is > going on though, https://godbolt.org/z/Gbxbxa is how I expect MSVC to > handle include/linux/compiler_attributes.h. > > The C preprocessor should make it such that MSVC never sees > `__attribute__` or `__fallthrough__`; that it does begs the question. > That would seem to imply that `#if __has_attribute(__fallthrough__)` > somehow evaluates to true on MSVC, but my godbolt link shows it does > not. > > Could the upstream ACPICA project be #define'ing something that could > be altering this? (Or not #define'ing something?) > > Worst case, we could do as Joe Perches suggested and disable > -Wfallthrough for drivers/acpi/acpica/. I agree, something is fishy. MSVC has several flags for conformance and extensions support, including two full C preprocessors in newer versions; which means we might be missing something, but I don't see how the code in compiler_attributes.h could be confusing MSVC even in older non-conforming versions. Cheers, Miguel
Re: [PATCH] net: ethernet: ti: cpsw: fix cpts irq after suspend
* Grygorii Strashko [201112 11:15]:
> Depending on the SoC/platform the CPSW can completely lose context after a
> suspend/resume cycle, including CPSW wrapper (WR) which will cause reset of
> WR_C0_MISC_EN register, so CPTS IRQ will became disabled.
>
> Fix it by moving CPTS IRQ enabling in cpsw_ndo_open() where CPTS is
> actually started.
>
> Fixes: 84ea9c0a95d7 ("net: ethernet: ti: cpsw: enable cpts irq")
> Reported-by: Tony Lindgren
> Signed-off-by: Grygorii Strashko
Thanks this works for me:
Tested-by: Tony Lindgren
Re: [PATCH net-next 00/18] net: phy: add support for shared interrupts (part 2)
On Thu, Nov 12, 2020 at 06:19:10PM -0800, Jakub Kicinski wrote: > On Thu, 12 Nov 2020 17:54:55 +0200 Ioana Ciornei wrote: > > From: Ioana Ciornei > > > > This patch set aims to actually add support for shared interrupts in > > phylib and not only for multi-PHY devices. While we are at it, > > streamline the interrupt handling in phylib. > > Ioana, would you mind resending? Looks like the kernel.org patchwork > instance is way less reliable at piecing series together :( No problem, I'll resend. So from now on we'll be using the kernel.org patchwork only, right? I am asking this because from what I can tell the ozlabs patchwork was not updated in the last days. Ioana
Re: [PATCH v2] cpuset: fix race between hotplug work and later CPU offline
On Thu, Nov 12, 2020 at 12:17:11PM -0500, Daniel Jordan wrote:
> One of our machines keeled over trying to rebuild the scheduler domains.
> Mainline produces the same splat:
>
> BUG: unable to handle page fault for address: 607f820054db
> CPU: 2 PID: 149 Comm: kworker/1:1 Not tainted 5.10.0-rc1-master+ #6
> Workqueue: events cpuset_hotplug_workfn
> RIP: build_sched_domains
> Call Trace:
>partition_sched_domains_locked
>rebuild_sched_domains_locked
>cpuset_hotplug_workfn
>
> It happens with cgroup2 and exclusive cpusets only. This reproducer
> triggers it on an 8-cpu vm and works most effectively with no
> preexisting child cgroups:
>
> cd $UNIFIED_ROOT
> mkdir cg1
> echo 4-7 > cg1/cpuset.cpus
> echo root > cg1/cpuset.cpus.partition
>
> # with smt/control reading 'on',
> echo off > /sys/devices/system/cpu/smt/control
>
> RIP maps to
>
> sd->shared = *per_cpu_ptr(sdd->sds, sd_id);
>
> from sd_init(). sd_id is calculated earlier in the same function:
>
> cpumask_and(sched_domain_span(sd), cpu_map, tl->mask(cpu));
> sd_id = cpumask_first(sched_domain_span(sd));
>
> tl->mask(cpu), which reads cpu_sibling_map on x86, returns an empty mask
> and so cpumask_first() returns >= nr_cpu_ids, which leads to the bogus
> value from per_cpu_ptr() above.
>
> The problem is a race between cpuset_hotplug_workfn() and a later
> offline of CPU N. cpuset_hotplug_workfn() updates the effective masks
> when N is still online, the offline clears N from cpu_sibling_map, and
> then the worker uses the stale effective masks that still have N to
> generate the scheduling domains, leading the worker to read
> N's empty cpu_sibling_map in sd_init().
>
> rebuild_sched_domains_locked() prevented the race during the cgroup2
> cpuset series up until the Fixes commit changed its check. Make the
> check more robust so that it can detect an offline CPU in any exclusive
> cpuset's effective mask, not just the top one.
>
> Fixes: 0ccea8feb980 ("cpuset: Make generate_sched_domains() work with
> partition")
> Signed-off-by: Daniel Jordan
> Cc: Johannes Weiner
> Cc: Li Zefan
> Cc: Peter Zijlstra
> Cc: Prateek Sood
> Cc: Tejun Heo
> Cc: Waiman Long
> Cc: cgro...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org
Works for me. TJ, do I take this or do you want it in the cgroup tree?
In that case:
Acked-by: Peter Zijlstra (Intel)
Re: Regression: QCA6390 fails with "mm/page_alloc: place pages to tail in __free_pages_core()"
Op 12.11.2020 om 11:48 schreef David Hildenbrand:
Trying to understand the code, it looks like there are always two rounds of reqests. The first one always fails
("requesting one big chunk of DMA memory"), the second one (providing multiple chunks of DMA memory) is supposed to work
- and we do allocate memory.
In the *working* cases we have
Respond mem req failed, result: 1, err: 0
qmi failed to respond fw mem req:-22
...
chip_id 0x0 chip_family 0xb board_id 0xff soc_id 0x
We don't fail in qmi_txn_wait() - second request w
In the *non-working* cases we have
Respond mem req failed, result: 1, err: 0
qmi failed to respond fw mem req:-22
...
qmi failed memory request, err = -110
qmi failed to respond fw mem req:-110
We fail in qmi_txn_wait(). We run into a timeout (ETIMEDOUT).
Can we bump up the timeout limit and see if things change? Maybe FW needs more
time with other addresses.
I tried increasing ATH11K_QMI_WLANFW_TIMEOUT_MS 20 times to 10 (i.e. 100 seconds) and it didn't have any positive
effect, the second error (-110) just came 100 seconds later and not 5.
Re: [PATCH] sched/fair: Fix overutilized update in enqueue_task_fair()
On Thu, Nov 12, 2020 at 11:12:01AM +, Quentin Perret wrote:
> enqueue_task_fair() attempts to skip the overutilized update for new
> tasks as their util_avg is not accurate yet. However, the flag we check
> to do so is overwritten earlier on in the function, which makes the
> condition pretty much a nop.
>
> Fix this by saving the flag early on.
>
> Fixes: 2802bf3cd936 ("sched/fair: Add over-utilization/tipping point
> indicator")
Fix that wrapping for you :-)
> Reported-by: Rick Yiu
> Signed-off-by: Quentin Perret
Thanks!
Re: [PATCH v1] clk: Add enable-state column to clk summary
Quoting Dmitry Osipenko (2020-11-04 08:56:31) > Add "enable state" column to the clk summary. It's handy to know actual > hardware state of all clocks for debugging purposes. In conjunction with > clk_ignore_unused, this tells us what unused clocks are left on after > bootloader without disabling the clocks. Should it be called "boot state" then? That idea sounds OK to me. > It's also s useful debugging Stray 's' here. > information for cases where firmware touches clocks. Care to explain more? Presumably you mean when firmware is modifying clk state without notifying the kernel? In which case it should be called "hardware enable" or something like that and be a "Y/N/?" value depending on if the value can be read or not and if it is enabled or not? > > Signed-off-by: Dmitry Osipenko
Re: [PATCH] sched/core: trivial: Fix typos in comments
On Thu, Nov 12, 2020 at 07:51:56PM -0500, Tal Zussman wrote: I'm not much for patches like this, but I'll take it. Thanks!
Re: [PATCH] MIPS: Loongson64: Add read_persistent_clock64()
于 2020年11月13日 GMT+08:00 上午11:41:01, Tiezhu Yang 写到: >On 11/13/2020 10:21 AM, Jiaxun Yang wrote: >> >> >> 在 2020/11/12 20:03, Tiezhu Yang 写道: >>> On 11/12/2020 06:09 PM, Jiaxun Yang wrote: 在 2020/11/12 18:04, Jiaxun Yang 写道: > Hi Tiezhu, > > 在 2020/11/12 16:29, Tiezhu Yang 写道: >> Add read_persistent_clock64() to read the time from the battery >> backed >> persistent clock. With this patch, we can fix the wrong time issue >> due >> to the system clock is not consistent with hardware clock after >> resume >> from sleep state S3 (suspend to RAM), at the same time, the system >> time >> can be right instead of "Thu Jan 1 08:00:00 CST 1970" without rtc >> driver. >> >> start_kernel() >>timekeeping_init() >> read_persistent_wall_and_boot_offset() >>read_persistent_clock64() >> >> timekeeping_resume() >>read_persistent_clock64() >> >> timekeeping_suspend() >>read_persistent_clock64() > > It is highly discoraged to do anything with bridgetype, which isn't > probed via > devicetree. > > Please check if you can deal with that inside RTC framework, or > make it as > a part of RTC driver (e.g. set up a callback). > > Also you should submit RTC driver at first if you intend to > complete LS7A support. Oops, Just dig it deeper, I guess simply select RTC_HCTOSYS would solve the issue. We're trying very hard to decouple all the drivers and conponents, DeviceTree for all! >>> >>> +cc WANG Xuerui >>> >>> Hi Jiaxun, >>> >>> Thanks for your reply. >>> >>> Xuerui has already submitted the patch of LS7A rtc driver [1], >>> but not yet been merged into the mainline kernel, I discussed >>> with him early today. >>> >>> Do you mean that read_persistent_clock64() can call the function >>> like rtc_read_time() defined in rtc driver? >> >> I do think select RTC_HCTOSYS after getting RTC driver applied can help. > >Yes, I agree. > >> What's your point to have read_persistent_clock64 for Loongson64? > >(1) Currently, the LS7A RTC driver has not been merged into the >mainline kernel, read_persistent_clock64() is useful in the following >call path: > >start_kernel() >timekeeping_init() > read_persistent_wall_and_boot_offset() >read_persistent_clock64() > >(2) When the LS7A RTC driver is merged into the mainline kernel >some time later, if RTC_HCTOSYS and RTC_DRV_LS2X are not set, >read_persistent_clock64() is also useful unless RTC_HCTOSYS >and RTC_DRV_LS2X are set by default in Kconfig instead of >loongson3_defconfig. > >So I think read_persistent_clock64() looks like a backup function. Still can't understand why this kind of backup is necessary. If you wish to help please help with the RTC driver. Duplication is not the way we work. Please try to learn common solutions, all others are doing so. Thanks - Jiaxun > >> >> Thanks >> >> - Jiaxun >> >>> >>> Thanks, >>> Tiezhu >>> >>> [1] >>> https://patchwork.kernel.org/project/linux-mips/patch/20200923075845.360974-2-...@xen0n.name/ >>> > > Thanks. > > - Jiaxun > >> >> Signed-off-by: Yinglu Yang >> Signed-off-by: Tiezhu Yang >> --- >>
Re: [PATCH v3 1/2] dt-bindings: spmi: document binding for the Mediatek SPMI controller
Quoting Hsin-Hsiung Wang (2020-10-15 05:59:07)
> This adds documentation for the SPMI controller found on Mediatek SoCs.
>
> Signed-off-by: Hsin-Hsiung Wang
I don't know what's going on but my MUA sees a bunch of CRLF line
endings in these patches.
> diff --git a/Documentation/devicetree/bindings/spmi/spmi-mtk-pmif.yaml
> b/Documentation/devicetree/bindings/spmi/spmi-mtk-pmif.yaml
> new file mode 100644
> index ..39459ca2e0da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spmi/spmi-mtk-pmif.yaml
> @@ -0,0 +1,71 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spmi/spmi-mtk-pmif.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek SPMI Controller Device Tree Bindings
> +
> +maintainers:
> + - Stephen Boyd
> + - Matthias Brugger
Is there someone at mediatek who can be the maintainer of this binding?
> +
> +description: |+
What's up with the plus?
> + On MediaTek SoCs the PMIC is connected via SPMI and the controller allows
> + for multiple SoCs to control a single SPMI master.
> +
> +properties:
> + compatible:
> +const: mediatek,mt6873-spmi
> +
> + reg:
> +minItems: 2
> +maxItems: 2
> +
> + reg-names:
> +items:
> + - const: "pmif"
> + - const: "spmimst"
> +
> + clocks:
> +minItems: 3
> +maxItems: 3
> +
> + clock-names:
> +items:
> + - const: "pmif_sys_ck"
> + - const: "pmif_tmr_ck"
> + - const: "spmimst_clk_mux"
> +
> + assigned-clocks:
> +maxItems: 1
> +
> + assigned-clock-parents:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
Is reg-names really required?
> + - clocks
> + - clock-names
I think we need additionalProperties: False here
> +
> +examples:
> + - |
> +#include
> +
> +spmi: spmi@10027000 {
> +compatible = "mediatek,mt6873-spmi";
> +reg = <0 0x10027000 0 0x000e00>,
> + <0 0x10029000 0 0x000100>;
I think we can drop the two cells and just have one cell binding here?
> +reg-names = "pmif", "spmimst";
> +clocks = <&infracfg CLK_INFRA_PMIC_AP>,
> + <&infracfg CLK_INFRA_PMIC_TMR>,
> + <&topckgen CLK_TOP_SPMI_MST_SEL>;
> +clock-names = "pmif_sys_ck",
> + "pmif_tmr_ck",
> + "spmimst_clk_mux";
> +assigned-clocks = <&topckgen CLK_TOP_PWRAP_ULPOSC_SEL>;
> +assigned-clock-parents = <&topckgen CLK_TOP_OSC_D10>;
> +};
> +...
Re: [PATCH 7/7] usb: musb: convert to devm_platform_ioremap_resource_byname
On Thu, 2020-11-12 at 15:08 +0100, Geert Uytterhoeven wrote:
> Hi Chunfeng,
>
> On Wed, Jul 22, 2020 at 9:54 AM Chunfeng Yun
> wrote:
> > Use devm_platform_ioremap_resource_byname() to simplify code
> >
> > Cc: Bin Liu
> > Signed-off-by: Chunfeng Yun
>
> Thanks for your patch, which is now commit 2d30e408a2a6b344 ("usb: musb:
> convert to devm_platform_ioremap_resource_byname") in v5.9.
>
> > --- a/drivers/usb/musb/musb_dsps.c
> > +++ b/drivers/usb/musb/musb_dsps.c
> > @@ -429,12 +429,10 @@ static int dsps_musb_init(struct musb *musb)
> > struct platform_device *parent = to_platform_device(dev->parent);
> > const struct dsps_musb_wrapper *wrp = glue->wrp;
> > void __iomem *reg_base;
> > - struct resource *r;
> > u32 rev, val;
> > int ret;
> >
> > - r = platform_get_resource_byname(parent, IORESOURCE_MEM, "control");
> > - reg_base = devm_ioremap_resource(dev, r);
> > + reg_base = devm_platform_ioremap_resource_byname(parent, "control");
> > if (IS_ERR(reg_base))
> > return PTR_ERR(reg_base);
> > musb->ctrl_base = reg_base;
>
> On Beaglebone Black, where each interface has 2 children:
>
> musb-dsps 47401c00.usb: can't request region for resource [mem
> 0x47401800-0x474019ff]
> musb-hdrc musb-hdrc.1: musb_init_controller failed with status -16
> musb-hdrc: probe of musb-hdrc.1 failed with error -16
> musb-dsps 47401400.usb: can't request region for resource [mem
> 0x47401000-0x474011ff]
> musb-hdrc musb-hdrc.0: musb_init_controller failed with status -16
> musb-hdrc: probe of musb-hdrc.0 failed with error -16
>
> Before, devm_ioremap_resource() was called on "dev" ("musb-hdrc.0" or
> "musb-hdrc.1"), after it is called on "&pdev->dev" ("47401400.usb" or
> "47401c00.usb"), leading to a duplicate region request, which fails.
>
My bad, I didn't notice that, thanks a lot.
And sorry, I missed your message
> I have sent a revert:
> https://lore.kernel.org/linux-usb/20201112135900.3822599-1-geert+rene...@glider.be/
>
> Gr{oetje,eeting}s,
>
> Geert
>
Re: kernel panic: stack is corrupted in get_kernel_gp_address
syzbot suspects this issue was fixed by commit: commit a49145acfb975d921464b84fe00279f99827d816 Author: George Kennedy Date: Tue Jul 7 19:26:03 2020 + fbmem: add margin check to fb_check_caps() bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10ff757250 start commit: f4d51dff Linux 5.9-rc4 git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=a9075b36a6ae26c9 dashboard link: https://syzkaller.appspot.com/bug?extid=d6459d8f8984c0929e54 userspace arch: i386 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=164270dd90 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: fbmem: add margin check to fb_check_caps() For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH] iio: adc: stm32-adc: adapt clock duty cycle for proper operation
On 11/8/20 4:18 PM, Jonathan Cameron wrote:
> On Fri, 6 Nov 2020 17:57:26 +0100
> Fabrice Gasnier wrote:
>
>> For proper operation, STM32 ADC should be used with a clock duty cycle
>> of 50%, in the range of 49% to 51%. Depending on the clock tree, divider
>> can be used in case clock duty cycle is out of this range.
>> In case clk_get_scaled_duty_cycle() returns an error, kindly apply a
>> divider by default (don't make the probe fail).
>>
>> Signed-off-by: Fabrice Gasnier
> Hi Fabrice,
>
> This sounds like it's a fix for a situation in which the device is not
> currently working? If so, please let me know a fixes tag.
Hi Jonathan,
That's a good point. I also thought about adding a fixes tag. Currently
I think this can't be hit upstream, as clock tree is tuned to fit duty
cycle constraints. So far, nobody seems to complain about it. So this
can probably go through the normal tree.
Thanks,
Fabrice
>
> Thanks,
>
> Jonathan
>
>> ---
>> drivers/iio/adc/stm32-adc-core.c | 21 -
>> 1 file changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iio/adc/stm32-adc-core.c
>> b/drivers/iio/adc/stm32-adc-core.c
>> index cd870c0..d64a9e8 100644
>> --- a/drivers/iio/adc/stm32-adc-core.c
>> +++ b/drivers/iio/adc/stm32-adc-core.c
>> @@ -202,7 +202,7 @@ static int stm32h7_adc_clk_sel(struct platform_device
>> *pdev,
>> {
>> u32 ckmode, presc, val;
>> unsigned long rate;
>> -int i, div;
>> +int i, div, duty;
>>
>> /* stm32h7 bus clock is common for all ADC instances (mandatory) */
>> if (!priv->bclk) {
>> @@ -226,6 +226,11 @@ static int stm32h7_adc_clk_sel(struct platform_device
>> *pdev,
>> return -EINVAL;
>> }
>>
>> +/* If duty is an error, kindly use at least /2 divider */
>> +duty = clk_get_scaled_duty_cycle(priv->aclk, 100);
>> +if (duty < 0)
>> +dev_warn(&pdev->dev, "adc clock duty: %d\n", duty);
>> +
>> for (i = 0; i < ARRAY_SIZE(stm32h7_adc_ckmodes_spec); i++) {
>> ckmode = stm32h7_adc_ckmodes_spec[i].ckmode;
>> presc = stm32h7_adc_ckmodes_spec[i].presc;
>> @@ -234,6 +239,13 @@ static int stm32h7_adc_clk_sel(struct platform_device
>> *pdev,
>> if (ckmode)
>> continue;
>>
>> +/*
>> + * For proper operation, clock duty cycle range is 49%
>> + * to 51%. Apply at least /2 prescaler otherwise.
>> + */
>> +if (div == 1 && (duty < 49 || duty > 51))
>> +continue;
>> +
>> if ((rate / div) <= priv->max_clk_rate)
>> goto out;
>> }
>> @@ -246,6 +258,10 @@ static int stm32h7_adc_clk_sel(struct platform_device
>> *pdev,
>> return -EINVAL;
>> }
>>
>> +duty = clk_get_scaled_duty_cycle(priv->bclk, 100);
>> +if (duty < 0)
>> +dev_warn(&pdev->dev, "bus clock duty: %d\n", duty);
>> +
>> for (i = 0; i < ARRAY_SIZE(stm32h7_adc_ckmodes_spec); i++) {
>> ckmode = stm32h7_adc_ckmodes_spec[i].ckmode;
>> presc = stm32h7_adc_ckmodes_spec[i].presc;
>> @@ -254,6 +270,9 @@ static int stm32h7_adc_clk_sel(struct platform_device
>> *pdev,
>> if (!ckmode)
>> continue;
>>
>> +if (div == 1 && (duty < 49 || duty > 51))
>> +continue;
>> +
>> if ((rate / div) <= priv->max_clk_rate)
>> goto out;
>> }
>
Re: [PATCH] [v2] i2c: stm32f7: Fix runtime PM imbalance on error
Hello
Looks good to me
Reviewed-by: Pierre-Yves MORDRET
Thx
Regards
On 6/1/20 7:56 AM, Alain Volmat wrote:
> Hi,
>
> Reviewed-by: Alain Volmat
>
> Thanks,
> Alain
>
> On Wed, May 27, 2020 at 01:38:53AM +, Dinghao Liu wrote:
>> pm_runtime_get_sync() increments the runtime PM usage counter even
>> the call returns an error code. Thus a pairing decrement is needed
>> on the error handling path to keep the counter balanced.
>>
>> Signed-off-by: Dinghao Liu
>> ---
>>
>> Changelog:
>>
>> v2: - Use pm_runtime_put_noidle() instead of
>> pm_runtime_put_autosuspend(). Fix 5 more
>> similar cases within this dirver.
>> ---
>> drivers/i2c/busses/i2c-stm32f7.c | 24 ++--
>> 1 file changed, 18 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-stm32f7.c
>> b/drivers/i2c/busses/i2c-stm32f7.c
>> index 330ffed011e0..822fd1f5b5ae 100644
>> --- a/drivers/i2c/busses/i2c-stm32f7.c
>> +++ b/drivers/i2c/busses/i2c-stm32f7.c
>> @@ -1620,8 +1620,10 @@ static int stm32f7_i2c_xfer(struct i2c_adapter
>> *i2c_adap,
>> f7_msg->smbus = false;
>>
>> ret = pm_runtime_get_sync(i2c_dev->dev);
>> -if (ret < 0)
>> +if (ret < 0) {
>> +pm_runtime_put_noidle(i2c_dev->dev);
>> return ret;
>> +}
>>
>> ret = stm32f7_i2c_wait_free_bus(i2c_dev);
>> if (ret)
>> @@ -1666,8 +1668,10 @@ static int stm32f7_i2c_smbus_xfer(struct i2c_adapter
>> *adapter, u16 addr,
>> f7_msg->smbus = true;
>>
>> ret = pm_runtime_get_sync(dev);
>> -if (ret < 0)
>> +if (ret < 0) {
>> +pm_runtime_put_noidle(dev);
>> return ret;
>> +}
>>
>> ret = stm32f7_i2c_wait_free_bus(i2c_dev);
>> if (ret)
>> @@ -1767,8 +1771,10 @@ static int stm32f7_i2c_reg_slave(struct i2c_client
>> *slave)
>> return ret;
>>
>> ret = pm_runtime_get_sync(dev);
>> -if (ret < 0)
>> +if (ret < 0) {
>> +pm_runtime_put_noidle(dev);
>> return ret;
>> +}
>>
>> if (!stm32f7_i2c_is_slave_registered(i2c_dev))
>> stm32f7_i2c_enable_wakeup(i2c_dev, true);
>> @@ -1837,8 +1843,10 @@ static int stm32f7_i2c_unreg_slave(struct i2c_client
>> *slave)
>> WARN_ON(!i2c_dev->slave[id]);
>>
>> ret = pm_runtime_get_sync(i2c_dev->dev);
>> -if (ret < 0)
>> +if (ret < 0) {
>> +pm_runtime_put_noidle(i2c_dev->dev);
>> return ret;
>> +}
>>
>> if (id == 0) {
>> mask = STM32F7_I2C_OAR1_OA1EN;
>> @@ -2182,8 +2190,10 @@ static int stm32f7_i2c_regs_backup(struct
>> stm32f7_i2c_dev *i2c_dev)
>> struct stm32f7_i2c_regs *backup_regs = &i2c_dev->backup_regs;
>>
>> ret = pm_runtime_get_sync(i2c_dev->dev);
>> -if (ret < 0)
>> +if (ret < 0) {
>> +pm_runtime_put_noidle(i2c_dev->dev);
>> return ret;
>> +}
>>
>> backup_regs->cr1 = readl_relaxed(i2c_dev->base + STM32F7_I2C_CR1);
>> backup_regs->cr2 = readl_relaxed(i2c_dev->base + STM32F7_I2C_CR2);
>> @@ -2204,8 +2214,10 @@ static int stm32f7_i2c_regs_restore(struct
>> stm32f7_i2c_dev *i2c_dev)
>> struct stm32f7_i2c_regs *backup_regs = &i2c_dev->backup_regs;
>>
>> ret = pm_runtime_get_sync(i2c_dev->dev);
>> -if (ret < 0)
>> +if (ret < 0) {
>> +pm_runtime_put_noidle(i2c_dev->dev);
>> return ret;
>> +}
>>
>> cr1 = readl_relaxed(i2c_dev->base + STM32F7_I2C_CR1);
>> if (cr1 & STM32F7_I2C_CR1_PE)
>> --
>> 2.17.1
>>
[PATCH v3] clk: mediatek: Make mtk_clk_register_mux() a static function
mtk_clk_register_mux() should be a static function
Fixes: a3ae549917f16 ("clk: mediatek: Add new clkmux register API")
Signed-off-by: Weiyi Lu
---
drivers/clk/mediatek/clk-mux.c | 2 +-
drivers/clk/mediatek/clk-mux.h | 4
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mux.c b/drivers/clk/mediatek/clk-mux.c
index 14e127e..dcc1352 100644
--- a/drivers/clk/mediatek/clk-mux.c
+++ b/drivers/clk/mediatek/clk-mux.c
@@ -155,7 +155,7 @@ static int mtk_clk_mux_set_parent_setclr_lock(struct clk_hw
*hw, u8 index)
.set_parent = mtk_clk_mux_set_parent_setclr_lock,
};
-struct clk *mtk_clk_register_mux(const struct mtk_mux *mux,
+static struct clk *mtk_clk_register_mux(const struct mtk_mux *mux,
struct regmap *regmap,
spinlock_t *lock)
{
diff --git a/drivers/clk/mediatek/clk-mux.h b/drivers/clk/mediatek/clk-mux.h
index f5625f4..8e2f927 100644
--- a/drivers/clk/mediatek/clk-mux.h
+++ b/drivers/clk/mediatek/clk-mux.h
@@ -77,10 +77,6 @@ struct mtk_mux {
_width, _gate, _upd_ofs, _upd, \
CLK_SET_RATE_PARENT)
-struct clk *mtk_clk_register_mux(const struct mtk_mux *mux,
-struct regmap *regmap,
-spinlock_t *lock);
-
int mtk_clk_register_muxes(const struct mtk_mux *muxes,
int num, struct device_node *node,
spinlock_t *lock,
--
1.8.1.1.dirty
[PATCH] phy: mapphone-mdm6600: remove the unused variable error value assignment
From: Kaixu Xia
The value of variable error is overwritten by the following call
devm_request_threaded_irq() in phy_mdm6600_device_power_on(), so here the
value assignment is useless. Remove it.
Reported-by: Tosk Robot
Signed-off-by: Kaixu Xia
---
drivers/phy/motorola/phy-mapphone-mdm6600.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/phy/motorola/phy-mapphone-mdm6600.c
b/drivers/phy/motorola/phy-mapphone-mdm6600.c
index 5172971..24ab848 100644
--- a/drivers/phy/motorola/phy-mapphone-mdm6600.c
+++ b/drivers/phy/motorola/phy-mapphone-mdm6600.c
@@ -421,7 +421,6 @@ static int phy_mdm6600_device_power_on(struct phy_mdm6600
*ddata)
dev_info(ddata->dev, "Powered up OK\n");
} else {
ddata->enabled = false;
- error = -ETIMEDOUT;
dev_err(ddata->dev, "Timed out powering up\n");
}
--
1.8.3.1
回复: memory leak in __usbhid_submit_report
发件人: syzbot 发送时间: 2020年11月11日 21:55 收件人: benjamin.tissoi...@redhat.com; ji...@kernel.org; linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; syzkaller-b...@googlegroups.com 主题: memory leak in __usbhid_submit_report [Please note this e-mail is from an EXTERNAL e-mail address] Hello, syzbot found the following issue on: HEAD commit:f8394f23 Linux 5.10-rc3 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=12ebbdc650 kernel config: https://syzkaller.appspot.com/x/.config?x=a3f13716fa0212fd dashboard link: https://syzkaller.appspot.com/bug?extid=47b26cd837ececfc666d compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14497b8250 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1586ff1450 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+47b26cd837ececfc6...@syzkaller.appspotmail.com BUG: memory leak unreferenced object 0x8881097e5ec0 (size 32): comm "kworker/0:1", pid 7, jiffies 4294949214 (age 33.520s) hex dump (first 32 bytes): 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [<8296eaa1>] __usbhid_submit_report+0x116/0x490 drivers/hid/usbhid/hid-core.c:588 [] usbhid_submit_report drivers/hid/usbhid/hid-core.c:638 [inline] [ ] usbhid_request+0x59/0xa0 drivers/hid/usbhid/hid-core.c:1272 [<428a854b>] hidinput_led_worker+0x59/0x160 drivers/hid/hid-input.c:1507 [<1bb8d86d>] process_one_work+0x27d/0x590 kernel/workqueue.c:2272 [<5d9a2f9c>] worker_thread+0x59/0x5d0 kernel/workqueue.c:2418 [ ] kthread+0x178/0x1b0 kernel/kthread.c:292 [<99d5a9ee>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 When usb device disconnect the "raw_report" should be free in usbhid_stop. can we release it in this function, as shown below: usbhid_stop(struct hid_device *hid) { for (index = 0; index < HID_CONTROL_FIFO_SIZE; index++) { if (usbhid->ctrl[index].raw_report) kfree(usbhid->ctrl[index].raw_report); if (usbhid->out[index].raw_report) kfree(usbhid->out[index].raw_report); } ... } BUG: memory leak unreferenced object 0x8881120200c0 (size 32): comm "kworker/0:1", pid 7, jiffies 4294949214 (age 33.520s) hex dump (first 32 bytes): 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [<8296eaa1>] __usbhid_submit_report+0x116/0x490 drivers/hid/usbhid/hid-core.c:588 [ ] usbhid_submit_report drivers/hid/usbhid/hid-core.c:638 [inline] [ ] usbhid_request+0x59/0xa0 drivers/hid/usbhid/hid-core.c:1272 [<428a854b>] hidinput_led_worker+0x59/0x160 drivers/hid/hid-input.c:1507 [<1bb8d86d>] process_one_work+0x27d/0x590 kernel/workqueue.c:2272 [<5d9a2f9c>] worker_thread+0x59/0x5d0 kernel/workqueue.c:2418 [ ] kthread+0x178/0x1b0 kernel/kthread.c:292 [<99d5a9ee>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 BUG: memory leak unreferenced object 0x888107fa9420 (size 32): comm "kworker/0:1", pid 7, jiffies 4294949214 (age 33.520s) hex dump (first 32 bytes): 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [<8296eaa1>] __usbhid_submit_report+0x116/0x490 drivers/hid/usbhid/hid-core.c:588 [ ] usbhid_submit_report drivers/hid/usbhid/hid-core.c:638 [inline] [ ] usbhid_request+0x59/0xa0 drivers/hid/usbhid/hid-core.c:1272 [<428a854b>] hidinput_led_worker+0x59/0x160 drivers/hid/hid-input.c:1507 [<1bb8d86d>] process_one_work+0x27d/0x590 kernel/workqueue.c:2272 [<5d9a2f9c>] worker_thread+0x59/0x5d0 kernel/workqueue.c:2418 [ ] kthread+0x178/0x1b0 kernel/kthread.c:292 [<99d5a9ee>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 BUG: memory leak unreferenced object 0x888112020b60 (size 32): comm "kworker/1:4", pid 8569, jiffies 4294949237 (age 33.290s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [<8296eaa1>] __usbhid_submit_report+0x116/0x490 drivers/hid/usbhid/hid-core.c:588 [ ] usbhid_submit_report drivers/hid/usbhid/hid-core.c:638
Re: [PATCH net] net: phy: mscc: remove non-MACSec compatible phy
On 12.11.2020 14:28, Jakub Kicinski wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
On Thu, 12 Nov 2020 10:04:29 +0100 Steen Hegelund wrote:
Selecting VSC8575 as a MACSec PHY was not correct
The relevant datasheet can be found here:
- VSC8575: https://www.microchip.com/wwwproducts/en/VSC8575
Fixes: 0a504e9e97886 ("net: phy: mscc: macsec initialization")
Signed-off-by: Steen Hegelund
Fixes tag: Fixes: 0a504e9e97886 ("net: phy: mscc: macsec initialization")
Has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
Hi Jacub,
Right, that sha was for a tree object, not a commit. I should have
checked that.
Thanks for the log command example. That is really useful.
BR
Steen
---
Steen Hegelund
steen.hegel...@microchip.com
Re: [PATCH v3 2/2] spmi: mediatek: Add support for MT6873/8192
Quoting Hsin-Hsiung Wang (2020-10-15 05:59:08)
> add spmi support for MT6873/8192.
Capitalize Add please.
>
> Signed-off-by: Hsin-Hsiung Wang
> ---
> drivers/spmi/Kconfig | 9 +
> drivers/spmi/Makefile| 1 +
> drivers/spmi/spmi-mtk-pmif.c | 474 +++
> 3 files changed, 484 insertions(+)
> create mode 100644 drivers/spmi/spmi-mtk-pmif.c
>
> diff --git a/drivers/spmi/spmi-mtk-pmif.c b/drivers/spmi/spmi-mtk-pmif.c
> new file mode 100644
> index ..ac71e64a2bda
> --- /dev/null
> +++ b/drivers/spmi/spmi-mtk-pmif.c
> @@ -0,0 +1,474 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2020 MediaTek Inc.
> +
> +#include
> +#include
> +#include
> +#include
Is this include used?
> +#include
> +#include
> +
> +#define SWINF_IDLE 0x00
> +#define SWINF_WFVLDCLR 0x06
> +
> +#define GET_SWINF(x) (((x) >> 1) & 0x7)
> +
> +#define PMIF_CMD_REG_0 0
> +#define PMIF_CMD_REG 1
> +#define PMIF_CMD_EXT_REG 2
> +#define PMIF_CMD_EXT_REG_LONG 3
> +
> +#define PMIF_DELAY_US 10
> +#define PMIF_TIMEOUT(10 * 1000)
> +
> +#define PMIF_CHAN_OFFSET 0x5
> +
> +#define SPMI_OP_ST_BUSY 1
> +
> +struct ch_reg {
> + u32 ch_sta;
> + u32 wdata;
> + u32 rdata;
> + u32 ch_send;
> + u32 ch_rdy;
> +};
> +
> +struct pmif {
> + void __iomem*base;
> + const u32 *regs;
> + void __iomem*spmimst_base;
> + const u32 *spmimst_regs;
> + u32 soc_chan;
> + int grpid;
> + raw_spinlock_t lock;
> + struct clk *pmif_sys_ck;
> + struct clk *pmif_tmr_ck;
These two are acquired but never used?
> + struct clk *spmimst_clk_mux;
> + struct ch_reg chan;
> +};
> +
> +enum pmif_regs {
> + PMIF_INIT_DONE,
> + PMIF_INF_EN,
> + PMIF_ARB_EN,
> + PMIF_CMDISSUE_EN,
> + PMIF_TIMER_CTRL,
> + PMIF_SPI_MODE_CTRL,
> + PMIF_IRQ_EVENT_EN_0,
> + PMIF_IRQ_FLAG_0,
> + PMIF_IRQ_CLR_0,
> + PMIF_IRQ_EVENT_EN_1,
> + PMIF_IRQ_FLAG_1,
> + PMIF_IRQ_CLR_1,
> + PMIF_IRQ_EVENT_EN_2,
> + PMIF_IRQ_FLAG_2,
> + PMIF_IRQ_CLR_2,
> + PMIF_IRQ_EVENT_EN_3,
> + PMIF_IRQ_FLAG_3,
> + PMIF_IRQ_CLR_3,
> + PMIF_IRQ_EVENT_EN_4,
> + PMIF_IRQ_FLAG_4,
> + PMIF_IRQ_CLR_4,
> + PMIF_WDT_EVENT_EN_0,
> + PMIF_WDT_FLAG_0,
> + PMIF_WDT_EVENT_EN_1,
> + PMIF_WDT_FLAG_1,
> + PMIF_SWINF_0_STA,
> + PMIF_SWINF_0_WDATA_31_0,
> + PMIF_SWINF_0_RDATA_31_0,
> + PMIF_SWINF_0_ACC,
> + PMIF_SWINF_0_VLD_CLR,
> + PMIF_SWINF_1_STA,
> + PMIF_SWINF_1_WDATA_31_0,
> + PMIF_SWINF_1_RDATA_31_0,
> + PMIF_SWINF_1_ACC,
> + PMIF_SWINF_1_VLD_CLR,
> + PMIF_SWINF_2_STA,
> + PMIF_SWINF_2_WDATA_31_0,
> + PMIF_SWINF_2_RDATA_31_0,
> + PMIF_SWINF_2_ACC,
> + PMIF_SWINF_2_VLD_CLR,
> + PMIF_SWINF_3_STA,
> + PMIF_SWINF_3_WDATA_31_0,
> + PMIF_SWINF_3_RDATA_31_0,
> + PMIF_SWINF_3_ACC,
> + PMIF_SWINF_3_VLD_CLR,
> +};
> +
> +static const u32 mt6873_regs[] = {
> + [PMIF_INIT_DONE] = 0x,
> + [PMIF_INF_EN] = 0x0024,
> + [PMIF_ARB_EN] = 0x0150,
> + [PMIF_CMDISSUE_EN] =0x03B4,
> + [PMIF_TIMER_CTRL] = 0x03E0,
> + [PMIF_SPI_MODE_CTRL] = 0x0400,
> + [PMIF_IRQ_EVENT_EN_0] = 0x0418,
> + [PMIF_IRQ_FLAG_0] = 0x0420,
> + [PMIF_IRQ_CLR_0] = 0x0424,
> + [PMIF_IRQ_EVENT_EN_1] = 0x0428,
> + [PMIF_IRQ_FLAG_1] = 0x0430,
> + [PMIF_IRQ_CLR_1] = 0x0434,
> + [PMIF_IRQ_EVENT_EN_2] = 0x0438,
> + [PMIF_IRQ_FLAG_2] = 0x0440,
> + [PMIF_IRQ_CLR_2] = 0x0444,
> + [PMIF_IRQ_EVENT_EN_3] = 0x0448,
> + [PMIF_IRQ_FLAG_3] = 0x0450,
> + [PMIF_IRQ_CLR_3] = 0x0454,
> + [PMIF_IRQ_EVENT_EN_4] = 0x0458,
> + [PMIF_IRQ_FLAG_4] = 0x0460,
> + [PMIF_IRQ_CLR_4] = 0x0464,
> + [PMIF_WDT_EVENT_EN_0] = 0x046C,
> + [PMIF_WDT_FLAG_0] = 0x0470,
> + [PMIF_WDT_EVENT_EN_1] = 0x0474,
> + [PMIF_WDT_FLAG_1] = 0x0478,
> + [PMIF_SWINF_0_ACC] =0x0C00,
> + [PMIF_SWINF_0_WDATA_31_0] = 0x0C04,
> + [PMIF_SWINF_0_RDATA_31_0] = 0x0C14,
> + [PMIF_SWINF_0_VLD_CLR] =0x0C24,
> + [PMIF_SWINF_0_STA] =0x0C28,
> + [PMIF_SWINF_1_ACC] =0x0C40,
> + [PMIF_SWINF_1_WDATA_31_0] = 0x0C44,
> + [PMIF_SWINF_1_RDATA_31_0] = 0x0C54,
> + [PMIF_SWINF_1_VLD_CLR] =0x0C64,
> + [PMIF_SWINF_1_STA] =0x0C68,
> + [PMIF_SWINF_2_ACC] =0x0C80,
> + [PMIF_SWINF_2_WDATA_31_0] = 0x0C84,
> + [PMIF_SWINF_2_RDATA_31_0] = 0x0C94,
> + [PMIF_SWINF_2_VLD_CLR] =0x0CA4,
> + [PMIF_SWINF_2_STA] =0x0CA8,
> + [PMIF_SWINF_3_ACC] =0x0CC0,
RE: [PATCH] brcmfmac: fix error return code in brcmf_cfg80211_connect()
> Fix to return a negative error code from the error handling case instead of
> 0, as done elsewhere in th>
>
> Fixes: 3b1e0a7bdfee ("brcmfmac: add support for SAE authentication offload")
> Reported-by: Hulk Robot
> Signed-off-by: Zhang Changzhong
Reviewed-by: Chi-hsien Lin
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> b/drivers/net/wireless/broadc>
> index a2dbbb9..0ee421f 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -2137,7 +2137,8 @@ brcmf_cfg80211_connect(struct wiphy *wiphy, struct
> net_device *ndev,
> BRCMF_WSEC_MAX_PSK_LEN);
> else if (profile->use_fwsup == BRCMF_PROFILE_FWSUP_SAE) {
> /* clean up user-space RSNE */
> - if (brcmf_fil_iovar_data_set(ifp, "wpaie", NULL, 0)) {
> + err = brcmf_fil_iovar_data_set(ifp, "wpaie", NULL, 0);
> + if (err) {
> bphy_err(drvr, "failed to clean up user-space RSNE\n");
> goto done;
> }
> --
> 2.9.5
[bug report] sched/fair: Prefer prev cpu in asymmetric wakeup path
Hello Vincent Guittot,
The patch b4c9c9f15649: "sched/fair: Prefer prev cpu in asymmetric
wakeup path" from Oct 29, 2020, leads to the following static checker
warning:
kernel/sched/fair.c:6249 select_idle_sibling()
error: uninitialized symbol 'task_util'.
kernel/sched/fair.c
6233 static int select_idle_sibling(struct task_struct *p, int prev, int
target)
6234 {
6235 struct sched_domain *sd;
6236 unsigned long task_util;
6237 int i, recent_used_cpu;
6238
6239 /*
6240 * On asymmetric system, update task utilization because we
will check
6241 * that the task fits with cpu's capacity.
6242 */
The original comment was a bit more clear... Perhaps "On asymmetric
system[s], [record the] task utilization because we will check that the
task [can be done within] the cpu's capacity."
6243 if (static_branch_unlikely(&sched_asym_cpucapacity)) {
6244 sync_entity_load_avg(&p->se);
6245 task_util = uclamp_task_util(p);
6246 }
"task_util" is not initialized on the else path.
6247
6248 if ((available_idle_cpu(target) || sched_idle_cpu(target)) &&
6249 asym_fits_capacity(task_util, target))
^
Uninitialized variable warning.
6250 return target;
6251
6252 /*
6253 * If the previous CPU is cache affine and idle, don't be
stupid:
6254 */
6255 if (prev != target && cpus_share_cache(prev, target) &&
6256 (available_idle_cpu(prev) || sched_idle_cpu(prev)) &&
6257 asym_fits_capacity(task_util, prev))
6258 return prev;
6259
6260 /*
6261 * Allow a per-cpu kthread to stack with the wakee if the
regards,
dan carpenter
Re: [PATCH v9 0/5] Exynos: Simple QoS for exynos-bus using interconnect
On 11/12/20 16:09, Sylwester Nawrocki wrote: > > This patchset adds interconnect API support for the Exynos SoC "samsung, > exynos-bus" compatible devices, which already have their corresponding > exynos-bus driver in the devfreq subsystem. Complementing the devfreq > driver with an interconnect functionality allows to ensure the QoS > requirements of devices accessing the system memory (e.g. video processing > devices) are fulfilled and allows to avoid issues like the one discussed > in thread [1]. > > This patch series adds implementation of the interconnect provider per each > "samsung,exynos-bus" compatible DT node, with one interconnect node per > provider. The interconnect code which was previously added as a part of > the devfreq driver has been converted to a separate platform driver. > In the devfreq a corresponding virtual child platform device is registered. > Integration of devfreq and interconnect frameworks is achieved through > the PM QoS API. > > A sample interconnect consumer for exynos-mixer is added in patch 5/5, > it is currently added only for exynos4412 and allows to address the > mixer DMA underrun error issues [1]. Good work Sylwester! Thank you and all the reviewers! What would be the merge path for this patchset? Looks like there is no build dependency between patches. Should i take just patches 2,3 or also patch 1? Chanwoo? Thanks, Georgi
Re: [PATCH RFC v5 01/13] perf jevents: Add support for an extra directory level
On 11/6/20 6:05 PM, John Garry wrote:
> Currently only upto a level 2 directory is supported, in form
> vendor/platform.
Hi John,
Just want to check in case of sub directories,
Will it be good add on/feasible to be able to include events of particular
sub-directory for a
platform? Otherwise with this patch in the end all event will be part of
same pmu_event structure. So what is the purpose of sub directories? Let me
know if I am missing something.
Thanks,
Kajol Jain
>
> Add support for a further level, to support vendor/platform
> sub-directories in future.
>
> Signed-off-by: John Garry
> ---
> tools/perf/pmu-events/jevents.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
> index 72cfa3b5046d..9022216b1253 100644
> --- a/tools/perf/pmu-events/jevents.c
> +++ b/tools/perf/pmu-events/jevents.c
> @@ -978,15 +978,20 @@ static int process_one_file(const char *fpath, const
> struct stat *sb,
> int level = ftwbuf->level;
> int err = 0;
>
> - if (level == 2 && is_dir) {
> + if (level >= 2 && is_dir) {
> + int count = 0;
> /*
>* For level 2 directory, bname will include parent name,
>* like vendor/platform. So search back from platform dir
>* to find this.
> + * Something similar for level 3 directory, but we're a PMU
> + * category folder, like vendor/platform/cpu.
>*/
> bname = (char *) fpath + ftwbuf->base - 2;
> for (;;) {
> if (*bname == '/')
> + count++;
> + if (count == level - 1)
> break;
> bname--;
> }
> @@ -999,13 +1004,13 @@ static int process_one_file(const char *fpath, const
> struct stat *sb,
>level, sb->st_size, bname, fpath);
>
> /* base dir or too deep */
> - if (level == 0 || level > 3)
> + if (level == 0 || level > 4)
> return 0;
>
>
> /* model directory, reset topic */
> if ((level == 1 && is_dir && is_leaf_dir(fpath)) ||
> - (level == 2 && is_dir)) {
> + (level >= 2 && is_dir && is_leaf_dir(fpath))) {
> if (close_table)
> print_events_table_suffix(eventsfp);
>
>
[PATCH 1/2] base: Rename devm_ioremap_resource to make the implicit request_mem explicit
The main difference between devm_ioremap() and devm_ioremap_resource()
(apart from the different way to pass the area to map) is that the latter
also calls devm_request_mem() which is unintuitive and yields problems
like
https://lore.kernel.org/r/1555670144-24220-1-git-send-email-aisheng.d...@nxp.com
.
So rename devm_ioremap_resource and it's relative devm_ioremap_resource_wc
to include "request" in their name.
Until all users are converted, provide wrappers with the old name.
Signed-off-by: Uwe Kleine-König
---
.../driver-api/driver-model/devres.rst| 4 +--
include/linux/device.h| 31 ---
lib/devres.c | 18 +--
3 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/Documentation/driver-api/driver-model/devres.rst
b/Documentation/driver-api/driver-model/devres.rst
index bb676570acc3..65f9f44d5c39 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -309,8 +309,8 @@ IOMAP
devm_ioremap()
devm_ioremap_uc()
devm_ioremap_wc()
- devm_ioremap_resource() : checks resource, requests memory region, ioremaps
- devm_ioremap_resource_wc()
+ devm_request_ioremap_resource() : checks resource, requests memory region,
ioremaps
+ devm_request_ioremap_resource_wc()
devm_platform_ioremap_resource() : calls devm_ioremap_resource() for
platform device
devm_platform_ioremap_resource_wc()
devm_platform_ioremap_resource_byname()
diff --git a/include/linux/device.h b/include/linux/device.h
index 5ed101be7b2e..927992549db9 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -240,10 +240,33 @@ unsigned long devm_get_free_pages(struct device *dev,
gfp_t gfp_mask, unsigned int order);
void devm_free_pages(struct device *dev, unsigned long addr);
-void __iomem *devm_ioremap_resource(struct device *dev,
- const struct resource *res);
-void __iomem *devm_ioremap_resource_wc(struct device *dev,
- const struct resource *res);
+void __iomem *devm_request_ioremap_resource(struct device *dev,
+ const struct resource *res);
+/*
+ * devm_ioremap_resource() was the initial name chosen for
+ * devm_request_ioremap_resource(). Please stick to the latter for clearer
+ * semantics.
+ */
+static inline void __iomem *
+devm_ioremap_resource(struct device *dev, const struct resource *res)
+{
+ return devm_request_ioremap_resource(dev, res);
+}
+
+void __iomem *devm_request_ioremap_resource_wc(struct device *dev,
+ const struct resource *res);
+
+/*
+ * devm_ioremap_resource_wc() was the initial name chosen for
+ * devm_request_ioremap_resource_wc(). Please stick to the latter for clearer
+ * semantics.
+ */
+static inline void __iomem *
+devm_ioremap_resource_wc(struct device *dev,
+const struct resource *res)
+{
+ return devm_request_ioremap_resource_wc(dev, res);
+}
void __iomem *devm_of_iomap(struct device *dev,
struct device_node *node, int index,
diff --git a/lib/devres.c b/lib/devres.c
index 2a4ff5d64288..907588f1a5b7 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -114,8 +114,8 @@ void devm_iounmap(struct device *dev, void __iomem *addr)
EXPORT_SYMBOL(devm_iounmap);
static void __iomem *
-__devm_ioremap_resource(struct device *dev, const struct resource *res,
- enum devm_ioremap_type type)
+__devm_request_ioremap_resource(struct device *dev, const struct resource *res,
+ enum devm_ioremap_type type)
{
resource_size_t size;
void __iomem *dest_ptr;
@@ -172,12 +172,12 @@ __devm_ioremap_resource(struct device *dev, const struct
resource *res,
* Return: a pointer to the remapped memory or an ERR_PTR() encoded error code
* on failure.
*/
-void __iomem *devm_ioremap_resource(struct device *dev,
- const struct resource *res)
+void __iomem *devm_request_ioremap_resource(struct device *dev,
+ const struct resource *res)
{
- return __devm_ioremap_resource(dev, res, DEVM_IOREMAP);
+ return __devm_request_ioremap_resource(dev, res, DEVM_IOREMAP);
}
-EXPORT_SYMBOL(devm_ioremap_resource);
+EXPORT_SYMBOL(devm_request_ioremap_resource);
/**
* devm_ioremap_resource_wc() - write-combined variant of
@@ -188,10 +188,10 @@ EXPORT_SYMBOL(devm_ioremap_resource);
* Return: a pointer to the remapped memory or an ERR_PTR() encoded error code
* on failure.
*/
-void __iomem *devm_ioremap_resource_wc(struct device *dev,
- const struct resource *res)
+void __iomem *devm_request_ioremap_resource_wc(struct device *dev,
+ const struct resource *res)
{
-
[PATCH 0/2] Rename ioremap functions that include request_mem
Hello, here comes a patch set that implements the suggestion in the previous mail so we have something to discuss about. Best regards Uwe Uwe Kleine-König (2): base: Rename devm_ioremap_resource to make the implicit request_mem explicit platform: Rename devm_platform_ioremap_resource to make the implicit request_mem explicit .../driver-api/driver-model/devres.rst| 6 +-- drivers/base/platform.c | 26 +-- include/linux/device.h| 32 -- include/linux/platform_device.h | 43 +-- lib/devres.c | 18 5 files changed, 93 insertions(+), 32 deletions(-) base-commit: 3650b228f83adda7e5ee532e2b90429c03f7b9ec -- 2.28.0
[PATCH 2/2] platform: Rename devm_platform_ioremap_resource to make the implicit request_mem explicit
devm_ioremap_resource() and so devm_platform_ioremap_resource() et al also
include a call to devm_request_mem(). Make this explicit in their name
to make this difference compared to devm_ioremap() more obvious.
This follows the similar rename of devm_ioremap_resource in the previous
commit.
Signed-off-by: Uwe Kleine-König
---
.../driver-api/driver-model/devres.rst| 2 +-
drivers/base/platform.c | 26 +--
include/linux/device.h| 3 +-
include/linux/platform_device.h | 43 +--
4 files changed, 56 insertions(+), 18 deletions(-)
diff --git a/Documentation/driver-api/driver-model/devres.rst
b/Documentation/driver-api/driver-model/devres.rst
index 65f9f44d5c39..6dd5c219f11e 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -311,7 +311,7 @@ IOMAP
devm_ioremap_wc()
devm_request_ioremap_resource() : checks resource, requests memory region,
ioremaps
devm_request_ioremap_resource_wc()
- devm_platform_ioremap_resource() : calls devm_ioremap_resource() for
platform device
+ devm_platform_request_ioremap_resource() : calls
devm_request_ioremap_resource() for platform device
devm_platform_ioremap_resource_wc()
devm_platform_ioremap_resource_byname()
devm_platform_get_and_ioremap_resource()
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 88aef93eb4dd..5a451121a9e0 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -65,8 +65,8 @@ EXPORT_SYMBOL_GPL(platform_get_resource);
#ifdef CONFIG_HAS_IOMEM
/**
- * devm_platform_get_and_ioremap_resource - call devm_ioremap_resource() for a
- * platform device and get resource
+ * devm_platform_get_request_and_ioremap_resource - call
devm_ioremap_resource() for a
+ * platform device and get
resource
*
* @pdev: platform device to use both for memory resource lookup as well as
*resource management
@@ -77,17 +77,17 @@ EXPORT_SYMBOL_GPL(platform_get_resource);
* on failure.
*/
void __iomem *
-devm_platform_get_and_ioremap_resource(struct platform_device *pdev,
- unsigned int index, struct resource **res)
+devm_platform_get_request_and_ioremap_resource(struct platform_device *pdev,
+ unsigned int index, struct
resource **res)
{
struct resource *r;
r = platform_get_resource(pdev, IORESOURCE_MEM, index);
if (res)
*res = r;
- return devm_ioremap_resource(&pdev->dev, r);
+ return devm_request_ioremap_resource(&pdev->dev, r);
}
-EXPORT_SYMBOL_GPL(devm_platform_get_and_ioremap_resource);
+EXPORT_SYMBOL_GPL(devm_platform_get_request_and_ioremap_resource);
/**
* devm_platform_ioremap_resource - call devm_ioremap_resource() for a platform
@@ -100,12 +100,12 @@ EXPORT_SYMBOL_GPL(devm_platform_get_and_ioremap_resource);
* Return: a pointer to the remapped memory or an ERR_PTR() encoded error code
* on failure.
*/
-void __iomem *devm_platform_ioremap_resource(struct platform_device *pdev,
-unsigned int index)
+void __iomem *devm_platform_request_ioremap_resource(struct platform_device
*pdev,
+unsigned int index)
{
- return devm_platform_get_and_ioremap_resource(pdev, index, NULL);
+ return devm_platform_get_request_and_ioremap_resource(pdev, index,
NULL);
}
-EXPORT_SYMBOL_GPL(devm_platform_ioremap_resource);
+EXPORT_SYMBOL_GPL(devm_platform_request_ioremap_resource);
/**
* devm_platform_ioremap_resource_wc - write-combined variant of
@@ -118,13 +118,13 @@ EXPORT_SYMBOL_GPL(devm_platform_ioremap_resource);
* Return: a pointer to the remapped memory or an ERR_PTR() encoded error code
* on failure.
*/
-void __iomem *devm_platform_ioremap_resource_wc(struct platform_device *pdev,
- unsigned int index)
+void __iomem *devm_platform_request_ioremap_resource_wc(struct platform_device
*pdev,
+ unsigned int index)
{
struct resource *res;
res = platform_get_resource(pdev, IORESOURCE_MEM, index);
- return devm_ioremap_resource_wc(&pdev->dev, res);
+ return devm_request_ioremap_resource_wc(&pdev->dev, res);
}
/**
diff --git a/include/linux/device.h b/include/linux/device.h
index 927992549db9..3679a42f94a9 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -245,7 +245,8 @@ void __iomem *devm_request_ioremap_resource(struct device
*dev,
/*
* devm_ioremap_resource() was the initial name chosen for
* devm_request_ioremap_resource(). Please stick to the latter for clearer
- * semantics.
+ * semantics. When converting consider using
+ * devm_platform_request_ioremap
Re: [PATCH v9 0/5] Exynos: Simple QoS for exynos-bus using interconnect
On 11/13/20 5:48 PM, Georgi Djakov wrote: > On 11/12/20 16:09, Sylwester Nawrocki wrote: >> >> This patchset adds interconnect API support for the Exynos SoC "samsung, >> exynos-bus" compatible devices, which already have their corresponding >> exynos-bus driver in the devfreq subsystem. Complementing the devfreq >> driver with an interconnect functionality allows to ensure the QoS >> requirements of devices accessing the system memory (e.g. video processing >> devices) are fulfilled and allows to avoid issues like the one discussed >> in thread [1]. >> >> This patch series adds implementation of the interconnect provider per each >> "samsung,exynos-bus" compatible DT node, with one interconnect node per >> provider. The interconnect code which was previously added as a part of >> the devfreq driver has been converted to a separate platform driver. >> In the devfreq a corresponding virtual child platform device is registered. >> Integration of devfreq and interconnect frameworks is achieved through >> the PM QoS API. >> >> A sample interconnect consumer for exynos-mixer is added in patch 5/5, >> it is currently added only for exynos4412 and allows to address the >> mixer DMA underrun error issues [1]. > > Good work Sylwester! Thank you and all the reviewers! What would be the merge > path for this patchset? Looks like there is no build dependency between > patches. > Should i take just patches 2,3 or also patch 1? Chanwoo? Hi Georgi, If you take the patch 2,3, I'll apply patch 1,4 to devfreq.git. Hi Sylwester, First of all, thanks for your work to finish it for a long time. I'm very happy about finishing this work. It is very necessary feature for the QoS. Once again, thank for your work. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [bug report] sched/fair: Prefer prev cpu in asymmetric wakeup path
Hi Dan,
Le vendredi 13 nov. 2020 à 11:46:57 (+0300), Dan Carpenter a écrit :
> Hello Vincent Guittot,
>
> The patch b4c9c9f15649: "sched/fair: Prefer prev cpu in asymmetric
> wakeup path" from Oct 29, 2020, leads to the following static checker
> warning:
>
> kernel/sched/fair.c:6249 select_idle_sibling()
> error: uninitialized symbol 'task_util'.
>
> kernel/sched/fair.c
> 6233 static int select_idle_sibling(struct task_struct *p, int prev, int
> target)
> 6234 {
> 6235 struct sched_domain *sd;
> 6236 unsigned long task_util;
> 6237 int i, recent_used_cpu;
> 6238
> 6239 /*
> 6240 * On asymmetric system, update task utilization because we
> will check
> 6241 * that the task fits with cpu's capacity.
> 6242 */
>
> The original comment was a bit more clear... Perhaps "On asymmetric
> system[s], [record the] task utilization because we will check that the
> task [can be done within] the cpu's capacity."
The comment "update task utilization because we will check ..." refers to
sync_entity_load_avg()
>
> 6243 if (static_branch_unlikely(&sched_asym_cpucapacity)) {
> 6244 sync_entity_load_avg(&p->se);
> 6245 task_util = uclamp_task_util(p);
> 6246 }
>
> "task_util" is not initialized on the else path.
no need because it will not be used
>
> 6247
> 6248 if ((available_idle_cpu(target) || sched_idle_cpu(target)) &&
> 6249 asym_fits_capacity(task_util, target))
>^
> Uninitialized variable warning.
asym_fits_capacity includes the same condition as above when we set task_util
so task_util can't be used unintialize
static inline bool asym_fits_capacity(int task_util, int cpu)
{
if (static_branch_unlikely(&sched_asym_cpucapacity))
return fits_capacity(task_util, capacity_of(cpu));
return true;
}
>
> 6250 return target;
> 6251
> 6252 /*
> 6253 * If the previous CPU is cache affine and idle, don't be
> stupid:
> 6254 */
> 6255 if (prev != target && cpus_share_cache(prev, target) &&
> 6256 (available_idle_cpu(prev) || sched_idle_cpu(prev)) &&
> 6257 asym_fits_capacity(task_util, prev))
> 6258 return prev;
> 6259
> 6260 /*
> 6261 * Allow a per-cpu kthread to stack with the wakee if the
>
> regards,
> dan carpenter
Re: [PATCH] platform/chrome: Don't treat RTC events as wakeup sources
On Fri, 30 Oct 2020 16:25:23 -0700, Stephen Boyd wrote: > The EC sends an RTC host event when the RTC fires, but we don't need to > treat that as a wakeup event here. The RTC class already properly > handles activating and deactivating a wakeup source in rtc_update_irq() > by calling pm_stay_awake() at the start of processing and pm_relax() > once all expired RTC timers have been processed. This reduces one wakeup > increment but not much else. I noticed this while debugging RTC wakeups > and how they always incremented the wakeup count by two instead of one > because this is duplicated. Applied, thanks! [1/1] platform/chrome: Don't treat RTC events as wakeup sources commit: 853c1a789f5fe8e783586a5c2dcc2ad1b57ac20f Best regards, -- Enric Balletbo i Serra
[PATCH] x86/PCI: fix a comments issue
The comments is using kernel-doc markup, while it isn't, so remove it from kernel-doc type to avoid warning: arch/x86/pci/i386.c:373: warning: Function parameter or member 'pcibios_assign_resources' not described in 'fs_initcall' Signed-off-by: Alex Shi Cc: Bjorn Helgaas Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: x...@kernel.org Cc: "H. Peter Anvin" Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- arch/x86/pci/i386.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c index fa855bbaebaf..77fda6d432c6 100644 --- a/arch/x86/pci/i386.c +++ b/arch/x86/pci/i386.c @@ -366,7 +366,7 @@ static int __init pcibios_assign_resources(void) return 0; } -/** +/* * called in fs_initcall (one below subsys_initcall), * give a chance for motherboard reserve resources */ -- 2.29.GIT
[PATCH v2 1/3] net: mac80211: use core API for updating TX/RX stats
Commits
d3fd65484c781 ("net: core: add dev_sw_netstats_tx_add")
451b05f413d3f ("net: netdevice.h: sw_netstats_rx_add helper)
have added API to update net device per-cpu TX/RX stats.
Use core API instead of ieee80211_tx/rx_stats().
Signed-off-by: Lev Stipakov
---
v2: also replace ieee80211_rx_stats() with dev_sw_netstats_rx_add()
net/mac80211/rx.c | 18 --
net/mac80211/tx.c | 16 +++-
2 files changed, 7 insertions(+), 27 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 09d1c9fb8872..0c1a19a93c79 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -32,16 +32,6 @@
#include "wme.h"
#include "rate.h"
-static inline void ieee80211_rx_stats(struct net_device *dev, u32 len)
-{
- struct pcpu_sw_netstats *tstats = this_cpu_ptr(dev->tstats);
-
- u64_stats_update_begin(&tstats->syncp);
- tstats->rx_packets++;
- tstats->rx_bytes += len;
- u64_stats_update_end(&tstats->syncp);
-}
-
/*
* monitor mode reception
*
@@ -842,7 +832,7 @@ ieee80211_rx_monitor(struct ieee80211_local *local, struct
sk_buff *origskb,
if (skb) {
skb->dev = sdata->dev;
- ieee80211_rx_stats(skb->dev, skb->len);
+ dev_sw_netstats_rx_add(skb->dev, skb->len);
netif_receive_skb(skb);
}
}
@@ -2560,7 +2550,7 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
skb = rx->skb;
xmit_skb = NULL;
- ieee80211_rx_stats(dev, skb->len);
+ dev_sw_netstats_rx_add(dev, skb->len);
if (rx->sta) {
/* The seqno index has the same property as needed
@@ -3699,7 +3689,7 @@ static void ieee80211_rx_cooked_monitor(struct
ieee80211_rx_data *rx,
}
prev_dev = sdata->dev;
- ieee80211_rx_stats(sdata->dev, skb->len);
+ dev_sw_netstats_rx_add(sdata->dev, skb->len);
}
if (prev_dev) {
@@ -4416,7 +4406,7 @@ static bool ieee80211_invoke_fast_rx(struct
ieee80211_rx_data *rx,
skb->dev = fast_rx->dev;
- ieee80211_rx_stats(fast_rx->dev, skb->len);
+ dev_sw_netstats_rx_add(fast_rx->dev, skb->len);
/* The seqno index has the same property as needed
* for the rx_msdu field, i.e. it is IEEE80211_NUM_TIDS
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 5f05f4651dd7..7807f8178527 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -38,16 +38,6 @@
/* misc utils */
-static inline void ieee80211_tx_stats(struct net_device *dev, u32 len)
-{
- struct pcpu_sw_netstats *tstats = this_cpu_ptr(dev->tstats);
-
- u64_stats_update_begin(&tstats->syncp);
- tstats->tx_packets++;
- tstats->tx_bytes += len;
- u64_stats_update_end(&tstats->syncp);
-}
-
static __le16 ieee80211_duration(struct ieee80211_tx_data *tx,
struct sk_buff *skb, int group_addr,
int next_frag_len)
@@ -3403,7 +3393,7 @@ static void ieee80211_xmit_fast_finish(struct
ieee80211_sub_if_data *sdata,
if (key)
info->control.hw_key = &key->conf;
- ieee80211_tx_stats(skb->dev, skb->len);
+ dev_sw_netstats_tx_add(skb->dev, 1, skb->len);
if (hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_QOS_DATA)) {
tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
@@ -4021,7 +4011,7 @@ void __ieee80211_subif_start_xmit(struct sk_buff *skb,
goto out;
}
- ieee80211_tx_stats(dev, skb->len);
+ dev_sw_netstats_tx_add(dev, 1, skb->len);
ieee80211_xmit(sdata, sta, skb);
}
@@ -4248,7 +4238,7 @@ static void ieee80211_8023_xmit(struct
ieee80211_sub_if_data *sdata,
info->hw_queue = sdata->vif.hw_queue[skb_get_queue_mapping(skb)];
- ieee80211_tx_stats(dev, skb->len);
+ dev_sw_netstats_tx_add(dev, 1, skb->len);
sta->tx_stats.bytes[skb_get_queue_mapping(skb)] += skb->len;
sta->tx_stats.packets[skb_get_queue_mapping(skb)]++;
--
2.25.1
[PATCH] configfs: fix kernel-doc markup issue
Add explanation for 'frag' parameter to avoid kernel-doc issue: fs/configfs/dir.c:277: warning: Function parameter or member 'frag' not described in 'configfs_create_dir' Signed-off-by: Alex Shi Cc: Joel Becker Cc: Christoph Hellwig Cc: linux-kernel@vger.kernel.org --- fs/configfs/dir.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c index b0983e2a4e2c..b839dd1b459f 100644 --- a/fs/configfs/dir.c +++ b/fs/configfs/dir.c @@ -267,6 +267,7 @@ static void configfs_remove_dirent(struct dentry *dentry) * configfs_create_dir - create a directory for an config_item. * @item: config_itemwe're creating directory for. * @dentry:config_item's dentry. + * @frag: config_item's fragment. * * Note: user-created entries won't be allowed under this new directory * until it is validated by configfs_dir_set_ready() -- 2.29.GIT
[PATCH] locking/rtmutex: remove useless parameter for rt_mutex_proxy_unlock
The parameter 'proxy_owner' isn't used, so could be removed.
Signed-off-by: Alex Shi
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Darren Hart
Cc: Will Deacon
Cc: linux-kernel@vger.kernel.org
---
kernel/futex.c | 2 +-
kernel/locking/rtmutex.c| 3 +--
kernel/locking/rtmutex_common.h | 3 +--
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index f8614ef4ff31..347deedcfd0e 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -796,7 +796,7 @@ static void put_pi_state(struct futex_pi_state *pi_state)
list_del_init(&pi_state->list);
raw_spin_unlock(&owner->pi_lock);
}
- rt_mutex_proxy_unlock(&pi_state->pi_mutex, owner);
+ rt_mutex_proxy_unlock(&pi_state->pi_mutex);
raw_spin_unlock_irq(&pi_state->pi_mutex.wait_lock);
}
diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 50fa521fe767..f196045f2857 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1721,8 +1721,7 @@ void rt_mutex_init_proxy_locked(struct rt_mutex *lock,
* possible because it belongs to the pi_state which is about to be freed
* and it is not longer visible to other tasks.
*/
-void rt_mutex_proxy_unlock(struct rt_mutex *lock,
- struct task_struct *proxy_owner)
+void rt_mutex_proxy_unlock(struct rt_mutex *lock)
{
debug_rt_mutex_proxy_unlock(lock);
rt_mutex_set_owner(lock, NULL);
diff --git a/kernel/locking/rtmutex_common.h b/kernel/locking/rtmutex_common.h
index d1d62f942be2..ca6fb489007b 100644
--- a/kernel/locking/rtmutex_common.h
+++ b/kernel/locking/rtmutex_common.h
@@ -133,8 +133,7 @@ enum rtmutex_chainwalk {
extern struct task_struct *rt_mutex_next_owner(struct rt_mutex *lock);
extern void rt_mutex_init_proxy_locked(struct rt_mutex *lock,
struct task_struct *proxy_owner);
-extern void rt_mutex_proxy_unlock(struct rt_mutex *lock,
- struct task_struct *proxy_owner);
+extern void rt_mutex_proxy_unlock(struct rt_mutex *lock);
extern void rt_mutex_init_waiter(struct rt_mutex_waiter *waiter);
extern int __rt_mutex_start_proxy_lock(struct rt_mutex *lock,
struct rt_mutex_waiter *waiter,
--
2.29.GIT
[PATCH] locking/rtmutex: add missed kernel-doc markup
To fix the following issues: kernel/locking/rtmutex.c:1612: warning: Function parameter or member 'lock' not described in '__rt_mutex_futex_unlock' kernel/locking/rtmutex.c:1612: warning: Function parameter or member 'wake_q' not described in '__rt_mutex_futex_unlock' kernel/locking/rtmutex.c:1675: warning: Function parameter or member 'name' not described in '__rt_mutex_init' kernel/locking/rtmutex.c:1675: warning: Function parameter or member 'key' not described in '__rt_mutex_init' Signed-off-by: Alex Shi Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Will Deacon Cc: linux-kernel@vger.kernel.org --- kernel/locking/rtmutex.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index cfdd5b93264d..50fa521fe767 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -1604,8 +1604,11 @@ void __sched rt_mutex_unlock(struct rt_mutex *lock) EXPORT_SYMBOL_GPL(rt_mutex_unlock); /** - * Futex variant, that since futex variants do not use the fast-path, can be - * simple and will not need to retry. + * __rt_mutex_futex_unlock - Futex variant, that since futex variants + * do not use the fast-path, can be simple and will not need to retry. + * + * @lock: the rt_mutex to be unlocked + * @wake_q: wake queue head from which get the next lock waiter */ bool __sched __rt_mutex_futex_unlock(struct rt_mutex *lock, struct wake_q_head *wake_q) @@ -1665,6 +1668,8 @@ EXPORT_SYMBOL_GPL(rt_mutex_destroy); * __rt_mutex_init - initialize the rt lock * * @lock: the rt lock to be initialized + * @name: the lock name used for debug + * @key: the lock class key used for debug * * Initialize the rt lock to unlocked state. * -- 2.29.GIT
Re: [PATCH v2 0/7] platform/chrome: cros_ec_typec: Register partner PD information
On Thu, 29 Oct 2020 15:27:28 -0700, Prashant Malani wrote: > This series adds support to retrieve Type C PD(Power Delivery) Discovery > information from the Chrome OS EC, and register this information with > the Type C connector class framework. > > There are also a couple of patches which fix minor bugs with the > existing cros-ec-typec driver. > > [...] Applied, thanks! [1/7] platform/chrome: cros_ec_typec: Relocate set_port_params_v*() functions commit: 0498710be002b35bcb43895c4133a4c4bbfd837e [2/7] platform/chrome: cros_ec_typec: Fix remove partner logic commit: 7ab5a673f4ce65875c76e9812d2e6da063b87fb7 [3/7] platform/chrome: cros_ec_typec: Clear partner identity on device removal commit: 514acf1cefd020eb21d7c180050a8d66b723d2d8 [4/7] platform/chrome: cros_ec: Import Type C host commands commit: cd2c40ff90b0e385c18f881ab5e17f7137864223 [5/7] platform/chrome: cros_ec_typec: Introduce TYPEC_STATUS commit: 80f8cef60d79f23c02e546ba3de2fce84d5e8bdb [6/7] platform/chrome: cros_ec_typec: Parse partner PD ID VDOs commit: f6f668118918f533676e51f3214f5a104562b59c [7/7] platform/chrome: cros_ec_typec: Register partner altmodes commit: de0f49487db3667f5204dcec6d3482c9bd1a0a30 Best regards, -- Enric Balletbo i Serra
[PATCH] PKCS#7: drop function from kernel-doc pkcs7_validate_trust_one
The function is a static function, so no needs add into kernel-doc. and we could avoid warning: crypto/asymmetric_keys/pkcs7_trust.c:25: warning: Function parameter or member 'pkcs7' not described in 'pkcs7_validate_trust_one' crypto/asymmetric_keys/pkcs7_trust.c:25: warning: Function parameter or member 'sinfo' not described in 'pkcs7_validate_trust_one' crypto/asymmetric_keys/pkcs7_trust.c:25: warning: Function parameter or member 'trust_keyring' not described in 'pkcs7_validate_trust_one' Signed-off-by: Alex Shi Cc: David Howells Cc: Herbert Xu Cc: "David S. Miller" Cc: keyri...@vger.kernel.org Cc: linux-cry...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- crypto/asymmetric_keys/pkcs7_trust.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/asymmetric_keys/pkcs7_trust.c b/crypto/asymmetric_keys/pkcs7_trust.c index 61af3c4d82cc..b531df2013c4 100644 --- a/crypto/asymmetric_keys/pkcs7_trust.c +++ b/crypto/asymmetric_keys/pkcs7_trust.c @@ -16,7 +16,7 @@ #include #include "pkcs7_parser.h" -/** +/* * Check the trust on one PKCS#7 SignedInfo block. */ static int pkcs7_validate_trust_one(struct pkcs7_message *pkcs7, -- 2.29.GIT
[PATCH] PM / suspend: fix kernel-doc markup
Add parameter explanation to fix kernel-doc marks: kernel/power/suspend.c:233: warning: Function parameter or member 'state' not described in 'suspend_valid_only_mem' kernel/power/suspend.c:344: warning: Function parameter or member 'state' not described in 'suspend_prepare' Signed-off-by: Alex Shi Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Pavel Machek Cc: linux...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- kernel/power/suspend.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c index 32391acc806b..502d86ed99c7 100644 --- a/kernel/power/suspend.c +++ b/kernel/power/suspend.c @@ -224,6 +224,7 @@ EXPORT_SYMBOL_GPL(suspend_set_ops); /** * suspend_valid_only_mem - Generic memory-only valid callback. + * @state: Suspend state to be set * * Platform drivers that implement mem suspend only and only need to check for * that in their .valid() callback can use this instead of rolling their own @@ -335,6 +336,7 @@ static int suspend_test(int level) /** * suspend_prepare - Prepare for entering system sleep state. + * @state: suspend state which sleep from * * Common code run for every system sleep state that can be entered (except for * hibernation). Run suspend notifiers, allocate the "suspend" console and -- 2.29.GIT
回复: [PATCH] kthread_worker: Add flush delayed work func
发件人: Andrew Morton 发送时间: 2020年11月13日 8:01 收件人: Zhang, Qiang 抄送: pmla...@suse.com; t...@kernel.org; linux...@kvack.org; linux-kernel@vger.kernel.org 主题: Re: [PATCH] kthread_worker: Add flush delayed work func [Please note this e-mail is from an EXTERNAL e-mail address] On Wed, 11 Nov 2020 17:13:55 +0800 qiang.zh...@windriver.com wrote: > Add 'kthread_flush_delayed_work' func, the principle of > this func is wait for a dwork to finish executing the > last queueing. > >We'd like to see some code which actually uses this new function >please. Either in this patch or as one or more followup patches. > >btw, we call it "function", not "func". But neither is really needed - >just use () to identify a function. ie: >: Add kthread_flush_delayed_work(). The principle of this is to wait for >: a dwork to finish executing the last queueing. I don't see it being used in the kernel code so far, and I'm not sure if it's going to be used in subsequent scenarios (it like flush_delayed_work in workqueue )or whether it's currently using "kthread_work" some code needs it. Thanks Qiang
Re: [PATCH v3] gpio: sifive: To get gpio irq offset from device tree data
On Fri, Nov 13, 2020 at 3:34 AM Greentime Hu wrote: > > We can get hwirq number of the gpio by its irq_data->hwirq so that we don't > need to add more macros for different platforms. This patch is tested in > SiFive Unleashed board and SiFive Unmatched board. > > Signed-off-by: Greentime Hu > --- Please list the changes between versions of patches. What has changed since v2? Bartosz
Re: [PATCH v9 0/5] Exynos: Simple QoS for exynos-bus using interconnect
On 11/13/20 11:07, Chanwoo Choi wrote: > On 11/13/20 5:48 PM, Georgi Djakov wrote: >> On 11/12/20 16:09, Sylwester Nawrocki wrote: >>> >>> This patchset adds interconnect API support for the Exynos SoC "samsung, >>> exynos-bus" compatible devices, which already have their corresponding >>> exynos-bus driver in the devfreq subsystem. Complementing the devfreq >>> driver with an interconnect functionality allows to ensure the QoS >>> requirements of devices accessing the system memory (e.g. video processing >>> devices) are fulfilled and allows to avoid issues like the one discussed >>> in thread [1]. >>> >>> This patch series adds implementation of the interconnect provider per each >>> "samsung,exynos-bus" compatible DT node, with one interconnect node per >>> provider. The interconnect code which was previously added as a part of >>> the devfreq driver has been converted to a separate platform driver. >>> In the devfreq a corresponding virtual child platform device is registered. >>> Integration of devfreq and interconnect frameworks is achieved through >>> the PM QoS API. >>> >>> A sample interconnect consumer for exynos-mixer is added in patch 5/5, >>> it is currently added only for exynos4412 and allows to address the >>> mixer DMA underrun error issues [1]. >> >> Good work Sylwester! Thank you and all the reviewers! What would be the merge >> path for this patchset? Looks like there is no build dependency between >> patches. >> Should i take just patches 2,3 or also patch 1? Chanwoo? > > Hi Georgi, > > If you take the patch 2,3, I'll apply patch 1,4 to devfreq.git. Ok, sounds good! Thanks for clarifying! BR, Georgi
[PATCH v2 2/3] net: openvswitch: use core API to update/provide stats
Commit d3fd65484c781 ("net: core: add dev_sw_netstats_tx_add") has added
function "dev_sw_netstats_tx_add()" to update net device per-cpu TX
stats.
Use this function instead of own code.
While on it, remove internal_get_stats() and replace it
with dev_get_tstats64().
Signed-off-by: Lev Stipakov
---
v2:
- do not delete len variable and add comment why
- replace internal_get_stats() vs dev_get_tstats64()
net/openvswitch/vport-internal_dev.c | 29 +++-
1 file changed, 7 insertions(+), 22 deletions(-)
diff --git a/net/openvswitch/vport-internal_dev.c
b/net/openvswitch/vport-internal_dev.c
index 1e30d8df3ba5..5b2ee9c1c00b 100644
--- a/net/openvswitch/vport-internal_dev.c
+++ b/net/openvswitch/vport-internal_dev.c
@@ -35,21 +35,18 @@ internal_dev_xmit(struct sk_buff *skb, struct net_device
*netdev)
{
int len, err;
+ /* store len value because skb can be freed inside ovs_vport_receive()
*/
len = skb->len;
+
rcu_read_lock();
err = ovs_vport_receive(internal_dev_priv(netdev)->vport, skb, NULL);
rcu_read_unlock();
- if (likely(!err)) {
- struct pcpu_sw_netstats *tstats = this_cpu_ptr(netdev->tstats);
-
- u64_stats_update_begin(&tstats->syncp);
- tstats->tx_bytes += len;
- tstats->tx_packets++;
- u64_stats_update_end(&tstats->syncp);
- } else {
+ if (likely(!err))
+ dev_sw_netstats_tx_add(netdev, 1, len);
+ else
netdev->stats.tx_errors++;
- }
+
return NETDEV_TX_OK;
}
@@ -83,24 +80,12 @@ static void internal_dev_destructor(struct net_device *dev)
ovs_vport_free(vport);
}
-static void
-internal_get_stats(struct net_device *dev, struct rtnl_link_stats64 *stats)
-{
- memset(stats, 0, sizeof(*stats));
- stats->rx_errors = dev->stats.rx_errors;
- stats->tx_errors = dev->stats.tx_errors;
- stats->tx_dropped = dev->stats.tx_dropped;
- stats->rx_dropped = dev->stats.rx_dropped;
-
- dev_fetch_sw_netstats(stats, dev->tstats);
-}
-
static const struct net_device_ops internal_dev_netdev_ops = {
.ndo_open = internal_dev_open,
.ndo_stop = internal_dev_stop,
.ndo_start_xmit = internal_dev_xmit,
.ndo_set_mac_address = eth_mac_addr,
- .ndo_get_stats64 = internal_get_stats,
+ .ndo_get_stats64 = dev_get_tstats64,
};
static struct rtnl_link_ops internal_dev_link_ops __read_mostly = {
--
2.25.1
Re: [PATCH v1] clk: Add enable-state column to clk summary
13.11.2020 11:18, Stephen Boyd пишет: > Quoting Dmitry Osipenko (2020-11-04 08:56:31) >> Add "enable state" column to the clk summary. It's handy to know actual >> hardware state of all clocks for debugging purposes. In conjunction with >> clk_ignore_unused, this tells us what unused clocks are left on after >> bootloader without disabling the clocks. > > Should it be called "boot state" then? That idea sounds OK to me. > >> It's also s useful debugging > > Stray 's' here. > >> information for cases where firmware touches clocks. > > Care to explain more? Presumably you mean when firmware is modifying clk > state without notifying the kernel? This is exactly what I meant. > In which case it should be called > "hardware enable" or something like that and be a "Y/N/?" value > depending on if the value can be read or not and if it is enabled or not? Indeed, I like the "hardware enable", thank you for the suggestion. The "Y/N/?" suggestion is also good. I'll prepare v2, thank you for the review!
[PATCH v2 3/3] net: xfrm: use core API for updating/providing stats
Commit d3fd65484c781 ("net: core: add dev_sw_netstats_tx_add") has added
function "dev_sw_netstats_tx_add()" to update net device per-cpu TX
stats.
Use this function instead of own code.
While on it, remove xfrmi_get_stats64() and replace it with
dev_get_tstats64().
Signed-off-by: Lev Stipakov
---
v2: replace xfrmi_get_stats64() vs dev_get_tstats64()
net/xfrm/xfrm_interface.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c
index 9b8e292a7c6a..697cdcfbb5e1 100644
--- a/net/xfrm/xfrm_interface.c
+++ b/net/xfrm/xfrm_interface.c
@@ -319,12 +319,7 @@ xfrmi_xmit2(struct sk_buff *skb, struct net_device *dev,
struct flowi *fl)
err = dst_output(xi->net, skb->sk, skb);
if (net_xmit_eval(err) == 0) {
- struct pcpu_sw_netstats *tstats = this_cpu_ptr(dev->tstats);
-
- u64_stats_update_begin(&tstats->syncp);
- tstats->tx_bytes += length;
- tstats->tx_packets++;
- u64_stats_update_end(&tstats->syncp);
+ dev_sw_netstats_tx_add(dev, 1, length);
} else {
stats->tx_errors++;
stats->tx_aborted_errors++;
@@ -538,15 +533,6 @@ static int xfrmi_update(struct xfrm_if *xi, struct
xfrm_if_parms *p)
return err;
}
-static void xfrmi_get_stats64(struct net_device *dev,
- struct rtnl_link_stats64 *s)
-{
- dev_fetch_sw_netstats(s, dev->tstats);
-
- s->rx_dropped = dev->stats.rx_dropped;
- s->tx_dropped = dev->stats.tx_dropped;
-}
-
static int xfrmi_get_iflink(const struct net_device *dev)
{
struct xfrm_if *xi = netdev_priv(dev);
@@ -554,12 +540,11 @@ static int xfrmi_get_iflink(const struct net_device *dev)
return xi->p.link;
}
-
static const struct net_device_ops xfrmi_netdev_ops = {
.ndo_init = xfrmi_dev_init,
.ndo_uninit = xfrmi_dev_uninit,
.ndo_start_xmit = xfrmi_xmit,
- .ndo_get_stats64 = xfrmi_get_stats64,
+ .ndo_get_stats64 = dev_get_tstats64,
.ndo_get_iflink = xfrmi_get_iflink,
};
--
2.25.1
[PATCH v2 0/5] MIPS: ralink: add CPU clock detection and clock gate driver for MT7621
This patchset ports CPU clock detection for MT7621 from OpenWrt and adds a complete clock plan for the mt7621 SOC. The documentation for this SOC only talks about two registers regarding to the clocks: * SYSC_REG_CPLL_CLKCFG0 - provides some information about boostrapped refclock. PLL and dividers used for CPU and some sort of BUS (AHB?). * SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable clocks for all or some ip cores. No documentation about a probably existant set of dividers for each ip core is included in the datasheets. So we cannot make anything better, AFAICT. Looking into driver code, and some openWRT patched there are another frequences which are used in some drivers (uart, sd...). According to all of this information the clock plan for this SoC is set as follows: - Main top clock "xtal" from where all the rest of the world is derived. - CPU clock "cpu" derived from "xtal" frequencies and a bunch of register reads and predividers. - BUS clock "bus" derived from "cpu" and with (cpu / 4) MHz. - Fixed clocks from "xtal": * "50m": 50 MHz. * "125m": 125 MHz. * "150m": 150 MHz. * "250m": 250 MHz. * "270m": 270 MHz. We also have a buch of gate clocks with their parents: - "hsdma": "150m" - "fe": "250m" - "sp_divtx": "270m" - "timer": "50m" - "pcm": "270m" - "pio": "50m" - "gdma": "bus" - "nand": "125m" - "i2c": "50m" - "i2s": "270m" - "spi": "bus" - "uart1": "50m" - "uart2": "50m" - "uart3": "50m" - "eth": "50m" - "pcie0": "125m" - "pcie1": "125m" - "pcie2": "125m" - "crypto": "250m" - "shxc": "50m" There was a previous attempt of doing this here[0] but the author (Chuanhong Guo) did not wanted to make assumptions of a clock plan for the platform that time. It seems that now he has a better idea of how the clocks are dispossed for this SoC so he share code[1] where some frequencies and clock parents for the gates are coded from a real mediatek private clock plan. I do really want this to be upstreamed so according to the comments in previous attempt[0] from Oleksij Rempel and the frequencies in code[1] I have tried to do this by myself. All of this patches have been tested in a GNUBee PC1 resulting in a working platform. Changes in v2: - Remove the following patches: * dt: bindings: add mt7621-pll device tree binding documentation. * MIPS: ralink: add clock device providing cpu/ahb/apb clock for mt7621. - Move all relevant clock code to 'drivers/clk/ralink/clk-mt7621.c' and unify there previous 'mt7621-pll' and 'mt7621-clk' into a unique driver and binding 'mt7621-clk'. - Driver is not a platform driver anymore and now make use of 'CLK_OF_DECLARE' because we need clocks available in 'plat_time_init' before setting up the timer for the GIC. - Use new fixed clocks as parents for different gates and deriving from 'xtal' using frequencies in[1]. - Adapt dts file and bindings header and documentation for new changes. - Change MAINTAINERS file to only contains clk-mt7621.c code and mediatek,mt7621-clk.yaml file. [0]: https://www.lkml.org/lkml/2019/7/23/1044 [1]: https://github.com/981213/linux/commit/2eca1f045e4c3db18c941135464c0d7422ad8133 Sergio Paracuellos (5): dt-bindings: clock: add dt binding header for mt7621 clocks dt: bindings: add mt7621-clk device tree binding documentation clk: ralink: add clock driver for mt7621 SoC staging: mt7621-dts: make use of new 'mt7621-clk' MAINTAINERS: add MT7621 CLOCK maintainer .../bindings/clock/mediatek,mt7621-clk.yaml | 61 MAINTAINERS | 6 + drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 1 + drivers/clk/ralink/Kconfig| 14 + drivers/clk/ralink/Makefile | 2 + drivers/clk/ralink/clk-mt7621.c | 345 ++ drivers/staging/mt7621-dts/gbpc1.dts | 11 - drivers/staging/mt7621-dts/mt7621.dtsi| 72 ++-- include/dt-bindings/clock/mt7621-clk.h| 41 +++ 10 files changed, 504 insertions(+), 50 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml create mode 100644 drivers/clk/ralink/Kconfig create mode 100644 drivers/clk/ralink/Makefile create mode 100644 drivers/clk/ralink/clk-mt7621.c create mode 100644 include/dt-bindings/clock/mt7621-clk.h -- 2.25.1
[PATCH v2 1/5] dt-bindings: clock: add dt binding header for mt7621 clocks
Adds dt binding header for 'mediatek,mt7621-clk' clocks. Signed-off-by: Sergio Paracuellos --- include/dt-bindings/clock/mt7621-clk.h | 41 ++ 1 file changed, 41 insertions(+) create mode 100644 include/dt-bindings/clock/mt7621-clk.h diff --git a/include/dt-bindings/clock/mt7621-clk.h b/include/dt-bindings/clock/mt7621-clk.h new file mode 100644 index ..1422badcf9de --- /dev/null +++ b/include/dt-bindings/clock/mt7621-clk.h @@ -0,0 +1,41 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Author: Sergio Paracuellos + */ + +#ifndef _DT_BINDINGS_CLK_MT7621_H +#define _DT_BINDINGS_CLK_MT7621_H + +#define MT7621_CLK_XTAL0 +#define MT7621_CLK_CPU 1 +#define MT7621_CLK_BUS 2 +#define MT7621_CLK_50M 3 +#define MT7621_CLK_125M4 +#define MT7621_CLK_150M5 +#define MT7621_CLK_250M6 +#define MT7621_CLK_270M7 + +#define MT7621_CLK_HSDMA 8 +#define MT7621_CLK_FE 9 +#define MT7621_CLK_SP_DIVTX10 +#define MT7621_CLK_TIMER 11 +#define MT7621_CLK_PCM 12 +#define MT7621_CLK_PIO 13 +#define MT7621_CLK_GDMA14 +#define MT7621_CLK_NAND15 +#define MT7621_CLK_I2C 16 +#define MT7621_CLK_I2S 17 +#define MT7621_CLK_SPI 18 +#define MT7621_CLK_UART1 19 +#define MT7621_CLK_UART2 20 +#define MT7621_CLK_UART3 21 +#define MT7621_CLK_ETH 22 +#define MT7621_CLK_PCIE0 23 +#define MT7621_CLK_PCIE1 24 +#define MT7621_CLK_PCIE2 25 +#define MT7621_CLK_CRYPTO 26 +#define MT7621_CLK_SHXC27 + +#define MT7621_CLK_MAX 28 + +#endif /* _DT_BINDINGS_CLK_MT7621_H */ -- 2.25.1
[PATCH v2 3/5] clk: ralink: add clock driver for mt7621 SoC
The documentation for this SOC only talks about two registers regarding to the clocks: * SYSC_REG_CPLL_CLKCFG0 - provides some information about boostrapped refclock. PLL and dividers used for CPU and some sort of BUS. * SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable clocks for all or some ip cores. Looking into driver code, and some openWRT patched there are another frequences which are used in some drivers (uart, sd...). According to all of this information the clock plan for this SoC is set as follows: - Main top clock "xtal" from where all the rest of the world is derived. - CPU clock "cpu" derived from "xtal" frequencies and a bunch of register reads and predividers. - BUS clock "bus" derived from "cpu" and with (cpu / 4) MHz. - Fixed clocks from "xtal": * "50m": 50 MHz. * "125m": 125 MHz. * "150m": 150 MHz. * "250m": 250 MHz. * "270m": 270 MHz. We also have a buch of gate clocks with their parents: * "hsdma": "150m" * "fe": "250m" * "sp_divtx": "270m" * "timer": "50m" * "pcm": "270m" * "pio": "50m" * "gdma": "bus" * "nand": "125m" * "i2c": "50m" * "i2s": "270m" * "spi": "bus" * "uart1": "50m" * "uart2": "50m" * "uart3": "50m" * "eth": "50m" * "pcie0": "125m" * "pcie1": "125m" * "pcie2": "125m" * "crypto": "250m" * "shxc": "50m" With this information the clk driver will provide clock and gates functionality from a a set of hardcoded clocks allowing to define a nice device tree without fixed clocks. Signed-off-by: Sergio Paracuellos --- drivers/clk/Kconfig | 1 + drivers/clk/Makefile| 1 + drivers/clk/ralink/Kconfig | 14 ++ drivers/clk/ralink/Makefile | 2 + drivers/clk/ralink/clk-mt7621.c | 345 5 files changed, 363 insertions(+) create mode 100644 drivers/clk/ralink/Kconfig create mode 100644 drivers/clk/ralink/Makefile create mode 100644 drivers/clk/ralink/clk-mt7621.c diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index c715d4681a0b..5f94c4329033 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -372,6 +372,7 @@ source "drivers/clk/mediatek/Kconfig" source "drivers/clk/meson/Kconfig" source "drivers/clk/mvebu/Kconfig" source "drivers/clk/qcom/Kconfig" +source "drivers/clk/ralink/Kconfig" source "drivers/clk/renesas/Kconfig" source "drivers/clk/rockchip/Kconfig" source "drivers/clk/samsung/Kconfig" diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index da8fcf147eb1..6578e167b047 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -100,6 +100,7 @@ obj-$(CONFIG_COMMON_CLK_NXP)+= nxp/ obj-$(CONFIG_MACH_PISTACHIO) += pistachio/ obj-$(CONFIG_COMMON_CLK_PXA) += pxa/ obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/ +obj-y += ralink/ obj-y += renesas/ obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/ obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/ diff --git a/drivers/clk/ralink/Kconfig b/drivers/clk/ralink/Kconfig new file mode 100644 index ..7e8697327e0c --- /dev/null +++ b/drivers/clk/ralink/Kconfig @@ -0,0 +1,14 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# MediaTek Mt7621 Clock Driver +# +menu "Clock driver for mediatek mt7621 SoC" + depends on SOC_MT7621 || COMPILE_TEST + +config CLK_MT7621 + bool "Clock driver for MediaTek MT7621" + depends on SOC_MT7621 || COMPILE_TEST + default SOC_MT7621 + help + This driver supports MediaTek MT7621 basic clocks. +endmenu diff --git a/drivers/clk/ralink/Makefile b/drivers/clk/ralink/Makefile new file mode 100644 index ..cf6f9216379d --- /dev/null +++ b/drivers/clk/ralink/Makefile @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0 +obj-$(CONFIG_CLK_MT7621) += clk-mt7621.o diff --git a/drivers/clk/ralink/clk-mt7621.c b/drivers/clk/ralink/clk-mt7621.c new file mode 100644 index ..03ad27048053 --- /dev/null +++ b/drivers/clk/ralink/clk-mt7621.c @@ -0,0 +1,345 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Mediatek MT7621 Clock Driver + * Author: Sergio Paracuellos + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +/* Configuration registers */ +#define SYSC_REG_SYSTEM_CONFIG0 0x10 +#define SYSC_REG_SYSTEM_CONFIG1 0x14 +#define SYSC_REG_CLKCFG0 0x2c +#define SYSC_REG_CLKCFG1 0x30 +#define SYSC_REG_CUR_CLK_STS 0x44 + +#define MEMC_REG_CPU_PLL 0x648 +#define XTAL_MODE_SEL_MASK 0x7 +#define XTAL_MODE_SEL_SHIFT6 + +#define CPU_CLK_SEL_MASK 0x3 +#define CPU_CLK_SEL_SHIFT 30 + +#define CUR_CPU_FDIV_MASK 0x1f +#define CUR_CPU_FDIV_SHIFT 8 +#define CUR_CPU_FFRAC_MASK 0x1f +#define CUR_CPU_FFRAC_SHIFT0 + +#define CPU_PLL_PREDIV_MASK0x3 +#define CPU_PLL_PREDIV_SHIFT
[PATCH v2 2/5] dt: bindings: add mt7621-clk device tree binding documentation
Adds device tree binding documentation for clocks in the
MT7621 SOC.
Signed-off-by: Sergio Paracuellos
---
.../bindings/clock/mediatek,mt7621-clk.yaml | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
new file mode 100644
index ..363bd9880e29
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/mediatek,mt7621-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MT7621 Clock Device Tree Bindings
+
+maintainers:
+ - Sergio Paracuellos
+
+description: |
+ The MT7621 has a PLL controller from where the cpu clock is provided
+ as well as derived clocks for the bus and the peripherals. It also
+ can gate SoC device clocks.
+
+ Each clock is assigned an identifier and client nodes use this identifier
+ to specify the clock which they consume.
+
+ All these identifiers could be found in:
+ [1]: .
+
+properties:
+ compatible:
+const: mediatek,mt7621-clk
+
+ ralink,sysctl:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ phandle to the syscon which is in the same address area with syscon
+ device.
+
+ "#clock-cells":
+description:
+ The first cell indicates the clock gate number, see [1] for available
+ clocks.
+const: 1
+
+ clock-output-names:
+maxItems: 8
+
+required:
+ - compatible
+ - ralink,sysctl
+ - '#clock-cells'
+ - clock-output-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+pll {
+ compatible = "mediatek,mt7621-clk";
+ ralink,sysctl = <&sysc>;
+ #clock-cells = <1>;
+ clock-output-names = "xtal", "cpu", "bus",
+ "50m", "125m", "150m",
+ "225m", "250m";
+};
--
2.25.1
[PATCH v2 5/5] MAINTAINERS: add MT7621 CLOCK maintainer
Adding myself as maintainer for mt7621 clock driver. Signed-off-by: Sergio Paracuellos --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f1f088a29bc2..30822ad6837c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11142,6 +11142,12 @@ L: linux-wirel...@vger.kernel.org S: Maintained F: drivers/net/wireless/mediatek/mt7601u/ +MEDIATEK MT7621 CLOCK DRIVER +M: Sergio Paracuellos +S: Maintained +F: Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yaml +F: drivers/clk/ralink/clk-mt7621.c + MEDIATEK MT7621/28/88 I2C DRIVER M: Stefan Roese L: linux-...@vger.kernel.org -- 2.25.1
[PATCH v2 4/5] staging: mt7621-dts: make use of new 'mt7621-clk'
Clocks for SoC mt7621 have been properly integrated so there is
no need to declare fixed clocks at all in the device tree. Remove
all of them, add new device tree nodes for mt7621-clk and update
the rest of the nodes to use them.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-dts/gbpc1.dts | 11
drivers/staging/mt7621-dts/mt7621.dtsi | 72 --
2 files changed, 33 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/mt7621-dts/gbpc1.dts
b/drivers/staging/mt7621-dts/gbpc1.dts
index a7c0d3115d72..7716d0efe524 100644
--- a/drivers/staging/mt7621-dts/gbpc1.dts
+++ b/drivers/staging/mt7621-dts/gbpc1.dts
@@ -100,17 +100,6 @@ partition@5 {
};
};
-&sysclock {
- compatible = "fixed-clock";
- /* This is normally 1/4 of cpuclock */
- clock-frequency = <22500>;
-};
-
-&cpuclock {
- compatible = "fixed-clock";
- clock-frequency = <9>;
-};
-
&pcie {
pinctrl-names = "default";
pinctrl-0 = <&pcie_pins>;
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 82aa93634eda..f64e66de4bf7 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -1,5 +1,6 @@
#include
#include
+#include
/ {
#address-cells = <1>;
@@ -27,26 +28,13 @@ aliases {
serial0 = &uartlite;
};
- cpuclock: cpuclock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
-
- /* FIXME: there should be way to detect this */
- clock-frequency = <88000>;
- };
-
- sysclock: sysclock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
-
- /* This is normally 1/4 of cpuclock */
- clock-frequency = <22000>;
- };
-
- mmc_clock: mmc_clock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <4800>;
+ pll: pll {
+ compatible = "mediatek,mt7621-clk";
+ ralink,sysctl = <&sysc>;
+ #clock-cells = <1>;
+ clock-output-names = "xtal", "cpu", "bus",
+"50m", "125m", "150m",
+"225m", "250m";
};
mmc_fixed_3v3: fixedregulator@0 {
@@ -76,7 +64,7 @@ palmbus: palmbus@1E00 {
#size-cells = <1>;
sysc: sysc@0 {
- compatible = "mtk,mt7621-sysc";
+ compatible = "mtk,mt7621-sysc", "syscon";
reg = <0x0 0x100>;
};
@@ -100,8 +88,8 @@ i2c: i2c@900 {
compatible = "mediatek,mt7621-i2c";
reg = <0x900 0x100>;
- clocks = <&sysclock>;
-
+ clocks = <&pll MT7621_CLK_I2C>;
+ clock-names = "i2c";
resets = <&rstctrl 16>;
reset-names = "i2c";
@@ -118,8 +106,8 @@ i2s: i2s@a00 {
compatible = "mediatek,mt7621-i2s";
reg = <0xa00 0x100>;
- clocks = <&sysclock>;
-
+ clocks = <&pll MT7621_CLK_I2S>;
+ clock-names = "i2s";
resets = <&rstctrl 17>;
reset-names = "i2s";
@@ -155,8 +143,8 @@ uartlite: uartlite@c00 {
compatible = "ns16550a";
reg = <0xc00 0x100>;
- clocks = <&sysclock>;
- clock-frequency = <5000>;
+ clocks = <&pll MT7621_CLK_UART1>;
+ clock-names = "uart1";
interrupt-parent = <&gic>;
interrupts = ;
@@ -172,7 +160,7 @@ spi0: spi@b00 {
compatible = "ralink,mt7621-spi";
reg = <0xb00 0x100>;
- clocks = <&sysclock>;
+ clocks = <&pll MT7621_CLK_SPI>;
resets = <&rstctrl 18>;
reset-names = "spi";
@@ -188,6 +176,8 @@ gdma: gdma@2800 {
compatible = "ralink,rt3883-gdma";
reg = <0x2800 0x800>;
+ clocks = <&pll MT7621_CLK_GDMA>;
+ clock-names = "gdma";
resets = <&rstctrl 14>;
reset-names = "dma";
@@ -205,6 +195,8 @@ hsdma: hsdma@7000 {
compatible = "mediatek,mt7621-hsdma";
reg = <0x7000 0x1000>;
+ clocks = <&pll MT7621_CLK_HSDMA>;
+ clock-names = "hsdma";
resets = <&rstctrl 5>;
RE: linux-next: build failure after merge of the usb-chipidea-next tree
> > After merging the usb-chipidea-next tree, today's linux-next build (powerpc > allyesconfig) failed like this: > > In file included from drivers/usb/chipidea/trace.h:18, > from drivers/usb/chipidea/trace.c:11: > drivers/usb/chipidea/ci.h: In function 'ci_otg_is_fsm_mode': > drivers/usb/chipidea/ci.h:440:47: error: invalid use of undefined type 'struct > ci_hdrc_platform_data' > 440 | struct usb_otg_caps *otg_caps = &ci->platdata->ci_otg_caps; > | ^~ > Thanks, I fixed it today. Peter
[PATCH net v2] net: phy: mscc: remove non-MACSec compatible phy
Selecting VSC8575 as a MACSec PHY was not correct
The relevant datasheet can be found here:
- VSC8575: https://www.microchip.com/wwwproducts/en/VSC8575
History:
v1 -> v2:
- Corrected the sha in the "Fixes:" tag
Fixes: 1bbe0ecc2a1a ("net: phy: mscc: macsec initialization")
Signed-off-by: Steen Hegelund
---
drivers/net/phy/mscc/mscc_macsec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/phy/mscc/mscc_macsec.c
b/drivers/net/phy/mscc/mscc_macsec.c
index 1d4c012194e9..72292bf6c51c 100644
--- a/drivers/net/phy/mscc/mscc_macsec.c
+++ b/drivers/net/phy/mscc/mscc_macsec.c
@@ -981,7 +981,6 @@ int vsc8584_macsec_init(struct phy_device *phydev)
switch (phydev->phy_id & phydev->drv->phy_id_mask) {
case PHY_ID_VSC856X:
- case PHY_ID_VSC8575:
case PHY_ID_VSC8582:
case PHY_ID_VSC8584:
INIT_LIST_HEAD(&vsc8531->macsec_flows);
--
2.29.2
Re: [PATCH v9 2/3] pinctrl: pinctrl-microchip-sgpio: Add pinctrl driver for Microsemi Serial GPIO
Andy Shevchenko writes:
> On Wed, Nov 11, 2020 at 2:25 PM Lars Povlsen
> wrote:
>>
>> This adds a pinctrl driver for the Microsemi/Microchip Serial GPIO
>> (SGPIO) device used in various SoC's.
>>
>> The driver is added as a pinctrl driver, albeit only having just GPIO
>> support currently. The hardware supports other functions that will be
>> added following.
>
> Thanks for an update!
> Seems closer to the final. My comments below.
Well I am certainly glad to hear that!
>
> ...
>
>> + * Author:
>
> No First Name Last Name?
>
I'll add that.
> ...
>
>> +static int sgpio_output_get(struct sgpio_priv *priv,
>> + struct sgpio_port_addr *addr)
>> +{
>> + u32 val, portval = sgpio_readl(priv, REG_PORT_CONFIG, addr->port);
>> + unsigned int bit = SGPIO_SRC_BITS * addr->bit;
>> +
>> + switch (priv->properties->arch) {
>> + case SGPIO_ARCH_LUTON:
>> + val = FIELD_GET(SGPIO_LUTON_BIT_SOURCE, portval);
>> + break;
>> + case SGPIO_ARCH_OCELOT:
>> + val = FIELD_GET(SGPIO_OCELOT_BIT_SOURCE, portval);
>> + break;
>> + case SGPIO_ARCH_SPARX5:
>> + val = FIELD_GET(SGPIO_SPARX5_BIT_SOURCE, portval);
>> + break;
>> + default:
>> + val = 0;
>
> Missed break; statement.
Fine.
>
>> + }
>> + return !!(val & BIT(bit));
>> +}
>
> ...
>
>> +static const struct pinconf_ops sgpio_confops = {
>> + .is_generic = true,
>> + .pin_config_get = sgpio_pinconf_get,
>> + .pin_config_set = sgpio_pinconf_set,
>
>> + .pin_config_config_dbg_show = pinconf_generic_dump_config,
>
> Do you need this? I mean isn't it default by pin core?
No, I see other drivers also setting this up explicitly.
>
>> +};
>
> ...
>
>> +static int sgpio_gpio_request_enable(struct pinctrl_dev *pctldev,
>> +struct pinctrl_gpio_range *range,
>> +unsigned int offset)
>> +{
>> + struct sgpio_bank *bank = pinctrl_dev_get_drvdata(pctldev);
>> + struct sgpio_priv *priv = bank->priv;
>> + struct sgpio_port_addr addr;
>> +
>> + sgpio_pin_to_addr(priv, offset, &addr);
>> +
>> + if ((priv->ports & BIT(addr.port)) == 0) {
>> + dev_warn(priv->dev, "Request port %d.%d: Port is not
>> enabled\n",
>> +addr.port, addr.bit);
>> + }
>> +
>> + return 0;
>
> I believe this function also does some sanity checks. Perhaps you need
> to call a generic one.
> Hence check what should be done in the tear down case.
>
This checks whether the requested signal is actually enabled in the
bitstream. If it is not, it will trigger a warning message. I recon it
should also signal this with the error code, so I'll add that.
Generic code does not have knowledge about the bit stream configuration
(priv->ports), so it can't check for that.
>> +}
>
> ...
>
>> + if (priv->in.gpio.ngpio != priv->out.gpio.ngpio) {
>> + dev_err(dev, "Banks must have same GPIO count\n");
>> + return -EINVAL;
>
> -ERANGE?
We can do that.
>
>> + }
Thanks,
---Lars
--
Lars Povlsen,
Microchip
[PATCH 3/2] checkpatch: document the function renaming and deprecation around devm_ioremap_resource
Signed-off-by: Uwe Kleine-König --- Hello, this can also be squashed into the respective patches instead. Best regards Uwe scripts/checkpatch.pl | 5 + 1 file changed, 5 insertions(+) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index fab38b493cef..5abb87256d4c 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -615,6 +615,11 @@ our %deprecated_apis = ( "rcu_barrier_sched" => "rcu_barrier", "get_state_synchronize_sched" => "get_state_synchronize_rcu", "cond_synchronize_sched"=> "cond_synchronize_rcu", + "devm_platform_get_and_ioremap_resource" => "devm_platform_get_request_and_ioremap_resource", + "devm_platform_ioremap_resource"=> "devm_platform_request_ioremap_resource", + "devm_platform_ioremap_resource_wc" => "devm_platform_request_ioremap_resource_wc", + "devm_ioremap_resource" => "devm_request_ioremap_resource", + "devm_ioremap_resource_wc" => "devm_request_ioremap_resource_wc", ); #Create a search pattern for all these strings to speed up a loop below -- 2.28.0
Re: About devm_platform_ioremap_resource [Was: Re: [PATCH 01/32] pwm: sun4i: convert to devm_platform_ioremap_resource]
On Fri, Nov 13, 2020 at 8:04 AM Uwe Kleine-König
wrote:
>
> Hello,
>
> [Added lkml and the people involved in commit 7945f929f1a7
> ("drivers: provide devm_platform_ioremap_resource()") to Cc:. For the
> new readers: This is about patches making use of
> devm_platform_ioremap_resource() instead of open coding it. Full context
> at https://lore.kernel.org/r/20201112190649.GA908613@ulmo]
>
> On Thu, Nov 12, 2020 at 10:14:29PM +0100, Uwe Kleine-König wrote:
> > On Thu, Nov 12, 2020 at 08:06:49PM +0100, Thierry Reding wrote:
> > > I also think that it's overly narrow is scope, so you can't actually
> > > "blindly" use this helper and I've seen quite a few cases where this was
> > > unknowingly used for cases where it shouldn't have been used and then
> > > broke things (because some drivers must not do the request_mem_region()
> > > for example).
> >
> > You have a link to such an accident?
>
> I got a hint in private here:
> https://lore.kernel.org/r/1555670144-24220-1-git-send-email-aisheng.d...@nxp.com
>
> devm_platform_ioremap_resource() is platform_get_resource() +
> devm_ioremap_resource() and here it was used to replace
> platform_get_resource() + devm_ioremap().
>
> IMHO the unlucky thing in this situation is that devm_ioremap_resource()
> and devm_ioremap() are different by more than just how they get the area
> to remap. (i.e. devm_ioremap_resource() also does
> devm_request_mem_region().)
>
> So the problem is not the added wrapper, but unclear semantics in the
> functions it uses. In my eyes devm_ioremap() and
> devm_platform_ioremap_resource() should better be named
> devm_request_ioremap() and devm_platform_request_ioremap_resource()
> respectively. Is it worth to rename these for clearity?
But devm_ioremap() doesn't request the region. Did you mean
devm_ioremap_resource() should become devm_request_ioremap_resource()?
Bartosz
RE: [PATCH] crypto: crypto4xx - Replace bitwise OR with logical OR in crypto4xx_build_pd
From: Nathan Chancellor
> Sent: 12 November 2020 21:49
>
> On Thu, Nov 12, 2020 at 10:21:35PM +0100, Christian Lamparter wrote:
> > Hello,
> >
> > On 12/11/2020 21:07, Nathan Chancellor wrote:
> > > Clang warns:
> > >
> > > drivers/crypto/amcc/crypto4xx_core.c:921:60: warning: operator '?:' has
> > > lower precedence than '|'; '|' will be evaluated first
> > > [-Wbitwise-conditional-parentheses]
> > > (crypto_tfm_alg_type(req->tfm) == CRYPTO_ALG_TYPE_AEAD)
> > > ?
> > > ~~~
> > > ^
> > > drivers/crypto/amcc/crypto4xx_core.c:921:60: note: place parentheses
> > > around the '|' expression to silence this warning
> > > (crypto_tfm_alg_type(req->tfm) == CRYPTO_ALG_TYPE_AEAD)
> > > ?
> > >
> > > ^
> > > )
> > > drivers/crypto/amcc/crypto4xx_core.c:921:60: note: place parentheses
> > > around the '?:' expression to evaluate it first
> > > (crypto_tfm_alg_type(req->tfm) == CRYPTO_ALG_TYPE_AEAD)
> > > ?
> > >
> > > ^
> > > (
> > > 1 warning generated.
> > >
> > > It looks like this should have been a logical OR so that
> > > PD_CTL_HASH_FINAL gets added to the w bitmask if crypto_tfm_alg_type
> > > is either CRYPTO_ALG_TYPE_AHASH or CRYPTO_ALG_TYPE_AEAD.
> > Yes. This probably wasn't spotted earlier since the driver doesn't make
> > use of CRYPTO_ALG_TYPE_AHASH (yet). This is because the hash accelerator
> > setup cost was never worth it.
> >
> > > Change the operator so that everything works properly.
> > I'm curious if this is true. Is there a way to break this somehow on
> > purpose?
>
> I do not really have a way to validate that statement, I just figured
> that the operator being wrong meant that something could go wrong that
> was not intended.
>
> > I've extracted the code from line 921 and added the defines
> > (the CRYPTO_ALG_... from the current 5.10-rc3 crypto.h and the PD_CTL_
> > from crypto4xx_reg_def.h) and replaced the u32 with uint32_t
> > so it runs in userspace too:
> >
> > --- crypto4xx_test.c ---
> > /* test study - is it possible to break the | vs || in crypto4xx's code */
> >
> > #include
> > #include
> >
> > #define CRYPTO_ALG_TYPE_AEAD0x0003
> > #define CRYPTO_ALG_TYPE_AHASH 0x000f
> > #define PD_CTL_HASH_FINAL (1<<4) /* Stand-in for BIT(4) */
> > #define PD_CTL_HOST_READY (1<<0) /* BIT(0) */
> >
> > uint32_t func_with_bitwise_or(uint32_t alg_type)
> > {
> > return PD_CTL_HOST_READY |
> > ((alg_type == CRYPTO_ALG_TYPE_AHASH) |
> > (alg_type == CRYPTO_ALG_TYPE_AEAD) ?
> > PD_CTL_HASH_FINAL : 0);
> > }
>
> Looking at this more, I think the only reason that the code works as is
> is because PD_CTL_HOST_READY is 1 AND CRYPTO_ALG_TYPE_AHASH is not used.
>
> (alg_type == CRYPTO_ALG_TYPE_AEAD) ? PD_CTL_HASH_FINAL : 0 is evaluated
> first, which results in either PD_CTL_HASH_FINAL or 0.
>
> Then (alg_type == CRYPTO_ALG_TYPE_AHASH) is evaluated, which is
> evaluated to either 0 or 1.
>
> Then we mask everything together:
>
> PD_CTL_HOST_READY | (0 || 1) | (PD_CTL_HOST_READY || 0)
The result is the same for both | and || as they are both higher
priority than ?: (which is only higher priority than ,).
The () around the == aren't needed (except to stop the compiler
bleating). The bitwise | is lower priority than == because it
existed before || and K&R didn't change the priority when they
added || (I think they've said later they wished they had.)
The () around the entire ?: clause are needed.
So the code is the same as:
rval = PD_CTL_HOST_READY;
if (alg_type == CRYPTO_ALG_TYPE_AHASH | alg_type ==
CRYPTO_ALG_TYPE_AEAD)
rval |= PD_CTL_HASH_FINAL;
return rval;
Using | may well generate faster code (no branches).
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: [PATCH] usb/mos7720: process deferred urbs in a workqueue
Sorry about the late reply.
On Thu, Nov 05, 2020 at 10:17:13PM -0800, Davidlohr Bueso wrote:
> On Thu, 05 Nov 2020, Johan Hovold wrote:
> >On Wed, Nov 04, 2020 at 04:13:07PM -0800, Davidlohr Bueso wrote:
> >> Also, but not strictly related to this. What do you think of deferring all
> >> work in write_parport_reg_nonblock() unconditionally? I'd like to avoid
> >> that mutex_trylock() because eventually I'll be re-adding a warn in the
> >> locking code, but that would also simplify the code done here in the
> >> nonblocking irq write. I'm not at all familiar with parport, but I would
> >> think that restore_state context would not care.
> >
> >Sounds good to me. As long as the state is restored before submitting
> >further requests we should be fine. That would even allow getting rid of
> >write_parport_reg_nonblock() as you can restore the state using
> >synchronous calls from the worker thread. Should simplify things quite a
> >bit.
>
> What about something like the below (probably buggy)? I avoided messing with
> the completion in the work callback, like what prologue/epilogue does for all
> other synchronous calls, because when releasing we sync the work anyway and we
> need to account for scenarios where the work is scheduled but yet not running,
> so it would not be the best fit. And this also makes the flush_work() always
> wait for both writes, otherwise I was having the thread locklessly busy-wait
> on a flag that was set until both write_parport_reg_nonblock() calls returned
> before the flush such that all potential scheduled work was observed. Unless
> I missed something, the cleanup is considerable.
Yeah, I wouldn't bother with the completion, looks broken anyway as
nothing prevent two parport calls from interfering with each other it
seems.
[...]
> /*
> * This is the the common top part of all parallel port callback operations
> that
> * send synchronous messages to the device. This implements convoluted
> locking
> @@ -458,6 +281,10 @@ static int parport_prologue(struct parport *pp)
> reinit_completion(&mos_parport->syncmsg_compl);
> spin_unlock(&release_lock);
>
> + /* ensure writes from restore are submitted before new requests */
> + if (work_pending(&mos_parport->work))
> + flush_work(&mos_parport->work);
> +
> mutex_lock(&mos_parport->serial->disc_mutex);
> if (mos_parport->serial->disconnected) {
> /* device disconnected */
> @@ -482,6 +309,28 @@ static inline void parport_epilogue(struct parport *pp)
> complete(&mos_parport->syncmsg_compl);
> }
>
> +static void deferred_restore_writes(struct work_struct *work)
> +{
> + struct mos7715_parport *mos_parport;
> +
> + mos_parport = container_of(work, struct mos7715_parport, work);
> +
> + mutex_lock(&mos_parport->serial->disc_mutex);
> +
> + /* if device disconnected, game over */
> + if (mos_parport->serial->disconnected) {
> + mutex_unlock(&mos_parport->serial->disc_mutex);
> + return;
> + }
> +
> + write_mos_reg(mos_parport->serial, dummy, MOS7720_DCR,
> + mos_parport->shadowDCR);
> + write_mos_reg(mos_parport->serial, dummy, MOS7720_ECR,
> + mos_parport->shadowECR);
> + kref_put(&mos_parport->ref_count, destroy_mos_parport);
> + mutex_unlock(&mos_parport->serial->disc_mutex);
> +}
> +
> static void parport_mos7715_write_data(struct parport *pp, unsigned char d)
> {
> struct mos7715_parport *mos_parport = pp->private_data;
> @@ -639,12 +488,12 @@ static void parport_mos7715_restore_state(struct
> parport *pp,
> spin_unlock(&release_lock);
> return;
> }
> + kref_get(&mos_parport->ref_count);
I think can do away with the reference count too as you flush the work
before dropping the final reference in release().
> mos_parport->shadowDCR = s->u.pc.ctr;
> mos_parport->shadowECR = s->u.pc.ecr;
> - write_parport_reg_nonblock(mos_parport, MOS7720_DCR,
> -mos_parport->shadowDCR);
> - write_parport_reg_nonblock(mos_parport, MOS7720_ECR,
> -mos_parport->shadowECR);
> +
> + /* defer synchronous writes outside of irq */
> + schedule_work(&mos_parport->work);
> spin_unlock(&release_lock);
> }
>
> @@ -714,12 +563,9 @@ static int mos7715_parport_init(struct usb_serial
> *serial)
>
> mos_parport->msg_pending = false;
> kref_init(&mos_parport->ref_count);
> - spin_lock_init(&mos_parport->listlock);
> - INIT_LIST_HEAD(&mos_parport->active_urbs);
> - INIT_LIST_HEAD(&mos_parport->deferred_urbs);
> usb_set_serial_data(serial, mos_parport); /* hijack private pointer */
> mos_parport->serial = serial;
> - tasklet_setup(&mos_parport->urb_tasklet, send_deferred_urbs);
> + INIT_WORK(&mos_parport->work, deferred_restore_writes);
> init_completion(&mos_parport->syncmsg_compl);
>
> /* c
[PATCH] iio: adc: ad7887: convert probe to device-managed functions
This is conversion of the driver to use device-managed functions.
The IIO registration and triggered buffer setup both have device-managed
versions.
The regulator disable needs to be handled via an action_or_reset handler.
With these changes, the remove hook is removed, and the error path is
cleaned up in probe.
Signed-off-by: Alexandru Ardelean
---
drivers/iio/adc/ad7887.c | 43 ++--
1 file changed, 15 insertions(+), 28 deletions(-)
diff --git a/drivers/iio/adc/ad7887.c b/drivers/iio/adc/ad7887.c
index 99a480ad3985..4f6f0e0e03ee 100644
--- a/drivers/iio/adc/ad7887.c
+++ b/drivers/iio/adc/ad7887.c
@@ -232,6 +232,13 @@ static const struct iio_info ad7887_info = {
.read_raw = &ad7887_read_raw,
};
+static void ad7887_reg_disable(void *data)
+{
+ struct regulator *reg = data;
+
+ regulator_disable(reg);
+}
+
static int ad7887_probe(struct spi_device *spi)
{
struct ad7887_platform_data *pdata = spi->dev.platform_data;
@@ -258,6 +265,10 @@ static int ad7887_probe(struct spi_device *spi)
ret = regulator_enable(st->reg);
if (ret)
return ret;
+
+ ret = devm_add_action_or_reset(&spi->dev, ad7887_reg_disable,
st->reg);
+ if (ret)
+ return ret;
}
st->chip_info =
@@ -316,36 +327,13 @@ static int ad7887_probe(struct spi_device *spi)
indio_dev->num_channels = st->chip_info->num_channels;
}
- ret = iio_triggered_buffer_setup(indio_dev, &iio_pollfunc_store_time,
+ ret = devm_iio_triggered_buffer_setup(&spi->dev, indio_dev,
+ &iio_pollfunc_store_time,
&ad7887_trigger_handler, &ad7887_ring_setup_ops);
if (ret)
- goto error_disable_reg;
-
- ret = iio_device_register(indio_dev);
- if (ret)
- goto error_unregister_ring;
-
- return 0;
-error_unregister_ring:
- iio_triggered_buffer_cleanup(indio_dev);
-error_disable_reg:
- if (st->reg)
- regulator_disable(st->reg);
-
- return ret;
-}
-
-static int ad7887_remove(struct spi_device *spi)
-{
- struct iio_dev *indio_dev = spi_get_drvdata(spi);
- struct ad7887_state *st = iio_priv(indio_dev);
-
- iio_device_unregister(indio_dev);
- iio_triggered_buffer_cleanup(indio_dev);
- if (st->reg)
- regulator_disable(st->reg);
+ return ret;
- return 0;
+ return devm_iio_device_register(&spi->dev, indio_dev);
}
static const struct spi_device_id ad7887_id[] = {
@@ -359,7 +347,6 @@ static struct spi_driver ad7887_driver = {
.name = "ad7887",
},
.probe = ad7887_probe,
- .remove = ad7887_remove,
.id_table = ad7887_id,
};
module_spi_driver(ad7887_driver);
--
2.27.0
[PATCH] Remove unnecessary invoking of wbt_update_limits in wbt_init
From: Lei Chen It's unnecessary to call wbt_update_limits explicitly within wbt_init, because it will be called in the following function wbt_queue_depth_changed. Signed-off-by: Lei Chen --- block/blk-wbt.c | 1 - 1 file changed, 1 deletion(-) diff --git a/block/blk-wbt.c b/block/blk-wbt.c index fd41008..0321ca8 100644 --- a/block/blk-wbt.c +++ b/block/blk-wbt.c @@ -835,7 +835,6 @@ int wbt_init(struct request_queue *q) rwb->enable_state = WBT_STATE_ON_DEFAULT; rwb->wc = 1; rwb->rq_depth.default_depth = RWB_DEF_DEPTH; - wbt_update_limits(rwb); /* * Assign rwb and add the stats callback. -- 1.8.3.1
Re: [PATCH] MIPS: reserve the memblock right after the kernel
Hello Serge, Thomas,
On 11/11/2020 15:52, Serge Semin wrote:
>>> Could you send a patch, which removes check_kernel_section_mem completly ?
finally I think you are right and this would be the right way.
>> this will expose one issue:
>> platforms usually do it in a sane way, like it was done last 15 years, namely
>> add kernel image without non-complete pages on the boundaries.
>> This will lead to the situation, that request_resource() will fail at least
>> for .bss section of the kernel and it will not be properly displayed under
>> /proc/iomem (and probably same problem will appear, which initially motivated
>> the creation of check_kernel_section_mem()).
>
> Are you saying that some old platforms rely on the
> check_kernel_section_mem() method adding the memory occupied by the
> kernel to the system? If so, do you have an example of such?
Initially I was confused why the below patch didn't solve the issue on Octeon:
@@ -532,8 +532,8 @@ static void __init request_crashkernel(struct resource *res)
static void __init check_kernel_sections_mem(void)
{
- phys_addr_t start = PFN_PHYS(PFN_DOWN(__pa_symbol(&_text)));
- phys_addr_t size = PFN_PHYS(PFN_UP(__pa_symbol(&_end))) - start;
+ phys_addr_t start = __pa_symbol(&_text);
+ phys_addr_t size = __pa_symbol(&_end) - start;
... and finally I understood, that the reason was in fact that I tested on Linux
v5.4, which still had this code to reserve RAM resources:
for_each_memblock(memory, region) {
phys_addr_t start =
PFN_PHYS(memblock_region_memory_base_pfn(region));
phys_addr_t end =
PFN_PHYS(memblock_region_memory_end_pfn(region)) - 1;
struct resource *res;
...
res->start = start;
res->end = end;
res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
res->name = "System RAM";
request_resource(&iomem_resource, res);
so I suppose that's where this evil truncation happened. Nowdays this is
different
and I believe we can try to remove check_kernel_sections_mem() completely and
this will solve the memory corruption on Octeon.
> So IMHO what could be the best conclusion in the framework of this patch:
> 1) As Thomas said any platform-specific reservation should be done in the
> platform-specific code. That means if octeon needs some memory behind
> the kernel being reserved, then it should be done for example in
> prom_init().
> 2) The check_kernel_sections_mem() method can be removed. But it
> should be done carefully. We at least need to try to find all the
> platforms, which rely on its functionality.
Thanks for looking into this! I agree with your analysis, I'll try to rework,
removing check_kernel_sections_mem().
--
Best regards,
Alexander Sverdlin.
Re: [PATCH] Input: add new touchpad driver for Zinitix IC
[Fixed Warnings.]
Add new touchpad driver for Zinitix IC
Supports five fingers multi-touch and firmware updates.
It communicates with the device via an I2C bus.
Signed-off-by : KwangDeok Son
---
diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index d8b6a5dab190..effd1b019b02 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -457,4 +457,15 @@ config MOUSE_NAVPOINT_PXA27x
To compile this driver as a module, choose M here: the
module will be called navpoint.
+config MOUSE_ZINITIX_I2C
+ tristate "ZINITIX I2C Touchpad support"
+ depends on I2C
+ help
+ This driver adds support for Zinitix I2C Touchpad.
+
+ Say Y here if you have a Zinitix I2C Touchpad.
+
+ To compile this driver as a module, choose M here: the module will be
+ called zinitix_i2c.
+
endif
diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
index e49f08565076..93ffa556a311 100644
--- a/drivers/input/mouse/Makefile
+++ b/drivers/input/mouse/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_MOUSE_SERIAL)+= sermouse.o
obj-$(CONFIG_MOUSE_SYNAPTICS_I2C) += synaptics_i2c.o
obj-$(CONFIG_MOUSE_SYNAPTICS_USB) += synaptics_usb.o
obj-$(CONFIG_MOUSE_VSXXXAA)+= vsxxxaa.o
+obj-$(CONFIG_MOUSE_ZINITIX_I2C)+= zinitix_i2c.o
cyapatp-objs := cyapa.o cyapa_gen3.o cyapa_gen5.o cyapa_gen6.o
psmouse-objs := psmouse-base.o synaptics.o focaltech.o
diff --git a/drivers/input/mouse/zinitix_i2c.c
b/drivers/input/mouse/zinitix_i2c.c
index e69de29bb2d1..d441b1cb1274 100755
--- a/drivers/input/mouse/zinitix_i2c.c
+++ b/drivers/input/mouse/zinitix_i2c.c
@@ -0,0 +1,1491 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Zinitics I2C Touchpad driver
+ *
+ * Copyright (c) 2020 ZINITIX Co.,Ltd
+ *
+ * Author: KwangDeok Son
+ *
+ * Based on elan driver:
+ * Copyright (c) 2011-2013 ELAN Microelectronics Corp.
+ * copyright (c) 2011-2012 Cypress Semiconductor, Inc.
+ * copyright (c) 2011-2012 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * Trademarks are the property of their respective owners.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "zinitix_i2c.h"
+
+static int zinitix_i2c_read(struct i2c_client *client, u16 reg, u8 *val, u16
len)
+{
+ __le16 buf[] = {
+ cpu_to_le16(reg),
+ };
+ struct i2c_msg msgs[] = {
+ {
+ .addr = client->addr,
+ .flags = client->flags & I2C_M_TEN,
+ .len = sizeof(buf),
+ .buf = (u8 *)buf,
+ },
+ {
+ .addr = client->addr,
+ .flags = (client->flags & I2C_M_TEN) | I2C_M_RD,
+ .len = len,
+ .buf = val,
+ }
+ };
+ int ret;
+
+ ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
+
+ return ret == ARRAY_SIZE(msgs) ? 0 : (ret < 0 ? ret : -EIO);
+}
+
+static int zinitix_i2c_write(struct i2c_client *client, u16 reg, u16 cmd)
+{
+ __le16 buf[] = {
+ cpu_to_le16(reg),
+ cpu_to_le16(cmd),
+ };
+ struct i2c_msg msg = {
+ .addr = client->addr,
+ .flags = client->flags & I2C_M_TEN,
+ .len = sizeof(buf),
+ .buf = (u8 *)buf,
+ };
+ int ret;
+
+ ret = i2c_transfer(client->adapter, &msg, 1);
+ if (ret != 1) {
+ if (ret >= 0)
+ ret = -EIO;
+ dev_err(&client->dev, "writing cmd (0x%04x) failed: %d\n", reg,
ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int zinitix_i2c_read_buf(struct i2c_client *client, u8 *buf, u16
bufsize, u8 *val, u16 len)
+{
+ struct i2c_msg msgs[] = {
+ {
+ .addr = client->addr,
+ .flags = client->flags & I2C_M_TEN,
+ .len = bufsize,
+ .buf = buf,
+ },
+ {
+ .addr = client->addr,
+ .flags = (client->flags & I2C_M_TEN) | I2C_M_RD,
+ .len = len,
+ .buf = val,
+ }
+ };
+ int ret;
+
+ ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
+
+ return ret == ARRAY_SIZE(msgs) ? 0 : (ret < 0 ? ret : -EIO);
+}
+
+static int zinitix_i2c_write_buf(struct i2c_client *client, u8 *buf, u8
bufsize)
+{
+ struct i2c_msg msg = {
+ .addr = client-
Re: iommu/vt-d: Cure VF irqdomain hickup
On 2020-11-12 21:34, Thomas Gleixner wrote: On Thu, Nov 12 2020 at 20:15, Thomas Gleixner wrote: The recent changes to store the MSI irqdomain pointer in struct device missed that Intel DMAR does not register virtual function devices. Due to that a VF device gets the plain PCI-MSI domain assigned and then issues compat MSI messages which get caught by the interrupt remapping unit. Cure that by inheriting the irq domain from the physical function device. That's a temporary workaround. The correct fix is to inherit the irq domain from the bus, but that's a larger effort which needs quite some other changes to the way how x86 manages PCI and MSI domains. Bah, that's not really going to work with the way how irq remapping works on x86 because at least Intel/DMAR can have more than one DMAR unit on a bus. So the alternative solution would be to assign the domain per device, but the current ordering creates a hen and egg problem. Looking the domain up in pci_set_msi_domain() does not work because at that point the device is not registered in the IOMMU. That happens from device_add(). Marc, is there any problem to reorder the calls in pci_device_add(): device_add(); pci_set_msi_domain(); I *think* it works as long as we keep the "match_driver = false" hack. Otherwise, we risk binding to a driver early, and game over. That would allow to add a irq_find_matching_fwspec() based lookup to pci_msi_get_device_domain(). Just so that I understand the issue: is the core of the problem that there is no 1:1 mapping between a PCI bus and a DMAR unit, and no firmware topology information to indicate which one to pick? Though I'm not yet convinced that the outcome would be less horrible than the hack in the DMAR driver when I'm taking all the other horrors of x86 (including XEN) into account :) I tried to follow the notifier into the DMAR driver, ended up in the IRQ remapping code, and lost the will to live. I have a question though: In the bus notifier callback, you end-up in dmar_pci_bus_add_dev(), which calls intel_irq_remap_add_device(), which tries to set the MSI domain. Why isn't that enough? Are we still missing any information at that stage? Thanks, M. -- Jazz is not dead. It just smells funny...
Re: [PATCH v3] gpio: sifive: To get gpio irq offset from device tree data
Bartosz Golaszewski 於 2020年11月13日 週五 下午5:00寫道： > > On Fri, Nov 13, 2020 at 3:34 AM Greentime Hu wrote: > > > > We can get hwirq number of the gpio by its irq_data->hwirq so that we don't > > need to add more macros for different platforms. This patch is tested in > > SiFive Unleashed board and SiFive Unmatched board. > > > > Signed-off-by: Greentime Hu > > --- > > Please list the changes between versions of patches. What has changed since > v2? changes in v3: Add 2 newlines changes in v2: Use irqd_to_hwirq() instead of d->hwirq and platform_get_irq() instead of irq_of_parse_and_map()
[PATCH] altera-stapl: remove the unreached switch case
From: Kaixu Xia The value of the variable status must be one of the 0, -EIO and -EILSEQ, so the switch cases -ENODATA and default are unreached. Remove them. Reported-by: Tosk Robot Signed-off-by: Kaixu Xia --- drivers/misc/altera-stapl/altera.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/misc/altera-stapl/altera.c b/drivers/misc/altera-stapl/altera.c index 5bdf574..8ad1e9e 100644 --- a/drivers/misc/altera-stapl/altera.c +++ b/drivers/misc/altera-stapl/altera.c @@ -2265,19 +2265,10 @@ static int altera_check_crc(u8 *p, s32 program_size) "actual %04x\n", __func__, local_expected, local_actual); break; - case -ENODATA: - printk(KERN_ERR "%s: expected CRC not found, " - "actual CRC = %04x\n", __func__, - local_actual); - break; case -EIO: printk(KERN_ERR "%s: error: format isn't " "recognized.\n", __func__); break; - default: - printk(KERN_ERR "%s: CRC function returned error " - "code %d\n", __func__, status); - break; } } -- 1.8.3.1
Re: [PATCH v4 02/11] firmware: raspberrypi: Introduce devm_rpi_firmware_get()
On Thu, 2020-11-12 at 18:25 +0100, Bartosz Golaszewski wrote:
> On Thu, Nov 12, 2020 at 5:44 PM Nicolas Saenz Julienne
> wrote:
> > Itroduce devm_rpi_firmware_get(), it'll simplify the firmware handling
> > for most consumers.
> >
> > Suggested-by: Bartosz Golaszewski
> > Signed-off-by: Nicolas Saenz Julienne
> > ---
> >
> > Changes since v2:
> > - Introduce devm_rpi_firmware_get()
> >
> > drivers/firmware/raspberrypi.c | 31 +-
> > include/soc/bcm2835/raspberrypi-firmware.h | 8 ++
> > 2 files changed, 38 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> > index 438e17074a97..4ab2dfdc82ad 100644
> > --- a/drivers/firmware/raspberrypi.c
> > +++ b/drivers/firmware/raspberrypi.c
> > @@ -237,10 +237,17 @@ static void rpi_firmware_delete(struct kref *kref)
> > kfree(fw);
> > }
> >
> > -void rpi_firmware_put(struct rpi_firmware *fw)
> > +static void __rpi_firmware_put(void *data)
> > {
>
> The '__' prefix is very vague and usually used for unlocked variants
> of functions. The casting to void * in rpi_firmware_put() is also
> unneeded. I would much prefer that the devres release callback be
> called devm_rpi_firmware_put() and that it call rpi_firmware_put()
> which would then call kref_put().
Yes, that's better. I'll change it.
Regards,
Nicolas
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] phy: tegra: Don't warn on probe deferral
On 11/11/20 6:37 PM, Jon Hunter wrote:
> Deferred probe is an expected return value for devm_regulator_bulk_get().
> Given that the driver deals with it properly, there's no need to output a
> warning that may potentially confuse users.
>
> Signed-off-by: Jon Hunter
> ---
> drivers/phy/tegra/xusb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c
> index ad88d74c1884..2eafb813825b 100644
> --- a/drivers/phy/tegra/xusb.c
> +++ b/drivers/phy/tegra/xusb.c
> @@ -1200,7 +1200,7 @@ static int tegra_xusb_padctl_probe(struct
> platform_device *pdev)
> err = devm_regulator_bulk_get(&pdev->dev, padctl->soc->num_supplies,
> padctl->supplies);
> if (err < 0) {
> - dev_err(&pdev->dev, "failed to get regulators: %d\n", err);
> + dev_err_probe(&pdev->dev, err, "failed to get regulators\n");
> goto remove;
> }
>
>
Acked-by: JC Kuo
Re: [RFT for v9] (Was Re: [PATCH v8 -tip 00/26] Core scheduling)
On 2020/11/7 4:55, Joel Fernandes wrote: > All, > > I am getting ready to send the next v9 series based on tip/master > branch. Could you please give the below tree a try and report any results in > your testing? > git tree: > https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git (branch > coresched) > git log: > https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/log/?h=coresched > > The major changes in this series are the improvements: > (1) > "sched: Make snapshotting of min_vruntime more CGroup-friendly" > https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/commit/?h=coresched-v9-for-test&id=9a20a6652b3c50fd51faa829f7947004239a04eb > > (2) > "sched: Simplify the core pick loop for optimized case" > https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/commit/?h=coresched-v9-for-test&id=0370117b4fd418cdaaa6b1489bfc14f305691152 > > And a bug fix: > (1) > "sched: Enqueue task into core queue only after vruntime is updated" > https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/commit/?h=coresched-v9-for-test&id=401dad5536e7e05d1299d0864e6fc5072029f492 > > There are also 2 more bug fixes that I squashed-in related to kernel > protection and a crash seen on the tip/master branch. > > Hoping to send the series next week out to the list. > > Have a great weekend, and Thanks! > > - Joel > > > On Mon, Oct 19, 2020 at 09:43:10PM -0400, Joel Fernandes (Google) wrote: Adding 4 workloads test results for core scheduling v9 candidate: - kernel under test: -- coresched community v9 candidate from https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git (branch coresched) -- latest commit: 2e8591a330ff (HEAD -> coresched, origin/coresched) NEW: sched: Add a coresched command line option -- coresched=on kernel parameter applied - workloads: -- A. sysbench cpu (192 threads) + sysbench cpu (192 threads) -- B. sysbench cpu (192 threads) + sysbench mysql (192 threads, mysqld forced into the same cgroup) -- C. uperf netperf.xml (192 threads over TCP or UDP protocol separately) -- D. will-it-scale context_switch via pipe (192 threads) - test machine setup: CPU(s): 192 On-line CPU(s) list: 0-191 Thread(s) per core: 2 Core(s) per socket: 48 Socket(s): 2 NUMA node(s):4 - test results, no obvious performance drop compared to community v8 build: -- workload A: +--+--+--++ | | ** | sysbench cpu * 192 | sysbench cpu * 192 | +==+==+==++ | cgroup | ** | cg_sysbench_cpu_0| cg_sysbench_cpu_1 | +--+--+--++ | record_item | ** | Tput_avg (events/s) | Tput_avg (events/s)| +--+--+--++ | coresched_normalized | ** | 0.98 | 1.01 | +--+--+--++ | default_normalized | ** | 1| 1 | +--+--+--++ | smtoff_normalized| ** | 0.59 | 0.6 | +--+--+--++ -- workload B: +--+--+--++ | | ** | sysbench cpu * 192 | sysbench mysql * 192 | +==+==+==++ | cgroup | ** | cg_sysbench_cpu_0| cg_sysbench_mysql_0| +--+--+--++ | record_item | ** | Tput_avg (events/s) | Tput_avg (events/s)| +--+--+--++ | coresched_normalized | ** | 1.02 | 0.78 | +--+--+--++ | default_normalized | ** | 1| 1 | +--+--+--++ | smtoff_normalized| ** | 0.59 | 0.75 | +--+--+--++ -- workload C: +--+--+---+---+ | |
[PATCH] spi: imx: enable runtime pm support
Hello Clark, This patch breaks spi-imx on imx7d. Toradex Colibri imx7d spi reports with: [4.258468] inv-mpu6000-spi spi2.0: I/O Error in PIO [4.264269] inv-mpu6000-spi spi2.0: SPI transfer failed: -110 [4.264305] spi_master spi2: failed to transfer one message from queue We are using spi-imx with dma. Reverting your patch fixes this issue. The baseline commit 951cbbc386ff01b50da4f46387e994e81d9ab431 (tag: v5.9.8, stable/linux-5.9.y) Could you please give some comments on this issue ?
Re: [PATCH RFC v5 01/13] perf jevents: Add support for an extra directory level
On 13/11/2020 08:48, kajoljain wrote: On 11/6/20 6:05 PM, John Garry wrote: Currently only upto a level 2 directory is supported, in form vendor/platform. Hi John, Just want to check in case of sub directories, Will it be good add on/feasible to be able to include events of particular sub-directory for a platform? Otherwise with this patch in the end all event will be part of same pmu_event structure. So what is the purpose of sub directories? Let me know if I am missing something. Hi Kajol Jain, So currently we support both of the following structure: arch/platform arch/vendor/platform/ arch/vendor/platform/ is for an arch like arm, where the arch provider may not be the vendor. I want to go one step further, to support also: arch/vendor/platform/cpu arch/vendor/platform/sys Here we have separate folders for cpu and sys events. CPU events in "cpu" folder are added to pmu_events_map[], as before. And events in "sys" folder are added from patch 2/13 to new table pmu_sys_events_table[]. I hope it's clearer now. Thanks, John Thanks, Kajol Jain Add support for a further level, to support vendor/platform sub-directories in future.
Re: [PATCH net v2] net: phy: mscc: remove non-MACSec compatible phy
Quoting Steen Hegelund (2020-11-13 10:11:16)
> Selecting VSC8575 as a MACSec PHY was not correct
>
> The relevant datasheet can be found here:
> - VSC8575: https://www.microchip.com/wwwproducts/en/VSC8575
>
> History:
> v1 -> v2:
>- Corrected the sha in the "Fixes:" tag
>
> Fixes: 1bbe0ecc2a1a ("net: phy: mscc: macsec initialization")
> Signed-off-by: Steen Hegelund
Reviewed-by: Antoine Tenart
Small comment: you can put the commit history after the --- so it
doesn't end-up in the commit log (except when it's relevant, which isn't
the case here). I don't think that's a blocker though.
Thanks Steen!
Antoine
> ---
> drivers/net/phy/mscc/mscc_macsec.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/phy/mscc/mscc_macsec.c
> b/drivers/net/phy/mscc/mscc_macsec.c
> index 1d4c012194e9..72292bf6c51c 100644
> --- a/drivers/net/phy/mscc/mscc_macsec.c
> +++ b/drivers/net/phy/mscc/mscc_macsec.c
> @@ -981,7 +981,6 @@ int vsc8584_macsec_init(struct phy_device *phydev)
>
> switch (phydev->phy_id & phydev->drv->phy_id_mask) {
> case PHY_ID_VSC856X:
> - case PHY_ID_VSC8575:
> case PHY_ID_VSC8582:
> case PHY_ID_VSC8584:
> INIT_LIST_HEAD(&vsc8531->macsec_flows);
> --
> 2.29.2
>
[PATCH] crypto: hisilicon/zip - add a work_queue for zip irq
The patch 'irqchip/gic-v3-its: Balance initial LPI affinity across CPUs'
set the IRQ to an uncentain CPU. If an IRQ is bound to the CPU used by the
thread which is sending request, the throughput will be just half.
So allocate a 'work_queue' and set as 'WQ_UNBOUND' to do the back half work
on some different CPUS.
Signed-off-by: Yang Shen
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/zip/zip_main.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/hisilicon/zip/zip_main.c
b/drivers/crypto/hisilicon/zip/zip_main.c
index 3d1524b..4fb5a32b 100644
--- a/drivers/crypto/hisilicon/zip/zip_main.c
+++ b/drivers/crypto/hisilicon/zip/zip_main.c
@@ -747,6 +747,8 @@ static int hisi_zip_pf_probe_init(struct hisi_zip *hisi_zip)
static int hisi_zip_qm_init(struct hisi_qm *qm, struct pci_dev *pdev)
{
+ int ret;
+
qm->pdev = pdev;
qm->ver = pdev->revision;
qm->algs = "zlib\ngzip";
@@ -772,7 +774,25 @@ static int hisi_zip_qm_init(struct hisi_qm *qm, struct
pci_dev *pdev)
qm->qp_num = HZIP_QUEUE_NUM_V1 - HZIP_PF_DEF_Q_NUM;
}
- return hisi_qm_init(qm);
+ qm->wq = alloc_workqueue("%s", WQ_HIGHPRI | WQ_MEM_RECLAIM |
+WQ_UNBOUND, num_online_cpus(),
+pci_name(qm->pdev));
+ if (!qm->wq) {
+ pci_err(qm->pdev, "fail to alloc workqueue\n");
+ return -ENOMEM;
+ }
+
+ ret = hisi_qm_init(qm);
+ if (ret)
+ destroy_workqueue(qm->wq);
+
+ return ret;
+}
+
+static void hisi_zip_qm_uninit(struct hisi_qm *qm)
+{
+ hisi_qm_uninit(qm);
+ destroy_workqueue(qm->wq);
}
static int hisi_zip_probe_init(struct hisi_zip *hisi_zip)
@@ -854,7 +874,7 @@ static int hisi_zip_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
hisi_qm_dev_err_uninit(qm);
err_qm_uninit:
- hisi_qm_uninit(qm);
+ hisi_zip_qm_uninit(qm);
return ret;
}
@@ -872,7 +892,7 @@ static void hisi_zip_remove(struct pci_dev *pdev)
hisi_zip_debugfs_exit(qm);
hisi_qm_stop(qm, QM_NORMAL);
hisi_qm_dev_err_uninit(qm);
- hisi_qm_uninit(qm);
+ hisi_zip_qm_uninit(qm);
}
static const struct pci_error_handlers hisi_zip_err_handler = {
--
2.7.4
Re: About devm_platform_ioremap_resource [Was: Re: [PATCH 01/32] pwm: sun4i: convert to devm_platform_ioremap_resource]
On Fri, Nov 13, 2020 at 10:12:46AM +0100, Bartosz Golaszewski wrote:
> On Fri, Nov 13, 2020 at 8:04 AM Uwe Kleine-König
> wrote:
> >
> > Hello,
> >
> > [Added lkml and the people involved in commit 7945f929f1a7
> > ("drivers: provide devm_platform_ioremap_resource()") to Cc:. For the
> > new readers: This is about patches making use of
> > devm_platform_ioremap_resource() instead of open coding it. Full context
> > at https://lore.kernel.org/r/20201112190649.GA908613@ulmo]
> >
> > On Thu, Nov 12, 2020 at 10:14:29PM +0100, Uwe Kleine-König wrote:
> > > On Thu, Nov 12, 2020 at 08:06:49PM +0100, Thierry Reding wrote:
> > > > I also think that it's overly narrow is scope, so you can't actually
> > > > "blindly" use this helper and I've seen quite a few cases where this was
> > > > unknowingly used for cases where it shouldn't have been used and then
> > > > broke things (because some drivers must not do the request_mem_region()
> > > > for example).
> > >
> > > You have a link to such an accident?
> >
> > I got a hint in private here:
> > https://lore.kernel.org/r/1555670144-24220-1-git-send-email-aisheng.d...@nxp.com
> >
> > devm_platform_ioremap_resource() is platform_get_resource() +
> > devm_ioremap_resource() and here it was used to replace
> > platform_get_resource() + devm_ioremap().
> >
> > IMHO the unlucky thing in this situation is that devm_ioremap_resource()
> > and devm_ioremap() are different by more than just how they get the area
> > to remap. (i.e. devm_ioremap_resource() also does
> > devm_request_mem_region().)
> >
> > So the problem is not the added wrapper, but unclear semantics in the
> > functions it uses. In my eyes devm_ioremap() and
> > devm_platform_ioremap_resource() should better be named
> > devm_request_ioremap() and devm_platform_request_ioremap_resource()
> > respectively. Is it worth to rename these for clearity?
>
> But devm_ioremap() doesn't request the region. Did you mean
> devm_ioremap_resource() should become devm_request_ioremap_resource()?
Yes indeed. The last paragraph should be:
So the problem is not the added wrapper, but unclear semantics in the
functions it uses. In my eyes devm_ioremap_resource() and
devm_platform_ioremap_resource() should better be named
devm_request_ioremap_resource() and
devm_platform_request_ioremap_resource().
(Note that I created a patch series that implements this suggestion, but
you were not on Cc: as I extensively trimmed the recipents assuming most
people are not interested. See
https://lore.kernel.org/r/20201113085327.125041-1-u.kleine-koe...@pengutronix.de)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Re: [PATCH v5 3/9] lib: zstd: Upgrade to latest upstream zstd version 1.4.6
Hi Nick, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on cryptodev/master] [also build test WARNING on kdave/for-next f2fs/dev-test linus/master v5.10-rc3 next-20201112] [cannot apply to crypto/master] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Nick-Terrell/lib-zstd-Add-zstd-compatibility-wrapper/20201103-150617 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master config: powerpc-randconfig-c004-20201103 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "coccinelle warnings: (new ones prefixed by >>)" >> lib/zstd/compress/zstd_compress.c:3248:24-25: Unneeded semicolon Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH] lib: zstd: fix semicolon.cocci warnings
From: kernel test robot lib/zstd/compress/zstd_compress.c:3248:24-25: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Nick Terrell Reported-by: kernel test robot Signed-off-by: kernel test robot --- url: https://github.com/0day-ci/linux/commits/Nick-Terrell/lib-zstd-Add-zstd-compatibility-wrapper/20201103-150617 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master zstd_compress.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/lib/zstd/compress/zstd_compress.c +++ b/lib/zstd/compress/zstd_compress.c @@ -3245,7 +3245,7 @@ size_t ZSTD_compress(void* dst, size_t d ZSTD_CCtx* cctx = ZSTD_createCCtx(); RETURN_ERROR_IF(!cctx, memory_allocation, "ZSTD_createCCtx failed"); result = ZSTD_compressCCtx(cctx, dst, dstCapacity, src, srcSize, compressionLevel); -ZSTD_freeCCtx(cctx);; +ZSTD_freeCCtx(cctx); return result; }
Re: [PATCH v5 2/4] mfd: Add driver for Embedded Controller found on Acer Iconia Tab A500
On Wed, 04 Nov 2020, Dmitry Osipenko wrote:
> Acer Iconia Tab A500 is an Android tablet device, it has ENE KB930
> Embedded Controller which provides battery-gauge, LED, GPIO and some
> other functions. The EC uses firmware that is specifically customized
> for Acer A500. This patch adds MFD driver for the Embedded Controller
> which allows to power-off / reboot the A500 device, it also provides
> a common register read/write API that will be used by the sub-devices.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/mfd/Kconfig| 12 +++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/acer-ec-a500.c | 203 +
> 3 files changed, 216 insertions(+)
> create mode 100644 drivers/mfd/acer-ec-a500.c
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 8b99a13669bf..527ba5054d80 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -2097,6 +2097,18 @@ config MFD_KHADAS_MCU
> additional drivers must be enabled in order to use the functionality
> of the device.
>
> +config MFD_ACER_A500_EC
> + tristate "Embedded Controller driver for Acer Iconia Tab A500"
Drop "driver". This is meant to be describing the device.
> + depends on I2C
depends on OF ?
> + depends on ARCH_TEGRA_2x_SOC || COMPILE_TEST
> + select MFD_CORE
> + select REGMAP
> + help
> + Support for Acer Iconia Tab A500 Embedded Controller.
> +
> + The controller itself is ENE KB930, it is running firmware
> + customized for the specific needs of the Acer A500 hardware.
> +
> menu "Multimedia Capabilities Port drivers"
> depends on ARCH_SA1100
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 1780019d2474..7bfc57c8b363 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -263,6 +263,7 @@ obj-$(CONFIG_MFD_ROHM_BD71828)+= rohm-bd71828.o
> obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
> obj-$(CONFIG_MFD_STMFX) += stmfx.o
> obj-$(CONFIG_MFD_KHADAS_MCU) += khadas-mcu.o
> +obj-$(CONFIG_MFD_ACER_A500_EC) += acer-ec-a500.o
>
> obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
> obj-$(CONFIG_MFD_SIMPLE_MFD_I2C) += simple-mfd-i2c.o
> diff --git a/drivers/mfd/acer-ec-a500.c b/drivers/mfd/acer-ec-a500.c
> new file mode 100644
> index ..2785a6d9bcc4
> --- /dev/null
> +++ b/drivers/mfd/acer-ec-a500.c
> @@ -0,0 +1,203 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * MFD driver for Acer Iconia Tab A500 Embedded Controller.
An "MFD" isn't a thing. Please describe the device.
> + * Copyright 2020 GRATE-driver project.
> + *
> + * Based on downstream driver from Acer Inc.
Most drivers are. Not sure this is required.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Alphabetical please. ;)
> +#define A500_EC_I2C_ERR_TIMEOUT 500
> +#define A500_EC_POWER_CMD_TIMEOUT1000
> +
> +enum {
> + REG_CURRENT_NOW = 0x03,
> + REG_SHUTDOWN = 0x52,
> + REG_WARM_REBOOT = 0x54,
> + REG_COLD_REBOOT = 0x55,
> +};
> +
> +static struct i2c_client *a500_ec_client_pm_off;
> +
> +static int a500_ec_read(void *context, const void *reg_buf, size_t reg_size,
> + void *val_buf, size_t val_sizel)
> +{
> + struct i2c_client *client = context;
> + unsigned int reg, retries = 5;
> + u16 *ret_val = val_buf;
> + s32 ret = 0;
> +
> + if (reg_size != 1 || val_sizel != 2)
No magic numbers please.
What does this *mean*?
> + return -EOPNOTSUPP;
Why EOPNOTSUPP?
> + reg = *(u8 *)reg_buf;
> +
> + while (retries-- > 0) {
> + ret = i2c_smbus_read_word_data(client, reg);
> + if (ret >= 0)
> + break;
> +
> + msleep(A500_EC_I2C_ERR_TIMEOUT);
> + }
> +
> + if (ret < 0) {
> + dev_err(&client->dev, "read 0x%x failed: %d\n", reg, ret);
> + return ret;
> + }
> +
> + *ret_val = ret;
> +
> + if (reg == REG_CURRENT_NOW)
> + fsleep(1);
Ooo, new toy!
> + return 0;
> +}
I'm surprised there isn't a generic function which does this kind of
read. Seems like pretty common/boilerplate stuff.
> +static int a500_ec_write(void *context, const void *data, size_t count)
> +{
> + struct i2c_client *client = context;
> + unsigned int reg, val, retries = 5;
> + s32 ret = 0;
> +
> + if (count != 3)
Define or comment needed.
> + return -EOPNOTSUPP;
> +
> + reg = *(u8 *)(data + 0);
> + val = *(u16 *)(data + 1);
> +
> + while (retries-- > 0) {
> + ret = i2c_smbus_write_word_data(client, reg, val);
> + if (ret >= 0)
> + break;
> +
> + msleep(A500_EC_I2C_ERR_TIMEOUT);
> + }
> +
> + if (ret < 0) {
> + dev_err(&client->dev, "write 0x%x failed: %d\n", reg, ret);
> + return ret;
> + }
> +
> + return 0;
> +}
[PATCH v3 00/14] An alternative series for asymmetric AArch32 systems
Hi again everyone, I'm not a scheduler hacker, I'm a scheduler hacker's mate. I'm only hacking the scheduler, 'cos trying to run 32-bit applications on systems where not all of the CPUs support it is GREAT. It's Friday 13th, and I'm back with version three of the increasingly popular patches I previously posted here: v1: https://lore.kernel.org/r/20201027215118.27003-1-w...@kernel.org v2: https://lore.kernel.org/r/20201109213023.15092-1-w...@kernel.org and which started life as a reimplementation of some patches from Qais: https://lore.kernel.org/r/20201021104611.2744565-1-qais.you...@arm.com The aim of this series is to allow 32-bit ARM applications to run on arm64 SoCs where not all of the CPUs support the 32-bit instruction set. There are some major changes in v3: * Add some scheduler hooks for restricting a task's affinity mask * Implement these hooks for arm64 so that we can avoid 32-bit tasks running on 64-bit-only cores * Restrict affinity mask of 32-bit tasks on execve() * Prevent hot-unplug of all 32-bit CPUs if we have a mismatched system * Ensure 32-bit EL0 cpumask is zero-initialised (oops) It's worth mentioning that this approach goes directly against my initial proposal for punting the affinity management to userspace, because it turns out that doesn't really work. There are cases where the kernel has to muck with the affinity mask explicitly, such as execve(), CPU hotplug and cpuset balancing. Ensuring that these don't lead to random SIGKILLs as far as userspace is concerned means avoiding any 64-bit-only CPUs appearing in the affinity mask for a 32-bit task, at which point it's easier just to handle everything in the kernel anyway. - Patches 1-6 hack the arm64 CPU feature code to allow 32-bit tasks to run on a mismatched system, but forcing SIGKILL if a task ends up on the wrong CPU. This is gated on a command-line option; without it, a mismatched system will be treated as 64-bit-only. - Patches 7-11 add scheduler functionality necessary to constrain the CPU affinity mask on a per-task basis and hook this up for execve() on arm64. - Patches 12-14 finish off the arm64 plumbing and remove the logic for killing misplaced tasks, as it adds overhead to the context-switch and ret-to-user paths. This seems to do the right thing in my contrived QEMU environment, but as I say, I'm not a scheduler hacker so I'm open to alternative ideas. Cheers, Will Cc: Catalin Marinas Cc: Marc Zyngier Cc: Greg Kroah-Hartman Cc: Peter Zijlstra Cc: Morten Rasmussen Cc: Qais Yousef Cc: Suren Baghdasaryan Cc: Quentin Perret Cc: Tejun Heo Cc: Li Zefan Cc: Johannes Weiner Cc: Ingo Molnar Cc: Juri Lelli Cc: Vincent Guittot Cc: kernel-t...@android.com --->8 Will Deacon (14): arm64: cpuinfo: Split AArch32 registers out into a separate struct arm64: Allow mismatched 32-bit EL0 support KVM: arm64: Kill 32-bit vCPUs on systems with mismatched EL0 support arm64: Kill 32-bit applications scheduled on 64-bit-only CPUs arm64: Advertise CPUs capable of running 32-bit applications in sysfs arm64: Hook up cmdline parameter to allow mismatched 32-bit EL0 sched: Introduce restrict_cpus_allowed_ptr() to limit task CPU affinity arm64: exec: Adjust affinity for compat tasks with mismatched 32-bit EL0 cpuset: Don't use the cpu_possible_mask as a last resort for cgroup v1 sched: Introduce arch_cpu_allowed_mask() to limit fallback rq selection sched: Reject CPU affinity changes based on arch_cpu_allowed_mask() arm64: Prevent offlining first CPU with 32-bit EL0 on mismatched system arm64: Implement arch_cpu_allowed_mask() arm64: Remove logic to kill 32-bit tasks on 64-bit-only cores .../ABI/testing/sysfs-devices-system-cpu | 9 + .../admin-guide/kernel-parameters.txt | 7 + arch/arm64/include/asm/cpu.h | 44 ++-- arch/arm64/include/asm/cpucaps.h | 2 +- arch/arm64/include/asm/cpufeature.h | 8 +- arch/arm64/include/asm/mmu_context.h | 12 + arch/arm64/kernel/cpufeature.c| 219 ++ arch/arm64/kernel/cpuinfo.c | 53 +++-- arch/arm64/kernel/process.c | 17 +- arch/arm64/kvm/arm.c | 11 +- include/linux/sched.h | 1 + kernel/cgroup/cpuset.c| 6 +- kernel/sched/core.c | 90 +-- 13 files changed, 370 insertions(+), 109 deletions(-) -- 2.29.2.299.gdc1121823c-goog
[PATCH v3 02/14] arm64: Allow mismatched 32-bit EL0 support
When confronted with a mixture of CPUs, some of which support 32-bit
applications and others which don't, we quite sensibly treat the system
as 64-bit only for userspace and prevent execve() of 32-bit binaries.
Unfortunately, some crazy folks have decided to build systems like this
with the intention of running 32-bit applications, so relax our
sanitisation logic to continue to advertise 32-bit support to userspace
on these systems and track the real 32-bit capable cores in a cpumask
instead. For now, the default behaviour remains but will be tied to
a command-line option in a later patch.
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/cpucaps.h| 2 +-
arch/arm64/include/asm/cpufeature.h | 8 ++-
arch/arm64/kernel/cpufeature.c | 106 ++--
3 files changed, 107 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index e7d98997c09c..e6f0eb4643a0 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -20,7 +20,7 @@
#define ARM64_ALT_PAN_NOT_UAO 10
#define ARM64_HAS_VIRT_HOST_EXTN 11
#define ARM64_WORKAROUND_CAVIUM_27456 12
-#define ARM64_HAS_32BIT_EL013
+#define ARM64_HAS_32BIT_EL0_DO_NOT_USE 13
#define ARM64_HARDEN_EL2_VECTORS 14
#define ARM64_HAS_CNP 15
#define ARM64_HAS_NO_FPSIMD16
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index 97244d4feca9..f447d313a9c5 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -604,9 +604,15 @@ static inline bool cpu_supports_mixed_endian_el0(void)
return id_aa64mmfr0_mixed_endian_el0(read_cpuid(ID_AA64MMFR0_EL1));
}
+const struct cpumask *system_32bit_el0_cpumask(void);
+DECLARE_STATIC_KEY_FALSE(arm64_mismatched_32bit_el0);
+
static inline bool system_supports_32bit_el0(void)
{
- return cpus_have_const_cap(ARM64_HAS_32BIT_EL0);
+ u64 pfr0 = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1);
+
+ return id_aa64pfr0_32bit_el0(pfr0) ||
+ static_branch_unlikely(&arm64_mismatched_32bit_el0);
}
static inline bool system_supports_4kb_granule(void)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d4a7e84b1513..1aa01ecc133f 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -104,6 +104,24 @@ DECLARE_BITMAP(boot_capabilities, ARM64_NPATCHABLE);
bool arm64_use_ng_mappings = false;
EXPORT_SYMBOL(arm64_use_ng_mappings);
+/*
+ * Permit PER_LINUX32 and execve() of 32-bit binaries even if not all CPUs
+ * support it?
+ */
+static bool __read_mostly allow_mismatched_32bit_el0;
+
+/*
+ * Static branch enabled only if allow_mismatched_32bit_el0 is set and we have
+ * seen at least one CPU capable of 32-bit EL0.
+ */
+DEFINE_STATIC_KEY_FALSE(arm64_mismatched_32bit_el0);
+
+/*
+ * Mask of CPUs supporting 32-bit EL0.
+ * Only valid if arm64_mismatched_32bit_el0 is enabled.
+ */
+static cpumask_var_t cpu_32bit_el0_mask __cpumask_var_read_mostly;
+
/*
* Flag to indicate if we have computed the system wide
* capabilities based on the boot time active CPUs. This
@@ -756,7 +774,7 @@ static void __init sort_ftr_regs(void)
* Any bits that are not covered by an arm64_ftr_bits entry are considered
* RES0 for the system-wide value, and must strictly match.
*/
-static void __init init_cpu_ftr_reg(u32 sys_reg, u64 new)
+static void init_cpu_ftr_reg(u32 sys_reg, u64 new)
{
u64 val = 0;
u64 strict_mask = ~0x0ULL;
@@ -819,7 +837,7 @@ static void __init init_cpu_hwcaps_indirect_list(void)
static void __init setup_boot_cpu_capabilities(void);
-static void __init init_32bit_cpu_features(struct cpuinfo_32bit *info)
+static void init_32bit_cpu_features(struct cpuinfo_32bit *info)
{
init_cpu_ftr_reg(SYS_ID_DFR0_EL1, info->reg_id_dfr0);
init_cpu_ftr_reg(SYS_ID_DFR1_EL1, info->reg_id_dfr1);
@@ -935,6 +953,25 @@ static void relax_cpu_ftr_reg(u32 sys_id, int field)
WARN_ON(!ftrp->width);
}
+static void update_compat_elf_hwcaps(void);
+
+static void update_mismatched_32bit_el0_cpu_features(struct cpuinfo_arm64
*info,
+struct cpuinfo_arm64 *boot)
+{
+ static bool boot_cpu_32bit_regs_overridden = false;
+
+ if (!allow_mismatched_32bit_el0 || boot_cpu_32bit_regs_overridden)
+ return;
+
+ if (id_aa64pfr0_32bit_el0(boot->reg_id_aa64pfr0))
+ return;
+
+ boot->aarch32 = info->aarch32;
+ init_32bit_cpu_features(&boot->aarch32);
+ update_compat_elf_hwcaps();
+ boot_cpu_32bit_regs_overridden = true;
+}
+
static int update_32bit_cpu_features(int cpu, struct cpuinfo_32bit *info,
struct cpuinfo_32bit *boot)
{
@@ -1095,6 +1132,7 @@ void update_cpu_featur
[PATCH v3 06/14] arm64: Hook up cmdline parameter to allow mismatched 32-bit EL0
Allow systems with mismatched 32-bit support at EL0 to run 32-bit
applications based on a new kernel parameter.
Signed-off-by: Will Deacon
---
Documentation/admin-guide/kernel-parameters.txt | 7 +++
arch/arm64/kernel/cpufeature.c | 7 +++
2 files changed, 14 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 526d65d8573a..f20188c44d83 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -289,6 +289,13 @@
do not want to use tracing_snapshot_alloc() as it needs
to be done where GFP_KERNEL allocations are allowed.
+ allow_mismatched_32bit_el0 [ARM64]
+ Allow execve() of 32-bit applications and setting of the
+ PER_LINUX32 personality on systems where only a strict
+ subset of the CPUs support 32-bit EL0. When this
+ parameter is present, the set of CPUs supporting 32-bit
+ EL0 is indicated by /sys/devices/system/cpu/aarch32_el0.
+
amd_iommu= [HW,X86-64]
Pass parameters to the AMD IOMMU driver in the system.
Possible values are:
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index a7a9b7bffc49..dfded018af44 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1273,6 +1273,13 @@ const struct cpumask *system_32bit_el0_cpumask(void)
return cpu_present_mask;
}
+static int __init parse_32bit_el0_param(char *str)
+{
+ allow_mismatched_32bit_el0 = true;
+ return 0;
+}
+early_param("allow_mismatched_32bit_el0", parse_32bit_el0_param);
+
static ssize_t aarch32_el0_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
--
2.29.2.299.gdc1121823c-goog
[PATCH v3 01/14] arm64: cpuinfo: Split AArch32 registers out into a separate struct
In preparation for late initialisation of the "sanitised" AArch32 register
state, move the AArch32 registers out of 'struct cpuinfo' and into their
own struct definition.
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/cpu.h | 44 +++--
arch/arm64/kernel/cpufeature.c | 71 ++
arch/arm64/kernel/cpuinfo.c| 53 +
3 files changed, 89 insertions(+), 79 deletions(-)
diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
index 7faae6ff3ab4..f4e01aa0f442 100644
--- a/arch/arm64/include/asm/cpu.h
+++ b/arch/arm64/include/asm/cpu.h
@@ -12,26 +12,7 @@
/*
* Records attributes of an individual CPU.
*/
-struct cpuinfo_arm64 {
- struct cpu cpu;
- struct kobject kobj;
- u32 reg_ctr;
- u32 reg_cntfrq;
- u32 reg_dczid;
- u32 reg_midr;
- u32 reg_revidr;
-
- u64 reg_id_aa64dfr0;
- u64 reg_id_aa64dfr1;
- u64 reg_id_aa64isar0;
- u64 reg_id_aa64isar1;
- u64 reg_id_aa64mmfr0;
- u64 reg_id_aa64mmfr1;
- u64 reg_id_aa64mmfr2;
- u64 reg_id_aa64pfr0;
- u64 reg_id_aa64pfr1;
- u64 reg_id_aa64zfr0;
-
+struct cpuinfo_32bit {
u32 reg_id_dfr0;
u32 reg_id_dfr1;
u32 reg_id_isar0;
@@ -54,6 +35,29 @@ struct cpuinfo_arm64 {
u32 reg_mvfr0;
u32 reg_mvfr1;
u32 reg_mvfr2;
+};
+
+struct cpuinfo_arm64 {
+ struct cpu cpu;
+ struct kobject kobj;
+ u32 reg_ctr;
+ u32 reg_cntfrq;
+ u32 reg_dczid;
+ u32 reg_midr;
+ u32 reg_revidr;
+
+ u64 reg_id_aa64dfr0;
+ u64 reg_id_aa64dfr1;
+ u64 reg_id_aa64isar0;
+ u64 reg_id_aa64isar1;
+ u64 reg_id_aa64mmfr0;
+ u64 reg_id_aa64mmfr1;
+ u64 reg_id_aa64mmfr2;
+ u64 reg_id_aa64pfr0;
+ u64 reg_id_aa64pfr1;
+ u64 reg_id_aa64zfr0;
+
+ struct cpuinfo_32bitaarch32;
/* pseudo-ZCR for recording maximum ZCR_EL1 LEN value: */
u64 reg_zcr;
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index dcc165b3fc04..d4a7e84b1513 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -819,6 +819,31 @@ static void __init init_cpu_hwcaps_indirect_list(void)
static void __init setup_boot_cpu_capabilities(void);
+static void __init init_32bit_cpu_features(struct cpuinfo_32bit *info)
+{
+ init_cpu_ftr_reg(SYS_ID_DFR0_EL1, info->reg_id_dfr0);
+ init_cpu_ftr_reg(SYS_ID_DFR1_EL1, info->reg_id_dfr1);
+ init_cpu_ftr_reg(SYS_ID_ISAR0_EL1, info->reg_id_isar0);
+ init_cpu_ftr_reg(SYS_ID_ISAR1_EL1, info->reg_id_isar1);
+ init_cpu_ftr_reg(SYS_ID_ISAR2_EL1, info->reg_id_isar2);
+ init_cpu_ftr_reg(SYS_ID_ISAR3_EL1, info->reg_id_isar3);
+ init_cpu_ftr_reg(SYS_ID_ISAR4_EL1, info->reg_id_isar4);
+ init_cpu_ftr_reg(SYS_ID_ISAR5_EL1, info->reg_id_isar5);
+ init_cpu_ftr_reg(SYS_ID_ISAR6_EL1, info->reg_id_isar6);
+ init_cpu_ftr_reg(SYS_ID_MMFR0_EL1, info->reg_id_mmfr0);
+ init_cpu_ftr_reg(SYS_ID_MMFR1_EL1, info->reg_id_mmfr1);
+ init_cpu_ftr_reg(SYS_ID_MMFR2_EL1, info->reg_id_mmfr2);
+ init_cpu_ftr_reg(SYS_ID_MMFR3_EL1, info->reg_id_mmfr3);
+ init_cpu_ftr_reg(SYS_ID_MMFR4_EL1, info->reg_id_mmfr4);
+ init_cpu_ftr_reg(SYS_ID_MMFR5_EL1, info->reg_id_mmfr5);
+ init_cpu_ftr_reg(SYS_ID_PFR0_EL1, info->reg_id_pfr0);
+ init_cpu_ftr_reg(SYS_ID_PFR1_EL1, info->reg_id_pfr1);
+ init_cpu_ftr_reg(SYS_ID_PFR2_EL1, info->reg_id_pfr2);
+ init_cpu_ftr_reg(SYS_MVFR0_EL1, info->reg_mvfr0);
+ init_cpu_ftr_reg(SYS_MVFR1_EL1, info->reg_mvfr1);
+ init_cpu_ftr_reg(SYS_MVFR2_EL1, info->reg_mvfr2);
+}
+
void __init init_cpu_features(struct cpuinfo_arm64 *info)
{
/* Before we start using the tables, make sure it is sorted */
@@ -838,29 +863,8 @@ void __init init_cpu_features(struct cpuinfo_arm64 *info)
init_cpu_ftr_reg(SYS_ID_AA64PFR1_EL1, info->reg_id_aa64pfr1);
init_cpu_ftr_reg(SYS_ID_AA64ZFR0_EL1, info->reg_id_aa64zfr0);
- if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0)) {
- init_cpu_ftr_reg(SYS_ID_DFR0_EL1, info->reg_id_dfr0);
- init_cpu_ftr_reg(SYS_ID_DFR1_EL1, info->reg_id_dfr1);
- init_cpu_ftr_reg(SYS_ID_ISAR0_EL1, info->reg_id_isar0);
- init_cpu_ftr_reg(SYS_ID_ISAR1_EL1, info->reg_id_isar1);
- init_cpu_ftr_reg(SYS_ID_ISAR2_EL1, info->reg_id_isar2);
- i
[PATCH v3 04/14] arm64: Kill 32-bit applications scheduled on 64-bit-only CPUs
Scheduling a 32-bit application on a 64-bit-only CPU is a bad idea.
Ensure that 32-bit applications always take the slow-path when returning
to userspace on a system with mismatched support at EL0, so that we can
avoid trying to run on a 64-bit-only CPU and force a SIGKILL instead.
Signed-off-by: Will Deacon
---
arch/arm64/kernel/process.c | 19 ++-
arch/arm64/kernel/signal.c | 26 ++
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 4784011cecac..1540ab0fbf23 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -542,6 +542,15 @@ static void erratum_1418040_thread_switch(struct
task_struct *prev,
write_sysreg(val, cntkctl_el1);
}
+static void compat_thread_switch(struct task_struct *next)
+{
+ if (!is_compat_thread(task_thread_info(next)))
+ return;
+
+ if (static_branch_unlikely(&arm64_mismatched_32bit_el0))
+ set_tsk_thread_flag(next, TIF_NOTIFY_RESUME);
+}
+
/*
* Thread switching.
*/
@@ -558,6 +567,7 @@ __notrace_funcgraph struct task_struct *__switch_to(struct
task_struct *prev,
uao_thread_switch(next);
ssbs_thread_switch(next);
erratum_1418040_thread_switch(prev, next);
+ compat_thread_switch(next);
/*
* Complete any pending TLB or cache maintenance on this CPU in case
@@ -620,8 +630,15 @@ unsigned long arch_align_stack(unsigned long sp)
*/
void arch_setup_new_exec(void)
{
- current->mm->context.flags = is_compat_task() ? MMCF_AARCH32 : 0;
+ unsigned long mmflags = 0;
+
+ if (is_compat_task()) {
+ mmflags = MMCF_AARCH32;
+ if (static_branch_unlikely(&arm64_mismatched_32bit_el0))
+ set_tsk_thread_flag(current, TIF_NOTIFY_RESUME);
+ }
+ current->mm->context.flags = mmflags;
ptrauth_thread_init_user(current);
if (task_spec_ssb_noexec(current)) {
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index a8184cad8890..bcb6ca2d9a7c 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -911,6 +911,19 @@ static void do_signal(struct pt_regs *regs)
restore_saved_sigmask();
}
+static bool cpu_affinity_invalid(struct pt_regs *regs)
+{
+ if (!compat_user_mode(regs))
+ return false;
+
+ /*
+* We're preemptible, but a reschedule will cause us to check the
+* affinity again.
+*/
+ return !cpumask_test_cpu(raw_smp_processor_id(),
+system_32bit_el0_cpumask());
+}
+
asmlinkage void do_notify_resume(struct pt_regs *regs,
unsigned long thread_flags)
{
@@ -948,6 +961,19 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
if (thread_flags & _TIF_NOTIFY_RESUME) {
tracehook_notify_resume(regs);
rseq_handle_notify_resume(NULL, regs);
+
+ /*
+* If we reschedule after checking the affinity
+* then we must ensure that TIF_NOTIFY_RESUME
+* is set so that we check the affinity again.
+* Since tracehook_notify_resume() clears the
+* flag, ensure that the compiler doesn't move
+* it after the affinity check.
+*/
+ barrier();
+
+ if (cpu_affinity_invalid(regs))
+ force_sig(SIGKILL);
}
if (thread_flags & _TIF_FOREIGN_FPSTATE)
--
2.29.2.299.gdc1121823c-goog
[PATCH v3 03/14] KVM: arm64: Kill 32-bit vCPUs on systems with mismatched EL0 support
If a vCPU is caught running 32-bit code on a system with mismatched
support at EL0, then we should kill it.
Acked-by: Marc Zyngier
Signed-off-by: Will Deacon
---
arch/arm64/kvm/arm.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 5750ec34960e..d322ac0f4a8e 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -633,6 +633,15 @@ static void check_vcpu_requests(struct kvm_vcpu *vcpu)
}
}
+static bool vcpu_mode_is_bad_32bit(struct kvm_vcpu *vcpu)
+{
+ if (likely(!vcpu_mode_is_32bit(vcpu)))
+ return false;
+
+ return !system_supports_32bit_el0() ||
+ static_branch_unlikely(&arm64_mismatched_32bit_el0);
+}
+
/**
* kvm_arch_vcpu_ioctl_run - the main VCPU run function to execute guest code
* @vcpu: The VCPU pointer
@@ -816,7 +825,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
* with the asymmetric AArch32 case), return to userspace with
* a fatal error.
*/
- if (!system_supports_32bit_el0() && vcpu_mode_is_32bit(vcpu)) {
+ if (vcpu_mode_is_bad_32bit(vcpu)) {
/*
* As we have caught the guest red-handed, decide that
* it isn't fit for purpose anymore by making the vcpu
--
2.29.2.299.gdc1121823c-goog
[PATCH v3 14/14] arm64: Remove logic to kill 32-bit tasks on 64-bit-only cores
The scheduler now knows enough about these braindead systems to place
32-bit tasks accordingly, so throw out the safety checks and allow the
ret-to-user path to avoid do_notify_resume() if there is nothing to do.
Signed-off-by: Will Deacon
---
arch/arm64/kernel/process.c | 12
arch/arm64/kernel/signal.c | 26 --
2 files changed, 38 deletions(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 17b94007fed4..dba94af1b840 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -542,15 +542,6 @@ static void erratum_1418040_thread_switch(struct
task_struct *prev,
write_sysreg(val, cntkctl_el1);
}
-static void compat_thread_switch(struct task_struct *next)
-{
- if (!is_compat_thread(task_thread_info(next)))
- return;
-
- if (static_branch_unlikely(&arm64_mismatched_32bit_el0))
- set_tsk_thread_flag(next, TIF_NOTIFY_RESUME);
-}
-
/*
* Thread switching.
*/
@@ -567,7 +558,6 @@ __notrace_funcgraph struct task_struct *__switch_to(struct
task_struct *prev,
uao_thread_switch(next);
ssbs_thread_switch(next);
erratum_1418040_thread_switch(prev, next);
- compat_thread_switch(next);
/*
* Complete any pending TLB or cache maintenance on this CPU in case
@@ -631,8 +621,6 @@ static void adjust_compat_task_affinity(struct task_struct
*p)
if (restrict_cpus_allowed_ptr(p, mask))
set_cpus_allowed_ptr(p, mask);
-
- set_tsk_thread_flag(current, TIF_NOTIFY_RESUME);
}
/*
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index bcb6ca2d9a7c..a8184cad8890 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -911,19 +911,6 @@ static void do_signal(struct pt_regs *regs)
restore_saved_sigmask();
}
-static bool cpu_affinity_invalid(struct pt_regs *regs)
-{
- if (!compat_user_mode(regs))
- return false;
-
- /*
-* We're preemptible, but a reschedule will cause us to check the
-* affinity again.
-*/
- return !cpumask_test_cpu(raw_smp_processor_id(),
-system_32bit_el0_cpumask());
-}
-
asmlinkage void do_notify_resume(struct pt_regs *regs,
unsigned long thread_flags)
{
@@ -961,19 +948,6 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
if (thread_flags & _TIF_NOTIFY_RESUME) {
tracehook_notify_resume(regs);
rseq_handle_notify_resume(NULL, regs);
-
- /*
-* If we reschedule after checking the affinity
-* then we must ensure that TIF_NOTIFY_RESUME
-* is set so that we check the affinity again.
-* Since tracehook_notify_resume() clears the
-* flag, ensure that the compiler doesn't move
-* it after the affinity check.
-*/
- barrier();
-
- if (cpu_affinity_invalid(regs))
- force_sig(SIGKILL);
}
if (thread_flags & _TIF_FOREIGN_FPSTATE)
--
2.29.2.299.gdc1121823c-goog
[PATCH v3 13/14] arm64: Implement arch_cpu_allowed_mask()
Provide an implementation of arch_cpu_allowed_mask() so that we can
prevent 64-bit-only cores being added to the 'cpus_mask' for compat
tasks on systems with mismatched 32-bit support at EL0,
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/mmu_context.h | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/include/asm/mmu_context.h
b/arch/arm64/include/asm/mmu_context.h
index 0672236e1aea..54fc469e7db9 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -251,6 +251,18 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
#define deactivate_mm(tsk,mm) do { } while (0)
#define activate_mm(prev,next) switch_mm(prev, next, current)
+static inline const struct cpumask *arch_cpu_allowed_mask(struct task_struct
*p)
+{
+ if (!static_branch_unlikely(&arm64_mismatched_32bit_el0))
+ return cpu_possible_mask;
+
+ if (!is_compat_thread(task_thread_info(p)))
+ return cpu_possible_mask;
+
+ return system_32bit_el0_cpumask();
+}
+#define arch_cpu_allowed_mask arch_cpu_allowed_mask
+
void verify_cpu_asid_bits(void);
void post_ttbr_update_workaround(void);
--
2.29.2.299.gdc1121823c-goog
[PATCH v3 08/14] arm64: exec: Adjust affinity for compat tasks with mismatched 32-bit EL0
When exec'ing a 32-bit task on a system with mismatched support for
32-bit EL0, try to ensure that it starts life on a CPU that can actually
run it.
Signed-off-by: Will Deacon
---
arch/arm64/kernel/process.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 1540ab0fbf23..17b94007fed4 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -625,6 +625,16 @@ unsigned long arch_align_stack(unsigned long sp)
return sp & ~0xf;
}
+static void adjust_compat_task_affinity(struct task_struct *p)
+{
+ const struct cpumask *mask = system_32bit_el0_cpumask();
+
+ if (restrict_cpus_allowed_ptr(p, mask))
+ set_cpus_allowed_ptr(p, mask);
+
+ set_tsk_thread_flag(current, TIF_NOTIFY_RESUME);
+}
+
/*
* Called from setup_new_exec() after (COMPAT_)SET_PERSONALITY.
*/
@@ -635,7 +645,7 @@ void arch_setup_new_exec(void)
if (is_compat_task()) {
mmflags = MMCF_AARCH32;
if (static_branch_unlikely(&arm64_mismatched_32bit_el0))
- set_tsk_thread_flag(current, TIF_NOTIFY_RESUME);
+ adjust_compat_task_affinity(current);
}
current->mm->context.flags = mmflags;
--
2.29.2.299.gdc1121823c-goog
[PATCH v3 11/14] sched: Reject CPU affinity changes based on arch_cpu_allowed_mask()
Reject explicit requests to change the affinity mask of a task via
set_cpus_allowed_ptr() if the requested mask is not a subset of the
mask returned by arch_cpu_allowed_mask(). This ensures that the
'cpus_mask' for a given task cannot contain CPUs which are incapable of
executing it, except in cases where the affinity is forced.
Signed-off-by: Will Deacon
---
kernel/sched/core.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 8df38ebfe769..13bdb2ae4d3f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1877,6 +1877,7 @@ static int __set_cpus_allowed_ptr_locked(struct
task_struct *p,
struct rq_flags *rf)
{
const struct cpumask *cpu_valid_mask = cpu_active_mask;
+ const struct cpumask *cpu_allowed_mask = arch_cpu_allowed_mask(p);
unsigned int dest_cpu;
int ret = 0;
@@ -1887,6 +1888,9 @@ static int __set_cpus_allowed_ptr_locked(struct
task_struct *p,
* Kernel threads are allowed on online && !active CPUs
*/
cpu_valid_mask = cpu_online_mask;
+ } else if (!cpumask_subset(new_mask, cpu_allowed_mask)) {
+ ret = -EINVAL;
+ goto out;
}
/*
--
2.29.2.299.gdc1121823c-goog
[PATCH v3 05/14] arm64: Advertise CPUs capable of running 32-bit applications in sysfs
Since 32-bit applications will be killed if they are caught trying to
execute on a 64-bit-only CPU in a mismatched system, advertise the set
of 32-bit capable CPUs to userspace in sysfs.
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Will Deacon
---
.../ABI/testing/sysfs-devices-system-cpu | 9 +
arch/arm64/kernel/cpufeature.c| 19 +++
2 files changed, 28 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu
b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 1a04ca8162ad..8a2e377b0dde 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -493,6 +493,15 @@ Description: AArch64 CPU registers
'identification' directory exposes the CPU ID registers for
identifying model and revision of the CPU.
+What: /sys/devices/system/cpu/aarch32_el0
+Date: November 2020
+Contact: Linux ARM Kernel Mailing list
+Description: Identifies the subset of CPUs in the system that can execute
+ AArch32 (32-bit ARM) applications. If present, the same format
as
+ /sys/devices/system/cpu/{offline,online,possible,present} is
used.
+ If absent, then all or none of the CPUs can execute AArch32
+ applications and execve() will behave accordingly.
+
What: /sys/devices/system/cpu/cpu#/cpu_capacity
Date: December 2016
Contact: Linux kernel mailing list
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 1aa01ecc133f..a7a9b7bffc49 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -67,6 +67,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1272,6 +1273,24 @@ const struct cpumask *system_32bit_el0_cpumask(void)
return cpu_present_mask;
}
+static ssize_t aarch32_el0_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ const struct cpumask *mask = system_32bit_el0_cpumask();
+
+ return sysfs_emit(buf, "%*pbl\n", cpumask_pr_args(mask));
+}
+static const DEVICE_ATTR_RO(aarch32_el0);
+
+static int __init aarch32_el0_sysfs_init(void)
+{
+ if (!allow_mismatched_32bit_el0)
+ return 0;
+
+ return device_create_file(cpu_subsys.dev_root, &dev_attr_aarch32_el0);
+}
+device_initcall(aarch32_el0_sysfs_init);
+
static bool has_32bit_el0(const struct arm64_cpu_capabilities *entry, int
scope)
{
if (!has_cpuid_feature(entry, scope))
--
2.29.2.299.gdc1121823c-goog
[PATCH v3 10/14] sched: Introduce arch_cpu_allowed_mask() to limit fallback rq selection
Asymmetric systems may not offer the same level of userspace ISA support across all CPUs, meaning that some applications cannot be executed by some CPUs. As a concrete example, upcoming arm64 big.LITTLE designs do not feature support for 32-bit applications on both clusters. On such a system, we must take care not to migrate a task to an unsupported CPU when forcefully moving tasks in select_fallback_rq() in response to a CPU hot-unplug operation. Introduce an arch_cpu_allowed_mask() hook which, given a task argument, allows an architecture to return a cpumask of CPUs that are capable of executing that task. The default implementation returns the cpu_possible_mask, since sane machines do not suffer from per-cpu ISA limitations that affect scheduling. The new mask is used when selecting the fallback runqueue as a last resort before forcing a migration to the first active CPU. Signed-off-by: Will Deacon --- kernel/sched/core.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 818c8f7bdf2a..8df38ebfe769 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -1696,6 +1696,11 @@ void check_preempt_curr(struct rq *rq, struct task_struct *p, int flags) #ifdef CONFIG_SMP +/* Must contain at least one active CPU */ +#ifndef arch_cpu_allowed_mask +#define arch_cpu_allowed_mask(p) cpu_possible_mask +#endif + /* * Per-CPU kthreads are allowed to run on !active && online CPUs, see * __set_cpus_allowed_ptr() and select_fallback_rq(). @@ -1708,7 +1713,10 @@ static inline bool is_cpu_allowed(struct task_struct *p, int cpu) if (is_per_cpu_kthread(p)) return cpu_online(cpu); - return cpu_active(cpu); + if (!cpu_active(cpu)) + return false; + + return cpumask_test_cpu(cpu, arch_cpu_allowed_mask(p)); } /* @@ -2361,10 +2369,9 @@ static int select_fallback_rq(int cpu, struct task_struct *p) } fallthrough; case possible: - do_set_cpus_allowed(p, cpu_possible_mask); + do_set_cpus_allowed(p, arch_cpu_allowed_mask(p)); state = fail; break; - case fail: BUG(); break; -- 2.29.2.299.gdc1121823c-goog
[PATCH v3 12/14] arm64: Prevent offlining first CPU with 32-bit EL0 on mismatched system
If we want to support 32-bit applications, then when we identify a CPU
with mismatched 32-bit EL0 support we must ensure that we will always
have an active 32-bit CPU available to us from then on. This is important
for the scheduler, because is_cpu_allowed() will be constrained to 32-bit
CPUs for compat tasks and forced migration due to a hotplug event will
hang if no 32-bit CPUs are available.
On detecting a mismatch, prevent offlining of either the mismatching CPU
if it is 32-bit capable, or find the first active 32-bit capable CPU
otherwise.
Signed-off-by: Will Deacon
---
arch/arm64/kernel/cpufeature.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index dfded018af44..853f3ac876a3 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1237,6 +1237,8 @@ has_cpuid_feature(const struct arm64_cpu_capabilities
*entry, int scope)
static int enable_mismatched_32bit_el0(unsigned int cpu)
{
+ static int lucky_winner = -1;
+
struct cpuinfo_arm64 *info = &per_cpu(cpu_data, cpu);
bool cpu_32bit = id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0);
@@ -1245,6 +1247,22 @@ static int enable_mismatched_32bit_el0(unsigned int cpu)
static_branch_enable_cpuslocked(&arm64_mismatched_32bit_el0);
}
+ if (cpumask_test_cpu(0, cpu_32bit_el0_mask) == cpu_32bit)
+ return 0;
+
+ if (lucky_winner >= 0)
+ return 0;
+
+ /*
+* We've detected a mismatch. We need to keep one of our CPUs with
+* 32-bit EL0 online so that is_cpu_allowed() doesn't end up rejecting
+* every CPU in the system for a 32-bit task.
+*/
+ lucky_winner = cpu_32bit ? cpu : cpumask_any_and(cpu_32bit_el0_mask,
+cpu_active_mask);
+ get_cpu_device(lucky_winner)->offline_disabled = true;
+ pr_info("Asymmetric 32-bit EL0 support detected on CPU %u; CPU
hot-unplug disabled on CPU %u\n",
+ cpu, lucky_winner);
return 0;
}
--
2.29.2.299.gdc1121823c-goog
[PATCH v3 09/14] cpuset: Don't use the cpu_possible_mask as a last resort for cgroup v1
If the scheduler cannot find an allowed CPU for a task,
cpuset_cpus_allowed_fallback() will widen the affinity to cpu_possible_mask
if cgroup v1 is in use.
In preparation for allowing architectures to provide their own fallback
mask, just return early if we're not using cgroup v2 and allow
select_fallback_rq() to figure out the mask by itself.
Cc: Li Zefan
Cc: Tejun Heo
Cc: Johannes Weiner
Signed-off-by: Will Deacon
---
kernel/cgroup/cpuset.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 57b5b5d0a5fd..e970737c3ed2 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -3299,9 +3299,11 @@ void cpuset_cpus_allowed(struct task_struct *tsk, struct
cpumask *pmask)
void cpuset_cpus_allowed_fallback(struct task_struct *tsk)
{
+ if (!is_in_v2_mode())
+ return; /* select_fallback_rq will try harder */
+
rcu_read_lock();
- do_set_cpus_allowed(tsk, is_in_v2_mode() ?
- task_cs(tsk)->cpus_allowed : cpu_possible_mask);
+ do_set_cpus_allowed(tsk, task_cs(tsk)->cpus_allowed);
rcu_read_unlock();
/*
--
2.29.2.299.gdc1121823c-goog
[PATCH v3 07/14] sched: Introduce restrict_cpus_allowed_ptr() to limit task CPU affinity
Asymmetric systems may not offer the same level of userspace ISA support
across all CPUs, meaning that some applications cannot be executed by
some CPUs. As a concrete example, upcoming arm64 big.LITTLE designs do
not feature support for 32-bit applications on both clusters.
Although userspace can carefully manage the affinity masks for such
tasks, one place where it is particularly problematic is execve()
because the CPU on which the execve() is occurring may be incompatible
with the new application image. In such a situation, it is desirable to
restrict the affinity mask of the task and ensure that the new image is
entered on a compatible CPU. From userspace's point of view, this looks
the same as if the incompatible CPUs have been hotplugged off in its
affinity mask.
In preparation for restricting the affinity mask for compat tasks on
arm64 systems without uniform support for 32-bit applications, introduce
a restrict_cpus_allowed_ptr(), which allows the current affinity mask
for a task to be shrunk to the intersection of a parameter mask.
Signed-off-by: Will Deacon
---
include/linux/sched.h | 1 +
kernel/sched/core.c | 73 ++-
2 files changed, 59 insertions(+), 15 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 063cd120b459..1cd12c3ce9ee 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1631,6 +1631,7 @@ extern int task_can_attach(struct task_struct *p, const
struct cpumask *cs_cpus_
#ifdef CONFIG_SMP
extern void do_set_cpus_allowed(struct task_struct *p, const struct cpumask
*new_mask);
extern int set_cpus_allowed_ptr(struct task_struct *p, const struct cpumask
*new_mask);
+extern int restrict_cpus_allowed_ptr(struct task_struct *p, const struct
cpumask *mask);
#else
static inline void do_set_cpus_allowed(struct task_struct *p, const struct
cpumask *new_mask)
{
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d2003a7d5ab5..818c8f7bdf2a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1860,24 +1860,18 @@ void do_set_cpus_allowed(struct task_struct *p, const
struct cpumask *new_mask)
}
/*
- * Change a given task's CPU affinity. Migrate the thread to a
- * proper CPU and schedule it away if the CPU it's executing on
- * is removed from the allowed bitmask.
- *
- * NOTE: the caller must have a valid reference to the task, the
- * task must not exit() & deallocate itself prematurely. The
- * call is not atomic; no spinlocks may be held.
+ * Called with both p->pi_lock and rq->lock held; drops both before returning.
*/
-static int __set_cpus_allowed_ptr(struct task_struct *p,
- const struct cpumask *new_mask, bool check)
+static int __set_cpus_allowed_ptr_locked(struct task_struct *p,
+const struct cpumask *new_mask,
+bool check,
+struct rq *rq,
+struct rq_flags *rf)
{
const struct cpumask *cpu_valid_mask = cpu_active_mask;
unsigned int dest_cpu;
- struct rq_flags rf;
- struct rq *rq;
int ret = 0;
- rq = task_rq_lock(p, &rf);
update_rq_clock(rq);
if (p->flags & PF_KTHREAD) {
@@ -1929,7 +1923,7 @@ static int __set_cpus_allowed_ptr(struct task_struct *p,
if (task_running(rq, p) || p->state == TASK_WAKING) {
struct migration_arg arg = { p, dest_cpu };
/* Need help from migration thread: drop lock and wait. */
- task_rq_unlock(rq, p, &rf);
+ task_rq_unlock(rq, p, rf);
stop_one_cpu(cpu_of(rq), migration_cpu_stop, &arg);
return 0;
} else if (task_on_rq_queued(p)) {
@@ -1937,20 +1931,69 @@ static int __set_cpus_allowed_ptr(struct task_struct *p,
* OK, since we're going to drop the lock immediately
* afterwards anyway.
*/
- rq = move_queued_task(rq, &rf, p, dest_cpu);
+ rq = move_queued_task(rq, rf, p, dest_cpu);
}
out:
- task_rq_unlock(rq, p, &rf);
+ task_rq_unlock(rq, p, rf);
return ret;
}
+/*
+ * Change a given task's CPU affinity. Migrate the thread to a
+ * proper CPU and schedule it away if the CPU it's executing on
+ * is removed from the allowed bitmask.
+ *
+ * NOTE: the caller must have a valid reference to the task, the
+ * task must not exit() & deallocate itself prematurely. The
+ * call is not atomic; no spinlocks may be held.
+ */
+static int __set_cpus_allowed_ptr(struct task_struct *p,
+ const struct cpumask *new_mask, bool check)
+{
+ struct rq_flags rf;
+ struct rq *rq;
+
+ rq = task_rq_lock(p, &rf);
+ return __set_cpus_allowed_ptr_locked(p, new_mask, check, rq, &rf);
+}
+
int set_cpus_allowed_ptr(struct task_struct *p, const struct cpum
