Re: [PATCH] mm/zsmalloc: Change stat type parameter to int
On Mon, Jul 31, 2017 at 10:50:00AM -0700, Matthias Kaehlcke wrote: > zs_stat_inc/dec/get() uses enum zs_stat_type for the stat type, however > some callers pass an enum fullness_group value. Change the type to int > to reflect the actual use of the functions and get rid of > 'enum-conversion' warnings Maybe clang? > > Signed-off-by: Matthias Kaehlcke Anyway, Acked-by: Minchan Kim Thanks!
Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage
Jens Axboe writes:
...
>
> Can you try the below fix? Should be more palatable than the previous
> one. Brian, maybe you can take a look at the IRQ issue mentioned above?
Given the patch from Brian fixed the lockdep warning, do you still want
me to try and test this one?
cheers
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index f6097b89d5d3..dfb89596af81 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -481,13 +481,14 @@ static void scsi_starved_list_run(struct Scsi_Host
> *shost)
> * Purpose:Select a proper request queue to serve next
> *
> * Arguments: q - last request's queue
> + * async - run queues async, if we need to
> *
> * Returns: Nothing
> *
> * Notes: The previous command was completely finished, start
> * a new one if possible.
> */
> -static void scsi_run_queue(struct request_queue *q)
> +static void scsi_run_queue(struct request_queue *q, bool async)
> {
> struct scsi_device *sdev = q->queuedata;
>
> @@ -497,7 +498,7 @@ static void scsi_run_queue(struct request_queue *q)
> scsi_starved_list_run(sdev->host);
>
> if (q->mq_ops)
> - blk_mq_run_hw_queues(q, false);
> + blk_mq_run_hw_queues(q, async);
> else
> blk_run_queue(q);
> }
> @@ -509,7 +510,7 @@ void scsi_requeue_run_queue(struct work_struct *work)
>
> sdev = container_of(work, struct scsi_device, requeue_work);
> q = sdev->request_queue;
> - scsi_run_queue(q);
> + scsi_run_queue(q, false);
> }
>
> /*
> @@ -543,17 +544,22 @@ static void scsi_requeue_command(struct request_queue
> *q, struct scsi_cmnd *cmd)
> blk_requeue_request(q, req);
> spin_unlock_irqrestore(q->queue_lock, flags);
>
> - scsi_run_queue(q);
> + scsi_run_queue(q, true);
>
> put_device(&sdev->sdev_gendev);
> }
>
> -void scsi_run_host_queues(struct Scsi_Host *shost)
> +static void __scsi_run_host_queues(struct Scsi_Host *shost, bool async)
> {
> struct scsi_device *sdev;
>
> shost_for_each_device(sdev, shost)
> - scsi_run_queue(sdev->request_queue);
> + scsi_run_queue(sdev->request_queue, async);
> +}
> +
> +void scsi_run_host_queues(struct Scsi_Host *shost)
> +{
> + __scsi_run_host_queues(shost, false);
> }
>
> static void scsi_uninit_cmd(struct scsi_cmnd *cmd)
> @@ -671,7 +677,7 @@ static bool scsi_end_request(struct request *req,
> blk_status_t error,
> blk_finish_request(req, error);
> spin_unlock_irqrestore(q->queue_lock, flags);
>
> - scsi_run_queue(q);
> + scsi_run_queue(q, false);
> }
>
> put_device(&sdev->sdev_gendev);
> @@ -2293,7 +2299,7 @@ EXPORT_SYMBOL(scsi_block_requests);
> void scsi_unblock_requests(struct Scsi_Host *shost)
> {
> shost->host_self_blocked = 0;
> - scsi_run_host_queues(shost);
> + __scsi_run_host_queues(shost, true);
> }
> EXPORT_SYMBOL(scsi_unblock_requests);
>
> @@ -2897,10 +2903,10 @@ scsi_device_quiesce(struct scsi_device *sdev)
> if (err)
> return err;
>
> - scsi_run_queue(sdev->request_queue);
> + scsi_run_queue(sdev->request_queue, false);
> while (atomic_read(&sdev->device_busy)) {
> msleep_interruptible(200);
> - scsi_run_queue(sdev->request_queue);
> + scsi_run_queue(sdev->request_queue, false);
> }
> return 0;
> }
> @@ -2924,7 +2930,7 @@ void scsi_device_resume(struct scsi_device *sdev)
> mutex_lock(&sdev->state_mutex);
> if (sdev->sdev_state == SDEV_QUIESCE &&
> scsi_device_set_state(sdev, SDEV_RUNNING) == 0)
> - scsi_run_queue(sdev->request_queue);
> + scsi_run_queue(sdev->request_queue, false);
> mutex_unlock(&sdev->state_mutex);
> }
> EXPORT_SYMBOL(scsi_device_resume);
>
> --
> Jens Axboe
Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage
Michael Ellerman writes: > Brian King writes: > >> On 07/28/2017 10:17 AM, Brian J King wrote: >>> Jens Axboe wrote on 07/28/2017 09:25:48 AM: >>> Can you try the below fix? Should be more palatable than the previous one. Brian, maybe you can take a look at the IRQ issue mentioned above? >> >> Michael, >> >> Does this address the issue you are seeing? > > Yes it seems to, thanks. > > I only see the trace on reboot, and not 100% of the time. But I've > survived a couple of reboots now without seeing anything, so I think > this is helping. > > I'll put the patch in my Jenkins over night and let you know how it > survives that, which should be ~= 25 boots. No lockdep warnings or other oddness over night, so that patch looks good to me. cheers
Re: [RFC] KVM: optimize the kvm_vcpu_on_spin
On Mon, 31 Jul 2017 19:32:26 +0200
David Hildenbrand wrote:
> This one should work for s390x, no caching (or special access patterns
> like on x86) needed:
>
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -2447,6 +2447,11 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
> return kvm_s390_vcpu_has_irq(vcpu, 0);
> }
>
> +bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu)
> +{
> + return !(vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE);
> +}
> +
> void kvm_s390_vcpu_block(struct kvm_vcpu *vcpu)
> {
> atomic_or(PROG_BLOCK_SIE, &vcpu->arch.sie_block->prog20);
Yes, that should work.
RE: Issue with commit de3ef1eb1cd - PM / core: Drop run_wake flag from struct dev_pm_info [Was: MEI-related WARN_ON() triggered during resume-from-sleep on v4.13-rc2+]
> -Original Message- > From: Dominik Brodowski [mailto:li...@dominikbrodowski.net] > Sent: Tuesday, August 01, 2017 09:37 > To: Usyskin, Alexander ; Rafael J. Wysocki > > Cc: Winkler, Tomas ; Wysocki, Rafael J > ; Mika Westerberg > ; Bjorn Helgaas ; > linux-kernel@vger.kernel.org; Linux PM ; ACPI > Devel Maling List > Subject: Re: Issue with commit de3ef1eb1cd - PM / core: Drop run_wake flag > from struct dev_pm_info [Was: MEI-related WARN_ON() triggered during > resume-from-sleep on v4.13-rc2+] > > Alexander, Rafael, > > On Tue, Aug 01, 2017 at 02:05:22AM +0200, Rafael J. Wysocki wrote: > > Actually, I don't think it will make any difference. Please check the > > one attached this time. > > On Tue, Aug 01, 2017 at 05:25:03AM +, Usyskin, Alexander wrote: > > Dominik, can you try comment out "if (!pci_dev_run_wake(pdev))" > > at drivers/misc/mei/pci-me.c (around line 223) to set domain callbacks > > by force to see if this is indeed the case? > > thanks for taking a look at this issue. I have tested both approaches, and > either works fine and solves the issue. Which approach is better I cannot say, > though. > > Thanks, > Dominik Thanks for envestigation. Our HW requires PCI_DEV_FLAGS_NEEDS_RESUME as we need to go via reset during suspend and this cannot be initiated while in runtime suspended. We will work on the patch. Thanks Tomas
Re: [PATCH 2/3] gpio: Add FT232H CBUS GPIO driver
On Thu, Jul 6, 2017 at 10:49 PM, Anatolij Gustschin wrote: > Add driver for CBUS pins on FT232H. The driver supports setting > GPIO direction and getting/setting CBUS 0-3 pin value. The CBUS > pins have to be enabled by configuring I/O mode in the FTDI EEPROM. > > Signed-off-by: Anatolij Gustschin (...) > + select GPIO_GENERIC You do not seem to be using this. > +#include This include should not be needed. If it is, something is wrong. > +#include Drivers should only include this. > +#include > +#include > +#include > +#include Why is this needed if the device is abstracted behind an MFD interface? > +#include I.e. this? Apart from these small things it looks like a solid and nice driver, do you plan to merge this into MFD or should I merge it? Since it depends on the Kconfig symbol I guess I can merge it orthogonally if I am sure Lee will pick the MFD part. Yours, Linus Walleij
Re: [RFC v6 21/62] powerpc: introduce execute-only pkey
Thiago Jung Bauermann writes: > Ram Pai writes: ... >> + >> +/* We got one, store it and use it from here on out */ >> +if (need_to_set_mm_pkey) >> +mm->context.execute_only_pkey = execute_only_pkey; >> +return execute_only_pkey; >> +} > > If you follow the code flow in __execute_only_pkey, the AMR and UAMOR > are read 3 times in total, and AMR is written twice. IAMR is read and > written twice. Since they are SPRs and access to them is slow (or isn't > it?), SPRs read/writes are slow, but they're not *that* slow in comparison to a system call (which I think is where this code is being called?). So we should try to avoid too many SPR read/writes, but at the same time we can accept more than the minimum if it makes the code much easier to follow. cheers
[PATCH 2/2] gpio: omap : Add missing clk_unprepare().
omap_gpio_probe() can fail here and we must disable clock.
Signed-off-by: Arvind Yadav
---
drivers/gpio/gpio-omap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index f8c550de..dbf869f 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1247,6 +1247,8 @@ static int omap_gpio_probe(struct platform_device *pdev)
if (ret) {
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
+ if (bank->dbck_flag)
+ clk_unprepare(bank->dbck);
return ret;
}
--
1.9.1
[PATCH 1/2] gpio: mb86s7x: Handle return value of clk_prepare_enable.
clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- drivers/gpio/gpio-mb86s7x.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-mb86s7x.c b/drivers/gpio/gpio-mb86s7x.c index ffb73f6..94d7726 100644 --- a/drivers/gpio/gpio-mb86s7x.c +++ b/drivers/gpio/gpio-mb86s7x.c @@ -168,7 +168,9 @@ static int mb86s70_gpio_probe(struct platform_device *pdev) if (IS_ERR(gchip->clk)) return PTR_ERR(gchip->clk); - clk_prepare_enable(gchip->clk); + ret = clk_prepare_enable(gchip->clk); + if (ret) + return ret; spin_lock_init(&gchip->lock); -- 1.9.1
Re: [PATCH] genirq: Provide IRQCHIP_ONESHOT_EDGE_SAFE
On Tue, 1 Aug 2017, Benjamin Herrenschmidt wrote: > On Mon, 2017-07-31 at 21:33 +0200, Thomas Gleixner wrote: > > If an interrupt chip is marked IRQCHIP_ONESHOT_SAFE it signals that the > > interrupt chip does not require the ONESHOT mode for threaded > > interrupts. Unfortunately this is applied independent of the interrupt type > > (edge/level). > > > > The powerpc XPIC wants this functionality only for edge type > > interrupts. Provide a new flag which provides the same functionality > > restricted to edge type interrupts. > > Thanks ! I'll test that asap (got pulled into another emergency so it > might take a day or two). I'm not around til Aug. 14th, so feel free to route it Linuswards directly. Thanks, tglx
linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
After merging the akpm tree, today's linux-next build (sparc defconfig)
failed like this:
In file included from mm/vmscan.c:55:0:
include/linux/swapops.h: In function 'swp_entry_to_pmd':
include/linux/swapops.h:226:9: error: implicit declaration of function '__pmd'
[-Werror=implicit-function-declaration]
return __pmd(0);
^
include/linux/swapops.h:226:9: error: incompatible types when returning type
'int' but 'pmd_t {aka struct }' was expected
Caused by commit
9bb18490758c ("mm-thp-enable-thp-migration-in-generic-path-fix")
It looks like sparc 32 bit has no __pmd() ...
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
Re: Issue with commit de3ef1eb1cd - PM / core: Drop run_wake flag from struct dev_pm_info [Was: MEI-related WARN_ON() triggered during resume-from-sleep on v4.13-rc2+]
Alexander, Rafael, On Tue, Aug 01, 2017 at 02:05:22AM +0200, Rafael J. Wysocki wrote: > Actually, I don't think it will make any difference. Please check the > one attached this time. On Tue, Aug 01, 2017 at 05:25:03AM +, Usyskin, Alexander wrote: > Dominik, can you try comment out "if (!pci_dev_run_wake(pdev))" > at drivers/misc/mei/pci-me.c (around line 223) to set domain callbacks by > force > to see if this is indeed the case? thanks for taking a look at this issue. I have tested both approaches, and either works fine and solves the issue. Which approach is better I cannot say, though. Thanks, Dominik signature.asc Description: PGP signature
Re: [PATCH v4 3/9] perf anntoate browser: Fix the toggle total period view showing number of samples
On 07/28/2017 01:57 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Jul 28, 2017 at 01:16:02AM +0900, Taeung Song escreveu:
Currently the toggle total period view on the annotate TUI
shows the number of samples, not period like below.
So fix the toggle total period view on the annotate TUI like below.
$ perf annotate --show-total-period
Before:
│Disassembly of section .text:
│
│00109a90 <_mcount@@GLIBC_2.2.5>:
│ sub$0x38,%rsp
3 │ mov%rax,(%rsp)
3 │ mov%rcx,0x8(%rsp)
After:
│Disassembly of section .text:
│
│00109a90 <_mcount@@GLIBC_2.2.5>:
│ sub$0x38,%rsp
2204022 │ mov%rax,(%rsp)
2207405 │ mov%rcx,0x8(%rsp)
Reported-by: Namhyung Kim
Cc: Milian Wolff
Cc: Jiri Olsa
Signed-off-by: Taeung Song
---
tools/perf/ui/browsers/annotate.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/tools/perf/ui/browsers/annotate.c
b/tools/perf/ui/browsers/annotate.c
index dbe4e63..87b0395 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -18,7 +18,7 @@
struct disasm_line_samples {
double percent;
- u64 nr;
+ struct sym_hist_entry sample;
};
#define IPC_WIDTH 6
@@ -110,7 +110,9 @@ static int annotate_browser__set_jumps_percent_color(struct
annotate_browser *br
static int annotate_browser__pcnt_width(struct annotate_browser *ab)
{
- int w = 7 * ab->nr_events;
+ int w = annotate_browser__opts.show_total_period ? 11 : 7;
+
+ w *= ab->nr_events;
if (ab->have_cycles)
w += IPC_WIDTH + CYCLES_WIDTH;
@@ -151,8 +153,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].sample.period);
} else {
ui_browser__printf(browser, "%6.2f ",
bdl->samples[i].percent);
@@ -162,7 +164,7 @@ 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);
+ ui_browser__write_nstring(browser, " ", pcnt_width);
This one had to be on a separate patch to clarify pcnt_width usage, that
can't be used here because we may have cycles_width in it:
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=perf/core&id=ef03136d8df02b4aad314ad7c66c275f4df94225
else
ui_browser__printf(browser, "%*s", 7, "Percent");
}
@@ -457,7 +459,7 @@ static void annotate_browser__calc_percent(struct
annotate_browser *browser,
pos->offset,
next ? next->offset : len,
&path, &sample);
- bpos->samples[i].nr = sample.nr_samples;
+ bpos->samples[i].sample = sample;
this one is at:
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=perf/core&id=ac57d540fbdd7429300eafe5878cb06047904db0
Take a look at current acme/perf/core.
I'll take care of the rest, thanks.
- Arnaldo
I got it, I checked current acme/perf/core !
Thanks,
Taeung
if (max_percent < bpos->samples[i].percent)
max_percent = bpos->samples[i].percent;
--
2.7.4
Re: [PATCH v4 5/9] perf annotate stdio: Support --show-nr-samples option
On 07/29/2017 01:26 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Jul 28, 2017 at 01:16:16AM +0900, Taeung Song escreveu:
Add --show-nr-samples option to perf-annotate
so that it corresponds with perf-report.
So this is not that intuitive, i.e. if one ask for:
perf annotate --show-total-period --show-nr-samples
then both should appear, no?
- Arnaldo
I thought the users can use both --show-total-period and --show-nr-samples,
but perf-annotate can preferentially show the total period view IMHO.
What do you think about it ?
we need to prevent users from using both ?
Thanks,
Taeung
Cc: Namhyung Kim
Cc: Milian Wolff
Cc: Jiri Olsa
Signed-off-by: Taeung Song
---
tools/perf/builtin-annotate.c | 2 ++
tools/perf/util/annotate.c| 6 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 6db782d..a8e6db2 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -447,6 +447,8 @@ int cmd_annotate(int argc, const char **argv)
"Show event group information together"),
OPT_BOOLEAN(0, "show-total-period", &symbol_conf.show_total_period,
"Show a column with the sum of periods"),
+ OPT_BOOLEAN('n', "show-nr-samples", &symbol_conf.show_nr_samples,
+ "Show a column with the number of samples"),
OPT_CALLBACK_DEFAULT(0, "stdio-color", NULL, "mode",
"'always' (default), 'never' or 'auto' only applicable
to --stdio mode",
stdio__config_color, "always"),
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 5125c2b..7032bdc 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1144,6 +1144,9 @@ static int disasm_line__print(struct disasm_line *dl,
struct symbol *sym, u64 st
if (symbol_conf.show_total_period)
color_fprintf(stdout, color, " %11" PRIu64,
sample.period);
+ else if (symbol_conf.show_nr_samples)
+ color_fprintf(stdout, color, " %7" PRIu64,
+ sample.nr_samples);
else
color_fprintf(stdout, color, " %7.2f", percent);
}
@@ -1824,7 +1827,8 @@ int symbol__annotate_printf(struct symbol *sym, struct
map *map,
width *= evsel->nr_members;
graph_dotted_len = printf(" %-*.*s| Source code & Disassembly of %s for %s (%" PRIu64 " samples)\n",
- width, width, symbol_conf.show_total_period ? "Event
count" : "Percent",
+ width, width, symbol_conf.show_total_period ?
"Event count" :
+ symbol_conf.show_nr_samples ? "Samples" :
"Percent",
d_filename, evsel_name, h->nr_samples);
printf("%-*.*s\n",
--
2.7.4
linux-next: build failure after merge of the akpm tree
Hi Andrew, After merging the akpm tree, today's linux-next build (powerpc allyesconfig) failed like this: In file included from arch/powerpc/include/asm/paca.h:19:0, from arch/powerpc/include/asm/hw_irq.h:42, from arch/powerpc/include/asm/irqflags.h:11, from include/linux/irqflags.h:15, from include/linux/spinlock.h:53, from include/linux/wait.h:8, from include/linux/wait_bit.h:7, from include/linux/fs.h:5, from include/linux/buffer_head.h:11, from fs/adfs/dir_f.c:12: In function 'memcpy', inlined from '__adfs_dir_put' at fs/adfs/dir_f.c:318:2, inlined from 'adfs_f_update' at fs/adfs/dir_f.c:403:2: include/linux/string.h:305:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter __read_overflow2(); ^ I don't know why this has turned up now. I have just left it broken for now and would appreciate any fix. -- Cheers, Stephen Rothwell
Re: [PATCH v4 5/9] perf annotate stdio: Support --show-nr-samples option
On 07/29/2017 01:26 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Jul 28, 2017 at 01:16:16AM +0900, Taeung Song escreveu:
Add --show-nr-samples option to perf-annotate
so that it corresponds with perf-report.
So this is not that intuitive, i.e. if one ask for:
perf annotate --show-total-period --show-nr-samples
then both should appear, no?
- Arnaldo
I thought the users can use both --show-total-period and --show-nr-samples,
but perf-annotate can preferentially show the total period view IMHO.
What do you think about it ?
we need to prevent users from using both ?
Thanks,
Taeung
Cc: Namhyung Kim
Cc: Milian Wolff
Cc: Jiri Olsa
Signed-off-by: Taeung Song
---
tools/perf/builtin-annotate.c | 2 ++
tools/perf/util/annotate.c| 6 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 6db782d..a8e6db2 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -447,6 +447,8 @@ int cmd_annotate(int argc, const char **argv)
"Show event group information together"),
OPT_BOOLEAN(0, "show-total-period", &symbol_conf.show_total_period,
"Show a column with the sum of periods"),
+ OPT_BOOLEAN('n', "show-nr-samples", &symbol_conf.show_nr_samples,
+ "Show a column with the number of samples"),
OPT_CALLBACK_DEFAULT(0, "stdio-color", NULL, "mode",
"'always' (default), 'never' or 'auto' only applicable
to --stdio mode",
stdio__config_color, "always"),
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 5125c2b..7032bdc 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1144,6 +1144,9 @@ static int disasm_line__print(struct disasm_line *dl,
struct symbol *sym, u64 st
if (symbol_conf.show_total_period)
color_fprintf(stdout, color, " %11" PRIu64,
sample.period);
+ else if (symbol_conf.show_nr_samples)
+ color_fprintf(stdout, color, " %7" PRIu64,
+ sample.nr_samples);
else
color_fprintf(stdout, color, " %7.2f", percent);
}
@@ -1824,7 +1827,8 @@ int symbol__annotate_printf(struct symbol *sym, struct
map *map,
width *= evsel->nr_members;
graph_dotted_len = printf(" %-*.*s| Source code & Disassembly of %s for %s (%" PRIu64 " samples)\n",
- width, width, symbol_conf.show_total_period ? "Event
count" : "Percent",
+ width, width, symbol_conf.show_total_period ?
"Event count" :
+ symbol_conf.show_nr_samples ? "Samples" :
"Percent",
d_filename, evsel_name, h->nr_samples);
printf("%-*.*s\n",
--
2.7.4
Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt
On Mon, Jul 31, 2017 at 09:44:04AM +0200, Christoph Hellwig wrote: > On Mon, Jul 31, 2017 at 09:42:06AM +0200, Christoph Hellwig wrote: > > On Mon, Jul 31, 2017 at 04:36:47PM +0900, Minchan Kim wrote: > > > Do you suggest define something special flag(e.g., SWP_INMEMORY) > > > for in-memory swap to swap_info_struct when swapon time manually > > > or from bdi_queue_someting automatically? > > > And depending the flag of swap_info_struct, use the onstack bio > > > instead of dynamic allocation if the swap device is in-memory? > > > > Currently swap always just does I/O on a single page as far > > as I can tell, so it can always just use an on-stack bio and > > biovec. > > That's for synchronous I/O, aka reads of course. For writes you'll > need to do a dynamic allocation if they are asynchronous. But yes, > if we want to force certain devices to be synchronous we'll need > a flag for that. Okay, I will look into that. Thanks for the suggestion, Christoph.
[PATCH v2 1/1] usb: xhci: Add debugfs interface for xHCI driver
This adds debugfs consumer for xHCI driver. The debugfs entries
read all host registers, device/endpoint contexts, command ring,
event ring and various endpoint rings. With these entries, users
can check the registers and memory spaces used by a host during
run time, or save all the information with a simple 'cp -r' for
post-mortem programs.
The file hierarchy looks like this.
[root of debugfs]
|__usb
|[e,u,o]hci <-[root for other HCIs]
|xhci <---[root for xHCI]
|__:00:14.0 <--[xHCI host name]
|reg-cap<[capability registers]
|reg-op <---[operational registers]
|reg-runtime<---[runtime registers]
|reg-ext-#cap_name <[extended capability regs]
|command-ring <---[root for command ring]
|__cycle<--[ring cycle]
|__dequeue <[ring dequeue pointer]
|__enqueue <[ring enqueue pointer]
|__trbs <---[ring trbs]
|event-ring <-[root for event ring]
|__cycle<--[ring cycle]
|__dequeue <[ring dequeue pointer]
|__enqueue <[ring enqueue pointer]
|__trbs <---[ring trbs]
|devices<[root for devices]
|__#slot_id <---[root for a device]
|name <-[device name]
|slot-context <[slot context]
|ep-context <---[endpoint contexts]
|ep#ep_index<[root for an endpoint]
|__cycle<--[ring cycle]
|__dequeue <[ring dequeue pointer]
|__enqueue <[ring enqueue pointer]
|__trbs <---[ring trbs]
Signed-off-by: Lu Baolu
---
Change log:
v1->v2:
- No need to check return valuse of debugfs interfaces.
- Remove file entries when adding endpoint failed.
drivers/usb/host/Makefile | 4 +
drivers/usb/host/xhci-debugfs.c | 526
drivers/usb/host/xhci-debugfs.h | 137 +++
drivers/usb/host/xhci-mem.c | 5 +-
drivers/usb/host/xhci.c | 23 +-
drivers/usb/host/xhci.h | 9 +
6 files changed, 700 insertions(+), 4 deletions(-)
create mode 100644 drivers/usb/host/xhci-debugfs.c
create mode 100644 drivers/usb/host/xhci-debugfs.h
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index cf2691f..b2a7f05 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -25,6 +25,10 @@ ifneq ($(CONFIG_USB_XHCI_RCAR), )
xhci-plat-hcd-y += xhci-rcar.o
endif
+ifneq ($(CONFIG_DEBUG_FS),)
+ xhci-hcd-y += xhci-debugfs.o
+endif
+
obj-$(CONFIG_USB_WHCI_HCD) += whci/
obj-$(CONFIG_USB_PCI) += pci-quirks.o
diff --git a/drivers/usb/host/xhci-debugfs.c b/drivers/usb/host/xhci-debugfs.c
new file mode 100644
index 000..6772ee9
--- /dev/null
+++ b/drivers/usb/host/xhci-debugfs.c
@@ -0,0 +1,526 @@
+/*
+ * xhci-debugfs.c - xHCI debugfs interface
+ *
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * Author: Lu Baolu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+
+#include "xhci.h"
+#include "xhci-debugfs.h"
+
+static const struct debugfs_reg32 xhci_cap_regs[] = {
+ dump_register(CAPLENGTH),
+ dump_register(HCSPARAMS1),
+ dump_register(HCSPARAMS2),
+ dump_register(HCSPARAMS3),
+ dump_register(HCCPARAMS1),
+ dump_register(DOORBELLOFF),
+ dump_register(RUNTIMEOFF),
+ dump_register(HCCPARAMS2),
+};
+
+static const struct debugfs_reg32 xhci_op_regs[] = {
+ dump_register(USBCMD),
+ dump_register(USBSTS),
+ dump_register(PAGESIZE),
+ dump_register(DNCTRL),
+ dump_register(CRCR),
+ dump_register(DCBAAP_LOW),
+ dump_register(DCBAAP_HIGH),
+ dump_register(CONFIG),
+};
+
+static const struct debugfs_reg32 xhci_runtime_regs[] = {
+ dump_register(MFINDEX),
+ dump_register(IR0_IMAN),
+ dump_register(IR0_IMOD),
+ dump_register(IR0_ERSTSZ),
+ dump_register(IR0_ERSTBA_LOW),
+ dump_register(IR0_ERSTBA_HIGH),
+ dump_register(IR0_ERDP_LOW),
+ dump_register(IR0_ERDP_HIGH),
+};
+
+static const struct debugfs_reg32 xhci_extcap_legsup[] = {
+ dump_register(EXTCAP_USBLEGSUP),
+ dump_register(EXTCAP_USBLEGCTLSTS),
+};
+
+static const struct debugfs_reg32 xhci_extcap_protocol[] = {
+ dump
Re: linux-next: build warning after merge of the akpm tree
Hi, Stephen,
Thanks for reporting.
Stephen Rothwell writes:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> mm/swapfile.c: In function 'reuse_swap_page':
> mm/swapfile.c:1429:16: warning: 'offset' may be used uninitialized in this
> function [-Wmaybe-uninitialized]
> unsigned long offset;
> ^
>
> Introduced by commit
>
> e16cd4930836 ("mm, THP, swap: make reuse_swap_page() works for THP swapped
> out")
This looks like a false positive reporting and not reported by my
compiler and kbuild compiler (gcc-6). But anyway, we should silence it.
Best Regards,
Huang, Ying
-->8--
>From 7a7ff76d7bcbd7affda169b29abcf3dafa38052e Mon Sep 17 00:00:00 2001
From: Huang Ying
Date: Tue, 1 Aug 2017 14:12:21 +0800
Subject: [PATCH] mm, THP, swap: Silence a compiler warning
To fix the following compiler warning,
mm/swapfile.c: In function 'reuse_swap_page':
mm/swapfile.c:1429:16: warning: 'offset' may be used uninitialized in this
function [-Wmaybe-uninitialized]
unsigned long offset;
^
This is a false positive report, but we should silence it anyway.
Reported-by: Stephen Rothwell
Signed-off-by: "Huang, Ying"
---
mm/swapfile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 32434541cc12..64a94f70e867 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1426,7 +1426,7 @@ static int page_trans_huge_map_swapcount(struct page
*page, int *total_mapcount,
int *total_swapcount)
{
int i, map_swapcount, _total_mapcount, _total_swapcount;
- unsigned long offset;
+ unsigned long offset = 0;
struct swap_info_struct *si;
struct swap_cluster_info *ci = NULL;
unsigned char *map = NULL;
--
2.13.2
Re: [PATCH] f2fs: provide f2fs_balance_fs to __write_data_page for dentry pages
Hi Jay,
The SBI_BLOCK_OPS can not cover all the case, once SBI_BLOCK_OPS is
set, all the normal writeback
(before the SBI_BLOCK_OPS is clear) of dentry pages which do not come
from write_checkpoint flow will
totally miss all the f2fs_balance_fs check.
On 2017/8/1 8:44, Jaegeuk Kim wrote:
Hi Yunlong,
On 07/29, Yunlong Song wrote:
f2fs_balance_fs of dentry pages is skipped in __write_data_page due to deadlock
of gc_mutex in write_checkpoint flow. This patch enables f2fs_balance_fs for
normal dentry page writeback to ensure there are always enough free segments.
So, how about adding SBI_BLOCK_OPS
/* For s_flag in struct f2fs_sb_info */
enum {
SBI_IS_DIRTY, /* dirty flag for checkpoint */
SBI_IS_CLOSE, /* specify unmounting */
SBI_NEED_FSCK, /* need fsck.f2fs to fix */
SBI_POR_DOING, /* recovery is doing or not */
SBI_NEED_SB_WRITE, /* need to recover superblock */
SBI_NEED_CP,/* need to checkpoint */
===
SBI_BLOCK_OPS, /* doing block_operations */
===
};
How aboud avoiding f2fs_balance_fs() in __write_data_page() by:
if (!is_sbi_flag_set(sbi, SBI_BLOCK_OPS) || !S_ISDIR(inode->i_mode))
f2fs_balance_fs();
In block_operations(),
set_sbi_flag(sbi, SBI_BLOCK_OPS);
...
clear_sbi_flag(sbi, SBI_BLOCK_OPS);
Thanks,
Reported-by: Chao Yu
Signed-off-by: Yunlong Song
---
fs/f2fs/checkpoint.c | 2 +-
fs/f2fs/data.c | 67 +---
fs/f2fs/f2fs.h | 1 +
3 files changed, 61 insertions(+), 9 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 3c84a25..2882878 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -904,7 +904,7 @@ int sync_dirty_inodes(struct f2fs_sb_info *sbi, enum
inode_type type)
if (inode) {
unsigned long cur_ino = inode->i_ino;
- filemap_fdatawrite(inode->i_mapping);
+ f2fs_filemap_fdatawrite(inode->i_mapping, is_dir);
iput(inode);
/* We need to give cpu to another writers. */
if (ino == cur_ino) {
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index aefc2a5..ed7efa5 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1475,7 +1475,7 @@ int do_write_data_page(struct f2fs_io_info *fio)
}
static int __write_data_page(struct page *page, bool *submitted,
- struct writeback_control *wbc)
+ struct writeback_control *wbc, bool do_balance)
{
struct inode *inode = page->mapping->host;
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
@@ -1578,7 +1578,7 @@ static int __write_data_page(struct page *page, bool
*submitted,
}
unlock_page(page);
- if (!S_ISDIR(inode->i_mode))
+ if (do_balance)
f2fs_balance_fs(sbi, need_balance_fs);
if (unlikely(f2fs_cp_error(sbi))) {
@@ -1602,7 +1602,7 @@ static int __write_data_page(struct page *page, bool
*submitted,
static int f2fs_write_data_page(struct page *page,
struct writeback_control *wbc)
{
- return __write_data_page(page, NULL, wbc);
+ return __write_data_page(page, NULL, wbc, true);
}
/*
@@ -1611,7 +1611,7 @@ static int f2fs_write_data_page(struct page *page,
* warm/hot data page.
*/
static int f2fs_write_cache_pages(struct address_space *mapping,
- struct writeback_control *wbc)
+ struct writeback_control *wbc, bool
do_balance)
{
int ret = 0;
int done = 0;
@@ -1701,7 +1701,7 @@ static int f2fs_write_cache_pages(struct address_space
*mapping,
if (!clear_page_dirty_for_io(page))
goto continue_unlock;
- ret = __write_data_page(page, &submitted, wbc);
+ ret = __write_data_page(page, &submitted, wbc,
do_balance);
if (unlikely(ret)) {
/*
* keep nr_to_write, since vfs uses this to
@@ -1756,8 +1756,8 @@ static int f2fs_write_cache_pages(struct address_space
*mapping,
return ret;
}
-static int f2fs_write_data_pages(struct address_space *mapping,
- struct writeback_control *wbc)
+static int _f2fs_write_data_pages(struct address_space *mapping,
+ struct writeback_control *wbc, bool do_balance)
{
struct inode *inode = mapping->host;
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
@@ -1794,7 +1794,7 @@ static int f2fs_write_data_pages(struct address_space
*mapping,
goto skip_write;
blk_start_plug(&plug);
- ret = f2fs_write_cache_pa
linux-next: build warning after merge of the akpm tree
Hi Andrew,
After merging the akpm tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
mm/swapfile.c: In function 'reuse_swap_page':
mm/swapfile.c:1429:16: warning: 'offset' may be used uninitialized in this
function [-Wmaybe-uninitialized]
unsigned long offset;
^
Introduced by commit
e16cd4930836 ("mm, THP, swap: make reuse_swap_page() works for THP swapped
out")
--
Cheers,
Stephen Rothwell
Re: [RESEND PATCH v3 2/2] userfaultfd: selftest: Add tests for UFFD_FEATURE_SIGBUS feature
On Mon, Jul 31, 2017 at 09:54:06PM -0400, Prakash Sangappa wrote:
> This patch adds tests for UFFD_FEATURE_SIGBUS feature. The
> tests will verify signal delivery instead of userfault events.
> Also, test use of UFFDIO_COPY to allocate memory and retry
> accessing monitored area after signal delivery.
>
> This patch also fixes a bug in uffd_poll_thread() where 'uffd'
> is leaked.
>
> Signed-off-by: Prakash Sangappa
> ---
Reviewed-by: Mike Rapoport
> Change log
>
> v3: Eliminated use of sig_repeat variable and simplified error return.
>
> v2:
> - Added comments to explain the tests.
> - Fixed test to fail immediately if signal repeats.
> - Addressed other review comments.
>
> v1: https://lkml.org/lkml/2017/7/26/101
> ---
> tools/testing/selftests/vm/userfaultfd.c | 127
> +-
> 1 files changed, 124 insertions(+), 3 deletions(-)
>
> diff --git a/tools/testing/selftests/vm/userfaultfd.c
> b/tools/testing/selftests/vm/userfaultfd.c
> index 1eae79a..52740ae 100644
> --- a/tools/testing/selftests/vm/userfaultfd.c
> +++ b/tools/testing/selftests/vm/userfaultfd.c
> @@ -66,6 +66,7 @@
> #include
> #include
> #include
> +#include
>
> #ifdef __NR_userfaultfd
>
> @@ -408,6 +409,7 @@ static int copy_page(int ufd, unsigned long offset)
> userfaults++;
> break;
> case UFFD_EVENT_FORK:
> + close(uffd);
> uffd = msg.arg.fork.ufd;
> pollfd[0].fd = uffd;
> break;
> @@ -572,6 +574,17 @@ static int userfaultfd_open(int features)
> return 0;
> }
>
> +sigjmp_buf jbuf, *sigbuf;
> +
> +static void sighndl(int sig, siginfo_t *siginfo, void *ptr)
> +{
> + if (sig == SIGBUS) {
> + if (sigbuf)
> + siglongjmp(*sigbuf, 1);
> + abort();
> + }
> +}
> +
> /*
> * For non-cooperative userfaultfd test we fork() a process that will
> * generate pagefaults, will mremap the area monitored by the
> @@ -585,19 +598,59 @@ static int userfaultfd_open(int features)
> * The release of the pages currently generates event for shmem and
> * anonymous memory (UFFD_EVENT_REMOVE), hence it is not checked
> * for hugetlb.
> + * For signal test(UFFD_FEATURE_SIGBUS), signal_test = 1, we register
> + * monitored area, generate pagefaults and test that signal is delivered.
> + * Use UFFDIO_COPY to allocate missing page and retry. For signal_test = 2
> + * test robustness use case - we release monitored area, fork a process
> + * that will generate pagefaults and verify signal is generated.
> + * This also tests UFFD_FEATURE_EVENT_FORK event along with the signal
> + * feature. Using monitor thread, verify no userfault events are generated.
> */
> -static int faulting_process(void)
> +static int faulting_process(int signal_test)
> {
> unsigned long nr;
> unsigned long long count;
> unsigned long split_nr_pages;
> + unsigned long lastnr;
> + struct sigaction act;
> + unsigned long signalled = 0;
>
> if (test_type != TEST_HUGETLB)
> split_nr_pages = (nr_pages + 1) / 2;
> else
> split_nr_pages = nr_pages;
>
> + if (signal_test) {
> + sigbuf = &jbuf;
> + memset(&act, 0, sizeof(act));
> + act.sa_sigaction = sighndl;
> + act.sa_flags = SA_SIGINFO;
> + if (sigaction(SIGBUS, &act, 0)) {
> + perror("sigaction");
> + return 1;
> + }
> + lastnr = (unsigned long)-1;
> + }
> +
> for (nr = 0; nr < split_nr_pages; nr++) {
> + if (signal_test) {
> + if (sigsetjmp(*sigbuf, 1) != 0) {
> + if (nr == lastnr) {
> + fprintf(stderr, "Signal repeated\n");
> + return 1;
> + }
> +
> + lastnr = nr;
> + if (signal_test == 1) {
> + if (copy_page(uffd, nr * page_size))
> + signalled++;
> + } else {
> + signalled++;
> + continue;
> + }
> + }
> + }
> +
> count = *area_count(area_dst, nr);
> if (count != count_verify[nr]) {
> fprintf(stderr,
> @@ -607,6 +660,9 @@ static int faulting_process(void)
> }
> }
>
> + if (signal_test)
> + return signalled != split_nr_pages;
> +
> if (test_type == TEST_HUGETLB)
> return 0;
>
> @@ -761,7 +817,7 @@ static int userfaultfd_events_test(void)
> perror("fork"), exit(1);
>
> if (!pid)
> - retu
[PATCH v2 3/4] mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem
Nadav reported parallel MADV_DONTNEED on same range has a stale TLB
problem and Mel fixed it[1] and found same problem on MADV_FREE[2].
Quote from Mel Gorman
"The race in question is CPU 0 running madv_free and updating some PTEs
while CPU 1 is also running madv_free and looking at the same PTEs.
CPU 1 may have writable TLB entries for a page but fail the pte_dirty
check (because CPU 0 has updated it already) and potentially fail to flush.
Hence, when madv_free on CPU 1 returns, there are still potentially writable
TLB entries and the underlying PTE is still present so that a subsequent write
does not necessarily propagate the dirty bit to the underlying PTE any more.
Reclaim at some unknown time at the future may then see that the PTE is still
clean and discard the page even though a write has happened in the meantime.
I think this is possible but I could have missed some protection in madv_free
that prevents it happening."
This patch aims for solving both problems all at once and is ready for
other problem with KSM, MADV_FREE and soft-dirty story[3].
TLB batch API(tlb_[gather|finish]_mmu] uses [inc|dec]_tlb_flush_pending
and mmu_tlb_flush_pending so that when tlb_finish_mmu is called, we can catch
there are parallel threads going on. In that case, forcefully, flush TLB
to prevent for user to access memory via stale TLB entry although it fail
to gather page table entry.
I confiremd this patch works with [4] test program Nadav gave so this patch
supersedes "mm: Always flush VMA ranges affected by zap_page_range v2"
in current mmotm.
NOTE:
This patch modifies arch-specific TLB gathering interface(x86, ia64,
s390, sh, um). It seems most of architecture are straightforward but s390
need to be careful because tlb_flush_mmu works only if mm->context.flush_mm
is set to non-zero which happens only a pte entry really is cleared by
ptep_get_and_clear and friends. However, this problem never changes the
pte entries but need to flush to prevent memory access from stale tlb.
Any thoughts?
[1] http://lkml.kernel.org/r/20170725101230.5v7gvnjmcnkzz...@techsingularity.net
[2] http://lkml.kernel.org/r/20170725100722.2dxnmgypmwnrf...@suse.de
[3] http://lkml.kernel.org/r/bd3a0ebe-ecf4-41d4-87fa-c755ea9ab...@gmail.com
[4] https://patchwork.kernel.org/patch/9861621/
Cc: Ingo Molnar
Cc: Russell King
Cc: Tony Luck
Cc: Martin Schwidefsky
Cc: "David S. Miller"
Cc: Heiko Carstens
Cc: Yoshinori Sato
Cc: Jeff Dike
Cc: linux-a...@vger.kernel.org
Cc: Nadav Amit
Reported-by: Mel Gorman
Signed-off-by: Minchan Kim
---
arch/arm/include/asm/tlb.h | 7 ++-
arch/ia64/include/asm/tlb.h | 4 +++-
arch/s390/include/asm/tlb.h | 7 ++-
arch/sh/include/asm/tlb.h | 4 ++--
arch/um/include/asm/tlb.h | 7 ++-
include/asm-generic/tlb.h | 2 +-
include/linux/mm_types.h| 8
mm/memory.c | 32 +---
8 files changed, 49 insertions(+), 22 deletions(-)
diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h
index 7f5b2a2d3861..d5562f9ce600 100644
--- a/arch/arm/include/asm/tlb.h
+++ b/arch/arm/include/asm/tlb.h
@@ -168,8 +168,13 @@ arch_tlb_gather_mmu(struct mmu_gather *tlb, struct
mm_struct *mm,
static inline void
arch_tlb_finish_mmu(struct mmu_gather *tlb,
- unsigned long start, unsigned long end)
+ unsigned long start, unsigned long end, bool force)
{
+ if (force) {
+ tlb->range_start = start;
+ tlb->range_end = end;
+ }
+
tlb_flush_mmu(tlb);
/* keep the page table cache within bounds */
diff --git a/arch/ia64/include/asm/tlb.h b/arch/ia64/include/asm/tlb.h
index 93cadc04ac62..cbe5ac3699bf 100644
--- a/arch/ia64/include/asm/tlb.h
+++ b/arch/ia64/include/asm/tlb.h
@@ -187,8 +187,10 @@ arch_tlb_gather_mmu(struct mmu_gather *tlb, struct
mm_struct *mm,
*/
static inline void
arch_tlb_finish_mmu(struct mmu_gather *tlb,
- unsigned long start, unsigned long end)
+ unsigned long start, unsigned long end, bool force)
{
+ if (force)
+ tlb->need_flush = 1;
/*
* Note: tlb->nr may be 0 at this point, so we can't rely on
tlb->start_addr and
* tlb->end_addr.
diff --git a/arch/s390/include/asm/tlb.h b/arch/s390/include/asm/tlb.h
index fa4b461694b7..3a14b864b2e3 100644
--- a/arch/s390/include/asm/tlb.h
+++ b/arch/s390/include/asm/tlb.h
@@ -77,8 +77,13 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb)
static inline void
arch_tlb_finish_mmu(struct mmu_gather *tlb,
- unsigned long start, unsigned long end)
+ unsigned long start, unsigned long end, bool force)
{
+ if (force) {
+ tlb->start = start;
+ tlb->end = end;
+ }
+
tlb_flush_mmu(tlb);
}
diff --git a/arch/sh/include/asm/tlb.h b/arch/sh/include/asm/tlb.h
index 89786560dbd4..51a8bc967e75 100644
--- a/arch/sh/include
[PATCH v2 1/4] mm: refactoring TLB gathering API
This patch is ready for solving race problems caused by TLB batch.
For that, we will increase/decrease TLB flush pending count of
mm_struct whenever tlb_[gather|finish]_mmu is called.
Before making it simple, this patch separates architecture specific
part and rename it to arch_tlb_[gather|finish]_mmu and generic part
just calls it.
It shouldn't change any behavior.
Cc: Ingo Molnar
Cc: Russell King
Cc: Tony Luck
Cc: Martin Schwidefsky
Cc: "David S. Miller"
Cc: Heiko Carstens
Cc: Yoshinori Sato
Cc: Jeff Dike
Cc: linux-a...@vger.kernel.org
Cc: Nadav Amit
Cc: Mel Gorman
Signed-off-by: Minchan Kim
---
arch/arm/include/asm/tlb.h | 6 --
arch/ia64/include/asm/tlb.h | 6 --
arch/s390/include/asm/tlb.h | 12 ++--
arch/sh/include/asm/tlb.h | 6 --
arch/um/include/asm/tlb.h | 8 +---
include/asm-generic/tlb.h | 7 ---
include/linux/mm_types.h| 6 ++
mm/memory.c | 36 +---
8 files changed, 62 insertions(+), 25 deletions(-)
diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h
index 3f2eb76243e3..7f5b2a2d3861 100644
--- a/arch/arm/include/asm/tlb.h
+++ b/arch/arm/include/asm/tlb.h
@@ -148,7 +148,8 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb)
}
static inline void
-tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long
start, unsigned long end)
+arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
+ unsigned long start, unsigned long end)
{
tlb->mm = mm;
tlb->fullmm = !(start | (end+1));
@@ -166,7 +167,8 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct
*mm, unsigned long start
}
static inline void
-tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
+arch_tlb_finish_mmu(struct mmu_gather *tlb,
+ unsigned long start, unsigned long end)
{
tlb_flush_mmu(tlb);
diff --git a/arch/ia64/include/asm/tlb.h b/arch/ia64/include/asm/tlb.h
index fced197b9626..93cadc04ac62 100644
--- a/arch/ia64/include/asm/tlb.h
+++ b/arch/ia64/include/asm/tlb.h
@@ -168,7 +168,8 @@ static inline void __tlb_alloc_page(struct mmu_gather *tlb)
static inline void
-tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long
start, unsigned long end)
+arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
+ unsigned long start, unsigned long end)
{
tlb->mm = mm;
tlb->max = ARRAY_SIZE(tlb->local);
@@ -185,7 +186,8 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct
*mm, unsigned long start
* collected.
*/
static inline void
-tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
+arch_tlb_finish_mmu(struct mmu_gather *tlb,
+ unsigned long start, unsigned long end)
{
/*
* Note: tlb->nr may be 0 at this point, so we can't rely on
tlb->start_addr and
diff --git a/arch/s390/include/asm/tlb.h b/arch/s390/include/asm/tlb.h
index 950af48e88be..fa4b461694b7 100644
--- a/arch/s390/include/asm/tlb.h
+++ b/arch/s390/include/asm/tlb.h
@@ -47,10 +47,9 @@ struct mmu_table_batch {
extern void tlb_table_flush(struct mmu_gather *tlb);
extern void tlb_remove_table(struct mmu_gather *tlb, void *table);
-static inline void tlb_gather_mmu(struct mmu_gather *tlb,
- struct mm_struct *mm,
- unsigned long start,
- unsigned long end)
+static inline void
+arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
+ unsigned long start, unsigned long end)
{
tlb->mm = mm;
tlb->start = start;
@@ -76,8 +75,9 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb)
tlb_flush_mmu_free(tlb);
}
-static inline void tlb_finish_mmu(struct mmu_gather *tlb,
- unsigned long start, unsigned long end)
+static inline void
+arch_tlb_finish_mmu(struct mmu_gather *tlb,
+ unsigned long start, unsigned long end)
{
tlb_flush_mmu(tlb);
}
diff --git a/arch/sh/include/asm/tlb.h b/arch/sh/include/asm/tlb.h
index 46e0d635e36f..89786560dbd4 100644
--- a/arch/sh/include/asm/tlb.h
+++ b/arch/sh/include/asm/tlb.h
@@ -36,7 +36,8 @@ static inline void init_tlb_gather(struct mmu_gather *tlb)
}
static inline void
-tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long
start, unsigned long end)
+arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
+ unsigned long start, unsigned long end)
{
tlb->mm = mm;
tlb->start = start;
@@ -47,7 +48,8 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
unsigned long start
}
static inline void
-tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
+arch_tlb_finish_mmu(struct mmu_gather *tlb,
+ unsigned long start,
[PATCH v2 2/4] mm: make tlb_flush_pending global
Currently, tlb_flush_pending is used only for CONFIG_[NUMA_BALANCING|
COMPACTION] but upcoming patches to solve subtle TLB flush bacting
problem will use it regardless of compaction/numa so this patch
doesn't remove the dependency.
Cc: Nadav Amit
Cc: Mel Gorman
Signed-off-by: Minchan Kim
---
include/linux/mm_types.h | 21 -
mm/debug.c | 2 --
2 files changed, 23 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index c605f2a3a68e..892a7b0196fd 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -487,14 +487,12 @@ struct mm_struct {
/* numa_scan_seq prevents two threads setting pte_numa */
int numa_scan_seq;
#endif
-#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION)
/*
* An operation with batched TLB flushing is going on. Anything that
* can move process memory needs to flush the TLB when moving a
* PROT_NONE or PROT_NUMA mapped page.
*/
atomic_t tlb_flush_pending;
-#endif
#ifdef CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
/* See flush_tlb_batched_pending() */
bool tlb_flush_batched;
@@ -528,7 +526,6 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb, struct
mm_struct *mm,
extern void tlb_finish_mmu(struct mmu_gather *tlb,
unsigned long start, unsigned long end);
-#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION)
/*
* Memory barriers to keep this state in sync are graciously provided by
* the page table locks, outside of which no page table modifications happen.
@@ -569,24 +566,6 @@ static inline void dec_tlb_flush_pending(struct mm_struct
*mm)
smp_mb__before_atomic();
atomic_dec(&mm->tlb_flush_pending);
}
-#else
-static inline bool mm_tlb_flush_pending(struct mm_struct *mm)
-{
- return false;
-}
-
-static inline void init_tlb_flush_pending(struct mm_struct *mm)
-{
-}
-
-static inline void inc_tlb_flush_pending(struct mm_struct *mm)
-{
-}
-
-static inline void dec_tlb_flush_pending(struct mm_struct *mm)
-{
-}
-#endif
struct vm_fault;
diff --git a/mm/debug.c b/mm/debug.c
index d70103bb4731..18a9b15b1e37 100644
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -158,9 +158,7 @@ void dump_mm(const struct mm_struct *mm)
#ifdef CONFIG_NUMA_BALANCING
mm->numa_next_scan, mm->numa_scan_offset, mm->numa_scan_seq,
#endif
-#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION)
atomic_read(&mm->tlb_flush_pending),
-#endif
mm->def_flags, &mm->def_flags
);
}
--
2.7.4
[PATCH v2 0/4] fix several TLB batch races
Nadav and Mel founded several subtle races caused by TLB batching. This patchset aims for solving thoses problems using embedding [inc|dec]_tlb_flush_pending to TLB batching API. With that, places to know TLB flush pending catch it up by using mm_tlb_flush_pending. Each patch includes detailed description. This patchset is based on v4.13-rc2-mmots-2017-07-28-16-10 + "[PATCH v5 0/3] mm: fixes of tlb_flush_pending races" from Nadav * from v1 * TLB batching API separation core part from arch specific one - Mel * introduce mm_tlb_flush_nested - Mel Minchan Kim (4): mm: refactoring TLB gathering API mm: make tlb_flush_pending global mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem mm: fix KSM data corruption arch/arm/include/asm/tlb.h | 11 ++-- arch/ia64/include/asm/tlb.h | 8 -- arch/s390/include/asm/tlb.h | 17 - arch/sh/include/asm/tlb.h | 8 +++--- arch/um/include/asm/tlb.h | 13 +++--- fs/proc/task_mmu.c | 4 ++- include/asm-generic/tlb.h | 7 ++--- include/linux/mm_types.h| 35 ++--- mm/debug.c | 2 -- mm/ksm.c| 3 ++- mm/memory.c | 62 +++-- 11 files changed, 107 insertions(+), 63 deletions(-) -- 2.7.4
[PATCH v2 4/4] mm: fix KSM data corruption
Nadav reported KSM can corrupt the user data by the TLB batching race[1].
That means data user written can be lost.
Quote from Nadav Amit
"
For this race we need 4 CPUs:
CPU0: Caches a writable and dirty PTE entry, and uses the stale value for
write later.
CPU1: Runs madvise_free on the range that includes the PTE. It would clear
the dirty-bit. It batches TLB flushes.
CPU2: Writes 4 to /proc/PID/clear_refs , clearing the PTEs soft-dirty. We
care about the fact that it clears the PTE write-bit, and of course, batches
TLB flushes.
CPU3: Runs KSM. Our purpose is to pass the following test in
write_protect_page():
if (pte_write(*pvmw.pte) || pte_dirty(*pvmw.pte) ||
(pte_protnone(*pvmw.pte) && pte_savedwrite(*pvmw.pte)))
Since it will avoid TLB flush. And we want to do it while the PTE is stale.
Later, and before replacing the page, we would be able to change the page.
Note that all the operations the CPU1-3 perform canhappen in parallel since
they only acquire mmap_sem for read.
We start with two identical pages. Everything below regards the same
page/PTE.
CPU0CPU1CPU2CPU3
Write the same
value on page
[cache PTE as
dirty in TLB]
MADV_FREE
pte_mkclean()
4 > clear_refs
pte_wrprotect()
write_protect_page()
[ success, no flush ]
pages_indentical()
[ ok ]
Write to page
different value
[Ok, using stale
PTE]
replace_page()
Later, CPU1, CPU2 and CPU3 would flush the TLB, but that is too late. CPU0
already wrote on the page, but KSM ignored this write, and it got lost.
"
In above scenario, MADV_FREE is fixed by changing TLB batching API
including [set|clear]_tlb_flush_pending. Remained thing is soft-dirty part.
This patch changes soft-dirty uses TLB batching API instead of flush_tlb_mm
and KSM checks pending TLB flush by using mm_tlb_flush_pending so that
it will flush TLB to avoid data lost if there are other parallel threads
pending TLB flush.
[1] http://lkml.kernel.org/r/bd3a0ebe-ecf4-41d4-87fa-c755ea9ab...@gmail.com
Note:
I failed to reproduce this problem through Nadav's test program which
need to tune timing in my system speed so didn't confirm it work.
Nadav, Could you test this patch on your test machine?
Thanks!
Cc: Nadav Amit
Cc: Mel Gorman
Cc: Hugh Dickins
Cc: Andrea Arcangeli
Signed-off-by: Minchan Kim
---
fs/proc/task_mmu.c | 4 +++-
mm/ksm.c | 3 ++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 9782dedeead7..58ef3a6abbc0 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1018,6 +1018,7 @@ static ssize_t clear_refs_write(struct file *file, const
char __user *buf,
enum clear_refs_types type;
int itype;
int rv;
+ struct mmu_gather tlb;
memset(buffer, 0, sizeof(buffer));
if (count > sizeof(buffer) - 1)
@@ -1062,6 +1063,7 @@ static ssize_t clear_refs_write(struct file *file, const
char __user *buf,
}
down_read(&mm->mmap_sem);
+ tlb_gather_mmu(&tlb, mm, 0, -1);
if (type == CLEAR_REFS_SOFT_DIRTY) {
for (vma = mm->mmap; vma; vma = vma->vm_next) {
if (!(vma->vm_flags & VM_SOFTDIRTY))
@@ -1083,7 +1085,7 @@ static ssize_t clear_refs_write(struct file *file, const
char __user *buf,
walk_page_range(0, mm->highest_vm_end, &clear_refs_walk);
if (type == CLEAR_REFS_SOFT_DIRTY)
mmu_notifier_invalidate_range_end(mm, 0, -1);
- flush_tlb_mm(mm);
+ tlb_finish_mmu(&tlb, 0, -1);
up_read(&mm->mmap_sem);
out_mm:
mmput(mm);
diff --git a/mm/ksm.c b/mm/ksm.c
index 0c927e36a639..15dd7415f7b3 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1038,7 +1038,8 @@ static int write_protect_page(struct vm_area_struct *vma,
struct page *page,
goto out_unlock;
if (pte_write(*pvmw.pte) || pte_dirty(*pvmw.pte) ||
- (pte_protnone(*pvmw.pte) && pte_savedwrite(*pvmw.pte))) {
+ (pte_protnone(*pvmw.pte) && pte_savedwrite(*pvmw.pte)) ||
+ mm_tlb_flush_pending(mm)) {
pte_t entry;
swapped = PageSwapCache(page);
--
2.7.4
Re: [RFC]Add new mdev interface for QoS
On 2017/7/28 0:00, Gao, Ping A wrote: > On 2017/7/27 0:43, Alex Williamson wrote: >> [cc +libvir-list] >> >> On Wed, 26 Jul 2017 21:16:59 +0800 >> "Gao, Ping A" wrote: >> >>> The vfio-mdev provide the capability to let different guest share the >>> same physical device through mediate sharing, as result it bring a >>> requirement about how to control the device sharing, we need a QoS >>> related interface for mdev to management virtual device resource. >>> >>> E.g. In practical use, vGPUs assigned to different quests almost has >>> different performance requirements, some guests may need higher priority >>> for real time usage, some other may need more portion of the GPU >>> resource to get higher 3D performance, corresponding we can define some >>> interfaces like weight/cap for overall budget control, priority for >>> single submission control. >>> >>> So I suggest to add some common attributes which are vendor agnostic in >>> mdev core sysfs for QoS purpose. >> I think what you're asking for is just some standardization of a QoS >> attribute_group which a vendor can optionally include within the >> existing mdev_parent_ops.mdev_attr_groups. The mdev core will >> transparently enable this, but it really only provides the standard, >> all of the support code is left for the vendor. I'm fine with that, >> but of course the trouble with and sort of standardization is arriving >> at an agreed upon standard. Are there QoS knobs that are generic >> across any mdev device type? Are there others that are more specific >> to vGPU? Are there existing examples of this that we can steal their >> specification? > Yes, you are right, standardization QoS knobs are exactly what I wanted. > Only when it become a part of the mdev framework and libvirt, then QoS > such critical feature can be leveraged by cloud usage. HW vendor only > need to focus on the implementation of the corresponding QoS algorithm > in their back-end driver. > > Vfio-mdev framework provide the capability to share the device that lack > of HW virtualization support to guests, no matter the device type, > mediated sharing actually is a time sharing multiplex method, from this > point of view, QoS can be take as a generic way about how to control the > time assignment for virtual mdev device that occupy HW. As result we can > define QoS knob generic across any device type by this way. Even if HW > has build in with some kind of QoS support, I think it's not a problem > for back-end driver to convert mdev standard QoS definition to their > specification to reach the same performance expectation. Seems there are > no examples for us to follow, we need define it from scratch. > > I proposal universal QoS control interfaces like below: > > Cap: The cap limits the maximum percentage of time a mdev device can own > physical device. e.g. cap=60, means mdev device cannot take over 60% of > total physical resource. > > Weight: The weight define proportional control of the mdev device > resource between guests, it’s orthogonal with Cap, to target load > balancing. E.g. if guest 1 should take double mdev device resource > compare with guest 2, need set weight ratio to 2:1. > > Priority: The guest who has higher priority will get execution first, > target to some real time usage and speeding interactive response. > > Above QoS interfaces cover both overall budget control and single > submission control. I will sent out detail design later once get aligned. Hi Alex, Any comments about the interface mentioned above? >> Also, mdev devices are not necessarily the exclusive users of the >> hardware, we can have a native user such as a local X client. They're >> not an mdev user, so we can't support them via the mdev_attr_group. >> Does there need to be a per mdev parent QoS attribute_group standard >> for somehow defining the QoS of all the child mdev devices, or perhaps >> representing the remaining host QoS attributes? > That's really an open, if we don't take host workload into consideration > for cloud usage, it's not a problem any more, however such assumption is > not reasonable. Any way if we take mdev devices as clients of host > driver, and host driver provide the capability to divide out a portion > HW resource to mdev devices, then it's only need to take care about the > resource that host assigned for mdev devices. Follow this way QoS for > mdev focus on the relationship between mdev devices no need to take care > the host workload. > > -Ping > >> Ultimately libvirt and upper level management tools would be the >> consumer of these control knobs, so let's immediately get libvirt >> involved in the discussion. Thanks, >> >> Alex
linux-next: manual merge of the akpm tree with the wberr tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/linux/fs.h
between commit:
9dcc0577f2a4 ("mm: remove optimizations based on i_size in mapping writeback
waits")
from the wberr tree and patch:
"mm: remove optimizations based on i_size in mapping writeback waits"
from the akpm tree.
I fixed it up (I just dropped the akpm tree patch) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
Re: [PATCH V3] pci: quirk: Apply APM ACS quirk to XGene devices
On Mon, Jul 31, 2017 at 2:55 PM, Alex Williamson
wrote:
> On Mon, 31 Jul 2017 10:56:53 -0700
> Feng Kan wrote:
>
>> On Fri, Jul 28, 2017 at 4:00 PM, Alex Williamson
>> wrote:
>> > On Fri, 28 Jul 2017 11:50:43 -0700
>> > Feng Kan wrote:
>> >
>> >> The APM X-Gene PCIe root port does not support ACS at this point.
>> >> However, the hw provides isolation and source validation through
>> >> the SMMU. The stream ID generated by the PCIe ports contain both
>> >> the BDF as well as the port ID in its 3 most significant bits.
>> >> Turn on ACS but disable all the peer to peer features.
>> >>
>> >> Signed-off-by: Feng Kan
>> >> ---
>> >> V3 Change: Add comment regarding unique port id in stream ID
>> >> V2 Change: Move XGene ACS quirk to unique XGene function
>> >>
>> >> drivers/pci/quirks.c | 15 +++
>> >> 1 file changed, 15 insertions(+)
>> >>
>> >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> >> index 085fb78..0f8f1cd 100644
>> >> --- a/drivers/pci/quirks.c
>> >> +++ b/drivers/pci/quirks.c
>> >> @@ -4120,6 +4120,19 @@ static int pci_quirk_cavium_acs(struct pci_dev
>> >> *dev, u16 acs_flags)
>> >> return acs_flags ? 0 : 1;
>> >> }
>> >>
>> >> +static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags)
>> >> +{
>> >> + /*
>> >> + * XGene root matching this quirk do not allow peer-to-peer
>> >> + * transactions with others, allowing masking out these bits as if
>> >> they
>> >> + * were unimplemented in the ACS capability.
>> >> + */
>> >> + acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR |
>> >> +PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT);
>> >> +
>> >> + return acs_flags ? 0 : 1;
>> >> +}
>> >> +
>> >> /*
>> >> * Many Intel PCH root ports do provide ACS-like features to disable peer
>> >> * transactions and validate bus numbers in requests, but do not provide
>> >> an
>> >> @@ -4368,6 +4381,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev
>> >> *dev, u16 acs_flags)
>> >> { 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
>> >> /* Cavium ThunderX */
>> >> { PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
>> >> + /* APM XGene */
>> >> + { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
>> >> { 0 }
>> >> };
>> >>
>> >
>> > Hi Feng,
>> >
>> > Sorry, I have one more question as I happened to spend some time
>> > looking at PCI_ACS_DT this week. DT specifies that peer-to-peer should
>> > occur normally between egress ports for transactions which are
>> > pre-translated by an ATS unit on the endpoint. Therefore if a root
>> > port doesn't allow peer-to-peer, it seems like it should not claim to
>> > support PCI_ACS_DT. I know your quirk is just a copy of the Cavium
>> > one, but we should also go back and verify this question with them, or
>> > perhaps I'm misinterpreting this capability. AIUI this is also a
>> > performance capability, not an isolation capability, so it shouldn't
>> > affect the ability to consider a device isolated, it only gets
>> > confusing if we expect a performance benefit from this but don't
>> > actually see one. Does your root port have this ability to
>> > selectively allow peer-to-peer of pre-translated transactions? Thanks,
>> We do not support peer to peer between root ports (each root port is a
>> root complex in itself).
>> Therefore, this bit set/unset has no effect.
>>
>> As one of our guys pointed out in PCIe 3.1a, it may help address your
>> concern above.
>>
>> """
>> Root Port indication of ACS Direct Translated P2P support does not imply any
>> particular level of peer-to-peer support by the Root Complex, or that
>> peer-to-peer traffic is supported at all.
>> """
>
> That's interesting, but is that referring to the ACS capability or the
> control?
I could imagine how advertising the capability would not
> imply any particular level of p2p, but enabling the control (which is
> what we're claiming via this quirk) the spec states:
>
> When ACS Direct Translated P2P is enabled in a Downstream Port,
> peer-to-peer Memory Requests whose Address Type (AT) field indicates
> a Translated address must be routed normally (“directly”) to the peer
> Egress Port, regardless of ACS P2P Request Redirect and ACS P2P
> Egress Control settings. All other peer-to-peer Requests must still
> be subject to ACS P2P Request Redirect and ACS P2P Egress Control
> settings.
>
> Note the *must* phrasing. Furthermore, 7.16.3:
>
> ACS Direct Translated P2P Enable (T) – When Set, overrides the ACS
> P2P Request Redirect and ACS P2P Egress Control mechanisms with
> peer-to-peer Memory Requests whose Address Translation (AT) field
> indicates a Translated address (see Section 6.12.3).
>
> This bit is ignored if ACS Translation Blocking Enable (B) is 1b.
>
> Default value of this bit is 0b. Must be hardwired to 0b if the ACS
> Direct Translated P2P functionality is not implemented.
>
> Not
Re: [GIT PULL] Please pull NFS client changes for Linux 4.13
On Mon, Jul 31, 2017 at 8:43 AM, da...@codemonkey.org.uk wrote: > Another NFSv4 KASAN splat, this time from rc3. > > BUG: KASAN: use-after-free in nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4] Ugh. It's really hard to tell what access that it - KASAN doesn't actually give enough information. There's lots of 8-byte accesses there in that function. Any chance of getting the output from ./scripts/faddr2line vmlinux nfs4_exchange_id_done+0x3d7/0x8e0 or something? That would be extremely useful in general for stacktraces, but it's doubly useful for KASAN because most *other* stacktraces tend to have a very limited number of things that can warn (ie there's one or two WARN_ON() calls in a function), but KASAN can have tens or hundreds.. Linus > Read of size 8 at addr 8804508af528 by task kworker/2:1/34 > > CPU: 2 PID: 34 Comm: kworker/2:1 Not tainted 4.13.0-rc3-think+ #1 > Workqueue: rpciod rpc_async_schedule [sunrpc] > Call Trace: > dump_stack+0x68/0xa1 > print_address_description+0xd9/0x270 > kasan_report+0x257/0x370 > ? nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4] > check_memory_region+0x13a/0x1a0 > __asan_loadN+0xf/0x20 > nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4] > ? nfs4_exchange_id_release+0xb0/0xb0 [nfsv4] > rpc_exit_task+0x69/0x110 [sunrpc] > ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc] > ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc] > __rpc_execute+0x1a0/0x840 [sunrpc] > ? rpc_wake_up_queued_task+0x50/0x50 [sunrpc] > ? __lock_is_held+0x9a/0x100 > ? debug_lockdep_rcu_enabled.part.16+0x1a/0x30 > rpc_async_schedule+0x12/0x20 [sunrpc] > process_one_work+0x4d5/0xa70 > ? flush_delayed_work+0x70/0x70 > ? lock_acquire+0xfc/0x220 > worker_thread+0x88/0x630 > ? pci_mmcfg_check_reserved+0xc0/0xc0 > kthread+0x1a6/0x1f0 > ? process_one_work+0xa70/0xa70 > ? kthread_create_on_node+0xc0/0xc0 > ret_from_fork+0x27/0x40 > > Allocated by task 1: > save_stack_trace+0x1b/0x20 > save_stack+0x46/0xd0 > kasan_kmalloc+0xad/0xe0 > kasan_slab_alloc+0x12/0x20 > kmem_cache_alloc+0xe0/0x2f0 > getname_flags+0x43/0x220 > getname+0x12/0x20 > do_sys_open+0x14c/0x2b0 > SyS_open+0x1e/0x20 > do_syscall_64+0xea/0x260 > return_from_SYSCALL_64+0x0/0x7a > > Freed by task 1: > save_stack_trace+0x1b/0x20 > save_stack+0x46/0xd0 > kasan_slab_free+0x72/0xc0 > kmem_cache_free+0xa8/0x300 > putname+0x80/0x90 > do_sys_open+0x22f/0x2b0 > SyS_open+0x1e/0x20 > do_syscall_64+0xea/0x260 > return_from_SYSCALL_64+0x0/0x7a > > The buggy address belongs to the object at 8804508aeac0\x0a which belongs > to the cache names_cache of size 4096 > The buggy address is located 2664 bytes inside of\x0a 4096-byte region > [8804508aeac0, 8804508afac0) > The buggy address belongs to the page: > page:ea0011422a00 count:1 mapcount:0 mapping: (null) index:0x0 > [CONT START] compound_mapcount: 0 > flags: 0x80008100(slab|head) > raw: 80008100 000100070007 > raw: ea00113d6020 ea001136e220 8804664f8040 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > 8804508af400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > 8804508af480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >>8804508af500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ^ > 8804508af580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > 8804508af600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > == >
Re: [PATCH v7 08/15] RISC-V: Atomic and Locking Code
On Mon, Jul 31, 2017 at 06:00:02PM -0700, Palmer Dabbelt wrote:
> This contains all the code that directly interfaces with the RISC-V
> memory model. While this code corforms to the current RISC-V ISA
> specifications (user 2.2 and priv 1.10), the memory model is somewhat
> underspecified in those documents. There is a working group that hopes
> to produce a formal memory model by the end of the year, but my
> understanding is that the basic definitions we're relying on here won't
> change significantly.
>
> Signed-off-by: Palmer Dabbelt
> ---
> arch/riscv/include/asm/atomic.h | 328
>
> arch/riscv/include/asm/barrier.h| 68 +++
> arch/riscv/include/asm/bitops.h | 218 +
> arch/riscv/include/asm/cacheflush.h | 39
> arch/riscv/include/asm/cmpxchg.h| 134 +
> arch/riscv/include/asm/io.h | 303 +
> arch/riscv/include/asm/spinlock.h | 165
> arch/riscv/include/asm/spinlock_types.h | 33
> arch/riscv/include/asm/tlb.h| 24 +++
> arch/riscv/include/asm/tlbflush.h | 64 +++
> 10 files changed, 1376 insertions(+)
> create mode 100644 arch/riscv/include/asm/atomic.h
> create mode 100644 arch/riscv/include/asm/barrier.h
> create mode 100644 arch/riscv/include/asm/bitops.h
> create mode 100644 arch/riscv/include/asm/cacheflush.h
> create mode 100644 arch/riscv/include/asm/cmpxchg.h
> create mode 100644 arch/riscv/include/asm/io.h
> create mode 100644 arch/riscv/include/asm/spinlock.h
> create mode 100644 arch/riscv/include/asm/spinlock_types.h
> create mode 100644 arch/riscv/include/asm/tlb.h
> create mode 100644 arch/riscv/include/asm/tlbflush.h
>
> diff --git a/arch/riscv/include/asm/atomic.h b/arch/riscv/include/asm/atomic.h
> new file mode 100644
> index ..ee3ab06e492b
> --- /dev/null
> +++ b/arch/riscv/include/asm/atomic.h
> @@ -0,0 +1,328 @@
> +/*
> + * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
> + * Copyright (C) 2012 Regents of the University of California
> + * Copyright (C) 2017 SiFive
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + */
> +
> +#ifndef _ASM_RISCV_ATOMIC_H
> +#define _ASM_RISCV_ATOMIC_H
> +
> +#ifdef CONFIG_GENERIC_ATOMIC64
> +# include
> +#else
> +# if (__riscv_xlen < 64)
> +# error "64-bit atomics require XLEN to be at least 64"
> +# endif
> +#endif
> +
> +#include
> +#include
> +
> +#define ATOMIC_INIT(i) { (i) }
> +static __always_inline int atomic_read(const atomic_t *v)
> +{
> + return READ_ONCE(v->counter);
> +}
> +static __always_inline void atomic_set(atomic_t *v, int i)
> +{
> + WRITE_ONCE(v->counter, i);
> +}
> +
> +#ifndef CONFIG_GENERIC_ATOMIC64
> +#define ATOMIC64_INIT(i) { (i) }
> +static __always_inline int atomic64_read(const atomic64_t *v)
^
should be "long long"?
> +{
> + return READ_ONCE(v->counter);
> +}
> +static __always_inline void atomic64_set(atomic64_t *v, int i)
^
Ditto.
Have you ever run the selftest with CONFIG_ATOMIC64_SELFTEST=y?
Regards,
Boqun
> +{
> + WRITE_ONCE(v->counter, i);
> +}
> +#endif
> +
[...]
signature.asc
Description: PGP signature
Re: [PATCH v2] Bluetooth: btusb: add ID for LiteOn 04ca:3016
Hi Brian, On Mon, Jul 31, 2017, Brian Norris wrote: > Contains a QCA6174A-5 chipset, with USB BT. Let's support loading > firmware on it. > > From usb-devices: > T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 > D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=04ca ProdID=3016 Rev=00.01 > C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA > I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > > Signed-off-by: Brian Norris > --- > v2: > * include usb-devices info in commit message > > drivers/bluetooth/btusb.c | 1 + > 1 file changed, 1 insertion(+) Applied to bluetooth-next. Thanks. Johan
linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/kernel/rtas.c: In function 'rtas_online_cpus_mask':
arch/powerpc/kernel/rtas.c:917:37: error: 'GFP_KENREL' undeclared (first use in
this function)
if (!alloc_cpumask_var(&tmp_mask, GFP_KENREL))
^
Caused by commit
404170cf1c4c ("mm: treewide: remove GFP_TEMPORARY allocation flag")
I added the following patch:
From: Stephen Rothwell
Date: Tue, 1 Aug 2017 15:25:33 +1000
Subject: [PATCH] mm: treewide: remove GFP_TEMPORARY allocation flag fix
Signed-off-by: Stephen Rothwell
---
arch/powerpc/kernel/rtas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 90d27dcd0da8..1643e9e53655 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -914,7 +914,7 @@ int rtas_online_cpus_mask(cpumask_var_t cpus)
if (ret) {
cpumask_var_t tmp_mask;
- if (!alloc_cpumask_var(&tmp_mask, GFP_KENREL))
+ if (!alloc_cpumask_var(&tmp_mask, GFP_KERNEL))
return ret;
/* Use tmp_mask to preserve cpus mask from first failure */
--
2.13.2
--
Cheers,
Stephen Rothwell
RE: Issue with commit de3ef1eb1cd - PM / core: Drop run_wake flag from struct dev_pm_info [Was: MEI-related WARN_ON() triggered during resume-from-sleep on v4.13-rc2+]
Hi We using pci_dev_run_wake that changed in mentioned patch to decide if to replace usual PM callbacks with domain ones. IIRC, the mei device is not remote wakeable on that platform, so we should set domain callbacks. There was a patch in PM framework that squashes runtime suspend with usual suspend for some devices. May it be that now pci_dev_run_wake returns true form mei and we are not setting domain callbacks? In that case we going through PCI device level PM path and may trigger that squash. That will explain lack of mei logs on suspend. Dominik, can you try comment out "if (!pci_dev_run_wake(pdev))" at drivers/misc/mei/pci-me.c (around line 223) to set domain callbacks by force to see if this is indeed the case? -- Alexander (Sasha) Usyskin ISDC TEE CoE – HECI et alii Intel Corporation -Original Message- From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael J. Wysocki Sent: Tuesday, August 01, 2017 03:05 To: Rafael J. Wysocki Cc: Dominik Brodowski ; Winkler, Tomas ; Wysocki, Rafael J ; Mika Westerberg ; Bjorn Helgaas ; Usyskin, Alexander ; linux-kernel@vger.kernel.org; Linux PM ; ACPI Devel Maling List Subject: Re: Issue with commit de3ef1eb1cd - PM / core: Drop run_wake flag from struct dev_pm_info [Was: MEI-related WARN_ON() triggered during resume-from-sleep on v4.13-rc2+] On Tue, Aug 1, 2017 at 1:55 AM, Rafael J. Wysocki wrote: > Hi, > > On Tue, Aug 1, 2017 at 12:16 AM, Dominik Brodowski > wrote: >> Rafael, Mika, Bjorn and Tomas, >> >> can't explain exactly what causes breakage between MEI and PM first >> seen on >> v4.13-rc2 (ther was a typo in the orignal message), but I was able to >> bisect it down to commit >> >> [de3ef1eb1cd0cc3a75f7a3661e10ed827f370ab8] PM / core: Drop run_wake >> flag from struct dev_pm_info >> > > [cut] > >>> >>> > [ 192.940537] Restarting tasks ... >>> > [ 192.940610] PGI is not set >>> > [ 192.940619] [ cut here ] [ 192.940623] >>> > WARNING: CPU: 0 >>> > PID: 1661 at >>> > /home/brodo/local/kernel/git/linux/drivers/misc/mei/hw- >>> > me.c:653 mei_me_pg_exit_sync+0x351/0x360 [ 192.940624] Modules >>> > linked >>> > in: >>> > [ 192.940627] CPU: 0 PID: 1661 Comm: kworker/0:3 Not tainted >>> > 4.13.0-rc2+ >>> > #2 [ 192.940628] Hardware name: Dell Inc. XPS 13 9343/0TM99H, >>> > BIOS A11 >>> > 12/08/2016 [ 192.940630] Workqueue: pm pm_runtime_work [ >>> > 192.940642] Call Trace: >>> > [ 192.940646] ? pci_pme_active+0x1de/0x1f0 [ 192.940649] ? >>> > pci_restore_standard_config+0x50/0x50 >>> > [ 192.940651] ? kfree+0x172/0x190 [ 192.940653] ? >>> > kfree+0x172/0x190 [ 192.940655] ? >>> > pci_restore_standard_config+0x50/0x50 >>> > [ 192.940663] mei_me_pm_runtime_resume+0x3f/0xc0 >>> > [ 192.940665] pci_pm_runtime_resume+0x7a/0xa0 [ 192.940667] >>> > __rpm_callback+0xb9/0x1e0 [ 192.940668] ? >>> > preempt_count_add+0x6d/0xc0 [ 192.940670] rpm_callback+0x24/0x90 >>> > [ 192.940672] ? pci_restore_standard_config+0x50/0x50 >>> > [ 192.940674] rpm_resume+0x4e8/0x800 [ 192.940676] >>> > pm_runtime_work+0x55/0xb0 [ 192.940678] >>> > process_one_work+0x184/0x3e0 [ 192.940680] >>> > worker_thread+0x4d/0x3a0 [ 192.940681] ? >>> > preempt_count_sub+0x9b/0x100 [ 192.940683] >>> > kthread+0x122/0x140 [ 192.940684] ? process_one_work+0x3e0/0x3e0 >>> > kthread+[ >>> > 192.940685] ? __kthread_create_on_node+0x1a0/0x1a0 >>> > [ 192.940688] ret_from_fork+0x27/0x40 [ 192.940690] Code: 96 3a >>> > 9e ff 48 8b 7d 98 e8 cd 21 58 00 83 bb bc 01 00 00 >>> > 04 0f 85 40 fe ff ff e9 41 fe ff ff 48 c7 c7 5f 04 99 96 e8 93 6b >>> > 9f ff <0f> ff e9 5d fd ff ff e8 33 fe 99 ff 0f 1f 00 0f 1f 44 00 >>> > 00 55 [ 192.940719] ---[ end trace >>> > a86955597774ead8 ]--- [ 192.942540] done. >>> > >>> > This doesn't / didn't happen on v4.12. >> >> >> By using the dynamic_debug infrastructure, I was able to obtain a few >> more data points: >> >> Running 0847684cfc5f, when suspending the system to ram and resuming >> again, I see the following messages: > > You have removed some relevant parts of the log, but I think I see > what's going on. > >> [ 614.936773] sd 3:0:0:0: [sda] Stopping disk >> [ 614.956004] mei_me :00:16.0: rpm: me: runtime resume > > This is a runtime resume during system suspend. > >> [ 614.956165] ACPI : EC: event blocked >> [ 614.980164] mei_me :00:16.0: interrupt source 0x0002 >> [ 614.980191] mei_me :00:16.0: function called after ISR to >> handle the interrupt processing. >> ... >> [ 615.266896] Suspended for 1.190 seconds >> ... >> [ 615.455775] sd 3:0:0:0: [sda] Starting disk >> [ 615.455855] mei_me :00:16.0: interrupt source 0x0002 >> [ 615.455870] mei_me :00:16.0: function called after ISR to >> handle the interrupt processing. >> [ 615.455877] mei_me :00:16.0: we need to start the dev. >> >> and everything
linux-next: build warning after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
fs/proc/task_mmu.c: In function 'show_map_vma':
fs/proc/task_mmu.c:285:28: warning: unused variable 'priv' [-Wunused-variable]
struct proc_maps_private *priv = m->private;
^
Introduced by commit
14ccc3193225 ("fs, proc: remove priv argument from is_stack")
--
Cheers,
Stephen Rothwell
Re: "BUG: unable to handle kernel NULL pointer dereference" in swapping shmem
Hello Huang, On Tue, Aug 01, 2017 at 11:30:41AM +0800, Huang, Ying wrote: > Hi, Horiguchi san, > > Naoya Horiguchi writes: > > > Hi, > > > > I found the following bug when testing mmotm-2017-07-31-16-56. > > The triggering testcase just swaps in/out shmem pages. > > It seems to me related to thp swapping improvement patchset, > > so let me report this to the relevant people. > > > > Thanks, > > Naoya Horiguchi > > --- ... > > Thanks for reporting! Do you test it on a HDD? I can reproduce this on > a HDD, the fix patch is as follow, could you try it? Yes, my test ran on a HDD. And I confirmed that the suggested patch fixes the panic. Thank you for your quick work. - Naoya Horiguchi > > Best Regards, > Huang, Ying > > ->8- > From 2487f0230fef59c1ef89792e2af7bcabc02470cf Mon Sep 17 00:00:00 2001 > From: Huang Ying > Date: Tue, 1 Aug 2017 11:20:23 +0800 > Subject: [PATCH] mm, THP, swap: Fix swap_page_trans_huge_swapped on HDD > > To fix the following kernel bug, > > [ 112.690842] ===> testcase 'mm/shmem_swap' start > [ 112.788440] Adding 40956k swap on > /mnt/tests/examples/regression/kernel/mm_regression/mm_regression/work/swapfile. > Priority:-2 extents:1 across:40956k FS > [ 112.815903] bash (17346): drop_caches: 3 > [ 112.975713] BUG: unable to handle kernel NULL pointer dereference at > 0007 > [ 112.984464] IP: swap_page_trans_huge_swapped+0x49/0xd0 > [ 112.990202] PGD 805e62067 > [ 112.990202] P4D 805e62067 > [ 112.993219] PUD 80447b067 > [ 112.996236] PMD 0 > [ 112.999253] > [ 113.003155] Oops: [#1] SMP > [ 113.006658] Modules linked in: nfsv4 dns_resolver nfs fscache > xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 > iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 > xt_conntrack nf_conntrack libcrc32c ipt_REJECT nf_reject_ipv4 tun > bridge stp llc ebtable_filter ebtables ip6_tables iptable_filter > intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm > iTCO_wdt nfsd iTCO_vendor_support mei_me auth_rpcgss mei lpc_ich > ipmi_si ipmi_devintf irqbypass nfs_acl shpchp sg mfd_core ie31200_edac > lockd ipmi_msghandler pcspkr video acpi_pad grace sunrpc ip_tables > sr_mod sd_mod cdrom tg3 ata_generic pata_acpi ata_piix ptp libata > megaraid_sas crc32c_intel pps_core dm_mirror dm_region_hash dm_log > dm_mod > [ 113.077676] CPU: 0 PID: 17431 Comm: test_alloc_gene Not tainted > 4.13.0-rc3-mm1-v4.13-rc3-mmotm-2017-07-31-16-56+ #1 > [ 113.089323] Hardware name: NEC Express5800/T110g-E > [N8100-2187Y]/GA-6LASV1, BIOS 4.6.1204 10/17/2014 > [ 113.099516] task: a06705de9740 task.stack: ac0947c0c000 > [ 113.106124] RIP: 0010:swap_page_trans_huge_swapped+0x49/0xd0 > [ 113.112438] RSP: 0018:ac0947c0fb38 EFLAGS: 00010246 > [ 113.118269] RAX: RBX: RCX: > 0040 > [ 113.126233] RDX: 0001 RSI: 05d6 RDI: > a06705674cfc > [ 113.134196] RBP: ac0947c0fb60 R08: R09: > 88ca2180 > [ 113.142161] R10: 0230 R11: a066e7a9b451 R12: > a06705674c00 > [ 113.150123] R13: 05d6 R14: 0400 R15: > ac0944001000 > [ 113.158088] FS: 7f855b243740() GS:a0672fc0() > knlGS: > [ 113.167118] CS: 0010 DS: ES: CR0: 80050033 > [ 113.173529] CR2: 0007 CR3: 000808de2002 CR4: > 001606f0 > [ 113.181493] Call Trace: > [ 113.184222] free_swap_and_cache+0x73/0x1d0 > [ 113.19] shmem_free_swap+0x5e/0x70 > [ 113.193072] shmem_undo_range+0x4bd/0x8b0 > [ 113.197547] shmem_truncate_range+0x14/0x40 > [ 113.202211] shmem_evict_inode+0xba/0x190 > [ 113.206686] evict+0xd3/0x1a0 > [ 113.210004] iput+0x17d/0x1d0 > [ 113.213316] dentry_unlink_inode+0xb9/0xf0 > [ 113.217887] __dentry_kill+0xc7/0x170 > [ 113.221994] dput+0x19c/0x1d0 > [ 113.225311] __fput+0x188/0x210 > [ 113.228813] fput+0xe/0x10 > [ 113.232221] task_work_run+0x86/0xa0 > [ 113.236209] exit_to_usermode_loop+0x6d/0x99 > [ 113.240981] syscall_return_slowpath+0xad/0xd0 > [ 113.245961] entry_SYSCALL_64_fastpath+0xa3/0xa5 > [ 113.251127] RIP: 0033:0x7f855a940b17 > [ 113.255113] RSP: 002b:7fff955b5048 EFLAGS: 0206 ORIG_RAX: > 001f > [ 113.263562] RAX: RBX: RCX: > 7f855a940b17 > [ 113.271524] RDX: RSI: RDI: > 00028001 > [ 113.279488] RBP: 7fff955b5060 R08: R09: > > [ 113.287450] R10: 7fff955b4dd0 R11: 0206 R12: > 00401da0 > [ 113.295414] R13: 7fff955b5350 R14: R15: > > [ 113.303378] Code: f5 41 54 49 89 fc 53 48 8b 47 70 4c 8b 7f 68 48 85 > c0 74 70 4c 89 f3 48 c1 eb 06 48 01 c3 48 89 df e8 fc 10 54 00 48 85 > db 74 59 43 07 04 75 31 48 b8 ff ff ff ff ff ff ff 01 49 21 c5 43 > 80 > [ 113.324450] RIP: swap_page_
[GIT] Networking
1) Handle notifier registry failures properly in tun/tap driver, from Tonghao Zhang. 2) Fix bpf verifier handling of subtraction bounds and add a testcase for this, from Edward Cree. 3) Increase reset timeout in ftgmac100 driver, from Ben Herrenschmidt. 4) Fix use after free in prd_retire_rx_blk_timer_exired() in AF_PACKET, from Cong Wang. 5) Fix SElinux regression due to recent UDP optimizations, from Paolo Abeni. 6) We accidently increment IPSTATS_MIB_FRAGFAILS in the ipv6 code paths, fix from Stefano Brivio. 7) Fix some mem leaks in dccp, from Xin Long. 8) Adjust MDIO_BUS kconfig deps to avoid build errors, from Arnd Bergmann. 9) Mac address length check and buffer size fixes from Cong Wang. 10) Don't leak sockets in ipv6 udp early demux, from Paolo Abeni. 11) Fix return value when copy_from_user() fails in bpf_prog_get_info_by_fd(), from Daniel Borkmann. 12) Handle PHY_HALTED properly in phy library state machine, from Florian Fainelli. 13) Fix OOPS in fib_sync_down_dev(), from Ido Schimmel. 14) Fix truesize calculation in virtio_net which led to performance regressions, from Michael S. Tsirkin. Please pull, thanks a lot! The following changes since commit 96080f697786e0a30006fcbcc5b53f350fcb3e9f: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-07-20 16:33:39 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git for you to fetch changes up to cc75f8514db6a3aec517760fccaf954e5b46478c: samples/bpf: fix bpf tunnel cleanup (2017-07-31 22:02:47 -0700) Alex Vesker (1): net/mlx5e: IPoIB, Modify add/remove underlay QPN flows Arend Van Spriel (2): brcmfmac: fix regression in brcmf_sdio_txpkt_hdalign() brcmfmac: fix memleak due to calling brcmf_sdiod_sgtable_alloc() twice Arnd Bergmann (3): net: phy: rework Kconfig settings for MDIO_BUS phy: bcm-ns-usb3: fix MDIO_BUS dependency tcp: avoid bogus gcc-7 array-bounds warning Aviv Heller (1): net/mlx5: Consider tx_enabled in all modes on remap Benjamin Herrenschmidt (2): ftgmac100: Increase reset timeout ftgmac100: Make the MDIO bus a child of the ethernet device Colin Ian King (1): net: tc35815: fix spelling mistake: "Intterrupt" -> "Interrupt" Dan Carpenter (1): iwlwifi: missing error code in iwl_trans_pcie_alloc() Daniel Borkmann (2): bpf: don't indicate success when copy_from_user fails bpf: fix bpf_prog_get_info_by_fd to dump correct xlated_prog_len Daniel Stone (1): brcmfmac: Don't grow SKB by negative size David S. Miller (4): Merge branch 'bpf-fix-verifier-min-max-handling-in-BPF_SUB' Merge tag 'wireless-drivers-for-davem-2017-07-21' of git://git.kernel.org/.../kvalo/wireless-drivers Merge tag 'mlx5-fixes-2017-07-27-V2' of git://git.kernel.org/.../saeed/linux Merge tag 'wireless-drivers-for-davem-2017-07-28' of git://git.kernel.org/.../kvalo/wireless-drivers Edward Cree (2): selftests/bpf: subtraction bounds test bpf/verifier: fix min/max handling in BPF_SUB Emmanuel Grumbach (3): iwlwifi: dvm: prevent an out of bounds access iwlwifi: mvm: fix a NULL pointer dereference of error in recovery iwlwifi: fix tracing when tx only is enabled Eran Ben Elisha (1): net/mlx5: Clean SRIOV eswitch resources upon VF creation failure Eugenia Emantayev (7): net/mlx5: Fix mlx5_ifc_mtpps_reg_bits structure size net/mlx5e: Add field select to MTPPS register net/mlx5e: Fix broken disable 1PPS flow net/mlx5e: Change 1PPS out scheme net/mlx5e: Add missing support for PTP_CLK_REQ_PPS request net/mlx5e: Fix wrong delay calculation for overflow check scheduling net/mlx5e: Schedule overflow check work to mlx5e workqueue Florian Fainelli (4): net: dsa: Initialize ds->cpu_port_mask earlier net: phy: Correctly process PHY_HALTED in phy_stop_machine() MAINTAINERS: Add more files to the PHY LIBRARY section Revert "net: bcmgenet: Remove init parameter from bcmgenet_mii_config" Gao Feng (1): ppp: Fix a scheduling-while-atomic bug in del_chan Ido Schimmel (2): mlxsw: spectrum_router: Don't offload routes next in list ipv4: fib: Fix NULL pointer deref during fib_sync_down_dev() Ilan Tayari (1): net/mlx5e: Fix outer_header_zero() check size Jakub Kicinski (1): bpf: don't zero out the info struct in bpf_obj_get_info_by_fd() Jason Wang (1): Revert "vhost: cache used event for better performance" Joel Stanley (1): ftgmac100: return error in ftgmac100_alloc_rx_buf Johannes Berg (1): iwlwifi: mvm: defer setting IWL_MVM_STATUS_IN_HW_RESTART Kalle Valo (1): Merge tag 'iwlwifi-for-kalle-2017-07-21' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes Larry Finger (1): Revert "rtlwifi: btcoex: rtl8723be: fix ant_sel not
Re: [PATCH v4 00/15] exec: Use sane stack rlimit under secureexec
On Mon, Jul 31, 2017 at 10:11 PM, Linus Torvalds wrote: > > And I just checked this on a separate branch, just because I wanted to > see what the overall diff was. There's a conflict [..] Side note: the overall patch looks fine to me. I like how it removes complexity and code. I didn't test it (other than test *building* the merge), so take that for what it's worth, but at least the patches look sensible both on an individual level and as an end result. Linus
Re: [PATCH v4 00/15] exec: Use sane stack rlimit under secureexec
On Mon, Jul 31, 2017 at 8:03 PM, Kees Cook wrote: > > Yeah, I'm open to whatever. It's not clear where it should go, but if > you want to take it and Linus doesn't want it "early", that works for > me. Linus, Andrew, thoughts? I'd actually like this to go in separately from all the other security stuff. And I just checked this on a separate branch, just because I wanted to see what the overall diff was. There's a conflict with apparmor already - the resolution looks fairly straightforward, but considering the area this touches, it would probably be good that Kees keeps this branch and verifies things like that. Linus
[PATCH] staging/pi433: Solved some coding style issues in pi433_if.c
From: Rishabh Hardas
Solved a few coding style issues, used BIT macro to set MINORBITS.
Signed-off-by: Rishabh Hardas
---
drivers/staging/pi433/pi433_if.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index d9328ce..f10ffc3 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -47,18 +47,18 @@
#include
#include
#include
+#include
#ifdef CONFIG_COMPAT
-#include
+#include
#endif
#include "pi433_if.h"
#include "rf69.h"
-
-#define N_PI433_MINORS (1U << MINORBITS) /*32*//* ...
up to 256 */
-#define MAX_MSG_SIZE 900 /* min: FIFO_SIZE! */
-#define MSG_FIFO_SIZE 65536 /* 65536 = 2^16 */
-#define NUM_DIO2
+#define N_PI433_MINORS BIT(MINORBITS) /*32*/ /* ... up to 256 */
+#define MAX_MSG_SIZE 900 /* min: FIFO_SIZE! */
+#define MSG_FIFO_SIZE 65536 /* 65536 = 2^16 */
+#define NUM_DIO2
static dev_t pi433_dev;
static DEFINE_IDR(pi433_idr);
@@ -66,10 +66,14 @@
static struct class *pi433_class; /* mainly for udev to create /dev/pi433 */
-/* tx config is instance specific
- so with each open a new tx config struct is needed */
-/* rx config is device specific
- so we have just one rx config, ebedded in device struct */
+/*
+ * tx config is instance specific
+ * so with each open a new tx config struct is needed
+ */
+/*
+ * rx config is device specific
+ * so we have just one rx config, ebedded in device struct
+ */
struct pi433_device {
/* device handling related values */
dev_t devt;
--
1.9.1
Re: [PATCH v2] Coccinelle: Script to remove unnecessary static on local variables
Acked-by: Julia Lawall
On Mon, 31 Jul 2017, Gustavo A. R. Silva wrote:
> Coccinelle script to remove unnecessary static on local variables when
> the variables are not used before update.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> Changes in v2:
> Update header and Copyright note.
>
> scripts/coccinelle/misc/static_unnecessary.cocci | 96
>
> 1 file changed, 96 insertions(+)
> create mode 100644 scripts/coccinelle/misc/static_unnecessary.cocci
>
> diff --git a/scripts/coccinelle/misc/static_unnecessary.cocci
> b/scripts/coccinelle/misc/static_unnecessary.cocci
> new file mode 100644
> index 000..2b10586
> --- /dev/null
> +++ b/scripts/coccinelle/misc/static_unnecessary.cocci
> @@ -0,0 +1,96 @@
> +/// Drop static on local variable when the variable is not used before
> update.
> +//#
> +//# Removing unnecessary static on local variables reduces the code
> +//# size and increases maintainability.
> +//#
> +//# On the other hand, even though it is rare, be aware that if a
> +//# large object is initialized all at once, it might not be wise
> +//# to remove the static because that would increase the risk of a
> +//# stack overflow.
> +///
> +// Confidence: Moderate
> +// Copyright: (C) 2017 Julia Lawall, Inria. GPLv2.
> +// URL: http://coccinelle.lip6.fr/
> +// Copyright: (C) 2017 Gustavo A. R. Silva. GPLv2.
> +// Work supported by a grant from
> +// The Linux Foundation's Core Infrastructure Initiative.
> +// URL: https://www.coreinfrastructure.org/
> +// Options: --no-includes --include-headers
> +// Keywords: static
> +
> +virtual patch
> +virtual context
> +virtual org
> +virtual report
> +
> +//
> +@bad exists@
> +position p;
> +identifier x;
> +expression e;
> +type T;
> +@@
> +
> +T x@p;
> +... when != x = e
> +x = <+...x...+>
> +
> +@worse exists@
> +position p;
> +identifier x;
> +type T;
> +@@
> +
> +T x@p;
> +...
> + &x
> +
> +@modify depends on patch && !context && !org && !report@
> +identifier x;
> +expression e;
> +type T;
> +position p != {bad.p,worse.p};
> +@@
> +
> +-static
> + T x@p;
> + ... when != x
> + when strict
> +?x = e;
> +//
> +
> +
> +//
>
> +
> +@modify_context depends on !patch && (context || org || report) forall@
> +type T;
> +identifier x;
> +expression e;
> +position p != {bad.p,worse.p};
> +position j0;
> +@@
> +
> +* static
> + T x@j0@p;
> + ... when != x
> + when strict
> +?x = e;
> +
> +//
>
> +
> +@script:python modify_org depends on org@
> +j0 << modify_context.j0;
> +@@
> +
> +msg = "Unnecessary static on local variable."
> +coccilib.org.print_todo(j0[0], msg)
> +
> +//
>
> +
> +@script:python modify_report depends on report@
> +j0 << modify_context.j0;
> +@@
> +
> +msg = "Unnecessary static on local variable."
> +coccilib.report.print_report(j0[0], msg)
> +
> --
> 2.5.0
>
>
[PATCH 0/3] drm: Add CRTC-id based ioctls for vblank query/event
Here's an updated series for the proposed new IOCTLs. Major changes since last time: * Leave driver API with 32-bit vblank counts * Use ktime_t instead of struct timespec. * Check for MODESETTING before using modesetting APIs * Ensure vblank is running in new get_sequence ioctl There are other minor changes noted in each patch. Thanks to helpful review from: Daniel Vetter Michel Dänzer Ville Syrjälä -keith
[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]
These provide crtc-id based functions instead of pipe-number, while
also offering higher resolution time (ns) and wider frame count (64)
as required by the Vulkan API.
v2:
* Check for DRIVER_MODESET in new crtc-based vblank ioctls
Failing to check this will oops the driver.
* Ensure vblank interupt is running in crtc_get_sequence ioctl
The sequence and timing values are not correct while the
interrupt is off, so make sure it's running before asking for
them.
* Short-circuit get_sequence if the counter is enabled and accurate
Steal the idea from the code in wait_vblank to avoid the
expense of drm_vblank_get/put
* Return active state of crtc in crtc_get_sequence ioctl
Might be useful for applications that aren't in charge of
modesetting?
* Use drm_crtc_vblank_get/put in new crtc-based vblank sequence ioctls
Daniel Vetter prefers these over the old drm_vblank_put/get
APIs.
* Return s64 ns instead of u64 in new sequence event
Suggested-by: Daniel Vetter
Suggested-by: Ville Syrjälä
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_internal.h | 6 ++
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_vblank.c | 173 +
include/drm/drm_vblank.h | 1 +
include/uapi/drm/drm.h | 32
5 files changed, 214 insertions(+)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 5cecc974d2f9..b68a193b7907 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -65,6 +65,12 @@ int drm_legacy_irq_control(struct drm_device *dev, void
*data,
int drm_legacy_modeset_ctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp);
+
+int drm_crtc_queue_sequence_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp);
+
/* drm_auth.c */
int drm_getmagic(struct drm_device *dev, void *data,
struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index f1e568176da9..63016cf3e224 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -657,6 +657,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE,
drm_syncobj_fd_to_handle_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl,
DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE,
drm_crtc_queue_sequence_ioctl, DRM_UNLOCKED),
};
#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 7e7119a5ada3..69b8c92cdd3a 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -812,6 +812,11 @@ static void send_vblank_event(struct drm_device *dev,
e->event.vbl.tv_sec = tv.tv_sec;
e->event.vbl.tv_usec = tv.tv_usec;
break;
+ case DRM_EVENT_CRTC_SEQUENCE:
+ if (seq)
+ e->event.seq.sequence = seq;
+ e->event.seq.time_ns = ktime_to_ns(now);
+ break;
}
trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq);
drm_send_event_locked(dev, &e->base);
@@ -1682,3 +1687,171 @@ bool drm_crtc_handle_vblank(struct drm_crtc *crtc)
return drm_handle_vblank(crtc->dev, drm_crtc_index(crtc));
}
EXPORT_SYMBOL(drm_crtc_handle_vblank);
+
+/*
+ * Get crtc VBLANK count.
+ *
+ * \param dev DRM device
+ * \param data user arguement, pointing to a drm_crtc_get_sequence structure.
+ * \param file_priv drm file private for the user's open file descriptor
+ */
+
+int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_crtc *crtc;
+ struct drm_vblank_crtc *vblank;
+ int pipe;
+ struct drm_crtc_get_sequence *get_seq = data;
+ ktime_t now;
+ bool vblank_enabled;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ if (!dev->irq_enabled)
+ return -EINVAL;
+
+ crtc = drm_crtc_find(dev, get_seq->crtc_id);
+ if (!crtc)
+ return -ENOENT;
+
+ pipe = drm_crtc_index(crtc);
+
+ vblank = &dev->vblank[pipe];
+ vblank_enabled = dev->vblank_disable_immediate &&
READ_ONCE(vblank->enabled);
+
+ if (!vblank_enabled) {
+ ret = drm_crtc_vblank_get(crtc);
+ if (ret) {
+ DRM_DEBUG("crtc %d failed to acquire vblank counter,
%d\n", pipe, ret);
+
[PATCH 1/3] drm: Widen vblank UAPI to 64 bits. Change vblank time to ktime_t [v2]
This modifies the datatypes used by the vblank code to provide both 64
bits of vblank count and switch to using ktime_t for timestamps to
increase resolution from microseconds to nanoseconds.
The driver interfaces have been left using 32 bits of vblank count;
all of the code necessary to widen that value for the user API was
already included to handle devices returning fewer than 32-bits.
This will provide the necessary datatypes for the Vulkan API.
v2:
* Re-write wait_vblank ioctl to ABSOLUTE sequence
When an application uses the WAIT_VBLANK ioctl with RELATIVE
or NEXTONMISS bits set, the target vblank interval is updated
within the kernel. We need to write that target back to the
ioctl buffer and update the flags bits so that if the wait is
interrupted by a signal, when it is re-started, it will target
precisely the same vblank count as before.
* Leave driver API with 32-bit vblank count
Suggested-by: Michel Dänzer
Suggested-by: Daniel Vetter
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_vblank.c | 186 +--
include/drm/drmP.h | 2 +-
include/drm/drm_drv.h| 2 +-
include/drm/drm_vblank.h | 16 ++--
4 files changed, 120 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 463e4d81fb0d..346601ad698d 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -43,7 +43,7 @@
static bool
drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
- struct timeval *tvblank, bool in_vblank_irq);
+ ktime_t *tvblank, bool in_vblank_irq);
static unsigned int drm_timestamp_precision = 20; /* Default to 20 usecs. */
@@ -64,7 +64,7 @@ MODULE_PARM_DESC(timestamp_monotonic, "Use monotonic
timestamps");
static void store_vblank(struct drm_device *dev, unsigned int pipe,
u32 vblank_count_inc,
-struct timeval *t_vblank, u32 last)
+ktime_t t_vblank, u32 last)
{
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
@@ -73,7 +73,7 @@ static void store_vblank(struct drm_device *dev, unsigned int
pipe,
vblank->last = last;
write_seqlock(&vblank->seqlock);
- vblank->time = *t_vblank;
+ vblank->time = t_vblank;
vblank->count += vblank_count_inc;
write_sequnlock(&vblank->seqlock);
}
@@ -116,7 +116,7 @@ static void drm_reset_vblank_timestamp(struct drm_device
*dev, unsigned int pipe
{
u32 cur_vblank;
bool rc;
- struct timeval t_vblank;
+ ktime_t t_vblank;
int count = DRM_TIMESTAMP_MAXRETRIES;
spin_lock(&dev->vblank_time_lock);
@@ -136,13 +136,13 @@ static void drm_reset_vblank_timestamp(struct drm_device
*dev, unsigned int pipe
* interrupt and assign 0 for now, to mark the vblanktimestamp as
invalid.
*/
if (!rc)
- t_vblank = (struct timeval) {0, 0};
+ t_vblank = 0;
/*
* +1 to make sure user will never see the same
* vblank counter value before and after a modeset
*/
- store_vblank(dev, pipe, 1, &t_vblank, cur_vblank);
+ store_vblank(dev, pipe, 1, t_vblank, cur_vblank);
spin_unlock(&dev->vblank_time_lock);
}
@@ -165,7 +165,7 @@ static void drm_update_vblank_count(struct drm_device *dev,
unsigned int pipe,
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
u32 cur_vblank, diff;
bool rc;
- struct timeval t_vblank;
+ ktime_t t_vblank;
int count = DRM_TIMESTAMP_MAXRETRIES;
int framedur_ns = vblank->framedur_ns;
@@ -190,11 +190,9 @@ static void drm_update_vblank_count(struct drm_device
*dev, unsigned int pipe,
/* trust the hw counter when it's around */
diff = (cur_vblank - vblank->last) & dev->max_vblank_count;
} else if (rc && framedur_ns) {
- const struct timeval *t_old;
- u64 diff_ns;
+ ktime_t diff_ns;
- t_old = &vblank->time;
- diff_ns = timeval_to_ns(&t_vblank) - timeval_to_ns(t_old);
+ diff_ns = t_vblank - vblank->time;
/*
* Figure out how many vblanks we've missed based
@@ -228,7 +226,7 @@ static void drm_update_vblank_count(struct drm_device *dev,
unsigned int pipe,
}
DRM_DEBUG_VBL("updating vblank count on crtc %u:"
- " current=%u, diff=%u, hw=%u hw_last=%u\n",
+ " current=%llu, diff=%u, hw=%u hw_last=%u\n",
pipe, vblank->count, diff, cur_vblank, vblank->last);
if (diff == 0) {
@@ -243,9 +241,9 @@ static void drm_update_vblank_count(struct drm_device *dev,
unsigned int pipe,
* for now, to mark the vblanktimestamp as invalid.
*/
[PATCH 2/3] drm: Reorganize drm_pending_event to support future event types [v2]
Place drm_event_vblank in a new union that includes that and a bare
drm_event structure. This will allow new members of that union to be
added in the future without changing code related to the existing vbl
event type.
Assignments to the crtc_id field are now done when the event is
allocated, rather than when delievered. This way, delivery doesn't
need to have the crtc ID available.
v2:
* Remove 'dev' argument from create_vblank_event
It wasn't being used anyways, and if we need it in the future,
we can always get it from crtc->dev.
* Check for MODESETTING before looking for crtc in queue_vblank_event
UMS drivers will oops if we try to get a crtc, so make sure
we're modesetting before we try to find a crtc_id to fill into
the event.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_atomic.c | 7 ---
drivers/gpu/drm/drm_plane.c | 2 +-
drivers/gpu/drm/drm_vblank.c | 30 ++
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 ++--
include/drm/drm_vblank.h | 8 +++-
6 files changed, 34 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c0f336d23f9c..272b83ea9369 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1839,7 +1839,7 @@ int drm_atomic_debugfs_init(struct drm_minor *minor)
*/
static struct drm_pending_vblank_event *create_vblank_event(
- struct drm_device *dev, uint64_t user_data)
+ struct drm_crtc *crtc, uint64_t user_data)
{
struct drm_pending_vblank_event *e = NULL;
@@ -1849,7 +1849,8 @@ static struct drm_pending_vblank_event
*create_vblank_event(
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof(e->event);
- e->event.user_data = user_data;
+ e->event.vbl.crtc_id = crtc->base.id;
+ e->event.vbl.user_data = user_data;
return e;
}
@@ -2052,7 +2053,7 @@ static int prepare_crtc_signaling(struct drm_device *dev,
if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT || fence_ptr) {
struct drm_pending_vblank_event *e;
- e = create_vblank_event(dev, arg->user_data);
+ e = create_vblank_event(crtc, arg->user_data);
if (!e)
return -ENOMEM;
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 5dc8c4350602..fe9f31285bc2 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -918,7 +918,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
}
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof(e->event);
- e->event.user_data = page_flip->user_data;
+ e->event.vbl.user_data = page_flip->user_data;
ret = drm_event_reserve_init(dev, file_priv, &e->base,
&e->event.base);
if (ret) {
kfree(e);
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 346601ad698d..7e7119a5ada3 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -804,14 +804,16 @@ static void send_vblank_event(struct drm_device *dev,
{
struct timeval tv;
- tv = ktime_to_timeval(now);
- e->event.sequence = seq;
- e->event.tv_sec = tv.tv_sec;
- e->event.tv_usec = tv.tv_usec;
-
- trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe,
-e->event.sequence);
-
+ switch (e->event.base.type) {
+ case DRM_EVENT_VBLANK:
+ case DRM_EVENT_FLIP_COMPLETE:
+ tv = ktime_to_timeval(now);
+ e->event.vbl.sequence = seq;
+ e->event.vbl.tv_sec = tv.tv_sec;
+ e->event.vbl.tv_usec = tv.tv_usec;
+ break;
+ }
+ trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq);
drm_send_event_locked(dev, &e->base);
}
@@ -863,7 +865,6 @@ void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
e->pipe = pipe;
e->sequence = drm_vblank_count(dev, pipe);
- e->event.crtc_id = crtc->base.id;
list_add_tail(&e->base.link, &dev->vblank_event_list);
}
EXPORT_SYMBOL(drm_crtc_arm_vblank_event);
@@ -894,7 +895,6 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
now = get_drm_timestamp();
}
e->pipe = pipe;
- e->event.crtc_id = crtc->base.id;
send_vblank_event(dev, e, seq, now);
}
EXPORT_SYMBOL(drm_crtc_send_vblank_event);
@@ -1354,8 +1354,14 @@ static int drm_queue_vblank_event(struct drm_device
*dev, unsigned int pipe,
e->pipe = pipe;
e->event.base.type = DRM_EVENT_VBLANK;
- e->event.base.length = sizeof(e->event);
- e->event.user_
Re: [alsa-devel] [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger
On 2017年08月01日 11:30, Vinod Koul wrote:
On Mon, Jul 31, 2017 at 06:47:34PM +0800, Cheng-Yi Chiang wrote:
From: "U. Artie Eoff"
Reset the hw_ptr before queuing the restore_stream_context
work to eradicate a nasty white audio noise on resume.
Liam, Jie? This on legacy BYT driver..
Tested-by: Cheng-Yi Chiang
Signed-off-by: U. Artie Eoff
Signed-off-by: Cheng-Yi Chiang
---
sound/soc/intel/baytrail/sst-baytrail-pcm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/sound/soc/intel/baytrail/sst-baytrail-pcm.c
b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
index 4765ad474544..e0db7070cd42 100644
--- a/sound/soc/intel/baytrail/sst-baytrail-pcm.c
+++ b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
@@ -187,8 +187,10 @@ static int sst_byt_pcm_trigger(struct snd_pcm_substream
*substream, int cmd)
sst_byt_stream_start(byt, pcm_data->stream, 0);
break;
case SNDRV_PCM_TRIGGER_RESUME:
- if (pdata->restore_stream == true)
+ if (pdata->restore_stream == true) {
+ pcm_data->hw_ptr = 0;
Won't this break the hw_ptr and make the resuming won't play from the
pausing point of the last suspending?
Thanks,
~Keyon
schedule_work(&pcm_data->work);
+ }
else
sst_byt_stream_resume(byt, pcm_data->stream);
break;
--
2.12.2
[PATCH 3/7] mtd: spi-nor: cadence-quadspi: Add runtime PM support
Add pm_runtime* calls to cadence-quadspi driver. This is required to
switch on QSPI power domain on TI 66AK2G SoC during probe.
Signed-off-by: Vignesh R
---
drivers/mtd/spi-nor/cadence-quadspi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 297c86a2d4a7..1e432916e00b 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1219,6 +1220,13 @@ static int cqspi_probe(struct platform_device *pdev)
return -ENXIO;
}
+ pm_runtime_enable(&pdev->dev);
+ ret = pm_runtime_get_sync(&pdev->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(&pdev->dev);
+ return ret;
+ }
+
ret = clk_prepare_enable(cqspi->clk);
if (ret) {
dev_err(dev, "Cannot enable QSPI clock.\n");
@@ -1269,6 +1277,9 @@ static int cqspi_remove(struct platform_device *pdev)
clk_disable_unprepare(cqspi->clk);
+ pm_runtime_put_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+
return 0;
}
--
2.13.3
[PATCH 4/7] ARM: dts: keystone-k2g: Add QSPI DT entry
Add DT node for Cadence QSPI IP present in 66AK2G SoC.
Signed-off-by: Vignesh R
---
arch/arm/boot/dts/keystone-k2g.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi
b/arch/arm/boot/dts/keystone-k2g.dtsi
index bf4d1fa30840..95327aabfaa4 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -168,5 +168,20 @@
#reset-cells = <2>;
};
};
+
+ qspi: qspi@294 {
+ compatible = "ti,k2g-qspi", "cdns,qspi-nor";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0294 0x1000>,
+ <0x2400 0x400>;
+ interrupts = ;
+ cdns,fifo-depth = <256>;
+ cdns,fifo-width = <4>;
+ cdns,trigger-address = <0x2400>;
+ clocks = <&k2g_clks 0x43 0x0>;
+ power-domains = <&k2g_pds 0x43>;
+ status = "disabled";
+ };
};
};
--
2.13.3
[PATCH 1/7] mtd: spi-nor: cadence-quadspi: add a delay in write sequence
As per 66AK2G02 TRM[1] SPRUHY8F section 11.15.5.3 Indirect Access
Controller programming sequence, a delay equal to couple QSPI master
clock(~5ns) is required after setting CQSPI_REG_INDIRECTWR_START bit and
writing data to the flash. Add a new compatible to handle the couple of
cycles of delay required in the indirect write sequence, since this
delay is specific to TI 66AK2G SoC.
[1]http://www.ti.com/lit/ug/spruhy8f/spruhy8f.pdf
Signed-off-by: Vignesh R
---
Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 +
drivers/mtd/spi-nor/cadence-quadspi.c | 13 +
2 files changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
index f248056da24c..fdd511a83511 100644
--- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
@@ -2,6 +2,7 @@
Required properties:
- compatible : Should be "cdns,qspi-nor".
+ Should be "ti,k2g-qspi" for TI 66AK2G platform.
- reg : Contains two entries, each of which is a tuple consisting of a
physical address and length. The first entry is the address and
length of the controller register set. The second entry is the
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 53c7d8e0327a..94571590371d 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -76,6 +76,7 @@ struct cqspi_st {
u32 fifo_depth;
u32 fifo_width;
u32 trigger_address;
+ u32 wr_delay;
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
};
@@ -608,6 +609,14 @@ static int cqspi_indirect_write_execute(struct spi_nor
*nor,
reinit_completion(&cqspi->transfer_complete);
writel(CQSPI_REG_INDIRECTWR_START_MASK,
reg_base + CQSPI_REG_INDIRECTWR);
+ /*
+* As per 66AK2G02 TRM SPRUHY8F section 11.15.5.3 Indirect Access
+* Controller programming sequence, couple of cycles of
+* QSPI_REF_CLK delay is required for the above bit to
+* be internally synchronized by the QSPI module. Provide 5
+* cycles of delay.
+*/
+ ndelay(cqspi->wr_delay);
while (remaining > 0) {
write_bytes = remaining > page_size ? page_size : remaining;
@@ -1213,6 +1222,9 @@ static int cqspi_probe(struct platform_device *pdev)
}
cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
+ if (of_device_is_compatible(dev->of_node, "ti,k2g-qspi"))
+ cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
+ cqspi->master_ref_clk_hz);
ret = devm_request_irq(dev, irq, cqspi_irq_handler, 0,
pdev->name, cqspi);
@@ -1285,6 +1297,7 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
static const struct of_device_id cqspi_dt_ids[] = {
{.compatible = "cdns,qspi-nor",},
+ {.compatible = "ti,k2g-qspi",},
{ /* end of table */ }
};
--
2.13.3
[PATCH 5/7] ARM: dts: keystone-k2g-evm: Add QSPI node
66AK2G EVM has a s25fl512s flash connected to QSPI CS0. Add pinmux for
QSPI and DT entries for the same.
Signed-off-by: Vignesh R
---
arch/arm/boot/dts/keystone-k2g-evm.dts | 69 ++
1 file changed, 69 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts
b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 61883cb969d2..55d632977e8f 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -34,6 +34,18 @@
K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE0) /* uart0_txd.uart0_txd */
>;
};
+
+ qspi_pins: pinmux_qspi_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x1204) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* qspi_clk.qspi_clk */
+ K2G_CORE_IOPAD(0x1208) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* qspi_rclk.qspi_rclk */
+ K2G_CORE_IOPAD(0x120c) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* qspi_d0.qspi_d0 */
+ K2G_CORE_IOPAD(0x1210) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* qspi_d1.qspi_d1 */
+ K2G_CORE_IOPAD(0x1214) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* qspi_d2.qspi_d2 */
+ K2G_CORE_IOPAD(0x1218) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* qspi_d3.qspi_d3 */
+ K2G_CORE_IOPAD(0x121c) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* qspi_csn0.qspi_csn0 */
+ >;
+ };
};
&uart0 {
@@ -41,3 +53,60 @@
pinctrl-0 = <&uart0_pins>;
status = "okay";
};
+
+&qspi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&qspi_pins>;
+ cdns,rclk-en;
+ status = "okay";
+
+ flash0: m25p80@0 {
+ compatible = "s25fl512s", "jedec,spi-nor";
+ reg = <0>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <4>;
+ spi-max-frequency = <9600>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cdns,read-delay = <5>;
+ cdns,tshsl-ns = <500>;
+ cdns,tsd2d-ns = <500>;
+ cdns,tchsh-ns = <119>;
+ cdns,tslch-ns = <119>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "QSPI.u-boot";
+ reg = <0x 0x0010>;
+ };
+ partition@10 {
+ label = "QSPI.u-boot-env";
+ reg = <0x0010 0x0004>;
+ };
+ partition@14 {
+ label = "QSPI.skern";
+ reg = <0x0014 0x004>;
+ };
+ partition@18 {
+ label = "QSPI.sci-firmware";
+ reg = <0x0018 0x004>;
+ };
+ partition@1c {
+ label = "QSPI.kernel";
+ reg = <0x001c 0x080>;
+ };
+ partition@9c {
+ label = "QSPI.u-boot-spl-os";
+ reg = <0x009c 0x004>;
+ };
+ partition@a0 {
+ label = "QSPI.file-system";
+ reg = <0x00a0 0x360>;
+ };
+ };
+ };
+};
--
2.13.3
Re: [PATCH V2 00/12]: spmi: pmic-arb: Support for HW v5 and other fixes
On 2017-07-28 12:40, Kiran Gunda wrote: v2: * [PATCH V2 04/12] spmi: pmic-arb: optimize qpnpint_irq_set_type function Added Stephen's Reviewed-by tag. * [PATCH V2 05/12] spmi: pmic-arb: fix memory allocation for mapping_table Added Fixes tag and Stephen's Reviewed-by tag. * [PATCH V2 02/12] spmi: pmic-arb: rename pa_xx to pmic_arb_xx and other cleanup Added Stephen's Reviewed-by tag. * [PATCH V2 06/12] spmi: pmic-arb: replace the writel_relaxed with __raw_writel Added Fixes tag. * [PATCH V2 03/12] spmi: pmic-arb: clean up pmic_arb_find_apid function Fixed alignement issue and added Stephen's reviewed-by tag. Now all the patches in this series are reviewed and acked by Stephen boyd and are ready for merge. v1: * This patch series add the support for pmic arbiter hardware v5 along with the few bug fixes and code cleanup. * This new series is the combined series of [PATCH V3 0/5]: spmi: pmic-arb: Fixup patches and [PATCH V4 0/4]: spmi: pmic-arb: support for V5 HW and bug fixes, which are being reviewed by Stephen Boyd. * This series depends on the below patch uploaded by Stephen Boyd https://patchwork.kernel.org/patch/9810723/. David Collins (1): spmi: pmic-arb: add support for HW version 5 Fenglin Wu (1): spmi: pmic-arb: Remove checking opc value not less than 0 Kiran Gunda (10): spmi: pmic-arb: remove the read/write access checks spmi: pmic-arb: rename pa_xx to pmic_arb_xx and other cleanup spmi: pmic-arb: clean up pmic_arb_find_apid function spmi: pmic-arb: optimize qpnpint_irq_set_type function spmi: pmic-arb: fix memory allocation for mapping_table spmi: pmic-arb: replace the writel_relaxed with __raw_writel spmi: pmic-arb: return the value instead of passing by pointer spmi: pmic-arb: use irq_chip callback to set spmi irq wakeup capability spmi: pmic-arb: return __iomem pointer instead of offset spmi: pmic-arb: fix a possible null pointer dereference drivers/spmi/spmi-pmic-arb.c | 825 +-- 1 file changed, 481 insertions(+), 344 deletions(-) Hi Greg, Could you please pull this patch series in to your tree? All these patches are reviewed and acked by Stephen boyd.
[PATCH 2/7] mtd: spi-nor: cadence-quadspi: Add support to enable loopback clock circuit
Cadence QSPI IP has a adapted loopback circuit which can be enabled by
setting BYPASS field to 0 in READCAPTURE register. It enables use of
QSPI return clock to latch the data rather than the internal QSPI
reference clock. For high speed operations, adapted loopback circuit
using QSPI return clock helps to increase data valid window.
Add DT parameter cdns,rclk-en to help enable adapted loopback circuit
for boards which do have QSPI return clock provided.
This patch also modifies cqspi_readdata_capture() function's bypass
parameter to bool to match how its used in the function.
Signed-off-by: Vignesh R
---
Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 3 +++
drivers/mtd/spi-nor/cadence-quadspi.c | 8 ++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
index fdd511a83511..6cc7d58ce7f6 100644
--- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
@@ -15,6 +15,9 @@ Required properties:
Optional properties:
- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
+- cdns,rclk-en : Flag to indicate that QSPI return clock is used to latch
+ the read data rather than the QSPI clock. Make sure that QSPI return
+ clock is populated on the board before using this property.
Optional subnodes:
Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 94571590371d..297c86a2d4a7 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -75,6 +75,7 @@ struct cqspi_st {
boolis_decoded_cs;
u32 fifo_depth;
u32 fifo_width;
+ boolrclk_en;
u32 trigger_address;
u32 wr_delay;
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
@@ -784,7 +785,7 @@ static void cqspi_config_baudrate_div(struct cqspi_st
*cqspi)
}
static void cqspi_readdata_capture(struct cqspi_st *cqspi,
- const unsigned int bypass,
+ const bool bypass,
const unsigned int delay)
{
void __iomem *reg_base = cqspi->iobase;
@@ -848,7 +849,8 @@ static void cqspi_configure(struct spi_nor *nor)
cqspi->sclk = sclk;
cqspi_config_baudrate_div(cqspi);
cqspi_delay(nor);
- cqspi_readdata_capture(cqspi, 1, f_pdata->read_delay);
+ cqspi_readdata_capture(cqspi, !cqspi->rclk_en,
+ f_pdata->read_delay);
}
if (switch_cs || switch_ck)
@@ -1045,6 +1047,8 @@ static int cqspi_of_get_pdata(struct platform_device
*pdev)
return -ENXIO;
}
+ cqspi->rclk_en = of_property_read_bool(np, "cdns,rclk-en");
+
return 0;
}
--
2.13.3
[PATCH 0/7] K2G: Add QSPI support
This series adds support for Cadence QSPI for 66AK2G SoC. The first three patches enhance the cadence-quadspi driver to support loopback clock and pm_runtime and tweaks for 66AK2G SoC. Remaining patches add DT nodes and enable the driver in defconfig. Tested on 66AK2G GP and ICE boards. Vignesh R (7): mtd: spi-nor: cadence-quadspi: add a delay in write sequence mtd: spi-nor: cadence-quadspi: Add support to enable loopback clock circuit mtd: spi-nor: cadence-quadspi: Add runtime PM support ARM: dts: keystone-k2g: Add QSPI DT entry ARM: dts: keystone-k2g-evm: Add QSPI node ARM: dts: keystone-k2g-ice: Add QSPI node ARM: configs: keystone: Enable Cadence QSPI driver .../devicetree/bindings/mtd/cadence-quadspi.txt| 4 ++ arch/arm/boot/dts/keystone-k2g-evm.dts | 69 ++ arch/arm/boot/dts/keystone-k2g-ice.dts | 69 ++ arch/arm/boot/dts/keystone-k2g.dtsi| 15 + arch/arm/configs/keystone_defconfig| 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 32 +- 6 files changed, 188 insertions(+), 2 deletions(-) -- 2.13.3
[PATCH 6/7] ARM: dts: keystone-k2g-ice: Add QSPI node
66AK2G ICE board has a s25fl256s1 flash connected to QSPI CS0. Add
pinmux and DT entries for the same.
Signed-off-by: Vignesh R
---
arch/arm/boot/dts/keystone-k2g-ice.dts | 69 ++
1 file changed, 69 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g-ice.dts
b/arch/arm/boot/dts/keystone-k2g-ice.dts
index d820d37b5148..075c3a605c8b 100644
--- a/arch/arm/boot/dts/keystone-k2g-ice.dts
+++ b/arch/arm/boot/dts/keystone-k2g-ice.dts
@@ -26,6 +26,18 @@
K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE0) /* uart0_txd.uart0_txd */
>;
};
+
+ qspi_pins: pinmux_qspi_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x1204) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* qspi_clk.qspi_clk */
+ K2G_CORE_IOPAD(0x1208) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* qspi_rclk.qspi_rclk */
+ K2G_CORE_IOPAD(0x120c) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* qspi_d0.qspi_d0 */
+ K2G_CORE_IOPAD(0x1210) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* qspi_d1.qspi_d1 */
+ K2G_CORE_IOPAD(0x1214) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* qspi_d2.qspi_d2 */
+ K2G_CORE_IOPAD(0x1218) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* qspi_d3.qspi_d3 */
+ K2G_CORE_IOPAD(0x121c) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* qspi_csn0.qspi_csn0 */
+ >;
+ };
};
&uart0 {
@@ -33,3 +45,60 @@
pinctrl-0 = <&uart0_pins>;
status = "okay";
};
+
+&qspi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&qspi_pins>;
+ cdns,rclk-en;
+ status = "okay";
+
+ flash0: m25p80@0 {
+ compatible = "s25fl256s1", "jedec,spi-nor";
+ reg = <0>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <4>;
+ spi-max-frequency = <9600>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cdns,read-delay = <5>;
+ cdns,tshsl-ns = <500>;
+ cdns,tsd2d-ns = <500>;
+ cdns,tchsh-ns = <119>;
+ cdns,tslch-ns = <119>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "QSPI.u-boot";
+ reg = <0x 0x0010>;
+ };
+ partition@10 {
+ label = "QSPI.u-boot-env";
+ reg = <0x0010 0x0004>;
+ };
+ partition@14 {
+ label = "QSPI.skern";
+ reg = <0x0014 0x004>;
+ };
+ partition@18 {
+ label = "QSPI.sci-firmware";
+ reg = <0x0018 0x004>;
+ };
+ partition@1c {
+ label = "QSPI.kernel";
+ reg = <0x001c 0x080>;
+ };
+ partition@9c {
+ label = "QSPI.u-boot-spl-os";
+ reg = <0x009c 0x004>;
+ };
+ partition@a0 {
+ label = "QSPI.file-system";
+ reg = <0x00a0 0x160>;
+ };
+ };
+ };
+};
--
2.13.3
[PATCH 7/7] ARM: configs: keystone: Enable Cadence QSPI driver
66AK2G SoC has a Cadence QSPI IP. Therefore, enable cadence-quadspi driver as part of keystone_defconfig. Since, QSPI flash can be used to for root filesystem, built it into the kernel instead of module. Signed-off-by: Vignesh R --- arch/arm/configs/keystone_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig index d47ea43d097e..4c8abf3c1ab1 100644 --- a/arch/arm/configs/keystone_defconfig +++ b/arch/arm/configs/keystone_defconfig @@ -124,6 +124,7 @@ CONFIG_MTD_M25P80=y CONFIG_MTD_NAND=y CONFIG_MTD_NAND_DAVINCI=y CONFIG_MTD_SPI_NOR=y +CONFIG_SPI_CADENCE_QUADSPI=y CONFIG_MTD_UBI=y CONFIG_BLK_DEV_LOOP=y CONFIG_SRAM=y -- 2.13.3
[PATCH 2/6] dt-bindings: ti,omap-hsmmc: Add 66AK2G mmc controller
Update the ti,omap-hsmmc.txt to include information about 66AK2G specific mmc controller. Also cleanup the entries under optional properties to look a bit nicer. Signed-off-by: Lokesh Vutla --- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 52 +++--- 1 file changed, 37 insertions(+), 15 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 0e026c151c1c..016741402e37 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -1,33 +1,55 @@ -* TI Highspeed MMC host controller for OMAP +* TI Highspeed MMC host controller for OMAP and 66AK2G family. -The Highspeed MMC Host Controller on TI OMAP family +The Highspeed MMC Host Controller on TI OMAP and 66AK2G family provides an interface for MMC, SD, and SDIO types of memory cards. This file documents differences between the core properties described by mmc.txt and the properties used by the omap_hsmmc driver. Required properties: + - compatible: Should be "ti,omap2-hsmmc", for OMAP2 controllers Should be "ti,omap3-hsmmc", for OMAP3 controllers Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0 Should be "ti,omap4-hsmmc", for OMAP4 controllers Should be "ti,am33xx-hsmmc", for AM335x controllers -- ti,hwmods: Must be "mmc", n is controller instance starting 1 + Should be "ti,k2g-hsmmc", "ti,omap4-hsmmc" for 66AK2G controllers. + +SoC specific required properties: +- +The following are mandatory properties for OMAPs, AM33xx and AM43xx SoCs only: +- ti,hwmods: Must be "mmc", n is controller instance starting 1. + +The following are mandatory properties for 66AK2G SoCs only: +- power-domains:Should contain a phandle to a PM domain provider node + and an args specifier containing the MMC device id + value. This property is as per the binding, + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt +- clocks: Must contain an entry for each entry in clock-names. Should + be defined as per the he appropriate clock bindings consumer + usage in Documentation/devicetree/bindings/clock/ti,sci-clk.txt +- clock-names: Shall be "fck" for the functional clock, + and "mmchsdb_fck" for the debounce clock. + Optional properties: -ti,dual-volt: boolean, supports dual voltage cards --supply: phandle to the regulator device tree node -"supply-name" examples are "vmmc", "vmmc_aux"(deprecated)/"vqmmc" etc -ti,non-removable: non-removable slot (like eMMC) -ti,needs-special-reset: Requires a special softreset sequence -ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High Speed -dmas: List of DMA specifiers with the controller specific format -as described in the generic DMA client binding. A tx and rx -specifier is required. -dma-names: List of DMA request names. These strings correspond -1:1 with the DMA specifiers listed in dmas. The string naming is -to be "rx" and "tx" for RX and TX DMA requests, respectively. + +- ti,dual-volt:boolean, supports dual voltage cards +- -supply:phandle to the regulator device tree node + "supply-name" examples are "vmmc", + "vmmc_aux"(deprecated)/"vqmmc" etc +- ti,non-removable:non-removable slot (like eMMC) +- ti,needs-special-reset: Requires a special softreset sequence +- ti,needs-special-hs-handling:HSMMC IP needs special setting + for handling High Speed +- dmas:List of DMA specifiers with the controller specific + format as described in the generic DMA client + binding. A tx and rx specifier is required. +- dma-names: List of DMA request names. These strings correspond + 1:1 with the DMA specifiers listed in dmas. + The string naming is to be "rx" and "tx" for + RX and TX DMA requests, respectively. Examples: -- 2.13.0
[PATCH 6/6] ARM: configs: keystone: Enable MMC and regulators
Enable the TI OMAP HSMMC and fixed regulator support for keystone platforms. Signed-off-by: Lokesh Vutla --- arch/arm/configs/keystone_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig index d47ea43d097e..3397e91a5db1 100644 --- a/arch/arm/configs/keystone_defconfig +++ b/arch/arm/configs/keystone_defconfig @@ -156,6 +156,8 @@ CONFIG_POWER_RESET_KEYSTONE=y # CONFIG_HWMON is not set CONFIG_WATCHDOG=y CONFIG_DAVINCI_WATCHDOG=y +CONFIG_REGULATOR=y +CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_MON=y @@ -164,6 +166,8 @@ CONFIG_USB_STORAGE=y CONFIG_USB_DWC3=y CONFIG_NOP_USB_XCEIV=y CONFIG_KEYSTONE_USB_PHY=y +CONFIG_MMC=y +CONFIG_MMC_OMAP_HS=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_GPIO=y -- 2.13.0
[PATCH 0/6] ARM: dts: keystone-k2g: Add support for eDMA and MMC
This series adds DT nodes and documentation for eDMA and MMC IPs on Keystone 66AK2G SoC. Also enable the required configs in keystone_defconfig. This series depends on Keerthy's gpio node patches on 66AK2G: https://patchwork.kernel.org/patch/9864311/ Tested: k2g-evm with rootfs on mmc: http://pastebin.ubuntu.com/25217978/ Lokesh Vutla (5): dt-bindings: ti,edma: Add 66AK2G specific information dt-bindings: ti,omap-hsmmc: Add 66AK2G mmc controller ARM: dts: keystone-k2g: add MMC0 and MMC1 nodes ARM: dts: keystone-k2g-evm: Enable MMC0 and MMC1 ARM: configs: keystone: Enable MMC and regulators Peter Ujfalusi (1): ARM: dts: keystone-k2g: Add eDMA nodes Documentation/devicetree/bindings/dma/ti-edma.txt | 95 +++-- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 52 arch/arm/boot/dts/keystone-k2g-evm.dts | 53 arch/arm/boot/dts/keystone-k2g.dtsi| 98 ++ arch/arm/configs/keystone_defconfig| 4 + 5 files changed, 282 insertions(+), 20 deletions(-) -- 2.13.0
[PATCH 5/6] ARM: dts: keystone-k2g-evm: Enable MMC0 and MMC1
Enable MMC0 which is used for micro SD and MMC1 which is used for the on
board EMMC.
Signed-off-by: Lokesh Vutla
[fcoo...@ti.com: add mmc1, bufferclass and pullup/pulldown settings]
Signed-off-by: Franklin S Cooper Jr
[nsek...@ti.com: add card detect GPIO support]
Signed-off-by: Sekhar Nori
---
arch/arm/boot/dts/keystone-k2g-evm.dts | 53 ++
1 file changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts
b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 61883cb969d2..f47f95d8bf1c 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -25,6 +25,13 @@
reg = <0x0008 0x 0x 0x8000>;
};
+ vcc3v3_dcin_reg: fixedregulator-vcc3v3-dcin {
+ compatible = "regulator-fixed";
+ regulator-name = "mmc0_fixed";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
};
&k2g_pinctrl {
@@ -34,6 +41,33 @@
K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE0) /* uart0_txd.uart0_txd */
>;
};
+
+ mmc0_pins: pinmux_mmc0_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x1300) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE2)/* mmc0_dat3.mmc0_dat3 */
+ K2G_CORE_IOPAD(0x1304) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE2)/* mmc0_dat2.mmc0_dat2 */
+ K2G_CORE_IOPAD(0x1308) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE2)/* mmc0_dat1.mmc0_dat1 */
+ K2G_CORE_IOPAD(0x130c) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE2)/* mmc0_dat0.mmc0_dat0 */
+ K2G_CORE_IOPAD(0x1310) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE2)/* mmc0_clk.mmc0_clk */
+ K2G_CORE_IOPAD(0x1314) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE2)/* mmc0_cmd.mmc0_cmd */
+ K2G_CORE_IOPAD(0x12ec) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE3)/* mmc0_sdcd.gpio1_12 */
+ >;
+ };
+
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x10ec) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE0)/* mmc1_dat7.mmc1_dat7 */
+ K2G_CORE_IOPAD(0x10f0) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE0)/* mmc1_dat6.mmc1_dat6 */
+ K2G_CORE_IOPAD(0x10f4) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE0)/* mmc1_dat5.mmc1_dat5 */
+ K2G_CORE_IOPAD(0x10f8) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE0)/* mmc1_dat4.mmc1_dat4 */
+ K2G_CORE_IOPAD(0x10fc) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE0)/* mmc1_dat3.mmc1_dat3 */
+ K2G_CORE_IOPAD(0x1100) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE0)/* mmc1_dat2.mmc1_dat2 */
+ K2G_CORE_IOPAD(0x1104) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE0)/* mmc1_dat1.mmc1_dat1 */
+ K2G_CORE_IOPAD(0x1108) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE0)/* mmc1_dat0.mmc1_dat0 */
+ K2G_CORE_IOPAD(0x110c) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE0)/* mmc1_clk.mmc1_clk */
+ K2G_CORE_IOPAD(0x1110) (BUFFER_CLASS_B | PIN_PULLUP |
MUX_MODE0)/* mmc1_cmd.mmc1_cmd */
+ >;
+ };
};
&uart0 {
@@ -41,3 +75,22 @@
pinctrl-0 = <&uart0_pins>;
status = "okay";
};
+
+&gpio1 {
+ status = "okay";
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
+ vmmc-supply = <&vcc3v3_dcin_reg>;
+ cd-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <&vcc3v3_dcin_reg>; /* VCC3V3_EMMC is connected to
VCC3V3_DCIN */
+ status = "okay";
+};
--
2.13.0
[PATCH 4/6] ARM: dts: keystone-k2g: add MMC0 and MMC1 nodes
Add device tree nodes for MMC0 and MMC1 pesent
on 66AK2G device.
Signed-off-by: Lokesh Vutla
[nsek...@ti.com: fix clock-names for mmc1 node]
Signed-off-by: Sekhar Nori
---
arch/arm/boot/dts/keystone-k2g.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi
b/arch/arm/boot/dts/keystone-k2g.dtsi
index 3f1fd3df76d5..9ecea2c27d76 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -276,5 +276,37 @@
reg = <0x027b8000 0x400>;
power-domains = <&k2g_pds 0x4f>;
};
+
+ mmc0: mmc@2300 {
+ compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc";
+ reg = <0x2300 0x400>;
+ interrupts = ;
+ dmas = <&edma1 24 0>, <&edma1 25 0>;
+ dma-names = "tx", "rx";
+ bus-width = <4>;
+ ti,needs-special-reset;
+ no-1-8-v;
+ max-frequency = <9600>;
+ power-domains = <&k2g_pds 0xb>;
+ clocks = <&k2g_clks 0xb 1>, <&k2g_clks 0xb 2>;
+ clock-names = "fck", "mmchsdb_fck";
+ status = "disabled";
+ };
+
+ mmc1: mmc@2310 {
+ compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc";
+ reg = <0x2310 0x400>;
+ interrupts = ;
+ dmas = <&edma1 26 0>, <&edma1 27 0>;
+ dma-names = "tx", "rx";
+ bus-width = <8>;
+ ti,needs-special-reset;
+ ti,non-removable;
+ max-frequency = <9600>;
+ power-domains = <&k2g_pds 0xc>;
+ clocks = <&k2g_clks 0xc 1>, <&k2g_clks 0xc 2>;
+ clock-names = "fck", "mmchsdb_fck";
+ status = "disabled";
+ };
};
};
--
2.13.0
[PATCH 3/6] ARM: dts: keystone-k2g: Add eDMA nodes
From: Peter Ujfalusi
Add nodes for eDMA0 and eDMA1.
Signed-off-by: Peter Ujfalusi
Signed-off-by: Dave Gerlach
Signed-off-by: Lokesh Vutla
---
arch/arm/boot/dts/keystone-k2g.dtsi | 66 +
1 file changed, 66 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi
b/arch/arm/boot/dts/keystone-k2g.dtsi
index f9ff29972295..3f1fd3df76d5 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -210,5 +210,71 @@
clocks = <&k2g_clks 0x001c 0x0>;
clock-names = "gpio";
};
+
+ edma0: edma@0270 {
+ compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc";
+ reg = <0x0270 0x8000>;
+ reg-names = "edma3_cc";
+ interrupts = ,
+ ,
+ ;
+ interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+ dma-requests = <64>;
+ #dma-cells = <2>;
+
+ ti,tptcs = <&edma0_tptc0 7>, <&edma0_tptc1 0>;
+
+ ti,edma-memcpy-channels = <32 33 34 35>;
+
+ power-domains = <&k2g_pds 0x3f>;
+ };
+
+ edma0_tptc0: tptc@0276 {
+ compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc";
+ reg = <0x0276 0x400>;
+ power-domains = <&k2g_pds 0x3f>;
+ };
+
+ edma0_tptc1: tptc@02768000 {
+ compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc";
+ reg = <0x02768000 0x400>;
+ power-domains = <&k2g_pds 0x3f>;
+ };
+
+ edma1: edma@02728000 {
+ compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc";
+ reg = <0x02728000 0x8000>;
+ reg-names = "edma3_cc";
+ interrupts = ,
+ ,
+ ;
+ interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+ dma-requests = <64>;
+ #dma-cells = <2>;
+
+ ti,tptcs = <&edma1_tptc0 7>, <&edma1_tptc1 0>;
+
+ /*
+* memcpy is disabled, can be enabled with:
+* ti,edma-memcpy-channels = <12 13 14 15>;
+* for example.
+*/
+
+ power-domains = <&k2g_pds 0x4f>;
+ };
+
+ edma1_tptc0: tptc@027b {
+ compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc";
+ reg = <0x027b 0x400>;
+ power-domains = <&k2g_pds 0x4f>;
+ };
+
+ edma1_tptc1: tptc@027b8000 {
+ compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc";
+ reg = <0x027b8000 0x400>;
+ power-domains = <&k2g_pds 0x4f>;
+ };
};
};
--
2.13.0
[PATCH 1/6] dt-bindings: ti,edma: Add 66AK2G specific information
Update ti,edma binding documentation to reflect 66AK2G specific
properties.
Signed-off-by: Lokesh Vutla
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 95 +--
1 file changed, 90 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index 18090e7226b4..05fe2931d025 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -9,7 +9,12 @@ execute the actual DMA tansfer.
eDMA3 Channel Controller
Required properties:
-- compatible: "ti,edma3-tpcc" for the channel controller(s)
+
+- compatible: Should be:
+ - "ti,edma3-tpcc" for the channel controller(s) on OMAP,
+ AM33xx and AM43xx SoCs.
+ - "ti,k2g-edma3-tpcc", "ti,edma3-tpcc" for the
+ channel controller(s) on 66AK2G.
- #dma-cells: Should be set to <2>. The first number is the DMA request
number and the second is the TC the channel is serviced on.
- reg: Memory map of eDMA CC
@@ -19,8 +24,19 @@ Required properties:
- ti,tptcs:List of TPTCs associated with the eDMA in the following form:
<&tptc_phandle TC_priority_number>. The highest priority is 0.
+SoC-specific Required properties:
+
+The following are mandatory properties for OMAP, AM33xx and AM43xx SoCs only:
+- ti,hwmods: Name of the hwmods associated to the eDMA CC.
+
+The following are mandatory properties for 66AK2G SoCs only:
+- power-domains:Should contain a phandle to a PM domain provider node
+ and an args specifier containing the device id
+ value. This property is as per the binding,
+ Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+
Optional properties:
-- ti,hwmods: Name of the hwmods associated to the eDMA CC
+---
- ti,edma-memcpy-channels: List of channels allocated to be used for memcpy,
iow
these channels will be SW triggered channels. See example.
- ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
@@ -31,17 +47,34 @@ Optional properties:
eDMA3 Transfer Controller
Required properties:
-- compatible: "ti,edma3-tptc" for the transfer controller(s)
+
+- compatible: Should be:
+ - "ti,edma3-tptc" for the transfer controller(s) on OMAP,
+ AM33xx and AM43xx SoCs.
+ - "ti,k2g-edma3-tptc", "ti,edma3-tptc" for the
+ transfer controller(s) on 66AK2G.
- reg: Memory map of eDMA TC
- interrupts: Interrupt number for TCerrint.
+SoC-specific Required properties:
+
+The following are mandatory properties for OMAP, AM33xx and AM43xx SoCs only:
+- ti,hwmods: Name of the hwmods associated to the eDMA TC.
+
+The following are mandatory properties for 66AK2G SoCs only:
+- power-domains:Should contain a phandle to a PM domain provider node
+ and an args specifier containing the device id
+ value. This property is as per the binding,
+ Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+
Optional properties:
-- ti,hwmods: Name of the hwmods associated to the given eDMA TC
+---
- interrupt-names: "edma3_tcerrint"
--
-Example:
+Examples:
+1.
edma: edma@4900 {
compatible = "ti,edma3-tpcc";
ti,hwmods = "tpcc";
@@ -109,6 +142,58 @@ mcasp0: mcasp@48038000 {
dma-names = "tx", "rx";
};
+2.
+edma1: edma@02728000 {
+ compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc";
+ reg = <0x02728000 0x8000>;
+ reg-names = "edma3_cc";
+ interrupts = ,
+ ,
+ ;
+ interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+ dma-requests = <64>;
+ #dma-cells = <2>;
+
+ ti,tptcs = <&edma1_tptc0 7>, <&edma1_tptc1 0>;
+
+ /*
+* memcpy is disabled, can be enabled with:
+* ti,edma-memcpy-channels = <12 13 14 15>;
+* for example.
+*/
+
+ power-domains = <&k2g_pds 0x4f>;
+};
+
+edma1_tptc0: tptc@027b {
+ compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc";
+ reg = <0x027b 0x400>;
+ power-domains = <&k2g_pds 0x4f>;
+};
+
+edma1_tptc1: tptc@027b8000 {
+ compatible = "ti, k2g-edma3-tptc", "ti,edma3-tptc";
+ reg = <0x027b8000 0x400>;
+ power-domains = <&k2g_pds 0x4f>;
+};
+
+mmc0: mmc@2300 {
+ compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc";
+ reg = <0x2300 0x400>;
+ interrupts = ;
+ dmas = <&edma1 24 0>, <&edma1 25 0>;
+ dma-names = "tx", "rx";
+ bus-width = <4>;
+ ti,needs-special-reset;
+ no-1-8-v;
+
[PATCH v2] Coccinelle: Script to remove unnecessary static on local variables
Coccinelle script to remove unnecessary static on local variables when
the variables are not used before update.
Signed-off-by: Gustavo A. R. Silva
---
Changes in v2:
Update header and Copyright note.
scripts/coccinelle/misc/static_unnecessary.cocci | 96
1 file changed, 96 insertions(+)
create mode 100644 scripts/coccinelle/misc/static_unnecessary.cocci
diff --git a/scripts/coccinelle/misc/static_unnecessary.cocci
b/scripts/coccinelle/misc/static_unnecessary.cocci
new file mode 100644
index 000..2b10586
--- /dev/null
+++ b/scripts/coccinelle/misc/static_unnecessary.cocci
@@ -0,0 +1,96 @@
+/// Drop static on local variable when the variable is not used before update.
+//#
+//# Removing unnecessary static on local variables reduces the code
+//# size and increases maintainability.
+//#
+//# On the other hand, even though it is rare, be aware that if a
+//# large object is initialized all at once, it might not be wise
+//# to remove the static because that would increase the risk of a
+//# stack overflow.
+///
+// Confidence: Moderate
+// Copyright: (C) 2017 Julia Lawall, Inria. GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Copyright: (C) 2017 Gustavo A. R. Silva. GPLv2.
+// Work supported by a grant from
+// The Linux Foundation's Core Infrastructure Initiative.
+// URL: https://www.coreinfrastructure.org/
+// Options: --no-includes --include-headers
+// Keywords: static
+
+virtual patch
+virtual context
+virtual org
+virtual report
+
+//
+@bad exists@
+position p;
+identifier x;
+expression e;
+type T;
+@@
+
+T x@p;
+... when != x = e
+x = <+...x...+>
+
+@worse exists@
+position p;
+identifier x;
+type T;
+@@
+
+T x@p;
+...
+ &x
+
+@modify depends on patch && !context && !org && !report@
+identifier x;
+expression e;
+type T;
+position p != {bad.p,worse.p};
+@@
+
+-static
+ T x@p;
+ ... when != x
+ when strict
+?x = e;
+//
+
+
+//
+
+@modify_context depends on !patch && (context || org || report) forall@
+type T;
+identifier x;
+expression e;
+position p != {bad.p,worse.p};
+position j0;
+@@
+
+* static
+ T x@j0@p;
+ ... when != x
+ when strict
+?x = e;
+
+//
+
+@script:python modify_org depends on org@
+j0 << modify_context.j0;
+@@
+
+msg = "Unnecessary static on local variable."
+coccilib.org.print_todo(j0[0], msg)
+
+//
+
+@script:python modify_report depends on report@
+j0 << modify_context.j0;
+@@
+
+msg = "Unnecessary static on local variable."
+coccilib.report.print_report(j0[0], msg)
+
--
2.5.0
Re: [PATCH] staging: ks7010: fix styling WARNINGs
Hi Ashish, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.13-rc3 next-20170731] [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/Ashish-Kalra/staging-ks7010-fix-styling-WARNINGs/20170801-121331 config: tile-allmodconfig (attached as .config) compiler: tilegx-linux-gcc (GCC) 4.6.2 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=tile All errors (new ones prefixed by >>): drivers/staging//ks7010/ks7010_sdio.c: In function 'ks7010_sdio_readb': drivers/staging//ks7010/ks7010_sdio.c:77:12: error: invalid storage class for function 'ks7010_sdio_readb' drivers/staging//ks7010/ks7010_sdio.c:77:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] drivers/staging//ks7010/ks7010_sdio.c:89:12: error: invalid storage class for function 'ks7010_sdio_read' drivers/staging//ks7010/ks7010_sdio.c:98:12: error: invalid storage class for function 'ks7010_sdio_writeb' drivers/staging//ks7010/ks7010_sdio.c:110:12: error: invalid storage class for function 'ks7010_sdio_write' drivers/staging//ks7010/ks7010_sdio.c:118:13: error: invalid storage class for function 'ks_wlan_hw_sleep_doze_request' drivers/staging//ks7010/ks7010_sdio.c:144:13: error: invalid storage class for function 'ks_wlan_hw_sleep_wakeup_request' drivers/staging//ks7010/ks7010_sdio.c:191:13: error: invalid storage class for function '_ks_wlan_hw_power_save' drivers/staging//ks7010/ks7010_sdio.c:252:12: error: invalid storage class for function 'enqueue_txdev' drivers/staging//ks7010/ks7010_sdio.c:290:12: error: invalid storage class for function 'write_to_device' drivers/staging//ks7010/ks7010_sdio.c:320:13: error: invalid storage class for function 'tx_device_task' drivers/staging//ks7010/ks7010_sdio.c:379:13: error: invalid storage class for function 'rx_event_task' drivers/staging//ks7010/ks7010_sdio.c:396:13: error: invalid storage class for function 'ks_wlan_hw_rx' drivers/staging//ks7010/ks7010_sdio.c:452:13: error: invalid storage class for function 'ks7010_rw_function' drivers/staging//ks7010/ks7010_sdio.c:522:13: error: invalid storage class for function 'ks_sdio_interrupt' drivers/staging//ks7010/ks7010_sdio.c:593:12: error: invalid storage class for function 'trx_device_init' drivers/staging//ks7010/ks7010_sdio.c:609:13: error: invalid storage class for function 'trx_device_exit' drivers/staging//ks7010/ks7010_sdio.c:625:12: error: invalid storage class for function 'ks7010_sdio_update_index' drivers/staging//ks7010/ks7010_sdio.c:652:12: error: invalid storage class for function 'ks7010_sdio_data_compare' drivers/staging//ks7010/ks7010_sdio.c:680:12: error: invalid storage class for function 'ks7010_upload_firmware' drivers/staging//ks7010/ks7010_sdio.c:775:13: error: invalid storage class for function 'ks7010_card_init' drivers/staging//ks7010/ks7010_sdio.c:828:13: error: invalid storage class for function 'ks7010_init_defaults' drivers/staging//ks7010/ks7010_sdio.c:855:12: error: invalid storage class for function 'ks7010_sdio_probe' drivers/staging//ks7010/ks7010_sdio.c:1005:12: error: invalid storage class for function 'send_stop_request' drivers/staging//ks7010/ks7010_sdio.c:1032:13: error: invalid storage class for function 'ks7010_sdio_remove' drivers/staging//ks7010/ks7010_sdio.c:1100:2: error: initializer element is not constant drivers/staging//ks7010/ks7010_sdio.c:1100:2: error: (near initialization for 'ks7010_sdio_driver.probe') drivers/staging//ks7010/ks7010_sdio.c:1101:2: error: initializer element is not constant drivers/staging//ks7010/ks7010_sdio.c:1101:2: error: (near initialization for 'ks7010_sdio_driver.remove') drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class for function 'ks7010_sdio_driver_init' >> drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class >> for function '__inittest' drivers/staging//ks7010/ks7010_sdio.c:1104:1: warning: 'alias' attribute ignored [-Wattributes] drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class for function 'ks7010_sdio_driver_exit' drivers/staging//ks7010/ks7010_sdio.c:1104:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] >> drivers/staging//ks7010/ks7010_sdio.c:1104:1: error
RE: [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger
This patch was originally submitted in the context of the ChromiumOS kernel
3.10 for BYT
(https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/AsoBhfHzQg8).
> -Original Message-
> From: Koul, Vinod
> Sent: Monday, July 31, 2017 8:30 PM
> To: Cheng-Yi Chiang ; Jie, Yang
> Cc: linux-kernel@vger.kernel.org; Liam Girdwood ; Mark
> Brown ; Jaroslav Kysela
> ; Takashi Iwai ; Eoff, Ullysses A
> ; alsa-de...@alsa-project.org
> Subject: Re: [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger
>
> On Mon, Jul 31, 2017 at 06:47:34PM +0800, Cheng-Yi Chiang wrote:
> > From: "U. Artie Eoff"
> >
> > Reset the hw_ptr before queuing the restore_stream_context
> > work to eradicate a nasty white audio noise on resume.
>
> Liam, Jie? This on legacy BYT driver..
>
> >
> > Tested-by: Cheng-Yi Chiang
> > Signed-off-by: U. Artie Eoff
> > Signed-off-by: Cheng-Yi Chiang
> > ---
> > sound/soc/intel/baytrail/sst-baytrail-pcm.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/sound/soc/intel/baytrail/sst-baytrail-pcm.c
> > b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
> > index 4765ad474544..e0db7070cd42 100644
> > --- a/sound/soc/intel/baytrail/sst-baytrail-pcm.c
> > +++ b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
> > @@ -187,8 +187,10 @@ static int sst_byt_pcm_trigger(struct
> > snd_pcm_substream *substream, int cmd)
> > sst_byt_stream_start(byt, pcm_data->stream, 0);
> > break;
> > case SNDRV_PCM_TRIGGER_RESUME:
> > - if (pdata->restore_stream == true)
> > + if (pdata->restore_stream == true) {
> > + pcm_data->hw_ptr = 0;
> > schedule_work(&pcm_data->work);
> > + }
> > else
> > sst_byt_stream_resume(byt, pcm_data->stream);
> > break;
> > --
> > 2.12.2
> >
>
> --
> ~Vinod
Re: [PATCH] staging: ks7010: fix styling WARNINGs
Hi Ashish, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.13-rc3 next-20170731] [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/Ashish-Kalra/staging-ks7010-fix-styling-WARNINGs/20170801-121331 config: i386-randconfig-x008-201731 (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=i386 All error/warnings (new ones prefixed by >>): drivers/staging/ks7010/ks7010_sdio.c: In function 'ks7010_sdio_readb': >> drivers/staging/ks7010/ks7010_sdio.c:77:12: error: invalid storage class for >> function 'ks7010_sdio_readb' static int ks7010_sdio_readb(struct ks_wlan_private *priv, unsigned int address, ^ >> drivers/staging/ks7010/ks7010_sdio.c:77:1: warning: ISO C90 forbids mixed >> declarations and code [-Wdeclaration-after-statement] static int ks7010_sdio_readb(struct ks_wlan_private *priv, unsigned int address, ^~ >> drivers/staging/ks7010/ks7010_sdio.c:89:12: error: invalid storage class for >> function 'ks7010_sdio_read' static int ks7010_sdio_read(struct ks_wlan_private *priv, unsigned int address, ^~~~ >> drivers/staging/ks7010/ks7010_sdio.c:98:12: error: invalid storage class for >> function 'ks7010_sdio_writeb' static int ks7010_sdio_writeb(struct ks_wlan_private *priv, ^~ >> drivers/staging/ks7010/ks7010_sdio.c:110:12: error: invalid storage class >> for function 'ks7010_sdio_write' static int ks7010_sdio_write(struct ks_wlan_private *priv, unsigned int address, ^ >> drivers/staging/ks7010/ks7010_sdio.c:118:13: error: invalid storage class >> for function 'ks_wlan_hw_sleep_doze_request' static void ks_wlan_hw_sleep_doze_request(struct ks_wlan_private *priv) ^ >> drivers/staging/ks7010/ks7010_sdio.c:144:13: error: invalid storage class >> for function 'ks_wlan_hw_sleep_wakeup_request' static void ks_wlan_hw_sleep_wakeup_request(struct ks_wlan_private *priv) ^~~ >> drivers/staging/ks7010/ks7010_sdio.c:191:13: error: invalid storage class >> for function '_ks_wlan_hw_power_save' static void _ks_wlan_hw_power_save(struct ks_wlan_private *priv) ^~ >> drivers/staging/ks7010/ks7010_sdio.c:252:12: error: invalid storage class >> for function 'enqueue_txdev' static int enqueue_txdev(struct ks_wlan_private *priv, unsigned char *p, ^ >> drivers/staging/ks7010/ks7010_sdio.c:290:12: error: invalid storage class >> for function 'write_to_device' static int write_to_device(struct ks_wlan_private *priv, unsigned char *buffer, ^~~ >> drivers/staging/ks7010/ks7010_sdio.c:320:13: error: invalid storage class >> for function 'tx_device_task' static void tx_device_task(struct ks_wlan_private *priv) ^~ >> drivers/staging/ks7010/ks7010_sdio.c:379:13: error: invalid storage class >> for function 'rx_event_task' static void rx_event_task(unsigned long dev) ^ >> drivers/staging/ks7010/ks7010_sdio.c:396:13: error: invalid storage class >> for function 'ks_wlan_hw_rx' static void ks_wlan_hw_rx(struct ks_wlan_private *priv, uint16_t size) ^ >> drivers/staging/ks7010/ks7010_sdio.c:452:13: error: invalid storage class >> for function 'ks7010_rw_function' static void ks7010_rw_function(struct work_struct *work) ^~ >> drivers/staging/ks7010/ks7010_sdio.c:522:13: error: invalid storage class >> for function 'ks_sdio_interrupt' static void ks_sdio_interrupt(struct sdio_func *func) ^ >> drivers/staging/ks7010/ks7010_sdio.c:593:12: error: invalid storage class >> for function 'trx_device_init' static int trx_device_init(struct ks_wlan_private *priv) ^~~ >> drivers/staging/ks7010/ks7010_sdio.c:609:13: error: invalid storage class >> for function 'trx_device_exit' static void trx_device_exit(struct ks_wlan_private *priv) ^~~ >> drivers/staging/ks7010/ks7010_sdio.c:625:12: error: invalid storage class >> for function 'ks7010_sdio_update_index' static int ks7010_sdio_update_index(struct ks_wlan_private *priv, u32 index)
[PATCH] futex: allow for compiling out PI support
This makes it possible to preserve basic futex support and compile out
the PI support when RT mutexes are not available.
Signed-off-by: Nicolas Pitre
---
include/linux/futex.h | 7 ++-
init/Kconfig| 7 ++-
kernel/futex.c | 22 ++
kernel/locking/rtmutex_common.h | 29 +
4 files changed, 63 insertions(+), 2 deletions(-)
diff --git a/include/linux/futex.h b/include/linux/futex.h
index 7c5b694864..f36bfd26f9 100644
--- a/include/linux/futex.h
+++ b/include/linux/futex.h
@@ -54,7 +54,6 @@ union futex_key {
#ifdef CONFIG_FUTEX
extern void exit_robust_list(struct task_struct *curr);
-extern void exit_pi_state_list(struct task_struct *curr);
#ifdef CONFIG_HAVE_FUTEX_CMPXCHG
#define futex_cmpxchg_enabled 1
#else
@@ -64,8 +63,14 @@ extern int futex_cmpxchg_enabled;
static inline void exit_robust_list(struct task_struct *curr)
{
}
+#endif
+
+#ifdef CONFIG_FUTEX_PI
+extern void exit_pi_state_list(struct task_struct *curr);
+#else
static inline void exit_pi_state_list(struct task_struct *curr)
{
}
#endif
+
#endif
diff --git a/init/Kconfig b/init/Kconfig
index 8514b25db2..5f0ef850e8 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1275,12 +1275,17 @@ config BASE_FULL
config FUTEX
bool "Enable futex support" if EXPERT
default y
- select RT_MUTEXES
+ imply RT_MUTEXES
help
Disabling this option will cause the kernel to be built without
support for "fast userspace mutexes". The resulting kernel may not
run glibc-based applications correctly.
+config FUTEX_PI
+ bool
+ depends on FUTEX && RT_MUTEXES
+ default y
+
config HAVE_FUTEX_CMPXCHG
bool
depends on FUTEX
diff --git a/kernel/futex.c b/kernel/futex.c
index 16dbe4c938..ad0af4df1b 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -875,6 +875,8 @@ static struct task_struct *futex_find_get_task(pid_t pid)
return p;
}
+#ifdef CONFIG_FUTEX_PI
+
/*
* This task is holding PI mutexes at exit time => bad.
* Kernel cleans up PI-state, but userspace is likely hosed.
@@ -932,6 +934,8 @@ void exit_pi_state_list(struct task_struct *curr)
raw_spin_unlock_irq(&curr->pi_lock);
}
+#endif
+
/*
* We need to check the following states:
*
@@ -1799,6 +1803,15 @@ static int futex_requeue(u32 __user *uaddr1, unsigned
int flags,
struct futex_q *this, *next;
DEFINE_WAKE_Q(wake_q);
+ /*
+* When PI not supported: return -ENOSYS if requeue_pi is true,
+* consequently the compiler knows requeue_pi is always false past
+* this point which will optimize away all the conditional code
+* further down.
+*/
+ if (!IS_ENABLED(CONFIG_FUTEX_PI) && requeue_pi)
+ return -ENOSYS;
+
if (requeue_pi) {
/*
* Requeue PI only works on two distinct uaddrs. This
@@ -2594,6 +2607,9 @@ static int futex_lock_pi(u32 __user *uaddr, unsigned int
flags,
struct futex_q q = futex_q_init;
int res, ret;
+ if (!IS_ENABLED(CONFIG_FUTEX_PI))
+ return -ENOSYS;
+
if (refill_pi_state_cache())
return -ENOMEM;
@@ -2773,6 +2789,9 @@ static int futex_unlock_pi(u32 __user *uaddr, unsigned
int flags)
struct futex_q *top_waiter;
int ret;
+ if (!IS_ENABLED(CONFIG_FUTEX_PI))
+ return -ENOSYS;
+
retry:
if (get_user(uval, uaddr))
return -EFAULT;
@@ -2983,6 +3002,9 @@ static int futex_wait_requeue_pi(u32 __user *uaddr,
unsigned int flags,
struct futex_q q = futex_q_init;
int res, ret;
+ if (!IS_ENABLED(CONFIG_FUTEX_PI))
+ return -ENOSYS;
+
if (uaddr == uaddr2)
return -EINVAL;
diff --git a/kernel/locking/rtmutex_common.h b/kernel/locking/rtmutex_common.h
index 72ad45a9a7..8d039b928d 100644
--- a/kernel/locking/rtmutex_common.h
+++ b/kernel/locking/rtmutex_common.h
@@ -40,6 +40,9 @@ struct rt_mutex_waiter {
/*
* Various helpers to access the waiters-tree:
*/
+
+#ifdef CONFIG_RT_MUTEXES
+
static inline int rt_mutex_has_waiters(struct rt_mutex *lock)
{
return !RB_EMPTY_ROOT(&lock->waiters);
@@ -69,6 +72,32 @@ task_top_pi_waiter(struct task_struct *p)
pi_tree_entry);
}
+#else
+
+static inline int rt_mutex_has_waiters(struct rt_mutex *lock)
+{
+ return false;
+}
+
+static inline struct rt_mutex_waiter *
+rt_mutex_top_waiter(struct rt_mutex *lock)
+{
+ return NULL;
+}
+
+static inline int task_has_pi_waiters(struct task_struct *p)
+{
+ return false;
+}
+
+static inline struct rt_mutex_waiter *
+task_top_pi_waiter(struct task_struct *p)
+{
+ return NULL;
+}
+
+#endif
+
/*
* lock->owner state tracking:
*/
[PATCH v3] serio: PS/2 gpio bit banging driver for the serio bus
This driver provides PS/2 serio bus support by implementing bit banging
with the GPIO API. The GPIO pins, data and clock, can be configured with
a node in the device tree or by static platform data.
Writing to a device is supported as well, though it is not recommended as
the timings to be halt given by libps2 are very tough and difficult to
reach with bit banging. Therefore it can be configured (also in DT and
pdata) whether the serio write function should be available for clients.
This driver is for development purposes and not for productive use.
However, this driver can be useful e.g. when no USB port is available or
using old peripherals is desired as PS/2 controller chips getting rare.
This driver was tested on a RPI1 and on Hikey960 and it worked well
together with the atkbd driver.
Signed-off-by: Danilo Krummrich
---
v2: Removed one verbose print statement, changed another one to dev_dbg.
v3: - fixed compiler warning on blackfin
- depends on GPIOLIB
- clarify documentation
---
.../devicetree/bindings/serio/ps2-gpio.txt | 20 +
Documentation/gpio/drivers-on-gpio.txt | 5 +
drivers/input/serio/Kconfig| 11 +
drivers/input/serio/Makefile | 1 +
drivers/input/serio/ps2-gpio.c | 439 +
include/linux/ps2-gpio.h | 27 ++
6 files changed, 503 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serio/ps2-gpio.txt
create mode 100644 drivers/input/serio/ps2-gpio.c
create mode 100644 include/linux/ps2-gpio.h
diff --git a/Documentation/devicetree/bindings/serio/ps2-gpio.txt
b/Documentation/devicetree/bindings/serio/ps2-gpio.txt
new file mode 100644
index 000..828a5b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/serio/ps2-gpio.txt
@@ -0,0 +1,20 @@
+Device-Tree bindings for ps2 gpio driver
+
+Required properties:
+ - compatible = "ps2-gpio";
+ - gpios: data and clock gpio
+
+Optional properties:
+ - ps2-gpio,write-enable: Indicates whether write function is provided
+ to serio device. Most probably providing the write fn will not work,
+ because of the tough timing libps2 requires.
+
+Example nodes:
+
+ps2@0 {
+ compatible = "ps2-gpio";
+ gpios = <&gpio 24 0 /* data */
+&gpio 23 0 /* clock */
+ >;
+ i2c-gpio,write-enable = <0>;
+};
diff --git a/Documentation/gpio/drivers-on-gpio.txt
b/Documentation/gpio/drivers-on-gpio.txt
index 3065132..97c8716 100644
--- a/Documentation/gpio/drivers-on-gpio.txt
+++ b/Documentation/gpio/drivers-on-gpio.txt
@@ -84,6 +84,11 @@ hardware descriptions such as device tree or ACPI:
NAND flash MTD subsystem and provides chip access and partition parsing like
any other NAND driving hardware.
+- ps2-gpio: drivers/input/serio/ps2-gpio.c is used to drive an PS/2 (IBM) serio
+ bus, data and clock line, by bit banging two GPIO lines. It will appear as
+ any other serio bus to the system and makes it possible to connect drivers
+ for e.g. keyboards and other PS/2 protocol based devices.
+
Apart from this there are special GPIO drivers in subsystems like MMC/SD to
read card detect and write protect GPIO lines, and in the TTY serial subsystem
to emulate MCTRL (modem control) signals CTS/RTS by using two GPIO lines. The
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index c3d05b4..292d6e2 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -292,6 +292,17 @@ config SERIO_SUN4I_PS2
To compile this driver as a module, choose M here: the
module will be called sun4i-ps2.
+config SERIO_GPIO_PS2
+ tristate "GPIO PS/2 bit banging driver"
+ depends on GPIOLIB
+ help
+ Say Y here if you want PS/2 bit banging support via GPIO.
+
+ To compile this driver as a module, choose M here: the
+ module will be called gpio-ps2.
+
+ If you are unsure, say N.
+
config USERIO
tristate "User space serio port driver support"
help
diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile
index 2374ef9..767bd9b 100644
--- a/drivers/input/serio/Makefile
+++ b/drivers/input/serio/Makefile
@@ -30,4 +30,5 @@ obj-$(CONFIG_SERIO_APBPS2)+= apbps2.o
obj-$(CONFIG_SERIO_OLPC_APSP) += olpc_apsp.o
obj-$(CONFIG_HYPERV_KEYBOARD) += hyperv-keyboard.o
obj-$(CONFIG_SERIO_SUN4I_PS2) += sun4i-ps2.o
+obj-$(CONFIG_SERIO_GPIO_PS2) += ps2-gpio.o
obj-$(CONFIG_USERIO) += userio.o
diff --git a/drivers/input/serio/ps2-gpio.c b/drivers/input/serio/ps2-gpio.c
new file mode 100644
index 000..fc5368b
--- /dev/null
+++ b/drivers/input/serio/ps2-gpio.c
@@ -0,0 +1,439 @@
+/*
+ * GPIO based serio bus driver for bit banging the PS/2 protocol
+ *
+ * Author: Danilo Krummrich
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License v
Re: linux-next: manual merge of the rcu tree with the tip tree
- On Aug 1, 2017, at 12:03 AM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
> On Tue, Aug 01, 2017 at 12:04:05AM +, Mathieu Desnoyers wrote:
>> - On Jul 31, 2017, at 12:13 PM, Paul E. McKenney
>> paul...@linux.vnet.ibm.com
>> wrote:
>>
>> > On Mon, Jul 31, 2017 at 01:50:29PM +1000, Stephen Rothwell wrote:
>> >> Hi Paul,
>> >>
>> >> Today's linux-next merge of the rcu tree got a conflict in:
>> >>
>> >> arch/x86/mm/tlb.c
>> >>
>> >> between commit:
>> >>
>> >> 94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")
>> >>
>> >> from the tip tree and commit:
>> >>
>> >> d7713e8f8b23 ("membarrier: Expedited private command")
>> >>
>> >> from the rcu tree.
>> >>
>> >> I fixed it up (the former removed the comment and the load_cr3(), so I
>> >> just dropped the commend change in the latter) and can carry the fix as
>> >> necessary. This is now fixed as far as linux-next is concerned, but any
>> >> non trivial conflicts should be mentioned to your upstream maintainer
>> >> when your tree is submitted for merging. You may also want to consider
>> >> cooperating with the maintainer of the conflicting tree to minimise any
>> >> particularly complex conflicts.
>> >
>> > Thank you, Stephen!
>> >
>> > Mathieu, Peter, our commit log reads as if removal of load_cr3() would
>> > simply result in relying on the ordering provided by the atomic ops
>> > in switch_mm() for mm_cpumask(), so that only the commit log and the
>> > comment need changing.
>> >
>> > Please let me know if I am missing something here.
>>
>> I think you are right. Both load_cr3() and mm_cpumask update operations
>> (LOCK prefixed) provide the appropriate barriers on x86. So it's just a
>> matter of adapting the comment to the new reality.
>
> Like this?
The updated comment in the commit message looks good, but I would be
tempted to add a comment in x86 switch_mm_irqs_off() stating the
following requirement just before the line invoking cpumask_set_cpu():
/*
* The full memory barrier implied by mm_cpumask update operations
* is required by the membarrier system call.
*/
Thanks,
Mathieu
>
> Thanx, Paul
>
>
>
> commit fde19879b6bd1abc0c1d4d5f945efed61bf7eb8c
> Author: Mathieu Desnoyers
> Date: Fri Jul 28 16:40:40 2017 -0400
>
>membarrier: Expedited private command
>
>Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built
>from all runqueues for which current thread's mm is the same as the
>thread calling sys_membarrier. It executes faster than the non-expedited
>variant (no blocking). It also works on NOHZ_FULL configurations.
>
>Scheduler-wise, it requires a memory barrier before and after context
>switching between processes (which have different mm). The memory
>barrier before context switch is already present. For the barrier after
>context switch:
>
>* Our TSO archs can do RELEASE without being a full barrier. Look at
> x86 spin_unlock() being a regular STORE for example. But for those
> archs, all atomics imply smp_mb and all of them have atomic ops in
> switch_mm() for mm_cpumask().
>
>* From all weakly ordered machines, only ARM64 and PPC can do RELEASE,
> the rest does indeed do smp_mb(), so there the spin_unlock() is a full
> barrier and we're good.
>
>* ARM64 has a very heavy barrier in switch_to(), which suffices.
>
>* PPC just removed its barrier from switch_to(), but appears to be
> talking about adding something to switch_mm(). So add a
> smp_mb__after_unlock_lock() for now, until this is settled on the PPC
> side.
>
>Changes since v3:
>- Properly document the memory barriers provided by each architecture.
>
>Changes since v2:
>- Address comments from Peter Zijlstra,
>- Add smp_mb__after_unlock_lock() after finish_lock_switch() in
> finish_task_switch() to add the memory barrier we need after storing
> to rq->curr. This is much simpler than the previous approach relying
> on atomic_dec_and_test() in mmdrop(), which actually added a memory
> barrier in the common case of switching between userspace processes.
>- Return -EINVAL when MEMBARRIER_CMD_SHARED is used on a nohz_full
> kernel, rather than having the whole membarrier system call returning
> -ENOSYS. Indeed, CMD_PRIVATE_EXPEDITED is compatible with nohz_full.
> Adapt the CMD_QUERY mask accordingly.
>
>Changes since v1:
>- move membarrier code under kernel/sched/ because it uses the
> scheduler runqueue,
>- only add the barrier when we switch from a kernel thread. The case
> where we switch from a user-space thread is already handled by
> the atomic_dec_and_test() in mmdrop().
>- add a comment to mmdrop() documenting the requirement on the implicit
>
Re: [PATCH] futex: split PI support to a file of its own
On Mon, 31 Jul 2017, Thomas Gleixner wrote: > But I really do not agree with your reasoning about easier to understand > and maintain. I have the dubious pleasure to stare into that code on a > regular base. PI and non PI share a lot of code and it's really not helping > to have two separate files to stare at. That makes following the PI code > even harder than it is already. So I rather like to see that PI code in an > #ifdef block and not split out into its own file. OK. And in fact I think I now managed to keep #ifdef's to a very small number, counting on dead code elimination instead. Please see next patch. > Please provide a diffstat along with the patch next time. Hmmm... was supposed to be there. For the record it was: include/linux/futex.h |7 +- init/Kconfig |7 +- kernel/futex.c| 1559 +- kernel/futex_pi.c | 1563 +++ 4 files changed, 1598 insertions(+), 1538 deletions(-) Admitedly not small. But when PI is disabled then futex.o shrinks by roughly the half of its original size. So a lot of code is dedicated to PI. Nicolas
[stable 4.4: PATCH] sched/cputime: Fix prev steal time accouting during CPU hotplug
commit 3d89e5478bf550a50c99e93adf659369798263b0 upstream.
Commit:
e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")
... set rq->prev_* to 0 after a CPU hotplug comes back, in order to
fix the case where (after CPU hotplug) steal time is smaller than
rq->prev_steal_time.
However, this should never happen. Steal time was only smaller because of the
KVM-specific bug fixed by the previous patch. Worse, the previous patch
triggers a bug on CPU hot-unplug/plug operation: because
rq->prev_steal_time is cleared, all of the CPU's past steal time will be
accounted again on hot-plug.
Since the root cause has been fixed, we can just revert
commit e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU
hotplug").
Signed-off-by: Wanpeng Li
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Paolo Bonzini
Cc: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Radim Krčmář
Cc: Rik van Riel
Cc: Thomas Gleixner
Fixes: 'commit e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU
hotplug")'
Link:
http://lkml.kernel.org/r/1465813966-3116-3-git-send-email-wanpeng...@hotmail.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Andres Oportus
---
kernel/sched/core.c | 1 -
kernel/sched/sched.h | 13 -
2 files changed, 14 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c436426..b103b9c 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5553,7 +5553,6 @@ migration_call(struct notifier_block *nfb, unsigned long
action, void *hcpu)
case CPU_UP_PREPARE:
rq->calc_load_update = calc_load_update;
- account_reset_rq(rq);
break;
case CPU_ONLINE:
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 4e5db65..55d92a1 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1770,16 +1770,3 @@ static inline u64 irq_time_read(int cpu)
}
#endif /* CONFIG_64BIT */
#endif /* CONFIG_IRQ_TIME_ACCOUNTING */
-
-static inline void account_reset_rq(struct rq *rq)
-{
-#ifdef CONFIG_IRQ_TIME_ACCOUNTING
- rq->prev_irq_time = 0;
-#endif
-#ifdef CONFIG_PARAVIRT
- rq->prev_steal_time = 0;
-#endif
-#ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
- rq->prev_steal_time_rq = 0;
-#endif
-}
--
1.9.1
Re: [PATCH v3 0/5] ARM64: disable irq between breakpoint and step exception
Hi James, On Monday 31 July 2017 10:45 PM, James Morse wrote: Hi Pratyush, On 31/07/17 11:40, Pratyush Anand wrote: samples/hw_breakpoint/data_breakpoint.c passes with x86_64 but fails with ARM64. Even though it has been NAKed previously on upstream [1, 2], I have tried to come up with patches which can resolve it for ARM64 as well. I noticed that even perf step exception can go into an infinite loop if CPU receives an interrupt while executing breakpoint/watchpoint handler. So, event though we are not concerned about above test, we will have to find a solution for the perf issue. This caught my eye as I've been reworking the order the DAIF flags get set/cleared[0]. Thanks for pointing to your series. What causes your infinite loop? Is it single-stepping kernel_exit? If so patch 4 "arm64: entry.S mask all exceptions during kernel_exit" [1] may help. Flow is like this: - A SW or HW breakpoint exception is being generated on a cpu lets say CPU5 - Breakpoint handler does something which causes an interrupt to be active on the same CPU. In fact there might be many other reasons for an interrupt to be active on a CPU while breakpoint handler was being executed. - So, as soon as we return from breakpoint exception, we go to the IRQ exception handler, while we were expecting a single step exception. I do not think that your patch 4 will help here. That patch disables interrupt while kernel_exit will execute.So,until we enable PSR I bit, we can not stop an interrupt to be generated before step exception. You can easily reproduce the issue with following: # insmod data_breakpoint.ko ksym=__sysrq_enabled # cat /proc/sys/kernel/sysrq Where data_breakpoint.ko is module from samples/hw_breakpoint/data_breakpoint.c. If its more like "single stepping something we didn't expect" you will get the same problem if we take an SError. (which with that series is unmasked ~all the time). Either way this looks like a new and exciting way of hitting the 'known issue' described in patch 12 [3]. Would disabling MDSCR_EL1.SS if we took an exception solve your problem? If so, I think we should add a new flag, 'TIF_KSINGLESTEP', causing us to save/restore MDSCR_EL1.SS into pt_regs on el1 exceptions. This would let us single-step without modifying the DAIF flags for the location we are stepping, and allow taking any kind of exception from that location. We should disable nested users of single-step, we can do that by testing the flag, print a warning then pretend we missed the breakpoint. (hence it needs to be separate from the user single-step flag). Thanks, James [0] https://www.spinics.net/lists/arm-kernel/msg596684.html [1] https://www.spinics.net/lists/arm-kernel/msg596686.html [2] https://www.spinics.net/lists/arm-kernel/msg596689.html ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Regards Pratyush
Re: [PATCH v2] serio: PS2 gpio bit banging driver for the serio bus
On 2017-08-01 01:34, Randy Dunlap wrote: On 07/31/2017 03:35 PM, Danilo Krummrich wrote: diff --git a/Documentation/gpio/drivers-on-gpio.txt b/Documentation/gpio/drivers-on-gpio.txt index 3065132..b106e72 100644 --- a/Documentation/gpio/drivers-on-gpio.txt +++ b/Documentation/gpio/drivers-on-gpio.txt @@ -84,6 +84,11 @@ hardware descriptions such as device tree or ACPI: NAND flash MTD subsystem and provides chip access and partition parsing like any other NAND driving hardware. +- ps2-gpio: drivers/input/serio/ps2-gpio.c is used to drive an PS2 serio bus, drive a PS2 Is this PS2 as in IBM Micro Channel or PlayStation 2? It's the PS/2 mouse/keyboard protocol introduced by IBM. + data and clock line, by bit banging two GPIO lines. It will appear as any + other serio bus to the system and makes it possible to connect drivers for + e.g. keyboards and other PS2 protocol based devices. + Apart from this there are special GPIO drivers in subsystems like MMC/SD to read card detect and write protect GPIO lines, and in the TTY serial subsystem to emulate MCTRL (modem control) signals CTS/RTS by using two GPIO lines. The diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig index c3d05b4..abca0e0 100644 --- a/drivers/input/serio/Kconfig +++ b/drivers/input/serio/Kconfig @@ -292,6 +292,16 @@ config SERIO_SUN4I_PS2 To compile this driver as a module, choose M here: the module will be called sun4i-ps2. +config SERIO_GPIO_PS2 + tristate "GPIO PS/2 bit banging driver" depends on GPIO ?? Thank you, missed that. + help + Say Y here if you want PS/2 bit banging support via GPIO. + + To compile this driver as a module, choose M here: the + module will be called gpio-ps2. + + If you are unsure, say N. + config USERIO tristate "User space serio port driver support" help
Re: linux-next: manual merge of the rcu tree with the tip tree
On Tue, Aug 01, 2017 at 12:04:05AM +, Mathieu Desnoyers wrote:
> - On Jul 31, 2017, at 12:13 PM, Paul E. McKenney
> paul...@linux.vnet.ibm.com wrote:
>
> > On Mon, Jul 31, 2017 at 01:50:29PM +1000, Stephen Rothwell wrote:
> >> Hi Paul,
> >>
> >> Today's linux-next merge of the rcu tree got a conflict in:
> >>
> >> arch/x86/mm/tlb.c
> >>
> >> between commit:
> >>
> >> 94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")
> >>
> >> from the tip tree and commit:
> >>
> >> d7713e8f8b23 ("membarrier: Expedited private command")
> >>
> >> from the rcu tree.
> >>
> >> I fixed it up (the former removed the comment and the load_cr3(), so I
> >> just dropped the commend change in the latter) and can carry the fix as
> >> necessary. This is now fixed as far as linux-next is concerned, but any
> >> non trivial conflicts should be mentioned to your upstream maintainer
> >> when your tree is submitted for merging. You may also want to consider
> >> cooperating with the maintainer of the conflicting tree to minimise any
> >> particularly complex conflicts.
> >
> > Thank you, Stephen!
> >
> > Mathieu, Peter, our commit log reads as if removal of load_cr3() would
> > simply result in relying on the ordering provided by the atomic ops
> > in switch_mm() for mm_cpumask(), so that only the commit log and the
> > comment need changing.
> >
> > Please let me know if I am missing something here.
>
> I think you are right. Both load_cr3() and mm_cpumask update operations
> (LOCK prefixed) provide the appropriate barriers on x86. So it's just a
> matter of adapting the comment to the new reality.
Like this?
Thanx, Paul
commit fde19879b6bd1abc0c1d4d5f945efed61bf7eb8c
Author: Mathieu Desnoyers
Date: Fri Jul 28 16:40:40 2017 -0400
membarrier: Expedited private command
Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built
from all runqueues for which current thread's mm is the same as the
thread calling sys_membarrier. It executes faster than the non-expedited
variant (no blocking). It also works on NOHZ_FULL configurations.
Scheduler-wise, it requires a memory barrier before and after context
switching between processes (which have different mm). The memory
barrier before context switch is already present. For the barrier after
context switch:
* Our TSO archs can do RELEASE without being a full barrier. Look at
x86 spin_unlock() being a regular STORE for example. But for those
archs, all atomics imply smp_mb and all of them have atomic ops in
switch_mm() for mm_cpumask().
* From all weakly ordered machines, only ARM64 and PPC can do RELEASE,
the rest does indeed do smp_mb(), so there the spin_unlock() is a full
barrier and we're good.
* ARM64 has a very heavy barrier in switch_to(), which suffices.
* PPC just removed its barrier from switch_to(), but appears to be
talking about adding something to switch_mm(). So add a
smp_mb__after_unlock_lock() for now, until this is settled on the PPC
side.
Changes since v3:
- Properly document the memory barriers provided by each architecture.
Changes since v2:
- Address comments from Peter Zijlstra,
- Add smp_mb__after_unlock_lock() after finish_lock_switch() in
finish_task_switch() to add the memory barrier we need after storing
to rq->curr. This is much simpler than the previous approach relying
on atomic_dec_and_test() in mmdrop(), which actually added a memory
barrier in the common case of switching between userspace processes.
- Return -EINVAL when MEMBARRIER_CMD_SHARED is used on a nohz_full
kernel, rather than having the whole membarrier system call returning
-ENOSYS. Indeed, CMD_PRIVATE_EXPEDITED is compatible with nohz_full.
Adapt the CMD_QUERY mask accordingly.
Changes since v1:
- move membarrier code under kernel/sched/ because it uses the
scheduler runqueue,
- only add the barrier when we switch from a kernel thread. The case
where we switch from a user-space thread is already handled by
the atomic_dec_and_test() in mmdrop().
- add a comment to mmdrop() documenting the requirement on the implicit
memory barrier.
CC: Peter Zijlstra
CC: Paul E. McKenney
CC: Boqun Feng
CC: Andrew Hunter
CC: Maged Michael
CC: gro...@google.com
CC: Avi Kivity
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Michael Ellerman
Signed-off-by: Mathieu Desnoyers
Signed-off-by: Paul E. McKenney
Tested-by: Dave Watson
diff --git a/MAINTAINERS b/MAINTAINERS
index f66488dfdbc9..3b035584272f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8621,7 +8621,7 @@ M:Mathieu Desnoyers
M: "Paul
Re: [PATCH RFC] arm64: introduce mm_context_t flags
On Monday 31 July 2017 08:18 PM, Yury Norov wrote: - If we start using TIF flags here, we cannot easily add new mm_context specific bits because they may mess with TIF ones. This one seems convincing argument. ATM do you have any mm_context flag which would you like to incorporate? I think that this is not what was intended when you added new field in mm_context_t. In this patch the MMCF_AARCH32 flag is introduced, where MMCF prefix stands for mm_context_t flags. And the new flag is used for uprobes code instead of TIF_32BIT. -- Regards Pratyush
RE: [PATCH V4 2/2] timer: imx-tpm: add imx tpm timer support
Hi Daniel,
> -Original Message-
> From: Daniel Lezcano [mailto:daniel.lezc...@linaro.org]
> Sent: Monday, July 31, 2017 10:29 PM
> To: A.s. Dong; linux-kernel@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org; t...@linutronix.de;
> shawn...@kernel.org; Jacky Bai; Anson Huang; donga...@gmail.com;
> ker...@pengutronix.de; Arnd Bergmann
> Subject: Re: [PATCH V4 2/2] timer: imx-tpm: add imx tpm timer support
>
> On 05/07/2017 04:35, Dong Aisheng wrote:
> > IMX Timer/PWM Module (TPM) supports both timer and pwm function while
> > this patch only adds the timer support. PWM would be added later.
> >
> > The TPM counter, compare and capture registers are clocked by an
> > asynchronous clock that can remain enabled in low power modes.
> >
> > NOTE: We observed in a very small probability, the bus fabric
> > contention between GPU and A7 may results a few cycles delay of
> > writing CNT registers which may cause the min_delta event got missed,
> > so we need add a ETIME check here in case it happened.
> >
> > Cc: Daniel Lezcano
> > Cc: Arnd Bergmann
> > Cc: Thomas Gleixner
> > Cc: Shawn Guo
> > Cc: Anson Huang
> > Cc: Bai Ping
> > Signed-off-by: Dong Aisheng
> >
> > ---
> > ChangeLog:
> > v3->v4:
> > * also add ETIME explanation in function
> > v2->v3:
> > * address all comments from Daniel Lezcano
> > * add more explaination on ETIME check in commit message
> > v1->v2:
> > * change to readl/writel from __raw_readl/writel according to Arnd's
> >suggestion to avoid endian issue
> > * add help information in Kconfig
> > * add more error checking
> > ---
> > drivers/clocksource/Kconfig | 8 ++
> > drivers/clocksource/Makefile| 1 +
> > drivers/clocksource/timer-imx-tpm.c | 239
> >
> > 3 files changed, 248 insertions(+)
> > create mode 100644 drivers/clocksource/timer-imx-tpm.c
>
> [ ... ]
>
> > +static struct irqaction tpm_timer_irq = {
> > + .name = "i.MX7ULP TPM Timer",
> > + .flags = IRQF_TIMER | IRQF_IRQPOLL,
> > + .handler= tpm_timer_interrupt,
> > + .dev_id = &clockevent_tpm,
> > +};
> >
>
> Please remove the structure above and use request_irq instead of setup_irq
> below + return code checking.
>
Okay, will switch to it.
> > +static int __init tpm_clockevent_init(unsigned long rate, int irq) {
> > + setup_irq(irq, &tpm_timer_irq);
> > +
> > + clockevent_tpm.cpumask = cpumask_of(0);
> > + clockevent_tpm.irq = irq;
> > + clockevents_config_and_register(&clockevent_tpm,
> > + rate, 300, 0xfffe);
> > +
> > + return 0;
> > +}
> > +
> > +static int __init tpm_timer_init(struct device_node *np) {
>
> [ ... ]
>
> > + rate = clk_get_rate(per) >> 3;
>
> Why ?
>
Because TPM internally is configured to divide 8.
The full context is:
/* increase per cnt, div 8 by default */
writel(TPM_SC_CMOD_INC_PER_CNT | TPM_SC_CMOD_DIV_DEFAULT,
timer_base + TPM_SC);
/* set MOD register to maximum for free running mode */
writel(0x, timer_base + TPM_MOD);
rate = clk_get_rate(per) >> 3;
> > + tpm_clocksource_init(rate);
> > + tpm_clockevent_init(rate, irq);
>
> Check.
>
Currently non of them return error code, do I still need to check?
> > + return 0;
> > +
> > +err_per_clk_enable:
> > + clk_disable_unprepare(ipg);
> > +err_ipg_clk_enable:
>
> No need to add an extra label.
>
Okay, will remove one.
> > +err_clk_get:
> > + clk_put(per);
> > + clk_put(ipg);
> > +err_iomap:
> > + iounmap(timer_base);
> > + return ret;
> > +}
> > +CLOCKSOURCE_OF_DECLARE(imx7ulp, "fsl,imx7ulp-tpm", tpm_timer_init);
>
> CLOCKSOURCE_OF_DECLARE is renamed to TIMER_OF_DECLARE.
>
Looks new, will change to it.
Thanks!
Regards
Dong Aisheng
> Thanks!
>
> -- Daniel
>
>
> --
> Facebook |
> Twitter | blog/> Blog
Re: "BUG: unable to handle kernel NULL pointer dereference" in swapping shmem
Hi, Horiguchi san, Naoya Horiguchi writes: > Hi, > > I found the following bug when testing mmotm-2017-07-31-16-56. > The triggering testcase just swaps in/out shmem pages. > It seems to me related to thp swapping improvement patchset, > so let me report this to the relevant people. > > Thanks, > Naoya Horiguchi > --- > [ 112.690842] ===> testcase 'mm/shmem_swap' start > [ 112.788440] Adding 40956k swap on > /mnt/tests/examples/regression/kernel/mm_regression/mm_regression/work/swapfile. > Priority:-2 extents:1 across:40956k FS > [ 112.815903] bash (17346): drop_caches: 3 > [ 112.975713] BUG: unable to handle kernel NULL pointer dereference at > 0007 > [ 112.984464] IP: swap_page_trans_huge_swapped+0x49/0xd0 > [ 112.990202] PGD 805e62067 > [ 112.990202] P4D 805e62067 > [ 112.993219] PUD 80447b067 > [ 112.996236] PMD 0 > [ 112.999253] > [ 113.003155] Oops: [#1] SMP > [ 113.006658] Modules linked in: nfsv4 dns_resolver nfs fscache > xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 > iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 > xt_conntrack nf_conntrack libcrc32c ipt_REJECT nf_reject_ipv4 tun > bridge stp llc ebtable_filter ebtables ip6_tables iptable_filter > intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm > iTCO_wdt nfsd iTCO_vendor_support mei_me auth_rpcgss mei lpc_ich > ipmi_si ipmi_devintf irqbypass nfs_acl shpchp sg mfd_core ie31200_edac > lockd ipmi_msghandler pcspkr video acpi_pad grace sunrpc ip_tables > sr_mod sd_mod cdrom tg3 ata_generic pata_acpi ata_piix ptp libata > megaraid_sas crc32c_intel pps_core dm_mirror dm_region_hash dm_log > dm_mod > [ 113.077676] CPU: 0 PID: 17431 Comm: test_alloc_gene Not tainted > 4.13.0-rc3-mm1-v4.13-rc3-mmotm-2017-07-31-16-56+ #1 > [ 113.089323] Hardware name: NEC Express5800/T110g-E > [N8100-2187Y]/GA-6LASV1, BIOS 4.6.1204 10/17/2014 > [ 113.099516] task: a06705de9740 task.stack: ac0947c0c000 > [ 113.106124] RIP: 0010:swap_page_trans_huge_swapped+0x49/0xd0 > [ 113.112438] RSP: 0018:ac0947c0fb38 EFLAGS: 00010246 > [ 113.118269] RAX: RBX: RCX: > 0040 > [ 113.126233] RDX: 0001 RSI: 05d6 RDI: > a06705674cfc > [ 113.134196] RBP: ac0947c0fb60 R08: R09: > 88ca2180 > [ 113.142161] R10: 0230 R11: a066e7a9b451 R12: > a06705674c00 > [ 113.150123] R13: 05d6 R14: 0400 R15: > ac0944001000 > [ 113.158088] FS: 7f855b243740() GS:a0672fc0() > knlGS: > [ 113.167118] CS: 0010 DS: ES: CR0: 80050033 > [ 113.173529] CR2: 0007 CR3: 000808de2002 CR4: > 001606f0 > [ 113.181493] Call Trace: > [ 113.184222] free_swap_and_cache+0x73/0x1d0 > [ 113.19] shmem_free_swap+0x5e/0x70 > [ 113.193072] shmem_undo_range+0x4bd/0x8b0 > [ 113.197547] shmem_truncate_range+0x14/0x40 > [ 113.202211] shmem_evict_inode+0xba/0x190 > [ 113.206686] evict+0xd3/0x1a0 > [ 113.210004] iput+0x17d/0x1d0 > [ 113.213316] dentry_unlink_inode+0xb9/0xf0 > [ 113.217887] __dentry_kill+0xc7/0x170 > [ 113.221994] dput+0x19c/0x1d0 > [ 113.225311] __fput+0x188/0x210 > [ 113.228813] fput+0xe/0x10 > [ 113.232221] task_work_run+0x86/0xa0 > [ 113.236209] exit_to_usermode_loop+0x6d/0x99 > [ 113.240981] syscall_return_slowpath+0xad/0xd0 > [ 113.245961] entry_SYSCALL_64_fastpath+0xa3/0xa5 > [ 113.251127] RIP: 0033:0x7f855a940b17 > [ 113.255113] RSP: 002b:7fff955b5048 EFLAGS: 0206 ORIG_RAX: > 001f > [ 113.263562] RAX: RBX: RCX: > 7f855a940b17 > [ 113.271524] RDX: RSI: RDI: > 00028001 > [ 113.279488] RBP: 7fff955b5060 R08: R09: > > [ 113.287450] R10: 7fff955b4dd0 R11: 0206 R12: > 00401da0 > [ 113.295414] R13: 7fff955b5350 R14: R15: > > [ 113.303378] Code: f5 41 54 49 89 fc 53 48 8b 47 70 4c 8b 7f 68 48 85 > c0 74 70 4c 89 f3 48 c1 eb 06 48 01 c3 48 89 df e8 fc 10 54 00 48 85 > db 74 59 43 07 04 75 31 48 b8 ff ff ff ff ff ff ff 01 49 21 c5 43 > 80 > [ 113.324450] RIP: swap_page_trans_huge_swapped+0x49/0xd0 RSP: > ac0947c0fb38 > [ 113.332413] CR2: 0007 > [ 113.336121] ---[ end trace 2cd503b4980b0afc ]--- > [ 113.341281] Kernel panic - not syncing: Fatal exception > [ 113.347398] Kernel Offset: 0x700 from 0x8100 (relocation > range: 0x8000-0xbfff) Thanks for reporting! Do you test it on a HDD? I can reproduce this on a HDD, the fix patch is as follow, could you try it? Best Regards, Huang, Ying ->8- >From 2487f0230fef59c1ef89792e2af7bcabc02470cf Mon Sep 17 00:00:00 2001 From: Huang Ying Date: Tue, 1 Aug 2017 11:2
Re: [RFC] KVM: optimize the kvm_vcpu_on_spin
On 2017/7/31 21:20, Paolo Bonzini wrote: > On 31/07/2017 14:27, David Hildenbrand wrote: >>> I'm not sure whether the operation of get the vcpu's priority-level is >>> expensive on all architectures, so I record it in kvm_sched_out() for >>> minimal the extra cycles cost in kvm_vcpu_on_spin(). >>> >> as you only care for x86 right now either way, you can directly optimize >> here for the good (here: x86) case (keeping changes and therefore >> possible bugs minimal). > > I agree with Cornelia that this is inconsistent, so you shouldn't update > me->in_kernmode in kvm_vcpu_on_spin. However, get_cpl requires > vcpu_load on Intel x86, so Mike's patch is necessary (vmx_get_cpl -> > vmx_read_guest_seg_ar -> vmcs_read32). > Hi Paolo, It seems that other architectures(e.g. arm/s390) needn't to cache the result, but x86 need, so I need to move 'in_kernmode' into kvm_vcpu_arch and only add this field to x86, right? > Alternatively, we can add a new callback kvm_x86_ops->sched_out to x86 > KVM, and call vmx_get_cpl from the Intel implementation (vmx_sched_out). In this approach, vmx_sched_out would only call vmx_get_cpl, isn't too redundant, because we can just call kvm_x86_ops->get_cpl instead at the right place? > This will cache the result until the next sched_in, so that 'until the next sched_in' --> Do we need to clear the result in sched in ? > kvm_vcpu_on_spin can use it. > > Paolo > > . > -- Regards, Longpeng(Mike)
Re: [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger
On Mon, Jul 31, 2017 at 06:47:34PM +0800, Cheng-Yi Chiang wrote:
> From: "U. Artie Eoff"
>
> Reset the hw_ptr before queuing the restore_stream_context
> work to eradicate a nasty white audio noise on resume.
Liam, Jie? This on legacy BYT driver..
>
> Tested-by: Cheng-Yi Chiang
> Signed-off-by: U. Artie Eoff
> Signed-off-by: Cheng-Yi Chiang
> ---
> sound/soc/intel/baytrail/sst-baytrail-pcm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/intel/baytrail/sst-baytrail-pcm.c
> b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
> index 4765ad474544..e0db7070cd42 100644
> --- a/sound/soc/intel/baytrail/sst-baytrail-pcm.c
> +++ b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
> @@ -187,8 +187,10 @@ static int sst_byt_pcm_trigger(struct snd_pcm_substream
> *substream, int cmd)
> sst_byt_stream_start(byt, pcm_data->stream, 0);
> break;
> case SNDRV_PCM_TRIGGER_RESUME:
> - if (pdata->restore_stream == true)
> + if (pdata->restore_stream == true) {
> + pcm_data->hw_ptr = 0;
> schedule_work(&pcm_data->work);
> + }
> else
> sst_byt_stream_resume(byt, pcm_data->stream);
> break;
> --
> 2.12.2
>
--
~Vinod
Re: [PATCH] iio: accel: Bugfix to enbale and allow different events to work parallely.
Thanks for doing that work. I have had it on my list for a long time and you seem to fix it. Although I'd happily review and possibly test it, unfortunately I can't do so before the week of August 21st. If this might go in quick, nothing will stop me from reviewing either, so, whatever. Thanks again! Sure no problem, looking forward to your review comments. Actually I am planning to add Orientation events for FXLS8471Q, for that is it good idea to overload existing IIO_ROT channel type? Also thinking of adding 4 channel modifiers i.e portrait up/down, landscape left/right. Any suggestions are welcome. Thank you. On 07/31/2017 10:17 PM, harinath Nampally wrote: This driver supports multiple devices like mma8653, mma8652, mma8452, mma8453 and fxls8471. Almost all these devices have more than one event. Current driver design hardcodes the event specific information, so only one event can be supported by this driver and current design doesn't have the flexibility to add more events. This patch fixes by detaching the event related information from chip_info struct, and based on channel type and event direction the corresponding event configuration registers are picked dynamically. Hence multiple events can be handled in read/write callbacks. Changes are thoroughly tested on fxls8471 device on imx6UL Eval board using iio_event_monitor user space program. After this fix both Freefall and Transient events are handled by the driver without any conflicts. Thanks for doing that work. I have had it on my list for a long time and you seem to fix it. Although I'd happily review and possibly test it, unfortunately I can't do so before the week of August 21st. If this might go in quick, nothing will stop me from reviewing either, so, whatever. Thanks again!
Re: [PATCH v4 00/15] exec: Use sane stack rlimit under secureexec
On Mon, Jul 31, 2017 at 5:54 PM, James Morris wrote: > On Mon, 31 Jul 2017, Kees Cook wrote: > >> Ugh, please ignore this v4. There's a typo that snuck in. I'll send a v5 >> soon... > > Aside from that, it's looking good. This touches a lot of stuff in > security/ so it may make sense for it to go in via my tree. Yeah, I'm open to whatever. It's not clear where it should go, but if you want to take it and Linus doesn't want it "early", that works for me. Linus, Andrew, thoughts? -Kees -- Kees Cook Pixel Security
Re: [linux-sunxi] [PATCH v3 02/12] ASoC: sun4i-i2s: Add clkdiv offsets to quirks
On Sat, Jul 29, 2017 at 10:17 PM, wrote:
> From: Marcus Cooper
>
> The BCLKDIV and MCLKDIV found on newer SoCs start from an offset of 1.
> Add the functionality to adjust the division values according to the
> needs to the device being used.
>
> Signed-off-by: Marcus Cooper
> ---
> sound/soc/sunxi/sun4i-i2s.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index d7ee7a443e4e..1d538de4e4d0 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -94,9 +94,13 @@
> * struct sun4i_i2s_quirks - Differences between SoC variants.
> *
> * @has_reset: SoC needs reset deasserted.
> + * @mclk_offset: Value by which mclkdiv needs to be adjusted.
> + * @bclk_offset: Value by which bclkdiv needs to be adjusted.
> */
> struct sun4i_i2s_quirks {
> boolhas_reset;
> + unsigned intmclk_offset;
> + unsigned intbclk_offset;
> };
>
> struct sun4i_i2s {
> @@ -149,7 +153,7 @@ static int sun4i_i2s_get_bclk_div(struct sun4i_i2s *i2s,
> const struct sun4i_i2s_clk_div *bdiv = &sun4i_i2s_bclk_div[i];
>
> if (bdiv->div == div)
> - return bdiv->val;
> + return bdiv->val + i2s->variant->bclk_offset;
The offset should best be applied when the value is written to the register,
in sun4i_i2s_set_clk_rate(). sun4i_i2s_get_*_div() should do what the name
says, that is calculate a divider based on the parameters it is given.
Regards
ChenYu
> }
>
> return -EINVAL;
> @@ -167,7 +171,7 @@ static int sun4i_i2s_get_mclk_div(struct sun4i_i2s *i2s,
> const struct sun4i_i2s_clk_div *mdiv = &sun4i_i2s_mclk_div[i];
>
> if (mdiv->div == div)
> - return mdiv->val;
> + return mdiv->val + i2s->variant->mclk_offset;
> }
>
> return -EINVAL;
> --
> 2.13.3
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH v3 01/12] ASoC: sun4i-i2s: Extend quirks scope
On Sat, Jul 29, 2017 at 10:17 PM, wrote: > From: Marcus Cooper > > In preparation for the changes required to support newer SoCs then typo? > quirks has been moved and also added to the device structure. > > Signed-off-by: Marcus Cooper Otherwise, Reviewed-by: Chen-Yu Tsai
"BUG: unable to handle kernel NULL pointer dereference" in swapping shmem
Hi, I found the following bug when testing mmotm-2017-07-31-16-56. The triggering testcase just swaps in/out shmem pages. It seems to me related to thp swapping improvement patchset, so let me report this to the relevant people. Thanks, Naoya Horiguchi --- [ 112.690842] ===> testcase 'mm/shmem_swap' start [ 112.788440] Adding 40956k swap on /mnt/tests/examples/regression/kernel/mm_regression/mm_regression/work/swapfile. Priority:-2 extents:1 across:40956k FS [ 112.815903] bash (17346): drop_caches: 3 [ 112.975713] BUG: unable to handle kernel NULL pointer dereference at 0007 [ 112.984464] IP: swap_page_trans_huge_swapped+0x49/0xd0 [ 112.990202] PGD 805e62067 [ 112.990202] P4D 805e62067 [ 112.993219] PUD 80447b067 [ 112.996236] PMD 0 [ 112.999253] [ 113.003155] Oops: [#1] SMP [ 113.006658] Modules linked in: nfsv4 dns_resolver nfs fscache xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6_tables iptable_filter intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm iTCO_wdt nfsd iTCO_vendor_support mei_me auth_rpcgss mei lpc_ich ipmi_si ipmi_devintf irqbypass nfs_acl shpchp sg mfd_core ie31200_edac lockd ipmi_msghandler pcspkr video acpi_pad grace sunrpc ip_tables sr_mod sd_mod cdrom tg3 ata_generic pata_acpi ata_piix ptp libata megaraid_sas crc32c_intel pps_core dm_mirror dm_region_hash dm_log dm_mod [ 113.077676] CPU: 0 PID: 17431 Comm: test_alloc_gene Not tainted 4.13.0-rc3-mm1-v4.13-rc3-mmotm-2017-07-31-16-56+ #1 [ 113.089323] Hardware name: NEC Express5800/T110g-E [N8100-2187Y]/GA-6LASV1, BIOS 4.6.1204 10/17/2014 [ 113.099516] task: a06705de9740 task.stack: ac0947c0c000 [ 113.106124] RIP: 0010:swap_page_trans_huge_swapped+0x49/0xd0 [ 113.112438] RSP: 0018:ac0947c0fb38 EFLAGS: 00010246 [ 113.118269] RAX: RBX: RCX: 0040 [ 113.126233] RDX: 0001 RSI: 05d6 RDI: a06705674cfc [ 113.134196] RBP: ac0947c0fb60 R08: R09: 88ca2180 [ 113.142161] R10: 0230 R11: a066e7a9b451 R12: a06705674c00 [ 113.150123] R13: 05d6 R14: 0400 R15: ac0944001000 [ 113.158088] FS: 7f855b243740() GS:a0672fc0() knlGS: [ 113.167118] CS: 0010 DS: ES: CR0: 80050033 [ 113.173529] CR2: 0007 CR3: 000808de2002 CR4: 001606f0 [ 113.181493] Call Trace: [ 113.184222] free_swap_and_cache+0x73/0x1d0 [ 113.19] shmem_free_swap+0x5e/0x70 [ 113.193072] shmem_undo_range+0x4bd/0x8b0 [ 113.197547] shmem_truncate_range+0x14/0x40 [ 113.202211] shmem_evict_inode+0xba/0x190 [ 113.206686] evict+0xd3/0x1a0 [ 113.210004] iput+0x17d/0x1d0 [ 113.213316] dentry_unlink_inode+0xb9/0xf0 [ 113.217887] __dentry_kill+0xc7/0x170 [ 113.221994] dput+0x19c/0x1d0 [ 113.225311] __fput+0x188/0x210 [ 113.228813] fput+0xe/0x10 [ 113.232221] task_work_run+0x86/0xa0 [ 113.236209] exit_to_usermode_loop+0x6d/0x99 [ 113.240981] syscall_return_slowpath+0xad/0xd0 [ 113.245961] entry_SYSCALL_64_fastpath+0xa3/0xa5 [ 113.251127] RIP: 0033:0x7f855a940b17 [ 113.255113] RSP: 002b:7fff955b5048 EFLAGS: 0206 ORIG_RAX: 001f [ 113.263562] RAX: RBX: RCX: 7f855a940b17 [ 113.271524] RDX: RSI: RDI: 00028001 [ 113.279488] RBP: 7fff955b5060 R08: R09: [ 113.287450] R10: 7fff955b4dd0 R11: 0206 R12: 00401da0 [ 113.295414] R13: 7fff955b5350 R14: R15: [ 113.303378] Code: f5 41 54 49 89 fc 53 48 8b 47 70 4c 8b 7f 68 48 85 c0 74 70 4c 89 f3 48 c1 eb 06 48 01 c3 48 89 df e8 fc 10 54 00 48 85 db 74 59 43 07 04 75 31 48 b8 ff ff ff ff ff ff ff 01 49 21 c5 43 80 [ 113.324450] RIP: swap_page_trans_huge_swapped+0x49/0xd0 RSP: ac0947c0fb38 [ 113.332413] CR2: 0007 [ 113.336121] ---[ end trace 2cd503b4980b0afc ]--- [ 113.341281] Kernel panic - not syncing: Fatal exception [ 113.347398] Kernel Offset: 0x700 from 0x8100 (relocation range: 0x8000-0xbfff)
Re: [RFC V2] printk: add warning while drop partial text in msg
On (07/30/17 21:37), pierre Kuo wrote:
> If the buffer pass to msg_print_text is not big enough to put both all
> prefixes and log_text(msg), kernel will quietly break.
> That means the user may not have the chance to know whether the
> log_text(msg) is fully printed into buffer or not.
>
> In this patch, once above case happened, we try to calculate how many
> characters of log_text(msg) are dropped and add warning for debugging
> purpose.
[..]
Hello,
this is not the only place that can truncate the message.
vprintk_emit() can do so as well /* vscnprintf() */. but
I think we don't care that much. a user likely will notice
truncated messages. we report lost messages, because this
is a completely different sort of problem.
[..]
> @@ -1264,8 +1270,23 @@ static size_t msg_print_text(const struct printk_log
> *msg, bool syslog, char *bu
>
> if (buf) {
> if (print_prefix(msg, syslog, NULL) +
> - text_len + 1 >= size - len)
> + text_len + 1 >= size - len) {
> + /* below stores dropped characters
> + * related information in next msg
> + */
> + size_t drop_len;
> +
> + drop_len = scnprintf(drop_msg,
> + MAX_DROP_MSG_LENGTH,
> + "<%u characters dropped>",
> + (next) ?
> + (unsigned int)(text_size + next - text)
> :
> + (unsigned int)text_size);
> + drop_msg[drop_len] = 0;
> + log_store(msg->facility, msg->level, msg->flags,
> + 0, NULL, 0, drop_msg, strlen(drop_msg));
> break;
> + }
this change, most likely, will confuse people. because msg_print_text() is
called on a message that is being currently processed, which is not
necessarily the last message in the logbuf. for example, see console_unlock().
we do something like this:
while (console_seq != log_next_seq) {
msg = log_from_idx(console_idx);
msg_print_text(msg);
console_idx = log_next(console_idx);
console_seq++;
}
your log_store(), invoked from msg_print_text(), will append the error
message to the logbuf (tail), possibly far-far-far away from console_idx.
so your "characters dropped" warning will appear much later.
> len += print_prefix(msg, syslog, buf + len);
> memcpy(buf + len, text, text_len);
but more importantly, msg_print_text() is called from several places. and
can even be called from a user space, potentially triggering the same
"" error log_store() over and over again, wiping out
the actually important kernel messages. which is
a) not nice
and
b) can be used to deliberately "hide" something really important.
so, no. sorry, I don't like this change.
-ss
Re: [PATCH 1/3] fs, xfs: introduce S_IOMAP_IMMUTABLE
On Mon, Jul 31, 2017 at 10:15:12PM -0400, Colin Walters wrote:
> On Mon, Jul 31, 2017, at 02:23 PM, Darrick J. Wong wrote:
>
> > I don't think F_SEAL_{SHRINK,GROW} prevents reflinking or CoW of file data,
> > which are two things that cannot happen under S_IOMAP_IMMUTABLE that
> > aren't size changes. From the implementation it looks like shrink and
> > grow are only supposed to disallow changes to i_size, not i_blocks (or
> > the file block map).
>
> True.
>
> > Then again, I suppose F_SEAL_* only work on shmem, so maybe it simply
> > isn't defined for any other filesystem...? e.g. it doesn't prohibit
> > reflink, but the only fs implementing seals doesn't support reflink.
> >
> >
> >
> > Seals cannot be removed, which is too strict for the S_IOMAP_IMMUTABLE
> > user cases being presented.
>
> To be clear, the set of use cases is swap files and DAX, right? Or is there
> anything else?
I've outlined other use cases in previous discussions. To repeat
myself, every so often we get someone with, say, a new high
speed camera that want to dma the camera frames direct to the
storage because they can't push 500,000 frames/s through the CPU
to storage. Hence they want to bypass the OS and DMA the data direct
to the storage. To do this they need a mechanism to freeze and unfreeze
the block map of the file so that nothing modifies the block map
while the camera hardware is dumping data direct to the storage.
Immutable extent maps provide the functionality they need to
implement this safely.
There's also other similar use cases for RDMA targets on PMEM
(regardless of whether DAX is enabled or not), and I've come across
a couple of requests for mechanisms to allow fabric based nvme
storage to do direct data transfers between storage devices, too.
All of these use cases can be safely implemented if there is a
mechanism to mark extent maps as immutable for the duration of
the operation they need to perform.
> I can't imagine why anyone would want to turn a swap file back into a regular
> file.
> I haven't fully followed DAX, but I'd take your word for it if people want to
> be able to remove the flag after.
DAX isn't the driver of that functionality, it's the other use cases
that need it, and why the proposed "only remove flag if len == 0"
API is a non-starter
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
[PATCHv4 3/3] DRM:ivip Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong
Driver for Intel FPGA Video and Image Processing
Suite Frame Buffer II. The driver only supports the Intel
Arria10 devkit and its variants. This driver can be either
loaded staticlly or in modules. The OF device tree binding
is located at:
Documentation/devicetree/bindings/display/altr,vip-fb2.txt
Signed-off-by: Ong, Hean Loong
---
V3:
*Changes to fixing drm_simple_pipe
*Used drm_fb_cma_get_gem_addr
V2:
*Adding drm_simple_display_pipe_init
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/ivip/Kconfig | 13 +++
drivers/gpu/drm/ivip/Makefile | 9 ++
drivers/gpu/drm/ivip/intel_vip_conn.c | 96
drivers/gpu/drm/ivip/intel_vip_core.c | 183 ++
drivers/gpu/drm/ivip/intel_vip_drv.h | 54 +
drivers/gpu/drm/ivip/intel_vip_of.c | 204 ++
8 files changed, 562 insertions(+)
create mode 100644 drivers/gpu/drm/ivip/Kconfig
create mode 100644 drivers/gpu/drm/ivip/Makefile
create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 83cb2a8..38a184d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -195,6 +195,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
source "drivers/gpu/drm/i915/Kconfig"
+source "drivers/gpu/drm/ivip/Kconfig"
+
config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 24a066e..4162a0e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
obj-$(CONFIG_DRM_MGA) += mga/
obj-$(CONFIG_DRM_I810) += i810/
obj-$(CONFIG_DRM_I915) += i915/
+obj-$(CONFIG_DRM_IVIP) += ivip/
obj-$(CONFIG_DRM_MGAG200) += mgag200/
obj-$(CONFIG_DRM_VC4) += vc4/
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
new file mode 100644
index 000..9a8c5ce
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Kconfig
@@ -0,0 +1,13 @@
+config DRM_IVIP
+tristate "Intel FGPA Video and Image Processing"
+depends on DRM && OF
+select DRM_GEM_CMA_HELPER
+select DRM_KMS_HELPER
+select DRM_KMS_FB_HELPER
+select DRM_KMS_CMA_HELPER
+help
+Choose this option if you have a Intel FPGA Arria 10 system
+and above with a Display Port IP. This does not support legacy
+Intel FPGA Cyclone V display port. Currently only single frame
+buffer is supported. Note that ACPI and X_86 architecture is yet
+to be supported.If M is selected the module would be called ivip.
diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
new file mode 100644
index 000..95291c6
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the drm device driver. This driver provides support for the
+# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
+
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_IVIP) += ivip.o
+ivip-objs := intel_vip_of.o intel_vip_core.o \
+intel_vip_conn.o
diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c
b/drivers/gpu/drm/ivip/intel_vip_conn.c
new file mode 100644
index 000..063d91e
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
@@ -0,0 +1,96 @@
+/*
+ * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * Authors:
+ * Ong, Hean-Loong
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static enum drm_connector_status
+intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
+{
+ return connector_status_connected;
+}
+
+static void intelvipfb_drm_connector_destroy(struct drm_connector *connector)
+{
+ drm_connector_unregister(connector);
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs intelvipfb_drm_connector_funcs = {
+ .dpms = drm_atomic_helper_connect
[PATCHv4 2/3] ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong Intel FPGA Video and Image Processing Suite Frame Buffer II driver config for Arria 10 devkit and its variants Signed-off-by: Ong, Hean Loong --- arch/arm/configs/socfpga_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig index 2620ce7..255f553 100644 --- a/arch/arm/configs/socfpga_defconfig +++ b/arch/arm/configs/socfpga_defconfig @@ -111,6 +111,12 @@ CONFIG_MFD_ALTERA_A10SR=y CONFIG_MFD_STMPE=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_DRM=m +CONFIG_DRM_IVIP=m +CONFIG_DRM_IVIP_OF=m +CONFIG_FB=y +CONFIG_FB_SIMPLE=y +CONFIG_FRAMEBUFFER_CONSOLE=m CONFIG_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_DWC2=y -- 2.7.4
[PATCHv4 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong
Device tree binding for Intel FPGA Video and Image
Processing Suite. The binding involved would be generated
from the Altera (Intel) Qsys system. The bindings would
set the max width, max height, buts per pixel and memory
port width. The device tree binding only supports the Intel
Arria10 devkit and its variants. Vendor name retained as
altr.
Signed-off-by: Ong, Hean Loong
---
.../devicetree/bindings/display/altr,vip-fb2.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt
diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
new file mode 100644
index 000..c4338d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
@@ -0,0 +1,39 @@
+Intel Video and Image Processing(VIP) Frame Buffer II bindings
+
+Supported hardware: Arria 10 and above with display port IP
+
+The hardware associated with this device tree is a SoC FPGA. Where there is an
ARM controller
+and a FPGA device. The ARM controller would host the Linux OS while the FPGA
device runs on its
+individual IP firmware. In the Intel VIP Frame Buffer II the ARM controller
would be
+driving data from the Linux OS to the FPGA device programmed with the Frame
Buffer II IP
+to render pixels to be streamed to the Display Port connector.
+
+The Frame Buffer II device is a simple frame buffer device. The device
contains the display
+properties and the bridge or connector register. The output for this device
currently
+is a dedicated to a single Display Port. Currently the max resolution
supported is 1280 x 720 at
+60Hz.
+
+More information the FPGA video IP component can be acquired from
+https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_vip.pdf
+
+
+New bindings:
+=
+Required properties:
+
+- compatible: "altr,vip-frame-buffer-2.0"
+- reg: Physical base address and length of the framebuffer controller's
+ registers.
+- altr,max-width: The width of the framebuffer in pixels.
+- altr,max-height: The height of the framebuffer in pixels.
+- altr,mem-port-width = the bus width of the avalon master port on the frame
reader
+
+Example:
+
+ dp_0_frame_buf: display-controller@10280 {
+ compatible = "altr,vip-frame-buffer-2.0";
+ reg = <0x0001 0x0280 0x0040>;
+ altr,max-width = <1280>;
+ altr,max-height = <720>;
+ altr,mem-port-width = <128>;
+ };
--
2.7.4
[PATCHv4 0/3] Intel FPGA VIP Frame Buffer II drm driver
From: Ong Hean Loong The FPGA FrameBuffer Soft IP could be seen as the GPU and the DRM driver patch here is allocating memory for information to be streamed from the ARM/Linux to the display port. Basically the driver just wraps the information such as the pixels to be drawn by the FPGA FrameBuffer 2. The piece of hardware in discussion is the SoC FPGA where Linux runs on the ARM chip and the FGPA is driven by its NIOS soft core with its own proprietary firmware. For example the application from the ARM Linux would have to write information on the /dev/fb0 with the information stored in the SDRAM to be fetched by the FPGA framebuffer IP and displayed on the Display Port Monitor. Ong Hean Loong (3): ARM:dt-bindings Intel FPGA Video and Image Processing Suite ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite DRM:ivip Intel FPGA Video and Image Processing Suite .../devicetree/bindings/display/altr,vip-fb2.txt | 39 arch/arm/configs/socfpga_defconfig | 6 + drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/ivip/Kconfig | 13 ++ drivers/gpu/drm/ivip/Makefile | 9 + drivers/gpu/drm/ivip/intel_vip_conn.c | 96 ++ drivers/gpu/drm/ivip/intel_vip_core.c | 183 ++ drivers/gpu/drm/ivip/intel_vip_drv.h | 54 ++ drivers/gpu/drm/ivip/intel_vip_of.c| 204 + 10 files changed, 607 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt create mode 100644 drivers/gpu/drm/ivip/Kconfig create mode 100644 drivers/gpu/drm/ivip/Makefile create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c -- 2.7.4
Re: [RFC] KVM: optimize the kvm_vcpu_on_spin
On 2017/7/31 21:22, Christoffer Dall wrote:
> On Sat, Jul 29, 2017 at 02:22:57PM +0800, Longpeng(Mike) wrote:
>> We had disscuss the idea here:
>> https://www.spinics.net/lists/kvm/msg140593.html
>
> This is not a very nice way to start a commit description.
>
> Please provide the necessary background to understand your change
> directly in the commit message.
>
>>
>> I think it's also suitable for other architectures.
>>
>
> I think this sentence can go in the end of the commit message together
> with your explanation of only doing this for x86.
>
OK :)
> By the way, the ARM solution should be pretty simple:
>
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index a39a1e1..b9f68e4 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -416,6 +416,11 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *v)
> && !v->arch.power_off && !v->arch.pause);
> }
>
> +bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu)
> +{
> + return vcpu_mode_priv(vcpu);
> +}
> +
> /* Just ensure a guest exit from a particular CPU */
> static void exit_vm_noop(void *info)
> {
>
>
> I am also curious in the workload you use to measure this and how I can
> evaluate the benefit on ARM?
>
We had tested this using the SpecVirt testsuite, no improvement (no decrease at
least) because of the spinlock isn't the major factor of this testsuite.
Currently I haven't any performance numbers to prove the patch is make sense,
but I'll do some tests later.
> Thanks,
> -Christoffer
>
>> If the vcpu(me) exit due to request a usermode spinlock, then
>> the spinlock-holder may be preempted in usermode or kernmode.
>> But if the vcpu(me) is in kernmode, then the holder must be
>> preempted in kernmode, so we should choose a vcpu in kernmode
>> as the most eligible candidate.
>>
>> PS: I only implement X86 arch currently for I'm not familiar
>> with other architecture.
>>
>> Signed-off-by: Longpeng(Mike)
>> ---
>> arch/mips/kvm/mips.c | 5 +
>> arch/powerpc/kvm/powerpc.c | 5 +
>> arch/s390/kvm/kvm-s390.c | 5 +
>> arch/x86/kvm/x86.c | 5 +
>> include/linux/kvm_host.h | 4
>> virt/kvm/arm/arm.c | 5 +
>> virt/kvm/kvm_main.c| 9 -
>> 7 files changed, 37 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
>> index d4b2ad1..2e2701d 100644
>> --- a/arch/mips/kvm/mips.c
>> +++ b/arch/mips/kvm/mips.c
>> @@ -98,6 +98,11 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>> return !!(vcpu->arch.pending_exceptions);
>> }
>>
>> +bool kvm_arch_vcpu_spin_kernmode(struct kvm_vcpu *vcpu)
>> +{
>> +return false;
>> +}
>> +
>> int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
>> {
>> return 1;
>> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>> index 1a75c0b..2489f64 100644
>> --- a/arch/powerpc/kvm/powerpc.c
>> +++ b/arch/powerpc/kvm/powerpc.c
>> @@ -58,6 +58,11 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *v)
>> return !!(v->arch.pending_exceptions) || kvm_request_pending(v);
>> }
>>
>> +bool kvm_arch_vcpu_spin_kernmode(struct kvm_vcpu *vcpu)
>> +{
>> +return false;
>> +}
>> +
>> int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
>> {
>> return 1;
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index 3f2884e..9d7c42e 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -2443,6 +2443,11 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>> return kvm_s390_vcpu_has_irq(vcpu, 0);
>> }
>>
>> +bool kvm_arch_vcpu_spin_kernmode(struct kvm_vcpu *vcpu)
>> +{
>> +return false;
>> +}
>> +
>> void kvm_s390_vcpu_block(struct kvm_vcpu *vcpu)
>> {
>> atomic_or(PROG_BLOCK_SIE, &vcpu->arch.sie_block->prog20);
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 82a63c5..b5a2e53 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -8435,6 +8435,11 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>> return kvm_vcpu_running(vcpu) || kvm_vcpu_has_events(vcpu);
>> }
>>
>> +bool kvm_arch_vcpu_spin_kernmode(struct kvm_vcpu *vcpu)
>> +{
>> +return kvm_x86_ops->get_cpl(vcpu) == 0;
>> +}
>> +
>> int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
>> {
>> return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> index 648b34c..f8f0d74 100644
>> --- a/include/linux/kvm_host.h
>> +++ b/include/linux/kvm_host.h
>> @@ -272,6 +272,9 @@ struct kvm_vcpu {
>> } spin_loop;
>> #endif
>> bool preempted;
>> +/* If vcpu is in kernel-mode when preempted */
>> +bool in_kernmode;
>> +
>> struct kvm_vcpu_arch arch;
>> struct dentry *debugfs_dentry;
>> };
>> @@ -797,6 +800,7 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu
>> *vcpu,
>> void kvm_arch_hardware_unsetup(void);
>> void kvm_arch_check_processor_compat(void *rtn);
>> int kvm_arch_vc
[PATCH v2] KVM: nVMX: Fix attempting to emulate "Acknowledge interrupt on exit" when there is no interrupt which L1 requires to inject to L2
From: Wanpeng Li
[ cut here ]
WARNING: CPU: 5 PID: 2288 at arch/x86/kvm/vmx.c:11124
nested_vmx_vmexit+0xd64/0xd70 [kvm_intel]
CPU: 5 PID: 2288 Comm: qemu-system-x86 Not tainted 4.13.0-rc2+ #7
RIP: 0010:nested_vmx_vmexit+0xd64/0xd70 [kvm_intel]
Call Trace:
vmx_check_nested_events+0x131/0x1f0 [kvm_intel]
? vmx_check_nested_events+0x131/0x1f0 [kvm_intel]
kvm_arch_vcpu_ioctl_run+0x5dd/0x1be0 [kvm]
? vmx_vcpu_load+0x1be/0x220 [kvm_intel]
? kvm_arch_vcpu_load+0x62/0x230 [kvm]
kvm_vcpu_ioctl+0x340/0x700 [kvm]
? kvm_vcpu_ioctl+0x340/0x700 [kvm]
? __fget+0xfc/0x210
do_vfs_ioctl+0xa4/0x6a0
? __fget+0x11d/0x210
SyS_ioctl+0x79/0x90
do_syscall_64+0x8f/0x750
? trace_hardirqs_on_thunk+0x1a/0x1c
entry_SYSCALL64_slow_path+0x25/0x25
This can be reproduced by booting L1 guest w/ 'noapic' grub parameter, which
means that tells the kernel to not make use of any IOAPICs that may be present
in the system.
Actually external_intr variable in nested_vmx_vmexit() is the req_int_win
variable passed from vcpu_enter_guest() which means that the L0's userspace
requests an irq window. I observed the scenario (!kvm_cpu_has_interrupt(vcpu) &&
L0's userspace reqeusts an irq window) is true, so there is no interrupt which
L1 requires to inject to L2, we should not attempt to emualte "Acknowledge
interrupt on exit" for the irq window requirement in this scenario.
This patch fixes it by not attempt to emulate "Acknowledge interrupt on exit"
if there is no L1 requirement to inject an interrupt to L2.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
v1 -> v2:
* update patch description
* check nested_exit_intr_ack_set() first
arch/x86/kvm/vmx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 2737343..c5a0ab5 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8,8 +8,9 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu,
u32 exit_reason,
vmx_switch_vmcs(vcpu, &vmx->vmcs01);
- if ((exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT)
- && nested_exit_intr_ack_set(vcpu)) {
+ if (nested_exit_intr_ack_set(vcpu) &&
+ exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT &&
+ kvm_cpu_has_interrupt(vcpu)) {
int irq = kvm_cpu_get_interrupt(vcpu);
WARN_ON(irq < 0);
vmcs12->vm_exit_intr_info = irq |
--
2.7.4
Re: [PATCH 3/3] mm/sched: memdelay: memory health interface for systems and workloads
On Mon, 2017-07-31 at 16:38 -0400, Johannes Weiner wrote: > On Mon, Jul 31, 2017 at 09:49:39PM +0200, Mike Galbraith wrote: > > On Mon, 2017-07-31 at 14:41 -0400, Johannes Weiner wrote: > > > > > > Adding an rq counter for tasks inside memdelay sections should be > > > straight-forward as well (except for maybe the migration cost of that > > > state between CPUs in ttwu that Mike pointed out). > > > > What I pointed out should be easily eliminated (zero use case). > > How so? I was thinking along the lines of schedstat_enabled(). > > > That leaves the question of how to track these numbers per cgroup at > > > an acceptable cost. The idea for a tree of cgroups is that walltime > > > impact of delays at each level is reported for all tasks at or below > > > that level. E.g. a leave group aggregates the state of its own tasks, > > > the root/system aggregates the state of all tasks in the system; hence > > > the propagation of the task state counters up the hierarchy. > > > > The crux of the biscuit is where exactly the investment return lies. > > Gathering of these numbers ain't gonna be free, no matter how hard you > > try, and you're plugging into paths where every cycle added is made of > > userspace hide. > > Right. But how to implement it sanely and optimize for cycles, and > whether we want to default-enable this interface are two separate > conversations. > > It makes sense to me to first make the implementation as lightweight > on cycles and maintainability as possible, and then worry about the > cost / benefit defaults of the shipped Linux kernel afterwards. > > That goes for the purely informative userspace interface, anyway. The > easily-provoked thrashing livelock I have described in the email to > Andrew is a different matter. If the OOM killer requires hooking up to > this metric to fix it, it won't be optional. But the OOM code isn't > part of this series yet, so again a conversation best had later, IMO. If that "the many must pay a toll to save the few" conversation ever happens, just recall me registering my boo/hiss in advance. I don't have to feel guilty about not liking the idea of making donations to feed the poor starving proggies ;-) -Mike
Re: [linux-sunxi] Re: [PATCH 0/4] clk: sunxi-ng: Fix issues with fractional mode
On Tue, Aug 1, 2017 at 12:50 AM, Jernej Škrabec wrote: > Hi Chen-Yu, > > Dne ponedeljek, 31. julij 2017 ob 07:13:34 CEST je Chen-Yu Tsai napisal(a): >> Hi Jernej, >> >> On Mon, Jul 31, 2017 at 12:41 AM, Jernej Skrabec >> >> wrote: >> > During development of H3 HDMI driver, I found some issues with >> > setting video clock rate. It turned out that clock driver decided >> > to use fractional mode and selected right frequency, but it didn't >> > enable it. Additionally, fractional helpers don't wait on lock. >> >> What kind of resolution were you testing to actually hit this? > > 1920x1080p @ 60Hz > >> >> AFAIK the fractional mode is either 297 or 270 MHz. Even Full HD >> 1080p60 dot clocks aren't that high. And the clk drivers should >> try to request a matching parent clk rate. So the PLL wouldn't >> go that high. Are you testing 4k @ 30fps? > > No, it is a bit more complicated than that. H3's HDMI PHY is proprietary and > register meanings are not known well. Because of that, I'm using values found > in BSP driver. Those values include pixel clock divider. BSP driver always use > 297 MHz as a base and uses dividers in PHY to prepare right pixel clock. So > the case for 1080p is 297 MHz / 2 = 148.5 MHz. I see. So for the current in kernel users, none would be able to hit the fractional mode clock rates. HDMI on sun5i is limited to 1080p60, and we don't support pixel doubling. LCD dotclocks have a minimal /6 divider, though it doesn't seem likely they will hit this either, or we would have seen someone complain. And these drivers were introduced well before 4.13-rc1. The clk maintainers really like to have just critical fixes, and fixes for stuff added in the current release. So I'm re-queuing these 4 patches for 4.14. Thanks ChenYu > >> >> As it stands, I don't think any of the existing display support >> can go that high, so I think we're safe as far as old kernels >> go, i.e. we don't need to Cc stable for these. > > Ok. > > Regards, > Jernej > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.
Re: [PATCH 1/3] fs, xfs: introduce S_IOMAP_IMMUTABLE
On Mon, Jul 31, 2017, at 02:23 PM, Darrick J. Wong wrote:
> I don't think F_SEAL_{SHRINK,GROW} prevents reflinking or CoW of file data,
> which are two things that cannot happen under S_IOMAP_IMMUTABLE that
> aren't size changes. From the implementation it looks like shrink and
> grow are only supposed to disallow changes to i_size, not i_blocks (or
> the file block map).
True.
> Then again, I suppose F_SEAL_* only work on shmem, so maybe it simply
> isn't defined for any other filesystem...? e.g. it doesn't prohibit
> reflink, but the only fs implementing seals doesn't support reflink.
>
>
>
> Seals cannot be removed, which is too strict for the S_IOMAP_IMMUTABLE
> user cases being presented.
To be clear, the set of use cases is swap files and DAX, right? Or is there
anything else?
I can't imagine why anyone would want to turn a swap file back into a regular
file.
I haven't fully followed DAX, but I'd take your word for it if people want to
be able to remove the flag after.
Anyways, I think your broader point is right; the use cases are different enough
that it doesn't make sense to try to add S_CONTENT_IMMUTABLE (or however
one decides to call it) at the same time.
[PATCH] sched: fix NULL pointer issue in pick_next_entity()
When we select CFQ as the scheduler, in function pick_next_task_fair it will pass NULL as the 2nd argument to pick_next_entity: pick_next_entity(cfs_rq, NULL); And once __pick_first_entity() is called, it could return NULL as well. So in function pick_next_entity(), the local variable 'left' and 'curr' could both be NULL, then this will cause NULL pointer issue. In order to fix this issue, we just need return NULL under the condition that both 'left' and 'curr' are NULL, meaning that no entity available. Signed-off-by: Yafang Shao --- kernel/sched/fair.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index c95880e..e64c359 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3903,6 +3903,8 @@ static void clear_buddies(struct cfs_rq *cfs_rq, struct sched_entity *se) struct sched_entity *left = __pick_first_entity(cfs_rq); struct sched_entity *se; + if (!left && !curr) + return NULL; /* * If curr is set we have to see if its left of the leftmost entity * still in the tree, provided there was anything in the tree at all. -- 1.8.3.1
Re: [RFC][PATCH v3]: documentation,atomic: Add new documents
On Mon, Jul 31, 2017 at 10:43:45AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 31, 2017 at 07:04:03PM +0800, Boqun Feng wrote:
> > On Mon, Jul 31, 2017 at 11:05:35AM +0200, Peter Zijlstra wrote:
> > > On Wed, Jul 26, 2017 at 08:47:50PM +0800, Boqun Feng wrote:
> > >
> > > > > +
> > > > > +Further, while something like:
> > > > > +
> > > > > + smp_mb__before_atomic();
> > > > > + atomic_dec(&X);
> > > > > +
> > > > > +is a 'typical' RELEASE pattern, the barrier is strictly stronger than
> > > > > +a RELEASE. Similarly for something like:
> > > > > +
> > > >
> > > > .. at here. Maybe you planned to put stronger ACQUIRE pattern?
> > >
> > > Yes, although I struggled to find a sensible one. The problem is that
> > > ACQUIRE is on loads and value returning atomics have an ACQUIRE variant,
> > > so why would you ever want to use smp_mb__after_atomic() for this.
> > >
> > >
> > > That is, the best I could come up with is something like:
> > >
> > > val = atomic_fetch_or_relaxed(1, &var);
> > > smp_mb__after_atomic();
> > >
> > > But in that case we should've just written:
> > >
> > > val = atomic_fetch_or_acquire(1, &var);
> > >
> >
> > Agreed.
> >
> > And besides, in memory-barriers.txt, the wording is:
> >
> > (*) smp_mb__before_atomic();
> > (*) smp_mb__after_atomic();
> >
> > These are for use with atomic (such as add, subtract, increment and
> > decrement) functions that don't return a value, especially when used
> > for
> > reference counting.
> >
> > So actually, using smp_mb__after_atomic() for ACQUIRE is a misuse.
>
> You lost me on this one.
>
> Why wouldn't the following have ACQUIRE semantics?
>
> atomic_inc(&var);
> smp_mb__after_atomic();
>
> Is the issue that there is no actual value returned or some such?
>
That "misuse" is a wrong word there ;-(
I actually meant "the usage is correct but we don't encourage using
smp_mb__after_atomic() *only* for an ACQUIRE, because _acquire() could
always be used in that case, as Peter said".
In fact in your case, the ordering is stronger, both the load and store
part of the atomic op are ordered with the memory ops following it.
In short, I suggested we tell users to use
smp_mb__{before,after}_atomic() only when _{release,acquire} ops don't
suffice, i.e. for an RCsc RELEASE or a smp_mb() to order ops other than
the atomic op itself(like the one you use in __call_rcu_nocb_enqueue()).
But maybe this is too strict, and Peter said he would write something
about it in IRC, so I'm not that stick to this suggestion ;-)
Regards,
Boqun
> > > Suggestions?
> >
> > As a result, I think it's better we say smp_mb__{before,after}_atomic()
> > are only for 1) non-value-returning RmW atomic ops, 2)
> > {set,clear,change}_bit and 3) internal use of atomic primitives(e.g. the
> > generic version of fully ordered atomics).
> >
> > 1) prevents people to use it for an ACQUIRE, but allows for a RELEASE.
> > 1) & 2) makes atomic_t.txt consistent with memory-barriers.txt
> > 3) explains our usage of those barriers internally.
> >
> > Thoughts?
>
> So if I have something like this, the assertion really can trigger?
>
> WRITE_ONCE(x, 1); atomic_inc(&y);
> r0 = xchg_release(&y, 5); smp_mb__after_atomic();
> r1 = READ_ONCE(x);
>
>
> WARN_ON(r0 == 0 && r1 == 0);
>
> I must confess that I am not seeing why we would want to allow this
> outcome.
>
> Thanx, Paul
>
signature.asc
Description: PGP signature
Re: [PATCH V2] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug
On 07/31/2017 10:09 AM, Zheng, Lv wrote:
> Hi,
>
>> From: linux-acpi-ow...@vger.kernel.org
>> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Song
>> liwei
>> Subject: [PATCH V2] ACPI, APEI: Fixup incorrect 16-bit access width firmware
>> bug
>>
>> From: Liwei Song
>>
>> This is a follow up to commit f712c71f7b2b ("ACPI, APEI: Fixup common
>> access width firmware bug") fix the following firmware bug:
>>
>> [Firmware Bug]: APEI: Invalid bit width + offset in GAR [0xb2/16/0/1/1]
>>
>> This is due to an 8-bit access width is specified for a 16-bit register,
>> Rearrange the condition and add 8-bit width check.
>>
>> Signed-off-by: Liwei Song
>> ---
>> drivers/acpi/apei/apei-base.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c
>> index da370e1..eca3d7a 100644
>> --- a/drivers/acpi/apei/apei-base.c
>> +++ b/drivers/acpi/apei/apei-base.c
>> @@ -604,12 +604,12 @@ static int apei_check_gar(struct acpi_generic_address
>> *reg, u64 *paddr,
>> *access_bit_width = 1UL << (access_size_code + 2);
>>
>> /* Fixup common BIOS bug */
>> -if (bit_width == 32 && bit_offset == 0 && (*paddr & 0x03) == 0 &&
>> -*access_bit_width < 32)
>> -*access_bit_width = 32;
>> -else if (bit_width == 64 && bit_offset == 0 && (*paddr & 0x07) == 0 &&
>> -*access_bit_width < 64)
>> -*access_bit_width = 64;
>> +if (*access_bit_width < bit_width && bit_offset == 0) {
>> +if ((bit_width == 16 && (*paddr & 0x01) == 0) ||
>> +(bit_width == 32 && (*paddr & 0x03) == 0) ||
>> +(bit_width == 64 && (*paddr & 0x07) == 0))
>> +*access_bit_width = bit_width;
>> +}
>>
>> if ((bit_width + bit_offset) > *access_bit_width) {
>> pr_warning(FW_BUG APEI_PFX
>
> IMO, such problem could also be fixed by this commit and a cleanup of APEI
> GAR code to invoke generic ACPICA GAR API - acpi_read()/acpi_write() directly.
> https://github.com/acpica/acpica/pull/209
Hi Lv,
I'm a bit confuse about the commit you said, do you mean this commit can also
fix
this common 16-bit access width error, and will check-in to upstream kernel
latter?
If so, please ignore this review.
Thanks,
Liwei.
>
> Thanks and best regards
> Lv
>
>
>
RE: [PATCH v1 1/6] dma: fsl-dma: add devicetree documentation for qdma driver.
Redraw this patch, thanks.
Jiaheng
-Original Message-
From: jiaheng.fan [mailto:jiaheng@nxp.com]
Sent: Tuesday, August 01, 2017 9:47 AM
To: vinod.k...@intel.com; robh...@kernel.org; dan.j.willi...@intel.com;
mark.rutl...@arm.com; li...@armlinux.org.uk; shawn...@kernel.org
Cc: Leo Li ; dmaeng...@vger.kernel.org;
linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Jiafei Pan
; Jiaheng Fan
Subject: [PATCH v1 1/6] dma: fsl-dma: add devicetree documentation for qdma
driver.
signed-off-by: jiaheng.fan
---
Documentation/devicetree/bindings/dma/fsl-qdma.txt | 42 ++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/fsl-qdma.txt
diff --git a/Documentation/devicetree/bindings/dma/fsl-qdma.txt
b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
new file mode 100644
index 000..b076177
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
@@ -0,0 +1,42 @@
+* Freescale queue Direct Memory Access Controller(qDMA) Controller
+
+ The qDMA controller transfers blocks of data between one source and
+one or more destinations. The blocks of data transferred can be
+represented in memory as contiguous or non-contiguous using
+scatter/gather table(s). Channel virtualization is supported through
+enqueuing of DMA jobs to, or dequeuing DMA jobs from, different work queues.
+
+* qDMA Controller
+Required properties:
+- compatible :
+ - "fsl,ls1021a-qdma",
+ Or "fsl,ls1043a-qdma" followed by "fsl,ls1021a-qdma",
+- reg : Specifies base physical address(s) and size of the qDMA registers.
+ The region is qDMA control register's address and size.
+- interrupts : A list of interrupt-specifiers, one for each entry in
+ interrupt-names.
+- interrupt-names : Should contain:
+ "qdma-error" - the error interrupt
+ "qdma-queue" - the queue interrupt
+- channels : Number of channels supported by the controller
+- queues : Number of queues supported by driver
+
+Optional properties:
+- big-endian: If present registers and hardware scatter/gather descriptors
+ of the qDMA are implemented in big endian mode, otherwise in little
+ mode.
+
+
+Examples:
+
+ qdma: qdma@839 {
+ compatible = "fsl,ls1021a-qdma";
+ reg = <0x0 0x8398000 0x0 0x2000 /* Controller registers */
+ 0x0 0x839a000 0x0 0x2000>; /* Block registers */
+ interrupts = ,
+ ;
+ interrupt-names = "qdma-error", "qdma-queue";
+ channels = <8>;
+ queues = <2>;
+ big-endian;
+ };
--
2.7.4
