Re: [PATCH] crypto: caam - free qman_fq after kill_fq
On 7/11/2017 9:21 AM, Xulin Sun wrote: > kill_fq removes a complete frame queue, it needs to free the qman_fq > in the last. Else kmemleak will report the below warning: > > unreferenced object 0x800073085c80 (size 128): > comm "cryptomgr_test", pid 199, jiffies 4294937850 (age 67.840s) > hex dump (first 32 bytes): > 00 00 00 00 00 00 00 00 a0 80 7e 00 00 80 ff ff > 00 00 00 00 00 00 00 00 04 00 04 00 5c 01 00 00 > backtrace: > [] create_object+0xf8/0x258 > [] kmemleak_alloc+0x58/0xa0 > [] kmem_cache_alloc_trace+0x2c8/0x358 > [] create_caam_req_fq+0x40/0x170 > [] caam_drv_ctx_update+0x54/0x248 > [] aead_setkey+0x154/0x300 > [] setkey+0x50/0xf0 > [] __test_aead+0x5ec/0x1028 > [] test_aead+0x44/0xc8 > [] alg_test_aead+0x58/0xd0 > [] alg_test+0x14c/0x308 > [] cryptomgr_test+0x50/0x58 > [] kthread+0xdc/0xf0 > [] ret_from_fork+0x10/0x50 > > And check where the function kill_fq() is called to remove > the additional kfree to qman_fq. > > Signed-off-by: Xulin Sun > --- > drivers/crypto/caam/qi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/crypto/caam/qi.c b/drivers/crypto/caam/qi.c > index 1990ed4..c4b9173 100644 > --- a/drivers/crypto/caam/qi.c > +++ b/drivers/crypto/caam/qi.c > @@ -277,6 +277,7 @@ static int kill_fq(struct device *qidev, struct qman_fq > *fq) > dev_err(qidev, "OOS of FQID: %u failed\n", fq->fqid); > > qman_destroy_fq(fq); > + kfree(fq); There is a case where kfree(fq) is executed and kill_fq() returns != 0 - that is when qman_oos_fq() returns != 0. Thus please make sure there is no reference to "fq" after kill_fq(..., fq) is called, even if kill_fq() return code is != 0. For e.g.: if (kill_fq(qidev, new_fq)) dev_warn(qidev, "New CAAM FQ: %u kill failed\n", new_fq->fqid); ^^ already kfree-ed Thanks, Horia > > return ret; > } > @@ -511,7 +512,6 @@ int caam_qi_shutdown(struct device *qidev) > > if (kill_fq(qidev, per_cpu(pcpu_qipriv.rsp_fq, i))) > dev_err(qidev, "Rsp FQ kill failed, cpu: %d\n", i); > - kfree(per_cpu(pcpu_qipriv.rsp_fq, i)); > } > > /* >
Re: [PATCH v8 1/5] [media] cec.h: Add stub function for cec_register_cec_notifier()
On 10/07/17 17:46, Jose Abreu wrote:
> Add a new stub function for cec_register_cec_notifier() so that
> we can still call this function when CONFIG_CEC_NOTIFIER and
> CONFIG_CEC_CORE are not set.
>
> Signed-off-by: Jose Abreu
> Cc: Carlos Palminha
> Cc: Hans Verkuil
> ---
> include/media/cec.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/media/cec.h b/include/media/cec.h
> index 56643b2..8357f60 100644
> --- a/include/media/cec.h
> +++ b/include/media/cec.h
> @@ -365,6 +365,14 @@ static inline int cec_phys_addr_validate(u16 phys_addr,
> u16 *parent, u16 *port)
> return 0;
> }
>
> +#ifndef CONFIG_CEC_NOTIFIER
> +struct cec_notifier;
> +static inline void cec_register_cec_notifier(struct cec_adapter *adap,
> + struct cec_notifier *notifier)
> +{
> +}
> +#endif
> +
> #endif
>
> /**
>
This isn't quite right. This function prototype needs to be moved to
cec-notifier.h.
I also saw that it isn't documented. I'll make a patch for this which will also
include
documentation.
Regards,
Hans
Re: [PATCH] mm: Mark create_huge_pmd() inline to prevent build failure
Hi Dan,
On Thu, Jul 13, 2017 at 2:29 AM, Dan Williams wrote:
> On Tue, Jul 11, 2017 at 11:57 PM, Geert Uytterhoeven
> wrote:
>> With gcc 4.1.2:
>>
>> mm/memory.o: In function `create_huge_pmd':
>> memory.c:(.text+0x93e): undefined reference to
>> `do_huge_pmd_anonymous_page'
>>
>> Converting transparent_hugepage_enabled() from a macro to a static
>> inline function reduced the ability of the compiler to remove unused
>> code.
>>
>> Fix this by marking create_huge_pmd() inline.
>>
>> Fixes: 16981d763501c0e0 ("mm: improve readability of
>> transparent_hugepage_enabled()")
>> Signed-off-by: Geert Uytterhoeven
>> ---
>> Interestingly, create_huge_pmd() is emitted in the assembler output, but
>> never called.
>> ---
>> mm/memory.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index cbb57194687e393a..0e517be91a89e162 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -3591,7 +3591,7 @@ static int do_numa_page(struct vm_fault *vmf)
>> return 0;
>> }
>>
>> -static int create_huge_pmd(struct vm_fault *vmf)
>> +static inline int create_huge_pmd(struct vm_fault *vmf)
>> {
>
> This seems fragile, what if the kernel decides to ignore the inline
> hint? If it must be inlined to avoid compile errors then it should be
> __always_inline, right?
With gcc-4, "inline" is already #define'd to
#define inline inline __attribute__((always_inline,unused)) notrace
> I also wonder if it's enough to just specify __always_inline to
> transparent_hugepage_enabled(), i.e. in case the compiler is making an
> uninlined copy of transparent_hugepage_enabled() in mm/memory.c.
Hence the answer is no.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: A udev rule to serve the change event of ACPI container?
On Thu 13-07-17 14:58:06, Joey Lee wrote: > Hi Michal, > > Sorry for my delay. > > On Tue, Jul 11, 2017 at 10:25:32AM +0200, Michal Hocko wrote: > > On Mon 26-06-17 10:59:07, Michal Hocko wrote: > > > On Mon 26-06-17 14:26:57, Joey Lee wrote: > > > > Hi all, > > > > > > > > If ACPI received ejection request for a ACPI container, kernel > > > > emits KOBJ_CHANGE uevent when it found online children devices > > > > below the acpi container. > > > > > > > > Base on the description of caa73ea15 kernel patch, user space > > > > is expected to offline all devices below the container and the > > > > container itself. Then, user space can finalize the removal of > > > > the container with the help of its ACPI device object's eject > > > > attribute in sysfs. > > > > > > > > That means that kernel relies on users space to peform the offline > > > > and ejection jobs to acpi container and children devices. The > > > > discussion is here: > > > > https://lkml.org/lkml/2013/11/28/520 > > > > > > > > The mail loop didn't explain why the userspace is responsible for > > > > the whole container offlining. Is it possible to do that transparently > > > > from the kernel? What's the difference between offlining memory and > > > > processors which happends without any cleanup and container which > > > > does essentially the same except it happens at once? > > > > > > > > - After a couple of years, can we let the container hot-remove > > > >process transparently? > > > > - Except udev rule, does there have any other mechanism to trigger > > > >auto offline/ejection? > > > > > > I would be also interested whether the kernel can simply send an udev > > > event > > > to all devices in the container. > > > > Any opinion on this? > > If BIOS emits ejection event for a ACPI0004 container, someone needs > to handle the offline/eject jobs of container. Either kernel or user > space. > > Only sending uevent to individual child device can simplify udev rule, > but it also means that the kernel needs to offline/eject container > after all children devices are offlined. Why cannot kernel send this eject command to the BIOS if the whole container is offline? If it is not then the kernel would send EBUSY to the BIOS and BIOS would have to retry after some timeout. Or is it a problem that currently implemented BIOS firmwares do not implement this retry? -- Michal Hocko SUSE Labs
Regression with suspicious RCU usage splats with cpu_pm change
Hi,
Looks like next-20170713 gives me a bunch of "suspicious RCU usage"
splats with cpuidle_coupled on duovero, see below. I bisected it down
to commit 2f027e003d05 ("cpu_pm: replace raw_notifier with
atomic_notifier").
Regards,
Tony
8< ---
=
WARNING: suspicious RCU usage
4.12.0-next-20170713+ #118 Tainted: GW
-
./include/linux/rcupdate.h:611 rcu_read_lock() used illegally while idle!
[2.928802]
other info that might help us debug this:
[2.928802]
[2.946777]
RCU used illegally from idle CPU!
rcu_scheduler_active = 2, debug_locks = 1
RCU used illegally from extended quiescent state!
1 lock held by swapper/1/0:
#0: (rcu_read_lock){..}, at: []
__atomic_notifier_call_chain+0x0/0x150
[2.975433]
stack backtrace:
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G W 4.12.0-next-20170713+
#118
Hardware name: Generic OMAP4 (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xac/0xe0)
[] (dump_stack) from []
(__atomic_notifier_call_chain+0x128/0x150)
[] (__atomic_notifier_call_chain) from []
(cpu_pm_enter+0x24/0x64)
[] (cpu_pm_enter) from []
(omap_enter_idle_coupled+0x188/0x208)
[] (omap_enter_idle_coupled) from []
(cpuidle_enter_state+0x118/0x514)
[] (cpuidle_enter_state) from []
(cpuidle_enter_state_coupled+0x3a8/0x40c)
[] (cpuidle_enter_state_coupled) from []
(do_idle+0x1a8/0x21c)
[] (do_idle) from [] (cpu_startup_entry+0x18/0x1c)
[] (cpu_startup_entry) from [<8010164c>] (0x8010164c)
[3.088043]
=
WARNING: suspicious RCU usage
4.12.0-next-20170713+ #118 Tainted: GW
-
./include/linux/rcupdate.h:611 rcu_read_lock() used illegally while idle!
[3.115661]
other info that might help us debug this:
[3.115661]
[3.123718]
RCU used illegally from idle CPU!
rcu_scheduler_active = 2, debug_locks = 1
RCU used illegally from extended quiescent state!
2 locks held by swapper/1/0:
#0: (rcu_read_lock){..}, at: []
__atomic_notifier_call_chain+0x0/0x150
#1: (rcu_read_lock){..}, at: [] __is_insn_slot_addr+0x0/0x16c
[3.161773]
stack backtrace:
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G W 4.12.0-next-20170713+
#118
Hardware name: Generic OMAP4 (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xac/0xe0)
[] (dump_stack) from [] (__is_insn_slot_addr+0x144/0x16c)
[] (__is_insn_slot_addr) from []
(kernel_text_address+0x70/0x9c)
[] (kernel_text_address) from [] (unwind_frame+0x3c/0x654)
[] (unwind_frame) from [] (unwind_backtrace+0x9c/0x120)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xac/0xe0)
[] (dump_stack) from []
(__atomic_notifier_call_chain+0x128/0x150)
[] (__atomic_notifier_call_chain) from []
(cpu_pm_enter+0x24/0x64)
[] (cpu_pm_enter) from []
(omap_enter_idle_coupled+0x188/0x208)
[] (omap_enter_idle_coupled) from []
(cpuidle_enter_state+0x118/0x514)
[] (cpuidle_enter_state) from []
(cpuidle_enter_state_coupled+0x3a8/0x40c)
[] (cpuidle_enter_state_coupled) from []
(do_idle+0x1a8/0x21c)
[] (do_idle) from [] (cpu_startup_entry+0x18/0x1c)
[] (cpu_startup_entry) from [<8010164c>] (0x8010164c)
[3.313781]
=
WARNING: suspicious RCU usage
4.12.0-next-20170713+ #118 Tainted: GW
-
./include/linux/rcupdate.h:662 rcu_read_unlock() used illegally while idle!
[3.341583]
other info that might help us debug this:
[3.341583]
[3.349639]
RCU used illegally from idle CPU!
rcu_scheduler_active = 2, debug_locks = 1
RCU used illegally from extended quiescent state!
3 locks held by swapper/1/0:
#0: (rcu_read_lock){..}, at: []
__atomic_notifier_call_chain+0x0/0x150
#1: (rcu_read_lock){..}, at: [] __is_insn_slot_addr+0x0/0x16c
#2: (rcu_read_lock){..}, at: [] __is_insn_slot_addr+0x0/0x16c
[3.395996]
stack backtrace:
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G W 4.12.0-next-20170713+
#118
Hardware name: Generic OMAP4 (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xac/0xe0)
[] (dump_stack) from [] (__is_insn_slot_addr+0x11c/0x16c)
[] (__is_insn_slot_addr) from []
(kernel_text_address+0x70/0x9c)
[] (kernel_text_address) from [] (unwind_frame+0x3c/0x654)
[] (unwind_frame) from [] (unwind_backtrace+0x9c/0x120)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xac/0xe0)
[] (dump_stack) from [] (__is_insn_slot_addr+0x144/0x16c)
[] (__is_insn_slot_addr) from []
(kernel_text_address+0x70/0x9c)
[] (kernel_text_address) from [] (unwind_frame+0x3c/0x654)
[] (unwind_frame) from [] (unwind_backtrace+0x9c/0x120)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_st
[PATCH] ASoC: hisilicon: constify snd_soc_dai_ops structure
This structure is only stored in the ops field of a snd_soc_dai_driver
structure. That field is declared const, so snd_soc_dai_ops structures
that have this property can be declared as const also.
Signed-off-by: Gustavo A. R. Silva
---
sound/soc/hisilicon/hi6210-i2s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/hisilicon/hi6210-i2s.c b/sound/soc/hisilicon/hi6210-i2s.c
index b193d3b..0c8f86d 100644
--- a/sound/soc/hisilicon/hi6210-i2s.c
+++ b/sound/soc/hisilicon/hi6210-i2s.c
@@ -517,7 +517,7 @@ static int hi6210_i2s_dai_probe(struct snd_soc_dai *dai)
}
-static struct snd_soc_dai_ops hi6210_i2s_dai_ops = {
+static const struct snd_soc_dai_ops hi6210_i2s_dai_ops = {
.trigger= hi6210_i2s_trigger,
.hw_params = hi6210_i2s_hw_params,
.set_fmt= hi6210_i2s_set_fmt,
--
2.5.0
Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)
On Wed, Jul 12, 2017 at 05:32:25PM -0500, Josh Poimboeuf wrote: > If you want perf to be able to use ORC instead of DWARF for user space > binaries, that's not currently possible, though I don't see any > technical blockers for doing so. Perf would need to be taught to read > ORC data. So the problem with userspace stuff is that the unwind data isn't readily available from NMI context. So the kernel unwinder will trigger a fault and abort. The very best we can hope for is using the EH [*] stuff that all binaries actually have _and_ map. The only problem is that most programs don't actually use the EH stuff much so while its mapped, its not actually paged in, so we're still stuck. [*] C++ ABI requires EH bits for stack unwinding for exception handling and the like, and because C++ can unwind through C code, C ABI also mandates EH bits be present. ORC doesn't much change this. What is currently an option is for perf to simply copy out the top n-Kb of the stack for each sample (talk about expensive) and then have userspace unwind it. And for userspace unwinding in userspace, libunwind and the like are fine, I see absolutely no reason to use ORC bits here.
[PATCH] ASoC: fsl_spdif: constify snd_soc_dai_ops structure
This structure is only stored in the ops field of a snd_soc_dai_driver
structure. That field is declared const, so snd_soc_dai_ops structures
that have this property can be declared as const also.
Signed-off-by: Gustavo A. R. Silva
---
sound/soc/fsl/fsl_spdif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_spdif.c b/sound/soc/fsl/fsl_spdif.c
index 1ff467c..7e6cc4d 100644
--- a/sound/soc/fsl/fsl_spdif.c
+++ b/sound/soc/fsl/fsl_spdif.c
@@ -626,7 +626,7 @@ static int fsl_spdif_trigger(struct snd_pcm_substream
*substream,
return 0;
}
-static struct snd_soc_dai_ops fsl_spdif_dai_ops = {
+static const struct snd_soc_dai_ops fsl_spdif_dai_ops = {
.startup = fsl_spdif_startup,
.hw_params = fsl_spdif_hw_params,
.trigger = fsl_spdif_trigger,
--
2.5.0
[PATCH] ASoC: fsl_esai: constify snd_soc_dai_ops structure
This structure is only stored in the ops field of a snd_soc_dai_driver
structure. That field is declared const, so snd_soc_dai_ops structures
that have this property can be declared as const also.
Signed-off-by: Gustavo A. R. Silva
---
sound/soc/fsl/fsl_esai.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 809a069..cef79a1 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -620,7 +620,7 @@ static int fsl_esai_trigger(struct snd_pcm_substream
*substream, int cmd,
return 0;
}
-static struct snd_soc_dai_ops fsl_esai_dai_ops = {
+static const struct snd_soc_dai_ops fsl_esai_dai_ops = {
.startup = fsl_esai_startup,
.shutdown = fsl_esai_shutdown,
.trigger = fsl_esai_trigger,
--
2.5.0
Re: [PATCH v2 1/4] dt-bindings: pwm-backlight: add pwm-delay-us property
Rob, 2017-07-06 20:23 GMT+02:00 Enric Balletbo Serra : > Hi Rob, > > 2017-07-06 19:07 GMT+02:00 Rob Herring : >> On Fri, Jun 30, 2017 at 6:21 AM, Enric Balletbo i Serra >> wrote: >>> From: huang lin >>> >>> Add a pwm-delay-us property to specify the delay between setting an >>> initial (non-zero) PWM value and enabling the backlight, and also the >>> delay between disabling the backlight and setting PWM value to 0. >>> >>> Signed-off-by: huang lin >>> Signed-off-by: Enric Balletbo i Serra >>> --- >>> Changes since v1: >>> - As suggested by Daniel Thompson >>>- Do not assume power-on delay and power-off delay will be the same >>> >>> v1: https://lkml.org/lkml/2017/6/28/219 >>> >>> Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt | 6 >>> ++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git >>> a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt >>> b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt >>> index 764db86..49b037e 100644 >>> --- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt >>> +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt >>> @@ -17,6 +17,11 @@ Optional properties: >>> "pwms" property (see PWM binding[0]) >>>- enable-gpios: contains a single GPIO specifier for the GPIO which >>> enables >>>and disables the backlight (see GPIO binding[1]) >>> + - pwm-delay-us: delay between setting an initial (non-zero) PWM value and >>> + enabling the backlight, and also the delay between >>> disabling >>> + the backlight and setting PWM value to 0. >>> + The 1st cell is the pre-delay in micro seconds. >>> + The 2nd cell is the post-delay in micro seconds. >> >> pre and post imply a time before and after a certain event, but these >> are for 2 different events. These are more like an enable/on delay and >> disable/off delay which probably should be separate properties. What >> happens when we need the opposite sequence or a different sequence? >> Maybe some panel requires the PWM to be 0 until some time after >> enabling. >> A second proposal, what do you think? - post-pwm-on-delay-us: Delay in us after setting an initial (non-zero) PWM and enabling the backlight using GPIO. - pwm-off-delay-us: Delay in us after disabling the backlight using a GPIO and setting PWM value to 0. Thanks, Enric > > Maybe, Only I can say that the panels I checked always first enable > the PWM and then set the ENABLE signal, but of course I didn't check > all the panels. > > Would be more acceptable have enable-delay-us and disable-delay-us > proprieties? > >> I don't understand why you even need a post delay. The PWM can be set >> to 0 while enabled, right? So if the PWM is set to 0 while enabled and >> then disable the backlight, then there's no delay. Plus this doesn't >> make much sense to me electrically either. The PWM duty cycle is going >> to be completely async to the enable line change. The PWM state could >> go from 1 to 0 at any point in time relative to the enable line >> change. >> > > To be honest I'm also not sure why is required the post delay, some > panels specify a 0 but others specifies a minimum value between you > off the panel and disable the PWM. The only reason I added the post > delay is because the different datasheets specifies it, I don't have a > use case that the post delay is used to fix something. > > Thanks, > Enric > >> These issues are the problem with generic bindings. Adding 1 property >> is no big deal, but then what happens with the next variation. These >> timing constraints need to be able to be implied by the panel's >> compatible. >> >> Rob
Re: [PATCH 1/4] perf annotate: Fix wrong --show-total-period option showing number of samples
Hi Arnaldo :)
On 07/13/2017 05:09 AM, Arnaldo Carvalho de Melo wrote:
Em Wed, Jul 12, 2017 at 07:14:04AM +0900, Taeung Song escreveu:
Currently the --show-total-period option of perf-annotate
is different from perf-report's.
For example, perf-report ordinarily shows period and number of samples.
# Overhead SamplesPeriod Command Shared Object Symbol
# ... ..
#
9.83% 102 84813704 test test[.] knapsack
But --show-total-period of perf-annotate has two problem like below:
1) Wrong column i.e. 'Percent'
2) Show number of samples, not period
So fix this option to show period instead of number of samples.
so you have multiple bugs here, please fix one per patch, i.e. if using
--show-total-period the header should not be "Percent".
Okey, I'll separate this patch.
Then, you need a patch to introduce that "struct sym_sample" and use it,
but please rename it to "struct sym_hist_entry".
I got it.
You can do it and just update the sym_hist_entry->period field, before
the change to pass 'struct sample' around.
Understood.
That disasm__calc_percent() function could receive a pointer to a struct
sym_hist_entry instead of two pointers.
Okey.
Small, self contained patches that do one thing make reviewing easier,
by yourself and others.
Yep.
Please give this a try, if you didn't understand something here I can do
it for you, as this needs doing to fix real bugs.
Thanks,
- Arnaldo
I understood what you said! I'll send v2 in accordance with your comment.
Thanks,
Taeung
Before:
Percent | Source code & Disassembly of old for cycles:ppp (102 samples)
-
:
:
:
: Disassembly of section .text:
:
: 00400816 :
: knapsack():
1 :400816: push %rbp
After:
Event count | Source code & Disassembly of old for cycles:ppp (84813704
event count)
--
:
:
:
: Disassembly of section .text:
:
: 00400816 :
: knapsack():
743737 :400816: push %rbp
Cc: Namhyung Kim
Cc: Milian Wolff
Cc: Jiri Olsa
Signed-off-by: Taeung Song
---
tools/perf/builtin-annotate.c | 4 +-
tools/perf/builtin-report.c | 13 +++---
tools/perf/builtin-top.c | 6 ++-
tools/perf/ui/browsers/annotate.c | 4 +-
tools/perf/ui/gtk/annotate.c | 4 +-
tools/perf/util/annotate.c| 92 +--
tools/perf/util/annotate.h| 12 +++--
7 files changed, 96 insertions(+), 39 deletions(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 7a5dc7e..f314661 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -177,14 +177,12 @@ static int perf_evsel__add_sample(struct perf_evsel
*evsel,
*/
process_branch_stack(sample->branch_stack, al, sample);
- sample->period = 1;
sample->weight = 1;
-
Please do not remove this line.
he = hists__add_entry(hists, al, NULL, NULL, NULL, sample, true);
if (he == NULL)
return -ENOMEM;
- ret = hist_entry__inc_addr_samples(he, evsel->idx, al->addr);
+ ret = hist_entry__inc_addr_samples(he, sample, evsel->idx, al->addr);
hists__inc_nr_samples(hists, true);
return ret;
}
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 79a33eb..5f1894c 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -113,13 +113,14 @@ static int hist_iter__report_callback(struct
hist_entry_iter *iter,
struct report *rep = arg;
struct hist_entry *he = iter->he;
struct perf_evsel *evsel = iter->evsel;
+ struct perf_sample *sample = iter->sample;
struct mem_info *mi;
struct branch_info *bi;
if (!ui__has_annotation())
return 0;
- hist__account_cycles(iter->sample->branch_stack, al, iter->sample,
+ hist__account_cycles(sample->branch_stack, al, sample,
rep->nonany_branch_mode);
if (sort__mode == SORT_MODE__BRANCH) {
@@ -136,14 +137,16 @@ static int hist_iter__report_callback(struct
hist_entry_iter *iter,
if (err)
goto out;
- err = hist_entry__inc_addr_samples(he, evsel->idx, al->addr);
+ err = hist_entry__inc_addr_samples(he, sample,
+ evsel->idx, al->addr);
why break this into two lines?
} else if (symbol_conf.cumulate_callchain) {
if (single)
-
[PATCH] ASoC: fsl_asrc: constify snd_soc_dai_ops structure
This structure is only stored in the ops field of a snd_soc_dai_driver
structure. That field is declared const, so snd_soc_dai_ops structures
that have this property can be declared as const also.
Signed-off-by: Gustavo A. R. Silva
---
sound/soc/fsl/fsl_asrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 8cfffa7..806d399 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -542,7 +542,7 @@ static int fsl_asrc_dai_trigger(struct snd_pcm_substream
*substream, int cmd,
return 0;
}
-static struct snd_soc_dai_ops fsl_asrc_dai_ops = {
+static const struct snd_soc_dai_ops fsl_asrc_dai_ops = {
.hw_params= fsl_asrc_dai_hw_params,
.hw_free = fsl_asrc_dai_hw_free,
.trigger = fsl_asrc_dai_trigger,
--
2.5.0
Re: [PATCH 2/4] perf anntoate browser: Fix the toggle total period view to show period, not number of samples
On 07/13/2017 05:10 AM, Arnaldo Carvalho de Melo wrote:
Em Wed, Jul 12, 2017 at 07:14:10AM +0900, Taeung Song escreveu:
Currently the toggle total period view on the annotate TUI
shows the number of samples, not period like below.
$ perf annotate --show-total-period
Percent│
│
│
│Disassembly of section .text:
│
│00109a90 <_mcount@@GLIBC_2.2.5>:
│ sub$0x38,%rsp
3 │ mov%rax,(%rsp)
3 │ mov%rcx,0x8(%rsp)
This output has two problem:
1) Wrong column i.e. 'Percent'
2) Show number of samples, not period
So fix the toggle total period view on the annotate TUI like below.
Event count│
│
│
│Disassembly of section .text:
│
│00109a90 <_mcount@@GLIBC_2.2.5>:
│ sub$0x38,%rsp
2204022 │ mov%rax,(%rsp)
2207405 │ mov%rcx,0x8(%rsp)
Cc: Namhyung Kim
Cc: Milian Wolff
Cc: Jiri Olsa
Signed-off-by: Taeung Song
---
tools/perf/ui/browsers/annotate.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/tools/perf/ui/browsers/annotate.c
b/tools/perf/ui/browsers/annotate.c
index 73e5ae2..0ddc3b2 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -18,6 +18,7 @@
struct disasm_line_samples {
double percent;
u64 nr;
+ u64 period;
So now this becomes a sym_hist_entry? (nr, period)
Yep!
};
#define IPC_WIDTH 6
@@ -113,6 +114,10 @@ static int annotate_browser__pcnt_width(struct
annotate_browser *ab)
if (ab->have_cycles)
w += IPC_WIDTH + CYCLES_WIDTH;
+
+ if (annotate_browser__opts.show_total_period)
+ w += 4 * ab->nr_events;
+
return w;
}
@@ -150,8 +155,8 @@ static void annotate_browser__write(struct ui_browser *browser, void *entry, int
bdl->samples[i].percent,
current_entry);
if (annotate_browser__opts.show_total_period) {
- ui_browser__printf(browser, "%6" PRIu64 " ",
- bdl->samples[i].nr);
+ ui_browser__printf(browser, "%10" PRIu64 " ",
+ bdl->samples[i].period);
} else {
ui_browser__printf(browser, "%6.2f ",
bdl->samples[i].percent);
@@ -161,9 +166,13 @@ static void annotate_browser__write(struct ui_browser
*browser, void *entry, int
ui_browser__set_percent_color(browser, 0, current_entry);
if (!show_title)
- ui_browser__write_nstring(browser, " ", 7 *
ab->nr_events);
- else
- ui_browser__printf(browser, "%*s", 7, "Percent");
+ ui_browser__write_nstring(browser, " ", pcnt_width);
+ else {
+ if (annotate_browser__opts.show_total_period)
+ ui_browser__printf(browser, "%*s", 11, "Event
count");
+ else
+ ui_browser__printf(browser, "%*s", 7,
"Percent");
+ }
}
if (ab->have_cycles) {
if (dl->ipc)
@@ -457,6 +466,7 @@ static void annotate_browser__calc_percent(struct
annotate_browser *browser,
next ? next->offset : len,
&path, &nr_samples, &period);
bpos->samples[i].nr = nr_samples;
+ bpos->samples[i].period = period;
if (max_percent < bpos->samples[i].percent)
max_percent = bpos->samples[i].percent;
--
2.7.4
Re: [PATCH] nvme: also provide a UUID in the WWID sysfs attribute
Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH v5 2/5] tick: Add freeze timer events
On Fri, Jul 07, 2017 at 05:03:00PM -0700, Derek Basehore wrote: > Adds a new feature to tick to schedule wakeups on a CPU during freeze. > This won't fully wake up the system (devices are not resumed), but > allow simple platform functionality to be run during freeze with > little power impact. > > This implementation allows an idle driver to setup a timer event with > the clock event device when entering freeze by calling > tick_set_freeze_event. Only one caller should exist for the function. > > tick_freeze_event_expired is used to check if the timer went off when > the CPU wakes. > > The event is cleared by tick_clear_freeze_event. Why? What's wrong with using the RTC stuff? RTC should be able to wake suspended systems, see RTCWAKE(8).
Re: [alsa-devel] [PATCH] ASoC: fsl_asrc: constify snd_soc_dai_ops structure
Gustavo,
please stop posting in this style. It's really annoying to see
spontaneously popping-up almost same patch for more than two hours
long.
If you have a series of the same fix patches, send them as a patch
set in a shot with a thread. git-send-email does it right.
I don't mind a couple of patches posted separately, but this is over
the limit.
thanks,
Takashi
On Thu, 13 Jul 2017 09:23:51 +0200,
Gustavo A. R. Silva wrote:
>
> This structure is only stored in the ops field of a snd_soc_dai_driver
> structure. That field is declared const, so snd_soc_dai_ops structures
> that have this property can be declared as const also.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> sound/soc/fsl/fsl_asrc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
> index 8cfffa7..806d399 100644
> --- a/sound/soc/fsl/fsl_asrc.c
> +++ b/sound/soc/fsl/fsl_asrc.c
> @@ -542,7 +542,7 @@ static int fsl_asrc_dai_trigger(struct snd_pcm_substream
> *substream, int cmd,
> return 0;
> }
>
> -static struct snd_soc_dai_ops fsl_asrc_dai_ops = {
> +static const struct snd_soc_dai_ops fsl_asrc_dai_ops = {
> .hw_params= fsl_asrc_dai_hw_params,
> .hw_free = fsl_asrc_dai_hw_free,
> .trigger = fsl_asrc_dai_trigger,
> --
> 2.5.0
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
Re: [PATCH v6 1/4] firmware: scm: Add new SCM call API for switching memory ownership
On 7/13/2017 11:24 AM, Stephen Boyd wrote:
On 07/12, Dwivedi, Avaneesh Kumar (avani) wrote:
On 7/8/2017 4:19 AM, Stephen Boyd wrote:
On 06/22, Avaneesh Kumar Dwivedi wrote:
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 6e6d561..cdfe986 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -292,6 +304,86 @@ int qcom_scm_pas_shutdown(u32 peripheral)
}
EXPORT_SYMBOL(qcom_scm_pas_shutdown);
+/**
+ * qcom_scm_assign_mem() - Make a secure call to reassign memory ownership
+ *
+ * @mem_addr: mem region whose ownership need to be reassigned
+ * @mem_sz: size of the region.
+ * @srcvm:vmid for current set of owners, each set bit in
+ *flag indicate a unique owner
+ * @newvm:array having new owners and corrsponding permission
+ *flags
+ * @dest_cnt: number of owners in next set.
+ * Return next set of owners on success.
+ */
+int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, int srcvm,
+ struct qcom_scm_vmperm *newvm, int dest_cnt)
+{
+ unsigned long dma_attrs = DMA_ATTR_FORCE_CONTIGUOUS;
Why do we need this? Just curious if we can drop this.
The force contiguous flag is required with dma_alloc_attrs() api to
allocate memory from physically contiguous zone.
I am not sure, are you saying that api will work without the
attribute or you mean i shall use some api which does not take
explicit attribute?
Does physically contiguous zone mean some CMA carveout? I wasn't
aware of a carveout for scm devices. I'm still not following the
reasoning here.
the memory will be allocated from common carveout, there is no scm
device specific
carveout. i will use dma_alloc_coherent() and will drop off this flag.
we need physical contigious zone to fill and pass scm call parameters to TZ.
I'm saying that I don't understand why we need this flag. It
feels like this sort of constraint would apply all over the scm
driver if it was true, hence the confusion.
+
+ ret = __qcom_scm_assign_mem(__scm->dev, memory_phys,
+ memory_sz, src_phys, src_sz, dest_phys, dest_sz);
+ dma_free_attrs(__scm->dev, ALIGN(mem_all_sz, SZ_64),
+ ptr, src_phys, dma_attrs);
+ if (ret == 0)
+ return next_vm;
+ else if (ret > 0)
+ return -ret;
This still confuses me. Do we really just pass whatever the
firmware tells us the error code is up to the caller? Shouldn't
we be remapping the scm errors we receive to normal linux errnos?
because i do not know in advance what exactly will be the return
error code, moreover there are number of error codes which are
returned in case of failure
so if i have to return linux error code, i can not do one to one
mapping of error code and will have to return single error code for
all failure.
let me know your comments further on this.+ return ret;
Yes, returning -EINVAL all the time is fine if we can't remap the
error. In fact, we should probably do what we do downstream and
print out the error value returned from the firmware to the
kernel log and then return some sane errno up to the caller. That
way the few people who know what the error codes mean can tell us
why the scm call failed.
OK, will do same.
just last thing to ask, should i resend all 4 patches together again or
only one patch in v7 version.
as chnage will be in only 1 out of 4 patches.
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [PATCH v2] [media] lirc_zilog: Clean up lirc zilog error codes
Almost there on the subject. Stuff between brackets is removed by git, so you should rather use something like [PATCH v2] staging: lirc: Clean up zilog error codes On Wed, Jul 12, 2017 at 9:17 PM, Yves Lemée wrote: > According the coding style guidelines, the ENOSYS error code must be returned > in case of a non existent system call. This code has been replaced with > the ENOTTY error code indicating a missing functionality. > > v2: Improved punctuation > Fixed patch subject This change info goes below the --- line and just above the diffstat. > Signed-off-by: Yves Lemée > --- > drivers/staging/media/lirc/lirc_zilog.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/staging/media/lirc/lirc_zilog.c > b/drivers/staging/media/lirc/lirc_zilog.c > index 015e41bd036e..26dd32d5b5b2 100644 > --- a/drivers/staging/media/lirc/lirc_zilog.c > +++ b/drivers/staging/media/lirc/lirc_zilog.c > @@ -1249,7 +1249,7 @@ static long ioctl(struct file *filep, unsigned int cmd, > unsigned long arg) > break; > case LIRC_GET_REC_MODE: > if (!(features & LIRC_CAN_REC_MASK)) > - return -ENOSYS; > + return -ENOTTY; > > result = put_user(LIRC_REC2MODE > (features & LIRC_CAN_REC_MASK), > @@ -1257,21 +1257,21 @@ static long ioctl(struct file *filep, unsigned int > cmd, unsigned long arg) > break; > case LIRC_SET_REC_MODE: > if (!(features & LIRC_CAN_REC_MASK)) > - return -ENOSYS; > + return -ENOTTY; > > result = get_user(mode, uptr); > if (!result && !(LIRC_MODE2REC(mode) & features)) > - result = -EINVAL; > + result = -ENOTTY; > break; > case LIRC_GET_SEND_MODE: > if (!(features & LIRC_CAN_SEND_MASK)) > - return -ENOSYS; > + return -ENOTTY; > > result = put_user(LIRC_MODE_PULSE, uptr); > break; > case LIRC_SET_SEND_MODE: > if (!(features & LIRC_CAN_SEND_MASK)) > - return -ENOSYS; > + return -ENOTTY; > > result = get_user(mode, uptr); > if (!result && mode != LIRC_MODE_PULSE) > -- > 2.13.2 > > ___ > devel mailing list > de...@linuxdriverproject.org > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [alsa-devel] [PATCH] ASoC: fsl_asrc: constify snd_soc_dai_ops structure
Hi Takashi,
Quoting Takashi Iwai :
Gustavo,
please stop posting in this style. It's really annoying to see
spontaneously popping-up almost same patch for more than two hours
long.
If you have a series of the same fix patches, send them as a patch
set in a shot with a thread. git-send-email does it right.
I will do that.
Thanks for the suggestion.
--
Gustavo A. R. Silva
I don't mind a couple of patches posted separately, but this is over
the limit.
thanks,
Takashi
On Thu, 13 Jul 2017 09:23:51 +0200,
Gustavo A. R. Silva wrote:
This structure is only stored in the ops field of a snd_soc_dai_driver
structure. That field is declared const, so snd_soc_dai_ops structures
that have this property can be declared as const also.
Signed-off-by: Gustavo A. R. Silva
---
sound/soc/fsl/fsl_asrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 8cfffa7..806d399 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -542,7 +542,7 @@ static int fsl_asrc_dai_trigger(struct
snd_pcm_substream *substream, int cmd,
return 0;
}
-static struct snd_soc_dai_ops fsl_asrc_dai_ops = {
+static const struct snd_soc_dai_ops fsl_asrc_dai_ops = {
.hw_params= fsl_asrc_dai_hw_params,
.hw_free = fsl_asrc_dai_hw_free,
.trigger = fsl_asrc_dai_trigger,
--
2.5.0
___
Alsa-devel mailing list
alsa-de...@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Re: [PATCH v2 1/4] dt-bindings: pwm-backlight: add pwm-delay-us property
On Thu 2017-07-13 09:22:15, Enric Balletbo Serra wrote: > Rob, > > 2017-07-06 20:23 GMT+02:00 Enric Balletbo Serra : > > Hi Rob, > > > > 2017-07-06 19:07 GMT+02:00 Rob Herring : > >> On Fri, Jun 30, 2017 at 6:21 AM, Enric Balletbo i Serra > >> wrote: > >>> From: huang lin > >>> > >>> Add a pwm-delay-us property to specify the delay between setting an > >>> initial (non-zero) PWM value and enabling the backlight, and also the > >>> delay between disabling the backlight and setting PWM value to 0. > >>> > >>> Signed-off-by: huang lin > >>> Signed-off-by: Enric Balletbo i Serra > >>> --- > >>> Changes since v1: > >>> - As suggested by Daniel Thompson > >>>- Do not assume power-on delay and power-off delay will be the same > >>> > >>> v1: https://lkml.org/lkml/2017/6/28/219 > >>> > >>> Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt | 6 > >>> ++ > >>> 1 file changed, 6 insertions(+) > >>> > >>> diff --git > >>> a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt > >>> b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt > >>> index 764db86..49b037e 100644 > >>> --- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt > >>> +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt > >>> @@ -17,6 +17,11 @@ Optional properties: > >>> "pwms" property (see PWM binding[0]) > >>>- enable-gpios: contains a single GPIO specifier for the GPIO which > >>> enables > >>>and disables the backlight (see GPIO binding[1]) > >>> + - pwm-delay-us: delay between setting an initial (non-zero) PWM value > >>> and > >>> + enabling the backlight, and also the delay between > >>> disabling > >>> + the backlight and setting PWM value to 0. > >>> + The 1st cell is the pre-delay in micro seconds. > >>> + The 2nd cell is the post-delay in micro seconds. > >> > >> pre and post imply a time before and after a certain event, but these > >> are for 2 different events. These are more like an enable/on delay and > >> disable/off delay which probably should be separate properties. What > >> happens when we need the opposite sequence or a different sequence? > >> Maybe some panel requires the PWM to be 0 until some time after > >> enabling. > >> > > A second proposal, what do you think? > > - post-pwm-on-delay-us: Delay in us after setting an initial (non-zero) PWM > and enabling the backlight using GPIO. This says "PWM on", "enable GPIO", "delay". Which is not what you want. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v12 5/8] virtio-balloon: VIRTIO_BALLOON_F_SG
On 07/12/2017 09:56 PM, Michael S. Tsirkin wrote:
So the way I see it, there are several issues:
- internal wait - forces multiple APIs like kick/kick_sync
note how kick_sync can fail but your code never checks return code
- need to re-write the last descriptor - might not work
for alternative layouts which always expose descriptors
immediately
Probably it wasn't clear. Please let me explain the two functions here:
1) virtqueue_add_chain_desc(vq, head_id, prev_id,..):
grabs a desc from the vq and inserts it to the chain tail (which is
indexed by
prev_id, probably better to call it tail_id). Then, the new added desc
becomes
the tail (i.e. the last desc). The _F_NEXT flag is cleared for each desc
when it's
added to the chain, and set when another desc comes to follow later.
2) virtqueue_add_chain(vq, head_id,..): expose the chain to the other end.
So, if people want to add a desc and immediately expose it to the other end,
i.e. build a single desc chain, they can just add and expose:
virtqueue_add_chain_desc(..);
virtqueue_add_chain(..,head_id);
Would you see any issues here?
- some kind of iterator type would be nicer instead of
maintaining head/prev explicitly
Why would we need to iterate the chain? I think it would be simpler to use
a wrapper struct:
struct virtqueue_desc_chain {
unsigned int head; // head desc id of the chain
unsigned int tail; // tail desc id of the chain
}
The new desc will be put to desc[tail].next, and we don't need to walk
from the head desc[head].next when inserting a new desc to the chain, right?
As for the use, it would be better to do
if (!add_next(vq, ...)) {
add_last(vq, ...)
kick
wait
}
"!add_next(vq, ...)" means that the vq is full? If so, what would
add_last() do then?
Using VIRTQUEUE_DESC_ID_INIT seems to avoid a branch in the driver, but
in fact it merely puts the branch in the virtio code.
Actually it wasn't intended to improve performance. It is used to
indicate the "init" state
of the chain. So, when virtqueue_add_chain_desc(, head_id,..) finds head
id=INIT, it will
assign the grabbed desc id to &head_id. In some sense, it is equivalent
to add_first().
Do you have a different opinion here?
Best,
Wei
Re: [RFC v5 02/38] powerpc: Free up four 64K PTE bits in 64K backed HPTE pages
On Wed, Jul 12, 2017 at 01:10:51PM +1000, Balbir Singh wrote: > On Tue, 11 Jul 2017 08:44:15 -0700 > Ram Pai wrote: > > > On Tue, Jul 11, 2017 at 03:59:59PM +1000, Balbir Singh wrote: > > > On Wed, 5 Jul 2017 14:21:39 -0700 > > > Ram Pai wrote: > > > > > > > Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6 > > > > in the 64K backed HPTE pages. This along with the earlier > > > > patch will entirely free up the four bits from 64K PTE. > > > > The bit numbers are big-endian as defined in the ISA3.0 > > > > > > > > This patch does the following change to 64K PTE backed > > > > by 64K HPTE. > > > > > > > > H_PAGE_F_SECOND (S) which occupied bit 4 moves to the > > > > second part of the pte to bit 60. > > > > H_PAGE_F_GIX (G,I,X) which occupied bit 5, 6 and 7 also > > > > moves to the second part of the pte to bit 61, > > > > 62, 63, 64 respectively > > > > > > > > since bit 7 is now freed up, we move H_PAGE_BUSY (B) from > > > > bit 9 to bit 7. > > > > > > > > The second part of the PTE will hold > > > > (H_PAGE_F_SECOND|H_PAGE_F_GIX) at bit 60,61,62,63. > > > > > > > > Before the patch, the 64K HPTE backed 64k PTE format was > > > > as follows > > > > > > > > 0 1 2 3 4 5 6 7 8 9 10...63 > > > > : : : : : : : : : : :: > > > > v v v v v v v v v v vv > > > > > > > > ,-,-,-,-,--,--,--,--,-,-,-,-,-,--,-,-,-, > > > > |x|x|x| |S |G |I |X |x|B|x|x|x||.|.|.|.| <- primary pte > > > > '_'_'_'_'__'__'__'__'_'_'_'_'_''_'_'_'_' > > > > | | | | | | | | | | | | |..| | | | | <- secondary > > > > pte > > > > '_'_'_'_'__'__'__'__'_'_'_'_'__'_'_'_'_' > > > > > > > > > > It's not entirely clear what the secondary pte contains > > > today and how many of the bits are free today? > > > > The secondary pte today is not used for anything for 64k-hpte > > backed ptes. It gets used the moment the pte gets backed by > > 4-k hptes. Till then the bits are available. And this patch > > makes use of that knowledge. > > OK.. but does this mean subpage-protection? Or do you mean > page size demotion? I presume it's the later. Yes. the later. RP
Re: [PATCH v1] spi: loopback-test: provide loop request option.
On Wed, Jul 12, 2017 at 03:40:20PM +0200, Oleksij Rempel wrote:
> From: Oleksij Rempel
>
> Provide a module parameter to request internal
> loop by the SPI master controller.
> This should make loop testing easier without extra HW modification.
>
> Signed-off-by: Oleksij Rempel
> ---
> drivers/spi/spi-loopback-test.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/spi/spi-loopback-test.c b/drivers/spi/spi-loopback-test.c
> index f4875f177df0..34e1544d7d0e 100644
> --- a/drivers/spi/spi-loopback-test.c
> +++ b/drivers/spi/spi-loopback-test.c
> @@ -51,6 +51,14 @@ MODULE_PARM_DESC(loopback,
>"is checked to match tx_buf after the spi_message "\
>"is executed");
>
> +/* the device is jumpered for loopback - enabling some rx_buf tests */
> +int loop_req;
> +module_param(loop_req, int, 0);
> +MODULE_PARM_DESC(loop_req,
> + "if set enable controller will be asked to enable "\
> + "test loop mode. If supported, MISO and MOSI will be " \
> + "jumpered by SPI controller");
> +
> /* run only a specific test */
> int run_only_test = -1;
> module_param(run_only_test, int, 0);
> @@ -313,6 +321,16 @@ static int spi_loopback_test_probe(struct spi_device
> *spi)
> {
> int ret;
>
> + if (loop_req) {
> + spi->mode = SPI_LOOP | spi->mode;
> + ret = spi_setup(spi);
> + if (ret) {
> + dev_err(&spi->dev, "SPI setup wasn't successful %d\n",
> ret);
> + dev_err(&spi->dev, "SPI_LOOP is not supported by SPI
> master.");
Why two error messages here? What about:
dev_err(&spi->dev, "SPI setup with SPI_LOOP failed (%d)\n", ret);
These lines are > 80 chars, so you should break them.
> + return -ENODEV;
return ret?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [RFC v5 14/38] powerpc: initial plumbing for key management
On Wed, Jul 12, 2017 at 01:28:25PM +1000, Balbir Singh wrote:
> On Wed, 5 Jul 2017 14:21:51 -0700
> Ram Pai wrote:
>
> > Initial plumbing to manage all the keys supported by the
> > hardware.
> >
> > Total 32 keys are supported on powerpc. However pkey 0,1
> > and 31 are reserved. So effectively we have 29 pkeys.
> >
> > This patch keeps track of reserved keys, allocated keys
> > and keys that are currently free.
>
> It looks like this patch will only work in guest mode?
> Is that an assumption we've made? What happens if I use
> keys when running in hypervisor mode?
It works in supervisor mode, as a guest aswell as a bare-metal
kernel. Whatever needs to be done in hypervisor mode
is already there in power-kvm.
>
> >
> > Also it adds skeletal functions and macros, that the
> > architecture-independent code expects to be available.
> >
> > Signed-off-by: Ram Pai
> > ---
> > arch/powerpc/Kconfig | 16 +
> > arch/powerpc/include/asm/book3s/64/mmu.h |9 +++
> > arch/powerpc/include/asm/pkeys.h | 106
> > ++
> > arch/powerpc/mm/mmu_context_book3s64.c |5 ++
> > 4 files changed, 136 insertions(+), 0 deletions(-)
> > create mode 100644 arch/powerpc/include/asm/pkeys.h
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index f7c8f99..a2480b6 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -871,6 +871,22 @@ config SECCOMP
> >
> > If unsure, say Y. Only embedded should say N here.
> >
> > +config PPC64_MEMORY_PROTECTION_KEYS
> > + prompt "PowerPC Memory Protection Keys"
> > + def_bool y
> > + # Note: only available in 64-bit mode
> > + depends on PPC64 && PPC_64K_PAGES
> > + select ARCH_USES_HIGH_VMA_FLAGS
> > + select ARCH_HAS_PKEYS
> > + ---help---
> > + Memory Protection Keys provides a mechanism for enforcing
> > + page-based protections, but without requiring modification of the
> > + page tables when an application changes protection domains.
> > +
> > + For details, see Documentation/powerpc/protection-keys.txt
> > +
> > + If unsure, say y.
> > +
> > endmenu
> >
> > config ISA_DMA_API
> > diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h
> > b/arch/powerpc/include/asm/book3s/64/mmu.h
> > index 77529a3..104ad72 100644
> > --- a/arch/powerpc/include/asm/book3s/64/mmu.h
> > +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
> > @@ -108,6 +108,15 @@ struct patb_entry {
> > #ifdef CONFIG_SPAPR_TCE_IOMMU
> > struct list_head iommu_group_mem_list;
> > #endif
> > +
> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> > + /*
> > +* Each bit represents one protection key.
> > +* bit set -> key allocated
> > +* bit unset -> key available for allocation
> > +*/
> > + u32 pkey_allocation_map;
> > +#endif
> > } mm_context_t;
> >
> > /*
> > diff --git a/arch/powerpc/include/asm/pkeys.h
> > b/arch/powerpc/include/asm/pkeys.h
> > new file mode 100644
> > index 000..9345767
> > --- /dev/null
> > +++ b/arch/powerpc/include/asm/pkeys.h
> > @@ -0,0 +1,106 @@
> > +#ifndef _ASM_PPC64_PKEYS_H
> > +#define _ASM_PPC64_PKEYS_H
> > +
> > +#define arch_max_pkey() 32
> > +#define ARCH_VM_PKEY_FLAGS (VM_PKEY_BIT0 | VM_PKEY_BIT1 | VM_PKEY_BIT2 | \
> > + VM_PKEY_BIT3 | VM_PKEY_BIT4)
> > +/*
> > + * Bits are in BE format.
> > + * NOTE: key 31, 1, 0 are not used.
> > + * key 0 is used by default. It give read/write/execute permission.
> > + * key 31 is reserved by the hypervisor.
> > + * key 1 is recommended to be not used.
> > + * PowerISA(3.0) page 1015, programming note.
> > + */
> > +#define PKEY_INITIAL_ALLOCAION 0xc001
>
> Shouldn't this be exchanged via CAS for guests? Have you seen
> ibm,processor-storage-keys?
Yes. Was one of my TODOs to initilize this using the device-tree
interface. A brief look at that did not show the reserved keys
properly enumerated. But I may be wrong.
>
> > +
> > +#define pkeybit_mask(pkey) (0x1 << (arch_max_pkey() - pkey - 1))
> > +
> > +#define mm_pkey_allocation_map(mm) (mm->context.pkey_allocation_map)
> > +
> > +#define mm_set_pkey_allocated(mm, pkey) { \
> > + mm_pkey_allocation_map(mm) |= pkeybit_mask(pkey); \
> > +}
> > +
> > +#define mm_set_pkey_free(mm, pkey) { \
> > + mm_pkey_allocation_map(mm) &= ~pkeybit_mask(pkey); \
> > +}
> > +
> > +#define mm_set_pkey_is_allocated(mm, pkey) \
> > + (mm_pkey_allocation_map(mm) & pkeybit_mask(pkey))
> > +
> > +#define mm_set_pkey_is_reserved(mm, pkey) (PKEY_INITIAL_ALLOCAION & \
> > + pkeybit_mask(pkey))
> > +
> > +static inline bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey)
> > +{
> > + /* a reserved key is never considered as 'explicitly allocated' */
> > + return (!mm_set_pkey_is_reserved(mm, pkey) &&
> > + mm_set_pkey_is_allocated(mm, pkey));
> > +}
> > +
> > +/*
> > + * Returns a positive, 5-bit key on success, or -1 on failur
Re: [PATCH 0/2] Workaround for uPD72020x USB3 chips
On 13/07/17 07:48, Ard Biesheuvel wrote: > On 13 July 2017 at 04:12, Bjorn Helgaas wrote: >> On Mon, Jul 10, 2017 at 04:52:28PM +0100, Marc Zyngier wrote: >>> Ard and myself have just spent quite some time lately trying to pin >>> down an issue in the DMA code which was taking the form of a PCIe USB3 >>> controller issuing a DMA access at some bizarre address, and being >>> caught red-handed by the IOMMU. >>> >>> After much head scratching and most of a week-end spent on tracing the >>> damn thing, I'm now convinced that the DMA code is fine, the XHCI >>> driver is correct, but that the HW (a Renesas uPD720202 chip) is a >>> nasty piece of work. >>> >>> The issue is as follow: >>> >>> - EFI initializes the controller using physical addresses above the >>> 4GB limit (this is on an arm64 box where the memory starts at >>> 0x80_...). >>> >>> - The kernel takes over, sends a XHCI reset to the controller, and >>> because we have an IOMMU sitting between the controller and memory, >>> provides *virtual* addresses. Trying to make things a bit faster for >>> our controller, it issues IOVAs in the low 4GB range). >>> >>> - Low and behold, the controller is now issuing transactions with a >>> 0x80 prefix in front of our IOVA. Yes, the same prefix that was >>> programmed during the EFI configuration. IOMMU fault, not happy. >>> >>> If the kernel is hacked to only generate IOVAs that are more than >>> 32bit wide, the HW behaves correctly. The only way I can explain this >>> behaviour is that the HW latches the top 32bit of the ERST (it is >>> always the ERST IOVA that appears in my traces) in some internal >>> register, and that the XHCI reset fails to clear it. Writing zero in >>> the top bits is not enough to clear it either. >>> >>> So far, the only solution we have for this lovely piece of kit is to >>> force a PCI reset at probe time, which puts it right. The patches are >>> pretty ugly, but that's the best I could come up with so far. >>> >>> Tested on a pair of AMD Opteron 1100 boxes with Renesas uPD720201 and >>> uPD720202 controllers. >>> >>> Marc Zyngier (2): >>> PCI: Implement pci_reset_function_locked >>> usb: host: pci_quirks: Force hard reset of Renesas uPD72020x USB >>> controller >>> >>> drivers/pci/pci.c | 35 +++ >>> drivers/usb/host/pci-quirks.c | 20 >>> drivers/usb/host/pci-quirks.h | 1 + >>> drivers/usb/host/xhci-pci.c | 7 +++ >>> include/linux/pci.h | 1 + >>> 5 files changed, 64 insertions(+) >> >> I provisionally applied this to pci/virtualization. I'd like to have an >> XHCI ack before going further, though. >> >> I assume this only affects boxes where the firmware uses addresses above >> 4GB, i.e., not very many? So this is v4.14 material? Or do you think it's >> important for v4.13? >> > > As I mentioned, it would be nice if this could at least go into v4.11 > and later, given that v4.11 contains a patch that switches all PCI > devices to 32-bit addressing only when the IOMMU is involved in DMA, > and this is what triggered the issue on arm64 boards with such a PCI > card and no DRAM below 4 GB. Agreed. It is likely that the issue will trigger on any 64bit->32bit IOVA transition, not only EFI->kernel, such as a kexec from a 4.10 to a 4.11 kernel. More importantly, this could have a dramatic effect on a system where both the 32bit and 64bit address ranges are valid. In my case, I was saved by the IOMMU blocking the DMA access, but imagine for a second the device was using PAs... I'm not sure that this is completely hypothetical, nor arm64 specific. Thanks, M. -- Jazz is not dead. It just smells funny...
Re: [PATCH] firmware: remove request_firmware_into_buf()
On Thu, Jul 13, 2017 at 01:44:34AM +0200, Luis R. Rodriguez wrote: > On Tue, Jun 27, 2017 at 10:37:11AM -0700, Bjorn Andersson wrote: > > On Mon 26 Jun 23:52 PDT 2017, Greg Kroah-Hartman wrote: > > > Why would we keep it if there is no in-tree user for it? If you want it > > > sometime in the future, great, we can revert the deletion then, but > > > keeping it around for nothing isn't ok, you know that :) > > > > > > > Of course I know that :) > > > > I did put a patch in the tubes for this yesterday [1], it's late for > > v4.13, but I would be happy to see the API stay and we would have a user > > in v4.14 (and tick this off Qualcomm's "required" list). > > > > [1] https://lkml.org/lkml/2017/6/26/693 > > Greg, > > What have you decided to do? Given that this didn't go in for 4.13-rc1, I figured it was kind of obvious, I'm waiting to see if a user shows up for this release :) And it's always trivial to revert a patch to add an api back if someone does need/want it, so this shouldn't be a big deal to anyone. > Also what is the threshold for number of drivers to use a new feature for us > to > add it? Note that there is a bundle of features queued up now and as per your > own preference it would seem you want a new API call for each new feature... Usually it's a good engineering practice to have 3 users of any interface to prove that you got the interface correct, right? But I'm not making any hard and fast rule here, let's see the patches and judge it from there... thanks, greg k-h
[PATCH 1/2] RDMA/ocrdma: Fix an error code in ocrdma_alloc_pd()
We should preserve the original "status" error code instead of resetting
it to zero. Returning ERR_PTR(0) is the same as NULL and results in a
NULL dereference in the callers. I added a printk() on error instead.
Fixes: 45e86b33ec8b ("RDMA/ocrdma: Cache recv DB until QP moved to RTR")
Signed-off-by: Dan Carpenter
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
index 2f30bda8457a..cc317e858040 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
@@ -744,7 +744,8 @@ struct ib_pd *ocrdma_alloc_pd(struct ib_device *ibdev,
if (is_uctx_pd) {
ocrdma_release_ucontext_pd(uctx);
} else {
- status = _ocrdma_dealloc_pd(dev, pd);
+ if (_ocrdma_dealloc_pd(dev, pd))
+ pr_err("%s: _ocrdma_dealloc_pd() failed\n", __func__);
}
exit:
return ERR_PTR(status);
Re: [GIT PULL] sysctl fixes for v4.13-rc1
On Thu, Jul 13, 2017 at 2:45 AM, Eric W. Biederman
wrote:
>
> Linus,
>
> Please pull the for-linus branch from the git tree:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> for-linus
>
>HEAD: 2fd1d2c4ceb2248a727696962cf3370dc9f5a0a4 proc: Fix
> proc_sys_prune_dcache to hold a sb reference
>
> A rather embarassing and hard to hit bug was merged into 4.11-rc1.
> Andrei Vagin tracked this bug now and after some starting at the
> code I came up with a fix.
>
> Eric
>
> From 2fd1d2c4ceb2248a727696962cf3370dc9f5a0a4 Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman"
> Date: Thu, 6 Jul 2017 08:41:06 -0500
> Subject: [PATCH] proc: Fix proc_sys_prune_dcache to hold a sb reference
>
> Andrei Vagin writes:
> FYI: This bug has been reproduced on 4.11.7
[...]
> Cc: sta...@vger.kernel.org
Please add first affected Linux-kernel release.
Cc: sta...@vger.kernel.org # 4.11
- Sedat -
> Reported-by: Andrei Vagin
> Tested-by: Andrei Vagin
> Fixes: ace0c791e6c3 ("proc/sysctl: Don't grab i_lock under sysctl_lock.")
> Fixes: d6cffbbe9a7e ("proc/sysctl: prune stale dentries during unregistering")
> Signed-off-by: "Eric W. Biederman"
Re: [PATCH v2 1/4] dt-bindings: pwm-backlight: add pwm-delay-us property
2017-07-13 9:39 GMT+02:00 Pavel Machek : > On Thu 2017-07-13 09:22:15, Enric Balletbo Serra wrote: >> Rob, >> >> 2017-07-06 20:23 GMT+02:00 Enric Balletbo Serra : >> > Hi Rob, >> > >> > 2017-07-06 19:07 GMT+02:00 Rob Herring : >> >> On Fri, Jun 30, 2017 at 6:21 AM, Enric Balletbo i Serra >> >> wrote: >> >>> From: huang lin >> >>> >> >>> Add a pwm-delay-us property to specify the delay between setting an >> >>> initial (non-zero) PWM value and enabling the backlight, and also the >> >>> delay between disabling the backlight and setting PWM value to 0. >> >>> >> >>> Signed-off-by: huang lin >> >>> Signed-off-by: Enric Balletbo i Serra >> >>> --- >> >>> Changes since v1: >> >>> - As suggested by Daniel Thompson >> >>>- Do not assume power-on delay and power-off delay will be the same >> >>> >> >>> v1: https://lkml.org/lkml/2017/6/28/219 >> >>> >> >>> Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt | 6 >> >>> ++ >> >>> 1 file changed, 6 insertions(+) >> >>> >> >>> diff --git >> >>> a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt >> >>> b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt >> >>> index 764db86..49b037e 100644 >> >>> --- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt >> >>> +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt >> >>> @@ -17,6 +17,11 @@ Optional properties: >> >>> "pwms" property (see PWM binding[0]) >> >>>- enable-gpios: contains a single GPIO specifier for the GPIO which >> >>> enables >> >>>and disables the backlight (see GPIO binding[1]) >> >>> + - pwm-delay-us: delay between setting an initial (non-zero) PWM value >> >>> and >> >>> + enabling the backlight, and also the delay between >> >>> disabling >> >>> + the backlight and setting PWM value to 0. >> >>> + The 1st cell is the pre-delay in micro seconds. >> >>> + The 2nd cell is the post-delay in micro seconds. >> >> >> >> pre and post imply a time before and after a certain event, but these >> >> are for 2 different events. These are more like an enable/on delay and >> >> disable/off delay which probably should be separate properties. What >> >> happens when we need the opposite sequence or a different sequence? >> >> Maybe some panel requires the PWM to be 0 until some time after >> >> enabling. >> >> >> >> A second proposal, what do you think? >> >> - post-pwm-on-delay-us: Delay in us after setting an initial (non-zero) PWM >> and enabling the backlight using GPIO. > > This says "PWM on", "enable GPIO", "delay". Which is not what you > want. > Ok, seems I need to improve a bit more my English skills. :) after -> between ? Then, if I understand correctly, this (found in another binding that I used as reference) - post-power-on-delay-ms : Delay in ms after powering the card and de-asserting the reset-gpios (if any) means, Power the card, de-asserting reset, delay ? Regards, Enric. > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[PATCH v3 2/9] clk: at91: add audio plls to the compatible list in DT binding
This new clock driver set allows to have a fractional divided clock that would generate a precise clock particularly suitable for audio applications. The main audio pll clock has two children clocks: one that is connected to the PMC, the other that can directly drive a pad. As these two routes have different enable bits and different dividers and divider formulas, they are handled by two different drivers. This adds the audio plls (frac, pad and pmc) to the compatible list of at91 clocks in DT binding. Signed-off-by: Quentin Schulz Acked-by: Rob Herring --- added in v2: - split from big patch with pll drivers and dt-binding Documentation/devicetree/bindings/clock/at91-clock.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt index 5f3ad65daf69..51c259a92d02 100644 --- a/Documentation/devicetree/bindings/clock/at91-clock.txt +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt @@ -81,6 +81,16 @@ Required properties: "atmel,sama5d2-clk-generated": at91 generated clock + "atmel,sama5d2-clk-audio-pll-frac": + at91 audio fractional pll + + "atmel,sama5d2-clk-audio-pll-pad": + at91 audio pll CLK_AUDIO output pin + + "atmel,sama5d2-clk-audio-pll-pmc" + at91 audio pll output on AUDIOPLLCLK that feeds the PMC + and can be used by peripheral clock or generic clock + Required properties for SCKC node: - reg : defines the IO memory reserved for the SCKC. - #size-cells : shall be 0 (reg is used to encode clk id). -- 2.11.0
Re: [PATCH] mm: Mark create_huge_pmd() inline to prevent build failure
On Thu, Jul 13, 2017 at 12:04 AM, Geert Uytterhoeven
wrote:
> Hi Dan,
>
> On Thu, Jul 13, 2017 at 2:29 AM, Dan Williams
> wrote:
>> On Tue, Jul 11, 2017 at 11:57 PM, Geert Uytterhoeven
>> wrote:
>>> With gcc 4.1.2:
>>>
>>> mm/memory.o: In function `create_huge_pmd':
>>> memory.c:(.text+0x93e): undefined reference to
>>> `do_huge_pmd_anonymous_page'
>>>
>>> Converting transparent_hugepage_enabled() from a macro to a static
>>> inline function reduced the ability of the compiler to remove unused
>>> code.
>>>
>>> Fix this by marking create_huge_pmd() inline.
>>>
>>> Fixes: 16981d763501c0e0 ("mm: improve readability of
>>> transparent_hugepage_enabled()")
>>> Signed-off-by: Geert Uytterhoeven
>>> ---
>>> Interestingly, create_huge_pmd() is emitted in the assembler output, but
>>> never called.
>>> ---
>>> mm/memory.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/mm/memory.c b/mm/memory.c
>>> index cbb57194687e393a..0e517be91a89e162 100644
>>> --- a/mm/memory.c
>>> +++ b/mm/memory.c
>>> @@ -3591,7 +3591,7 @@ static int do_numa_page(struct vm_fault *vmf)
>>> return 0;
>>> }
>>>
>>> -static int create_huge_pmd(struct vm_fault *vmf)
>>> +static inline int create_huge_pmd(struct vm_fault *vmf)
>>> {
>>
>> This seems fragile, what if the kernel decides to ignore the inline
>> hint? If it must be inlined to avoid compile errors then it should be
>> __always_inline, right?
>
> With gcc-4, "inline" is already #define'd to
> #define inline inline __attribute__((always_inline,unused)) notrace
Ah, ok.
Acked-by: Dan Williams
[PATCH v3 1/9] clk: at91: clk-generated: remove useless divisor loop
The driver requests the current clk rate of each of its parent clocks to
decide whether a clock rate is suitable or not. It does not request
determine_rate from a parent clock which could request a rate change in
parent clock (i.e. there is no parent rate propagation).
We know the rate we want (passed along req argument of the function) and
the parent clock rate, thus we know the closest rounded divisor, we
don't need to iterate over the available divisors to find the best one
for a given clock.
Signed-off-by: Quentin Schulz
Acked-by: Boris Brezillon
---
drivers/clk/at91/clk-generated.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/at91/clk-generated.c b/drivers/clk/at91/clk-generated.c
index f0b7ae904ce2..ef4b4e03de04 100644
--- a/drivers/clk/at91/clk-generated.c
+++ b/drivers/clk/at91/clk-generated.c
@@ -124,19 +124,18 @@ static int clk_generated_determine_rate(struct clk_hw *hw,
(gck->range.max && min_rate > gck->range.max))
continue;
- for (div = 1; div < GENERATED_MAX_DIV + 2; div++) {
- tmp_rate = DIV_ROUND_CLOSEST(parent_rate, div);
- tmp_diff = abs(req->rate - tmp_rate);
-
- if (best_diff < 0 || best_diff > tmp_diff) {
- best_rate = tmp_rate;
- best_diff = tmp_diff;
- req->best_parent_rate = parent_rate;
- req->best_parent_hw = parent;
- }
-
- if (!best_diff || tmp_rate < req->rate)
- break;
+ div = DIV_ROUND_CLOSEST(parent_rate, req->rate);
+ if (!div)
+ tmp_rate = parent_rate;
+ else
+ tmp_rate = parent_rate / div;
+ tmp_diff = abs(req->rate - tmp_rate);
+
+ if (best_diff < 0 || best_diff > tmp_diff) {
+ best_rate = tmp_rate;
+ best_diff = tmp_diff;
+ req->best_parent_rate = parent_rate;
+ req->best_parent_hw = parent;
}
if (!best_diff)
--
2.11.0
Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support
On Thu, Jul 13, 2017 at 01:13:43AM +0200, Rafael J. Wysocki wrote: > I *guess* the concern is that in the new model there is no control over the > time of requesting the frequency change and when the change actually > happens. There isn't in any case. If some brilliant hardware designer shares the regulator's I2C bus with another device that requires 'big' transfers (say a DSP) we're hosed whichever way around. > IIUC the whole point of making the governor thread an RT or DL one is to > ensure that the change will happen as soon as technically possible, because if > it doesn't happen in a specific time frame, it can very well be skipped > entirely. So I think the interrupt driven thing can actually do better than the rt-mutex based one, and I cannot think of a case where it would do worse. The I2C completion interrupt can splice in the pending request at the earliest opportunity, even though the mutex owner might still think it owns things. And if that is not possible, it'll still be as fast as waiting for the mutex to be released (or ever so slightly faster, because it will not quiesce the bus like it would otherwise at the end of a transfer).
[PATCH v3 0/9] add support for Sama5d2 audio PLLs and enable ClassD
This patch series adds support for the audio PLLs and enables ClassD that can be found in ATMEL Sama5d2 SoC. There are two audio PLLs (PMC and PAD) that shares the same parent (FRAC). FRAC can output between 620 and 700MHz and only multiply the rate of its parent. The two audio PLLs then divide the FRAC rate to best match the asked rate. I basically took an old patch series posted by Nicolas on December, 6th 2016[1][2][3] and the comments Boris did on the first version[4] Nicolas sent on July, 15th 2015. I also fixed the function used to compute the divisors, removed useless spinlocks and added a range to the audio frac PLL to stay within vendor's supported range. Clocks that are children of gclk (generated-clk) are now able to propagate rate to the audio PLL clocks when needed. However, there are multiple children clocks that could technically change the rate of audio_pll (via gck). With the rate locking introduced in Jerome Brunet's patch series[5], the first consumer to enable the clock will be the one definitely setting the rate of the clock. Without the rate locking, the last consumer to set the rate will be able to mess with the rate. Since audio IPs are most likely to request the same rate, we enforce that the only clks able to modify gck rate are those of audio IPs. To remain consistent, we deny other clocks to be children of audio_pll. Thanks, Quentin [1] https://patchwork.kernel.org/patch/9462351/ [2] https://patchwork.kernel.org/patch/9462347/ [3] https://patchwork.kernel.org/patch/9462349/ [4] https://www.spinics.net/lists/arm-kernel/msg436120.html [5] http://www.spinics.net/lists/linux-clk/msg17927.html Cyrille Pitchen (2): ARM: dts: at91: sama5d2: add classd nodes ARM: dts: at91: sama5d2_xplained: add pin muxing and enable classd Quentin Schulz (7): clk: at91: clk-generated: remove useless divisor loop clk: at91: add audio plls to the compatible list in DT binding clk: at91: add audio pll clock drivers clk: at91: clk-generated: create function to find best_diff clk: at91: clk-generated: make gclk determine audio_pll rate ASoC: atmel-classd: remove aclk clock from DT binding ASoC: atmel-classd: remove aclk clock .../devicetree/bindings/clock/at91-clock.txt | 10 + .../devicetree/bindings/sound/atmel-classd.txt | 9 +- arch/arm/boot/dts/at91-sama5d2_xplained.dts| 16 ++ arch/arm/boot/dts/sama5d2.dtsi | 39 +++- arch/arm/mach-at91/Kconfig | 4 + drivers/clk/at91/Makefile | 2 + drivers/clk/at91/clk-audio-pll-pad.c | 206 ++ drivers/clk/at91/clk-audio-pll-pmc.c | 174 +++ drivers/clk/at91/clk-audio-pll.c | 239 + drivers/clk/at91/clk-generated.c | 101 +++-- include/linux/clk/at91_pmc.h | 25 +++ sound/soc/atmel/atmel-classd.c | 47 ++-- 12 files changed, 813 insertions(+), 59 deletions(-) create mode 100644 drivers/clk/at91/clk-audio-pll-pad.c create mode 100644 drivers/clk/at91/clk-audio-pll-pmc.c create mode 100644 drivers/clk/at91/clk-audio-pll.c -- 2.11.0
[PATCH v3 9/9] ARM: dts: at91: sama5d2_xplained: add pin muxing and enable classd
From: Cyrille Pitchen
This patch adds the pin muxing for classd and enables it.
Signed-off-by: Cyrille Pitchen
Signed-off-by: Nicolas Ferre
Signed-off-by: Quentin Schulz
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 2e2c3d1a1fa2..e92b030ca45a 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -355,6 +355,14 @@
bias-pull-up;
};
+ pinctrl_classd_default: classd_default {
+ pinmux = ,
+,
+,
+;
+ bias-pull-up;
+ };
+
pinctrl_flx0_default: flx0_default {
pinmux = ,
;
@@ -488,6 +496,14 @@
};
+ classd: classd@fc048000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_classd_default>;
+ atmel,pwm-type = "diff";
+ atmel,non-overlap-time = <10>;
+ status = "okay";
+ };
+
can1: can@fc05 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_can1_default>;
--
2.11.0
[PATCH v3 8/9] ASoC: atmel-classd: remove aclk clock
Since gclk (generated-clk) is now able to determine the rate of the
audio_pll, there is no need for classd to have a direct phandle to the
audio_pll while already having a phandle to gclk.
Thus, remove all mentions to aclk in classd driver and update macros and
variable names.
Signed-off-by: Quentin Schulz
Acked-by: Mark Brown
---
added in v2:
- split from bigger patch with audio PLLs and DT binding,
- updated all variables and macros named ACLK to GCLK,
sound/soc/atmel/atmel-classd.c | 47 +-
1 file changed, 14 insertions(+), 33 deletions(-)
diff --git a/sound/soc/atmel/atmel-classd.c b/sound/soc/atmel/atmel-classd.c
index b7ef8c59b49a..be6b775b6f46 100644
--- a/sound/soc/atmel/atmel-classd.c
+++ b/sound/soc/atmel/atmel-classd.c
@@ -32,7 +32,6 @@ struct atmel_classd {
struct regmap *regmap;
struct clk *pclk;
struct clk *gclk;
- struct clk *aclk;
int irq;
const struct atmel_classd_pdata *pdata;
};
@@ -330,11 +329,6 @@ static int atmel_classd_codec_dai_startup(struct
snd_pcm_substream *substream,
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
struct atmel_classd *dd = snd_soc_card_get_drvdata(rtd->card);
- int ret;
-
- ret = clk_prepare_enable(dd->aclk);
- if (ret)
- return ret;
return clk_prepare_enable(dd->gclk);
}
@@ -357,31 +351,31 @@ static int atmel_classd_codec_dai_digital_mute(struct
snd_soc_dai *codec_dai,
return 0;
}
-#define CLASSD_ACLK_RATE_11M2896_MPY_8 (112896 * 100 * 8)
-#define CLASSD_ACLK_RATE_12M288_MPY_8 (12288 * 1000 * 8)
+#define CLASSD_GCLK_RATE_11M2896_MPY_8 (112896 * 100 * 8)
+#define CLASSD_GCLK_RATE_12M288_MPY_8 (12288 * 1000 * 8)
static struct {
int rate;
int sample_rate;
int dsp_clk;
- unsigned long aclk_rate;
+ unsigned long gclk_rate;
} const sample_rates[] = {
{ 8000, CLASSD_INTPMR_FRAME_8K,
- CLASSD_INTPMR_DSP_CLK_FREQ_12M288, CLASSD_ACLK_RATE_12M288_MPY_8 },
+ CLASSD_INTPMR_DSP_CLK_FREQ_12M288, CLASSD_GCLK_RATE_12M288_MPY_8 },
{ 16000, CLASSD_INTPMR_FRAME_16K,
- CLASSD_INTPMR_DSP_CLK_FREQ_12M288, CLASSD_ACLK_RATE_12M288_MPY_8 },
+ CLASSD_INTPMR_DSP_CLK_FREQ_12M288, CLASSD_GCLK_RATE_12M288_MPY_8 },
{ 32000, CLASSD_INTPMR_FRAME_32K,
- CLASSD_INTPMR_DSP_CLK_FREQ_12M288, CLASSD_ACLK_RATE_12M288_MPY_8 },
+ CLASSD_INTPMR_DSP_CLK_FREQ_12M288, CLASSD_GCLK_RATE_12M288_MPY_8 },
{ 48000, CLASSD_INTPMR_FRAME_48K,
- CLASSD_INTPMR_DSP_CLK_FREQ_12M288, CLASSD_ACLK_RATE_12M288_MPY_8 },
+ CLASSD_INTPMR_DSP_CLK_FREQ_12M288, CLASSD_GCLK_RATE_12M288_MPY_8 },
{ 96000, CLASSD_INTPMR_FRAME_96K,
- CLASSD_INTPMR_DSP_CLK_FREQ_12M288, CLASSD_ACLK_RATE_12M288_MPY_8 },
+ CLASSD_INTPMR_DSP_CLK_FREQ_12M288, CLASSD_GCLK_RATE_12M288_MPY_8 },
{ 22050, CLASSD_INTPMR_FRAME_22K,
- CLASSD_INTPMR_DSP_CLK_FREQ_11M2896, CLASSD_ACLK_RATE_11M2896_MPY_8 },
+ CLASSD_INTPMR_DSP_CLK_FREQ_11M2896, CLASSD_GCLK_RATE_11M2896_MPY_8 },
{ 44100, CLASSD_INTPMR_FRAME_44K,
- CLASSD_INTPMR_DSP_CLK_FREQ_11M2896, CLASSD_ACLK_RATE_11M2896_MPY_8 },
+ CLASSD_INTPMR_DSP_CLK_FREQ_11M2896, CLASSD_GCLK_RATE_11M2896_MPY_8 },
{ 88200, CLASSD_INTPMR_FRAME_88K,
- CLASSD_INTPMR_DSP_CLK_FREQ_11M2896, CLASSD_ACLK_RATE_11M2896_MPY_8 },
+ CLASSD_INTPMR_DSP_CLK_FREQ_11M2896, CLASSD_GCLK_RATE_11M2896_MPY_8 },
};
static int
@@ -410,13 +404,12 @@ atmel_classd_codec_dai_hw_params(struct snd_pcm_substream
*substream,
}
dev_dbg(codec->dev,
- "Selected SAMPLE_RATE of %dHz, ACLK_RATE of %ldHz\n",
- sample_rates[best].rate, sample_rates[best].aclk_rate);
+ "Selected SAMPLE_RATE of %dHz, GCLK_RATE of %ldHz\n",
+ sample_rates[best].rate, sample_rates[best].gclk_rate);
clk_disable_unprepare(dd->gclk);
- clk_disable_unprepare(dd->aclk);
- ret = clk_set_rate(dd->aclk, sample_rates[best].aclk_rate);
+ ret = clk_set_rate(dd->gclk, sample_rates[best].gclk_rate);
if (ret)
return ret;
@@ -426,10 +419,6 @@ atmel_classd_codec_dai_hw_params(struct snd_pcm_substream
*substream,
snd_soc_update_bits(codec, CLASSD_INTPMR, mask, val);
- ret = clk_prepare_enable(dd->aclk);
- if (ret)
- return ret;
-
return clk_prepare_enable(dd->gclk);
}
@@ -441,7 +430,6 @@ atmel_classd_codec_dai_shutdown(struct snd_pcm_substream
*substream,
struct atmel_classd *dd = snd_soc_card_get_drvdata(rtd->card);
clk_disable_unprepare(dd->gclk);
- clk_disable_unprepare(dd->aclk);
}
static int atmel_classd_codec_dai_prepare(struct snd_pcm_substream *substream,
@@ -596,13 +584,6 @@ static int atmel_classd_probe(struct platform_device *pdev)
return ret;
}
- dd->aclk = devm_clk_get(dev
[PATCH v3 6/9] clk: at91: clk-generated: make gclk determine audio_pll rate
This allows gclk to determine audio_pll rate and set the parent rate
accordingly.
However, there are multiple children clocks that could technically
change the rate of audio_pll (via gck). With the rate locking, the first
consumer to enable the clock will be the one definitely setting the rate
of the clock.
Since audio IPs are most likely to request the same rate, we enforce
that the only clks able to modify gck rate are those of audio IPs.
To remain consistent, we deny other clocks to be children of audio_pll.
Signed-off-by: Quentin Schulz
Acked-by: Boris Brezillon
---
v3:
- added a flag per generated clock to know which one is allowed to
modify audio_pll rate,
- set the flag in setup function depending on the compatible and the
clock ID,
v2:
- added conditions for audio pll rate setting restriction for SSC and
I2S,
drivers/clk/at91/clk-generated.c | 63
1 file changed, 57 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/at91/clk-generated.c b/drivers/clk/at91/clk-generated.c
index 7260e498e059..33481368740e 100644
--- a/drivers/clk/at91/clk-generated.c
+++ b/drivers/clk/at91/clk-generated.c
@@ -26,6 +26,13 @@
#define GENERATED_SOURCE_MAX 6
#define GENERATED_MAX_DIV 255
+#define GCK_ID_SSC043
+#define GCK_ID_SSC144
+#define GCK_ID_I2S054
+#define GCK_ID_I2S155
+#define GCK_ID_CLASSD 59
+#define GCK_INDEX_DT_AUDIO_PLL 5
+
struct clk_generated {
struct clk_hw hw;
struct regmap *regmap;
@@ -34,6 +41,7 @@ struct clk_generated {
u32 id;
u32 gckdiv;
u8 parent_id;
+ bool audio_pll_allowed;
};
#define to_clk_generated(hw) \
@@ -126,15 +134,14 @@ static int clk_generated_determine_rate(struct clk_hw *hw,
{
struct clk_generated *gck = to_clk_generated(hw);
struct clk_hw *parent = NULL;
+ struct clk_rate_request req_parent = *req;
long best_rate = -EINVAL;
- unsigned long min_rate;
+ unsigned long min_rate, parent_rate;
int best_diff = -1;
int i;
+ u32 div;
- for (i = 0; i < clk_hw_get_num_parents(hw); i++) {
- u32 div;
- unsigned long parent_rate;
-
+ for (i = 0; i < clk_hw_get_num_parents(hw) - 1; i++) {
parent = clk_hw_get_parent_by_index(hw, i);
if (!parent)
continue;
@@ -150,11 +157,38 @@ static int clk_generated_determine_rate(struct clk_hw *hw,
clk_generated_best_diff(req, parent, parent_rate, div,
&best_diff, &best_rate);
+ if (!best_diff)
+ break;
+ }
+
+ /*
+* The audio_pll rate can be modified, unlike the five others clocks
+* that should never be altered.
+* The audio_pll can technically be used by multiple consumers. However,
+* with the rate locking, the first consumer to enable to clock will be
+* the one definitely setting the rate of the clock.
+* Since audio IPs are most likely to request the same rate, we enforce
+* that the only clks able to modify gck rate are those of audio IPs.
+*/
+
+ if (!gck->audio_pll_allowed)
+ goto end;
+
+ parent = clk_hw_get_parent_by_index(hw, GCK_INDEX_DT_AUDIO_PLL);
+ if (!parent)
+ goto end;
+
+ for (div = 1; div < GENERATED_MAX_DIV + 2; div++) {
+ req_parent.rate = req->rate * div;
+ __clk_determine_rate(parent, &req_parent);
+ clk_generated_best_diff(req, parent, req_parent.rate, div,
+ &best_diff, &best_rate);
if (!best_diff)
break;
}
+end:
pr_debug("GCLK: %s, best_rate = %ld, parent clk: %s @ %ld\n",
__func__, best_rate,
__clk_get_name((req->best_parent_hw)->clk),
@@ -264,7 +298,8 @@ at91_clk_register_generated(struct regmap *regmap,
spinlock_t *lock,
init.ops = &generated_ops;
init.parent_names = parent_names;
init.num_parents = num_parents;
- init.flags = CLK_SET_RATE_GATE | CLK_SET_PARENT_GATE;
+ init.flags = CLK_SET_RATE_GATE | CLK_SET_PARENT_GATE |
+ CLK_SET_RATE_PARENT;
gck->id = id;
gck->hw.init = &init;
@@ -296,6 +331,7 @@ static void __init of_sama5d2_clk_generated_setup(struct
device_node *np)
struct device_node *gcknp;
struct clk_range range = CLK_RANGE(0, 0);
struct regmap *regmap;
+ struct clk_generated *gck;
num_parents = of_clk_get_parent_count(np);
if (num_parents == 0 || num_parents > GENERATED_SOURCE_MAX)
@@ -327,6 +363,21 @@ static void __init of_sama5d2_clk_generated_setup(struct
device_node *np)
hw = at91_clk_register_generated(regmap, &pmc_pcr_lock, name,
[PATCH v3 7/9] ASoC: atmel-classd: remove aclk clock from DT binding
Since gclk (generated-clk) is now able to determine the rate of the
audio_pll, there is no need for classd to have a direct phandle to the
audio_pll while already having a phandle to gclk.
This binding is used by no board in mainline so it is safe to be
modified.
Signed-off-by: Quentin Schulz
Acked-by: Mark Brown
Acked-by: Rob Herring
---
added in v2
Documentation/devicetree/bindings/sound/atmel-classd.txt | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/atmel-classd.txt
b/Documentation/devicetree/bindings/sound/atmel-classd.txt
index 549e701cb7a1..898551076382 100644
--- a/Documentation/devicetree/bindings/sound/atmel-classd.txt
+++ b/Documentation/devicetree/bindings/sound/atmel-classd.txt
@@ -13,13 +13,11 @@ Required properties:
Must be "tx".
- clock-names
Tuple listing input clock names.
- Required elements: "pclk", "gclk" and "aclk".
+ Required elements: "pclk" and "gclk".
- clocks
Please refer to clock-bindings.txt.
- assigned-clocks
Should be <&classd_gclk>.
-- assigned-clock-parents
- Should be <&audio_pll_pmc>.
Optional properties:
- pinctrl-names, pinctrl-0
@@ -45,10 +43,9 @@ classd: classd@fc048000 {
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(47))>;
dma-names = "tx";
- clocks = <&classd_clk>, <&classd_gclk>, <&audio_pll_pmc>;
- clock-names = "pclk", "gclk", "aclk";
+ clocks = <&classd_clk>, <&classd_gclk>;
+ clock-names = "pclk", "gclk";
assigned-clocks = <&classd_gclk>;
- assigned-clock-parents = <&audio_pll_pmc>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_classd_default>;
--
2.11.0
[PATCH v3 3/9] clk: at91: add audio pll clock drivers
This new clock driver set allows to have a fractional divided clock that
would generate a precise clock particularly suitable for audio
applications.
The main audio pll clock has two children clocks: one that is connected
to the PMC, the other that can directly drive a pad. As these two routes
have different enable bits and different dividers and divider formulas,
they are handled by two different drivers. Each of them could modify the
rate of the main audio pll parent.
The main audio pll clock can output 620MHz to 700MHz.
Signed-off-by: Nicolas Ferre
Signed-off-by: Quentin Schulz
---
v2:
- split DT binding in a different patch,
- removed unused AUDIO_PLL_*FOUT* defines from clk-audio-pll-pmc,
- split classD modifications in a different patch,
arch/arm/mach-at91/Kconfig | 4 +
drivers/clk/at91/Makefile| 2 +
drivers/clk/at91/clk-audio-pll-pad.c | 206 ++
drivers/clk/at91/clk-audio-pll-pmc.c | 174 +
drivers/clk/at91/clk-audio-pll.c | 239 +++
include/linux/clk/at91_pmc.h | 25
6 files changed, 650 insertions(+)
create mode 100644 drivers/clk/at91/clk-audio-pll-pad.c
create mode 100644 drivers/clk/at91/clk-audio-pll-pmc.c
create mode 100644 drivers/clk/at91/clk-audio-pll.c
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index d735e5fc4772..9ae14d59a9ce 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -26,6 +26,7 @@ config SOC_SAMA5D2
select HAVE_AT91_USB_CLK
select HAVE_AT91_H32MX
select HAVE_AT91_GENERATED_CLK
+ select HAVE_AT91_AUDIO_PLL
select PINCTRL_AT91PIO4
help
Select this if ou are using one of Atmel's SAMA5D2 family SoC.
@@ -125,6 +126,9 @@ config HAVE_AT91_H32MX
config HAVE_AT91_GENERATED_CLK
bool
+config HAVE_AT91_AUDIO_PLL
+ bool
+
config SOC_SAM_V4_V5
bool
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 13e67bd35cff..c9353d17763a 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -6,6 +6,8 @@ obj-y += pmc.o sckc.o
obj-y += clk-slow.o clk-main.o clk-pll.o clk-plldiv.o clk-master.o
obj-y += clk-system.o clk-peripheral.o clk-programmable.o
+obj-$(CONFIG_HAVE_AT91_AUDIO_PLL) += clk-audio-pll.o
+obj-$(CONFIG_HAVE_AT91_AUDIO_PLL) += clk-audio-pll-pmc.o
clk-audio-pll-pad.o
obj-$(CONFIG_HAVE_AT91_UTMI) += clk-utmi.o
obj-$(CONFIG_HAVE_AT91_USB_CLK)+= clk-usb.o
obj-$(CONFIG_HAVE_AT91_SMD)+= clk-smd.o
diff --git a/drivers/clk/at91/clk-audio-pll-pad.c
b/drivers/clk/at91/clk-audio-pll-pad.c
new file mode 100644
index ..10dd6d625696
--- /dev/null
+++ b/drivers/clk/at91/clk-audio-pll-pad.c
@@ -0,0 +1,206 @@
+/*
+ * Copyright (C) 2016 Atmel Corporation,
+ * Nicolas Ferre
+ * Copyright (C) 2017 Free Electrons,
+ *Quentin Schulz
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pmc.h"
+
+/*
+ * DOC: PAD output for fractional PLL clock for audio
+ *
+ * Traits of this clock:
+ * enable - clk_enable writes divisors and enables PAD output
+ * rate - rate is adjustable.
+ *clk->rate = parent->rate / (qdaudio * div))
+ * parent - fixed parent. No clk_set_parent support
+ */
+
+#define AUDIO_PLL_QDPAD(qd, div) ((AT91_PMC_AUDIO_PLL_QDPAD_EXTDIV(qd) &
\
+ AT91_PMC_AUDIO_PLL_QDPAD_EXTDIV_MASK)
| \
+(AT91_PMC_AUDIO_PLL_QDPAD_DIV(div) & \
+ AT91_PMC_AUDIO_PLL_QDPAD_DIV_MASK))
+
+struct clk_audio_pad {
+ struct clk_hw hw;
+ struct regmap *regmap;
+ u8 qdaudio;
+ u8 div;
+};
+
+#define to_clk_audio_pad(hw) container_of(hw, struct clk_audio_pad, hw)
+
+static int clk_audio_pll_pad_enable(struct clk_hw *hw)
+{
+ struct clk_audio_pad *apad_ck = to_clk_audio_pad(hw);
+
+ regmap_update_bits(apad_ck->regmap, AT91_PMC_AUDIO_PLL1,
+ AT91_PMC_AUDIO_PLL_QDPAD_MASK,
+ AUDIO_PLL_QDPAD(apad_ck->qdaudio, apad_ck->div));
+ regmap_update_bits(apad_ck->regmap, AT91_PMC_AUDIO_PLL0,
+ AT91_PMC_AUDIO_PLL_PADEN, AT91_PMC_AUDIO_PLL_PADEN);
+
+ return 0;
+}
+
+static void clk_audio_pll_pad_disable(struct clk_hw *hw)
+{
+ struct clk_audio_pad *apad_ck = to_clk_audio_pad(hw);
+
+ regmap_update_bits(apad_ck->regmap, AT91_PMC_AUDIO_PLL0,
+ AT91_PMC_AUDIO_PLL_PADEN, 0);
+}
+
+static unsigned long clk_audio_pll_pad_recalc_rate(s
[PATCH v3 4/9] ARM: dts: at91: sama5d2: add classd nodes
From: Cyrille Pitchen
This patch adds nodes for the classd device and its generated clock.
Signed-off-by: Cyrille Pitchen
Signed-off-by: Nicolas Ferre
Signed-off-by: Quentin Schulz
---
arch/arm/boot/dts/sama5d2.dtsi | 39 ++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index cc06da394366..a564cd1ba327 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -494,6 +494,24 @@
clocks = <&plla>;
};
+ audio_pll_frac: audiopll_fracck {
+ compatible =
"atmel,sama5d2-clk-audio-pll-frac";
+ #clock-cells = <0>;
+ clocks = <&main>;
+ };
+
+ audio_pll_pad: audiopll_padck {
+ compatible =
"atmel,sama5d2-clk-audio-pll-pad";
+ #clock-cells = <0>;
+ clocks = <&audio_pll_frac>;
+ };
+
+ audio_pll_pmc: audiopll_pmcck {
+ compatible =
"atmel,sama5d2-clk-audio-pll-pmc";
+ #clock-cells = <0>;
+ clocks = <&audio_pll_frac>;
+ };
+
utmi: utmick {
compatible =
"atmel,at91sam9x5-clk-utmi";
#clock-cells = <0>;
@@ -895,7 +913,7 @@
#address-cells = <1>;
#size-cells = <0>;
interrupt-parent = <&pmc>;
- clocks = <&clk32k>, <&main>,
<&plladiv>, <&utmi>, <&mck>;
+ clocks = <&clk32k>, <&main>,
<&plladiv>, <&utmi>, <&mck>, <&audio_pll_pmc>;
sdmmc0_gclk: sdmmc0_gclk {
#clock-cells = <0>;
@@ -951,6 +969,12 @@
reg = <57>;
atmel,clk-output-range = <0
8000>;
};
+
+ classd_gclk: classd_gclk {
+ #clock-cells = <0>;
+ reg = <59>;
+ atmel,clk-output-range = <0
1>;
+ };
};
};
@@ -1406,6 +1430,19 @@
status = "okay";
};
+ classd: classd@fc048000 {
+ compatible = "atmel,sama5d2-classd";
+ reg = <0xfc048000 0x100>;
+ interrupts = <59 IRQ_TYPE_LEVEL_HIGH 7>;
+ dmas = <&dma0
+ (AT91_XDMAC_DT_MEM_IF(0) |
AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(47))>;
+ dma-names = "tx";
+ clocks = <&classd_clk>, <&classd_gclk>;
+ clock-names = "pclk", "gclk";
+ status = "disabled";
+ };
+
can1: can@fc05 {
compatible = "bosch,m_can";
reg = <0xfc05 0x4000>, <0x21 0x4000>;
--
2.11.0
[PATCH v3 5/9] clk: at91: clk-generated: create function to find best_diff
The way to find the best_diff and do the appropriate process afterwards
can be re-used.
This patch prepares the driver for an upcoming patch that will allow
clk_generated to determine the rate of the audio_pll.
Signed-off-by: Quentin Schulz
Acked-by: Boris Brezillon
---
drivers/clk/at91/clk-generated.c | 41 ++--
1 file changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/at91/clk-generated.c b/drivers/clk/at91/clk-generated.c
index ef4b4e03de04..7260e498e059 100644
--- a/drivers/clk/at91/clk-generated.c
+++ b/drivers/clk/at91/clk-generated.c
@@ -99,15 +99,36 @@ clk_generated_recalc_rate(struct clk_hw *hw,
return DIV_ROUND_CLOSEST(parent_rate, gck->gckdiv + 1);
}
+static void clk_generated_best_diff(struct clk_rate_request *req,
+ struct clk_hw *parent,
+ unsigned long parent_rate, u32 div,
+ int *best_diff, long *best_rate)
+{
+ unsigned long tmp_rate;
+ int tmp_diff;
+
+ if (!div)
+ tmp_rate = parent_rate;
+ else
+ tmp_rate = parent_rate / div;
+ tmp_diff = abs(req->rate - tmp_rate);
+
+ if (*best_diff < 0 || *best_diff > tmp_diff) {
+ *best_rate = tmp_rate;
+ *best_diff = tmp_diff;
+ req->best_parent_rate = parent_rate;
+ req->best_parent_hw = parent;
+ }
+}
+
static int clk_generated_determine_rate(struct clk_hw *hw,
struct clk_rate_request *req)
{
struct clk_generated *gck = to_clk_generated(hw);
struct clk_hw *parent = NULL;
long best_rate = -EINVAL;
- unsigned long tmp_rate, min_rate;
+ unsigned long min_rate;
int best_diff = -1;
- int tmp_diff;
int i;
for (i = 0; i < clk_hw_get_num_parents(hw); i++) {
@@ -125,18 +146,10 @@ static int clk_generated_determine_rate(struct clk_hw *hw,
continue;
div = DIV_ROUND_CLOSEST(parent_rate, req->rate);
- if (!div)
- tmp_rate = parent_rate;
- else
- tmp_rate = parent_rate / div;
- tmp_diff = abs(req->rate - tmp_rate);
-
- if (best_diff < 0 || best_diff > tmp_diff) {
- best_rate = tmp_rate;
- best_diff = tmp_diff;
- req->best_parent_rate = parent_rate;
- req->best_parent_hw = parent;
- }
+
+ clk_generated_best_diff(req, parent, parent_rate, div,
+ &best_diff, &best_rate);
+
if (!best_diff)
break;
--
2.11.0
[PATCH] rbd: Fix uninitialized variable use in rbd_acquire_lock
drivers/block/rbd.c: In function 'rbd_acquire_lock':
drivers/block/rbd.c:3602:44: error: 'ret' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
Silence the warning, found it when built old kernel(3.10) with
OBS(opensuse build service).
Signed-off-by: Kefeng Wang
---
drivers/block/rbd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index b008b6a..b640ad8 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -3435,7 +3435,7 @@ static void rbd_acquire_lock(struct work_struct *work)
struct rbd_device *rbd_dev = container_of(to_delayed_work(work),
struct rbd_device, lock_dwork);
enum rbd_lock_state lock_state;
- int ret;
+ int ret = 0;
dout("%s rbd_dev %p\n", __func__, rbd_dev);
again:
--
1.7.12.4
Re: [PATCH v2] clk: fractional-divider: fix up the fractional clk's jitter
On 07/10/2017 07:05 PM, Heiko Stuebner wrote:
Hi Elaine,
Am Freitag, 7. Juli 2017, 10:52:23 CEST schrieb Elaine Zhang:
add clk_fractional_divider_special_ops for rockchip specific requirements,
fractional divider must set that denominator is 20 times larger than
numerator to generate precise clock frequency.
Otherwise the CLK jitter is very big, poor quality of the clock signal.
RK document description:
3.1.9 Fractional divider usage
To get specific frequency, clocks of I2S, SPDIF, UARTcan be generated by
fractional divider. Generally you must set that denominator is 20 times
larger than numerator to generate precise clock frequency. So the
fractional divider applies only to generate low frequency clock like
I2S, UART.igned-off-by: Elaine Zhang
Signed-off-by: Elaine Zhang
---
drivers/clk/clk-fractional-divider.c | 32
drivers/clk/rockchip/clk.c | 2 +-
include/linux/clk-provider.h | 1 +
3 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-fractional-divider.c
b/drivers/clk/clk-fractional-divider.c
index aab904618eb6..3107b33327f9 100644
--- a/drivers/clk/clk-fractional-divider.c
+++ b/drivers/clk/clk-fractional-divider.c
@@ -158,6 +158,38 @@ struct clk_hw *clk_hw_register_fractional_divider(struct
device *dev,
}
EXPORT_SYMBOL_GPL(clk_hw_register_fractional_divider);
+static long clk_fd_round_rate_special(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
this obviously still encodes Rockchip-specific things into the generic
fractional-divider driver. And it's of course only special for Rockchip
fractional dividers and will end it chaos if every implementation wants
to add a "special" function there.
Did you have a look at the patch I added to the last mail (for real this time)?
I think your patch is not most appropriate.
Because I think the rational_best_approximation is work well, I modified
is parent_rate,
I just need to make sure the parent_rate > frac_rate * 20.
And I modify this like: (It is more appropriate?)
(I tested in RK SoCs. It's work well.)
diff --git a/drivers/clk/clk-fractional-divider.c
b/drivers/clk/clk-fractional-divider.c
index e7a315e840e6..ccc9a98e53ce 100644
--- a/drivers/clk/clk-fractional-divider.c
+++ b/drivers/clk/clk-fractional-divider.c
@@ -62,6 +62,9 @@ static long clk_fd_round_rate(struct clk_hw *hw,
unsigned long rate,
if (!rate || rate >= *parent_rate)
return *parent_rate;
+ if (fd->approx)
+ fd->approx(hw, rate, parent_rate);
+
/*
* Get rate closer to *parent_rate to guarantee there is no overflow
* for m and n. In the result it will be the nearest rate left shifted
@@ -147,6 +150,7 @@ struct clk_hw
*clk_hw_register_fractional_divider(struct device *dev,
fd->nmask = GENMASK(nwidth - 1, 0) << nshift;
fd->flags = clk_divider_flags;
fd->lock = lock;
+ fd->approx = NULL;
fd->hw.init = &init;
hw = &fd->hw;
diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
index e96a2e187862..a8ed48ffd531 100644
--- a/drivers/clk/rockchip/clk.c
+++ b/drivers/clk/rockchip/clk.c
@@ -160,6 +160,21 @@ static int rockchip_clk_frac_notifier_cb(struct
notifier_block *nb,
return notifier_from_errno(ret);
}
+void rockchip_fractional_special_approx(struct clk_hw *hw,
+ unsigned long rate,
+ unsigned long *parent_rate)
+{
+ struct clk_hw *p_parent;
+ unsigned long p_rate, p_parent_rate;
+
+ p_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
+ if ((rate * 20 > p_rate) && (p_rate % rate != 0)) {
+ p_parent = clk_hw_get_parent(clk_hw_get_parent(hw));
+ p_parent_rate = clk_hw_get_rate(p_parent);
+ *parent_rate = p_parent_rate;
+ }
+}
+
static struct clk *rockchip_clk_register_frac_branch(
struct rockchip_clk_provider *ctx, const char *name,
const char *const *parent_names, u8 num_parents,
@@ -206,6 +221,7 @@ static struct clk *rockchip_clk_register_frac_branch(
div->nwidth = 16;
div->nmask = GENMASK(div->nwidth - 1, 0) << div->nshift;
div->lock = lock;
+ div->approx = rockchip_fractional_special_approx;
div_ops = &clk_fractional_divider_ops;
clk = clk_register_composite(NULL, name, parent_names, num_parents,
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index f70440a4edd7..6e4f6940e39e 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -513,6 +513,9 @@ struct clk_fractional_divider {
u8 nwidth;
u32 nmask;
u8 flags;
+ void(*approx)(struct clk_hw *hw,
+ unsigned long rate,
+ un
Re: [PATCH v6 1/4] firmware: scm: Add new SCM call API for switching memory ownership
On 07/13, Dwivedi, Avaneesh Kumar (avani) wrote: > OK, will do same. > just last thing to ask, should i resend all 4 patches together again > or only one patch in v7 version. > as chnage will be in only 1 out of 4 patches. I would resend all of them. That's standard practice for patch series. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [RFC v5 15/38] powerpc: helper function to read,write AMR,IAMR,UAMOR registers
On Wed, Jul 12, 2017 at 03:26:01PM +1000, Balbir Singh wrote:
> On Wed, 5 Jul 2017 14:21:52 -0700
> Ram Pai wrote:
>
> > Implements helper functions to read and write the key related
> > registers; AMR, IAMR, UAMOR.
> >
> > AMR register tracks the read,write permission of a key
> > IAMR register tracks the execute permission of a key
> > UAMOR register enables and disables a key
> >
> > Signed-off-by: Ram Pai
> > ---
> > arch/powerpc/include/asm/book3s/64/pgtable.h | 60
> > ++
> > 1 files changed, 60 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
> > b/arch/powerpc/include/asm/book3s/64/pgtable.h
> > index 85bc987..435d6a7 100644
> > --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> > +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> > @@ -428,6 +428,66 @@ static inline void huge_ptep_set_wrprotect(struct
> > mm_struct *mm,
> > pte_update(mm, addr, ptep, 0, _PAGE_PRIVILEGED, 1);
> > }
> >
> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> > +
> > +#include
> > +static inline u64 read_amr(void)
> > +{
> > + return mfspr(SPRN_AMR);
> > +}
> > +static inline void write_amr(u64 value)
> > +{
> > + mtspr(SPRN_AMR, value);
> > +}
> > +static inline u64 read_iamr(void)
> > +{
> > + return mfspr(SPRN_IAMR);
> > +}
> > +static inline void write_iamr(u64 value)
> > +{
> > + mtspr(SPRN_IAMR, value);
> > +}
> > +static inline u64 read_uamor(void)
> > +{
> > + return mfspr(SPRN_UAMOR);
> > +}
> > +static inline void write_uamor(u64 value)
> > +{
> > + mtspr(SPRN_UAMOR, value);
> > +}
> > +
> > +#else /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> > +
> > +static inline u64 read_amr(void)
> > +{
> > + WARN(1, "%s called with MEMORY PROTECTION KEYS disabled\n", __func__);
> > + return -1;
> > +}
>
> Why do we need to have a version here if we are going to WARN(), why not
> let the compilation fail if called from outside of
> CONFIG_PPC64_MEMORY_PROTECTION_KEYS?
> Is that the intention?
I did not want to stop someone; kernel module for example, from calling
these interfaces from outside the pkey domain.
Either way can be argued to be correct, I suppose.
RP
Re: [PULL REQUEST] i2c for 4.13
Hello,
On Wed, Jul 12, 2017 at 10:16:32AM -0700, Linus Torvalds wrote:
> On Wed, Jul 12, 2017 at 8:49 AM, Wolfram Sang wrote:
> > drivers/i2c/i2c-core-acpi.c| 665
> > drivers/i2c/{i2c-core.c => i2c-core-base.c}| 1684
> > +---
> > drivers/i2c/i2c-core-of.c | 276
> > drivers/i2c/i2c-core-slave.c | 115 ++
> > drivers/i2c/i2c-core-smbus.c | 594 +++
> > drivers/i2c/i2c-core.h | 24 +
> > drivers/i2c/i2c-stub.c | 14 +-
>
> Side note on this.. (and doesn't affect the pull - I pulled it and
> it's going through my test build right now).
>
> Please don't do the silly "start every filename with the same prefix".
> It annoys people (ie me) that use tab-completion, and it just looks
> stupid.
>
> And this core re-org does it twice over - first with "i2c-" and then
> with "core-".
>
> Of *course* it's "i2c-something.c" - it's in the i2c directory. So
> that part is entirely pointless.
>
> And the "core-something.c" part seems to be entirely to keep the files
> together - but if the issue really is "sort files together", then
> that's why we have subdirectories.
>
> So I personally tend to much prefer
>
>drivers/i2c/core/acpi.c
>drivers/i2c/core/base.c
>drivers/i2c/core/of.c
>drivers/i2c/core/slave.c
>drivers/i2c/core/smbus.c
>drivers/i2c/core/core.h
>
> as the model. Then things *really* sort together, auto-complete works
> better, and tools like "git diff --dirstat" etc that group changes by
> directories also automatically just do the right thing.
>
> And notice how the filenames are smaller and prettier too? It's just a
> win/win situation.
>
> But I'm not going to enforce my style guide on you, since I very
> seldom actually end up touching those files. If this was some area
> where I often actually ended up looking at things, I'd almost require
> a sane directory structure, though.
>
> Because "name things with the same prefix" is not a sane directory structure.
Another reason I remember for the prefix thing is that this way the
kernel modules are not named of.ko, core.ko and base.ko. (But this can
be fixed in the Makefile of course with some more prose.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [patch] autogain support for bayer10 format (was Re: [patch] propagating controls in libv4l2)
Hi! > Oh, somehow I got confused that this is kernel code :) > > >But I'd say NEON conversion is not neccessary anytime soon. First, > >this is just trying to get average luminosity. We can easily skip > >quite a lot of pixels, and still get reasonable answer. > > > >Second, omap3isp actually has a hardware block computing statistics > >for us. We just don't use it for simplicity. > > > > Right, I forgot about that. > > >(But if you want to play with camera, I'll get you patches; there's > >ton of work to be done, both kernel and userspace :-). > > Well, I saw a low hanging fruit I thought I can convert to NEON in a day or > two, while having some rest from the huge "project" I am devoting all my > spare time recently (rebasing hildon/maemo 5 on top of devuan Jessie). > Still, if there is something relatively small to be done, just email me and > I'll have a look. Well, there's a ton of work on camera, and some work on libcmtspeechdata. The later is rather self-contained. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 3/3] ARM: dts: at91: sama5d2: use sama5d2 compatible string for SMC
On Wed, 12 Jul 2017, Alexandre Belloni wrote:
> On 11/07/2017 at 10:25:56 +0100, Lee Jones wrote:
> > On Tue, 11 Jul 2017, Ludovic Desroches wrote:
> >
> > > On Tue, Jul 11, 2017 at 09:58:29AM +0200, Ludovic Desroches wrote:
> > > > On Tue, Jul 11, 2017 at 09:52:58AM +0200, Nicolas Ferre wrote:
> > > > > On 11/07/2017 at 09:40, Ludovic Desroches wrote:
> > > > > > A new compatible string has been introduced for sama5d2 SMC to
> > > > > > allow to
> > > > > > manage the registers mapping change.
> > > > > >
> > > > > > Signed-off-by: Ludovic Desroches
> > > > > > ---
> > > > > > arch/arm/boot/dts/sama5d2.dtsi | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/arch/arm/boot/dts/sama5d2.dtsi
> > > > > > b/arch/arm/boot/dts/sama5d2.dtsi
> > > > > > index 4fcd5bb219e3..60e69aeacbdb 100644
> > > > > > --- a/arch/arm/boot/dts/sama5d2.dtsi
> > > > > > +++ b/arch/arm/boot/dts/sama5d2.dtsi
> > > > > > @@ -1048,7 +1048,7 @@
> > > > > > };
> > > > > >
> > > > > > hsmc: hsmc@f8014000 {
> > > > > > - compatible = "atmel,sama5d3-smc",
> > > > > > "syscon", "simple-mfd";
> > > > > > + compatible = "atmel,sama5d2-smc",
> > > > > > "syscon", "simple-mfd";
> > > > >
> > > > > You'd better use something like:
> > > > > compatible = "atmel,sama5d2-smc", "atmel,sama5d3-smc", "syscon",
> > > > > "simple-mfd";
> > > >
> > > > But it's not true, during data interface setup, we will write values in
> > > > the wrong place if we fallback on "atmel,sama5d3-smc".
> > > >
> > > > Regards
> > > >
> > > > Ludovic
> > > >
> > > > >
> > > > > So that this patch is independent from the rest of the series and
> > > > > we can avoid to having to synchronize with mfd or mtd/nand for this
> > > > > part.
> > >
> > > If Lee and Boris agree, maybe the series can go through AT91.
> >
> > That's fine, but if the series goes though another tree, I will
> > require a pull-request.
> >
> > I am also happy to carry though the MFD tree (and will of course send
> > out a PR to the other affected Maintainers).
> >
>
> I think the easiest is that you take the first two patches through mfd
> and I'll take the third one through at91.
>
> Our plan is to get everything fixed for the final 4.13 (I'll send the DT
> as a fix, on top of 4.13-rc1). Is that OK for you ?
Perfect.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 01/18] mfd: madera: Add register definitions for Cirrus Logic Madera codecs
On Mon, 24 Apr 2017, Richard Fitzgerald wrote: > This patch adds a header file of register definitions for Cirrus > Logic "Madera" class codecs. These codecs are all based off a common > set of hardware IP so have a common register map (with a few minor > device-to-device variations). These are complex devices with a large > number of features and so have a correspondingly large register set. > The registers.h file has been auto-generated from the hardware register > definitions, stripped down to only registers we need to access from > the driver. > > Signed-off-by: Richard Fitzgerald > --- > > No changes since V1. > > MAINTAINERS | 10 + > include/linux/mfd/madera/registers.h | 8832 > ++ > 2 files changed, 8842 insertions(+) > create mode 100644 include/linux/mfd/madera/registers.h This patch has been rejected by Linus. https://lkml.org/lkml/2017/7/7/579 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [RFC v5 34/38] procfs: display the protection-key number associated with a vma
On Tue, Jul 11, 2017 at 11:13:56AM -0700, Dave Hansen wrote:
> On 07/05/2017 02:22 PM, Ram Pai wrote:
> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> > +void arch_show_smap(struct seq_file *m, struct vm_area_struct *vma)
> > +{
> > + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma));
> > +}
> > +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
>
> This seems like kinda silly unnecessary duplication. Could we just put
> this in the fs/proc/ code and #ifdef it on ARCH_HAS_PKEYS?
Well x86 predicates it based on availability of X86_FEATURE_OSPKE.
powerpc doesn't need that check or any similar check. So trying to
generalize the code does not save much IMHO.
maybe have a seperate inline function that does
seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma));
and is called from x86 and powerpc's arch_show_smap()?
At least will keep the string format captured in
one single place.
thoughts?
RP
[PATCH v3 2/2] mmc: sdhci-of-at91: set clocks and presets after resume from deepest PM
This adds deepest (Backup+Self-Refresh) PM support to the ATMEL SAMA5D2
SoC's SDHCI controller.
When resuming from deepest state, it is required to restore preset
registers as the registers are lost since VDD core has been shut down
when entering deepest state on the SAMA5D2. The clocks need to be
reconfigured as well.
The other registers and init process are taken care of by the SDHCI
core.
Signed-off-by: Quentin Schulz
Acked-by: Ludovic Desroches
---
v3:
- pm_runtime_force_suspend before setting restore_needed flag,
v2:
- use runtime_resume as system_resume,
- set a flag to tell when restoring presets is needed,
- use a flag to tell runtime_resume to restore presets,
- surround sdhci_at91_suspend with ifdef CONFIG_PM_SLEEP instead of CONFIG_PM,
drivers/mmc/host/sdhci-of-at91.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-at91.c b/drivers/mmc/host/sdhci-of-at91.c
index fb8c6011f13d..88e9b5f35a62 100644
--- a/drivers/mmc/host/sdhci-of-at91.c
+++ b/drivers/mmc/host/sdhci-of-at91.c
@@ -41,6 +41,7 @@ struct sdhci_at91_priv {
struct clk *hclock;
struct clk *gck;
struct clk *mainck;
+ bool restore_needed;
};
static void sdhci_at91_set_clock(struct sdhci_host *host, unsigned int clock)
@@ -206,6 +207,22 @@ static int sdhci_at91_set_clks_presets(struct device *dev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int sdhci_at91_suspend(struct device *dev)
+{
+ struct sdhci_host *host = dev_get_drvdata(dev);
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_at91_priv *priv = sdhci_pltfm_priv(pltfm_host);
+ int ret;
+
+ ret = pm_runtime_force_suspend(dev);
+
+ priv->restore_needed = true;
+
+ return ret;
+}
+#endif /* CONFIG_PM_SLEEP */
+
#ifdef CONFIG_PM
static int sdhci_at91_runtime_suspend(struct device *dev)
{
@@ -233,6 +250,15 @@ static int sdhci_at91_runtime_resume(struct device *dev)
struct sdhci_at91_priv *priv = sdhci_pltfm_priv(pltfm_host);
int ret;
+ if (priv->restore_needed) {
+ ret = sdhci_at91_set_clks_presets(dev);
+ if (ret)
+ return ret;
+
+ priv->restore_needed = false;
+ goto out;
+ }
+
ret = clk_prepare_enable(priv->mainck);
if (ret) {
dev_err(dev, "can't enable mainck\n");
@@ -251,13 +277,13 @@ static int sdhci_at91_runtime_resume(struct device *dev)
return ret;
}
+out:
return sdhci_runtime_resume_host(host);
}
#endif /* CONFIG_PM */
static const struct dev_pm_ops sdhci_at91_dev_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
- pm_runtime_force_resume)
+ SET_SYSTEM_SLEEP_PM_OPS(sdhci_at91_suspend, pm_runtime_force_resume)
SET_RUNTIME_PM_OPS(sdhci_at91_runtime_suspend,
sdhci_at91_runtime_resume,
NULL)
@@ -306,6 +332,8 @@ static int sdhci_at91_probe(struct platform_device *pdev)
if (ret)
goto sdhci_pltfm_free;
+ priv->restore_needed = false;
+
ret = mmc_of_parse(host->mmc);
if (ret)
goto clocks_disable_unprepare;
--
2.11.0
[PATCH v3 1/2] mmc: sdhci-of-at91: factor out clks and presets setting
The setting of clocks and presets is currently done in probe only but
once deep PM support is added, it'll be needed in the resume function.
Let's create a function for this setting.
Signed-off-by: Quentin Schulz
Acked-by: Ludovic Desroches
Acked-by: Adrian Hunter
---
drivers/mmc/host/sdhci-of-at91.c | 147 ++-
1 file changed, 82 insertions(+), 65 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-at91.c b/drivers/mmc/host/sdhci-of-at91.c
index 7611fd679f1a..fb8c6011f13d 100644
--- a/drivers/mmc/host/sdhci-of-at91.c
+++ b/drivers/mmc/host/sdhci-of-at91.c
@@ -128,6 +128,84 @@ static const struct of_device_id sdhci_at91_dt_match[] = {
};
MODULE_DEVICE_TABLE(of, sdhci_at91_dt_match);
+static int sdhci_at91_set_clks_presets(struct device *dev)
+{
+ struct sdhci_host *host = dev_get_drvdata(dev);
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_at91_priv *priv = sdhci_pltfm_priv(pltfm_host);
+ int ret;
+ unsigned intcaps0, caps1;
+ unsigned intclk_base, clk_mul;
+ unsigned intgck_rate, real_gck_rate;
+ unsigned intpreset_div;
+
+ /*
+* The mult clock is provided by as a generated clock by the PMC
+* controller. In order to set the rate of gck, we have to get the
+* base clock rate and the clock mult from capabilities.
+*/
+ clk_prepare_enable(priv->hclock);
+ caps0 = readl(host->ioaddr + SDHCI_CAPABILITIES);
+ caps1 = readl(host->ioaddr + SDHCI_CAPABILITIES_1);
+ clk_base = (caps0 & SDHCI_CLOCK_V3_BASE_MASK) >> SDHCI_CLOCK_BASE_SHIFT;
+ clk_mul = (caps1 & SDHCI_CLOCK_MUL_MASK) >> SDHCI_CLOCK_MUL_SHIFT;
+ gck_rate = clk_base * 100 * (clk_mul + 1);
+ ret = clk_set_rate(priv->gck, gck_rate);
+ if (ret < 0) {
+ dev_err(dev, "failed to set gck");
+ clk_disable_unprepare(priv->hclock);
+ return ret;
+ }
+ /*
+* We need to check if we have the requested rate for gck because in
+* some cases this rate could be not supported. If it happens, the rate
+* is the closest one gck can provide. We have to update the value
+* of clk mul.
+*/
+ real_gck_rate = clk_get_rate(priv->gck);
+ if (real_gck_rate != gck_rate) {
+ clk_mul = real_gck_rate / (clk_base * 100) - 1;
+ caps1 &= (~SDHCI_CLOCK_MUL_MASK);
+ caps1 |= ((clk_mul << SDHCI_CLOCK_MUL_SHIFT) &
+ SDHCI_CLOCK_MUL_MASK);
+ /* Set capabilities in r/w mode. */
+ writel(SDMMC_CACR_KEY | SDMMC_CACR_CAPWREN,
+ host->ioaddr + SDMMC_CACR);
+ writel(caps1, host->ioaddr + SDHCI_CAPABILITIES_1);
+ /* Set capabilities in ro mode. */
+ writel(0, host->ioaddr + SDMMC_CACR);
+ dev_info(dev, "update clk mul to %u as gck rate is %u Hz\n",
+clk_mul, real_gck_rate);
+ }
+
+ /*
+* We have to set preset values because it depends on the clk_mul
+* value. Moreover, SDR104 is supported in a degraded mode since the
+* maximum sd clock value is 120 MHz instead of 208 MHz. For that
+* reason, we need to use presets to support SDR104.
+*/
+ preset_div = DIV_ROUND_UP(real_gck_rate, 2400) - 1;
+ writew(SDHCI_AT91_PRESET_COMMON_CONF | preset_div,
+ host->ioaddr + SDHCI_PRESET_FOR_SDR12);
+ preset_div = DIV_ROUND_UP(real_gck_rate, 5000) - 1;
+ writew(SDHCI_AT91_PRESET_COMMON_CONF | preset_div,
+ host->ioaddr + SDHCI_PRESET_FOR_SDR25);
+ preset_div = DIV_ROUND_UP(real_gck_rate, 1) - 1;
+ writew(SDHCI_AT91_PRESET_COMMON_CONF | preset_div,
+ host->ioaddr + SDHCI_PRESET_FOR_SDR50);
+ preset_div = DIV_ROUND_UP(real_gck_rate, 12000) - 1;
+ writew(SDHCI_AT91_PRESET_COMMON_CONF | preset_div,
+ host->ioaddr + SDHCI_PRESET_FOR_SDR104);
+ preset_div = DIV_ROUND_UP(real_gck_rate, 5000) - 1;
+ writew(SDHCI_AT91_PRESET_COMMON_CONF | preset_div,
+ host->ioaddr + SDHCI_PRESET_FOR_DDR50);
+
+ clk_prepare_enable(priv->mainck);
+ clk_prepare_enable(priv->gck);
+
+ return 0;
+}
+
#ifdef CONFIG_PM
static int sdhci_at91_runtime_suspend(struct device *dev)
{
@@ -192,11 +270,7 @@ static int sdhci_at91_probe(struct platform_device *pdev)
struct sdhci_host *host;
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_at91_priv *priv;
- unsigned intcaps0, caps1;
- unsigned intclk_base, clk_mul;
- unsigned intgck_rate, real_gck_rate;
int ret;
- unsigned int
Re: [PATCH] mfd: intel_soc_pmic_chtwc: Turn Kconfig option into a bool
On Fri, 23 Jun 2017, Hans de Goede wrote: > The PMIC provides ACPI OpRegions which must be available for other > drivers' PS0 / PS3 methods early-on as such it must be builtin as the > Kconfig help text already states. > > Somehow its Kconfig option ended up being a tristate though, this fixes > this. > > Signed-off-by: Hans de Goede > --- > Note, feel free to squash this in the original commit if you wish > --- > drivers/mfd/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 8533cb46a875..be962d128f31 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -476,7 +476,7 @@ config INTEL_SOC_PMIC_BXTWC > on these systems. > > config INTEL_SOC_PMIC_CHTWC > - tristate "Support for Intel Cherry Trail Whiskey Cove PMIC" > + bool "Support for Intel Cherry Trail Whiskey Cove PMIC" > depends on ACPI && HAS_IOMEM && I2C=y && COMMON_CLK > depends on X86 || COMPILE_TEST > select MFD_CORE -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] arm64: dts: ls1012a: add USB host controller nodes
On Wed, Jul 05, 2017 at 10:54:03AM +0800, Ran Wang wrote:
> LS1012A has one USB 3.0(DWC3) controller and
> one USB 2.0 controller.
>
> Signed-off-by: Ran Wang
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> index b497ac1..8aa2dcf 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> @@ -411,6 +411,23 @@
><&clockgen 4 3>;
> };
>
> + usb0: usb3@2f0 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0x2f0 0x0 0x1>;
> + interrupts = <0 60 0x4>;
> + dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,dis_rxdet_inp3_quirk;
> + };
> +
> + usb1: usb2@860 {
> + compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
> + reg = <0x0 0x860 0x0 0x1000>;
> + interrupts = <0 139 0x4>;
> + dr_mode = "host";
> + phy_type = "ulpi";
> + };
Please keep the nodes sorted in unit-address.
Shawn
> +
> sata: sata@320 {
> compatible = "fsl,ls1012a-ahci", "fsl,ls1043a-ahci";
> reg = <0x0 0x320 0x0 0x1>,
> --
> 2.1.0.27.g96db324
>
Re: [PATCH v3 0/7] Enhance libsas hotplug feature
On 13/07/2017 02:37, wangyijing wrote: > So much nicer. BTW, /dev/sdb is a SATA disk, the rest are SAS. Oh, I take a mistake ? The result you tested the hotplug which applied this patchset is fine ? Thanks! Yijing. Well basic hotplug is fine, as below. I did not do any robust testing. root@(none)$ echo 0 > ./phy-0:7/sas_phy/phy-0:7/enable root@(none)$ [ 180.147676] hisi_sas_v2_hw HISI0162:01: found dev[8:1] is gone [ 180.216558] hisi_sas_v2_hw HISI0162:01: found dev[7:1] is gone [ 180.280548] hisi_sas_v2_hw HISI0162:01: found dev[6:1] is gone [ 180.352556] hisi_sas_v2_hw HISI0162:01: found dev[5:1] is gone [ 180.432495] hisi_sas_v2_hw HISI0162:01: found dev[4:1] is gone [ 180.508492] hisi_sas_v2_hw HISI0162:01: found dev[3:1] is gone [ 180.527577] sd 0:0:1:0: [sdb] Synchronizing SCSI cache [ 180.532728] sd 0:0:1:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=0x00 [ 180.541591] sd 0:0:1:0: [sdb] Stopping disk [ 180.545767] sd 0:0:1:0: [sdb] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=0x00 [ 180.612491] hisi_sas_v2_hw HISI0162:01: found dev[2:5] is gone [ 180.696452] hisi_sas_v2_hw HISI0162:01: found dev[1:1] is gone [ 180.703221] hisi_sas_v2_hw HISI0162:01: found dev[0:2] is gone root@(none)$ echo 1 > ./phy-0:7/sas_phy/phy-0:7/enable root@(none)$ [ 185.937831] hisi_sas_v2_hw HISI0162:01: phyup: phy7 link_rate=11 [ 185.996575] scsi 0:0:8:0: Direct-Access SanDisk LT0200MO P404 PQ: 0 ANSI: 6 [ 187.059642] ata2.00: ATA-8: HGST HUS724040ALA640, MFAOA8B0, max UDMA/133 [ 187.066341] ata2.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 187.073278] ata2.00: ATA Identify Device Log not supported [ 187.078755] ata2.00: Security Log not supported [ 187.085239] ata2.00: ATA Identify Device Log not supported [ 187.090715] ata2.00: Security Log not supported [ 187.095236] ata2.00: configured for UDMA/133 [ 187.136917] scsi 0:0:9:0: Direct-Access ATA HGST HUS724040AL A8B0 PQ: 0 ANSI: 5 [ 187.187612] sd 0:0:9:0: [sdb] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB) [ 187.195365] sd 0:0:9:0: [sdb] Write Protect is off [ 187.200161] sd 0:0:9:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 187.223844] sd 0:0:9:0: [sdb] Attached SCSI disk [ 187.225498] scsi 0:0:10:0: Direct-Access SanDisk LT0200MO P404 PQ: 0 ANSI: 6 [ 187.243864] sd 0:0:8:0: [sda] 390721968 512-byte logical blocks: (200 GB/186 GiB) [ 187.285879] sd 0:0:8:0: [sda] Write Protect is off [ 187.367898] sd 0:0:8:0: [sda] Write cache: disabled, read cache: disabled, supports DPO and FUA [ 187.524043] scsi 0:0:11:0: Direct-Access SanDisk LT0200MO P404 PQ: 0 ANSI: 6 [ 187.701505] sd 0:0:10:0: [sdc] 390721968 512-byte logical blocks: (200 GB/186 GiB) [ 187.743547] sd 0:0:10:0: [sdc] Write Protect is off [ 187.822546] scsi 0:0:12:0: Direct-Access SanDisk LT0200MO P404 PQ: 0 ANSI: 6 [ 187.825531] sd 0:0:10:0: [sdc] Write cache: disabled, read cache: disabled, supports DPO and FUA [ 188.000167] sd 0:0:11:0: [sdd] 390721968 512-byte logical blocks: (200 GB/186 GiB) [ 188.042205] sd 0:0:11:0: [sdd] Write Protect is off [ 188.121527] scsi 0:0:13:0: Direct-Access SanDisk LT0200MO P404 PQ: 0 ANSI: 6 [ 188.124274] sd 0:0:11:0: [sdd] Write cache: disabled, read cache: disabled, supports DPO and FUA [ 188.298942] sd 0:0:12:0: [sde] 390721968 512-byte logical blocks: (200 GB/186 GiB) [ 188.340960] sd 0:0:12:0: [sde] Write Protect is off [ 188.420023] scsi 0:0:14:0: Direct-Access SanDisk LT0200MO P404 PQ: 0 ANSI: 6 [ 188.422969] sd 0:0:12:0: [sde] Write cache: disabled, read cache: disabled, supports DPO and FUA [ 188.597501] sd 0:0:13:0: [sdf] 390721968 512-byte logical blocks: (200 GB/186 GiB) [ 188.605069] sd 0:0:8:0: [sda] Attached SCSI disk [ 188.639520] sd 0:0:13:0: [sdf] Write Protect is off [ 188.682445] scsi 0:0:15:0: Enclosure 12G SAS Expander RevB PQ: 0 ANSI: 6 [ 188.721540] sd 0:0:13:0: [sdf] Write cache: disabled, read cache: disabled, supports DPO and FUA [ 188.896399] sd 0:0:14:0: [sdg] 390721968 512-byte logical blocks: (200 GB/186 GiB) [ 188.938445] sd 0:0:14:0: [sdg] Write Protect is off [ 189.020444] sd 0:0:14:0: [sdg] Write cache: disabled, read cache: disabled, supports DPO and FUA [ 189.060608] sd 0:0:10:0: [sdc] Attached SCSI disk [ 189.359073] sd 0:0:11:0: [sdd] Attached SCSI disk [ 189.657643] sd 0:0:12:0: [sde] Attached SCSI disk [ 189.956585] sd 0:0:13:0: [sdf] Attached SCSI disk [ 190.255148] sd 0:0:14:0: [sdg] Attached SCSI disk root@(none)$ echo 0 > ./phy-0:7/sas_phy/phy-0:7/enable root@(none)$ [ 192.895718] hisi_sas_v2_hw HISI0162:01: found dev[8:1] is gone [ 192.964671] hisi_sas_v2_hw HISI0162:01: found dev[7:1] is gone [ 193.032744] hisi_sas_v2_hw HISI0162:01: found dev[6:1] is gone [ 193.096755] hisi_sas_v2_hw HISI0162:01: found dev[5:1] is gone [ 193.157072] hisi_sas_v2_hw HISI0162:01: found dev[4:
Re: [GIT PULL] Please pull JSON files for Power9 PMU events
On Thu, Jul 13, 2017 at 01:43:41PM +1000, Michael Ellerman wrote: > Sukadev Bhattiprolu writes: > ... > > > > tools/perf/pmu-events/arch/powerpc/mapfile.csv | 3 + > > .../perf/pmu-events/arch/powerpc/power9/cache.json | 176 + > > .../arch/powerpc/power9/floating-point.json| 44 ++ > > .../pmu-events/arch/powerpc/power9/frontend.json | 446 +++ > > .../pmu-events/arch/powerpc/power9/marked.json | 782 > > +++ > > .../pmu-events/arch/powerpc/power9/memory.json | 158 > > In the map file we have "power9.json", but the files are power9/x.json. > How does that work? hum, we take just the base name from that string and use it as a map to the directory/struct with events.. so no harm done I guess it's the leftover from when we switched from single file to per topic event files.. x86 arch seems to have it right I'll send the fix thanks, jirka
[PATCH] libata: remove unused rc in ata_eh_handle_port_resume
Remove unused variable ‘rc’. Signed-off-by: Kefeng Wang --- drivers/ata/libata-eh.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c index b70bcf6..7d79d20 100644 --- a/drivers/ata/libata-eh.c +++ b/drivers/ata/libata-eh.c @@ -4175,7 +4175,6 @@ static void ata_eh_handle_port_resume(struct ata_port *ap) struct ata_link *link; struct ata_device *dev; unsigned long flags; - int rc = 0; /* are we resuming? */ spin_lock_irqsave(ap->lock, flags); @@ -4202,7 +4201,7 @@ static void ata_eh_handle_port_resume(struct ata_port *ap) ata_acpi_set_state(ap, ap->pm_mesg); if (ap->ops->port_resume) - rc = ap->ops->port_resume(ap); + ap->ops->port_resume(ap); /* tell ACPI that we're resuming */ ata_acpi_on_resume(ap); -- 1.8.3.1
Re: [PATCH v7 06/16] lockdep: Detect and handle hist_lock ring buffer overwrite
On Thu, Jul 13, 2017 at 11:07:45AM +0900, Byungchul Park wrote:
> Does my approach have problems, rewinding to 'original idx' on exit and
> deciding whether overwrite or not? I think, this way, no need to do the
> drastic work. Or.. does my one get more overhead in usual case?
So I think that invalidating just the one entry doesn't work; the moment
you fill that up the iteration in commit_xhlocks() will again use the
next one etc.. even though you wanted it not to.
So we need to wipe the _entire_ history.
So I _think_ the below should work, but its not been near a compiler.
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -822,6 +822,7 @@ struct task_struct {
unsigned int xhlock_idx_soft; /* For restoring at softirq exit */
unsigned int xhlock_idx_hard; /* For restoring at hardirq exit */
unsigned int xhlock_idx_hist; /* For restoring at history boundaries */
+ unsigned int xhlock_idX_max;
#endif
#ifdef CONFIG_UBSAN
unsigned intin_ubsan;
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -4746,6 +4746,14 @@ EXPORT_SYMBOL_GPL(lockdep_rcu_suspicious
static atomic_t cross_gen_id; /* Can be wrapped */
/*
+ * make xhlock_valid() false.
+ */
+static inline void invalidate_xhlock(struct hist_lock *xhlock)
+{
+ xhlock->hlock.instance = NULL;
+}
+
+/*
* Lock history stacks; we have 3 nested lock history stacks:
*
* Hard IRQ
@@ -4764,28 +4772,58 @@ static atomic_t cross_gen_id; /* Can be
* MAX_XHLOCKS_NR ? Possibly re-instroduce hist_gen_id ?
*/
-void crossrelease_hardirq_start(void)
+static inline void __crossrelease_start(unsigned int *stamp)
{
if (current->xhlocks)
- current->xhlock_idx_hard = current->xhlock_idx;
+ *stamp = current->xhlock_idx;
+}
+
+static void __crossrelease_end(unsigned int *stamp)
+{
+ int i;
+
+ if (!current->xhlocks)
+ return;
+
+ current->xhlock_idx = *stamp;
+
+ /*
+* If we rewind past the tail; all of history is lost.
+*/
+ if ((current->xhlock_idx_max - *stamp) < MAX_XHLOCKS_NR)
+ return;
+
+ /*
+* Invalidate the entire history..
+*/
+ for (i = 0; i < MAX_XHLOCKS_NR; i++)
+ invalidate_xhlock(&xhlock(i));
+
+ current->xhlock_idx = 0;
+ current->xhlock_idx_hard = 0;
+ current->xhlock_idx_soft = 0;
+ current->xhlock_idx_hist = 0;
+ current->xhlock_idx_max = 0;
+}
+
+void crossrelease_hardirq_start(void)
+{
+ __crossrelease_start(¤t->xhlock_idx_hard);
}
void crossrelease_hardirq_end(void)
{
- if (current->xhlocks)
- current->xhlock_idx = current->xhlock_idx_hard;
+ __crossrelease_end(¤t->xhlock_idx_hard);
}
void crossrelease_softirq_start(void)
{
- if (current->xhlocks)
- current->xhlock_idx_soft = current->xhlock_idx;
+ __crossrelease_start(¤t->xhlock_idx_soft);
}
void crossrelease_softirq_end(void)
{
- if (current->xhlocks)
- current->xhlock_idx = current->xhlock_idx_soft;
+ __crossrelease_end(¤t->xhlock_idx_soft);
}
/*
@@ -4806,14 +4844,12 @@ void crossrelease_softirq_end(void)
*/
void crossrelease_hist_start(void)
{
- if (current->xhlocks)
- current->xhlock_idx_hist = current->xhlock_idx;
+ __crossrelease_start(¤t->xhlock_idx_hist);
}
void crossrelease_hist_end(void)
{
- if (current->xhlocks)
- current->xhlock_idx = current->xhlock_idx_hist;
+ __crossrelease_end(¤t->xhlock_idx_hist);
}
static int cross_lock(struct lockdep_map *lock)
@@ -4880,6 +4916,9 @@ static void add_xhlock(struct held_lock
unsigned int idx = ++current->xhlock_idx;
struct hist_lock *xhlock = &xhlock(idx);
+ if ((int)(current->xhlock_idx_max - idx) < 0)
+ current->xhlock_idx_max = idx;
+
#ifdef CONFIG_DEBUG_LOCKDEP
/*
* This can be done locklessly because they are all task-local
Re: [PATCH v3] backlight: lm3630a: bump REG_MAX value to 0x50 instead of 0x1F
On Fri, 23 Jun 2017, Bhushan Shah wrote:
> In the lm3630a_chip_init we try to write to 0x50 register, which is
> higher value then the max_register value, this resulted in regmap_write
> return -EIO.
>
> Fix this by bumping REG_MAX value to 0x50.
>
> This code was introduced with the chip revision in commit 28e64a68a2ef,
> however setting filter strength was failing silently because it used
> unsigned int for storing and comparing the return values. Bug related to
> signedness was fixed in 2a0c316bf3cc, which made it error out correctly
> instead of failing silently.
>
> I found this issue by using this driver on LGE Nexus 5 (hammerhead).
> After this commit lm3630a_chip_init succeeds instead of failing with
> -EIO.
>
> Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
> Fixes: 2a0c316bf3cc ("drivers/video/backlight/lm3630a_bl.c: fix
> signedness bug in lm3630a_chip_init()")
>
> Signed-off-by: Bhushan Shah
> Suggested-by: Bjorn Andersson
> ---
>
> Changes since v2:
> - Include information about commits which introduced bug in commit message
> - Include information about test hardware in commit message
> - Expand define name to REG_FILTER_STRENGTH
>
> drivers/video/backlight/lm3630a_bl.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Applied, thanks.
> diff --git a/drivers/video/backlight/lm3630a_bl.c
> b/drivers/video/backlight/lm3630a_bl.c
> index 60d6c2ac87aa..2030a6b77a09 100644
> --- a/drivers/video/backlight/lm3630a_bl.c
> +++ b/drivers/video/backlight/lm3630a_bl.c
> @@ -31,7 +31,8 @@
> #define REG_FAULT0x0B
> #define REG_PWM_OUTLOW 0x12
> #define REG_PWM_OUTHIGH 0x13
> -#define REG_MAX 0x1F
> +#define REG_FILTER_STRENGTH 0x50
> +#define REG_MAX 0x50
>
> #define INT_DEBOUNCE_MSEC10
> struct lm3630a_chip {
> @@ -80,7 +81,7 @@ static int lm3630a_chip_init(struct lm3630a_chip *pchip)
>
> usleep_range(1000, 2000);
> /* set Filter Strength Register */
> - rval = lm3630a_write(pchip, 0x50, 0x03);
> + rval = lm3630a_write(pchip, REG_FILTER_STRENGTH, 0x03);
> /* set Cofig. register */
> rval |= lm3630a_update(pchip, REG_CONFIG, 0x07, pdata->pwm_ctrl);
> /* set boost control */
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] um: Re-enable verbose panic()
Hi Richard, [auto build test WARNING on uml/linux-next] [also build test WARNING on v4.12 next-20170713] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Richard-Weinberger/um-Re-enable-verbose-panic/20170713-094737 base: https://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git linux-next config: um-allnoconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=um All warnings (new ones prefixed by >>): warning: (UML) selects DEBUG_BUGVERBOSE which has unmet direct dependencies (BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)) --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH 00/12] staging: ccree: coding style fixes
Another batch of ccree coding style fixes.
These goes on top of commit a8c4ae12 ("staging: ccree: Fix alignment issues in
ssi_sysfs.c")
in staging-testing.
Gilad Ben-Yossef (12):
staging: ccree remove unnecessary parentheses
staging: ccree: clean up struct ssi_aead_ctx
staging: ccree: use proper printk format for dma_addr_t
staging: ccree: fix parenthesis alignment
staging: ccree: fix split strings
staging: ccree: CamelCase to snake_case in func vars
staging: ccree: CamelCase to snake_case in aead struct
staging: ccree: avoid constant comparison
staging: ccree: avoid unnecessary line continuation
staging: ccree: remove func name from log messages
staging: ccree: kmalloc by sizeof var not type
staging: ccree: remove whitespace before a quoted newline
drivers/staging/ccree/ssi_aead.c| 242 +--
drivers/staging/ccree/ssi_aead.h| 12 +-
drivers/staging/ccree/ssi_buffer_mgr.c | 247 +++-
drivers/staging/ccree/ssi_cipher.c | 65 -
drivers/staging/ccree/ssi_driver.c | 16 +--
drivers/staging/ccree/ssi_hash.c| 209 ++-
drivers/staging/ccree/ssi_ivgen.c | 17 +--
drivers/staging/ccree/ssi_pm.c | 4 +-
drivers/staging/ccree/ssi_request_mgr.c | 29 ++--
drivers/staging/ccree/ssi_sysfs.c | 18 +--
10 files changed, 435 insertions(+), 424 deletions(-)
--
2.1.4
[PATCH 06/12] staging: ccree: CamelCase to snake_case in func vars
Turn local vars and function parameters names in CamelCase
to snake_case.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c | 26 +-
drivers/staging/ccree/ssi_buffer_mgr.c | 15 ---
drivers/staging/ccree/ssi_hash.c | 29 +++--
3 files changed, 36 insertions(+), 34 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 2d6ba8d..6d5cf02 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -307,7 +307,7 @@ static int xcbc_setkey(struct cc_hw_desc *desc, struct
ssi_aead_ctx *ctx)
static int hmac_setkey(struct cc_hw_desc *desc, struct ssi_aead_ctx *ctx)
{
- unsigned int hmacPadConst[2] = { HMAC_IPAD_CONST, HMAC_OPAD_CONST };
+ unsigned int hmac_pad_const[2] = { HMAC_IPAD_CONST, HMAC_OPAD_CONST };
unsigned int digest_ofs = 0;
unsigned int hash_mode = (ctx->auth_mode == DRV_HASH_SHA1) ?
DRV_HASH_HW_SHA1 : DRV_HASH_HW_SHA256;
@@ -341,7 +341,7 @@ static int hmac_setkey(struct cc_hw_desc *desc, struct
ssi_aead_ctx *ctx)
/* Prepare ipad key */
hw_desc_init(&desc[idx]);
- set_xor_val(&desc[idx], hmacPadConst[i]);
+ set_xor_val(&desc[idx], hmac_pad_const[i]);
set_cipher_mode(&desc[idx], hash_mode);
set_flow_mode(&desc[idx], S_DIN_to_HASH);
set_setup_mode(&desc[idx], SETUP_LOAD_STATE1);
@@ -1381,27 +1381,27 @@ static int validate_data_size(struct ssi_aead_ctx *ctx,
}
#if SSI_CC_HAS_AES_CCM
-static unsigned int format_ccm_a0(u8 *pA0Buff, u32 headerSize)
+static unsigned int format_ccm_a0(u8 *pa0_buff, u32 header_size)
{
unsigned int len = 0;
- if (headerSize == 0)
+ if (header_size == 0)
return 0;
- if (headerSize < ((1UL << 16) - (1UL << 8))) {
+ if (header_size < ((1UL << 16) - (1UL << 8))) {
len = 2;
- pA0Buff[0] = (headerSize >> 8) & 0xFF;
- pA0Buff[1] = headerSize & 0xFF;
+ pa0_buff[0] = (header_size >> 8) & 0xFF;
+ pa0_buff[1] = header_size & 0xFF;
} else {
len = 6;
- pA0Buff[0] = 0xFF;
- pA0Buff[1] = 0xFE;
- pA0Buff[2] = (headerSize >> 24) & 0xFF;
- pA0Buff[3] = (headerSize >> 16) & 0xFF;
- pA0Buff[4] = (headerSize >> 8) & 0xFF;
- pA0Buff[5] = headerSize & 0xFF;
+ pa0_buff[0] = 0xFF;
+ pa0_buff[1] = 0xFE;
+ pa0_buff[2] = (header_size >> 24) & 0xFF;
+ pa0_buff[3] = (header_size >> 16) & 0xFF;
+ pa0_buff[4] = (header_size >> 8) & 0xFF;
+ pa0_buff[5] = header_size & 0xFF;
}
return len;
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c
b/drivers/staging/ccree/ssi_buffer_mgr.c
index ed3945b..b707cbc 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -182,8 +182,8 @@ static inline int ssi_buffer_mgr_render_buff_to_mlli(
}
static inline int ssi_buffer_mgr_render_scatterlist_to_mlli(
- struct scatterlist *sgl, u32 sgl_data_len, u32 sglOffset, u32
*curr_nents,
- u32 **mlli_entry_pp)
+ struct scatterlist *sgl, u32 sgl_data_len, u32 sgl_offset,
+ u32 *curr_nents, u32 **mlli_entry_pp)
{
struct scatterlist *curr_sgl = sgl;
u32 *mlli_entry_p = *mlli_entry_pp;
@@ -192,16 +192,17 @@ static inline int
ssi_buffer_mgr_render_scatterlist_to_mlli(
for ( ; (curr_sgl) && (sgl_data_len != 0);
curr_sgl = sg_next(curr_sgl)) {
u32 entry_data_len =
- (sgl_data_len > sg_dma_len(curr_sgl) - sglOffset) ?
- sg_dma_len(curr_sgl) - sglOffset : sgl_data_len;
+ (sgl_data_len > sg_dma_len(curr_sgl) - sgl_offset) ?
+ sg_dma_len(curr_sgl) - sgl_offset :
+ sgl_data_len;
sgl_data_len -= entry_data_len;
rc = ssi_buffer_mgr_render_buff_to_mlli(
- sg_dma_address(curr_sgl) + sglOffset, entry_data_len,
curr_nents,
- &mlli_entry_p);
+ sg_dma_address(curr_sgl) + sgl_offset, entry_data_len,
+ curr_nents, &mlli_entry_p);
if (rc != 0)
return rc;
- sglOffset = 0;
+ sgl_offset = 0;
}
*mlli_entry_pp = mlli_entry_p;
return 0;
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index d0c8a8d..9c9c48b 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -965,7 +965,7 @@ static int ssi_hash_setkey(void *hash,
unsigned int keylen,
[PATCH 03/12] staging: ccree: use proper printk format for dma_addr_t
Fix needless casting to unsigned long long in printk for
DMA addresses by using proper %pad format.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c| 16
drivers/staging/ccree/ssi_buffer_mgr.c | 48
drivers/staging/ccree/ssi_cipher.c | 20 +-
drivers/staging/ccree/ssi_driver.c | 6 +--
drivers/staging/ccree/ssi_hash.c| 65 -
drivers/staging/ccree/ssi_request_mgr.c | 8 ++--
6 files changed, 81 insertions(+), 82 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index fd37dde..43455b9 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -102,8 +102,8 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
/* Unmap enckey buffer */
if (ctx->enckey) {
dma_free_coherent(dev, AES_MAX_KEY_SIZE, ctx->enckey,
ctx->enckey_dma_addr);
- SSI_LOG_DEBUG("Freed enckey DMA buffer
enckey_dma_addr=0x%llX\n",
- (unsigned long long)ctx->enckey_dma_addr);
+ SSI_LOG_DEBUG("Freed enckey DMA buffer enckey_dma_addr=%pad\n",
+ ctx->enckey_dma_addr);
ctx->enckey_dma_addr = 0;
ctx->enckey = NULL;
}
@@ -116,8 +116,8 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
xcbc->xcbc_keys,
xcbc->xcbc_keys_dma_addr);
}
- SSI_LOG_DEBUG("Freed xcbc_keys DMA buffer
xcbc_keys_dma_addr=0x%llX\n",
- (unsigned long long)xcbc->xcbc_keys_dma_addr);
+ SSI_LOG_DEBUG("Freed xcbc_keys DMA buffer
xcbc_keys_dma_addr=%pad\n",
+ xcbc->xcbc_keys_dma_addr);
xcbc->xcbc_keys_dma_addr = 0;
xcbc->xcbc_keys = NULL;
} else if (ctx->auth_mode != DRV_HASH_NULL) { /* HMAC auth. */
@@ -127,8 +127,8 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
dma_free_coherent(dev, 2 * MAX_HMAC_DIGEST_SIZE,
hmac->ipad_opad,
hmac->ipad_opad_dma_addr);
- SSI_LOG_DEBUG("Freed ipad_opad DMA buffer
ipad_opad_dma_addr=0x%llX\n",
- (unsigned long
long)hmac->ipad_opad_dma_addr);
+ SSI_LOG_DEBUG("Freed ipad_opad DMA buffer
ipad_opad_dma_addr=%pad\n",
+ hmac->ipad_opad_dma_addr);
hmac->ipad_opad_dma_addr = 0;
hmac->ipad_opad = NULL;
}
@@ -136,8 +136,8 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
dma_free_coherent(dev, MAX_HMAC_BLOCK_SIZE,
hmac->padded_authkey,
hmac->padded_authkey_dma_addr);
- SSI_LOG_DEBUG("Freed padded_authkey DMA buffer
padded_authkey_dma_addr=0x%llX\n",
- (unsigned long
long)hmac->padded_authkey_dma_addr);
+ SSI_LOG_DEBUG("Freed padded_authkey DMA buffer
padded_authkey_dma_addr=%pad\n",
+ hmac->padded_authkey_dma_addr);
hmac->padded_authkey_dma_addr = 0;
hmac->padded_authkey = NULL;
}
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 4127f9f..dcd78f6 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -259,9 +259,9 @@ static int ssi_buffer_mgr_generate_mlli(
mlli_params->mlli_len = (total_nents * LLI_ENTRY_BYTE_SIZE);
SSI_LOG_DEBUG("MLLI params: "
-"virt_addr=%pK dma_addr=0x%llX mlli_len=0x%X\n",
+"virt_addr=%pK dma_addr=%pad mlli_len=0x%X\n",
mlli_params->mlli_virt_addr,
- (unsigned long long)mlli_params->mlli_dma_addr,
+ mlli_params->mlli_dma_addr,
mlli_params->mlli_len);
build_mlli_exit:
@@ -275,9 +275,9 @@ static inline void ssi_buffer_mgr_add_buffer_entry(
{
unsigned int index = sgl_data->num_of_buffers;
- SSI_LOG_DEBUG("index=%u single_buff=0x%llX "
+ SSI_LOG_DEBUG("index=%u single_buff=%pad "
"buffer_len=0x%08X is_last=%d\n",
-index, (unsigned long long)buffer_dma, buffer_len,
is_last_entry);
+index, buffer_dma, buffer_len, is_last_entry);
sgl_data->nents[index] = 1;
sgl_data->entry[index].buffer_dma = buffer_dma;
sgl_data->offset[index] = 0;
@@ -358,10 +358,10 @@ static int ssi_buffer_mgr_map_scatterlist(
SSI_LOG_ERR("dma_map_sg() single buffer failed\n");
[PATCH 04/12] staging: ccree: fix parenthesis alignment
Fix various remaining parenthesis alignment issues.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c| 46 +
drivers/staging/ccree/ssi_buffer_mgr.c | 30 ++-
drivers/staging/ccree/ssi_cipher.c | 2 +-
drivers/staging/ccree/ssi_hash.c| 88 +
drivers/staging/ccree/ssi_ivgen.c | 5 +-
drivers/staging/ccree/ssi_request_mgr.c | 4 +-
6 files changed, 96 insertions(+), 79 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 43455b9..51a2b73 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -96,7 +96,7 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
SSI_LOG_DEBUG("Clearing context @%p for %s\n",
- crypto_aead_ctx(tfm), crypto_tfm_alg_name(&tfm->base));
+ crypto_aead_ctx(tfm), crypto_tfm_alg_name(&tfm->base));
dev = &ctx->drvdata->plat_dev->dev;
/* Unmap enckey buffer */
@@ -163,7 +163,7 @@ static int ssi_aead_init(struct crypto_aead *tfm)
/* Allocate key buffer, cache line aligned */
ctx->enckey = dma_alloc_coherent(dev, AES_MAX_KEY_SIZE,
- &ctx->enckey_dma_addr, GFP_KERNEL);
+&ctx->enckey_dma_addr, GFP_KERNEL);
if (!ctx->enckey) {
SSI_LOG_ERR("Failed allocating key buffer\n");
goto init_failed;
@@ -239,7 +239,7 @@ static void ssi_aead_complete(struct device *dev, void
*ssi_req, void __iomem *c
if (areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) {
if (memcmp(areq_ctx->mac_buf, areq_ctx->icv_virt_addr,
- ctx->authsize) != 0) {
+ ctx->authsize) != 0) {
SSI_LOG_DEBUG("Payload authentication failure, "
"(auth-size=%d, cipher=%d).\n",
ctx->authsize, ctx->cipher_mode);
@@ -378,7 +378,7 @@ static int hmac_setkey(struct cc_hw_desc *desc, struct
ssi_aead_ctx *ctx)
static int validate_keys_sizes(struct ssi_aead_ctx *ctx)
{
SSI_LOG_DEBUG("enc_keylen=%u authkeylen=%u\n",
- ctx->enc_keylen, ctx->auth_keylen);
+ ctx->enc_keylen, ctx->auth_keylen);
switch (ctx->auth_mode) {
case DRV_HASH_SHA1:
@@ -402,7 +402,7 @@ static int validate_keys_sizes(struct ssi_aead_ctx *ctx)
if (unlikely(ctx->flow_mode == S_DIN_to_DES)) {
if (ctx->enc_keylen != DES3_EDE_KEY_SIZE) {
SSI_LOG_ERR("Invalid cipher(3DES) key size: %u\n",
- ctx->enc_keylen);
+ ctx->enc_keylen);
return -EINVAL;
}
} else { /* Default assumed to be AES ciphers */
@@ -410,7 +410,7 @@ static int validate_keys_sizes(struct ssi_aead_ctx *ctx)
(ctx->enc_keylen != AES_KEYSIZE_192) &&
(ctx->enc_keylen != AES_KEYSIZE_256)) {
SSI_LOG_ERR("Invalid cipher(AES) key size: %u\n",
- ctx->enc_keylen);
+ ctx->enc_keylen);
return -EINVAL;
}
}
@@ -553,7 +553,8 @@ ssi_aead_setkey(struct crypto_aead *tfm, const u8 *key,
unsigned int keylen)
int seq_len = 0, rc = -EINVAL;
SSI_LOG_DEBUG("Setting key in context @%p for %s. key=%p keylen=%u\n",
- ctx, crypto_tfm_alg_name(crypto_aead_tfm(tfm)), key, keylen);
+ ctx, crypto_tfm_alg_name(crypto_aead_tfm(tfm)), key,
+ keylen);
/* STAT_PHASE_0: Init and sanity checks */
@@ -684,7 +685,7 @@ static int ssi_aead_setauthsize(
#if SSI_CC_HAS_AES_CCM
static int ssi_rfc4309_ccm_setauthsize(struct crypto_aead *authenc,
- unsigned int authsize)
+ unsigned int authsize)
{
switch (authsize) {
case 8:
@@ -699,7 +700,7 @@ static int ssi_rfc4309_ccm_setauthsize(struct crypto_aead
*authenc,
}
static int ssi_ccm_setauthsize(struct crypto_aead *authenc,
- unsigned int authsize)
+ unsigned int authsize)
{
switch (authsize) {
case 4:
@@ -1183,7 +1184,7 @@ static inline void ssi_aead_load_mlli_to_sram(
(req_ctx->data_buff_type == SSI_DMA_BUF_MLLI) ||
!req_ctx->is_single_pass)) {
SSI_LOG_DEBUG("Copy-to-sram: mlli_dma=%08x, mlli_size=%u\n",
- (unsigned int)ctx->drvdata->mlli_sram_addr,
+ (unsigned int)ctx->drvdata->mlli_sram_addr,
req_ctx->mlli_params.mlli_len);
/* Copy MLLI table host-to-sram */
[PATCH 02/12] staging: ccree: clean up struct ssi_aead_ctx
struct ssi_aead_ctx has some nested structure defined, resulting
in code accessing them to be very unreadable.
Move out the nested structure definitions out of the struct
and use the change to make the code accessing it more readable
and better coding style compliant by shortening lines and
properly matching alignment,
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c | 108 +++
1 file changed, 64 insertions(+), 44 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 99eeeda..fd37dde 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -56,22 +56,26 @@ struct ssi_aead_handle {
struct list_head aead_list;
};
+struct cc_hmac_s {
+ u8 *padded_authkey;
+ u8 *ipad_opad; /* IPAD, OPAD*/
+ dma_addr_t padded_authkey_dma_addr;
+ dma_addr_t ipad_opad_dma_addr;
+};
+
+struct cc_xcbc_s {
+ u8 *xcbc_keys; /* K1,K2,K3 */
+ dma_addr_t xcbc_keys_dma_addr;
+};
+
struct ssi_aead_ctx {
struct ssi_drvdata *drvdata;
u8 ctr_nonce[MAX_NONCE_SIZE]; /* used for ctr3686 iv and aes ccm */
u8 *enckey;
dma_addr_t enckey_dma_addr;
union {
- struct {
- u8 *padded_authkey;
- u8 *ipad_opad; /* IPAD, OPAD*/
- dma_addr_t padded_authkey_dma_addr;
- dma_addr_t ipad_opad_dma_addr;
- } hmac;
- struct {
- u8 *xcbc_keys; /* K1,K2,K3 */
- dma_addr_t xcbc_keys_dma_addr;
- } xcbc;
+ struct cc_hmac_s hmac;
+ struct cc_xcbc_s xcbc;
} auth_state;
unsigned int enc_keylen;
unsigned int auth_keylen;
@@ -105,33 +109,37 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
}
if (ctx->auth_mode == DRV_HASH_XCBC_MAC) { /* XCBC authetication */
- if (ctx->auth_state.xcbc.xcbc_keys) {
+ struct cc_xcbc_s *xcbc = &ctx->auth_state.xcbc;
+
+ if (xcbc->xcbc_keys) {
dma_free_coherent(dev, CC_AES_128_BIT_KEY_SIZE * 3,
- ctx->auth_state.xcbc.xcbc_keys,
- ctx->auth_state.xcbc.xcbc_keys_dma_addr);
+ xcbc->xcbc_keys,
+ xcbc->xcbc_keys_dma_addr);
}
SSI_LOG_DEBUG("Freed xcbc_keys DMA buffer
xcbc_keys_dma_addr=0x%llX\n",
- (unsigned long
long)ctx->auth_state.xcbc.xcbc_keys_dma_addr);
- ctx->auth_state.xcbc.xcbc_keys_dma_addr = 0;
- ctx->auth_state.xcbc.xcbc_keys = NULL;
+ (unsigned long long)xcbc->xcbc_keys_dma_addr);
+ xcbc->xcbc_keys_dma_addr = 0;
+ xcbc->xcbc_keys = NULL;
} else if (ctx->auth_mode != DRV_HASH_NULL) { /* HMAC auth. */
- if (ctx->auth_state.hmac.ipad_opad) {
+ struct cc_hmac_s *hmac = &ctx->auth_state.hmac;
+
+ if (hmac->ipad_opad) {
dma_free_coherent(dev, 2 * MAX_HMAC_DIGEST_SIZE,
- ctx->auth_state.hmac.ipad_opad,
- ctx->auth_state.hmac.ipad_opad_dma_addr);
+ hmac->ipad_opad,
+ hmac->ipad_opad_dma_addr);
SSI_LOG_DEBUG("Freed ipad_opad DMA buffer
ipad_opad_dma_addr=0x%llX\n",
- (unsigned long
long)ctx->auth_state.hmac.ipad_opad_dma_addr);
- ctx->auth_state.hmac.ipad_opad_dma_addr = 0;
- ctx->auth_state.hmac.ipad_opad = NULL;
+ (unsigned long
long)hmac->ipad_opad_dma_addr);
+ hmac->ipad_opad_dma_addr = 0;
+ hmac->ipad_opad = NULL;
}
- if (ctx->auth_state.hmac.padded_authkey) {
+ if (hmac->padded_authkey) {
dma_free_coherent(dev, MAX_HMAC_BLOCK_SIZE,
- ctx->auth_state.hmac.padded_authkey,
- ctx->auth_state.hmac.padded_authkey_dma_addr);
+ hmac->padded_authkey,
+ hmac->padded_authkey_dma_addr);
SSI_LOG_DEBUG("Freed padded_authkey DMA buffer
padded_authkey_dma_addr=0x%llX\n",
- (unsigned long
long)ctx->auth_state.hmac.padded_authkey_dma_addr);
- ctx->auth_state.hmac.padded_authkey_dma_addr = 0;
- ctx->auth_state.hmac.padded_authkey = NULL;
+ (unsigned long
long)hmac->padded_authkey_dma_addr);
+ hmac->p
[PATCH 01/12] staging: ccree remove unnecessary parentheses
Remove unnecessary parentheses from ccree driver code.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c| 4 ++--
drivers/staging/ccree/ssi_buffer_mgr.c | 8
drivers/staging/ccree/ssi_driver.c | 2 +-
drivers/staging/ccree/ssi_ivgen.c | 2 +-
drivers/staging/ccree/ssi_request_mgr.c | 2 +-
drivers/staging/ccree/ssi_sysfs.c | 8
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 3a10c31..99eeeda 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -92,7 +92,7 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
SSI_LOG_DEBUG("Clearing context @%p for %s\n",
- crypto_aead_ctx(tfm), crypto_tfm_alg_name(&(tfm->base)));
+ crypto_aead_ctx(tfm), crypto_tfm_alg_name(&tfm->base));
dev = &ctx->drvdata->plat_dev->dev;
/* Unmap enckey buffer */
@@ -143,7 +143,7 @@ static int ssi_aead_init(struct crypto_aead *tfm)
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
struct ssi_crypto_alg *ssi_alg =
container_of(alg, struct ssi_crypto_alg, aead_alg);
- SSI_LOG_DEBUG("Initializing context @%p for %s\n", ctx,
crypto_tfm_alg_name(&(tfm->base)));
+ SSI_LOG_DEBUG("Initializing context @%p for %s\n", ctx,
crypto_tfm_alg_name(&tfm->base));
/* Initialize modes in instance */
ctx->cipher_mode = ssi_alg->cipher_mode;
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c
b/drivers/staging/ccree/ssi_buffer_mgr.c
index feeaf8d..4127f9f 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -221,7 +221,7 @@ static int ssi_buffer_mgr_generate_mlli(
/* Allocate memory from the pointed pool */
mlli_params->mlli_virt_addr = dma_pool_alloc(
mlli_params->curr_pool, GFP_KERNEL,
- &(mlli_params->mlli_dma_addr));
+ &mlli_params->mlli_dma_addr);
if (unlikely(!mlli_params->mlli_virt_addr)) {
SSI_LOG_ERR("dma_pool_alloc() failed\n");
rc = -ENOMEM;
@@ -249,7 +249,7 @@ static int ssi_buffer_mgr_generate_mlli(
/*Calculate the current MLLI table length for the
*length field in the descriptor
*/
- *(sg_data->mlli_nents[i]) +=
+ *sg_data->mlli_nents[i] +=
(total_nents - prev_total_nents);
prev_total_nents = total_nents;
}
@@ -1176,7 +1176,7 @@ static inline int ssi_buffer_mgr_aead_chain_data(
rc = ssi_buffer_mgr_map_scatterlist(dev, req->dst, size_for_map,
DMA_BIDIRECTIONAL,
- &(areq_ctx->dst.nents),
+ &areq_ctx->dst.nents,
LLI_MAX_NUM_OF_DATA_ENTRIES,
&dst_last_bytes,
&dst_mapped_nents);
@@ -1407,7 +1407,7 @@ int ssi_buffer_mgr_map_aead_request(
if (is_gcm4543)
size_to_map += crypto_aead_ivsize(tfm);
rc = ssi_buffer_mgr_map_scatterlist(dev, req->src,
- size_to_map, DMA_BIDIRECTIONAL,
&(areq_ctx->src.nents),
+ size_to_map, DMA_BIDIRECTIONAL,
&areq_ctx->src.nents,
LLI_MAX_NUM_OF_ASSOC_DATA_ENTRIES +
LLI_MAX_NUM_OF_DATA_ENTRIES, &dummy, &mapped_nents);
if (unlikely(rc != 0)) {
rc = -ENOMEM;
diff --git a/drivers/staging/ccree/ssi_driver.c
b/drivers/staging/ccree/ssi_driver.c
index afb7c48..4246c9b 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -327,7 +327,7 @@ static int init_cc_resources(struct platform_device
*plat_dev)
}
#ifdef ENABLE_CC_SYSFS
- rc = ssi_sysfs_init(&(plat_dev->dev.kobj), new_drvdata);
+ rc = ssi_sysfs_init(&plat_dev->dev.kobj, new_drvdata);
if (unlikely(rc != 0)) {
SSI_LOG_ERR("init_stat_db failed\n");
goto init_cc_res_err;
diff --git a/drivers/staging/ccree/ssi_ivgen.c
b/drivers/staging/ccree/ssi_ivgen.c
index 5ff3368..025bff5 100644
--- a/drivers/staging/ccree/ssi_ivgen.c
+++ b/drivers/staging/ccree/ssi_ivgen.c
@@ -158,7 +158,7 @@ int ssi_ivgen_init_sram_pool(struct ssi_drvdata *drvdata)
void ssi_ivgen_fini(struct ssi_drvdata *drvdata)
{
struct ssi_ivgen_ctx *ivgen_ctx = drvdata->ivgen_handle;
- struct device *device = &(drvdata->plat_dev->dev);
+ struct device *device = &drvdata->pla
[PATCH 11/12] staging: ccree: kmalloc by sizeof var not type
Change places where we alloc memory by sizeof type to sizeof var.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c| 4 ++--
drivers/staging/ccree/ssi_cipher.c | 4 ++--
drivers/staging/ccree/ssi_driver.c | 2 +-
drivers/staging/ccree/ssi_hash.c| 4 ++--
drivers/staging/ccree/ssi_ivgen.c | 2 +-
drivers/staging/ccree/ssi_request_mgr.c | 2 +-
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index aa94839..15d05af 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -2659,7 +2659,7 @@ static struct ssi_crypto_alg *ssi_aead_create_alg(struct
ssi_alg_template *templ
struct ssi_crypto_alg *t_alg;
struct aead_alg *alg;
- t_alg = kzalloc(sizeof(struct ssi_crypto_alg), GFP_KERNEL);
+ t_alg = kzalloc(sizeof(*t_alg), GFP_KERNEL);
if (!t_alg) {
SSI_LOG_ERR("failed to allocate t_alg\n");
return ERR_PTR(-ENOMEM);
@@ -2714,7 +2714,7 @@ int ssi_aead_alloc(struct ssi_drvdata *drvdata)
int rc = -ENOMEM;
int alg;
- aead_handle = kmalloc(sizeof(struct ssi_aead_handle), GFP_KERNEL);
+ aead_handle = kmalloc(sizeof(*aead_handle), GFP_KERNEL);
if (!aead_handle) {
rc = -ENOMEM;
goto fail0;
diff --git a/drivers/staging/ccree/ssi_cipher.c
b/drivers/staging/ccree/ssi_cipher.c
index 3402022..06e6a89 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -1214,7 +1214,7 @@ struct ssi_crypto_alg *ssi_ablkcipher_create_alg(struct
ssi_alg_template *templa
struct ssi_crypto_alg *t_alg;
struct crypto_alg *alg;
- t_alg = kzalloc(sizeof(struct ssi_crypto_alg), GFP_KERNEL);
+ t_alg = kzalloc(sizeof(*t_alg), GFP_KERNEL);
if (!t_alg) {
SSI_LOG_ERR("failed to allocate t_alg\n");
return ERR_PTR(-ENOMEM);
@@ -1275,7 +1275,7 @@ int ssi_ablkcipher_alloc(struct ssi_drvdata *drvdata)
int rc = -ENOMEM;
int alg;
- ablkcipher_handle = kmalloc(sizeof(struct ssi_blkcipher_handle),
+ ablkcipher_handle = kmalloc(sizeof(*ablkcipher_handle),
GFP_KERNEL);
if (!ablkcipher_handle)
return -ENOMEM;
diff --git a/drivers/staging/ccree/ssi_driver.c
b/drivers/staging/ccree/ssi_driver.c
index d104dbd..1cae2b7 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -223,7 +223,7 @@ static int init_cc_resources(struct platform_device
*plat_dev)
struct resource *req_mem_cc_regs = NULL;
void __iomem *cc_base = NULL;
bool irq_registered = false;
- struct ssi_drvdata *new_drvdata = kzalloc(sizeof(struct ssi_drvdata),
GFP_KERNEL);
+ struct ssi_drvdata *new_drvdata = kzalloc(sizeof(*new_drvdata),
GFP_KERNEL);
struct device *dev = &plat_dev->dev;
struct device_node *np = dev->of_node;
u32 signature_val;
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index 292250e..11bbbc3 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -2060,7 +2060,7 @@ ssi_hash_create_alg(struct ssi_hash_template *template,
bool keyed)
struct crypto_alg *alg;
struct ahash_alg *halg;
- t_crypto_alg = kzalloc(sizeof(struct ssi_hash_alg), GFP_KERNEL);
+ t_crypto_alg = kzalloc(sizeof(*t_crypto_alg), GFP_KERNEL);
if (!t_crypto_alg) {
SSI_LOG_ERR("failed to allocate t_alg\n");
return ERR_PTR(-ENOMEM);
@@ -2224,7 +2224,7 @@ int ssi_hash_alloc(struct ssi_drvdata *drvdata)
int rc = 0;
int alg;
- hash_handle = kzalloc(sizeof(struct ssi_hash_handle), GFP_KERNEL);
+ hash_handle = kzalloc(sizeof(*hash_handle), GFP_KERNEL);
if (!hash_handle) {
SSI_LOG_ERR("kzalloc failed to allocate %zu B\n",
sizeof(struct ssi_hash_handle));
diff --git a/drivers/staging/ccree/ssi_ivgen.c
b/drivers/staging/ccree/ssi_ivgen.c
index c6f400f..8d6f8ad 100644
--- a/drivers/staging/ccree/ssi_ivgen.c
+++ b/drivers/staging/ccree/ssi_ivgen.c
@@ -191,7 +191,7 @@ int ssi_ivgen_init(struct ssi_drvdata *drvdata)
int rc;
/* Allocate "this" context */
- drvdata->ivgen_handle = kzalloc(sizeof(struct ssi_ivgen_ctx),
GFP_KERNEL);
+ drvdata->ivgen_handle = kzalloc(sizeof(*drvdata->ivgen_handle),
GFP_KERNEL);
if (!drvdata->ivgen_handle) {
SSI_LOG_ERR("Not enough memory to allocate IVGEN context (%zu
B)\n",
sizeof(struct ssi_ivgen_ctx));
diff --git a/drivers/staging/ccree/ssi_request_mgr.c
b/drivers/staging/ccree/ssi_request_mgr.c
index 9a4bb5c..cae9904 100644
--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -
[PATCH 10/12] staging: ccree: remove func name from log messages
The SSI_LOG macros already add __func__ to log messages, so remove
log message that add them a second time in the log message itself.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c | 4 ++--
drivers/staging/ccree/ssi_cipher.c | 14 +++---
drivers/staging/ccree/ssi_driver.c | 2 +-
drivers/staging/ccree/ssi_hash.c | 2 +-
drivers/staging/ccree/ssi_pm.c | 4 ++--
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index c6edef0..aa94839 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -2269,7 +2269,7 @@ static int ssi_gcm_setauthsize(struct crypto_aead
*authenc,
static int ssi_rfc4106_gcm_setauthsize(struct crypto_aead *authenc,
unsigned int authsize)
{
- SSI_LOG_DEBUG("ssi_rfc4106_gcm_setauthsize() authsize %d\n", authsize);
+ SSI_LOG_DEBUG("authsize %d\n", authsize);
switch (authsize) {
case 8:
@@ -2286,7 +2286,7 @@ static int ssi_rfc4106_gcm_setauthsize(struct crypto_aead
*authenc,
static int ssi_rfc4543_gcm_setauthsize(struct crypto_aead *authenc,
unsigned int authsize)
{
- SSI_LOG_DEBUG("ssi_rfc4543_gcm_setauthsize() authsize %d\n", authsize);
+ SSI_LOG_DEBUG("authsize %d\n", authsize);
if (authsize != 16)
return -EINVAL;
diff --git a/drivers/staging/ccree/ssi_cipher.c
b/drivers/staging/ccree/ssi_cipher.c
index 7e34236..3402022 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -304,7 +304,7 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
ctx_p, crypto_tfm_alg_name(tfm), keylen);
dump_byte_array("key", (u8 *)key, keylen);
- SSI_LOG_DEBUG("ssi_blkcipher_setkey: after FIPS check");
+ SSI_LOG_DEBUG("after FIPS check");
/* STAT_PHASE_0: Init and sanity checks */
@@ -350,7 +350,7 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
}
ctx_p->keylen = keylen;
- SSI_LOG_DEBUG("ssi_blkcipher_setkey: ssi_is_hw_key ret 0");
+ SSI_LOG_DEBUG("ssi_is_hw_key ret 0");
return 0;
}
@@ -360,19 +360,19 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
if (unlikely(!des_ekey(tmp, key)) &&
(crypto_tfm_get_flags(tfm) & CRYPTO_TFM_REQ_WEAK_KEY)) {
tfm->crt_flags |= CRYPTO_TFM_RES_WEAK_KEY;
- SSI_LOG_DEBUG("ssi_blkcipher_setkey: weak DES key");
+ SSI_LOG_DEBUG("weak DES key");
return -EINVAL;
}
}
if ((ctx_p->cipher_mode == DRV_CIPHER_XTS) &&
xts_check_key(tfm, key, keylen) != 0) {
- SSI_LOG_DEBUG("ssi_blkcipher_setkey: weak XTS key");
+ SSI_LOG_DEBUG("weak XTS key");
return -EINVAL;
}
if ((ctx_p->flow_mode == S_DIN_to_DES) &&
(keylen == DES3_EDE_KEY_SIZE) &&
ssi_verify_3des_keys(key, keylen) != 0) {
- SSI_LOG_DEBUG("ssi_blkcipher_setkey: weak 3DES key");
+ SSI_LOG_DEBUG("weak 3DES key");
return -EINVAL;
}
@@ -387,7 +387,7 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
if (ctx_p->key_round_number < CC_MULTI2_MIN_NUM_ROUNDS ||
ctx_p->key_round_number > CC_MULTI2_MAX_NUM_ROUNDS) {
crypto_tfm_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
- SSI_LOG_DEBUG("ssi_blkcipher_setkey: SSI_CC_HAS_MULTI2
einval");
+ SSI_LOG_DEBUG("SSI_CC_HAS_MULTI2 einval");
return -EINVAL;
#endif /*SSI_CC_HAS_MULTI2*/
} else {
@@ -414,7 +414,7 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
max_key_buf_size, DMA_TO_DEVICE);
ctx_p->keylen = keylen;
-SSI_LOG_DEBUG("ssi_blkcipher_setkey: return safely");
+SSI_LOG_DEBUG("return safely");
return 0;
}
diff --git a/drivers/staging/ccree/ssi_driver.c
b/drivers/staging/ccree/ssi_driver.c
index c07a028..d104dbd 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -81,7 +81,7 @@ void dump_byte_array(const char *name, const u8 *the_array,
unsigned long size)
char line_buf[80];
if (!the_array) {
- SSI_LOG_ERR("cannot dump_byte_array - NULL pointer\n");
+ SSI_LOG_ERR("cannot dump array - NULL pointer\n");
return;
}
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index 9c9c48b..292250e 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -974,7 +974,7 @@ static int ssi_hash_setkey(void *hash,
[PATCH 09/12] staging: ccree: avoid unnecessary line continuation
Avoid unnecessary line continuation in log function call.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 8a1c408..c6edef0 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1864,8 +1864,9 @@ static inline void ssi_aead_dump_gcm(
SSI_LOG_DEBUG("%s\n", title);
}
- SSI_LOG_DEBUG("cipher_mode %d, authsize %d, enc_keylen %d, assoclen %d,
cryptlen %d\n", \
-ctx->cipher_mode, ctx->authsize,
ctx->enc_keylen, req->assoclen, req_ctx->cryptlen);
+ SSI_LOG_DEBUG("cipher_mode %d, authsize %d, enc_keylen %d, assoclen %d,
cryptlen %d\n",
+ ctx->cipher_mode, ctx->authsize, ctx->enc_keylen,
+ req->assoclen, req_ctx->cryptlen);
if (ctx->enckey)
dump_byte_array("mac key", ctx->enckey, 16);
--
2.1.4
[PATCH 12/12] staging: ccree: remove whitespace before a quoted newline
Remove unnecessary whitespace before a quoted newline in strings.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_cipher.c | 6 +++---
drivers/staging/ccree/ssi_hash.c | 2 +-
drivers/staging/ccree/ssi_sysfs.c | 10 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/ccree/ssi_cipher.c
b/drivers/staging/ccree/ssi_cipher.c
index 06e6a89..e09fe03 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -614,14 +614,14 @@ ssi_blkcipher_create_data_desc(
break;
#endif /*SSI_CC_HAS_MULTI2*/
default:
- SSI_LOG_ERR("invalid flow mode, flow_mode = %d \n", flow_mode);
+ SSI_LOG_ERR("invalid flow mode, flow_mode = %d\n", flow_mode);
return;
}
/* Process */
if (likely(req_ctx->dma_buf_type == SSI_DMA_BUF_DLLI)) {
- SSI_LOG_DEBUG(" data params addr %pad length 0x%X \n",
+ SSI_LOG_DEBUG(" data params addr %pad length 0x%X\n",
sg_dma_address(src), nbytes);
- SSI_LOG_DEBUG(" data params addr %pad length 0x%X \n",
+ SSI_LOG_DEBUG(" data params addr %pad length 0x%X\n",
sg_dma_address(dst), nbytes);
hw_desc_init(&desc[*seq_size]);
set_din_type(&desc[*seq_size], DMA_DLLI, sg_dma_address(src),
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index 11bbbc3..713be20 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -1552,7 +1552,7 @@ static int ssi_mac_finup(struct ahash_request *req)
SSI_LOG_DEBUG("= finup xcbc(%d) \n", req->nbytes);
if (state->xcbc_count > 0 && req->nbytes == 0) {
- SSI_LOG_DEBUG("No data to update. Call to fdx_mac_final \n");
+ SSI_LOG_DEBUG("No data to update. Call to fdx_mac_final\n");
return ssi_mac_final(req);
}
diff --git a/drivers/staging/ccree/ssi_sysfs.c
b/drivers/staging/ccree/ssi_sysfs.c
index 802fd49..0655658 100644
--- a/drivers/staging/ccree/ssi_sysfs.c
+++ b/drivers/staging/ccree/ssi_sysfs.c
@@ -287,15 +287,15 @@ static ssize_t ssi_sys_regdump_show(struct kobject *kobj,
int offset = 0;
register_value = CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF,
HOST_SIGNATURE));
- offset += scnprintf(buf + offset, PAGE_SIZE - offset, "%s \t(0x%lX)\t
0x%08X \n", "HOST_SIGNATURE ", DX_HOST_SIGNATURE_REG_OFFSET,
register_value);
+ offset += scnprintf(buf + offset, PAGE_SIZE - offset, "%s \t(0x%lX)\t
0x%08X\n", "HOST_SIGNATURE ", DX_HOST_SIGNATURE_REG_OFFSET,
register_value);
register_value = CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF,
HOST_IRR));
- offset += scnprintf(buf + offset, PAGE_SIZE - offset, "%s \t(0x%lX)\t
0x%08X \n", "HOST_IRR ", DX_HOST_IRR_REG_OFFSET, register_value);
+ offset += scnprintf(buf + offset, PAGE_SIZE - offset, "%s \t(0x%lX)\t
0x%08X\n", "HOST_IRR ", DX_HOST_IRR_REG_OFFSET, register_value);
register_value = CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF,
HOST_POWER_DOWN_EN));
- offset += scnprintf(buf + offset, PAGE_SIZE - offset, "%s \t(0x%lX)\t
0x%08X \n", "HOST_POWER_DOWN_EN ", DX_HOST_POWER_DOWN_EN_REG_OFFSET,
register_value);
+ offset += scnprintf(buf + offset, PAGE_SIZE - offset, "%s \t(0x%lX)\t
0x%08X\n", "HOST_POWER_DOWN_EN ", DX_HOST_POWER_DOWN_EN_REG_OFFSET,
register_value);
register_value = CC_HAL_READ_REGISTER(CC_REG_OFFSET(CRY_KERNEL,
AXIM_MON_ERR));
- offset += scnprintf(buf + offset, PAGE_SIZE - offset, "%s \t(0x%lX)\t
0x%08X \n", "AXIM_MON_ERR ", DX_AXIM_MON_ERR_REG_OFFSET,
register_value);
+ offset += scnprintf(buf + offset, PAGE_SIZE - offset, "%s \t(0x%lX)\t
0x%08X\n", "AXIM_MON_ERR ", DX_AXIM_MON_ERR_REG_OFFSET, register_value);
register_value = CC_HAL_READ_REGISTER(CC_REG_OFFSET(CRY_KERNEL,
DSCRPTR_QUEUE_CONTENT));
- offset += scnprintf(buf + offset, PAGE_SIZE - offset, "%s \t(0x%lX)\t
0x%08X \n", "DSCRPTR_QUEUE_CONTENT", DX_DSCRPTR_QUEUE_CONTENT_REG_OFFSET,
register_value);
+ offset += scnprintf(buf + offset, PAGE_SIZE - offset, "%s \t(0x%lX)\t
0x%08X\n", "DSCRPTR_QUEUE_CONTENT", DX_DSCRPTR_QUEUE_CONTENT_REG_OFFSET,
register_value);
return offset;
}
--
2.1.4
[PATCH 07/12] staging: ccree: CamelCase to snake_case in aead struct
Rename aead_req_struct fields from CamelCase to snake_case.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c | 26 ++--
drivers/staging/ccree/ssi_aead.h | 12 +++---
drivers/staging/ccree/ssi_buffer_mgr.c | 78 +-
3 files changed, 58 insertions(+), 58 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 6d5cf02..dab4914 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -251,8 +251,8 @@ static void ssi_aead_complete(struct device *dev, void
*ssi_req, void __iomem *c
} else { /*ENCRYPT*/
if (unlikely(areq_ctx->is_icv_fragmented))
ssi_buffer_mgr_copy_scatterlist_portion(
- areq_ctx->mac_buf, areq_ctx->dstSgl,
areq->cryptlen + areq_ctx->dstOffset,
- areq->cryptlen + areq_ctx->dstOffset +
ctx->authsize, SSI_SG_FROM_BUF);
+ areq_ctx->mac_buf, areq_ctx->dst_sgl,
areq->cryptlen + areq_ctx->dst_offset,
+ areq->cryptlen + areq_ctx->dst_offset +
ctx->authsize, SSI_SG_FROM_BUF);
/* If an IV was generated, copy it back to the user provided
buffer. */
if (areq_ctx->backup_giv) {
@@ -777,11 +777,11 @@ ssi_aead_process_authenc_data_desc(
{
struct scatterlist *cipher =
(direct == DRV_CRYPTO_DIRECTION_ENCRYPT) ?
- areq_ctx->dstSgl : areq_ctx->srcSgl;
+ areq_ctx->dst_sgl : areq_ctx->src_sgl;
unsigned int offset =
(direct == DRV_CRYPTO_DIRECTION_ENCRYPT) ?
- areq_ctx->dstOffset : areq_ctx->srcOffset;
+ areq_ctx->dst_offset : areq_ctx->src_offset;
SSI_LOG_DEBUG("AUTHENC: SRC/DST buffer type DLLI\n");
hw_desc_init(&desc[idx]);
set_din_type(&desc[idx], DMA_DLLI,
@@ -843,11 +843,11 @@ ssi_aead_process_cipher_data_desc(
SSI_LOG_DEBUG("CIPHER: SRC/DST buffer type DLLI\n");
hw_desc_init(&desc[idx]);
set_din_type(&desc[idx], DMA_DLLI,
-(sg_dma_address(areq_ctx->srcSgl) +
- areq_ctx->srcOffset), areq_ctx->cryptlen, NS_BIT);
+(sg_dma_address(areq_ctx->src_sgl) +
+ areq_ctx->src_offset), areq_ctx->cryptlen,
NS_BIT);
set_dout_dlli(&desc[idx],
- (sg_dma_address(areq_ctx->dstSgl) +
- areq_ctx->dstOffset),
+ (sg_dma_address(areq_ctx->dst_sgl) +
+ areq_ctx->dst_offset),
areq_ctx->cryptlen, NS_BIT, 0);
set_flow_mode(&desc[idx], flow_mode);
break;
@@ -1880,7 +1880,7 @@ static inline void ssi_aead_dump_gcm(
dump_byte_array("mac_buf", req_ctx->mac_buf, AES_BLOCK_SIZE);
- dump_byte_array("gcm_len_block", req_ctx->gcm_len_block.lenA,
AES_BLOCK_SIZE);
+ dump_byte_array("gcm_len_block", req_ctx->gcm_len_block.len_a,
AES_BLOCK_SIZE);
if (req->src && req->cryptlen)
dump_byte_array("req->src", sg_virt(req->src), req->cryptlen +
req->assoclen);
@@ -1919,16 +1919,16 @@ static int config_gcm_context(struct aead_request *req)
__be64 temp64;
temp64 = cpu_to_be64(req->assoclen * 8);
- memcpy(&req_ctx->gcm_len_block.lenA, &temp64, sizeof(temp64));
+ memcpy(&req_ctx->gcm_len_block.len_a, &temp64, sizeof(temp64));
temp64 = cpu_to_be64(cryptlen * 8);
- memcpy(&req_ctx->gcm_len_block.lenC, &temp64, 8);
+ memcpy(&req_ctx->gcm_len_block.len_c, &temp64, 8);
} else { //rfc4543=> all data(AAD,IV,Plain) are considered additional
data that is nothing is encrypted.
__be64 temp64;
temp64 = cpu_to_be64((req->assoclen + GCM_BLOCK_RFC4_IV_SIZE +
cryptlen) * 8);
- memcpy(&req_ctx->gcm_len_block.lenA, &temp64, sizeof(temp64));
+ memcpy(&req_ctx->gcm_len_block.len_a, &temp64, sizeof(temp64));
temp64 = 0;
- memcpy(&req_ctx->gcm_len_block.lenC, &temp64, 8);
+ memcpy(&req_ctx->gcm_len_block.len_c, &temp64, 8);
}
return 0;
diff --git a/drivers/staging/ccree/ssi_aead.h b/drivers/staging/ccree/ssi_aead.h
index 39cc633..e85bcd9 100644
--- a/drivers/staging/ccree/ssi_aead.h
+++ b/drivers/staging/ccree/ssi_aead.h
@@ -69,8 +69,8 @@ struct aead_req_ctx {
u8 gcm_iv_inc2[AES_BLOCK_SIZE] cacheline_aligned;
u8 hkey[AES_BLOCK_SIZE] cacheline_aligned;
struct {
- u8 lenA[GCM_BLOCK_LEN_SIZE] cacheline_aligned;
- u8
[PATCH 05/12] staging: ccree: fix split strings
Fix strings in log messages being split across lines and the resulting
alignment issues when being fixed.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c| 9 ++--
drivers/staging/ccree/ssi_buffer_mgr.c | 86 ++---
drivers/staging/ccree/ssi_cipher.c | 27 +--
drivers/staging/ccree/ssi_driver.c | 4 +-
drivers/staging/ccree/ssi_hash.c| 43 -
drivers/staging/ccree/ssi_ivgen.c | 8 +--
drivers/staging/ccree/ssi_request_mgr.c | 13 ++---
7 files changed, 81 insertions(+), 109 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 51a2b73..2d6ba8d 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -240,9 +240,8 @@ static void ssi_aead_complete(struct device *dev, void
*ssi_req, void __iomem *c
if (areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) {
if (memcmp(areq_ctx->mac_buf, areq_ctx->icv_virt_addr,
ctx->authsize) != 0) {
- SSI_LOG_DEBUG("Payload authentication failure, "
- "(auth-size=%d, cipher=%d).\n",
- ctx->authsize, ctx->cipher_mode);
+ SSI_LOG_DEBUG("Payload authentication failure,
(auth-size=%d, cipher=%d).\n",
+ ctx->authsize, ctx->cipher_mode);
/* In case of payload authentication failure, MUST NOT
* revealed the decrypted message --> zero its memory.
*/
@@ -455,8 +454,8 @@ ssi_get_plain_hmac_key(struct crypto_aead *tfm, const u8
*key, unsigned int keyl
if (likely(keylen != 0)) {
key_dma_addr = dma_map_single(dev, (void *)key, keylen,
DMA_TO_DEVICE);
if (unlikely(dma_mapping_error(dev, key_dma_addr))) {
- SSI_LOG_ERR("Mapping key va=0x%p len=%u for"
- " DMA failed\n", key, keylen);
+ SSI_LOG_ERR("Mapping key va=0x%p len=%u for DMA
failed\n",
+ key, keylen);
return -ENOMEM;
}
if (keylen > blocksize) {
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c
b/drivers/staging/ccree/ssi_buffer_mgr.c
index c3960d1..ed3945b 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -82,8 +82,8 @@ static unsigned int ssi_buffer_mgr_get_sgl_nents(
while (nbytes != 0) {
if (sg_is_chain(sg_list)) {
- SSI_LOG_ERR("Unexpected chained entry "
- "in sg (entry =0x%X)\n", nents);
+ SSI_LOG_ERR("Unexpected chained entry in sg (entry
=0x%X)\n",
+ nents);
BUG();
}
if (sg_list->length != 0) {
@@ -258,11 +258,9 @@ static int ssi_buffer_mgr_generate_mlli(
/* Set MLLI size for the bypass operation */
mlli_params->mlli_len = (total_nents * LLI_ENTRY_BYTE_SIZE);
- SSI_LOG_DEBUG("MLLI params: "
-"virt_addr=%pK dma_addr=%pad mlli_len=0x%X\n",
- mlli_params->mlli_virt_addr,
- mlli_params->mlli_dma_addr,
- mlli_params->mlli_len);
+ SSI_LOG_DEBUG("MLLI params: virt_addr=%pK dma_addr=%pad
mlli_len=0x%X\n",
+ mlli_params->mlli_virt_addr, mlli_params->mlli_dma_addr,
+ mlli_params->mlli_len);
build_mlli_exit:
return rc;
@@ -275,9 +273,8 @@ static inline void ssi_buffer_mgr_add_buffer_entry(
{
unsigned int index = sgl_data->num_of_buffers;
- SSI_LOG_DEBUG("index=%u single_buff=%pad "
-"buffer_len=0x%08X is_last=%d\n",
-index, buffer_dma, buffer_len, is_last_entry);
+ SSI_LOG_DEBUG("index=%u single_buff=%pad buffer_len=0x%08X
is_last=%d\n",
+ index, buffer_dma, buffer_len, is_last_entry);
sgl_data->nents[index] = 1;
sgl_data->entry[index].buffer_dma = buffer_dma;
sgl_data->offset[index] = 0;
@@ -358,8 +355,7 @@ static int ssi_buffer_mgr_map_scatterlist(
SSI_LOG_ERR("dma_map_sg() single buffer failed\n");
return -ENOMEM;
}
- SSI_LOG_DEBUG("Mapped sg: dma_address=%pad "
-"page=%p addr=%pK offset=%u "
+ SSI_LOG_DEBUG("Mapped sg: dma_address=%pad page=%p addr=%pK
offset=%u "
"length=%u\n",
sg_dma_address(sg),
sg_page(sg),
@@ -418,12 +414,10 @@ ssi_aead_handle_config_buf(struct device *dev,
sg_init_one(&areq_ctx->ccm_adata_sg, config_data, AES_BLOCK_SIZE +
areq_ctx->ccm_hdr_s
[PATCH 08/12] staging: ccree: avoid constant comparison
Re-write predicate to avoid constant comparison.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index dab4914..8a1c408 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1573,7 +1573,7 @@ static int config_ccm_adata(struct aead_request *req)
/* taken from crypto/ccm.c */
/* 2 <= L <= 8, so 1 <= L' <= 7. */
- if (2 > l || l > 8) {
+ if (l < 2 || l > 8) {
SSI_LOG_ERR("illegal iv value %X\n", req->iv[0]);
return -EINVAL;
}
--
2.1.4
Re: [PATCH v3 7/9] vfio: Use driver_override to avert binding to compromising drivers
On Tue, Jul 11, 2017 at 10:41:16AM -0600, Alex Williamson wrote: > Let me give a concrete scenario, I have a dual-port conventional PCI > e1000 NIC. The IOMMU operates on PCIe requester IDs and therefore both > NIC functions are masked behind the requester ID of a PCIe-to-PCI > bridge. We cannot have the e1000 driver managing one function and a > user managing the other (via vfio-pci). Agreed, but really, if a user asks to do such a thing, they deserve the pieces the kernel ends up in, right? > In this case, not only is the > DMA not isolated but the functions share the same IOMMU context. > Therefore in order to allow the user access to one function via > vfio-pci, the other function needs to be in a known state, either also > bound to vfio-pci, bound to an innocuous driver like pci-stub, or > unbound from any driver. Given this state, user now has access to one > function of the device, but how can we fix our driver to manage the > other function? We have USB drivers that do this all the time, due to crazy USB specs that required it. The cdc-acm driver is one example, and I think there are a number of USB sound devices that also have this issue. Just have the driver of the "first" device grab the second one as well and "know" about the resources involved, as you are doing today. But, then you somehow seem to have the requirement to prevent userspace from mucking around in your driver bindings, and really, you shouldn't care about this, because again, if it messes up here, all bets are off. > If the other function is also bound to vfio-pci, the driver core does > not allow us to refuse a driver remove request, the best we can do is > block for a while, but we best not do that too long so we end up in the > device unbound state. > > Likewise, if the other function was bound to pci-stub, this driver won't > block remove, so the device for the other port can transition to an > unbound state. > > Once in an unbound state, how would fixing either the vfio-pci or the > core vfio driver prevent the scenario which can now happen of the > unbound device being bound to the host e1000 driver? This can happen > in pure PCIe topologies as well where perhaps the IOMMU context is not > shared, but the devices still lack DMA isolation within the group. > > The only tool we currently have to manage this scenario is that the > vfio core driver can pull BUG_ON after the fact of the other device > being bound to a host driver. Well, how about just locking the device down, don't crash the kernel. That at least gives userspace a chance to figure out what they did was wrong. > Understandably, users aren't so keen on > this, which is why I'm trying to allow vfio to block binding of that > other device before it happens. None of this really seems to fall > within the capabilities of the existing driver core, so simply fixing > my driver doesn't seem to be a well defined option. Is there a simple > solution I'm missing? We're not concerned only with auto-probing, we > need to protect against explicit bind attempts as well. Again, if userspace does an explicit bind/unbind attempt, it _HAS_ to know what it is doing, we can't protect ourselves from that, that's always been the case. The bind/unbind was done as a way for people to say "I know more about what is going on than the kernel does right now, so I'm going to override it." and we have to trust that they do know that. Don't spend a lot of time and energy trying to protect yourself from that please. thanks, greg k-h
Re: [PATCH v12 6/8] mm: support reporting free page blocks
On 07/13/2017 08:33 AM, Michael S. Tsirkin wrote:
On Wed, Jul 12, 2017 at 08:40:19PM +0800, Wei Wang wrote:
This patch adds support for reporting blocks of pages on the free list
specified by the caller.
As pages can leave the free list during this call or immediately
afterwards, they are not guaranteed to be free after the function
returns. The only guarantee this makes is that the page was on the free
list at some point in time after the function has been invoked.
Therefore, it is not safe for caller to use any pages on the returned
block or to discard data that is put there after the function returns.
However, it is safe for caller to discard data that was in one of these
pages before the function was invoked.
Signed-off-by: Wei Wang
Signed-off-by: Liang Li
---
include/linux/mm.h | 5 +++
mm/page_alloc.c| 96 ++
2 files changed, 101 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 46b9ac5..76cb433 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1835,6 +1835,11 @@ extern void free_area_init_node(int nid, unsigned long *
zones_size,
unsigned long zone_start_pfn, unsigned long *zholes_size);
extern void free_initmem(void);
+#if IS_ENABLED(CONFIG_VIRTIO_BALLOON)
+extern int report_unused_page_block(struct zone *zone, unsigned int order,
+ unsigned int migratetype,
+ struct page **page);
+#endif
/*
* Free reserved pages within range [PAGE_ALIGN(start), end & PAGE_MASK)
* into the buddy system. The freed pages will be poisoned with pattern
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 64b7d82..8b3c9dd 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4753,6 +4753,102 @@ void show_free_areas(unsigned int filter, nodemask_t
*nodemask)
show_swap_cache_info();
}
+#if IS_ENABLED(CONFIG_VIRTIO_BALLOON)
+
+/*
+ * Heuristically get a page block in the system that is unused.
+ * It is possible that pages from the page block are used immediately after
+ * report_unused_page_block() returns. It is the caller's responsibility
+ * to either detect or prevent the use of such pages.
+ *
+ * The free list to check: zone->free_area[order].free_list[migratetype].
+ *
+ * If the caller supplied page block (i.e. **page) is on the free list, offer
+ * the next page block on the list to the caller. Otherwise, offer the first
+ * page block on the list.
+ *
+ * Note: it is not safe for caller to use any pages on the returned
+ * block or to discard data that is put there after the function returns.
+ * However, it is safe for caller to discard data that was in one of these
+ * pages before the function was invoked.
+ *
+ * Return 0 when a page block is found on the caller specified free list.
Otherwise?
Other values mean that no page block is found. I will add them.
+ */
As an alternative, we could have an API that scans free pages
and invokes a callback under a lock. Granted, this might end up
staying a lot of time under a lock. Is this a big issue?
Some benchmarking will tell.
It would then be up to the hypervisor to decide whether it wants to play
tricks with the dirty bit or just wants to drop pages while VCPU is
stopped.
+int report_unused_page_block(struct zone *zone, unsigned int order,
+unsigned int migratetype, struct page **page)
+{
+ struct zone *this_zone;
+ struct list_head *this_list;
+ int ret = 0;
+ unsigned long flags;
+
+ /* Sanity check */
+ if (zone == NULL || page == NULL || order >= MAX_ORDER ||
+ migratetype >= MIGRATE_TYPES)
+ return -EINVAL;
Why do callers this?
+
+ /* Zone validity check */
+ for_each_populated_zone(this_zone) {
+ if (zone == this_zone)
+ break;
+ }
Why? Will take a long time if there are lots of zones.
+
+ /* Got a non-existent zone from the caller? */
+ if (zone != this_zone)
+ return -EINVAL;
When does this happen?
The above lines of code are just sanity check. If not
necessary, we can remove them.
+
+ spin_lock_irqsave(&this_zone->lock, flags);
+
+ this_list = &zone->free_area[order].free_list[migratetype];
+ if (list_empty(this_list)) {
+ *page = NULL;
+ ret = 1;
What does this mean?
Just means the list is empty, and expects the caller to try again
in the next list.
Probably, use "-EAGAIN" is better?
+ *page = list_first_entry(this_list, struct page, lru);
+ ret = 0;
+ goto out;
+ }
+
+ /*
+* The page block passed from the caller is not on this free list
+* anymore (e.g. a 1MB free page block has been split). In this case,
+* offer the first page block on the free list that the caller is
+* asking for.
This just might keep giv
Re: [PATCH 0/2] Workaround for uPD72020x USB3 chips
On Wed, Jul 12, 2017 at 10:12:34PM -0500, Bjorn Helgaas wrote: > On Mon, Jul 10, 2017 at 04:52:28PM +0100, Marc Zyngier wrote: > > Ard and myself have just spent quite some time lately trying to pin > > down an issue in the DMA code which was taking the form of a PCIe USB3 > > controller issuing a DMA access at some bizarre address, and being > > caught red-handed by the IOMMU. > > > > After much head scratching and most of a week-end spent on tracing the > > damn thing, I'm now convinced that the DMA code is fine, the XHCI > > driver is correct, but that the HW (a Renesas uPD720202 chip) is a > > nasty piece of work. > > > > The issue is as follow: > > > > - EFI initializes the controller using physical addresses above the > > 4GB limit (this is on an arm64 box where the memory starts at > > 0x80_...). > > > > - The kernel takes over, sends a XHCI reset to the controller, and > > because we have an IOMMU sitting between the controller and memory, > > provides *virtual* addresses. Trying to make things a bit faster for > > our controller, it issues IOVAs in the low 4GB range). > > > > - Low and behold, the controller is now issuing transactions with a > > 0x80 prefix in front of our IOVA. Yes, the same prefix that was > > programmed during the EFI configuration. IOMMU fault, not happy. > > > > If the kernel is hacked to only generate IOVAs that are more than > > 32bit wide, the HW behaves correctly. The only way I can explain this > > behaviour is that the HW latches the top 32bit of the ERST (it is > > always the ERST IOVA that appears in my traces) in some internal > > register, and that the XHCI reset fails to clear it. Writing zero in > > the top bits is not enough to clear it either. > > > > So far, the only solution we have for this lovely piece of kit is to > > force a PCI reset at probe time, which puts it right. The patches are > > pretty ugly, but that's the best I could come up with so far. > > > > Tested on a pair of AMD Opteron 1100 boxes with Renesas uPD720201 and > > uPD720202 controllers. > > > > Marc Zyngier (2): > > PCI: Implement pci_reset_function_locked > > usb: host: pci_quirks: Force hard reset of Renesas uPD72020x USB > > controller > > > > drivers/pci/pci.c | 35 +++ > > drivers/usb/host/pci-quirks.c | 20 > > drivers/usb/host/pci-quirks.h | 1 + > > drivers/usb/host/xhci-pci.c | 7 +++ > > include/linux/pci.h | 1 + > > 5 files changed, 64 insertions(+) > > I provisionally applied this to pci/virtualization. I'd like to have an > XHCI ack before going further, though. The xhci maintainer is on vacation, let's wait a week for him to get back to get this. Given the long time that this has been broken on this hardware, I think we can wait another week just fine :) thanks, greg k-h
[PATCH] crypto: brcm - Support more FlexRM rings than SPU engines.
Enhance code to generically support cases where DMA rings
are greater than or equal to number of SPU engines.
New hardware has underlying DMA engine-FlexRM with 32 rings
which can be used to communicate to any of the available
10 SPU engines.
Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
Signed-off-by: Raveendra Padasalagi
cc: sta...@vger.kernel.org
---
drivers/crypto/bcm/cipher.c | 105 +---
drivers/crypto/bcm/cipher.h | 15 ---
2 files changed, 57 insertions(+), 63 deletions(-)
diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index cc0d5b9..ecc32d8 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -119,7 +119,7 @@ static u8 select_channel(void)
{
u8 chan_idx = atomic_inc_return(&iproc_priv.next_chan);
- return chan_idx % iproc_priv.spu.num_spu;
+ return chan_idx % iproc_priv.spu.num_chan;
}
/**
@@ -4527,8 +4527,13 @@ static void spu_functions_register(struct device *dev,
*/
static int spu_mb_init(struct device *dev)
{
- struct mbox_client *mcl = &iproc_priv.mcl[iproc_priv.spu.num_spu];
- int err;
+ struct mbox_client *mcl = &iproc_priv.mcl;
+ int err, i;
+
+ iproc_priv.mbox = devm_kcalloc(dev, iproc_priv.spu.num_chan,
+ sizeof(struct mbox_chan *), GFP_KERNEL);
+ if (iproc_priv.mbox == NULL)
+ return -ENOMEM;
mcl->dev = dev;
mcl->tx_block = false;
@@ -4537,15 +4542,16 @@ static int spu_mb_init(struct device *dev)
mcl->rx_callback = spu_rx_callback;
mcl->tx_done = NULL;
- iproc_priv.mbox[iproc_priv.spu.num_spu] =
- mbox_request_channel(mcl, 0);
- if (IS_ERR(iproc_priv.mbox[iproc_priv.spu.num_spu])) {
- err = (int)PTR_ERR(iproc_priv.mbox[iproc_priv.spu.num_spu]);
- dev_err(dev,
- "Mbox channel %d request failed with err %d",
- iproc_priv.spu.num_spu, err);
- iproc_priv.mbox[iproc_priv.spu.num_spu] = NULL;
- return err;
+ for (i = 0; i < iproc_priv.spu.num_chan; i++) {
+ iproc_priv.mbox[i] = mbox_request_channel(mcl, i);
+ if (IS_ERR(iproc_priv.mbox[i])) {
+ err = (int)PTR_ERR(iproc_priv.mbox[i]);
+ dev_err(dev,
+ "Mbox channel %d request failed with err %d",
+ i, err);
+ iproc_priv.mbox[i] = NULL;
+ return err;
+ }
}
return 0;
@@ -4555,7 +4561,7 @@ static void spu_mb_release(struct platform_device *pdev)
{
int i;
- for (i = 0; i < iproc_priv.spu.num_spu; i++)
+ for (i = 0; i < iproc_priv.spu.num_chan; i++)
mbox_free_channel(iproc_priv.mbox[i]);
}
@@ -4566,7 +4572,7 @@ static void spu_counters_init(void)
atomic_set(&iproc_priv.session_count, 0);
atomic_set(&iproc_priv.stream_count, 0);
- atomic_set(&iproc_priv.next_chan, (int)iproc_priv.spu.num_spu);
+ atomic_set(&iproc_priv.next_chan, (int)iproc_priv.spu.num_chan);
atomic64_set(&iproc_priv.bytes_in, 0);
atomic64_set(&iproc_priv.bytes_out, 0);
for (i = 0; i < SPU_OP_NUM; i++) {
@@ -4809,46 +4815,41 @@ static int spu_dt_read(struct platform_device *pdev)
const struct of_device_id *match;
const struct spu_type_subtype *matched_spu_type;
void __iomem *spu_reg_vbase[MAX_SPUS];
- int err;
+ struct device_node *dn = pdev->dev.of_node;
+ int err, i;
+
+ /* Count number of mailbox channels */
+ spu->num_chan = of_count_phandle_with_args(dn, "mboxes", "#mbox-cells");
match = of_match_device(of_match_ptr(bcm_spu_dt_ids), dev);
matched_spu_type = match->data;
- if (iproc_priv.spu.num_spu > 1) {
- /* If this is 2nd or later SPU, make sure it's same type */
- if ((spu->spu_type != matched_spu_type->type) ||
- (spu->spu_subtype != matched_spu_type->subtype)) {
- err = -EINVAL;
- dev_err(&pdev->dev, "Multiple SPU types not allowed");
- return err;
- }
- } else {
- /* Record type of first SPU */
- spu->spu_type = matched_spu_type->type;
- spu->spu_subtype = matched_spu_type->subtype;
- }
+ spu->spu_type = matched_spu_type->type;
+ spu->spu_subtype = matched_spu_type->subtype;
- /* Get and map SPU registers */
- spu_ctrl_regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!spu_ctrl_regs) {
- err = -EINVAL;
- dev_err(&pdev->dev, "Invalid/missing registers for SPU\n");
- return err;
- }
+ i = 0;
+ while ((i < MAX_SPUS) && ((spu
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods
On Wed, Jul 12, 2017 at 11:46:17AM -0700, Paul E. McKenney wrote: > So please let me know if rcu_needs_cpu() or rcu_prepare_for_idle() are > prominent contributors to to-idle latency. Right, some actual data would be good.
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods
On Wed, Jul 12, 2017 at 02:32:40PM -0700, Andi Kleen wrote: > On Wed, Jul 12, 2017 at 10:34:10AM +0200, Peter Zijlstra wrote: > > On Wed, Jul 12, 2017 at 12:15:08PM +0800, Li, Aubrey wrote: > > > Okay, the difference is that Mike's patch uses a very simple algorithm to > > > make the decision. > > > > No, the difference is that we don't end up with duplication of a metric > > ton of code. > > What do you mean? There isn't much duplication from the fast path > in Aubrey's patch kit. A whole second idle path is one too many. We're not going to have duplicate idle paths. > It just moves some code around from the cpuidle governor to be generic, > that accounts for the bulk of the changes. It's just moving however, > not adding. It wasn't at first glance evident it was a pure move because he does it over a bunch of patches. Also, that code will not be moved to the generic code, people are working on alternatives and very much rely on this being a governor thing. > > It uses the normal idle path, it just makes the NOHZ enter fail. > > Which is only a small part of the problem. Given the data so far provided it was by far the biggest problem. If you want more things changed, you really have to give more data.
Re: [virtio-dev] Re: [PATCH v12 7/8] mm: export symbol of next_zone and first_online_pgdat
On 07/13/2017 08:16 AM, Michael S. Tsirkin wrote:
On Wed, Jul 12, 2017 at 08:40:20PM +0800, Wei Wang wrote:
This patch enables for_each_zone()/for_each_populated_zone() to be
invoked by a kernel module.
... for use by virtio balloon.
With this patch, other kernel modules can also use the for_each_zone().
Would it be better to claim it broader?
Signed-off-by: Wei Wang
balloon seems to only use
+ for_each_populated_zone(zone)
+ for_each_migratetype_order(order, type)
Yes. using for_each_populated_zone() requires the following export.
Best,
Wei
---
mm/mmzone.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/mmzone.c b/mm/mmzone.c
index a51c0a6..08a2a3a 100644
--- a/mm/mmzone.c
+++ b/mm/mmzone.c
@@ -13,6 +13,7 @@ struct pglist_data *first_online_pgdat(void)
{
return NODE_DATA(first_online_node);
}
+EXPORT_SYMBOL_GPL(first_online_pgdat);
struct pglist_data *next_online_pgdat(struct pglist_data *pgdat)
{
@@ -41,6 +42,7 @@ struct zone *next_zone(struct zone *zone)
}
return zone;
}
+EXPORT_SYMBOL_GPL(next_zone);
static inline int zref_in_nodemask(struct zoneref *zref, nodemask_t *nodes)
{
--
2.7.4
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [PATCH v3 0/7] Enhance libsas hotplug feature
在 2017/7/13 16:08, John Garry 写道: > On 13/07/2017 02:37, wangyijing wrote: >>> > So much nicer. BTW, /dev/sdb is a SATA disk, the rest are SAS. >> Oh, I take a mistake ? The result you tested the hotplug which applied this >> patchset is fine ? >> >> Thanks! >> Yijing. > > Well basic hotplug is fine, as below. I did not do any robust testing. > OK， thanks，I tested with and without fio running, the results are both fine. Thanks! Yijing. > root@(none)$ echo 0 > ./phy-0:7/sas_phy/phy-0:7/enable > root@(none)$ [ 180.147676] hisi_sas_v2_hw HISI0162:01: found dev[8:1] is gone > [ 180.216558] hisi_sas_v2_hw HISI0162:01: found dev[7:1] is gone > [ 180.280548] hisi_sas_v2_hw HISI0162:01: found dev[6:1] is gone > [ 180.352556] hisi_sas_v2_hw HISI0162:01: found dev[5:1] is gone > [ 180.432495] hisi_sas_v2_hw HISI0162:01: found dev[4:1] is gone > [ 180.508492] hisi_sas_v2_hw HISI0162:01: found dev[3:1] is gone > [ 180.527577] sd 0:0:1:0: [sdb] Synchronizing SCSI cache > [ 180.532728] sd 0:0:1:0: [sdb] Synchronize Cache(10) failed: Result: > hostbyte=0x04 driverbyte=0x00 > [ 180.541591] sd 0:0:1:0: [sdb] Stopping disk > [ 180.545767] sd 0:0:1:0: [sdb] Start/Stop Unit failed: Result: > hostbyte=0x04 driverbyte=0x00 > [ 180.612491] hisi_sas_v2_hw HISI0162:01: found dev[2:5] is gone > [ 180.696452] hisi_sas_v2_hw HISI0162:01: found dev[1:1] is gone > [ 180.703221] hisi_sas_v2_hw HISI0162:01: found dev[0:2] is gone > > root@(none)$ echo 1 > ./phy-0:7/sas_phy/phy-0:7/enable > root@(none)$ [ 185.937831] hisi_sas_v2_hw HISI0162:01: phyup: phy7 > link_rate=11 > [ 185.996575] scsi 0:0:8:0: Direct-Access SanDisk LT0200MO P404 PQ: 0 > ANSI: 6 > [ 187.059642] ata2.00: ATA-8: HGST HUS724040ALA640, MFAOA8B0, max UDMA/133 > [ 187.066341] ata2.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 31/32) > [ 187.073278] ata2.00: ATA Identify Device Log not supported > [ 187.078755] ata2.00: Security Log not supported > [ 187.085239] ata2.00: ATA Identify Device Log not supported > [ 187.090715] ata2.00: Security Log not supported > [ 187.095236] ata2.00: configured for UDMA/133 > [ 187.136917] scsi 0:0:9:0: Direct-Access ATA HGST HUS724040AL A8B0 > PQ: 0 ANSI: 5 > [ 187.187612] sd 0:0:9:0: [sdb] 7814037168 512-byte logical blocks: (4.00 > TB/3.64 TiB) > [ 187.195365] sd 0:0:9:0: [sdb] Write Protect is off > [ 187.200161] sd 0:0:9:0: [sdb] Write cache: enabled, read cache: enabled, > doesn't support DPO or FUA > [ 187.223844] sd 0:0:9:0: [sdb] Attached SCSI disk > [ 187.225498] scsi 0:0:10:0: Direct-Access SanDisk LT0200MO P404 PQ: 0 > ANSI: 6 > [ 187.243864] sd 0:0:8:0: [sda] 390721968 512-byte logical blocks: (200 > GB/186 GiB) > [ 187.285879] sd 0:0:8:0: [sda] Write Protect is off > [ 187.367898] sd 0:0:8:0: [sda] Write cache: disabled, read cache: disabled, > supports DPO and FUA > [ 187.524043] scsi 0:0:11:0: Direct-Access SanDisk LT0200MO P404 PQ: 0 > ANSI: 6 > [ 187.701505] sd 0:0:10:0: [sdc] 390721968 512-byte logical blocks: (200 > GB/186 GiB) > [ 187.743547] sd 0:0:10:0: [sdc] Write Protect is off > [ 187.822546] scsi 0:0:12:0: Direct-Access SanDisk LT0200MO P404 PQ: 0 > ANSI: 6 > [ 187.825531] sd 0:0:10:0: [sdc] Write cache: disabled, read cache: > disabled, supports DPO and FUA > [ 188.000167] sd 0:0:11:0: [sdd] 390721968 512-byte logical blocks: (200 > GB/186 GiB) > [ 188.042205] sd 0:0:11:0: [sdd] Write Protect is off > [ 188.121527] scsi 0:0:13:0: Direct-Access SanDisk LT0200MO P404 PQ: 0 > ANSI: 6 > [ 188.124274] sd 0:0:11:0: [sdd] Write cache: disabled, read cache: > disabled, supports DPO and FUA > [ 188.298942] sd 0:0:12:0: [sde] 390721968 512-byte logical blocks: (200 > GB/186 GiB) > [ 188.340960] sd 0:0:12:0: [sde] Write Protect is off > [ 188.420023] scsi 0:0:14:0: Direct-Access SanDisk LT0200MO P404 PQ: 0 > ANSI: 6 > [ 188.422969] sd 0:0:12:0: [sde] Write cache: disabled, read cache: > disabled, supports DPO and FUA > [ 188.597501] sd 0:0:13:0: [sdf] 390721968 512-byte logical blocks: (200 > GB/186 GiB) > [ 188.605069] sd 0:0:8:0: [sda] Attached SCSI disk > [ 188.639520] sd 0:0:13:0: [sdf] Write Protect is off > [ 188.682445] scsi 0:0:15:0: Enclosure 12G SAS Expander RevB PQ: 0 > ANSI: 6 > [ 188.721540] sd 0:0:13:0: [sdf] Write cache: disabled, read cache: > disabled, supports DPO and FUA > [ 188.896399] sd 0:0:14:0: [sdg] 390721968 512-byte logical blocks: (200 > GB/186 GiB) > [ 188.938445] sd 0:0:14:0: [sdg] Write Protect is off > [ 189.020444] sd 0:0:14:0: [sdg] Write cache: disabled, read cache: > disabled, supports DPO and FUA > [ 189.060608] sd 0:0:10:0: [sdc] Attached SCSI disk > [ 189.359073] sd 0:0:11:0: [sdd] Attached SCSI disk > [ 189.657643] sd 0:0:12:0: [sde] Attached SCSI disk > [ 189.956585] sd 0:0:13:0: [sdf] Attached SCSI disk > [ 190.255148] sd 0:0:14:0: [sdg] Attached SCSI disk > > root@(none)$ echo 0 > ./phy-0:7/sas_phy/phy-0:7/enable > root@(none)$ [ 19
Re: [PATCH v12 8/8] virtio-balloon: VIRTIO_BALLOON_F_CMD_VQ
On 07/13/2017 08:22 AM, Michael S. Tsirkin wrote:
On Wed, Jul 12, 2017 at 08:40:21PM +0800, Wei Wang wrote:
Add a new vq, cmdq, to handle requests between the device and driver.
This patch implements two commands sent from the device and handled in
the driver.
1) VIRTIO_BALLOON_CMDQ_REPORT_STATS: this command is used to report
the guest memory statistics to the host. The stats_vq mechanism is not
used when the cmdq mechanism is enabled.
2) VIRTIO_BALLOON_CMDQ_REPORT_UNUSED_PAGES: this command is used to
report the guest unused pages to the host.
Since now we have a vq to handle multiple commands, we need to keep only
one vq operation at a time. Here, we change the existing START_USE()
and END_USE() to lock on each vq operation.
Signed-off-by: Wei Wang
Signed-off-by: Liang Li
---
drivers/virtio/virtio_balloon.c | 245 ++--
drivers/virtio/virtio_ring.c| 25 +++-
include/linux/virtio.h | 2 +
include/uapi/linux/virtio_balloon.h | 10 ++
4 files changed, 265 insertions(+), 17 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index aa4e7ec..ae91fbf 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -54,11 +54,12 @@ static struct vfsmount *balloon_mnt;
struct virtio_balloon {
struct virtio_device *vdev;
- struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
+ struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *cmd_vq;
/* The balloon servicing is delegated to a freezable workqueue. */
struct work_struct update_balloon_stats_work;
struct work_struct update_balloon_size_work;
+ struct work_struct cmdq_handle_work;
/* Prevent updating balloon when it is being canceled. */
spinlock_t stop_update_lock;
@@ -90,6 +91,12 @@ struct virtio_balloon {
/* Memory statistics */
struct virtio_balloon_stat stats[VIRTIO_BALLOON_S_NR];
+ /* Cmdq msg buffer for memory statistics */
+ struct virtio_balloon_cmdq_hdr cmdq_stats_hdr;
+
+ /* Cmdq msg buffer for reporting ununsed pages */
+ struct virtio_balloon_cmdq_hdr cmdq_unused_page_hdr;
+
/* To register callback in oom notifier call chain */
struct notifier_block nb;
};
@@ -485,25 +492,214 @@ static void update_balloon_size_func(struct work_struct
*work)
queue_work(system_freezable_wq, work);
}
+static unsigned int cmdq_hdr_add(struct virtqueue *vq,
+struct virtio_balloon_cmdq_hdr *hdr,
+bool in)
+{
+ unsigned int id = VIRTQUEUE_DESC_ID_INIT;
+ uint64_t hdr_pa = (uint64_t)virt_to_phys((void *)hdr);
+
+ virtqueue_add_chain_desc(vq, hdr_pa, sizeof(*hdr), &id, &id, in);
+
+ /* Deliver the hdr for the host to send commands. */
+ if (in) {
+ hdr->flags = 0;
+ virtqueue_add_chain(vq, id, 0, NULL, hdr, NULL);
+ virtqueue_kick(vq);
+ }
+
+ return id;
+}
+
+static void cmdq_add_chain_desc(struct virtio_balloon *vb,
+ struct virtio_balloon_cmdq_hdr *hdr,
+ uint64_t addr,
+ uint32_t len,
+ unsigned int *head_id,
+ unsigned int *prev_id)
+{
+retry:
+ if (*head_id == VIRTQUEUE_DESC_ID_INIT) {
+ *head_id = cmdq_hdr_add(vb->cmd_vq, hdr, 0);
+ *prev_id = *head_id;
+ }
+
+ virtqueue_add_chain_desc(vb->cmd_vq, addr, len, head_id, prev_id, 0);
+ if (*head_id == *prev_id) {
That's an ugly way to detect ring full.
It's actually not detecting ring full. I will call it tail_id, instead
of prev_id.
So, *head_id == *tail_id is the case that the first desc was just added by
virtqueue_add_chain_desc().
Best,
Wei
RE: [PATCH] arm64: dts: ls1012a: add USB host controller nodes
> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: Thursday, July 13, 2017 4:07 PM
> To: Ran Wang
> Cc: Rob Herring ; Mark Rutland
> ; Catalin Marinas ; Will
> Deacon ; Andy Tang ; Harninder
> Rai ; Horia Geantă ; open
> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> ; moderated list:ARM64 PORT (AARCH64
> ARCHITECTURE) ; open list ker...@vger.kernel.org>
> Subject: Re: [PATCH] arm64: dts: ls1012a: add USB host controller nodes
>
> On Wed, Jul 05, 2017 at 10:54:03AM +0800, Ran Wang wrote:
> > LS1012A has one USB 3.0(DWC3) controller and one USB 2.0 controller.
> >
> > Signed-off-by: Ran Wang
> > ---
> > arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 17 +
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > index b497ac1..8aa2dcf 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > @@ -411,6 +411,23 @@
> > <&clockgen 4 3>;
> > };
> >
> > + usb0: usb3@2f0 {
> > + compatible = "snps,dwc3";
> > + reg = <0x0 0x2f0 0x0 0x1>;
> > + interrupts = <0 60 0x4>;
> > + dr_mode = "host";
> > + snps,quirk-frame-length-adjustment = <0x20>;
> > + snps,dis_rxdet_inp3_quirk;
> > + };
> > +
> > + usb1: usb2@860 {
> > + compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
> > + reg = <0x0 0x860 0x0 0x1000>;
> > + interrupts = <0 139 0x4>;
> > + dr_mode = "host";
> > + phy_type = "ulpi";
> > + };
>
> Please keep the nodes sorted in unit-address.
>
> Shawn
Do you mean to move the node 'usb1: usb2@860' forward to where it's address
is just before '@860 '?
I think it's reasonable to put USB controller nodes together in DTS for
developer to do issue analysis.
Ran
>
> > +
> > sata: sata@320 {
> > compatible = "fsl,ls1012a-ahci", "fsl,ls1043a-ahci";
> > reg = <0x0 0x320 0x0 0x1>,
> > --
> > 2.1.0.27.g96db324
> >
Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support
On 13-07-17, 01:13, Rafael J. Wysocki wrote: > On Wednesday, July 12, 2017 01:14:26 PM Peter Zijlstra wrote: > > On Wed, Jul 12, 2017 at 02:57:55PM +0530, Viresh Kumar wrote: > > > IIUC, it will take more time to change the frequency eventually with > > > the interrupt-driven state machine as there may be multiple bottom > > > halves involved here, for supply, clk, etc, which would run at normal > > > priorities now. And those were boosted currently due to the high > > > priority sugov thread. And we are fine with that (from performance > > > point of view) ? > > > > I'm not sure what you mean; bottom halves as in softirq? Workqueues or normal threads actually. Maybe I am completely wrong, but this is how I believe things are going to be: Configuration: Both regulator and clk registers accessible over I2C bus. Scheduler calls schedutil, which eventually calls cpufreq driver (w/o kthread). The cpufreq backend driver will queue a async request with callback (with regulator core) to update regulator's constraints (which can sleep as we need to talk over I2C). The callback will be called once regulator is programmed. And we return right after submitting the request with regulator core. Now, I2C transfer will finish (i.e. regulator programmed) and the driver specific callback will get called. It will try to change the frequency now and wait (sleep) until it finishes. I hope the regulator core wouldn't call the driver callback from interrupt context but some sort of bottom half, maybe workqueue (That's what I was referring to earlier). And finally the clk is programmed and the state machine finished. > > From what I can > > tell an i2c bus does clk_prepare_enable() on registration and from that > > point on clk_enable() is usable from atomic contexts. That assumes that we can access registers of the I2C controller atomically without sleeping. Not sure how many ARM platforms have I2C controller connected over a slow bus though. > > But afaict clk > > stuff doesn't do interrupts at all. The clk stuff may not need it if the clock controllers registers can be accessed atomically. But if (as in my example) the clk controller is also over the I2C bus, then the interrupt will be provided from I2C bus and clk routines would return only after transfer is done. > > (with a note that I absolutely hate the clk locking) Yeah, that's a beast :) > > I think the interrupt driven thing can actually be faster than the > > 'regular' task waiting on the mutex. The regulator message can be > > locklessly queued (it only ever makes sense to have 1 such message > > pending, any later one will invalidate a prior one). > > > > Then the i2c interrupt can detect the availability of this pending > > message and splice it into the transfer queue at an opportune moment. > > > > (of course, the current i2c bits don't support any of that) > > I *guess* the concern is that in the new model there is no control over the > time of requesting the frequency change and when the change actually > happens. Right. > IIUC the whole point of making the governor thread an RT or DL one is to > ensure that the change will happen as soon as technically possible, because if > it doesn't happen in a specific time frame, it can very well be skipped > entirely. Yes, or actually we can have more trouble (below..). > > > Coming back to where we started from (where should we call > > > arch_set_freq_scale() from ?). > > > > The drivers.. the core cpufreq doesn't know when (if any) transition is > > completed. > > Right. > > > > I think we would still need some kind of synchronization between > > > cpufreq core and the cpufreq drivers to make sure we don't start > > > another freq change before the previous one is complete. Otherwise > > > the cpufreq drivers would be required to have similar support with > > > proper locking in place. > > > > Not sure what you mean; also not sure why. On x86 we never know, cannot > > know. So why would this stuff be any different. So as per the above example, the software on ARM requires to program multiple hardware components (clk, regulator, power-domain, etc) for changing CPUs frequency. And this has to be non-racy, otherwise we might have programmed regulator, domain etc, but right before we change the frequency another request may land which may try to program the regulator again. We would be screwed badly here. Its not a problem on X86 because (I believe) most of this is done by the hardware for you. And you guys don't have to worry for that. We already take care of these synchronization issues in slow switching path (cpufreq_freq_transition_begin()), where we guarantee that a new freq change request doesn't start before the previous one is over. -- viresh
Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)
On Thu, Jul 13, 2017 at 09:12:53AM +0200, Peter Zijlstra wrote: > On Wed, Jul 12, 2017 at 05:32:25PM -0500, Josh Poimboeuf wrote: > > If you want perf to be able to use ORC instead of DWARF for user space > > binaries, that's not currently possible, though I don't see any > > technical blockers for doing so. Perf would need to be taught to read > > ORC data. > > So the problem with userspace stuff is that the unwind data isn't > readily available from NMI context. > > So the kernel unwinder will trigger a fault and abort. > > The very best we can hope for is using the EH [*] stuff that all > binaries actually have _and_ map. The only problem is that most programs > don't actually use the EH stuff much so while its mapped, its not > actually paged in, so we're still stuck. One gloriously ugly hack would be to delay the userspace unwind to return-to-userspace, at which point we have a schedulable context and can take faults. Of course, then you have to somehow identify this later unwind sample with all relevant prior samples and stitch the whole thing back together, but that should be doable. In fact, it would be at all hard to do, just queue a task_work from the NMI and have that do the EH based unwind.
Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)
On Thu, Jul 13, 2017 at 10:50:15AM +0200, Peter Zijlstra wrote: > On Thu, Jul 13, 2017 at 09:12:53AM +0200, Peter Zijlstra wrote: > > On Wed, Jul 12, 2017 at 05:32:25PM -0500, Josh Poimboeuf wrote: > > > If you want perf to be able to use ORC instead of DWARF for user space > > > binaries, that's not currently possible, though I don't see any > > > technical blockers for doing so. Perf would need to be taught to read > > > ORC data. > > > > So the problem with userspace stuff is that the unwind data isn't > > readily available from NMI context. > > > > So the kernel unwinder will trigger a fault and abort. > > > > The very best we can hope for is using the EH [*] stuff that all > > binaries actually have _and_ map. The only problem is that most programs > > don't actually use the EH stuff much so while its mapped, its not > > actually paged in, so we're still stuck. > > One gloriously ugly hack would be to delay the userspace unwind to > return-to-userspace, at which point we have a schedulable context and > can take faults. > > Of course, then you have to somehow identify this later unwind sample > with all relevant prior samples and stitch the whole thing back > together, but that should be doable. > > In fact, it would be at all hard to do, just queue a task_work from the +not > NMI and have that do the EH based unwind.
Re: PM / Suspend: Print wall time at suspend entry and exit
Hi! > >And userspace should not really be parsing kernel logs for time > >keeping, right? > Post-mortem, armed with user space logs in CLOCK_REALTIME (a choice that > most want on Android Logging) and kernel logs, these messages are > _invaluable_ in order to merge the kernel activities with user space. At > runtime they help too, as there is some post-mortem activities on user space > logging daemon startup. > >The devices you are talking about... is any of them running something > >close to mainline kernel, or is planned for merge? I'd like to get a > >phone that is supported by mainline... > > Android on hikey development board is running 4.9 kernel + Android patches > (this is one of 'em), I _expect_ ToT will work. As for _real_ phones, you > have to take that up with the vendors making the chips. Well, there are real phones with mainline Linux: Nokia N900, N9, N950, Motorola Droid 4. Current kernel is 4.13, not v4.9. Yes, Qualcomm is a problem. There are other vendors, you can get those phones in retail. So no, I don't think android community is doing a good job. I don't think it makes sense to merge patches that "help debugging" when basic support is missing. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] selftests: cpufreq: Check cpuinfo_cur_freq set as expected
On 12-07-17, 14:29, Leonard Crestez wrote: > This checks that the cpufreq driver actually sets the requested > frequency. > > Signed-off-by: Leonard Crestez > > --- > > I've been looking at using kselftests for imx. This patch exposes an > issue with the imx6 cpufreq driver on imx6sx where frequencies are set > incorrectly because of clk mishandling. This is already caught by some > internal test scripts which also run against upstream but it's nice to > make this visible through kselftest. Sure, thanks for that. > I'm not sure it's correct to check that frequency matches exactly, > perhaps something like a 5% tolerance should be included for complex > drivers where the target freq is only a "hint"? We can do better, see below.. > I checked intel_pstate > but it doesn't even seem to expose an userspace governor for manual > frequency selection anyway. Sure, and so that wouldn't be affected by this. > Unfortunately cpufreq selftests don't seem to have a clear idea of > "pass" or "fail" results. Yeah, I had this test setup for a while and just pushed it through. Over that many tests aren't really tests but just looking out for crashes, etc. Never got a chance to improve it :( > This patch will just print some TAP-like > "ok" and "not ok" lines but failures are not actually propagated upwards > in a well-defined way. That would be fine for now. > Have you considered what it would take to TAP-ify the output of cpufreq > tests? Output is very complex so perhaps it might make sense to adopt some > sort of subtest syntax for kselftest, something like this: Not yet :( > diff --git a/tools/testing/selftests/cpufreq/cpufreq.sh > b/tools/testing/selftests/cpufreq/cpufreq.sh > index 1ed3832..323b5bb 100755 > --- a/tools/testing/selftests/cpufreq/cpufreq.sh > +++ b/tools/testing/selftests/cpufreq/cpufreq.sh > @@ -151,6 +151,14 @@ test_all_frequencies() > # Set all frequencies one-by-one > for freq in $freqs; do > set_cpu_frequency $1 $freq > + > + local cur_freq > + cur_freq=`cat $CPUFREQROOT/$1/cpuinfo_cur_freq` Yes, we want to verify if freq change happened or not, but may be only reading scaling_cur_freq would be enough for now? And that wouldn't be a problem for X86 (which Rafael mentioned) as well IIUC. -- viresh
Re: [PATCH] arm64: dts: ls1012a: add USB host controller nodes
On Thu, Jul 13, 2017 at 08:46:50AM +, Ran Wang wrote:
> > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > > b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > > index b497ac1..8aa2dcf 100644
> > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
> > > @@ -411,6 +411,23 @@
> > ><&clockgen 4 3>;
> > > };
> > >
> > > + usb0: usb3@2f0 {
> > > + compatible = "snps,dwc3";
> > > + reg = <0x0 0x2f0 0x0 0x1>;
> > > + interrupts = <0 60 0x4>;
> > > + dr_mode = "host";
> > > + snps,quirk-frame-length-adjustment = <0x20>;
> > > + snps,dis_rxdet_inp3_quirk;
> > > + };
> > > +
> > > + usb1: usb2@860 {
> > > + compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
> > > + reg = <0x0 0x860 0x0 0x1000>;
> > > + interrupts = <0 139 0x4>;
> > > + dr_mode = "host";
> > > + phy_type = "ulpi";
> > > + };
> >
> > Please keep the nodes sorted in unit-address.
> >
> > Shawn
> Do you mean to move the node 'usb1: usb2@860' forward to where it's
> address is just before '@860 '?
> I think it's reasonable to put USB controller nodes together in DTS for
> developer to do issue analysis.
The nodes under simple-bus are maintained in order of unit-address.
Please respect that.
usb2@860 should go after sata@320 with the current nodes.
Shawn
> > > +
> > > sata: sata@320 {
> > > compatible = "fsl,ls1012a-ahci", "fsl,ls1043a-ahci";
> > > reg = <0x0 0x320 0x0 0x1>,
> > > --
> > > 2.1.0.27.g96db324
> > >
Re: [PATCH v7 06/16] lockdep: Detect and handle hist_lock ring buffer overwrite
On Thu, Jul 13, 2017 at 10:14:42AM +0200, Peter Zijlstra wrote:
> On Thu, Jul 13, 2017 at 11:07:45AM +0900, Byungchul Park wrote:
> > Does my approach have problems, rewinding to 'original idx' on exit and
> > deciding whether overwrite or not? I think, this way, no need to do the
> > drastic work. Or.. does my one get more overhead in usual case?
>
> So I think that invalidating just the one entry doesn't work; the moment
I think invalidating just the one is enough. After rewinding, the entry
will be invalidated and the ring buffer starts to be filled forward from
the point with valid ones. When commit, it will proceed backward with
valid ones until meeting the invalidated entry and stop.
IOW, in case of (overwritten)
rewind to here
|
pp
iii
invalidate it on exit_irq
and start to fill from here again
|
px
iii
when commit occurs here
|
pxpppi
do commit within this range
|<-|
pxpppi
So I think this works and is much simple. Anything I missed?
> you fill that up the iteration in commit_xhlocks() will again use the
> next one etc.. even though you wanted it not to.
>
> So we need to wipe the _entire_ history.
>
> So I _think_ the below should work, but its not been near a compiler.
>
>
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -822,6 +822,7 @@ struct task_struct {
> unsigned int xhlock_idx_soft; /* For restoring at softirq exit */
> unsigned int xhlock_idx_hard; /* For restoring at hardirq exit */
> unsigned int xhlock_idx_hist; /* For restoring at history boundaries */
> + unsigned int xhlock_idX_max;
> #endif
> #ifdef CONFIG_UBSAN
> unsigned intin_ubsan;
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -4746,6 +4746,14 @@ EXPORT_SYMBOL_GPL(lockdep_rcu_suspicious
> static atomic_t cross_gen_id; /* Can be wrapped */
>
> /*
> + * make xhlock_valid() false.
> + */
> +static inline void invalidate_xhlock(struct hist_lock *xhlock)
> +{
> + xhlock->hlock.instance = NULL;
> +}
> +
> +/*
> * Lock history stacks; we have 3 nested lock history stacks:
> *
> * Hard IRQ
> @@ -4764,28 +4772,58 @@ static atomic_t cross_gen_id; /* Can be
> * MAX_XHLOCKS_NR ? Possibly re-instroduce hist_gen_id ?
> */
>
> -void crossrelease_hardirq_start(void)
> +static inline void __crossrelease_start(unsigned int *stamp)
> {
> if (current->xhlocks)
> - current->xhlock_idx_hard = current->xhlock_idx;
> + *stamp = current->xhlock_idx;
> +}
> +
> +static void __crossrelease_end(unsigned int *stamp)
> +{
> + int i;
> +
> + if (!current->xhlocks)
> + return;
> +
> + current->xhlock_idx = *stamp;
> +
> + /*
> + * If we rewind past the tail; all of history is lost.
> + */
> + if ((current->xhlock_idx_max - *stamp) < MAX_XHLOCKS_NR)
> + return;
> +
> + /*
> + * Invalidate the entire history..
> + */
> + for (i = 0; i < MAX_XHLOCKS_NR; i++)
> + invalidate_xhlock(&xhlock(i));
> +
> + current->xhlock_idx = 0;
> + current->xhlock_idx_hard = 0;
> + current->xhlock_idx_soft = 0;
> + current->xhlock_idx_hist = 0;
> + current->xhlock_idx_max = 0;
> +}
> +
> +void crossrelease_hardirq_start(void)
> +{
> + __crossrelease_start(¤t->xhlock_idx_hard);
> }
>
> void crossrelease_hardirq_end(void)
> {
> - if (current->xhlocks)
> - current->xhlock_idx = current->xhlock_idx_hard;
> + __crossrelease_end(¤t->xhlock_idx_hard);
> }
>
> void crossrelease_softirq_start(void)
> {
> - if (current->xhlocks)
> - current->xhlock_idx_soft = current->xhlock_idx;
> + __crossrelease_start(¤t->xhlock_idx_soft);
> }
>
> void crossrelease_softirq_end(void)
> {
> - if (current->xhlocks)
> - current->xhlock_idx = current->xhlock_idx_soft;
> + __crossrelease_end(¤t->xhlock_idx_soft);
> }
>
> /*
> @@ -4806,14 +4844,12 @@ void crossrelease_softirq_end(void)
> */
> void crossrelease_hist_start(void)
> {
> - if (current->xhlocks)
> - current->xhlock_idx_hist = current->xhlock_idx;
> + __crossrelease_start(¤t->xhlock_idx_hist);
> }
>
> void crossrelease_hist_end(void)
> {
> - if (current->xhlocks)
> - current->xhlock_idx = current->xhlock_idx_hist;
> + __crossrelease_end(¤t->xhlock_idx_hist);
> }
>
> static int cross_lock(struct lockdep_map *lock)
> @@ -4880,6 +4916,9 @@ static void add_xhlock(struct held_lock
> unsigned int idx = ++current->xhlock_idx;
> struct hist_lock *xhlock = &xhlock(idx);
>
> + if ((int)(current->xhlock_idx_max - idx) < 0)
> + current->xhlock_idx_max = idx;
> +
> #ifdef CONFIG_DEBUG_LOCKDEP
> /*
>* This can be
[GIT PULL] RTC for 4.13
Hi Linus, Here is the pull-request for the RTC subsystem for 4.13. The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-4.13 for you to fetch changes up to 40bf6a35483ee25271ce2a90d8976cf1409a033a: rtc: Remove wrong deprecation comment (2017-07-12 23:11:23 +0200) RTC for 4.13 Subsystem: - expose non volatile RAM using nvmem instead of open coding in many drivers. Unfortunately, this option has to be enabled by default to not break existing users. - rtctest can now test for cutoff dates, showing when an RTC will start failing to properly save time and date. - new RTC registration functions to remove race conditions in drivers Newly supported RTCs: - Broadcom STB wake-timer - Epson RX8130CE - Maxim IC DS1308 - STMicroelectronics STM32H7 Drivers: - ds1307: use regmap, use nvmem, more cleanups - ds3232: temperature reading support - gemini: renamed to ftrtc010 - m41t80: use CCF to expose the clock - rv8803: use nvmem - s3c: many cleanups - st-lpc: fix y2106 bug Alexandre Belloni (17): rtc: sysfs: make name uniform rtc: dev: remove rtc->name from debug message rtc: pcf8563: avoid using rtc->name rtc: ds1307: avoid using rtc-name rtc: remove rtc_device.name rtc: class separate device allocation from registration rtc: class separate id allocation from registration rtc: introduce new registration method rtc: at91rm9200: remove race condition rtc: add generic nvmem support rtc: rv8803: switch to rtc_register_device rtc: rv8803: use generic nvmem support rtc: rv8803: remove rv8803_remove rtc: ds1307: switch to rtc_register_device rtc: ds1307: use generic nvmem rtc: ds1307: remove ds1307_remove rtc: Remove wrong deprecation comment Amelie Delaunay (2): dt-bindings: rtc: stm32: add support for STM32H7 rtc: stm32: add STM32H7 RTC support Arnd Bergmann (1): nvmem: include linux/err.h from header Benjamin Gaignard (3): tools: timer: add rtctest_setdate rtc: rtctest: add check for problematic dates rtc: st-lpc: make it robust against y2038/2106 bug Brian Norris (1): rtc: brcmstb-waketimer: Add Broadcom STB wake-timer Dan Carpenter (1): rtc: rtc-nuc900: fix loop timeout test David Lowe (1): rtc: rtc-ds1307: enable support for mcp794xx as a wakeup source without IRQ Diaz de Grenu, Jose (1): rtc: mxc: remove unused variable Florian Fainelli (1): dt-bindings: Document the Broadcom STB wake-up timer node Gary Bisson (4): rtc: m41t80: fix SQWE override when setting an alarm rtc: m41t80: fix SQW dividers override when setting a date rtc: m41t80: remove sqw sysfs entry rtc: m41t80: add clock provider support Heiner Kallweit (3): rtc: ds1307: convert driver to regmap rtc: ds1307: use regmap_update_bits where applicable rtc: ds1307: factor out century bit handling Kirill Esipov (1): rtc: ds3232: add temperature support Krzysztof Kozlowski (6): rtc: s3c: Jump to central exit point on getting src clock error rtc: s3c: Minor white-space cleanups rtc: s3c: Drop unneeded cast to void pointer rtc: s3c: Do not remove const from rodata memory rtc: s3c: Handle clock prepare failures in probe rtc: s3c: Handle clock enable failures Linus Walleij (3): rtc: gemini: Add optional clock handling rtc: gemini: Augment DT bindings for Faraday rtc: gemini/ftrtc010: rename driver and symbols Marek Vasut (1): rtc: ds1307: Add support for Epson RX8130CE Mauro Carvalho Chehab (1): rtc.txt: standardize document format Sean Nyekjaer (1): rtc: ds1307: add ds1308 variant Vaibhav Jain (3): rtc: opal: Handle disabled TPO in opal_get_tpo_time() rtc: interface: Validate alarm-time before handling rollover rtc: opal: Implement rtc_class_ops.alarm_irq_enable callback .../bindings/rtc/brcm,brcmstb-waketimer.txt| 22 + .../devicetree/bindings/rtc/cortina,gemini.txt | 14 - .../devicetree/bindings/rtc/faraday,ftrtc010.txt | 28 + .../devicetree/bindings/rtc/st,stm32-rtc.txt | 32 +- Documentation/rtc.txt | 46 +- MAINTAINERS| 2 +- drivers/rtc/Kconfig| 37 +- drivers/rtc/Makefile | 4 +- drivers/rtc/class.c| 202 +++-- drivers/rtc/interface.c| 9 +- drivers/rtc/nvmem.c| 113 +++ drivers/rtc/rtc-at91rm9200.c | 14 +- drivers/rtc/rtc-brcm
[PATCH] mfd: Add missing Kconfig dependency for TPS65086
MTF_CORE should be enabled when driver is enabled. Signed-off-by: Michal Simek --- drivers/mfd/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 94ad2c1c3d90..f98b5a6d4da8 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -1294,6 +1294,7 @@ config TPS6507X config MFD_TPS65086 tristate "TI TPS65086 Power Management Integrated Chips (PMICs)" + select MFD_CORE select REGMAP select REGMAP_IRQ select REGMAP_I2C -- 1.9.1
[PATCH 2/2] pinctrl: zynq: Fix warnings in the driver
From: Nava kishore Manne
This patch fixes the below warning
--> Prefer 'unsigned int' to bare use of 'unsigned'.
--> line over 80 characters.
--> Prefer 'unsigned int **' to bare use of 'unsigned **'.
Signed-off-by: Nava kishore Manne
Signed-off-by: Michal Simek
---
drivers/pinctrl/pinctrl-zynq.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-zynq.c b/drivers/pinctrl/pinctrl-zynq.c
index 7565651acdc6..a0daf27042bd 100644
--- a/drivers/pinctrl/pinctrl-zynq.c
+++ b/drivers/pinctrl/pinctrl-zynq.c
@@ -62,7 +62,7 @@ struct zynq_pinctrl {
struct zynq_pctrl_group {
const char *name;
const unsigned int *pins;
- const unsigned npins;
+ const unsigned int npins;
};
/**
@@ -841,7 +841,7 @@ static int zynq_pctrl_get_groups_count(struct pinctrl_dev
*pctldev)
}
static const char *zynq_pctrl_get_group_name(struct pinctrl_dev *pctldev,
-unsigned selector)
+unsigned int selector)
{
struct zynq_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
@@ -849,9 +849,9 @@ static const char *zynq_pctrl_get_group_name(struct
pinctrl_dev *pctldev,
}
static int zynq_pctrl_get_group_pins(struct pinctrl_dev *pctldev,
-unsigned selector,
-const unsigned **pins,
-unsigned *num_pins)
+unsigned int selector,
+const unsigned int **pins,
+unsigned int *num_pins)
{
struct zynq_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
@@ -878,7 +878,7 @@ static int zynq_pmux_get_functions_count(struct pinctrl_dev
*pctldev)
}
static const char *zynq_pmux_get_function_name(struct pinctrl_dev *pctldev,
- unsigned selector)
+ unsigned int selector)
{
struct zynq_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
@@ -886,7 +886,7 @@ static const char *zynq_pmux_get_function_name(struct
pinctrl_dev *pctldev,
}
static int zynq_pmux_get_function_groups(struct pinctrl_dev *pctldev,
-unsigned selector,
+unsigned int selector,
const char * const **groups,
unsigned * const num_groups)
{
@@ -898,8 +898,8 @@ static int zynq_pmux_get_function_groups(struct pinctrl_dev
*pctldev,
}
static int zynq_pinmux_set_mux(struct pinctrl_dev *pctldev,
- unsigned function,
- unsigned group)
+ unsigned int function,
+ unsigned int group)
{
int i, ret;
struct zynq_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
@@ -986,8 +986,8 @@ enum zynq_pin_config_param {
};
#ifdef CONFIG_DEBUG_FS
-static const struct pin_config_item
zynq_conf_items[ARRAY_SIZE(zynq_dt_params)] = {
- PCONFDUMP(PIN_CONFIG_IOSTANDARD, "IO-standard", NULL, true),
+static const struct pin_config_item zynq_conf_items[ARRAY_SIZE(zynq_dt_params)]
+ = { PCONFDUMP(PIN_CONFIG_IOSTANDARD, "IO-standard", NULL, true),
};
#endif
@@ -997,7 +997,7 @@ static unsigned int zynq_pinconf_iostd_get(u32 reg)
}
static int zynq_pinconf_cfg_get(struct pinctrl_dev *pctldev,
- unsigned pin,
+ unsigned int pin,
unsigned long *config)
{
u32 reg;
@@ -1054,9 +1054,9 @@ static int zynq_pinconf_cfg_get(struct pinctrl_dev
*pctldev,
}
static int zynq_pinconf_cfg_set(struct pinctrl_dev *pctldev,
- unsigned pin,
+ unsigned int pin,
unsigned long *configs,
- unsigned num_configs)
+ unsigned int num_configs)
{
int i, ret;
u32 reg;
@@ -1130,9 +1130,9 @@ static int zynq_pinconf_cfg_set(struct pinctrl_dev
*pctldev,
}
static int zynq_pinconf_group_set(struct pinctrl_dev *pctldev,
- unsigned selector,
+ unsigned int selector,
unsigned long *configs,
- unsigned num_configs)
+ unsigned int num_configs)
{
int i, ret;
struct zynq_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
--
1.9.1
[PATCH 1/2] pinctrl: zynq: Fix kernel doc warnings
From: Nava kishore Manne This patch fixes the kernel doc warnings in the driver. Signed-off-by: Nava kishore Manne Signed-off-by: Michal Simek --- drivers/pinctrl/pinctrl-zynq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/pinctrl-zynq.c b/drivers/pinctrl/pinctrl-zynq.c index b51a46dfdcc3..7565651acdc6 100644 --- a/drivers/pinctrl/pinctrl-zynq.c +++ b/drivers/pinctrl/pinctrl-zynq.c @@ -45,7 +45,7 @@ * @syscon:Syscon regmap * @pctrl_offset: Offset for pinctrl into the @syscon space * @groups:Pingroups - * @ngroupos: Number of @groups + * @ngroups: Number of @groups * @funcs: Pinmux functions * @nfuncs:Number of @funcs */ -- 1.9.1
[PATCH] cpufreq: dt: Add zynqmp to the cpufreq dt platdev
From: Shubhrajyoti Datta
Add zynqmp to the cpufreq dt platform device.
Signed-off-by: Shubhrajyoti Datta
Signed-off-by: Michal Simek
---
drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 1c262923fe58..2eb40d46d357 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -94,6 +94,7 @@
{ .compatible = "ti,omap5", },
{ .compatible = "xlnx,zynq-7000", },
+ { .compatible = "xlnx,zynqmp", },
{ .compatible = "zte,zx296718", },
--
1.9.1
Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)
* Peter Zijlstra wrote: > > One gloriously ugly hack would be to delay the userspace unwind to > > return-to-userspace, at which point we have a schedulable context and can > > take > > faults. I don't think it's ugly, and it has various advantages: > > Of course, then you have to somehow identify this later unwind sample with > > all > > relevant prior samples and stitch the whole thing back together, but that > > should be doable. > > > > In fact, it would not be at all hard to do, just queue a task_work from the > > NMI and have that do the EH based unwind. This would have a couple of advantages: - as you mention, being able to fault in debug info and generally do IO/scheduling, - profiling overhead would be accounted to the task context that generates it, not the NMI context, - there would be a natural batching/coalescing optimization if multiple events hit the same system call: the user-space backtrace would only have to be looked up once for all samples that got collected. This could be done by separating the user-space backtrace into a separate event, and perf tooling would then apply the same user-space backtrace to all prior kernel samples. I.e. the ring-buffer would have trace entries like: [ kernel sample #1, with kernel backtrace #1 ] [ kernel sample #2, with kernel backtrace #2 ] [ kernel sample #3, with kernel backtrace #3 ] [ user-space backtrace #1 at syscall return ] ... Note how the three kernel samples didn't have to do any user-space unwinding at all, so the user-space unwinding overhead got reduced by a factor of 3. Tooling would know that 'user-space backtrace #1' applies to the previous three kernel samples. Or so? Thanks, Ingo
Re: [PATCH] cpufreq: dt: Add zynqmp to the cpufreq dt platdev
On 13-07-17, 11:19, Michal Simek wrote:
> From: Shubhrajyoti Datta
>
> Add zynqmp to the cpufreq dt platform device.
>
> Signed-off-by: Shubhrajyoti Datta
> Signed-off-by: Michal Simek
> ---
>
> drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
> b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 1c262923fe58..2eb40d46d357 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -94,6 +94,7 @@
> { .compatible = "ti,omap5", },
>
> { .compatible = "xlnx,zynq-7000", },
> + { .compatible = "xlnx,zynqmp", },
>
> { .compatible = "zte,zx296718", },
Acked-by: Viresh Kumar
--
viresh
[PATCH v2] crypto: caam - free qman_fq after kill_fq
kill_fq removes a complete frame queue, it needs to free the qman_fq
in the last. Else kmemleak will report the below warning:
unreferenced object 0x800073085c80 (size 128):
comm "cryptomgr_test", pid 199, jiffies 4294937850 (age 67.840s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 a0 80 7e 00 00 80 ff ff
00 00 00 00 00 00 00 00 04 00 04 00 5c 01 00 00
backtrace:
[] create_object+0xf8/0x258
[] kmemleak_alloc+0x58/0xa0
[] kmem_cache_alloc_trace+0x2c8/0x358
[] create_caam_req_fq+0x40/0x170
[] caam_drv_ctx_update+0x54/0x248
[] aead_setkey+0x154/0x300
[] setkey+0x50/0xf0
[] __test_aead+0x5ec/0x1028
[] test_aead+0x44/0xc8
[] alg_test_aead+0x58/0xd0
[] alg_test+0x14c/0x308
[] cryptomgr_test+0x50/0x58
[] kthread+0xdc/0xf0
[] ret_from_fork+0x10/0x50
And check where the function kill_fq() is called to remove
the additional kfree to qman_fq and avoid re-calling the released qman_fq.
Signed-off-by: Xulin Sun
---
v1->v2:
Checked where the function kill_fq() is called to avoid re-calling the released
qman_fq.
drivers/crypto/caam/qi.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/caam/qi.c b/drivers/crypto/caam/qi.c
index 1990ed4..608ce91 100644
--- a/drivers/crypto/caam/qi.c
+++ b/drivers/crypto/caam/qi.c
@@ -277,6 +277,7 @@ static int kill_fq(struct device *qidev, struct qman_fq *fq)
dev_err(qidev, "OOS of FQID: %u failed\n", fq->fqid);
qman_destroy_fq(fq);
+ kfree(fq);
return ret;
}
@@ -342,8 +343,7 @@ int caam_drv_ctx_update(struct caam_drv_ctx *drv_ctx, u32
*sh_desc)
drv_ctx->req_fq = old_fq;
if (kill_fq(qidev, new_fq))
- dev_warn(qidev, "New CAAM FQ: %u kill failed\n",
-new_fq->fqid);
+ dev_warn(qidev, "New CAAM FQ kill failed\n");
return ret;
}
@@ -373,10 +373,9 @@ int caam_drv_ctx_update(struct caam_drv_ctx *drv_ctx, u32
*sh_desc)
drv_ctx->req_fq = old_fq;
if (kill_fq(qidev, new_fq))
- dev_warn(qidev, "New CAAM FQ: %u kill failed\n",
-new_fq->fqid);
+ dev_warn(qidev, "New CAAM FQ kill failed\n");
} else if (kill_fq(qidev, old_fq)) {
- dev_warn(qidev, "Old CAAM FQ: %u kill failed\n", old_fq->fqid);
+ dev_warn(qidev, "Old CAAM FQ kill failed\n");
}
return 0;
@@ -511,7 +510,6 @@ int caam_qi_shutdown(struct device *qidev)
if (kill_fq(qidev, per_cpu(pcpu_qipriv.rsp_fq, i)))
dev_err(qidev, "Rsp FQ kill failed, cpu: %d\n", i);
- kfree(per_cpu(pcpu_qipriv.rsp_fq, i));
}
/*
--
2.7.4
Re: [PATCH] bpf: fix return in bpf_skb_adjust_net
On 07/13/2017 08:27 AM, Kefeng Wang wrote: The bpf_skb_adjust_net() ignores the return value of bpf_skb_net_shrink/grow, and always return 0, fix it by return 'ret'. Signed-off-by: Kefeng Wang Sigh, yep of course. Thanks! Acked-by: Daniel Borkmann
[PATCH net] xgene: Don't fail probe, if there is no clk resource for SGMII interfaces
From: Thomas Bogendoerfer
This change fixes following problem
[1.827940] xgene-enet: probe of 1f210030.ethernet failed with error -2
which leads to a missing ethernet interface (reproducable at least on
Gigabyte MP30-AR0 and APM Mustang systems).
The check for a valid clk resource fails, because DT doesn't provide a
clock for sgenet1. But the driver doesn't use this clk, if the ethernet
port is connected via SGMII. Therefore this patch avoids probing for clk
on SGMII interfaces.
Fixes: 9aea7779b764 drivers: net: xgene: Fix crash on DT systems
Signed-off-by: Thomas Bogendoerfer
---
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index d3906f6b01bd..86058a9f3417 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -1785,16 +1785,18 @@ static int xgene_enet_get_resources(struct
xgene_enet_pdata *pdata)
xgene_enet_gpiod_get(pdata);
- pdata->clk = devm_clk_get(&pdev->dev, NULL);
- if (IS_ERR(pdata->clk)) {
- /* Abort if the clock is defined but couldn't be retrived.
-* Always abort if the clock is missing on DT system as
-* the driver can't cope with this case.
-*/
- if (PTR_ERR(pdata->clk) != -ENOENT || dev->of_node)
- return PTR_ERR(pdata->clk);
- /* Firmware may have set up the clock already. */
- dev_info(dev, "clocks have been setup already\n");
+ if (pdata->phy_mode != PHY_INTERFACE_MODE_SGMII) {
+ pdata->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(pdata->clk)) {
+ /* Abort if the clock is defined but couldn't be
+* retrived. Always abort if the clock is missing on
+* DT system as the driver can't cope with this case.
+*/
+ if (PTR_ERR(pdata->clk) != -ENOENT || dev->of_node)
+ return PTR_ERR(pdata->clk);
+ /* Firmware may have set up the clock already. */
+ dev_info(dev, "clocks have been setup already\n");
+ }
}
if (pdata->phy_mode != PHY_INTERFACE_MODE_XGMII)
--
2.12.3
