[PATCH v15 2/8] perf evlist: Introduce aux evlist
An auxiliary evlist is created by perf_evlist__new_aux() using an
existing evlist as its parent. An auxiliary evlist can have its own
'struct perf_mmap', but can't have any other data. User should use its
parent instead when accessing other data.
Auxiliary evlists are containers of 'struct perf_mmap'. It is introduced
to allow its parent evlist to map different events into separated mmaps.
Following commits create an auxiliary evlist for overwritable
events, because overwritable events need a read only and backwards ring
buffer, which is different from normal events.
To achieve this goal, this patch carefully changes 'evlist' to
'evlist->parent' in all functions in the path of 'perf_evlist__mmap_ex',
except 'evlist->mmap' related operations, to make sure all evlist
modifications (like pollfd and event id hash tables) goes to original
evlist.
A 'evlist->parent' pointer is added to 'struct perf_evlist' and points to
the evlist itself for normal evlists.
Children of one evlist are linked into it so one can find all children
from its parent.
To avoid potential complexity, forbid creating aux evlist from another
aux evlist.
Improve perf_evlist__munmap_filtered(), so when recording, if an event
is terminated, unmap mmaps, from parent and children.
Signed-off-by: Wang Nan
Cc: He Kuang
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: Nilay Vaish
Cc: pi3or...@163.com
---
tools/perf/util/evlist.c | 49 +---
tools/perf/util/evlist.h | 12
2 files changed, 50 insertions(+), 11 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 7228596..7000fe2 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -41,10 +41,12 @@ void perf_evlist__init(struct perf_evlist *evlist, struct
cpu_map *cpus,
for (i = 0; i < PERF_EVLIST__HLIST_SIZE; ++i)
INIT_HLIST_HEAD(&evlist->heads[i]);
INIT_LIST_HEAD(&evlist->entries);
+ INIT_LIST_HEAD(&evlist->children);
perf_evlist__set_maps(evlist, cpus, threads);
fdarray__init(&evlist->pollfd, 64);
evlist->workload.pid = -1;
evlist->backward = false;
+ evlist->parent = evlist;
}
struct perf_evlist *perf_evlist__new(void)
@@ -490,13 +492,17 @@ static void perf_evlist__munmap_filtered(struct fdarray
*fda, int fd,
void *arg __maybe_unused)
{
struct perf_evlist *evlist = container_of(fda, struct perf_evlist,
pollfd);
+ struct perf_evlist *child;
perf_evlist__mmap_put(evlist, fda->priv[fd].idx);
+ list_for_each_entry(child, &evlist->children, list)
+ perf_evlist__mmap_put(child, fda->priv[fd].idx);
+
}
int perf_evlist__filter_pollfd(struct perf_evlist *evlist, short
revents_and_mask)
{
- return fdarray__filter(&evlist->pollfd, revents_and_mask,
+ return fdarray__filter(&evlist->parent->pollfd, revents_and_mask,
perf_evlist__munmap_filtered, NULL);
}
@@ -1015,7 +1021,7 @@ static int perf_evlist__mmap_per_evsel(struct perf_evlist
*evlist, int idx,
struct perf_evsel *evsel;
int revent;
- evlist__for_each_entry(evlist, evsel) {
+ evlist__for_each_entry(evlist->parent, evsel) {
int fd;
if (!!evsel->attr.write_backward != (evlist->overwrite &&
evlist->backward))
@@ -1047,16 +1053,16 @@ static int perf_evlist__mmap_per_evsel(struct
perf_evlist *evlist, int idx,
* Therefore don't add it for polling.
*/
if (!evsel->system_wide &&
- __perf_evlist__add_pollfd(evlist, fd, idx, revent) < 0) {
+ __perf_evlist__add_pollfd(evlist->parent, fd, idx, revent)
< 0) {
perf_evlist__mmap_put(evlist, idx);
return -1;
}
if (evsel->attr.read_format & PERF_FORMAT_ID) {
- if (perf_evlist__id_add_fd(evlist, evsel, cpu, thread,
+ if (perf_evlist__id_add_fd(evlist->parent, evsel, cpu,
thread,
fd) < 0)
return -1;
- perf_evlist__set_sid_idx(evlist, evsel, idx, cpu,
+ perf_evlist__set_sid_idx(evlist->parent, evsel, idx,
cpu,
thread);
}
}
@@ -1097,13 +1103,13 @@ static int perf_evlist__mmap_per_thread(struct
perf_evlist *evlist,
struct mmap_params *mp)
{
int thread;
- int nr_threads = thread_map__nr(evlist->threads);
+ int nr_threads = thread_map__nr(evlist->parent->threads);
pr_debug2("perf event ring buffer mmapped per thread\n");
for (thread = 0; thread < nr_threads; thread++) {
int output = -1;
-
Re: [PATCH v2 2/5] usb: DT binding documentation for qoriq usb 2.0 controller
On Sat, Jul 09, 2016 at 10:00:53AM +0530, Rajesh Bhagat wrote:
> Describes the qoriq usb 2.0 controller driver binding, currently used
> for LS1021A and LS1012A platform.
>
> Signed-off-by: Rajesh Bhagat
> ---
> Changes in v2:
> - Adds DT binding documentation for qoriq usb 2.0 controller
> - Changed the compatible string to fsl,ci-qoriq-usb2
>
> .../devicetree/bindings/usb/ci-hdrc-qoriq.txt | 34
> ++
> 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
> b/Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
> new file mode 100644
> index 000..8ad7306
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
> @@ -0,0 +1,34 @@
> +* Freescale QorIQ SoC USB 2.0 Controllers
> +
> +Required properties:
> +- compatible: Should be "fsl,ci-qoriq-usb2"
> + Wherever applicable, the IP version of the USB controller should
> + also be mentioned (for eg. fsl,ci-qoriq-usb2-vX.Y).
> + where, X.Y is IP version of USB controller.
Why you need to add IP version at compatible string?
Does it can't be read out from ID register of Identification Registers.
> +- reg: Should contain registers location and length
> +- interrupts: Should contain controller interrupt
> +- phy-names: from the *Generic PHY* bindings
> +- phys: from the *Generic PHY* bindings
> +- clocks: clock provider specifier
> +- clock-names: shall be "usb2-clock"
> +Refer to clk/clock-bindings.txt for generic clock consumer properties
> +
> +Recommended properties:
> +- dr_mode: One of "host" or "peripheral".
Do you support dual-role?
> +- phy_type: the type of the phy connected to the core. Should be one
> + of "utmi", "utmi_wide", "ulpi", "serial" or "hsic". Without this
> + property the PORTSC register won't be touched
> +
> +Examples:
> +usb@860 {
> + compatible = "fsl,ci-qoriq-usb2",
> + "fsl,ci-qoriq-usb2-v2.5";
> + reg = <0x0 0x860 0x0 0x1000>;
> + interrupts = <0 139 0x4>;
> + phy-names = "usb2-phy";
> + phys = <&usbphy0>;
> + clock-names = "usb2-clock";
> + clocks = <&clockgen 4 3>;
> + dr_mode = "host";
> + phy_type = "ulpi";
> +};
> --
> 2.6.2.198.g614a2ac
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
linux-next: manual merge of the pwm tree with the regulator tree
Hi Thierry,
Today's linux-next merge of the pwm tree got a conflict in:
drivers/regulator/pwm-regulator.c
between commit:
830583004e61 ("regulator: pwm: Drop unneeded pwm_enable() call")
27bfa8893b15 ("regulator: pwm: Support for enable GPIO")
c2588393e631 ("regulator: pwm: Fix regulator ramp delay for continuous mode")
from the regulator tree and commit:
b0303deaa480 ("regulator: pwm: Adjust PWM config at probe time")
8bd57ca236d0 ("regulator: pwm: Switch to the atomic PWM API")
25d16595935b ("regulator: pwm: Retrieve correct voltage")
53f239af4c14 ("regulator: pwm: Support extra continuous mode cases")
from the pwm tree.
I fixed it up (I think, please check - see below) and can carry the fix
as necessary. This is now fixed as far as linux-next is concerned, but
any non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/regulator/pwm-regulator.c
index 666bc3bb52ef,a8e9147dd8db..
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@@ -20,8 -20,13 +20,14 @@@
#include
#include
#include
+#include
+ struct pwm_continuous_reg_data {
+ unsigned int min_uV_dutycycle;
+ unsigned int max_uV_dutycycle;
+ unsigned int dutycycle_unit;
+ };
+
struct pwm_regulator_data {
/* Shared */
struct pwm_device *pwm;
@@@ -36,12 -44,6 +45,9 @@@
struct regulator_ops ops;
int state;
+
- /* Continuous voltage */
- int volt_uV;
-
+ /* Enable GPIO */
+ struct gpio_desc *enb_gpio;
};
struct pwm_voltages {
@@@ -134,53 -174,59 +187,58 @@@ static int pwm_regulator_get_voltage(st
}
static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
- int min_uV, int max_uV,
- unsigned *selector)
+int req_min_uV, int req_max_uV,
+unsigned int *selector)
{
struct pwm_regulator_data *drvdata = rdev_get_drvdata(rdev);
+ unsigned int min_uV_duty = drvdata->continuous.min_uV_dutycycle;
+ unsigned int max_uV_duty = drvdata->continuous.max_uV_dutycycle;
+ unsigned int duty_unit = drvdata->continuous.dutycycle_unit;
unsigned int ramp_delay = rdev->constraints->ramp_delay;
- struct pwm_args pargs;
- unsigned int req_diff = min_uV - rdev->constraints->min_uV;
- unsigned int diff;
- unsigned int duty_pulse;
- u64 req_period;
- u32 rem;
+ int min_uV = rdev->constraints->min_uV;
+ int max_uV = rdev->constraints->max_uV;
+ int diff_uV = max_uV - min_uV;
+ struct pwm_state pstate;
+ unsigned int diff_duty;
+ unsigned int dutycycle;
+ int old_uV = pwm_regulator_get_voltage(rdev);
int ret;
- pwm_get_args(drvdata->pwm, &pargs);
- diff = rdev->constraints->max_uV - rdev->constraints->min_uV;
+ pwm_init_state(drvdata->pwm, &pstate);
- /* First try to find out if we get the iduty cycle time which is
-* factor of PWM period time. If (request_diff_to_min * pwm_period)
-* is perfect divided by voltage_range_diff then it is possible to
-* get duty cycle time which is factor of PWM period. This will help
-* to get output voltage nearer to requested value as there is no
-* calculation loss.
+ /*
+* The dutycycle for min_uV might be greater than the one for max_uV.
+* This is happening when the user needs an inversed polarity, but the
+* PWM device does not support inversing it in hardware.
*/
- req_period = req_diff * pargs.period;
- div_u64_rem(req_period, diff, &rem);
- if (!rem) {
- do_div(req_period, diff);
- duty_pulse = (unsigned int)req_period;
- } else {
- duty_pulse = (pargs.period / 100) * ((req_diff * 100) / diff);
- }
+ if (max_uV_duty < min_uV_duty)
+ diff_duty = min_uV_duty - max_uV_duty;
+ else
+ diff_duty = max_uV_duty - min_uV_duty;
+
+ dutycycle = DIV_ROUND_CLOSEST_ULL((u64)(req_min_uV - min_uV) *
+ diff_duty,
+ diff_uV);
+
+ if (max_uV_duty < min_uV_duty)
+ dutycycle = min_uV_duty - dutycycle;
+ else
+ dutycycle = min_uV_duty + dutycycle;
+
+ pwm_set_relative_duty_cycle(&pstate, dutycycle, duty_unit);
- ret = pwm_config(drvdata->pwm, duty_pulse, pargs.period);
+ ret = pwm_apply_state(drvdata->pwm, &pstate);
if (ret) {
dev_err(&rdev->dev, "Failed to configure PWM: %d\n", ret);
[PATCH v15 6/8] perf tools: Enable overwrite settings
This patch allows following config terms and option:
Globally setting events to overwrite;
# perf record --overwrite ...
Set specific events to be overwrite or no-overwrite.
# perf record --event cycles/overwrite/ ...
# perf record --event cycles/no-overwrite/ ...
Add missing config terms and update config term array size because the
longest string length is changed.
For overwritable events, automatically select attr.write_backward since
perf requires it to be backward for reading.
Test result:
# perf record --overwrite -e syscalls:*enter_nanosleep* usleep 1
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 0.011 MB perf.data (1 samples) ]
# perf evlist -v
syscalls:sys_enter_nanosleep: type: 2, size: 112, config: 0x134, {
sample_period, sample_freq }: 1, sample_type: IP|TID|TIME|CPU|PERIOD|RAW,
disabled: 1, inherit: 1, mmap: 1, comm: 1, enable_on_exec: 1, task: 1,
sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, write_backward: 1
# Tip: use 'perf evlist --trace-fields' to show fields for tracepoint events
Signed-off-by: Wang Nan
Signed-off-by: He Kuang
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: Nilay Vaish
Cc: pi3or...@163.com
---
tools/perf/Documentation/perf-record.txt | 14 ++
tools/perf/builtin-record.c | 1 +
tools/perf/perf.h| 1 +
tools/perf/tests/backward-ring-buffer.c | 14 ++
tools/perf/util/evsel.c | 4
tools/perf/util/evsel.h | 2 ++
tools/perf/util/parse-events.c | 20 ++--
tools/perf/util/parse-events.h | 2 ++
tools/perf/util/parse-events.l | 2 ++
9 files changed, 50 insertions(+), 10 deletions(-)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 5b46b1d..384c630 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -367,6 +367,20 @@ options.
'perf record --dry-run -e' can act as a BPF script compiler if llvm.dump-obj
in config file is set to true.
+--overwrite::
+Makes all events use an overwritable ring buffer. An overwritable ring
+buffer works like a flight recorder: when it gets full, the kernel will
+overwrite the oldest records, that thus will never make it to the
+perf.data file.
+
+When '--overwrite' and '--switch-output' are used perf records and drops
+events until it receives a signal, meaning that something unusual was
+detected that warrants taking a snapshot of the most current events,
+those fitting in the ring buffer at that moment.
+
+'overwrite' attribute can also be set or canceled for an event using
+config terms. For example: 'cycles/overwrite/' and
'instructions/no-overwrite/'.
+
SEE ALSO
linkperf:perf-stat[1], linkperf:perf-list[1]
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 005a121..3af9c15 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1554,6 +1554,7 @@ struct option __record_options[] = {
OPT_BOOLEAN_SET('i', "no-inherit", &record.opts.no_inherit,
&record.opts.no_inherit_set,
"child tasks do not inherit counters"),
+ OPT_BOOLEAN(0, "overwrite", &record.opts.overwrite, "use overwrite
mode"),
OPT_UINTEGER('F', "freq", &record.opts.user_freq, "profile at this
frequency"),
OPT_CALLBACK('m', "mmap-pages", &record.opts, "pages[,pages]",
"number of mmap data pages and AUX area tracing mmap
pages",
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index cd8f1b1..608b42b 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -59,6 +59,7 @@ struct record_opts {
bool record_switch_events;
bool all_kernel;
bool all_user;
+ bool overwrite;
unsigned int freq;
unsigned int mmap_pages;
unsigned int auxtrace_mmap_pages;
diff --git a/tools/perf/tests/backward-ring-buffer.c
b/tools/perf/tests/backward-ring-buffer.c
index 2e66c48..8368f03 100644
--- a/tools/perf/tests/backward-ring-buffer.c
+++ b/tools/perf/tests/backward-ring-buffer.c
@@ -150,26 +150,24 @@ int test__backward_ring_buffer(int subtest __maybe_unused)
}
bzero(&parse_error, sizeof(parse_error));
- err = parse_events(evlist, "syscalls:sys_enter_prctl", &parse_error);
+ /*
+* Set backward bit, ring buffer should be writing from end. Record
+* it in aux evlist
+*/
+ err = parse_events(evlist, "syscalls:sys_enter_prctl/overwrite/",
&parse_error);
if (err) {
pr_debug("Failed to parse tracepoint event, try use root\n");
ret = TEST_SKIP;
goto out_delete_evlist;
}
- /*
-* Set backward bit, ring buffer should be writing from end. Record
-
[PATCH v15 7/8] perf tools: Don't warn about out of order event if write_backward is used
If write_backward attribute is set, records are written into kernel
ring buffer from end to beginning, but read from beginning to end.
To avoid 'XX out of order events recorded' warning message (timestamps
of records is in reverse order when using write_backward), suppress the
warning message if write_backward is selected by at lease one event.
Result:
Before this patch:
# perf record -m 1 -e raw_syscalls:sys_exit/overwrite/ \
-e raw_syscalls:sys_enter \
dd if=/dev/zero of=/dev/null count=300
300+0 records in
300+0 records out
153600 bytes (154 kB) copied, 0.000601617 s, 255 MB/s
[ perf record: Woken up 5 times to write data ]
Warning:
40 out of order events recorded.
[ perf record: Captured and wrote 0.096 MB perf.data (696 samples) ]
After this patch:
# perf record -m 1 -e raw_syscalls:sys_exit/overwrite/ \
-e raw_syscalls:sys_enter \
dd if=/dev/zero of=/dev/null count=300
300+0 records in
300+0 records out
153600 bytes (154 kB) copied, 0.000644873 s, 238 MB/s
[ perf record: Woken up 5 times to write data ]
[ perf record: Captured and wrote 0.096 MB perf.data (696 samples) ]
Signed-off-by: Wang Nan
Signed-off-by: He Kuang
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: Nilay Vaish
Cc: pi3or...@163.com
---
tools/perf/util/session.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 078d496..5d61242 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1499,10 +1499,27 @@ int perf_session__register_idle_thread(struct
perf_session *session)
return err;
}
+static void
+perf_session__warn_order(const struct perf_session *session)
+{
+ const struct ordered_events *oe = &session->ordered_events;
+ struct perf_evsel *evsel;
+ bool should_warn = true;
+
+ evlist__for_each_entry(session->evlist, evsel) {
+ if (evsel->attr.write_backward)
+ should_warn = false;
+ }
+
+ if (!should_warn)
+ return;
+ if (oe->nr_unordered_events != 0)
+ ui__warning("%u out of order events recorded.\n",
oe->nr_unordered_events);
+}
+
static void perf_session__warn_about_errors(const struct perf_session *session)
{
const struct events_stats *stats = &session->evlist->stats;
- const struct ordered_events *oe = &session->ordered_events;
if (session->tool->lost == perf_event__process_lost &&
stats->nr_events[PERF_RECORD_LOST] != 0) {
@@ -1559,8 +1576,7 @@ static void perf_session__warn_about_errors(const struct
perf_session *session)
stats->nr_unprocessable_samples);
}
- if (oe->nr_unordered_events != 0)
- ui__warning("%u out of order events recorded.\n",
oe->nr_unordered_events);
+ perf_session__warn_order(session);
events_stats__auxtrace_error_warn(stats);
--
1.8.3.4
[PATCH v15 4/8] perf record: Introduce rec->overwrite_evlist for overwritable events
Create an auxiliary evlist for overwritable events.
Before mmap, build this evlist and set 'overwrite' and 'backward'
attribute. Since perf_evlist__mmap_ex() only maps events when
evsel->overwrite matches evlist's corresponding attributes, with
these two evlists an event goes to either rec->evlist or
rec->overwrite_evlist.
Signed-off-by: Wang Nan
Cc: He Kuang
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: Nilay Vaish
Cc: pi3or...@163.com
---
tools/perf/builtin-record.c | 54 +
1 file changed, 50 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index b2b3b60..ec1f90c 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -51,6 +51,7 @@ struct record {
struct perf_data_file file;
struct auxtrace_record *itr;
struct perf_evlist *evlist;
+ struct perf_evlist *overwrite_evlist;
struct perf_session *session;
const char *progname;
int realtime_prio;
@@ -342,13 +343,41 @@ int auxtrace_record__snapshot_start(struct
auxtrace_record *itr __maybe_unused)
#endif
+static int record__create_overwrite_evlist(struct record *rec)
+{
+ struct perf_evlist *evlist = rec->evlist;
+ struct perf_evsel *pos;
+
+ evlist__for_each_entry(evlist, pos) {
+ if (!pos->attr.write_backward)
+ continue;
+
+ if (!rec->overwrite_evlist) {
+ rec->overwrite_evlist = perf_evlist__new_aux(evlist);
+ if (rec->overwrite_evlist) {
+ rec->overwrite_evlist->backward = true;
+ rec->overwrite_evlist->overwrite = true;
+ return 0;
+ } else
+ return -ENOMEM;
+ }
+ }
+ return 0;
+}
+
static int record__mmap_evlist(struct record *rec,
- struct perf_evlist *evlist)
+ struct perf_evlist *evlist,
+ bool overwrite)
{
struct record_opts *opts = &rec->opts;
char msg[512];
- if (perf_evlist__mmap_ex(evlist, opts->mmap_pages, false,
+ /*
+* Don't use evlist->overwrite because it is logically an
+* internal attribute and is set by perf_evlist__mmap_ex().
+* Avoid circular dependency.
+*/
+ if (perf_evlist__mmap_ex(evlist, opts->mmap_pages, overwrite,
opts->auxtrace_mmap_pages,
opts->auxtrace_snapshot_mode) < 0) {
if (errno == EPERM) {
@@ -373,7 +402,20 @@ static int record__mmap_evlist(struct record *rec,
static int record__mmap(struct record *rec)
{
- return record__mmap_evlist(rec, rec->evlist);
+ int err;
+
+ err = record__create_overwrite_evlist(rec);
+ if (err)
+ return err;
+
+ err = record__mmap_evlist(rec, rec->evlist, false);
+ if (err)
+ return err;
+
+ if (!rec->overwrite_evlist)
+ return 0;
+
+ return record__mmap_evlist(rec, rec->overwrite_evlist, true);
}
static int record__open(struct record *rec)
@@ -698,10 +740,11 @@ static const struct perf_event_mmap_page
*record__pick_pc(struct record *rec)
{
const struct perf_event_mmap_page *pc;
+ /* Change it to a loop if a new aux evlist is added */
pc = perf_evlist__pick_pc(rec->evlist);
if (pc)
return pc;
- return NULL;
+ return perf_evlist__pick_pc(rec->overwrite_evlist);
}
static int record__synthesize(struct record *rec)
@@ -1311,6 +1354,7 @@ static struct record record = {
.mmap2 = perf_event__process_mmap2,
.ordered_events = true,
},
+ .overwrite_evlist = NULL,
};
const char record_callchain_help[] = CALLCHAIN_RECORD_HELP
@@ -1614,6 +1658,8 @@ int cmd_record(int argc, const char **argv, const char
*prefix __maybe_unused)
err = __cmd_record(&record, argc, argv);
out_symbol_exit:
perf_evlist__delete(rec->evlist);
+ if (rec->overwrite_evlist)
+ perf_evlist__delete(rec->overwrite_evlist);
symbol__exit();
auxtrace_record__free(rec->itr);
return err;
--
1.8.3.4
[PATCH v15 3/8] perf tests: Add testcase for auxiliary evlist
Improve test backward-ring-buffer, trace both enter and exit event of
prctl() syscall, utilize auxiliary evlist to mmap enter and exit event
into separated mmaps.
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: Nilay Vaish
Cc: He Kuang
---
tools/perf/tests/backward-ring-buffer.c | 103 ++--
1 file changed, 84 insertions(+), 19 deletions(-)
diff --git a/tools/perf/tests/backward-ring-buffer.c
b/tools/perf/tests/backward-ring-buffer.c
index 1750ef2..2e66c48 100644
--- a/tools/perf/tests/backward-ring-buffer.c
+++ b/tools/perf/tests/backward-ring-buffer.c
@@ -23,16 +23,34 @@ static void testcase(void)
}
}
+static void perf_evlist__mmap_read_catchup_all(struct perf_evlist *evlist)
+{
+ int i;
+
+ for (i = 0; i < evlist->nr_mmaps; i++)
+ perf_evlist__mmap_read_catchup(evlist, i);
+}
+
static int count_samples(struct perf_evlist *evlist, int *sample_count,
int *comm_count)
{
int i;
+ union perf_event *(*reader)(struct perf_evlist *, int);
+
+ if (evlist->backward)
+ reader = perf_evlist__mmap_read_backward;
+ else
+ reader = perf_evlist__mmap_read_forward;
for (i = 0; i < evlist->nr_mmaps; i++) {
union perf_event *event;
- perf_evlist__mmap_read_catchup(evlist, i);
- while ((event = perf_evlist__mmap_read_backward(evlist, i)) !=
NULL) {
+ /*
+* Before calling count_samples(), ring buffers in backward
+* evlist should have catched up with newest record
+* using perf_evlist__mmap_read_catchup_all().
+*/
+ while ((event = (*reader)(evlist, i)) != NULL) {
const u32 type = event->header.type;
switch (type) {
@@ -51,34 +69,57 @@ static int count_samples(struct perf_evlist *evlist, int
*sample_count,
return TEST_OK;
}
-static int do_test(struct perf_evlist *evlist, int mmap_pages,
- int *sample_count, int *comm_count)
+struct test_result {
+ int sys_enter;
+ int sys_exit;
+ int comm;
+};
+
+static int do_test(struct perf_evlist *evlist,
+ struct perf_evlist *aux_evlist,
+ int mmap_pages,
+ struct test_result *res)
{
int err;
char sbuf[STRERR_BUFSIZE];
- err = perf_evlist__mmap(evlist, mmap_pages, true);
+ err = perf_evlist__mmap(evlist, mmap_pages, false);
if (err < 0) {
pr_debug("perf_evlist__mmap: %s\n",
strerror_r(errno, sbuf, sizeof(sbuf)));
return TEST_FAIL;
}
+ err = perf_evlist__mmap(aux_evlist, mmap_pages, true);
+ if (err < 0) {
+ pr_debug("perf_evlist__mmap for aux_evlist: %s\n",
+strerror_r(errno, sbuf, sizeof(sbuf)));
+ return TEST_FAIL;
+ }
+
perf_evlist__enable(evlist);
testcase();
perf_evlist__disable(evlist);
- err = count_samples(evlist, sample_count, comm_count);
+ perf_evlist__mmap_read_catchup_all(aux_evlist);
+ err = count_samples(aux_evlist, &res->sys_exit, &res->comm);
+ if (err)
+ goto errout;
+ err = count_samples(evlist, &res->sys_enter, &res->comm);
+ if (err)
+ goto errout;
+errout:
perf_evlist__munmap(evlist);
+ perf_evlist__munmap(aux_evlist);
return err;
}
int test__backward_ring_buffer(int subtest __maybe_unused)
{
- int ret = TEST_SKIP, err, sample_count = 0, comm_count = 0;
+ int ret = TEST_SKIP, err;
char pid[16], sbuf[STRERR_BUFSIZE];
- struct perf_evlist *evlist;
+ struct perf_evlist *evlist, *aux_evlist = NULL;
struct perf_evsel *evsel __maybe_unused;
struct parse_events_error parse_error;
struct record_opts opts = {
@@ -90,6 +131,7 @@ int test__backward_ring_buffer(int subtest __maybe_unused)
.mmap_pages = 256,
.default_interval = 1,
};
+ struct test_result res = {0, 0, 0};
snprintf(pid, sizeof(pid), "%d", getpid());
pid[sizeof(pid) - 1] = '\0';
@@ -101,7 +143,6 @@ int test__backward_ring_buffer(int subtest __maybe_unused)
return TEST_FAIL;
}
- evlist->backward = true;
err = perf_evlist__create_maps(evlist, &opts.target);
if (err < 0) {
pr_debug("Not enough memory to create thread/cpu maps\n");
@@ -116,11 +157,21 @@ int test__backward_ring_buffer(int subtest __maybe_unused)
goto out_delete_evlist;
}
- perf_evlist__config(evlist, &opts, NULL);
+ /*
+* Set backward bit, ring buffer should be writing from end. Record
+* it in aux evlist
+
[PATCH v15 1/8] perf tools: Drop redundant evsel->overwrite indicator
From: Arnaldo Carvalho de Melo
evsel->overwrite indicator means an event should be put into
overwritable ring buffer. In current implementation, it equals to
evsel->attr.write_backward. To reduce compliexity, remove
evsel->overwrite, use evsel->attr.write_backward instead.
In addition, in __perf_evsel__open(), if kernel doesn't support
write_backward and user explicitly set it in evsel, don't fallback
like other missing feature, since it is meaningless to fall back to
a forward ring buffer in this case: we are unable to stably read
from an forward overwritable ring buffer.
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Wang Nan
Cc: He Kuang
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: Nilay Vaish
Cc: pi3or...@163.com
---
tools/perf/tests/backward-ring-buffer.c | 1 +
tools/perf/util/evlist.c| 4 ++--
tools/perf/util/evsel.c | 12 +---
tools/perf/util/evsel.h | 1 -
4 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/tools/perf/tests/backward-ring-buffer.c
b/tools/perf/tests/backward-ring-buffer.c
index e70313f..1750ef2 100644
--- a/tools/perf/tests/backward-ring-buffer.c
+++ b/tools/perf/tests/backward-ring-buffer.c
@@ -101,6 +101,7 @@ int test__backward_ring_buffer(int subtest __maybe_unused)
return TEST_FAIL;
}
+ evlist->backward = true;
err = perf_evlist__create_maps(evlist, &opts.target);
if (err < 0) {
pr_debug("Not enough memory to create thread/cpu maps\n");
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 1135077..7228596 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1003,7 +1003,7 @@ static bool
perf_evlist__should_poll(struct perf_evlist *evlist __maybe_unused,
struct perf_evsel *evsel)
{
- if (evsel->overwrite)
+ if (evsel->attr.write_backward)
return false;
return true;
}
@@ -1018,7 +1018,7 @@ static int perf_evlist__mmap_per_evsel(struct perf_evlist
*evlist, int idx,
evlist__for_each_entry(evlist, evsel) {
int fd;
- if (evsel->overwrite != (evlist->overwrite && evlist->backward))
+ if (!!evsel->attr.write_backward != (evlist->overwrite &&
evlist->backward))
continue;
if (evsel->system_wide && thread)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 0fea724..3abe519 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1359,6 +1359,9 @@ static int __perf_evsel__open(struct perf_evsel *evsel,
struct cpu_map *cpus,
int pid = -1, err;
enum { NO_CHANGE, SET_TO_MAX, INCREASED_MAX } set_rlimit = NO_CHANGE;
+ if (perf_missing_features.write_backward && evsel->attr.write_backward)
+ return -EINVAL;
+
if (evsel->system_wide)
nthreads = 1;
else
@@ -1389,11 +1392,6 @@ fallback_missing_features:
if (perf_missing_features.lbr_flags)
evsel->attr.branch_sample_type &= ~(PERF_SAMPLE_BRANCH_NO_FLAGS
|
PERF_SAMPLE_BRANCH_NO_CYCLES);
- if (perf_missing_features.write_backward) {
- if (evsel->overwrite)
- return -EINVAL;
- evsel->attr.write_backward = false;
- }
retry_sample_id:
if (perf_missing_features.sample_id_all)
evsel->attr.sample_id_all = 0;
@@ -1495,7 +1493,7 @@ try_fallback:
*/
if (!perf_missing_features.write_backward &&
evsel->attr.write_backward) {
perf_missing_features.write_backward = true;
- goto fallback_missing_features;
+ goto out_close;
} else if (!perf_missing_features.clockid_wrong &&
evsel->attr.use_clockid) {
perf_missing_features.clockid_wrong = true;
goto fallback_missing_features;
@@ -2404,7 +2402,7 @@ int perf_evsel__open_strerror(struct perf_evsel *evsel,
struct target *target,
"We found oprofile daemon running, please stop it and try again.");
break;
case EINVAL:
- if (evsel->overwrite && perf_missing_features.write_backward)
+ if (evsel->attr.write_backward &&
perf_missing_features.write_backward)
return scnprintf(msg, size, "Reading from overwrite
event is not supported by this kernel.");
if (perf_missing_features.clockid)
return scnprintf(msg, size, "clockid feature not
supported.");
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 86fed7a..a31ee2d 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -114,7 +114,6 @@ struct perf_evsel {
booltracking;
boolper_pkg;
boolprecise_max;
- bool
[PATCH v15 5/8] perf record: Read from overwritable ring buffer
overwrite_evt_state is introduced to reflect the state of overwritable
ring buffers. It is a state machine with following states:
.(forbid)_.
| V
NOTREADY -(0)-> RUNNING --(1)--> DATA_PENDING --(2)--> EMPTY
^ ^ | ^ |
| |__(forbid)/ |___(forbid)___/|
| |
\_(3)___/
NOTREADY : Overwritable evlist is not ready
RUNNING : Overwritable ring buffers are recording
DATA_PENDING : We are required to collect overwritable ring buffers
EMPTY: We have collected data from those ring buffers.
(0): Create overwritable evlist
(1): Pause ring buffers for reading
(2): Read from ring buffers
(3): Resume ring buffers for recording
We can't avoid this complexity. Since we deliberately drop records from
overwritable ring buffer, there's no way for us to check remaining from
ring buffer itself (by checking head and old pointers). Therefore, we
need DATA_PENDING and EMPTY state to help us recording what we have done
to the ring buffer.
With the above state machine, this patch improves record__mmap_read_all(),
read from overwritable ring buffer when DATA_PENDING state is observed.
Since the above state machine governs overwritable ring buffer only, if
there's no such ring buffer, it should stop.
Signed-off-by: Wang Nan
Signed-off-by: He Kuang
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: Nilay Vaish
Cc: pi3or...@163.com
---
tools/perf/builtin-record.c | 158 +++-
1 file changed, 157 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index ec1f90c..005a121 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -43,6 +43,33 @@
#include
#include
+/*
+ * State machine of overwrite_evt_state:
+ *
+ * .(forbid)_.
+ * | V
+ * NOTREADY -(0)-> RUNNING --(1)--> DATA_PENDING --(2)--> EMPTY
+ * ^ ^ | ^ |
+ * | |__(forbid)/ |___(forbid)___/|
+ * | |
+ *\_(3)___/
+ *
+ * NOTREADY : Overwritable evlist is not ready
+ * RUNNING : Overwritable ring buffers are recording
+ * DATA_PENDING : We are required to collect overwritable ring buffers
+ * EMPTY: We have collected data from those ring buffers.
+ *
+ * (0): Create overwritable evlist
+ * (1): Pause ring buffers for reading
+ * (2): Read from ring buffers
+ * (3): Resume ring buffers for recording
+ */
+enum overwrite_evt_state {
+ OVERWRITE_EVT_NOTREADY,
+ OVERWRITE_EVT_RUNNING,
+ OVERWRITE_EVT_DATA_PENDING,
+ OVERWRITE_EVT_EMPTY,
+};
struct record {
struct perf_tooltool;
@@ -62,6 +89,7 @@ struct record {
boolbuildid_all;
booltimestamp_filename;
boolswitch_output;
+ enum overwrite_evt_state overwrite_evt_state;
unsigned long long samples;
};
@@ -343,6 +371,96 @@ int auxtrace_record__snapshot_start(struct auxtrace_record
*itr __maybe_unused)
#endif
+static void
+record__toggle_overwrite_evlist(struct record *rec,
+ enum overwrite_evt_state state)
+{
+ struct perf_evlist *evlist = rec->overwrite_evlist;
+ enum overwrite_evt_state old_state = rec->overwrite_evt_state;
+ enum action {
+ NONE,
+ PAUSE,
+ RESUME,
+ } action = NONE;
+
+ if (!evlist)
+ return;
+
+ switch (old_state) {
+ case OVERWRITE_EVT_RUNNING: {
+ switch (state) {
+ case OVERWRITE_EVT_DATA_PENDING:
+ action = PAUSE;
+ break;
+ case OVERWRITE_EVT_RUNNING:
+ case OVERWRITE_EVT_EMPTY:
+ case OVERWRITE_EVT_NOTREADY:
+ default:
+ goto state_err;
+ }
+ break;
+ }
+ case OVERWRITE_EVT_DATA_PENDING: {
+ switch (state) {
+ case OVERWRITE_EVT_EMPTY:
+ break;
+ case OVERWRITE_EVT_RUNNING:
+ case OVERWRITE_EVT_DATA_PENDING:
+ case OVERWRITE_EVT_NOTREADY:
+ default:
+ goto state_err;
+ }
+ break;
+ }
+ case OVERWRITE_EVT_EMPTY: {
+ switch (state) {
+ case OVERWRITE_EVT_RUNNING:
+ action = RESUME;
+
[PATCH v15 0/8] perf tools: Support overwritable ring buffer
This patch set enables daemonized perf recording by utilizing
overwritable backward ring buffer. With this feature one can
put perf background, and dump ring buffer records by a SIGUSR2
when he/she find something unusual. For example, following
command record system calls, schedule events and samples on cpu cycles
continously:
# perf record -g -e cycles -e raw_syscalls:*/call-graph=no/ \
-e sched:sched_switch/call-graph=no/ \
--switch-output --overwrite -a
Then by sending SIGUSR2 to perf when lagging is happen, we get multiple
perf.data output, each of them correspond a abnormal event, and the data
size is reasonable:
# ls -l ./perf.data*
-rw--- 1 root root 5122165 May 13 23:51 ./perf.data.2016051323511683
-rw--- 1 root root 5135093 May 13 23:51 ./perf.data.2016051323512107
-rw--- 1 root root 5135213 May 13 23:51 ./perf.data.2016051323512215
-rw--- 1 root root 5135157 May 13 23:51 ./perf.data.2016051323512387
v1 -> v2: Totally redesign: drop the principle of 'channal', use
auxiliary evlist instead. Fix missing documentation.
v2 -> v3: Rename perf_evlist__toggle_paused() to perf_evlist__pause/resume.
v3 -> v4: Update commit message to describe auxiliary evlist more clearly.
v4 -> v5: Reorder commits, ensure '--overwrite' works right after perf
support the option.
Add test cases for auxiliary evlist.
Avoid bug if main evlist is empty.
v5 -> v6: Improve filter pollfd related code.
v6 -> v7: Rebase to newest perf/core.
v7 -> v8: Unmap mmaps from parent and children in
perf_evlist__munmap_filtered(), hide more detail of aux evlist.
Add --tail-synthesize, do synthesize at the end of perf.data.
v8 -> v9: Beautify code of test case, make patch set more granular,
improve documentation.
v9 -> v10: Make patch set more granular: extract preparation code to
patch 1-3.
v10 -> v11: Rebase to newest perf/core: solve conflicts caused by commit
e5cadb93d08 ("perf evlist: Rename for_each() macros to
for_each_entry()").
v11 -> v12: Improve 'perf test backward': skip this test on old kernel,
resolve conflicts.
v12 -> v13: Drop evsel->overwrite, use evsel->attr.write_backward instead.
v13 -> v14: Follow Jiri Olsa's suggestion: Improve commit message,
add OVERWRITE_EVT_NOTREADY state, stop the state machine if
overwrite_evlist is not generated.
v14 -> v15: Follow Jiri Olsa's suggestion: Improve test case; small code
adjustment.
Arnaldf Carvalho de Melo (1):
perf tools: Drop redundant evsel->overwrite indicator
Wang Nan (7):
perf evlist: Introduce aux evlist
perf tests: Add testcase for auxiliary evlist
perf record: Introduce rec->overwrite_evlist for overwritable events
perf record: Read from overwritable ring buffer
perf tools: Enable overwrite settings
perf tools: Don't warn about out of order event if write_backward is
used
perf tools: Add --tail-synthesize option
tools/perf/Documentation/perf-record.txt | 22 +++
tools/perf/builtin-record.c | 244 +--
tools/perf/perf.h| 2 +
tools/perf/tests/backward-ring-buffer.c | 102 ++---
tools/perf/util/evlist.c | 53 +--
tools/perf/util/evlist.h | 12 ++
tools/perf/util/evsel.c | 16 +-
tools/perf/util/evsel.h | 3 +-
tools/perf/util/parse-events.c | 20 ++-
tools/perf/util/parse-events.h | 2 +
tools/perf/util/parse-events.l | 2 +
tools/perf/util/session.c| 22 ++-
12 files changed, 444 insertions(+), 56 deletions(-)
--
1.8.3.4
Re: [PATCH v5 2/3] pwm: iproc: Add support for Broadcom iproc pwm controller
Hi Thierry, On Fri, Jul 8, 2016 at 8:46 PM, Thierry Reding wrote: > On Tue, Jul 05, 2016 at 02:00:25AM -0400, Yendapally Reddy Dhananjaya Reddy > wrote: >> Add support for the PWM controller present in Broadcom's iProc >> family of SoCs.It has been tested on the Northstar+ bcm958625HR board. >> >> Signed-off-by: Yendapally Reddy Dhananjaya Reddy >> >> --- >> drivers/pwm/Kconfig | 10 ++ >> drivers/pwm/Makefile| 1 + >> drivers/pwm/pwm-bcm-iproc.c | 268 >> >> 3 files changed, 279 insertions(+) >> create mode 100644 drivers/pwm/pwm-bcm-iproc.c > > I've applied this, but I had to make a couple of changes for coding > style and to squash compiler warnings. Please check the PWM tree's > for-next branch to see if it still works for you. > Thanks. It is working fine for me. A small change is required here, NSEC_PER_SEC instead of USEC_PER_SEC in two places. Thanks Dhananjay > Thierry
[PATCH v15 8/8] perf tools: Add --tail-synthesize option
When working with overwritable ring buffer there's a inconvenience
problem: if perf dumps data after a long period after it starts, non-sample
events may lost, which makes following 'perf report' unable to identify
proc name and mmap layout. For example:
# perf record -m 4 -e raw_syscalls:* -g --overwrite --switch-output \
dd if=/dev/zero of=/dev/null
send SIGUSR2 after dd runs long enough. The resuling perf.data lost
correct comm and mmap events:
# perf script -i perf.data.2016061522374354
perf 24478 [004] 2581325.601789: raw_syscalls:sys_exit: NR 0 = 512
Should be 'dd'
27b2e8 syscall_slow_exit_work+0xfe2000e3
(/lib/modules/4.6.0-rc3+/build/vmlinux)
203cc7 do_syscall_64+0xfe200117
(/lib/modules/4.6.0-rc3+/build/vmlinux)
b18d83 return_from_SYSCALL_64+0xfe20
(/lib/modules/4.6.0-rc3+/build/vmlinux)
7f47c417edf0 [unknown] ([unknown])
Fail to unwind
This patch provides a '--tail-synthesize' option, allows perf to collect
system status when finalizing output file. In resuling output file, the
non-sample events reflect system status when dumping data.
After this patch:
# perf record -m 4 -e raw_syscalls:* -g --overwrite --switch-output
--tail-synthesize \
dd if=/dev/zero of=/dev/null
# perf script -i perf.data.2016061600544998
dd 27364 [004] 2583244.994464: raw_syscalls:sys_enter: NR 1 (1, ...
^^
Correct comm
203a18 syscall_trace_enter_phase2+0xfe2001a8
([kernel.kallsyms])
203aa5 syscall_trace_enter+0xfe200055 ([kernel.kallsyms])
203caa do_syscall_64+0xfe2000fa ([kernel.kallsyms])
b18d83 return_from_SYSCALL_64+0xfe20 ([kernel.kallsyms])
d8e50 __GI___libc_write+0x01d9639f4010
(/tmp/oxygen_root-w00229757/lib64/libc-2.18.so)
^
Correct unwind
This option doesn't aim to solve this problem completely. If a process
terminates before SIGUSR2, we still lost its COMM and MMAP events. For
example, we can't unwind correctly from the final perf.data we get from
the previous example, because when perf collects the final output file
(when we press C-c), 'dd' has been terminated so its
'/proc//mmap' becomes empty. However, this is a cheaper choice. To
completely solve this problem we need to continously output non-sample
events. To satisify the requirement of daemonization, we need to merge
them periodically. It is possible but requires much more code and cycles.
Automatically select --tail-synthesize when --overwrite is provided.
Signed-off-by: Wang Nan
Cc: He Kuang
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: Nilay Vaish
Cc: pi3or...@163.com
---
tools/perf/Documentation/perf-record.txt | 8
tools/perf/builtin-record.c | 31 +--
tools/perf/perf.h| 1 +
3 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 384c630..69966ab 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -367,6 +367,12 @@ options.
'perf record --dry-run -e' can act as a BPF script compiler if llvm.dump-obj
in config file is set to true.
+--tail-synthesize::
+Instead of collecting non-sample events (for example, fork, comm, mmap) at
+the beginning of record, collect them during finalizing an output file.
+The collected non-sample events reflects the status of the system when
+record is finished.
+
--overwrite::
Makes all events use an overwritable ring buffer. An overwritable ring
buffer works like a flight recorder: when it gets full, the kernel will
@@ -381,6 +387,8 @@ those fitting in the ring buffer at that moment.
'overwrite' attribute can also be set or canceled for an event using
config terms. For example: 'cycles/overwrite/' and
'instructions/no-overwrite/'.
+Implies --tail-synthesize.
+
SEE ALSO
linkperf:perf-stat[1], linkperf:perf-list[1]
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 3af9c15..39cc8c7 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -760,13 +760,16 @@ record__finish_output(struct record *rec)
return;
}
-static int record__synthesize_workload(struct record *rec)
+static int record__synthesize_workload(struct record *rec, bool tail)
{
struct {
struct thread_map map;
struct thread_map_data map_data;
} thread_map;
+ if (rec->opts.tail_synthesize != tail)
+ return 0;
+
thread_map.map.nr = 1;
thread_map.map.map[0].pid = rec->evlist->workload.pid;
thread_map.map.map[0].comm = NULL;
@@ -777,7 +780,7 @@ static int record__synthesize_workload(struct record *rec)
Re: [PATCH v2 1/5] drivers: usb: chipidea: Add qoriq platform driver
On Sat, Jul 09, 2016 at 10:00:52AM +0530, Rajesh Bhagat wrote:
> Adds qoriq platform driver for chipidea controller,
> verfied on LS1021A and LS1012A platforms.
>
> Signed-off-by: Rajesh Bhagat
> ---
> Changes in v2:
> - Replaced Freescale with QorIQ in comments section
> - Added macros to remove hardcoding while programming registers
> - Changed the compatible string to fsl,ci-qoriq-usb2 and added version
> - Removed calls to devm free/release calls
>
> drivers/usb/chipidea/Makefile| 2 +
> drivers/usb/chipidea/ci_hdrc_qoriq.c | 237
> +++
> drivers/usb/chipidea/ci_hdrc_qoriq.h | 65 ++
> 3 files changed, 304 insertions(+)
> create mode 100644 drivers/usb/chipidea/ci_hdrc_qoriq.c
> create mode 100644 drivers/usb/chipidea/ci_hdrc_qoriq.h
>
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index 518e445..3122b86b 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -14,3 +14,5 @@ obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_zevio.o
> obj-$(CONFIG_USB_CHIPIDEA_PCI) += ci_hdrc_pci.o
>
> obj-$(CONFIG_USB_CHIPIDEA_OF)+= usbmisc_imx.o ci_hdrc_imx.o
> +
> +obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_qoriq.o
> diff --git a/drivers/usb/chipidea/ci_hdrc_qoriq.c
> b/drivers/usb/chipidea/ci_hdrc_qoriq.c
> new file mode 100644
> index 000..3f478c6
> --- /dev/null
> +++ b/drivers/usb/chipidea/ci_hdrc_qoriq.c
> @@ -0,0 +1,237 @@
> +/*
> + * QorIQ SoC USB 2.0 Controller driver
> + *
> + * Copyright 2016 Freescale Semiconductor, Inc.
> + * Author: Rajesh Bhagat
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "ci.h"
> +#include "ci_hdrc_qoriq.h"
> +
> +struct ci_hdrc_qoriq_data {
> + struct phy *phy;
> + struct clk *clk;
> + void __iomem *qoriq_regs;
> + struct platform_device *ci_pdev;
> + enum usb_phy_interface phy_mode;
> +};
> +
> +/*
> + * clock helper functions
> + */
> +static int ci_hdrc_qoriq_get_clks(struct platform_device *pdev)
> +{
> + int ret;
> + struct device *dev = &pdev->dev;
> + struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
> +
> + data->clk = devm_clk_get(dev, "usb2-clock");
> + if (IS_ERR(data->clk)) {
> + dev_err(dev, "failed to get clk, err=%ld\n",
> + PTR_ERR(data->clk));
> + return ret;
return PTR_ERR(data->clk), and delete ret.
> + }
> + return 0;
> +}
> +
> +static int ci_hdrc_qoriq_prepare_enable_clks(struct platform_device *pdev)
> +{
> + int ret;
> + struct device *dev = &pdev->dev;
> + struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
> +
> + ret = clk_prepare_enable(data->clk);
> + if (ret) {
> + dev_err(dev, "failed to prepare/enable clk, err=%d\n", ret);
> + return ret;
> + }
> + return 0;
> +}
> +
> +static void ci_hdrc_qoriq_disable_unprepare_clks(struct platform_device
> *pdev)
> +{
> + struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
> +
> + clk_disable_unprepare(data->clk);
> +}
> +
> +static int ci_hdrc_qoriq_usb_setup(struct platform_device *pdev)
> +{
> + u32 reg;
> + struct resource *res;
> + struct device *dev = &pdev->dev;
> + struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(dev, "failed to get I/O memory\n");
> + return -ENOENT;
> + }
> +
> + dev_dbg(dev, "res->start %llx, resource_size(res) %llx\n", res->start,
> + resource_size(res));
Delete above debug message please.
> + data->qoriq_regs = devm_ioremap(dev, res->start, resource_size(res));
> + if (IS_ERR(data->qoriq_regs)) {
> + dev_err(dev, "failed to remap I/O memory\n");
> + return -ENOMEM;
> + }
> +
This mapping will be freed soon, using ioremap instead.
> + data->phy_mode = of_usb_get_phy_mode(pdev->dev.of_node);
> + dev_dbg(dev, "phy_mode %d\n", data->phy_mode);
Delete above debug message please.
> +
> + reg = ioread32be(data->qoriq_regs + QORIQ_SOC_USB_CTRL);
> + switch (data->phy_mode) {
> + case USBPHY_INTERFACE_MODE_ULPI:
> + iowrite32be(reg | ~UTMI_PHY_EN,
> + data->qoriq_regs + QORIQ_SOC_USB_CTRL);
> + reg = ioread32be(data->qoriq_regs + QORIQ_SOC_USB_CTRL);
> + iowrite32be(reg | USB_CTRL_USB_EN,
> + data->qoriq_regs + QORIQ_SOC_USB_CTRL);
> + break;
> + default:
> + dev_err(dev, "unsupported phy_mode %d\n", data->phy_mode
Re: [PATCH v5 7/7] ARM: dts: sun9i: Switch to the AC100 RTC clock outputs for osc32k
Hi,
On Fri, Jul 08, 2016 at 10:33:42PM +0800, Chen-Yu Tsai wrote:
> The 32.768 kHz clock inside the A80 SoC is fed from an external source,
> typically the AC100 RTC module.
>
> Make the osc32k placeholder a fixed-factor clock so board dts files can
> specify its source.
>
> Signed-off-by: Chen-Yu Tsai
> ---
> Changes since v4: none
> Changes since v3: none
> Changes since v2: none
> Changes since v1: none
> ---
> arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 5 +
> arch/arm/boot/dts/sun9i-a80-optimus.dts | 5 +
> arch/arm/boot/dts/sun9i-a80.dtsi| 9 +++--
> 3 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
> b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
> index cf2f4b72a841..04b014603659 100644
> --- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
> +++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
> @@ -103,6 +103,11 @@
> allwinner,drive = ;
> };
>
> +&osc32k {
> + /* osc32k input is from AC100 */
> + clocks = <&ac100_rtc 0>;
> +};
> +
I'm guessing that an unresolved dependency when the driver has not
loaded yet, or is not even compiled ?
How is it working then?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
[PATCH] cdrom: support read sub-channel command in LBA format
Hello Jens, In CDROM Linux driver code, "Read Sub channel" format is hard coded with CDROM_MSF format only in the function cdrom_read_subchannel() and mmc_ioctl_cdrom_subchannel() in cdrom.c. Hence, irrespective of "Read Sub channel" command with CDROM_LBA/CDROM_MSF format, the reported Response which is in MSF format was considered as LBA in user space application. Now the behavior is changed in such way that IOCTL returns either CDROM_MSF or CDROM_LBA format per user request. Please find the fix patch attached. Best regards Veeraiyan Chidambaram RBEI/ECF Tel. +91(422)676-4495 0001-cdrom-support-read-sub-channel-command-in-LBA-format.patch Description: 0001-cdrom-support-read-sub-channel-command-in-LBA-format.patch
Re: bug in memcg oom-killer results in a hung syscall in another process in the same cgroup
On Sat 09-07-16 16:49:32, Shayan Pooya wrote: > I came across the following issue in kernel 3.16 (Ubuntu 14.04) which > was then reproduced in kernels 4.4 LTS: > After a couple of of memcg oom-kills in a cgroup, a syscall in > *another* process in the same cgroup hangs indefinitely. > > Reproducing: > > # mkdir -p strace_run > # mkdir /sys/fs/cgroup/memory/1 > # echo 1073741824 > /sys/fs/cgroup/memory/1/memory.limit_in_bytes > # echo 0 > /sys/fs/cgroup/memory/1/memory.swappiness > # for i in $(seq 1000); do ./call-mem-hog > /sys/fs/cgroup/memory/1/cgroup.procs & done > > Where call-mem-hog is: > #!/bin/sh > set -ex > echo $$ > $1 > echo "Adding $$ to $1" > strace -ff -tt ./mem-hog 2> strace_run/$$ > > > Initially I thought it was a userspace bug in dash as it only happened > with /bin/sh (which points to dash) and not with bash. I see the > following hanging processes: > > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > root 20999 0.0 0.0 4508 100 pts/6S16:28 0:00 > /bin/sh ./call-mem-hog /sys/fs/cgroup/memory/1/cgroup.procs > > However, when using strace, I noticed that sometimes there is actually > a mem-hog process hanging on sbrk syscall (Of course the > memory.oom_control is 0 and this is not expected). > Sending an ABRT signal to the waiting strace process then resulted in > the mem-hog process getting oom-killed by the kernel. Could you post the stack trace of the hung oom victim? Also could you post the full kernel log? -- Michal Hocko SUSE Labs
[PATCH 1/2] kexec: remove unnecessary unusable_pages
From: zhong jiang
In general, kexec alloc pages from buddy system, it cannot exceed
the physical address in the system.
The patch just remove this code, no functional change.
Signed-off-by: zhong jiang
---
include/linux/kexec.h | 1 -
kernel/kexec_core.c | 13 -
2 files changed, 14 deletions(-)
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index e8acb2b..26e4917 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -162,7 +162,6 @@ struct kimage {
struct list_head control_pages;
struct list_head dest_pages;
- struct list_head unusable_pages;
/* Address of next control page to allocate for crash kernels. */
unsigned long control_page;
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 56b3ed0..448127d 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -257,9 +257,6 @@ struct kimage *do_kimage_alloc_init(void)
/* Initialize the list of destination pages */
INIT_LIST_HEAD(&image->dest_pages);
- /* Initialize the list of unusable pages */
- INIT_LIST_HEAD(&image->unusable_pages);
-
return image;
}
@@ -517,10 +514,6 @@ static void kimage_free_extra_pages(struct kimage *image)
{
/* Walk through and free any extra destination pages I may have */
kimage_free_page_list(&image->dest_pages);
-
- /* Walk through and free any unusable pages I have cached */
- kimage_free_page_list(&image->unusable_pages);
-
}
void kimage_terminate(struct kimage *image)
{
@@ -647,12 +640,6 @@ static struct page *kimage_alloc_page(struct kimage *image,
page = kimage_alloc_pages(gfp_mask, 0);
if (!page)
return NULL;
- /* If the page cannot be used file it away */
- if (page_to_pfn(page) >
- (KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
- list_add(&page->lru, &image->unusable_pages);
- continue;
- }
addr = page_to_pfn(page) << PAGE_SHIFT;
/* If it is the destination page we want use it */
--
1.8.3.1
[PATCH 2/2] kexec: add a pmd huge entry condition during the page table
From: zhong jiang
when image is loaded into kernel, we need set up page table for it.
and all valid pfn also set up new mapping. it will set up a pmd huge
entry if pud_present is true. relocate_kernel points to code segment
can locate in the pmd huge entry in init_transtion_pgtable. therefore,
we need to take the situation into account.
Signed-off-by: zhong jiang
---
arch/x86/kernel/machine_kexec_64.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/machine_kexec_64.c
b/arch/x86/kernel/machine_kexec_64.c
index 5a294e4..c33e344 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -34,6 +35,17 @@ static struct kexec_file_ops *kexec_file_loaders[] = {
};
#endif
+static void split_pmd(pmd_t *pmd, pte_t *pte)
+{
+ unsigned long pfn = pmd_pfn(*pmd);
+ int i = 0;
+
+ do {
+ set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC));
+ pfn++;
+ } while (pte++, i++, i < PTRS_PER_PTE);
+}
+
static void free_transition_pgtable(struct kimage *image)
{
free_page((unsigned long)image->arch.pud);
@@ -68,15 +80,19 @@ static int init_transition_pgtable(struct kimage *image,
pgd_t *pgd)
set_pud(pud, __pud(__pa(pmd) | _KERNPG_TABLE));
}
pmd = pmd_offset(pud, vaddr);
- if (!pmd_present(*pmd)) {
+ if (!pmd_present(*pmd) || pmd_huge(*pmd)) {
pte = (pte_t *)get_zeroed_page(GFP_KERNEL);
if (!pte)
goto err;
image->arch.pte = pte;
- set_pmd(pmd, __pmd(__pa(pte) | _KERNPG_TABLE));
+ if (pmd_huge(*pmd))
+ split_pmd(pmd, pte);
+ else
+ set_pmd(pmd, __pmd(__pa(pte) | _KERNPG_TABLE));
}
pte = pte_offset_kernel(pmd, vaddr);
set_pte(pte, pfn_pte(paddr >> PAGE_SHIFT, PAGE_KERNEL_EXEC));
+
return 0;
err:
free_transition_pgtable(image);
--
1.8.3.1
[PATCH v4 2/3] iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.
Add Mediatek auxadc driver based on iio.
It will register a device in iio and support iio.
So thermal can read auxadc channel to sample data by iio device.
It is tested successfully on mt2701 platform.
Mt8173 and mt6577 platforms are not tested.
But the expectation is compatible.
Signed-off-by: Zhiyong Tao
---
drivers/iio/adc/Kconfig | 13 ++
drivers/iio/adc/Makefile|1 +
drivers/iio/adc/mt6577_auxadc.c | 294 +++
3 files changed, 308 insertions(+)
create mode 100644 drivers/iio/adc/mt6577_auxadc.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 25378c5..14929fc 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -305,6 +305,19 @@ config MCP3422
This driver can also be built as a module. If so, the module will be
called mcp3422.
+config MEDIATEK_MT6577_AUXADC
+tristate "MediaTek AUXADC driver"
+depends on ARCH_MEDIATEK || COMPILE_TEST
+depends on HAS_IOMEM
+help
+ Say yes here to enable support for MediaTek mt65xx AUXADC.
+
+ The driver supports immediate mode operation to read from one of
sixteen
+ channels (external or internal).
+
+ This driver can also be built as a module. If so, the module will be
+ called mt6577_auxadc.
+
config MEN_Z188_ADC
tristate "MEN 16z188 ADC IP Core support"
depends on MCB
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 38638d4..8306347 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_MAX1027) += max1027.o
obj-$(CONFIG_MAX1363) += max1363.o
obj-$(CONFIG_MCP320X) += mcp320x.o
obj-$(CONFIG_MCP3422) += mcp3422.o
+obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
obj-$(CONFIG_MXS_LRADC) += mxs-lradc.o
obj-$(CONFIG_NAU7802) += nau7802.o
diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c
new file mode 100644
index 000..c7cc901
--- /dev/null
+++ b/drivers/iio/adc/mt6577_auxadc.c
@@ -0,0 +1,294 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Zhiyong Tao
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register definitions */
+#define MT6577_AUXADC_CON00x00
+#define MT6577_AUXADC_CON10x04
+#define MT6577_AUXADC_CON20x10
+#define MT6577_AUXADC_STA BIT(0)
+
+#define MT6577_AUXADC_DAT00x14
+#define MT6577_AUXADC_RDY0BIT(12)
+
+#define MT6577_AUXADC_MISC0x94
+#define MT6577_AUXADC_PDN_EN BIT(14)
+
+#define MT6577_AUXADC_DAT_MASK0xfff
+#define MT6577_AUXADC_SLEEP_US1000
+#define MT6577_AUXADC_TIMEOUT_US 1
+#define MT6577_AUXADC_POWER_READY_MS 1
+#define MT6577_AUXADC_SAMPLE_READY_US 25
+
+struct mt6577_auxadc_device {
+ void __iomem *reg_base;
+ struct clk *adc_clk;
+ struct mutex lock;
+};
+
+#define MT6577_AUXADC_CHANNEL(idx) { \
+ .type = IIO_VOLTAGE,\
+ .indexed = 1, \
+ .channel = (idx), \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
+}
+
+static const struct iio_chan_spec mt6577_auxadc_iio_channels[] = {
+ MT6577_AUXADC_CHANNEL(0),
+ MT6577_AUXADC_CHANNEL(1),
+ MT6577_AUXADC_CHANNEL(2),
+ MT6577_AUXADC_CHANNEL(3),
+ MT6577_AUXADC_CHANNEL(4),
+ MT6577_AUXADC_CHANNEL(5),
+ MT6577_AUXADC_CHANNEL(6),
+ MT6577_AUXADC_CHANNEL(7),
+ MT6577_AUXADC_CHANNEL(8),
+ MT6577_AUXADC_CHANNEL(9),
+ MT6577_AUXADC_CHANNEL(10),
+ MT6577_AUXADC_CHANNEL(11),
+ MT6577_AUXADC_CHANNEL(12),
+ MT6577_AUXADC_CHANNEL(13),
+ MT6577_AUXADC_CHANNEL(14),
+ MT6577_AUXADC_CHANNEL(15),
+};
+
+static int mt6577_auxadc_read(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan)
+{
+ u32 rawdata, val;
+ void __iomem *reg_channel;
+ int ret;
+ struct mt6577_auxadc_device *adc_dev = iio_priv(indio_dev);
+
+ reg_channel = adc_dev->reg_base + MT6577_AUXADC_DAT0 +
+ chan->channel * 0x04;
+
+ mutex_lock
Re: [patch] crypto: sha256-mb - cleanup a || vs | typo
Hi Linus,
On Fri, Jul 8, 2016 at 7:19 PM, Linus Torvalds
wrote:
> (c)
> // This can be a single line. Or many. Your choice.
> The (c) form is particularly good for things like enum or structure
> member comments at the end of code, where you might want to align
> things up, but the ending comment marker ends up being visually pretty
> distracting (and lining _that_ up is too much make-believe work).
While I'm a fan of the (c) form myself, I became used to not using it for
kernel code. Except for internal comments that are not intended to be sent
out. This works fine, as checkpatch will complain if I ever forget to remove
them while preparing patches.
The alternative would be to teach checkpatch to complain about FIXME, TODO,
and XXX in comments...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v4 1/3] dt-bindings: auxadc: Add binding document for Mediatek auxadc.
The commit adds the device tree binding documentation for the mediatek
auxadc found on Mediatek MT2701.
Thermal gets auxadc sample data by iio device.
So the commit changes auxadc device tree binding documentation from
/soc/mediatek/auxadc.txt to /iio/adc/mt6577_auxadc.txt.
Signed-off-by: Zhiyong Tao
---
.../devicetree/bindings/iio/adc/mt6577_auxadc.txt | 27
.../devicetree/bindings/soc/mediatek/auxadc.txt| 21 ---
2 files changed, 27 insertions(+), 21 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
delete mode 100644 Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
new file mode 100644
index 000..bc23792
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
@@ -0,0 +1,27 @@
+* Mediatek AUXADC - Analog to Digital Converter on Mediatek mobile soc
(mt65xx/mt81xx/mt27xx)
+===
+
+The Auxiliary Analog/Digital Converter (AUXADC) is an ADC found
+in some Mediatek SoCs which among other things measures the temperatures
+in the SoC. It can be used directly with register accesses, but it is also
+used by thermal controller which reads the temperatures from the AUXADC
+directly via its own bus interface. See
+Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
+for the Thermal Controller which holds a phandle to the AUXADC.
+
+Required properties:
+ - compatible: "mediatek,mt2701-auxadc" or "mediatek,mt8173-auxadc"
+ - reg: Address range of the AUXADC unit.
+ - clocks: Should contain a clock specifier for each entry in clock-names
+ - clock-names: Should contain "main".
+ - #io-channel-cells: Should be 1, see ../iio-bindings.txt
+
+Example:
+
+auxadc: adc@11001000 {
+ compatible = "mediatek,mt2701-auxadc";
+ reg = <0 0x11001000 0 0x1000>;
+ clocks = <&pericfg CLK_PERI_AUXADC>;
+ clock-names = "main";
+ #io-channel-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
b/Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
deleted file mode 100644
index bdb7829..000
--- a/Documentation/devicetree/bindings/soc/mediatek/auxadc.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-MediaTek AUXADC
-===
-
-The Auxiliary Analog/Digital Converter (AUXADC) is an ADC found
-in some Mediatek SoCs which among other things measures the temperatures
-in the SoC. It can be used directly with register accesses, but it is also
-used by thermal controller which reads the temperatures from the AUXADC
-directly via its own bus interface. See
-Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
-for the Thermal Controller which holds a phandle to the AUXADC.
-
-Required properties:
-- compatible: Must be "mediatek,mt8173-auxadc"
-- reg: Address range of the AUXADC unit
-
-Example:
-
-auxadc: auxadc@11001000 {
- compatible = "mediatek,mt8173-auxadc";
- reg = <0 0x11001000 0 0x1000>;
-};
--
1.7.9.5
[PATCH v4 3/3] arm: dts: mt2701: Add auxadc node.
The commit adds auxadc nodes to the Mediatek MT2701 dtsi file.
Signed-off-by: Zhiyong Tao
---
arch/arm/boot/dts/mt2701.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 42d5a37..c0a2644 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -187,6 +187,15 @@
<0 0x10216000 0 0x2000>;
};
+ auxadc: adc@11001000 {
+ compatible = "mediatek,mt2701-auxadc";
+ reg = <0 0x11001000 0 0x1000>;
+ clocks = <&pericfg CLK_PERI_AUXADC>;
+ clock-names = "main";
+ #io-channel-cells = <1>;
+ status = "disabled";
+ };
+
uart0: serial@11002000 {
compatible = "mediatek,mt2701-uart",
"mediatek,mt6577-uart";
--
1.7.9.5
[PATCH v4 0/3] AUXADC: Mediatek auxadc driver
This series includes three patches: 1.Change the device tree binding documentation. 2.Add auxadc driver based on linux iio. 3.Add auxadc nodes in the mediatek MT2701 dtsi file. Changes in patch v4: 1).Change the file name 'mt65xx_auxdc.txt' to 'mt6577_auxdc.txt'. 2).Remove 'break' after 'return' in 'mt6577_auxadc_read_raw'. 3).Use 'mt2701' instead of 'auxadc' in dts commit message. 4).Change 'auxadc@' to 'adc@' in mt2701.dtsi. Changes in patch v3: 1).Add '#' before 'io-channel-cells' and change 'auxadc@' to 'adc@' in auxadc binding document. 2).Fix CONFIG_MEDIATEK_MT65XX_AUXADC sequence as alphabetical order. 3).Change the prefix 'MT65XX' to 'MT6577' to match auxadc driver name. 4).Remove the delays stored in 'mt6577_auxadc_device' and use the defined delay directly. 5).Use '-ETIMEDOUT' instead of '-EINVAL'. 6).Return value directly in 'mt6577_auxadc_read_raw'. 7).Add power off and unprepare clock if 'iio_device_register' failed. 8).Change 'Registers' to 'Register'. Changes in patch v2: 1).Change the file name mt65xx_auxadc.c to mt6577_auxadc.c. 2).Add 'depends on ARCH_MEDIATEK || COMPILE_TEST and HAS_IOMEM' for MEDIATEK_MT65XX_AUXADC config. 3).Add check case for return value of 'readl_poll_timeout'. 4).Remove returning 1 and 0 for SCALE and OFFSET. use channel type 'IIO_CHAN_INFO_PROCESSED' instead of 'IIO_CHAN_INFO_RAW'. 5).Remove 'IIO_CHAN_INFO_OFFSET' and 'IIO_CHAN_INFO_SCALE' in 'MT65XX_AUXADC_CHANNEL' channel type. 6).Add check case when auxadc power on failure. if auxadc power on failure, clk_disable_unprepare should be executed. 7).Put 'platform_set_drvdata' before 'iio_device_register'. 8).Fix coding style and spelling error. Zhiyong Tao (3): dt-bindings: auxadc: Add binding document for Mediatek auxadc. iio: adc: mt2701: Add Mediatek auxadc driver for mt2701. arm: dts: mt2701: Add auxadc node. .../devicetree/bindings/iio/adc/mt6577_auxadc.txt | 27 ++ .../devicetree/bindings/soc/mediatek/auxadc.txt| 21 -- arch/arm/boot/dts/mt2701.dtsi |9 + drivers/iio/adc/Kconfig| 13 + drivers/iio/adc/Makefile |1 + drivers/iio/adc/mt6577_auxadc.c| 294 6 files changed, 344 insertions(+), 21 deletions(-) create mode 100644 Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt delete mode 100644 Documentation/devicetree/bindings/soc/mediatek/auxadc.txt create mode 100644 drivers/iio/adc/mt6577_auxadc.c
Re: [PATCH 1/3] Add a new field to struct shrinker
On Sat 09-07-16 04:43:31, Janani Ravichandran wrote:
> Struct shrinker does not have a field to uniquely identify the shrinkers
> it represents. It would be helpful to have a new field to hold names of
> shrinkers. This information would be useful while analyzing their
> behavior using tracepoints.
This will however increase the vmlinux size even when no tracing is
enabled. Why cannot we simply print the name of the shrinker callbacks?
>
> ---
> include/linux/shrinker.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h
> index 4fcacd9..431125c 100644
> --- a/include/linux/shrinker.h
> +++ b/include/linux/shrinker.h
> @@ -52,6 +52,7 @@ struct shrinker {
> unsigned long (*scan_objects)(struct shrinker *,
> struct shrink_control *sc);
>
> + const char *name;
> int seeks; /* seeks to recreate an obj */
> long batch; /* reclaim batch size, 0 = default */
> unsigned long flags;
> --
> 2.7.0
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
--
Michal Hocko
SUSE Labs
Re: [PATCH v2 4/4] kernel/time/clockevents: compensate for monotonic clock's dynamic frequency
Nicolai Stange writes:
> With NOHZ_FULL and one single well-isolated, CPU consumptive task, one
> would expect approximately one clockevent interrupt per second. However, on
> my Intel Haswell where the monotonic clock is the TSC monotonic clock and
> the clockevent device is the TSC deadline device, it turns out that every
> second, there are two such interrupts: the first one arrives always
> approximately ~50us before the scheduled deadline as programmed by
> tick_nohz_stop_sched_tick() through the hrtimer API. The
> __hrtimer_run_queues() called in this interrupt detects that the queued
> tick_sched_timer hasn't expired yet and simply does nothing except
> reprogramming the clock event device to fire shortly after again.
>
> These too early programmed deadlines are explained as follows:
> clockevents_program_event() programs the clockevent device to fire
> after
> f_event * delta_t_progr
> clockevent device cycles where f_event is the clockevent device's hardware
> frequency and delta_t_progr is the requested time interval. After that many
> clockevent device cycles have elapsed, the device underlying the monotonic
> clock, that is the monotonic raw clock has seen f_raw / f_event as many
> cycles.
> The ktime_get() called from __hrtimer_run_queues() interprets those
> cycles to run at the frequency of the monotonic clock. Summarizing:
> delta_t_perc = 1/f_mono * f_raw/f_event * f_event * delta_t_progr
>= f_raw / f_mono * delta_t_progr
> with f_mono being the monotonic clock's frequency and delta_t_perc being
> the elapsed time interval as perceived by __hrtimer_run_queues().
>
> Now, f_mono is not a constant, but is dynamically adjusted in
> timekeeping_adjust() in order to compensate for the NTP error. With the
> large values of delta_t_progr of 10^9ns with NOHZ_FULL, the error made
> becomes significant and results in the double timer interrupts described
> above.
>
> Compensate for this error by multiplying delta_t_progr with f_mono / f_raw
> in clockevents_program_event() before actually programming the clockevent
> device.
>
> Namely, introduce a helper, timekeeping_mono_interval_to_raw(), which
> converts a given time interval from the monotonic clock's perception to
> that of the raw monotonic clock by multiplying the value by f_mono / f_raw.
> Call that helper from clockevents_program_event() in order to obtain a
> suitable time interval to program the clockevent device with.
>
> Signed-off-by: Nicolai Stange
> ---
> kernel/time/clockevents.c | 1 +
> kernel/time/timekeeping.c | 59
> +++
> kernel/time/timekeeping.h | 1 +
> 3 files changed, 61 insertions(+)
>
> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
> index a9b76a4..4bccf04 100644
> --- a/kernel/time/clockevents.c
> +++ b/kernel/time/clockevents.c
> @@ -329,6 +329,7 @@ int clockevents_program_event(struct clock_event_device
> *dev, ktime_t expires,
> return dev->set_next_ktime(expires, dev);
>
> delta = ktime_to_ns(ktime_sub(expires, ktime_get()));
> + delta = timekeeping_mono_interval_to_raw(delta);
> if (delta <= 0)
> return force ? clockevents_program_min_delta(dev) : -ETIME;
>
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index dcd5ce6..51dfbbb 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
>
> #include "tick-internal.h"
> #include "ntp_internal.h"
> @@ -2133,6 +2134,64 @@ out:
> }
>
> /**
> + * timekeeper_mono_interval_to_raw - Convert mono interval to raw's
> perception.
> + * @interval: Time interval as measured by the mono clock.
> + *
> + * Converts the given time interval as measured by the monotonic clock to
> + * what would have been measured by the raw monotonic clock in the meanwhile.
> + * The monotonic clock's frequency gets dynamically adjusted every now and
> then
> + * in order to compensate for the differences to NTP. OTOH, the clockevents
> + * devices are not affected by this adjustment, i.e. they keep ticking at
> some
> + * fixed hardware frequency which may be assumed to have a constant ratio to
> + * the fixed raw monotonic clock's frequency. This function provides a means
> + * to convert time intervals from the dynamic frequency monotonic clock to
> + * the fixed frequency hardware world.
> + *
> + * If interval < 0, zero is returned. If an overflow happens during the
> + * calculation, KTIME_MAX is returned.
> + */
> +s64 timekeeping_mono_interval_to_raw(s64 interval)
> +{
> + struct timekeeper *tk = &tk_core.timekeeper;
> + u32 raw_mult = tk->tkr_raw.mult, mono_mult = tk->tkr_mono.mult;
> + u64 raw, tmp;
> +
> + /* The overflow checks below can't deal with negative intervals. */
> + if (interval <= 0)
> + return 0;
> +
> + /*
> + * Calculate
> + * raw = f_mono / f_raw * interval
> +
Re: [tip:perf/core] Revert "perf/x86/intel, watchdog: Switch NMI watchdog to ref cycles on x86"
On Sun, Jul 10, 2016 at 12:03:41PM -0700, tip-bot for Ingo Molnar wrote: > Commit-ID: 44530d588e142a96cf0cd345a7cb8911c4f88720 > Gitweb: http://git.kernel.org/tip/44530d588e142a96cf0cd345a7cb8911c4f88720 > Author: Ingo Molnar > AuthorDate: Sun, 10 Jul 2016 20:58:36 +0200 > Committer: Ingo Molnar > CommitDate: Sun, 10 Jul 2016 20:58:36 +0200 > > Revert "perf/x86/intel, watchdog: Switch NMI watchdog to ref cycles on x86" > > This reverts commit 2c95afc1e83d93fac3be6923465e1753c2c53b0a. > > Stephane reported the following regression: > > > Since Andi added: > > > > commit 2c95afc1e83d93fac3be6923465e1753c2c53b0a > > Author: Andi Kleen > > Date: Thu Jun 9 06:14:38 2016 -0700 > > > >perf/x86/intel, watchdog: Switch NMI watchdog to ref cycles on x86 > > > > $ perf stat -e ref-cycles ls > > > > > > fails systematically because the ref-cycles is now used by the > > watchdog and given this is a system-wide pinned event, it monopolizes > > the fixed counter 2 which is the only counter able to measure this event. > > Since the next merge window is near, fix the regression for now > by reverting the commit. I don't think there is any better solution than the original patch. The NMI watchdog taking up the precious cycle counter (which is far more important than the obscure ref cycles) was always a big problem because it prevents any groups running that need it. A lot of tools, including now perf stat --topdown now cannot deal with it without adding extra multiplexing which totally destroys the measurements on non steady state workloads. So I would prefer to not revert it. If you want ref-cycles you can just disable the NMI watchdog. Today most people who use cycles in non trivial situations have to do that. With ref-cycles still some people have to do it, but it's far less common than before. So basically the revert is worse than what was there with the patch. -Andi
Re: [PATCH v6] ASoC: rockchip: Add machine driver for RK3399 GRU Boards
Hi Mark, In your opinion, is there anything needs to be optimized in this patch? Thanks. On 2016年06月20日 21:08, Rob Herring wrote: On Thu, Jun 16, 2016 at 08:40:58PM +0800, Xing Zheng wrote: Because we need to support the multiple codecs (MAX98357A/RT5514/DA7219) on the RK3399 GRU boards, this patch can help us to support these codecs. Signed-off-by: Xing Zheng --- Changes in v6: - remove enable/disable dapm pins, and to switch codecs via user space - fix "Speaker" dapm route for max98357a - add SND_JACK_LINEOUT flag for da7219 jack detection Changes in v5: - fix the build warning for missing I2C/CLKDEV_LOOKUP dependency Changes in v4: - the compatible name needs to be based on a single reference design, and the name of the board is called "GRU" - use one i2sX card "rockchip,cpu = <&i2s0>" instead of array that is based on GRU - rename DOC to rockchip,rk3399-gru-sound.txt - rename compatible to rockchip,rk3399-gru-sound - rename source code to rk3399_gru_sound.c Changes in v3: - rename DOC to rockchip,rk3399-max98357a-rt5514-da7219.txt - rename compatible to rockchip,rk3399-max98357a-rt5514-da7219 - rename source code to rk3399_max98357a_rt5514_da7219.c Changes in v2: - use the FS 256 to set mclks of the max98357a and rt5514 danamically - add more sample rate for da7219 .../bindings/sound/rockchip,rk3399-gru-sound.txt | 15 + Acked-by: Rob Herring sound/soc/rockchip/Kconfig | 11 + sound/soc/rockchip/Makefile|2 + sound/soc/rockchip/rk3399_gru_sound.c | 322 4 files changed, 350 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt create mode 100644 sound/soc/rockchip/rk3399_gru_sound.c -- - Xing Zheng
Re: [RFC][PATCH v2 3/3] mm/page_owner: track page free call chain
On Fri, Jul 08, 2016 at 09:11:32PM +0900, Sergey Senozhatsky wrote:
> Extend page_owner with free_pages() tracking functionality. This adds to the
> dump_page_owner() output an additional backtrace, that tells us what path has
> freed the page.
>
> Aa a trivial example, let's assume that do_some_foo() has an error - an extra
> put_page() on error return path, and the function is also getting preempted,
> letting some other task to allocate the same page, which is then 'mistakenly'
> getting freed once again by do_some_foo().
>
> CPUA CPUB
>
> void do_some_foo(void)
> {
> page = alloc_page();
> if (error) {
> put_page(page);
> goto out;
> }
> ...
> out:
> <>
> void do_some_bar()
> {
> page = alloc_page();
> ...
> <>
> ...
> put_page(page);
> }
> <>
> put_page(page);
> }
>
> With the existing implementation we would see only CPUB's backtrace
> from bad_page. The extended page_owner would also report CPUA's
> put_page(), which can be a helpful hint.
>
> Backtrace:
>
> BUG: Bad page state in process cc1 pfn:bae1d
> page:ea0002eb8740 count:-1 mapcount:0 mapping: (null) index:0x0
> flags: 0x4000()
> page dumped because: nonzero _count
> page allocated via order 0, migratetype Unmovable, gfp_mask
> 0x2000200(GFP_NOWAIT|__GFP_NOWARN)
> [] save_stack_trace+0x26/0x41
> [] save_stack+0x46/0xc3
> [] __page_owner_alloc_pages+0x24/0x41
> [] post_alloc_hook+0x1e/0x20
> [] get_page_from_freelist+0x4fd/0x756
> [] __alloc_pages_nodemask+0xe7/0xbcf
> [] __get_free_pages+0x12/0x40
> [] __tlb_remove_page_size.part.12+0x37/0x78
> [] __tlb_remove_page_size+0x21/0x23
> [] unmap_page_range+0x63a/0x75b
> [] unmap_single_vma+0xbc/0xc6
> [] unmap_vmas+0x35/0x44
> [] exit_mmap+0x5a/0xec
> [] mmput+0x4a/0xdc
> [] do_exit+0x398/0x8de
> [] do_group_exit+0x45/0xb0
> page freed, was allocated via order 0, migratetype Unmovable, gfp_mask
> 0x2000200(GFP_NOWAIT|__GFP_NOWARN)
> [] save_stack_trace+0x26/0x41
> [] save_stack+0x46/0xc3
> [] __page_owner_free_pages+0x25/0x71
> [] free_hot_cold_page+0x1d6/0x1ea
> [] __put_page+0x37/0x3a
> [] do_some_foo()+0x8a/0x8e
> ...
> Modules linked in:
> CPU: 3 PID: 1274 Comm: cc1 Not tainted
> 4.7.0-rc5-next-20160701-dbg-9-ge01494f-dirty #535
> 8800aeea3c18 811e67ca ea0002eb8740
> 8175675e 8800aeea3c40 810c87f5
> 81880b40 880137d98438 8800aeea3c50 810c88d5
> Call Trace:
> [] dump_stack+0x68/0x92
> [] bad_page+0xf8/0x11e
> [] check_new_page_bad+0x63/0x65
> [] get_page_from_freelist+0x22a/0x756
> [] __alloc_pages_nodemask+0xe7/0xbcf
> [] ? trace_hardirqs_on_caller+0x16d/0x189
> [] ? vma_merge+0x159/0x249
> [] ? __lock_acquire+0x2ac/0x15c7
> [] pte_alloc_one+0x1b/0x67
> [] __pte_alloc+0x19/0xa6
> [] handle_mm_fault+0x409/0xc59
> [] __do_page_fault+0x1d8/0x3ac
> [] do_page_fault+0xc/0xe
> [] page_fault+0x1f/0x30
>
> Signed-off-by: Sergey Senozhatsky
> ---
> include/linux/page_ext.h | 11 ++-
> mm/page_owner.c | 74
> ++--
> mm/vmstat.c | 3 ++
> 3 files changed, 59 insertions(+), 29 deletions(-)
>
> diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h
> index 66ba2bb..094 100644
> --- a/include/linux/page_ext.h
> +++ b/include/linux/page_ext.h
> @@ -27,12 +27,21 @@ enum page_ext_flags {
> PAGE_EXT_DEBUG_POISON, /* Page is poisoned */
> PAGE_EXT_DEBUG_GUARD,
> PAGE_EXT_OWNER_ALLOC,
> + PAGE_EXT_OWNER_FREE,
> #if defined(CONFIG_IDLE_PAGE_TRACKING) && !defined(CONFIG_64BIT)
> PAGE_EXT_YOUNG,
> PAGE_EXT_IDLE,
> #endif
> };
>
> +#ifdef CONFIG_PAGE_OWNER
> +enum page_owner_handles {
> + PAGE_OWNER_HANDLE_ALLOC,
> + PAGE_OWNER_HANDLE_FREE,
> + PAGE_OWNER_HANDLE_MAX
> +};
> +#endif
> +
> /*
> * Page Extension can be considered as an extended mem_map.
> * A page_ext page is associated with every page descriptor. The
> @@ -46,7 +55,7 @@ struct page_ext {
> unsigned int order;
> gfp_t gfp_mask;
> int last_migrate_reason;
> - depot_stack_handle_t handle;
> + depot_stack_handle_t handles[PAGE_OWNER_HANDLE_MAX];
> #endif
> };
>
> diff --git a/mm/page_owner.c b/mm/page_owner.c
> index 4acccb7..c431ac4 100644
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
> @@ -13,6 +13,11 @@
>
> #define PAGE_OWNER_STACK_DEPTH (16)
>
> +static const char *page_owner_handles_names[PAGE_OWNE
Re: [LEDE-DEV] DHCP via bridge in case of IPv4
Hi Russel, On Sun, 2016-07-10 at 00:19 -0700, Russell Senior wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > "Alexey" == Alexey Brodkin writes: > Alexey> Hi Aaron, > Alexey> On Sat, 2016-07-09 at 07:47 -0400, Aaron Z wrote: > > > > > > > > On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin > > > wrote: > > > > > > > > > > > > Hello, > > > > > > > > I was playing with quite simple bridged setup on different boards > > > with > very recent kernels (4.6.3 as of this writing) and found one > > > interesting > behavior that I cannot yet understand and googling > > > din't help here as well. > > > > > > > > > > > > My setup is pretty simple: > > > > - -- - > > > > > > > > > > > > > > > > > > > HOST | | "Dumb AP" | | Wireless > > > client | > > with DHCP |<->(eth0) (wlan0)<->| > > > attempting to | > > server| |\ br0 > > > / | | get settings via DHCP | > > > > - -- - > > > > > > > > > > > > * HOST is my laptop with DHCP server that works for sure. > * > > > "Dumb AP" is a separate board (I tried ARM-based Wandboard and > > > ARC-based > AXS10x boards but results are exactly the same) with > > > wired (eth0) and wireless > (wlan0) network controllers bridged > > > together (br0). That "br0" bridge flawlessly > gets its settings > > > from DHCP server on host. > * Wireless client could be either a > > > smatrphone or another laptop etc but > what's important it should > > > be configured to get network settings by DHCP as well. > > > > > > > > > > > > So what happens "br0" always gets network settings from DHCP server > > > on HOST. > That's fine. But wireless client only reliably gets > > > settings from DHCP server > if IPv6 is enabled on "Dumb AP" board. If > > > IPv6 is disabled I may see that > wireless client sends "DHCP > > > Discover" then server replies with "DHCP Offer" but > that offer > > > never reaches wireless client. > > > > > > > > > Do you have WDS enabled? If not, DHCP has issues in that scenario: > > > https://wiki.openwrt.org/doc/howto/clientmode > If the Dumb AP's wireless interface is in ap-mode, then this shouldn't > be an issue. It's only client-mode interfaces that have trouble with > bridging. > > I'd suggest running tcpdump on the Dumb AP's wireless interface and the > client's wireless interface and see which of them sees the various parts > of the DHCP handshake. So I did but for DHCP server and wireless client (had no tcpdump on Dump AP at the moment). That's what I see on the server: ->8--- No. TimeSource Destination Protocol Length Info 3 0.151181000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 11 2.760796000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- Transaction ID 0x31dc321f 14 5.220985000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 15 5.22115 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- Transaction ID 0x31dc321f 23 15.649835000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 24 15.650017000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- Transaction ID 0x31dc321f 32 25.648589000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 33 25.648758000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- Transaction ID 0x31dc321f 43 35.864567000 0.0.0.0255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 48 38.832837000 10.42.0.1 10.42.0.13 DHCP 342DHCP Offer- Transaction ID 0x31dc321f ->8--- That's on the wireless client: ->8--- No. Time Source Destination Protocol Length Info 1171 94.192971000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 1182 99.263686000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 1185 109.692642000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 1186 119.691474000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f 1190 129.907507000 0.0.0.0 255.255.255.255 DHCP 342DHCP Discover - Transaction ID 0x31dc321f ->8--- I'll try to capture data from Dumb AP sometime soon and will reply to the thread. -Alexey
linux-next: build warning after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning (CONFIG_MPLS is disabled):
net/ipv4/tunnel4.c: In function 'tunnel4_init':
net/ipv4/tunnel4.c:223:1: warning: label 'err_mpls' defined but not used
[-Wunused-label]
err_mpls:
^
and the powerpc ppc64_defconfig build produced this (CONFIG_IPV6 is disabled):
net/ipv4/tunnel4.c: In function 'tunnel4_init':
net/ipv4/tunnel4.c:226:1: warning: label 'err_ipv6' defined but not used
[-Wunused-label]
err_ipv6:
^
Introduced by commit
8afe97e5d416 ("tunnels: support MPLS over IPv4 tunnels")
--
Cheers,
Stephen Rothwell
Re: [PATCH v7 0/11] Output raw touch data via V4L2
On 07/08/2016 01:25 PM, Nick Dyer wrote: > This is a series of patches to add output of raw touch diagnostic data via > V4L2 > to the Atmel maXTouch and Synaptics RMI4 drivers. > > It's a rewrite of the previous implementation which output via debugfs: it now > uses a V4L2 device in a similar way to the sur40 driver. > > We have a utility which can read the data and display it in a useful format: > https://github.com/ndyer/heatmap/commits/heatmap-v4l > > These patches are also available from > https://github.com/ndyer/linux/commits/v4l-touch-v7-2016-07-08 > > I will also send a patch to update v4l2-compliance. The series looks good, but it needs to be rebased due to this change: http://www.spinics.net/lists/linux-media/msg101733.html Regarding patch 3/11: as you may know we're moving from DocBook to sphinx for the documentation in 4.8. The git branch with that code is here: https://git.linuxtv.org/media_tree.git/log/?h=docs-next If you can redo this patch 3/11 on top of that branch, then that would be great. Regards, Hans > > Changes in v7: > - Tested by Andrew Duggan and Chris Healy. > - Update bus_info to add "rmi4:" bus. > - Fix code style issues in sur40 changes. > > Changes in v6: > - Remove BUF_TYPE_TOUCH_CAPTURE, as discussed with Hans V touch devices will > use BUF_TYPE_VIDEO_CAPTURE. > - Touch devices should now register CAP_VIDEO_CAPTURE: CAP_TOUCH just says > that > this is a touch device, not a video device, but otherwise it acts the same. > - Add some code to v4l_s_fmt() to set sensible default values for fields not > used by touch. > - Improve naming/doc of RMI4 F54 report types. > - Various minor DocBook fixes, and split to separate patch. > - Update my email address. > - Rework sur40 changes so that PIX_FMT_GREY is supported for backward > compatibility. Florian is it possible for you to test? > > Changes in v5 (Hans Verkuil review): > - Update v4l2-core: > - Add VFL_TYPE_TOUCH, V4L2_BUF_TYPE_TOUCH_CAPTURE and V4L2_CAP_TOUCH > - Change V4L2_INPUT_TYPE_TOUCH_SENSOR to V4L2_INPUT_TYPE_TOUCH > - Improve DocBook documentation > - Add FMT definitions for touch data > - Note this will need the latest version of the heatmap util > - Synaptics RMI4 driver: > - Remove some less important non full frame report types > - Switch report type names to const char * array > - Move a static array to inside context struct > - Split sur40 changes to a separate commit > > Changes in v4: > - Address nits from the input side in atmel_mxt_ts patches (Dmitry Torokhov) > - Add Synaptics RMI4 F54 support patch > > Changes in v3: > - Address V4L2 review comments from Hans Verkuil > - Run v4l-compliance and fix all issues - needs minor patch here: > https://github.com/ndyer/v4l-utils/commit/cf50469773f > > Changes in v2: > - Split pixfmt changes into separate commit and add DocBook > - Introduce VFL_TYPE_TOUCH_SENSOR and /dev/v4l-touch > - Remove "single node" support for now, it may be better to treat it as > metadata later > - Explicitly set VFL_DIR_RX > - Fix Kconfig > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH v2 04/13] KVM: x86: dynamic kvm_apic_map
On 2016/7/8 1:15, Radim Krčmář wrote:
x2APIC supports up to 2^32-1 LAPICs, but most guest in coming years will
have slighly less VCPUs. Dynamic size saves memory at the cost of
turning one constant into a variable.
apic_map mutex had to be moved before allocation to avoid races with cpu
hotplug.
Signed-off-by: Radim Krčmář
---
v2:
* replaced size with max_apic_id to minimize chances of overflow [Andrew]
* fixed allocation size [Paolo]
arch/x86/include/asm/kvm_host.h | 3 ++-
arch/x86/kvm/lapic.c| 18 +-
arch/x86/kvm/lapic.h| 2 +-
3 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3194b19b9c7b..643e3dffcd85 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -682,11 +682,12 @@ struct kvm_arch_memory_slot {
struct kvm_apic_map {
struct rcu_head rcu;
u8 mode;
- struct kvm_lapic *phys_map[256];
+ u32 max_apic_id;
union {
struct kvm_lapic *xapic_flat_map[8];
struct kvm_lapic *xapic_cluster_map[16][4];
};
+ struct kvm_lapic *phys_map[];
};
/* Hyper-V emulation context */
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 9880d03f533d..224fc1c5fcc6 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -120,7 +120,7 @@ static inline bool kvm_apic_map_get_logical_dest(struct
kvm_apic_map *map,
switch (map->mode) {
case KVM_APIC_MODE_X2APIC: {
u32 offset = (dest_id >> 16) * 16;
- u32 max_apic_id = ARRAY_SIZE(map->phys_map) - 1;
+ u32 max_apic_id = map->max_apic_id;
if (offset <= max_apic_id) {
u8 cluster_size = min(max_apic_id - offset + 1, 16U);
@@ -152,14 +152,22 @@ static void recalculate_apic_map(struct kvm *kvm)
struct kvm_apic_map *new, *old = NULL;
struct kvm_vcpu *vcpu;
int i;
-
- new = kzalloc(sizeof(struct kvm_apic_map), GFP_KERNEL);
+ u32 max_id = 255;
mutex_lock(&kvm->arch.apic_map_lock);
+ kvm_for_each_vcpu(i, vcpu, kvm)
+ if (kvm_apic_present(vcpu))
+ max_id = max(max_id, kvm_apic_id(vcpu->arch.apic));
+
+ new = kzalloc(sizeof(struct kvm_apic_map) +
+ sizeof(struct kvm_lapic *) * (max_id + 1), GFP_KERNEL);
+
I think this may cause the host runs out of memory if a malicious guest
did follow thing:
1. vcpu a is doing apic map recalculation.
2. vcpu b write the apic id with 0xff
3. then vcpu b enable the x2apic: in kvm_lapic_set_base(), we will set
apic_base to new value before reset the apic id.
4. vcpu a may see the x2apic enabled in vcpu b plus an old apic
id(0xff), and max_id will become (0xff >> 24).
if (!new)
goto out;
+ new->max_apic_id = max_id;
+
kvm_for_each_vcpu(i, vcpu, kvm) {
struct kvm_lapic *apic = vcpu->arch.apic;
struct kvm_lapic **cluster;
@@ -172,7 +180,7 @@ static void recalculate_apic_map(struct kvm *kvm)
aid = kvm_apic_id(apic);
ldr = kvm_lapic_get_reg(apic, APIC_LDR);
- if (aid < ARRAY_SIZE(new->phys_map))
+ if (aid <= new->max_apic_id)
new->phys_map[aid] = apic;
if (apic_x2apic_mode(apic)) {
@@ -710,7 +718,7 @@ static inline bool kvm_apic_map_get_dest_lapic(struct kvm
*kvm,
return false;
if (irq->dest_mode == APIC_DEST_PHYSICAL) {
- if (irq->dest_id >= ARRAY_SIZE(map->phys_map)) {
+ if (irq->dest_id > map->max_apic_id) {
*bitmap = 0;
} else {
*dst = &map->phys_map[irq->dest_id];
diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
index 336ba51bb16e..8d811139d2b3 100644
--- a/arch/x86/kvm/lapic.h
+++ b/arch/x86/kvm/lapic.h
@@ -200,7 +200,7 @@ static inline int kvm_lapic_latched_init(struct kvm_vcpu
*vcpu)
return lapic_in_kernel(vcpu) && test_bit(KVM_APIC_INIT,
&vcpu->arch.apic->pending_events);
}
-static inline int kvm_apic_id(struct kvm_lapic *apic)
+static inline u32 kvm_apic_id(struct kvm_lapic *apic)
{
return (kvm_lapic_get_reg(apic, APIC_ID) >> 24) & 0xff;
}
--
best regards
yang
Re: [PATCH v2 11/13] KVM: x86: add KVM_CAP_X2APIC_API
On 2016/7/8 1:15, Radim Krčmář wrote:
KVM_CAP_X2APIC_API can be enabled to extend APIC ID in get/set ioctl and MSI
addresses to 32 bits. Both are needed to support x2APIC.
The capability has to be toggleable and disabled by default, because get/set
ioctl shifted and truncated APIC ID to 8 bits by using a non-standard protocol
inspired by xAPIC and the change is not backward-compatible.
Changes to MSI addresses follow the format used by interrupt remapping unit.
The upper address word, that used to be 0, contains upper 24 bits of the LAPIC
address in its upper 24 bits. Lower 8 bits are reserved as 0.
Using the upper address word is not backward-compatible either as we didn't
check that userspace zeroed the word. Reserved bits are still not explicitly
Does this means we cannot migrate the VM from KVM_CAP_X2APIC_API enabled
host to the disable host even VM doesn't have more than 255 VCPUs?
checked, but non-zero data will affect LAPIC addresses, which will cause a bug.
Signed-off-by: Radim Krčmář
---
v2:
* pass struct kvm into kvm_set_msi_irq [Paolo]
* trace address_hi [David]
* use hex dst, like other tracepoins
* strict reserved MSI bits checking [Paolo]
* loose reserved capability bits checking [Paolo]
* improved documentation [Paolo]
Documentation/virtual/kvm/api.txt | 32
arch/x86/include/asm/kvm_host.h | 4 +++-
arch/x86/kvm/irq_comm.c | 26 +-
arch/x86/kvm/lapic.c | 13 +
arch/x86/kvm/vmx.c| 2 +-
arch/x86/kvm/x86.c| 5 +
include/trace/events/kvm.h| 5 +++--
include/uapi/linux/kvm.h | 1 +
8 files changed, 75 insertions(+), 13 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 09efa9eb3926..a8f2ef910f98 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1482,6 +1482,10 @@ struct kvm_irq_routing_msi {
__u32 pad;
};
+On x86, address_hi is ignored unless the KVM_CAP_X2APIC_API capability is
+enabled. If it is enabled, address_hi bits 31-8 provide bits 31-8 of the
+destination id. Bits 7-0 of address_hi must be zero.
+
struct kvm_irq_routing_s390_adapter {
__u64 ind_addr;
__u64 summary_addr;
@@ -1583,6 +1587,15 @@ struct kvm_lapic_state {
Reads the Local APIC registers and copies them into the input argument. The
data format and layout are the same as documented in the architecture manual.
+If KVM_CAP_X2APIC_API is enabled, then the format of APIC_ID register depends
+on the APIC mode (reported by MSR_IA32_APICBASE) of its VCPU. x2APIC stores
+APIC ID in the APIC_ID register (bytes 32-35). xAPIC only allows an 8-bit APIC
+ID which is stored in bits 31-24 of the APIC register, or equivalently in byte
+35 of struct kvm_lapic_state's regs field.
+
+If KVM_CAP_X2APIC_API is disabled, struct kvm_lapic_state always uses xAPIC
+format.
+
4.58 KVM_SET_LAPIC
@@ -1600,6 +1613,10 @@ struct kvm_lapic_state {
Copies the input argument into the Local APIC registers. The data format
and layout are the same as documented in the architecture manual.
+The format of the APIC ID register (bytes 32-35 of struct kvm_lapic_state's
+regs field) depends on the state of the KVM_CAP_X2APIC_API capability.
+See the note in KVM_GET_LAPIC.
+
4.59 KVM_IOEVENTFD
@@ -2180,6 +2197,10 @@ struct kvm_msi {
No flags are defined so far. The corresponding field must be 0.
+On x86, address_hi is ignored unless the KVM_CAP_X2APIC_API capability is
+enabled. If it is enabled, address_hi bits 31-8 provide bits 31-8 of the
+destination id. Bits 7-0 of address_hi must be zero.
+
4.71 KVM_CREATE_PIT2
@@ -3811,6 +3832,17 @@ Allows use of runtime-instrumentation introduced with
zEC12 processor.
Will return -EINVAL if the machine does not support runtime-instrumentation.
Will return -EBUSY if a VCPU has already been created.
+7.7 KVM_CAP_X2APIC_API
+
+Architectures: x86
+Parameters: none
+Returns: 0
+
+Enabling this capability changes the behavior of KVM_SET_GSI_ROUTING,
+KVM_SIGNAL_MSI, KVM_SET_LAPIC, and KVM_GET_LAPIC, allowing the use of 32-bit
+APIC IDs. See KVM_CAP_X2APIC_API in their respective sections.
+
+
8. Other capabilities.
--
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 643e3dffcd85..f1b202b34c72 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -782,6 +782,8 @@ struct kvm_arch {
u32 ldr_mode;
struct page *avic_logical_id_table_page;
struct page *avic_physical_id_table_page;
+
+ bool x2apic_api;
};
struct kvm_vm_stat {
@@ -1364,7 +1366,7 @@ bool kvm_vcpu_is_bsp(struct kvm_vcpu *vcpu);
bool kvm_intr_is_single_vcpu(struct kvm *kvm, struct kvm_lapic_irq *irq,
struct kvm_vcpu **dest_vcpu);
-void kvm_set_msi_irq(struct kvm_kernel_irq_routing_entry *e,
+void kvm_set_m
[lkp] [btrfs] 407237cea1: RIP: [] btrfs_init_free_space_ctl+0x41/0x90
FYI, we noticed the following commit:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 407237cea1a068b2fad0455654c2f33266df79d2 ("btrfs: pull
node/sector/stripe sizes out of root and into fs_info")
in testcase: boot
on test machine: 2 threads qemu-system-x86_64 -enable-kvm -cpu
Haswell,+smep,+smap with 360M memory
caused below changes:
+--+++
| | 917a5648f6 | 407237cea1 |
+--+++
| boot_successes | 0 | 0 |
| boot_failures| 30 | 6 |
| WARNING:at_kernel/rcu/rcuperf.c:#rcu_perf_writer | 30 | 6 |
| BUG:unable_to_handle_kernel | 30 | 6 |
| Oops:#[##] | 30 | 6 |
| RIP:__setup_root | 30 ||
| Kernel_panic-not_syncing:Fatal_exception | 30 | 6 |
| backtrace:rcu_perf_writer| 30 | 6 |
| backtrace:btrfs_run_sanity_tests | 30 | 6 |
| backtrace:init_btrfs_fs | 30 | 6 |
| backtrace:kernel_init_freeable | 30 | 6 |
| RIP:btrfs_init_free_space_ctl| 0 | 6 |
| backtrace:btrfs_init_free_space_ctl | 0 | 6 |
+--+++
[ 23.337693] Btrfs loaded, crc32c=crc32c-generic, debug=on, assert=on
[ 23.338443] BTRFS: selftest: sectorsize: 4096 nodesize: 4096
[ 23.338476] BTRFS: selftest: Running btrfs free space cache tests
[ 23.338568] BUG: unable to handle kernel paging request at 25d8
[ 23.338602] IP: [] btrfs_init_free_space_ctl+0x41/0x90
[ 23.338606] PGD 0
[ 23.338631] Oops: [#1]
[ 23.338660] CPU: 0 PID: 1 Comm: swapper Tainted: GW
4.7.0-rc6-00052-g407237c #3
[ 23.338663] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Debian-1.8.2-1 04/01/2014
[ 23.338667] task: 880013c5 ti: 880013c44000 task.ti:
880013c44000
[ 23.338695] RIP: 0010:[] []
btrfs_init_free_space_ctl+0x41/0x90
[ 23.338699] RSP: :880013c47db0 EFLAGS: 00010286
[ 23.338701] RAX: RBX: 8800108dcc00 RCX:
[ 23.338703] RDX: 8310fb00 RSI: 81f3e7ce RDI: 8800108dcc80
[ 23.338727] RBP: 880013c47dc0 R08: 0001 R09: 8800108dcc00
[ 23.338729] R10: 0001 R11: R12: 8800161e4c00
[ 23.338732] R13: 08001000 R14: 81f2fd78 R15: 0800
[ 23.338736] FS: () GS:82221000()
knlGS:
[ 23.338760] CS: 0010 DS: ES: CR0: 80050033
[ 23.338762] CR2: 25d8 CR3: 0220c000 CR4: 06f0
[ 23.338793] Stack:
[ 23.338800] 8800161e4c00 1000 880013c47de8
8141fc5f
[ 23.338827] 1000 1000
880013c47e48
[ 23.338832] 8141e260 8818 1000
880013c47e10
[ 23.338855] Call Trace:
[ 23.338864] [] btrfs_alloc_dummy_block_group+0xbf/0xf0
[ 23.338891] [] btrfs_test_free_space_cache+0x40/0xe80
[ 23.338896] [] btrfs_run_sanity_tests+0xa8/0x140
[ 23.338924] [] ? do_early_param+0x8f/0x8f
[ 23.338954] [] init_btrfs_fs+0xd8/0x13d
[ 23.338959] [] ? debugfs_init+0x50/0x50
[ 23.339027] [] do_one_initcall+0x98/0x13d
[ 23.339055] [] ? do_early_param+0x8f/0x8f
[ 23.339060] [] kernel_init_freeable+0x100/0x194
[ 23.339091] [] kernel_init+0x9/0xf0
[ 23.339119] [] ret_from_fork+0x1f/0x40
[ 23.339146] [] ? rest_init+0xc0/0xc0
[ 23.339440] Code: 8b 9f 88 01 00 00 49 89 fc 48 89 df e8 49 de cf ff 49 8b
44 24 30 48 8d bb 80 00 00 00 48 c7 c2 00 fb 10 83 48 c7 c6 ce e7 f3 81 <8b> 80
d8 25 00 00 89 43 64 49 8b 04 24 4c 89 63 78 48 c7 43 70
[ 23.339447] RIP [] btrfs_init_free_space_ctl+0x41/0x90
[ 23.339471] RSP
[ 23.339473] CR2: 25d8
[ 23.339540] ---[ end trace 95f2e73b26a8f7da ]---
[ 23.339543] Kernel panic - not syncing: Fatal exception
[ 23.339606] Kernel Offset: disabled
FYI, raw QEMU command line is:
qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -kernel
/pkg/linux/x86_64-randconfig-s0-07080832/gcc-6/407237cea1a068b2fad0455654c2f33266df79d2/vmlinuz-4.7.0-rc6-00052-g407237c
-append 'root=/dev/ram0 user=lkp
job=/lkp/scheduled/vm-lkp-wsx03-quantal-x86_64-12/bisect_boot-1-quantal-core-x86_64.cgz-x86_64-randconfig-s0-07080832-407237cea1a068b2fad0455654c2f33266df79d2-20160708-80489-t0jhh0-0.yaml
ARCH=x
linux-next: manual merge of the kvm-ppc-paulus tree with the fsl tree
Hi Paul,
Today's linux-next merge of the kvm-ppc-paulus tree got a conflict in:
arch/powerpc/include/asm/paca.h
between commit:
c223c90386bc ("powerpc32: provide VIRT_CPU_ACCOUNTING")
from the fsl tree and commit:
fd7bacbca47a ("KVM: PPC: Book3S HV: Fix TB corruption in guest exit path on
HMI interrupt")
from the kvm-ppc-paulus tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/powerpc/include/asm/paca.h
index ad171e979ab0,4b17bd058e01..
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@@ -25,7 -25,7 +25,8 @@@
#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
#include
#endif
+#include
+ #include
register struct paca_struct *local_paca asm("r13");
Re: [kernel-hardening] Re: [PATCH 9/9] mm: SLUB hardened usercopy support
On Fri, Jul 08, 2016 at 04:48:38PM -0400, Kees Cook wrote:
> On Fri, Jul 8, 2016 at 1:41 PM, Kees Cook wrote:
> > On Fri, Jul 8, 2016 at 12:20 PM, Christoph Lameter wrote:
> >> On Fri, 8 Jul 2016, Kees Cook wrote:
> >>
> >>> Is check_valid_pointer() making sure the pointer is within the usable
> >>> size? It seemed like it was checking that it was within the slub
> >>> object (checks against s->size, wants it above base after moving
> >>> pointer to include redzone, etc).
> >>
> >> check_valid_pointer verifies that a pointer is pointing to the start of an
> >> object. It is used to verify the internal points that SLUB used and
> >> should not be modified to do anything different.
> >
> > Yup, no worries -- I won't touch it. :) I just wanted to verify my
> > understanding.
> >
> > And after playing a bit more, I see that the only thing to the left is
> > padding and redzone. SLUB layout, from what I saw:
> >
> > offset: what's there
> > ---
> > start: padding, redzone
> > red_left_pad: object itself
> > inuse: rest of metadata
> > size: start of next slub object
> >
> > (and object_size == inuse - red_left_pad)
> >
> > i.e. a pointer must be between red_left_pad and inuse, which is the
> > same as pointer - ref_left_pad being less than object_size.
> >
> > So, as found already, the position in the usercopy check needs to be
> > bumped down by red_left_pad, which is what Michael's fix does, so I'll
> > include it in the next version.
>
> Actually, after some offline chats, I think this is better, since it
> makes sure the ptr doesn't end up somewhere weird before we start the
> calculations. This leaves the pointer as-is, but explicitly handles
> the redzone on the offset instead, with no wrapping, etc:
>
> /* Find offset within object. */
> offset = (ptr - page_address(page)) % s->size;
>
> + /* Adjust for redzone and reject if within the redzone. */
> + if (s->flags & SLAB_RED_ZONE) {
> + if (offset < s->red_left_pad)
> + return s->name;
> + offset -= s->red_left_pad;
> + }
> +
> /* Allow address range falling entirely within object size. */
> if (offset <= s->object_size && n <= s->object_size - offset)
> return NULL;
>
As Christoph saids, please use slab_ksize() rather than
s->object_size.
Otherwise, looks good to me.
Thanks.
Re: [PATCH v6] mm, kasan: switch SLUB to stackdepot, enable memory quarantine for SLUB
On Fri, Jul 08, 2016 at 12:36:50PM +0200, Alexander Potapenko wrote:
> For KASAN builds:
> - switch SLUB allocator to using stackdepot instead of storing the
>allocation/deallocation stacks in the objects;
> - change the freelist hook so that parts of the freelist can be put
>into the quarantine.
>
> Signed-off-by: Alexander Potapenko
> ---
> v6: - addressed comments by Andrey Ryabinin:
> - move nearest_obj() back to header files
> - fix check_pad_bytes() to address problems with poisoning
> - don't define __OBJECT_POISON to 0
> - simplify slab_free_freelist_hook() implementation
> - move KASAN definintions used by SLUB code to include/linux/kasan.h
> - fix minor nits
> v5: - addressed comments by Andrey Ryabinin:
> - don't define SLAB_RED_ZONE, SLAB_POISON, SLAB_STORE_USER to 0
> - account for left redzone size when SLAB_RED_ZONE is used
> - incidentally moved the implementations of nearest_obj() to mm/sl[au]b.c
> v4: - addressed comments by Andrey Ryabinin:
> - don't set slub_debug by default for everyone;
> - introduce the ___cache_free() helper function.
> v3: - addressed comments by Andrey Ryabinin:
> - replaced KMALLOC_MAX_CACHE_SIZE with KMALLOC_MAX_SIZE in
> kasan_cache_create();
> - for caches with SLAB_KASAN flag set, their alloc_meta_offset and
> free_meta_offset are always valid.
> v2: - incorporated kbuild fixes by Andrew Morton
> ---
> include/linux/kasan.h| 23 ++
> include/linux/slab_def.h | 3 ++-
> include/linux/slub_def.h | 13 +++
> lib/Kconfig.kasan| 4 ++--
> mm/kasan/Makefile| 3 +--
> mm/kasan/kasan.c | 61
> ++--
> mm/kasan/kasan.h | 26 +
> mm/kasan/report.c| 8 +++
> mm/slab.h| 5 +++-
> mm/slub.c| 44 +++---
> 10 files changed, 114 insertions(+), 76 deletions(-)
>
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 611927f..99b9ffc 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -2,6 +2,7 @@
> #define _LINUX_KASAN_H
>
> #include
> +#include
> #include
>
> struct kmem_cache;
> @@ -20,6 +21,28 @@ extern pte_t kasan_zero_pte[PTRS_PER_PTE];
> extern pmd_t kasan_zero_pmd[PTRS_PER_PMD];
> extern pud_t kasan_zero_pud[PTRS_PER_PUD];
>
> +struct kasan_track {
> + u32 pid;
> + depot_stack_handle_t stack;
> +};
> +
> +struct kasan_alloc_meta {
> + struct kasan_track track;
> + u32 state : 2; /* enum kasan_state */
> + u32 alloc_size : 30;
> +};
> +
> +struct qlist_node {
> + struct qlist_node *next;
> +};
> +struct kasan_free_meta {
> + /* This field is used while the object is in the quarantine.
> + * Otherwise it might be used for the allocator freelist.
> + */
> + struct qlist_node quarantine_link;
> + struct kasan_track track;
> +};
> +
> void kasan_populate_zero_shadow(const void *shadow_start,
> const void *shadow_end);
>
> diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
> index 8694f7a..6f35df7 100644
> --- a/include/linux/slab_def.h
> +++ b/include/linux/slab_def.h
> @@ -88,7 +88,8 @@ struct kmem_cache {
> };
>
> static inline void *nearest_obj(struct kmem_cache *cache, struct page *page,
> - void *x) {
> + void *x)
> +{
> void *object = x - (x - page->s_mem) % cache->size;
> void *last_object = page->s_mem + (cache->num - 1) * cache->size;
>
> diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
> index d1faa01..07e4549 100644
> --- a/include/linux/slub_def.h
> +++ b/include/linux/slub_def.h
> @@ -99,6 +99,10 @@ struct kmem_cache {
>*/
> int remote_node_defrag_ratio;
> #endif
> +#ifdef CONFIG_KASAN
> + struct kasan_cache kasan_info;
> +#endif
> +
> struct kmem_cache_node *node[MAX_NUMNODES];
> };
>
> @@ -119,10 +123,11 @@ static inline void *nearest_obj(struct kmem_cache
> *cache, struct page *page,
> void *object = x - (x - page_address(page)) % cache->size;
> void *last_object = page_address(page) +
> (page->objects - 1) * cache->size;
> - if (unlikely(object > last_object))
> - return last_object;
> - else
> - return object;
> + void *result = (unlikely(object > last_object)) ? last_object : object;
> +
> + if (cache->flags & SLAB_RED_ZONE)
> + return ((char *)result + cache->red_left_pad);
> + return result;
As Andrey saids, it should be a separate patch. And, can we use
wrapper function, fixup_red_left()?
> }
>
> #endif /* _LINUX_SLUB_DEF_H */
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index 67d8c68..bd38aab 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -5,9 +5,9 @@ if HAVE_ARCH_KASAN
>
> con
Re: [PATCH v3] Add tw5864 driver
Hi Andrey, Thanks for this driver. Some review comments below: On 07/09/2016 09:46 PM, Andrey Utkin wrote: > From: Andrey Utkin > > > Changes in v3 since v2: > - Kconfig: select VIDEOBUF2_DMA_CONTIG, not SG > - drop i2c code as unused > - Dropped num_buffers check in queue_setup as suggested by Hans > - Drop std autodetect on streaming start as suggested by Hans > - Cleanup buf queue on enable_input() failure > - Change container_of() to list_entry() where applicable > - Changed V4L2_FIELD_NONE to V4L2_FIELD_INTERLACED as suggested > - frameinterval rework suggested by Hans > - Add enum_framesizes > - Report framesize based on std, not input w/h > - Add printed warning about known video quality issues > - MAINTAINERS: fix path > - request_mem_region() -> pci_request_regions() > - Rebase onto Hans' "for-v4.8i" branch > - Follow changes from patchset "vb2: replace allocation context by device > pointer" > > Below log is produced by today's v4l2-compliance from v4l-utils git, and this > patch based on branch "for-v4.8i" of > git://linuxtv.org/hverkuil/media_tree.git . > Compliance test runs fine. > > checkpatch.pl is happy with this patch except for artifacts_warning which > produces a bunch of such warnings: > > WARNING: quoted string split across lines > #155: FILE: drivers/media/pci/tw5864/tw5864-core.c:44: > +"This driver was developed by Bluecherry LLC by deducing behaviour of > original" > +" manufacturer's driver, from both source code and execution traces.\n" > > I believe I'd better not join all the lines to avoid them looking like > > "Paragraph one.\Paragraph two.\Paragraph three.\n" > > # v4l2-compliance -d 6 -s > v4l2-compliance SHA : 5e74f6a15aa14c01d8319e086d98f33d96a6a04d > > Driver Info: > Driver name : tw5864 > Card type : TW5864 Encoder 2 > Bus info : PCI::06:05.0 > Driver version: 4.7.0 > Capabilities : 0x8521 > Video Capture > Read/Write > Streaming > Extended Pix Format > Device Capabilities > Device Caps : 0x0521 > Video Capture > Read/Write > Streaming > Extended Pix Format > > Compliance test for device /dev/video6 (not using libv4l2): > > Required ioctls: > test VIDIOC_QUERYCAP: OK > > Allow for multiple opens: > test second video open: OK > test VIDIOC_QUERYCAP: OK > test VIDIOC_G/S_PRIORITY: OK > > Debug ioctls: > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) > test VIDIOC_LOG_STATUS: OK > > Input ioctls: > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > test VIDIOC_ENUMAUDIO: OK (Not Supported) > test VIDIOC_G/S/ENUMINPUT: OK > test VIDIOC_G/S_AUDIO: OK (Not Supported) > Inputs: 1 Audio Inputs: 0 Tuners: 0 > > Output ioctls: > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > Input/Output configuration ioctls: > test VIDIOC_ENUM/G/S/QUERY_STD: OK > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > test VIDIOC_G/S_EDID: OK (Not Supported) > > Test input 0: > > Control ioctls: > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK > test VIDIOC_QUERYCTRL: OK > test VIDIOC_G/S_CTRL: OK > test VIDIOC_G/S/TRY_EXT_CTRLS: OK > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > Standard Controls: 11 Private Controls: 0 > > Format ioctls: > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > test VIDIOC_G/S_PARM: OK > test VIDIOC_G_FBUF: OK (Not Supported) > test VIDIOC_G_FMT: OK > test VIDIOC_TRY_FMT: OK > test VIDIOC_S_FMT: OK > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) > test Cropping: OK (Not Supported) > test Composing: OK (Not Supported) > test Scaling: OK (Not Supported) > > Codec ioctls: > test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) > test VIDIOC_G_ENC_INDEX: OK (Not Supported) > test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) > > Buffer ioctls: > test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK > test VIDIOC_EXPBUF: OK > > Test i
Re: [PATCH 3/3] ARM: dts: exynos: correct the rtc compatible value for exynos5
On 07/09/2016 11:23 AM, Randy Li wrote:
> Those platforms are reported to use the same rtc IP core
> as exynos3250's.
Insufficient. Exynos4 also has to be updated. Actually all SoC from SoC
family requires rtc src clock. I think S3C6410 also requires it but I
don't have all the data necessary to confirm this.
Best regards,
Krzysztof
>
> Signed-off-by: Randy Li
> ---
> arch/arm/boot/dts/exynos3250.dtsi | 2 +-
> arch/arm/boot/dts/exynos5.dtsi| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 62f3dcd..cdd69a0 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -208,7 +208,7 @@
> };
>
> rtc: rtc@1007 {
> - compatible = "samsung,s3c6410-rtc";
> + compatible = "samsung,exynos3250-rtc";
> reg = <0x1007 0x100>;
> interrupts = <0 73 0>, <0 74 0>;
> interrupt-parent = <&pmu_system_controller>;
> diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
> index d5c0f18..71a1ad2 100644
> --- a/arch/arm/boot/dts/exynos5.dtsi
> +++ b/arch/arm/boot/dts/exynos5.dtsi
> @@ -88,7 +88,7 @@
> };
>
> rtc: rtc@101E {
> - compatible = "samsung,s3c6410-rtc";
> + compatible = "samsung,exynos3250-rtc";
> reg = <0x101E 0x100>;
> interrupts = <0 43 0>, <0 44 0>;
> status = "disabled";
>
Re: [PATCH 2/3] rtc: s3c: add device data for samsung,exynos3250-rtc
On 07/09/2016 11:23 AM, Randy Li wrote:
> The device data for samsung,exynos3250-rtc and samsung,s3c6410-rtc
> are just have a difference, but keeping using the same device data
> would cause the platform using the other IP core not work.
I cannot understand what you wanted to say here. Please rephrase it.
Why not just reverting a42e6eae457837d6a5925f4926f5ba05ccf44f89?
Best regards,
Krzysztof
>
> Signed-off-by: Randy Li
> ---
> drivers/rtc/rtc-s3c.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
> index 5dc18ca..e9f6151 100644
> --- a/drivers/rtc/rtc-s3c.c
> +++ b/drivers/rtc/rtc-s3c.c
> @@ -810,6 +810,18 @@ static struct s3c_rtc_data const s3c6410_rtc_data = {
> .disable= s3c6410_rtc_disable,
> };
>
> +static struct s3c_rtc_data const exynos3250_rtc_data = {
> + .max_user_freq = 32768,
> + .needs_src_clk = true,
> + .irq_handler= s3c6410_rtc_irq,
> + .set_freq = s3c6410_rtc_setfreq,
> + .enable_tick= s3c6410_rtc_enable_tick,
> + .save_tick_cnt = s3c6410_rtc_save_tick_cnt,
> + .restore_tick_cnt = s3c6410_rtc_restore_tick_cnt,
> + .enable = s3c24xx_rtc_enable,
> + .disable= s3c6410_rtc_disable,
> +};
> +
> static const struct of_device_id s3c_rtc_dt_match[] = {
> {
> .compatible = "samsung,s3c2410-rtc",
> @@ -825,7 +837,7 @@ static const struct of_device_id s3c_rtc_dt_match[] = {
> .data = (void *)&s3c6410_rtc_data,
> }, {
> .compatible = "samsung,exynos3250-rtc",
> - .data = (void *)&s3c6410_rtc_data,
> + .data = (void *)&exynos3250_rtc_data,
> },
> { /* sentinel */ },
> };
>
Re: [PATCH 1/3] Revert "drivers/rtc/rtc-s3c.c: add .needs_src_clk to s3c6410 RTC data"
On 07/09/2016 11:23 AM, Randy Li wrote:
> This reverts commit 8792f7772f4f40ffc68bad5f28311205584b734d.
> The s3c6410 rtc don't use rtc_src property, that property is designed
> for Exynos5250 and Exynos5440. The problem reported in the commit
> I mentioned should be fixed in the other way.
... so you break in this commit all the newer platforms because the
rtc_src clock won't be enabled.
Does not look right.
Best regards,
Krzysztof
>
> Signed-off-by: Randy Li
> ---
> drivers/rtc/rtc-s3c.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
> index d01ad7e..5dc18ca 100644
> --- a/drivers/rtc/rtc-s3c.c
> +++ b/drivers/rtc/rtc-s3c.c
> @@ -801,7 +801,6 @@ static struct s3c_rtc_data const s3c2443_rtc_data = {
>
> static struct s3c_rtc_data const s3c6410_rtc_data = {
> .max_user_freq = 32768,
> - .needs_src_clk = true,
> .irq_handler= s3c6410_rtc_irq,
> .set_freq = s3c6410_rtc_setfreq,
> .enable_tick= s3c6410_rtc_enable_tick,
>
Re: [PATCH v2 19/22] usb: chipidea: msm: Handle phy power states
On Thu, Jul 07, 2016 at 03:21:10PM -0700, Stephen Boyd wrote:
> The ULPI phy on qcom platforms needs to be initialized and
> powered on after a USB reset and before we toggle the run/stop
> bit. Otherwise, the phy locks up and doesn't work properly. Hook
> the phy initialization into the RESET event and the phy power off
> into the STOPPED event.
>
> Cc: Peter Chen
> Cc: Greg Kroah-Hartman
> ---
> drivers/usb/chipidea/ci_hdrc_msm.c | 40
> +++---
> drivers/usb/chipidea/core.c| 8 ++--
> drivers/usb/chipidea/host.c| 8 ++--
> include/linux/usb/chipidea.h | 2 +-
> 4 files changed, 33 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index ab6a7713ee5c..5c486c15e043 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -75,20 +75,33 @@ static const struct reset_control_ops
> ci_hdrc_msm_reset_ops = {
> .reset = ci_hdrc_msm_por_reset,
> };
>
> -static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
> +static int ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
> {
> struct device *dev = ci->dev->parent;
> struct ci_hdrc_msm *msm_ci = dev_get_drvdata(dev);
> + int ret;
>
> switch (event) {
> case CI_HDRC_CONTROLLER_RESET_EVENT:
> dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
> +
> + hw_phymode_configure(ci);
> if (msm_ci->secondary_phy) {
> u32 val = readl_relaxed(msm_ci->base + HS_PHY_SEC_CTRL);
> val |= HS_PHY_DIG_CLAMP_N;
> writel_relaxed(val, msm_ci->base + HS_PHY_SEC_CTRL);
> }
>
> + ret = phy_init(ci->phy);
> + if (ret)
> + return ret;
> +
> + ret = phy_power_on(ci->phy);
> + if (ret) {
> + phy_exit(ci->phy);
> + return ret;
> + }
> +
> /* use AHB transactor, allow posted data writes */
> hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
>
> @@ -108,21 +121,18 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc
> *ci, unsigned event)
>HSPHY_SESS_VLD_CTRL);
>
> }
> -
> - usb_phy_init(ci->usb_phy);
> break;
> case CI_HDRC_CONTROLLER_STOPPED_EVENT:
> dev_dbg(dev, "CI_HDRC_CONTROLLER_STOPPED_EVENT received\n");
> - /*
> - * Put the phy in non-driving mode. Otherwise host
> - * may not detect soft-disconnection.
> - */
> - usb_phy_notify_disconnect(ci->usb_phy, USB_SPEED_UNKNOWN);
> + phy_power_off(ci->phy);
> + phy_exit(ci->phy);
> break;
> default:
> dev_dbg(dev, "unknown ci_hdrc event\n");
> break;
> }
> +
> + return 0;
> }
>
> static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
> @@ -162,7 +172,6 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
> {
> struct ci_hdrc_msm *ci;
> struct platform_device *plat_ci;
> - struct usb_phy *phy;
> struct clk *clk;
> struct reset_control *reset;
> struct resource *res;
> @@ -176,21 +185,12 @@ static int ci_hdrc_msm_probe(struct platform_device
> *pdev)
> return -ENOMEM;
> platform_set_drvdata(pdev, ci);
>
> - /*
> - * OTG(PHY) driver takes care of PHY initialization, clock management,
> - * powering up VBUS, mapping of registers address space and power
> - * management.
> - */
> - phy = devm_usb_get_phy_by_phandle(&pdev->dev, "usb-phy", 0);
> - if (IS_ERR(phy))
> - return PTR_ERR(phy);
> -
> ci->pdata.name = "ci_hdrc_msm";
> ci->pdata.capoffset = DEF_CAPOFFSET;
> ci->pdata.flags = CI_HDRC_REGS_SHARED | CI_HDRC_DISABLE_STREAMING |
> - CI_HDRC_OVERRIDE_AHB_BURST;
> + CI_HDRC_OVERRIDE_AHB_BURST |
> + CI_HDRC_OVERRIDE_PHY_CONTROL;
> ci->pdata.notify_event = ci_hdrc_msm_notify_event;
> - ci->pdata.usb_phy = phy;
>
> reset = devm_reset_control_get(&pdev->dev, "core");
> if (IS_ERR(reset))
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index f144e1bbcc82..0866c03d66df 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -327,6 +327,7 @@ void hw_phymode_configure(struct ci_hdrc *ci)
> hw_write(ci, OP_PORTSC, PORTSC_STS, PORTSC_STS);
> }
> }
> +EXPORT_SYMBOL_GPL(hw_phymode_configure);
>
> /**
> * _ci_usb_phy_init: initialize phy taking in account both phy and usb_phy
> @@ -503,9 +504,12 @@ int hw_device_reset(struct ci_hdrc *ci)
> return ret;
> }
>
> - if (
Re: [PATCH v2 20/22] usb: chipidea: msm: Be silent on probe defer errors
On Thu, Jul 07, 2016 at 03:21:11PM -0700, Stephen Boyd wrote:
> If something fails in ci_hdrc_add_device() due to probe defer, we
> shouldn't print an error message. Be silent in this case as we'll
> try probe again later.
>
> Cc: Peter Chen
> Cc: Greg Kroah-Hartman
> Signed-off-by: Stephen Boyd
> ---
> drivers/usb/chipidea/ci_hdrc_msm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 5c486c15e043..d4cc45f8e65e 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -257,8 +257,9 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
> plat_ci = ci_hdrc_add_device(&pdev->dev, pdev->resource,
>pdev->num_resources, &ci->pdata);
> if (IS_ERR(plat_ci)) {
> - dev_err(&pdev->dev, "ci_hdrc_add_device failed!\n");
> ret = PTR_ERR(plat_ci);
> + if (ret != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "ci_hdrc_add_device failed!\n");
> goto err_mux;
> }
>
Acked-by: Peter Chen
--
Best Regards,
Peter Chen
Re: [PATCH 0/3] making rtc cores from s3c6410 and exynos3250 both work
On 07/09/2016 11:23 AM, Randy Li wrote: > The 8792f7772f4f40ffc68bad5f28311205584b734d would just make those > platform using rtc core from exynos3250 work but have a huge > effect on those platforms using the rtc core from s3c6410. > These patches would fix this problem. > Which problem? What huge effect? On which platforms? You didn't describe it... Your change breaks the ABI and is not compatible with current bindings documentation. Best regards, Krzysztof > Randy Li (3): > Revert "drivers/rtc/rtc-s3c.c: add .needs_src_clk to s3c6410 RTC data" > rtc: s3c: add device data for samsung,exynos3250-rtc > ARM: dts: exynos: correct the rtc compatible value for exynos5 > > arch/arm/boot/dts/exynos3250.dtsi | 2 +- > arch/arm/boot/dts/exynos5.dtsi| 2 +- > drivers/rtc/rtc-s3c.c | 15 +-- > 3 files changed, 15 insertions(+), 4 deletions(-) >
Re: [PATCH v2 18/22] usb: chipidea: msm: Add reset controller for PHY POR bit
On Thu, Jul 07, 2016 at 03:21:09PM -0700, Stephen Boyd wrote:
> The MSM chipidea wrapper has two bits that are used to reset the
> first or second phy. Add support for these bits via the reset
> controller framework, so that phy drivers can reset their
> hardware at the right time during initialization.
>
> Cc: Peter Chen
> Cc: Greg Kroah-Hartman
> Signed-off-by: Stephen Boyd
> ---
> drivers/usb/chipidea/Kconfig | 1 +
> drivers/usb/chipidea/ci_hdrc_msm.c | 45
> --
> 2 files changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
> index 4f8c342a8865..488ecdf56bdd 100644
> --- a/drivers/usb/chipidea/Kconfig
> +++ b/drivers/usb/chipidea/Kconfig
> @@ -2,6 +2,7 @@ config USB_CHIPIDEA
> tristate "ChipIdea Highspeed Dual Role Controller"
> depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD &&
> !USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA
> select EXTCON
> + select RESET_CONTROLLER
> help
> Say Y here if your system has a dual role high speed USB
> controller based on ChipIdea silicon IP. Currently, only the
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index da2d399acdd2..ab6a7713ee5c 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -31,8 +32,10 @@
> #define HSPHY_SESS_VLD_CTRL BIT(25)
>
> /* Vendor base starts at 0x200 beyond CI base */
> +#define HS_PHY_CTRL 0x0040
> #define HS_PHY_SEC_CTRL 0x0078
> #define HS_PHY_DIG_CLAMP_N BIT(16)
> +#define HS_PHY_POR_ASSERTBIT(0)
>
> struct ci_hdrc_msm {
> struct platform_device *ci;
> @@ -40,11 +43,38 @@ struct ci_hdrc_msm {
> struct clk *iface_clk;
> struct clk *fs_clk;
> struct ci_hdrc_platform_data pdata;
> + struct reset_controller_dev rcdev;
> bool secondary_phy;
> bool hsic;
> void __iomem *base;
> };
>
> +static int
> +ci_hdrc_msm_por_reset(struct reset_controller_dev *r, unsigned long id)
> +{
> + struct ci_hdrc_msm *ci_msm = container_of(r, struct ci_hdrc_msm, rcdev);
> + void __iomem *addr = ci_msm->base;
> + u32 val;
> +
> + if (id)
> + addr += HS_PHY_SEC_CTRL;
> + else
> + addr += HS_PHY_CTRL;
> +
> + val = readl_relaxed(addr);
> + val |= HS_PHY_POR_ASSERT;
> + writel(val, addr);
> + udelay(12);
Does this delay is reference manual defines or experienced value?
Do you need to comment it?
Peter
> + val &= ~HS_PHY_POR_ASSERT;
> + writel(val, addr);
> +
> + return 0;
> +}
> +
> +static const struct reset_control_ops ci_hdrc_msm_reset_ops = {
> + .reset = ci_hdrc_msm_por_reset,
> +};
> +
> static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
> {
> struct device *dev = ci->dev->parent;
> @@ -186,10 +216,18 @@ static int ci_hdrc_msm_probe(struct platform_device
> *pdev)
> if (!ci->base)
> return -ENOMEM;
>
> - ret = clk_prepare_enable(ci->fs_clk);
> + ci->rcdev.owner = THIS_MODULE;
> + ci->rcdev.ops = &ci_hdrc_msm_reset_ops;
> + ci->rcdev.of_node = pdev->dev.of_node;
> + ci->rcdev.nr_resets = 2;
> + ret = reset_controller_register(&ci->rcdev);
> if (ret)
> return ret;
>
> + ret = clk_prepare_enable(ci->fs_clk);
> + if (ret)
> + goto err_fs;
> +
> reset_control_assert(reset);
> usleep_range(1, 12000);
> reset_control_deassert(reset);
> @@ -198,7 +236,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>
> ret = clk_prepare_enable(ci->core_clk);
> if (ret)
> - return ret;
> + goto err_fs;
>
> ret = clk_prepare_enable(ci->iface_clk);
> if (ret)
> @@ -236,6 +274,8 @@ err_mux:
> clk_disable_unprepare(ci->iface_clk);
> err_iface:
> clk_disable_unprepare(ci->core_clk);
> +err_fs:
> + reset_controller_unregister(&ci->rcdev);
> return ret;
> }
>
> @@ -247,6 +287,7 @@ static int ci_hdrc_msm_remove(struct platform_device
> *pdev)
> ci_hdrc_remove_device(ci->ci);
> clk_disable_unprepare(ci->iface_clk);
> clk_disable_unprepare(ci->core_clk);
> + reset_controller_unregister(&ci->rcdev);
>
> return 0;
> }
> --
> 2.9.0.rc2.8.ga28705d
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
Re: [PATCH v2 17/22] usb: chipidea: msm: Make platform data driver local instead of global
On Thu, Jul 07, 2016 at 03:21:08PM -0700, Stephen Boyd wrote:
> If two devices are probed with this same driver, they'll share
> the same platform data structure, while the chipidea core layer
> writes and modifies it. This can lead to interesting results
> especially if one device is an OTG type chipidea controller and
> another is a host. Let's create a copy of this structure per each
> device instance so that odd things don't happen.
>
> Cc: Peter Chen
> Cc: Greg Kroah-Hartman
> Signed-off-by: Stephen Boyd
> ---
> drivers/usb/chipidea/ci_hdrc_msm.c | 20
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 81437c8cea82..da2d399acdd2 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -39,6 +39,7 @@ struct ci_hdrc_msm {
> struct clk *core_clk;
> struct clk *iface_clk;
> struct clk *fs_clk;
> + struct ci_hdrc_platform_data pdata;
> bool secondary_phy;
> bool hsic;
> void __iomem *base;
> @@ -94,16 +95,6 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci,
> unsigned event)
> }
> }
>
> -static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
> - .name = "ci_hdrc_msm",
> - .capoffset = DEF_CAPOFFSET,
> - .flags = CI_HDRC_REGS_SHARED |
> - CI_HDRC_DISABLE_STREAMING |
> - CI_HDRC_OVERRIDE_AHB_BURST,
> -
> - .notify_event = ci_hdrc_msm_notify_event,
> -};
> -
> static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
> struct platform_device *pdev)
> {
> @@ -164,7 +155,12 @@ static int ci_hdrc_msm_probe(struct platform_device
> *pdev)
> if (IS_ERR(phy))
> return PTR_ERR(phy);
>
> - ci_hdrc_msm_platdata.usb_phy = phy;
> + ci->pdata.name = "ci_hdrc_msm";
> + ci->pdata.capoffset = DEF_CAPOFFSET;
> + ci->pdata.flags = CI_HDRC_REGS_SHARED | CI_HDRC_DISABLE_STREAMING |
> + CI_HDRC_OVERRIDE_AHB_BURST;
> + ci->pdata.notify_event = ci_hdrc_msm_notify_event;
> + ci->pdata.usb_phy = phy;
>
> reset = devm_reset_control_get(&pdev->dev, "core");
> if (IS_ERR(reset))
> @@ -221,7 +217,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
> of_node_put(ulpi_node);
>
> plat_ci = ci_hdrc_add_device(&pdev->dev, pdev->resource,
> - pdev->num_resources,
> &ci_hdrc_msm_platdata);
> + pdev->num_resources, &ci->pdata);
Acked-by: Peter Chen
--
Best Regards,
Peter Chen
[RFC PATCH v2] clk: move check of CLK_SET_RATE_GATE flag to clk_propagate_rate_change()
From: Jiada Wang
Previously CLK_SET_RATE_GATE flag is only checked in clk_set_rate()
which only ensures the clock being called by clk_set_rate() won't
change rate when it has been prepared if CLK_SET_RATE_GATE flag is set.
But a clk_set_rate() request may propagate rate change to these clocks
from the requested clock's topmost parent clock to all its offsprings,
when any one of these clocks has CLK_SET_RATE_GATE flag set
and it has been prepared, the clk_set_rate() request should fail.
This patch moves check of CLK_SET_RATE_GATE flag to
clk_propagate_rate_change() to ensure all affected clocks will
be checked if their rate will be changed after clk_set_rate().
Signed-off-by: Jiada Wang
---
drivers/clk/clk.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 820a939..2f930c8 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1437,6 +1437,9 @@ static struct clk_core *clk_propagate_rate_change(struct
clk_core *core,
if (core->rate == core->new_rate)
return NULL;
+ if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
+ return core;
+
if (core->notifier_count) {
ret = __clk_notify(core, event, core->rate, core->new_rate);
if (ret & NOTIFY_STOP_MASK)
@@ -1571,9 +1574,6 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
if (rate == clk_core_get_rate_nolock(core))
return 0;
- if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
- return -EBUSY;
-
/* calculate new rates and get the topmost changed clock */
top = clk_calc_new_rates(core, rate);
if (!top)
--
1.7.9.5
Re: [PATCH v2 16/22] usb: chipidea: msm: Restore wrapper settings after reset
On Thu, Jul 07, 2016 at 03:21:07PM -0700, Stephen Boyd wrote:
> When the RESET bit is set in the USBCMD register it resets quite
> a few of the wrapper's registers to their reset state. This
> includes the GENCONFIG and GENCONFIG2 registers. Currently this
> is done by the usb phy and ehci-msm drivers writing into the
> controller wrapper's MMIO address space. Let's consolidate the
> register writes into the wrapper driver instead so that we
> clearly split the wrapper from the phys.
>
> Cc: Peter Chen
> Cc: Greg Kroah-Hartman
> Signed-off-by: Stephen Boyd
> ---
> drivers/usb/chipidea/ci_hdrc_msm.c | 39
> ++
> 1 file changed, 39 insertions(+)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 7708bee3ff3e..81437c8cea82 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -14,11 +14,22 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "ci.h"
>
> #define HS_PHY_AHB_MODE 0x0098
>
> +#define HS_PHY_GENCONFIG 0x009c
> +#define HS_PHY_TXFIFO_IDLE_FORCE_DIS BIT(4)
> +
> +#define HS_PHY_GENCONFIG_2 0x00a0
> +#define HS_PHY_SESS_VLD_CTRL_EN BIT(7)
> +#define HS_PHY_ULPI_TX_PKT_EN_CLR_FIXBIT(19)
> +
> +#define HSPHY_SESS_VLD_CTRL BIT(25)
> +
Keep alignment please
Others are ok.
Acked-by: Peter Chen
> /* Vendor base starts at 0x200 beyond CI base */
> #define HS_PHY_SEC_CTRL 0x0078
> #define HS_PHY_DIG_CLAMP_N BIT(16)
> @@ -29,6 +40,7 @@ struct ci_hdrc_msm {
> struct clk *iface_clk;
> struct clk *fs_clk;
> bool secondary_phy;
> + bool hsic;
> void __iomem *base;
> };
>
> @@ -48,6 +60,24 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci,
> unsigned event)
>
> /* use AHB transactor, allow posted data writes */
> hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
> +
> + /* workaround for rx buffer collision issue */
> + hw_write_id_reg(ci, HS_PHY_GENCONFIG,
> + HS_PHY_TXFIFO_IDLE_FORCE_DIS, 0);
> +
> + if (!msm_ci->hsic)
> + hw_write_id_reg(ci, HS_PHY_GENCONFIG_2,
> + HS_PHY_ULPI_TX_PKT_EN_CLR_FIX, 0);
> +
> + if (ci->platdata->vbus_extcon.edev) {
> + hw_write_id_reg(ci, HS_PHY_GENCONFIG_2,
> + HS_PHY_SESS_VLD_CTRL_EN,
> + HS_PHY_SESS_VLD_CTRL_EN);
> + hw_write(ci, OP_USBCMD, HSPHY_SESS_VLD_CTRL,
> + HSPHY_SESS_VLD_CTRL);
> +
> + }
> +
> usb_phy_init(ci->usb_phy);
> break;
> case CI_HDRC_CONTROLLER_STOPPED_EVENT:
> @@ -116,6 +146,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
> struct reset_control *reset;
> struct resource *res;
> int ret;
> + struct device_node *ulpi_node, *phy_node;
>
> dev_dbg(&pdev->dev, "ci_hdrc_msm_probe\n");
>
> @@ -181,6 +212,14 @@ static int ci_hdrc_msm_probe(struct platform_device
> *pdev)
> if (ret)
> goto err_mux;
>
> + ulpi_node = of_find_node_by_name(pdev->dev.of_node, "ulpi");
> + if (ulpi_node) {
> + phy_node = of_get_next_available_child(ulpi_node, NULL);
> + ci->hsic = of_device_is_compatible(phy_node,
> "qcom,usb-hsic-phy");
> + of_node_put(phy_node);
> + }
> + of_node_put(ulpi_node);
> +
> plat_ci = ci_hdrc_add_device(&pdev->dev, pdev->resource,
>pdev->num_resources,
> &ci_hdrc_msm_platdata);
> if (IS_ERR(plat_ci)) {
> --
> 2.9.0.rc2.8.ga28705d
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
Re: linux-next: build failure after merge of the pm tree
Hi Mika, On Mon, 11 Jul 2016 07:48:17 +0300 Mika Westerberg wrote: > > Looks like it is the module name (configfs.o) that confuses modpost or > linker. The below patch fixes it for me. That makes sense. Thanks. -- Cheers, Stephen Rothwell
Re: linux-next: manual merge of the clockevents tree with the arm-soc tree
Hi all,
On Thu, 7 Jul 2016 14:12:26 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the clockevents tree got a conflict in:
>
> arch/arm/Kconfig
>
> between commit:
>
> c86f51737f8d ("ARM: clps711x: Switch to MULTIPLATFORM")
>
> from the arm-soc tree and commit:
>
> 250e46aa3bb3 ("clocksource/drivers/clps_711x: Add the COMPILE_TEST option")
>
> from the clockevents tree.
>
> I fixed it up (I used the arm-soc version of this file and then added
> the following merge fix 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.
>
> From: Stephen Rothwell
> Date: Thu, 7 Jul 2016 13:59:06 +1000
> Subject: [PATCH] clocksource/drivers/clps_711x: fixup for "ARM: clps711x:
> Switch to MULTIPLATFORM"
>
> Signed-off-by: Stephen Rothwell
> ---
> arch/arm/mach-clps711x/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-clps711x/Kconfig b/arch/arm/mach-clps711x/Kconfig
> index 3b56197ccfd0..dc7c6edeab39 100644
> --- a/arch/arm/mach-clps711x/Kconfig
> +++ b/arch/arm/mach-clps711x/Kconfig
> @@ -3,8 +3,8 @@ menuconfig ARCH_CLPS711X
> depends on ARCH_MULTI_V4T
> select ARCH_REQUIRE_GPIOLIB
> select AUTO_ZRELADDR
> - select CLKSRC_MMIO
> select CLKSRC_OF
> + select CLPS711X_TIMER
> select COMMON_CLK
> select CPU_ARM720T
> select GENERIC_CLOCKEVENTS
> --
> 2.8.1
This merge fix is now applicable to the merge between the arm-soc tree
and the tip tree.
Also, the clockevents tree needs to be cleaned up as all its commits
have been added to the tip tree as different commits (but the same
patches) :-(
--
Cheers,
Stephen Rothwell
Re: [PATCH v15 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Hi Felipe, On 1 July 2016 at 14:05, Baolin Wang wrote: > Currently the Linux kernel does not provide any standard integration of this > feature that integrates the USB subsystem with the system power regulation > provided by PMICs meaning that either vendors must add this in their kernels > or USB gadget devices based on Linux (such as mobile phones) may not behave > as they should. Thus provide a standard framework for doing this in kernel. > > Now introduce one user with wm831x_power to support and test the usb charger, > which is pending testing. Moreover there may be other potential users will use > it in future. > > Changes since v14: > - Add kernel documentation for struct usb_cahrger. > - Remove some redundant WARN() functions. > > Changes since v13: > - Remove the charger checking in usb_gadget_vbus_draw() function. > - Rename some functions in charger.c file. > - Rebase on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > tags/usb-for-v4.8 > > Changes since v12: > - Remove the class and device things. > - Link usb charger to udc-core.ko. > - Create one "charger" subdirectory which holds all charger-related > attributes. > > Changes since v11: > - Reviewed and tested by Li Jun. > > Changes since v10: > - Introduce usb_charger_get_state() function to check charger state. > - Remove the mutex lock in usb_charger_set_cur_limit_by_type() function > in case will be issued in atomic context. > > Baolin Wang (4): > usb: gadget: Introduce the usb charger framework > usb: gadget: Support for the usb charger framework > usb: gadget: Integrate with the usb gadget supporting for usb charger > power: wm831x_power: Support USB charger current limit management > > drivers/power/wm831x_power.c | 69 > drivers/usb/gadget/Kconfig |8 + > drivers/usb/gadget/udc/Makefile |1 + > drivers/usb/gadget/udc/charger.c | 738 > ++ > drivers/usb/gadget/udc/core.c| 17 + > include/linux/mfd/wm831x/pdata.h |3 + > include/linux/usb/charger.h | 183 ++ > include/linux/usb/gadget.h |3 + > include/uapi/linux/usb/charger.h | 31 ++ > 9 files changed, 1053 insertions(+) > create mode 100644 drivers/usb/gadget/udc/charger.c > create mode 100644 include/linux/usb/charger.h > create mode 100644 include/uapi/linux/usb/charger.h > > -- > 1.7.9.5 > Do you have any other comments about this v15 patchset? If not, could you please add this version patchset into your 'next' branch? Thanks a lot. -- Baolin.wang Best Regards
linux-next: manual merge of the tip tree with the kspp tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/kernel/x86_init.c
between commit:
255303026193 ("x86: apply more __ro_after_init and const")
from the kspp tree and commit:
1bf8915ae515 ("x86/tsc: Enumerate SKL cpu_khz and tsc_khz via CPUID")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/kernel/x86_init.c
index 111b838db7fe,58b459296e13..
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@@ -91,7 -91,8 +91,8 @@@ struct x86_cpuinit_ops x86_cpuinit =
static void default_nmi_init(void) { };
static int default_i8042_detect(void) { return 1; };
-struct x86_platform_ops x86_platform = {
+struct x86_platform_ops x86_platform __ro_after_init = {
+ .calibrate_cpu = native_calibrate_cpu,
.calibrate_tsc = native_calibrate_tsc,
.get_wallclock = mach_get_cmos_time,
.set_wallclock = mach_set_rtc_mmss,
Re: [lkp] [ext4] 5405511e1a: ltp.acl_test01.fail]
Hi, Theodore
On Sun, Jul 10, 2016 at 11:15:53PM -0400, Theodore Ts'o wrote:
>On Mon, Jul 11, 2016 at 09:59:54AM +0800, kernel test robot wrote:
>>
>> FYI, we noticed the following commit:
>>
>> https://github.com/0day-ci/linux
>> Vegard-Nossum/ext4-validate-number-of-clusters-in-group/20160708-041426
>> commit 5405511e1a984ab644fa9e29a0d3d958b835ab75 ("ext4: validate number of
>> meta clusters in group")
>
>Hi, many thanks for the report. One question -- is there some way the
>reporting could be speeded up? Vegard's patch was sent late on the
>7th, and it looks like it hit the 0day-ci git repo a few hours later
>on the 8th, and was run early in the morning Chinese time. Was the
>delay until the 11th due to the weekend and the desire to have a human
>sanity check the result? Is that because there was a concern that
>there would be too many false positives?
Yes, you're right, although we have auto report feature (which has much
less delay) for high confidence errors/regressions detected, we still need
human sanity check for other cases to avoid too many false positives, it
will introduce some delays especially in weekend, sorry for that. We'll
improve our auto report part to cover more sensible cases.
>
>Also, if there was some way the 0day robot report could include a
>In-Reply-To: header to the patch being sent to the mailing list (in
>this case: <577eb740.10...@oracle.com>), it would make this even
>*more* useful.
>
Good point! We'll add this feature later.
Thanks,
Xiaolong
>
>Vegard, I'm guessing you didn't have a chance to test your patch
>before you sent it to the list?
>
> bit_max = ext4_num_clusters_in_group(sb, i);
> if ((bit_max >> 3) >= sb->s_blocksize) {
> ext4_msg(sb, KERN_WARNING, "clusters in "
> "group %u exceeds block size", i);
> goto failed_mount;
> }
>
>
>This is the test which is failing, but it will fail by default on
>pretty much all ext4 file systems, since by default there will be
>32768 blocks (clusters) per group, with a 4k block size (and 32768 >>
>3 == 4096). And in the test that failed, this was a 1k block size
>with 8192 blocks per blocks (and 8192 >> 3 == 1024).
>
>Anyway, as I mentioned before, I'd much rather do very specific sanity
>checking on superblock fields, instead of sanity checking calculated
>values such as ext4_num_clusters_in_group().
>
>Perhaps the easist thing to do is to run e2fsck -n on those file
>systems that are causing problems?
>
>Cheers,
>
> - Ted
Re: [PATCH v7 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga
From: Date: Thu, 7 Jul 2016 20:23:30 -0700 > From: Tien Hock Loh > > This adds support for TSE PCS that uses SGMII adapter when the phy-mode of > the dwmac is set to sgmii. > > Signed-off-by: Tien Hock Loh > Acked-by: Rob Herring Applied to net-next, thanks.
Re: [PATCH] spi: spi-ti-qspi: clear wlen field while setting word length.
Hi Prahlad,
On Sunday 10 July 2016 01:35 AM, Prahlad V wrote:
> When a word length of 1 byte is selected and writing data of length
> more than QSPI_WLEN_MAX_BYTES, first MAX_BYTES will be transfered
> and remaining will be transfered byte by byte. In that case wlen
> field should be cleared before setting.
>
> Signed-off-by: Prahlad V
> ---
> drivers/spi/spi-ti-qspi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
> index 29ea8d2..6c61f54 100644
> --- a/drivers/spi/spi-ti-qspi.c
> +++ b/drivers/spi/spi-ti-qspi.c
> @@ -276,9 +276,9 @@ static int qspi_write_msg(struct ti_qspi *qspi, struct
> spi_transfer *t,
> cmd |= QSPI_WLEN(QSPI_WLEN_MAX_BITS);
> } else {
> writeb(*txbuf, qspi->base + QSPI_SPI_DATA_REG);
> - cmd = qspi->cmd | QSPI_WR_SNGL;
qspi->cmd always has WLEN field cleared and set to WLEN = 1 byte (see
ti_qspi_start_transfer_one()). And hence variable 'cmd' will also have
WLEN set to 1 byte.
> xfer_len = wlen;
> - cmd |= QSPI_WLEN(wlen);
> + cmd = ((qspi->cmd & ~QSPI_WLEN_MASK) |
> + QSPI_WLEN(wlen));
So, this won't be necessary.
--
Regards
Vignesh
Re: [PATCH v3] sched/deadline: remove useless param from setup_new_dl_entity
On 2016/07/08 at 19:28, Juri Lelli wrote:
> setup_new_dl_entity() takes two parameters, but it only actually uses
> one of them, under a different name, to setup a new dl_entity, after:
>
> 2f9f3fdc928 "sched/deadline: Remove dl_new from struct sched_dl_entity"
>
> as we currently do
>
> setup_new_dl_entity(&p->dl, &p->dl)
>
> However, before Luca's change we were doing
>
> setup_new_dl_entity(dl_se, pi_se)
>
> in update_dl_entity() for a dl_se->new entity: we were using pi_se's
> parameters (the potential PI donor) for setting up a new entity.
>
> Restore this behaviour (as we want to correctly initialize parameters of
> a boosted task that enters DEADLINE) by removing the useless second
> parameter of setup_new_dl_entity() and retrieving the top waiter
> directly from inside that function.
>
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Steven Rostedt
> Cc: Luca Abeni
> Signed-off-by: Juri Lelli
>
> ---
> Changes from v2:
>- optimize by calling rt_mutex_get_top_task only if the task is
> boosted (as suggested by Steve)
>
> Changes from v1:
>- Steve pointed out that we were actually using the second parameter
> to permorm initialization
>- Luca confirmed that behavior is slightly changed w.r.t. before his
> change
>- changelog updated and original behavior restored
> ---
> kernel/sched/deadline.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index fcb7f0217ff4..7aeb21963d3c 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -346,11 +346,12 @@ static void check_preempt_curr_dl(struct rq *rq, struct
> task_struct *p,
> * one, and to (try to!) reconcile itself with its own scheduling
> * parameters.
> */
> -static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se,
> -struct sched_dl_entity *pi_se)
> +static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se)
> {
> struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
> struct rq *rq = rq_of_dl_rq(dl_rq);
> + struct task_struct *pi_task;
> + struct sched_dl_entity *pi_se = dl_se;
>
> WARN_ON(dl_time_before(rq_clock(rq), dl_se->deadline));
>
> @@ -363,6 +364,15 @@ static inline void setup_new_dl_entity(struct
> sched_dl_entity *dl_se,
> return;
>
> /*
> + * Use the scheduling parameters of the top pi-waiter task,
> + * if we have one from which we can inherit a deadline.
> + */
> + if (dl_se->dl_boosted &&
> + (pi_task = rt_mutex_get_top_task(dl_task_of(dl_se))) &&
> + dl_prio(pi_task->normal_prio))
> + pi_se = &pi_task->dl;
> +
> + /*
>* We use the regular wall clock time to set deadlines in the
>* future; in fact, we must consider execution overheads (time
>* spent on hardirq context, etc.).
> @@ -1721,7 +1731,7 @@ static void switched_from_dl(struct rq *rq, struct
> task_struct *p)
> static void switched_to_dl(struct rq *rq, struct task_struct *p)
> {
> if (dl_time_before(p->dl.deadline, rq_clock(rq)))
> - setup_new_dl_entity(&p->dl, &p->dl);
> + setup_new_dl_entity(&p->dl);
I'm curious why we even call setup_new_dl_entity() for non-queued cases?
It seems more reasonable to do it when it really gets queued. We can see
that enqueue_task_dl()->update_dl_entity() also has the same update logic
as switched_to_dl().
If so, for already queued and boosted cases, rt_mutex_setprio() will call
enqueue_task() with ENQUEUE_REPLENISH set, so enqueue_dl_entity()
->replenish_dl_entity() will advance p->dl.deadline beforehand, see code:
replenish_dl_entity():
if (dl_se->dl_deadline == 0) {
dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline;
dl_se->runtime = pi_se->dl_runtime;
}
IOW, we don't need to handle !dl boosted cases in setup_new_dl_entity().
Regards,
Xunlei
>
> if (task_on_rq_queued(p) && rq->curr != p) {
> #ifdef CONFIG_SMP
Re: [RFT PATCH v5 0/3] Fix preemption timer optimization while nested guests run
2016-07-08 20:02 GMT+08:00 Paolo Bonzini : > As mentioned earlier, I don't have a reproducer yet that requires any > changes beyond Wanpeng's (patch 1)---it's possible of course to write > a kvm-unit-test testcase but I haven't had time for that yet. > > Thanks, > > Paolo Bonzini (2): > KVM: VMX: reflect broken preemption timer in vmcs_config > KVM: nVMX: keep preemption timer enabled during L2 execution Cool, this patchset works after my testing. Feel free to add my Tested-by for your two patches. :) Regards, Wanpeng Li
[RFC PATCH] clk: move check of CLK_SET_RATE_GATE flag to clk_propagate_rate_change()
From: Jiada Wang
Previously CLK_SET_RATE_GATE flag is only checked in clk_set_rate()
which only ensures the clock being called by clk_set_rate() won't
change rate when it has been prepared if CLK_SET_RATE_GATE flag is set.
But a clk_set_rate() request may propagate rate change to these clocks
from the requested clock's topmost parent clock to all its offsprings,
when any one of these clocks has CLK_SET_RATE_GATE flag set
and it has been prepared, the clk_set_rate() request should fail.
This patch moves check of CLK_SET_RATE_GATE flag to
clk_propagate_rate_change() to ensure all affected clocks will
be checked if their rate will be changed after clk_set_rate().
Signed-off-by: Jiada Wang
---
drivers/clk/clk.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 820a939..aa5e4c3 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1437,6 +1437,9 @@ static struct clk_core *clk_propagate_rate_change(struct
clk_core *core,
if (core->rate == core->new_rate)
return NULL;
+ if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
+ return -EBUSY;
+
if (core->notifier_count) {
ret = __clk_notify(core, event, core->rate, core->new_rate);
if (ret & NOTIFY_STOP_MASK)
@@ -1571,9 +1574,6 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
if (rate == clk_core_get_rate_nolock(core))
return 0;
- if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
- return -EBUSY;
-
/* calculate new rates and get the topmost changed clock */
top = clk_calc_new_rates(core, rate);
if (!top)
--
1.7.9.5
linux-next: manual merge of the block tree with the f2fs tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in:
fs/f2fs/data.c
between commits:
19a5f5e2ef37 ("f2fs: drop any block plugging")
52763a4b7a21 ("f2fs: detect host-managed SMR by feature flag")
78682f794479 ("f2fs: fix to avoid reading out encrypted data in page cache")
from the f2fs tree and commits:
4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio")
04d328defd06 ("f2fs: use bio op accessors")
from the block tree.
I fixed it up (see below - I am not confident of these fixups, so
please check and let me know if anything else is needed) and can carry
the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/f2fs/data.c
index 20b30162e7b4,8769e8349dff..
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@@ -100,16 -97,11 +100,16 @@@ static struct bio *__bio_alloc(struct f
return bio;
}
- static inline void __submit_bio(struct f2fs_sb_info *sbi, int rw,
- struct bio *bio, enum page_type type)
-static inline void __submit_bio(struct f2fs_sb_info *sbi, struct bio *bio)
++static inline void __submit_bio(struct f2fs_sb_info *sbi, struct bio *bio,
++ enum page_type type)
{
- if (!is_read_io(rw)) {
- if (!is_read_io(bio_op(bio)))
++ if (!is_read_io(bio_op(bio))) {
atomic_inc(&sbi->nr_wb_bios);
+ if (f2fs_sb_mounted_hmsmr(sbi->sb) &&
+ current->plug && (type == DATA || type == NODE))
+ blk_finish_plug(current->plug);
+ }
- submit_bio(rw, bio);
+ submit_bio(bio);
}
static void __submit_merged_bio(struct f2fs_bio_info *io)
@@@ -124,7 -116,9 +124,9 @@@
else
trace_f2fs_submit_write_bio(io->sbi->sb, fio, io->bio);
- __submit_bio(io->sbi, fio->rw, io->bio, fio->type);
+ bio_set_op_attrs(io->bio, fio->op, fio->op_flags);
+
- __submit_bio(io->sbi, io->bio);
++ __submit_bio(io->sbi, io->bio, fio->type);
io->bio = NULL;
}
@@@ -241,8 -237,10 +245,10 @@@ int f2fs_submit_page_bio(struct f2fs_io
bio_put(bio);
return -EFAULT;
}
+ bio->bi_rw = fio->op_flags;
+ bio_set_op_attrs(bio, fio->op, fio->op_flags);
- __submit_bio(fio->sbi, fio->rw, bio, fio->type);
- __submit_bio(fio->sbi, bio);
++ __submit_bio(fio->sbi, bio, fio->type);
return 0;
}
@@@ -1080,13 -1057,36 +1087,14 @@@ got_it
*/
if (bio && (last_block_in_bio != block_nr - 1)) {
submit_and_realloc:
- __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
- __submit_bio(F2FS_I_SB(inode), bio);
++ __submit_bio(F2FS_I_SB(inode), bio, DATA);
bio = NULL;
}
if (bio == NULL) {
- struct fscrypt_ctx *ctx = NULL;
-
- if (f2fs_encrypted_inode(inode) &&
- S_ISREG(inode->i_mode)) {
-
- ctx = fscrypt_get_ctx(inode, GFP_NOFS);
- if (IS_ERR(ctx))
- goto set_error_page;
-
- /* wait the page to be moved by cleaning */
- f2fs_wait_on_encrypted_page_writeback(
- F2FS_I_SB(inode), block_nr);
- }
-
- bio = bio_alloc(GFP_KERNEL,
- min_t(int, nr_pages, BIO_MAX_PAGES));
- if (!bio) {
- if (ctx)
- fscrypt_release_ctx(ctx);
+ bio = f2fs_grab_bio(inode, block_nr, nr_pages);
+ if (IS_ERR(bio))
goto set_error_page;
- }
- bio->bi_bdev = bdev;
- bio->bi_iter.bi_sector = SECTOR_FROM_BLOCK(block_nr);
- bio->bi_end_io = f2fs_read_end_io;
- bio->bi_private = ctx;
+ bio_set_op_attrs(bio, REQ_OP_READ, 0);
}
if (bio_add_page(bio, page, blocksize, 0) < blocksize)
@@@ -1101,7 -1101,7 +1109,7 @@@ set_error_page
goto next_page;
confused:
if (bio) {
- __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
- __submit_bio(F2FS_I_SB(inode), bio);
++ __submit_bio(F2FS_I_SB(inode), bio, DATA);
Re: [PATCH v2 15/22] usb: chipidea: msm: Mux over secondary phy at the right time
On Thu, Jul 07, 2016 at 03:21:06PM -0700, Stephen Boyd wrote:
> We need to pick the correct phy at runtime based on how the SoC
> has been wired onto the board. If the secondary phy is used, take
> it out of reset and mux over to it by writing into the TCSR
> register. Make sure to do this on reset too, because this
> register is reset to the default value (primary phy) after the
> RESET bit is set in USBCMD.
>
> Cc: Peter Chen
> Cc: Greg Kroah-Hartman
> Signed-off-by: Stephen Boyd
> ---
> drivers/usb/chipidea/ci_hdrc_msm.c | 67
> +++---
> 1 file changed, 62 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 7e870a253f55..7708bee3ff3e 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -8,29 +8,44 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> #include "ci.h"
>
> #define HS_PHY_AHB_MODE 0x0098
>
> +/* Vendor base starts at 0x200 beyond CI base */
> +#define HS_PHY_SEC_CTRL 0x0078
> +#define HS_PHY_DIG_CLAMP_N BIT(16)
> +
Keep alignment
> struct ci_hdrc_msm {
> struct platform_device *ci;
> struct clk *core_clk;
> struct clk *iface_clk;
> struct clk *fs_clk;
> + bool secondary_phy;
> + void __iomem *base;
> };
>
> static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
> {
> - struct device *dev = ci->gadget.dev.parent;
> + struct device *dev = ci->dev->parent;
> + struct ci_hdrc_msm *msm_ci = dev_get_drvdata(dev);
>
> switch (event) {
> case CI_HDRC_CONTROLLER_RESET_EVENT:
> dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
> + if (msm_ci->secondary_phy) {
> + u32 val = readl_relaxed(msm_ci->base + HS_PHY_SEC_CTRL);
> + val |= HS_PHY_DIG_CLAMP_N;
> + writel_relaxed(val, msm_ci->base + HS_PHY_SEC_CTRL);
> + }
> +
> /* use AHB transactor, allow posted data writes */
> hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
> usb_phy_init(ci->usb_phy);
> @@ -59,6 +74,39 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata =
> {
> .notify_event = ci_hdrc_msm_notify_event,
> };
>
> +static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
> +struct platform_device *pdev)
> +{
> + struct regmap *regmap;
> + struct device *dev = &pdev->dev;
> + struct of_phandle_args args;
> + u32 val;
> + int ret;
> +
> + ret = of_parse_phandle_with_fixed_args(dev->of_node, "phy-select", 2, 0,
> +&args);
> + if (ret)
> + return 0;
> +
> + regmap = syscon_node_to_regmap(args.np);
> + of_node_put(args.np);
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + ret = regmap_write(regmap, args.args[0], args.args[1]);
> + if (ret)
> + return ret;
> +
> + ci->secondary_phy = !!args.args[1];
> + if (ci->secondary_phy) {
> + val = readl_relaxed(ci->base + HS_PHY_SEC_CTRL);
> + val |= HS_PHY_DIG_CLAMP_N;
> + writel_relaxed(val, ci->base + HS_PHY_SEC_CTRL);
> + }
> +
> + return 0;
> +}
> +
> static int ci_hdrc_msm_probe(struct platform_device *pdev)
> {
> struct ci_hdrc_msm *ci;
> @@ -66,6 +114,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
> struct usb_phy *phy;
> struct clk *clk;
> struct reset_control *reset;
> + struct resource *res;
> int ret;
>
> dev_dbg(&pdev->dev, "ci_hdrc_msm_probe\n");
> @@ -105,6 +154,11 @@ static int ci_hdrc_msm_probe(struct platform_device
> *pdev)
> ci->fs_clk = NULL;
> }
>
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + ci->base = devm_ioremap_resource(&pdev->dev, res);
> + if (!ci->base)
> + return -ENOMEM;
> +
> ret = clk_prepare_enable(ci->fs_clk);
> if (ret)
> return ret;
> @@ -123,9 +177,12 @@ static int ci_hdrc_msm_probe(struct platform_device
> *pdev)
> if (ret)
> goto err_iface;
>
> - plat_ci = ci_hdrc_add_device(&pdev->dev,
> - pdev->resource, pdev->num_resources,
> - &ci_hdrc_msm_platdata);
> + ret = ci_hdrc_msm_mux_phy(ci, pdev);
> + if (ret)
> + goto err_mux;
> +
> + plat_ci = ci_hdrc_add_device(&pdev->dev, pdev->resource,
> + pdev->num_resources,
> &ci_hdrc_msm_platdata);
The above line has not changed.
After fixing above, you can add my ack.
Acked-by: Peter Chen
--
Best Regards,
Peter Chen
Re: linux-next: build failure after merge of the pm tree
On Mon, Jul 11, 2016 at 11:46:53AM +1000, Stephen Rothwell wrote:
> Hi Rafael,
>
> After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> ERROR: "configfs_unregister_subsystem" [samples/configfs/configfs_sample.ko]
> undefined!
> ERROR: "configfs_register_subsystem" [samples/configfs/configfs_sample.ko]
> undefined!
> ERROR: "config_group_init" [samples/configfs/configfs_sample.ko] undefined!
> ERROR: "config_item_init_type_name" [samples/configfs/configfs_sample.ko]
> undefined!
> ERROR: "config_group_init_type_name" [samples/configfs/configfs_sample.ko]
> undefined!
> ERROR: "configfs_undepend_item" [fs/ocfs2/cluster/ocfs2_nodemanager.ko]
> undefined!
> ERROR: "config_item_put" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] undefined!
> ERROR: "config_item_init_type_name" [fs/ocfs2/cluster/ocfs2_nodemanager.ko]
> undefined!
>
> ... and many more ...
>
> Presumably (maybe?) caused by commit
>
> 0bf54fcd9504 ("ACPI: add support for configfs")
>
> though it is not obvious why this should be a problem.
Looks like it is the module name (configfs.o) that confuses modpost or
linker. The below patch fixes it for me.
From: Mika Westerberg
Subject: [PATCH] ACPI: Rename configfs.c to acpi_configfs.c to prevent link
error
If we compile ACPI configfs.c as module it will confuse the linker as it
hides symbols from the actual configfs:
Kernel: arch/x86/boot/bzImage is ready (#1236)
MODPOST 5739 modules
ERROR: "configfs_unregister_subsystem" [samples/configfs/configfs_sample.ko]
undefined!
ERROR: "configfs_register_subsystem" [samples/configfs/configfs_sample.ko]
undefined!
ERROR: "config_group_init" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "config_item_init_type_name" [samples/configfs/configfs_sample.ko]
undefined!
ERROR: "config_group_init_type_name" [samples/configfs/configfs_sample.ko]
undefined!
ERROR: "configfs_undepend_item" [fs/ocfs2/cluster/ocfs2_nodemanager.ko]
undefined!
...
Prevent these by renaming the file to acpi_configfs.c instead.
Reported-by: Scott Lawson
Signed-off-by: Mika Westerberg
---
drivers/acpi/Makefile| 2 +-
drivers/acpi/{configfs.c => acpi_configfs.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename drivers/acpi/{configfs.c => acpi_configfs.c} (100%)
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 1dc2173ad8d0..f72a83df1cf3 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -99,6 +99,6 @@ obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o
obj-$(CONFIG_PMIC_OPREGION)+= pmic/intel_pmic.o
obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
-obj-$(CONFIG_ACPI_CONFIGFS)+= configfs.o
+obj-$(CONFIG_ACPI_CONFIGFS)+= acpi_configfs.o
video-objs += acpi_video.o video_detect.o
diff --git a/drivers/acpi/configfs.c b/drivers/acpi/acpi_configfs.c
similarity index 100%
rename from drivers/acpi/configfs.c
rename to drivers/acpi/acpi_configfs.c
--
2.8.1
Re: [PATCH v2 14/22] usb: chipidea: msm: Add proper clk and reset support
On Thu, Jul 07, 2016 at 03:21:05PM -0700, Stephen Boyd wrote:
> The msm chipidea controller uses two main clks, an AHB clk to
> read/write the MMIO registers and a core clk called the system
> clk that drives the controller itself. Add support for these clks
> as they're required in all designs.
>
> Also add support for an optional third clk that we need to turn
> on to reset the controller and wrapper logic and other
> "housekeeping" things. This clk was removed in later revisions of
> the hardware because the reset methodology no longer required
> clks to be enabled to propagate resets.
>
> Cc: Peter Chen
> Cc: Greg Kroah-Hartman
> Signed-off-by: Stephen Boyd
> ---
> drivers/usb/chipidea/ci_hdrc_msm.c | 72
> +++---
> 1 file changed, 68 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index b282a717bf8c..7e870a253f55 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -10,11 +10,20 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "ci.h"
>
> #define HS_PHY_AHB_MODE 0x0098
>
> +struct ci_hdrc_msm {
> + struct platform_device *ci;
> + struct clk *core_clk;
> + struct clk *iface_clk;
> + struct clk *fs_clk;
> +};
> +
> static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
> {
> struct device *dev = ci->gadget.dev.parent;
> @@ -52,11 +61,20 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata
> = {
>
> static int ci_hdrc_msm_probe(struct platform_device *pdev)
> {
> + struct ci_hdrc_msm *ci;
> struct platform_device *plat_ci;
> struct usb_phy *phy;
> + struct clk *clk;
> + struct reset_control *reset;
> + int ret;
>
> dev_dbg(&pdev->dev, "ci_hdrc_msm_probe\n");
>
> + ci = devm_kzalloc(&pdev->dev, sizeof(*ci), GFP_KERNEL);
> + if (!ci)
> + return -ENOMEM;
> + platform_set_drvdata(pdev, ci);
> +
> /*
>* OTG(PHY) driver takes care of PHY initialization, clock management,
>* powering up VBUS, mapping of registers address space and power
> @@ -68,29 +86,75 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>
> ci_hdrc_msm_platdata.usb_phy = phy;
>
> + reset = devm_reset_control_get(&pdev->dev, "core");
> + if (IS_ERR(reset))
> + return PTR_ERR(reset);
> +
> + ci->core_clk = clk = devm_clk_get(&pdev->dev, "core");
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + ci->iface_clk = clk = devm_clk_get(&pdev->dev, "iface");
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + ci->fs_clk = clk = devm_clk_get(&pdev->dev, "fs");
> + if (IS_ERR(clk)) {
> + if (PTR_ERR(clk) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + ci->fs_clk = NULL;
> + }
> +
> + ret = clk_prepare_enable(ci->fs_clk);
> + if (ret)
> + return ret;
> +
> + reset_control_assert(reset);
> + usleep_range(1, 12000);
> + reset_control_deassert(reset);
> +
> + clk_disable_unprepare(ci->fs_clk);
> +
> + ret = clk_prepare_enable(ci->core_clk);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(ci->iface_clk);
> + if (ret)
> + goto err_iface;
> +
> plat_ci = ci_hdrc_add_device(&pdev->dev,
> pdev->resource, pdev->num_resources,
> &ci_hdrc_msm_platdata);
> if (IS_ERR(plat_ci)) {
> dev_err(&pdev->dev, "ci_hdrc_add_device failed!\n");
> - return PTR_ERR(plat_ci);
> + ret = PTR_ERR(plat_ci);
> + goto err_mux;
> }
>
> - platform_set_drvdata(pdev, plat_ci);
> + ci->ci = plat_ci;
>
> pm_runtime_set_active(&pdev->dev);
> pm_runtime_no_callbacks(&pdev->dev);
> pm_runtime_enable(&pdev->dev);
>
> return 0;
> +
> +err_mux:
> + clk_disable_unprepare(ci->iface_clk);
> +err_iface:
> + clk_disable_unprepare(ci->core_clk);
> + return ret;
> }
>
> static int ci_hdrc_msm_remove(struct platform_device *pdev)
> {
> - struct platform_device *plat_ci = platform_get_drvdata(pdev);
> + struct ci_hdrc_msm *ci = platform_get_drvdata(pdev);
>
> pm_runtime_disable(&pdev->dev);
> - ci_hdrc_remove_device(plat_ci);
> + ci_hdrc_remove_device(ci->ci);
> + clk_disable_unprepare(ci->iface_clk);
> + clk_disable_unprepare(ci->core_clk);
>
> return 0;
> }
> --
Acked-by: Peter Chen
--
Best Regards,
Peter Chen
Re: [PATCH] vcodec: mediatek: Add g/s_selection support for V4L2 Encoder
Hi Tiffany,
My apologies for the delay, but here is my review at last:
On 05/30/2016 09:52 AM, Tiffany Lin wrote:
> This patch add g/s_selection support for MT8173
>
> Signed-off-by: Tiffany Lin
> ---
> drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 74
>
> 1 file changed, 74 insertions(+)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> index 6e72d73..23ef9a1 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> @@ -630,6 +630,77 @@ static int vidioc_try_fmt_vid_out_mplane(struct file
> *file, void *priv,
> return vidioc_try_fmt(f, fmt);
> }
>
> +static int vidioc_venc_g_selection(struct file *file, void *priv,
> + struct v4l2_selection *s)
> +{
> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> + struct mtk_q_data *q_data;
> +
> + /* crop means compose for output devices */
> + switch (s->target) {
> + case V4L2_SEL_TGT_CROP_DEFAULT:
> + case V4L2_SEL_TGT_CROP_BOUNDS:
> + case V4L2_SEL_TGT_CROP:
> + case V4L2_SEL_TGT_COMPOSE_DEFAULT:
> + case V4L2_SEL_TGT_COMPOSE_BOUNDS:
> + case V4L2_SEL_TGT_COMPOSE:
> + if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + mtk_v4l2_err("Invalid s->type = %d", s->type);
> + return -EINVAL;
> + }
> + break;
> + default:
> + mtk_v4l2_err("Invalid s->target = %d", s->target);
> + return -EINVAL;
> + }
> +
> + q_data = mtk_venc_get_q_data(ctx, s->type);
> + if (!q_data)
> + return -EINVAL;
> +
> + s->r.top = 0;
> + s->r.left = 0;
> + s->r.width = q_data->visible_width;
> + s->r.height = q_data->visible_height;
> +
> + return 0;
> +}
> +
> +static int vidioc_venc_s_selection(struct file *file, void *priv,
> + struct v4l2_selection *s)
> +{
> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> + struct mtk_q_data *q_data;
> +
> + switch (s->target) {
> + case V4L2_SEL_TGT_CROP_DEFAULT:
> + case V4L2_SEL_TGT_CROP_BOUNDS:
> + case V4L2_SEL_TGT_CROP:
> + case V4L2_SEL_TGT_COMPOSE_DEFAULT:
> + case V4L2_SEL_TGT_COMPOSE_BOUNDS:
> + case V4L2_SEL_TGT_COMPOSE:
> + if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + mtk_v4l2_err("Invalid s->type = %d", s->type);
> + return -EINVAL;
> + }
> + break;
> + default:
> + mtk_v4l2_err("Invalid s->target = %d", s->target);
> + return -EINVAL;
> + }
> +
> + q_data = mtk_venc_get_q_data(ctx, s->type);
> + if (!q_data)
> + return -EINVAL;
> +
> + s->r.top = 0;
> + s->r.left = 0;
> + q_data->visible_width = s->r.width;
> + q_data->visible_height = s->r.height;
This makes no sense.
See this page:
https://hverkuil.home.xs4all.nl/spec/media.html#selection-api
For the video output direction (memory -> HW encoder) the data source is
the memory, the data sink is the HW encoder. For the video capture direction
(HW encoder -> memory) the data source is the HW encoder and the data sink
is the memory.
Usually for m2m devices the video output direction may support cropping and
the video capture direction may support composing.
It's not clear what you intend here, especially since you set left and right
to 0. That's not what the selection operation is supposed to do.
Regards,
Hans
> +
> + return 0;
> +}
> +
> static int vidioc_venc_qbuf(struct file *file, void *priv,
> struct v4l2_buffer *buf)
> {
> @@ -688,6 +759,9 @@ const struct v4l2_ioctl_ops mtk_venc_ioctl_ops = {
>
> .vidioc_create_bufs = v4l2_m2m_ioctl_create_bufs,
> .vidioc_prepare_buf = v4l2_m2m_ioctl_prepare_buf,
> +
> + .vidioc_g_selection = vidioc_venc_g_selection,
> + .vidioc_s_selection = vidioc_venc_s_selection,
> };
>
> static int vb2ops_venc_queue_setup(struct vb2_queue *vq,
>
Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls
On Jul 9, 2016 1:37 AM, "Ingo Molnar" wrote: > > > * Dave Hansen wrote: > > > On 07/08/2016 12:18 AM, Ingo Molnar wrote: > > > > > So the question is, what is user-space going to do? Do any glibc patches > > > exist? How are the user-space library side APIs going to look like? > > > > My goal at the moment is to get folks enabled to the point that they can > > start > > modifying apps to use pkeys without having to patch their kernels. > > I don't have confidence that we can design good high-level userspace > > interfaces > > without seeing some real apps try to use the low-level ones and seeing how > > they > > struggle. > > > > I had some glibc code to do the pkey alloc/free operations, but those aren't > > necessary if we're doing it in the kernel. Other than getting the syscall > > wrappers in place, I don't have any immediate plans to do anything in glibc. > > > > Was there something you were expecting to see? > > Yeah, so (as you probably guessed!) I'm starting to have second thoughts > about the > complexity of the alloc/free/set/get interface I suggested, and Mel's review > certainly strengthened that feeling. > > I have two worries: > > 1) > > A technical worry I have is that the 'pkey allocation interface' does not > seem to > be taking the per thread property of pkeys into account - while that property > would be useful for apps. That is a limitation that seems unjustified. > > The reason for this is that we are storing the key allocation bitmap in > struct_mm, > in mm->context.pkey_allocation_map - while we should be storing it in > task_struct > or thread_info. Huh? Doesn't this have to be per mm? Sure, PKRU is per thread, but the page tables are shared. > 2) > > My main worry is that it appears at this stage that we are still pretty far > away > from completely shadowing the hardware pkey state in the kernel - and without > that > we cannot really force user-space to use the 'proper' APIs. They can just use > the > raw instructions, condition them on a CPUID and be done with it: everything > can be > organized in user-space. > My vote would be to keep the allocation mechanism but get rid of pkey_set. Also, I think the debug poisoning feature is overcomplicated. Let's just forbid mprotect_key with an unallocated key. There are still two issues that I think we need to address, though: 1. Signal delivery shouldn't unconditionally clear PKRU. That's what the current patches do, and it's unsafe. I'd rather set PKRU to the maximally locked down state on signal delivery (except for the PROT_EXEC key), although that might cause its own set of problems. 2. When thread A allocates a pkey, how does it lock down thread B? #2 could be addressed by using fully-locked-down as the initial state post-exec() and copying the state on clone(). Dave, are there any cases in practice where one thread would allocate a pkey and want other threads to immediately have access to the memory with that key? I find myself wondering whether we should stop using XSAVE for PKRU sooner rather than later. If we do anything like the above, we completely lose the init optimization, and the code would be a good deal simpler if we switched PKRU directly in switch_to and could therefore treat it like a normal register everywhere else. --Andy
Re: [PATCH] arm64: defconfig: Enable more IP blocks for Exynos7 and Exynos5433
Hi Krzysztof, On 07/09/2016 01:47 AM, Krzysztof Kozlowski wrote: Enable more drivers for IP blocks for existing Exynos7 and upcoming Exynos5433: 1. SPI, 2. Watchdog, 3. USB: DWC3, Exynos EHCI and OHCI, 4. Exynos ADC, 5. Samsung PWM. These are already used by Exynos7 Espresso board or will be used by Exynos5433 based board. Signed-off-by: Krzysztof Kozlowski Thanks for posting this patch. Reviewed-by: Alim Akhtar --- If there are no objections, I can take it through Samsung SoC tree. --- arch/arm64/configs/defconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index c05b8badec2c..fe6d6c34323a 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -183,6 +183,7 @@ CONFIG_SPI_ORION=y CONFIG_SPI_PL022=y CONFIG_SPI_QUP=y CONFIG_SPI_SPIDEV=m +CONFIG_SPI_S3C64XX=y CONFIG_SPMI=y CONFIG_PINCTRL_SINGLE=y CONFIG_PINCTRL_MSM8916=y @@ -202,6 +203,7 @@ CONFIG_THERMAL_EMULATION=y CONFIG_EXYNOS_THERMAL=y CONFIG_WATCHDOG=y CONFIG_RENESAS_WDT=y +CONFIG_S3C2410_WATCHDOG=y CONFIG_MFD_SPMI_PMIC=y CONFIG_MFD_SEC_CORE=y CONFIG_MFD_HI655X_PMIC=y @@ -221,18 +223,22 @@ CONFIG_SOUND=y CONFIG_SND=y CONFIG_SND_SOC=y CONFIG_SND_SOC_RCAR=y +CONFIG_SND_SOC_SAMSUNG=y CONFIG_SND_SOC_AK4613=y CONFIG_USB=y CONFIG_USB_OTG=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_RCAR=y +CONFIG_USB_EHCI_EXYNOS=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_MSM=y CONFIG_USB_EHCI_HCD_PLATFORM=y +CONFIG_USB_OHCI_EXYNOS=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_HCD_PLATFORM=y CONFIG_USB_STORAGE=y CONFIG_USB_DWC2=y +CONFIG_USB_DWC3=y CONFIG_USB_CHIPIDEA=y CONFIG_USB_CHIPIDEA_UDC=y CONFIG_USB_CHIPIDEA_HOST=y @@ -304,6 +310,10 @@ CONFIG_PHY_HI6220_USB=y CONFIG_PHY_XGENE=y CONFIG_ARM_SCPI_PROTOCOL=y CONFIG_ACPI=y +CONFIG_IIO=y +CONFIG_EXYNOS_ADC=y +CONFIG_PWM=y +CONFIG_PWM_SAMSUNG=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_FANOTIFY=y
Re: [PATCH v3 0/9] Add MT8173 Video Decoder Driver
Hi Hans, On Fri, 2016-07-08 at 13:44 +0200, Hans Verkuil wrote: > On 07/07/2016 12:16 PM, tiffany lin wrote: > > Hi Hans, > > > > > > On Wed, 2016-07-06 at 15:19 +0200, Hans Verkuil wrote: > >> Hi Tiffany, > >> > >> I plan to review this patch series on Friday, but one obvious question is > >> what the reason for these failures is: > >> > >>> Input/Output configuration ioctls: > >>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) > >>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > >>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > >>> test VIDIOC_G/S_EDID: OK (Not Supported) > >>> > >>> Control ioctls: > >>> test VIDIOC_QUERYCTRL/MENU: OK > >>> fail: > >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-controls.cpp(357): > >>> g_ctrl returned an error (11) > >>> test VIDIOC_G/S_CTRL: FAIL > >>> fail: > >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-controls.cpp(579): > >>> g_ext_ctrls returned an error (11) > >>> test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL > > These fails are because VIDIOC_G_CTRL and VIDIOC_G_EXT_CTRLS return > > V4L2_CID_MIN_BUFFERS_FOR_CAPTURE only when dirver in MTK_STATE_HEADER > > state, or it will return EAGAIN. > > This could help user space get correct value, not default value that may > > changed base on media content. > > OK, I really don't like this. I also looked what the s5p-mfc-dec driver does > (the only other > driver currently implementing this), and that returns -EINVAL. > > My proposal would be to change this. If this information isn't known yet, why > not > just return 0 as the value? The doc would have to be updated and (preferably) > also > the s5p-mfc-dec driver. I've added Samsung devs to the Cc list, let me know > what you > think. > Got it. We will return 0 as the value instead EAGAIN. > > > >>> fail: > >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-controls.cpp(721): > >>> subscribe event for control 'User Controls' failed > >>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL > > Driver do not support subscribe event for control 'User Controls' for > > now. > > Do we need to support this? > > I don't see why this would fail. It's OK to subscribe to such controls, > although > you'll never get an event. > Got it. I will rerun using latest v4l2-compliance test check this. > >>> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > >>> Standard Controls: 2 Private Controls: 0 > >>> > >>> Format ioctls: > >>> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > >>> test VIDIOC_G/S_PARM: OK (Not Supported) > >>> test VIDIOC_G_FBUF: OK (Not Supported) > >>> fail: > >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-formats.cpp(405): > >>> expected EINVAL, but got 11 when getting format for buftype 9 > >>> test VIDIOC_G_FMT: FAIL > > This is because vidioc_vdec_g_fmt only succeed when context is in > > MTK_STATE_HEADER state, or user space cannot get correct format data > > using this function. > > Comparing this to s5p-mfc-dec I see that -EINVAL is returned in that case. > > I am not opposed to using EAGAIN in s5p-mfc-dec as well. Marek, Kamil, what is > your opinion? > > > > >>> test VIDIOC_TRY_FMT: OK (Not Supported) > >>> test VIDIOC_S_FMT: OK (Not Supported) > >>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) > >>> > >>> Codec ioctls: > >>> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) > >>> test VIDIOC_G_ENC_INDEX: OK (Not Supported) > >>> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) > >>> > >>> Buffer ioctls: > >>> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK > >>> fail: > >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(500): > >>> q.has_expbuf(node) > > Our OUTPUT and CAPTURE queue support both VB2_DMABUF and VB2_MMAP, user > > space can select which to use in runtime. > > So our driver default support v4l2_m2m_ioctl_expbuf functionality. > > In v4l2-compliance test, it will check v4l2_m2m_ioctl_expbuf only valid > > when node->valid_memorytype is V4L2_MEMORY_MMAP. > > So when go through node->valid_memorytype is V4L2_MEMORY_DMABUF, it > > fail. > > valid_memorytype should have both MMAP and DMABUF flags. > > But v4l-utils-1.6.0 is way too old to be certain it isn't some > v4l2-compliance bug > that has since been fixed. > Got it. I will rerun using master branch to check this. best regards, Tiffany > Regards, > > Hans > > > > > > > best regards, > > Tiffany > > > > > > > >>> test VIDIOC_EXPBUF: FAIL > >>> > >>> > >>> Total: 38, Succeeded: 33, Failed: 5, Warnings: 0 > >> > >> If it is due to a bug in v4l
Linux 4.7-rc7
We've had a nicely calm week, which is what I expected - the last rc really was bigger just due to random timing issues, and not some worrying pattern about this release cycle. Whew. Anyway, there's a couple of regressions still being looked at, but unless anything odd happens, this is going to be the last rc. However, due to my travel schedule, I won't be doing the final 4.7 next weekend, and people will have two weeks to report (and fix) any remaining bugs. Yeah, that's the ticket. My travel schedule isn't screwing anything up, instead think of it as you guys getting a BONUS WEEK! Yay! Ok, my travel schedule probably _is_ screwing somebody's plans up, for which I apologize in advance. And hey, even that planned delay could obviously change, if somebody finds some real killer bug. But it doesn't look all that likely, considering that this hasn't been a particularly big or scary release cycle. But do go out and test. The appended shortlog gives the details on the preceding calm week, but the overview is very normal: two thirds drivers (networking, sound, gpio, misc), with the rest being pretty evenly split between arch fixes and "misc" (in this case mostly core kernel, networking, and ecryptfs). But all of it is pretty small. Linus --- Aaron Campbell (1): iommu/vt-d: Fix infinite loop in free_all_cpu_cached_iovas Ajit Pandey (1): ASoC: wm5110: Add missing route from OUT3R to SYSCLK Alan Cox (1): ASoC: Intel: atom: fix missing breaks that would cause the wrong operation to execute Alan Stern (1): SCSI: fix new bug in scsi_dev_info_list string matching Alexander Shiyan (1): ASoC: fsl_ssi: Fix number of words per frame for I2S-slave mode Arnd Bergmann (1): ASoC: hdmi-codec: select CONFIG_HDMI Aviv Heller (1): bonding: fix enslavement slave link notifications Bard Liao (2): ASoC: rt5670: fix HP Playback Volume control ASoC: rt5645: fix reg-2f default value. Ben Skeggs (1): drm/nouveau/disp/sor/gf119: select correct sor when poking training pattern Bjørn Mork (1): cdc_ncm: workaround for EM7455 "silent" data interface Bob Copeland (1): ALSA: hda - fix read before array start Bob Liu (1): xen-blkfront: save uncompleted reqs in blkfront_resume() Borislav Petkov (1): x86/amd_nb: Fix boot crash on non-AMD systems Brian King (1): ipr: Clear interrupt on croc/crocodile when running with LSI Bruno Prémont (1): qla2xxx: Fix NULL pointer deref in QLA interrupt Charles Keepax (1): ASoC: wm5102: Correct supported channels on trace compressed DAI Chris J Arges (1): ecryptfs: fix spelling mistakes Christophe JAILLET (1): ALSA: echoaudio: Fix memory allocation Christophe Jaillet (1): fsl/fman: fix error handling Colin Pitrat (1): gpio: sch: Fix Oops on module load on Asus Eee PC 1201 Dan Carpenter (1): platform/chrome: cros_ec_dev - double fetch bug in ioctl Daniel Borkmann (1): macsec: set actual real device for xmit when !protect_frames Daniel Jurgens (5): net/mlx5: Fix incorrect page count when in internal error net/mlx5: Fix wait_vital for VFs and remove fixed sleep net/mlx5e: Timeout if SQ doesn't flush during close net/mlx5e: Implement ndo_tx_timeout callback net/mlx5e: Handle RQ flush in error cases David Daney (1): MIPS: Fix page table corruption on THP permission changes. David S. Miller (2): packet: Use symmetric hash for PACKET_FANOUT_HASH. Revert "fsl/fman: fix error handling" Eric Dumazet (1): bonding: prevent out of bound accesses Fabio Estevam (1): ASoC: ak4613: Remove owner assignment from platform_driver Florian Fainelli (1): net: bcmsysport: Device stats are unsigned long Ganapatrao Kulkarni (1): arm64: Enable workaround for Cavium erratum 27456 on thunderx-81xx Ganesh Goudar (1): cxgb4: update latest firmware version supported Geert Uytterhoeven (2): ASoC: wm8940: Enable cache usage to fix crashes on resume ASoC: ak4613: Enable cache usage to fix crashes on resume Haishuang Yan (1): geneve: fix max_mtu setting Huang Rui (2): drm/amd/powerplay: fix incorrect voltage table value for polaris10 drm/amd/powerplay: fix incorrect voltage table value for tonga Hugh Dickins (1): tmpfs: fix regression hang in fallocate undo James Morse (1): arm64: kernel: Save and restore UAO and addr_limit on exception entry Jan Beulich (4): xenbus: don't BUG() on user mode induced condition xenbus: don't bail early from xenbus_dev_request_and_reply() xenbus: simplify xenbus_dev_request_and_reply() xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7 Janusz Krzysztofik (1): ASoC: cx20442: set tty->receiver_room in v253_open Jarod Wilson (1): e1000e: keep Rx/Tx HW_VLAN_CTAG in sync Jeff Mahoney (2): Revert "ecryptfs: forbid opening files without mmap handler" ecr
RE: [PATCH v2 08/17] libnvdimm: introduce nvdimm_flush() and nvdimm_has_flush()
> -Original Message- > From: Williams, Dan J > Sent: Sunday, July 10, 2016 1:01 PM > To: lkp > Cc: kbuild-...@01.org; linux-nvd...@lists.01.org; linux-fsdevel fsde...@vger.kernel.org>; Linux ACPI ; Ross > Zwisler ; Christoph Hellwig ; > linux- > ker...@vger.kernel.org > Subject: Re: [PATCH v2 08/17] libnvdimm: introduce nvdimm_flush() and > nvdimm_has_flush() > > On Sat, Jul 9, 2016 at 9:47 PM, kbuild test robot wrote: > > Hi, > > > > [auto build test ERROR on linux-nvdimm/libnvdimm-for-next] > > [also build test ERROR on next-20160708] > > [cannot apply to v4.7-rc6] > > [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/Dan-Williams/replace- > pcommit-with-ADR-or-directed-flushing/20160710-113558 > > base: https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git > libnvdimm-for-next > > config: i386-randconfig-r0-201628 (attached as .config) > > compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430 > > reproduce: > > # save the attached .config to linux build tree > > make ARCH=i386 > > Hi kbuild team, > > Can we add an "i386 allmodconfig" build to the standard "BUILD > SUCCESS" notification runs? I had two positive build results on a Thanks, yes, currently i386 allmodconfig has been covered for all kinds of test including kbiuld on registered repo or LKML patches. If the test is running on a repo for its new commits, a BUILD SUCCESS mail, it will list the current coverage by the time the mail is sent out like m32r m32104ut_defconfig m32r mappi3.smp_defconfig m32r opsput_defconfig m32r usrv_defconfig xtensa common_defconfig xtensa iss_defconfig i386 allmodconfig mips jz4740 mips allnoconfig > private branch prior to posting this series, but the i386 runs did not > build the nvdimm sub-system. > > In any event this report is valid, so thank you for that! > > > > > > All errors (new ones prefixed by >>): > > > >drivers/nvdimm/region_devs.c: In function 'nvdimm_flush': > >>> drivers/nvdimm/region_devs.c:887:4: error: implicit declaration of > >>> function > 'writeq' [-Werror=implicit-function-declaration] > >writeq(1, ndrd->flush_wpq[i][0]); > >^~ > >cc1: some warnings being treated as errors > > > > vim +/writeq +887 drivers/nvdimm/region_devs.c > > > >881 * writes to avoid the cache via arch_memcpy_to_pmem(). The > >882 * final wmb() ensures ordering for the NVDIMM flush write. > >883 */ > >884 wmb(); > >885 for (i = 0; i < nd_region->ndr_mappings; i++) > >886 if (ndrd->flush_wpq[i][0]) > > > 887 writeq(1, ndrd->flush_wpq[i][0]); > >888 wmb(); > >889 } > >890 EXPORT_SYMBOL_GPL(nvdimm_flush); > > > > --- > > 0-DAY kernel test infrastructureOpen Source Technology > > Center > > https://lists.01.org/pipermail/kbuild-all Intel > > Corporation
Re: [PATCH 3/3] net: hisilicon: Add Fast Ethernet MAC driver
Hi Arnd,
On 2016/6/28 17:34, Arnd Bergmann wrote:
> On Tuesday, June 28, 2016 5:21:19 PM CEST Dongpo Li wrote:
>> On 2016/6/15 5:20, Arnd Bergmann wrote:
>>> On Tuesday, June 14, 2016 9:17:44 PM CEST Li Dongpo wrote:
On 2016/6/13 17:06, Arnd Bergmann wrote:
> On Monday, June 13, 2016 2:07:56 PM CEST Dongpo Li wrote:
> You tx function uses BQL to optimize the queue length, and that
> is great. You also check xmit reclaim for rx interrupts, so
> as long as you have both rx and tx traffic, this should work
> great.
>
> However, I notice that you only have a 'tx fifo empty'
> interrupt triggering the napi poll, so I guess on a tx-only
> workload you will always end up pushing packets into the
> queue until BQL throttles tx, and then get the interrupt
> after all packets have been sent, which will cause BQL to
> make the queue longer up to the maximum queue size, and that
> negates the effect of BQL.
>
> Is there any way you can get a tx interrupt earlier than
> this in order to get a more balanced queue, or is it ok
> to just rely on rx packets to come in occasionally, and
> just use the tx fifo empty interrupt as a fallback?
>
In tx direction, there are only two kinds of interrupts, 'tx fifo empty'
and 'tx one packet finish'. I didn't use 'tx one packet finish' because
it would lead to high hardware interrupts rate. This has been verified in
our chips. It's ok to just use tx fifo empty interrupt.
>>>
>>> I'm not convinced by the explanation, I don't think that has anything
>>> to do with the hardware design, but instead is about the correctness
>>> of the BQL logic with your driver.
>>>
>>> Maybe your xmit function can do something like
>>>
>>> if (dql_avail(netdev_get_tx_queue(dev, 0)->dql) < 0)
>>> enable per-packet interrupt
>>> else
>>> use only fifo-empty interrupt
>>>
>>> That way, you don't get a lot of interrupts when the system is
>>> in a state of packets being received and sent continuously,
>>> but if you get to the point where your tx queue fills up
>>> and no rx interrupts arrive, you don't have to wait for it
>>> to become completely empty before adding new packets, and
>>> BQL won't keep growing the queue.
>>>
>> Hi, Arnd
>> I tried enable per-packet interrupt when tx queue full in xmit function
>> and disable it in NAPI poll. But the number of interrupts are a little
>> bigger than only using fifo-empty interrupt.
>
> Right, I'd expect that to be the case, it basically means that the
> algorithm works as expected.
>
> Just to be sure you didn't have extra interrupts: you only enable the
> per-packet interrupts if interrupts are currently enabled, not in
> NAPI polling mode, right?
>
Sorry so long to reply to you. I use the per-packet interrupt like this:
In my xmit function,
if (hardware tx fifo is full) {
enable tx per-packet interrupt;
netif_stop_queue(dev);
return NETDEV_TX_BUSY;
}
In interrupt handle function,
if (interrupt is tx per-packet or tx fifo-empty or rx) {
disable tx per-packet interrupt;
napi_schedule(&priv->napi);
}
We disable tx per-packet interrupt anyway because the NAPI poll will reclaim
the tx fifo.
When the NAPI poll completed, it will only enable the tx fifo-empty interrupt
and rx interrupt except the tx per-packet interrupt.
Is this solution okay?
>> The other hand, this is a fast ethernet MAC. Its maximum speed is 100Mbps.
>> This speed is very easily achived and the efficiency of the BQL is not
>> so important. What we focus on is the lower cpu utilization.
>> So I think it is okay to just use the tx fifo empty interrupt.
>
> BQL is not about efficiency, it's about keeping the latency down, which
> is at least as important for low-throughput devices as it is for faster
> ones. I don't think that disabling BQL here would be the right answer,
> you'd just end up with the maximum TX queue length all the time.
>
> Your queue length is 12 packets of 1500 bytes, meaning that you have 1.4ms
> of latency at 100mbit/s rate, or 14ms for 10mbit/s. This is much less
> than most, but it's probably still worth using BQL on it.
>
I spent some time reading some articles and the goal of BQL is more clear to me.
BQL is designed to get the minimum buffer size that will not make hardware
under starvation.
The goal is to reduce latency without the side effect of throughput.
Thanks for your explanation.
> Arnd
>
> .
>
Regards,
Dongpo
.
Re: [PATCH v2 12/22] usb: chipidea: msm: Rely on core to override AHBBURST
On Thu, Jul 07, 2016 at 03:21:03PM -0700, Stephen Boyd wrote:
> The core framework already handles setting this parameter with a
> platform quirk. Add the appropriate flag so that we always set
> AHBBURST to 0. Technically DT should be doing this, but we always
> do it for msm chipidea devices so setting the flag in the driver
> works just as well.
You may need to mention if the platform needs to set value rather
than 0, it needs to "ahb-burst-config" at dts, others are ok.
Acked-by: Peter Chen
>
> Cc: Peter Chen
> Cc: Greg Kroah-Hartman
> Signed-off-by: Stephen Boyd
> ---
> drivers/usb/chipidea/ci_hdrc_msm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 89c1a02d69b5..719b20caf88e 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -24,7 +24,6 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci,
> unsigned event)
> switch (event) {
> case CI_HDRC_CONTROLLER_RESET_EVENT:
> dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
> - writel(0, USB_AHBBURST);
> /* use AHB transactor, allow posted data writes */
> writel(0x8, USB_AHBMODE);
> usb_phy_init(ci->usb_phy);
> @@ -47,7 +46,8 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
> .name = "ci_hdrc_msm",
> .capoffset = DEF_CAPOFFSET,
> .flags = CI_HDRC_REGS_SHARED |
> - CI_HDRC_DISABLE_STREAMING,
> + CI_HDRC_DISABLE_STREAMING |
> + CI_HDRC_OVERRIDE_AHB_BURST,
>
> .notify_event = ci_hdrc_msm_notify_event,
> };
> --
> 2.9.0.rc2.8.ga28705d
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
Re: [lkp] [ACPI / APEI] a3e2acc5e3: kmsg.BERT:Can't_request_iomem_region<#-#>
I'm very surprised that there was a BERT table on an Atom machine. More details
about the machine please. Also BIOS version.
Sent from my iPhone
> On Jul 10, 2016, at 18:43, kernel test robot wrote:
>
>
> FYI, we noticed the following commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> commit a3e2acc5e37b22b6808a0b8e46887c3577de9c9e ("ACPI / APEI: Add Boot Error
> Record Table (BERT) support")
>
> in testcase: locktorture
> with following parameters: runtime=300s
>
> on test machine: Atom with 8G memory
>
> caused below changes:
>
>
> [ 12.317148] BERT: Can't request iomem region
> .
>
>
>
> To reproduce:
>
>git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>cd lkp-tests
>bin/lkp install job.yaml # job file is attached in this email
>bin/lkp run job.yaml
>
>
>
> Thanks,
> Xiaolong
>
>
>
Re: [PATCH v2 11/22] usb: chipidea: msm: Mark device as runtime pm active
On Thu, Jul 07, 2016 at 03:21:02PM -0700, Stephen Boyd wrote: > We're not properly marking the glue layer/wrapper device as > runtime active, so runtime PM believes that the hardware state is > inactive when we call pm_runtime_enable() in this driver. This > causes a problem when the glue layer has a power domain > associated with it, because runtime PM will go and disable the > power domain to match the 'inactive' state of the device. Let's > mark the device as active so that runtime PM doesn't improperly > power down this device when it's actually active. > > Cc: Peter Chen > Cc: Greg Kroah-Hartman > Signed-off-by: Stephen Boyd > --- > drivers/usb/chipidea/ci_hdrc_msm.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c > b/drivers/usb/chipidea/ci_hdrc_msm.c > index 3889809fd0c4..89c1a02d69b5 100644 > --- a/drivers/usb/chipidea/ci_hdrc_msm.c > +++ b/drivers/usb/chipidea/ci_hdrc_msm.c > @@ -80,6 +80,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, plat_ci); > > + pm_runtime_set_active(&pdev->dev); > pm_runtime_no_callbacks(&pdev->dev); > pm_runtime_enable(&pdev->dev); > Acked-by: Peter Chen -- Best Regards, Peter Chen
Re: [PATCH v4 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.
On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> kexec_locate_mem_hole will be used by the PowerPC kexec_file_load
> implementation to find free memory for the purgatory stack.
>
> Signed-off-by: Thiago Jung Bauermann
> Cc: Eric Biederman
> Cc: Dave Young
> ---
> include/linux/kexec.h | 1 +
> kernel/kexec_file.c | 25 -
> 2 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index ff5fa7707bd7..803f563df81d 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -174,6 +174,7 @@ struct kexec_buf {
> int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
> int (*func)(u64, u64, void *));
> extern int kexec_add_buffer(struct kexec_buf *kbuf);
> +int kexec_locate_mem_hole(struct kexec_buf *kbuf);
> #endif /* CONFIG_KEXEC_FILE */
>
> struct kimage {
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 82ccfc4ee97e..3125d1689712 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -450,6 +450,23 @@ int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
> }
>
> /**
> + * kexec_locate_mem_hole - find free memory for the purgatory or the next
> kernel
> + * @kbuf:Parameters for the memory search.
> + *
> + * On success, kbuf->mem will have the start address of the memory region
> found.
> + *
> + * Return: 0 on success, negative errno on error.
> + */
> +int kexec_locate_mem_hole(struct kexec_buf *kbuf)
> +{
> + int ret;
> +
> + ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
> +
> + return ret == 1 ? 0 : -EADDRNOTAVAIL;
> +}
> +
> +/**
> * kexec_add_buffer - place a buffer in a kexec segment
> * @kbuf:Buffer contents and memory parameters.
> *
> @@ -489,11 +506,9 @@ int kexec_add_buffer(struct kexec_buf *kbuf)
> kbuf->buf_align = max(kbuf->buf_align, PAGE_SIZE);
>
> /* Walk the RAM ranges and allocate a suitable range for the buffer */
> - ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
> - if (ret != 1) {
> - /* A suitable memory range could not be found for buffer */
> - return -EADDRNOTAVAIL;
> - }
> + ret = kexec_locate_mem_hole(kbuf);
> + if (ret)
> + return ret;
>
> /* Found a suitable memory range */
> ksegment = &kbuf->image->segment[kbuf->image->nr_segments];
> --
> 1.9.1
>
Acked-by: Dave Young
Thanks
Dave
Re: [PATCH v14 3/8] perf tests: Add testcase for auxiliary evlist
On 2016/7/8 22:48, Jiri Olsa wrote:
On Thu, Jul 07, 2016 at 05:34:44AM +, Wang Nan wrote:
SNIP
ret = TEST_FAIL;
- err = do_test(evlist, opts.mmap_pages, &sample_count,
+ err = do_test(evlist, aux_evlist, opts.mmap_pages,
+ &enter_sample_count, &exit_sample_count,
&comm_count);
if (err != TEST_OK)
goto out_delete_evlist;
- if ((sample_count != NR_ITERS) || (comm_count != NR_ITERS)) {
- pr_err("Unexpected counter: sample_count=%d, comm_count=%d\n",
- sample_count, comm_count);
+ if (enter_sample_count != exit_sample_count) {
+ pr_err("Unexpected counter: enter_sample_count=%d,
exit_sample_count=%d\n",
+ enter_sample_count, exit_sample_count);
+ goto out_delete_evlist;
+ }
+
+ if ((exit_sample_count != NR_ITERS) || (comm_count != NR_ITERS)) {
+ pr_err("Unexpected counter: exit_sample_count=%d,
comm_count=%d\n",
+ exit_sample_count, comm_count);
goto out_delete_evlist;
}
- err = do_test(evlist, 1, &sample_count, &comm_count);
+ err = do_test(evlist, aux_evlist, 1, &dummy, &dummy, &dummy);
why dont you test numbers for 1 page mmap? seems like the data would fit..
is the purpose just to check if we can map just 1 page?
Data won't fit. 1 page map make sure the buffer is overwritten.
Thank you.
thanks,
jirka
Re: [PATCH v4 2/9] kexec_file: Change kexec_add_buffer to take kexec_buf as argument.
On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> Adapt all callers to the new function prototype.
>
> In addition, change the type of kexec_buf.buffer from char * to void *.
> There is no particular reason for it to be a char *, and the change
> allows us to get rid of 3 existing casts to char * in the code.
>
> Signed-off-by: Thiago Jung Bauermann
> Cc: Eric Biederman
> Cc: Dave Young
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> ---
> arch/x86/kernel/crash.c | 37
> arch/x86/kernel/kexec-bzimage64.c | 48 +++--
> include/linux/kexec.h | 8 +---
> kernel/kexec_file.c | 88
> ++-
> 4 files changed, 87 insertions(+), 94 deletions(-)
>
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 9ef978d69c22..dc026ea361dc 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -615,9 +615,9 @@ static int determine_backup_region(u64 start, u64 end,
> void *arg)
>
> int crash_load_segments(struct kimage *image)
> {
> - unsigned long src_start, src_sz, elf_sz;
> - void *elf_addr;
> int ret;
> + struct kexec_buf kbuf = { .image = image, .buf_min = 0,
> + .buf_max = ULONG_MAX, .top_down = false };
>
> /*
>* Determine and load a segment for backup area. First 640K RAM
> @@ -631,43 +631,44 @@ int crash_load_segments(struct kimage *image)
> if (ret < 0)
> return ret;
>
> - src_start = image->arch.backup_src_start;
> - src_sz = image->arch.backup_src_sz;
> -
> /* Add backup segment. */
> - if (src_sz) {
> + if (image->arch.backup_src_sz) {
> + kbuf.buffer = &crash_zero_bytes;
> + kbuf.bufsz = sizeof(crash_zero_bytes);
> + kbuf.memsz = image->arch.backup_src_sz;
> + kbuf.buf_align = PAGE_SIZE;
> /*
>* Ideally there is no source for backup segment. This is
>* copied in purgatory after crash. Just add a zero filled
>* segment for now to make sure checksum logic works fine.
>*/
> - ret = kexec_add_buffer(image, (char *)&crash_zero_bytes,
> -sizeof(crash_zero_bytes), src_sz,
> -PAGE_SIZE, 0, -1, 0,
> -&image->arch.backup_load_addr);
> + ret = kexec_add_buffer(&kbuf);
> if (ret)
> return ret;
> + image->arch.backup_load_addr = kbuf.mem;
> pr_debug("Loaded backup region at 0x%lx backup_start=0x%lx
> memsz=0x%lx\n",
> - image->arch.backup_load_addr, src_start, src_sz);
> + image->arch.backup_load_addr,
> + image->arch.backup_src_start, kbuf.memsz);
> }
>
> /* Prepare elf headers and add a segment */
> - ret = prepare_elf_headers(image, &elf_addr, &elf_sz);
> + ret = prepare_elf_headers(image, &kbuf.buffer, &kbuf.bufsz);
> if (ret)
> return ret;
>
> - image->arch.elf_headers = elf_addr;
> - image->arch.elf_headers_sz = elf_sz;
> + image->arch.elf_headers = kbuf.buffer;
> + image->arch.elf_headers_sz = kbuf.bufsz;
>
> - ret = kexec_add_buffer(image, (char *)elf_addr, elf_sz, elf_sz,
> - ELF_CORE_HEADER_ALIGN, 0, -1, 0,
> - &image->arch.elf_load_addr);
> + kbuf.memsz = kbuf.bufsz;
> + kbuf.buf_align = ELF_CORE_HEADER_ALIGN;
> + ret = kexec_add_buffer(&kbuf);
> if (ret) {
> vfree((void *)image->arch.elf_headers);
> return ret;
> }
> + image->arch.elf_load_addr = kbuf.mem;
> pr_debug("Loaded ELF headers at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> - image->arch.elf_load_addr, elf_sz, elf_sz);
> + image->arch.elf_load_addr, kbuf.bufsz, kbuf.bufsz);
>
> return ret;
> }
> diff --git a/arch/x86/kernel/kexec-bzimage64.c
> b/arch/x86/kernel/kexec-bzimage64.c
> index f2356bda2b05..4b3a75329fb6 100644
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -331,17 +331,17 @@ static void *bzImage64_load(struct kimage *image, char
> *kernel,
>
> struct setup_header *header;
> int setup_sects, kern16_size, ret = 0;
> - unsigned long setup_header_size, params_cmdline_sz, params_misc_sz;
> + unsigned long setup_header_size, params_cmdline_sz;
> struct boot_params *params;
> unsigned long bootparam_load_addr, kernel_load_addr, initrd_load_addr;
> unsigned long purgatory_load_addr;
> - unsigned long kernel_bufsz, kernel_memsz, kernel_align;
> - char *kernel_buf;
> struct bzimage64_data *ldata;
> struct kexec_entry64_regs regs64;
> void *stack;
> unsigned int setup_hd
Re: [PATCH v4 1/9] kexec_file: Allow arch-specific memory walking for kexec_add_buffer
On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> Allow architectures to specify a different memory walking function for
> kexec_add_buffer. x86 uses iomem to track reserved memory ranges, but
> PowerPC uses the memblock subsystem.
>
> Signed-off-by: Thiago Jung Bauermann
> Cc: Eric Biederman
> Cc: Dave Young
> ---
> include/linux/kexec.h | 29 -
> kernel/kexec_file.c | 30 ++
> kernel/kexec_internal.h | 16
> 3 files changed, 50 insertions(+), 25 deletions(-)
>
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index e8acb2b43dd9..2549a99a748c 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -146,7 +146,34 @@ struct kexec_file_ops {
> kexec_verify_sig_t *verify_sig;
> #endif
> };
> -#endif
> +
> +/**
> + * struct kexec_buf - parameters for finding a place for a buffer in memory
> + * @image: kexec image in which memory to search.
> + * @buffer: Contents which will be copied to the allocated memory.
> + * @bufsz: Size of @buffer.
> + * @mem: On return will have address of the buffer in memory.
> + * @memsz: Size for the buffer in memory.
> + * @buf_align: Minimum alignment needed.
> + * @buf_min: The buffer can't be placed below this address.
> + * @buf_max: The buffer can't be placed above this address.
> + * @top_down:Allocate from top of memory.
> + */
> +struct kexec_buf {
> + struct kimage *image;
> + char *buffer;
> + unsigned long bufsz;
> + unsigned long mem;
> + unsigned long memsz;
> + unsigned long buf_align;
> + unsigned long buf_min;
> + unsigned long buf_max;
> + bool top_down;
> +};
> +
> +int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
> +int (*func)(u64, u64, void *));
> +#endif /* CONFIG_KEXEC_FILE */
>
> struct kimage {
> kimage_entry_t head;
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 01ab82a40d22..9c0c565a08db 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -428,6 +428,27 @@ static int locate_mem_hole_callback(u64 start, u64 end,
> void *arg)
> return locate_mem_hole_bottom_up(start, end, kbuf);
> }
>
> +/**
> + * arch_kexec_walk_mem - call func(data) on free memory regions
> + * @kbuf:Context info for the search. Also passed to @func.
> + * @func:Function to call for each memory region.
> + *
> + * Return: The memory walk will stop when func returns a non-zero value
> + * and that value will be returned. If all free regions are visited without
> + * func returning non-zero, then zero will be returned.
> + */
> +int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
> +int (*func)(u64, u64, void *))
> +{
> + if (kbuf->image->type == KEXEC_TYPE_CRASH)
> + return walk_iomem_res_desc(crashk_res.desc,
> +IORESOURCE_SYSTEM_RAM |
> IORESOURCE_BUSY,
> +crashk_res.start, crashk_res.end,
> +kbuf, func);
> + else
> + return walk_system_ram_res(0, ULONG_MAX, kbuf, func);
> +}
> +
> /*
> * Helper function for placing a buffer in a kexec segment. This assumes
> * that kexec_mutex is held.
> @@ -474,14 +495,7 @@ int kexec_add_buffer(struct kimage *image, char *buffer,
> unsigned long bufsz,
> kbuf->top_down = top_down;
>
> /* Walk the RAM ranges and allocate a suitable range for the buffer */
> - if (image->type == KEXEC_TYPE_CRASH)
> - ret = walk_iomem_res_desc(crashk_res.desc,
> - IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
> - crashk_res.start, crashk_res.end, kbuf,
> - locate_mem_hole_callback);
> - else
> - ret = walk_system_ram_res(0, -1, kbuf,
> - locate_mem_hole_callback);
> + ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
> if (ret != 1) {
> /* A suitable memory range could not be found for buffer */
> return -EADDRNOTAVAIL;
> diff --git a/kernel/kexec_internal.h b/kernel/kexec_internal.h
> index 0a52315d9c62..4cef7e4706b0 100644
> --- a/kernel/kexec_internal.h
> +++ b/kernel/kexec_internal.h
> @@ -20,22 +20,6 @@ struct kexec_sha_region {
> unsigned long len;
> };
>
> -/*
> - * Keeps track of buffer parameters as provided by caller for requesting
> - * memory placement of buffer.
> - */
> -struct kexec_buf {
> - struct kimage *image;
> - char *buffer;
> - unsigned long bufsz;
> - unsigned long mem;
> - unsigned long memsz;
> - unsigned long buf_align;
> - unsigned long buf_min;
> - unsigned long buf_max;
> - bool top_down; /* allocate from top of memory hole */
> -};
> -
> void kimage_file_post_load_cleanup(struct kimage *image);
> #else /* CONFIG_KE
linux-next: build failure after merge of the drm-msm tree
Hi Rob,
After merging the drm-msm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/msm/hdmi/hdmi.c:523:15: error: initialization from incompatible
pointer type [-Werror=incompatible-pointer-types]
.hw_params = msm_hdmi_audio_hw_params,
^
drivers/gpu/drm/msm/hdmi/hdmi.c:523:15: note: (near initialization for
'msm_hdmi_audio_codec_ops.hw_params')
drivers/gpu/drm/msm/hdmi/hdmi.c:524:20: error: initialization from incompatible
pointer type [-Werror=incompatible-pointer-types]
.audio_shutdown = msm_hdmi_audio_shutdown,
^
drivers/gpu/drm/msm/hdmi/hdmi.c:524:20: note: (near initialization for
'msm_hdmi_audio_codec_ops.audio_shutdown')
Caused by commit
bf714255fed7 ("drm: msm: Add ASoC generic hdmi audio codec support.")
interacting with commit
efc9194bcff8 ("ASoC: hdmi-codec: callback function will be called with
private data")
from the sound-asoc (and drm) trees.
I have added this merge fix patch for today (dave will need something
like this when he merges your tree):
From: Stephen Rothwell
Date: Mon, 11 Jul 2016 13:16:23 +1000
Subject: [PATCH] drm: msm: fix up for "ASoC: hdmi-codec: callback function
will be called with private data"
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index aada35547eca..33bf52c6b312 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -438,7 +438,7 @@ static int msm_hdmi_get_gpio(struct device_node *of_node,
const char *name)
/*
* HDMI audio codec callbacks
*/
-static int msm_hdmi_audio_hw_params(struct device *dev,
+static int msm_hdmi_audio_hw_params(struct device *dev, void *data,
struct hdmi_codec_daifmt *daifmt,
struct hdmi_codec_params *params)
{
@@ -512,7 +512,7 @@ static int msm_hdmi_audio_hw_params(struct device *dev,
return 0;
}
-static void msm_hdmi_audio_shutdown(struct device *dev)
+static void msm_hdmi_audio_shutdown(struct device *dev, void *data)
{
struct hdmi *hdmi = dev_get_drvdata(dev);
--
2.8.1
--
Cheers,
Stephen Rothwell
RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions
Hi, > From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com] > Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control > method lid device restrictions > > Hi, > > On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng wrote: > > There are many AML tables reporting wrong initial lid state, and some of > > them never reports lid state. As a proxy layer acting between, ACPI > button > > driver is not able to handle all such cases, but need to re-define the > > usage model of the ACPI lid. That is: > > 1. It's initial state is not reliable; > > 2. There may not be open event; > > 3. Userspace should only take action against the close event which is > >reliable, always sent after a real lid close. > > This patch adds documentation of the usage model. > > > > Link: https://lkml.org/2016/3/7/460 > > Link: https://github.com/systemd/systemd/issues/2087 > > Signed-off-by: Lv Zheng > > Cc: Bastien Nocera: > > Cc: Benjamin Tissoires > > Cc: linux-in...@vger.kernel.org > > --- > > Documentation/acpi/acpi-lid.txt | 62 > +++ > > 1 file changed, 62 insertions(+) > > create mode 100644 Documentation/acpi/acpi-lid.txt > > > > diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi- > lid.txt > > new file mode 100644 > > index 000..7e4f7ed > > --- /dev/null > > +++ b/Documentation/acpi/acpi-lid.txt > > @@ -0,0 +1,62 @@ > > +Usage Model of the ACPI Control Method Lid Device > > + > > +Copyright (C) 2016, Intel Corporation > > +Author: Lv Zheng > > + > > + > > +Abstract: > > + > > +Platforms containing lids convey lid state (open/close) to OSPMs using > a > > +control method lid device. To implement this, the AML tables issue > > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has > > +changed. The _LID control method for the lid device must be > implemented to > > +report the "current" state of the lid as either "opened" or "closed". > > + > > +This document describes the restrictions and the expections of the > Linux > > +ACPI lid device driver. > > + > > + > > +1. Restrictions of the returning value of the _LID control method > > + > > +The _LID control method is described to return the "current" lid state. > > +However the word of "current" has ambiguity, many AML tables return > the lid > > +state upon the last lid notification instead of returning the lid state > > +upon the last _LID evaluation. There won't be difference when the _LID > > +control method is evaluated during the runtime, the problem is its > initial > > +returning value. When the AML tables implement this control method > with > > +cached value, the initial returning value is likely not reliable. There are > > +simply so many examples always retuning "closed" as initial lid state. > > + > > +2. Restrictions of the lid state change notifications > > + > > +There are many AML tables never notifying when the lid device state is > > +changed to "opened". But it is ensured that the AML tables always > notify > > +"closed" when the lid state is changed to "closed". This is normally used > > +to trigger some system power saving operations on Windows. Since it is > > +fully tested, this notification is reliable for all AML tables. > > + > > +3. Expections for the userspace users of the ACPI lid device driver > > + > > +The userspace programs should stop relying on > > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is only > > +used for the validation purpose. > > I'd say: this file actually calls the _LID method described above. And > given the previous explanation, it is not reliable enough on some > platforms. So it is strongly advised for user-space program to not > solely rely on this file to determine the actual lid state. [Lv Zheng] OK. > > > + > > +New userspace programs should rely on the lid "closed" notification to > > +trigger some power saving operations and may stop taking actions > according > > +to the lid "opened" notification. A new input switch event - > SW_ACPI_LID is > > +prepared for the new userspace to implement this ACPI control method > lid > > +device specific logics. > > That's not entirely what we discussed before (to prevent regressions): > - if the device doesn't have reliable LID switch state, then there > would be the new input event, and so userspace should only rely on > opened notifications. > - if the device has reliable switch information, the new input event > should not be exported and userspace knows that the current input > switch event is reliable. > > Also, using a new "switch" event is a terrible idea. Switches have a > state (open/close) and you are using this to forward a single open > event. So using a switch just allows you to say to userspace you are > using the "new" LID meaning, but you'll still have to manually reset > the switch and you will have to document how this event is not a > switch. > > Please use a simple KEY_LID_OPEN event you will send through > [input_key_event(KEY
Re: [PATCH v2 10/22] usb: chipidea: Add support for ULPI PHY bus
On Thu, Jul 07, 2016 at 03:21:01PM -0700, Stephen Boyd wrote:
> Some phys for the chipidea controller are controlled via the ULPI
> viewport. Add support for the ULPI bus so that these sorts of
> phys can be probed and read/written automatically without having
> to duplicate the viewport logic in each phy driver.
>
> Cc: Peter Chen
> Cc: Greg Kroah-Hartman
> Cc: Heikki Krogerus
> Signed-off-by: Stephen Boyd
> ---
> drivers/usb/chipidea/Kconfig | 7 +++
> drivers/usb/chipidea/Makefile | 1 +
> drivers/usb/chipidea/ci.h | 22
> drivers/usb/chipidea/core.c | 31 +---
> drivers/usb/chipidea/ulpi.c | 113
> ++
> 5 files changed, 168 insertions(+), 6 deletions(-)
> create mode 100644 drivers/usb/chipidea/ulpi.c
>
> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
> index 3644a3500b70..4f8c342a8865 100644
> --- a/drivers/usb/chipidea/Kconfig
> +++ b/drivers/usb/chipidea/Kconfig
> @@ -37,4 +37,11 @@ config USB_CHIPIDEA_HOST
> Say Y here to enable host controller functionality of the
> ChipIdea driver.
>
> +config USB_CHIPIDEA_ULPI
> + bool "ChipIdea ULPI PHY support"
> + depends on USB_ULPI_BUS=y || USB_ULPI_BUS=USB_CHIPIDEA
> + help
> + Say Y here if you have a ULPI PHY attached to your ChipIdea
> + controller.
> +
> endif
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index 518e445476c3..39fca5715ed3 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -4,6 +4,7 @@ ci_hdrc-y := core.o otg.o debug.o
> ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC) += udc.o
> ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST) += host.o
> ci_hdrc-$(CONFIG_USB_OTG_FSM)+= otg_fsm.o
> +ci_hdrc-$(CONFIG_USB_CHIPIDEA_ULPI) += ulpi.o
>
> # Glue/Bridge layers go here
>
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 05bc4d631cb9..637dd7675e71 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -18,6 +18,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
>
> /**
> * DEFINE
> @@ -52,6 +54,7 @@ enum ci_hw_regs {
> OP_ENDPTLISTADDR,
> OP_TTCTRL,
> OP_BURSTSIZE,
> + OP_ULPI_VIEWPORT,
> OP_PORTSC,
> OP_DEVLC,
> OP_OTGSC,
> @@ -187,6 +190,8 @@ struct hw_bank {
> * @test_mode: the selected test mode
> * @platdata: platform specific information supplied by parent device
> * @vbus_active: is VBUS active
> + * @ulpi: pointer to ULPI device, if any
> + * @ulpi_ops: ULPI read/write ops for this device
> * @phy: pointer to PHY, if any
> * @usb_phy: pointer to USB PHY, if any and if using the USB PHY framework
> * @hcd: pointer to usb_hcd for ehci host driver
> @@ -236,6 +241,10 @@ struct ci_hdrc {
>
> struct ci_hdrc_platform_data*platdata;
> int vbus_active;
> +#ifdef CONFIG_USB_CHIPIDEA_ULPI
> + struct ulpi *ulpi;
> + struct ulpi_ops ulpi_ops;
> +#endif
> struct phy *phy;
> /* old usb_phy interface */
> struct usb_phy *usb_phy;
> @@ -418,6 +427,17 @@ static inline bool ci_otg_is_fsm_mode(struct ci_hdrc *ci)
> #endif
> }
>
> +#if IS_ENABLED(CONFIG_USB_CHIPIDEA_ULPI)
> +int ci_ulpi_init(struct ci_hdrc *ci);
> +void ci_ulpi_exit(struct ci_hdrc *ci);
> +int ci_ulpi_resume(struct ci_hdrc *ci);
> +#else
> +static inline int ci_ulpi_init(struct ci_hdrc *ci) { return 0; }
> +static inline void ci_ulpi_exit(struct ci_hdrc *ci) { }
> +static inline int ci_ulpi_resume(struct ci_hdrc *ci) { return 0; }
> +#endif
> +
> +
One more blank line
> u32 hw_read_intr_enable(struct ci_hdrc *ci);
>
> u32 hw_read_intr_status(struct ci_hdrc *ci);
> @@ -428,6 +448,8 @@ int hw_port_test_set(struct ci_hdrc *ci, u8 mode);
>
> u8 hw_port_test_get(struct ci_hdrc *ci);
>
> +void hw_phymode_configure(struct ci_hdrc *ci);
> +
> void ci_platform_configure(struct ci_hdrc *ci);
>
> int dbg_create_files(struct ci_hdrc *ci);
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 532085a096d9..f144e1bbcc82 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -86,6 +86,7 @@ static const u8 ci_regs_nolpm[] = {
> [OP_ENDPTLISTADDR] = 0x18U,
> [OP_TTCTRL] = 0x1CU,
> [OP_BURSTSIZE] = 0x20U,
> + [OP_ULPI_VIEWPORT] = 0x30U,
> [OP_PORTSC] = 0x44U,
> [OP_DEVLC] = 0x84U,
> [OP_OTGSC] = 0x64U,
> @@ -110,6 +111,7 @@ static const u8 ci_regs_lpm[] = {
> [OP_ENDPTLISTADDR] = 0x18U,
> [OP_TTCTRL] = 0x1CU,
> [OP_BURSTSIZE] = 0x20U,
> + [OP_ULPI_VIEWPORT] = 0x30U,
> [OP_PORTSC]
Re: [lkp] [ext4] 5405511e1a: ltp.acl_test01.fail]
On Mon, Jul 11, 2016 at 09:59:54AM +0800, kernel test robot wrote:
>
> FYI, we noticed the following commit:
>
> https://github.com/0day-ci/linux
> Vegard-Nossum/ext4-validate-number-of-clusters-in-group/20160708-041426
> commit 5405511e1a984ab644fa9e29a0d3d958b835ab75 ("ext4: validate number of
> meta clusters in group")
Hi, many thanks for the report. One question -- is there some way the
reporting could be speeded up? Vegard's patch was sent late on the
7th, and it looks like it hit the 0day-ci git repo a few hours later
on the 8th, and was run early in the morning Chinese time. Was the
delay until the 11th due to the weekend and the desire to have a human
sanity check the result? Is that because there was a concern that
there would be too many false positives?
Also, if there was some way the 0day robot report could include a
In-Reply-To: header to the patch being sent to the mailing list (in
this case: <577eb740.10...@oracle.com>), it would make this even
*more* useful.
Vegard, I'm guessing you didn't have a chance to test your patch
before you sent it to the list?
bit_max = ext4_num_clusters_in_group(sb, i);
if ((bit_max >> 3) >= sb->s_blocksize) {
ext4_msg(sb, KERN_WARNING, "clusters in "
"group %u exceeds block size", i);
goto failed_mount;
}
This is the test which is failing, but it will fail by default on
pretty much all ext4 file systems, since by default there will be
32768 blocks (clusters) per group, with a 4k block size (and 32768 >>
3 == 4096). And in the test that failed, this was a 1k block size
with 8192 blocks per blocks (and 8192 >> 3 == 1024).
Anyway, as I mentioned before, I'd much rather do very specific sanity
checking on superblock fields, instead of sanity checking calculated
values such as ext4_num_clusters_in_group().
Perhaps the easist thing to do is to run e2fsck -n on those file
systems that are causing problems?
Cheers,
- Ted
[PATCH v3 1/2] dt-bindings: auxadc: Add binding document for Mediatek auxadc.
The commit adds the device tree binding documentation for the mediatek
auxadc found on Mediatek MT2701.
Thermal gets auxadc sample data by iio device.
So the commit changes auxadc device tree binding documentation from
/soc/mediatek/auxadc.txt to /iio/adc/mt65xx_auxadc.txt.
Signed-off-by: Zhiyong Tao
---
.../devicetree/bindings/iio/adc/mt65xx_auxadc.txt |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt
b/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt
index 47fcd1b..bc23792 100644
--- a/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt
@@ -14,11 +14,11 @@ Required properties:
- reg: Address range of the AUXADC unit.
- clocks: Should contain a clock specifier for each entry in clock-names
- clock-names: Should contain "main".
- - io-channel-cells: Should be 1, see ../iio-bindings.txt
+ - #io-channel-cells: Should be 1, see ../iio-bindings.txt
Example:
-auxadc: auxadc@11001000 {
+auxadc: adc@11001000 {
compatible = "mediatek,mt2701-auxadc";
reg = <0 0x11001000 0 0x1000>;
clocks = <&pericfg CLK_PERI_AUXADC>;
--
1.7.9.5
Re: [RFC] arm64: kexec_file_load support
On 07/08/16 at 11:48am, Thiago Jung Bauermann wrote:
> Am Donnerstag, 07 Juli 2016, 14:12:45 schrieb Dave Young:
> > If so maybe change a bit from your precious mentioned 7 args proposal like
> > below?
> >
> > struct kexec_file_fd {
> > enum kexec_file_type;
> > int fd;
> > }
> >
> > struct kexec_fdset {
> > int nr_fd;
> > struct kexec_file_fd fd[0];
> > }
> >
> > int kexec_file_load(int kernel_fd, int initrd_fd,
> > unsigned long cmdline_len, const char *cmdline_ptr,
> > unsigned long flags, struct kexec_fdset *extra_fds);
>
>
> Is there a way for the kernel to distinguish whether the process passed 5 or
> 6 arguments? How can it know whether extra_fds is a valid argument or just
> garbage? I think we have to define a new flag KEXEC_FILE_EXTRA_FDS so that
> the process can signal that it is using the new interface.
Agreed, a new flag is needed.
Thanks
Dave
[PATCH v3 2/2] iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.
Add Mediatek auxadc driver based on iio.
It will register a device in iio and support iio.
So thermal can read auxadc channel to sample data by iio device.
It is tested successfully on mt2701 platform.
Mt8173 and mt6577 platforms are not tested.
But the expectation is compatible.
Signed-off-by: Zhiyong Tao
---
drivers/iio/adc/Kconfig | 26 +++---
drivers/iio/adc/Makefile|2 +-
drivers/iio/adc/mt6577_auxadc.c | 186 +++
3 files changed, 104 insertions(+), 110 deletions(-)
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 66e9b44..14929fc 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -305,6 +305,19 @@ config MCP3422
This driver can also be built as a module. If so, the module will be
called mcp3422.
+config MEDIATEK_MT6577_AUXADC
+tristate "MediaTek AUXADC driver"
+depends on ARCH_MEDIATEK || COMPILE_TEST
+depends on HAS_IOMEM
+help
+ Say yes here to enable support for MediaTek mt65xx AUXADC.
+
+ The driver supports immediate mode operation to read from one of
sixteen
+ channels (external or internal).
+
+ This driver can also be built as a module. If so, the module will be
+ called mt6577_auxadc.
+
config MEN_Z188_ADC
tristate "MEN 16z188 ADC IP Core support"
depends on MCB
@@ -315,19 +328,6 @@ config MEN_Z188_ADC
This driver can also be built as a module. If so, the module will be
called men_z188_adc.
-config MEDIATEK_MT65XX_AUXADC
- tristate "MediaTek AUXADC driver"
- depends on ARCH_MEDIATEK || COMPILE_TEST
- depends on HAS_IOMEM
- help
- Say yes here to enable support for MediaTek mt65xx AUXADC.
-
- The driver supports immediate mode operation to read from one of
sixteen
- channels (external or internal).
-
- This driver can also be built as a module. If so, the module will be
- called mt6577_auxadc.
-
config MXS_LRADC
tristate "Freescale i.MX23/i.MX28 LRADC"
depends on (ARCH_MXS || COMPILE_TEST) && HAS_IOMEM
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 14a630f..8306347 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -30,8 +30,8 @@ obj-$(CONFIG_MAX1027) += max1027.o
obj-$(CONFIG_MAX1363) += max1363.o
obj-$(CONFIG_MCP320X) += mcp320x.o
obj-$(CONFIG_MCP3422) += mcp3422.o
+obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
-obj-$(CONFIG_MEDIATEK_MT65XX_AUXADC) += mt6577_auxadc.o
obj-$(CONFIG_MXS_LRADC) += mxs-lradc.o
obj-$(CONFIG_NAU7802) += nau7802.o
obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c
index a56531a..a853ae8 100644
--- a/drivers/iio/adc/mt6577_auxadc.c
+++ b/drivers/iio/adc/mt6577_auxadc.c
@@ -24,80 +24,78 @@
#include
#include
-/* Registers definitions */
-#define MT65XX_AUXADC_CON00x00
-#define MT65XX_AUXADC_CON10x04
-#define MT65XX_AUXADC_CON20x10
-#define MT65XX_AUXADC_STA BIT(0)
+/* Register definitions */
+#define MT6577_AUXADC_CON00x00
+#define MT6577_AUXADC_CON10x04
+#define MT6577_AUXADC_CON20x10
+#define MT6577_AUXADC_STA BIT(0)
-#define MT65XX_AUXADC_DAT00x14
-#define MT65XX_AUXADC_RDY0BIT(12)
+#define MT6577_AUXADC_DAT00x14
+#define MT6577_AUXADC_RDY0BIT(12)
-#define MT65XX_AUXADC_MISC0x94
-#define MT65XX_AUXADC_PDN_EN BIT(14)
+#define MT6577_AUXADC_MISC0x94
+#define MT6577_AUXADC_PDN_EN BIT(14)
-#define MT65XX_AUXADC_DAT_MASK0xfff
-#define MT65XX_AUXADC_SLEEP_US1000
-#define MT65XX_AUXADC_TIMEOUT_US 1
-#define MT65XX_AUXADC_POWER_READY_MS 1
-#define MT65XX_AUXADC_SAMPLE_READY_US 25
+#define MT6577_AUXADC_DAT_MASK0xfff
+#define MT6577_AUXADC_SLEEP_US1000
+#define MT6577_AUXADC_TIMEOUT_US 1
+#define MT6577_AUXADC_POWER_READY_MS 1
+#define MT6577_AUXADC_SAMPLE_READY_US 25
-struct mt65xx_auxadc_device {
+struct mt6577_auxadc_device {
void __iomem *reg_base;
struct clk *adc_clk;
struct mutex lock;
- unsigned int power_ready_ms;
- unsigned int sample_ready_us;
};
-#define MT65XX_AUXADC_CHANNEL(idx) { \
+#define MT6577_AUXADC_CHANNEL(idx) { \
.type = IIO_VOLTAGE,\
.indexed = 1, \
.channel = (idx),
[PATCH v3 0/2] AUXADC: Mediatek auxadc driver
This series includes three patches: 1.Change the device tree binding documentation. 2.Add auxadc driver based on linux iio. 3.Add auxadc nodes in the mediatek MT2701 dtsi file. changes in patch v3: 1).Add '#' before 'io-channel-cells' and change 'auxadc@' to 'adc@' in auxadc binding document. 2).Fix CONFIG_MEDIATEK_MT65XX_AUXADC sequence as alphabetical order. 3).Change the prefix 'MT65XX' to 'MT6577' to match auxadc driver name. 4).Remove the delays stored in 'mt6577_auxadc_device' and use the defined delay directly. 5).Use '-ETIMEDOUT' instead of '-EINVAL'. 6).Return value directly in 'mt6577_auxadc_read_raw'. 7).Add power off and unprepare clock if 'iio_device_register' failed. 8).Change 'Registers' to 'Register'. changes in patch v2: 1).Change the file name mt65xx_auxadc.c to mt6577_auxadc.c. 2).Add 'depends on ARCH_MEDIATEK || COMPILE_TEST and HAS_IOMEM' for MEDIATEK_MT65XX_AUXADC config. 3).Add check case for return value of 'readl_poll_timeout'. 4).Remove returning 1 and 0 for SCALE and OFFSET. use channel type 'IIO_CHAN_INFO_PROCESSED' instead of 'IIO_CHAN_INFO_RAW'. 5).Remove 'IIO_CHAN_INFO_OFFSET' and 'IIO_CHAN_INFO_SCALE' in 'MT65XX_AUXADC_CHANNEL' channel type. 6).Add check case when auxadc power on failure. if auxadc power on failure, clk_disable_unprepare should be executed. 7).Put 'platform_set_drvdata' before 'iio_device_register'. 8).Fix coding style and spelling error. Zhiyong Tao (2): dt-bindings: auxadc: Add binding document for Mediatek auxadc. iio: adc: mt2701: Add Mediatek auxadc driver for mt2701. .../devicetree/bindings/iio/adc/mt65xx_auxadc.txt |4 +- drivers/iio/adc/Kconfig| 26 +-- drivers/iio/adc/Makefile |2 +- drivers/iio/adc/mt6577_auxadc.c| 186 ++-- 4 files changed, 106 insertions(+), 112 deletions(-)
Re: [PATCH v2 05/10] power/reset: Add reset driver support for nuc900
[Re: [PATCH v2 05/10] power/reset: Add reset driver support for nuc900] On 11/07/2016 (Mon 10:30) Wan Zongshun wrote: > > > On 2016年07月11日 05:56, Paul Gortmaker wrote: > >On Sun, Jul 10, 2016 at 3:27 AM, Wan Zongshun wrote > >>This driver is to add reset support for nuc900 series, > >>currently, it only supports nuc970 SoC reset. > >> > >>Signed-off-by: Wan Zongshun > >>--- > >> drivers/power/reset/Kconfig| 7 +++ > >> drivers/power/reset/Makefile | 1 + > >> drivers/power/reset/nuc900-reset.c | 93 > >> ++ > >> 3 files changed, 101 insertions(+) > >> create mode 100644 drivers/power/reset/nuc900-reset.c > >> > >>diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig > >>index 9bb2622..8c84892 100644 > >>--- a/drivers/power/reset/Kconfig > >>+++ b/drivers/power/reset/Kconfig > >>@@ -94,6 +94,13 @@ config POWER_RESET_MSM > >> help > >> Power off and restart support for Qualcomm boards. > >> > >>+config POWER_RESET_NUC900 > >>+ bool "Nuc900 restart driver" > > > >If this driver is bool and not tristate, then please remove all references > >to MODULE_ and then the module.h include as well. > > I will remove the following codes in my reset.c driver. > > MODULE_DEVICE_TABLE(of, of_nuc900_reset_match); > #include Thanks -- it is not a specific criticism of your driver, but just a mistake that we have consistently copied from one driver to the next, and I hope we can stop doing that with the right reviews. P. -- > > > > > >Thanks, > >Paul. > >-- > > > >>+ depends on ARCH_W90X900 > >>+ help > >>+ Power off and restart support for Nuvoton NUC900 family of > >>+ reference boards. > >>+ > >> config POWER_RESET_LTC2952 > >> bool "LTC2952 PowerPath power-off driver" > >> depends on OF_GPIO > >>diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile > >>index ab7aa86..d4df889 100644 > >>--- a/drivers/power/reset/Makefile > >>+++ b/drivers/power/reset/Makefile > >>@@ -9,6 +9,7 @@ obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o > >> obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o > >> obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o > >> obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o > >>+obj-$(CONFIG_POWER_RESET_NUC900) += nuc900-reset.o > >> obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o > >> obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o > >> obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o > >>diff --git a/drivers/power/reset/nuc900-reset.c > >>b/drivers/power/reset/nuc900-reset.c > >>new file mode 100644 > >>index 000..49986b7 > >>--- /dev/null > >>+++ b/drivers/power/reset/nuc900-reset.c > >>@@ -0,0 +1,93 @@ > >>+/* > >>+ * Copyright 2016 Wan Zongshun > >>+ * > >>+ * The code contained herein is licensed under the GNU General Public > >>+ * License. You may obtain a copy of the GNU General Public License > >>+ * Version 2 or later at the following locations: > >>+ * > >>+ * http://www.opensource.org/licenses/gpl-license.html > >>+ * http://www.gnu.org/copyleft/gpl.html > >>+ */ > >>+#include > >>+#include > >>+#include > >>+#include > >>+#include > >>+#include > >>+#include > >>+#include > >>+#include > >>+#include > >>+#include > >> > > > >[...] > > > >___ > >linux-arm-kernel mailing list > >linux-arm-ker...@lists.infradead.org > >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > >
Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver
Hi Hans, On Fri, 2016-07-08 at 12:23 +0200, Hans Verkuil wrote: > On 05/30/2016 02:29 PM, Tiffany Lin wrote: > > Add V4L2_PIX_FMT_MT21 documentation > > > > Signed-off-by: Tiffany Lin > > --- > > Documentation/DocBook/media/v4l/pixfmt.xml |6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml > > b/Documentation/DocBook/media/v4l/pixfmt.xml > > index 5a08aee..d40e0ce 100644 > > --- a/Documentation/DocBook/media/v4l/pixfmt.xml > > +++ b/Documentation/DocBook/media/v4l/pixfmt.xml > > @@ -1980,6 +1980,12 @@ array. Anything what's in between the UYVY lines is > > JPEG data and should be > > concatenated to form the JPEG stream. > > > > > > + > > + V4L2_PIX_FMT_MT21 > > + 'MT21' > > + Compressed two-planar YVU420 format used by Mediatek MT8173 > > + codec driver. > > Can you give a few more details? The encoder driver doesn't seem to produce > this > format, so who is creating this? Where is this format documented? > It can be as input format for encoder, MDP and display drivers in our platform. This private format is only available in our platform. So I put it in "Reserved Format Identifiers" sections. best regards, Tiffany > Regards, > > Hans > > > + > > > > > > > >
Re: [PATCH v9 1/4] dt-bindings: soc: Add documentation for the MediaTek GCE unit
Hi Jan, On Fri, 2016-07-08 at 12:17 +0200, Jan Lübbe wrote: > On Do, 2016-06-30 at 15:14 +0800, HS Liao wrote: > [...] > > +Required properties: > > +- compatible: Must be "mediatek,mt8173-gce" > > +- reg: Address range of the GCE unit > > +- interrupts: The interrupt signal from the GCE block > > +- clock: Clocks according to the common clock binding > > +- clock-names: Must be "gce" to stand for GCE clock > > +- #mbox-cells: Should be 1 > [...] > > + #mbox-cells = <1>; > [...] > > + mediatek,gce = <&gce>; > > + mboxes = <&gce 0 1 /* main display with merging wfe */ > > + &gce 1 1>; /* sub display with merging wfe */ > > It seems that you use two cells instead of one as you declared above. > This should be consistent. Will correct it as 2. > Also, why do you need an explicit phandle to the gce if you already use > mailboxes? "mediatek,gce" should be added to all clients which ask gce to access their registers. "mboxes" should be added to all clients which will communicate with gce via mailbox. For example, if mmsys send cmdq tasks to ask gce to write registers of mmsys and ovl, mmsys should have "mediatek,gce" and "mboxes", and ovl should have "mediatek,gce". I will explain their difference in GCE's device tree document. > Best regards, > Jan Lübbe Thanks, HS
[PATCH v2] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize
Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size
attribute, which means it need to align the request buffer's size to an ep's
maxpacketsize.
Thus we add usb_ep_align_maybe() function to check if it is need to align
the request buffer's size to an ep's maxpacketsize.
Signed-off-by: Baolin Wang
Acked-by: Michal Nazarewicz
---
Changelog since v1:
- Remove the in_ep modification.
- Remove max_t() function.
drivers/usb/gadget/function/f_midi.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/function/f_midi.c
b/drivers/usb/gadget/function/f_midi.c
index 58fc199..59f6278 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -359,10 +359,14 @@ static int f_midi_set_alt(struct usb_function *f,
unsigned intf, unsigned alt)
/* allocate a bunch of read buffers and queue them all at once. */
for (i = 0; i < midi->qlen && err == 0; i++) {
- struct usb_request *req =
- midi_alloc_ep_req(midi->out_ep,
- max_t(unsigned, midi->buflen,
- bulk_out_desc.wMaxPacketSize));
+ struct usb_request *req;
+ unsigned length;
+
+ length = midi->buflen < bulk_out_desc.wMaxPacketSize
+ ? bulk_out_desc.wMaxPacketSize
+ : usb_ep_align_maybe(midi->gadget, midi->out_ep,
+midi->buflen);
+ req = midi_alloc_ep_req(midi->out_ep, length);
if (req == NULL)
return -ENOMEM;
--
1.7.9.5
[PATCH] xen_pvscsi: reclaim the ring request when mapping data failed
During scsi command queueing, if mapping data fails, we need to
reclaim the failed request. Otherwise, the garbage request will
be pushed into the ring for the backend to work.
Signed-off-by: Bin Wu
---
drivers/scsi/xen-scsifront.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
index 9dc8687..655163d 100644
--- a/drivers/scsi/xen-scsifront.c
+++ b/drivers/scsi/xen-scsifront.c
@@ -565,6 +565,7 @@ static int scsifront_queuecommand(struct Scsi_Host *shost,
err = map_data_for_request(info, sc, ring_req, shadow);
if (err < 0) {
pr_debug("%s: err %d\n", __func__, err);
+info->ring.req_prod_pvt--;
scsifront_put_rqid(info, rqid);
scsifront_return(info);
spin_unlock_irqrestore(shost->host_lock, flags);
--
2.3.2 (Apple Git-55)
PCIe MSI address is not written at pci_enable_msi_range call
Hi, I have a query. I see that when we use PCI_MSI_IRQ_DOMAIN to handle MSI's, MSI address is not being written in to end point's PCI_MSI_ADDRESS_LO/HI at the call pci_enable_msi_range. Instead it is being written at the time end point requests irq. Can any one tell the reason why is it handled in this manner ? Correct me If my observation is wrong. Thanks & Regards, Bharat This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Re: [PATCH v4 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.
On 07/10/16 at 04:11pm, Michael Ellerman wrote: > Thiago Jung Bauermann writes: > > > kexec_locate_mem_hole will be used by the PowerPC kexec_file_load > > implementation to find free memory for the purgatory stack. > > > > Signed-off-by: Thiago Jung Bauermann > > Cc: Eric Biederman > > Cc: Dave Young > > Dave are you happy with the first three patches? If so do you mind > sending an ack? I reviewed the 3 patches, they look good to me. Will ack after a small test today. > > Given the series touches generic code, x86 and powerpc this might be one > for Andrew to take. Or is there a kexec tree it should go through? They should go Andrew's tree, but I'm not sure about the powerpc part. Thanks Dave
Re: [PATCH] x86: fix rdmsr MSR_PLATFORM_INFO unsafe warning in kvm guest
Hi Ingo, Thomas,
2016-06-22 9:28 GMT+08:00 Wanpeng Li :
> From: Wanpeng Li
>
> [ cut here ]
> WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50
> ex_handler_rdmsr_unsafe+0x6a/0x70
> unchecked MSR access error: RDMSR from 0xce
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc3+ #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> 81c03ce0 813b3eae 81c03d30
> 81c03d20 81067181 00320001
> 81c03df8 8179676c 81fcd2c0
> Call Trace:
> dump_stack+0x67/0x99
> __warn+0xd1/0xf0
> warn_slowpath_fmt+0x4f/0x60
> ex_handler_rdmsr_unsafe+0x6a/0x70
> fixup_exception+0x39/0x50
> do_general_protection+0x93/0x1b0
> general_protection+0x22/0x30
> ? cpu_khz_from_msr+0xd8/0x1c0
> native_calibrate_cpu+0x30/0x5b0
> tsc_init+0x2b/0x297
> x86_late_time_init+0xf/0x11
> start_kernel+0x398/0x451
> ? set_init_arg+0x55/0x55
> x86_64_start_reservations+0x2f/0x31
> x86_64_start_kernel+0xea/0xed
>
> After commit (fc141535ad8 : "x86 tsc_msr: Extend to include Intel Core
> Architecture"), rdmsr MSR_PLATFORM_INFO is used to get maximum non-turbo
I just saw commit (fc273eeef314c : "x86 tsc_msr: Extend to include
Intel Core Architecture") was merged in tip tree, then this patch is
needed to fix that commit. The bug is reported by LKP several weeks
ago, and kvm maintainer Paolo has already replied "This looks good" to
this patch.
Regards,
Wanpeng Li
> ratio for recent Intel Core Architecture which results in kvm guest rdmsr
> unsafe warning.
>
> As Radim pointed out before:
>
> | MSR_PLATFORM_INFO: Intel changes it from family to family and there is
> | no obvious overlap or default. If we picked 0 (any other fixed value),
> | then the guest would have to know that 0 doesn't mean that
> | MSR_PLATFORM_INFO returned 0, but that KVM doesn't emulate this MSR and
> | the value cannot be used. This is very similar to handling a #GP in the
> | guest, but also has a disadvantage, because KVM cannot say that
> | MSR_PLATFORM_INFO is 0. Simple emulation is not possible.
>
> This patch fix it by using rdmsr_safe to read MSR_PLATFORM_INFO in kvm
> guest in order that #GP can be fixed up, then tsc will be calibrated by
> PIT, HPET etc.
>
> Reported-by: kernel test robot
> Cc: Len Brown
> Cc: "Rafael J. Wysocki"
> Cc: Zhang Rui
> Cc: Chen Yu
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: jacob.jun@intel.com
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Signed-off-by: Wanpeng Li
> ---
> arch/x86/kernel/tsc_msr.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
> index e0c2b30..e6e465e 100644
> --- a/arch/x86/kernel/tsc_msr.c
> +++ b/arch/x86/kernel/tsc_msr.c
> @@ -70,7 +70,7 @@ static int match_cpu(u8 family, u8 model)
> */
> unsigned long cpu_khz_from_msr(void)
> {
> - u32 lo, hi, ratio, freq_id, freq;
> + u32 lo, hi, freq_id, freq, ratio = 0;
> unsigned long res;
> int cpu_index;
>
> @@ -123,8 +123,8 @@ unsigned long cpu_khz_from_msr(void)
> }
>
> get_ratio:
> - rdmsr(MSR_PLATFORM_INFO, lo, hi);
> - ratio = (lo >> 8) & 0xff;
> + if (!rdmsr_safe(MSR_PLATFORM_INFO, &lo, &hi))
> + ratio = (lo >> 8) & 0xff;
>
> done:
> /* TSC frequency = maximum resolved freq * maximum resolved bus ratio
> */
> --
> 1.9.1
>
PCIe MSI address is not written at pci_enable_msi_range call
Hi, I have a query. I see that when we use PCI_MSI_IRQ_DOMAIN to handle MSI's, MSI address is not being written in to end point's PCI_MSI_ADDRESS_LO/HI at the call pci_enable_msi_range. Instead it is being written at the time end point requests irq. Can any one tell the reason why is it handled in this manner ? Correct me If my observation is wrong. Thanks & Regards, Bharat This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Re: [PATCH v2 09/22] usb: chipidea: Kick OTG state machine for AVVIS with vbus extcon
On Thu, Jul 07, 2016 at 03:21:00PM -0700, Stephen Boyd wrote:
> Force the OTG state machine to go forward when we're using an
> extcon for vbus detection. In this case, the controller may never
> raise an interrupt for AVVIS, so we need to simulate the event by
> toggling the appropriate OTG fsm bits and kicking the state
> machine again.
>
> Cc: Peter Chen
> Cc: Greg Kroah-Hartman
> Signed-off-by: Stephen Boyd
> ---
>
> I think this was rejected last time around but I've kept it in the
> series to continue discussion on how we're supposed to be emulating
> vbus an id pin interrupts and the otgsc register.
>
> drivers/usb/chipidea/otg_fsm.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
> index de8e22ec3902..aab076fc4d82 100644
> --- a/drivers/usb/chipidea/otg_fsm.c
> +++ b/drivers/usb/chipidea/otg_fsm.c
> @@ -475,6 +475,14 @@ static void ci_otg_drv_vbus(struct otg_fsm *fsm, int on)
> return;
> }
> }
> + /*
> + * Force state machine forward if we use extcon
> + * to detect vbus state (i.e. simulate AVVIS event)
> + */
> + if (!IS_ERR(ci->platdata->vbus_extcon.edev)) {
> + fsm->a_vbus_vld = 1;
> + ci_otg_queue_work(ci);
> + }
> /* Disable data pulse irq */
> hw_write_otgsc(ci, OTGSC_DPIE, 0);
>
> @@ -486,6 +494,15 @@ static void ci_otg_drv_vbus(struct otg_fsm *fsm, int on)
>
> fsm->a_bus_drop = 1;
> fsm->a_bus_req = 0;
> + /*
> + * Force state machine forward if we use extcon
> + * to detect vbus state (i.e. simulate AVVIS event)
> + */
> + if (!IS_ERR(ci->platdata->vbus_extcon.edev)) {
> + fsm->a_vbus_vld = 0;
> + fsm->b_conn = 0;
> + ci_otg_queue_work(ci);
> + }
> }
> }
>
Well, if we don't have a_valid, we can't know a_vbus_err state at
A device side if vbus is error (eg, less than 4.4v), and B device
will NOT be disconnect if vbus is still larger than BSV.
Do you really need OTG FSM? If you can pass the OTG test described at
Documentation/usb/chipidea.txt, I can accept it, I find the OTG
compliance test does not test ~a_vbus_vld either, see
otgeh_compliance_plan_1_2, ch6.7.12.2 Paths not tested.
--
Best Regards,
Peter Chen
linux-next: manual merge of the drm tree with the jc_docs tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
Documentation/index.rst
between commit:
17defc282fe6 ("Documentation: add meta-documentation for Sphinx and
kernel-doc")
from the jc_docs tree and commit:
cb597fcea5c2 ("Documentation/gpu: add new gpu.rst converted from DocBook
gpu.tmpl")
from the drm tree.
I fixed it up (see below - I just put them in alphabetical order ...)
and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/index.rst
index ad07716c73f4,dacc77b43c29..
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@@ -13,8 -13,7 +13,9 @@@ Contents
.. toctree::
:maxdepth: 2
+gpu/index
+ kernel-documentation
+ media/media_uapi
Indices and tables
==
Re: [PATCH v2 05/10] power/reset: Add reset driver support for nuc900
On 2016年07月11日 05:56, Paul Gortmaker wrote: On Sun, Jul 10, 2016 at 3:27 AM, Wan Zongshun wrote This driver is to add reset support for nuc900 series, currently, it only supports nuc970 SoC reset. Signed-off-by: Wan Zongshun --- drivers/power/reset/Kconfig| 7 +++ drivers/power/reset/Makefile | 1 + drivers/power/reset/nuc900-reset.c | 93 ++ 3 files changed, 101 insertions(+) create mode 100644 drivers/power/reset/nuc900-reset.c diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig index 9bb2622..8c84892 100644 --- a/drivers/power/reset/Kconfig +++ b/drivers/power/reset/Kconfig @@ -94,6 +94,13 @@ config POWER_RESET_MSM help Power off and restart support for Qualcomm boards. +config POWER_RESET_NUC900 + bool "Nuc900 restart driver" If this driver is bool and not tristate, then please remove all references to MODULE_ and then the module.h include as well. I will remove the following codes in my reset.c driver. MODULE_DEVICE_TABLE(of, of_nuc900_reset_match); #include Thanks, Paul. -- + depends on ARCH_W90X900 + help + Power off and restart support for Nuvoton NUC900 family of + reference boards. + config POWER_RESET_LTC2952 bool "LTC2952 PowerPath power-off driver" depends on OF_GPIO diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile index ab7aa86..d4df889 100644 --- a/drivers/power/reset/Makefile +++ b/drivers/power/reset/Makefile @@ -9,6 +9,7 @@ obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o +obj-$(CONFIG_POWER_RESET_NUC900) += nuc900-reset.o obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o diff --git a/drivers/power/reset/nuc900-reset.c b/drivers/power/reset/nuc900-reset.c new file mode 100644 index 000..49986b7 --- /dev/null +++ b/drivers/power/reset/nuc900-reset.c @@ -0,0 +1,93 @@ +/* + * Copyright 2016 Wan Zongshun + * + * The code contained herein is licensed under the GNU General Public + * License. You may obtain a copy of the GNU General Public License + * Version 2 or later at the following locations: + * + * http://www.opensource.org/licenses/gpl-license.html + * http://www.gnu.org/copyleft/gpl.html + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include [...] ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 2/2] net: ethernet: bcmgenet: use phy_ethtool_{get|set}_link_ksettings
Le 10/07/2016 15:50, Philippe Reynes a écrit :
> Hi all,
>
>
> On 05/07/16 23:40, Ben Hutchings wrote:
>> On Tue, 2016-07-05 at 14:15 -0700, Florian Fainelli wrote:
>>> On 07/05/2016 02:07 PM, Philippe Reynes wrote:
Hi Florian,
On 05/07/16 06:30, Florian Fainelli wrote:
> Le 04/07/2016 16:03, David Miller a écrit :
>> From: Philippe Reynes
>> Date: Sun, 3 Jul 2016 17:33:57 +0200
>>
>>> There are two generics functions
>>> phy_ethtool_{get|set}_link_ksettings,
>>> so we can use them instead of defining the same code in the driver.
>>>
>>> Signed-off-by: Philippe Reynes
>>
>> Applied.
>>
>
> The transformation is not equivalent, we lost the checks on
> netif_running() in the process, and those are here for a reason, if
> the
> interface is down and therefore clock gated, MDIO accesses to the PHY
> will simply fail outright and cause bus errors.
Oh, I see, I've missed this. Sorry for this mistake.
We should revert this path.
>>>
>>> Well, maybe better than that, actually put the check in the generic
>>> functions, because if the link is down, aka netif_running() returns
>>> false, link parameters cannot be reliably queried and they are invalid.
>
> In my understanding, if the link is down, the pointer phydev in the
> struct net_device is NULL. So generic functions
> phy_ethtool_{get|set}_link_ksetting
> should return -ENODEV.
This pointer is NULL only when phy_detach() is called typically by
phy_disconnect(), but remains and needs to be valid reference throughout
the entire time the network interface is open regardless of the link state.
One of the reasons why some drivers are checking for the phydev pointer
to be NULL is because you can have one process open the network
interface, attaching to the PHY at some point in that ndo_open, and
another one calling in ethtool_get_settings for instance and this second
process can see a transient state where the PHY device is not yet
attached (aka NULL).
>
> If I'm wrong, and it everybody agree, I'll send a patch that add a check
> on netif_running.
>
>> Either the hardware or the driver needs to remember:
>>
>> - Is auto-negotiation enabled
>> - If so, which modes are advertised
>> - If not, which mode is forced
>>
>> And it should still be possible to get or set that information when the
>> interface is down.
>
> It could be possible to save the set_link_ksettings request if the link
> is down, and apply it when the link become up.
> It also could be possible to save the last state of the link before it
> goes to down, and return it to a get_link_ksettings when the link is down.
> But what happen if the link was never up before the first
> get_link_kettings ?
Humm, sure, I would take a few examples first and see how consistent
they are with allowing these operations while the link is down and move
from there.
Thanks!
--
Florian
Re: [PATCH] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize
On 8 July 2016 at 21:04, Michal Nazarewicz wrote:
> On Fri, Jul 08 2016, Baolin Wang wrote:
>> On 7 July 2016 at 20:51, Michal Nazarewicz wrote:
>>> On Thu, Jul 07 2016, Baolin Wang wrote:
Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size
attribute, which means it need to align the request buffer's size to an
ep's
maxpacketsize.
Thus we add usb_ep_align_maybe() function to check if it is need to align
the request buffer's size to an ep's maxpacketsize.
Signed-off-by: Baolin Wang
>>>
>>> Acked-by: Michal Nazarewicz
>>>
---
drivers/usb/gadget/function/f_midi.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/gadget/function/f_midi.c
b/drivers/usb/gadget/function/f_midi.c
index 58fc199..2e3f11e 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -328,7 +328,7 @@ static int f_midi_start_ep(struct f_midi *midi,
static int f_midi_set_alt(struct usb_function *f, unsigned intf, unsigned
alt)
{
struct f_midi *midi = func_to_midi(f);
- unsigned i;
+ unsigned i, length;
int err;
/* we only set alt for MIDIStreaming interface */
@@ -345,9 +345,11 @@ static int f_midi_set_alt(struct usb_function *f,
unsigned intf, unsigned alt)
/* pre-allocate write usb requests to use on f_midi_transmit. */
while (kfifo_avail(&midi->in_req_fifo)) {
- struct usb_request *req =
- midi_alloc_ep_req(midi->in_ep, midi->buflen);
+ struct usb_request *req;
+ length = usb_ep_align_maybe(midi->gadget, midi->in_ep,
+ midi->buflen);
+ req = midi_alloc_ep_req(midi->in_ep, length);
if (req == NULL)
return -ENOMEM;
@@ -359,10 +361,12 @@ static int f_midi_set_alt(struct usb_function *f,
unsigned intf, unsigned alt)
/* allocate a bunch of read buffers and queue them all at once. */
for (i = 0; i < midi->qlen && err == 0; i++) {
- struct usb_request *req =
- midi_alloc_ep_req(midi->out_ep,
- max_t(unsigned, midi->buflen,
- bulk_out_desc.wMaxPacketSize));
+ struct usb_request *req;
+
+ length = usb_ep_align_maybe(midi->gadget, midi->out_ep,
+ midi->buflen);
+ req = midi_alloc_ep_req(midi->out_ep,
+ max_t(unsigned, length,
bulk_out_desc.wMaxPacketSize));
>>>
>>> Perhaps:
>>>
>>> + length = midi->buflen < bulk_out_desc.wMaxPacketSize
>>> + ? bulk_out_desc.wMaxPacketSize
>>> + : usb_ep_align_maybe(midi->gadget, midi->out_ep,
>>> +midi->buflen);
>>> + req = midi_alloc_ep_req(midi->out_ep, length);
>>>
>>> I find it somewhat cleaner. Up to you.
>>
>> But if the gadget does not requires 'quirk_ep_out_aligned_size', then
>> we also can keep midi->buflen length although midi->buflen <
>> bulk_out_desc.wMaxPacketSize, right? Thanks for your comment.
>
> I don’t know. That’s not what the original code was doing. The
> original code was using:
>
> max_t(unsigned, midi->buflen, bulk_out_desc.wMaxPacketSize));
OK.
>
> for some reason.>
>
if (req == NULL)
return -ENOMEM;
>>>
>>> --
>>> Best regards
>>> ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
>>> «If at first you don’t succeed, give up skydiving»
>>
>>
>>
>> --
>> Baolin.wang
>> Best Regards
>
> --
> Best regards
> ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
> «If at first you don’t succeed, give up skydiving»
--
Baolin.wang
Best Regards
Re: [PATCH] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize
On 8 July 2016 at 21:27, Felipe Balbi wrote:
>
> Hi again,
>
> Felipe Balbi writes:
>> Michal Nazarewicz writes:
>>> On Fri, Jul 08 2016, Baolin Wang wrote:
On 7 July 2016 at 20:51, Michal Nazarewicz wrote:
> On Thu, Jul 07 2016, Baolin Wang wrote:
>> Some gadget device (such as dwc3 gadget) requires
>> quirk_ep_out_aligned_size
>> attribute, which means it need to align the request buffer's size to an
>> ep's
>> maxpacketsize.
>>
>> Thus we add usb_ep_align_maybe() function to check if it is need to align
>> the request buffer's size to an ep's maxpacketsize.
>>
>> Signed-off-by: Baolin Wang
>
> Acked-by: Michal Nazarewicz
>
>> ---
>> drivers/usb/gadget/function/f_midi.c | 18 +++---
>> 1 file changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c
>> b/drivers/usb/gadget/function/f_midi.c
>> index 58fc199..2e3f11e 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -328,7 +328,7 @@ static int f_midi_start_ep(struct f_midi *midi,
>> static int f_midi_set_alt(struct usb_function *f, unsigned intf,
>> unsigned alt)
>> {
>> struct f_midi *midi = func_to_midi(f);
>> - unsigned i;
>> + unsigned i, length;
>> int err;
>>
>> /* we only set alt for MIDIStreaming interface */
>> @@ -345,9 +345,11 @@ static int f_midi_set_alt(struct usb_function *f,
>> unsigned intf, unsigned alt)
>>
>> /* pre-allocate write usb requests to use on f_midi_transmit. */
>> while (kfifo_avail(&midi->in_req_fifo)) {
>> - struct usb_request *req =
>> - midi_alloc_ep_req(midi->in_ep, midi->buflen);
>> + struct usb_request *req;
>>
>> + length = usb_ep_align_maybe(midi->gadget, midi->in_ep,
>> + midi->buflen);
>> + req = midi_alloc_ep_req(midi->in_ep, length);
>> if (req == NULL)
>> return -ENOMEM;
>>
>> @@ -359,10 +361,12 @@ static int f_midi_set_alt(struct usb_function *f,
>> unsigned intf, unsigned alt)
>>
>> /* allocate a bunch of read buffers and queue them all at once. */
>> for (i = 0; i < midi->qlen && err == 0; i++) {
>> - struct usb_request *req =
>> - midi_alloc_ep_req(midi->out_ep,
>> - max_t(unsigned, midi->buflen,
>> - bulk_out_desc.wMaxPacketSize));
>> + struct usb_request *req;
>> +
>> + length = usb_ep_align_maybe(midi->gadget, midi->out_ep,
>> + midi->buflen);
>> + req = midi_alloc_ep_req(midi->out_ep,
>> + max_t(unsigned, length,
>> bulk_out_desc.wMaxPacketSize));
>
> Perhaps:
>
> + length = midi->buflen < bulk_out_desc.wMaxPacketSize
> + ? bulk_out_desc.wMaxPacketSize
> + : usb_ep_align_maybe(midi->gadget, midi->out_ep,
> +midi->buflen);
> + req = midi_alloc_ep_req(midi->out_ep, length);
>
> I find it somewhat cleaner. Up to you.
But if the gadget does not requires 'quirk_ep_out_aligned_size', then
we also can keep midi->buflen length although midi->buflen <
bulk_out_desc.wMaxPacketSize, right? Thanks for your comment.
>>>
>>> I don’t know. That’s not what the original code was doing. The
>>> original code was using:
>>>
>>> max_t(unsigned, midi->buflen, bulk_out_desc.wMaxPacketSize));
>>>
>>> for some reason.>
>>
>> My take on this is that it's calling max_t() to try and align to
>> wMaxPacketSize. We can see from original commit what was the intent:
>>
>> commit 03d27ade4941076b34c823d63d91dc895731a595
>> Author: Felipe F. Tonello
>> Date: Wed Mar 9 19:39:30 2016 +
>>
>> usb: gadget: f_midi: Fixed a bug when buflen was smaller than
>> wMaxPacketSize
>>
>> buflen by default (256) is smaller than wMaxPacketSize (512) in
>> high-speed
>> devices.
>>
>> That caused the OUT endpoint to freeze if the host send any data packet
>> of
>> length greater than 256 bytes.
>>
>> This is an example dump of what happended on that enpoint:
>> HOST: [DATA][Length=260][...]
>> DEVICE: [NAK]
>> HOST: [PING]
>> DEVICE: [NAK]
>> HOST: [PING]
>> DEVICE: [NAK]
>> ...
>> HOST: [PING]
>> DEVICE: [NAK]
>>
>> This patch fixes this problem by setting the minimum usb_request's
>> buffer size
>> for the OUT endpoint as its wMaxPacketSize.
>>
>> Acked-by: Michal Nazarewicz
>> Signed-off-by: Felipe F. Tonello
>> Si
Re: [PATCH] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize
On 8 July 2016 at 21:21, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size
>> attribute, which means it need to align the request buffer's size to an ep's
>> maxpacketsize.
>>
>> Thus we add usb_ep_align_maybe() function to check if it is need to align
>> the request buffer's size to an ep's maxpacketsize.
>>
>> Signed-off-by: Baolin Wang
>> ---
>> drivers/usb/gadget/function/f_midi.c | 18 +++---
>> 1 file changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c
>> b/drivers/usb/gadget/function/f_midi.c
>> index 58fc199..2e3f11e 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -328,7 +328,7 @@ static int f_midi_start_ep(struct f_midi *midi,
>> static int f_midi_set_alt(struct usb_function *f, unsigned intf, unsigned
>> alt)
>> {
>> struct f_midi *midi = func_to_midi(f);
>> - unsigned i;
>> + unsigned i, length;
>> int err;
>>
>> /* we only set alt for MIDIStreaming interface */
>> @@ -345,9 +345,11 @@ static int f_midi_set_alt(struct usb_function *f,
>> unsigned intf, unsigned alt)
>>
>> /* pre-allocate write usb requests to use on f_midi_transmit. */
>> while (kfifo_avail(&midi->in_req_fifo)) {
>> - struct usb_request *req =
>> - midi_alloc_ep_req(midi->in_ep, midi->buflen);
>> + struct usb_request *req;
>>
>> + length = usb_ep_align_maybe(midi->gadget, midi->in_ep,
>> + midi->buflen);
>
> this is not needed for in_ep, only out_ep, right?
Yes. You are right.
>
>> + req = midi_alloc_ep_req(midi->in_ep, length);
>> if (req == NULL)
>> return -ENOMEM;
>>
>> @@ -359,10 +361,12 @@ static int f_midi_set_alt(struct usb_function *f,
>> unsigned intf, unsigned alt)
>>
>> /* allocate a bunch of read buffers and queue them all at once. */
>> for (i = 0; i < midi->qlen && err == 0; i++) {
>> - struct usb_request *req =
>> - midi_alloc_ep_req(midi->out_ep,
>> - max_t(unsigned, midi->buflen,
>> - bulk_out_desc.wMaxPacketSize));
>> + struct usb_request *req;
>> +
>> + length = usb_ep_align_maybe(midi->gadget, midi->out_ep,
>> + midi->buflen);
>
> after calling usb_ep_align_maybe()...
>
>> + req = midi_alloc_ep_req(midi->out_ep,
>> + max_t(unsigned, length, bulk_out_desc.wMaxPacketSize));
>
> ... max_t() is pointless. length will *always* >= wMaxPacketSize.
It is not. If the gadget device dose not require
quirk_ep_out_aligned_size, then the lengh may be <= wMaxPacketSize.
--
Baolin.wang
Best Regards
