OLQF_CLEAN flag is used by OCFS2 on disk to recognize whether quota
recovery is needed or not. We also somewhat abuse mem_dqinfo->dqi_flags
to pass this flag around. Use private flags for this to avoid clashes
with other quota flags / not pollute generic quota flag namespace.
Signed-off-by: Jan Kara <jack@suse.cz>
Currently, v2 quota format blindly stored flags from in-memory dqinfo on
disk, although there are no flags supported. Since it is stupid to store
flags which have no effect, just store 0 unconditionally and don't
bother loading it from disk.
Note that userspace could have stored some flags there via Q_SETINFO
quotactl and then later read them (although flags have no effect) but
I'm pretty sure noone does that (most definitely quota-tools don't and
quota interface doesn't have too much other users).
Signed-off-by: Jan Kara <jack@suse.cz>
blkdev_issue_discard() will zero a given block range. This is done by
way of explicit writing, thus provisioning or allocating the blocks on
disk.
There are use cases where the desired behavior is to zero the blocks but
unprovision them if possible. The blocks must deterministically contain
zeroes when they are subsequently read back.
This patch adds a flag to blkdev_issue_zeroout() that provides this
variant. If the discard flag is set and a block device guarantees
discard_zeroes_data we will use REQ_DISCARD to clear the block range. If
the device does not support discard_zeroes_data or if the discard
request fails we will fall back to first REQ_WRITE_SAME and then a
regular REQ_WRITE.
Also update the callers of blkdev_issue_zero() to reflect the new flag
and make sb_issue_zeroout() prefer the discard approach.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
With removal of backing_dev_info from struct address_space,
we don't need to assign it in Lustre either.
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Jens Axboe <axboe@fb.com>
Hi,
If you can manage to submit an async write as the first async I/O from
the context of a process with realtime scheduling priority, then a
cfq_queue is allocated, but filed into the wrong async_cfqq bucket. It
ends up in the best effort array, but actually has realtime I/O
scheduling priority set in cfqq->ioprio.
The reason is that cfq_get_queue assumes the default scheduling class and
priority when there is no information present (i.e. when the async cfqq
is created):
static struct cfq_queue *
cfq_get_queue(struct cfq_data *cfqd, bool is_sync, struct cfq_io_cq *cic,
struct bio *bio, gfp_t gfp_mask)
{
const int ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
const int ioprio = IOPRIO_PRIO_DATA(cic->ioprio);
cic->ioprio starts out as 0, which is "invalid". So, class of 0
(IOPRIO_CLASS_NONE) is passed to cfq_async_queue_prio like so:
async_cfqq = cfq_async_queue_prio(cfqd, ioprio_class, ioprio);
static struct cfq_queue **
cfq_async_queue_prio(struct cfq_data *cfqd, int ioprio_class, int ioprio)
{
switch (ioprio_class) {
case IOPRIO_CLASS_RT:
return &cfqd->async_cfqq[0][ioprio];
case IOPRIO_CLASS_NONE:
ioprio = IOPRIO_NORM;
/* fall through */
case IOPRIO_CLASS_BE:
return &cfqd->async_cfqq[1][ioprio];
case IOPRIO_CLASS_IDLE:
return &cfqd->async_idle_cfqq;
default:
BUG();
}
}
Here, instead of returning a class mapped from the process' scheduling
priority, we get back the bucket associated with IOPRIO_CLASS_BE.
Now, there is no queue allocated there yet, so we create it:
cfqq = cfq_find_alloc_queue(cfqd, is_sync, cic, bio, gfp_mask);
That function ends up doing this:
cfq_init_cfqq(cfqd, cfqq, current->pid, is_sync);
cfq_init_prio_data(cfqq, cic);
cfq_init_cfqq marks the priority as having changed. Then, cfq_init_prio
data does this:
ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
switch (ioprio_class) {
default:
printk(KERN_ERR "cfq: bad prio %x\n", ioprio_class);
case IOPRIO_CLASS_NONE:
/*
* no prio set, inherit CPU scheduling settings
*/
cfqq->ioprio = task_nice_ioprio(tsk);
cfqq->ioprio_class = task_nice_ioclass(tsk);
break;
So we basically have two code paths that treat IOPRIO_CLASS_NONE
differently, which results in an RT async cfqq filed into a best effort
bucket.
Attached is a patch which fixes the problem. I'm not sure how to make
it cleaner. Suggestions would be welcome.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Tested-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: stable@kernel.org
Signed-off-by: Jens Axboe <axboe@fb.com>
Since d621e8bae5 (Create of_mm_gpiochip_remove), there is a
counterpart for of_mm_gpiochip_add.
This patch implements the remove function of the driver making use of
it.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Station info state is started in allocation, so should be
destroyed on free (it's just a timer); rate control must
be freed if anything afterwards fails to initialize.
LED exit should be later, no need for locking there, but
it needs to be done also when rate init failed.
Also clean up the code by moving a label so the locking
doesn't have to be done separately.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The PCIe spec (r3.0, sec 7.8.9) says Hot-Plug Surprise indicates support
for surprise *removal*, but pciehp checked this to determine if it should
handle presence detect interrupts for device *addition*.
Allow surprise device addition even if the slot doesn't advertise support
for surprise removal.
Keith has a platform with slots for front-loading SFF devices. The slots
do not have attention buttons and do not support surprise removal, but they
do have presence detect. In that case, we still want to use presence
detect for device addition.
Keith's original patch handled surprise insertions only if Hot-Plug Capable
is set. I think that test is superfluous because pciehp only claims slots
that advertise Hot-Plug Capable (see get_port_device_capability()).
Link: http://lkml.kernel.org/r/1419275223-14602-1-git-send-email-keith.busch@intel.com
Based-on-patch-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rajat Jain <rajatxjain@gmail.com>
The prior change fixes default output ordering with each column but it
breaks -o/--order option. This patch prepends a new hpp fmt struct to
sort list but not to output field list so that it can affect ordering
without adding a new output column.
The new hpp fmt uses its own compare functions which treats dummy
entries (which have no baseline) little differently - the delta field
can be computed without baseline but others (ratio and wdiff) are not.
The new output will look like below:
$ perf diff -o 2 perf.data.{old,cur,new}
...
# Baseline/0 Delta/1 Delta/2 Shared Object Symbol
# .......... ....... ....... ................. ..........................................
22.98% +0.51% +0.52% libc-2.20.so [.] _int_malloc
5.70% +0.28% +0.30% libc-2.20.so [.] free
4.38% -0.21% +0.25% a.out [.] main
1.32% -0.15% +0.05% a.out [.] free@plt
+0.01% [kernel.kallsyms] [k] intel_pstate_timer_func
+0.01% [kernel.kallsyms] [k] _raw_spin_lock_irqsave
+0.01% [kernel.kallsyms] [k] timekeeping_update.constprop.8
+0.01% +0.01% [kernel.kallsyms] [k] apic_timer_interrupt
0.01% -0.00% [kernel.kallsyms] [k] native_read_msr_safe
0.01% -0.01% -0.01% [kernel.kallsyms] [k] native_write_msr_safe
1.31% +0.03% -0.06% a.out [.] malloc@plt
31.50% -0.74% -0.23% libc-2.20.so [.] _int_free
32.75% +0.28% -0.83% libc-2.20.so [.] malloc
0.01% [kernel.kallsyms] [k] scheduler_tick
+0.01% [kernel.kallsyms] [k] read_tsc
+0.01% [kernel.kallsyms] [k] perf_adjust_freq_unthr_context.part.82
In above example, the output was sorted by 'Delta/2' column first, and
then 'Baseline/0' and finally 'Delta/1'.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1420677949-6719-8-git-send-email-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Currently ->cmp, ->collapse and ->sort callbacks doesn't pass
corresponding fmt. But it'll be needed by upcoming changes in
perf diff command.
Suggested-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1420677949-6719-6-git-send-email-namhyung@kernel.org
[ fix build by passing perf_hpp_fmt pointer to hist_entry__cmp_ methods ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The fmt_to_data_file() is to retrieve struct data__file from
perf_hpp_fmt which is embedded in diff_hpp_fmt. It'll be used by sort
callback functions later.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1420677949-6719-5-git-send-email-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Current perf diff result is somewhat confusing since it sometimes hide
small result and sometimes there's no result. So do not hide small
result (less than 0.01%) and print "N/A" if baseline is not
recorded (for ratio and wdiff only). Blank means the baseline is
available but its pairs are not.
Before:
# Baseline Delta Shared Object Symbol
# ........ ....... ................. .........................
#
...
0.01% -0.01% [kernel.kallsyms] [k] native_write_msr_safe
0.01% [kernel.kallsyms] [k] scheduler_tick
0.01% [kernel.kallsyms] [k] native_read_msr_safe
0.00% [kernel.kallsyms] [k] __rcu_read_unlock
[kernel.kallsyms] [k] _raw_spin_lock
+0.01% [kernel.kallsyms] [k] apic_timer_interrupt
[kernel.kallsyms] [k] read_tsc
After:
# Baseline Delta Shared Object Symbol
# ........ ....... ................. .........................
#
...
0.01% -0.01% [kernel.kallsyms] [k] native_write_msr_safe
0.01% [kernel.kallsyms] [k] scheduler_tick
0.01% [kernel.kallsyms] [k] native_read_msr_safe
0.00% [kernel.kallsyms] [k] __rcu_read_unlock
+0.01% [kernel.kallsyms] [k] _raw_spin_lock
+0.01% [kernel.kallsyms] [k] apic_timer_interrupt
+0.01% [kernel.kallsyms] [k] read_tsc
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1419656793-32756-3-git-send-email-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The hists__compute_resort() is to sort output fields based on the
given field/criteria. This was done without the sort list but as we
added the field to the sort list, we can do it with normal
hists__output_resort() using the ->sort callback.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1419656793-32756-2-git-send-email-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The exclusive options are to prohibit use of conflicting options at the
same time. But it had a side effect that it also limits a such option
can be used at most once. Currently the only user of the flag is perf
probe and it allows to use such options more than once, but when one
tries to use it, perf will fail like below:
$ sudo perf probe -x /lib/libc-2.20.so --add malloc --add free
Error: option `add' cannot be used with add
...
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1420886028-15135-1-git-send-email-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Event parameters are a basic way for partial events to be specified in
sysfs with per-event names given to the fields that need to be filled in
when using a particular event.
It is intended for supporting cases where the single 'cpu' parameter is
insufficient. For example, POWER 8 has events for physical
sockets/cores/cpus that are accessible from with virtual machines. To
keep using the single 'cpu' parameter we'd need to perform a mapping
between Linux's cpus and the physical machine's cpus (in this case Linux
is running under a hypervisor). This isn't possible because bindings
between our cpus and physical cpus may not be fixed, and we probably
won't have a "cpu" on each physical cpu.
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Cody P Schafer <dev@codyps.com>
Cc: Haren Myneni <hbabu@us.ibm.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lkml.kernel.org/r/1420679633-28856-4-git-send-email-sukadev@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This causes `perf list pmu` to show parameters for parameterized events
like:
pmu/event_name,param1=?,param2=?/ [Kernel PMU event]
An example:
hv_24x7/HPM_TLBIE__PHYS_CORE,core=?/ [Kernel PMU event]
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Cody P Schafer <dev@codyps.com>
Cc: Haren Myneni <hbabu@us.ibm.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lkml.kernel.org/r/1420679633-28856-3-git-send-email-sukadev@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Removes some functions that are not used anywhere:
color_parse_mem()
color_parse()
This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ramkumar Ramachandra <artagnon@gmail.com>
Link: http://lkml.kernel.org/r/1419079865-354-1-git-send-email-rickard_strandqvist@spectrumdigital.se
[ Remove now unused parse_{attr,color} routines too ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The report__inc_stat() function collects the number of hist entries in
the session in order to calculate the max size of the progess bar.
It'd be better if it does it during the addition of hist entries so that
it can be used by other places too.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1419223455-4362-2-git-send-email-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The code being used when decaying and deleting entries from a hists
instance was the same, provide a function to avoid code dup.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-j6ideab7lkakavfvfguw858z@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
No logic changes, just to be consistent.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-f7n5y0mvk6gew5185h6fg316@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Just like the other parameters, grouping it on the builtin-mem specific
config area: struct perf_mem.
Acked-by: Stephane Eranian <eranian@google.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Joe Mario <jmario@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Richard Fowles <rfowles@redhat.com>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-ad8ns5l51ongemfsir3zy09x@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This patch modifies perf mem to default to sampling loads and stores
simultaneously. It could only do one or the other before yet there was
no hardware restriction preventing simultaneous collection. With this
patch, one run is sufficient to collect both.
It is still possible to sample only loads or stores by using the
-t option:
$ perf mem -t load rec
$ perf mem -t load rep
Or
$ perf mem -t store rec
$ perf mem -t store rep
The perf report TUI will show one event at a time. The store output will
contain a Weight column which will be empty.
In V2, we updated the man pages to reflect the change and also simplify
the initialization of the argv vector passed to the cmd_*() functions as
per LKML feedback.
In V3, we fixed typos in the changelog.
Signed-off-by: Stephane Eranian <eranian@google.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Joe Mario <jmario@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Richard Fowles <rfowles@redhat.com>
Link: http://lkml.kernel.org/r/20141217152355.GA10053@thinkpad
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Commit c7d7ddee7e ("ata: libahci: Allow using multiple regulators")
releases regulators during ahci_platform_put_resources(). That doesn't
work because the function is run as part of the devres machinery. Such
resources are torn down in reverse order. Since the array that holds
pointers to the regulators is allocated using devres after the device
context to which ahci_platform_put_resources() is attached, the memory
will be freed before calling ahci_platform_put_resources() and thereby
causing a use-after-free error.
This commit fixes this by using regular allocations for the array. The
memory can then be freed after the regulators have been released. This
conserves the advantages of using the managed API.
Reported-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
This line converts PHYS_OFFSET into PHYS_PFN_OFFSET.
It is better to use PAGE_SHIFT rather than the magic number 12.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This comment does not correspond to the actual code.
When zImage is loaded at a lower *OR* higher address of
the destination of Image, it won't overwrite itself.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This patch fixes following build warning:
In file included from include/linux/printk.h:261:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/power/bq24190_charger.c:11:
drivers/power/bq24190_charger.c: In function ‘bq24190_irq_handler_thread’:
include/linux/dynamic_debug.h:86:20: warning: ‘ss_reg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^
drivers/power/bq24190_charger.c:1211:5: note: ‘ss_reg’ was declared here
u8 ss_reg, f_reg;
^
In file included from include/linux/printk.h:261:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/power/bq24190_charger.c:11:
include/linux/dynamic_debug.h:86:20: warning: ‘f_reg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^
drivers/power/bq24190_charger.c:1211:13: note: ‘f_reg’ was declared here
u8 ss_reg, f_reg;
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
DMA contiguous allocations have been able to use highmem since commit
"95b0e65 ARM: mm: don't limit default CMA region only to low memory"
but a comment still notes the earlier "low memory" limitation. Update
the comment to remove the low memory limitation and fix the
s/contigouos/contiguous/ typo while we're at it.
Signed-off-by: George G. Davis <george_davis@mentor.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
As of commit abda1bd5f4 __cpu_suspend()
takes only 2 arguments, and those arguments are passed by the platform
code. This comment thus makes no sense, as cpu_suspend() is not actually
hiding any arguments.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The current rounding of "size" is wrong:
- If "start" is sufficiently near the next page boundary, "size"
is decremented by more than enough and the last page is lost.
- If "size" is sufficiently small, it is wrapped around and gets
a bogus value.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When building a multi_v7_defconfig kernel it is not possible to configure
DEBUG_LL to use any serial device except a ARM Primecell PL01X, or more
accurately and worse, it is possible to configure a different serial
device but KConfig does not honour this request. In fact this also
overrides the user selection for some of the single platform kernels, for
example I don't think DEBUG_LL can be targeted at ICE or semihosted
supervisor for ARCH_VERSATILE.
This happens because DEBUG_UART_PL01X is automatically enabled by
some architectures and this means user decisions made regarding
the DEBUG_LL backend will be overridden. Problem is fixed by removing the
automatic enabling of this option.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
On EP93XX uncompress.h uses CONFIG_DEBUG_UART_PHYS instead of a hard
coded serial port. This means the build breaks when DEBUG_LL
(and DEBUG_LL_UART_PL01X) is not enabled.
This is fixed by adding a new dependency.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
As part of the migration we introduce DEBUG_UART_PHYS/DEBUG_UART_VIRT
which default to UART1 but allow a user to configure UART2 or UART3.
We also introduce symbolic names for the registers and flags.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Arnd Bergmann <arnd.bergmann@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The omap1's debug-macro.S is similar to the generic 8250 code. Compared to
the 8520 code the omap1 macro automatically determines what UART to use
based on breadcrumbs left by the bootloader and automatically copes with
the eccentric register layout on OMAP7XX.
This patch drops both these features and relies instead on the generic
8250 macros:
1. Dropping support for the bootloader breadcrumbs is identical to the
way the migration was handled for OMAP2 (see 808b7e07464d...).
2. Support for OMAP7XX still exists but it must be configured by hand
(DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Arnd Bergmann <arnd.bergmann@linaro.org>
Cc: linux-omap@vger.kernel.org
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
As part of the migration a couple of uart definitions have been copied
from of the platform specific header files.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Greg Ungerer <gerg@uclinux.org>
Cc: Arnd Bergmann <arnd.bergmann@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Only a very small handful of platforms support DEBUG_LL_UART_NONE but it
lurks in the menus of every single platform config ready to break the
build. This is an especial problem for defconfig/oldconfig since it is
often selected by default.
This patch solves the problem by removing this option. Any platforms
still depending upon this option must be migrated.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
All defconfigs touched by this patch already enable DEBUG_LL and by
default DEBUG_LL_UART_NONE will be selected. This causes no issues
today because due to some back compatibility magic we eventually need
to remove it is not actually honoured. Nevertheless DEBUG_LL_UART_8250
is the right value for these platforms and should be set in the config
files.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The default value for DEBUG_CNS3xxx appears twice. This patch removes
the one with the wrong sort order.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add a reset driver for Renesas R-Mobile and SH-Mobile SoCs. It registers
a restart handler to trigger a soft power-on reset through the R-Mobile
System Controller.
The priority of this restart handler is 192, to allow a watchdog driver
to use priority 128.
Note that we do not use syscon-reboot, as the HPB (Peripheral Bus
Bridge) semaphore should be acquired on systems where both the ARM and
SH core are in use. The driver can be extended later to support this,
when needed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
arch/x86/kvm/emulate.c: In function ‘check_cr_write’:
arch/x86/kvm/emulate.c:3552:4: warning: left shift count >= width of type
rsvd = CR3_L_MODE_RESERVED_BITS & ~CR3_PCID_INVD;
happens because sizeof(UL) on 32-bit is 4 bytes but we shift it 63 bits
to the left.
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Fix a potentially uninitialized return value in klp_enable_func().
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The I2C address for the TDA9989 and TDA19989 is fixed at 0x34 but the
two LSBs of the TDA19988's address are set by two configuration pins
on the chip. Irrespective of the chip, the associated CEC peripheral's
I2C address is based upon the main I2C address.
This patch avoids any special handling required to support systems that
contain multiple TDA19988 devices on the same I2C bus.
Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Copying 64 bit data from user space using get_user is not supported
on all architectures, and may result in the following build error.
ERROR: "__get_user_bad" [drivers/gpu/drm/drm.ko] undefined!
Avoid the problem by using copy_from_user.
Fixes: d34f20d6e2 ("drm: Atomic modeset ioctl")
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The current implementation of drm_read() faces a number of issues:
1. Upon an error, it consumes the event which may lead to the client
blocking.
2. Upon an error, it forgets about events already copied
3. If it fails to copy a single event with O_NONBLOCK it falls into a
infinite loop of reporting EAGAIN.
3. There is a race between multiple waiters and blocking reads of the
events list.
Here, we inline drm_dequeue_event() into drm_read() so that we can take
the spinlock around the list walking and event copying, and importantly
reorder the error handling to avoid the issues above.
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Testcase: igt/drm_read
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make drm_fb_helper_initial_config() return an int rather than a bool so
that the error can be properly propagated. While at it, update drivers
to propagate errors further rather than just ignore them.
v2:
- cirrus: No cleanup is required, the top-level cirrus_driver_load()
will do it as part of cirrus_driver_unload() in its cleanup path.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
[danvet: Squash in simplification patch from kbuild.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 765d5b9c2b ("fbdev: fbcon: select VT_HW_CONSOLE_BINDING")
made FRAMEBUFFER_CONSOLE always select VT_HW_CONSOLE_BINDING, but forgot
to remove
select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
from the individual drivers' sections that already did this before.
Remove it, also from new drivers.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
