Re: [PATCH 2/7] tty: Remove trailing whitespace
On Thu, Oct 18, 2018 at 07:19:33AM +0200, Greg Kroah-Hartman wrote: > On Wed, Oct 17, 2018 at 10:21:25AM +1100, Tobin C. Harding wrote: > > From: "Tobin C. Harding" > > > > Currently files under drivers/tty/ contain trailing whitespace. This is > > easy to fix and easy to review so lets do it now before we do other > > kernel-docs cleanups. > > > > Signed-off-by: Tobin C. Harding > > This patch is an example of the from and signed-off-by line not > matching. Seems like it happened on every-other-one. > > Perhaps your git setup was wrong for when you committed the patches? Thanks Greg, tunnel vision I only read the first 'From:' header! I rekon I must of done some of these patches before I setup git with the new address. This has the serendipitous outcome of explaining why people add that second 'From:' in patches with a different email of their own - I've always wondered why that was :) Will fix and re-spin. thanks, Tobin.
Re: [PATCH 2/7] tty: Remove trailing whitespace
On Thu, Oct 18, 2018 at 07:19:33AM +0200, Greg Kroah-Hartman wrote: > On Wed, Oct 17, 2018 at 10:21:25AM +1100, Tobin C. Harding wrote: > > From: "Tobin C. Harding" > > > > Currently files under drivers/tty/ contain trailing whitespace. This is > > easy to fix and easy to review so lets do it now before we do other > > kernel-docs cleanups. > > > > Signed-off-by: Tobin C. Harding > > This patch is an example of the from and signed-off-by line not > matching. Seems like it happened on every-other-one. > > Perhaps your git setup was wrong for when you committed the patches? Thanks Greg, tunnel vision I only read the first 'From:' header! I rekon I must of done some of these patches before I setup git with the new address. This has the serendipitous outcome of explaining why people add that second 'From:' in patches with a different email of their own - I've always wondered why that was :) Will fix and re-spin. thanks, Tobin.
Re: [PATCH 2/4] Renames variable to fix shadow warning.
* Leonardo Bras wrote:
> Thanks Ingo,
> On Wed, Oct 17, 2018 at 3:01 AM Ingo Molnar wrote:
> >
> >
> > * Leonardo Brás wrote:
> >
> > > Renames the char variable to avoid shadowing a variable previously
> > > declared on this function.
> > >
> > > Signed-off-by: Leonardo Brás
> > > ---
> > > arch/x86/entry/vdso/vdso2c.h | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/x86/entry/vdso/vdso2c.h b/arch/x86/entry/vdso/vdso2c.h
> > > index fa847a620f40..9466998d0f28 100644
> > > --- a/arch/x86/entry/vdso/vdso2c.h
> > > +++ b/arch/x86/entry/vdso/vdso2c.h
> > > @@ -93,11 +93,11 @@ static void BITSFUNC(go)(void *raw_addr, size_t
> > > raw_len,
> > > int k;
> > > ELF(Sym) *sym = raw_addr + GET_LE(_hdr->sh_offset) +
> > > GET_LE(_hdr->sh_entsize) * i;
> > > - const char *name = raw_addr +
> > > GET_LE(_hdr->sh_offset) +
> > > + const char *name2 = raw_addr +
> > > GET_LE(_hdr->sh_offset) +
> > > GET_LE(>st_name);
> > >
> > > for (k = 0; k < NSYMS; k++) {
> > > - if (!strcmp(name, required_syms[k].name)) {
> > > + if (!strcmp(name2, required_syms[k].name)) {
> > > if (syms[k]) {
> > > fail("duplicate symbol %s\n",
> > >required_syms[k].name);
> >
> > NAK.
> >
> > Please read and understand the code and rename both variables to
> > meaningful names, not just a mindless name/name2 ...
> >
>
> It's changed! This change will be available on v2.
Thanks!
Ingo
Re: [PATCH 2/4] Renames variable to fix shadow warning.
* Leonardo Bras wrote:
> Thanks Ingo,
> On Wed, Oct 17, 2018 at 3:01 AM Ingo Molnar wrote:
> >
> >
> > * Leonardo Brás wrote:
> >
> > > Renames the char variable to avoid shadowing a variable previously
> > > declared on this function.
> > >
> > > Signed-off-by: Leonardo Brás
> > > ---
> > > arch/x86/entry/vdso/vdso2c.h | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/x86/entry/vdso/vdso2c.h b/arch/x86/entry/vdso/vdso2c.h
> > > index fa847a620f40..9466998d0f28 100644
> > > --- a/arch/x86/entry/vdso/vdso2c.h
> > > +++ b/arch/x86/entry/vdso/vdso2c.h
> > > @@ -93,11 +93,11 @@ static void BITSFUNC(go)(void *raw_addr, size_t
> > > raw_len,
> > > int k;
> > > ELF(Sym) *sym = raw_addr + GET_LE(_hdr->sh_offset) +
> > > GET_LE(_hdr->sh_entsize) * i;
> > > - const char *name = raw_addr +
> > > GET_LE(_hdr->sh_offset) +
> > > + const char *name2 = raw_addr +
> > > GET_LE(_hdr->sh_offset) +
> > > GET_LE(>st_name);
> > >
> > > for (k = 0; k < NSYMS; k++) {
> > > - if (!strcmp(name, required_syms[k].name)) {
> > > + if (!strcmp(name2, required_syms[k].name)) {
> > > if (syms[k]) {
> > > fail("duplicate symbol %s\n",
> > >required_syms[k].name);
> >
> > NAK.
> >
> > Please read and understand the code and rename both variables to
> > meaningful names, not just a mindless name/name2 ...
> >
>
> It's changed! This change will be available on v2.
Thanks!
Ingo
Re: [GIT PULL 00/11] perf/urgent fixes
* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > Best Regards, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit c1883f10cfe05c707cce46d6999411c50a2413ca: > > Merge tag 'perf-urgent-for-mingo-4.19-20181005' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent > (2018-10-05 18:14:00 +0200) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-urgent-for-mingo-4.19-20181017 > > for you to fetch changes up to edeb0c90df3581b821a764052d185df985f8b8dc: > > perf tools: Stop fallbacking to kallsyms for vdso symbols lookup > (2018-10-17 15:56:15 -0300) > > > perf/urgent fixes: > > - Stop fallbacking to kallsyms for vDSO symbols lookup, this wasn't > being really used and is not valid in arches such as Sparc, where > user and kernel space don't share the address space, relying only on > cpumode to figure out what DSOs to lookup (Arnaldo Carvalho de Melo) > > - Align cpu map synthesized events properly, fixing SIGBUS in > CPUs like Sparc (David Miller) > > - Fix use of alternatives to find JDIR (Jarod Wilson) > > - Store ids for events with their own cpus when synthesizing user > level event details (scale, unit, etc) events, fixing a crash > when recording a PMU event with a cpumask defined (Jiri Olsa) > > - Fix wrong filter_band* values for uncore Intel vendor events (Jiri Olsa) > > - Fix detection of tracefs path in systems without tracefs, where > that path should be the debugfs mountpoint plus "/tracing/" (Jiri Olsa) > > - Pass build flags to traceevent build, allowing using alternative > flags in distro packages, RPM, for instance (Jiri Olsa) > > - Fix 'perf report' crash on invalid inline debug information (Milian Wolff) > > - Synch kvm uapi copies (Arnaldo Carvalho de Melo) > > Signed-off-by: Arnaldo Carvalho de Melo > > > Arnaldo Carvalho de Melo (3): > tools arch uapi: Sync the x86 kvm.h copy > tools headers uapi: Sync kvm.h copy > perf tools: Stop fallbacking to kallsyms for vdso symbols lookup > > David Miller (1): > perf cpu_map: Align cpu map synthesized events properly. > > Jarod Wilson (1): > perf tools: Fix use of alternatives to find JDIR > > Jiri Olsa (5): > Revert "perf tools: Fix PMU term format max value calculation" > perf vendor events intel: Fix wrong filter_band* values for uncore > events > perf evsel: Store ids for events with their own cpus > perf_event__synthesize_event_update_cpus > perf tools: Fix tracing_path_mount proper path > perf tools: Pass build flags to traceevent build > > Milian Wolff (1): > perf report: Don't crash on invalid inline debug information > > tools/arch/x86/include/uapi/asm/kvm.h | 1 + > tools/include/uapi/linux/kvm.h | 1 + > tools/lib/api/fs/tracing_path.c| 4 ++-- > tools/perf/Makefile.config | 2 +- > tools/perf/Makefile.perf | 2 +- > tools/perf/builtin-report.c| 1 + > .../pmu-events/arch/x86/ivytown/uncore-power.json | 16 > .../pmu-events/arch/x86/jaketown/uncore-power.json | 16 > tools/perf/util/event.c| 22 > +++--- > tools/perf/util/evsel.c| 3 +++ > tools/perf/util/pmu.c | 13 +++-- > tools/perf/util/srcline.c | 3 +++ > 12 files changed, 39 insertions(+), 45 deletions(-) Pulled, thanks a lot Arnaldo! Ingo
Re: [GIT PULL 00/11] perf/urgent fixes
* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > Best Regards, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit c1883f10cfe05c707cce46d6999411c50a2413ca: > > Merge tag 'perf-urgent-for-mingo-4.19-20181005' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent > (2018-10-05 18:14:00 +0200) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-urgent-for-mingo-4.19-20181017 > > for you to fetch changes up to edeb0c90df3581b821a764052d185df985f8b8dc: > > perf tools: Stop fallbacking to kallsyms for vdso symbols lookup > (2018-10-17 15:56:15 -0300) > > > perf/urgent fixes: > > - Stop fallbacking to kallsyms for vDSO symbols lookup, this wasn't > being really used and is not valid in arches such as Sparc, where > user and kernel space don't share the address space, relying only on > cpumode to figure out what DSOs to lookup (Arnaldo Carvalho de Melo) > > - Align cpu map synthesized events properly, fixing SIGBUS in > CPUs like Sparc (David Miller) > > - Fix use of alternatives to find JDIR (Jarod Wilson) > > - Store ids for events with their own cpus when synthesizing user > level event details (scale, unit, etc) events, fixing a crash > when recording a PMU event with a cpumask defined (Jiri Olsa) > > - Fix wrong filter_band* values for uncore Intel vendor events (Jiri Olsa) > > - Fix detection of tracefs path in systems without tracefs, where > that path should be the debugfs mountpoint plus "/tracing/" (Jiri Olsa) > > - Pass build flags to traceevent build, allowing using alternative > flags in distro packages, RPM, for instance (Jiri Olsa) > > - Fix 'perf report' crash on invalid inline debug information (Milian Wolff) > > - Synch kvm uapi copies (Arnaldo Carvalho de Melo) > > Signed-off-by: Arnaldo Carvalho de Melo > > > Arnaldo Carvalho de Melo (3): > tools arch uapi: Sync the x86 kvm.h copy > tools headers uapi: Sync kvm.h copy > perf tools: Stop fallbacking to kallsyms for vdso symbols lookup > > David Miller (1): > perf cpu_map: Align cpu map synthesized events properly. > > Jarod Wilson (1): > perf tools: Fix use of alternatives to find JDIR > > Jiri Olsa (5): > Revert "perf tools: Fix PMU term format max value calculation" > perf vendor events intel: Fix wrong filter_band* values for uncore > events > perf evsel: Store ids for events with their own cpus > perf_event__synthesize_event_update_cpus > perf tools: Fix tracing_path_mount proper path > perf tools: Pass build flags to traceevent build > > Milian Wolff (1): > perf report: Don't crash on invalid inline debug information > > tools/arch/x86/include/uapi/asm/kvm.h | 1 + > tools/include/uapi/linux/kvm.h | 1 + > tools/lib/api/fs/tracing_path.c| 4 ++-- > tools/perf/Makefile.config | 2 +- > tools/perf/Makefile.perf | 2 +- > tools/perf/builtin-report.c| 1 + > .../pmu-events/arch/x86/ivytown/uncore-power.json | 16 > .../pmu-events/arch/x86/jaketown/uncore-power.json | 16 > tools/perf/util/event.c| 22 > +++--- > tools/perf/util/evsel.c| 3 +++ > tools/perf/util/pmu.c | 13 +++-- > tools/perf/util/srcline.c | 3 +++ > 12 files changed, 39 insertions(+), 45 deletions(-) Pulled, thanks a lot Arnaldo! Ingo
Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.
Sergey Senozhatsky wrote: > To my personal taste, "baud rate of registered and enabled consoles" > approach is drastically more relevant than hard coded 10 * HZ or > 60 * HZ magic numbers... But not in the form of that "min baud rate" > brain fart, which I have posted. I'm saying that my 60 * HZ is "duration which the OOM killer keeps refraining from calling printk()". Such period is required for allowing console users to do their operations without being disturbed by the OOM killer. Even if you succeeded to calculate average speed of the OOM killer messages being flushed to consoles, printing the OOM killer messages with that speed will keep the console users unable to do their operations. Please do not print the OOM killer messages when the OOM killer cannot make progress... It just disturbs console users.
Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.
Sergey Senozhatsky wrote: > To my personal taste, "baud rate of registered and enabled consoles" > approach is drastically more relevant than hard coded 10 * HZ or > 60 * HZ magic numbers... But not in the form of that "min baud rate" > brain fart, which I have posted. I'm saying that my 60 * HZ is "duration which the OOM killer keeps refraining from calling printk()". Such period is required for allowing console users to do their operations without being disturbed by the OOM killer. Even if you succeeded to calculate average speed of the OOM killer messages being flushed to consoles, printing the OOM killer messages with that speed will keep the console users unable to do their operations. Please do not print the OOM killer messages when the OOM killer cannot make progress... It just disturbs console users.
Re: [PATCH] Input: pm8941-pwrkey - Add pms405 pwrkey support
On 19-09-18, 18:49, Bjorn Andersson wrote:
> From: Vinod Koul
>
> Update the binding and driver for pms405 pwrkey.
Rob, Dmitry
Gentle reminder for this patch...
> Signed-off-by: Vinod Koul
> Signed-off-by: Bjorn Andersson
> ---
> Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt | 1 +
> drivers/input/misc/pm8941-pwrkey.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> index 34ab5763f494..736fba3bad54 100644
> --- a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> +++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> @@ -8,6 +8,7 @@ PROPERTIES
> Definition: must be one of:
> "qcom,pm8941-pwrkey"
> "qcom,pm8941-resin"
> + "qcom,pms405-pwrkey"
>
> - reg:
> Usage: required
> diff --git a/drivers/input/misc/pm8941-pwrkey.c
> b/drivers/input/misc/pm8941-pwrkey.c
> index 48153e0ca19a..fccf63263c1c 100644
> --- a/drivers/input/misc/pm8941-pwrkey.c
> +++ b/drivers/input/misc/pm8941-pwrkey.c
> @@ -317,6 +317,7 @@ static const struct pm8941_data resin_data = {
> static const struct of_device_id pm8941_pwr_key_id_table[] = {
> { .compatible = "qcom,pm8941-pwrkey", .data = _data },
> { .compatible = "qcom,pm8941-resin", .data = _data },
> + { .compatible = "qcom,pms405-pwrkey", .data = _data },
> { }
> };
> MODULE_DEVICE_TABLE(of, pm8941_pwr_key_id_table);
> --
> 2.18.0
--
~Vinod
Re: [PATCH] Input: pm8941-pwrkey - Add pms405 pwrkey support
On 19-09-18, 18:49, Bjorn Andersson wrote:
> From: Vinod Koul
>
> Update the binding and driver for pms405 pwrkey.
Rob, Dmitry
Gentle reminder for this patch...
> Signed-off-by: Vinod Koul
> Signed-off-by: Bjorn Andersson
> ---
> Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt | 1 +
> drivers/input/misc/pm8941-pwrkey.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> index 34ab5763f494..736fba3bad54 100644
> --- a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> +++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> @@ -8,6 +8,7 @@ PROPERTIES
> Definition: must be one of:
> "qcom,pm8941-pwrkey"
> "qcom,pm8941-resin"
> + "qcom,pms405-pwrkey"
>
> - reg:
> Usage: required
> diff --git a/drivers/input/misc/pm8941-pwrkey.c
> b/drivers/input/misc/pm8941-pwrkey.c
> index 48153e0ca19a..fccf63263c1c 100644
> --- a/drivers/input/misc/pm8941-pwrkey.c
> +++ b/drivers/input/misc/pm8941-pwrkey.c
> @@ -317,6 +317,7 @@ static const struct pm8941_data resin_data = {
> static const struct of_device_id pm8941_pwr_key_id_table[] = {
> { .compatible = "qcom,pm8941-pwrkey", .data = _data },
> { .compatible = "qcom,pm8941-resin", .data = _data },
> + { .compatible = "qcom,pms405-pwrkey", .data = _data },
> { }
> };
> MODULE_DEVICE_TABLE(of, pm8941_pwr_key_id_table);
> --
> 2.18.0
--
~Vinod
Re: Crash in msm serial on dragonboard with ftrace bootargs
On 10/18/2018 8:03 AM, Steven Rostedt wrote: On Wed, 17 Oct 2018 00:36:05 +0530 Sai Prakash Ranjan wrote: On 10/17/2018 12:33 AM, Steven Rostedt wrote: On Wed, 17 Oct 2018 00:31:03 +0530 Sai Prakash Ranjan wrote: Haa seems like you are right! With "ftrace=function ftrace_filter=msm_read" , I can trigger the crash, but sadly "ftrace_notrace=msm_read" also crashes. So there's more than one problem area. What about ftrace_notrace=m* ? That too crashes. So something else is causing an issue besides just msm_read. Can you do an objdump -dr of the entire vmlinux binary and gzip it and post it somewhere. Not sure if it would be too big to email. You could try sending it to me privately. I'd like to see the binary that you are using. I have sent the objdump and dot config to you privately. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH V2 4/5] Drivers: hv: kvp: Use %u to print U32
From: Dexuan Cui I didn't find a real issue. Let's just make it consistent with the next "case REG_U64:" where %llu is used. Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen Hemminger Signed-off-by: K. Y. Srinivasan --- drivers/hv/hv_kvp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c index d6106e1a0d4a..5054d1105236 100644 --- a/drivers/hv/hv_kvp.c +++ b/drivers/hv/hv_kvp.c @@ -437,7 +437,7 @@ kvp_send_key(struct work_struct *dummy) val32 = in_msg->body.kvp_set.data.value_u32; message->body.kvp_set.data.value_size = sprintf(message->body.kvp_set.data.value, - "%d", val32) + 1; + "%u", val32) + 1; break; case REG_U64: -- 2.18.0
Re: Crash in msm serial on dragonboard with ftrace bootargs
On 10/18/2018 8:03 AM, Steven Rostedt wrote: On Wed, 17 Oct 2018 00:36:05 +0530 Sai Prakash Ranjan wrote: On 10/17/2018 12:33 AM, Steven Rostedt wrote: On Wed, 17 Oct 2018 00:31:03 +0530 Sai Prakash Ranjan wrote: Haa seems like you are right! With "ftrace=function ftrace_filter=msm_read" , I can trigger the crash, but sadly "ftrace_notrace=msm_read" also crashes. So there's more than one problem area. What about ftrace_notrace=m* ? That too crashes. So something else is causing an issue besides just msm_read. Can you do an objdump -dr of the entire vmlinux binary and gzip it and post it somewhere. Not sure if it would be too big to email. You could try sending it to me privately. I'd like to see the binary that you are using. I have sent the objdump and dot config to you privately. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH V2 4/5] Drivers: hv: kvp: Use %u to print U32
From: Dexuan Cui I didn't find a real issue. Let's just make it consistent with the next "case REG_U64:" where %llu is used. Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen Hemminger Signed-off-by: K. Y. Srinivasan --- drivers/hv/hv_kvp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c index d6106e1a0d4a..5054d1105236 100644 --- a/drivers/hv/hv_kvp.c +++ b/drivers/hv/hv_kvp.c @@ -437,7 +437,7 @@ kvp_send_key(struct work_struct *dummy) val32 = in_msg->body.kvp_set.data.value_u32; message->body.kvp_set.data.value_size = sprintf(message->body.kvp_set.data.value, - "%d", val32) + 1; + "%u", val32) + 1; break; case REG_U64: -- 2.18.0
[PATCH V2 0/5] Drivers: hv: Miscellaneous fixes
From: "K. Y. Srinivasan" Miscellaneous fixes. V2: Addressed comments from Greg. Dexuan Cui (3): Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up Drivers: hv: kvp: Use %u to print U32 Tools: hv: kvp: Fix a warning of buffer overflow with gcc 8.0.1 Haiyang Zhang (1): hv_utils: update name in struct hv_driver util_drv K. Y. Srinivasan (1): Drivers: hv: vmbus: Get rid of unnecessary state in hv_context drivers/hv/hv.c | 10 +++--- drivers/hv/hv_kvp.c | 28 +++- drivers/hv/hv_util.c | 2 +- drivers/hv/hyperv_vmbus.h | 2 -- tools/hv/hv_kvp_daemon.c | 15 +-- 5 files changed, 40 insertions(+), 17 deletions(-) -- 2.18.0
[PATCH V2 0/5] Drivers: hv: Miscellaneous fixes
From: "K. Y. Srinivasan" Miscellaneous fixes. V2: Addressed comments from Greg. Dexuan Cui (3): Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up Drivers: hv: kvp: Use %u to print U32 Tools: hv: kvp: Fix a warning of buffer overflow with gcc 8.0.1 Haiyang Zhang (1): hv_utils: update name in struct hv_driver util_drv K. Y. Srinivasan (1): Drivers: hv: vmbus: Get rid of unnecessary state in hv_context drivers/hv/hv.c | 10 +++--- drivers/hv/hv_kvp.c | 28 +++- drivers/hv/hv_util.c | 2 +- drivers/hv/hyperv_vmbus.h | 2 -- tools/hv/hv_kvp_daemon.c | 15 +-- 5 files changed, 40 insertions(+), 17 deletions(-) -- 2.18.0
Re: [PATCH 2/7] tty: Remove trailing whitespace
On Wed, Oct 17, 2018 at 10:21:25AM +1100, Tobin C. Harding wrote: > From: "Tobin C. Harding" > > Currently files under drivers/tty/ contain trailing whitespace. This is > easy to fix and easy to review so lets do it now before we do other > kernel-docs cleanups. > > Signed-off-by: Tobin C. Harding This patch is an example of the from and signed-off-by line not matching. Seems like it happened on every-other-one. Perhaps your git setup was wrong for when you committed the patches? thanks, greg k-h
Re: [PATCH 2/7] tty: Remove trailing whitespace
On Wed, Oct 17, 2018 at 10:21:25AM +1100, Tobin C. Harding wrote: > From: "Tobin C. Harding" > > Currently files under drivers/tty/ contain trailing whitespace. This is > easy to fix and easy to review so lets do it now before we do other > kernel-docs cleanups. > > Signed-off-by: Tobin C. Harding This patch is an example of the from and signed-off-by line not matching. Seems like it happened on every-other-one. Perhaps your git setup was wrong for when you committed the patches? thanks, greg k-h
[PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
From: Liang Yang Add initial support for the Amlogic NAND flash controller which found in the Meson-GXBB/GXL/AXG SoCs. Signed-off-by: Liang Yang Signed-off-by: Yixun Lan Signed-off-by: Jianxin Pan --- drivers/mtd/nand/raw/Kconfig | 10 + drivers/mtd/nand/raw/Makefile |1 + drivers/mtd/nand/raw/meson_nand.c | 1370 + 3 files changed, 1381 insertions(+) create mode 100644 drivers/mtd/nand/raw/meson_nand.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index c7efc31..223b041 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -541,4 +541,14 @@ config MTD_NAND_TEGRA is supported. Extra OOB bytes when using HW ECC are currently not supported. +config MTD_NAND_MESON + tristate "Support for NAND controller on Amlogic's Meson SoCs" + depends on ARCH_MESON || COMPILE_TEST + depends on COMMON_CLK_AMLOGIC + select COMMON_CLK_REGMAP_MESON + select MFD_SYSCON + help + Enables support for NAND controller on Amlogic's Meson SoCs. + This controller is found on Meson GXBB, GXL, AXG SoCs. + endif # MTD_NAND diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index 57159b3..a2cc2fe 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -56,6 +56,7 @@ obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand/ obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o obj-$(CONFIG_MTD_NAND_MTK) += mtk_ecc.o mtk_nand.o obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o +obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o nand-objs += nand_onfi.o diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c new file mode 100644 index 000..bcaac53 --- /dev/null +++ b/drivers/mtd/nand/raw/meson_nand.c @@ -0,0 +1,1370 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Amlogic Meson Nand Flash Controller Driver + * + * Copyright (c) 2018 Amlogic, inc. + * Author: Liang Yang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define NFC_REG_CMD0x00 +#define NFC_CMD_DRD(0x8 << 14) +#define NFC_CMD_IDLE (0xc << 14) +#define NFC_CMD_DWR(0x4 << 14) +#define NFC_CMD_CLE(0x5 << 14) +#define NFC_CMD_ALE(0x6 << 14) +#define NFC_CMD_ADL((0 << 16) | (3 << 20)) +#define NFC_CMD_ADH((1 << 16) | (3 << 20)) +#define NFC_CMD_AIL((2 << 16) | (3 << 20)) +#define NFC_CMD_AIH((3 << 16) | (3 << 20)) +#define NFC_CMD_SEED ((8 << 16) | (3 << 20)) +#define NFC_CMD_M2N((0 << 17) | (2 << 20)) +#define NFC_CMD_N2M((1 << 17) | (2 << 20)) +#define NFC_CMD_RB BIT(20) +#define NFC_CMD_IO6((0xb << 10) | (1 << 18)) + +#define NFC_REG_CFG0x04 +#define NFC_REG_DADR 0x08 +#define NFC_REG_IADR 0x0c +#define NFC_REG_BUF0x10 +#define NFC_REG_INFO 0x14 +#define NFC_REG_DC 0x18 +#define NFC_REG_ADR0x1c +#define NFC_REG_DL 0x20 +#define NFC_REG_DH 0x24 +#define NFC_REG_CADR 0x28 +#define NFC_REG_SADR 0x2c +#define NFC_REG_PINS 0x30 +#define NFC_REG_VER0x38 + +#define NFC_RB_IRQ_EN BIT(21) +#define NFC_INT_MASK (3 << 20) + +#define CMDRWGEN(cmd_dir, ran, bch, short_mode, page_size, pages) \ + ( \ + (cmd_dir) | \ + ((ran) << 19) | \ + ((bch) << 14) | \ + ((short_mode) << 13)| \ + (((page_size) & 0x7f) << 6) | \ + ((pages) & 0x3f)\ + ) + +#define GENCMDDADDRL(adl, addr)((adl) | ((addr) & 0x)) +#define GENCMDDADDRH(adh, addr)((adh) | (((addr) >> 16) & 0x)) +#define GENCMDIADDRL(ail, addr)((ail) | ((addr) & 0x)) +#define GENCMDIADDRH(aih, addr)((aih) | (((addr) >> 16) & 0x)) + +#define RB_STA(x) (1 << (26 + (x))) +#define DMA_DIR(dir) ((dir) ? NFC_CMD_N2M : NFC_CMD_M2N) + +#define ECC_CHECK_RETURN_FF(-1) + +#define NAND_CE0 (0xe << 10) +#define NAND_CE1 (0xd << 10) + +#define DMA_BUSY_TIMEOUT 0x10 +#define CMD_FIFO_EMPTY_TIMEOUT 1000 + +#define MAX_CE_NUM 2 + +/* eMMC clock register, misc control */ +#define SD_EMMC_CLOCK 0x00 +#define
[PATCH V2 2/5] hv_utils: update name in struct hv_driver util_drv
From: Haiyang Zhang
The correct module name is hv_utils. This patch corrects
the name in struct hv_driver util_drv.
Signed-off-by: Haiyang Zhang
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 423205077bf6..f10eeb120c8b 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -483,7 +483,7 @@ MODULE_DEVICE_TABLE(vmbus, id_table);
/* The one and only one */
static struct hv_driver util_drv = {
- .name = "hv_util",
+ .name = "hv_utils",
.id_table = id_table,
.probe = util_probe,
.remove = util_remove,
--
2.18.0
[PATCH V2 1/5] Drivers: hv: vmbus: Get rid of unnecessary state in hv_context
From: "K. Y. Srinivasan"
Currently we are replicating state in struct hv_context that is unnecessary -
this state can be retrieved from the hypervisor. Furthermore, this is a per-cpu
state that is being maintained as a global state in struct hv_context.
Get rid of this state in struct hv_context.
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv.c | 10 +++---
drivers/hv/hyperv_vmbus.h | 2 --
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 332d7c34be5c..166c2501de17 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -33,9 +33,7 @@
#include "hyperv_vmbus.h"
/* The one and only */
-struct hv_context hv_context = {
- .synic_initialized = false,
-};
+struct hv_context hv_context;
/*
* If false, we're using the old mechanism for stimer0 interrupts
@@ -326,8 +324,6 @@ int hv_synic_init(unsigned int cpu)
hv_set_synic_state(sctrl.as_uint64);
- hv_context.synic_initialized = true;
-
/*
* Register the per-cpu clockevent source.
*/
@@ -373,7 +369,8 @@ int hv_synic_cleanup(unsigned int cpu)
bool channel_found = false;
unsigned long flags;
- if (!hv_context.synic_initialized)
+ hv_get_synic_state(sctrl.as_uint64);
+ if (sctrl.enable != 1)
return -EFAULT;
/*
@@ -435,7 +432,6 @@ int hv_synic_cleanup(unsigned int cpu)
hv_set_siefp(siefp.as_uint64);
/* Disable the global synic bit */
- hv_get_synic_state(sctrl.as_uint64);
sctrl.enable = 0;
hv_set_synic_state(sctrl.as_uint64);
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 72eaba3d50fc..f17c06a5e74b 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -230,8 +230,6 @@ struct hv_context {
void *tsc_page;
- bool synic_initialized;
-
struct hv_per_cpu_context __percpu *cpu_context;
/*
--
2.18.0
[PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
From: Liang Yang Add initial support for the Amlogic NAND flash controller which found in the Meson-GXBB/GXL/AXG SoCs. Signed-off-by: Liang Yang Signed-off-by: Yixun Lan Signed-off-by: Jianxin Pan --- drivers/mtd/nand/raw/Kconfig | 10 + drivers/mtd/nand/raw/Makefile |1 + drivers/mtd/nand/raw/meson_nand.c | 1370 + 3 files changed, 1381 insertions(+) create mode 100644 drivers/mtd/nand/raw/meson_nand.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index c7efc31..223b041 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -541,4 +541,14 @@ config MTD_NAND_TEGRA is supported. Extra OOB bytes when using HW ECC are currently not supported. +config MTD_NAND_MESON + tristate "Support for NAND controller on Amlogic's Meson SoCs" + depends on ARCH_MESON || COMPILE_TEST + depends on COMMON_CLK_AMLOGIC + select COMMON_CLK_REGMAP_MESON + select MFD_SYSCON + help + Enables support for NAND controller on Amlogic's Meson SoCs. + This controller is found on Meson GXBB, GXL, AXG SoCs. + endif # MTD_NAND diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index 57159b3..a2cc2fe 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -56,6 +56,7 @@ obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand/ obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o obj-$(CONFIG_MTD_NAND_MTK) += mtk_ecc.o mtk_nand.o obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o +obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o nand-objs += nand_onfi.o diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c new file mode 100644 index 000..bcaac53 --- /dev/null +++ b/drivers/mtd/nand/raw/meson_nand.c @@ -0,0 +1,1370 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Amlogic Meson Nand Flash Controller Driver + * + * Copyright (c) 2018 Amlogic, inc. + * Author: Liang Yang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define NFC_REG_CMD0x00 +#define NFC_CMD_DRD(0x8 << 14) +#define NFC_CMD_IDLE (0xc << 14) +#define NFC_CMD_DWR(0x4 << 14) +#define NFC_CMD_CLE(0x5 << 14) +#define NFC_CMD_ALE(0x6 << 14) +#define NFC_CMD_ADL((0 << 16) | (3 << 20)) +#define NFC_CMD_ADH((1 << 16) | (3 << 20)) +#define NFC_CMD_AIL((2 << 16) | (3 << 20)) +#define NFC_CMD_AIH((3 << 16) | (3 << 20)) +#define NFC_CMD_SEED ((8 << 16) | (3 << 20)) +#define NFC_CMD_M2N((0 << 17) | (2 << 20)) +#define NFC_CMD_N2M((1 << 17) | (2 << 20)) +#define NFC_CMD_RB BIT(20) +#define NFC_CMD_IO6((0xb << 10) | (1 << 18)) + +#define NFC_REG_CFG0x04 +#define NFC_REG_DADR 0x08 +#define NFC_REG_IADR 0x0c +#define NFC_REG_BUF0x10 +#define NFC_REG_INFO 0x14 +#define NFC_REG_DC 0x18 +#define NFC_REG_ADR0x1c +#define NFC_REG_DL 0x20 +#define NFC_REG_DH 0x24 +#define NFC_REG_CADR 0x28 +#define NFC_REG_SADR 0x2c +#define NFC_REG_PINS 0x30 +#define NFC_REG_VER0x38 + +#define NFC_RB_IRQ_EN BIT(21) +#define NFC_INT_MASK (3 << 20) + +#define CMDRWGEN(cmd_dir, ran, bch, short_mode, page_size, pages) \ + ( \ + (cmd_dir) | \ + ((ran) << 19) | \ + ((bch) << 14) | \ + ((short_mode) << 13)| \ + (((page_size) & 0x7f) << 6) | \ + ((pages) & 0x3f)\ + ) + +#define GENCMDDADDRL(adl, addr)((adl) | ((addr) & 0x)) +#define GENCMDDADDRH(adh, addr)((adh) | (((addr) >> 16) & 0x)) +#define GENCMDIADDRL(ail, addr)((ail) | ((addr) & 0x)) +#define GENCMDIADDRH(aih, addr)((aih) | (((addr) >> 16) & 0x)) + +#define RB_STA(x) (1 << (26 + (x))) +#define DMA_DIR(dir) ((dir) ? NFC_CMD_N2M : NFC_CMD_M2N) + +#define ECC_CHECK_RETURN_FF(-1) + +#define NAND_CE0 (0xe << 10) +#define NAND_CE1 (0xd << 10) + +#define DMA_BUSY_TIMEOUT 0x10 +#define CMD_FIFO_EMPTY_TIMEOUT 1000 + +#define MAX_CE_NUM 2 + +/* eMMC clock register, misc control */ +#define SD_EMMC_CLOCK 0x00 +#define
[PATCH V2 2/5] hv_utils: update name in struct hv_driver util_drv
From: Haiyang Zhang
The correct module name is hv_utils. This patch corrects
the name in struct hv_driver util_drv.
Signed-off-by: Haiyang Zhang
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 423205077bf6..f10eeb120c8b 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -483,7 +483,7 @@ MODULE_DEVICE_TABLE(vmbus, id_table);
/* The one and only one */
static struct hv_driver util_drv = {
- .name = "hv_util",
+ .name = "hv_utils",
.id_table = id_table,
.probe = util_probe,
.remove = util_remove,
--
2.18.0
[PATCH V2 1/5] Drivers: hv: vmbus: Get rid of unnecessary state in hv_context
From: "K. Y. Srinivasan"
Currently we are replicating state in struct hv_context that is unnecessary -
this state can be retrieved from the hypervisor. Furthermore, this is a per-cpu
state that is being maintained as a global state in struct hv_context.
Get rid of this state in struct hv_context.
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv.c | 10 +++---
drivers/hv/hyperv_vmbus.h | 2 --
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 332d7c34be5c..166c2501de17 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -33,9 +33,7 @@
#include "hyperv_vmbus.h"
/* The one and only */
-struct hv_context hv_context = {
- .synic_initialized = false,
-};
+struct hv_context hv_context;
/*
* If false, we're using the old mechanism for stimer0 interrupts
@@ -326,8 +324,6 @@ int hv_synic_init(unsigned int cpu)
hv_set_synic_state(sctrl.as_uint64);
- hv_context.synic_initialized = true;
-
/*
* Register the per-cpu clockevent source.
*/
@@ -373,7 +369,8 @@ int hv_synic_cleanup(unsigned int cpu)
bool channel_found = false;
unsigned long flags;
- if (!hv_context.synic_initialized)
+ hv_get_synic_state(sctrl.as_uint64);
+ if (sctrl.enable != 1)
return -EFAULT;
/*
@@ -435,7 +432,6 @@ int hv_synic_cleanup(unsigned int cpu)
hv_set_siefp(siefp.as_uint64);
/* Disable the global synic bit */
- hv_get_synic_state(sctrl.as_uint64);
sctrl.enable = 0;
hv_set_synic_state(sctrl.as_uint64);
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 72eaba3d50fc..f17c06a5e74b 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -230,8 +230,6 @@ struct hv_context {
void *tsc_page;
- bool synic_initialized;
-
struct hv_per_cpu_context __percpu *cpu_context;
/*
--
2.18.0
[PATCH V2 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up
From: Dexuan Cui
In kvp_send_key(), we do need call process_ib_ipinfo() if
message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns out
the userland hv_kvp_daemon needs the info of operation, adapter_id and
addr_family. With the incorrect fc62c3b1977d, the host can't get the
VM's IP via KVP.
And, fc62c3b1977d added a "break;", but actually forgot to initialize
the key_size/value in the case of KVP_OP_SET, so the default key_size of
0 is passed to the kvp daemon, and the pool files
/var/lib/hyperv/.kvp_pool_* can't be updated.
This patch effectively rolls back the previous fc62c3b1977d, and
correctly fixes the "this statement may fall through" warnings.
This patch is tested on WS 2012 R2 and 2016.
Fixes: fc62c3b1977d ("Drivers: hv: kvp: Fix two "this statement may fall
through" warnings")
Signed-off-by: Dexuan Cui
Cc: K. Y. Srinivasan
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc:
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_kvp.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index a7513a8a8e37..d6106e1a0d4a 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -353,6 +353,9 @@ static void process_ib_ipinfo(void *in_msg, void *out_msg,
int op)
out->body.kvp_ip_val.dhcp_enabled = in->kvp_ip_val.dhcp_enabled;
+ /* fallthrough */
+
+ case KVP_OP_GET_IP_INFO:
utf16s_to_utf8s((wchar_t *)in->kvp_ip_val.adapter_id,
MAX_ADAPTER_ID_SIZE,
UTF16_LITTLE_ENDIAN,
@@ -405,7 +408,11 @@ kvp_send_key(struct work_struct *dummy)
process_ib_ipinfo(in_msg, message, KVP_OP_SET_IP_INFO);
break;
case KVP_OP_GET_IP_INFO:
- /* We only need to pass on message->kvp_hdr.operation. */
+ /*
+* We only need to pass on the info of operation, adapter_id
+* and addr_family to the userland kvp daemon.
+*/
+ process_ib_ipinfo(in_msg, message, KVP_OP_GET_IP_INFO);
break;
case KVP_OP_SET:
switch (in_msg->body.kvp_set.data.value_type) {
@@ -446,9 +453,9 @@ kvp_send_key(struct work_struct *dummy)
}
- break;
-
- case KVP_OP_GET:
+ /*
+* The key is always a string - utf16 encoding.
+*/
message->body.kvp_set.data.key_size =
utf16s_to_utf8s(
(wchar_t *)in_msg->body.kvp_set.data.key,
@@ -456,6 +463,17 @@ kvp_send_key(struct work_struct *dummy)
UTF16_LITTLE_ENDIAN,
message->body.kvp_set.data.key,
HV_KVP_EXCHANGE_MAX_KEY_SIZE - 1) + 1;
+
+ break;
+
+ case KVP_OP_GET:
+ message->body.kvp_get.data.key_size =
+ utf16s_to_utf8s(
+ (wchar_t *)in_msg->body.kvp_get.data.key,
+ in_msg->body.kvp_get.data.key_size,
+ UTF16_LITTLE_ENDIAN,
+ message->body.kvp_get.data.key,
+ HV_KVP_EXCHANGE_MAX_KEY_SIZE - 1) + 1;
break;
case KVP_OP_DELETE:
--
2.18.0
[PATCH V2 5/5] Tools: hv: kvp: Fix a warning of buffer overflow with gcc 8.0.1
From: Dexuan Cui
The patch fixes:
hv_kvp_daemon.c: In function 'kvp_set_ip_info':
hv_kvp_daemon.c:1305:2: note: 'snprintf' output between 41 and 4136 bytes
into a destination of size 4096
The "(unsigned int)str_len" is to avoid:
hv_kvp_daemon.c:1309:30: warning: comparison of integer expressions of
different signedness: 'int' and 'long unsigned int' [-Wsign-compare]
Signed-off-by: Dexuan Cui
Cc: K. Y. Srinivasan
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Signed-off-by: K. Y. Srinivasan
---
tools/hv/hv_kvp_daemon.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index bbb2a8ef367c..d7e06fe0270e 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1178,6 +1178,7 @@ static int kvp_set_ip_info(char *if_name, struct
hv_kvp_ipaddr_value *new_val)
FILE *file;
char cmd[PATH_MAX];
char *mac_addr;
+ int str_len;
/*
* Set the configuration for the specified interface with
@@ -1301,8 +1302,18 @@ static int kvp_set_ip_info(char *if_name, struct
hv_kvp_ipaddr_value *new_val)
* invoke the external script to do its magic.
*/
- snprintf(cmd, sizeof(cmd), KVP_SCRIPTS_PATH "%s %s",
-"hv_set_ifconfig", if_file);
+ str_len = snprintf(cmd, sizeof(cmd), KVP_SCRIPTS_PATH "%s %s",
+ "hv_set_ifconfig", if_file);
+ /*
+* This is a little overcautious, but it's necessary to suppress some
+* false warnings from gcc 8.0.1.
+*/
+ if (str_len <= 0 || (unsigned int)str_len >= sizeof(cmd)) {
+ syslog(LOG_ERR, "Cmd '%s' (len=%d) may be too long",
+ cmd, str_len);
+ return HV_E_FAIL;
+ }
+
if (system(cmd)) {
syslog(LOG_ERR, "Failed to execute cmd '%s'; error: %d %s",
cmd, errno, strerror(errno));
--
2.18.0
[PATCH V2 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up
From: Dexuan Cui
In kvp_send_key(), we do need call process_ib_ipinfo() if
message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns out
the userland hv_kvp_daemon needs the info of operation, adapter_id and
addr_family. With the incorrect fc62c3b1977d, the host can't get the
VM's IP via KVP.
And, fc62c3b1977d added a "break;", but actually forgot to initialize
the key_size/value in the case of KVP_OP_SET, so the default key_size of
0 is passed to the kvp daemon, and the pool files
/var/lib/hyperv/.kvp_pool_* can't be updated.
This patch effectively rolls back the previous fc62c3b1977d, and
correctly fixes the "this statement may fall through" warnings.
This patch is tested on WS 2012 R2 and 2016.
Fixes: fc62c3b1977d ("Drivers: hv: kvp: Fix two "this statement may fall
through" warnings")
Signed-off-by: Dexuan Cui
Cc: K. Y. Srinivasan
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc:
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_kvp.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
index a7513a8a8e37..d6106e1a0d4a 100644
--- a/drivers/hv/hv_kvp.c
+++ b/drivers/hv/hv_kvp.c
@@ -353,6 +353,9 @@ static void process_ib_ipinfo(void *in_msg, void *out_msg,
int op)
out->body.kvp_ip_val.dhcp_enabled = in->kvp_ip_val.dhcp_enabled;
+ /* fallthrough */
+
+ case KVP_OP_GET_IP_INFO:
utf16s_to_utf8s((wchar_t *)in->kvp_ip_val.adapter_id,
MAX_ADAPTER_ID_SIZE,
UTF16_LITTLE_ENDIAN,
@@ -405,7 +408,11 @@ kvp_send_key(struct work_struct *dummy)
process_ib_ipinfo(in_msg, message, KVP_OP_SET_IP_INFO);
break;
case KVP_OP_GET_IP_INFO:
- /* We only need to pass on message->kvp_hdr.operation. */
+ /*
+* We only need to pass on the info of operation, adapter_id
+* and addr_family to the userland kvp daemon.
+*/
+ process_ib_ipinfo(in_msg, message, KVP_OP_GET_IP_INFO);
break;
case KVP_OP_SET:
switch (in_msg->body.kvp_set.data.value_type) {
@@ -446,9 +453,9 @@ kvp_send_key(struct work_struct *dummy)
}
- break;
-
- case KVP_OP_GET:
+ /*
+* The key is always a string - utf16 encoding.
+*/
message->body.kvp_set.data.key_size =
utf16s_to_utf8s(
(wchar_t *)in_msg->body.kvp_set.data.key,
@@ -456,6 +463,17 @@ kvp_send_key(struct work_struct *dummy)
UTF16_LITTLE_ENDIAN,
message->body.kvp_set.data.key,
HV_KVP_EXCHANGE_MAX_KEY_SIZE - 1) + 1;
+
+ break;
+
+ case KVP_OP_GET:
+ message->body.kvp_get.data.key_size =
+ utf16s_to_utf8s(
+ (wchar_t *)in_msg->body.kvp_get.data.key,
+ in_msg->body.kvp_get.data.key_size,
+ UTF16_LITTLE_ENDIAN,
+ message->body.kvp_get.data.key,
+ HV_KVP_EXCHANGE_MAX_KEY_SIZE - 1) + 1;
break;
case KVP_OP_DELETE:
--
2.18.0
[PATCH V2 5/5] Tools: hv: kvp: Fix a warning of buffer overflow with gcc 8.0.1
From: Dexuan Cui
The patch fixes:
hv_kvp_daemon.c: In function 'kvp_set_ip_info':
hv_kvp_daemon.c:1305:2: note: 'snprintf' output between 41 and 4136 bytes
into a destination of size 4096
The "(unsigned int)str_len" is to avoid:
hv_kvp_daemon.c:1309:30: warning: comparison of integer expressions of
different signedness: 'int' and 'long unsigned int' [-Wsign-compare]
Signed-off-by: Dexuan Cui
Cc: K. Y. Srinivasan
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Signed-off-by: K. Y. Srinivasan
---
tools/hv/hv_kvp_daemon.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index bbb2a8ef367c..d7e06fe0270e 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1178,6 +1178,7 @@ static int kvp_set_ip_info(char *if_name, struct
hv_kvp_ipaddr_value *new_val)
FILE *file;
char cmd[PATH_MAX];
char *mac_addr;
+ int str_len;
/*
* Set the configuration for the specified interface with
@@ -1301,8 +1302,18 @@ static int kvp_set_ip_info(char *if_name, struct
hv_kvp_ipaddr_value *new_val)
* invoke the external script to do its magic.
*/
- snprintf(cmd, sizeof(cmd), KVP_SCRIPTS_PATH "%s %s",
-"hv_set_ifconfig", if_file);
+ str_len = snprintf(cmd, sizeof(cmd), KVP_SCRIPTS_PATH "%s %s",
+ "hv_set_ifconfig", if_file);
+ /*
+* This is a little overcautious, but it's necessary to suppress some
+* false warnings from gcc 8.0.1.
+*/
+ if (str_len <= 0 || (unsigned int)str_len >= sizeof(cmd)) {
+ syslog(LOG_ERR, "Cmd '%s' (len=%d) may be too long",
+ cmd, str_len);
+ return HV_E_FAIL;
+ }
+
if (system(cmd)) {
syslog(LOG_ERR, "Failed to execute cmd '%s'; error: %d %s",
cmd, errno, strerror(errno));
--
2.18.0
[PATCH v5 0/2] mtd: rawnand: meson: add Amlogic NAND driver support
These two patches try to add initial NAND driver support for Amlogic Meson SoCs, current it has been tested on GXL(p212) and AXG(s400) platform. Changes since v4 at [5]: - remove the initial default divider(CLK_DIV_MASK) in meson_nfc_clk_init() - dt-bindings: remove staus, add "rx" and "tx" clock, and node rename Changes since v3 at [4]: - remove partition table and some used props from dt-bindings Changes since v2 at [3]: - remove some hardcode time value, like twb - use dev wait R/B instead of nand_soft_waitrdy - implement nfc ecc init by ecc helper - rework nfc buffer init to register the maximun buffer when several chips - free nfc buffer when error and cleanup - add variable to teack all the already assigned CS lines - fix mtd->name use the first cs line only - remove dt "nand-enable-scrambler" and use NAND_NEED_SCRAMBLING instead. - move setuping ECC fileds after the identification phase - use nand_scan() and attach_chip() - check one event to return IRQ_NONE - delete cast when of_device_get_match_data - use nand_controller_init() helper - remove nfc driver complains when calling devm_ioremap_resource - clear irqs before setting up irq handler Changes since v1 at [1]: - adopt property amlogic,nand-enable-scrambler - thanks Martin - drop nand pins in DT - convert clk access to emmc clkc model - fix regiser field definition alignment - drop nand-user-mode - parse cs id from DT - rework n2m, m2n function - explain why insert two "IDLE" command - implement exec_op() - drop meson_nfc_get_nand_chip_dts() - release resource once error occur in meson_nfc_nand_chips_init(), - call nand_cleanup(nand) once mtd_device_register fail Items not addressed ( or confirmed ) in this version: - convert to ECC conf helper() - convert to dma coherent API - how to construct mtd->name [1] https://lkml.kernel.org/r/20180613161314.14894-1-yixun@amlogic.com [2] https://lkml.kernel.org/r/20180712211244.11428-1-yixun@amlogic.com [3] https://lkml.kernel.org/r/20180719094612.5833-1-yixun@amlogic.com [4] https://lkml.kernel.org/r/1536317831-58056-1-git-send-email-jianxin@amlogic.com/ [5] https://lore.kernel.org/r/1537433449-65213-2-git-send-email-jianxin@amlogic.com/ Liang Yang (2): dt-bindings: nand: meson: add Amlogic NAND controller driver mtd: rawnand: meson: add support for Amlogic NAND flash controller .../devicetree/bindings/mtd/amlogic,meson-nand.txt | 60 + drivers/mtd/nand/raw/Kconfig | 10 + drivers/mtd/nand/raw/Makefile |1 + drivers/mtd/nand/raw/meson_nand.c | 1370 4 files changed, 1441 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt create mode 100644 drivers/mtd/nand/raw/meson_nand.c -- 1.9.1
[PATCH v5 0/2] mtd: rawnand: meson: add Amlogic NAND driver support
These two patches try to add initial NAND driver support for Amlogic Meson SoCs, current it has been tested on GXL(p212) and AXG(s400) platform. Changes since v4 at [5]: - remove the initial default divider(CLK_DIV_MASK) in meson_nfc_clk_init() - dt-bindings: remove staus, add "rx" and "tx" clock, and node rename Changes since v3 at [4]: - remove partition table and some used props from dt-bindings Changes since v2 at [3]: - remove some hardcode time value, like twb - use dev wait R/B instead of nand_soft_waitrdy - implement nfc ecc init by ecc helper - rework nfc buffer init to register the maximun buffer when several chips - free nfc buffer when error and cleanup - add variable to teack all the already assigned CS lines - fix mtd->name use the first cs line only - remove dt "nand-enable-scrambler" and use NAND_NEED_SCRAMBLING instead. - move setuping ECC fileds after the identification phase - use nand_scan() and attach_chip() - check one event to return IRQ_NONE - delete cast when of_device_get_match_data - use nand_controller_init() helper - remove nfc driver complains when calling devm_ioremap_resource - clear irqs before setting up irq handler Changes since v1 at [1]: - adopt property amlogic,nand-enable-scrambler - thanks Martin - drop nand pins in DT - convert clk access to emmc clkc model - fix regiser field definition alignment - drop nand-user-mode - parse cs id from DT - rework n2m, m2n function - explain why insert two "IDLE" command - implement exec_op() - drop meson_nfc_get_nand_chip_dts() - release resource once error occur in meson_nfc_nand_chips_init(), - call nand_cleanup(nand) once mtd_device_register fail Items not addressed ( or confirmed ) in this version: - convert to ECC conf helper() - convert to dma coherent API - how to construct mtd->name [1] https://lkml.kernel.org/r/20180613161314.14894-1-yixun@amlogic.com [2] https://lkml.kernel.org/r/20180712211244.11428-1-yixun@amlogic.com [3] https://lkml.kernel.org/r/20180719094612.5833-1-yixun@amlogic.com [4] https://lkml.kernel.org/r/1536317831-58056-1-git-send-email-jianxin@amlogic.com/ [5] https://lore.kernel.org/r/1537433449-65213-2-git-send-email-jianxin@amlogic.com/ Liang Yang (2): dt-bindings: nand: meson: add Amlogic NAND controller driver mtd: rawnand: meson: add support for Amlogic NAND flash controller .../devicetree/bindings/mtd/amlogic,meson-nand.txt | 60 + drivers/mtd/nand/raw/Kconfig | 10 + drivers/mtd/nand/raw/Makefile |1 + drivers/mtd/nand/raw/meson_nand.c | 1370 4 files changed, 1441 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt create mode 100644 drivers/mtd/nand/raw/meson_nand.c -- 1.9.1
[PATCH v5 1/2] dt-bindings: nand: meson: add Amlogic NAND controller driver
From: Liang Yang
Add Amlogic NAND controller dt-bindings for Meson SoC,
Current this driver support GXBB/GXL/AXG platform.
Signed-off-by: Liang Yang
Signed-off-by: Yixun Lan
Signed-off-by: Jianxin Pan
---
.../devicetree/bindings/mtd/amlogic,meson-nand.txt | 60 ++
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
new file mode 100644
index 000..3983c11
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
@@ -0,0 +1,60 @@
+Amlogic NAND Flash Controller (NFC) for GXBB/GXL/AXG family SoCs
+
+This file documents the properties in addition to those available in
+the MTD NAND bindings.
+
+Required properties:
+- compatible : contains one of:
+ - "amlogic,meson-gxl-nfc"
+ - "amlogic,meson-axg-nfc"
+- clocks :
+ A list of phandle + clock-specifier pairs for the clocks listed
+ in clock-names.
+
+- clock-names: Should contain the following:
+ "core" - NFC module gate clock
+ "device" - device clock from eMMC sub clock controller
+ "rx" - rx clock phase
+ "tx" - tx clock phase
+
+- amlogic,mmc-syscon : Required for NAND clocks, it's shared with SD/eMMC
+ controller port C
+
+Optional children nodes:
+Children nodes represent the available nand chips.
+
+Other properties:
+see Documentation/devicetree/bindings/mtd/nand.txt for generic bindings.
+
+Example demonstrate on AXG SoC:
+
+ sd_emmc_c_clkc: mmc@7000 {
+ compatible = "amlogic,meson-axg-mmc-clkc", "syscon";
+ reg = <0x0 0x7000 0x0 0x800>;
+ };
+
+ nand-controller@7800 {
+ compatible = "amlogic,meson-axg-nfc";
+ reg = <0x0 0x7800 0x0 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+
+ clocks = < CLKID_SD_EMMC_C>,
+ <_emmc_c_clkc CLKID_MMC_DIV>,
+ <_emmc_c_clkc CLKID_MMC_PHASE_RX>,
+ <_emmc_c_clkc CLKID_MMC_PHASE_TX>;
+ clock-names = "core", "device", "rx", "tx";
+ amlogic,mmc-syscon = <_emmc_c_clkc>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ nand@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ nand-on-flash-bbt;
+ };
+ };
--
1.9.1
[PATCH v5 1/2] dt-bindings: nand: meson: add Amlogic NAND controller driver
From: Liang Yang
Add Amlogic NAND controller dt-bindings for Meson SoC,
Current this driver support GXBB/GXL/AXG platform.
Signed-off-by: Liang Yang
Signed-off-by: Yixun Lan
Signed-off-by: Jianxin Pan
---
.../devicetree/bindings/mtd/amlogic,meson-nand.txt | 60 ++
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
new file mode 100644
index 000..3983c11
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
@@ -0,0 +1,60 @@
+Amlogic NAND Flash Controller (NFC) for GXBB/GXL/AXG family SoCs
+
+This file documents the properties in addition to those available in
+the MTD NAND bindings.
+
+Required properties:
+- compatible : contains one of:
+ - "amlogic,meson-gxl-nfc"
+ - "amlogic,meson-axg-nfc"
+- clocks :
+ A list of phandle + clock-specifier pairs for the clocks listed
+ in clock-names.
+
+- clock-names: Should contain the following:
+ "core" - NFC module gate clock
+ "device" - device clock from eMMC sub clock controller
+ "rx" - rx clock phase
+ "tx" - tx clock phase
+
+- amlogic,mmc-syscon : Required for NAND clocks, it's shared with SD/eMMC
+ controller port C
+
+Optional children nodes:
+Children nodes represent the available nand chips.
+
+Other properties:
+see Documentation/devicetree/bindings/mtd/nand.txt for generic bindings.
+
+Example demonstrate on AXG SoC:
+
+ sd_emmc_c_clkc: mmc@7000 {
+ compatible = "amlogic,meson-axg-mmc-clkc", "syscon";
+ reg = <0x0 0x7000 0x0 0x800>;
+ };
+
+ nand-controller@7800 {
+ compatible = "amlogic,meson-axg-nfc";
+ reg = <0x0 0x7800 0x0 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+
+ clocks = < CLKID_SD_EMMC_C>,
+ <_emmc_c_clkc CLKID_MMC_DIV>,
+ <_emmc_c_clkc CLKID_MMC_PHASE_RX>,
+ <_emmc_c_clkc CLKID_MMC_PHASE_TX>;
+ clock-names = "core", "device", "rx", "tx";
+ amlogic,mmc-syscon = <_emmc_c_clkc>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ nand@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ nand-on-flash-bbt;
+ };
+ };
--
1.9.1
[PATCH v5 1/3] clk: meson: add emmc sub clock phase delay driver
From: Yixun Lan
Export the emmc sub clock phase delay ops which will be used
by the emmc sub clock driver itself.
Signed-off-by: Yixun Lan
Signed-off-by: Jianxin Pan
---
drivers/clk/meson/Makefile | 2 +-
drivers/clk/meson/clk-phase-delay.c | 79 +
drivers/clk/meson/clkc.h| 13 ++
3 files changed, 93 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/meson/clk-phase-delay.c
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 72ec8c4..39ce566 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -2,7 +2,7 @@
# Makefile for Meson specific clk
#
-obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-pll.o clk-mpll.o clk-phase.o
+obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-pll.o clk-mpll.o clk-phase.o
clk-phase-delay.o
obj-$(CONFIG_COMMON_CLK_AMLOGIC_AUDIO) += clk-triphase.o sclk-div.o
obj-$(CONFIG_COMMON_CLK_MESON_AO) += meson-aoclk.o
obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
diff --git a/drivers/clk/meson/clk-phase-delay.c
b/drivers/clk/meson/clk-phase-delay.c
new file mode 100644
index 000..b9573a7
--- /dev/null
+++ b/drivers/clk/meson/clk-phase-delay.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Amlogic Meson MMC Sub Clock Controller Driver
+ *
+ * Copyright (c) 2017 Baylibre SAS.
+ * Author: Jerome Brunet
+ *
+ * Copyright (c) 2018 Amlogic, inc.
+ * Author: Yixun Lan
+ */
+
+#include
+#include "clkc.h"
+
+static int meson_clk_phase_delay_get_phase(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_clk_phase_delay_data *ph =
+ meson_clk_get_phase_delay_data(clk);
+ unsigned long period_ps, p, d;
+ int degrees;
+ u32 val;
+
+ regmap_read(clk->map, ph->phase.reg_off, );
+ p = PARM_GET(ph->phase.width, ph->phase.shift, val);
+ degrees = p * 360 / (1 << (ph->phase.width));
+
+ period_ps = DIV_ROUND_UP((unsigned long)NSEC_PER_SEC * 1000,
+clk_hw_get_rate(hw));
+
+ d = PARM_GET(ph->delay.width, ph->delay.shift, val);
+ degrees += d * ph->delay_step_ps * 360 / period_ps;
+ degrees %= 360;
+
+ return degrees;
+}
+
+static void meson_clk_apply_phase_delay(struct clk_regmap *clk,
+ unsigned int phase,
+ unsigned int delay)
+{
+ struct meson_clk_phase_delay_data *ph = clk->data;
+ u32 val;
+
+ regmap_read(clk->map, ph->delay.reg_off, );
+ val = PARM_SET(ph->phase.width, ph->phase.shift, val, phase);
+ val = PARM_SET(ph->delay.width, ph->delay.shift, val, delay);
+ regmap_write(clk->map, ph->delay.reg_off, val);
+}
+
+static int meson_clk_phase_delay_set_phase(struct clk_hw *hw, int degrees)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_clk_phase_delay_data *ph =
+ meson_clk_get_phase_delay_data(clk);
+ unsigned long period_ps, d = 0, r;
+ u64 p;
+
+ p = degrees % 360;
+ period_ps = DIV_ROUND_UP((unsigned long)NSEC_PER_SEC * 1000,
+clk_hw_get_rate(hw));
+
+ /* First compute the phase index (p), the remainder (r) is the
+* part we'll try to acheive using the delays (d).
+*/
+ r = do_div(p, 360 / (1 << (ph->phase.width)));
+ d = DIV_ROUND_CLOSEST(r * period_ps,
+ 360 * ph->delay_step_ps);
+ d = min(d, PMASK(ph->delay.width));
+
+ meson_clk_apply_phase_delay(clk, p, d);
+ return 0;
+}
+
+const struct clk_ops meson_clk_phase_delay_ops = {
+ .get_phase = meson_clk_phase_delay_get_phase,
+ .set_phase = meson_clk_phase_delay_set_phase,
+};
+EXPORT_SYMBOL_GPL(meson_clk_phase_delay_ops);
diff --git a/drivers/clk/meson/clkc.h b/drivers/clk/meson/clkc.h
index 6b96d55..3309d78 100644
--- a/drivers/clk/meson/clkc.h
+++ b/drivers/clk/meson/clkc.h
@@ -105,6 +105,18 @@ struct clk_regmap _name = {
\
}, \
};
+struct meson_clk_phase_delay_data {
+ struct parm phase;
+ struct parm delay;
+ unsigned intdelay_step_ps;
+};
+
+static inline struct meson_clk_phase_delay_data *
+meson_clk_get_phase_delay_data(struct clk_regmap *clk)
+{
+ return (struct meson_clk_phase_delay_data *)clk->data;
+}
+
/* clk_ops */
extern const struct clk_ops meson_clk_pll_ro_ops;
extern const struct clk_ops meson_clk_pll_ops;
@@ -112,5 +124,6 @@ struct clk_regmap _name = {
\
extern const struct clk_ops meson_clk_mpll_ro_ops;
extern const struct clk_ops meson_clk_mpll_ops;
extern const struct clk_ops meson_clk_phase_ops;
+extern const struct clk_ops meson_clk_phase_delay_ops;
#endif /* __CLKC_H */
--
1.9.1
[PATCH v5 1/3] clk: meson: add emmc sub clock phase delay driver
From: Yixun Lan
Export the emmc sub clock phase delay ops which will be used
by the emmc sub clock driver itself.
Signed-off-by: Yixun Lan
Signed-off-by: Jianxin Pan
---
drivers/clk/meson/Makefile | 2 +-
drivers/clk/meson/clk-phase-delay.c | 79 +
drivers/clk/meson/clkc.h| 13 ++
3 files changed, 93 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/meson/clk-phase-delay.c
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 72ec8c4..39ce566 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -2,7 +2,7 @@
# Makefile for Meson specific clk
#
-obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-pll.o clk-mpll.o clk-phase.o
+obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-pll.o clk-mpll.o clk-phase.o
clk-phase-delay.o
obj-$(CONFIG_COMMON_CLK_AMLOGIC_AUDIO) += clk-triphase.o sclk-div.o
obj-$(CONFIG_COMMON_CLK_MESON_AO) += meson-aoclk.o
obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
diff --git a/drivers/clk/meson/clk-phase-delay.c
b/drivers/clk/meson/clk-phase-delay.c
new file mode 100644
index 000..b9573a7
--- /dev/null
+++ b/drivers/clk/meson/clk-phase-delay.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Amlogic Meson MMC Sub Clock Controller Driver
+ *
+ * Copyright (c) 2017 Baylibre SAS.
+ * Author: Jerome Brunet
+ *
+ * Copyright (c) 2018 Amlogic, inc.
+ * Author: Yixun Lan
+ */
+
+#include
+#include "clkc.h"
+
+static int meson_clk_phase_delay_get_phase(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_clk_phase_delay_data *ph =
+ meson_clk_get_phase_delay_data(clk);
+ unsigned long period_ps, p, d;
+ int degrees;
+ u32 val;
+
+ regmap_read(clk->map, ph->phase.reg_off, );
+ p = PARM_GET(ph->phase.width, ph->phase.shift, val);
+ degrees = p * 360 / (1 << (ph->phase.width));
+
+ period_ps = DIV_ROUND_UP((unsigned long)NSEC_PER_SEC * 1000,
+clk_hw_get_rate(hw));
+
+ d = PARM_GET(ph->delay.width, ph->delay.shift, val);
+ degrees += d * ph->delay_step_ps * 360 / period_ps;
+ degrees %= 360;
+
+ return degrees;
+}
+
+static void meson_clk_apply_phase_delay(struct clk_regmap *clk,
+ unsigned int phase,
+ unsigned int delay)
+{
+ struct meson_clk_phase_delay_data *ph = clk->data;
+ u32 val;
+
+ regmap_read(clk->map, ph->delay.reg_off, );
+ val = PARM_SET(ph->phase.width, ph->phase.shift, val, phase);
+ val = PARM_SET(ph->delay.width, ph->delay.shift, val, delay);
+ regmap_write(clk->map, ph->delay.reg_off, val);
+}
+
+static int meson_clk_phase_delay_set_phase(struct clk_hw *hw, int degrees)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_clk_phase_delay_data *ph =
+ meson_clk_get_phase_delay_data(clk);
+ unsigned long period_ps, d = 0, r;
+ u64 p;
+
+ p = degrees % 360;
+ period_ps = DIV_ROUND_UP((unsigned long)NSEC_PER_SEC * 1000,
+clk_hw_get_rate(hw));
+
+ /* First compute the phase index (p), the remainder (r) is the
+* part we'll try to acheive using the delays (d).
+*/
+ r = do_div(p, 360 / (1 << (ph->phase.width)));
+ d = DIV_ROUND_CLOSEST(r * period_ps,
+ 360 * ph->delay_step_ps);
+ d = min(d, PMASK(ph->delay.width));
+
+ meson_clk_apply_phase_delay(clk, p, d);
+ return 0;
+}
+
+const struct clk_ops meson_clk_phase_delay_ops = {
+ .get_phase = meson_clk_phase_delay_get_phase,
+ .set_phase = meson_clk_phase_delay_set_phase,
+};
+EXPORT_SYMBOL_GPL(meson_clk_phase_delay_ops);
diff --git a/drivers/clk/meson/clkc.h b/drivers/clk/meson/clkc.h
index 6b96d55..3309d78 100644
--- a/drivers/clk/meson/clkc.h
+++ b/drivers/clk/meson/clkc.h
@@ -105,6 +105,18 @@ struct clk_regmap _name = {
\
}, \
};
+struct meson_clk_phase_delay_data {
+ struct parm phase;
+ struct parm delay;
+ unsigned intdelay_step_ps;
+};
+
+static inline struct meson_clk_phase_delay_data *
+meson_clk_get_phase_delay_data(struct clk_regmap *clk)
+{
+ return (struct meson_clk_phase_delay_data *)clk->data;
+}
+
/* clk_ops */
extern const struct clk_ops meson_clk_pll_ro_ops;
extern const struct clk_ops meson_clk_pll_ops;
@@ -112,5 +124,6 @@ struct clk_regmap _name = {
\
extern const struct clk_ops meson_clk_mpll_ro_ops;
extern const struct clk_ops meson_clk_mpll_ops;
extern const struct clk_ops meson_clk_phase_ops;
+extern const struct clk_ops meson_clk_phase_delay_ops;
#endif /* __CLKC_H */
--
1.9.1
[PATCH v5 2/3] clk: meson: add DT documentation for emmc clock controller
From: Yixun Lan
Document the MMC sub clock controller driver, the potential consumer
of this driver is MMC or NAND. Also add four clock bindings IDs which
provided by this driver.
Reviewed-by: Rob Herring
Signed-off-by: Yixun Lan
Signed-off-by: Jianxin Pan
---
.../devicetree/bindings/clock/amlogic,mmc-clkc.txt | 31 ++
include/dt-bindings/clock/amlogic,mmc-clkc.h | 17
2 files changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
create mode 100644 include/dt-bindings/clock/amlogic,mmc-clkc.h
diff --git a/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
b/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
new file mode 100644
index 000..9e6d343
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
@@ -0,0 +1,31 @@
+* Amlogic MMC Sub Clock Controller Driver
+
+The Amlogic MMC clock controller generates and supplies clock to support
+MMC and NAND controller
+
+Required Properties:
+
+- compatible: should be:
+ "amlogic,gx-mmc-clkc"
+ "amlogic,axg-mmc-clkc"
+
+- #clock-cells: should be 1.
+- clocks: phandles to clocks corresponding to the clock-names property
+- clock-names: list of parent clock names
+ - "clkin0", "clkin1"
+
+Parent node should have the following properties :
+- compatible: "amlogic,axg-mmc-clkc", "syscon".
+- reg: base address and size of the MMC control register space.
+
+Example: Clock controller node:
+
+sd_mmc_c_clkc: clock-controller@7000 {
+ compatible = "amlogic,axg-mmc-clkc", "syscon";
+ reg = <0x0 0x7000 0x0 0x4>;
+ #clock-cells = <1>;
+
+ clock-names = "clkin0", "clkin1";
+ clocks = < CLKID_SD_MMC_C_CLK0>,
+< CLKID_FCLK_DIV2>;
+};
diff --git a/include/dt-bindings/clock/amlogic,mmc-clkc.h
b/include/dt-bindings/clock/amlogic,mmc-clkc.h
new file mode 100644
index 000..162b949
--- /dev/null
+++ b/include/dt-bindings/clock/amlogic,mmc-clkc.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
+/*
+ * Meson MMC sub clock tree IDs
+ *
+ * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
+ * Author: Yixun Lan
+ */
+
+#ifndef __MMC_CLKC_H
+#define __MMC_CLKC_H
+
+#define CLKID_MMC_DIV 1
+#define CLKID_MMC_PHASE_CORE 2
+#define CLKID_MMC_PHASE_TX 3
+#define CLKID_MMC_PHASE_RX 4
+
+#endif
--
1.9.1
[PATCH v5 3/3] clk: meson: add sub MMC clock controller driver
From: Yixun Lan
The patch will add a MMC clock controller driver which used by MMC or NAND,
It provide a mux and divider clock, and three phase clocks - core, tx, tx.
Two clocks are provided as the parent of MMC clock controller from
upper layer clock controller - eg "amlogic,axg-clkc" in AXG platform.
To specify which clock the MMC or NAND driver may consume,
the preprocessor macros in the dt-bindings/clock/amlogic,mmc-clkc.h header
can be used in the device tree sources.
Signed-off-by: Yixun Lan
Signed-off-by: Jianxin Pan
---
drivers/clk/meson/Kconfig | 10 ++
drivers/clk/meson/Makefile | 1 +
drivers/clk/meson/clk-regmap.c | 27 +++-
drivers/clk/meson/clk-regmap.h | 1 +
drivers/clk/meson/mmc-clkc.c | 296 +
5 files changed, 334 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/meson/mmc-clkc.c
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index efaa70f..8b8ccbc 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -15,6 +15,16 @@ config COMMON_CLK_MESON_AO
select COMMON_CLK_REGMAP_MESON
select RESET_CONTROLLER
+config COMMON_CLK_MMC_MESON
+ tristate "Meson MMC Sub Clock Controller Driver"
+ depends on COMMON_CLK_AMLOGIC
+ select MFD_SYSCON
+ select REGMAP
+ help
+ Support for the MMC sub clock controller on Amlogic Meson Platform,
+ which include S905 (GXBB, GXL), A113D/X (AXG) devices.
+ Say Y if you want this clock enabled.
+
config COMMON_CLK_REGMAP_MESON
bool
select REGMAP
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 39ce566..31c16d5 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -9,4 +9,5 @@ obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o gxbb-aoclk-32k.o
obj-$(CONFIG_COMMON_CLK_AXG)+= axg.o axg-aoclk.o
obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
+obj-$(CONFIG_COMMON_CLK_MMC_MESON) += mmc-clkc.o
obj-$(CONFIG_COMMON_CLK_REGMAP_MESON) += clk-regmap.o
diff --git a/drivers/clk/meson/clk-regmap.c b/drivers/clk/meson/clk-regmap.c
index 305ee30..f96314d 100644
--- a/drivers/clk/meson/clk-regmap.c
+++ b/drivers/clk/meson/clk-regmap.c
@@ -113,8 +113,25 @@ static int clk_regmap_div_set_rate(struct clk_hw *hw,
unsigned long rate,
clk_div_mask(div->width) << div->shift, val);
};
-/* Would prefer clk_regmap_div_ro_ops but clashes with qcom */
+static void clk_regmap_div_init(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct clk_regmap_div_data *div = clk_get_regmap_div_data(clk);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(clk->map, div->offset, );
+ if (ret)
+ return;
+ val &= (clk_div_mask(div->width) << div->shift);
+ if (!val)
+ regmap_update_bits(clk->map, div->offset,
+ clk_div_mask(div->width) << div->shift,
+ clk_div_mask(div->width));
+}
+
+/* Would prefer clk_regmap_div_ro_ops but clashes with qcom */
const struct clk_ops clk_regmap_divider_ops = {
.recalc_rate = clk_regmap_div_recalc_rate,
.round_rate = clk_regmap_div_round_rate,
@@ -122,6 +139,14 @@ static int clk_regmap_div_set_rate(struct clk_hw *hw,
unsigned long rate,
};
EXPORT_SYMBOL_GPL(clk_regmap_divider_ops);
+const struct clk_ops clk_regmap_divider_with_init_ops = {
+ .recalc_rate = clk_regmap_div_recalc_rate,
+ .round_rate = clk_regmap_div_round_rate,
+ .set_rate = clk_regmap_div_set_rate,
+ .init = clk_regmap_div_init,
+};
+EXPORT_SYMBOL_GPL(clk_regmap_divider_with_init_ops);
+
const struct clk_ops clk_regmap_divider_ro_ops = {
.recalc_rate = clk_regmap_div_recalc_rate,
.round_rate = clk_regmap_div_round_rate,
diff --git a/drivers/clk/meson/clk-regmap.h b/drivers/clk/meson/clk-regmap.h
index ed2d434..0ab7d37 100644
--- a/drivers/clk/meson/clk-regmap.h
+++ b/drivers/clk/meson/clk-regmap.h
@@ -109,5 +109,6 @@ struct clk_regmap_mux_data {
extern const struct clk_ops clk_regmap_mux_ops;
extern const struct clk_ops clk_regmap_mux_ro_ops;
+extern const struct clk_ops clk_regmap_divider_with_init_ops;
#endif /* __CLK_REGMAP_H */
diff --git a/drivers/clk/meson/mmc-clkc.c b/drivers/clk/meson/mmc-clkc.c
new file mode 100644
index 000..e3f
--- /dev/null
+++ b/drivers/clk/meson/mmc-clkc.c
@@ -0,0 +1,296 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Amlogic Meson MMC Sub Clock Controller Driver
+ *
+ * Copyright (c) 2017 Baylibre SAS.
+ * Author: Jerome Brunet
+ *
+ * Copyright (c) 2018 Amlogic, inc.
+ * Author: Yixun Lan
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clkc.h"
+
+/* clock ID used by internal driver */
+#define CLKID_MMC_MUX
[PATCH v5 2/3] clk: meson: add DT documentation for emmc clock controller
From: Yixun Lan
Document the MMC sub clock controller driver, the potential consumer
of this driver is MMC or NAND. Also add four clock bindings IDs which
provided by this driver.
Reviewed-by: Rob Herring
Signed-off-by: Yixun Lan
Signed-off-by: Jianxin Pan
---
.../devicetree/bindings/clock/amlogic,mmc-clkc.txt | 31 ++
include/dt-bindings/clock/amlogic,mmc-clkc.h | 17
2 files changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
create mode 100644 include/dt-bindings/clock/amlogic,mmc-clkc.h
diff --git a/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
b/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
new file mode 100644
index 000..9e6d343
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.txt
@@ -0,0 +1,31 @@
+* Amlogic MMC Sub Clock Controller Driver
+
+The Amlogic MMC clock controller generates and supplies clock to support
+MMC and NAND controller
+
+Required Properties:
+
+- compatible: should be:
+ "amlogic,gx-mmc-clkc"
+ "amlogic,axg-mmc-clkc"
+
+- #clock-cells: should be 1.
+- clocks: phandles to clocks corresponding to the clock-names property
+- clock-names: list of parent clock names
+ - "clkin0", "clkin1"
+
+Parent node should have the following properties :
+- compatible: "amlogic,axg-mmc-clkc", "syscon".
+- reg: base address and size of the MMC control register space.
+
+Example: Clock controller node:
+
+sd_mmc_c_clkc: clock-controller@7000 {
+ compatible = "amlogic,axg-mmc-clkc", "syscon";
+ reg = <0x0 0x7000 0x0 0x4>;
+ #clock-cells = <1>;
+
+ clock-names = "clkin0", "clkin1";
+ clocks = < CLKID_SD_MMC_C_CLK0>,
+< CLKID_FCLK_DIV2>;
+};
diff --git a/include/dt-bindings/clock/amlogic,mmc-clkc.h
b/include/dt-bindings/clock/amlogic,mmc-clkc.h
new file mode 100644
index 000..162b949
--- /dev/null
+++ b/include/dt-bindings/clock/amlogic,mmc-clkc.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
+/*
+ * Meson MMC sub clock tree IDs
+ *
+ * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
+ * Author: Yixun Lan
+ */
+
+#ifndef __MMC_CLKC_H
+#define __MMC_CLKC_H
+
+#define CLKID_MMC_DIV 1
+#define CLKID_MMC_PHASE_CORE 2
+#define CLKID_MMC_PHASE_TX 3
+#define CLKID_MMC_PHASE_RX 4
+
+#endif
--
1.9.1
[PATCH v5 3/3] clk: meson: add sub MMC clock controller driver
From: Yixun Lan
The patch will add a MMC clock controller driver which used by MMC or NAND,
It provide a mux and divider clock, and three phase clocks - core, tx, tx.
Two clocks are provided as the parent of MMC clock controller from
upper layer clock controller - eg "amlogic,axg-clkc" in AXG platform.
To specify which clock the MMC or NAND driver may consume,
the preprocessor macros in the dt-bindings/clock/amlogic,mmc-clkc.h header
can be used in the device tree sources.
Signed-off-by: Yixun Lan
Signed-off-by: Jianxin Pan
---
drivers/clk/meson/Kconfig | 10 ++
drivers/clk/meson/Makefile | 1 +
drivers/clk/meson/clk-regmap.c | 27 +++-
drivers/clk/meson/clk-regmap.h | 1 +
drivers/clk/meson/mmc-clkc.c | 296 +
5 files changed, 334 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/meson/mmc-clkc.c
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index efaa70f..8b8ccbc 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -15,6 +15,16 @@ config COMMON_CLK_MESON_AO
select COMMON_CLK_REGMAP_MESON
select RESET_CONTROLLER
+config COMMON_CLK_MMC_MESON
+ tristate "Meson MMC Sub Clock Controller Driver"
+ depends on COMMON_CLK_AMLOGIC
+ select MFD_SYSCON
+ select REGMAP
+ help
+ Support for the MMC sub clock controller on Amlogic Meson Platform,
+ which include S905 (GXBB, GXL), A113D/X (AXG) devices.
+ Say Y if you want this clock enabled.
+
config COMMON_CLK_REGMAP_MESON
bool
select REGMAP
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 39ce566..31c16d5 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -9,4 +9,5 @@ obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o gxbb-aoclk-32k.o
obj-$(CONFIG_COMMON_CLK_AXG)+= axg.o axg-aoclk.o
obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
+obj-$(CONFIG_COMMON_CLK_MMC_MESON) += mmc-clkc.o
obj-$(CONFIG_COMMON_CLK_REGMAP_MESON) += clk-regmap.o
diff --git a/drivers/clk/meson/clk-regmap.c b/drivers/clk/meson/clk-regmap.c
index 305ee30..f96314d 100644
--- a/drivers/clk/meson/clk-regmap.c
+++ b/drivers/clk/meson/clk-regmap.c
@@ -113,8 +113,25 @@ static int clk_regmap_div_set_rate(struct clk_hw *hw,
unsigned long rate,
clk_div_mask(div->width) << div->shift, val);
};
-/* Would prefer clk_regmap_div_ro_ops but clashes with qcom */
+static void clk_regmap_div_init(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct clk_regmap_div_data *div = clk_get_regmap_div_data(clk);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(clk->map, div->offset, );
+ if (ret)
+ return;
+ val &= (clk_div_mask(div->width) << div->shift);
+ if (!val)
+ regmap_update_bits(clk->map, div->offset,
+ clk_div_mask(div->width) << div->shift,
+ clk_div_mask(div->width));
+}
+
+/* Would prefer clk_regmap_div_ro_ops but clashes with qcom */
const struct clk_ops clk_regmap_divider_ops = {
.recalc_rate = clk_regmap_div_recalc_rate,
.round_rate = clk_regmap_div_round_rate,
@@ -122,6 +139,14 @@ static int clk_regmap_div_set_rate(struct clk_hw *hw,
unsigned long rate,
};
EXPORT_SYMBOL_GPL(clk_regmap_divider_ops);
+const struct clk_ops clk_regmap_divider_with_init_ops = {
+ .recalc_rate = clk_regmap_div_recalc_rate,
+ .round_rate = clk_regmap_div_round_rate,
+ .set_rate = clk_regmap_div_set_rate,
+ .init = clk_regmap_div_init,
+};
+EXPORT_SYMBOL_GPL(clk_regmap_divider_with_init_ops);
+
const struct clk_ops clk_regmap_divider_ro_ops = {
.recalc_rate = clk_regmap_div_recalc_rate,
.round_rate = clk_regmap_div_round_rate,
diff --git a/drivers/clk/meson/clk-regmap.h b/drivers/clk/meson/clk-regmap.h
index ed2d434..0ab7d37 100644
--- a/drivers/clk/meson/clk-regmap.h
+++ b/drivers/clk/meson/clk-regmap.h
@@ -109,5 +109,6 @@ struct clk_regmap_mux_data {
extern const struct clk_ops clk_regmap_mux_ops;
extern const struct clk_ops clk_regmap_mux_ro_ops;
+extern const struct clk_ops clk_regmap_divider_with_init_ops;
#endif /* __CLK_REGMAP_H */
diff --git a/drivers/clk/meson/mmc-clkc.c b/drivers/clk/meson/mmc-clkc.c
new file mode 100644
index 000..e3f
--- /dev/null
+++ b/drivers/clk/meson/mmc-clkc.c
@@ -0,0 +1,296 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Amlogic Meson MMC Sub Clock Controller Driver
+ *
+ * Copyright (c) 2017 Baylibre SAS.
+ * Author: Jerome Brunet
+ *
+ * Copyright (c) 2018 Amlogic, inc.
+ * Author: Yixun Lan
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clkc.h"
+
+/* clock ID used by internal driver */
+#define CLKID_MMC_MUX
linux-next: manual merge of the kselftest tree with the kvm tree
Hi Shuah,
Today's linux-next merge of the kselftest tree got a conflict in:
tools/testing/selftests/kvm/dirty_log_test.c
between commit:
fff8dcd7b4a2 ("kvm: selftests: port dirty_log_test to aarch64")
from the kvm tree and commit:
cda94d9ffa0e ("selftests: kvm: Fix -Wformat warnings")
from the kselftest tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc tools/testing/selftests/kvm/dirty_log_test.c
index d59820cc2d39,a9c4b5e21d7e..
--- a/tools/testing/selftests/kvm/dirty_log_test.c
+++ b/tools/testing/selftests/kvm/dirty_log_test.c
@@@ -17,52 -15,46 +17,52 @@@
#include "test_util.h"
#include "kvm_util.h"
+#include "processor.h"
+
+#define DEBUG printf
-#define DEBUG printf
+#define VCPU_ID 1
-#define VCPU_ID1
/* The memory slot index to track dirty pages */
-#define TEST_MEM_SLOT_INDEX1
-/*
- * GPA offset of the testing memory slot. Must be bigger than the
- * default vm mem slot, which is DEFAULT_GUEST_PHY_PAGES.
- */
-#define TEST_MEM_OFFSET(1ULL << 30) /* 1G */
-/* Size of the testing memory slot */
-#define TEST_MEM_PAGES (1ULL << 18) /* 1G for 4K pages */
+#define TEST_MEM_SLOT_INDEX 1
+
+/* Default guest test memory offset, 1G */
+#define DEFAULT_GUEST_TEST_MEM0x4000
+
/* How many pages to dirty for each guest loop */
-#define TEST_PAGES_PER_LOOP1024
+#define TEST_PAGES_PER_LOOP 1024
+
/* How many host loops to run (one KVM_GET_DIRTY_LOG for each loop) */
- #define TEST_HOST_LOOP_N 32
-#define TEST_HOST_LOOP_N 32UL
++#define TEST_HOST_LOOP_N 32UL
+
/* Interval for each host loop (ms) */
- #define TEST_HOST_LOOP_INTERVAL 10
-#define TEST_HOST_LOOP_INTERVAL10UL
++#define TEST_HOST_LOOP_INTERVAL 10UL
+
+/*
+ * Guest/Host shared variables. Ensure addr_gva2hva() and/or
+ * sync_global_to/from_guest() are used when accessing from
+ * the host. READ/WRITE_ONCE() should also be used with anything
+ * that may change.
+ */
+static uint64_t host_page_size;
+static uint64_t guest_page_size;
+static uint64_t guest_num_pages;
+static uint64_t random_array[TEST_PAGES_PER_LOOP];
+static uint64_t iteration;
/*
- * Guest variables. We use these variables to share data between host
- * and guest. There are two copies of the variables, one in host memory
- * (which is unused) and one in guest memory. When the host wants to
- * access these variables, it needs to call addr_gva2hva() to access the
- * guest copy.
+ * GPA offset of the testing memory slot. Must be bigger than
+ * DEFAULT_GUEST_PHY_PAGES.
*/
-uint64_t guest_random_array[TEST_PAGES_PER_LOOP];
-uint64_t guest_iteration;
-uint64_t guest_page_size;
+static uint64_t guest_test_mem = DEFAULT_GUEST_TEST_MEM;
/*
- * Writes to the first byte of a random page within the testing memory
- * region continuously.
+ * Continuously write to the first 8 bytes of a random pages within
+ * the testing memory region.
*/
-void guest_code(void)
+static void guest_code(void)
{
- int i = 0;
- uint64_t volatile *array = guest_random_array;
- uint64_t volatile *guest_addr;
+ int i;
while (true) {
for (i = 0; i < TEST_PAGES_PER_LOOP; i++) {
pgpdm0ztmkzpY.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the kselftest tree with the kvm tree
Hi Shuah,
Today's linux-next merge of the kselftest tree got a conflict in:
tools/testing/selftests/kvm/dirty_log_test.c
between commit:
fff8dcd7b4a2 ("kvm: selftests: port dirty_log_test to aarch64")
from the kvm tree and commit:
cda94d9ffa0e ("selftests: kvm: Fix -Wformat warnings")
from the kselftest tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc tools/testing/selftests/kvm/dirty_log_test.c
index d59820cc2d39,a9c4b5e21d7e..
--- a/tools/testing/selftests/kvm/dirty_log_test.c
+++ b/tools/testing/selftests/kvm/dirty_log_test.c
@@@ -17,52 -15,46 +17,52 @@@
#include "test_util.h"
#include "kvm_util.h"
+#include "processor.h"
+
+#define DEBUG printf
-#define DEBUG printf
+#define VCPU_ID 1
-#define VCPU_ID1
/* The memory slot index to track dirty pages */
-#define TEST_MEM_SLOT_INDEX1
-/*
- * GPA offset of the testing memory slot. Must be bigger than the
- * default vm mem slot, which is DEFAULT_GUEST_PHY_PAGES.
- */
-#define TEST_MEM_OFFSET(1ULL << 30) /* 1G */
-/* Size of the testing memory slot */
-#define TEST_MEM_PAGES (1ULL << 18) /* 1G for 4K pages */
+#define TEST_MEM_SLOT_INDEX 1
+
+/* Default guest test memory offset, 1G */
+#define DEFAULT_GUEST_TEST_MEM0x4000
+
/* How many pages to dirty for each guest loop */
-#define TEST_PAGES_PER_LOOP1024
+#define TEST_PAGES_PER_LOOP 1024
+
/* How many host loops to run (one KVM_GET_DIRTY_LOG for each loop) */
- #define TEST_HOST_LOOP_N 32
-#define TEST_HOST_LOOP_N 32UL
++#define TEST_HOST_LOOP_N 32UL
+
/* Interval for each host loop (ms) */
- #define TEST_HOST_LOOP_INTERVAL 10
-#define TEST_HOST_LOOP_INTERVAL10UL
++#define TEST_HOST_LOOP_INTERVAL 10UL
+
+/*
+ * Guest/Host shared variables. Ensure addr_gva2hva() and/or
+ * sync_global_to/from_guest() are used when accessing from
+ * the host. READ/WRITE_ONCE() should also be used with anything
+ * that may change.
+ */
+static uint64_t host_page_size;
+static uint64_t guest_page_size;
+static uint64_t guest_num_pages;
+static uint64_t random_array[TEST_PAGES_PER_LOOP];
+static uint64_t iteration;
/*
- * Guest variables. We use these variables to share data between host
- * and guest. There are two copies of the variables, one in host memory
- * (which is unused) and one in guest memory. When the host wants to
- * access these variables, it needs to call addr_gva2hva() to access the
- * guest copy.
+ * GPA offset of the testing memory slot. Must be bigger than
+ * DEFAULT_GUEST_PHY_PAGES.
*/
-uint64_t guest_random_array[TEST_PAGES_PER_LOOP];
-uint64_t guest_iteration;
-uint64_t guest_page_size;
+static uint64_t guest_test_mem = DEFAULT_GUEST_TEST_MEM;
/*
- * Writes to the first byte of a random page within the testing memory
- * region continuously.
+ * Continuously write to the first 8 bytes of a random pages within
+ * the testing memory region.
*/
-void guest_code(void)
+static void guest_code(void)
{
- int i = 0;
- uint64_t volatile *array = guest_random_array;
- uint64_t volatile *guest_addr;
+ int i;
while (true) {
for (i = 0; i < TEST_PAGES_PER_LOOP; i++) {
pgpdm0ztmkzpY.pgp
Description: OpenPGP digital signature
possible deadlock in ovl_copy_up_start
Hello,
syzbot found the following crash on:
HEAD commit:c343db455eb3 Merge branch 'parisc-4.19-3' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=167d08ee40
kernel config: https://syzkaller.appspot.com/x/.config?x=b3f55cb3dfcc6c33
dashboard link: https://syzkaller.appspot.com/bug?extid=3ef5c0d1a5cb0b21e6be
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3ef5c0d1a5cb0b21e...@syzkaller.appspotmail.com
overlayfs: filesystem on './file0' not supported as upperdir
XFS (loop3): unknown mount option [uid<].
kobject: 'loop2' (ce85f3f9): kobject_uevent_env
WARNING: possible recursive locking detected
kobject: 'loop2' (ce85f3f9): fill_kobj_path: path
= '/devices/virtual/block/loop2'
4.19.0-rc8+ #65 Not tainted
syz-executor2/8184 is trying to acquire lock:
d7157f3f (_i_lock_key[depth]){+.+.}, at:
ovl_copy_up_start+0x9c/0x2e0 fs/overlayfs/util.c:528
but task is already holding lock:
6f802695 (_i_lock_key[depth]){+.+.}, at:
ovl_nlink_start+0xe0/0x350 fs/overlayfs/util.c:771
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(_i_lock_key[depth]);
lock(_i_lock_key[depth]);
*** DEADLOCK ***
May be due to missing lock nesting notation
5 locks held by syz-executor2/8184:
#0: 75695ecf (sb_writers#17){.+.+}, at: sb_start_write
include/linux/fs.h:1566 [inline]
#0: 75695ecf (sb_writers#17){.+.+}, at: mnt_want_write+0x3f/0xc0
fs/namespace.c:360
#1: ee99eb71 (_i_mutex_dir_key[depth]/1){+.+.}, at:
inode_lock_nested include/linux/fs.h:773 [inline]
#1: ee99eb71 (_i_mutex_dir_key[depth]/1){+.+.}, at:
filename_create+0x1b2/0x5b0 fs/namei.c:3635
#2: 65f3eeeb (_i_mutex_key[depth]){+.+.}, at: inode_lock
include/linux/fs.h:738 [inline]
#2: 65f3eeeb (_i_mutex_key[depth]){+.+.}, at:
vfs_link+0x543/0xb70 fs/namei.c:4232
#3: 8b285486 (sb_writers#3){.+.+}, at: sb_start_write
include/linux/fs.h:1566 [inline]
#3: 8b285486 (sb_writers#3){.+.+}, at: mnt_want_write+0x3f/0xc0
fs/namespace.c:360
#4: 6f802695 (_i_lock_key[depth]){+.+.}, at:
ovl_nlink_start+0xe0/0x350 fs/overlayfs/util.c:771
stack backtrace:
CPU: 1 PID: 8184 Comm: syz-executor2 Not tainted 4.19.0-rc8+ #65
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
print_deadlock_bug kernel/locking/lockdep.c:1759 [inline]
check_deadlock kernel/locking/lockdep.c:1803 [inline]
validate_chain kernel/locking/lockdep.c:2399 [inline]
__lock_acquire.cold.61+0x1fb/0x482 kernel/locking/lockdep.c:3411
lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3900
__mutex_lock_common kernel/locking/mutex.c:925 [inline]
__mutex_lock+0x166/0x1700 kernel/locking/mutex.c:1072
mutex_lock_interruptible_nested+0x16/0x20 kernel/locking/mutex.c:1109
ovl_copy_up_start+0x9c/0x2e0 fs/overlayfs/util.c:528
ovl_copy_up_one+0x51f/0x1970 fs/overlayfs/copy_up.c:775
ovl_copy_up_flags+0x14e/0x1d0 fs/overlayfs/copy_up.c:827
ovl_copy_up+0x17/0x1a fs/overlayfs/copy_up.c:874
ovl_create_or_link+0xc7/0x1450 fs/overlayfs/dir.c:543
ovl_link+0x28b/0x37c fs/overlayfs/dir.c:679
vfs_link+0x7a9/0xb70 fs/namei.c:4241
do_linkat+0x724/0xa90 fs/namei.c:4309
__do_sys_linkat fs/namei.c:4333 [inline]
__se_sys_linkat fs/namei.c:4330 [inline]
__x64_sys_linkat+0xbe/0x150 fs/namei.c:4330
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457569
Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f8ab8a13c78 EFLAGS: 0246 ORIG_RAX: 0109
RAX: ffda RBX: 0005 RCX: 00457569
RDX: 000f RSI: 2200 RDI: 000f
RBP: 0072c040 R08: 0400 R09:
R10: 2180 R11: 0246 R12: 7f8ab8a146d4
R13: 004c31d1 R14: 004d3840 R15:
kobject: 'bluetooth' (bd8be530): kobject_add_internal:
parent: 'virtual', set: '(null)'
kobject: 'loop3' (7c159c39): kobject_uevent_env
kobject: 'kvm' (3101062f): kobject_uevent_env
kobject: 'loop3' (7c159c39): fill_kobj_path: path
= '/devices/virtual/block/loop3'
kobject: 'hci0' (6b48ee74): kobject_add_internal:
parent: 'bluetooth', set: 'devices'
kobject: 'kvm' (3101062f): fill_kobj_path: path
=
Zahlungsreferenz $4.500.000,00 USD
Sehr geehrter Herr / Frau Ihr Fonds $4.500.000,00 USD ist hier in unserer Verwahrung, wir warten auf Ihre untenstehenden Details zur Bearbeitung Ihrer Fondsansprüche. Leiten Sie Ihre Daten unten an den Leiter der Abteilung für Auslandsüberweisungen der NatWest Bank Plc weiter; für die notarielle Beglaubigung von Dokumenten. Ihr vollständiger Name Deine Adresse: Staatsangehörigkeit Alter der Geburt: Geschlecht: Besetzung: Mobiltelefon (Telefonnummer) E-Mail: natwestbank...@dr.com Ihre dringende Antwort wird benötigt. Unterschrift NatWest Bank Plc Dr. Ulrich Dorkowski
possible deadlock in ovl_copy_up_start
Hello,
syzbot found the following crash on:
HEAD commit:c343db455eb3 Merge branch 'parisc-4.19-3' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=167d08ee40
kernel config: https://syzkaller.appspot.com/x/.config?x=b3f55cb3dfcc6c33
dashboard link: https://syzkaller.appspot.com/bug?extid=3ef5c0d1a5cb0b21e6be
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3ef5c0d1a5cb0b21e...@syzkaller.appspotmail.com
overlayfs: filesystem on './file0' not supported as upperdir
XFS (loop3): unknown mount option [uid<].
kobject: 'loop2' (ce85f3f9): kobject_uevent_env
WARNING: possible recursive locking detected
kobject: 'loop2' (ce85f3f9): fill_kobj_path: path
= '/devices/virtual/block/loop2'
4.19.0-rc8+ #65 Not tainted
syz-executor2/8184 is trying to acquire lock:
d7157f3f (_i_lock_key[depth]){+.+.}, at:
ovl_copy_up_start+0x9c/0x2e0 fs/overlayfs/util.c:528
but task is already holding lock:
6f802695 (_i_lock_key[depth]){+.+.}, at:
ovl_nlink_start+0xe0/0x350 fs/overlayfs/util.c:771
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(_i_lock_key[depth]);
lock(_i_lock_key[depth]);
*** DEADLOCK ***
May be due to missing lock nesting notation
5 locks held by syz-executor2/8184:
#0: 75695ecf (sb_writers#17){.+.+}, at: sb_start_write
include/linux/fs.h:1566 [inline]
#0: 75695ecf (sb_writers#17){.+.+}, at: mnt_want_write+0x3f/0xc0
fs/namespace.c:360
#1: ee99eb71 (_i_mutex_dir_key[depth]/1){+.+.}, at:
inode_lock_nested include/linux/fs.h:773 [inline]
#1: ee99eb71 (_i_mutex_dir_key[depth]/1){+.+.}, at:
filename_create+0x1b2/0x5b0 fs/namei.c:3635
#2: 65f3eeeb (_i_mutex_key[depth]){+.+.}, at: inode_lock
include/linux/fs.h:738 [inline]
#2: 65f3eeeb (_i_mutex_key[depth]){+.+.}, at:
vfs_link+0x543/0xb70 fs/namei.c:4232
#3: 8b285486 (sb_writers#3){.+.+}, at: sb_start_write
include/linux/fs.h:1566 [inline]
#3: 8b285486 (sb_writers#3){.+.+}, at: mnt_want_write+0x3f/0xc0
fs/namespace.c:360
#4: 6f802695 (_i_lock_key[depth]){+.+.}, at:
ovl_nlink_start+0xe0/0x350 fs/overlayfs/util.c:771
stack backtrace:
CPU: 1 PID: 8184 Comm: syz-executor2 Not tainted 4.19.0-rc8+ #65
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
print_deadlock_bug kernel/locking/lockdep.c:1759 [inline]
check_deadlock kernel/locking/lockdep.c:1803 [inline]
validate_chain kernel/locking/lockdep.c:2399 [inline]
__lock_acquire.cold.61+0x1fb/0x482 kernel/locking/lockdep.c:3411
lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3900
__mutex_lock_common kernel/locking/mutex.c:925 [inline]
__mutex_lock+0x166/0x1700 kernel/locking/mutex.c:1072
mutex_lock_interruptible_nested+0x16/0x20 kernel/locking/mutex.c:1109
ovl_copy_up_start+0x9c/0x2e0 fs/overlayfs/util.c:528
ovl_copy_up_one+0x51f/0x1970 fs/overlayfs/copy_up.c:775
ovl_copy_up_flags+0x14e/0x1d0 fs/overlayfs/copy_up.c:827
ovl_copy_up+0x17/0x1a fs/overlayfs/copy_up.c:874
ovl_create_or_link+0xc7/0x1450 fs/overlayfs/dir.c:543
ovl_link+0x28b/0x37c fs/overlayfs/dir.c:679
vfs_link+0x7a9/0xb70 fs/namei.c:4241
do_linkat+0x724/0xa90 fs/namei.c:4309
__do_sys_linkat fs/namei.c:4333 [inline]
__se_sys_linkat fs/namei.c:4330 [inline]
__x64_sys_linkat+0xbe/0x150 fs/namei.c:4330
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457569
Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f8ab8a13c78 EFLAGS: 0246 ORIG_RAX: 0109
RAX: ffda RBX: 0005 RCX: 00457569
RDX: 000f RSI: 2200 RDI: 000f
RBP: 0072c040 R08: 0400 R09:
R10: 2180 R11: 0246 R12: 7f8ab8a146d4
R13: 004c31d1 R14: 004d3840 R15:
kobject: 'bluetooth' (bd8be530): kobject_add_internal:
parent: 'virtual', set: '(null)'
kobject: 'loop3' (7c159c39): kobject_uevent_env
kobject: 'kvm' (3101062f): kobject_uevent_env
kobject: 'loop3' (7c159c39): fill_kobj_path: path
= '/devices/virtual/block/loop3'
kobject: 'hci0' (6b48ee74): kobject_add_internal:
parent: 'bluetooth', set: 'devices'
kobject: 'kvm' (3101062f): fill_kobj_path: path
=
Zahlungsreferenz $4.500.000,00 USD
Sehr geehrter Herr / Frau Ihr Fonds $4.500.000,00 USD ist hier in unserer Verwahrung, wir warten auf Ihre untenstehenden Details zur Bearbeitung Ihrer Fondsansprüche. Leiten Sie Ihre Daten unten an den Leiter der Abteilung für Auslandsüberweisungen der NatWest Bank Plc weiter; für die notarielle Beglaubigung von Dokumenten. Ihr vollständiger Name Deine Adresse: Staatsangehörigkeit Alter der Geburt: Geschlecht: Besetzung: Mobiltelefon (Telefonnummer) E-Mail: natwestbank...@dr.com Ihre dringende Antwort wird benötigt. Unterschrift NatWest Bank Plc Dr. Ulrich Dorkowski
Re: [PATCH] pstore: Refactor compression initialization
On Wed, Oct 17, 2018 at 9:42 PM, Sai Prakash Ranjan
wrote:
> On 10/18/2018 7:00 AM, Joel Fernandes wrote:
> On Wed, Oct 17, 2018 at 02:41:24PM -0700, Kees Cook wrote:
>>>
>>> With compression initialization now separated from pstore_register(),
>>> there is no longer a good reason to do compression method selection
>>> during fs init. Instead, merge everything together into the late init.
>>> Additionally cleans up the reporting to be more clear.
>>>
>>> Signed-off-by: Kees Cook
>>> ---
>>> This patch goes on top of Joel's. I'll have both in linux-next shortly...
>>> ---
>>> fs/pstore/inode.c| 2 --
>>> fs/pstore/internal.h | 3 --
>>> fs/pstore/platform.c | 65
>>> 3 files changed, 41 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
>>> index 5fcb845b9fec..d814723fb27d 100644
>>> --- a/fs/pstore/inode.c
>>> +++ b/fs/pstore/inode.c
>>> @@ -486,8 +486,6 @@ static int __init init_pstore_fs(void)
>>> {
>>> int err;
>>> - pstore_choose_compression();
>>> -
>>> /* Create a convenient mount point for people to access pstore */
>>> err = sysfs_create_mount_point(fs_kobj, "pstore");
>>> if (err)
>>> diff --git a/fs/pstore/internal.h b/fs/pstore/internal.h
>>> index fb767e28aeb2..c029314478fa 100644
>>> --- a/fs/pstore/internal.h
>>> +++ b/fs/pstore/internal.h
>>> @@ -37,7 +37,4 @@ extern bool pstore_is_mounted(void);
>>> extern void pstore_record_init(struct pstore_record *record,
>>>struct pstore_info *psi);
>>> -/* Called during module_init() */
>>> -extern void __init pstore_choose_compression(void);
>>> -
>>> #endif
>>> diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
>>> index f09066db2d4d..e4737a5fa68c 100644
>>> --- a/fs/pstore/platform.c
>>> +++ b/fs/pstore/platform.c
>>> @@ -274,36 +274,56 @@ static int pstore_decompress(void *in, void *out,
>>> static void allocate_buf_for_compression(void)
>>> {
>>> + struct crypto_comp *ctx;
>>> + int size;
>>> + char *buf;
>>> +
>>> + /* Skip if not built-in or compression backend not selected yet.
>>> */
>>> if (!IS_ENABLED(CONFIG_PSTORE_COMPRESS) || !zbackend)
>>> return;
>>> + /* Skip if no pstore backend yet or compression init already
>>> done. */
>>> + if (!psinfo || tfm)
>>> + return;
>>> +
>>> if (!crypto_has_comp(zbackend->name, 0, 0)) {
>>> - pr_err("No %s compression\n", zbackend->name);
>>> + pr_err("Unknown compression: %s\n", zbackend->name);
>>> return;
>>> }
>>> - big_oops_buf_sz = zbackend->zbufsize(psinfo->bufsize);
>>> - if (big_oops_buf_sz <= 0)
>>> + size = zbackend->zbufsize(psinfo->bufsize);
>>> + if (size <= 0) {
>>> + pr_err("Invalid compression size for %s: %d\n",
>>> + zbackend->name, size);
>>> return;
>>> + }
>>> - big_oops_buf = kmalloc(big_oops_buf_sz, GFP_KERNEL);
>>> - if (!big_oops_buf) {
>>> - pr_err("allocate compression buffer error!\n");
>>> + buf = kmalloc(size, GFP_KERNEL);
>>> + if (!buf) {
>>> + pr_err("Failed %d byte compression buffer allocation for:
>>> %s\n",
>>> + size, zbackend->name);
>>> return;
>>> }
>>> - tfm = crypto_alloc_comp(zbackend->name, 0, 0);
>>> - if (IS_ERR_OR_NULL(tfm)) {
>>> - kfree(big_oops_buf);
>>> - big_oops_buf = NULL;
>>> - pr_err("crypto_alloc_comp() failed!\n");
>>> + ctx = crypto_alloc_comp(zbackend->name, 0, 0);
>>> + if (IS_ERR_OR_NULL(ctx)) {
>>> + kfree(buf);
>>> + pr_err("crypto_alloc_comp('%s') failed: %ld\n",
>>> zbackend->name,
>>> + PTR_ERR(ctx));
>>> return;
>>> }
>>> +
>>> + /* A non-NULL big_oops_buf indicates compression is available. */
>>> + tfm = ctx;
>>> + big_oops_buf_sz = size;
>>> + big_oops_buf = buf;
>>> +
>>> + pr_info("Using compression: %s\n", zbackend->name);
>>> }
>>> static void free_buf_for_compression(void)
>>> {
>>> - if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && !IS_ERR_OR_NULL(tfm))
>>> + if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && tfm)
>>> crypto_free_comp(tfm);
>>> kfree(big_oops_buf);
>>> big_oops_buf = NULL;
>>> @@ -764,31 +784,28 @@ static void pstore_timefunc(struct timer_list
>>> *unused)
>>> jiffies + msecs_to_jiffies(pstore_update_ms));
>>> }
>>> -void __init pstore_choose_compression(void)
>>> +static int __init pstore_compression_late_init(void)
>>> {
>>> const struct pstore_zbackend *step;
>>> if (!compress)
>>> - return;
>>> + return 0;
>>> + /* Locate
Re: [PATCH] pstore: Refactor compression initialization
On Wed, Oct 17, 2018 at 9:42 PM, Sai Prakash Ranjan
wrote:
> On 10/18/2018 7:00 AM, Joel Fernandes wrote:
> On Wed, Oct 17, 2018 at 02:41:24PM -0700, Kees Cook wrote:
>>>
>>> With compression initialization now separated from pstore_register(),
>>> there is no longer a good reason to do compression method selection
>>> during fs init. Instead, merge everything together into the late init.
>>> Additionally cleans up the reporting to be more clear.
>>>
>>> Signed-off-by: Kees Cook
>>> ---
>>> This patch goes on top of Joel's. I'll have both in linux-next shortly...
>>> ---
>>> fs/pstore/inode.c| 2 --
>>> fs/pstore/internal.h | 3 --
>>> fs/pstore/platform.c | 65
>>> 3 files changed, 41 insertions(+), 29 deletions(-)
>>>
>>> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
>>> index 5fcb845b9fec..d814723fb27d 100644
>>> --- a/fs/pstore/inode.c
>>> +++ b/fs/pstore/inode.c
>>> @@ -486,8 +486,6 @@ static int __init init_pstore_fs(void)
>>> {
>>> int err;
>>> - pstore_choose_compression();
>>> -
>>> /* Create a convenient mount point for people to access pstore */
>>> err = sysfs_create_mount_point(fs_kobj, "pstore");
>>> if (err)
>>> diff --git a/fs/pstore/internal.h b/fs/pstore/internal.h
>>> index fb767e28aeb2..c029314478fa 100644
>>> --- a/fs/pstore/internal.h
>>> +++ b/fs/pstore/internal.h
>>> @@ -37,7 +37,4 @@ extern bool pstore_is_mounted(void);
>>> extern void pstore_record_init(struct pstore_record *record,
>>>struct pstore_info *psi);
>>> -/* Called during module_init() */
>>> -extern void __init pstore_choose_compression(void);
>>> -
>>> #endif
>>> diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
>>> index f09066db2d4d..e4737a5fa68c 100644
>>> --- a/fs/pstore/platform.c
>>> +++ b/fs/pstore/platform.c
>>> @@ -274,36 +274,56 @@ static int pstore_decompress(void *in, void *out,
>>> static void allocate_buf_for_compression(void)
>>> {
>>> + struct crypto_comp *ctx;
>>> + int size;
>>> + char *buf;
>>> +
>>> + /* Skip if not built-in or compression backend not selected yet.
>>> */
>>> if (!IS_ENABLED(CONFIG_PSTORE_COMPRESS) || !zbackend)
>>> return;
>>> + /* Skip if no pstore backend yet or compression init already
>>> done. */
>>> + if (!psinfo || tfm)
>>> + return;
>>> +
>>> if (!crypto_has_comp(zbackend->name, 0, 0)) {
>>> - pr_err("No %s compression\n", zbackend->name);
>>> + pr_err("Unknown compression: %s\n", zbackend->name);
>>> return;
>>> }
>>> - big_oops_buf_sz = zbackend->zbufsize(psinfo->bufsize);
>>> - if (big_oops_buf_sz <= 0)
>>> + size = zbackend->zbufsize(psinfo->bufsize);
>>> + if (size <= 0) {
>>> + pr_err("Invalid compression size for %s: %d\n",
>>> + zbackend->name, size);
>>> return;
>>> + }
>>> - big_oops_buf = kmalloc(big_oops_buf_sz, GFP_KERNEL);
>>> - if (!big_oops_buf) {
>>> - pr_err("allocate compression buffer error!\n");
>>> + buf = kmalloc(size, GFP_KERNEL);
>>> + if (!buf) {
>>> + pr_err("Failed %d byte compression buffer allocation for:
>>> %s\n",
>>> + size, zbackend->name);
>>> return;
>>> }
>>> - tfm = crypto_alloc_comp(zbackend->name, 0, 0);
>>> - if (IS_ERR_OR_NULL(tfm)) {
>>> - kfree(big_oops_buf);
>>> - big_oops_buf = NULL;
>>> - pr_err("crypto_alloc_comp() failed!\n");
>>> + ctx = crypto_alloc_comp(zbackend->name, 0, 0);
>>> + if (IS_ERR_OR_NULL(ctx)) {
>>> + kfree(buf);
>>> + pr_err("crypto_alloc_comp('%s') failed: %ld\n",
>>> zbackend->name,
>>> + PTR_ERR(ctx));
>>> return;
>>> }
>>> +
>>> + /* A non-NULL big_oops_buf indicates compression is available. */
>>> + tfm = ctx;
>>> + big_oops_buf_sz = size;
>>> + big_oops_buf = buf;
>>> +
>>> + pr_info("Using compression: %s\n", zbackend->name);
>>> }
>>> static void free_buf_for_compression(void)
>>> {
>>> - if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && !IS_ERR_OR_NULL(tfm))
>>> + if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && tfm)
>>> crypto_free_comp(tfm);
>>> kfree(big_oops_buf);
>>> big_oops_buf = NULL;
>>> @@ -764,31 +784,28 @@ static void pstore_timefunc(struct timer_list
>>> *unused)
>>> jiffies + msecs_to_jiffies(pstore_update_ms));
>>> }
>>> -void __init pstore_choose_compression(void)
>>> +static int __init pstore_compression_late_init(void)
>>> {
>>> const struct pstore_zbackend *step;
>>> if (!compress)
>>> - return;
>>> + return 0;
>>> + /* Locate
Re: [PATCH] pstore: Refactor compression initialization
On Wed, Oct 17, 2018 at 6:30 PM, Joel Fernandes wrote:
> On Wed, Oct 17, 2018 at 02:41:24PM -0700, Kees Cook wrote:
>> With compression initialization now separated from pstore_register(),
>> there is no longer a good reason to do compression method selection
>> during fs init. Instead, merge everything together into the late init.
>> Additionally cleans up the reporting to be more clear.
>>
>> Signed-off-by: Kees Cook
>> ---
>> This patch goes on top of Joel's. I'll have both in linux-next shortly...
>> ---
>> fs/pstore/inode.c| 2 --
>> fs/pstore/internal.h | 3 --
>> fs/pstore/platform.c | 65
>> 3 files changed, 41 insertions(+), 29 deletions(-)
>>
>> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
>> index 5fcb845b9fec..d814723fb27d 100644
>> --- a/fs/pstore/inode.c
>> +++ b/fs/pstore/inode.c
>> @@ -486,8 +486,6 @@ static int __init init_pstore_fs(void)
>> {
>> int err;
>>
>> - pstore_choose_compression();
>> -
>> /* Create a convenient mount point for people to access pstore */
>> err = sysfs_create_mount_point(fs_kobj, "pstore");
>> if (err)
>> diff --git a/fs/pstore/internal.h b/fs/pstore/internal.h
>> index fb767e28aeb2..c029314478fa 100644
>> --- a/fs/pstore/internal.h
>> +++ b/fs/pstore/internal.h
>> @@ -37,7 +37,4 @@ extern bool pstore_is_mounted(void);
>> extern void pstore_record_init(struct pstore_record *record,
>> struct pstore_info *psi);
>>
>> -/* Called during module_init() */
>> -extern void __init pstore_choose_compression(void);
>> -
>> #endif
>> diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
>> index f09066db2d4d..e4737a5fa68c 100644
>> --- a/fs/pstore/platform.c
>> +++ b/fs/pstore/platform.c
>> @@ -274,36 +274,56 @@ static int pstore_decompress(void *in, void *out,
>>
>> static void allocate_buf_for_compression(void)
>> {
>> + struct crypto_comp *ctx;
>> + int size;
>> + char *buf;
>> +
>> + /* Skip if not built-in or compression backend not selected yet. */
>> if (!IS_ENABLED(CONFIG_PSTORE_COMPRESS) || !zbackend)
>> return;
>>
>> + /* Skip if no pstore backend yet or compression init already done. */
>> + if (!psinfo || tfm)
>> + return;
>> +
>> if (!crypto_has_comp(zbackend->name, 0, 0)) {
>> - pr_err("No %s compression\n", zbackend->name);
>> + pr_err("Unknown compression: %s\n", zbackend->name);
>> return;
>> }
>>
>> - big_oops_buf_sz = zbackend->zbufsize(psinfo->bufsize);
>> - if (big_oops_buf_sz <= 0)
>> + size = zbackend->zbufsize(psinfo->bufsize);
>> + if (size <= 0) {
>> + pr_err("Invalid compression size for %s: %d\n",
>> +zbackend->name, size);
>> return;
>> + }
>>
>> - big_oops_buf = kmalloc(big_oops_buf_sz, GFP_KERNEL);
>> - if (!big_oops_buf) {
>> - pr_err("allocate compression buffer error!\n");
>> + buf = kmalloc(size, GFP_KERNEL);
>> + if (!buf) {
>> + pr_err("Failed %d byte compression buffer allocation for:
>> %s\n",
>> +size, zbackend->name);
>> return;
>> }
>>
>> - tfm = crypto_alloc_comp(zbackend->name, 0, 0);
>> - if (IS_ERR_OR_NULL(tfm)) {
>> - kfree(big_oops_buf);
>> - big_oops_buf = NULL;
>> - pr_err("crypto_alloc_comp() failed!\n");
>> + ctx = crypto_alloc_comp(zbackend->name, 0, 0);
>> + if (IS_ERR_OR_NULL(ctx)) {
>> + kfree(buf);
>> + pr_err("crypto_alloc_comp('%s') failed: %ld\n", zbackend->name,
>> +PTR_ERR(ctx));
>> return;
>> }
>> +
>> + /* A non-NULL big_oops_buf indicates compression is available. */
>> + tfm = ctx;
>> + big_oops_buf_sz = size;
>> + big_oops_buf = buf;
>> +
>> + pr_info("Using compression: %s\n", zbackend->name);
>> }
>>
>> static void free_buf_for_compression(void)
>> {
>> - if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && !IS_ERR_OR_NULL(tfm))
>> + if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && tfm)
>> crypto_free_comp(tfm);
>> kfree(big_oops_buf);
>> big_oops_buf = NULL;
>> @@ -764,31 +784,28 @@ static void pstore_timefunc(struct timer_list *unused)
>> jiffies + msecs_to_jiffies(pstore_update_ms));
>> }
>>
>> -void __init pstore_choose_compression(void)
>> +static int __init pstore_compression_late_init(void)
>> {
>> const struct pstore_zbackend *step;
>>
>> if (!compress)
>> - return;
>> + return 0;
>>
>> + /* Locate desired compression method. */
>> for (step = zbackends; step->name; step++) {
>> if (!strcmp(compress, step->name)) {
>> zbackend = step;
>> - pr_info("using %s compression\n", zbackend->name);
>> - return;
>> +
Re: [PATCH] pstore: Refactor compression initialization
On Wed, Oct 17, 2018 at 6:30 PM, Joel Fernandes wrote:
> On Wed, Oct 17, 2018 at 02:41:24PM -0700, Kees Cook wrote:
>> With compression initialization now separated from pstore_register(),
>> there is no longer a good reason to do compression method selection
>> during fs init. Instead, merge everything together into the late init.
>> Additionally cleans up the reporting to be more clear.
>>
>> Signed-off-by: Kees Cook
>> ---
>> This patch goes on top of Joel's. I'll have both in linux-next shortly...
>> ---
>> fs/pstore/inode.c| 2 --
>> fs/pstore/internal.h | 3 --
>> fs/pstore/platform.c | 65
>> 3 files changed, 41 insertions(+), 29 deletions(-)
>>
>> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
>> index 5fcb845b9fec..d814723fb27d 100644
>> --- a/fs/pstore/inode.c
>> +++ b/fs/pstore/inode.c
>> @@ -486,8 +486,6 @@ static int __init init_pstore_fs(void)
>> {
>> int err;
>>
>> - pstore_choose_compression();
>> -
>> /* Create a convenient mount point for people to access pstore */
>> err = sysfs_create_mount_point(fs_kobj, "pstore");
>> if (err)
>> diff --git a/fs/pstore/internal.h b/fs/pstore/internal.h
>> index fb767e28aeb2..c029314478fa 100644
>> --- a/fs/pstore/internal.h
>> +++ b/fs/pstore/internal.h
>> @@ -37,7 +37,4 @@ extern bool pstore_is_mounted(void);
>> extern void pstore_record_init(struct pstore_record *record,
>> struct pstore_info *psi);
>>
>> -/* Called during module_init() */
>> -extern void __init pstore_choose_compression(void);
>> -
>> #endif
>> diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
>> index f09066db2d4d..e4737a5fa68c 100644
>> --- a/fs/pstore/platform.c
>> +++ b/fs/pstore/platform.c
>> @@ -274,36 +274,56 @@ static int pstore_decompress(void *in, void *out,
>>
>> static void allocate_buf_for_compression(void)
>> {
>> + struct crypto_comp *ctx;
>> + int size;
>> + char *buf;
>> +
>> + /* Skip if not built-in or compression backend not selected yet. */
>> if (!IS_ENABLED(CONFIG_PSTORE_COMPRESS) || !zbackend)
>> return;
>>
>> + /* Skip if no pstore backend yet or compression init already done. */
>> + if (!psinfo || tfm)
>> + return;
>> +
>> if (!crypto_has_comp(zbackend->name, 0, 0)) {
>> - pr_err("No %s compression\n", zbackend->name);
>> + pr_err("Unknown compression: %s\n", zbackend->name);
>> return;
>> }
>>
>> - big_oops_buf_sz = zbackend->zbufsize(psinfo->bufsize);
>> - if (big_oops_buf_sz <= 0)
>> + size = zbackend->zbufsize(psinfo->bufsize);
>> + if (size <= 0) {
>> + pr_err("Invalid compression size for %s: %d\n",
>> +zbackend->name, size);
>> return;
>> + }
>>
>> - big_oops_buf = kmalloc(big_oops_buf_sz, GFP_KERNEL);
>> - if (!big_oops_buf) {
>> - pr_err("allocate compression buffer error!\n");
>> + buf = kmalloc(size, GFP_KERNEL);
>> + if (!buf) {
>> + pr_err("Failed %d byte compression buffer allocation for:
>> %s\n",
>> +size, zbackend->name);
>> return;
>> }
>>
>> - tfm = crypto_alloc_comp(zbackend->name, 0, 0);
>> - if (IS_ERR_OR_NULL(tfm)) {
>> - kfree(big_oops_buf);
>> - big_oops_buf = NULL;
>> - pr_err("crypto_alloc_comp() failed!\n");
>> + ctx = crypto_alloc_comp(zbackend->name, 0, 0);
>> + if (IS_ERR_OR_NULL(ctx)) {
>> + kfree(buf);
>> + pr_err("crypto_alloc_comp('%s') failed: %ld\n", zbackend->name,
>> +PTR_ERR(ctx));
>> return;
>> }
>> +
>> + /* A non-NULL big_oops_buf indicates compression is available. */
>> + tfm = ctx;
>> + big_oops_buf_sz = size;
>> + big_oops_buf = buf;
>> +
>> + pr_info("Using compression: %s\n", zbackend->name);
>> }
>>
>> static void free_buf_for_compression(void)
>> {
>> - if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && !IS_ERR_OR_NULL(tfm))
>> + if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && tfm)
>> crypto_free_comp(tfm);
>> kfree(big_oops_buf);
>> big_oops_buf = NULL;
>> @@ -764,31 +784,28 @@ static void pstore_timefunc(struct timer_list *unused)
>> jiffies + msecs_to_jiffies(pstore_update_ms));
>> }
>>
>> -void __init pstore_choose_compression(void)
>> +static int __init pstore_compression_late_init(void)
>> {
>> const struct pstore_zbackend *step;
>>
>> if (!compress)
>> - return;
>> + return 0;
>>
>> + /* Locate desired compression method. */
>> for (step = zbackends; step->name; step++) {
>> if (!strcmp(compress, step->name)) {
>> zbackend = step;
>> - pr_info("using %s compression\n", zbackend->name);
>> - return;
>> +
Re: [PATCH] pstore: Refactor compression initialization
On 10/18/2018 7:00 AM, Joel Fernandes wrote:
On Wed, Oct 17, 2018 at 02:41:24PM -0700, Kees Cook wrote:
With compression initialization now separated from pstore_register(),
there is no longer a good reason to do compression method selection
during fs init. Instead, merge everything together into the late init.
Additionally cleans up the reporting to be more clear.
Signed-off-by: Kees Cook
---
This patch goes on top of Joel's. I'll have both in linux-next shortly...
---
fs/pstore/inode.c| 2 --
fs/pstore/internal.h | 3 --
fs/pstore/platform.c | 65
3 files changed, 41 insertions(+), 29 deletions(-)
diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index 5fcb845b9fec..d814723fb27d 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -486,8 +486,6 @@ static int __init init_pstore_fs(void)
{
int err;
- pstore_choose_compression();
-
/* Create a convenient mount point for people to access pstore */
err = sysfs_create_mount_point(fs_kobj, "pstore");
if (err)
diff --git a/fs/pstore/internal.h b/fs/pstore/internal.h
index fb767e28aeb2..c029314478fa 100644
--- a/fs/pstore/internal.h
+++ b/fs/pstore/internal.h
@@ -37,7 +37,4 @@ extern bool pstore_is_mounted(void);
extern void pstore_record_init(struct pstore_record *record,
struct pstore_info *psi);
-/* Called during module_init() */
-extern void __init pstore_choose_compression(void);
-
#endif
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index f09066db2d4d..e4737a5fa68c 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -274,36 +274,56 @@ static int pstore_decompress(void *in, void *out,
static void allocate_buf_for_compression(void)
{
+ struct crypto_comp *ctx;
+ int size;
+ char *buf;
+
+ /* Skip if not built-in or compression backend not selected yet. */
if (!IS_ENABLED(CONFIG_PSTORE_COMPRESS) || !zbackend)
return;
+ /* Skip if no pstore backend yet or compression init already done. */
+ if (!psinfo || tfm)
+ return;
+
if (!crypto_has_comp(zbackend->name, 0, 0)) {
- pr_err("No %s compression\n", zbackend->name);
+ pr_err("Unknown compression: %s\n", zbackend->name);
return;
}
- big_oops_buf_sz = zbackend->zbufsize(psinfo->bufsize);
- if (big_oops_buf_sz <= 0)
+ size = zbackend->zbufsize(psinfo->bufsize);
+ if (size <= 0) {
+ pr_err("Invalid compression size for %s: %d\n",
+ zbackend->name, size);
return;
+ }
- big_oops_buf = kmalloc(big_oops_buf_sz, GFP_KERNEL);
- if (!big_oops_buf) {
- pr_err("allocate compression buffer error!\n");
+ buf = kmalloc(size, GFP_KERNEL);
+ if (!buf) {
+ pr_err("Failed %d byte compression buffer allocation for: %s\n",
+ size, zbackend->name);
return;
}
- tfm = crypto_alloc_comp(zbackend->name, 0, 0);
- if (IS_ERR_OR_NULL(tfm)) {
- kfree(big_oops_buf);
- big_oops_buf = NULL;
- pr_err("crypto_alloc_comp() failed!\n");
+ ctx = crypto_alloc_comp(zbackend->name, 0, 0);
+ if (IS_ERR_OR_NULL(ctx)) {
+ kfree(buf);
+ pr_err("crypto_alloc_comp('%s') failed: %ld\n", zbackend->name,
+ PTR_ERR(ctx));
return;
}
+
+ /* A non-NULL big_oops_buf indicates compression is available. */
+ tfm = ctx;
+ big_oops_buf_sz = size;
+ big_oops_buf = buf;
+
+ pr_info("Using compression: %s\n", zbackend->name);
}
static void free_buf_for_compression(void)
{
- if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && !IS_ERR_OR_NULL(tfm))
+ if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && tfm)
crypto_free_comp(tfm);
kfree(big_oops_buf);
big_oops_buf = NULL;
@@ -764,31 +784,28 @@ static void pstore_timefunc(struct timer_list *unused)
jiffies + msecs_to_jiffies(pstore_update_ms));
}
-void __init pstore_choose_compression(void)
+static int __init pstore_compression_late_init(void)
{
const struct pstore_zbackend *step;
if (!compress)
- return;
+ return 0;
+ /* Locate desired compression method. */
for (step = zbackends; step->name; step++) {
if (!strcmp(compress, step->name)) {
zbackend = step;
- pr_info("using %s compression\n", zbackend->name);
- return;
+ break;
}
}
-}
-static int __init pstore_compression_late_init(void)
-{
/*
-* Check if any pstore backends registered earlier but did not allocate
-* for compression because crypto was not
Re: [PATCH] pstore: Refactor compression initialization
On 10/18/2018 7:00 AM, Joel Fernandes wrote:
On Wed, Oct 17, 2018 at 02:41:24PM -0700, Kees Cook wrote:
With compression initialization now separated from pstore_register(),
there is no longer a good reason to do compression method selection
during fs init. Instead, merge everything together into the late init.
Additionally cleans up the reporting to be more clear.
Signed-off-by: Kees Cook
---
This patch goes on top of Joel's. I'll have both in linux-next shortly...
---
fs/pstore/inode.c| 2 --
fs/pstore/internal.h | 3 --
fs/pstore/platform.c | 65
3 files changed, 41 insertions(+), 29 deletions(-)
diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index 5fcb845b9fec..d814723fb27d 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -486,8 +486,6 @@ static int __init init_pstore_fs(void)
{
int err;
- pstore_choose_compression();
-
/* Create a convenient mount point for people to access pstore */
err = sysfs_create_mount_point(fs_kobj, "pstore");
if (err)
diff --git a/fs/pstore/internal.h b/fs/pstore/internal.h
index fb767e28aeb2..c029314478fa 100644
--- a/fs/pstore/internal.h
+++ b/fs/pstore/internal.h
@@ -37,7 +37,4 @@ extern bool pstore_is_mounted(void);
extern void pstore_record_init(struct pstore_record *record,
struct pstore_info *psi);
-/* Called during module_init() */
-extern void __init pstore_choose_compression(void);
-
#endif
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index f09066db2d4d..e4737a5fa68c 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -274,36 +274,56 @@ static int pstore_decompress(void *in, void *out,
static void allocate_buf_for_compression(void)
{
+ struct crypto_comp *ctx;
+ int size;
+ char *buf;
+
+ /* Skip if not built-in or compression backend not selected yet. */
if (!IS_ENABLED(CONFIG_PSTORE_COMPRESS) || !zbackend)
return;
+ /* Skip if no pstore backend yet or compression init already done. */
+ if (!psinfo || tfm)
+ return;
+
if (!crypto_has_comp(zbackend->name, 0, 0)) {
- pr_err("No %s compression\n", zbackend->name);
+ pr_err("Unknown compression: %s\n", zbackend->name);
return;
}
- big_oops_buf_sz = zbackend->zbufsize(psinfo->bufsize);
- if (big_oops_buf_sz <= 0)
+ size = zbackend->zbufsize(psinfo->bufsize);
+ if (size <= 0) {
+ pr_err("Invalid compression size for %s: %d\n",
+ zbackend->name, size);
return;
+ }
- big_oops_buf = kmalloc(big_oops_buf_sz, GFP_KERNEL);
- if (!big_oops_buf) {
- pr_err("allocate compression buffer error!\n");
+ buf = kmalloc(size, GFP_KERNEL);
+ if (!buf) {
+ pr_err("Failed %d byte compression buffer allocation for: %s\n",
+ size, zbackend->name);
return;
}
- tfm = crypto_alloc_comp(zbackend->name, 0, 0);
- if (IS_ERR_OR_NULL(tfm)) {
- kfree(big_oops_buf);
- big_oops_buf = NULL;
- pr_err("crypto_alloc_comp() failed!\n");
+ ctx = crypto_alloc_comp(zbackend->name, 0, 0);
+ if (IS_ERR_OR_NULL(ctx)) {
+ kfree(buf);
+ pr_err("crypto_alloc_comp('%s') failed: %ld\n", zbackend->name,
+ PTR_ERR(ctx));
return;
}
+
+ /* A non-NULL big_oops_buf indicates compression is available. */
+ tfm = ctx;
+ big_oops_buf_sz = size;
+ big_oops_buf = buf;
+
+ pr_info("Using compression: %s\n", zbackend->name);
}
static void free_buf_for_compression(void)
{
- if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && !IS_ERR_OR_NULL(tfm))
+ if (IS_ENABLED(CONFIG_PSTORE_COMPRESS) && tfm)
crypto_free_comp(tfm);
kfree(big_oops_buf);
big_oops_buf = NULL;
@@ -764,31 +784,28 @@ static void pstore_timefunc(struct timer_list *unused)
jiffies + msecs_to_jiffies(pstore_update_ms));
}
-void __init pstore_choose_compression(void)
+static int __init pstore_compression_late_init(void)
{
const struct pstore_zbackend *step;
if (!compress)
- return;
+ return 0;
+ /* Locate desired compression method. */
for (step = zbackends; step->name; step++) {
if (!strcmp(compress, step->name)) {
zbackend = step;
- pr_info("using %s compression\n", zbackend->name);
- return;
+ break;
}
}
-}
-static int __init pstore_compression_late_init(void)
-{
/*
-* Check if any pstore backends registered earlier but did not allocate
-* for compression because crypto was not
Re: in_compat_syscall() returns from kernel thread for X86_32.
On Wed, Oct 17 2018, Andy Lutomirski wrote:
> On Wed, Oct 17, 2018 at 6:48 PM NeilBrown wrote:
>>
>>
>> Was: Re: [tip:x86/asm] x86/entry: Rename is_{ia32,x32}_task() to
>> in_{ia32,x32}_syscall()
>> On Tue, Apr 19 2016, tip-bot for Dmitry Safonov wrote:
>>
>> > Commit-ID: abfb9498ee1327f534df92a7ecaea81a85913bae
>> > Gitweb:
>> > http://git.kernel.org/tip/abfb9498ee1327f534df92a7ecaea81a85913bae
>> > Author: Dmitry Safonov
>> > AuthorDate: Mon, 18 Apr 2016 16:43:43 +0300
>> > Committer: Ingo Molnar
>> > CommitDate: Tue, 19 Apr 2016 10:44:52 +0200
>> >
>> > x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall()
>> >
>> ...
>> > @@ -318,7 +318,7 @@ static inline bool is_x32_task(void)
>> >
>> > static inline bool in_compat_syscall(void)
>> > {
>> > - return is_ia32_task() || is_x32_task();
>> > + return in_ia32_syscall() || in_x32_syscall();
>> > }
>>
>> Hi,
>> I'm reply to this patch largely to make sure I get the right people
>> .
>>
>> This test is always true when CONFIG_X86_32 is set, as that forces
>> in_ia32_syscall() to true.
>> However we might not be in a syscall at all - we might be running a
>> kernel thread which is always in 64 mode.
>> Every other implementation of in_compat_syscall() that I found is
>> dependant on a thread flag or syscall register flag, and so returns
>> "false" in a kernel thread.
>>
>> Might something like this be appropriate?
>>
>> diff --git a/arch/x86/include/asm/thread_info.h
>> b/arch/x86/include/asm/thread_info.h
>> index 2ff2a30a264f..c265b40a78f2 100644
>> --- a/arch/x86/include/asm/thread_info.h
>> +++ b/arch/x86/include/asm/thread_info.h
>> @@ -219,7 +219,7 @@ static inline int arch_within_stack_frames(const void *
>> const stack,
>> #ifndef __ASSEMBLY__
>>
>> #ifdef CONFIG_X86_32
>> -#define in_ia32_syscall() true
>> +#define in_ia32_syscall() (!(current->flags & PF_KTHREAD))
>> #else
>> #define in_ia32_syscall() (IS_ENABLED(CONFIG_IA32_EMULATION) && \
>>current_thread_info()->status & TS_COMPAT)
>>
>> This came up in the (no out-of-tree) lustre filesystem where some code
>> needs to assume 32-bit mode in X86_32 syscalls, and 64-bit mode in kernel
>> threads.
>>
>
> I could get on board with:
>
> ({WARN_ON_ONCE(current->flags & PF_KTHREAD); true})
>
> The point of these accessors is to be used *in a syscall*.
>
> What on Earth is Lustre doing that makes it have this problem?
Lustre uses it in the ->getattr method to make sure ->ino, ->dev and
->rdev are appropriately sized. This isn't very different from the
usage in ext4 to ensure the seek offset for directories is suitable.
These interfaces can be used both from systemcalls and from kernel
threads, such as via nfsd.
I don't *know* if nfsd is the particular kthread that causes problems
for lustre. All I know is that ->getattr returns 32bit squashed inode
numbers in kthread context where 64 bit numbers would be expected.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
Re: in_compat_syscall() returns from kernel thread for X86_32.
On Wed, Oct 17 2018, Andy Lutomirski wrote:
> On Wed, Oct 17, 2018 at 6:48 PM NeilBrown wrote:
>>
>>
>> Was: Re: [tip:x86/asm] x86/entry: Rename is_{ia32,x32}_task() to
>> in_{ia32,x32}_syscall()
>> On Tue, Apr 19 2016, tip-bot for Dmitry Safonov wrote:
>>
>> > Commit-ID: abfb9498ee1327f534df92a7ecaea81a85913bae
>> > Gitweb:
>> > http://git.kernel.org/tip/abfb9498ee1327f534df92a7ecaea81a85913bae
>> > Author: Dmitry Safonov
>> > AuthorDate: Mon, 18 Apr 2016 16:43:43 +0300
>> > Committer: Ingo Molnar
>> > CommitDate: Tue, 19 Apr 2016 10:44:52 +0200
>> >
>> > x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall()
>> >
>> ...
>> > @@ -318,7 +318,7 @@ static inline bool is_x32_task(void)
>> >
>> > static inline bool in_compat_syscall(void)
>> > {
>> > - return is_ia32_task() || is_x32_task();
>> > + return in_ia32_syscall() || in_x32_syscall();
>> > }
>>
>> Hi,
>> I'm reply to this patch largely to make sure I get the right people
>> .
>>
>> This test is always true when CONFIG_X86_32 is set, as that forces
>> in_ia32_syscall() to true.
>> However we might not be in a syscall at all - we might be running a
>> kernel thread which is always in 64 mode.
>> Every other implementation of in_compat_syscall() that I found is
>> dependant on a thread flag or syscall register flag, and so returns
>> "false" in a kernel thread.
>>
>> Might something like this be appropriate?
>>
>> diff --git a/arch/x86/include/asm/thread_info.h
>> b/arch/x86/include/asm/thread_info.h
>> index 2ff2a30a264f..c265b40a78f2 100644
>> --- a/arch/x86/include/asm/thread_info.h
>> +++ b/arch/x86/include/asm/thread_info.h
>> @@ -219,7 +219,7 @@ static inline int arch_within_stack_frames(const void *
>> const stack,
>> #ifndef __ASSEMBLY__
>>
>> #ifdef CONFIG_X86_32
>> -#define in_ia32_syscall() true
>> +#define in_ia32_syscall() (!(current->flags & PF_KTHREAD))
>> #else
>> #define in_ia32_syscall() (IS_ENABLED(CONFIG_IA32_EMULATION) && \
>>current_thread_info()->status & TS_COMPAT)
>>
>> This came up in the (no out-of-tree) lustre filesystem where some code
>> needs to assume 32-bit mode in X86_32 syscalls, and 64-bit mode in kernel
>> threads.
>>
>
> I could get on board with:
>
> ({WARN_ON_ONCE(current->flags & PF_KTHREAD); true})
>
> The point of these accessors is to be used *in a syscall*.
>
> What on Earth is Lustre doing that makes it have this problem?
Lustre uses it in the ->getattr method to make sure ->ino, ->dev and
->rdev are appropriately sized. This isn't very different from the
usage in ext4 to ensure the seek offset for directories is suitable.
These interfaces can be used both from systemcalls and from kernel
threads, such as via nfsd.
I don't *know* if nfsd is the particular kthread that causes problems
for lustre. All I know is that ->getattr returns 32bit squashed inode
numbers in kthread context where 64 bit numbers would be expected.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
Re: Question about mmap syscall and POSIX standard on mips arch
[mips folks Cc'd] On Thu, Oct 18, 2018 at 11:26:02AM +0800, Hongzhi, Song wrote: > Hi all, > > Ltp has a POSIX teatcase about mmap, 24-2.c. > > https://github.com/linux-test-project/ltp/blob/e816127e5d8efbff5ae53e9c2292fae22f36838b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-2.c#L94 [basically, MAP_FIXED mmap with addr + len > TASK_SIZE fails with -EINVAL on mips and -ENOMEM elsewhere] > Under POSIX standard, the expected errno should be ENOMEM > > when the specific [addr+len] exceeds the bound of memory. The mmap() function may fail if: [EINVAL] The addr argument (if MAP_FIXED was specified) or off is not a multiple of the page size as returned by sysconf(), or is considered invalid by ^^^ the implementation. ^^^ So that behaviour gets past POSIX. That part is mostly about the things like cache aliasing constraints, etc., but it leaves enough space to weasel out. Said that, this [ENOMEM] MAP_FIXED was specified, and the range [addr,addr+len) exceeds that allowed for the address space of a process; or, if MAP_FIXED was not specified and there is insufficient room in the address space to effect the mapping. is a lot more specific, so switching to -ENOMEM there might be a good idea, especially since on other architectures we do get -ENOMEM in that case, AFAICS.
Re: Question about mmap syscall and POSIX standard on mips arch
[mips folks Cc'd] On Thu, Oct 18, 2018 at 11:26:02AM +0800, Hongzhi, Song wrote: > Hi all, > > Ltp has a POSIX teatcase about mmap, 24-2.c. > > https://github.com/linux-test-project/ltp/blob/e816127e5d8efbff5ae53e9c2292fae22f36838b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-2.c#L94 [basically, MAP_FIXED mmap with addr + len > TASK_SIZE fails with -EINVAL on mips and -ENOMEM elsewhere] > Under POSIX standard, the expected errno should be ENOMEM > > when the specific [addr+len] exceeds the bound of memory. The mmap() function may fail if: [EINVAL] The addr argument (if MAP_FIXED was specified) or off is not a multiple of the page size as returned by sysconf(), or is considered invalid by ^^^ the implementation. ^^^ So that behaviour gets past POSIX. That part is mostly about the things like cache aliasing constraints, etc., but it leaves enough space to weasel out. Said that, this [ENOMEM] MAP_FIXED was specified, and the range [addr,addr+len) exceeds that allowed for the address space of a process; or, if MAP_FIXED was not specified and there is insufficient room in the address space to effect the mapping. is a lot more specific, so switching to -ENOMEM there might be a good idea, especially since on other architectures we do get -ENOMEM in that case, AFAICS.
Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.
On (10/18/18 11:46), Tetsuo Handa wrote:
> Sergey Senozhatsky wrote:
> >
> > int printk_ratelimit_interval(void)
> > {
> >int ret = DEFAULT_RATELIMIT_INTERVAL;
> >struct tty_driver *driver = NULL;
> >speed_t min_baud = MAX_INT;
> >
> >console_lock();
> >for_each_console(c) {
> >speed_t br;
> >
> >if (!c->device)
> >continue;
> >if (!(c->flags & CON_ENABLED))
> >continue;
> >if (!c->write)
> >continue;
> >driver = c->device(c, index);
> >if (!driver)
> >continue;
> >
> >br = tty_get_baud_rate(tty_driver to tty_struct [???]);
> >min_baud = min(min_baud, br);
> >}
> >console_unlock();
> >
> >switch (min_baud) {
> >case 115200:
> >return ret;
> >
> >case ...blah blah...:
> >return ret * 2;
> >
> >case 9600:
> >return ret * 4;
> >}
> >return ret;
> > }
>
> I don't think that baud rate is relevant. Writing to console messes up
> operations by console users. What matters is that we don't mess up consoles
> to the level (or frequency) where console users cannot do their operations.
> That is, interval between the last moment we wrote to a console and the
> first moment we will write to a console for the next time matters. Roughly
> speaking, remember the time stamp when we called call_console_drivers() for
> the last time, and compare with that stamp before trying to call a sort of
> ratelimited printk(). My patch is doing it using per call-site stamp
> recording.
To my personal taste, "baud rate of registered and enabled consoles"
approach is drastically more relevant than hard coded 10 * HZ or
60 * HZ magic numbers... But not in the form of that "min baud rate"
brain fart, which I have posted.
What I'd do:
-- Iterate over all registered and enabled serial consoles
-- Sum up all the baud rates
-- Calculate (*roughly*) how many bytes per second/minute/etc my
call_console_driver() can push
-- we actually don't even have to iterate all consoles. Just
add a baud rate in register_console() and sub baud rate
in unregister_console() of each console individually
-- and have a static unsigned long in printk.c, which OOM
can use in rate-limit interval check
-- Leave all the noise behind: e.g. console_sem can be locked by
a preempted fbcon, etc. It's out of my control; bad luck, there
is nothing I can do about it.
-- Then I would, probably, take the most recent, say, 100 OOM
reports, and calculate the *average* strlen() value
(including \r and \n at the end of each line)
(strlen(oom_report1) + ... + strlen(omm_report100)) / 100
Then I'd try to reach an agreement with MM people that we will
use this "average" oom_report_strlen() in ratelimit interval
calculation. Yes, some reports will be longer, some shorter.
Say, suppose...
I have 2 consoles, and I can write 250 bytes per second.
And average oom_report is 5000 bytes.
Then I can print one oom_report every (5000 / 250) seconds
in the *best* case. That's the optimistic baseline. There
can be printk()-s from other CPUs, etc. etc. No one can
predict those things.
Note, how things change when I have just 1 console enabled.
I have 1 console, and I can write 500 bytes per second.
And average oom_report is 5000 bytes.
Then I can print one oom_report every (5000 / 500) seconds
in the *best* case.
Just my $0.02. Who knows, may be it's dumb and ugly.
I don't have a dog in this fight.
-ss
Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.
On (10/18/18 11:46), Tetsuo Handa wrote:
> Sergey Senozhatsky wrote:
> >
> > int printk_ratelimit_interval(void)
> > {
> >int ret = DEFAULT_RATELIMIT_INTERVAL;
> >struct tty_driver *driver = NULL;
> >speed_t min_baud = MAX_INT;
> >
> >console_lock();
> >for_each_console(c) {
> >speed_t br;
> >
> >if (!c->device)
> >continue;
> >if (!(c->flags & CON_ENABLED))
> >continue;
> >if (!c->write)
> >continue;
> >driver = c->device(c, index);
> >if (!driver)
> >continue;
> >
> >br = tty_get_baud_rate(tty_driver to tty_struct [???]);
> >min_baud = min(min_baud, br);
> >}
> >console_unlock();
> >
> >switch (min_baud) {
> >case 115200:
> >return ret;
> >
> >case ...blah blah...:
> >return ret * 2;
> >
> >case 9600:
> >return ret * 4;
> >}
> >return ret;
> > }
>
> I don't think that baud rate is relevant. Writing to console messes up
> operations by console users. What matters is that we don't mess up consoles
> to the level (or frequency) where console users cannot do their operations.
> That is, interval between the last moment we wrote to a console and the
> first moment we will write to a console for the next time matters. Roughly
> speaking, remember the time stamp when we called call_console_drivers() for
> the last time, and compare with that stamp before trying to call a sort of
> ratelimited printk(). My patch is doing it using per call-site stamp
> recording.
To my personal taste, "baud rate of registered and enabled consoles"
approach is drastically more relevant than hard coded 10 * HZ or
60 * HZ magic numbers... But not in the form of that "min baud rate"
brain fart, which I have posted.
What I'd do:
-- Iterate over all registered and enabled serial consoles
-- Sum up all the baud rates
-- Calculate (*roughly*) how many bytes per second/minute/etc my
call_console_driver() can push
-- we actually don't even have to iterate all consoles. Just
add a baud rate in register_console() and sub baud rate
in unregister_console() of each console individually
-- and have a static unsigned long in printk.c, which OOM
can use in rate-limit interval check
-- Leave all the noise behind: e.g. console_sem can be locked by
a preempted fbcon, etc. It's out of my control; bad luck, there
is nothing I can do about it.
-- Then I would, probably, take the most recent, say, 100 OOM
reports, and calculate the *average* strlen() value
(including \r and \n at the end of each line)
(strlen(oom_report1) + ... + strlen(omm_report100)) / 100
Then I'd try to reach an agreement with MM people that we will
use this "average" oom_report_strlen() in ratelimit interval
calculation. Yes, some reports will be longer, some shorter.
Say, suppose...
I have 2 consoles, and I can write 250 bytes per second.
And average oom_report is 5000 bytes.
Then I can print one oom_report every (5000 / 250) seconds
in the *best* case. That's the optimistic baseline. There
can be printk()-s from other CPUs, etc. etc. No one can
predict those things.
Note, how things change when I have just 1 console enabled.
I have 1 console, and I can write 500 bytes per second.
And average oom_report is 5000 bytes.
Then I can print one oom_report every (5000 / 500) seconds
in the *best* case.
Just my $0.02. Who knows, may be it's dumb and ugly.
I don't have a dog in this fight.
-ss
linux-next: manual merge of the scsi-mkp tree with Linus' tree
Hi Martin,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
drivers/scsi/lpfc/lpfc_debugfs.c
between commit:
9e210178267b ("scsi: lpfc: Synchronize access to remoteport via rport")
from Linus' tree and commit:
d021613ee3ac ("scsi: lpfc: Remove set but not used variables 'tgtp'")
from the scsi-mkp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/scsi/lpfc/lpfc_debugfs.c
index aec5b10a8c85,d6e4cbfe3273..
--- a/drivers/scsi/lpfc/lpfc_debugfs.c
+++ b/drivers/scsi/lpfc/lpfc_debugfs.c
@@@ -550,8 -550,7 +550,7 @@@ lpfc_debugfs_nodelist_data(struct lpfc_
struct lpfc_nodelist *ndlp;
unsigned char *statep;
struct nvme_fc_local_port *localport;
- struct lpfc_nvmet_tgtport *tgtp;
- struct nvme_fc_remote_port *nrport;
+ struct nvme_fc_remote_port *nrport = NULL;
struct lpfc_nvme_rport *rport;
cnt = (LPFC_NODELIST_SIZE / LPFC_NODELIST_ENTRY_SIZE);
pgpjRzn5GDl2H.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the scsi-mkp tree with Linus' tree
Hi Martin,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
drivers/scsi/lpfc/lpfc_debugfs.c
between commit:
9e210178267b ("scsi: lpfc: Synchronize access to remoteport via rport")
from Linus' tree and commit:
d021613ee3ac ("scsi: lpfc: Remove set but not used variables 'tgtp'")
from the scsi-mkp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/scsi/lpfc/lpfc_debugfs.c
index aec5b10a8c85,d6e4cbfe3273..
--- a/drivers/scsi/lpfc/lpfc_debugfs.c
+++ b/drivers/scsi/lpfc/lpfc_debugfs.c
@@@ -550,8 -550,7 +550,7 @@@ lpfc_debugfs_nodelist_data(struct lpfc_
struct lpfc_nodelist *ndlp;
unsigned char *statep;
struct nvme_fc_local_port *localport;
- struct lpfc_nvmet_tgtport *tgtp;
- struct nvme_fc_remote_port *nrport;
+ struct nvme_fc_remote_port *nrport = NULL;
struct lpfc_nvme_rport *rport;
cnt = (LPFC_NODELIST_SIZE / LPFC_NODELIST_ENTRY_SIZE);
pgpjRzn5GDl2H.pgp
Description: OpenPGP digital signature
Re: [PATCH V9 00/21] C-SKY(csky) Linux Kernel Port
On Wed, Oct 17, 2018 at 05:58:46PM +0200, Arnd Bergmann wrote: > On Tue, Oct 16, 2018 at 4:58 AM Guo Ren wrote: > > > > This is the 9th version patchset to add the Linux kernel port for > > C-SKY(csky) based on linux-4.19-rc3. > > > > There are only a few changes between V8 patchset. Hope it could be > > merged into linux-4.20 and I'm very grateful for any help. > > I've gone through the entire series once more and saw no show-stoppers. > The last patch looked like it introduced a bug, but with that one dropped, > I'm happy for the architecture to get merged, unless anyone else > has any last-minute concerns. (Alternatively, explain why I'm wrong > and the code works correctly, of course). Ok and thx for the job of csky subsystem. > > I'd appreciate having someone else take another look at the signal > handling code, the atomics, and the DT bindings and provide another > Ack for those. > > The remaining open question is about the 32-bit time_t interfaces. > With 4.20, I did not manage to get the required system calls in place > for using 64-bit time_t in a new architecture, so you will at least > start out using 32-bit time_t and likely have to keep supporting > that going forward, unless we decide to break the ABI here later > on .This is something we normally don't do, but we might make > an exception here, under the assumption that there are no > existing users with the ABI. We can debate that once we get there. We support uclibc-ng and glibc. 1. For uclibc-ng, linux-4.20 could run with it. 2. For glibc, Maybe we could support 32-bit + 64-bit time_t with KERNEL_VERSION, or just only 64-bit then linux-4.20 couldn't work with the csky first glibc release. Best Regards Guo Ren
[PATCH] hugetlbfs: dirty pages as they are added to pagecache
Some test systems were experiencing negative huge page reserve
counts and incorrect file block counts. This was traced to
/proc/sys/vm/drop_caches removing clean pages from hugetlbfs
file pagecaches. When non-hugetlbfs explicit code removes the
pages, the appropriate accounting is not performed.
This can be recreated as follows:
fallocate -l 2M /dev/hugepages/foo
echo 1 > /proc/sys/vm/drop_caches
fallocate -l 2M /dev/hugepages/foo
grep -i huge /proc/meminfo
AnonHugePages: 0 kB
ShmemHugePages:0 kB
HugePages_Total:2048
HugePages_Free: 2047
HugePages_Rsvd:18446744073709551615
HugePages_Surp:0
Hugepagesize: 2048 kB
Hugetlb: 4194304 kB
ls -lsh /dev/hugepages/foo
4.0M -rw-r--r--. 1 root root 2.0M Oct 17 20:05 /dev/hugepages/foo
To address this issue, dirty pages as they are added to pagecache.
This can easily be reproduced with fallocate as shown above. Read
faulted pages will eventually end up being marked dirty. But there
is a window where they are clean and could be impacted by code such
as drop_caches. So, just dirty them all as they are added to the
pagecache.
In addition, it makes little sense to even try to drop hugetlbfs
pagecache pages, so disable calls to these filesystems in drop_caches
code.
Fixes: 70c3547e36f5 ("hugetlbfs: add hugetlbfs_fallocate()")
Cc: sta...@vger.kernel.org
Signed-off-by: Mike Kravetz
---
fs/drop_caches.c | 7 +++
mm/hugetlb.c | 6 ++
2 files changed, 13 insertions(+)
diff --git a/fs/drop_caches.c b/fs/drop_caches.c
index 82377017130f..b72c5bc502a8 100644
--- a/fs/drop_caches.c
+++ b/fs/drop_caches.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "internal.h"
/* A global variable is a bit ugly, but it keeps the code simple */
@@ -18,6 +19,12 @@ static void drop_pagecache_sb(struct super_block *sb, void
*unused)
{
struct inode *inode, *toput_inode = NULL;
+ /*
+* It makes no sense to try and drop hugetlbfs page cache pages.
+*/
+ if (sb->s_magic == HUGETLBFS_MAGIC)
+ return;
+
spin_lock(>s_inode_list_lock);
list_for_each_entry(inode, >s_inodes, i_sb_list) {
spin_lock(>i_lock);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 5c390f5a5207..7b5c0ad9a6bd 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3690,6 +3690,12 @@ int huge_add_to_page_cache(struct page *page, struct
address_space *mapping,
return err;
ClearPagePrivate(page);
+ /*
+* set page dirty so that it will not be removed from cache/file
+* by non-hugetlbfs specific code paths.
+*/
+ set_page_dirty(page);
+
spin_lock(>i_lock);
inode->i_blocks += blocks_per_huge_page(h);
spin_unlock(>i_lock);
--
2.17.2
Re: [PATCH V9 00/21] C-SKY(csky) Linux Kernel Port
On Wed, Oct 17, 2018 at 05:58:46PM +0200, Arnd Bergmann wrote: > On Tue, Oct 16, 2018 at 4:58 AM Guo Ren wrote: > > > > This is the 9th version patchset to add the Linux kernel port for > > C-SKY(csky) based on linux-4.19-rc3. > > > > There are only a few changes between V8 patchset. Hope it could be > > merged into linux-4.20 and I'm very grateful for any help. > > I've gone through the entire series once more and saw no show-stoppers. > The last patch looked like it introduced a bug, but with that one dropped, > I'm happy for the architecture to get merged, unless anyone else > has any last-minute concerns. (Alternatively, explain why I'm wrong > and the code works correctly, of course). Ok and thx for the job of csky subsystem. > > I'd appreciate having someone else take another look at the signal > handling code, the atomics, and the DT bindings and provide another > Ack for those. > > The remaining open question is about the 32-bit time_t interfaces. > With 4.20, I did not manage to get the required system calls in place > for using 64-bit time_t in a new architecture, so you will at least > start out using 32-bit time_t and likely have to keep supporting > that going forward, unless we decide to break the ABI here later > on .This is something we normally don't do, but we might make > an exception here, under the assumption that there are no > existing users with the ABI. We can debate that once we get there. We support uclibc-ng and glibc. 1. For uclibc-ng, linux-4.20 could run with it. 2. For glibc, Maybe we could support 32-bit + 64-bit time_t with KERNEL_VERSION, or just only 64-bit then linux-4.20 couldn't work with the csky first glibc release. Best Regards Guo Ren
[PATCH] hugetlbfs: dirty pages as they are added to pagecache
Some test systems were experiencing negative huge page reserve
counts and incorrect file block counts. This was traced to
/proc/sys/vm/drop_caches removing clean pages from hugetlbfs
file pagecaches. When non-hugetlbfs explicit code removes the
pages, the appropriate accounting is not performed.
This can be recreated as follows:
fallocate -l 2M /dev/hugepages/foo
echo 1 > /proc/sys/vm/drop_caches
fallocate -l 2M /dev/hugepages/foo
grep -i huge /proc/meminfo
AnonHugePages: 0 kB
ShmemHugePages:0 kB
HugePages_Total:2048
HugePages_Free: 2047
HugePages_Rsvd:18446744073709551615
HugePages_Surp:0
Hugepagesize: 2048 kB
Hugetlb: 4194304 kB
ls -lsh /dev/hugepages/foo
4.0M -rw-r--r--. 1 root root 2.0M Oct 17 20:05 /dev/hugepages/foo
To address this issue, dirty pages as they are added to pagecache.
This can easily be reproduced with fallocate as shown above. Read
faulted pages will eventually end up being marked dirty. But there
is a window where they are clean and could be impacted by code such
as drop_caches. So, just dirty them all as they are added to the
pagecache.
In addition, it makes little sense to even try to drop hugetlbfs
pagecache pages, so disable calls to these filesystems in drop_caches
code.
Fixes: 70c3547e36f5 ("hugetlbfs: add hugetlbfs_fallocate()")
Cc: sta...@vger.kernel.org
Signed-off-by: Mike Kravetz
---
fs/drop_caches.c | 7 +++
mm/hugetlb.c | 6 ++
2 files changed, 13 insertions(+)
diff --git a/fs/drop_caches.c b/fs/drop_caches.c
index 82377017130f..b72c5bc502a8 100644
--- a/fs/drop_caches.c
+++ b/fs/drop_caches.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "internal.h"
/* A global variable is a bit ugly, but it keeps the code simple */
@@ -18,6 +19,12 @@ static void drop_pagecache_sb(struct super_block *sb, void
*unused)
{
struct inode *inode, *toput_inode = NULL;
+ /*
+* It makes no sense to try and drop hugetlbfs page cache pages.
+*/
+ if (sb->s_magic == HUGETLBFS_MAGIC)
+ return;
+
spin_lock(>s_inode_list_lock);
list_for_each_entry(inode, >s_inodes, i_sb_list) {
spin_lock(>i_lock);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 5c390f5a5207..7b5c0ad9a6bd 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3690,6 +3690,12 @@ int huge_add_to_page_cache(struct page *page, struct
address_space *mapping,
return err;
ClearPagePrivate(page);
+ /*
+* set page dirty so that it will not be removed from cache/file
+* by non-hugetlbfs specific code paths.
+*/
+ set_page_dirty(page);
+
spin_lock(>i_lock);
inode->i_blocks += blocks_per_huge_page(h);
spin_unlock(>i_lock);
--
2.17.2
Re: [RFC PATCH 1/5] x86: introduce preemption disable prefix
On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit wrote: > > at 6:22 PM, Andy Lutomirski wrote: > > > > >> On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote: > >> > >> It is sometimes beneficial to prevent preemption for very few > >> instructions, or prevent preemption for some instructions that precede > >> a branch (this latter case will be introduced in the next patches). > >> > >> To provide such functionality on x86-64, we use an empty REX-prefix > >> (opcode 0x40) as an indication that preemption is disabled for the > >> following instruction. > > > > Nifty! > > > > That being said, I think you have a few bugs. First, you can’t just ignore > > a rescheduling interrupt, as you introduce unbounded latency when this > > happens — you’re effectively emulating preempt_enable_no_resched(), which > > is not a drop-in replacement for preempt_enable(). To fix this, you may > > need to jump to a slow-path trampoline that calls schedule() at the end or > > consider rewinding one instruction instead. Or use TF, which is only a > > little bit terrifying… > > Yes, I didn’t pay enough attention here. For my use-case, I think that the > easiest solution would be to make synchronize_sched() ignore preemptions > that happen while the prefix is detected. It would slightly change the > meaning of the prefix. > > > You also aren’t accounting for the case where you get an exception that > > is, in turn, preempted. > > Hmm.. Can you give me an example for such an exception in my use-case? I > cannot think of an exception that might be preempted (assuming #BP, #MC > cannot be preempted). > Look for cond_local_irq_enable(). --Andy
Re: [RFC PATCH 1/5] x86: introduce preemption disable prefix
On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit wrote: > > at 6:22 PM, Andy Lutomirski wrote: > > > > >> On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote: > >> > >> It is sometimes beneficial to prevent preemption for very few > >> instructions, or prevent preemption for some instructions that precede > >> a branch (this latter case will be introduced in the next patches). > >> > >> To provide such functionality on x86-64, we use an empty REX-prefix > >> (opcode 0x40) as an indication that preemption is disabled for the > >> following instruction. > > > > Nifty! > > > > That being said, I think you have a few bugs. First, you can’t just ignore > > a rescheduling interrupt, as you introduce unbounded latency when this > > happens — you’re effectively emulating preempt_enable_no_resched(), which > > is not a drop-in replacement for preempt_enable(). To fix this, you may > > need to jump to a slow-path trampoline that calls schedule() at the end or > > consider rewinding one instruction instead. Or use TF, which is only a > > little bit terrifying… > > Yes, I didn’t pay enough attention here. For my use-case, I think that the > easiest solution would be to make synchronize_sched() ignore preemptions > that happen while the prefix is detected. It would slightly change the > meaning of the prefix. > > > You also aren’t accounting for the case where you get an exception that > > is, in turn, preempted. > > Hmm.. Can you give me an example for such an exception in my use-case? I > cannot think of an exception that might be preempted (assuming #BP, #MC > cannot be preempted). > Look for cond_local_irq_enable(). --Andy
Re: [PATCH v3 4/6] clocksource: exynos_mct: Add arch_timer cooperation mode for ARM64
Hi Marek,
On 2018년 10월 17일 22:41, Marek Szyprowski wrote:
> To get ARM Architected Timers working on Samsung Exynos SoCs, one has to
> first configure and enable Exynos Multi-Core Timer, because they both
> share some common hardware blocks (global system counter). This patch
> adds a mode of cooperation with arch_timer driver, so kernel can use
> CP15 based timer interface via arch_timer driver, which is mandatory
> on ARM64. In such mode MCT driver only enables its clocks and starts
> global timer. Everything else will be handled by arch_timer driver.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/clocksource/exynos_mct.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/clocksource/exynos_mct.c
> b/drivers/clocksource/exynos_mct.c
> index 02ad55db390b..1b19a4f03929 100644
> --- a/drivers/clocksource/exynos_mct.c
> +++ b/drivers/clocksource/exynos_mct.c
> @@ -606,6 +606,15 @@ static int __init mct_init_dt(struct device_node *np,
> unsigned int int_type)
> if (ret)
> return ret;
>
> + if (IS_ENABLED(CONFIG_ARM64) && IS_ENABLED(CONFIG_ARM_ARCH_TIMER)) {
> + struct device_node *np = of_find_compatible_node(NULL, NULL,
> + "arm,armv8-timer");
> + if (np) {
> + of_node_put(np);
> + exynos4_mct_frc_start();
> + return 0;
> + }
> + }
>
> ret = exynos4_timer_interrupts(np, int_type);
> if (ret)
>
I tested it on Exynos5433-based TM2 board.
Reviewed-by: Chanwoo Choi
Tested-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 4/6] clocksource: exynos_mct: Add arch_timer cooperation mode for ARM64
Hi Marek,
On 2018년 10월 17일 22:41, Marek Szyprowski wrote:
> To get ARM Architected Timers working on Samsung Exynos SoCs, one has to
> first configure and enable Exynos Multi-Core Timer, because they both
> share some common hardware blocks (global system counter). This patch
> adds a mode of cooperation with arch_timer driver, so kernel can use
> CP15 based timer interface via arch_timer driver, which is mandatory
> on ARM64. In such mode MCT driver only enables its clocks and starts
> global timer. Everything else will be handled by arch_timer driver.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/clocksource/exynos_mct.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/clocksource/exynos_mct.c
> b/drivers/clocksource/exynos_mct.c
> index 02ad55db390b..1b19a4f03929 100644
> --- a/drivers/clocksource/exynos_mct.c
> +++ b/drivers/clocksource/exynos_mct.c
> @@ -606,6 +606,15 @@ static int __init mct_init_dt(struct device_node *np,
> unsigned int int_type)
> if (ret)
> return ret;
>
> + if (IS_ENABLED(CONFIG_ARM64) && IS_ENABLED(CONFIG_ARM_ARCH_TIMER)) {
> + struct device_node *np = of_find_compatible_node(NULL, NULL,
> + "arm,armv8-timer");
> + if (np) {
> + of_node_put(np);
> + exynos4_mct_frc_start();
> + return 0;
> + }
> + }
>
> ret = exynos4_timer_interrupts(np, int_type);
> if (ret)
>
I tested it on Exynos5433-based TM2 board.
Reviewed-by: Chanwoo Choi
Tested-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 3/6] clocksource: exynos_mct: Refactor resources allocation
Hi Marek,
I tested it for both kernel booting and cpu hotplugging
on Exynos5433-based TM2 board.
Reviewed-by: Chanwoo Choi
Tested-by: Chanwoo Choi
On 2018년 10월 17일 22:41, Marek Szyprowski wrote:
> Move interrupts allocation from exynos4_timer_resources() into separate
> function together with the interrupt number parsing code from
> mct_init_dt(), so the code for managing interrupts is kept together.
> While touching exynos4_timer_resources() function, move of_iomap() to it.
> No functional changes.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/clocksource/exynos_mct.c | 49 +++-
> 1 file changed, 30 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/clocksource/exynos_mct.c
> b/drivers/clocksource/exynos_mct.c
> index 49413900b24c..02ad55db390b 100644
> --- a/drivers/clocksource/exynos_mct.c
> +++ b/drivers/clocksource/exynos_mct.c
> @@ -502,11 +502,14 @@ static int exynos4_mct_dying_cpu(unsigned int cpu)
> return 0;
> }
>
> -static int __init exynos4_timer_resources(struct device_node *np, void
> __iomem *base)
> +static int __init exynos4_timer_resources(struct device_node *np)
> {
> - int err, cpu;
> struct clk *mct_clk, *tick_clk;
>
> + reg_base = of_iomap(np, 0);
> + if (!reg_base)
> + panic("%s: unable to ioremap mct address space\n", __func__);
> +
> tick_clk = of_clk_get_by_name(np, "fin_pll");
> if (IS_ERR(tick_clk))
> panic("%s: unable to determine tick clock rate\n", __func__);
> @@ -517,9 +520,27 @@ static int __init exynos4_timer_resources(struct
> device_node *np, void __iomem *
> panic("%s: unable to retrieve mct clock instance\n", __func__);
> clk_prepare_enable(mct_clk);
>
> - reg_base = base;
> - if (!reg_base)
> - panic("%s: unable to ioremap mct address space\n", __func__);
> + return 0;
> +}
> +
> +static int __init exynos4_timer_interrupts(struct device_node *np,
> +unsigned int int_type)
> +{
> + int i, err, cpu;
> +
> + mct_int_type = int_type;
> +
> + /* This driver uses only one global timer interrupt */
> + mct_irqs[MCT_G0_IRQ] = irq_of_parse_and_map(np, MCT_G0_IRQ);
> +
> + /*
> + * Find out the number of local irqs specified. The local
> + * timer irqs are specified after the four global timer
> + * irqs are specified.
> + */
> + nr_irqs = of_irq_count(np);
> + for (i = MCT_L0_IRQ; i < nr_irqs; i++)
> + mct_irqs[i] = irq_of_parse_and_map(np, i);
>
> if (mct_int_type == MCT_INT_PPI) {
>
> @@ -579,24 +600,14 @@ static int __init exynos4_timer_resources(struct
> device_node *np, void __iomem *
>
> static int __init mct_init_dt(struct device_node *np, unsigned int int_type)
> {
> - u32 nr_irqs, i;
> int ret;
>
> - mct_int_type = int_type;
> -
> - /* This driver uses only one global timer interrupt */
> - mct_irqs[MCT_G0_IRQ] = irq_of_parse_and_map(np, MCT_G0_IRQ);
> + ret = exynos4_timer_resources(np);
> + if (ret)
> + return ret;
>
> - /*
> - * Find out the number of local irqs specified. The local
> - * timer irqs are specified after the four global timer
> - * irqs are specified.
> - */
> - nr_irqs = of_irq_count(np);
> - for (i = MCT_L0_IRQ; i < nr_irqs; i++)
> - mct_irqs[i] = irq_of_parse_and_map(np, i);
>
> - ret = exynos4_timer_resources(np, of_iomap(np, 0));
> + ret = exynos4_timer_interrupts(np, int_type);
> if (ret)
> return ret;
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v3 3/6] clocksource: exynos_mct: Refactor resources allocation
Hi Marek,
I tested it for both kernel booting and cpu hotplugging
on Exynos5433-based TM2 board.
Reviewed-by: Chanwoo Choi
Tested-by: Chanwoo Choi
On 2018년 10월 17일 22:41, Marek Szyprowski wrote:
> Move interrupts allocation from exynos4_timer_resources() into separate
> function together with the interrupt number parsing code from
> mct_init_dt(), so the code for managing interrupts is kept together.
> While touching exynos4_timer_resources() function, move of_iomap() to it.
> No functional changes.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/clocksource/exynos_mct.c | 49 +++-
> 1 file changed, 30 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/clocksource/exynos_mct.c
> b/drivers/clocksource/exynos_mct.c
> index 49413900b24c..02ad55db390b 100644
> --- a/drivers/clocksource/exynos_mct.c
> +++ b/drivers/clocksource/exynos_mct.c
> @@ -502,11 +502,14 @@ static int exynos4_mct_dying_cpu(unsigned int cpu)
> return 0;
> }
>
> -static int __init exynos4_timer_resources(struct device_node *np, void
> __iomem *base)
> +static int __init exynos4_timer_resources(struct device_node *np)
> {
> - int err, cpu;
> struct clk *mct_clk, *tick_clk;
>
> + reg_base = of_iomap(np, 0);
> + if (!reg_base)
> + panic("%s: unable to ioremap mct address space\n", __func__);
> +
> tick_clk = of_clk_get_by_name(np, "fin_pll");
> if (IS_ERR(tick_clk))
> panic("%s: unable to determine tick clock rate\n", __func__);
> @@ -517,9 +520,27 @@ static int __init exynos4_timer_resources(struct
> device_node *np, void __iomem *
> panic("%s: unable to retrieve mct clock instance\n", __func__);
> clk_prepare_enable(mct_clk);
>
> - reg_base = base;
> - if (!reg_base)
> - panic("%s: unable to ioremap mct address space\n", __func__);
> + return 0;
> +}
> +
> +static int __init exynos4_timer_interrupts(struct device_node *np,
> +unsigned int int_type)
> +{
> + int i, err, cpu;
> +
> + mct_int_type = int_type;
> +
> + /* This driver uses only one global timer interrupt */
> + mct_irqs[MCT_G0_IRQ] = irq_of_parse_and_map(np, MCT_G0_IRQ);
> +
> + /*
> + * Find out the number of local irqs specified. The local
> + * timer irqs are specified after the four global timer
> + * irqs are specified.
> + */
> + nr_irqs = of_irq_count(np);
> + for (i = MCT_L0_IRQ; i < nr_irqs; i++)
> + mct_irqs[i] = irq_of_parse_and_map(np, i);
>
> if (mct_int_type == MCT_INT_PPI) {
>
> @@ -579,24 +600,14 @@ static int __init exynos4_timer_resources(struct
> device_node *np, void __iomem *
>
> static int __init mct_init_dt(struct device_node *np, unsigned int int_type)
> {
> - u32 nr_irqs, i;
> int ret;
>
> - mct_int_type = int_type;
> -
> - /* This driver uses only one global timer interrupt */
> - mct_irqs[MCT_G0_IRQ] = irq_of_parse_and_map(np, MCT_G0_IRQ);
> + ret = exynos4_timer_resources(np);
> + if (ret)
> + return ret;
>
> - /*
> - * Find out the number of local irqs specified. The local
> - * timer irqs are specified after the four global timer
> - * irqs are specified.
> - */
> - nr_irqs = of_irq_count(np);
> - for (i = MCT_L0_IRQ; i < nr_irqs; i++)
> - mct_irqs[i] = irq_of_parse_and_map(np, i);
>
> - ret = exynos4_timer_resources(np, of_iomap(np, 0));
> + ret = exynos4_timer_interrupts(np, int_type);
> if (ret)
> return ret;
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH V9 18/21] dt-bindings: csky CPU Bindings
On Thu, Oct 18, 2018 at 11:21:30AM +0800, Guo Ren wrote: > On Wed, Oct 17, 2018 at 05:50:33PM +0200, Arnd Bergmann wrote: > > On Tue, Oct 16, 2018 at 5:30 AM Guo Ren wrote: > > > > > > This patch adds the documentation to describe that how to add cpu nodes in > > > dts for SMP. > > > > > > Signed-off-by: Guo Ren > > > Cc: Rob Herring > > > > I don't see anything wrong, but I'll let Rob or some other DT maintainer > > provide an Ack when they are happy. > Yes, Rob help a lot for reviewing the DT-docs of csky subsystem. Thx Bob :) Sorry, Thx Rob. > > Best Regards > Guo Ren
Re: [PATCH V9 18/21] dt-bindings: csky CPU Bindings
On Thu, Oct 18, 2018 at 11:21:30AM +0800, Guo Ren wrote: > On Wed, Oct 17, 2018 at 05:50:33PM +0200, Arnd Bergmann wrote: > > On Tue, Oct 16, 2018 at 5:30 AM Guo Ren wrote: > > > > > > This patch adds the documentation to describe that how to add cpu nodes in > > > dts for SMP. > > > > > > Signed-off-by: Guo Ren > > > Cc: Rob Herring > > > > I don't see anything wrong, but I'll let Rob or some other DT maintainer > > provide an Ack when they are happy. > Yes, Rob help a lot for reviewing the DT-docs of csky subsystem. Thx Bob :) Sorry, Thx Rob. > > Best Regards > Guo Ren
Re: [PATCH 3/4] irqchip/mbigen: add support for a MBIGEN generating SPIs
Hi, Marc
On 2018/10/18 0:30, Marc Zyngier wrote:
On 16/10/18 10:15, Yang Yingliang wrote:
Now with
5052875 ("irqchip/gic-v3: Add support for Message Based Interrupts as an MSI
controller"),
we can support MBIGEN to generate message based SPIs by writing GICD_SETSPIR.
The first 64-pins of each MBIGEN chip is used to generate SPIs, and each
MBIGEN chip has several MBIGEN nodes, every node has 128 pins for generating
LPIs. The total pins are: 64(SPIs) + 128 * node_nr(LPIs). So we can translate
the pin index in a unified way in mbigen_domain_translate().
Also Add TYPE and VEC registers that used by generating SPIs, the driver can
access them when MBIGEN is used to generate SPIs.
Signed-off-by: Yang Yingliang
---
drivers/irqchip/irq-mbigen.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index f05998f..37c1932 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -48,6 +48,7 @@
#define MBIGEN_NODE_OFFSET0x1000
/* offset of vector register in mbigen node */
+#define REG_MBIGEN_SPI_VEC_OFFSET 0x500
#define REG_MBIGEN_LPI_VEC_OFFSET 0x200
/**
@@ -62,6 +63,7 @@
* This register is used to configure interrupt
* trigger type
*/
+#define REG_MBIGEN_SPI_TYPE_OFFSET 0x400
#define REG_MBIGEN_LPI_TYPE_OFFSET0x0
/**
@@ -79,6 +81,9 @@ static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t
hwirq)
{
unsigned int nid, pin;
+ if (hwirq < SPI_NUM_PER_MBIGEN_CHIP)
+ return (hwirq * 4 + REG_MBIGEN_SPI_VEC_OFFSET);
+
hwirq -= SPI_NUM_PER_MBIGEN_CHIP;
nid = hwirq / IRQS_PER_MBIGEN_NODE + 1;
pin = hwirq % IRQS_PER_MBIGEN_NODE;
@@ -92,6 +97,13 @@ static inline void get_mbigen_type_reg(irq_hw_number_t hwirq,
{
unsigned int nid, irq_ofst, ofst;
+ if (hwirq < SPI_NUM_PER_MBIGEN_CHIP) {
+ *mask = 1 << (hwirq % 32);
+ ofst = hwirq / 32 * 4;
+ *addr = ofst + REG_MBIGEN_SPI_TYPE_OFFSET;
+ return;
+ }
+
hwirq -= SPI_NUM_PER_MBIGEN_CHIP;
nid = hwirq / IRQS_PER_MBIGEN_NODE + 1;
irq_ofst = hwirq % IRQS_PER_MBIGEN_NODE;
@@ -162,6 +174,12 @@ static void mbigen_write_msg(struct msi_desc *desc, struct
msi_msg *msg)
u32 val;
base += get_mbigen_vec_reg(d->hwirq);
+
+ if (d->hwirq < SPI_NUM_PER_MBIGEN_CHIP) {
+ writel_relaxed(msg->data, base);
+ return;
+ }
How is the GICD_SETSPI_NSR base address programmed if you're ignoring
the address stored in the message?
Now, this base address is encoded in MBIGEN register by default.
In case this address isn't set to register in later SoCs, I think the
MBIGEN driver set this base address would be better. I will add
relative codes to handle both GICD_SETSPI_NSR and ITS Translate
address.
How do you deal with level interrupts, as you don't seem to use the
level MSI framework either?
The MBIGEN driver need to clear active state in irq_eoi hook, when it
dealing with level SPIs.
+
val = readl_relaxed(base);
val &= ~(IRQ_EVENT_ID_MASK << IRQ_EVENT_ID_SHIFT);
@@ -182,8 +200,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
if (fwspec->param_count != 2)
return -EINVAL;
- if ((fwspec->param[0] > MAXIMUM_IRQ_PIN_NUM) ||
- (fwspec->param[0] < SPI_NUM_PER_MBIGEN_CHIP))
+ if (fwspec->param[0] > MAXIMUM_IRQ_PIN_NUM)
return -EINVAL;
else
*hwirq = fwspec->param[0];
Now, the biggest question of them all: how does it work with ACPI? Last
time I checked, there was no DT support for platforms using the MBIGEN.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/hisilicon/hip07.dtsi
This DT describes how platform devices using the MBIGEN.
My gut feeling is that it would be so much better if the SPIs generated
by the MBIGEN were configured in firmware, and the devices behind it
would just describe the corresponding SPI...
We need use this framework to clear active state in MBIGEN register, so
configuring
in firmware is not enough...
Regards,
Yang
Thanks,
M.
Re: [PATCH V9 21/21] csky: support dword access for get_user_size()
On Wed, Oct 17, 2018 at 05:44:17PM +0200, Arnd Bergmann wrote:
> On Tue, Oct 16, 2018 at 5:33 AM Guo Ren wrote:
> >
> > Support dword access for get_user_size and redesign put_user_size with
> > the same style of get_user_size. It's Ok to use xxx_user_asm_common for
> > all size of variable with ldb, ldh, ldw, ld.d
> >
> > ld.d rx, (addr, 0) could "rx <= addr" "and r(x+1) <= addr+4" and this also
> > follow abiv2 gcc ABI for dword access.
>
> Are you sure this is correct for this?
>
> static inline u32 get_64_to_32(__u64 __user *p)
> {
> u32 ret;
> get_user(ret, p);
> return ret;
> }
>
> If I read __get_user_asm_common() right, the ld.d would overwrite
> two registers, but the caller only expects one, so it clobbers one
> that might be in use.
Ah... BUG! I only consider the get_user(u64, u64 *) :P
Change to:
case 8: \
__get_user_asm_dword((x), ptr, "ld.d", retval); \
break;
#define __get_user_asm_dword(x, ptr, err) \
do {\
u64 tmp;\
__get_user_asm_common(tmp, ptr, "ld.d", err); \
x = typeof(x) tmp; \
} while(0)
#define __put_user_asm_dword(x, ptr, err) \
do {\
u64 tmp = (u64) x; \
__put_user_asm_common(tmp, ptr, "st.d", err); \
} while(0)
Hmm?
Best Regards
Guo Ren
Re: [PATCH V9 21/21] csky: support dword access for get_user_size()
On Wed, Oct 17, 2018 at 05:44:17PM +0200, Arnd Bergmann wrote:
> On Tue, Oct 16, 2018 at 5:33 AM Guo Ren wrote:
> >
> > Support dword access for get_user_size and redesign put_user_size with
> > the same style of get_user_size. It's Ok to use xxx_user_asm_common for
> > all size of variable with ldb, ldh, ldw, ld.d
> >
> > ld.d rx, (addr, 0) could "rx <= addr" "and r(x+1) <= addr+4" and this also
> > follow abiv2 gcc ABI for dword access.
>
> Are you sure this is correct for this?
>
> static inline u32 get_64_to_32(__u64 __user *p)
> {
> u32 ret;
> get_user(ret, p);
> return ret;
> }
>
> If I read __get_user_asm_common() right, the ld.d would overwrite
> two registers, but the caller only expects one, so it clobbers one
> that might be in use.
Ah... BUG! I only consider the get_user(u64, u64 *) :P
Change to:
case 8: \
__get_user_asm_dword((x), ptr, "ld.d", retval); \
break;
#define __get_user_asm_dword(x, ptr, err) \
do {\
u64 tmp;\
__get_user_asm_common(tmp, ptr, "ld.d", err); \
x = typeof(x) tmp; \
} while(0)
#define __put_user_asm_dword(x, ptr, err) \
do {\
u64 tmp = (u64) x; \
__put_user_asm_common(tmp, ptr, "st.d", err); \
} while(0)
Hmm?
Best Regards
Guo Ren
Re: [PATCH 3/4] irqchip/mbigen: add support for a MBIGEN generating SPIs
Hi, Marc
On 2018/10/18 0:30, Marc Zyngier wrote:
On 16/10/18 10:15, Yang Yingliang wrote:
Now with
5052875 ("irqchip/gic-v3: Add support for Message Based Interrupts as an MSI
controller"),
we can support MBIGEN to generate message based SPIs by writing GICD_SETSPIR.
The first 64-pins of each MBIGEN chip is used to generate SPIs, and each
MBIGEN chip has several MBIGEN nodes, every node has 128 pins for generating
LPIs. The total pins are: 64(SPIs) + 128 * node_nr(LPIs). So we can translate
the pin index in a unified way in mbigen_domain_translate().
Also Add TYPE and VEC registers that used by generating SPIs, the driver can
access them when MBIGEN is used to generate SPIs.
Signed-off-by: Yang Yingliang
---
drivers/irqchip/irq-mbigen.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index f05998f..37c1932 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -48,6 +48,7 @@
#define MBIGEN_NODE_OFFSET0x1000
/* offset of vector register in mbigen node */
+#define REG_MBIGEN_SPI_VEC_OFFSET 0x500
#define REG_MBIGEN_LPI_VEC_OFFSET 0x200
/**
@@ -62,6 +63,7 @@
* This register is used to configure interrupt
* trigger type
*/
+#define REG_MBIGEN_SPI_TYPE_OFFSET 0x400
#define REG_MBIGEN_LPI_TYPE_OFFSET0x0
/**
@@ -79,6 +81,9 @@ static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t
hwirq)
{
unsigned int nid, pin;
+ if (hwirq < SPI_NUM_PER_MBIGEN_CHIP)
+ return (hwirq * 4 + REG_MBIGEN_SPI_VEC_OFFSET);
+
hwirq -= SPI_NUM_PER_MBIGEN_CHIP;
nid = hwirq / IRQS_PER_MBIGEN_NODE + 1;
pin = hwirq % IRQS_PER_MBIGEN_NODE;
@@ -92,6 +97,13 @@ static inline void get_mbigen_type_reg(irq_hw_number_t hwirq,
{
unsigned int nid, irq_ofst, ofst;
+ if (hwirq < SPI_NUM_PER_MBIGEN_CHIP) {
+ *mask = 1 << (hwirq % 32);
+ ofst = hwirq / 32 * 4;
+ *addr = ofst + REG_MBIGEN_SPI_TYPE_OFFSET;
+ return;
+ }
+
hwirq -= SPI_NUM_PER_MBIGEN_CHIP;
nid = hwirq / IRQS_PER_MBIGEN_NODE + 1;
irq_ofst = hwirq % IRQS_PER_MBIGEN_NODE;
@@ -162,6 +174,12 @@ static void mbigen_write_msg(struct msi_desc *desc, struct
msi_msg *msg)
u32 val;
base += get_mbigen_vec_reg(d->hwirq);
+
+ if (d->hwirq < SPI_NUM_PER_MBIGEN_CHIP) {
+ writel_relaxed(msg->data, base);
+ return;
+ }
How is the GICD_SETSPI_NSR base address programmed if you're ignoring
the address stored in the message?
Now, this base address is encoded in MBIGEN register by default.
In case this address isn't set to register in later SoCs, I think the
MBIGEN driver set this base address would be better. I will add
relative codes to handle both GICD_SETSPI_NSR and ITS Translate
address.
How do you deal with level interrupts, as you don't seem to use the
level MSI framework either?
The MBIGEN driver need to clear active state in irq_eoi hook, when it
dealing with level SPIs.
+
val = readl_relaxed(base);
val &= ~(IRQ_EVENT_ID_MASK << IRQ_EVENT_ID_SHIFT);
@@ -182,8 +200,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
if (fwspec->param_count != 2)
return -EINVAL;
- if ((fwspec->param[0] > MAXIMUM_IRQ_PIN_NUM) ||
- (fwspec->param[0] < SPI_NUM_PER_MBIGEN_CHIP))
+ if (fwspec->param[0] > MAXIMUM_IRQ_PIN_NUM)
return -EINVAL;
else
*hwirq = fwspec->param[0];
Now, the biggest question of them all: how does it work with ACPI? Last
time I checked, there was no DT support for platforms using the MBIGEN.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/hisilicon/hip07.dtsi
This DT describes how platform devices using the MBIGEN.
My gut feeling is that it would be so much better if the SPIs generated
by the MBIGEN were configured in firmware, and the devices behind it
would just describe the corresponding SPI...
We need use this framework to clear active state in MBIGEN register, so
configuring
in firmware is not enough...
Regards,
Yang
Thanks,
M.
Re: [RESEND PATCH] ARM: prevent tracing IPI_CPU_BACKTRACE
On Thu, 27 Sep 2018 at 11:42, Chunyan Zhang wrote:
>
> From: Arnd Bergmann
>
> When function tracing for IPIs is enabled, we get a warning for an
> overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
> as triggered by raise_nmi():
>
> arch/arm/kernel/smp.c: In function 'raise_nmi':
> arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds
> [-Werror=array-bounds]
> trace_ipi_raise(target, ipi_types[ipinr]);
>
> This is a correct warning as we actually overflow the array here.
>
> This patch raise_nmi() to call __smp_cross_call() instead of
> smp_cross_call(), to avoid calling into ftrace. For clarification,
> I'm also adding a two new code comments describing how this one
> is special.
>
> The warning appears to have shown up after patch e7273ff49acf
> ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI"), which
> changed the number assignment from '15' to '8', but as far as I can
> tell has existed since the IPI tracepoints were first introduced.
> If we decide to backport this patch to stable kernels, we probably
> need to backport e7273ff49acf as well.
>
> Resubmiting this patch is because that I found coverity is complaining
> the issue this patch fixed, and also I got the traces like below:
> "ipi_raise: target_mask=0001 (machine_suspend)" which actually was
> the TPS of suspend_resume[1] rather than ipi_raise.
>
> [1]
> https://elixir.bootlin.com/linux/latest/source/kernel/power/suspend.c#L80
>
> Signed-off-by: Arnd Bergmann
> Fixes: e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI")
> Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") # v3.17
> Signed-off-by: Chunyan Zhang
> ---
> arch/arm/include/asm/hardirq.h | 1 +
> arch/arm/kernel/smp.c | 6 +-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
> index cba23ea..7a88f16 100644
> --- a/arch/arm/include/asm/hardirq.h
> +++ b/arch/arm/include/asm/hardirq.h
> @@ -6,6 +6,7 @@
> #include
> #include
>
> +/* number of IPIS _not_ including IPI_CPU_BACKTRACE */
> #define NR_IPI 7
>
> typedef struct {
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 0978282..123be77 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -75,6 +75,10 @@ enum ipi_msg_type {
> IPI_CPU_STOP,
> IPI_IRQ_WORK,
> IPI_COMPLETION,
> + /*
> +* CPU_BACKTRACE is special and not included in NR_IPI
> +* or tracable with trace_ipi_*
> +*/
> IPI_CPU_BACKTRACE,
> /*
> * SGI8-15 can be reserved by secure firmware, and thus may
> @@ -755,7 +759,7 @@ core_initcall(register_cpufreq_notifier);
>
> static void raise_nmi(cpumask_t *mask)
> {
> - smp_cross_call(mask, IPI_CPU_BACKTRACE);
> + _smp_cross_call(mask, IPI_CPU_BACKTRACE);
Here should be double underline, i.e.
> + __smp_cross_call(mask, IPI_CPU_BACKTRACE);
> }
>
> void arch_trigger_cpumask_backtrace(const cpumask_t *mask, bool exclude_self)
> --
> 2.7.4
>
Re: [RESEND PATCH] ARM: prevent tracing IPI_CPU_BACKTRACE
On Thu, 27 Sep 2018 at 11:42, Chunyan Zhang wrote:
>
> From: Arnd Bergmann
>
> When function tracing for IPIs is enabled, we get a warning for an
> overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
> as triggered by raise_nmi():
>
> arch/arm/kernel/smp.c: In function 'raise_nmi':
> arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds
> [-Werror=array-bounds]
> trace_ipi_raise(target, ipi_types[ipinr]);
>
> This is a correct warning as we actually overflow the array here.
>
> This patch raise_nmi() to call __smp_cross_call() instead of
> smp_cross_call(), to avoid calling into ftrace. For clarification,
> I'm also adding a two new code comments describing how this one
> is special.
>
> The warning appears to have shown up after patch e7273ff49acf
> ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI"), which
> changed the number assignment from '15' to '8', but as far as I can
> tell has existed since the IPI tracepoints were first introduced.
> If we decide to backport this patch to stable kernels, we probably
> need to backport e7273ff49acf as well.
>
> Resubmiting this patch is because that I found coverity is complaining
> the issue this patch fixed, and also I got the traces like below:
> "ipi_raise: target_mask=0001 (machine_suspend)" which actually was
> the TPS of suspend_resume[1] rather than ipi_raise.
>
> [1]
> https://elixir.bootlin.com/linux/latest/source/kernel/power/suspend.c#L80
>
> Signed-off-by: Arnd Bergmann
> Fixes: e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI")
> Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") # v3.17
> Signed-off-by: Chunyan Zhang
> ---
> arch/arm/include/asm/hardirq.h | 1 +
> arch/arm/kernel/smp.c | 6 +-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
> index cba23ea..7a88f16 100644
> --- a/arch/arm/include/asm/hardirq.h
> +++ b/arch/arm/include/asm/hardirq.h
> @@ -6,6 +6,7 @@
> #include
> #include
>
> +/* number of IPIS _not_ including IPI_CPU_BACKTRACE */
> #define NR_IPI 7
>
> typedef struct {
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 0978282..123be77 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -75,6 +75,10 @@ enum ipi_msg_type {
> IPI_CPU_STOP,
> IPI_IRQ_WORK,
> IPI_COMPLETION,
> + /*
> +* CPU_BACKTRACE is special and not included in NR_IPI
> +* or tracable with trace_ipi_*
> +*/
> IPI_CPU_BACKTRACE,
> /*
> * SGI8-15 can be reserved by secure firmware, and thus may
> @@ -755,7 +759,7 @@ core_initcall(register_cpufreq_notifier);
>
> static void raise_nmi(cpumask_t *mask)
> {
> - smp_cross_call(mask, IPI_CPU_BACKTRACE);
> + _smp_cross_call(mask, IPI_CPU_BACKTRACE);
Here should be double underline, i.e.
> + __smp_cross_call(mask, IPI_CPU_BACKTRACE);
> }
>
> void arch_trigger_cpumask_backtrace(const cpumask_t *mask, bool exclude_self)
> --
> 2.7.4
>
Re: [RFC PATCH 1/5] x86: introduce preemption disable prefix
at 8:11 PM, Nadav Amit wrote: > at 6:22 PM, Andy Lutomirski wrote: > >>> On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote: >>> >>> It is sometimes beneficial to prevent preemption for very few >>> instructions, or prevent preemption for some instructions that precede >>> a branch (this latter case will be introduced in the next patches). >>> >>> To provide such functionality on x86-64, we use an empty REX-prefix >>> (opcode 0x40) as an indication that preemption is disabled for the >>> following instruction. >> >> Nifty! >> >> That being said, I think you have a few bugs. First, you can’t just ignore >> a rescheduling interrupt, as you introduce unbounded latency when this >> happens — you’re effectively emulating preempt_enable_no_resched(), which >> is not a drop-in replacement for preempt_enable(). To fix this, you may >> need to jump to a slow-path trampoline that calls schedule() at the end or >> consider rewinding one instruction instead. Or use TF, which is only a >> little bit terrifying… > > Yes, I didn’t pay enough attention here. For my use-case, I think that the > easiest solution would be to make synchronize_sched() ignore preemptions > that happen while the prefix is detected. It would slightly change the > meaning of the prefix. Ignore this nonsense that I wrote. I’ll try to come up with a decent solution. >> You also aren’t accounting for the case where you get an exception that >> is, in turn, preempted. > > Hmm.. Can you give me an example for such an exception in my use-case? I > cannot think of an exception that might be preempted (assuming #BP, #MC > cannot be preempted). > > I agree that for super-general case this might be inappropriate.
Re: [RFC PATCH 1/5] x86: introduce preemption disable prefix
at 8:11 PM, Nadav Amit wrote: > at 6:22 PM, Andy Lutomirski wrote: > >>> On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote: >>> >>> It is sometimes beneficial to prevent preemption for very few >>> instructions, or prevent preemption for some instructions that precede >>> a branch (this latter case will be introduced in the next patches). >>> >>> To provide such functionality on x86-64, we use an empty REX-prefix >>> (opcode 0x40) as an indication that preemption is disabled for the >>> following instruction. >> >> Nifty! >> >> That being said, I think you have a few bugs. First, you can’t just ignore >> a rescheduling interrupt, as you introduce unbounded latency when this >> happens — you’re effectively emulating preempt_enable_no_resched(), which >> is not a drop-in replacement for preempt_enable(). To fix this, you may >> need to jump to a slow-path trampoline that calls schedule() at the end or >> consider rewinding one instruction instead. Or use TF, which is only a >> little bit terrifying… > > Yes, I didn’t pay enough attention here. For my use-case, I think that the > easiest solution would be to make synchronize_sched() ignore preemptions > that happen while the prefix is detected. It would slightly change the > meaning of the prefix. Ignore this nonsense that I wrote. I’ll try to come up with a decent solution. >> You also aren’t accounting for the case where you get an exception that >> is, in turn, preempted. > > Hmm.. Can you give me an example for such an exception in my use-case? I > cannot think of an exception that might be preempted (assuming #BP, #MC > cannot be preempted). > > I agree that for super-general case this might be inappropriate.
Question about mmap syscall and POSIX standard on mips arch
Hi all,
Ltp has a POSIX teatcase about mmap, 24-2.c.
https://github.com/linux-test-project/ltp/blob/e816127e5d8efbff5ae53e9c2292fae22f36838b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-2.c#L94
-part of code-
pa = mmap(addr, len, PROT_READ | PROT_WRITE, MAP_FIXED |
MAP_SHARED, fd,
0);
if (pa == MAP_FAILED && errno == ENOMEM) {
printf("Got ENOMEM: %s\nTest PASSED\n", strerror(errno));
exit(PTS_PASS);
}
-end
Under POSIX standard, the expected errno should be ENOMEM
when the specific [addr+len] exceeds the bound of memory.
But mips returns EINVAL.
https://github.com/torvalds/linux/blob/bab5c80b211035739997ebd361a679fa85b39465/arch/mips/mm/mmap.c#L69
---part of code---
if (flags & MAP_FIXED) {
/* Even MAP_FIXED mappings must reside within TASK_SIZE */
if (TASK_SIZE - len < addr)
return -EINVAL;
---end--
So, can we change EINVAL to ENOMEM to follow POSIX standard?
--Hongzhi
Question about mmap syscall and POSIX standard on mips arch
Hi all,
Ltp has a POSIX teatcase about mmap, 24-2.c.
https://github.com/linux-test-project/ltp/blob/e816127e5d8efbff5ae53e9c2292fae22f36838b/testcases/open_posix_testsuite/conformance/interfaces/mmap/24-2.c#L94
-part of code-
pa = mmap(addr, len, PROT_READ | PROT_WRITE, MAP_FIXED |
MAP_SHARED, fd,
0);
if (pa == MAP_FAILED && errno == ENOMEM) {
printf("Got ENOMEM: %s\nTest PASSED\n", strerror(errno));
exit(PTS_PASS);
}
-end
Under POSIX standard, the expected errno should be ENOMEM
when the specific [addr+len] exceeds the bound of memory.
But mips returns EINVAL.
https://github.com/torvalds/linux/blob/bab5c80b211035739997ebd361a679fa85b39465/arch/mips/mm/mmap.c#L69
---part of code---
if (flags & MAP_FIXED) {
/* Even MAP_FIXED mappings must reside within TASK_SIZE */
if (TASK_SIZE - len < addr)
return -EINVAL;
---end--
So, can we change EINVAL to ENOMEM to follow POSIX standard?
--Hongzhi
[PATCH] PCI: mediatek: Use devm_of_pci_get_host_bridge_resources() to parse DT
From: Honghui Zhang
Use the devm_of_pci_get_host_bridge_resources() API in place of the PCI OF
DT parser.
Signed-off-by: Honghui Zhang
---
drivers/pci/controller/pcie-mediatek.c | 109 +
1 file changed, 29 insertions(+), 80 deletions(-)
diff --git a/drivers/pci/controller/pcie-mediatek.c
b/drivers/pci/controller/pcie-mediatek.c
index 2a1f97c..6632d4e 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -197,29 +197,20 @@ struct mtk_pcie_port {
* @dev: pointer to PCIe device
* @base: IO mapped register base
* @free_ck: free-run reference clock
- * @io: IO resource
- * @pio: PIO resource
* @mem: non-prefetchable memory resource
- * @busn: bus range
- * @offset: IO / Memory offset
* @ports: pointer to PCIe port information
* @soc: pointer to SoC-dependent operations
+ * @busnr: root bus number
*/
struct mtk_pcie {
struct device *dev;
void __iomem *base;
struct clk *free_ck;
- struct resource io;
- struct resource pio;
struct resource mem;
- struct resource busn;
- struct {
- resource_size_t mem;
- resource_size_t io;
- } offset;
struct list_head ports;
const struct mtk_pcie_soc *soc;
+ int busnr;
};
static void mtk_pcie_subsys_powerdown(struct mtk_pcie *pcie)
@@ -1045,55 +1036,42 @@ static int mtk_pcie_setup(struct mtk_pcie *pcie)
{
struct device *dev = pcie->dev;
struct device_node *node = dev->of_node, *child;
- struct of_pci_range_parser parser;
- struct of_pci_range range;
- struct resource res;
struct mtk_pcie_port *port, *tmp;
+ struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
+ struct list_head *windows = >windows;
+ struct resource_entry *win, *tmp_win;
+ resource_size_t io_base;
int err;
- if (of_pci_range_parser_init(, node)) {
- dev_err(dev, "missing \"ranges\" property\n");
- return -EINVAL;
- }
+ err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
+ windows, _base);
+ if (err)
+ return err;
- for_each_of_pci_range(, ) {
- err = of_pci_range_to_resource(, node, );
- if (err < 0)
- return err;
+ err = devm_request_pci_bus_resources(dev, windows);
+ if (err < 0)
+ return err;
- switch (res.flags & IORESOURCE_TYPE_BITS) {
+ /* Get the I/O and memory ranges from DT */
+ resource_list_for_each_entry_safe(win, tmp_win, windows) {
+ switch (resource_type(win->res)) {
case IORESOURCE_IO:
- pcie->offset.io = res.start - range.pci_addr;
-
- memcpy(>pio, , sizeof(res));
- pcie->pio.name = node->full_name;
-
- pcie->io.start = range.cpu_addr;
- pcie->io.end = range.cpu_addr + range.size - 1;
- pcie->io.flags = IORESOURCE_MEM;
- pcie->io.name = "I/O";
-
- memcpy(, >io, sizeof(res));
- break;
-
+ err = devm_pci_remap_iospace(dev, win->res, io_base);
+ if (err) {
+ dev_warn(dev, "error %d: failed to map resource
%pR\n",
+err, win->res);
+ resource_list_destroy_entry(win);
+ }
case IORESOURCE_MEM:
- pcie->offset.mem = res.start - range.pci_addr;
-
- memcpy(>mem, , sizeof(res));
+ memcpy(>mem, win->res, sizeof(*win->res));
pcie->mem.name = "non-prefetchable";
break;
+ case IORESOURCE_BUS:
+ pcie->busnr = win->res->start;
+ break;
}
}
- err = of_pci_parse_bus_range(node, >busn);
- if (err < 0) {
- dev_err(dev, "failed to parse bus ranges property: %d\n", err);
- pcie->busn.name = node->name;
- pcie->busn.start = 0;
- pcie->busn.end = 0xff;
- pcie->busn.flags = IORESOURCE_BUS;
- }
-
for_each_available_child_of_node(node, child) {
int slot;
@@ -1125,28 +1103,6 @@ static int mtk_pcie_setup(struct mtk_pcie *pcie)
return 0;
}
-static int mtk_pcie_request_resources(struct mtk_pcie *pcie)
-{
- struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
- struct list_head *windows = >windows;
- struct device *dev = pcie->dev;
- int err;
-
- pci_add_resource_offset(windows, >pio, pcie->offset.io);
-
[PATCH] PCI: mediatek: Use devm_of_pci_get_host_bridge_resources() to parse DT
From: Honghui Zhang
Use the devm_of_pci_get_host_bridge_resources() API in place of the PCI OF
DT parser.
Signed-off-by: Honghui Zhang
---
drivers/pci/controller/pcie-mediatek.c | 109 +
1 file changed, 29 insertions(+), 80 deletions(-)
diff --git a/drivers/pci/controller/pcie-mediatek.c
b/drivers/pci/controller/pcie-mediatek.c
index 2a1f97c..6632d4e 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -197,29 +197,20 @@ struct mtk_pcie_port {
* @dev: pointer to PCIe device
* @base: IO mapped register base
* @free_ck: free-run reference clock
- * @io: IO resource
- * @pio: PIO resource
* @mem: non-prefetchable memory resource
- * @busn: bus range
- * @offset: IO / Memory offset
* @ports: pointer to PCIe port information
* @soc: pointer to SoC-dependent operations
+ * @busnr: root bus number
*/
struct mtk_pcie {
struct device *dev;
void __iomem *base;
struct clk *free_ck;
- struct resource io;
- struct resource pio;
struct resource mem;
- struct resource busn;
- struct {
- resource_size_t mem;
- resource_size_t io;
- } offset;
struct list_head ports;
const struct mtk_pcie_soc *soc;
+ int busnr;
};
static void mtk_pcie_subsys_powerdown(struct mtk_pcie *pcie)
@@ -1045,55 +1036,42 @@ static int mtk_pcie_setup(struct mtk_pcie *pcie)
{
struct device *dev = pcie->dev;
struct device_node *node = dev->of_node, *child;
- struct of_pci_range_parser parser;
- struct of_pci_range range;
- struct resource res;
struct mtk_pcie_port *port, *tmp;
+ struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
+ struct list_head *windows = >windows;
+ struct resource_entry *win, *tmp_win;
+ resource_size_t io_base;
int err;
- if (of_pci_range_parser_init(, node)) {
- dev_err(dev, "missing \"ranges\" property\n");
- return -EINVAL;
- }
+ err = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
+ windows, _base);
+ if (err)
+ return err;
- for_each_of_pci_range(, ) {
- err = of_pci_range_to_resource(, node, );
- if (err < 0)
- return err;
+ err = devm_request_pci_bus_resources(dev, windows);
+ if (err < 0)
+ return err;
- switch (res.flags & IORESOURCE_TYPE_BITS) {
+ /* Get the I/O and memory ranges from DT */
+ resource_list_for_each_entry_safe(win, tmp_win, windows) {
+ switch (resource_type(win->res)) {
case IORESOURCE_IO:
- pcie->offset.io = res.start - range.pci_addr;
-
- memcpy(>pio, , sizeof(res));
- pcie->pio.name = node->full_name;
-
- pcie->io.start = range.cpu_addr;
- pcie->io.end = range.cpu_addr + range.size - 1;
- pcie->io.flags = IORESOURCE_MEM;
- pcie->io.name = "I/O";
-
- memcpy(, >io, sizeof(res));
- break;
-
+ err = devm_pci_remap_iospace(dev, win->res, io_base);
+ if (err) {
+ dev_warn(dev, "error %d: failed to map resource
%pR\n",
+err, win->res);
+ resource_list_destroy_entry(win);
+ }
case IORESOURCE_MEM:
- pcie->offset.mem = res.start - range.pci_addr;
-
- memcpy(>mem, , sizeof(res));
+ memcpy(>mem, win->res, sizeof(*win->res));
pcie->mem.name = "non-prefetchable";
break;
+ case IORESOURCE_BUS:
+ pcie->busnr = win->res->start;
+ break;
}
}
- err = of_pci_parse_bus_range(node, >busn);
- if (err < 0) {
- dev_err(dev, "failed to parse bus ranges property: %d\n", err);
- pcie->busn.name = node->name;
- pcie->busn.start = 0;
- pcie->busn.end = 0xff;
- pcie->busn.flags = IORESOURCE_BUS;
- }
-
for_each_available_child_of_node(node, child) {
int slot;
@@ -1125,28 +1103,6 @@ static int mtk_pcie_setup(struct mtk_pcie *pcie)
return 0;
}
-static int mtk_pcie_request_resources(struct mtk_pcie *pcie)
-{
- struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
- struct list_head *windows = >windows;
- struct device *dev = pcie->dev;
- int err;
-
- pci_add_resource_offset(windows, >pio, pcie->offset.io);
-
Re: [PATCH V9 18/21] dt-bindings: csky CPU Bindings
On Wed, Oct 17, 2018 at 05:50:33PM +0200, Arnd Bergmann wrote: > On Tue, Oct 16, 2018 at 5:30 AM Guo Ren wrote: > > > > This patch adds the documentation to describe that how to add cpu nodes in > > dts for SMP. > > > > Signed-off-by: Guo Ren > > Cc: Rob Herring > > I don't see anything wrong, but I'll let Rob or some other DT maintainer > provide an Ack when they are happy. Yes, Rob help a lot for reviewing the DT-docs of csky subsystem. Thx Bob :) Best Regards Guo Ren
Re: [PATCH V9 18/21] dt-bindings: csky CPU Bindings
On Wed, Oct 17, 2018 at 05:50:33PM +0200, Arnd Bergmann wrote: > On Tue, Oct 16, 2018 at 5:30 AM Guo Ren wrote: > > > > This patch adds the documentation to describe that how to add cpu nodes in > > dts for SMP. > > > > Signed-off-by: Guo Ren > > Cc: Rob Herring > > I don't see anything wrong, but I'll let Rob or some other DT maintainer > provide an Ack when they are happy. Yes, Rob help a lot for reviewing the DT-docs of csky subsystem. Thx Bob :) Best Regards Guo Ren
Re: [PATCH V9 15/21] csky: Debug and Ptrace GDB
On Wed, Oct 17, 2018 at 05:46:56PM +0200, Arnd Bergmann wrote:
> On Tue, Oct 16, 2018 at 5:06 AM Guo Ren wrote:
> >
> > This patch adds arch ptrace implementation, stack dump and bug.h.
> >
> > Signed-off-by: Guo Ren
> > Cc: Arnd Bergmann
>
> Reviewed-by: Arnd Bergmann
>
> > diff --git a/arch/csky/include/asm/bug.h b/arch/csky/include/asm/bug.h
> > new file mode 100644
> > index 000..bd7b323
> > --- /dev/null
> > +++ b/arch/csky/include/asm/bug.h
> > @@ -0,0 +1,26 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +
> > +#ifndef __ASM_CSKY_BUG_H
> > +#define __ASM_CSKY_BUG_H
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#define BUG() \
> > +do { \
> > + asm volatile ("bkpt\n");\
> > + unreachable(); \
> > +} while (0)
>
> Since you have a breakpoint instruction, a nice addition might
> be to use that for implementing WARN_ON as well, whenever you
> get around to doing that. It's certainly not required for the initial
> merge.
Thx for remind and I'll improve it next.
Best Regards
Guo Ren
Re: [PATCH V9 15/21] csky: Debug and Ptrace GDB
On Wed, Oct 17, 2018 at 05:46:56PM +0200, Arnd Bergmann wrote:
> On Tue, Oct 16, 2018 at 5:06 AM Guo Ren wrote:
> >
> > This patch adds arch ptrace implementation, stack dump and bug.h.
> >
> > Signed-off-by: Guo Ren
> > Cc: Arnd Bergmann
>
> Reviewed-by: Arnd Bergmann
>
> > diff --git a/arch/csky/include/asm/bug.h b/arch/csky/include/asm/bug.h
> > new file mode 100644
> > index 000..bd7b323
> > --- /dev/null
> > +++ b/arch/csky/include/asm/bug.h
> > @@ -0,0 +1,26 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +
> > +#ifndef __ASM_CSKY_BUG_H
> > +#define __ASM_CSKY_BUG_H
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#define BUG() \
> > +do { \
> > + asm volatile ("bkpt\n");\
> > + unreachable(); \
> > +} while (0)
>
> Since you have a breakpoint instruction, a nice addition might
> be to use that for implementing WARN_ON as well, whenever you
> get around to doing that. It's certainly not required for the initial
> merge.
Thx for remind and I'll improve it next.
Best Regards
Guo Ren
Re: [RFC PATCH 1/5] x86: introduce preemption disable prefix
at 6:22 PM, Andy Lutomirski wrote: > >> On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote: >> >> It is sometimes beneficial to prevent preemption for very few >> instructions, or prevent preemption for some instructions that precede >> a branch (this latter case will be introduced in the next patches). >> >> To provide such functionality on x86-64, we use an empty REX-prefix >> (opcode 0x40) as an indication that preemption is disabled for the >> following instruction. > > Nifty! > > That being said, I think you have a few bugs. First, you can’t just ignore > a rescheduling interrupt, as you introduce unbounded latency when this > happens — you’re effectively emulating preempt_enable_no_resched(), which > is not a drop-in replacement for preempt_enable(). To fix this, you may > need to jump to a slow-path trampoline that calls schedule() at the end or > consider rewinding one instruction instead. Or use TF, which is only a > little bit terrifying… Yes, I didn’t pay enough attention here. For my use-case, I think that the easiest solution would be to make synchronize_sched() ignore preemptions that happen while the prefix is detected. It would slightly change the meaning of the prefix. > You also aren’t accounting for the case where you get an exception that > is, in turn, preempted. Hmm.. Can you give me an example for such an exception in my use-case? I cannot think of an exception that might be preempted (assuming #BP, #MC cannot be preempted). I agree that for super-general case this might be inappropriate.
Re: [RFC PATCH 1/5] x86: introduce preemption disable prefix
at 6:22 PM, Andy Lutomirski wrote: > >> On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote: >> >> It is sometimes beneficial to prevent preemption for very few >> instructions, or prevent preemption for some instructions that precede >> a branch (this latter case will be introduced in the next patches). >> >> To provide such functionality on x86-64, we use an empty REX-prefix >> (opcode 0x40) as an indication that preemption is disabled for the >> following instruction. > > Nifty! > > That being said, I think you have a few bugs. First, you can’t just ignore > a rescheduling interrupt, as you introduce unbounded latency when this > happens — you’re effectively emulating preempt_enable_no_resched(), which > is not a drop-in replacement for preempt_enable(). To fix this, you may > need to jump to a slow-path trampoline that calls schedule() at the end or > consider rewinding one instruction instead. Or use TF, which is only a > little bit terrifying… Yes, I didn’t pay enough attention here. For my use-case, I think that the easiest solution would be to make synchronize_sched() ignore preemptions that happen while the prefix is detected. It would slightly change the meaning of the prefix. > You also aren’t accounting for the case where you get an exception that > is, in turn, preempted. Hmm.. Can you give me an example for such an exception in my use-case? I cannot think of an exception that might be preempted (assuming #BP, #MC cannot be preempted). I agree that for super-general case this might be inappropriate.
Re: [PATCH v2 2/2] dt-bindings: uniphier: move cache-uniphier.txt to vendor directory
Hi Rob,
On Thu, Oct 18, 2018 at 5:01 AM Rob Herring wrote:
>
> On Fri, 12 Oct 2018 13:25:24 +0900, Masahiro Yamada wrote:
> > Now, the Socionext vendor directory is available at
> > Documentation/devicetree/bindings/arm/socionext/
> >
> > Move cache-uniphier.txt over to it.
> >
> > Signed-off-by: Masahiro Yamada
> > ---
> >
> > Changes in v2:
> > - New patch
> >
> > .../devicetree/bindings/arm/{uniphier => socionext}/cache-uniphier.txt
> > | 0
> > 1 file changed, 0 insertions(+), 0 deletions(-)
> > rename Documentation/devicetree/bindings/arm/{uniphier =>
> > socionext}/cache-uniphier.txt (100%)
> >
>
> Reviewed-by: Rob Herring
Thanks for your review!
You gave your Reviewed-by twice to 2/2,
but nothing to 1/2.
Is the first patch under review?
Or, did you accidentally do that
instead of replying to each of the two?
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 2/2] dt-bindings: uniphier: move cache-uniphier.txt to vendor directory
Hi Rob,
On Thu, Oct 18, 2018 at 5:01 AM Rob Herring wrote:
>
> On Fri, 12 Oct 2018 13:25:24 +0900, Masahiro Yamada wrote:
> > Now, the Socionext vendor directory is available at
> > Documentation/devicetree/bindings/arm/socionext/
> >
> > Move cache-uniphier.txt over to it.
> >
> > Signed-off-by: Masahiro Yamada
> > ---
> >
> > Changes in v2:
> > - New patch
> >
> > .../devicetree/bindings/arm/{uniphier => socionext}/cache-uniphier.txt
> > | 0
> > 1 file changed, 0 insertions(+), 0 deletions(-)
> > rename Documentation/devicetree/bindings/arm/{uniphier =>
> > socionext}/cache-uniphier.txt (100%)
> >
>
> Reviewed-by: Rob Herring
Thanks for your review!
You gave your Reviewed-by twice to 2/2,
but nothing to 1/2.
Is the first patch under review?
Or, did you accidentally do that
instead of replying to each of the two?
--
Best Regards
Masahiro Yamada
Re: [PATCH V9 13/21] csky: Library functions
On Wed, Oct 17, 2018 at 05:24:36PM +0200, Arnd Bergmann wrote:
> On Tue, Oct 16, 2018 at 5:02 AM Guo Ren wrote:
>
> > +++ b/arch/csky/lib/delay.c
> > @@ -0,0 +1,39 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +void __delay(unsigned long loops)
> > +{
> > + asm volatile (
> > + "mov r0, r0\n"
> > + "1:declt %0\n"
> > + "bf 1b"
> > + : "=r"(loops)
> > + : "0"(loops));
> > +}
> > +EXPORT_SYMBOL(__delay);
> > +
> > +void __const_udelay(unsigned long xloops)
> > +{
> > + unsigned long long loops;
> > +
> > + loops = (unsigned long long)xloops * loops_per_jiffy * HZ;
> > +
> > + __delay(loops >> 32);
> > +}
> > +EXPORT_SYMBOL(__const_udelay);
>
> I can't find any indication we discussed this part before. Can you
> explain (in the
> changelog and in a reply) if there is a reliable high-resolution clocksource
> available in the architecture? If you can read the elapsed time here instead
> of
> using the loops_per_jiffy estimate, that would make this more robust, as
> well as speed up the boot.
>
> If you can't do that in general, that's fine, and you can add my
I'll add TODO list here, __delay should use get_cycles() and we didn't
implement __udelay() __ndelay() ... We'll improve it next.
Best Regards
Guo Ren
Re: [PATCH V9 13/21] csky: Library functions
On Wed, Oct 17, 2018 at 05:24:36PM +0200, Arnd Bergmann wrote:
> On Tue, Oct 16, 2018 at 5:02 AM Guo Ren wrote:
>
> > +++ b/arch/csky/lib/delay.c
> > @@ -0,0 +1,39 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +void __delay(unsigned long loops)
> > +{
> > + asm volatile (
> > + "mov r0, r0\n"
> > + "1:declt %0\n"
> > + "bf 1b"
> > + : "=r"(loops)
> > + : "0"(loops));
> > +}
> > +EXPORT_SYMBOL(__delay);
> > +
> > +void __const_udelay(unsigned long xloops)
> > +{
> > + unsigned long long loops;
> > +
> > + loops = (unsigned long long)xloops * loops_per_jiffy * HZ;
> > +
> > + __delay(loops >> 32);
> > +}
> > +EXPORT_SYMBOL(__const_udelay);
>
> I can't find any indication we discussed this part before. Can you
> explain (in the
> changelog and in a reply) if there is a reliable high-resolution clocksource
> available in the architecture? If you can read the elapsed time here instead
> of
> using the loops_per_jiffy estimate, that would make this more robust, as
> well as speed up the boot.
>
> If you can't do that in general, that's fine, and you can add my
I'll add TODO list here, __delay should use get_cycles() and we didn't
implement __udelay() __ndelay() ... We'll improve it next.
Best Regards
Guo Ren
Re: in_compat_syscall() returns from kernel thread for X86_32.
On Wed, Oct 17, 2018 at 07:37:42PM -0700, Andy Lutomirski wrote:
> I could get on board with:
>
> ({WARN_ON_ONCE(current->flags & PF_KTHREAD); true})
>
> The point of these accessors is to be used *in a syscall*.
>
> What on Earth is Lustre doing that makes it have this problem?
Plays with timestamps from a kernel thread, perhaps?
See the old .su joke about adenoidectomy with rectal access
for possible reasons for doing it that way...
Re: in_compat_syscall() returns from kernel thread for X86_32.
On Wed, Oct 17, 2018 at 07:37:42PM -0700, Andy Lutomirski wrote:
> I could get on board with:
>
> ({WARN_ON_ONCE(current->flags & PF_KTHREAD); true})
>
> The point of these accessors is to be used *in a syscall*.
>
> What on Earth is Lustre doing that makes it have this problem?
Plays with timestamps from a kernel thread, perhaps?
See the old .su joke about adenoidectomy with rectal access
for possible reasons for doing it that way...
Re: [PATCH V9 12/21] csky: ELF and module probe
On Wed, Oct 17, 2018 at 05:18:49PM +0200, Arnd Bergmann wrote: > On Tue, Oct 16, 2018 at 5:02 AM Guo Ren wrote: > > > > This patch adds ELF definition and module relocate codes. > > > > Signed-off-by: Guo Ren > > Cc: Arnd Bergmann > > > +#ifdef __cskyBE__ > > +#define ELF_DATA ELFDATA2MSB > > +#else > > +#define ELF_DATA ELFDATA2LSB > > +#endif > > You removed support for big-endian, right? I guess the #ifdef can also > get removed here then. Aside from that, Now, we only support little-endian and it could be removed. But maybe we need support big-endian in future, so I keep it here. Best Regards Guo Ren
Re: [PATCH V9 12/21] csky: ELF and module probe
On Wed, Oct 17, 2018 at 05:18:49PM +0200, Arnd Bergmann wrote: > On Tue, Oct 16, 2018 at 5:02 AM Guo Ren wrote: > > > > This patch adds ELF definition and module relocate codes. > > > > Signed-off-by: Guo Ren > > Cc: Arnd Bergmann > > > +#ifdef __cskyBE__ > > +#define ELF_DATA ELFDATA2MSB > > +#else > > +#define ELF_DATA ELFDATA2LSB > > +#endif > > You removed support for big-endian, right? I guess the #ifdef can also > get removed here then. Aside from that, Now, we only support little-endian and it could be removed. But maybe we need support big-endian in future, so I keep it here. Best Regards Guo Ren
Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.
Sergey Senozhatsky wrote:
> On (10/17/18 12:28), Michal Hocko wrote:
> > > Michal proposed ratelimiting dump_header() [2]. But I don't think that
> > > that patch is appropriate because that patch does not ratelimit
> > >
> > > "%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl, order=%d,
> > > oom_score_adj=%hd\n"
> > > "Out of memory and no killable processes...\n"
> [..]
> > > Let's make sure that next dump_header() waits for at least 60 seconds from
> > > previous "Out of memory and no killable processes..." message.
> >
> > Could you explain why this is any better than using a well established
> > ratelimit approach?
This is essentially a ratelimit approach, roughly equivalent with:
static DEFINE_RATELIMIT_STATE(oom_no_victim_rs, 60 * HZ, 1);
oom_no_victim_rs.flags |= RATELIMIT_MSG_ON_RELEASE;
if (__ratelimit(_no_victim_rs)) {
dump_header(oc, NULL);
pr_warn("Out of memory and no killable processes...\n");
oom_no_victim_rs.begin = jiffies;
}
>
> Tetsuo, let's use a well established rate-limit approach both in
> dump_hedaer() and out_of_memory(). I actually was under impression
> that Michal added rate-limiting to both of these functions.
Honestly speaking, I wonder whether rate-limit approach helps.
Using a late-limit is a runaround at best.
The fundamental problem here is that we are doing
while (!fatal_signal_pending(current) && !(current->flags & PF_EXITING)) {
pr_warn("Help me! I can't kill somebody...\n");
cond_resched();
}
when we are under memcg OOM situation and we can't OOM-kill some process
(i.e. we can make no progress). No matter how we throttle pr_warn(), this
will keep consuming CPU resources until the memcg OOM situation is solved.
We call panic() if this is global OOM situation. But for memcg OOM situation,
we do nothing and just hope that the memcg OOM situation is solved shortly.
Until commit 3100dab2aa09dc6e ("mm: memcontrol: print proper OOM header when
no eligible victim left."), we used WARN(1) to report that we are in a bad
situation. And since syzbot happened to hit this WARN(1) with panic_on_warn ==
1,
that commit removed this WARN(1) and instead added dump_header() and pr_warn().
And then since syzbot happened to hit RCU stalls at dump_header() added by
that commit, we are trying to mitigate this problem.
But what happens if threads hitting this path are SCHED_RT priority and deprived
threads not hitting this path (e.g. administrator's console session) of all CPU
resources for doing recovery operation? We might succeed with reducing frequency
of messing up the console screens with printk(), but we might fail to solve this
memcg OOM situation after all...
>
> The appropriate rate-limit value looks like something that printk()
> should know and be able to tell to the rest of the kernel. I don't
> think that middle ground will ever be found elsewhere.
>
>
> printk() knows what consoles are registered, and printk() also knows
> (sometimes) what console="..." options the kernel was provided with.
> If baud rates ware not provided as console= options, then serial
> consoles usually use some default value. We can probably ask consoles.
>
> So *maybe* we can do something like this
>
> //
> // WARNING: this is just a sketch. A silly idea.
> // I don't know if we can make it usable.
> //
>
> ---
>
> int printk_ratelimit_interval(void)
> {
>int ret = DEFAULT_RATELIMIT_INTERVAL;
>struct tty_driver *driver = NULL;
>speed_t min_baud = MAX_INT;
>
>console_lock();
>for_each_console(c) {
>speed_t br;
>
>if (!c->device)
>continue;
>if (!(c->flags & CON_ENABLED))
>continue;
>if (!c->write)
>continue;
>driver = c->device(c, index);
>if (!driver)
>continue;
>
>br = tty_get_baud_rate(tty_driver to tty_struct [???]);
>min_baud = min(min_baud, br);
>}
>console_unlock();
>
>switch (min_baud) {
>case 115200:
>return ret;
>
>case ...blah blah...:
>return ret * 2;
>
>case 9600:
>return ret * 4;
>}
>return ret;
> }
I don't think that baud rate is relevant. Writing to console messes up
operations by console users. What matters is that we don't mess up consoles
to the level (or frequency) where console users cannot do their operations.
That is, interval between the last moment we wrote to a console and the
first moment we will write to a console for the next time matters. Roughly
speaking, remember the time stamp when we called call_console_drivers() for
the last time, and compare with that stamp before trying to call a sort of
ratelimited printk(). My patch is doing it using per call-site stamp recording.
Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.
Sergey Senozhatsky wrote:
> On (10/17/18 12:28), Michal Hocko wrote:
> > > Michal proposed ratelimiting dump_header() [2]. But I don't think that
> > > that patch is appropriate because that patch does not ratelimit
> > >
> > > "%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl, order=%d,
> > > oom_score_adj=%hd\n"
> > > "Out of memory and no killable processes...\n"
> [..]
> > > Let's make sure that next dump_header() waits for at least 60 seconds from
> > > previous "Out of memory and no killable processes..." message.
> >
> > Could you explain why this is any better than using a well established
> > ratelimit approach?
This is essentially a ratelimit approach, roughly equivalent with:
static DEFINE_RATELIMIT_STATE(oom_no_victim_rs, 60 * HZ, 1);
oom_no_victim_rs.flags |= RATELIMIT_MSG_ON_RELEASE;
if (__ratelimit(_no_victim_rs)) {
dump_header(oc, NULL);
pr_warn("Out of memory and no killable processes...\n");
oom_no_victim_rs.begin = jiffies;
}
>
> Tetsuo, let's use a well established rate-limit approach both in
> dump_hedaer() and out_of_memory(). I actually was under impression
> that Michal added rate-limiting to both of these functions.
Honestly speaking, I wonder whether rate-limit approach helps.
Using a late-limit is a runaround at best.
The fundamental problem here is that we are doing
while (!fatal_signal_pending(current) && !(current->flags & PF_EXITING)) {
pr_warn("Help me! I can't kill somebody...\n");
cond_resched();
}
when we are under memcg OOM situation and we can't OOM-kill some process
(i.e. we can make no progress). No matter how we throttle pr_warn(), this
will keep consuming CPU resources until the memcg OOM situation is solved.
We call panic() if this is global OOM situation. But for memcg OOM situation,
we do nothing and just hope that the memcg OOM situation is solved shortly.
Until commit 3100dab2aa09dc6e ("mm: memcontrol: print proper OOM header when
no eligible victim left."), we used WARN(1) to report that we are in a bad
situation. And since syzbot happened to hit this WARN(1) with panic_on_warn ==
1,
that commit removed this WARN(1) and instead added dump_header() and pr_warn().
And then since syzbot happened to hit RCU stalls at dump_header() added by
that commit, we are trying to mitigate this problem.
But what happens if threads hitting this path are SCHED_RT priority and deprived
threads not hitting this path (e.g. administrator's console session) of all CPU
resources for doing recovery operation? We might succeed with reducing frequency
of messing up the console screens with printk(), but we might fail to solve this
memcg OOM situation after all...
>
> The appropriate rate-limit value looks like something that printk()
> should know and be able to tell to the rest of the kernel. I don't
> think that middle ground will ever be found elsewhere.
>
>
> printk() knows what consoles are registered, and printk() also knows
> (sometimes) what console="..." options the kernel was provided with.
> If baud rates ware not provided as console= options, then serial
> consoles usually use some default value. We can probably ask consoles.
>
> So *maybe* we can do something like this
>
> //
> // WARNING: this is just a sketch. A silly idea.
> // I don't know if we can make it usable.
> //
>
> ---
>
> int printk_ratelimit_interval(void)
> {
>int ret = DEFAULT_RATELIMIT_INTERVAL;
>struct tty_driver *driver = NULL;
>speed_t min_baud = MAX_INT;
>
>console_lock();
>for_each_console(c) {
>speed_t br;
>
>if (!c->device)
>continue;
>if (!(c->flags & CON_ENABLED))
>continue;
>if (!c->write)
>continue;
>driver = c->device(c, index);
>if (!driver)
>continue;
>
>br = tty_get_baud_rate(tty_driver to tty_struct [???]);
>min_baud = min(min_baud, br);
>}
>console_unlock();
>
>switch (min_baud) {
>case 115200:
>return ret;
>
>case ...blah blah...:
>return ret * 2;
>
>case 9600:
>return ret * 4;
>}
>return ret;
> }
I don't think that baud rate is relevant. Writing to console messes up
operations by console users. What matters is that we don't mess up consoles
to the level (or frequency) where console users cannot do their operations.
That is, interval between the last moment we wrote to a console and the
first moment we will write to a console for the next time matters. Roughly
speaking, remember the time stamp when we called call_console_drivers() for
the last time, and compare with that stamp before trying to call a sort of
ratelimited printk(). My patch is doing it using per call-site stamp recording.
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
include/uapi/linux/kvm.h
between commits:
214ff83d4473 ("KVM: x86: hyperv: implement PV IPI send hypercalls")
0804c849f1df ("kvm/x86 : add coalesced pio support")
57b119da3594 ("KVM: nVMX: add KVM_CAP_HYPERV_ENLIGHTENED_VMCS capability")
c4f55198c7c2 ("kvm: x86: Introduce KVM_CAP_EXCEPTION_PAYLOAD")
from the kvm tree and commit:
233a7cb23531 ("kvm: arm64: Allow tuning the physical address size for VM")
from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/uapi/linux/kvm.h
index cb6d44e1fe02,95aa73ca65dc..
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -960,11 -962,7 +969,12 @@@ struct kvm_ppc_resize_hpt
#define KVM_CAP_NESTED_STATE 157
#define KVM_CAP_ARM_INJECT_SERROR_ESR 158
#define KVM_CAP_MSR_PLATFORM_INFO 159
-#define KVM_CAP_ARM_VM_IPA_SIZE 160 /* returns maximum IPA bits for a VM */
+#define KVM_CAP_PPC_NESTED_HV 160
+#define KVM_CAP_HYPERV_SEND_IPI 161
+#define KVM_CAP_COALESCED_PIO 162
+#define KVM_CAP_HYPERV_ENLIGHTENED_VMCS 163
+#define KVM_CAP_EXCEPTION_PAYLOAD 164
++#define KVM_CAP_ARM_VM_IPA_SIZE 165 /* returns maximum IPA bits for a VM */
#ifdef KVM_CAP_IRQ_ROUTING
pgpQXXaIN4xWh.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
include/uapi/linux/kvm.h
between commits:
214ff83d4473 ("KVM: x86: hyperv: implement PV IPI send hypercalls")
0804c849f1df ("kvm/x86 : add coalesced pio support")
57b119da3594 ("KVM: nVMX: add KVM_CAP_HYPERV_ENLIGHTENED_VMCS capability")
c4f55198c7c2 ("kvm: x86: Introduce KVM_CAP_EXCEPTION_PAYLOAD")
from the kvm tree and commit:
233a7cb23531 ("kvm: arm64: Allow tuning the physical address size for VM")
from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/uapi/linux/kvm.h
index cb6d44e1fe02,95aa73ca65dc..
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -960,11 -962,7 +969,12 @@@ struct kvm_ppc_resize_hpt
#define KVM_CAP_NESTED_STATE 157
#define KVM_CAP_ARM_INJECT_SERROR_ESR 158
#define KVM_CAP_MSR_PLATFORM_INFO 159
-#define KVM_CAP_ARM_VM_IPA_SIZE 160 /* returns maximum IPA bits for a VM */
+#define KVM_CAP_PPC_NESTED_HV 160
+#define KVM_CAP_HYPERV_SEND_IPI 161
+#define KVM_CAP_COALESCED_PIO 162
+#define KVM_CAP_HYPERV_ENLIGHTENED_VMCS 163
+#define KVM_CAP_EXCEPTION_PAYLOAD 164
++#define KVM_CAP_ARM_VM_IPA_SIZE 165 /* returns maximum IPA bits for a VM */
#ifdef KVM_CAP_IRQ_ROUTING
pgpQXXaIN4xWh.pgp
Description: OpenPGP digital signature
